e1000/ICH8LAN weirdness - no ethtool link until initially forced up

e1000/ICH8LAN weirdness - no ethtool link until initially forced up

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]

[Please CC me on responses].

A spot of weirdness I ran into on my e1000 card.
It's the 82566DC model [8086:104b] (rev 02) x1 PCIe.

After modprobe e1000, ethtool reports that there is no link, despite the
correct link lights on the port. This breaks booting during a boot process that
checks for actual link status before using a device.

modprobe e1000:
> Intel(R) PRO/1000 Network Driver - version 7.2.9-k4-NAPI
> Copyright (c) 1999-2006 Intel Corporation.
> ACPI: PCI Interrupt 0000:00:19.0[A] -> GSI 20 (level, low) -> IRQ 20
> PCI: Setting latency timer of device 0000:00:19.0 to 64
> e1000: 0000:00:19.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:76:a3:6c:4d
> e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
> ADDRCONF(NETDEV_UP): eth1: link is not ready
> ADDRCONF(NETDEV_UP): eth1: link is not ready

Now I force the link up with ifconfig:
> e1000: eth1: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex
> ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

This behavior differs from every other network card, and is also present in the
7.3* version of the driver from sourceforge.

I think the e1000 should try to raise the link during the probe, so that it
works properly, without having to set ifconfig ethX up first.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: e1000/ICH8LAN weirdness - no ethtool link until initially forced up

[Pavel Machek]

Hi!

> [Please CC me on responses].
> 
> A spot of weirdness I ran into on my e1000 card.
> It's the 82566DC model [8086:104b] (rev 02) x1 PCIe.
> 
> After modprobe e1000, ethtool reports that there is no link, despite the
> correct link lights on the port. This breaks booting during a boot process that
> checks for actual link status before using a device.
...
> This behavior differs from every other network card, and is also present in the
> 7.3* version of the driver from sourceforge.
> 
> I think the e1000 should try to raise the link during the probe, so that it
> works properly, without having to set ifconfig ethX up first.

I think you should cc e1000 maintainers, and perhaps provide a patch....

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: e1000/ICH8LAN weirdness - no ethtool link until initially forced up

[Auke Kok]

Pavel Machek wrote:
> Hi!
> 
>> [Please CC me on responses].
>>
>> A spot of weirdness I ran into on my e1000 card.
>> It's the 82566DC model [8086:104b] (rev 02) x1 PCIe.
>>
>> After modprobe e1000, ethtool reports that there is no link, despite the
>> correct link lights on the port. This breaks booting during a boot process that
>> checks for actual link status before using a device.
> ...
>> This behavior differs from every other network card, and is also present in the
>> 7.3* version of the driver from sourceforge.
>>
>> I think the e1000 should try to raise the link during the probe, so that it
>> works properly, without having to set ifconfig ethX up first.
> 
> I think you should cc e1000 maintainers, and perhaps provide a patch....

I've read it and not come up with an answer due to some other issues at hand. E1000 
hardware works differently and this has been asked before, but the cards itself are in 
low power state when down. Changing this to bring up the link would make the card start 
to consume lots more power, which would automatically suck enormously for anyone using a 
laptop.

Unfortunately, we have no way to distinguish directly between mobile and non-mobile 
adapters, since they are usually the same.

Your application should really `ifconfig up` the device before checking for link.

Cheers,

Auke

Re: e1000/ICH8LAN weirdness - no ethtool link until initially forced up

[Theodore Tso]

On Tue, Nov 07, 2006 at 07:51:22AM -0800, Auke Kok wrote:
> 
> Your application should really `ifconfig up` the device before checking for 
> link.

And for those of us with laptops, application authors should do an
"ifconfig down" the device if it doesn't find a link.  Right now
thanks to such applications on my desktop, I boot with e1000
blacklisted so I can run in low-power mode when on a laptop.

BTW, it would be nice if the e1000 driver could be more safely
unloaded when it is built as a module.  Yeah, the right answer is that
the gnome desktop is made less power hungry, and there are other
things I can do such as kill -STOP various bits of the gnome desktop
when I am running in battery mode, but it would be nice if I could
forcibly down the e1000 driver, and right not simply keeping the
module unloaded is the most reliably way of doing it in the face of
desktop applets that don't care about how much power they are sucking
down....

						- Ted

Re: e1000/ICH8LAN weirdness - no ethtool link until initially forced up

[Auke Kok]

Theodore Tso wrote:
> On Tue, Nov 07, 2006 at 07:51:22AM -0800, Auke Kok wrote:
>> Your application should really `ifconfig up` the device before checking for 
>> link.
> 
> And for those of us with laptops, application authors should do an
> "ifconfig down" the device if it doesn't find a link.  Right now
> thanks to such applications on my desktop, I boot with e1000
> blacklisted so I can run in low-power mode when on a laptop.
> 
> BTW, it would be nice if the e1000 driver could be more safely
> unloaded when it is built as a module.

I'm not aware of unload issues, what is the problem that you have?

Auke

Re: e1000/ICH8LAN weirdness - no ethtool link until initially forced up

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

On Tue, Nov 07, 2006 at 07:51:22AM -0800, Auke Kok wrote:
> >I think you should cc e1000 maintainers, and perhaps provide a patch....
> I've read it and not come up with an answer due to some other issues at 
> hand. E1000 hardware works differently and this has been asked before, but 
> the cards itself are in low power state when down. Changing this to bring 
> up the link would make the card start to consume lots more power, which 
> would automatically suck enormously for anyone using a laptop.
> 
> Unfortunately, we have no way to distinguish directly between mobile and 
> non-mobile adapters, since they are usually the same.
> 
> Your application should really `ifconfig up` the device before checking for 
> link.
Actually pushing the link up in userspace doesn't specifically help my
applications, as I care about actual link status (as reported by
ethtool).

Is there no way to keep the link status correct (within 0.5 seconds),
without bringing the card to full power? Maybe a timer that fires a
proper check (with the power implications).

Would a patch that adds a modparam (not enabled by default) running the
behavior I'm after, be acceptable, so the e1000 driver can act identical
to all of the other drivers?

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: e1000/ICH8LAN weirdness - no ethtool link until initially forced up

[Auke Kok]

Robin H. Johnson wrote:
> On Tue, Nov 07, 2006 at 07:51:22AM -0800, Auke Kok wrote:
>>> I think you should cc e1000 maintainers, and perhaps provide a patch....
>> I've read it and not come up with an answer due to some other issues at 
>> hand. E1000 hardware works differently and this has been asked before, but 
>> the cards itself are in low power state when down. Changing this to bring 
>> up the link would make the card start to consume lots more power, which 
>> would automatically suck enormously for anyone using a laptop.
>>
>> Unfortunately, we have no way to distinguish directly between mobile and 
>> non-mobile adapters, since they are usually the same.
>>
>> Your application should really `ifconfig up` the device before checking for 
>> link.
> Actually pushing the link up in userspace doesn't specifically help my
> applications, as I care about actual link status (as reported by
> ethtool).

technically the link is already up if the cable is inserted and connected. doing an 
`ifconfig up` doesn't change that. If the link is down then this powers up the PHY so we 
can read the link status.

> Is there no way to keep the link status correct (within 0.5 seconds),
> without bringing the card to full power? Maybe a timer that fires a
> proper check (with the power implications).

no, not that I know of.

> Would a patch that adds a modparam (not enabled by default) running the
> behavior I'm after, be acceptable, so the e1000 driver can act identical
> to all of the other drivers?

I bet that all drivers work fine if you `ifconfig up` them. What happens if other NIC 
drivers implement similar powersaving methods and start working the same?

Cheers,

Auke

Re: e1000/ICH8LAN weirdness - no ethtool link until initially forced up

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

On Tue, Nov 07, 2006 at 02:32:32PM -0800, Auke Kok wrote:
> >Would a patch that adds a modparam (not enabled by default) running the
> >behavior I'm after, be acceptable, so the e1000 driver can act identical
> >to all of the other drivers?
> I bet that all drivers work fine if you `ifconfig up` them. What happens if 
> other NIC drivers implement similar powersaving methods and start working 
> the same?
In that, case the following (puesdo-code) would need to be added to
ethtool.

(before reading link status)
1. $oldstate = GET(current software state of UP/DOWN from ifconfig)
2. if($oldstate != UP) then SET(software state to UP)
3. if($oldstate != UP) then (some delay might be needed)
4. read PHY status
5. if($oldstate != UP) then SET(software state to $oldstate)

Thus ethtool should always report the correct PHY state.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: e1000/ICH8LAN weirdness - no ethtool link until initially forced up

[Pavel Machek]

Hi!

> >>This behavior differs from every other network card, and is also present 
> >>in the
> >>7.3* version of the driver from sourceforge.
> >>
> >>I think the e1000 should try to raise the link during the probe, so that 
> >>it
> >>works properly, without having to set ifconfig ethX up first.
> >
> >I think you should cc e1000 maintainers, and perhaps provide a patch....
> 
> I've read it and not come up with an answer due to some other issues at 
> hand. E1000 hardware works differently and this has been asked before, but 
> the cards itself are in low power state when down. Changing this to bring 
> up the link would make the card start to consume lots more power, which 
> would automatically suck enormously for anyone using a laptop.

Well, maybe E1000 should behave as the other cards behave, and
different solution needs to be found for power saving? ifconfig eth0
suspend?

									Pavel
 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

General network driver suspend/resume (was e1000 carrier related)

[Stephen Hemminger]

On Wed, 8 Nov 2006 13:04:07 +0100
Pavel Machek <pavel@ucw.cz> wrote:

> Hi!
> 
> > >>This behavior differs from every other network card, and is also present 
> > >>in the
> > >>7.3* version of the driver from sourceforge.
> > >>
> > >>I think the e1000 should try to raise the link during the probe, so that 
> > >>it
> > >>works properly, without having to set ifconfig ethX up first.
> > >
> > >I think you should cc e1000 maintainers, and perhaps provide a patch....
> > 
> > I've read it and not come up with an answer due to some other issues at 
> > hand. E1000 hardware works differently and this has been asked before, but 
> > the cards itself are in low power state when down. Changing this to bring 
> > up the link would make the card start to consume lots more power, which 
> > would automatically suck enormously for anyone using a laptop.
> 
> Well, maybe E1000 should behave as the other cards behave, and
> different solution needs to be found for power saving? ifconfig eth0
> suspend?
> 
> 									Pavel
>  
> 

The standard which all network drivers should use is:

module insertion:
	start in initial powerdown state

open:
	power up, bring up link

stop:
	bring down link
	return to powerdown state unless WOL is set.
	if doing WOL go to lowest power sensing state

suspend:
	same as stop

resume:
	same as open

module removal:
	stop already called so device should be in power down state.


Since suspend is basically same as stop, and resume is open
I am going to investigate doing suspend/resume in the network device layer
(unless subclassed by driver), so we can rip out the suspend/resume hook
from many network drivers. There will still be boards like sky2
that need own suspend/resume to deal with dual port etc.

-- 
Stephen Hemminger <shemminger@osdl.org>

Re: General network driver suspend/resume (was e1000 carrier related)

[Auke Kok]

Stephen Hemminger wrote:
> On Wed, 8 Nov 2006 13:04:07 +0100
> Pavel Machek <pavel@ucw.cz> wrote:
> 
>> Hi!
>>
>>>>> This behavior differs from every other network card, and is also present 
>>>>> in the
>>>>> 7.3* version of the driver from sourceforge.
>>>>>
>>>>> I think the e1000 should try to raise the link during the probe, so that 
>>>>> it
>>>>> works properly, without having to set ifconfig ethX up first.
>>>> I think you should cc e1000 maintainers, and perhaps provide a patch....
>>> I've read it and not come up with an answer due to some other issues at 
>>> hand. E1000 hardware works differently and this has been asked before, but 
>>> the cards itself are in low power state when down. Changing this to bring 
>>> up the link would make the card start to consume lots more power, which 
>>> would automatically suck enormously for anyone using a laptop.
>> Well, maybe E1000 should behave as the other cards behave, and
>> different solution needs to be found for power saving? ifconfig eth0
>> suspend?
>>
>> 									Pavel
>>  
>>
> 
> The standard which all network drivers should use is:
> 
> module insertion:
> 	start in initial powerdown state
> 
> open:
> 	power up, bring up link
> 
> stop:
> 	bring down link
> 	return to powerdown state unless WOL is set.
> 	if doing WOL go to lowest power sensing state
> 
> suspend:
> 	same as stop
> 
> resume:
> 	same as open
> 
> module removal:
> 	stop already called so device should be in power down state.
> 
> 
> Since suspend is basically same as stop, and resume is open
> I am going to investigate doing suspend/resume in the network device layer
> (unless subclassed by driver), so we can rip out the suspend/resume hook
> from many network drivers. There will still be boards like sky2
> that need own suspend/resume to deal with dual port etc.


beware that e1000 needs to save pci msi config space on top of the normal pci config 
space. Perhaps this needs to be fixed upstream in pci_save_state for msi devices, but 
the api for msi is not capable of detecting this atm.

Auke

Re: General network driver suspend/resume (was e1000 carrier related)

[Stephen Hemminger]

On Wed, 08 Nov 2006 13:10:50 -0800
Auke Kok <auke-jan.h.kok@intel.com> wrote:

> Stephen Hemminger wrote:
> > On Wed, 8 Nov 2006 13:04:07 +0100
> > Pavel Machek <pavel@ucw.cz> wrote:
> > 
> >> Hi!
> >>
> >>>>> This behavior differs from every other network card, and is also present 
> >>>>> in the
> >>>>> 7.3* version of the driver from sourceforge.
> >>>>>
> >>>>> I think the e1000 should try to raise the link during the probe, so that 
> >>>>> it
> >>>>> works properly, without having to set ifconfig ethX up first.
> >>>> I think you should cc e1000 maintainers, and perhaps provide a patch....
> >>> I've read it and not come up with an answer due to some other issues at 
> >>> hand. E1000 hardware works differently and this has been asked before, but 
> >>> the cards itself are in low power state when down. Changing this to bring 
> >>> up the link would make the card start to consume lots more power, which 
> >>> would automatically suck enormously for anyone using a laptop.
> >> Well, maybe E1000 should behave as the other cards behave, and
> >> different solution needs to be found for power saving? ifconfig eth0
> >> suspend?
> >>
> >> 									Pavel
> >>  
> >>
> > 
> > The standard which all network drivers should use is:
> > 
> > module insertion:
> > 	start in initial powerdown state
> > 
> > open:
> > 	power up, bring up link
> > 
> > stop:
> > 	bring down link
> > 	return to powerdown state unless WOL is set.
> > 	if doing WOL go to lowest power sensing state
> > 
> > suspend:
> > 	same as stop
> > 
> > resume:
> > 	same as open
> > 
> > module removal:
> > 	stop already called so device should be in power down state.
> > 
> > 
> > Since suspend is basically same as stop, and resume is open
> > I am going to investigate doing suspend/resume in the network device layer
> > (unless subclassed by driver), so we can rip out the suspend/resume hook
> > from many network drivers. There will still be boards like sky2
> > that need own suspend/resume to deal with dual port etc.
> 
> 
> beware that e1000 needs to save pci msi config space on top of the normal pci config 
> space. Perhaps this needs to be fixed upstream in pci_save_state for msi devices, but 
> the api for msi is not capable of detecting this atm.
> 

pci_config save needs to save more (including all the pci express stuff).
But until the mmconfig issues are fixed on x86_64 that will be impossible.
Maybe the last fix will solve the problem.


-- 
Stephen Hemminger <shemminger@osdl.org>