e1000: ethtool -p + cable pull = system wedges hard

e1000: ethtool -p + cable pull = system wedges hard

[Jay Vosburgh]

	Running both 2.6.17.6 plus the e1000 7.2.7 from sourceforge, or
the e1000 in netdev-2.6#upstream (7.1.9-k4).

	Starting up "ethtool -p ethX" then unplugging the cable
connected to the identified port is causing my system to completely
freeze; even sysrq is unresponsive.  I'm running on a 2-way x86 box,
with an 82545GM.

	Is this by any chance a known problem?

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

Re: e1000: ethtool -p + cable pull = system wedges hard

[Auke Kok]

Jay Vosburgh wrote:
> 	Running both 2.6.17.6 plus the e1000 7.2.7 from sourceforge, or
> the e1000 in netdev-2.6#upstream (7.1.9-k4).
> 
> 	Starting up "ethtool -p ethX" then unplugging the cable
> connected to the identified port is causing my system to completely
> freeze; even sysrq is unresponsive.  I'm running on a 2-way x86 box,
> with an 82545GM.
> 
> 	Is this by any chance a known problem?

not at all.

Can you include the output of `lspci -vv` and `ethtool -e ethX` ? We'll have to 
  go try to reproduce this.

It is certainly not a good thing that it hangs when you try to identify the 
port and unplug the cable, that should certainly work :)

Cheers,

Auke

Re: [E1000-devel] e1000: ethtool -p + cable pull = system wedges hard

[Auke Kok]

Auke Kok wrote:
> Jay Vosburgh wrote:
>> 	Running both 2.6.17.6 plus the e1000 7.2.7 from sourceforge, or
>> the e1000 in netdev-2.6#upstream (7.1.9-k4).
>>
>> 	Starting up "ethtool -p ethX" then unplugging the cable
>> connected to the identified port is causing my system to completely
>> freeze; even sysrq is unresponsive.  I'm running on a 2-way x86 box,
>> with an 82545GM.
>>
>> 	Is this by any chance a known problem?
> 
> not at all.

One of my brain halves (the third one ;)) poked me and told me that it *is* a 
known issue. Not good. Apparently as early as kernel 2.5.50 a change was 
introduced that causes this. I am unsure what exactly caused it and I assume it 
is generic (other nic's might also suffer). The issue is documented in our 
standalone driver documentation. Not sure what to do with this.

Auke

Re: e1000: ethtool -p + cable pull = system wedges hard

[Jay Vosburgh]

Auke Kok <auke-jan.h.kok@intel.com> wrote:

>Auke Kok wrote:
>> Jay Vosburgh wrote:
>>> 	Running both 2.6.17.6 plus the e1000 7.2.7 from sourceforge, or
>>> the e1000 in netdev-2.6#upstream (7.1.9-k4).
>>>
>>> 	Starting up "ethtool -p ethX" then unplugging the cable
>>> connected to the identified port is causing my system to completely
>>> freeze; even sysrq is unresponsive.  I'm running on a 2-way x86 box,
>>> with an 82545GM.
>>>
>>> 	Is this by any chance a known problem?
>> not at all.
>
>One of my brain halves (the third one ;)) poked me and told me that it
>*is* a known issue. Not good. Apparently as early as kernel 2.5.50 a
>change was introduced that causes this. I am unsure what exactly caused it
>and I assume it is generic (other nic's might also suffer). The issue is
>documented in our standalone driver documentation. Not sure what to do
>with this.

	It appears to not be generic.  The same recipe on tg3 and e100
devices does not mete out the same frontier justice as e1000.  I made no
changes to the system (same one described above), tried it against
2.6.17.6 with whatever versions of tg3 and e100 it comes with.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

RE: [E1000-devel] e1000: ethtool -p + cable pull = system wedges hard

[Brandeburg, Jesse]

Kok, Auke-jan H wrote:
> Auke Kok wrote:
>> Jay Vosburgh wrote:
>>> 	Running both 2.6.17.6 plus the e1000 7.2.7 from sourceforge, or
>>> the e1000 in netdev-2.6#upstream (7.1.9-k4).
>>> 
>>> 	Starting up "ethtool -p ethX" then unplugging the cable
>>> connected to the identified port is causing my system to completely
>>> freeze; even sysrq is unresponsive.  I'm running on a 2-way x86
>>> box, with an 82545GM. 
>>> 
>>> 	Is this by any chance a known problem?
>> 
>> not at all.
> 
> One of my brain halves (the third one ;)) poked me and told me that
> it *is* a known issue. Not good. Apparently as early as kernel 2.5.50
> a change was introduced that causes this. I am unsure what exactly
> caused it and I assume it is generic (other nic's might also suffer).
> The issue is documented in our standalone driver documentation. Not
> sure what to do with this. 

Has something to do with the RTNL lock being held and link notification,
as I remember.
We noticed it to be a global problem, happens with e100 too.

http://www.mail-archive.com/netdev@vger.kernel.org/msg01654.html

Jesse

Re: [E1000-devel] e1000: ethtool -p + cable pull = system wedges hard

[Jay Vosburgh]

Brandeburg, Jesse <jesse.brandeburg@intel.com> wrote:

>Kok, Auke-jan H wrote:
>> Auke Kok wrote:
>>> Jay Vosburgh wrote:
>>>> 	Running both 2.6.17.6 plus the e1000 7.2.7 from sourceforge, or
>>>> the e1000 in netdev-2.6#upstream (7.1.9-k4).
>>>> 
>>>> 	Starting up "ethtool -p ethX" then unplugging the cable
>>>> connected to the identified port is causing my system to completely
>>>> freeze; even sysrq is unresponsive.  I'm running on a 2-way x86
>>>> box, with an 82545GM. 
[...]
>Has something to do with the RTNL lock being held and link notification,
>as I remember.
>We noticed it to be a global problem, happens with e100 too.
>
>http://www.mail-archive.com/netdev@vger.kernel.org/msg01654.html

	Well, I thought maybe I'd messed it up when I tested the other
cards, but I just went and tried it again.  Only the e1000 wedges the
system if I pull the cable with ethtool -p running.  The e100 and tg3
don't lock up.  Pulling the cable ends the ethtool for tg3, but for e100
the blinky blinky keeps going even after the cable is back in.

	Even so, as you mention, the operation is holding the RTNL, so
anything else that wants it has to wait.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com