[U-Boot] Kernel OOPS on memcpy - bad memory setup?
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
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
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@denx.de Men will always be men -- no matter where they are. -- Harry Mudd, "Mudd's Women", stardate 1329.8
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
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@denx.de "He was so narrow minded he could see through a keyhole with both eyes ..."
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
-----Original Message----- From: Kristoffer Ericson kristoffer.ericson@gmail.com Reply-to: Kristoffer Ericson kristoffer.ericson@gmail.com To: wd@denx.de Cc: u-boot@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.
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@denx.de Cc: u-boot@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.
participants (3)
-
Chris Isbell -
Kristoffer Ericson -
Wolfgang Denk