Date:	Wed, 2 Jun 2010 18:20:46 -0600
From:	Robert Hancock <hancockrwd@...il.com>
To:	"Justin P. Mattock" <justinmattock@...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 Wed, Jun 2, 2010 at 6:05 PM, Justin P. Mattock
<justinmattock@...il.com> wrote:
>>>> 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:
>>
>> You get a segfault on that one? Running as root?
>>
>
> my bad(tired)I left out iopl(3);
> in the code which was giving a segfault.
>
> running the below code(s) just gives a command prompt
>
> int main() {
>        iopl(3);
>        outb(0xfe, 0xcf9);
>        return 0;
> }
>
> int main() {
>        iopl(3);
>        outb(6, 0xcf9);
>        return 0;
> }

What if you do:

#include <unistd.h>

int main() {
        iopl(3);
        outb(2, 0xcf9);
        sleep(1);
        outb(6, 0xcf9);
        return 0;
}

That's basically what PCI reboot does.

It's possible it doesn't take the first time - you could try modifying
drivers/acpi/reboot.c to call acpi_reset in a loop instead of just
trying once (assuming you have the patch to default to ACPI reboot
enabled).


>>> #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?
>>
>> No, the stuff after "Value to cause reset" is something else entirely.
>>
> alright!!
> Im wondering if KBD_STATUS_REG is wrong on this machine?
> and/or 0x472(will look into this stuff)
>>>
>>> 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
>>>
>>
>>
>
> cheers,
>
> 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/

Powered by blists - more mailing lists