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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53123DCF.7040500@zytor.com>
Date:	Sat, 01 Mar 2014 12:06:39 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>,
	"Li, Aubrey" <aubrey.li@...ux.intel.com>
CC:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"alan@...ux.intel.com" <alan@...ux.intel.com>,
	linux-kernel@...r.kernel.org, Len.Brown@...el.com,
	Adam Williamson <awilliam@...hat.com>
Subject: Re: [patch] x86: Introduce BOOT_EFI and BOOT_CF9 into the reboot
 sequence loop

On 03/01/2014 09:22 AM, Matthew Garrett wrote:
> On Sun, Mar 02, 2014 at 01:10:46AM +0800, Li, Aubrey wrote:
> 
>> Peter - Can you please clarify writing to cf9 caused some system hang.
>> If CF9 is the last way to try, that means ACPI, KBD takes no effect,
>> then if no CF9, the system hangs there in  infinite for() loop. If CF9
>> is there, that means CF9 takes no effect as well, CF9 does *NOT* cause
>> system hang, right? If the answer is no, can you please point me which
>> system hangs by CF9. I'd like to investigate what the ACPI reboot
>> vectors look like on these systems.
> 
> I think I'm fine with cf9 being in there as long as it comes after the 
> ACPI calls and as long as we're using either conf1 or conf2 access.
> 

Be careful.  This is *exactly* what I tried back in checkin
14d7ca5c575853664d8fe4f225a77b8df1b7de7d.  We had to back that out quite
quickly.

This was before we had the Link: tags pointing back to the LKML
discussion, but the date (2008-11-11) and title of the patch should give
a good hint for finding the discussion I would think.

    x86: attempt reboot via port CF9 if we have standard PCI ports

    Impact: Changes reboot behavior.

    If port CF9 seems to be safe to touch, attempt it before trying the
    keyboard controller.  Port CF9 is not available on all chipsets (a
    significant but decreasing number of modern chipsets don't implement
    it), but port CF9 itself should in general be safe to poke (no ill
    effects if unimplemented) on any system which has PCI Configuration
    Method #1 or #2, as it falls inside the PCI configuration port range
    in both cases.  No chipset without PCI is known to have port CF9,
    either, although an explicit "pci=bios" would mean we miss this and
    therefore don't use port CF9.  An explicit "reboot=pci" can be used to
    force the use of port CF9.

    Signed-off-by: H. Peter Anvin <hpa@...or.com>

	-hpa

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