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: <20120116075348.GF15641@elte.hu>
Date:	Mon, 16 Jan 2012 08:53:48 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Michael D Labriola <mlabriol@...b.com>,
	Matthew Garrett <mjg@...hat.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org,
	Kushal Koolwal <kushalkoolwal@...il.com>,
	support@...salogic.com, michael.d.labriola@...il.com
Subject: Re: Reboot hangs on VersaLogic Ocelot


(Cc:-ed Matthew Garrett)

* Michael D Labriola <mlabriol@...b.com> 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 
quirks.

Thanks,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ