Hi!
The eepro100 interface in my Fujitsy/Siemens Lifebook S-4546
won't come up after a suspend, if I unload the module and load it again
it works fine...
"ioctl SIOCSIFFLAGS: No such device" is the error message.
This happend in 2.4.5 i think.
/Pawel
> eepro100 2.4.7-ac3 problems (apm related)
>
>
> Hi!
>
> The eepro100 interface in my Fujitsy/Siemens Lifebook S-4546
> won't come up after a suspend, if I unload the module and load it again
> it works fine...
> "ioctl SIOCSIFFLAGS: No such device" is the error message.
>
> This happend in 2.4.5 i think.
>
> /Pawel
>
same here with an eepro100 inside a IBM Thinkpad570. Happened with
2.4.6-ac2. Since then I apply the appended patch after installing "-ac"
stuff. This completely disables power state handling for the device. Not
very clean, but I do not care in this particular case. It probably shows
a more principal issue with the eepro100. Kai - did you look deeper into
the issue?
Martin
diff -rc2 eepro100.c eepro100.c-ac3-orig
*** eepro100.c Tue Jul 31 11:21:26 2001
--- eepro100.c-ac3-orig Tue Jul 31 11:20:56 2001
***************
*** 779,783 ****
/* Put chip into power state D2 until we open() it. */
! pci_set_power_state(pdev, 0); /* MKN */
pci_set_drvdata (pdev, dev);
--- 779,783 ----
/* Put chip into power state D2 until we open() it. */
! pci_set_power_state(pdev, 2);
pci_set_drvdata (pdev, dev);
***************
*** 1834,1838 ****
printk(KERN_DEBUG "%s: %d multicast blocks dropped.\n",
dev->name, i);
! pci_set_power_state(sp->pdev, 0); /* MKN */
MOD_DEC_USE_COUNT;
--- 1834,1838 ----
printk(KERN_DEBUG "%s: %d multicast blocks dropped.\n",
dev->name, i);
! pci_set_power_state(sp->pdev, 2);
MOD_DEC_USE_COUNT;
--
------------------------------------------------------------------
Martin Knoblauch | email: [email protected]
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759
On Tue, 31 Jul 2001, Martin Knoblauch wrote:
> > The eepro100 interface in my Fujitsy/Siemens Lifebook S-4546
> > won't come up after a suspend, if I unload the module and load it again
> > it works fine...
> > "ioctl SIOCSIFFLAGS: No such device" is the error message.
>
> same here with an eepro100 inside a IBM Thinkpad570. Happened with
> 2.4.6-ac2. Since then I apply the appended patch after installing "-ac"
> stuff. This completely disables power state handling for the device. Not
> very clean, but I do not care in this particular case. It probably shows
> a more principal issue with the eepro100. Kai - did you look deeper into
> the issue?
I didn't look to deep, since my eepro100 works fine here, so I can't
reproduce your problem.
However, I'm wondering if the problems you guys are having are really the
same. IIRC, Martin's eepro100 wouldn't ever come up from state D2 into
working state again until the next reboot, right?
Whereas Pawel's eepro100 can be revived by reloading the module, so there
seems to be a difference. For Pawel, can you supply lspci -vvxxx output
before and after the suspend. That should give some hints.
Martin, if you want to spend some work on your problem, you could try to
collect some more data an your problem, particularly what about using
another state (D1/D3) when the interface is down. D3 will probably mean
that you have to save/restore PCI config space, so it's a bit more
tedious. Also, is there anything which makes your card work again after it
was in state D2? Like suspend/resume, or putting it into D3 and back into
D0? Does a warm reboot suffice, or do you need to power cycle.
As it stands, I don't see an alternative to Martin's problem apart from
the patch he's using - well, that could be done a bit more nicely, like
having a config option for the sleep D state, which would increase chances
Alan would take it as an -ac patch.
--Kai
Kai Germaschewski wrote:
>
> On Tue, 31 Jul 2001, Martin Knoblauch wrote:
>
> > > The eepro100 interface in my Fujitsy/Siemens Lifebook S-4546
> > > won't come up after a suspend, if I unload the module and load it again
> > > it works fine...
> > > "ioctl SIOCSIFFLAGS: No such device" is the error message.
> >
> > same here with an eepro100 inside a IBM Thinkpad570. Happened with
> > 2.4.6-ac2. Since then I apply the appended patch after installing "-ac"
> > stuff. This completely disables power state handling for the device. Not
> > very clean, but I do not care in this particular case. It probably shows
> > a more principal issue with the eepro100. Kai - did you look deeper into
> > the issue?
>
> I didn't look to deep, since my eepro100 works fine here, so I can't
> reproduce your problem.
>
> However, I'm wondering if the problems you guys are having are really the
> same. IIRC, Martin's eepro100 wouldn't ever come up from state D2 into
> working state again until the next reboot, right?
>
You may be 101% right and the problems are not identical, but something
seems to be fishy around eepro100 in notebooks and powersaving. Just
curious - is your working eepro100 in a notebook or in a "traditional"
server/desktop?
> Whereas Pawel's eepro100 can be revived by reloading the module, so there
> seems to be a difference. For Pawel, can you supply lspci -vvxxx output
> before and after the suspend. That should give some hints.
>
> Martin, if you want to spend some work on your problem, you could try to
> collect some more data an your problem, particularly what about using
> another state (D1/D3) when the interface is down. D3 will probably mean
> that you have to save/restore PCI config space, so it's a bit more
> tedious. Also, is there anything which makes your card work again after it
> was in state D2? Like suspend/resume, or putting it into D3 and back into
> D0? Does a warm reboot suffice, or do you need to power cycle.
>
As I said before, whatever I can do... Care to tell me (offline) where
to put the save/restore stuff?
In any case, I always need a cold reboot to revive the interface. Cold,
because the fu..... notebook has problems to do warm reboots. I guess
that has nothing to do with the eepro100 though.
> As it stands, I don't see an alternative to Martin's problem apart from
> the patch he's using - well, that could be done a bit more nicely, like
> having a config option for the sleep D state, which would increase chances
> Alan would take it as an -ac patch.
>
Actually, my little patch is in no way intended for inclusion. Just to
make my interface work again. If it helps others, wonderful. But the
real solution would be to find the root cause and fix it.
Martin
--
------------------------------------------------------------------
Martin Knoblauch | email: [email protected]
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759
Kai Germaschewski wrote:
>
>
> Martin, if you want to spend some work on your problem, you could try to
> collect some more data an your problem, particularly what about using
> another state (D1/D3) when the interface is down. D3 will probably mean
> that you have to save/restore PCI config space, so it's a bit more
> tedious. Also, is there anything which makes your card work again after it
> was in state D2? Like suspend/resume, or putting it into D3 and back into
> D0? Does a warm reboot suffice, or do you need to power cycle.
>
Hmm. I am kind of lost now. I just redid the tests I did with 2.4.6-ac2
under 2.4.7-ac3 and my eepro100 merrily survives any number of
D0->D2->D0 transitions. The only difference besides the kernels is the
ambient temperature. It is quite hot right now - and we don't have AC.
Martin
--
------------------------------------------------------------------
Martin Knoblauch | email: [email protected]
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759