lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 17 Aug 2009 14:02:35 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Maxim Levitsky <maximlevitsky@...il.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-pm@...ts.linux-foundation.org" 
	<linux-pm@...ts.linux-foundation.org>
Subject: Re: Very strange issues with ethernet wake on lan

On Monday 17 August 2009, Maxim Levitsky wrote:
> On Sun, 2009-08-16 at 06:42 +0300, Maxim Levitsky wrote:
> > Hi,
> > 
> > I have recently put back the davicom dm9009 ethernet card into my
> > computer.
> > 
> > Some long time ago, I have written its suspend/resume routines.
> > Now I see that few things have changed, like I need to enable wake in
> > sysfs or better patch the code to do so, some nice helpers like
> > pci_prepare_to_sleep have arrived, etc.
> > 
> > 
> > I narrowed the strange issue down to following situation:
> > 
> > I reload dmfe.ko (and networkmanager is disabled)
> > I don't ifup the device, thus pretty much no hardware initialization
> > takes place (but this appears not to matter anyway)
> > 
> > I then suspend the system, and WOL doesn't work (I have patched the
> > driver to enable WOL automaticly)
> > 
> > I then, suspend again. WOL works, and continues to work as long as I
> > don't reload the driver. If I do, same situation repeats.
> > 
> > Also, after a boot, WOL works, so a reload cycle triggers that issue.
> > 
> > And most importantly, if I don't do a
> > 
> > pci_set_power_state(pci_dev, pci_choose_state (pci_dev, state));
> > 
> > in .suspend, then WOL always works.
> > 
> > and I have even tried to set state manually to PCI_D3hot or PCI_D3cold, 
> > 
> > I also tried to use pci_save_state
> > 
> > 
> > I also have 2 copies of this card, and both have this issue.
> > I also tried 2 pci slots.
> > 
> > Kernel is vanilla 2.6.31-rc5
> 
> 
> Bisect reveals:
> 
> 44e4e66eeae5338b3ca0b28f8352e60bf18d5ba8 is first bad commit
> commit 44e4e66eeae5338b3ca0b28f8352e60bf18d5ba8
> Author: Rafael J. Wysocki <rjw@...k.pl>
> Date:   Mon Jul 7 03:32:52 2008 +0200
> 
>     PCI: rework pci_set_power_state function to call platform first
>     
>     Rework pci_set_power_state() so that the platform callback is
>     invoked before the native mechanism, if necessary.  Also, make
>     the function check if the device is power manageable by the
>     platform before invoking the platform callback.
>     
>     This may matter if the device dependent on additional power
>     resources controlled by the platform is being put into D0, in which
>     case those power resources must be turned on before we attempt to
>     handle the device itself.
>     
>     Signed-off-by: Rafael J. Wysocki <rjw@...k.pl>
>     Acked-by: Pavel Machek <pavel@...e.cz>
>     Signed-off-by: Jesse Barnes <jbarnes@...tuousgeek.org>
> 
> 
> Note that probably this device has no acpi entries, because it is an
> addon card, bios knows nothing about it

Well, thanks, but I was going to have a look at this issue anyway. :-)

Best,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists