On Tue, Sep 06, 2005 at 02:47:14PM -0700, David S. Miller wrote: > From: Eugene Surovegin <[EMAIL PROTECTED]> > Date: Tue, 6 Sep 2005 00:40:01 -0700 > > > According to Documentation/networking/netdevices.txt > > dev->hard_start_xmit must be called with interrupts *enabled*. > > > > Unfortunately, current netconsole code always calls netpoll with local > > interrupts disabled: > > > > write_msg (local_irq_save) > > netpoll_send_udp > > netpoll_send_skb > > np->dev->hard_start_xmit. > > > > I'm not sure this can cause any problems, but quick grep has showed > > that some drivers indeed rely on the documented behavior. > > > > Also, it'd be nice if netpoll author updated netdevices.txt with info > > about dev->poll_controller sync rules :) (in fact, I stumbled upon > > this inconsistency when I was trying to figure out locking for > > dev->poll_controller implementation in my driver). > > Yes, several drivers rely on interrupts being enabled, I learned this > the hard way in the past. Also, disabling interrupts during this > potentially expensive function call can kill your interrupt latency > sensitive devices (such as serial ports) and allow them to overflow.
We already have a similar latency problem but much worse with serial console. It does blocking polled I/O at serial rates, so printks have ~1ms latency _per character_ at 9600bps. Even at 115200bps, we're still looking at ~4ms to send half a line of text. > I don't immediately see how this can be fixed, because the console > code does really need to disable interrupts in order to not try > to recursively take it's locks. Unfortunately, netpoll fundamentally requires everything to work with interrupts off. This can't be changed. It could be called from the context of an oops, or worse, by the kgdb stub at a breakpoint. If drivers require interrupts enabled for hard_start_xmit, they simply can't work with netpoll. -- Mathematics is the supreme nostalgia of our time. - 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
