On Thu, May 13, 2010 at 08:04:15AM -0700, Linus Torvalds wrote:
quoted text
> 
> 
> 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.

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