Rune Torgersen wrote:
Scott Wood wrote:
Rune Torgersen wrote:
I hit the following WARN_ON when using mii-tools agains a ethernet
interface using a bit-banged mii interface
It looks like the kernel thinks it's in an interrupt, even though it
clearly isn't from the backtrace. Presumably, something
slept from an
interrupt handler; try turning on sleep-in-spinlock debugging.
I turned on sleep-in-spinlock and it did not reveal anything. I'm trying
some other debug options.
The root cause was probably something other than the phy code.
I'm not so sure, because it only happens when I run mii-tool agains the
interface useing the bit-banged driver, and then only the first time.
OK, it seems I should have checked 2.6.24 instead of head-of-tree;
softirq.c:139 is a different assertion than I thought. It's not
in_irq(), but irqs_disabled(). fs_ioctl() is disabling interrupts, and
spin_unlock_bh() doesn't like that. The current use of mutexes likes it
even less. The locking should be moved inside the phy bus
implementation, if it's needed at all.
It only happens once because it's a WARN_ON_ONCE(). :-)
-Scott
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
