On Wed, 8 Nov 2006 13:04:07 +0100
Pavel Machek <[email protected]> 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 <[email protected]>
Stephen Hemminger wrote:
> On Wed, 8 Nov 2006 13:04:07 +0100
> Pavel Machek <[email protected]> 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
On Wed, 08 Nov 2006 13:10:50 -0800
Auke Kok <[email protected]> wrote:
> Stephen Hemminger wrote:
> > On Wed, 8 Nov 2006 13:04:07 +0100
> > Pavel Machek <[email protected]> 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 <[email protected]>