[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100513155031.GA22238@core.coreip.homeip.net>
Date: Thu, 13 May 2010 08:50:31 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Bastien Nocera <hadess@...ess.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-input@...r.kernel.org
Subject: Re: [git pull] Input updates for 2.6.34-rc6
On Thu, May 13, 2010 at 08:04:15AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 13 May 2010, Bastien Nocera wrote:
> >
> > Maybe you didn't update to the latest firmwares on you Mac Mini, and
> > didn't see the problem with the updated BIOSes, I don't know.
>
> I can't update the firmware, since it's some random OS X program that does
> it (and I don't have OS X on the machine).
>
> But where does it lock up? During the boot probing? Or does it probe as
> having a keyboard because Apple added some crazy SMM code to try to
> emulate one with USB?
>
> Afaik, the Apple hardware actually does _physically_ have a keyboard
> controller (it's on the regular intel southbridge silicon, afaik), it just
> isn't connected to anything. And I think it is turned off in some of the
> southbridge control registers. The control registers also allow trapping
> into SMI when accessing the keyboard control registers, and maybe Apple
> screwed up there somewhere.
>
> On one of my Mac Mini's (didn't check the other), I get this:
>
> [ 2.955087] PNP: No PS/2 controller found. Probing ports directly.
> [ 2.958475] i8042.c: No controller found.
> [ 2.960998] mice: PS/2 mouse device common for all mice
>
> what do you get?
>
> The thing is, there's a _lot_ of machines out there with no legacy
> keyboard support. They tend to work.
Indeed most of them do just work. My Dell T110 for example boots just
fine and it only has USB, no PS/2 ports. However there is a rather
important difference I think - these other boxes are supposed to work
with multiple versions of Windows which, as far as I know, do probe for
the i8042. Apple only supports bootcamp on certain BIOSes and does not
really expect anything to touch these ports.
> We have timeouts for the i8042
> commands we do during init, but maybe we missed some case. And maybe we
> could easily add some extra tests too.
>
> A few printk's in the i8042 init routines to show where it locks up would
> be good.. I assume you did that already if you and Dmitry already tried to
> debug this. Where's the original thread?
>
>From what I remember (it was a few weeks old thread) we were hanging
when trying to read from the controller in i8042_flush(). Normally, if
controller isn't there we'd get a stream of 0xff which will never
"clear" and so after 32 reads we give up and abort controller
initialization. But on Bastien's box it just sits there.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists