[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#677638: laptop-mode-tools: Breaks wired network when running on battery



Added Ben and the Debian Kernel Team


On Saturday 16 June 2012 07:29 AM, Guillem Jover wrote:
>> 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.

Since this happens with 3.2 also, I have pulled in the kernel team.
Perhaps they have some information.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: