Prev: linux-next: Tree for June 2
Next: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
From: Justin P. Mattock on 2 Jun 2010 22:20
On 06/02/2010 07:15 PM, Justin P. Mattock wrote:
> On 06/02/2010 06:47 PM, Robert Hancock wrote:
>> On Wed, Jun 2, 2010 at 7:37 PM, Matthew Garrett<mjg59(a)srcf.ucam.org>
>> wrote:
>>> On Wed, Jun 02, 2010 at 05:27:22PM -0700, Justin P. Mattock wrote:
>>>> On 06/02/2010 05:20 PM, Robert Hancock wrote:
>>>>> #include<unistd.h>
>>>>>
>>>>> int main() {
>>>>> iopl(3);
>>>>> outb(2, 0xcf9);
>>>>> sleep(1);
>>>>> outb(6, 0xcf9);
>>>>> return 0;
>>>>> }
>>>>>
>>>>> That's basically what PCI reboot does.
>>>>
>>>> the above code reboot's the machine as it should..
>>>> I can look at that(need to take a break first though)
>>>> and see..
>>>
>>> That's pretty infuriating. The ACPI-provided definition doesn't work,
>>> and there's no ACPI mechanism for expressing the more complex cf9
>>> behaviour. Windows doesn't appear to special case this, so we're
>>> probably left trying to figure out why the keyboard controller method
>>> doesn't work. Sigh.
>>
>> Do these Macs even have a PC keyboard controller? A recent thread on
>> PS/2 keyboard/mouse controller probing suggests they may not..
>>
>> Justin, what happens if you try the simple outb(6, 0xcf9) test program
>> multiple times, does that do anything?
>>
>
>
> as soon as I change:
>
> int main() {
> iopl(3);
> outb(6, 0xcf9);
> usleep(100);
> outb(6, 0xcf9);
> return 0;
> }
> (the above gave a command prompt
> with numerous tries)
> to:
>
> int main() {
> iopl(3);
> outb(2, 0xcf9);
> usleep(100);
> outb(6, 0xcf9);
> return 0;
> }
>
> it worked..(on the first try)
>

just rebooted, and tried the one that worked,
had no response(just a command prompt) even though
it rebooted the system prior too.

> but still am confused as
> to why I tried: outb(2, 0xcf9);
> with nothing happening.
> (Maybe something in there
> is changing each boot or something.)
>

something is changing in there it seems.

Justin P. Mattock

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Justin P. Mattock on 3 Jun 2010 06:20
On 06/03/2010 02:54 AM, Alan Cox wrote:
> On Thu, 3 Jun 2010 03:18:51 +0100
> Matthew Garrett<mjg59(a)srcf.ucam.org> wrote:
>
>> On Wed, Jun 02, 2010 at 07:15:36PM -0700, Justin P. Mattock wrote:
>>> as soon as I change:
>>>
>>> int main() {
>>> iopl(3);
>>> outb(6, 0xcf9);
>>> usleep(100);
>>> outb(6, 0xcf9);
>>> return 0;
>>> }
>>> (the above gave a command prompt
>>> with numerous tries)
>>
>> Ok, so it's not that straghtforward. Sigh. There's various hacky
>> workarounds we could do here, but Windows doesn't seem to do them so I
>> lean towards suspecting that there's something wrong with our keyboard
>> controller reboot mechanism. I'll try doing some more tracing.
>
> At least some PCs you need to issue the reboot outb calls on the boot
> processor so the userspace tests won't be reliable.
>


well.. the userspace is unreliable from over here..
but if were looking at the issue we might as well
look at the whole problem at hand..
i.g. solving the problem with apple, and solving the
problem with the others..(basically getting rid of this
whole dmi entry list all together..(or at-least most of it)..

but might be a bit much..

Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Robert Hancock on 3 Jun 2010 10:50
On Thu, Jun 3, 2010 at 3:54 AM, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote:
> On Thu, 3 Jun 2010 03:18:51 +0100
> Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
>
>> On Wed, Jun 02, 2010 at 07:15:36PM -0700, Justin P. Mattock wrote:
>> > as soon as I change:
>> >
>> > int main() {
>> > � � iopl(3);
>> > � � outb(6, 0xcf9);
>> > � � usleep(100);
>> > � � outb(6, 0xcf9);
>> > � � return 0;
>> > }
>> > (the above gave a command prompt
>> > with numerous tries)
>>
>> Ok, so it's not that straghtforward. Sigh. There's various hacky
>> workarounds we could do here, but Windows doesn't seem to do them so I
>> lean towards suspecting that there's something wrong with our keyboard
>> controller reboot mechanism. I'll try doing some more tracing.
>
> At least some PCs you need to issue the reboot outb calls on the boot
> processor so the userspace tests won't be reliable.

In that case you could presumably run them:

taskset 0x00000001 (program name)

and see if that changes anything.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3 4
Prev: linux-next: Tree for June 2
Next: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)