Re: [PATCH]X86:reboot.c Add some dmi entries to pci_reboot_dmi_table.

[Justin P. Mattock]

On 06/02/2010 04:45 PM, Robert Hancock wrote:
> On 06/02/2010 05:43 PM, Justin P. Mattock wrote:
> > On 06/02/2010 04:18 PM, Robert Hancock wrote:
> > > On Wed, Jun 2, 2010 at 12:01 AM, Justin P. Mattock
> > > <justinmattock@xxxxxxxxx> 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:
>
> 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;
}

int main() {
	iopl(3);
	outb(6, 0x64);
	return 0;
}

int main() {
	iopl(3);
	outb(0xfe, 0x64);
	return 0;
}


(and yes I made sure I did this as root!!)

:-)

> > #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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/