cvs commit: src/sys/dev/re if_re.c

[Maxim Sobolev]

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 
re_stop().

> 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().

-Maxim