| To: | "Feldman, Scott" <scott.feldman@xxxxxxxxx> |
|---|---|
| Subject: | Re: 2.6.2 crash after network link failure |
| From: | Petr Vandrovec <vandrove@xxxxxxxxxx> |
| Date: | Tue, 10 Feb 2004 15:11:19 +0100 |
| Cc: | "David S. Miller" <davem@xxxxxxxxxx>, netdev@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx |
| In-reply-to: | <C6F5CF431189FA4CBAEC9E7DD5441E0102CBDE6C@orsmsx402.jf.intel.com> |
| References: | <C6F5CF431189FA4CBAEC9E7DD5441E0102CBDE6C@orsmsx402.jf.intel.com> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.5.5.1+cvs20040105i |
On Mon, Feb 09, 2004 at 03:37:48PM -0800, Feldman, Scott wrote:
> > I think what might be happening is that somehow the TX queue
> > is corrupted if
> > e100_config() runs (due to link UP state change) while there
> > are active normal SKB packets on the TX queue. Or perhaps
> > some TX queue handling locking issue.
> >
> > Scott, any ideas?
>
> e100 hardware will continue to process the hardware's Tx queue even
> after link is lost, and then cleanup (return skbs) on interrupt. I
> would expect e100 to be holding no Tx skbs when link returned.
>
> Petr, -mm kernel has an updated (and much simpler) e100 driver. Is this
> something you can try? The switch failure can be simulated by manually
> plugging the cable in/out.
Unfortunately it does not seem easily triggerable. I spent about one
hour plugging/unplugging cable while transmitting UDP packets as fast
as possible, sometime interleaved with 'mii-tool -r', and it refused
to crash...
Petr Vandrovec
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [NFS] [PATCH][RFC] use completions instead of sleep_on forrpciod, trond . myklebust |
|---|---|
| Next by Date: | [PATCH] pktgen unaligned access on IA-64, Robert Olsson |
| Previous by Thread: | RE: 2.6.2 crash after network link failure, Feldman, Scott |
| Next by Thread: | A small forcedeth driver issue, Kenneth Krekula |
| Indexes: | [Date] [Thread] [Top] [All Lists] |