linux-kernel - Re: [PATCH]X86:reboot.c Add some dmi entries to pci_reboot_dmi

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:	Wed, 02 Jun 2010 16:43:38 -0700
From:	"Justin P. Mattock" <justinmattock@...il.com>
To:	Robert Hancock <hancockrwd@...il.com>
CC:	Matthew Garrett <mjg59@...f.ucam.org>, x86@...nel.org,
	tglx@...utronix.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH]X86:reboot.c Add some dmi entries to pci_reboot_dmi_table.

On 06/02/2010 04:18 PM, Robert Hancock wrote:
> On Wed, Jun 2, 2010 at 12:01 AM, Justin P. Mattock
> <justinmattock@...il.com>  wrote:
>>> Can you post the FACP section of the acpidump output from this machine?
>>>
>>
>> here you go:
>>
>
>
>>              Reset Register Supported (V2) : 1
>
>> [074h 116 12]               Reset Register :<Generic Address Structure>
>> [074h 116  1]                     Space ID : 01 (SystemIO)
>> [075h 117  1]                    Bit Width : 08
>> [076h 118  1]                   Bit Offset : 00
>> [077h 119  1]                 Access Width : 00
>> [078h 120  8]                      Address : 0000000000000CF9
>>
>> [080h 128  1]         Value to cause reset : 06
>
> Hmm, so the FADT says the reset register is listed as supported, and
> says writing 0x06 to 0xCF9 is supposed to do it.. That's exactly what
> this should do:
>
> #include<sys/io.h>
>
> int main() {
>      iopl(3);
>      outb(6, 0xcf9);
>      return 0;
> }
>
> but you said that didn't do anything.. It kind of seems like ACPI
> reboot is busted on this machine then, but then I wonder how Windows
> manages to work..
>


alright!! I have a better idea at what this is now..
as for the above code, yes this one segfaults,
the other code posted on the thread just returns
a command prompt(testing:

#include <sys/io.h>

int main() {
     iopl(3);
     outb(0xfe, 0xcf9);
     return 0;
}
on a dell reboot's as is.)

both my macbook, and imac are
broken with the above.(but for whatever
reason the macbook doesnt need an dmi entry
in reboot.c just iMac9,1 etc..)

so the address for the CF9 is this:

[074h 116 12]               Reset Register : <Generic Address Structure>
[074h 116  1]                     Space ID : 01 (SystemIO)
[075h 117  1]                    Bit Width : 08
[076h 118  1]                   Bit Offset : 00
[077h 119  1]                 Access Width : 00
[078h 120  8]                      Address : 0000000000000CF9

[080h 128  1]         Value to cause reset : 06
[081h 129  3]                     Reserved : 000000
[084h 132  8]                 FACS Address : 00000000BFECD000
[08Ch 140  8]                 DSDT Address : 00000000BFEE0000
[094h 148 12]             PM1A Event Block : <Generic Address Structure>
[094h 148  1]                     Space ID : 01 (SystemIO)
[095h 149  1]                    Bit Width : 20
[096h 150  1]                   Bit Offset : 00
[097h 151  1]                 Access Width : 00
[098h 152  8]                      Address : 0000000000000400

not sure how to read this, but are there
two devices here i.g.
is the top a cold boot(reset register) and
the bottom(value to cause reset) a warm boot?

at the moment I'm trying to figure out what/where
*((unsigned short *)__va(0x472)) = reboot_mode;
0x472 comes from as well as 0x1234 then
#define KBD_STATUS_REG                0x64
to see if I can see anything.


thanks for the info on this..

Justin P. Mattock

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