As those computers never had any i8042 controllers, and the
current lookup code could potentially lock up/hang/wait for
timeout for long periods of time.
Fixes intermittent hangs on boot on a MacbookAir1,1
Signed-off-by: Bastien Nocera <[email protected]>
---
drivers/input/serio/i8042.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index d84a36e..2be7207 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -1438,12 +1438,30 @@ static struct platform_driver i8042_driver = {
.shutdown = i8042_shutdown,
};
+static struct dmi_system_id __initdata dmi_system_table[] = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_BIOS_VENDOR, "Apple Computer, Inc.")
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_BIOS_VENDOR, "Apple Inc.")
+ },
+ },
+ {}
+};
+
static int __init i8042_init(void)
{
int err;
dbg_init();
+ /* Intel Apple Macs never have an i8042 controller */
+ if (dmi_check_system(dmi_system_table) > 0)
+ return -ENODEV;
+
err = i8042_platform_init();
if (err)
return err;
--
1.6.6
On 01/20/10 10:23, Bastien Nocera wrote:
> As those computers never had any i8042 controllers, and the
> current lookup code could potentially lock up/hang/wait for
> timeout for long periods of time.
>
> Fixes intermittent hangs on boot on a MacbookAir1,1
>
> Signed-off-by: Bastien Nocera<[email protected]>
> ---
> drivers/input/serio/i8042.c | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
> index d84a36e..2be7207 100644
> --- a/drivers/input/serio/i8042.c
> +++ b/drivers/input/serio/i8042.c
> @@ -1438,12 +1438,30 @@ static struct platform_driver i8042_driver = {
> .shutdown = i8042_shutdown,
> };
>
> +static struct dmi_system_id __initdata dmi_system_table[] = {
> + {
> + .matches = {
> + DMI_MATCH(DMI_BIOS_VENDOR, "Apple Computer, Inc.")
> + },
> + },
> + {
> + .matches = {
> + DMI_MATCH(DMI_BIOS_VENDOR, "Apple Inc.")
> + },
> + },
> + {}
> +};
> +
> static int __init i8042_init(void)
> {
> int err;
>
> dbg_init();
>
> + /* Intel Apple Macs never have an i8042 controller */
> + if (dmi_check_system(dmi_system_table)> 0)
> + return -ENODEV;
> +
> err = i8042_platform_init();
> if (err)
> return err;
glad you submitted this. i.g. been looking at some dmi
blacklist thing over here(been racking my brain around
a bit, and seeing your idea simplified it a bit more for me).
as for what you have here, do you think individually
defining each machine is safer, or does it not matter?
I've been looking at this as well, to get a better idea:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7121413f2accf14cf05b38539fb7a8be77543370;hp=1a133e0c9dabda23e6693cabfdc1d5106dca5fc2
Justin P. Mattock
On Wed, 2010-01-20 at 11:14 -0800, Justin P. Mattock wrote:
> On 01/20/10 10:23, Bastien Nocera wrote:
> > As those computers never had any i8042 controllers, and the
> > current lookup code could potentially lock up/hang/wait for
> > timeout for long periods of time.
> >
> > Fixes intermittent hangs on boot on a MacbookAir1,1
<snip>
> glad you submitted this. i.g. been looking at some dmi
> blacklist thing over here(been racking my brain around
> a bit, and seeing your idea simplified it a bit more for me).
Yeah, dmi_check_system() returns the number of matches. I had to look up
the code to see what it did :)
> as for what you have here, do you think individually
> defining each machine is safer, or does it not matter?
For this particular case, it's not necessary, as none of the Apple
machines ever had any i8042 hardware. Or at least that's what Peter
Jones told me, and I have no reasons to doubt him.
Cheers
On 01/20/10 11:37, Bastien Nocera wrote:
> On Wed, 2010-01-20 at 11:14 -0800, Justin P. Mattock wrote:
>> On 01/20/10 10:23, Bastien Nocera wrote:
>>> As those computers never had any i8042 controllers, and the
>>> current lookup code could potentially lock up/hang/wait for
>>> timeout for long periods of time.
>>>
>>> Fixes intermittent hangs on boot on a MacbookAir1,1
> <snip>
>> glad you submitted this. i.g. been looking at some dmi
>> blacklist thing over here(been racking my brain around
>> a bit, and seeing your idea simplified it a bit more for me).
>
> Yeah, dmi_check_system() returns the number of matches. I had to look up
> the code to see what it did :)
>
>> as for what you have here, do you think individually
>> defining each machine is safer, or does it not matter?
>
> For this particular case, it's not necessary, as none of the Apple
> machines ever had any i8042 hardware. Or at least that's what Peter
> Jones told me, and I have no reasons to doubt him.
>
> Cheers
>
>
ahh.. because of the no i8042..
Justin P. Mattock
On 01/20/2010 12:23 PM, Bastien Nocera wrote:
> As those computers never had any i8042 controllers, and the
> current lookup code could potentially lock up/hang/wait for
> timeout for long periods of time.
>
> Fixes intermittent hangs on boot on a MacbookAir1,1
>
> Signed-off-by: Bastien Nocera<[email protected]>
I assume this is happening because of this code in
drivers/input/serio/i8042-x86ia64io.h:
if (!i8042_pnp_kbd_devices && !i8042_pnp_aux_devices) {
i8042_pnp_exit();
#if defined(__ia64__)
return -ENODEV;
#else
printk(KERN_INFO "PNP: No PS/2 controller found.
Probing ports directly.\n");
return 0;
#endif
In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
controller exists, we randomly bang on the ports in the expectation
they'll be there anyway. This seems rather misguided. It would seem like
a better idea to fix this rather than adding yet another DMI list
(especially since there likely are, or will be, machines without i8042
other than Macs).
I can see continuing on and probing if PNP isn't present on the machine,
but certainly if ACPI is enabled, I don't think we should be doing such
things.
On Wed, 2010-01-20 at 18:41 -0600, Robert Hancock wrote:
> On 01/20/2010 12:23 PM, Bastien Nocera wrote:
> > As those computers never had any i8042 controllers, and the
> > current lookup code could potentially lock up/hang/wait for
> > timeout for long periods of time.
> >
> > Fixes intermittent hangs on boot on a MacbookAir1,1
> >
> > Signed-off-by: Bastien Nocera<[email protected]>
>
> I assume this is happening because of this code in
> drivers/input/serio/i8042-x86ia64io.h:
>
> if (!i8042_pnp_kbd_devices && !i8042_pnp_aux_devices) {
> i8042_pnp_exit();
> #if defined(__ia64__)
> return -ENODEV;
> #else
> printk(KERN_INFO "PNP: No PS/2 controller found.
> Probing ports directly.\n");
> return 0;
> #endif
Actually, the error message is "i8042.c: No controller found". Which
happens very early in a sub-function of i8042_init().
So I don't think this would solve the problem.
> In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
> controller exists, we randomly bang on the ports in the expectation
> they'll be there anyway. This seems rather misguided. It would seem like
> a better idea to fix this rather than adding yet another DMI list
> (especially since there likely are, or will be, machines without i8042
> other than Macs).
They might also have a better BIOS than the Macs and avoid hanging when
that happens...
> I can see continuing on and probing if PNP isn't present on the machine,
> but certainly if ACPI is enabled, I don't think we should be doing such
> things.
On Wed, Jan 20, 2010 at 7:31 PM, Bastien Nocera <[email protected]> wrote:
> On Wed, 2010-01-20 at 18:41 -0600, Robert Hancock wrote:
>> On 01/20/2010 12:23 PM, Bastien Nocera wrote:
>> > As those computers never had any i8042 controllers, and the
>> > current lookup code could potentially lock up/hang/wait for
>> > timeout for long periods of time.
>> >
>> > Fixes intermittent hangs on boot on a MacbookAir1,1
>> >
>> > Signed-off-by: Bastien Nocera<[email protected]>
>>
>> I assume this is happening because of this code in
>> drivers/input/serio/i8042-x86ia64io.h:
>>
>> ? ? ? ? ?if (!i8042_pnp_kbd_devices && !i8042_pnp_aux_devices) {
>> ? ? ? ? ? ? ? ? ?i8042_pnp_exit();
>> #if defined(__ia64__)
>> ? ? ? ? ? ? ? ? ?return -ENODEV;
>> #else
>> ? ? ? ? ? ? ? ? ?printk(KERN_INFO "PNP: No PS/2 controller found.
>> Probing ports directly.\n");
>> ? ? ? ? ? ? ? ? ?return 0;
>> #endif
>
> Actually, the error message is "i8042.c: No controller found". Which
> happens very early in a sub-function of i8042_init().
>
> So I don't think this would solve the problem.
That message comes out of i8042_controller_check which gets called
after i8042_platform_init, which does the check above. So it appears
either the "PNP: No PS/2 controller found" message should have been
printed or PNP did in fact show a controller is present..
>
>> In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
>> controller exists, we randomly bang on the ports in the expectation
>> they'll be there anyway. This seems rather misguided. It would seem like
>> a better idea to fix this rather than adding yet another DMI list
>> (especially since there likely are, or will be, machines without i8042
>> other than Macs).
>
> They might also have a better BIOS than the Macs and avoid hanging when
> that happens...
>
>> I can see continuing on and probing if PNP isn't present on the machine,
>> but certainly if ACPI is enabled, I don't think we should be doing such
>> things.
>
>
On Wed, Jan 20, 2010 at 06:41:56PM -0600, Robert Hancock wrote:
> On 01/20/2010 12:23 PM, Bastien Nocera wrote:
> >As those computers never had any i8042 controllers, and the
> >current lookup code could potentially lock up/hang/wait for
> >timeout for long periods of time.
> >
> >Fixes intermittent hangs on boot on a MacbookAir1,1
> >
> >Signed-off-by: Bastien Nocera<[email protected]>
>
> I assume this is happening because of this code in
> drivers/input/serio/i8042-x86ia64io.h:
>
> if (!i8042_pnp_kbd_devices && !i8042_pnp_aux_devices) {
> i8042_pnp_exit();
> #if defined(__ia64__)
> return -ENODEV;
> #else
> printk(KERN_INFO "PNP: No PS/2 controller found.
> Probing ports directly.\n");
> return 0;
> #endif
>
> In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
> controller exists, we randomly bang on the ports in the expectation
> they'll be there anyway. This seems rather misguided.
Basically, we do not trust BIOS writers on x86 ;) In the past there were
occasions when they forgot to mention presence of KBD/AUX in DSDT and
elsewhere which lead to non-functional keyboard/mouse.
> It would seem
> like a better idea to fix this rather than adding yet another DMI
> list (especially since there likely are, or will be, machines
> without i8042 other than Macs).
>
If they are not Macs that mean they are tested with windows and thus
expect probes in i8042 port region so no harm done. In a few years if
everyone uses USB only we could add a year threshold to trust ACPI/PNP
data.
--
Dmitry
On Thu, Jan 21, 2010 at 12:55 PM, Dmitry Torokhov
<[email protected]> wrote:
> On Wed, Jan 20, 2010 at 06:41:56PM -0600, Robert Hancock wrote:
>> On 01/20/2010 12:23 PM, Bastien Nocera wrote:
>> >As those computers never had any i8042 controllers, and the
>> >current lookup code could potentially lock up/hang/wait for
>> >timeout for long periods of time.
>> >
>> >Fixes intermittent hangs on boot on a MacbookAir1,1
>> >
>> >Signed-off-by: Bastien Nocera<[email protected]>
>>
>> I assume this is happening because of this code in
>> drivers/input/serio/i8042-x86ia64io.h:
>>
>> ? ? ? ? if (!i8042_pnp_kbd_devices && !i8042_pnp_aux_devices) {
>> ? ? ? ? ? ? ? ? i8042_pnp_exit();
>> #if defined(__ia64__)
>> ? ? ? ? ? ? ? ? return -ENODEV;
>> #else
>> ? ? ? ? ? ? ? ? printk(KERN_INFO "PNP: No PS/2 controller found.
>> Probing ports directly.\n");
>> ? ? ? ? ? ? ? ? return 0;
>> #endif
>>
>> In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
>> controller exists, we randomly bang on the ports in the expectation
>> they'll be there anyway. This seems rather misguided.
>
> Basically, we do not trust BIOS writers on x86 ;) In the past there were
> occasions when they forgot to mention presence of KBD/AUX in DSDT and
> elsewhere which lead to non-functional keyboard/mouse.
Are we certain about that? Any pointers to reports?
>
>> It would seem
>> like a better idea to fix this rather than adding yet another DMI
>> list (especially since there likely are, or will be, machines
>> without i8042 other than Macs).
>>
>
> If they are not Macs that mean they are tested with windows and thus
> expect probes in i8042 port region so no harm done. In a few years if
> everyone uses USB only we could add a year threshold to trust ACPI/PNP
> data.
Macs will be tested with Windows too, so obviously it manages to avoid
this problem somehow, and I very much doubt it has an Apple-specific
check..
On 01/21/10 13:39, Robert Hancock wrote:
> On Thu, Jan 21, 2010 at 12:55 PM, Dmitry Torokhov
> <[email protected]> wrote:
>> On Wed, Jan 20, 2010 at 06:41:56PM -0600, Robert Hancock wrote:
>>> On 01/20/2010 12:23 PM, Bastien Nocera wrote:
>>>> As those computers never had any i8042 controllers, and the
>>>> current lookup code could potentially lock up/hang/wait for
>>>> timeout for long periods of time.
>>>>
>>>> Fixes intermittent hangs on boot on a MacbookAir1,1
>>>>
>>>> Signed-off-by: Bastien Nocera<[email protected]>
>>>
>>> I assume this is happening because of this code in
>>> drivers/input/serio/i8042-x86ia64io.h:
>>>
>>> if (!i8042_pnp_kbd_devices&& !i8042_pnp_aux_devices) {
>>> i8042_pnp_exit();
>>> #if defined(__ia64__)
>>> return -ENODEV;
>>> #else
>>> printk(KERN_INFO "PNP: No PS/2 controller found.
>>> Probing ports directly.\n");
>>> return 0;
>>> #endif
>>>
>>> In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
>>> controller exists, we randomly bang on the ports in the expectation
>>> they'll be there anyway. This seems rather misguided.
>>
>> Basically, we do not trust BIOS writers on x86 ;) In the past there were
>> occasions when they forgot to mention presence of KBD/AUX in DSDT and
>> elsewhere which lead to non-functional keyboard/mouse.
>
> Are we certain about that? Any pointers to reports?
>
>>
>>> It would seem
>>> like a better idea to fix this rather than adding yet another DMI
>>> list (especially since there likely are, or will be, machines
>>> without i8042 other than Macs).
>>>
>>
>> If they are not Macs that mean they are tested with windows and thus
>> expect probes in i8042 port region so no harm done. In a few years if
>> everyone uses USB only we could add a year threshold to trust ACPI/PNP
>> data.
>
> Macs will be tested with Windows too, so obviously it manages to avoid
> this problem somehow, and I very much doubt it has an Apple-specific
> check..
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I've an iMac, and a macbook over here,
if you guys need me to test out a patch for this let me know.
Justin P. Mattock
On Thu, 2010-01-21 at 15:39 -0600, Robert Hancock wrote:
<snip>
> Macs will be tested with Windows too, so obviously it manages to avoid
> this problem somehow, and I very much doubt it has an Apple-specific
> check..
Only the bootcamp-provided BIOS will be tested, not the stock one. This
patch covers both types of BIOSes.
On Thu, Jan 21, 2010 at 03:39:25PM -0600, Robert Hancock wrote:
> On Thu, Jan 21, 2010 at 12:55 PM, Dmitry Torokhov
> <[email protected]> wrote:
> > On Wed, Jan 20, 2010 at 06:41:56PM -0600, Robert Hancock wrote:
> >> On 01/20/2010 12:23 PM, Bastien Nocera wrote:
> >> >As those computers never had any i8042 controllers, and the
> >> >current lookup code could potentially lock up/hang/wait for
> >> >timeout for long periods of time.
> >> >
> >> >Fixes intermittent hangs on boot on a MacbookAir1,1
> >> >
> >> >Signed-off-by: Bastien Nocera<[email protected]>
> >>
> >> I assume this is happening because of this code in
> >> drivers/input/serio/i8042-x86ia64io.h:
> >>
> >> ? ? ? ? if (!i8042_pnp_kbd_devices && !i8042_pnp_aux_devices) {
> >> ? ? ? ? ? ? ? ? i8042_pnp_exit();
> >> #if defined(__ia64__)
> >> ? ? ? ? ? ? ? ? return -ENODEV;
> >> #else
> >> ? ? ? ? ? ? ? ? printk(KERN_INFO "PNP: No PS/2 controller found.
> >> Probing ports directly.\n");
> >> ? ? ? ? ? ? ? ? return 0;
> >> #endif
> >>
> >> In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
> >> controller exists, we randomly bang on the ports in the expectation
> >> they'll be there anyway. This seems rather misguided.
> >
> > Basically, we do not trust BIOS writers on x86 ;) In the past there were
> > occasions when they forgot to mention presence of KBD/AUX in DSDT and
> > elsewhere which lead to non-functional keyboard/mouse.
>
> Are we certain about that? Any pointers to reports?
>
This is from the changelog when this was introduced:
-------------------------------------------------------------------------
2005/02/25 21:21:03+01:00 vojtech
input: After testing on real world hardware, it's obvious we can't trust
ACPIPnP nor PnPBIOS to properly report the existence of a keyboard
and mouse port in all cases. Some BIOSes hide the ports if no mouse
or keyboard is connected, causing trouble with eg. KVM switches.
The i8042 driver now does read-only probing first, which should
not cause any problems even if an i8042 controller really is not
present.
However, on IA64 we still need to trust ACPI, since legacy-free
hardware is common there and invalid port accesses cause exceptions.
Signed-off-by: Vojtech Pavlik <[email protected]>
>> Input: Add ACPI-based i8042 keyboard and aux controller enumeration;
> > can be disabled by passing i8042.noacpi as a boot parameter.
>
> On a whim I decided to turn on ACPI, only to discover that my keyboard
> no longer worked. Passing i8042.noacpi=1 makes it work again.
> Attached please find boot messages with and without the boot
> parameter. Inlined below is a diff of the two.
--------------------------------------------------------------------------
I'm adding Vojtech in case he manages to recall what other failures he
has seen.
> >
> >> It would seem
> >> like a better idea to fix this rather than adding yet another DMI
> >> list (especially since there likely are, or will be, machines
> >> without i8042 other than Macs).
> >>
> >
> > If they are not Macs that mean they are tested with windows and thus
> > expect probes in i8042 port region so no harm done. In a few years if
> > everyone uses USB only we could add a year threshold to trust ACPI/PNP
> > data.
>
> Macs will be tested with Windows too, so obviously it manages to avoid
> this problem somehow, and I very much doubt it has an Apple-specific
> check..
Why not?
--
Dmitry
On Thu, Jan 21, 2010 at 4:17 PM, Dmitry Torokhov
<[email protected]> wrote:
> On Thu, Jan 21, 2010 at 03:39:25PM -0600, Robert Hancock wrote:
>> On Thu, Jan 21, 2010 at 12:55 PM, Dmitry Torokhov
>> <[email protected]> wrote:
>> > On Wed, Jan 20, 2010 at 06:41:56PM -0600, Robert Hancock wrote:
>> >> On 01/20/2010 12:23 PM, Bastien Nocera wrote:
>> >> >As those computers never had any i8042 controllers, and the
>> >> >current lookup code could potentially lock up/hang/wait for
>> >> >timeout for long periods of time.
>> >> >
>> >> >Fixes intermittent hangs on boot on a MacbookAir1,1
>> >> >
>> >> >Signed-off-by: Bastien Nocera<[email protected]>
>> >>
>> >> I assume this is happening because of this code in
>> >> drivers/input/serio/i8042-x86ia64io.h:
>> >>
>> >> ? ? ? ? if (!i8042_pnp_kbd_devices && !i8042_pnp_aux_devices) {
>> >> ? ? ? ? ? ? ? ? i8042_pnp_exit();
>> >> #if defined(__ia64__)
>> >> ? ? ? ? ? ? ? ? return -ENODEV;
>> >> #else
>> >> ? ? ? ? ? ? ? ? printk(KERN_INFO "PNP: No PS/2 controller found.
>> >> Probing ports directly.\n");
>> >> ? ? ? ? ? ? ? ? return 0;
>> >> #endif
>> >>
>> >> In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
>> >> controller exists, we randomly bang on the ports in the expectation
>> >> they'll be there anyway. This seems rather misguided.
>> >
>> > Basically, we do not trust BIOS writers on x86 ;) In the past there were
>> > occasions when they forgot to mention presence of KBD/AUX in DSDT and
>> > elsewhere which lead to non-functional keyboard/mouse.
>>
>> Are we certain about that? Any pointers to reports?
>>
>
> This is from the changelog when this was introduced:
>
> -------------------------------------------------------------------------
> 2005/02/25 21:21:03+01:00 vojtech
> input: After testing on real world hardware, it's obvious we can't trust
> ? ? ? ACPIPnP nor PnPBIOS to properly report the existence of a keyboard
> ? ? ? and mouse port in all cases. Some BIOSes hide the ports if no mouse
> ? ? ? or keyboard is connected, causing trouble with eg. KVM switches.
If it's just that case (which isn't certain given Vojtech's report),
then I think it's reasonable to ignore that by default. If the BIOS
decided to hide the controller then our default behavior should be to
believe it, with the ability to override that if necessary, not the
other way around.
>
> ? ? ? The i8042 driver now does read-only probing first, which should
> ? ? ? not cause any problems even if an i8042 controller really is not
> ? ? ? present.
>
> ? ? ? However, on IA64 we still need to trust ACPI, since legacy-free
> ? ? ? hardware is common there and invalid port accesses cause exceptions.
>
> ?Signed-off-by: Vojtech Pavlik <[email protected]>
>
>>> Input: Add ACPI-based i8042 keyboard and aux controller enumeration;
>> > can be disabled by passing i8042.noacpi as a boot parameter.
>>
>> On a whim I decided to turn on ACPI, only to discover that my keyboard
>> no longer worked. Passing i8042.noacpi=1 makes it work again.
>> Attached please find boot messages with and without the boot
>> parameter. Inlined below is a diff of the two.
>
> --------------------------------------------------------------------------
>
> I'm adding Vojtech in case he manages to recall what other failures he
> has seen.
>
>> >
>> >> It would seem
>> >> like a better idea to fix this rather than adding yet another DMI
>> >> list (especially since there likely are, or will be, machines
>> >> without i8042 other than Macs).
>> >>
>> >
>> > If they are not Macs that mean they are tested with windows and thus
>> > expect probes in i8042 port region so no harm done. In a few years if
>> > everyone uses USB only we could add a year threshold to trust ACPI/PNP
>> > data.
>>
>> Macs will be tested with Windows too, so obviously it manages to avoid
>> this problem somehow, and I very much doubt it has an Apple-specific
>> check..
>
> Why not?
Some of the supported Windows versions were likely released before any
Intel-based Macs, which would make such a check impossible.
I think we're far too quick to add DMI lists for things in the kernel.
If there's a way we can just do the right thing, we should be.
On Thu, Jan 21, 2010 at 3:49 PM, Justin P. Mattock
<[email protected]> wrote:
> On 01/21/10 13:39, Robert Hancock wrote:
>>
>> On Thu, Jan 21, 2010 at 12:55 PM, Dmitry Torokhov
>> <[email protected]> ?wrote:
>>>
>>> On Wed, Jan 20, 2010 at 06:41:56PM -0600, Robert Hancock wrote:
>>>>
>>>> On 01/20/2010 12:23 PM, Bastien Nocera wrote:
>>>>>
>>>>> As those computers never had any i8042 controllers, and the
>>>>> current lookup code could potentially lock up/hang/wait for
>>>>> timeout for long periods of time.
>>>>>
>>>>> Fixes intermittent hangs on boot on a MacbookAir1,1
>>>>>
>>>>> Signed-off-by: Bastien Nocera<[email protected]>
>>>>
>>>> I assume this is happening because of this code in
>>>> drivers/input/serio/i8042-x86ia64io.h:
>>>>
>>>> ? ? ? ? if (!i8042_pnp_kbd_devices&& ?!i8042_pnp_aux_devices) {
>>>> ? ? ? ? ? ? ? ? i8042_pnp_exit();
>>>> #if defined(__ia64__)
>>>> ? ? ? ? ? ? ? ? return -ENODEV;
>>>> #else
>>>> ? ? ? ? ? ? ? ? printk(KERN_INFO "PNP: No PS/2 controller found.
>>>> Probing ports directly.\n");
>>>> ? ? ? ? ? ? ? ? return 0;
>>>> #endif
>>>>
>>>> In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
>>>> controller exists, we randomly bang on the ports in the expectation
>>>> they'll be there anyway. This seems rather misguided.
>>>
>>> Basically, we do not trust BIOS writers on x86 ;) In the past there were
>>> occasions when they forgot to mention presence of KBD/AUX in DSDT and
>>> elsewhere which lead to non-functional keyboard/mouse.
>>
>> Are we certain about that? Any pointers to reports?
>>
>>>
>>>> It would seem
>>>> like a better idea to fix this rather than adding yet another DMI
>>>> list (especially since there likely are, or will be, machines
>>>> without i8042 other than Macs).
>>>>
>>>
>>> If they are not Macs that mean they are tested with windows and thus
>>> expect probes in i8042 port region so no harm done. In a few years if
>>> everyone uses USB only we could add a year threshold to trust ACPI/PNP
>>> data.
>>
>> Macs will be tested with Windows too, so obviously it manages to avoid
>> this problem somehow, and I very much doubt it has an Apple-specific
>> check..
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at ?http://www.tux.org/lkml/
>>
>
> I've an iMac, and a macbook over here,
> if you guys need me to test out a patch for this let me know.
Can you (and probably Bastien or whoever had the problematic machine)
check the output of:
cat /sys/bus/pnp/devices/*/id
and see if any of these are present?
PNP0303
PNP030b
FJC6000
FJC6001
PNP0f03
PNP0f0b
PNP0f0e
PNP0f12
PNP0f13
PNP0f19
PNP0f1c
SYN0801
On 01/21/10 16:29, Robert Hancock wrote:
> On Thu, Jan 21, 2010 at 3:49 PM, Justin P. Mattock
> <[email protected]> wrote:
>> On 01/21/10 13:39, Robert Hancock wrote:
>>>
>>> On Thu, Jan 21, 2010 at 12:55 PM, Dmitry Torokhov
>>> <[email protected]> wrote:
>>>>
>>>> On Wed, Jan 20, 2010 at 06:41:56PM -0600, Robert Hancock wrote:
>>>>>
>>>>> On 01/20/2010 12:23 PM, Bastien Nocera wrote:
>>>>>>
>>>>>> As those computers never had any i8042 controllers, and the
>>>>>> current lookup code could potentially lock up/hang/wait for
>>>>>> timeout for long periods of time.
>>>>>>
>>>>>> Fixes intermittent hangs on boot on a MacbookAir1,1
>>>>>>
>>>>>> Signed-off-by: Bastien Nocera<[email protected]>
>>>>>
>>>>> I assume this is happening because of this code in
>>>>> drivers/input/serio/i8042-x86ia64io.h:
>>>>>
>>>>> if (!i8042_pnp_kbd_devices&& !i8042_pnp_aux_devices) {
>>>>> i8042_pnp_exit();
>>>>> #if defined(__ia64__)
>>>>> return -ENODEV;
>>>>> #else
>>>>> printk(KERN_INFO "PNP: No PS/2 controller found.
>>>>> Probing ports directly.\n");
>>>>> return 0;
>>>>> #endif
>>>>>
>>>>> In other words, on x86, if PNP and/or ACPI don't indicate any PS/2
>>>>> controller exists, we randomly bang on the ports in the expectation
>>>>> they'll be there anyway. This seems rather misguided.
>>>>
>>>> Basically, we do not trust BIOS writers on x86 ;) In the past there were
>>>> occasions when they forgot to mention presence of KBD/AUX in DSDT and
>>>> elsewhere which lead to non-functional keyboard/mouse.
>>>
>>> Are we certain about that? Any pointers to reports?
>>>
>>>>
>>>>> It would seem
>>>>> like a better idea to fix this rather than adding yet another DMI
>>>>> list (especially since there likely are, or will be, machines
>>>>> without i8042 other than Macs).
>>>>>
>>>>
>>>> If they are not Macs that mean they are tested with windows and thus
>>>> expect probes in i8042 port region so no harm done. In a few years if
>>>> everyone uses USB only we could add a year threshold to trust ACPI/PNP
>>>> data.
>>>
>>> Macs will be tested with Windows too, so obviously it manages to avoid
>>> this problem somehow, and I very much doubt it has an Apple-specific
>>> check..
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to [email protected]
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>
>> I've an iMac, and a macbook over here,
>> if you guys need me to test out a patch for this let me know.
>
> Can you (and probably Bastien or whoever had the problematic machine)
> check the output of:
>
> cat /sys/bus/pnp/devices/*/id
>
> and see if any of these are present?
>
> PNP0303
> PNP030b
> FJC6000
> FJC6001
> PNP0f03
> PNP0f0b
> PNP0f0e
> PNP0f12
> PNP0f13
> PNP0f19
> PNP0f1c
> SYN0801
>
both macbook pro, and iMac9,1
have:
PNP0a08
PNP0a03
Justin P. Mattock
On Thu, 2010-01-21 at 17:20 -0800, Justin P. Mattock wrote:
> On 01/21/10 16:29, Robert Hancock wrote:
<snip>
> > cat /sys/bus/pnp/devices/*/id
> >
> > and see if any of these are present?
> >
> > PNP0303
> > PNP030b
> > FJC6000
> > FJC6001
> > PNP0f03
> > PNP0f0b
> > PNP0f0e
> > PNP0f12
> > PNP0f13
> > PNP0f19
> > PNP0f1c
> > SYN0801
> >
>
>
> both macbook pro, and iMac9,1
> have:
> PNP0a08
> PNP0a03
# cat /sys/bus/pnp/devices/*/id
PNP0a08
PNP0a03
PNP0c02
APP0001
PNP0200
INT0800
PNP0103
PNP0c01
PNP0c04
PNP0c02
PNP0b00
On a MacbookAir1,1
On Thu, Jan 21, 2010 at 8:09 PM, Bastien Nocera <[email protected]> wrote:
> On Thu, 2010-01-21 at 17:20 -0800, Justin P. Mattock wrote:
>> On 01/21/10 16:29, Robert Hancock wrote:
> <snip>
>> > cat /sys/bus/pnp/devices/*/id
>> >
>> > and see if any of these are present?
>> >
>> > PNP0303
>> > PNP030b
>> > FJC6000
>> > FJC6001
>> > PNP0f03
>> > PNP0f0b
>> > PNP0f0e
>> > PNP0f12
>> > PNP0f13
>> > PNP0f19
>> > PNP0f1c
>> > SYN0801
>> >
>>
>>
>> both macbook pro, and iMac9,1
>> have:
>> PNP0a08
>> PNP0a03
>
> # cat /sys/bus/pnp/devices/*/id
> PNP0a08
> PNP0a03
> PNP0c02
> APP0001
> PNP0200
> INT0800
> PNP0103
> PNP0c01
> PNP0c04
> PNP0c02
> PNP0b00
>
> On a MacbookAir1,1
So it doesn't report any keyboard or mouse controller. You're sure
that "PNP: No PS/2 controller found" message doesn't show up?
On 01/21/10 18:09, Bastien Nocera wrote:
> On Thu, 2010-01-21 at 17:20 -0800, Justin P. Mattock wrote:
>> On 01/21/10 16:29, Robert Hancock wrote:
> <snip>
>>> cat /sys/bus/pnp/devices/*/id
>>>
>>> and see if any of these are present?
>>>
>>> PNP0303
>>> PNP030b
>>> FJC6000
>>> FJC6001
>>> PNP0f03
>>> PNP0f0b
>>> PNP0f0e
>>> PNP0f12
>>> PNP0f13
>>> PNP0f19
>>> PNP0f1c
>>> SYN0801
>>>
>>
>>
>> both macbook pro, and iMac9,1
>> have:
>> PNP0a08
>> PNP0a03
>
> # cat /sys/bus/pnp/devices/*/id
> PNP0a08
> PNP0a03
> PNP0c02
> APP0001
> PNP0200
> INT0800
> PNP0103
> PNP0c01
> PNP0c04
> PNP0c02
> PNP0b00
>
> On a MacbookAir1,1
>
>
duh!! I only did one device
here's the two machines I have:
iMac9,1
PNP0a08
PNP0a03
PNP0c02
APP0001
PNP0200
PNP0103
PNP0c01
PNP0c04
PNP0c02
PNP0b00
MacBookPro2,2
PNP0a08
PNP0a03
PNP0c02
APP0001
PNP0200
INT0800
PNP0103
PNP0c01
PNP0c04
PNP0c02
PNP0b00
Justin P. Mattock
On Thu, 2010-01-21 at 20:30 -0600, Robert Hancock wrote:
<snip>
> So it doesn't report any keyboard or mouse controller. You're sure
> that "PNP: No PS/2 controller found" message doesn't show up?
Probably wrong kernel I was testing. I get, on an older kernel:
PNP: No PS/2 controller found. Probing ports directly.
So it would poke at it directly, which might cause hangs. The symptoms
is that, sometimes, the machine will hang on boot until I press the
power button, when it would continue.
Let me know if you know another way to blacklist the i8042 probing on
those machines...
On 01/21/2010 04:26 PM, Robert Hancock wrote:
>>
>> This is from the changelog when this was introduced:
>>
>> -------------------------------------------------------------------------
>> 2005/02/25 21:21:03+01:00 vojtech
>> input: After testing on real world hardware, it's obvious we can't trust
>> ACPIPnP nor PnPBIOS to properly report the existence of a keyboard
>> and mouse port in all cases. Some BIOSes hide the ports if no mouse
>> or keyboard is connected, causing trouble with eg. KVM switches.
>
> If it's just that case (which isn't certain given Vojtech's report),
> then I think it's reasonable to ignore that by default. If the BIOS
> decided to hide the controller then our default behavior should be to
> believe it, with the ability to override that if necessary, not the
> other way around.
>
You think it's reasonable to have the keyboard not work because
someone's KVM switch was in the wrong position when the system booted?
Sorry, that's not how the world works. It's sad that someone had the
bright idea that things should work that way, but that is definitely a
regression I wouldn't want to deal with.
The only thing that I could think of as a reasonable limit would be to
not probe these ports if we are booted from EFI/UEFI. That would cover
the ia64 case, too. However, I'm hardly confident that we wouldn't have
the same class of problems even there.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Fri, 2010-01-22 at 09:46 -0800, H. Peter Anvin wrote:
> On 01/21/2010 04:26 PM, Robert Hancock wrote:
> >>
> >> This is from the changelog when this was introduced:
> >>
> >> -------------------------------------------------------------------------
> >> 2005/02/25 21:21:03+01:00 vojtech
> >> input: After testing on real world hardware, it's obvious we can't trust
> >> ACPIPnP nor PnPBIOS to properly report the existence of a keyboard
> >> and mouse port in all cases. Some BIOSes hide the ports if no mouse
> >> or keyboard is connected, causing trouble with eg. KVM switches.
> >
> > If it's just that case (which isn't certain given Vojtech's report),
> > then I think it's reasonable to ignore that by default. If the BIOS
> > decided to hide the controller then our default behavior should be to
> > believe it, with the ability to override that if necessary, not the
> > other way around.
> >
>
> You think it's reasonable to have the keyboard not work because
> someone's KVM switch was in the wrong position when the system booted?
> Sorry, that's not how the world works. It's sad that someone had the
> bright idea that things should work that way, but that is definitely a
> regression I wouldn't want to deal with.
>
> The only thing that I could think of as a reasonable limit would be to
> not probe these ports if we are booted from EFI/UEFI. That would cover
> the ia64 case, too. However, I'm hardly confident that we wouldn't have
> the same class of problems even there.
Then I would guess that you think the manner in which I disabled the
i8042 checks in the original patch is viable/mergeable?
/Bastien, not sure who would have the last word
On Fri, Jan 22, 2010 at 11:46 AM, H. Peter Anvin <[email protected]> wrote:
> On 01/21/2010 04:26 PM, Robert Hancock wrote:
>>>
>>> This is from the changelog when this was introduced:
>>>
>>> -------------------------------------------------------------------------
>>> 2005/02/25 21:21:03+01:00 vojtech
>>> input: After testing on real world hardware, it's obvious we can't trust
>>> ? ? ? ACPIPnP nor PnPBIOS to properly report the existence of a keyboard
>>> ? ? ? and mouse port in all cases. Some BIOSes hide the ports if no mouse
>>> ? ? ? or keyboard is connected, causing trouble with eg. KVM switches.
>>
>> If it's just that case (which isn't certain given Vojtech's report),
>> then I think it's reasonable to ignore that by default. If the BIOS
>> decided to hide the controller then our default behavior should be to
>> believe it, with the ability to override that if necessary, not the
>> other way around.
>>
>
> You think it's reasonable to have the keyboard not work because
> someone's KVM switch was in the wrong position when the system booted?
> Sorry, that's not how the world works. ?It's sad that someone had the
> bright idea that things should work that way, but that is definitely a
> regression I wouldn't want to deal with.
I don't imagine most KVM switches would result in this - they usually
emulate the presence of a keyboard and mouse on all ports even if the
input isn't the active one. It could be the reporter had an older
switch that didn't do this.
I expect that it's quite common for the BIOS to disable the controller
if no device is detected, though. I think the idea is to prevent a
useless device from showing up in Device Manager and free up resources
for other devices. Problem is if it does this, we don't really know
what it did other than remove the PNP entry, and whether using the
controller anyway will work safely.
In any case, it's unlikely (though I admit I'm uncertain) that Windows
is going to blindly probe for an 8042 controller if the PNP
information doesn't indicate that one should be there - at least not
if it's using the ACPI HAL. And for this sort of hardware
compatibility issue, doing things differently than Windows does is
ultimately asking for trouble in the long term. It's highly
unreasonable to break that just for an unlikely corner case.
>
> The only thing that I could think of as a reasonable limit would be to
> not probe these ports if we are booted from EFI/UEFI. ?That would cover
> the ia64 case, too. ?However, I'm hardly confident that we wouldn't have
> the same class of problems even there.
>
> ? ? ? ?-hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. ?I don't speak on their behalf.
>
>
On 01/22/2010 02:33 PM, Robert Hancock wrote:
>>
>> You think it's reasonable to have the keyboard not work because
>> someone's KVM switch was in the wrong position when the system booted?
>> Sorry, that's not how the world works. It's sad that someone had the
>> bright idea that things should work that way, but that is definitely a
>> regression I wouldn't want to deal with.
>
> I don't imagine most KVM switches would result in this - they usually
> emulate the presence of a keyboard and mouse on all ports even if the
> input isn't the active one. It could be the reporter had an older
> switch that didn't do this.
>
The good ones do. The bad (cheap) ones just provide for a basic
electric disconnect. Heck, there used to be mechanical KVMs...
> I expect that it's quite common for the BIOS to disable the controller
> if no device is detected, though. I think the idea is to prevent a
> useless device from showing up in Device Manager and free up resources
> for other devices. Problem is if it does this, we don't really know
> what it did other than remove the PNP entry, and whether using the
> controller anyway will work safely.
>
> In any case, it's unlikely (though I admit I'm uncertain) that Windows
> is going to blindly probe for an 8042 controller if the PNP
> information doesn't indicate that one should be there - at least not
> if it's using the ACPI HAL. And for this sort of hardware
> compatibility issue, doing things differently than Windows does is
> ultimately asking for trouble in the long term. It's highly
> unreasonable to break that just for an unlikely corner case.
It's not unlikely - it's reality. Furthermore, BIOS programmers do
weird things all the time, especially to support, say, old Windows
versions that noone cares about anymore but mattered then.
-hpa
On Thu, Jan 21, 2010 at 02:17:01PM -0800, Dmitry Torokhov wrote:
> This is from the changelog when this was introduced:
>
> -------------------------------------------------------------------------
> 2005/02/25 21:21:03+01:00 vojtech
> input: After testing on real world hardware, it's obvious we can't trust
> ACPIPnP nor PnPBIOS to properly report the existence of a keyboard
> and mouse port in all cases. Some BIOSes hide the ports if no mouse
> or keyboard is connected, causing trouble with eg. KVM switches.
>
> The i8042 driver now does read-only probing first, which should
> not cause any problems even if an i8042 controller really is not
> present.
>
> However, on IA64 we still need to trust ACPI, since legacy-free
> hardware is common there and invalid port accesses cause exceptions.
>
> Signed-off-by: Vojtech Pavlik <[email protected]>
>
> >> Input: Add ACPI-based i8042 keyboard and aux controller enumeration;
> > > can be disabled by passing i8042.noacpi as a boot parameter.
> >
> > On a whim I decided to turn on ACPI, only to discover that my keyboard
> > no longer worked. Passing i8042.noacpi=1 makes it work again.
> > Attached please find boot messages with and without the boot
> > parameter. Inlined below is a diff of the two.
>
> --------------------------------------------------------------------------
>
> I'm adding Vojtech in case he manages to recall what other failures he
> has seen.
I don't think I can really recall what other problems we've had back
then, but I do remember it was quite an avalanche of mails that I've
started receiving after enabling the PnPBIOS/ACPIPnP probing and
trusting it fully.
Now, from the hardware point of view it doesn't make much sense for the
BIOS to hide/disable the i8042 controller, as both the keyboard IRQ and
the 0x60-0x6f address space are reserved for it (since the IBM PC/AT
times) and no other hardware can make use of those on an x86
architecture.
And this means that even on a Mac there should be no hardware present on
these addresses if there is no i8042 and Apple is claiming x86
compatibility.
Thus I believe that the right fix here is to figure out why the accesses
to the ports 0x60/0x64 take a long time or forever on a Mac. Is it just
that the kernel is timing out waiting for the i8042? Or is it something
more sinister?
--
Vojtech Pavlik
Director SuSE Labs
On 01/25/2010 08:34 AM, Vojtech Pavlik wrote:
>
> Thus I believe that the right fix here is to figure out why the accesses
> to the ports 0x60/0x64 take a long time or forever on a Mac. Is it just
> that the kernel is timing out waiting for the i8042? Or is it something
> more sinister?
>
In the A20 code in the setup code, I look for 0xFF coming back and
terminate the "wait for ready" loop much sooner than for other values.
0xFF is a *possible* status value, but not a very *likely* one
(especially for repeated reads), as it would represent:
parity error + receive timeout + transmit timeout + keyboard lock +
command + selftest OK + input full + output full.
-hpa
On Mon, Jan 25, 2010 at 01:32:42PM -0800, H. Peter Anvin wrote:
> On 01/25/2010 08:34 AM, Vojtech Pavlik wrote:
> >
> > Thus I believe that the right fix here is to figure out why the accesses
> > to the ports 0x60/0x64 take a long time or forever on a Mac. Is it just
> > that the kernel is timing out waiting for the i8042? Or is it something
> > more sinister?
> >
>
> In the A20 code in the setup code, I look for 0xFF coming back and
> terminate the "wait for ready" loop much sooner than for other values.
> 0xFF is a *possible* status value, but not a very *likely* one
> (especially for repeated reads), as it would represent:
>
> parity error + receive timeout + transmit timeout + keyboard lock +
> command + selftest OK + input full + output full.
>
You allow up to 32 0xFFs while i8042 driver does maximum 16 reads of
whatever - if OBF is still raised we assume i8042 is not there. Does
that mean that reads from 0x60 is what hurts on Macs?
Bastien, could you try modifying drivers/input/serio/i8042.c::
i8042_flush() to not call i8042_read_data() when str is 0xff and see if
it helps with lockups?
Thanks.
--
Dmitry
On 01/25/2010 02:15 PM, Dmitry Torokhov wrote:
> On Mon, Jan 25, 2010 at 01:32:42PM -0800, H. Peter Anvin wrote:
>> On 01/25/2010 08:34 AM, Vojtech Pavlik wrote:
>>>
>>> Thus I believe that the right fix here is to figure out why the accesses
>>> to the ports 0x60/0x64 take a long time or forever on a Mac. Is it just
>>> that the kernel is timing out waiting for the i8042? Or is it something
>>> more sinister?
>>>
>>
>> In the A20 code in the setup code, I look for 0xFF coming back and
>> terminate the "wait for ready" loop much sooner than for other values.
>> 0xFF is a *possible* status value, but not a very *likely* one
>> (especially for repeated reads), as it would represent:
>>
>> parity error + receive timeout + transmit timeout + keyboard lock +
>> command + selftest OK + input full + output full.
>>
>
> You allow up to 32 0xFFs while i8042 driver does maximum 16 reads of
> whatever - if OBF is still raised we assume i8042 is not there. Does
> that mean that reads from 0x60 is what hurts on Macs?
>
> Bastien, could you try modifying drivers/input/serio/i8042.c::
> i8042_flush() to not call i8042_read_data() when str is 0xff and see if
> it helps with lockups?
>
We should never read from port 0x60 unless bit 1 in port 0x64 is set.
Do we do that?
-hpa
On Mon, Jan 25, 2010 at 02:18:40PM -0800, H. Peter Anvin wrote:
> On 01/25/2010 02:15 PM, Dmitry Torokhov wrote:
> > On Mon, Jan 25, 2010 at 01:32:42PM -0800, H. Peter Anvin wrote:
> >> On 01/25/2010 08:34 AM, Vojtech Pavlik wrote:
> >>>
> >>> Thus I believe that the right fix here is to figure out why the accesses
> >>> to the ports 0x60/0x64 take a long time or forever on a Mac. Is it just
> >>> that the kernel is timing out waiting for the i8042? Or is it something
> >>> more sinister?
> >>>
> >>
> >> In the A20 code in the setup code, I look for 0xFF coming back and
> >> terminate the "wait for ready" loop much sooner than for other values.
> >> 0xFF is a *possible* status value, but not a very *likely* one
> >> (especially for repeated reads), as it would represent:
> >>
> >> parity error + receive timeout + transmit timeout + keyboard lock +
> >> command + selftest OK + input full + output full.
> >>
> >
> > You allow up to 32 0xFFs while i8042 driver does maximum 16 reads of
> > whatever - if OBF is still raised we assume i8042 is not there. Does
> > that mean that reads from 0x60 is what hurts on Macs?
> >
> > Bastien, could you try modifying drivers/input/serio/i8042.c::
> > i8042_flush() to not call i8042_read_data() when str is 0xff and see if
> > it helps with lockups?
> >
>
> We should never read from port 0x60 unless bit 1 in port 0x64 is set.
> Do we do that?
No, we don't read of OBF is 0. Incidentially 0xff has it set ;) so we do
try reading data port.
--
Dmitry
On 01/25/2010 02:30 PM, Dmitry Torokhov wrote:
>>
>> We should never read from port 0x60 unless bit 1 in port 0x64 is set.
>> Do we do that?
>
> No, we don't read of OBF is 0. Incidentially 0xff has it set ;) so we do
> try reading data port.
>
What do you do after reading the data port? In the case of the A20
code, we do dummy reads and loop until the data port drains (0xff of
course means it never drains...)
Note that it is quite likely the A20 code never gets exercised on Apple
boxes, since we only run it if A20 is disabled on entry, *and* the BIOS
doesn't implement INT 15h AX=2401h.
-hpa
On Mon, Jan 25, 2010 at 03:05:31PM -0800, H. Peter Anvin wrote:
> On 01/25/2010 02:30 PM, Dmitry Torokhov wrote:
> >>
> >> We should never read from port 0x60 unless bit 1 in port 0x64 is set.
> >> Do we do that?
> >
> > No, we don't read of OBF is 0. Incidentially 0xff has it set ;) so we do
> > try reading data port.
> >
>
> What do you do after reading the data port? In the case of the A20
> code, we do dummy reads and loop until the data port drains (0xff of
> course means it never drains...)
>
/*
* i8042_flush() flushes all data that may be in the keyboard and mouse
* buffers
* of the i8042 down the toilet.
*/
static int i8042_flush(void)
{
unsigned long flags;
unsigned char data, str;
int i = 0;
spin_lock_irqsave(&i8042_lock, flags);
while (((str = i8042_read_status()) & I8042_STR_OBF) && (i < I8042_BUFFER_SIZE)) {
udelay(50);
data = i8042_read_data();
i++;
dbg("%02x <- i8042 (flush, %s)", data,
str & I8042_STR_AUXDATA ? "aux" : "kbd");
}
spin_unlock_irqrestore(&i8042_lock, flags);
return i;
}
...
static int i8042_controller_check(void)
{
if (i8042_flush() == I8042_BUFFER_SIZE) {
printk(KERN_ERR "i8042.c: No controller found.\n");
return -ENODEV;
}
return 0;
}
--
Dmitry
On 01/25/2010 03:28 PM, Dmitry Torokhov wrote:
>
> /*
> * i8042_flush() flushes all data that may be in the keyboard and mouse
> * buffers
> * of the i8042 down the toilet.
> */
>
> static int i8042_flush(void)
> {
> unsigned long flags;
> unsigned char data, str;
> int i = 0;
>
> spin_lock_irqsave(&i8042_lock, flags);
>
> while (((str = i8042_read_status()) & I8042_STR_OBF) && (i < I8042_BUFFER_SIZE)) {
> udelay(50);
> data = i8042_read_data();
> i++;
> dbg("%02x <- i8042 (flush, %s)", data,
> str & I8042_STR_AUXDATA ? "aux" : "kbd");
> }
>
> spin_unlock_irqrestore(&i8042_lock, flags);
>
> return i;
> }
>
Given that I would say it's pretty safe to say the A20 code doesn't get
executed on these boxes, so I don't think there is anything I can add
here, unfortunately.
-hpa