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:	Mon, 16 Jan 2012 08:53:48 +0100
From:	Ingo Molnar <>
To:	Michael D Labriola <>,
	Matthew Garrett <>
Cc:	Thomas Gleixner <>,
	Ingo Molnar <>,
	"H. Peter Anvin" <>,,,
	Kushal Koolwal <>,,
Subject: Re: Reboot hangs on VersaLogic Ocelot

(Cc:-ed Matthew Garrett)

* Michael D Labriola <> wrote:

> I've been troubleshooting a VersaLogic Ocelot SBC that's been 
> hanging on reboot ever since I upgraded its BIOS.  The 
> conclusion I've come to is that commit e19e074 (x86: Fix 
> reboot problem on VersaLogic Menlow boards) needs to be 
> reverted.
> My system was rebooting fine (kernel v3.2) prior to upgrading 
> the BIOS, but it turns out that the DMI string being looked 
> for in the VersaLogic reboot quirk wasn't added until I 
> upgraded the BIOS.
> Here's a summary of the behavior I encountered on my system 
> (VL-EPMs-21a rev 1.00 w/ BIOS 6.5.102)
> - v2.6.37 reboot=bios is needed
> - v2.6.38-rc1: behavior changed, reboot=acpi is needed, reboot=kbd and
>   reboot=bios result in system hang.
> - v2.6.38: VersaLogic patch (e19e074 x86: Fix reboot problem on
>   VersaLogic Menlow boards) was applied prior to v2.6.38-rc7.  This
>   patch sets a quirk for VersaLogic Menlow boards that forces the use
>   of reboot=bios, which doesn't work anymore.  As far as I can tell,
>   there's no way to override this faulty quirk, as it seems to take
>   precedence over the reboot= argument.

That's another bug i'd argue - the user specifying something on 
the boot command line should *always* override the kernel's 
built-in defaults.

> - v3.2: It seems that commit 660e34c (x86: Reorder reboot method
>   preferences) changed the default reboot method to acpi prior to
>   v3.0-rc1, which means the default behavior is appropriate for the
>   Ocelot.  After reverting commit e19e074, my system reboots perfectly
>   w/out passing any reboot= arguments.  I confirmed that this is a
>   true statement for all 3 versions of the Ocelot's BIOS.

And this works for the older BIOS version as well, the one which 
motivated commit e19e074?

Please send a patch that removes the quirk (not named a revert - 
as technically the old quirk did solve problems), with the 
changelog containing your (excellent) bug analysis and the test 
coverage above, plus a signoff?

Matthew, do you concur? Looks like your reordering changes 
actively improved the default behavior and we can start removing 


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