linux-kernel - Re: Regression from 2.6.26: Hibernation (possibly suspend) broken on Toshiba R500 (bisected)

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]

Message-ID: <alpine.LFD.2.00.0812051750450.3425@nehalem.linux-foundation.org>
Date:	Fri, 5 Dec 2008 17:55:16 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Frans Pop <elendil@...net.nl>, Greg KH <greg@...ah.com>,
	Ingo Molnar <mingo@...e.hu>, jbarnes@...tuousgeek.org,
	lenb@...nel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	tiwai@...e.de, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Regression from 2.6.26: Hibernation (possibly suspend) broken
 on Toshiba R500 (bisected)

On Sat, 6 Dec 2008, Rafael J. Wysocki wrote:
>
> It only affects the legacy handling, but the non-legacy handling was left
> untouched.  IOW, the old "default" functions are still there and are being
> called by the "non-legacy" code (it's only used by USB at the moment, AFAICS).

Ok.

> Anyway, I did the test doing it only to the devices which don't have any
> non-default suspend-resume handling at all and _that_ apparently fixed the
> problem on my box. :-)

Which makes sense, btw. Because if you do the pci_save_state() on a device 
that _does_ have a suspend function, you'll be saving the post-suspend 
state - ie the device turned off.

So yeah, we really can only do the default suspend if the device has no 
pre-existing suspend function - or we'd need to make sure that all PCI 
drivers that do have suspend functions would only do the higher-level 
functionality.

Anyway, what I'm most interested in hearing is whether this actually 
improves your situation. I can _easily_ see that your resume problem could 
be due to interrupt timing. That's especially true if there are shared 
interrupts, but even in the absense of that, I'm not at all sure that the 
e1000e resume code is interrupt-safe, for example.

		Linus
--
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/