[U-Boot] Kernel OOPS on memcpy - bad memory setup?

[U-Boot] Kernel OOPS on memcpy - bad memory setup?

[Kristoffer Ericson]

Greetings,

Getting an kernel oops after running an package manager (ipkg). Not seeing it anywhere
else, but dont have any large binaries (busybox).

So, I assume I have made some memory error in u-boot?

Best wishes
Kristoffer

LOG:
[   25.195972] udevd (417): /proc/417/oom_adj is deprecated, please use /proc/417/oom_score_adj instead.
[   26.664276] Adding 34200k swap on /opt/swapfile.  Priority:-1 extents:10 across:34240k 
[   90.617094] Unable to handle kernel paging request at virtual address 2d429000
[   90.764870] pgd = c7d84000
[   90.832643] [2d429000] *pgd=00000000
[   90.904966] Internal error: Oops: 47d87805 [#1]
[   90.984380] last sysfs file: /sys/kernel/uevent_seqnum
[   91.069037] CPU: 0    Not tainted  (2.6.36-hpc+ #6)
[   91.152013] PC is at memcpy+0x30/0x29c
[   91.227604] LR is at 0x70692e6d
[   91.298029] pc : [<c031f590>]    lr : [<70692e6d>]    psr: 20000093
[   91.298062] sp : c7d7fd08  ip : 72615f35  fp : c7d7fd4c
[   91.470248] r10: 00000000  r9 : c7d0c6a0  r8 : 32722d38
[   91.551723] r7 : 2e382e35  r6 : 5f73706f  r5 : 2d656c75  r4 : 646f6d2d
[   91.641784] r3 : 6c726570  r2 : 00000fc0  r1 : c0048020  r0 : 2d429000
[   91.731741] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   91.875472] Control: c7d8717f  Table: c7d8717f  DAC: 00000015
[   91.961726] Process ipkg (pid: 572, stack limit = 0xc7d7e260)
[   92.047824] Stack: (0xc7d7fd08 to 0xc7d80000)
[   92.124740] fd00:                   c7d95c80 0000001d 0000015c c7d95d00 2d429000 c7d1245c
[   92.276297] fd20: c028f608 c7d95c80 c7d753e8 00000000 00020000 00000000 00000000 00000000
[   92.427886] fd40: c7d7fd5c c7d7fd50 c028f65c c028f560 c7d7fd6c c7d7fd60 c02bfd50 c028f64c
[   92.581195] fd60: c7d7fd88 c7d7fd70 c030ff4c c02bfd08 c7d95c80 00020000 c7d753e8 c7d7fdb8
[   92.734712] fd80: c7d7fd8c c031009c c030fe80 00000000 c7d753e8 00000000 00000000 00000040
[   92.889737] fda0: 00000001 c01da494 c01da400 c7d7fdd8 c7d7fdbc c031033c c030ff7c c01da400
[   93.046471] fdc0: c7d753e8 00000000 00000040 c7d7fdf8 c7d7fddc c0310e14 c031032c c01da400
[   93.207687] fde0: 00000050 c01ce400 00000040 c7d7fe08 c7d7fdfc c0310e6c c0310e08 c7d7fe18
[   93.373300] fe00: c7d7fe0c c03666d8 c0310e64 c7d7fe2c c7d7fe1c c0366730 c03666a8 c01da400
[   93.541968] fe20: c7d7fe58 c7d7fe30 c036a22c c03666e8 c01da400 c01f4960 00000000 40000093
[   93.715230] fe40: c036a0c0 c04b6640 c01ce400 c7d7fe80 c7d7fe5c c03664b4 c036a0cc c01fb640
[   93.891486] fe60: 00000073 00000001 00000000 00000000 00000001 c7d7fea4 c7d7fe84 c0263160
[   94.071438] fe80: c036633c c04b89e0 c01fb640 00000073 c04d02f4 c0142c60 c7d7fec4 c7d7fea8
[   94.253160] fea0: c0264ebc c026313c 00000073 00000032 00000000 00000000 c7d7fef0 c7d7fec8
[   94.436933] fec0: c0228850 c0264dc4 00000001 c7d7ffb0 00000002 00000202 00000000 c04cd984
[   94.622731] fee0: 0000000a c7d7ff08 c7d7fef4 c0220078 c0228788 ffffffff fa050000 c7d7ff84
[   94.810257] ff00: c7d7ff0c c02208ec c022000c c04cd960 c7d7e000 00000000 20000013 0000001a
[   94.997749] ff20: c7d7e000 00000000 00000202 00000000 c04cd984 0000000a c7d7ff84 c7d7ff88
[   95.185309] ff40: c7d7ff54 c024097c c0240694 60000013 ffffffff c0263160 c04b6e10 0000001a
[   95.372794] ff60: 00000000 00000001 00001c7a 00000000 c7d7e000 401f5188 c7d7ff94 c7d7ff88
[   95.560093] ff80: c024097c c024064c c7d7ffac c7d7ff98 c022007c c0240948 ffffffff fa050000
[   95.747426] ffa0: 00000000 c7d7ffb0 c0220ae8 c022000c 0008bac8 00000000 00000041 00000001
[   95.934715] ffc0: 00000037 00063d00 00001000 00001c7a 00000000 00021490 401f5188 0008e9e8
[   96.122023] ffe0: 00000001 bea9badc 00001fd0 40260814 60000010 ffffffff c7ffe031 c7ffe431
[   96.309348] Backtrace: 
[   96.390184] [<c028f554>] (__bounce_end_io_read+0x0/0xec) from [<c028f65c>] (bounce_end_io_read_isa+0x1c/0x24)
[   96.585508] [<c028f640>] (bounce_end_io_read_isa+0x0/0x24) from [<c02bfd50>] (bio_endio+0x54/0x58)
[   96.775490] [<c02bfcfc>] (bio_endio+0x0/0x58) from [<c030ff4c>] (req_bio_endio+0xd8/0xfc)
[   96.961106] [<c030fe74>] (req_bio_endio+0x0/0xfc) from [<c031009c>] (blk_update_request+0x12c/0x3b0)
[   97.153259]  r6:c7d753e8 r5:00020000 r4:c7d95c80
[   97.248362] [<c030ff70>] (blk_update_request+0x0/0x3b0) from [<c031033c>] (blk_update_bidi_request+0x1c/0x6c)
[   97.444051] [<c0310320>] (blk_update_bidi_request+0x0/0x6c) from [<c0310e14>] (blk_end_bidi_request+0x18/0x5c)
[   97.641155]  r7:00000040 r6:00000000 r5:c7d753e8 r4:c01da400
[   97.743099] [<c0310dfc>] (blk_end_bidi_request+0x0/0x5c) from [<c0310e6c>] (blk_end_request+0x14/0x18)
[   97.935168]  r7:00000040 r6:c01ce400 r5:00000050 r4:c01da400
[   98.036771] [<c0310e58>] (blk_end_request+0x0/0x18) from [<c03666d8>] (ide_end_rq+0x3c/0x40)
[   98.222439] [<c036669c>] (ide_end_rq+0x0/0x40) from [<c0366730>] (ide_complete_rq+0x54/0x60)
[   98.408814] [<c03666dc>] (ide_complete_rq+0x0/0x60) from [<c036a22c>] (task_pio_intr+0x16c/0x1f0)
[   98.598631]  r4:c01da400
[   98.679114] [<c036a0c0>] (task_pio_intr+0x0/0x1f0) from [<c03664b4>] (ide_intr+0x184/0x250)
[   98.862871] [<c0366330>] (ide_intr+0x0/0x250) from [<c0263160>] (handle_IRQ_event+0x30/0xf4)
[   99.047770] [<c0263130>] (handle_IRQ_event+0x0/0xf4) from [<c0264ebc>] (handle_edge_irq+0x104/0x164)
[   99.240827]  r8:c0142c60 r7:c04d02f4 r6:00000073 r5:c01fb640 r4:c04b89e0
[   99.350444] [<c0264db8>] (handle_edge_irq+0x0/0x164) from [<c0228850>] (sa1111_irq_handler+0xd4/0xf4)
[   99.543455]  r7:00000000 r6:00000000 r5:00000032 r4:00000073
[   99.645480] [<c022877c>] (sa1111_irq_handler+0x0/0xf4) from [<c0220078>] (asm_do_IRQ+0x78/0x9c)
[   99.833488] [<c0220000>] (asm_do_IRQ+0x0/0x9c) from [<c02208ec>] (__irq_svc+0x2c/0xa0)
[  100.017497] Exception stack(0xc7d7ff0c to 0xc7d7ff54)
[  100.116493] ff00:                            c04cd960 c7d7e000 00000000 20000013 0000001a
[  100.300200] ff20: c7d7e000 00000000 00000202 00000000 c04cd984 0000000a c7d7ff84 c7d7ff88
[  100.482375] ff40: c7d7ff54 c024097c c0240694 60000013 ffffffff
[  100.584664]  r5:fa050000 r4:ffffffff
[  100.670851] [<c0240640>] (__do_softirq+0x0/0x110) from [<c024097c>] (irq_exit+0x40/0x48)
[  100.851666] [<c024093c>] (irq_exit+0x0/0x48) from [<c022007c>] (asm_do_IRQ+0x7c/0x9c)
[  101.030912] [<c0220000>] (asm_do_IRQ+0x0/0x9c) from [<c0220ae8>] (__irq_usr+0x48/0xc0)
[  101.210396] Exception stack(0xc7d7ffb0 to 0xc7d7fff8)
[  101.306439] ffa0:                                     0008bac8 00000000 00000041 00000001
[  101.487559] ffc0: 00000037 00063d00 00001000 00001c7a 00000000 00021490 401f5188 0008e9e8
[  101.667226] ffe0: 00000001 bea9badc 00001fd0 40260814 60000010 ffffffff
[  101.772855]  r5:fa050000 r4:ffffffff
[  101.857748] Code: e92d01e0 ba000003 e8b151f8 e2522020 (e8a051f8) 
[  101.971402] ---[ end trace 6605307e29c0d995 ]---
[  102.062940] Kernel panic - not syncing: Fatal exception in interrupt
[  102.165115] Backtrace: 
[  102.241096] [<c0223fd8>] (dump_backtrace+0x0/0x110) from [<c022411c>] (dump_stack+0x18/0x1c)
[  102.417506]  r6:c7d7fcc0 r5:c7d7e000 r4:c04c904c
[  102.507326] [<c0224104>] (dump_stack+0x0/0x1c) from [<c023b518>] (panic+0x60/0x19c)
[  102.676799] [<c023b4b8>] (panic+0x0/0x19c) from [<c0224424>] (die+0x17c/0x1bc)
[  102.845391]  r3:00010100 r2:c04974ac r1:00000000 r0:c048ed0c
[  102.943232] [<c02242a8>] (die+0x0/0x1bc) from [<c0225680>] (__do_kernel_fault+0x6c/0x90)
[  103.118470]  r8:00000000 r7:47d87805 r6:c7d90780 r5:c7d7fcc0 r4:2d429000
[  103.223741] [<c0225614>] (__do_kernel_fault+0x0/0x90) from [<c0225910>] (do_page_fault+0x26c/0x28c)
[  103.407223]  r8:2d429000 r7:2d429000 r6:47d87805 r5:c7d7fcc0 r4:ffffffff
[  103.513279] [<c02256a4>] (do_page_fault+0x0/0x28c) from [<c02259d8>] (do_translation_fault+0x24/0xac)
[  103.697401] [<c02259b4>] (do_translation_fault+0x0/0xac) from [<c02202d4>] (do_DataAbort+0x40/0xa4)
[  103.880806]  r6:c7d87805 r5:c04b2db8 r4:ffffffff
[  103.972998] [<c0220294>] (do_DataAbort+0x0/0xa4) from [<c02208a0>] (__dabt_svc+0x40/0x60)
[  104.151881] Exception stack(0xc7d7fcc0 to 0xc7d7fd08)
[  104.247706] fcc0: 2d429000 c0048020 00000fc0 6c726570 646f6d2d 2d656c75 5f73706f 2e382e35
[  104.426405] fce0: 32722d38 c7d0c6a0 00000000 c7d7fd4c 72615f35 c7d7fd08 70692e6d c031f590
[  104.606820] fd00: 20000093 ffffffff
[  104.692761]  r8:32722d38 r7:2e382e35 r6:5f73706f r5:c7d7fcf4 r4:ffffffff
[  104.799707] [<c028f554>] (__bounce_end_io_read+0x0/0xec) from [<c028f65c>] (bounce_end_io_read_isa+0x1c/0x24)
[  104.991790] [<c028f640>] (bounce_end_io_read_isa+0x0/0x24) from [<c02bfd50>] (bio_endio+0x54/0x58)
[  105.179096] [<c02bfcfc>] (bio_endio+0x0/0x58) from [<c030ff4c>] (req_bio_endio+0xd8/0xfc)
[  105.363043] [<c030fe74>] (req_bio_endio+0x0/0xfc) from [<c031009c>] (blk_update_request+0x12c/0x3b0)
[  105.553088]  r6:c7d753e8 r5:00020000 r4:c7d95c80
[  105.648141] [<c030ff70>] (blk_update_request+0x0/0x3b0) from [<c031033c>] (blk_update_bidi_request+0x1c/0x6c)
[  105.842643] [<c0310320>] (blk_update_bidi_request+0x0/0x6c) from [<c0310e14>] (blk_end_bidi_request+0x18/0x5c)
[  106.038614]  r7:00000040 r6:00000000 r5:c7d753e8 r4:c01da400
[  106.140453] [<c0310dfc>] (blk_end_bidi_request+0x0/0x5c) from [<c0310e6c>] (blk_end_request+0x14/0x18)
[  106.331397]  r7:00000040 r6:c01ce400 r5:00000050 r4:c01da400
[  106.432923] [<c0310e58>] (blk_end_request+0x0/0x18) from [<c03666d8>] (ide_end_rq+0x3c/0x40)
[  106.616840] [<c036669c>] (ide_end_rq+0x0/0x40) from [<c0366730>] (ide_complete_rq+0x54/0x60)
[  106.802931] [<c03666dc>] (ide_complete_rq+0x0/0x60) from [<c036a22c>] (task_pio_intr+0x16c/0x1f0)
[  106.992778]  r4:c01da400
[  107.074042] [<c036a0c0>] (task_pio_intr+0x0/0x1f0) from [<c03664b4>] (ide_intr+0x184/0x250)
[  107.258578] [<c0366330>] (ide_intr+0x0/0x250) from [<c0263160>] (handle_IRQ_event+0x30/0xf4)
[  107.445595] [<c0263130>] (handle_IRQ_event+0x0/0xf4) from [<c0264ebc>] (handle_edge_irq+0x104/0x164)
[  107.639557]  r8:c0142c60 r7:c04d02f4 r6:00000073 r5:c01fb640 r4:c04b89e0
[  107.750323] [<c0264db8>] (handle_edge_irq+0x0/0x164) from [<c0228850>] (sa1111_irq_handler+0xd4/0xf4)
[  107.944169]  r7:00000000 r6:00000000 r5:00000032 r4:00000073
[  108.047246] [<c022877c>] (sa1111_irq_handler+0x0/0xf4) from [<c0220078>] (asm_do_IRQ+0x78/0x9c)
[  108.236274] [<c0220000>] (asm_do_IRQ+0x0/0x9c) from [<c02208ec>] (__irq_svc+0x2c/0xa0)
[  108.421183] Exception stack(0xc7d7ff0c to 0xc7d7ff54)
[  108.520790] ff00:                            c04cd960 c7d7e000 00000000 20000013 0000001a
[  108.705437] ff20: c7d7e000 00000000 00000202 00000000 c04cd984 0000000a c7d7ff84 c7d7ff88
[  108.888840] ff40: c7d7ff54 c024097c c0240694 60000013 ffffffff
[  108.991688]  r5:fa050000 r4:ffffffff
[  109.078653] [<c0240640>] (__do_softirq+0x0/0x110) from [<c024097c>] (irq_exit+0x40/0x48)
[  109.260573] [<c024093c>] (irq_exit+0x0/0x48) from [<c022007c>] (asm_do_IRQ+0x7c/0x9c)
[  109.440820] [<c0220000>] (asm_do_IRQ+0x0/0x9c) from [<c0220ae8>] (__irq_usr+0x48/0xc0)
[  109.621346] Exception stack(0xc7d7ffb0 to 0xc7d7fff8)
[  109.717713] ffa0:                                     0008bac8 00000000 00000041 00000001
[  109.899720] ffc0: 00000037 00063d00 00001000 00001c7a 00000000 00021490 401f5188 0008e9e8
[  110.080452] ffe0: 00000001 bea9badc 00001fd0 40260814 60000010 ffffffff
[  110.186387]  r5:fa050000 r4:ffffffff

[U-Boot] Kernel OOPS on memcpy - bad memory setup?

[Wolfgang Denk]

Dear Kristoffer Ericson,

In message <20101027214641.GC892@boggieman.bredbandsbolaget.se> you wrote:
> Greetings,
> 
> Getting an kernel oops after running an package manager (ipkg). Not seeing it anywhere
> else, but dont have any large binaries (busybox).
> 
> So, I assume I have made some memory error in u-boot?

No. U-Boot is long dead and gone when Linux boots.

Linux kernel oopses are a Linux issue.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Men will always be men -- no matter where they are.
	-- Harry Mudd, "Mudd's Women", stardate 1329.8

[U-Boot] Kernel OOPS on memcpy - bad memory setup?

[Chris Isbell]

-----Original Message-----
From: Kristoffer Ericson <kristoffer.ericson@gmail.com>
Reply-to: Kristoffer Ericson <kristoffer.ericson@gmail.com>
To: wd at denx.de
Cc: u-boot at lists.denx.de
Subject: [U-Boot] Kernel OOPS on memcpy - bad memory setup?
Date: Wed, 27 Oct 2010 23:46:41 +0200


Greetings,

Getting an kernel oops after running an package manager (ipkg). Not seeing it anywhere
else, but dont have any large binaries (busybox).

So, I assume I have made some memory error in u-boot?

Best wishes
Kristoffer


Dear Kristoffer,

I experienced a similar problem when U-Boot configured the SDRAM
controller incorrectly, so only half of the memory was being refreshed.

Regards,


Chris.

-- 
Chris Isbell
Systems Integration Manager, CDSRail
Fareham, Hampshire, UK.

[U-Boot] Kernel OOPS on memcpy - bad memory setup?

[Kristoffer Ericson]

On Thu, Oct 28, 2010 at 07:55:49AM +0100, Chris Isbell wrote:
> -----Original Message-----
> From: Kristoffer Ericson <kristoffer.ericson@gmail.com>
> Reply-to: Kristoffer Ericson <kristoffer.ericson@gmail.com>
> To: wd at denx.de
> Cc: u-boot at lists.denx.de
> Subject: [U-Boot] Kernel OOPS on memcpy - bad memory setup?
> Date: Wed, 27 Oct 2010 23:46:41 +0200
> 
> 
> Greetings,
> 
> Getting an kernel oops after running an package manager (ipkg). Not seeing it anywhere
> else, but dont have any large binaries (busybox).
> 
> So, I assume I have made some memory error in u-boot?
> 
> Best wishes
> Kristoffer
> 
> 
> Dear Kristoffer,
> 
> I experienced a similar problem when U-Boot configured the SDRAM
> controller incorrectly, so only half of the memory was being refreshed.

I was thinking somewhere in those lines, since linux pretty much
assumes that the bootloader already have the memory fully setup.
It could also be some cpufreq thing where I havent added the correct
memory settings yet (testing it now).

Thanks

> 
> Regards,
> 
> 
> Chris.
> 
> -- 
> Chris Isbell
> Systems Integration Manager, CDSRail
> Fareham, Hampshire, UK.

[U-Boot] Kernel OOPS on memcpy - bad memory setup?

[Kristoffer Ericson]

On Thu, Oct 28, 2010 at 12:04:56AM +0200, Wolfgang Denk wrote:
> Dear Kristoffer Ericson,
> 
> In message <20101027214641.GC892@boggieman.bredbandsbolaget.se> you wrote:
> > Greetings,
> > 
> > Getting an kernel oops after running an package manager (ipkg). Not seeing it anywhere
> > else, but dont have any large binaries (busybox).
> > 
> > So, I assume I have made some memory error in u-boot?
> 
> No. U-Boot is long dead and gone when Linux boots.
> 

Is that true even if I were to setup the memory registers incorrect?
I thought that linux pretty much expected the bootloader
to setup everything regarding the memory settings?

Oh, and IF I configured the memory incorrect, I should be able
to see somekind of fault when doing a memtest in u-boot, correct?
Or atleast that the write != read values?
And if I dont see that, then its linux kernel problem?

> Linux kernel oopses are a Linux issue.
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Men will always be men -- no matter where they are.
> 	-- Harry Mudd, "Mudd's Women", stardate 1329.8

[U-Boot] Kernel OOPS on memcpy - bad memory setup?

[Wolfgang Denk]

Dear Kristoffer Ericson,

In message <20101028190714.GD893@boggieman.bredbandsbolaget.se> you wrote:
>
> > No. U-Boot is long dead and gone when Linux boots.
> 
> Is that true even if I were to setup the memory registers incorrect?

It is truye that U-Boot ceases to exist as soon as Linux starts
executing.

> I thought that linux pretty much expected the bootloader
> to setup everything regarding the memory settings?

Of course Linux relies on proper hardware initialization by the boot
loader.

> Oh, and IF I configured the memory incorrect, I should be able
> to see somekind of fault when doing a memtest in u-boot, correct?

No. Usually this is NOT the case.

> Or atleast that the write != read values?

No. Please read the FAQ:
http://www.denx.de/wiki/DULG/UBootCrashAfterRelocation

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"He was so narrow minded he could see through  a  keyhole  with  both
eyes ..."

[U-Boot] Kernel OOPS on memcpy - bad memory setup?

[Kristoffer Ericson]

On Thu, Oct 28, 2010 at 09:15:55PM +0200, Wolfgang Denk wrote:
> Dear Kristoffer Ericson,
> 
> In message <20101028190714.GD893@boggieman.bredbandsbolaget.se> you wrote:
> >
> > > No. U-Boot is long dead and gone when Linux boots.
> > 
> > Is that true even if I were to setup the memory registers incorrect?
> 
> It is truye that U-Boot ceases to exist as soon as Linux starts
> executing.
> 
> > I thought that linux pretty much expected the bootloader
> > to setup everything regarding the memory settings?
> 
> Of course Linux relies on proper hardware initialization by the boot
> loader.
> 

alright.

> > Oh, and IF I configured the memory incorrect, I should be able
> > to see somekind of fault when doing a memtest in u-boot, correct?
> 
> No. Usually this is NOT the case.
> 
> > Or atleast that the write != read values?
> 
> No. Please read the FAQ:
> http://www.denx.de/wiki/DULG/UBootCrashAfterRelocation
> 

Very useful information. So in short (just to make it crystal clear):
Even if u-boot works fine and linux starts without
any issues and can run some binaries (busybox from what I see) okey. 
If I am seeing some kernel oops when running bigger binaries (e.g apt/ipkg) / doing heavier stuff 
(trying to ftp/lynx through pcmcia card), it could be cause by bad memory configuration and/or bad initialization?

> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> "He was so narrow minded he could see through  a  keyhole  with  both
> eyes ..."

[U-Boot] Kernel OOPS on memcpy - bad memory setup?

[Wolfgang Denk]

Dear Kristoffer Ericson,

In message <20101028195324.GF893@boggieman.bredbandsbolaget.se> you wrote:
>
> Very useful information. So in short (just to make it crystal clear):
> Even if u-boot works fine and linux starts without
> any issues and can run some binaries (busybox from what I see) okey. 
> If I am seeing some kernel oops when running bigger binaries (e.g apt/ipkg) / doing heavier stuff 
> (trying to ftp/lynx through pcmcia card), it could be cause by bad memory configuration and/or bad initialization?

Yes, especially that are such symptoms. Of course, broken hardware is
also an option.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I will also, for an appropriate fee, certify that  your  keyboard  is
object-oriented,  and  that  the bits on your hard disk are template-
compatible.            - Jeffrey S. Haemer in <411akr$3ga@cygnus.com>