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  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 19:35:03 -0400
From:	Len Brown <>
To:	Linus Torvalds <>
Cc:	Thomas Gleixner <>,
	"Rafael J. Wysocki" <>,
	Andrew Morton <>,
	Linux Kernel Mailing List <>,
	Jaroslav Kysela <>, Takashi Iwai <>,,
	Venkatesh Pallipadi <>,
	Ingo Molnar <>,,
	Len Brown <>,
	David Shaohua Li <>
Subject: Re: 2.6.23-rc6-mm1: failure to boot on HP nx6325, no sound when booted, USB-related WARNING

On Thursday 20 September 2007 17:55, Linus Torvalds wrote:
> 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
> > 
> >
> > 
> > and there Len claims that we *must* wake up CPU's early).
> ..and points to commit 1a38416cea8ac801ae8f261074721f35317613dc which in 
> turn talks about 
> 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? 

Intel's reference BIOS for Core Duo performs some re-initialization
in _WAK that will get blow away if INIT follows _WAK.
IIR, it is related to re-initializing the thermal sensors.
I opened bug 5651 when the BIOS team informed me of this issue.

Yes, bringing a processor offline and then online again w/o
an intervening suspend or reset would not evaluate _WAK,
and thus may still run into the issue.

I don't know if this is a widespread issue and a commonly
used BIOS hook, or if it is specific to certain processors.


> 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
> More majordomo info at
> Please read the FAQ at
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists