I am not at a computer. But i think it was the 3.6.11 release has a tcp bug fix in it. You might see if the symptoms match.. it might have also been backported or irrelevent or i maybe mistaken.
----- Reply message ----- From: "Quentin Armitage" quentin@armitage.org.uk To: "arm@lists.fedoraproject.org" arm@lists.fedoraproject.org Subject: [fedora-arm] Git causing kernel lockup Date: Mon, Dec 24, 2012 07:09 I'm using F18-beta-rc3 on a Dreamplug and experiencing kernel soft lockups when I do a git clone. I first noticed this happening with the 3.6.3-3.f18.armv5tel.kirkwood kernel (it may occur on earlier versions too), but it is still occurring with 3.6.10-6.fc18.armv5tel.kirkwood.
I get the following output on the console: [ 3531.311277] BUG: soft lockup - CPU#0 stuck for 22s! [git:678] [ 3531.317052] Modules linked in: 8021q garp stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6table_mangle ip6_tables xt_conntrack iptable_mangle ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ledtrig_timer snd_usb_audio vfat fat snd_usbmidi_lib snd_hwdep snd_rawmidi snd_seq snd_seq_device snd_pcm btmrvl_sdio btmrvl snd_page_alloc snd_timer snd soundcore libertas_sdio bluetooth libertas cfg80211 rfkill leds_gpio mv643xx_eth mmc_block sata_mv mvsdio mmc_core mv_cesa usb_storage [ 3531.364479] [ 3531.365971] Pid: 678, comm: git [ 3531.370604] CPU: 0 Not tainted (3.6.10-6.fc18.armv5tel.kirkwood #1) [ 3531.377259] PC is at __dma_page_dev_to_cpu+0x68/0xcc [ 3531.382247] LR is at dma_async_memcpy_pg_to_pg+0x150/0x1dc [ 3531.387758] pc : [<c000fa44>] lr : [<c0236274>] psr: 60000013 [ 3531.387758] sp : deb2dcf0 ip : 0001ee9d fp : 00000000 [ 3531.399282] r10: c09f9880 r9 : 00000fda r8 : 1ee9d07c [ 3531.404524] r7 : 00000001 r6 : 0000007c r5 : 00000026 r4 : c0b563a0 [ 3531.411073] r3 : c064e03c r2 : 00000000 r1 : 0000007c r0 : c0b563a0 [ 3531.417622] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 3531.424790] Control: 0005397f Table: 1eb40000 DAC: 00000015 [ 3531.430571] [<c000edac>] (unwind_backtrace+0x0/0x124) from [<c0074d40>] (watchdog_timer_fn+0xe8/0x13c) [ 3531.439929] [<c0074d40>] (watchdog_timer_fn+0xe8/0x13c) from [<c003aa18>] (__run_hrtimer+0xb0/0x1d4) [ 3531.449109] [<c003aa18>] (__run_hrtimer+0xb0/0x1d4) from [<c003b22c>] (hrtimer_interrupt+0x104/0x250) [ 3531.458383] [<c003b22c>] (hrtimer_interrupt+0x104/0x250) from [<c0016024>] (orion_timer_interrupt+0x24/0x34) [ 3531.468259] [<c0016024>] (orion_timer_interrupt+0x24/0x34) from [<c00754cc>] (handle_irq_event_percpu+0x38/0x23c) [ 3531.478572] [<c00754cc>] (handle_irq_event_percpu+0x38/0x23c) from [<c0075700>] (handle_irq_event+0x30/0x40) [ 3531.488445] [<c0075700>] (handle_irq_event+0x30/0x40) from [<c0077d30>] (handle_level_irq+0xcc/0xdc) [ 3531.497616] [<c0077d30>] (handle_level_irq+0xcc/0xdc) from [<c0074ef8>] (generic_handle_irq+0x28/0x38) [ 3531.506965] [<c0074ef8>] (generic_handle_irq+0x28/0x38) from [<c0009b64>] (handle_IRQ+0x68/0x8c) [ 3531.515796] [<c0009b64>] (handle_IRQ+0x68/0x8c) from [<c0444af4>] (__irq_svc+0x34/0x78) [ 3531.523843] [<c0444af4>] (__irq_svc+0x34/0x78) from [<c000fa44>] (__dma_page_dev_to_cpu+0x68/0xcc) [ 3531.532847] [<c000fa44>] (__dma_page_dev_to_cpu+0x68/0xcc) from [<c0236274>] (dma_async_memcpy_pg_to_pg+0x150/0x1dc) [ 3531.543416] [<c0236274>] (dma_async_memcpy_pg_to_pg+0x150/0x1dc) from [<c02377a8>] (dma_memcpy_pg_to_iovec+0xf0/0x180) [ 3531.554161] [<c02377a8>] (dma_memcpy_pg_to_iovec+0xf0/0x180) from [<c03835d0>] (dma_skb_copy_datagram_iovec+0x100/0x1d4) [ 3531.565092] [<c03835d0>] (dma_skb_copy_datagram_iovec+0x100/0x1d4) from [<c03a9c3c>] (tcp_recvmsg+0x630/0xac0) [ 3531.575143] [<c03a9c3c>] (tcp_recvmsg+0x630/0xac0) from [<c03c9138>] (inet_recvmsg+0x48/0x5c) [ 3531.583713] [<c03c9138>] (inet_recvmsg+0x48/0x5c) from [<c035bcfc>] (sock_aio_read+0x100/0x120) [ 3531.592460] [<c035bcfc>] (sock_aio_read+0x100/0x120) from [<c00e5524>] (do_sync_read+0x98/0xd4) [ 3531.601204] [<c00e5524>] (do_sync_read+0x98/0xd4) from [<c00e5e98>] (vfs_read+0xb4/0x184) [ 3531.609416] [<c00e5e98>] (vfs_read+0xb4/0x184) from [<c00e5fa4>] (sys_read+0x3c/0x70) [ 3531.617281] [<c00e5fa4>] (sys_read+0x3c/0x70) from [<c0008c60>] (ret_fast_syscall+0x0/0x2c) [ 3559.310637] BUG: soft lockup - CPU#0 stuck for 22s! [git:678] [ 3559.316404] Modules linked in: 8021q garp stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6table_mangle ip6_tables xt_conntrack iptable_mangle ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ledtrig_timer snd_usb_audio vfat fat snd_usbmidi_lib snd_hwdep snd_rawmidi snd_seq snd_seq_device snd_pcm btmrvl_sdio btmrvl snd_page_alloc snd_timer snd soundcore libertas_sdio bluetooth libertas cfg80211 rfkill leds_gpio mv643xx_eth mmc_block sata_mv mvsdio mmc_core mv_cesa usb_storage [ 3559.365324] Pid: 678, comm: git [ 3559.369957] CPU: 0 Not tainted (3.6.10-6.fc18.armv5tel.kirkwood #1) [ 3559.376611] PC is at __dma_page_dev_to_cpu+0x60/0xcc [ 3559.381600] LR is at __kunmap_atomic+0x7c/0x110 [ 3559.386152] pc : [<c000fa3c>] lr : [<c0012910>] psr: 60000013 [ 3559.386152] sp : deb2dcf0 ip : 00014044 fp : 00000000 [ 3559.397676] r10: c09f9880 r9 : 00000fda r8 : 1ee9d07c [ 3559.402918] r7 : 00000002 r6 : 00000fda r5 : 00000026 r4 : c09f9880 [ 3559.409467] r3 : c064e03c r2 : 00000000 r1 : 00000000 r0 : dfffec00 [ 3559.416016] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 3559.423184] Control: 0005397f Table: 1eb40000 DAC: 00000015 [ 3559.428964] [<c000edac>] (unwind_backtrace+0x0/0x124) from [<c0074d40>] (watchdog_timer_fn+0xe8/0x13c) [ 3559.438314] [<c0074d40>] (watchdog_timer_fn+0xe8/0x13c) from [<c003aa18>] (__run_hrtimer+0xb0/0x1d4) [ 3559.447494] [<c003aa18>] (__run_hrtimer+0xb0/0x1d4) from [<c003b22c>] (hrtimer_interrupt+0x104/0x250) [ 3559.456757] [<c003b22c>] (hrtimer_interrupt+0x104/0x250) from [<c0016024>] (orion_timer_interrupt+0x24/0x34) [ 3559.466636] [<c0016024>] (orion_timer_interrupt+0x24/0x34) from [<c00754cc>] (handle_irq_event_percpu+0x38/0x23c) [ 3559.476949] [<c00754cc>] (handle_irq_event_percpu+0x38/0x23c) from [<c0075700>] (handle_irq_event+0x30/0x40) [ 3559.486821] [<c0075700>] (handle_irq_event+0x30/0x40) from [<c0077d30>] (handle_level_irq+0xcc/0xdc) [ 3559.495994] [<c0077d30>] (handle_level_irq+0xcc/0xdc) from [<c0074ef8>] (generic_handle_irq+0x28/0x38) [ 3559.505341] [<c0074ef8>] (generic_handle_irq+0x28/0x38) from [<c0009b64>] (handle_IRQ+0x68/0x8c) [ 3559.514171] [<c0009b64>] (handle_IRQ+0x68/0x8c) from [<c0444af4>] (__irq_svc+0x34/0x78) [ 3559.522219] [<c0444af4>] (__irq_svc+0x34/0x78) from [<c000fa3c>] (__dma_page_dev_to_cpu+0x60/0xcc) [ 3559.531225] [<c000fa3c>] (__dma_page_dev_to_cpu+0x60/0xcc) from [<c02362bc>] (dma_async_memcpy_pg_to_pg+0x198/0x1dc) [ 3559.541802] [<c02362bc>] (dma_async_memcpy_pg_to_pg+0x198/0x1dc) from [<c02377a8>] (dma_memcpy_pg_to_iovec+0xf0/0x180) [ 3559.552556] [<c02377a8>] (dma_memcpy_pg_to_iovec+0xf0/0x180) from [<c03835d0>] (dma_skb_copy_datagram_iovec+0x100/0x1d4) [ 3559.563486] [<c03835d0>] (dma_skb_copy_datagram_iovec+0x100/0x1d4) from [<c03a9c3c>] (tcp_recvmsg+0x630/0xac0) [ 3559.573536] [<c03a9c3c>] (tcp_recvmsg+0x630/0xac0) from [<c03c9138>] (inet_recvmsg+0x48/0x5c) [ 3559.582107] [<c03c9138>] (inet_recvmsg+0x48/0x5c) from [<c035bcfc>] (sock_aio_read+0x100/0x120) [ 3559.590852] [<c035bcfc>] (sock_aio_read+0x100/0x120) from [<c00e5524>] (do_sync_read+0x98/0xd4) [ 3559.599597] [<c00e5524>] (do_sync_read+0x98/0xd4) from [<c00e5e98>] (vfs_read+0xb4/0x184) [ 3559.607810] [<c00e5e98>] (vfs_read+0xb4/0x184) from [<c00e5fa4>] (sys_read+0x3c/0x70) [ 3559.615675] [<c00e5fa4>] (sys_read+0x3c/0x70) from [<c0008c60>] (ret_fast_syscall+0x0/0x2c)
And the above keeps repeating until I power off the plug.
Is this of interest on this list, or should I report it elsewhere?
Quentin Armitage
I was able to get the pogo pink to boot the F18-kirkwood-20121220.img.xz off a usb thumb drive. It uses 1.1 usb which is doggy slow, and it is NOT saving env vars which is a PITA.
But they are: setenv usb_boot 'if ext2load usb $usb_device 0x1100000 /uInitrd; then bootm 0x800000 0x1100000;else bootm 0x800000;fi;' setenv usb_load_uimage 'mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /uImage' setenv usb_root /dev/sda3 (this is the doozan uboot, but I am wondering if I shouldnt get something else. anyone tried anything else?)
I am also seeing this during the boot: Is this rewriting the nand??
[ 34.638654] NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit), page size: 2048, OOB size: 64 [ 34.723723] Scanning device for bad blocks [ 34.728417] Bad eraseblock 6 at 0x0000000c0000 [ 34.733218] Bad eraseblock 11 at 0x000000160000 [ 34.740889] Bad eraseblock 53 at 0x0000006a0000 [ 34.749666] Bad eraseblock 110 at 0x000000dc0000 [ 34.762924] Bad eraseblock 226 at 0x000001c40000 [ 34.774550] Bad eraseblock 320 at 0x000002800000 [ 34.786623] Bad eraseblock 420 at 0x000003480000 [ 34.794733] Bad eraseblock 467 at 0x000003a60000 [ 34.802999] Bad eraseblock 516 at 0x000004080000 [ 34.821846] Bad eraseblock 707 at 0x000005860000 [ 34.826595] Bad eraseblock 709 at 0x0000058a0000 [ 34.832545] Bad eraseblock 727 at 0x000005ae0000 [ 34.837667] Bad eraseblock 734 at 0x000005bc0000 [ 34.843248] Bad eraseblock 747 at 0x000005d60000 [ 35.091406] Creating 3 MTD partitions on "orion_nand": [ 35.132266] 0x000000000000-0x000000100000 : "u-boot" [ 35.203610] 0x000000100000-0x000000500000 : "uImage" [ 35.272698] 0x000000500000-0x000008000000 : "root"
Also, the 'reboot' command isn't working on the guruplug plus. I haven't tried it on the pogoplug ironically as I have to leave right now.
Not rewriting, but the OOB (Out Of Band) data for those blocks indicates they have failed. It's just informational.
This isn't rewriting the internal nand?
[ 35.091406] Creating 3 MTD partitions on "orion_nand": [ 35.132266] 0x000000000000-0x000000100000 : "u-boot" [ 35.203610] 0x000000100000-0x000000500000 : "uImage" [ 35.272698] 0x000000500000-0x000008000000 : "root"
I can't test atm. I bricked it trying to switch u-boot since "saveenv" was not writing to the nand and saving.
reboot did work on it, before I bricked it. :)
Now with the jtag I am getting:
unknown NAND flash device found, manufacturer id: 0x00 device id: 0x00 in procedure 'nand'
I was getting a list of nand drivers and orion was listed but not loading.. Not exactly sure what to do here..
________________________________ From: Jonathan Masters jcm@redhat.com To: Sean Omalley omalley_s@rocketmail.com Cc: "arm@lists.fedoraproject.org" arm@lists.fedoraproject.org Sent: Thursday, December 27, 2012 5:16 AM Subject: Re: [fedora-arm] Pogoplug pink E02
Not rewriting, but the OOB (Out Of Band) data for those blocks indicates they have failed. It's just informational.
-- Sent from my iPad
On Dec 24, 2012, at 15:59, Sean Omalley omalley_s@rocketmail.com wrote:
I was able to get the pogo pink to boot the F18-kirkwood-20121220.img.xz off a usb thumb drive.
It uses 1.1 usb which is doggy slow, and it is NOT saving env vars which is a PITA.
But they are: setenv usb_boot 'if ext2load usb $usb_device 0x1100000 /uInitrd; then bootm 0x800000 0x1100000;else bootm 0x800000;fi;' setenv usb_load_uimage 'mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /uImage' setenv usb_root /dev/sda3 (this is the doozan uboot, but I am wondering if I shouldnt get something else. anyone tried anything else?)
I am also seeing this during the boot: Is this rewriting the nand??
[ 34.638654] NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit), page size: 2048, OOB size: 64 [ 34.723723] Scanning device for bad blocks [ 34.728417] Bad eraseblock 6 at 0x0000000c0000 [ 34.733218] Bad eraseblock 11 at 0x000000160000 [ 34.740889] Bad eraseblock 53 at 0x0000006a0000 [ 34.749666] Bad eraseblock 110 at 0x000000dc0000 [ 34.762924] Bad eraseblock 226 at 0x000001c40000 [ 34.774550] Bad eraseblock 320 at 0x000002800000 [ 34.786623] Bad eraseblock 420 at 0x000003480000 [ 34.794733] Bad eraseblock 467 at 0x000003a60000 [ 34.802999] Bad eraseblock 516 at 0x000004080000 [ 34.821846] Bad eraseblock 707 at 0x000005860000 [ 34.826595] Bad eraseblock 709 at 0x0000058a0000 [ 34.832545] Bad eraseblock 727 at 0x000005ae0000 [
34.837667] Bad eraseblock 734 at 0x000005bc0000
[ 34.843248] Bad eraseblock 747 at 0x000005d60000 [ 35.091406] Creating 3 MTD partitions on "orion_nand": [ 35.132266] 0x000000000000-0x000000100000 : "u-boot" [ 35.203610] 0x000000100000-0x000000500000 : "uImage" [ 35.272698] 0x000000500000-0x000008000000 : "root"
Also, the 'reboot' command isn't working on the guruplug plus. I haven't tried it on the pogoplug ironically as I have to leave right now.
_______________________________________________
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Just fyi, I have a working version of uboot back on the E02, i just went ahead and reflashed it with Marvell version: 3.4.27 - pingtoo patch.01 and it comes up in console again... but still getting this error:
unknown NAND flash device found, manufacturer id: 0x00 device id: 0x00 in procedure 'nand'
Any possible suggestions would be welcome at this point.. :)
But it works better then it did last night. Nice to know the guruplug jtag also works with the new version of openocd, the ftd2xx drivers and all the garbage too.
________________________________ From: Sean Omalley omalley_s@rocketmail.com To: "arm@lists.fedoraproject.org" arm@lists.fedoraproject.org Sent: Thursday, December 27, 2012 2:56 PM Subject: Re: [fedora-arm] Pogoplug pink E02
This isn't rewriting the internal nand?
[ 35.091406] Creating 3 MTD partitions on "orion_nand": [ 35.132266] 0x000000000000-0x000000100000 : "u-boot" [ 35.203610] 0x000000100000-0x000000500000 : "uImage" [ 35.272698] 0x000000500000-0x000008000000 : "root"
I can't test atm. I bricked it trying to switch u-boot since "saveenv" was not writing to the nand and saving.
reboot did work on it, before I bricked it. :)
Now with the jtag I am getting:
unknown NAND flash device found, manufacturer id: 0x00 device id: 0x00 in procedure 'nand'
I was getting a list of nand drivers and orion was listed but not loading.. Not exactly sure what to do here..
________________________________ From: Jonathan Masters jcm@redhat.com To: Sean Omalley omalley_s@rocketmail.com Cc: "arm@lists.fedoraproject.org" arm@lists.fedoraproject.org Sent: Thursday, December 27, 2012 5:16 AM Subject: Re: [fedora-arm] Pogoplug pink E02
Not rewriting, but the OOB (Out Of Band) data for those blocks indicates they have failed. It's just informational.
-- Sent from my iPad
On Dec 24, 2012, at 15:59, Sean Omalley omalley_s@rocketmail.com wrote:
I was able to get the pogo pink to boot the F18-kirkwood-20121220.img.xz off a usb thumb drive.
It uses 1.1 usb which is doggy slow, and it is NOT saving env vars which is a PITA.
But they are: setenv usb_boot 'if ext2load usb $usb_device 0x1100000 /uInitrd; then bootm 0x800000 0x1100000;else bootm 0x800000;fi;' setenv
usb_load_uimage 'mw 0x800000 0 1; ext2load usb $usb_device 0x800000 /uImage'
setenv usb_root /dev/sda3 (this is the doozan uboot, but I am wondering if I shouldnt get something else. anyone tried anything else?)
I am also seeing this during the boot: Is this rewriting the nand??
[ 34.638654] NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit), page size: 2048, OOB size: 64 [ 34.723723] Scanning device for bad blocks [ 34.728417] Bad eraseblock 6 at 0x0000000c0000 [ 34.733218] Bad eraseblock 11 at 0x000000160000 [ 34.740889] Bad eraseblock 53 at 0x0000006a0000 [ 34.749666] Bad eraseblock 110 at 0x000000dc0000 [ 34.762924] Bad eraseblock 226 at 0x000001c40000 [ 34.774550] Bad eraseblock 320 at 0x000002800000 [ 34.786623] Bad eraseblock 420 at 0x000003480000 [ 34.794733] Bad eraseblock 467 at 0x000003a60000 [ 34.802999] Bad eraseblock 516 at 0x000004080000 [ 34.821846] Bad eraseblock 707 at 0x000005860000 [ 34.826595] Bad eraseblock 709 at 0x0000058a0000 [ 34.832545] Bad eraseblock 727 at 0x000005ae0000 [
34.837667] Bad eraseblock 734 at 0x000005bc0000
[ 34.843248] Bad eraseblock 747 at 0x000005d60000 [ 35.091406] Creating 3 MTD partitions on "orion_nand": [ 35.132266] 0x000000000000-0x000000100000 : "u-boot" [ 35.203610] 0x000000100000-0x000000500000 : "uImage" [ 35.272698] 0x000000500000-0x000008000000 : "root"
Also, the 'reboot' command isn't working on the guruplug plus. I haven't tried it on the pogoplug ironically as I have to leave right now.
_______________________________________________
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Hi Sean,
The output is the MTD subsystem telling you what logically was configured - MTD layout is arbitrary and not defined per standard partition tables. The other warning was OOB (Out Of Band) block related. NAND uses OOB metadata (literally extra bits per block) to flag known bad blocks and the like. It has been many years since I hacked on YAFFS but I don't think much has changed in this area. Happy New Year.
Jon.