Re: [PATCH 11/22] e1000: Fire a link even interrupt instead of a watchdog at init.

2006-12-11 Thread Shaw Vrana
On Fri, Dec 08, 2006 at 03:03:09PM -0800, Kok, Auke wrote: > > Instead of calling a watchdog event we let our interrupt handler > cascade a link event. This allows us to spot link up immediately > after _up() without racing against a new watchdog. > > Signed-off-by: Jesse Brandeburg <[EMAIL PROTE

Re: e100: inappropriate handling of shared interrupt ?

2006-12-01 Thread Shaw Vrana
Hi Auke, On Mon, Nov 27, 2006 at 11:18:13AM -0800, Auke Kok wrote: > >I'm seeing some odd behavior using the e100 driver for an intel ethernet > >controller 82557/8/9 (revv 10). It appears as if the e100 driver is > >handling interrupts generated by another device, though I am not certain > >of t

e100: inappropriate handling of shared interrupt ?

2006-11-27 Thread Shaw Vrana
Hello All, I'm seeing some odd behavior using the e100 driver for an intel ethernet controller 82557/8/9 (revv 10). It appears as if the e100 driver is handling interrupts generated by another device, though I am not certain of this.. Using some printks, I see some odd packets received that are

Re: watchdog timeout panic in e1000 driver

2006-10-30 Thread Shaw Vrana
On Mon, Oct 30, 2006 at 09:30:24AM -0800, Auke Kok wrote: > >Even if the total lock time can be reduced, it's possible that interrupt > >handler is executed while the interrupted code is still holding the > >semaphore. > >I think your method only decrease the frequency of this problem. > >Why does

Re: e1000_xmit_frame and e1000_down racing with next_to_use?

2006-09-06 Thread Shaw Vrana
tx_ring->tx_lock to avoid that? Hi Stephen, Yes, holding the adapter->tx_lock is all that is needed. e1000_irq_disable has been called prior to e1000_clean_tx_ring or the interrupt has never been enabled (e1000_open), so a simple spin_lock should suffice. I've included a patch against Garzi

Re: e1000_down and tx_timeout worker race cleaning the transmit buffers

2006-04-29 Thread Shaw Vrana
Hi Auke, On 4/26/06, Auke Kok <[EMAIL PROTECTED]> wrote: > I'm concerned about the addition of the netif_running check to > e1000_down. While something like this is needed, I'm not familiar > enough w/ the code to know if this is okay. > All explanations and comments are greatly appreciated. W

Re: e1000_down and tx_timeout worker race cleaning the transmit buffers

2006-04-20 Thread Shaw Vrana
On Thursday 20 April 2006 17:10, Michael Chan wrote: > In tg3_remove_one(), we call flush_scheduled_work() in case the > reset_task is still pending. Here, it is safe to call > flush_scheduled_work() because we're not holding the rtnl. Again, when > it runs, nothing bad will happen because it will