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.66] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[ 54.34] BUG: spinlock
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.66] eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
[ 54.34] BUG: spinlock
Hi Anelo,
On 30/12/10 19:59, Angelo Dureghello wrote:
[snip]
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
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,
On Wed, Dec 29, 2010 at 19:06, Baruch Siach bar...@tkos.co.il wrote:
Hi Angelo,
On Wed, Dec 29, 2010 at 02:13:22PM +0100, Angelo Dureghello wrote:
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
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
Hi Angelo,
On 30/12/10 06:57, Angelo Dureghello wrote:
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
