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 linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |