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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
