linux-kernel - [PATCH] correct slow acpi_pm rating (fixes no boot with 2.6.21-rc3 and later)

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] [day] [month] [year] [list]

Message-Id: <1174595118.5662.16.camel@localhost.localdomain>
Date:	Thu, 22 Mar 2007 13:25:18 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	linux-kernel@...r.kernel.org, bunk@...sta.de, jikos@...os.cz,
	Bob Tracy <rct@...rkin.frus.com>
Subject: [PATCH] correct slow acpi_pm rating (fixes no boot with 2.6.21-rc3
	and later)

Tested by Bob Tracy.

On Wed, 2007-03-21 at 21:45 -0600, Bob Tracy wrote:
> john stultz wrote:
> > > > Also, does booting w/ "clocksource=jiffies" change the behavior?
> 
> Works fine with 2.6.21-rc4.  I'm running on that kernel as I type this.
> 
> > Also trying booting w/ "notsc" would be a useful data point.
> 
> Boot hangs at the point indicated in my original message.  I *did*
> notice the blurb in the console messages about the pit clocksource
> being selected/used.  There was also a complaint about it being
> unstable, with a negative delta.  I think these messages are consistent
> with the pre-bad-commit case other than where they appear in the boot
> messages.
> 
> > (...) a pre-bad-commit dmesg would help.
> 
> Sent under separate cover to John.

Yea. From looking at your boot log, it does look like the PIT
clocksource is being used. 

This does point to an issue w/ that clocksource, however I noticed its
getting selected over the ACPI PM timer, because you have the PIIX4 bug.
That bug drops the ACPI PM timers rating to the same as the PIT, so
that's why you're getting the PIT.

Realistically, the PIT is much slower then even the triple read ACPI PM,
so the de-ranking code is probably dropping it too far.

Try this patch and let me know if it does the right thing. Although I do
still need to dig a bit on the PIT hang issue.

-john


Don't drop ACPI PM quite so low if we see the PIIX4 bug.

Signed-off-by: John Stultz <johnstul@...ibm.com>

diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
index d42060e..5ac309e 100644
--- a/drivers/clocksource/acpi_pm.c
+++ b/drivers/clocksource/acpi_pm.c
@@ -90,7 +90,7 @@ __setup("acpi_pm_good", acpi_pm_good_set
 static inline void acpi_pm_need_workaround(void)
 {
 	clocksource_acpi_pm.read = acpi_pm_read_slow;
-	clocksource_acpi_pm.rating = 110;
+	clocksource_acpi_pm.rating = 120;
 }
 
 /*



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