Prev: Drivers: Stagins: memrar: cleanup
Next: [PATCH] input: Tone down logging from S3C touchscreen driver
From: Justin P. Mattock on 2 Jun 2010 22:10
On 06/02/2010 06:56 PM, Matthew Garrett wrote:
> On Wed, Jun 02, 2010 at 07:47:17PM -0600, Robert Hancock wrote:
>> On Wed, Jun 2, 2010 at 7:37 PM, Matthew Garrett<mjg59(a)srcf.ucam.org> wrote:
>>> 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..
>
> Possibly an SMM trap...
>
>> Justin, what happens if you try the simple outb(6, 0xcf9) test program
>> multiple times, does that do anything?
>
> Huh. That might work, yes. Windows does the ACPI write, an i8042 write,
> the ACPI write, another i8042 write and then gives up. If that happens
> sufficiently quickly, this might get us somewhere. Justin, can you try:
>
> #include<sys/io.h>
> #include<unistd.h>
>
> int main() {
> iopl(3);
> outb(6, 0xcf9);
> usleep(100);
> outb(6, 0xcf9);
> return 0;
> }
>
> and see if that reboots?
>


this thing is wacked out
this just rebooted the system:

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

and now it's motionless
(just a command prompt).

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 2 Jun 2010 22:30
On 06/02/2010 07:18 PM, Matthew Garrett 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.
>


I'll keep looking around as well(the best I can)

FWIW not sure if this means anything but


grep PS *.dsl

gives:


SPST, 1,
PSVT, 8,
PSCL, 8,
APPS, 1,
PSI0, 8,
PSI1, 8,
If (PSI0)
Store (0x00, PSI0)
Return (CRS (PSI0))
Return (CRSI (PSI0))
Store (SRS (Arg0), PSI0)
Store (SRSI (Arg0), PSI0)
If (PSI1)
Store (0x00, PSI1)
Return (CRS (PSI1))
Return (CRSI (PSI1))
Store (SRS (Arg0), PSI1)
Store (SRSI (Arg0), PSI1)
Method (_PSW, 1, NotSerialized)
Name (PSIT, 0x00)
Method (_PS0, 0, Serialized)
Method (_PS3, 0, Serialized)
Method (_PS0, 0, Serialized)
Store (0x00, APPS)
Method (_PS3, 0, Serialized)
Store (0x01, APPS)


there's no such thing as a PS/3 is there?

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/
First  |  Prev  | 
Pages: 1 2 3
Prev: Drivers: Stagins: memrar: cleanup
Next: [PATCH] input: Tone down logging from S3C touchscreen driver