Messages in this thread | | | Subject | Re: [PATCH] netpoll can lock up on low memory. | From | Steven Rostedt <> | Date | Fri, 05 Aug 2005 20:23:55 -0400 |
| |
On Fri, 2005-08-05 at 14:28 -0700, Matt Mackall wrote: > > Netpoll generally must assume it won't get a second chance, as it's > being called by things like oops() and panic() and used by things like > kgdb. If netpoll fails, the box is dead anyway. >
But it is also being called by every printk in the kernel. What happens when the printk that causes this lock up is not a panic but just some info print. One would use netconsole when they turn on more verbose printing, to keep the output fast, right? So if the system gets a little memory tight, but not to the point of failing, this will cause a lock up and no one would know why.
If you need to really get the data out, then the design should be changed. Have some return value showing the failure, check for oops_in_progress or whatever, and try again after turning interrupts back on, and getting to a point where the system can free up memory (write to swap, etc). Just a busy loop without ever getting a skb is just bad.
> > > The netpoll philosophy is to assume that its traffic is an absolute > > > priority - it is better to potentially hang trying to deliver a panic > > > message than to give up and crash silently. > > > > So even a long timeout would not do? So you don't even get a message to > > the console? > > In general, there's no way to measure time here. And if we're > using netconsole, what makes you think there's any other console?
Why assume that there isn't another console? The screen may be used with netconsole, you just lose whatever has been scrolled too far.
> > > > > Also, as Andi told me, the printk here would probably not show up > > > > anyway if this happens with netconsole. > > > > > > That's fine. But in fact, it does show up occassionally - I've seen > > > it. > > > > Then maybe what Andi told me is not true ;-) > > > > Oh, and did your machine crash when you saw it? Have you seen it with > > the e1000 driver? > > No and no. Most of my own testing is done with tg3. >
If you saw the message and the system didn't crash, then that's proof that if the driver is not working properly, you would have lock up the system, and the system was _not_ in a state that it _had_ to get the message out.
-- Steve
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |