Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933364Ab0FCAvN (ORCPT ); Wed, 2 Jun 2010 20:51:13 -0400 Received: from mail-px0-f174.google.com ([209.85.212.174]:63932 "EHLO mail-px0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932771Ab0FCAvL (ORCPT ); Wed, 2 Jun 2010 20:51:11 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wUo62QVDCMtIseU5pCBCQz9IAnLf6wn63IfRP+GUg4rsTzFolFsSe3PXxVp6fuGVrO ZJbnNWmh5H/CHY4sdpJPuAluHTlDSJMYXdCZxRZNEp766QB/Q+R471PjHi0T358cWEzs F5cv68e/KrO35Ksn21TA3ZORvw23x6Bm8AmOo= Message-ID: <4C06FC94.4020205@gmail.com> Date: Wed, 02 Jun 2010 17:51:32 -0700 From: "Justin P. Mattock" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091114 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Robert Hancock CC: Matthew Garrett , x86@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH]X86:reboot.c Add some dmi entries to pci_reboot_dmi_table. References: <20100601192101.GA15086@srcf.ucam.org> <4C056839.8020605@gmail.com> <20100601200704.GA16091@srcf.ucam.org> <4C056AE6.3000409@gmail.com> <20100601202130.GA16391@srcf.ucam.org> <4C056E0C.2030709@gmail.com> <20100601203351.GA16575@srcf.ucam.org> <4C0572B4.6000201@gmail.com> <20100601211219.GA17719@srcf.ucam.org> <4C057AE9.9020307@gmail.com> <20100601212901.GA18390@srcf.ucam.org> <4C057EF0.2030808@gmail.com> <4C05E800.1010400@gmail.com> <4C05F3BF.6090503@gmail.com> <4C06ECAA.3060708@gmail.com> <4C06ED18.2010400@gmail.com> <4C06F1DD.8060004@gmail.com> <4C06F6EA.6090701@gmail.com> <4C06F8B0.1010805@gmail.com> In-Reply-To: <4C06F8B0.1010805@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2906 Lines: 98 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 >>> 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 >>>>>>> >>>>>>> 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 >>> >>> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/