linux-kernel - Re: [patch] PM: suspend/resume debugging should depend on SOFTWARE

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:	Fri, 24 Nov 2006 10:08:45 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Mike Galbraith <efault@....de>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Pavel Machek <pavel@...e.cz>,
	Chuck Ebbert <76306.1226@...puserve.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>
Subject: Re: [patch] PM: suspend/resume debugging should depend on SOFTWARE_SUSPEND

On Fri, 24 Nov 2006, Mike Galbraith wrote:
> 
> I tried the dynticks/hires-timers/kbd suggestion, no difference.  It
> still boots in medicated snail mode, and emits a stream of IRQ9: nobody
> cared messages (fasteoi acpi, irqpoll = nogo) while doing so.

"medicated snail mode". Lol.

The "IRQ9: nobody cared" things are not unheard of. The Mac Mini had the 
same issue, and in that case it was because the firmware on that machine 
was just broken, and didn't re-enable ACPI mode correctly on resume. We 
worked around it by forcing a re-enable by hand, so that _exact_ issue 
isn't going to be your problem (or it would work since 2.6.18), but it's 
not unlikely that there is some other SCI setup that could have been 
missed.

One thing that is often worth testing is to try with APIC support if you 
don't have it already, or if you do have it, try _without_ APIC support. 
The firmware generally is only tested against MS operating systems, so 
it's only ever been tested for the particular irq setup that Windows tends 
to use, and as a result sometimes things work better in one more or 
another.

Based on the "fasteoi", you're obviously right now using the APIC, and 
that's _usually_ the mode that works better. But just in case, try booting 
with "noapic".

Also, can you send out the boot log with APIC information ("apic=debug"). 
Of course, don't disable the apic for that case, or it won't be very 
useful ;)

		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/