Hi Angelo,


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:

netdev@vger.kernel.org
linux-kernel@vger.kernel.org


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 

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.


-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--

[ message continues ]

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






--

[ message continues ]

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] ...
[ message continues ]

Hi Angelo,


Help from the m68k experts seems to be needed. Adding the relevant list to Cc.


-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--

[ message continues ]

-- 
Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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 Torvalds
--

[ message continues ]

Hi 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
[ ...
[ message continues ]

Does it still occur if you remove the debug line below?
---
 drivers/net/dm9000.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index 2d4c4fc..c774430 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -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 */


--

[ message continues ]

Hi Angelo,


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 Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
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
--

[ message continues ]

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, ...
[ message continues ]

Hi Anelo,

On 30/12/10 19:59, Angelo Dureghello wrote:

Yes, IRQ7 is "special" on the 5307. It is non-maskable. So normal

Yes, I suggest you try using another IRQ line. Stay away from IRQ7
for any normal devices.

Regards


-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
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
--

[ message continues ]

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





--

[ message continues ]

Hi Angelo,


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

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--

[ message continues ]