Hi! [ Ccing Lucas because I saw a related post which *might* be related, but it's not clear. I've not trimmed the mail for your convenience. <http://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg04477.html>]
On Sat, 2012-06-16 at 02:32:28 +0530, Ritesh Raj Sarraf wrote: > severity 677638 normal > tags 677638 +moreinfo > thanks > > Setting severity of normal because: > * You have an option to disable. That's right, but only as long as you know what needs disabling, it took me a while to spot what the culprit was, because the battery/ac stuff is a bit hairy, there's at least acpid, laptop-mode-tools, pm-utils, and the kernel messing with this stuff. Suddenly getting the network to stop working is pretty mysterious given all those layers, and as such (as said before) even if the real problem is with the driver or the kernel PM settings or whatever, if laptop-mode-tools triggers this (when it could avoid it), then that's a “problem” with it. > * This problem is not commonly reported. It could be that other poeple might not have been able to spot what triggered it, it's really not obvious. Checking google for similar errors I've got on my dmesg, I find quite some people reporting similar stuff on random forums and mailing lists. > * Not reproducible on my machine (with the same driver) Well, if it can affect other users then I'd say it justifies the severity. :) > On Friday 15 June 2012 09:27 PM, Guillem Jover wrote: > > Since some time now (I only sat down to track it down pretty recently, > > but this has going on for probably a year or more), laptop-mode-tools > > has broken the wired network (e1000e) whenever I unplug the laptop from > > the wall power. > > > > The culprit is BATT_THROTTLE_ETHERNET=1 in > > «/etc/laptop-mode/conf.d/ethernet.conf». > > > > This turns the working ethernet device from this state: > > > > ,--- > > # ethtool eth0 > > Settings for eth0: > > Supported ports: [ TP ] > > Supported link modes: 10baseT/Half 10ba > > 100baseT/Half 100baseT/Full > > 1000baseT/Full > > Supported pause frame use: No > > Supports auto-negotiation: Yes > > Advertised link modes: 10baseT/Half 10ba > > 100baseT/Half 100baseT/Full > > 1000baseT/Full > > Advertised pause frame use: No > > Advertised auto-negotiation: Yes > > Speed: 100Mb/s > > Duplex: Full > > Port: Twisted Pair > > PHYAD: 2 > > Transceiver: internal > > Auto-negotiation: on > > MDI-X: on > > Supports Wake-on: pumbg > > Wake-on: g > > Current message level: 0x00000001 (1) > > drv > > Link detected: yes > > `--- > > > > To this non-working state: > > > > ,--- > > # ethtool eth0 > > Settings for eth0: > > Supported ports: [ TP ] > > Supported link modes: 10baseT/Half 10ba > > 100baseT/Half 100baseT/Full > > 1000baseT/Full > > Supported pause frame use: No > > Supports auto-negotiation: Yes > > Advertised link modes: 10baseT/Half 10ba > > 100baseT/Half 100baseT/Full > > 1000baseT/Full > > Advertised pause frame use: No > > Advertised auto-negotiation: Yes > > Speed: Unknown! > > Duplex: Unknown! (255) > > Port: Twisted Pair > > PHYAD: 2 > > Transceiver: internal > > Auto-negotiation: on > > MDI-X: Unknown > > Supports Wake-on: pumbg > > Wake-on: d > > Current message level: 0x00000001 (1) > > drv > > Link detected: no > > `--- > > > > If I set BATT_THROTTLE_ETHERNET to 0, then everything works as before. > > > > I don't think this setting should be enabled by default if it might > > cause this type of breakage, even if it ends up being a driver > > problem. > > This is the first report on this behavior. > From your logs, it shows that when switched to battery, nothing is set > correct. Neither the speed, nor the Link. > > Could you please set DEBUG=1 in the ethernet module only, and then see > if it can provide more information on what is failing? > > e1000e must be a common driver supporting multiple Intel chipsets. I > have no problem setting the default to 0, but like I said, this is the > first time I've heard of this behavior. I've tracked it further down to «ethtool -s eth0 autoneg off», which totally messes up the network device. I've tested this with 3.2, 3.3 and 3.4 kernels, all are affected. I'll try to check later on with earlier kernels to see if something changes. It might be related to the PCIe controller, ACPI setup, the PM settings, or the driver itself, I've got some error messages on dmesg about the driver being unable to read from PHY registers and also about Hardware Errors, but then I've seen several instances of that on google, so I don't think it's really a hardware problem, as those have changed over time with different kernels. thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
