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] [day] [month] [year] [list]
Date:	Thu, 21 Aug 2008 14:34:34 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Simon Arlott <simon@...e.lp0.eu>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, jgarzik@...hat.com,
	netdev@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, ranma+kernel@...edrich.de
Subject: Re: [linux-pm] forcedeth 10de:0373 doesn't work on resume

On Monday, 18 of August 2008, Simon Arlott wrote:
> On 18/08/08 22:13, Rafael J. Wysocki wrote:
> > On Monday, 18 of August 2008, Andrew Morton wrote:
> >> On Tue, 05 Aug 2008 20:29:44 +0100
> >> Simon Arlott <simon@...e.lp0.eu> wrote:
> >> >
> >> 
> >> [two weeks pass...]
> > 
> > [Must have missed this message.]
> > 
> > I have a box with forcedeth that evidently works after a resume from
> > hibernation.  Unfortunately, so far I haven't been able to make the box
> 
> With hibernation would it re-initialise the devices differently?
> 
> > resume from suspend to RAM.  I'll do my best to try again tomorrow, but there's
> > a little hope. :-(
> 
> Mine doesn't either, try standby?
> 
> >> > My NIC stops working after resuming from standby, it's not receiving any interrupts:
> >> > Commit 25d90810ff49d2a63475776f24c74c6bb49b045f ([netdrvr] forcedeth: reorder suspend/resume code) 
> >> > introduces pci_disable_device to nv_suspend, but there's no corresponding pci_enable_device in 
> >> > nv_resume - so I added one (copied from e1000):
> >> > 
> >> > diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
> >> > index 01b38b0..db4f875 100644
> >> > --- a/drivers/net/forcedeth.c
> >> > +++ b/drivers/net/forcedeth.c
> >> > @@ -5922,6 +5922,13 @@ static int nv_resume(struct pci_dev *pdev)
> >> >  
> >> >  	pci_set_power_state(pdev, PCI_D0);
> >> >  	pci_restore_state(pdev);
> >> > +	rc = pci_enable_device(pdev);
> >> > +	if (rc) {
> >> > +		printk(KERN_ERR "forcedeth: Cannot enable PCI device from suspend\n");
> >> > +		return rc;
> >> > +	}
> >> > +	pci_set_master(pdev);
> >> > +
> >> >  	/* ack any pending wake events, disable PME */
> >> >  	pci_enable_wake(pdev, PCI_D0, 0);
> >> >  
> >> 
> >> That seems like a sensible change.
> >> 
> 
> With this applied, I can resume from standby *without MSI* and the 
> NIC still works. I haven't tested it without MSI and without the 
> patch... mostly because I got a BUG when I tried to recompile.
> 
> >> > This results in interrupts being re-enabled after suspend:
> >> > However, the NIC still doesn't work after resume.
> > 
> > Simon, I'd prefer the full dmesg to the grepped forcedeth messages.
> > 
> 
> Attached. (The previous email has all the standby/resume log output.)
> 
> > I guess this was resume from suspend to RAM?
> 
> Standby - resume from RAM is completely broken for my system.
> 
> >> Is it still broken in current kernels?
> > 
> > It probably is.
> 
> If I have MSI enabled, it still doesn't work.

I cannot reproduce the problem locally, at least not with 2.6.27-rc4.

I was able to make my box resume from suspend to RAM by using

# s2ram --force --vbe_mode --vbe_post

(s2ram as shipped in openSUSE 11.0) and forcedeth works correctly
after the resume.  However, I had to add 'acpi_sleep=old_ordering' to the
kernel command line.

My box is a desktop with an Asus A8N-SLI motherboard and an Athlon 64 X2 CPU.

I have created a Bugzilla entry for this issue at
http://bugzilla.kernel.org/show_bug.cgi?id=11390
Please put a boot log from dmesg and the output of 'lspci -vvv' in there, as
text attachments.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ