cvs commit: src/sys/dev/re if_re.c
sobomax at portaone.com
Thu Aug 18 19:58:39 GMT 2005
John Baldwin wrote:
>>Well, see kern/85005. IMO some generic approach should be worked out and
>>implemented since I think many other network drivers may be affected by
>>the same problem.
> I've still yet to see what the real panic is. For one thing, if the foo_stop
> method does its jobs, the ethernet hardware shouldn't be generating
> interrupts. The stop method should be shutting the card down (i.e. turning
> off the receiver and transmitter for example). Is your ethernet driver
> sharing an interrupt with another device and the other device is
Yes, this is the case here. It shares interrupt with IDE controller.
Panic happens in the re_rxeof() when the driver tries to dereference
sc->rl_ldata.rl_rx_mbuf[i], which has already been deallocated in the
> interrupting? In that case, the ethernet driver would have the same panic if
> you did an 'ifconfig foo0 down' and then the other device interrupted. So, I
No, I don't think it would since 'ifconfig foo0 down' resets IFF_UPP.
> think clearing IFF_UPP in foo_shutdown() is wrong. foo_stop() should really
> be sufficient, and foo_intr() should be able to handle a spurious interrupt
> while the interface is stopped without panicing since it already needs to do
> so to handle the shared interrupt case.
Apparently it doesn't handle it, which has been probably masked by the
IFF_UPP check in the re_intr(), so that this problem only happened at
shutdown, when IFF_UPP isn't cleared after re_stop().
More information about the cvs-all