[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 : [email protected]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
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
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
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 : [email protected]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
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
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 : [email protected]
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
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
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
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