On Thu, Jan 21, 2010 at 03:39:25PM -0600, Robert Hancock wrote:
quoted text
> On Thu, Jan 21, 2010 at 12:55 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> 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<hadess@hadess.net>
> >>
> >> 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 <vojtech@suse.cz>

quoted text
>> 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.

quoted text
> >
> >> 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
--
unsubscribe notice
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/