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]

Message-Id: <200709212120.03044.rjw@sisk.pl>
Date:	Fri, 21 Sep 2007 21:20:01 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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 Friday, 21 September 2007 18:27, Thomas Gleixner wrote:
> Rafael,
> 
> On Fri, 2007-09-21 at 16:20 +0200, Rafael J. Wysocki wrote:
> > > > If you need any help from me with that, please let me know.
> > > 
> > > I'm zooming in. It seems, that the ACPI idle code plays tricks with us.
> > > After debugging the swsusp_suspend() code path I figured out, that we
> > > end up in C2 or deeper power states while we run the suspend code. The
> > > same happens when we come back on resume. It looks like we disable stuff
> > > in the ACPI BIOS, which makes the C2 and deeper power states misbehave.
> > 
> > Hm, can you please run the test I've suggested in another branch of the
> > thread, ie.
> > 
> > # echo shutdown > /sys/power/disk
> > # echo disk > /sys/power/state
> > 
> > without your debugging code in disk.c?
> > 
> > This makes the hibernation code omit the major ACPI hooks, so if it works,
> > we'll know that these hooks are responsible for the problem.
> 
> Yes, this works fine. We still go into C3, but this seems not longer to
> brick the box.
> 
> > > I hacked the idle loop arch code to use halt() right before we call
> > > device_suspend() and switch back to the acpi idle code right after
> > > device_resume(). This solves the problem as well.
> > 
> > Well, that seems less intrusive than changing the code ordering right before
> > the major kernel release, but I think we should do our best to understand what
> > _exactly_ is happening here.
> 
> I found some other subtle thinko in the clock events code while I was
> heading down the swsusp_suspend code path. I wait for confirmation that
> it does not brick some endangered boxen, though. Still with this change
> in the clock events code, my VAIO goes into C2 or C3 and causes the box
> to wait for a helping keystroke.
> 
> The correct solution would be, that the ACPI code ignores the lower
> C-states during suspend / resume.

Yes, certainly.

> I simply rmmod'ed the processor module before suspend and the problem is
> solved as well. The cpuidle patches make this problem more prominent due
> to the possible more direct switch into lower power states, when we wait for
> a long time on something. 

So, perhaps we can add a .suspend()/.resume() routines to the processor driver
and use them to disable/enable the cpuidle functionality during a
suspend/resume?

> I think we really should not fiddle with the various cpu states during
> the critical parts of suspend / resume. Let's keep it simple. We have
> the same policy during boot and I think the suspend / resume critical
> parts have similar constraints.

I completely agree.

Greetings,
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/