dm9000 patch
Subsystems (2)
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Angelo,
Quoted 3 lines · Angelo Dureghello
sorry to contact you directly but i couldn't get any help from the kernel.org mailing list, since i am not a developer my mails are generally skipped.
The best way to get the contact info for a piece of kernel code, is using the get_maintainer.pl script. Running 'scripts/get_maintainer.pl -f drivers/net/dm9000.c' gives the following output:
[email protected]
[email protected]
I added both to Cc.
Quoted 3 lines
I am very near to have a custom board working with MCF5307 cpu and dm9000. I am using kernel 2.6.36-rc3 with your last patch about spinlock-recursion already included.
You should try to update to the latest .36 kernel, which is currently 2.6.36.2. The problem that you experience might be unrelated to the dm9000 driver (or to networking at all), so it might have been fixed in this version.
Quoted 3 lines
I have "ping" and "telnet" to the embedded board fully working. If i try to get a sample web page with some images from the board httpd with a browser, in 80% of cases i get a trap/oops:
Try to enable KALLSYMS in your kernel .config to make your stack trace more meaningful. This is under 'General setup -> Configure standard kernel features (for small systems) -> Load all symbols for debugging/ksymoops'.
I hope this helps.
baruch
Quoted 50 lines
[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29 [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 67.630000] Stack from 00d7b914: [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead 00dec1d4 0000001d 00000000 [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2 00c42c06 0015f6f9 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] Call Trace: [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a] [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6] [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e] [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44] [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218] [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06 [ 67.630000] Stack from 00d7b934: [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4 0000001d 00c42c06 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10 00146fb8 00d7ba20 00029e84 [ 67.630000] Call Trace: [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84] [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482] [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2] [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6] [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee] [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]As i said, i was hoping in your patch but i sadly discovered it is already included in this kernel version.
Hope you can give me some help or can forward me to an appropriate mailing list.
Signature · 3 lines
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il -Quoted 31 lines · Baruch Siach
Hi Angelo,
Quoted 4 lines · Angelo Dureghello
sorry to contact you directly but i couldn't get any help from the kernel.org mailing list, since i am not a developer my mails are generally skipped.
The best way to get the contact info for a piece of kernel code, is using the get_maintainer.pl script. Running '
scripts/get_maintainer.pl-fdrivers/net/dm9000.c' gives the following output:[email protected]
[email protected]I added both to Cc.
Quoted 4 lines
I am very near to have a custom board working with MCF5307 cpu and dm9000. I am using kernel 2.6.36-rc3 with your last patch about spinlock-recursion already included.
You should try to update to the latest .36 kernel, which is currently 2.6.36.2. The problem that you experience might be unrelated to the dm9000 driver (or to networking at all), so it might have been fixed in this version.
Quoted 4 lines
I have "ping" and "telnet" to the embedded board fully working. If i try to get a sample web page with some images from the board httpd with a browser, in 80% of cases i get a trap/oops:
Quoted 61 lines
Try to enable KALLSYMS in your kernel .config to make your stack trace more meaningful. This is under 'General setup -> Configure standard kernel features (for small systems) -> Load all symbols for debugging/ksymoops'.
I hope this helps.
baruch
Quoted 51 lines
[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29 [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 67.630000] Stack from 00d7b914: [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead 00dec1d4 0000001d 00000000 [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2 00c42c06 0015f6f9 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] Call Trace: [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a] [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6] [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e] [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44] [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218] [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06 [ 67.630000] Stack from 00d7b934: [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4 0000001d 00c42c06 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10 00146fb8 00d7ba20 00029e84 [ 67.630000] Call Trace: [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84] [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482] [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2] [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6] [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee] [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]As i said, i was hoping in your patch but i sadly discovered it is already included in this kernel version.
Hope you can give me some help or can forward me to an appropriate mailing list.
Hi Baruch and all,
many thanks for the help,
i am going to try 2.6.36.2 and KALLSYMS.
Anyway, my purpose now is to learn as much as possible the interrupt handling and the spinlock part, and as much as possible about linux drivers, since i am very interested to enter on this and be able to fix issues and contribute.
regards,
angelo
Hi all,
just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still there, below the call stack trace.
[ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29 [ 39.390000] lock: 00189c44, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 39.390000] Stack from 00d6a990: [ 39.390000] 00d6a9bc 000a9710 0017cac7 00189c44 dead4ead 00de48f4 0000001d 00000000 [ 39.390000] 00189c44 0002a646 00145f70 00d6a9f0 000a98e2 00189c44 0017cb2d 00189c44 [ 39.390000] 00d6aad8 0000001f 00145f5c 001523f6 00189c08 0002a646 00145f70 0002bc52 [ 39.390000] 00d6a9fc 00145f7e 00189c44 00d6aa28 0002a75e 00189c44 0000001f 00d6aad8 [ 39.390000] 0000001f 00145f5c 00189c08 0002a646 00145f70 0002bc52 00d6aa3c 00000bb6 [ 39.390000] 0000001f 00189c44 00cfc780 00d6aa84 0000337a 0000001f 00d6aa4c 00000001 [ 39.390000] Call Trace: [ 39.390000] [000a9710] spin_bug+0x86/0x11a [ 39.390000] [000a98e2] do_raw_spin_lock+0x58/0x120 [ 39.390000] [00145f7e] _raw_spin_lock+0xe/0x14 [ 39.390000] [0002a75e] __do_IRQ+0x2c/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [0002a82e] __do_IRQ+0xfc/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [000ef0ce] skb_release_all+0x10/0x20 [ 39.390000] [000ee6bc] __kfree_skb+0x10/0x92 [ 39.390000] [000ee75e] consume_skb+0x20/0x34 [ 39.390000] [000e004e] dm9000_start_xmit+0xdc/0xec [ 39.390000] [000f67a2] dev_hard_start_xmit+0x146/0x472 [ 39.390000] [00106506] sch_direct_xmit+0xc0/0x1bc [ 39.390000] [000f9914] dev_queue_xmit+0x160/0x3e4 [ 39.390000] [00113b3e] ip_finish_output+0xee/0x318 [ 39.390000] [001142b4] ip_output+0x7c/0x88 [ 39.390000] [00113dc6] ip_local_out+0x26/0x30 [ 39.390000] [00114d9a] ip_queue_xmit+0x152/0x374 [ 39.390000] [00125c8c] tcp_transmit_skb+0x3f0/0x732 [ 39.390000] [00126f26] tcp_write_xmit+0x178/0x868 [ 39.390000] [00127644] __tcp_push_pending_frames+0x2e/0x9a [ 39.390000] [0011c3d6] tcp_sendmsg+0x82e/0x98c [ 39.390000] [00137544] inet_sendmsg+0x32/0x54 [ 39.390000] [000e79a6] sock_aio_write+0xc8/0x138 [ 39.390000] [00042590] do_sync_write+0x9e/0xfe [ 39.390000] [00042668] vfs_write+0x78/0x84 [ 39.390000] [00042a92] sys_write+0x40/0x7a [ 39.390000] [00003224] system_call+0x84/0xc2 [ 39.390000]
dm9000e is as default not visible/selectable in menuconfig for Coldfire architectures, so this probably cannot be considered as a kernel bug.
I going forward in investigations, every help is appreciated,
regards,
angelo
Quoted 92 lines · Baruch Siach
Hi Angelo,
Quoted 4 lines · Angelo Dureghello
sorry to contact you directly but i couldn't get any help from the kernel.org mailing list, since i am not a developer my mails are generally skipped.
The best way to get the contact info for a piece of kernel code, is using the get_maintainer.pl script. Running '
scripts/get_maintainer.pl-fdrivers/net/dm9000.c' gives the following output:[email protected]
[email protected]I added both to Cc.
Quoted 4 lines
I am very near to have a custom board working with MCF5307 cpu and dm9000. I am using kernel 2.6.36-rc3 with your last patch about spinlock-recursion already included.
You should try to update to the latest .36 kernel, which is currently 2.6.36.2. The problem that you experience might be unrelated to the dm9000 driver (or to networking at all), so it might have been fixed in this version.
Quoted 4 lines
I have "ping" and "telnet" to the embedded board fully working. If i try to get a sample web page with some images from the board httpd with a browser, in 80% of cases i get a trap/oops:
Try to enable KALLSYMS in your kernel .config to make your stack trace more meaningful. This is under 'General setup -> Configure standard kernel features (for small systems) -> Load all symbols for debugging/ksymoops'.
I hope this helps.
baruch
Quoted 51 lines
[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29 [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 67.630000] Stack from 00d7b914: [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead 00dec1d4 0000001d 00000000 [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2 00c42c06 0015f6f9 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] Call Trace: [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a] [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6] [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e] [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44] [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218] [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06 [ 67.630000] Stack from 00d7b934: [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4 0000001d 00c42c06 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10 00146fb8 00d7ba20 00029e84 [ 67.630000] Call Trace: [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84] [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482] [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2] [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6] [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee] [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]As i said, i was hoping in your patch but i sadly discovered it is already included in this kernel version.
Hope you can give me some help or can forward me to an appropriate mailing list.
Hi Angelo,
Quoted 2 lines · Angelo Dureghello
just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still there, below the call stack trace.
Help from the m68k experts seems to be needed. Adding the relevant list to Cc.
baruch
Quoted 146 lines
[ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29 [ 39.390000] lock: 00189c44, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 39.390000] Stack from 00d6a990: [ 39.390000] 00d6a9bc 000a9710 0017cac7 00189c44 dead4ead 00de48f4 0000001d 00000000 [ 39.390000] 00189c44 0002a646 00145f70 00d6a9f0 000a98e2 00189c44 0017cb2d 00189c44 [ 39.390000] 00d6aad8 0000001f 00145f5c 001523f6 00189c08 0002a646 00145f70 0002bc52 [ 39.390000] 00d6a9fc 00145f7e 00189c44 00d6aa28 0002a75e 00189c44 0000001f 00d6aad8 [ 39.390000] 0000001f 00145f5c 00189c08 0002a646 00145f70 0002bc52 00d6aa3c 00000bb6 [ 39.390000] 0000001f 00189c44 00cfc780 00d6aa84 0000337a 0000001f 00d6aa4c 00000001 [ 39.390000] Call Trace: [ 39.390000] [000a9710] spin_bug+0x86/0x11a [ 39.390000] [000a98e2] do_raw_spin_lock+0x58/0x120 [ 39.390000] [00145f7e] _raw_spin_lock+0xe/0x14 [ 39.390000] [0002a75e] __do_IRQ+0x2c/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [0002a82e] __do_IRQ+0xfc/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [000ef0ce] skb_release_all+0x10/0x20 [ 39.390000] [000ee6bc] __kfree_skb+0x10/0x92 [ 39.390000] [000ee75e] consume_skb+0x20/0x34 [ 39.390000] [000e004e] dm9000_start_xmit+0xdc/0xec [ 39.390000] [000f67a2] dev_hard_start_xmit+0x146/0x472 [ 39.390000] [00106506] sch_direct_xmit+0xc0/0x1bc [ 39.390000] [000f9914] dev_queue_xmit+0x160/0x3e4 [ 39.390000] [00113b3e] ip_finish_output+0xee/0x318 [ 39.390000] [001142b4] ip_output+0x7c/0x88 [ 39.390000] [00113dc6] ip_local_out+0x26/0x30 [ 39.390000] [00114d9a] ip_queue_xmit+0x152/0x374 [ 39.390000] [00125c8c] tcp_transmit_skb+0x3f0/0x732 [ 39.390000] [00126f26] tcp_write_xmit+0x178/0x868 [ 39.390000] [00127644] __tcp_push_pending_frames+0x2e/0x9a [ 39.390000] [0011c3d6] tcp_sendmsg+0x82e/0x98c [ 39.390000] [00137544] inet_sendmsg+0x32/0x54 [ 39.390000] [000e79a6] sock_aio_write+0xc8/0x138 [ 39.390000] [00042590] do_sync_write+0x9e/0xfe [ 39.390000] [00042668] vfs_write+0x78/0x84 [ 39.390000] [00042a92] sys_write+0x40/0x7a [ 39.390000] [00003224] system_call+0x84/0xc2 [ 39.390000]dm9000e is as default not visible/selectable in menuconfig for Coldfire architectures, so this probably cannot be considered as a kernel bug.
I going forward in investigations, every help is appreciated,
regards,
angeloQuoted 83 lines · Baruch Siach
Hi Angelo,
Quoted 3 lines · Angelo Dureghello
sorry to contact you directly but i couldn't get any help from the kernel.org mailing list, since i am not a developer my mails are generally skipped.
The best way to get the contact info for a piece of kernel code, is using the get_maintainer.pl script. Running '
scripts/get_maintainer.pl-fdrivers/net/dm9000.c' gives the following output:[email protected]
[email protected]I added both to Cc.
Quoted 3 lines
I am very near to have a custom board working with MCF5307 cpu and dm9000. I am using kernel 2.6.36-rc3 with your last patch about spinlock-recursion already included.
You should try to update to the latest .36 kernel, which is currently 2.6.36.2. The problem that you experience might be unrelated to the dm9000 driver (or to networking at all), so it might have been fixed in this version.
Quoted 3 lines
I have "ping" and "telnet" to the embedded board fully working. If i try to get a sample web page with some images from the board httpd with a browser, in 80% of cases i get a trap/oops:
Try to enable KALLSYMS in your kernel .config to make your stack trace more meaningful. This is under 'General setup -> Configure standard kernel features (for small systems) -> Load all symbols for debugging/ksymoops'.
I hope this helps.
baruch
Quoted 50 lines
[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29 [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 67.630000] Stack from 00d7b914: [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead 00dec1d4 0000001d 00000000 [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2 00c42c06 0015f6f9 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] Call Trace: [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a] [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6] [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e] [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44] [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218] [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06 [ 67.630000] Stack from 00d7b934: [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4 0000001d 00c42c06 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10 00146fb8 00d7ba20 00029e84 [ 67.630000] Call Trace: [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84] [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482] [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2] [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6] [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee] [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]As i said, i was hoping in your patch but i sadly discovered it is already included in this kernel version.
Hope you can give me some help or can forward me to an appropriate mailing list.
Signature · 3 lines
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il -Quoted 7 lines · Baruch Siach
Hi Angelo,
Quoted 2 lines · Angelo Dureghello
just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still there, below the call stack trace.
Help from the m68k experts seems to be needed. Adding the relevant list to Cc.
This is uClinux? Added Cc...
Quoted 157 lines
Quoted 54 lines
[ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa
0x45E1[ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29 [ 39.390000] lock:00189c44, .magic:dead4ead, .owner: httpd/29, .owner_cpu: 0
[ 39.390000] Stack from00d6a990:
[ 39.390000]00d6a9bc000a97100017cac700189c44dead4ead00de48f40000001d00000000
[ 39.390000]00189c440002a64600145f7000d6a9f0000a98e200189c440017cb2d00189c44
[ 39.390000]00d6aad80000001f00145f5c001523f600189c080002a64600145f700002bc52
[ 39.390000]00d6a9fc00145f7e00189c4400d6aa280002a75e00189c440000001f00d6aad8
[ 39.390000]0000001f00145f5c00189c080002a64600145f700002bc5200d6aa3c00000bb6
[ 39.390000]0000001f00189c4400cfc78000d6aa840000337a0000001f00d6aa4c00000001
[ 39.390000] Call Trace:
[ 39.390000] [000a9710]spin_bug+0x86/0x11a
[ 39.390000] [000a98e2]do_raw_spin_lock+0x58/0x120
[ 39.390000] [00145f7e]_raw_spin_lock+0xe/0x14
[ 39.390000] [0002a75e]__do_IRQ+0x2c/0x108
[ 39.390000] [00000bb6]do_IRQ+0x48/0x62
[ 39.390000] [0000337a]inthandler+0x6a/0x74
[ 39.390000] [0002a82e]__do_IRQ+0xfc/0x108
[ 39.390000] [00000bb6]do_IRQ+0x48/0x62
[ 39.390000] [0000337a]inthandler+0x6a/0x74
[ 39.390000] [000ef0ce]skb_release_all+0x10/0x20
[ 39.390000] [000ee6bc]__kfree_skb+0x10/0x92
[ 39.390000] [000ee75e]consume_skb+0x20/0x34
[ 39.390000] [000e004e]dm9000_start_xmit+0xdc/0xec
[ 39.390000] [000f67a2]dev_hard_start_xmit+0x146/0x472[ 39.390000] [00106506]sch_direct_xmit+0xc0/0x1bc
[ 39.390000] [000f9914]dev_queue_xmit+0x160/0x3e4
[ 39.390000] [00113b3e]ip_finish_output+0xee/0x318
[ 39.390000] [001142b4]ip_output+0x7c/0x88
[ 39.390000] [00113dc6]ip_local_out+0x26/0x30
[ 39.390000] [00114d9a]ip_queue_xmit+0x152/0x374
[ 39.390000] [00125c8c]tcp_transmit_skb+0x3f0/0x732[ 39.390000] [00126f26]tcp_write_xmit+0x178/0x868
[ 39.390000] [00127644]__tcp_push_pending_frames+0x2e/0x9a[ 39.390000] [0011c3d6]tcp_sendmsg+0x82e/0x98c
[ 39.390000] [00137544]inet_sendmsg+0x32/0x54
[ 39.390000] [000e79a6]sock_aio_write+0xc8/0x138
[ 39.390000] [00042590]do_sync_write+0x9e/0xfe
[ 39.390000] [00042668]vfs_write+0x78/0x84
[ 39.390000] [00042a92]sys_write+0x40/0x7a
[ 39.390000] [00003224]system_call+0x84/0xc2
[ 39.390000]dm9000e is as default not visible/selectable in menuconfig for Coldfire architectures, so this probably cannot be considered as a kernel bug.
Quoted 92 lines
I going forward in investigations, every help is appreciated,
regards,
angeloQuoted 83 lines · Baruch Siach
Hi Angelo,
Quoted 3 lines · Angelo Dureghello
sorry to contact you directly but i couldn't get any help from the kernel.org mailing list, since i am not a developer my mails are generally skipped.
The best way to get the contact info for a piece of kernel code, is using the get_maintainer.pl script. Running '
scripts/get_maintainer.pl-fdrivers/net/dm9000.c' gives the following output:[email protected]
[email protected]I added both to Cc.
Quoted 3 lines
I am very near to have a custom board working with MCF5307 cpu and dm9000. I am using kernel 2.6.36-rc3 with your last patch about spinlock-recursion already included.
You should try to update to the latest .36 kernel, which is currently 2.6.36.2. The problem that you experience might be unrelated to the dm9000 driver (or to networking at all), so it might have been fixed in this version.
Quoted 3 lines
I have "ping" and "telnet" to the embedded board fully working. If i try to get a sample web page with some images from the board httpd with a browser, in 80% of cases i get a trap/oops:
Try to enable KALLSYMS in your kernel .config to make your stack trace more meaningful. This is under 'General setup -> Configure standard kernel features (for small systems) -> Load all symbols for debugging/ksymoops'.
I hope this helps.
baruch
Quoted 50 lines
[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa
0x45E1[ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29
[ 67.630000] lock:00c42c06, .magic:dead4ead, .owner: httpd/29, .owner_cpu: 0
[ 67.630000] Stack from00d7b914:
[ 67.630000]00d7b940000a8cf00015f69300c42c06dead4ead00dec1d40000001d00000000
[ 67.630000]00c42c060000618800c4280000d7b974000a8ec200c42c060015f6f900002704
[ 67.630000] 000000000000001f00146fa400152f0c00c42b600000618800c428000002b312
[ 67.630000]00d7b9840014701e00c42c060000000000d7b9c4000df21c00c42c0600000000
[ 67.630000] 000000000000001f00146fa400152f0c000005ea00cfc64000006188000096e8
[ 67.630000]0002b31200146fa400c42b600000270400d7b9ec00029d3a0000001f00c42800
[ 67.630000] Call Trace:
[ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a] [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6] [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e] [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44] [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218] [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29,00c42c06[ 67.630000] Stack from00d7b934:
[ 67.630000]00d7b974000a8f660015f7030000000000dec1d40000001d00c42c0600002704
[ 67.630000] 000000000000001f00146fa400152f0c00c42b600000618800c428000002b312
[ 67.630000]00d7b9840014701e00c42c060000000000d7b9c4000df21c00c42c0600000000
[ 67.630000] 000000000000001f00146fa400152f0c000005ea00cfc64000006188000096e8
[ 67.630000]0002b31200146fa400c42b600000270400d7b9ec00029d3a0000001f00c42800
[ 67.630000]0016c1b400cfc6400000001f0016c17800029d1000146fb800d7ba2000029e84
[ 67.630000] Call Trace:
[ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84] [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482] [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2] [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6] [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee] [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]As i said, i was hoping in your patch but i sadly discovered it is already included in this kernel version.
Hope you can give me some help or can forward me to an appropriate mailing list.--
~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{=
- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il - --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 10 lines
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus TorvaldsHi all,
thanks for the help,
the kernel is a main line kernel. Then yes, i am still using uclinux tree for libc/tools.
I collected another spinlock recursion with a slightly different call stack trace, as always, the spinlock recursion issue happen on a high tx/rx traffic of the dm9000e, in this case just asking an index.html with some images and texts:
[ 1108.930000] BUG: spinlock recursion on CPU#0, httpd/29 [ 1108.930000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 1108.930000] Stack from 00d7a688: [ 1108.930000] 00d7a6b4 000ad988 001840ca 00c42c06 dead4ead 00d641d4 0000001d 00000000 [ 1108.930000] 00c42c06 000064f0 00c42800 00d7a6e8 000adb5a 00c42c06 00184130 00002704 [ 1108.930000] 00000000 0000001f 0014d17e 00159912 00c42b60 000064f0 00c42800 0002cb16 [ 1108.930000] 00d7a6f8 0014d24e 00c42c06 00000000 00d7a738 000e485c 00c42c06 00000000 [ 1108.930000] 00000000 0000001f 0014d17e 00159912 0000004a 00cfc600 000064f0 00009a74 [ 1108.930000] 0002cb16 00191204 00d7a760 0002b6f2 00d7a760 0002b514 0000001f 00c42800 [ 1108.930000] Call Trace: [ 1108.930000] [000ad988] spin_bug+0x86/0x11a [ 1108.930000] [000adb5a] do_raw_spin_lock+0x58/0x120 [ 1108.930000] [0014d24e] _raw_spin_lock_irqsave+0x28/0x32 [ 1108.930000] [000e485c] dm9000_interrupt+0x1a/0x2e0 [ 1108.930000] [0002b514] handle_IRQ_event+0x2a/0xec [ 1108.930000] [0002b680] __do_IRQ+0xaa/0x128 [ 1108.930000] [00000bb6] do_IRQ+0x48/0x62 [ 1108.930000] [000033c6] inthandler+0x6a/0x74 [ 1108.930000] [000fb626] dev_hard_start_xmit+0x170/0x4c4 [ 1108.930000] [0010b80e] sch_direct_xmit+0xc0/0x1bc [ 1108.930000] [000fe9de] dev_queue_xmit+0x160/0x3e6 [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320 [ 1108.930000] [0011a768] ip_output+0x9e/0xa8 [ 1108.930000] [00119856] ip_local_out+0x26/0x30 [ 1108.930000] [0011a56e] ip_build_and_send_pkt+0x16e/0x178 [ 1108.930000] [0012fc96] tcp_v4_send_synack+0x52/0x90 [ 1108.930000] [00130f86] tcp_v4_conn_request+0x3fa/0x57c [ 1108.930000] [0012a1c6] tcp_rcv_state_process+0x25e/0xa66 [ 1108.930000] [001309a4] tcp_v4_do_rcv+0x7c/0x1c8 [ 1108.930000] [00132854] tcp_v4_rcv+0x546/0x6d2 [ 1108.930000] [001153a8] ip_local_deliver+0x9c/0x1b0 [ 1108.930000] [001158e8] ip_rcv+0x42c/0x5f0 [ 1108.930000] [000fa74e] __netif_receive_skb+0x196/0x2ec [ 1108.930000] [000fe142] process_backlog+0x72/0x11e [ 1108.930000] [000fe290] net_rx_action+0xa2/0x150 [ 1108.930000] [0000e13c] __do_softirq+0x74/0xe4 [ 1108.930000] [0000e1e2] do_softirq+0x36/0x40 [ 1108.930000] [0000e6c6] local_bh_enable+0x7a/0xa4 [ 1108.930000] [000fe972] dev_queue_xmit+0xf4/0x3e6 [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320 [ 1108.930000] [0011a768] ip_output+0x9e/0xa8 [ 1108.930000] [00119856] ip_local_out+0x26/0x30 [ 1108.930000] [0011a90a] ip_queue_xmit+0x198/0x426 [ 1108.930000] [0012bcc8] tcp_transmit_skb+0x3f0/0x76c [ 1108.930000] [0012cfda] tcp_write_xmit+0x178/0x868 [ 1108.930000] [0012d6f8] __tcp_push_pending_frames+0x2e/0x9a [ 1108.930000] [001222be] tcp_sendmsg+0x82e/0x98c [ 1108.930000] [0013d9c0] inet_sendmsg+0x32/0x54 [ 1108.930000] [000ec25e] sock_aio_write+0xc8/0x138 [ 1108.930000] [00043e7e] do_sync_write+0x9e/0xfe [ 1108.930000] [00043f56] vfs_write+0x78/0x84 [ 1108.930000] [0004446c] sys_write+0x40/0x7a [ 1108.930000] [00003244] system_call+0x84/0xc2 [ 1108.930000]
seems like while i transmit a packet, dm9000_interrupt try to acquire the spinlock owned from the same task.
Compiling the kernel i am getting:
CC kernel/irq/handle.okernel/irq/handle.c:432:3: warning: #warning __do_IRQ is deprecated. Please convert to proper flow handlers
Could the usage of __do_IRQ super-handler be a cause of the issue ?
many thanks,
angelo
Quoted 183 lines · Geert Uytterhoeven
Quoted 9 lines · Baruch Siach
Hi Angelo,
Quoted 3 lines · Angelo Dureghello
just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still there, below the call stack trace.
Help from the m68k experts seems to be needed. Adding the relevant list to Cc.
This is uClinux? Added Cc...
Quoted 166 lines
Quoted 54 lines
[ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29 [ 39.390000] lock: 00189c44, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 39.390000] Stack from 00d6a990: [ 39.390000] 00d6a9bc 000a9710 0017cac7 00189c44 dead4ead 00de48f4 0000001d 00000000 [ 39.390000] 00189c44 0002a646 00145f70 00d6a9f0 000a98e2 00189c44 0017cb2d 00189c44 [ 39.390000] 00d6aad8 0000001f 00145f5c 001523f6 00189c08 0002a646 00145f70 0002bc52 [ 39.390000] 00d6a9fc 00145f7e 00189c44 00d6aa28 0002a75e 00189c44 0000001f 00d6aad8 [ 39.390000] 0000001f 00145f5c 00189c08 0002a646 00145f70 0002bc52 00d6aa3c 00000bb6 [ 39.390000] 0000001f 00189c44 00cfc780 00d6aa84 0000337a 0000001f 00d6aa4c 00000001 [ 39.390000] Call Trace: [ 39.390000] [000a9710] spin_bug+0x86/0x11a [ 39.390000] [000a98e2] do_raw_spin_lock+0x58/0x120 [ 39.390000] [00145f7e] _raw_spin_lock+0xe/0x14 [ 39.390000] [0002a75e] __do_IRQ+0x2c/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [0002a82e] __do_IRQ+0xfc/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [000ef0ce] skb_release_all+0x10/0x20 [ 39.390000] [000ee6bc] __kfree_skb+0x10/0x92 [ 39.390000] [000ee75e] consume_skb+0x20/0x34 [ 39.390000] [000e004e] dm9000_start_xmit+0xdc/0xec [ 39.390000] [000f67a2] dev_hard_start_xmit+0x146/0x472 [ 39.390000] [00106506] sch_direct_xmit+0xc0/0x1bc [ 39.390000] [000f9914] dev_queue_xmit+0x160/0x3e4 [ 39.390000] [00113b3e] ip_finish_output+0xee/0x318 [ 39.390000] [001142b4] ip_output+0x7c/0x88 [ 39.390000] [00113dc6] ip_local_out+0x26/0x30 [ 39.390000] [00114d9a] ip_queue_xmit+0x152/0x374 [ 39.390000] [00125c8c] tcp_transmit_skb+0x3f0/0x732 [ 39.390000] [00126f26] tcp_write_xmit+0x178/0x868 [ 39.390000] [00127644] __tcp_push_pending_frames+0x2e/0x9a [ 39.390000] [0011c3d6] tcp_sendmsg+0x82e/0x98c [ 39.390000] [00137544] inet_sendmsg+0x32/0x54 [ 39.390000] [000e79a6] sock_aio_write+0xc8/0x138 [ 39.390000] [00042590] do_sync_write+0x9e/0xfe [ 39.390000] [00042668] vfs_write+0x78/0x84 [ 39.390000] [00042a92] sys_write+0x40/0x7a [ 39.390000] [00003224] system_call+0x84/0xc2 [ 39.390000]dm9000e is as default not visible/selectable in menuconfig for Coldfire architectures, so this probably cannot be considered as a kernel bug.
Quoted 101 lines
I going forward in investigations, every help is appreciated,
regards,
angeloQuoted 91 lines · Baruch Siach
Hi Angelo,
Quoted 4 lines · Angelo Dureghello
sorry to contact you directly but i couldn't get any help from the kernel.org mailing list, since i am not a developer my mails are generally skipped.
The best way to get the contact info for a piece of kernel code, is using the get_maintainer.pl script. Running '
scripts/get_maintainer.pl-fdrivers/net/dm9000.c' gives the following output:[email protected]
[email protected]I added both to Cc.
Quoted 4 lines
I am very near to have a custom board working with MCF5307 cpu and dm9000. I am using kernel 2.6.36-rc3 with your last patch about spinlock-recursion already included.
You should try to update to the latest .36 kernel, which is currently 2.6.36.2. The problem that you experience might be unrelated to the dm9000 driver (or to networking at all), so it might have been fixed in this version.
Quoted 4 lines
I have "ping" and "telnet" to the embedded board fully working. If i try to get a sample web page with some images from the board httpd with a browser, in 80% of cases i get a trap/oops:
Try to enable KALLSYMS in your kernel .config to make your stack trace more
meaningful. This is under 'General setup -> Configure standard kernel features
(for small systems) -> Load all symbols for debugging/ksymoops'.I hope this helps.
baruch
Quoted 51 lines
[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29 [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 67.630000] Stack from 00d7b914: [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead 00dec1d4 0000001d 00000000 [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2 00c42c06 0015f6f9 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] Call Trace: [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a] [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6] [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e] [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44] [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218] [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06 [ 67.630000] Stack from 00d7b934: [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4 0000001d 00c42c06 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10 00146fb8 00d7ba20 00029e84 [ 67.630000] Call Trace: [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84] [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482] [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2] [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6] [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee] [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]As i said, i was hoping in your patch but i sadly discovered it is already included in this kernel version.
Hope you can give me some help or can forward me to an appropriate mailing list.--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Quoted 2 lines · Angelo Dureghello
the kernel is a main line kernel. Then yes, i am still using uclinux tree for libc/tools.
Does it still occur if you remove the debug line below?
--- drivers/net/dm9000.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-)
drivers/net/dm9000.c +0 -2
@@ -1077,8 +1077,6 @@ static irqreturn_t dm9000_interrupt(int irq, void *dev_id)unsigned long flags;u8 reg_save; -dm9000_dbg (db,3 ,"entering %s\n" , __func__); -/* A real interrupt coming */ /* holders of db->lock must always block IRQs */
Hi Angelo,
Quoted 4 lines · Angelo Dureghello
Hi all,
thanks for the help,
the kernel is a main line kernel. Then yes, i am still using uclinux tree for libc/tools.
How is the DM9000 hardware connected to the 5307?
I am wondering how you connected the interrupt (and to which interrupt) and the addressing (direct of a chip select)?
(For example NETtel based 5307 platform support of the SMC91x code is in mainline as arch/m68knommu/platform/5307/nettel.c). Can you show the code you used to setup your dm9000 hardware? (Specifically I guess I want to know if you use the "auto-vectored" interrupt mode?)
Thanks
Greg
Quoted 266 lines
I collected another spinlock recursion with a slightly different call stack trace, as always, the spinlock recursion issue happen on a high tx/rx traffic of the dm9000e, in this case just asking an index.html with some images and texts:
[ 1108.930000] BUG: spinlock recursion on CPU#0, httpd/29 [ 1108.930000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 1108.930000] Stack from 00d7a688: [ 1108.930000] 00d7a6b4 000ad988 001840ca 00c42c06 dead4ead 00d641d4 0000001d 00000000 [ 1108.930000] 00c42c06 000064f0 00c42800 00d7a6e8 000adb5a 00c42c06 00184130 00002704 [ 1108.930000] 00000000 0000001f 0014d17e 00159912 00c42b60 000064f0 00c42800 0002cb16 [ 1108.930000] 00d7a6f8 0014d24e 00c42c06 00000000 00d7a738 000e485c 00c42c06 00000000 [ 1108.930000] 00000000 0000001f 0014d17e 00159912 0000004a 00cfc600 000064f0 00009a74 [ 1108.930000] 0002cb16 00191204 00d7a760 0002b6f2 00d7a760 0002b514 0000001f 00c42800 [ 1108.930000] Call Trace: [ 1108.930000] [000ad988] spin_bug+0x86/0x11a [ 1108.930000] [000adb5a] do_raw_spin_lock+0x58/0x120 [ 1108.930000] [0014d24e] _raw_spin_lock_irqsave+0x28/0x32 [ 1108.930000] [000e485c] dm9000_interrupt+0x1a/0x2e0 [ 1108.930000] [0002b514] handle_IRQ_event+0x2a/0xec [ 1108.930000] [0002b680] __do_IRQ+0xaa/0x128 [ 1108.930000] [00000bb6] do_IRQ+0x48/0x62 [ 1108.930000] [000033c6] inthandler+0x6a/0x74 [ 1108.930000] [000fb626] dev_hard_start_xmit+0x170/0x4c4 [ 1108.930000] [0010b80e] sch_direct_xmit+0xc0/0x1bc [ 1108.930000] [000fe9de] dev_queue_xmit+0x160/0x3e6 [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320 [ 1108.930000] [0011a768] ip_output+0x9e/0xa8 [ 1108.930000] [00119856] ip_local_out+0x26/0x30 [ 1108.930000] [0011a56e] ip_build_and_send_pkt+0x16e/0x178 [ 1108.930000] [0012fc96] tcp_v4_send_synack+0x52/0x90 [ 1108.930000] [00130f86] tcp_v4_conn_request+0x3fa/0x57c [ 1108.930000] [0012a1c6] tcp_rcv_state_process+0x25e/0xa66 [ 1108.930000] [001309a4] tcp_v4_do_rcv+0x7c/0x1c8 [ 1108.930000] [00132854] tcp_v4_rcv+0x546/0x6d2 [ 1108.930000] [001153a8] ip_local_deliver+0x9c/0x1b0 [ 1108.930000] [001158e8] ip_rcv+0x42c/0x5f0 [ 1108.930000] [000fa74e] __netif_receive_skb+0x196/0x2ec [ 1108.930000] [000fe142] process_backlog+0x72/0x11e [ 1108.930000] [000fe290] net_rx_action+0xa2/0x150 [ 1108.930000] [0000e13c] __do_softirq+0x74/0xe4 [ 1108.930000] [0000e1e2] do_softirq+0x36/0x40 [ 1108.930000] [0000e6c6] local_bh_enable+0x7a/0xa4 [ 1108.930000] [000fe972] dev_queue_xmit+0xf4/0x3e6 [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320 [ 1108.930000] [0011a768] ip_output+0x9e/0xa8 [ 1108.930000] [00119856] ip_local_out+0x26/0x30 [ 1108.930000] [0011a90a] ip_queue_xmit+0x198/0x426 [ 1108.930000] [0012bcc8] tcp_transmit_skb+0x3f0/0x76c [ 1108.930000] [0012cfda] tcp_write_xmit+0x178/0x868 [ 1108.930000] [0012d6f8] __tcp_push_pending_frames+0x2e/0x9a [ 1108.930000] [001222be] tcp_sendmsg+0x82e/0x98c [ 1108.930000] [0013d9c0] inet_sendmsg+0x32/0x54 [ 1108.930000] [000ec25e] sock_aio_write+0xc8/0x138 [ 1108.930000] [00043e7e] do_sync_write+0x9e/0xfe [ 1108.930000] [00043f56] vfs_write+0x78/0x84 [ 1108.930000] [0004446c] sys_write+0x40/0x7a [ 1108.930000] [00003244] system_call+0x84/0xc2 [ 1108.930000]seems like while i transmit a packet,
dm9000_interrupttry to acquire the spinlock owned from the same task.Compiling the kernel i am getting:
CCkernel/irq/handle.okernel/irq/handle.c:432:3: warning: #warning__do_IRQis deprecated. Please convert to proper flow handlersCould the usage of
__do_IRQsuper-handler be a cause of the issue ?many thanks,
angeloQuoted 175 lines · Geert Uytterhoeven
Quoted 7 lines · Baruch Siach
Hi Angelo,
Quoted 2 lines · Angelo Dureghello
just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still there, below the call stack trace.
Help from the m68k experts seems to be needed. Adding the relevant list to Cc.
This is uClinux? Added Cc...
Quoted 163 lines
Quoted 54 lines
[ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29 [ 39.390000] lock: 00189c44, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 39.390000] Stack from 00d6a990: [ 39.390000] 00d6a9bc 000a9710 0017cac7 00189c44 dead4ead 00de48f4 0000001d 00000000 [ 39.390000] 00189c44 0002a646 00145f70 00d6a9f0 000a98e2 00189c44 0017cb2d 00189c44 [ 39.390000] 00d6aad8 0000001f 00145f5c 001523f6 00189c08 0002a646 00145f70 0002bc52 [ 39.390000] 00d6a9fc 00145f7e 00189c44 00d6aa28 0002a75e 00189c44 0000001f 00d6aad8 [ 39.390000] 0000001f 00145f5c 00189c08 0002a646 00145f70 0002bc52 00d6aa3c 00000bb6 [ 39.390000] 0000001f 00189c44 00cfc780 00d6aa84 0000337a 0000001f 00d6aa4c 00000001 [ 39.390000] Call Trace: [ 39.390000] [000a9710] spin_bug+0x86/0x11a [ 39.390000] [000a98e2] do_raw_spin_lock+0x58/0x120 [ 39.390000] [00145f7e] _raw_spin_lock+0xe/0x14 [ 39.390000] [0002a75e] __do_IRQ+0x2c/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [0002a82e] __do_IRQ+0xfc/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [000ef0ce] skb_release_all+0x10/0x20 [ 39.390000] [000ee6bc] __kfree_skb+0x10/0x92 [ 39.390000] [000ee75e] consume_skb+0x20/0x34 [ 39.390000] [000e004e] dm9000_start_xmit+0xdc/0xec [ 39.390000] [000f67a2] dev_hard_start_xmit+0x146/0x472 [ 39.390000] [00106506] sch_direct_xmit+0xc0/0x1bc [ 39.390000] [000f9914] dev_queue_xmit+0x160/0x3e4 [ 39.390000] [00113b3e] ip_finish_output+0xee/0x318 [ 39.390000] [001142b4] ip_output+0x7c/0x88 [ 39.390000] [00113dc6] ip_local_out+0x26/0x30 [ 39.390000] [00114d9a] ip_queue_xmit+0x152/0x374 [ 39.390000] [00125c8c] tcp_transmit_skb+0x3f0/0x732 [ 39.390000] [00126f26] tcp_write_xmit+0x178/0x868 [ 39.390000] [00127644] __tcp_push_pending_frames+0x2e/0x9a [ 39.390000] [0011c3d6] tcp_sendmsg+0x82e/0x98c [ 39.390000] [00137544] inet_sendmsg+0x32/0x54 [ 39.390000] [000e79a6] sock_aio_write+0xc8/0x138 [ 39.390000] [00042590] do_sync_write+0x9e/0xfe [ 39.390000] [00042668] vfs_write+0x78/0x84 [ 39.390000] [00042a92] sys_write+0x40/0x7a [ 39.390000] [00003224] system_call+0x84/0xc2 [ 39.390000]dm9000e is as default not visible/selectable in menuconfig for Coldfire architectures, so this probably cannot be considered as a kernel bug.
Quoted 97 lines
I going forward in investigations, every help is appreciated,
regards,
angeloQuoted 89 lines · Baruch Siach
Hi Angelo,
Quoted 3 lines · Angelo Dureghello
sorry to contact you directly but i couldn't get any help from the kernel.org mailing list, since i am not a developer my mails are generally skipped.
The best way to get the contact info for a piece of kernel code, is using the
get_maintainer.pl script. Running 'scripts/get_maintainer.pl-fdrivers/net/dm9000.c' gives the following output:[email protected]
[email protected]I added both to Cc.
Quoted 4 lines
I am very near to have a custom board working with MCF5307 cpu and dm9000.
I am using kernel 2.6.36-rc3 with your last patch about spinlock-recursion already included.You should try to update to the latest .36 kernel, which is currently 2.6.36.2. The problem that you experience might be unrelated to the dm9000
driver (or to networking at all), so it might have been fixed in this version.Quoted 3 lines
I have "ping" and "telnet" to the embedded board fully working. If i try to get a sample web page with some images from the board httpd with a browser, in 80% of cases i get a trap/oops:
Try to enable KALLSYMS in your kernel .config to make your stack trace more
meaningful. This is under 'General setup -> Configure standard kernel features
(for small systems) -> Load all symbols for debugging/ksymoops'.I hope this helps.
baruch
Quoted 50 lines
[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29 [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 67.630000] Stack from 00d7b914: [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead 00dec1d4 0000001d 00000000 [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2 00c42c06 0015f6f9 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] Call Trace: [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a] [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6] [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e] [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44] [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218] [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06 [ 67.630000] Stack from 00d7b934: [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4 0000001d 00c42c06 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10 00146fb8 00d7ba20 00029e84 [ 67.630000] Call Trace: [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84] [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482] [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2] [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6] [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee] [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]As i said, i was hoping in your patch but i sadly discovered it is already included in this kernel version.
Hope you can give me some help or can forward me to an appropriate mailing list.--
~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{=- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il - --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/_______________________________________________
uClinux-dev mailing list [email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected] To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Signature · 12 lines
------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: [email protected] SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Hi all,
Joe,
about the debug line inside dm9000_interrupt,
//dm9000_dbg(db, 3, "entering %s\n", __func__);
nothing change, first browsing attempt crashed the board with the same call stack trace:
[ 4.660000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 54.340000] BUG: spinlock recursion on CPU#0, swapper/0 [ 54.340000] lock: 00191244, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0 [ 54.340000] Stack from 001a1b44: [ 54.340000] 001a1b70 000ad968 0018409b 00191244 dead4ead 0018d7a8 00000000 00000000 [ 54.340000] 00191244 0002b4ea 0014d190 001a1ba4 000adb3a 00191244 00184101 00191244 [ 54.340000] 001a1c98 0000001f 0014d15e ffffffe3 00191208 0002b4ea 0014d190 0002caf6 [ 54.340000] 001a1bb0 0014d1ac 00191244 001a1bdc 0002b602 00191244 0000001f 001a1c98 [ 54.340000] 0000001f 0014d15e 00191244 0002b4ea 0014d190 0002caf6 001a1bf0 00000bb6 [ 54.340000] 0000001f 00191244 00cfc6c0 001a1c38 000033c6 0000001f 001a1c00 00000001 [ 54.340000] Call Trace: [ 54.340000] [000ad968] spin_bug+0x86/0x11a [ 54.340000] [000adb3a] do_raw_spin_lock+0x58/0x120 [ 54.340000] [0014d1ac] _raw_spin_lock+0x1c/0x22 [ 54.340000] [0002b602] __do_IRQ+0x2c/0x108 [ 54.340000] [00000bb6] do_IRQ+0x48/0x62 [ 54.340000] [000033c6] inthandler+0x6a/0x74 [ 54.340000] [0014d16c] _raw_spin_unlock+0xe/0x32 [ 54.340000] [0002b6d2] __do_IRQ+0xfc/0x108 [ 54.340000] [00000bb6] do_IRQ+0x48/0x62 [ 54.340000] [000033c6] inthandler+0x6a/0x74 [ 54.340000] [00130f66] tcp_v4_conn_request+0x3fa/0x57c [ 54.340000] [0012a1a6] tcp_rcv_state_process+0x25e/0xa66 [ 54.340000] [00130984] tcp_v4_do_rcv+0x7c/0x1c8 [ 54.340000] [00132834] tcp_v4_rcv+0x546/0x6d2
Greg,
i phisically connected the HW interrupt pin of dm9000 to MCF5307 IRQ7 pin (pin68). dm9000 is configured (through a resistor to3.3V on pin 57) not as default, but to act with HIGH to LOW interrupt edge, as MCF5307 understand, and the interrupt line is pulled up to 3.3V to avoid flickering.
PULL UP RES to 3.3V
dm9000 | |
IRQ |---------+-------------------| MCCF5307 PIN 68 (IRQ7)
IRQ 7 is the "level 7" autovectored interrupt (vect 31 dec).
Checking well the MCF5307 datasheet i have seen that "level 7" interrupt i casually choosed seems to be a special level:
/18.7.1 Level 7 Interrupts
Level 7 interrupts are nonmaskable and are handled differently than other interrupts. Level 7 interrupts are edge triggered by a transition from a lower priority request to the level 7 request. Interrupts at all other levels are level sensitive. Therefore, if IRQ7 remains asserted, the MCF5307 recognizes only one level 7 interrupt because only one transition from a lower level request to a level 7 request occurred. For the processor to recognize two consecutive level 7 interrupts, one of the following must occur:
1) The interrupt request on the interrupt control pins is raised to level 7 and stays there until an interrupt-acknowledge cycle begins. The level later drops but then returns to level 7, causing a second transition on the interrupt control lines.
2) The interrupt request on the interrupt control pins is raised to level 7 and stays there. If the level 7 interrupt routine lowers the mask level, a second level 7 interrupt is recognized without a transition of the interrupt control pins. After the level 7 routine completes, the MCF5307 compares the mask level to the request level on the IRQx signals. Because the mask level is lower than the requested level, the interrupt mask is set back to level 7. To ensure it is recognized, the level 7 request on IRQ7 must be held until the second interrupt-acknowledge bus cycle begins./
I guess i can try to use another IRQ line, for example IRQ1 and see what happen. Let me know your thought and i can try right now to hw wire up the fix.
still many thanks,
regards,
angelo
Quoted 12 lines · Greg Ungerer
Hi Angelo,
Quoted 4 lines · Angelo Dureghello
Hi all,
thanks for the help,
the kernel is a main line kernel. Then yes, i am still using uclinux tree for libc/tools.How is the DM9000 hardware connected to the 5307?
I am wondering how you connected the interrupt (and to which interrupt) and the addressing (direct of a chip select)?
Quoted 279 lines
(For example NETtel based 5307 platform support of the SMC91x code is in mainline as
arch/m68knommu/platform/5307/nettel.c). Can you show the code you used to setup your dm9000 hardware? (Specifically I guess I want to know if you use the "auto-vectored" interrupt mode?)Thanks
GregQuoted 267 lines
I collected another spinlock recursion with a slightly different call stack trace, as always, the spinlock recursion issue happen on a high tx/rx traffic of the dm9000e, in this case just asking an index.html with some images and texts:
[ 1108.930000] BUG: spinlock recursion on CPU#0, httpd/29 [ 1108.930000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 1108.930000] Stack from 00d7a688: [ 1108.930000] 00d7a6b4 000ad988 001840ca 00c42c06 dead4ead 00d641d4 0000001d 00000000 [ 1108.930000] 00c42c06 000064f0 00c42800 00d7a6e8 000adb5a 00c42c06 00184130 00002704 [ 1108.930000] 00000000 0000001f 0014d17e 00159912 00c42b60 000064f0 00c42800 0002cb16 [ 1108.930000] 00d7a6f8 0014d24e 00c42c06 00000000 00d7a738 000e485c 00c42c06 00000000 [ 1108.930000] 00000000 0000001f 0014d17e 00159912 0000004a 00cfc600 000064f0 00009a74 [ 1108.930000] 0002cb16 00191204 00d7a760 0002b6f2 00d7a760 0002b514 0000001f 00c42800 [ 1108.930000] Call Trace: [ 1108.930000] [000ad988] spin_bug+0x86/0x11a [ 1108.930000] [000adb5a] do_raw_spin_lock+0x58/0x120 [ 1108.930000] [0014d24e] _raw_spin_lock_irqsave+0x28/0x32 [ 1108.930000] [000e485c] dm9000_interrupt+0x1a/0x2e0 [ 1108.930000] [0002b514] handle_IRQ_event+0x2a/0xec [ 1108.930000] [0002b680] __do_IRQ+0xaa/0x128 [ 1108.930000] [00000bb6] do_IRQ+0x48/0x62 [ 1108.930000] [000033c6] inthandler+0x6a/0x74 [ 1108.930000] [000fb626] dev_hard_start_xmit+0x170/0x4c4 [ 1108.930000] [0010b80e] sch_direct_xmit+0xc0/0x1bc [ 1108.930000] [000fe9de] dev_queue_xmit+0x160/0x3e6 [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320 [ 1108.930000] [0011a768] ip_output+0x9e/0xa8 [ 1108.930000] [00119856] ip_local_out+0x26/0x30 [ 1108.930000] [0011a56e] ip_build_and_send_pkt+0x16e/0x178 [ 1108.930000] [0012fc96] tcp_v4_send_synack+0x52/0x90 [ 1108.930000] [00130f86] tcp_v4_conn_request+0x3fa/0x57c [ 1108.930000] [0012a1c6] tcp_rcv_state_process+0x25e/0xa66 [ 1108.930000] [001309a4] tcp_v4_do_rcv+0x7c/0x1c8 [ 1108.930000] [00132854] tcp_v4_rcv+0x546/0x6d2 [ 1108.930000] [001153a8] ip_local_deliver+0x9c/0x1b0 [ 1108.930000] [001158e8] ip_rcv+0x42c/0x5f0 [ 1108.930000] [000fa74e] __netif_receive_skb+0x196/0x2ec [ 1108.930000] [000fe142] process_backlog+0x72/0x11e [ 1108.930000] [000fe290] net_rx_action+0xa2/0x150 [ 1108.930000] [0000e13c] __do_softirq+0x74/0xe4 [ 1108.930000] [0000e1e2] do_softirq+0x36/0x40 [ 1108.930000] [0000e6c6] local_bh_enable+0x7a/0xa4 [ 1108.930000] [000fe972] dev_queue_xmit+0xf4/0x3e6 [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320 [ 1108.930000] [0011a768] ip_output+0x9e/0xa8 [ 1108.930000] [00119856] ip_local_out+0x26/0x30 [ 1108.930000] [0011a90a] ip_queue_xmit+0x198/0x426 [ 1108.930000] [0012bcc8] tcp_transmit_skb+0x3f0/0x76c [ 1108.930000] [0012cfda] tcp_write_xmit+0x178/0x868 [ 1108.930000] [0012d6f8] __tcp_push_pending_frames+0x2e/0x9a [ 1108.930000] [001222be] tcp_sendmsg+0x82e/0x98c [ 1108.930000] [0013d9c0] inet_sendmsg+0x32/0x54 [ 1108.930000] [000ec25e] sock_aio_write+0xc8/0x138 [ 1108.930000] [00043e7e] do_sync_write+0x9e/0xfe [ 1108.930000] [00043f56] vfs_write+0x78/0x84 [ 1108.930000] [0004446c] sys_write+0x40/0x7a [ 1108.930000] [00003244] system_call+0x84/0xc2 [ 1108.930000]seems like while i transmit a packet,
dm9000_interrupttry to acquire the spinlock owned from the same task.Compiling the kernel i am getting:
CCkernel/irq/handle.okernel/irq/handle.c:432:3: warning: #warning__do_IRQis deprecated. Please convert to proper flow handlersCould the usage of
__do_IRQsuper-handler be a cause of the issue ?many thanks,
angeloQuoted 176 lines · Geert Uytterhoeven
Quoted 7 lines · Baruch Siach
Hi Angelo,
Quoted 2 lines · Angelo Dureghello
just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still there, below the call stack trace.
Help from the m68k experts seems to be needed. Adding the relevant list to Cc.
This is uClinux? Added Cc...
Quoted 164 lines
Quoted 151 lines
[ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29 [ 39.390000] lock: 00189c44, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 39.390000] Stack from 00d6a990: [ 39.390000] 00d6a9bc 000a9710 0017cac7 00189c44 dead4ead 00de48f4 0000001d 00000000 [ 39.390000] 00189c44 0002a646 00145f70 00d6a9f0 000a98e2 00189c44 0017cb2d 00189c44 [ 39.390000] 00d6aad8 0000001f 00145f5c 001523f6 00189c08 0002a646 00145f70 0002bc52 [ 39.390000] 00d6a9fc 00145f7e 00189c44 00d6aa28 0002a75e 00189c44 0000001f 00d6aad8 [ 39.390000] 0000001f 00145f5c 00189c08 0002a646 00145f70 0002bc52 00d6aa3c 00000bb6 [ 39.390000] 0000001f 00189c44 00cfc780 00d6aa84 0000337a 0000001f 00d6aa4c 00000001 [ 39.390000] Call Trace: [ 39.390000] [000a9710] spin_bug+0x86/0x11a [ 39.390000] [000a98e2] do_raw_spin_lock+0x58/0x120 [ 39.390000] [00145f7e] _raw_spin_lock+0xe/0x14 [ 39.390000] [0002a75e] __do_IRQ+0x2c/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [0002a82e] __do_IRQ+0xfc/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [000ef0ce] skb_release_all+0x10/0x20 [ 39.390000] [000ee6bc] __kfree_skb+0x10/0x92 [ 39.390000] [000ee75e] consume_skb+0x20/0x34 [ 39.390000] [000e004e] dm9000_start_xmit+0xdc/0xec [ 39.390000] [000f67a2] dev_hard_start_xmit+0x146/0x472 [ 39.390000] [00106506] sch_direct_xmit+0xc0/0x1bc [ 39.390000] [000f9914] dev_queue_xmit+0x160/0x3e4 [ 39.390000] [00113b3e] ip_finish_output+0xee/0x318 [ 39.390000] [001142b4] ip_output+0x7c/0x88 [ 39.390000] [00113dc6] ip_local_out+0x26/0x30 [ 39.390000] [00114d9a] ip_queue_xmit+0x152/0x374 [ 39.390000] [00125c8c] tcp_transmit_skb+0x3f0/0x732 [ 39.390000] [00126f26] tcp_write_xmit+0x178/0x868 [ 39.390000] [00127644] __tcp_push_pending_frames+0x2e/0x9a [ 39.390000] [0011c3d6] tcp_sendmsg+0x82e/0x98c [ 39.390000] [00137544] inet_sendmsg+0x32/0x54 [ 39.390000] [000e79a6] sock_aio_write+0xc8/0x138 [ 39.390000] [00042590] do_sync_write+0x9e/0xfe [ 39.390000] [00042668] vfs_write+0x78/0x84 [ 39.390000] [00042a92] sys_write+0x40/0x7a [ 39.390000] [00003224] system_call+0x84/0xc2 [ 39.390000]dm9000e is as default not visible/selectable in menuconfig for Coldfire architectures, so this probably cannot be considered as a kernel bug.
I going forward in investigations, every help is appreciated,
regards,
angeloQuoted 89 lines · Baruch Siach
Hi Angelo,
Quoted 3 lines · Angelo Dureghello
sorry to contact you directly but i couldn't get any help from the kernel.org mailing list, since i am not a developer my mails are generally skipped.
The best way to get the contact info for a piece of kernel code, is using the
get_maintainer.pl script. Running 'scripts/get_maintainer.pl-fdrivers/net/dm9000.c' gives the following output:[email protected]
[email protected]I added both to Cc.
Quoted 4 lines
I am very near to have a custom board working with MCF5307 cpu and dm9000.
I am using kernel 2.6.36-rc3 with your last patch about spinlock-recursion already included.You should try to update to the latest .36 kernel, which is currently 2.6.36.2. The problem that you experience might be unrelated to the dm9000
driver (or to networking at all), so it might have been fixed in this version.Quoted 3 lines
I have "ping" and "telnet" to the embedded board fully working. If i try to get a sample web page with some images from the board httpd with a browser, in 80% of cases i get a trap/oops:
Try to enable KALLSYMS in your kernel .config to make your stack trace more
meaningful. This is under 'General setup -> Configure standard kernel features
(for small systems) -> Load all symbols for debugging/ksymoops'.I hope this helps.
baruch
Quoted 50 lines
[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29 [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 67.630000] Stack from 00d7b914: [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead 00dec1d4 0000001d 00000000 [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2 00c42c06 0015f6f9 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] Call Trace: [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a] [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6] [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e] [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44] [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218] [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06 [ 67.630000] Stack from 00d7b934: [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4 0000001d 00c42c06 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10 00146fb8 00d7ba20 00029e84 [ 67.630000] Call Trace: [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84] [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482] [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2] [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6] [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee] [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]As i said, i was hoping in your patch but i sadly discovered it is already included in this kernel version.
Hope you can give me some help or can forward me to an appropriate mailing list.Signature · 11 lines
~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/_______________________________________________
uClinux-dev mailing list [email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected] To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list [email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected] To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Hi all,
Joe,
about the debug line inside dm9000_interrupt,
//dm9000_dbg(db, 3, "entering %s\n", __func__);
nothing change, first browsing attempt crashed the board with the same call stack trace:
[ 4.660000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 54.340000] BUG: spinlock recursion on CPU#0, swapper/0 [ 54.340000] lock: 00191244, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0 [ 54.340000] Stack from 001a1b44: [ 54.340000] 001a1b70 000ad968 0018409b 00191244 dead4ead 0018d7a8 00000000 00000000 [ 54.340000] 00191244 0002b4ea 0014d190 001a1ba4 000adb3a 00191244 00184101 00191244 [ 54.340000] 001a1c98 0000001f 0014d15e ffffffe3 00191208 0002b4ea 0014d190 0002caf6 [ 54.340000] 001a1bb0 0014d1ac 00191244 001a1bdc 0002b602 00191244 0000001f 001a1c98 [ 54.340000] 0000001f 0014d15e 00191244 0002b4ea 0014d190 0002caf6 001a1bf0 00000bb6 [ 54.340000] 0000001f 00191244 00cfc6c0 001a1c38 000033c6 0000001f 001a1c00 00000001 [ 54.340000] Call Trace: [ 54.340000] [000ad968] spin_bug+0x86/0x11a [ 54.340000] [000adb3a] do_raw_spin_lock+0x58/0x120 [ 54.340000] [0014d1ac] _raw_spin_lock+0x1c/0x22 [ 54.340000] [0002b602] __do_IRQ+0x2c/0x108 [ 54.340000] [00000bb6] do_IRQ+0x48/0x62 [ 54.340000] [000033c6] inthandler+0x6a/0x74 [ 54.340000] [0014d16c] _raw_spin_unlock+0xe/0x32 [ 54.340000] [0002b6d2] __do_IRQ+0xfc/0x108 [ 54.340000] [00000bb6] do_IRQ+0x48/0x62 [ 54.340000] [000033c6] inthandler+0x6a/0x74 [ 54.340000] [00130f66] tcp_v4_conn_request+0x3fa/0x57c [ 54.340000] [0012a1a6] tcp_rcv_state_process+0x25e/0xa66 [ 54.340000] [00130984] tcp_v4_do_rcv+0x7c/0x1c8 [ 54.340000] [00132834] tcp_v4_rcv+0x546/0x6d2
Greg,
i phisically connected the HW interrupt pin of dm9000 to MCF5307 IRQ7 pin (pin68). dm9000 is configured (through a resistor to3.3V on pin 57) not as default, but to act with HIGH to LOW interrupt edge, as MCF5307 understand, and the interrupt line is pulled up to 3.3V to avoid flickering.
PULL UP RES to 3.3V
dm9000 | |
IRQ |---------+-------------------| MCCF5307 PIN 68 (IRQ7)
IRQ 7 is the "level 7" autovectored interrupt (vect 31 dec).
Checking well the MCF5307 datasheet i have seen that "level 7" interrupt i casually choosed seems to be a special level:
/18.7.1 Level 7 Interrupts
Level 7 interrupts are nonmaskable and are handled differently than other interrupts. Level 7 interrupts are edge triggered by a transition from a lower priority request to the level 7 request. Interrupts at all other levels are level sensitive. Therefore, if IRQ7 remains asserted, the MCF5307 recognizes only one level 7 interrupt because only one transition from a lower level request to a level 7 request occurred. For the processor to recognize two consecutive level 7 interrupts, one of the following must occur:
1) The interrupt request on the interrupt control pins is raised to level 7 and stays there until an interrupt-acknowledge cycle begins. The level later drops but then returns to level 7, causing a second transition on the interrupt control lines.
2) The interrupt request on the interrupt control pins is raised to level 7 and stays there. If the level 7 interrupt routine lowers the mask level, a second level 7 interrupt is recognized without a transition of the interrupt control pins. After the level 7 routine completes, the MCF5307 compares the mask level to the request level on the IRQx signals. Because the mask level is lower than the requested level, the interrupt mask is set back to level 7. To ensure it is recognized, the level 7 request on IRQ7 must be held until the second interrupt-acknowledge bus cycle begins./
I guess i can try to use another IRQ line, for example IRQ1 and see what happen. Let me know your thought and i can try right now to hw wire up the fix.
still many thanks,
regards,
angelo
Quoted 12 lines · Greg Ungerer
Hi Angelo,
Quoted 4 lines · Angelo Dureghello
Hi all,
thanks for the help,
the kernel is a main line kernel. Then yes, i am still using uclinux tree for libc/tools.How is the DM9000 hardware connected to the 5307?
I am wondering how you connected the interrupt (and to which interrupt) and the addressing (direct of a chip select)?
Quoted 279 lines
(For example NETtel based 5307 platform support of the SMC91x code is in mainline as
arch/m68knommu/platform/5307/nettel.c). Can you show the code you used to setup your dm9000 hardware? (Specifically I guess I want to know if you use the "auto-vectored" interrupt mode?)Thanks
GregQuoted 267 lines
I collected another spinlock recursion with a slightly different call stack trace, as always, the spinlock recursion issue happen on a high tx/rx traffic of the dm9000e, in this case just asking an index.html with some images and texts:
[ 1108.930000] BUG: spinlock recursion on CPU#0, httpd/29 [ 1108.930000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 1108.930000] Stack from 00d7a688: [ 1108.930000] 00d7a6b4 000ad988 001840ca 00c42c06 dead4ead 00d641d4 0000001d 00000000 [ 1108.930000] 00c42c06 000064f0 00c42800 00d7a6e8 000adb5a 00c42c06 00184130 00002704 [ 1108.930000] 00000000 0000001f 0014d17e 00159912 00c42b60 000064f0 00c42800 0002cb16 [ 1108.930000] 00d7a6f8 0014d24e 00c42c06 00000000 00d7a738 000e485c 00c42c06 00000000 [ 1108.930000] 00000000 0000001f 0014d17e 00159912 0000004a 00cfc600 000064f0 00009a74 [ 1108.930000] 0002cb16 00191204 00d7a760 0002b6f2 00d7a760 0002b514 0000001f 00c42800 [ 1108.930000] Call Trace: [ 1108.930000] [000ad988] spin_bug+0x86/0x11a [ 1108.930000] [000adb5a] do_raw_spin_lock+0x58/0x120 [ 1108.930000] [0014d24e] _raw_spin_lock_irqsave+0x28/0x32 [ 1108.930000] [000e485c] dm9000_interrupt+0x1a/0x2e0 [ 1108.930000] [0002b514] handle_IRQ_event+0x2a/0xec [ 1108.930000] [0002b680] __do_IRQ+0xaa/0x128 [ 1108.930000] [00000bb6] do_IRQ+0x48/0x62 [ 1108.930000] [000033c6] inthandler+0x6a/0x74 [ 1108.930000] [000fb626] dev_hard_start_xmit+0x170/0x4c4 [ 1108.930000] [0010b80e] sch_direct_xmit+0xc0/0x1bc [ 1108.930000] [000fe9de] dev_queue_xmit+0x160/0x3e6 [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320 [ 1108.930000] [0011a768] ip_output+0x9e/0xa8 [ 1108.930000] [00119856] ip_local_out+0x26/0x30 [ 1108.930000] [0011a56e] ip_build_and_send_pkt+0x16e/0x178 [ 1108.930000] [0012fc96] tcp_v4_send_synack+0x52/0x90 [ 1108.930000] [00130f86] tcp_v4_conn_request+0x3fa/0x57c [ 1108.930000] [0012a1c6] tcp_rcv_state_process+0x25e/0xa66 [ 1108.930000] [001309a4] tcp_v4_do_rcv+0x7c/0x1c8 [ 1108.930000] [00132854] tcp_v4_rcv+0x546/0x6d2 [ 1108.930000] [001153a8] ip_local_deliver+0x9c/0x1b0 [ 1108.930000] [001158e8] ip_rcv+0x42c/0x5f0 [ 1108.930000] [000fa74e] __netif_receive_skb+0x196/0x2ec [ 1108.930000] [000fe142] process_backlog+0x72/0x11e [ 1108.930000] [000fe290] net_rx_action+0xa2/0x150 [ 1108.930000] [0000e13c] __do_softirq+0x74/0xe4 [ 1108.930000] [0000e1e2] do_softirq+0x36/0x40 [ 1108.930000] [0000e6c6] local_bh_enable+0x7a/0xa4 [ 1108.930000] [000fe972] dev_queue_xmit+0xf4/0x3e6 [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320 [ 1108.930000] [0011a768] ip_output+0x9e/0xa8 [ 1108.930000] [00119856] ip_local_out+0x26/0x30 [ 1108.930000] [0011a90a] ip_queue_xmit+0x198/0x426 [ 1108.930000] [0012bcc8] tcp_transmit_skb+0x3f0/0x76c [ 1108.930000] [0012cfda] tcp_write_xmit+0x178/0x868 [ 1108.930000] [0012d6f8] __tcp_push_pending_frames+0x2e/0x9a [ 1108.930000] [001222be] tcp_sendmsg+0x82e/0x98c [ 1108.930000] [0013d9c0] inet_sendmsg+0x32/0x54 [ 1108.930000] [000ec25e] sock_aio_write+0xc8/0x138 [ 1108.930000] [00043e7e] do_sync_write+0x9e/0xfe [ 1108.930000] [00043f56] vfs_write+0x78/0x84 [ 1108.930000] [0004446c] sys_write+0x40/0x7a [ 1108.930000] [00003244] system_call+0x84/0xc2 [ 1108.930000]seems like while i transmit a packet,
dm9000_interrupttry to acquire the spinlock owned from the same task.Compiling the kernel i am getting:
CCkernel/irq/handle.okernel/irq/handle.c:432:3: warning: #warning__do_IRQis deprecated. Please convert to proper flow handlersCould the usage of
__do_IRQsuper-handler be a cause of the issue ?many thanks,
angeloQuoted 176 lines · Geert Uytterhoeven
Quoted 7 lines · Baruch Siach
Hi Angelo,
Quoted 2 lines · Angelo Dureghello
just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still there, below the call stack trace.
Help from the m68k experts seems to be needed. Adding the relevant list to Cc.
This is uClinux? Added Cc...
Quoted 164 lines
Quoted 151 lines
[ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29 [ 39.390000] lock: 00189c44, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 39.390000] Stack from 00d6a990: [ 39.390000] 00d6a9bc 000a9710 0017cac7 00189c44 dead4ead 00de48f4 0000001d 00000000 [ 39.390000] 00189c44 0002a646 00145f70 00d6a9f0 000a98e2 00189c44 0017cb2d 00189c44 [ 39.390000] 00d6aad8 0000001f 00145f5c 001523f6 00189c08 0002a646 00145f70 0002bc52 [ 39.390000] 00d6a9fc 00145f7e 00189c44 00d6aa28 0002a75e 00189c44 0000001f 00d6aad8 [ 39.390000] 0000001f 00145f5c 00189c08 0002a646 00145f70 0002bc52 00d6aa3c 00000bb6 [ 39.390000] 0000001f 00189c44 00cfc780 00d6aa84 0000337a 0000001f 00d6aa4c 00000001 [ 39.390000] Call Trace: [ 39.390000] [000a9710] spin_bug+0x86/0x11a [ 39.390000] [000a98e2] do_raw_spin_lock+0x58/0x120 [ 39.390000] [00145f7e] _raw_spin_lock+0xe/0x14 [ 39.390000] [0002a75e] __do_IRQ+0x2c/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [0002a82e] __do_IRQ+0xfc/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [000ef0ce] skb_release_all+0x10/0x20 [ 39.390000] [000ee6bc] __kfree_skb+0x10/0x92 [ 39.390000] [000ee75e] consume_skb+0x20/0x34 [ 39.390000] [000e004e] dm9000_start_xmit+0xdc/0xec [ 39.390000] [000f67a2] dev_hard_start_xmit+0x146/0x472 [ 39.390000] [00106506] sch_direct_xmit+0xc0/0x1bc [ 39.390000] [000f9914] dev_queue_xmit+0x160/0x3e4 [ 39.390000] [00113b3e] ip_finish_output+0xee/0x318 [ 39.390000] [001142b4] ip_output+0x7c/0x88 [ 39.390000] [00113dc6] ip_local_out+0x26/0x30 [ 39.390000] [00114d9a] ip_queue_xmit+0x152/0x374 [ 39.390000] [00125c8c] tcp_transmit_skb+0x3f0/0x732 [ 39.390000] [00126f26] tcp_write_xmit+0x178/0x868 [ 39.390000] [00127644] __tcp_push_pending_frames+0x2e/0x9a [ 39.390000] [0011c3d6] tcp_sendmsg+0x82e/0x98c [ 39.390000] [00137544] inet_sendmsg+0x32/0x54 [ 39.390000] [000e79a6] sock_aio_write+0xc8/0x138 [ 39.390000] [00042590] do_sync_write+0x9e/0xfe [ 39.390000] [00042668] vfs_write+0x78/0x84 [ 39.390000] [00042a92] sys_write+0x40/0x7a [ 39.390000] [00003224] system_call+0x84/0xc2 [ 39.390000]dm9000e is as default not visible/selectable in menuconfig for Coldfire architectures, so this probably cannot be considered as a kernel bug.
I going forward in investigations, every help is appreciated,
regards,
angeloQuoted 89 lines · Baruch Siach
Hi Angelo,
Quoted 3 lines · Angelo Dureghello
sorry to contact you directly but i couldn't get any help from the kernel.org mailing list, since i am not a developer my mails are generally skipped.
The best way to get the contact info for a piece of kernel code, is using the
get_maintainer.pl script. Running 'scripts/get_maintainer.pl-fdrivers/net/dm9000.c' gives the following output:[email protected]
[email protected]I added both to Cc.
Quoted 4 lines
I am very near to have a custom board working with MCF5307 cpu and dm9000.
I am using kernel 2.6.36-rc3 with your last patch about spinlock-recursion already included.You should try to update to the latest .36 kernel, which is currently 2.6.36.2. The problem that you experience might be unrelated to the dm9000
driver (or to networking at all), so it might have been fixed in this version.Quoted 3 lines
I have "ping" and "telnet" to the embedded board fully working. If i try to get a sample web page with some images from the board httpd with a browser, in 80% of cases i get a trap/oops:
Try to enable KALLSYMS in your kernel .config to make your stack trace more
meaningful. This is under 'General setup -> Configure standard kernel features
(for small systems) -> Load all symbols for debugging/ksymoops'.I hope this helps.
baruch
Quoted 50 lines
[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29 [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 67.630000] Stack from 00d7b914: [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead 00dec1d4 0000001d 00000000 [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2 00c42c06 0015f6f9 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] Call Trace: [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a] [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6] [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e] [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44] [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218] [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06 [ 67.630000] Stack from 00d7b934: [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4 0000001d 00c42c06 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10 00146fb8 00d7ba20 00029e84 [ 67.630000] Call Trace: [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84] [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482] [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2] [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6] [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee] [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]As i said, i was hoping in your patch but i sadly discovered it is already included in this kernel version.
Hope you can give me some help or can forward me to an appropriate mailing list.Signature · 11 lines
~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/_______________________________________________
uClinux-dev mailing list [email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected] To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list [email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected] To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Hi Anelo,
On 30/12/10 19:59, Angelo Dureghello wrote:
[snip]
Quoted 9 lines
i phisically connected the HW interrupt pin of dm9000 to MCF5307 IRQ7 pin (pin68). dm9000 is configured (through a resistor to3.3V on pin 57) not as default, but to act with HIGH to LOW interrupt edge, as MCF5307 understand, and the interrupt line is pulled up to 3.3V to avoid flickering.
PULL UP RES to 3.3V
Quoted 8 lines
dm9000 | |
IRQ |---------+-------------------| MCCF5307 PIN 68 (IRQ7)IRQ 7 is the "level 7" autovectored interrupt (vect 31 dec).
Checking well the MCF5307 datasheet i have seen that "level 7" interrupt i casually choosed seems to be a special level:
Yes, IRQ7 is "special" on the 5307. It is non-maskable. So normal linux locking will be broken if you use it in the normal way.
Quoted 34 lines
/18.7.1 Level 7 Interrupts
Level 7 interrupts are nonmaskable and are handled differently than other interrupts.
Level 7 interrupts are edge triggered by a transition from a lower priority request to the
level 7 request. Interrupts at all other levels are level sensitive. Therefore, if IRQ7 remains
asserted, the MCF5307 recognizes only one level 7 interrupt because only one transition
from a lower level request to a level 7 request occurred. For the processor to
recognize two consecutive level 7 interrupts, one of the following must occur:1) The interrupt request on the interrupt control pins is raised to level 7 and stays there
until an interrupt-acknowledge cycle begins. The level later drops but then returns to
level 7, causing a second transition on the interrupt control lines.2) The interrupt request on the interrupt control pins is raised to level 7 and stays there.
If the level 7 interrupt routine lowers the mask level, a second level 7 interrupt is
recognized without a transition of the interrupt control pins. After the level 7 routine
completes, the MCF5307 compares the mask level to the request level on the IRQx
signals. Because the mask level is lower than the requested level, the interrupt mask
is set back to level 7. To ensure it is recognized, the level 7 request on IRQ7 must be
held until the second interrupt-acknowledge bus cycle begins./
Quoted 3 lines
I guess i can try to use another IRQ line, for example IRQ1 and see what happen. Let me know your thought and i can try right now to hw wire up the fix.
Yes, I suggest you try using another IRQ line. Stay away from IRQ7 for any normal devices.
Regards
Greg
Quoted 302 lines
still many thanks,
regards,
angeloQuoted 292 lines · Greg Ungerer
Hi Angelo,
Quoted 4 lines · Angelo Dureghello
Hi all,
thanks for the help,
the kernel is a main line kernel. Then yes, i am still using uclinux tree for libc/tools.How is the DM9000 hardware connected to the 5307?
I am wondering how you connected the interrupt (and to which interrupt) and the addressing (direct of a chip select)?(For example NETtel based 5307 platform support of the SMC91x code is in mainline as
arch/m68knommu/platform/5307/nettel.c). Can you show the code you used to setup your dm9000 hardware? (Specifically I guess I want to know if you use the "auto-vectored" interrupt mode?)Thanks
GregQuoted 268 lines
I collected another spinlock recursion with a slightly different call stack trace, as always, the spinlock recursion issue happen on a high tx/rx traffic of the dm9000e, in this case just asking an index.html with some images and texts:
[ 1108.930000] BUG: spinlock recursion on CPU#0, httpd/29 [ 1108.930000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 1108.930000] Stack from 00d7a688: [ 1108.930000] 00d7a6b4 000ad988 001840ca 00c42c06 dead4ead 00d641d4 0000001d 00000000 [ 1108.930000] 00c42c06 000064f0 00c42800 00d7a6e8 000adb5a 00c42c06 00184130 00002704 [ 1108.930000] 00000000 0000001f 0014d17e 00159912 00c42b60 000064f0 00c42800 0002cb16 [ 1108.930000] 00d7a6f8 0014d24e 00c42c06 00000000 00d7a738 000e485c 00c42c06 00000000 [ 1108.930000] 00000000 0000001f 0014d17e 00159912 0000004a 00cfc600 000064f0 00009a74 [ 1108.930000] 0002cb16 00191204 00d7a760 0002b6f2 00d7a760 0002b514 0000001f 00c42800 [ 1108.930000] Call Trace: [ 1108.930000] [000ad988] spin_bug+0x86/0x11a [ 1108.930000] [000adb5a] do_raw_spin_lock+0x58/0x120 [ 1108.930000] [0014d24e] _raw_spin_lock_irqsave+0x28/0x32 [ 1108.930000] [000e485c] dm9000_interrupt+0x1a/0x2e0 [ 1108.930000] [0002b514] handle_IRQ_event+0x2a/0xec [ 1108.930000] [0002b680] __do_IRQ+0xaa/0x128 [ 1108.930000] [00000bb6] do_IRQ+0x48/0x62 [ 1108.930000] [000033c6] inthandler+0x6a/0x74 [ 1108.930000] [000fb626] dev_hard_start_xmit+0x170/0x4c4 [ 1108.930000] [0010b80e] sch_direct_xmit+0xc0/0x1bc [ 1108.930000] [000fe9de] dev_queue_xmit+0x160/0x3e6 [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320 [ 1108.930000] [0011a768] ip_output+0x9e/0xa8 [ 1108.930000] [00119856] ip_local_out+0x26/0x30 [ 1108.930000] [0011a56e] ip_build_and_send_pkt+0x16e/0x178 [ 1108.930000] [0012fc96] tcp_v4_send_synack+0x52/0x90 [ 1108.930000] [00130f86] tcp_v4_conn_request+0x3fa/0x57c [ 1108.930000] [0012a1c6] tcp_rcv_state_process+0x25e/0xa66 [ 1108.930000] [001309a4] tcp_v4_do_rcv+0x7c/0x1c8 [ 1108.930000] [00132854] tcp_v4_rcv+0x546/0x6d2 [ 1108.930000] [001153a8] ip_local_deliver+0x9c/0x1b0 [ 1108.930000] [001158e8] ip_rcv+0x42c/0x5f0 [ 1108.930000] [000fa74e] __netif_receive_skb+0x196/0x2ec [ 1108.930000] [000fe142] process_backlog+0x72/0x11e [ 1108.930000] [000fe290] net_rx_action+0xa2/0x150 [ 1108.930000] [0000e13c] __do_softirq+0x74/0xe4 [ 1108.930000] [0000e1e2] do_softirq+0x36/0x40 [ 1108.930000] [0000e6c6] local_bh_enable+0x7a/0xa4 [ 1108.930000] [000fe972] dev_queue_xmit+0xf4/0x3e6 [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320 [ 1108.930000] [0011a768] ip_output+0x9e/0xa8 [ 1108.930000] [00119856] ip_local_out+0x26/0x30 [ 1108.930000] [0011a90a] ip_queue_xmit+0x198/0x426 [ 1108.930000] [0012bcc8] tcp_transmit_skb+0x3f0/0x76c [ 1108.930000] [0012cfda] tcp_write_xmit+0x178/0x868 [ 1108.930000] [0012d6f8] __tcp_push_pending_frames+0x2e/0x9a [ 1108.930000] [001222be] tcp_sendmsg+0x82e/0x98c [ 1108.930000] [0013d9c0] inet_sendmsg+0x32/0x54 [ 1108.930000] [000ec25e] sock_aio_write+0xc8/0x138 [ 1108.930000] [00043e7e] do_sync_write+0x9e/0xfe [ 1108.930000] [00043f56] vfs_write+0x78/0x84 [ 1108.930000] [0004446c] sys_write+0x40/0x7a [ 1108.930000] [00003244] system_call+0x84/0xc2 [ 1108.930000]seems like while i transmit a packet,
dm9000_interrupttry to acquire the spinlock owned from the same task.Compiling the kernel i am getting:
CCkernel/irq/handle.okernel/irq/handle.c:432:3: warning: #warning__do_IRQis deprecated. Please convert to proper flow handlersCould the usage of
__do_IRQsuper-handler be a cause of the issue ?many thanks,
angeloQuoted 177 lines · Geert Uytterhoeven
Quoted 7 lines · Baruch Siach
Hi Angelo,
Quoted 2 lines · Angelo Dureghello
just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still there, below the call stack trace.
Help from the m68k experts seems to be needed. Adding the relevant list to Cc.
This is uClinux? Added Cc...
Quoted 165 lines
Quoted 54 lines
[ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29 [ 39.390000] lock: 00189c44, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 39.390000] Stack from 00d6a990: [ 39.390000] 00d6a9bc 000a9710 0017cac7 00189c44 dead4ead 00de48f4 0000001d 00000000 [ 39.390000] 00189c44 0002a646 00145f70 00d6a9f0 000a98e2 00189c44 0017cb2d 00189c44 [ 39.390000] 00d6aad8 0000001f 00145f5c 001523f6 00189c08 0002a646 00145f70 0002bc52 [ 39.390000] 00d6a9fc 00145f7e 00189c44 00d6aa28 0002a75e 00189c44 0000001f 00d6aad8 [ 39.390000] 0000001f 00145f5c 00189c08 0002a646 00145f70 0002bc52 00d6aa3c 00000bb6 [ 39.390000] 0000001f 00189c44 00cfc780 00d6aa84 0000337a 0000001f 00d6aa4c 00000001 [ 39.390000] Call Trace: [ 39.390000] [000a9710] spin_bug+0x86/0x11a [ 39.390000] [000a98e2] do_raw_spin_lock+0x58/0x120 [ 39.390000] [00145f7e] _raw_spin_lock+0xe/0x14 [ 39.390000] [0002a75e] __do_IRQ+0x2c/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [0002a82e] __do_IRQ+0xfc/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [000ef0ce] skb_release_all+0x10/0x20 [ 39.390000] [000ee6bc] __kfree_skb+0x10/0x92 [ 39.390000] [000ee75e] consume_skb+0x20/0x34 [ 39.390000] [000e004e] dm9000_start_xmit+0xdc/0xec [ 39.390000] [000f67a2] dev_hard_start_xmit+0x146/0x472 [ 39.390000] [00106506] sch_direct_xmit+0xc0/0x1bc [ 39.390000] [000f9914] dev_queue_xmit+0x160/0x3e4 [ 39.390000] [00113b3e] ip_finish_output+0xee/0x318 [ 39.390000] [001142b4] ip_output+0x7c/0x88 [ 39.390000] [00113dc6] ip_local_out+0x26/0x30 [ 39.390000] [00114d9a] ip_queue_xmit+0x152/0x374 [ 39.390000] [00125c8c] tcp_transmit_skb+0x3f0/0x732 [ 39.390000] [00126f26] tcp_write_xmit+0x178/0x868 [ 39.390000] [00127644] __tcp_push_pending_frames+0x2e/0x9a [ 39.390000] [0011c3d6] tcp_sendmsg+0x82e/0x98c [ 39.390000] [00137544] inet_sendmsg+0x32/0x54 [ 39.390000] [000e79a6] sock_aio_write+0xc8/0x138 [ 39.390000] [00042590] do_sync_write+0x9e/0xfe [ 39.390000] [00042668] vfs_write+0x78/0x84 [ 39.390000] [00042a92] sys_write+0x40/0x7a [ 39.390000] [00003224] system_call+0x84/0xc2 [ 39.390000]dm9000e is as default not visible/selectable in menuconfig for Coldfire architectures, so this probably cannot be considered as a kernel bug.
Quoted 98 lines
I going forward in investigations, every help is appreciated,
regards,
angeloQuoted 90 lines · Baruch Siach
Hi Angelo,
Quoted 3 lines · Angelo Dureghello
sorry to contact you directly but i couldn't get any help from the kernel.org mailing list, since i am not a developer my mails are generally skipped.
The best way to get the contact info for a piece of kernel code, is using the
get_maintainer.pl script. Running 'scripts/get_maintainer.pl-fdrivers/net/dm9000.c' gives the following output:[email protected]
[email protected]I added both to Cc.
Quoted 4 lines
I am very near to have a custom board working with MCF5307 cpu and dm9000.
I am using kernel 2.6.36-rc3 with your last patch about spinlock-recursion already included.You should try to update to the latest .36 kernel, which is currently
2.6.36.2. The problem that you experience might be unrelated to the dm9000
driver (or to networking at all), so it might have been fixed in this version.Quoted 3 lines
I have "ping" and "telnet" to the embedded board fully working. If i try to get a sample web page with some images from the board httpd with a browser, in 80% of cases i get a trap/oops:
Try to enable KALLSYMS in your kernel .config to make your stack trace more
meaningful. This is under 'General setup -> Configure standard kernel features
(for small systems) -> Load all symbols for debugging/ksymoops'.I hope this helps.
baruch
Quoted 50 lines
[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29 [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 67.630000] Stack from 00d7b914: [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead 00dec1d4 0000001d 00000000 [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2 00c42c06 0015f6f9 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] Call Trace: [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a] [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6] [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e] [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44] [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218] [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06 [ 67.630000] Stack from 00d7b934: [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4 0000001d 00c42c06 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10 00146fb8 00d7ba20 00029e84 [ 67.630000] Call Trace: [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84] [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482] [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2] [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6] [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee] [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]As i said, i was hoping in your patch but i sadly discovered it is already included in this kernel version.
Hope you can give me some help or can forward me to an appropriate mailing list.--
~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{=- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il - --
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/_______________________________________________
uClinux-dev mailing list [email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected] To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Signature · 12 lines
------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: [email protected] SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close, FAX: +61 7 3891 3630 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Hi Greg and All,
infinite thanks, i solved finally my issue and the board is fully working.
I used IRQ7 line, casually, and unfortunately it was wrong.
IRQ7 is a special autovectored interrupt, in particular, it is an EDGE interrupt, and not a LEVEL interrupt like IRQ1 to 6.
I used IRQ1 now, a normal level interrupt, and everything works perfect.
So i have dm9000 and MCF5307 (big-endian cpu) fully working with 32 bit bus straight wired D0:31 to the dm9000, and would like to share my patch to dm9000.c, so maybe in next kernel versions dm9000 maybe could be enabled as default. Let me know eventually the procedure for this.
still many thanks,
regards,
angelo
Quoted 378 lines · Greg Ungerer
Hi Anelo,
On 30/12/10 19:59, Angelo Dureghello wrote:
[snip]Quoted 9 lines
i phisically connected the HW interrupt pin of dm9000 to MCF5307 IRQ7 pin (pin68). dm9000 is configured (through a resistor to3.3V on pin 57) not as default, but to act with HIGH to LOW interrupt edge, as MCF5307 understand, and the interrupt line is pulled up to 3.3V to avoid flickering.
PULL UP RES to 3.3V
Quoted 8 lines
dm9000 | |
IRQ |---------+-------------------| MCCF5307 PIN 68 (IRQ7)IRQ 7 is the "level 7" autovectored interrupt (vect 31 dec).
Checking well the MCF5307 datasheet i have seen that "level 7" interrupt i casually choosed seems to be a special level:
Yes, IRQ7 is "special" on the 5307. It is non-maskable. So normal linux locking will be broken if you use it in the normal way.
Quoted 34 lines
/18.7.1 Level 7 Interrupts
Level 7 interrupts are nonmaskable and are handled differently than other interrupts.
Level 7 interrupts are edge triggered by a transition from a lower priority request to the
level 7 request. Interrupts at all other levels are level sensitive. Therefore, if IRQ7 remains
asserted, the MCF5307 recognizes only one level 7 interrupt because only one transition
from a lower level request to a level 7 request occurred. For the processor to
recognize two consecutive level 7 interrupts, one of the following must occur:1) The interrupt request on the interrupt control pins is raised to level 7 and stays there
until an interrupt-acknowledge cycle begins. The level later drops but then returns to
level 7, causing a second transition on the interrupt control lines.2) The interrupt request on the interrupt control pins is raised to level 7 and stays there.
If the level 7 interrupt routine lowers the mask level, a second level 7 interrupt is
recognized without a transition of the interrupt control pins. After the level 7 routine
completes, the MCF5307 compares the mask level to the request level on the IRQx
signals. Because the mask level is lower than the requested level, the interrupt mask
is set back to level 7. To ensure it is recognized, the level 7 request on IRQ7 must be
held until the second interrupt-acknowledge bus cycle begins./Quoted 3 lines
I guess i can try to use another IRQ line, for example IRQ1 and see what happen. Let me know your thought and i can try right now to hw wire up the fix.
Yes, I suggest you try using another IRQ line. Stay away from IRQ7 for any normal devices.
Regards
GregQuoted 303 lines
still many thanks,
regards,
angeloQuoted 293 lines · Greg Ungerer
Hi Angelo,
Quoted 4 lines · Angelo Dureghello
Hi all,
thanks for the help,
the kernel is a main line kernel. Then yes, i am still using uclinux tree for libc/tools.How is the DM9000 hardware connected to the 5307?
I am wondering how you connected the interrupt (and to which interrupt) and the addressing (direct of a chip select)?(For example NETtel based 5307 platform support of the SMC91x code is in mainline as
arch/m68knommu/platform/5307/nettel.c). Can you show the code you used to setup your dm9000 hardware? (Specifically I guess I want to know if you use the "auto-vectored" interrupt mode?)Thanks
GregQuoted 269 lines
I collected another spinlock recursion with a slightly different call stack trace, as always, the spinlock recursion issue happen on a high tx/rx traffic of the dm9000e, in this case just asking an index.html with some images and texts:
[ 1108.930000] BUG: spinlock recursion on CPU#0, httpd/29 [ 1108.930000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 1108.930000] Stack from 00d7a688: [ 1108.930000] 00d7a6b4 000ad988 001840ca 00c42c06 dead4ead 00d641d4 0000001d 00000000 [ 1108.930000] 00c42c06 000064f0 00c42800 00d7a6e8 000adb5a 00c42c06 00184130 00002704 [ 1108.930000] 00000000 0000001f 0014d17e 00159912 00c42b60 000064f0 00c42800 0002cb16 [ 1108.930000] 00d7a6f8 0014d24e 00c42c06 00000000 00d7a738 000e485c 00c42c06 00000000 [ 1108.930000] 00000000 0000001f 0014d17e 00159912 0000004a 00cfc600 000064f0 00009a74 [ 1108.930000] 0002cb16 00191204 00d7a760 0002b6f2 00d7a760 0002b514 0000001f 00c42800 [ 1108.930000] Call Trace: [ 1108.930000] [000ad988] spin_bug+0x86/0x11a [ 1108.930000] [000adb5a] do_raw_spin_lock+0x58/0x120 [ 1108.930000] [0014d24e] _raw_spin_lock_irqsave+0x28/0x32 [ 1108.930000] [000e485c] dm9000_interrupt+0x1a/0x2e0 [ 1108.930000] [0002b514] handle_IRQ_event+0x2a/0xec [ 1108.930000] [0002b680] __do_IRQ+0xaa/0x128 [ 1108.930000] [00000bb6] do_IRQ+0x48/0x62 [ 1108.930000] [000033c6] inthandler+0x6a/0x74 [ 1108.930000] [000fb626] dev_hard_start_xmit+0x170/0x4c4 [ 1108.930000] [0010b80e] sch_direct_xmit+0xc0/0x1bc [ 1108.930000] [000fe9de] dev_queue_xmit+0x160/0x3e6 [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320 [ 1108.930000] [0011a768] ip_output+0x9e/0xa8 [ 1108.930000] [00119856] ip_local_out+0x26/0x30 [ 1108.930000] [0011a56e] ip_build_and_send_pkt+0x16e/0x178 [ 1108.930000] [0012fc96] tcp_v4_send_synack+0x52/0x90 [ 1108.930000] [00130f86] tcp_v4_conn_request+0x3fa/0x57c [ 1108.930000] [0012a1c6] tcp_rcv_state_process+0x25e/0xa66 [ 1108.930000] [001309a4] tcp_v4_do_rcv+0x7c/0x1c8 [ 1108.930000] [00132854] tcp_v4_rcv+0x546/0x6d2 [ 1108.930000] [001153a8] ip_local_deliver+0x9c/0x1b0 [ 1108.930000] [001158e8] ip_rcv+0x42c/0x5f0 [ 1108.930000] [000fa74e] __netif_receive_skb+0x196/0x2ec [ 1108.930000] [000fe142] process_backlog+0x72/0x11e [ 1108.930000] [000fe290] net_rx_action+0xa2/0x150 [ 1108.930000] [0000e13c] __do_softirq+0x74/0xe4 [ 1108.930000] [0000e1e2] do_softirq+0x36/0x40 [ 1108.930000] [0000e6c6] local_bh_enable+0x7a/0xa4 [ 1108.930000] [000fe972] dev_queue_xmit+0xf4/0x3e6 [ 1108.930000] [001195c4] ip_finish_output+0xec/0x320 [ 1108.930000] [0011a768] ip_output+0x9e/0xa8 [ 1108.930000] [00119856] ip_local_out+0x26/0x30 [ 1108.930000] [0011a90a] ip_queue_xmit+0x198/0x426 [ 1108.930000] [0012bcc8] tcp_transmit_skb+0x3f0/0x76c [ 1108.930000] [0012cfda] tcp_write_xmit+0x178/0x868 [ 1108.930000] [0012d6f8] __tcp_push_pending_frames+0x2e/0x9a [ 1108.930000] [001222be] tcp_sendmsg+0x82e/0x98c [ 1108.930000] [0013d9c0] inet_sendmsg+0x32/0x54 [ 1108.930000] [000ec25e] sock_aio_write+0xc8/0x138 [ 1108.930000] [00043e7e] do_sync_write+0x9e/0xfe [ 1108.930000] [00043f56] vfs_write+0x78/0x84 [ 1108.930000] [0004446c] sys_write+0x40/0x7a [ 1108.930000] [00003244] system_call+0x84/0xc2 [ 1108.930000]seems like while i transmit a packet,
dm9000_interrupttry to acquire the spinlock owned from the same task.Compiling the kernel i am getting:
CCkernel/irq/handle.okernel/irq/handle.c:432:3: warning: #warning__do_IRQis deprecated. Please convert to proper flow handlersCould the usage of
__do_IRQsuper-handler be a cause of the issue ?many thanks,
angeloQuoted 178 lines · Geert Uytterhoeven
Quoted 7 lines · Baruch Siach
Hi Angelo,
Quoted 2 lines · Angelo Dureghello
just FYI, i tested kernel 2.6.36.2, unfortunately the issue is still there, below the call stack trace.
Help from the m68k experts seems to be needed. Adding the relevant list to Cc.
This is uClinux? Added Cc...
Quoted 166 lines
Quoted 152 lines
[ 4.620000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 39.390000] BUG: spinlock recursion on CPU#0, httpd/29 [ 39.390000] lock: 00189c44, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 39.390000] Stack from 00d6a990: [ 39.390000] 00d6a9bc 000a9710 0017cac7 00189c44 dead4ead 00de48f4 0000001d 00000000 [ 39.390000] 00189c44 0002a646 00145f70 00d6a9f0 000a98e2 00189c44 0017cb2d 00189c44 [ 39.390000] 00d6aad8 0000001f 00145f5c 001523f6 00189c08 0002a646 00145f70 0002bc52 [ 39.390000] 00d6a9fc 00145f7e 00189c44 00d6aa28 0002a75e 00189c44 0000001f 00d6aad8 [ 39.390000] 0000001f 00145f5c 00189c08 0002a646 00145f70 0002bc52 00d6aa3c 00000bb6 [ 39.390000] 0000001f 00189c44 00cfc780 00d6aa84 0000337a 0000001f 00d6aa4c 00000001 [ 39.390000] Call Trace: [ 39.390000] [000a9710] spin_bug+0x86/0x11a [ 39.390000] [000a98e2] do_raw_spin_lock+0x58/0x120 [ 39.390000] [00145f7e] _raw_spin_lock+0xe/0x14 [ 39.390000] [0002a75e] __do_IRQ+0x2c/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [0002a82e] __do_IRQ+0xfc/0x108 [ 39.390000] [00000bb6] do_IRQ+0x48/0x62 [ 39.390000] [0000337a] inthandler+0x6a/0x74 [ 39.390000] [000ef0ce] skb_release_all+0x10/0x20 [ 39.390000] [000ee6bc] __kfree_skb+0x10/0x92 [ 39.390000] [000ee75e] consume_skb+0x20/0x34 [ 39.390000] [000e004e] dm9000_start_xmit+0xdc/0xec [ 39.390000] [000f67a2] dev_hard_start_xmit+0x146/0x472 [ 39.390000] [00106506] sch_direct_xmit+0xc0/0x1bc [ 39.390000] [000f9914] dev_queue_xmit+0x160/0x3e4 [ 39.390000] [00113b3e] ip_finish_output+0xee/0x318 [ 39.390000] [001142b4] ip_output+0x7c/0x88 [ 39.390000] [00113dc6] ip_local_out+0x26/0x30 [ 39.390000] [00114d9a] ip_queue_xmit+0x152/0x374 [ 39.390000] [00125c8c] tcp_transmit_skb+0x3f0/0x732 [ 39.390000] [00126f26] tcp_write_xmit+0x178/0x868 [ 39.390000] [00127644] __tcp_push_pending_frames+0x2e/0x9a [ 39.390000] [0011c3d6] tcp_sendmsg+0x82e/0x98c [ 39.390000] [00137544] inet_sendmsg+0x32/0x54 [ 39.390000] [000e79a6] sock_aio_write+0xc8/0x138 [ 39.390000] [00042590] do_sync_write+0x9e/0xfe [ 39.390000] [00042668] vfs_write+0x78/0x84 [ 39.390000] [00042a92] sys_write+0x40/0x7a [ 39.390000] [00003224] system_call+0x84/0xc2 [ 39.390000]dm9000e is as default not visible/selectable in menuconfig for Coldfire architectures, so this probably cannot be considered as a kernel bug.
I going forward in investigations, every help is appreciated,
regards,
angeloQuoted 90 lines · Baruch Siach
Hi Angelo,
Quoted 3 lines · Angelo Dureghello
sorry to contact you directly but i couldn't get any help from the kernel.org mailing list, since i am not a developer my mails are generally skipped.
The best way to get the contact info for a piece of kernel code, is using the
get_maintainer.pl script. Running 'scripts/get_maintainer.pl-fdrivers/net/dm9000.c' gives the following output:[email protected]
[email protected]I added both to Cc.
Quoted 4 lines
I am very near to have a custom board working with MCF5307 cpu and dm9000.
I am using kernel 2.6.36-rc3 with your last patch about spinlock-recursion already included.You should try to update to the latest .36 kernel, which is currently
2.6.36.2. The problem that you experience might be unrelated to the dm9000
driver (or to networking at all), so it might have been fixed in this version.Quoted 3 lines
I have "ping" and "telnet" to the embedded board fully working. If i try to get a sample web page with some images from the board httpd with a browser, in 80% of cases i get a trap/oops:
Try to enable KALLSYMS in your kernel .config to make your stack trace more
meaningful. This is under 'General setup -> Configure standard kernel features
(for small systems) -> Load all symbols for debugging/ksymoops'.I hope this helps.
baruch
Quoted 50 lines
[ 4.590000] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [ 67.630000] BUG: spinlock recursion on CPU#0, httpd/29 [ 67.630000] lock: 00c42c06, .magic: dead4ead, .owner: httpd/29, .owner_cpu: 0 [ 67.630000] Stack from 00d7b914: [ 67.630000] 00d7b940 000a8cf0 0015f693 00c42c06 dead4ead 00dec1d4 0000001d 00000000 [ 67.630000] 00c42c06 00006188 00c42800 00d7b974 000a8ec2 00c42c06 0015f6f9 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] Call Trace: [ 67.630000] [000a8cf0] [000a8ec2] [0014701e] [000df21c] [00029d3a] [ 67.630000] [00029e84] [00000bb6] [0000336e] [000df162] [000effd6] [ 67.630000] [00100482] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [ 67.630000] [0010dfb2] [0010ef80] [0011fed6] [00121170] [0012188e] [ 67.630000] [0011ecc6] [001249fe] [000e4084] [0011621c] [00131a44] [ 67.630000] [000e11ee] [00041944] [00041a1c] [00041e46] [00003218] [ 67.630000] BUG: spinlock lockup on CPU#0, httpd/29, 00c42c06 [ 67.630000] Stack from 00d7b934: [ 67.630000] 00d7b974 000a8f66 0015f703 00000000 00dec1d4 0000001d 00c42c06 00002704 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 00c42b60 00006188 00c42800 0002b312 [ 67.630000] 00d7b984 0014701e 00c42c06 00000000 00d7b9c4 000df21c 00c42c06 00000000 [ 67.630000] 00000000 0000001f 00146fa4 00152f0c 000005ea 00cfc640 00006188 000096e8 [ 67.630000] 0002b312 00146fa4 00c42b60 00002704 00d7b9ec 00029d3a 0000001f 00c42800 [ 67.630000] 0016c1b4 00cfc640 0000001f 0016c178 00029d10 00146fb8 00d7ba20 00029e84 [ 67.630000] Call Trace: [ 67.630000] [000a8f66] [0014701e] [000df21c] [00029d3a] [00029e84] [ 67.630000] [00000bb6] [0000336e] [000df162] [000effd6] [00100482] [ 67.630000] [000f312e] [000f9ebc] [0010dd2a] [0010e4a0] [0010dfb2] [ 67.630000] [0010ef80] [0011fed6] [00121170] [0012188e] [0011ecc6] [ 67.630000] [001249fe] [000e4084] [0011621c] [00131a44] [000e11ee] [ 67.630000] [00041944] [00041a1c] [00041e46] [00003218]As i said, i was hoping in your patch but i sadly discovered it is already included in this kernel version.
Hope you can give me some help or can forward me to an appropriate mailing list.Signature · 12 lines
~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/_______________________________________________
uClinux-dev mailing list [email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected] To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Hi Angelo,
Quoted 7 lines · Angelo Dureghello
Hi Greg and All,
infinite thanks, i solved finally my issue and the board is fully working.I used IRQ7 line, casually, and unfortunately it was wrong. IRQ7 is a special autovectored interrupt, in particular, it is an EDGE interrupt, and not a LEVEL interrupt like IRQ1 to 6.
Quoted 7 lines
I used IRQ1 now, a normal level interrupt, and everything works perfect.
So i have dm9000 and MCF5307 (big-endian cpu) fully working with 32 bit bus straight wired D0:31 to the dm9000, and would like to share my patch to
dm9000.c, so maybe in next kernel versions dm9000 maybe could be enabled as default. Let me know eventually the procedure for this.
Just send the patch to the netdev mailing list. For additional instructions see Documentation/SubmitChecklist and Documentation/SubmittingPatches. Once you submitted you patch you can track the status of your patch at
http://patchwork.ozlabs.org/project/netdev/list/.
baruch
Signature · 3 lines
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [email protected] - tel: +972.2.679.5364, http://www.tkos.co.il -