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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 02 Jun 2010 17:51:32 -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 05:34 PM, Robert Hancock wrote:
> On 06/02/2010 06:27 PM, Justin P. Mattock wrote:
>> On 06/02/2010 05:20 PM, Robert Hancock wrote:
>>> 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).
>>>
>>
>> the above code reboot's the machine as it should..
>> I can look at that(need to take a break first though)
>> and see..
>>
>> what about the whole kbd mechanism(0x64) give the info I provided
>> does it look possible, or is this machine strictly on cf9?
>
> The keyboard controller reset is the kernel default, so I assume that
> doesn't work on this machine or else this wouldn't have come up in the
> first place..
>

that's what I'm trying to figure out i.g. how to find
that value(is where I'm at).. tried showkey
but didn't see anything, looked in the dsdt but
didn't see anything that sticks out(to my knowledge)
in the area of 0x64 or 0x472

 From what I've read, having a cold boot, and or
a pci/cpu(trip) seems a bit harsh on the equipment
as opposed to a warm boot(hard disk's shutdown etc...)
but I could be wrong in that area..

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/