On Fri, 2005-08-05 at 07:36 -0700, David S. Miller wrote: > From: Steven Rostedt <[EMAIL PROTECTED]> > Date: Fri, 05 Aug 2005 10:27:06 -0400 > > > Darn it, since this should really be reported. Yes, the core netpoll > > should bail out, but it is also a problem with the driver and should be > > fixed. > > I don't get how you can even remotely claim this to > be a problem with the driver. > > If there is no cable plugged in, the link never comes > up, and that is a completely normal thing. The netpoll > code should simply not try forever to wait for the link > to go up.
You're right with that case. The problem with the driver is that it doesn't clean up the transmits if it just happened to overflow the transmit buffer and shut down the queue. The netpoll should at least see that the queue can be brought up again. That's what I have a problem with. In other words, I see two bugs: 1. The bug with the netpoll. It locks up if the driver's queue is down and never comes up. Which is fixed with Andi's patch. 2. The bug with the driver. Its netpoll doesn't detect that the queue can come back up again. With the timeout on netpoll this may no longer be a bug, since it should clean itself up after netpoll times out and turns interrupts back on. But if a timeout is avoidable by netpoll being a little smarter, then I believe that it should be fixed. Now do you understand where I'm coming from? -- Steve - 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
