linux-kernel - Re: 2.6.23-rc6-mm1: failure to boot on HP nx6325, no sound when booted, USB-related WARNING

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:	Thu, 20 Sep 2007 14:55:28 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jaroslav Kysela <perex@...e.cz>, Takashi Iwai <tiwai@...e.de>,
	linux-usb-devel@...ts.sourceforge.net,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	Ingo Molnar <mingo@...e.hu>, miklos@...redi.hu,
	Len Brown <len.brown@...el.com>,
	David Shaohua Li <shaohua.li@...el.com>
Subject: Re: 2.6.23-rc6-mm1: failure to boot on HP nx6325, no sound when
 booted, USB-related WARNING

On Thu, 20 Sep 2007, Linus Torvalds wrote:
> 
> (Btw, the above commit message points to just my response with a testing 
> patch to the real email: the actual explanation of the INSANE ordering is 
> from Len Brown in
> 
> 	https://lists.linux-foundation.org/pipermail/linux-pm/2006-November/004161.html
> 
> and there Len claims that we *must* wake up CPU's early).

..and points to commit 1a38416cea8ac801ae8f261074721f35317613dc which in 
turn talks about http://bugzilla.kernel.org/show_bug.cgi?id=5651 

Howerver, it seems that bugzilla entry may just be bogus. It talks about 
"it appears that some firmware in the future may depend on that sequence 
for correction operation"

Len, Shaohua, what are the real issues here? 

It would indeed be nice if we could just take CPU's down early (while 
everything is working), and run the whole suspend code with just one CPU, 
rather than having to worry about the ordering between CPU and device 
takedown.

That said, at least with STR, the situation is:

 1) suspend_console
 2)   device_suspend(PMSG_SUSPEND)	  (==   ->suspend)
 3)     disable_nonboot_cpus()
 4)       device_power_down(PMSG_SUSPEND) (==   ->suspend_late)
 5)         pm_ops->enter()
 6)       device_power_up()		  (==   ->resume_early)
 7)     enable_nonboot_cpus()
 8)     pm_finish()
 9)   device_resume()		          (==   ->resume
10) resume_console

So if we agree that things like timers etc should *never* be suspended by 
the early suspend, and *always* use "suspend_late/resume_early", then at 
least STR should be ok.

And I think that's a damn reasonable thing to agree on: timers (and 
anything else that CPU shutdown/bringup could *possibly* care about) 
should be considered core enough that they had better be on the 
suspend_late/resume_early list.

Thomas, Rafael, can you verify that at least STR is ok in this respect?

		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/