Input updates for 2.6.34-rc6
in [Kernel]
|
Prev: HWPOISON for hugepage (v5)
Next: gta02: Use pcf50633 backlight driver instead of platform backlight driver.
From: Linus Torvalds on 13 May 2010 10:40 On Thu, 13 May 2010, Dmitry Torokhov wrote: > > Bastien Nocera (1): > Input: i8042 - do not try to probe ports on Intel Apple Macs I pulled, but I skipped the last commit, because I think this one is fundamentally _wrong_. It is _not_ maintainable to create random tables of exceptions ("DMI tables"), and it's actively _wrong_ to do for something like this where we not only have historically worked perfectly well, and this apparently tries to hide some other bug (the commit says "could potentially lock up/hang/wait for timeout for long periods of time"). We should fix the problems instead of hiding them for specific machines. Does anybody really think that Apple machines are the only ones with no legacy keyboard? Hello? Does anybody seriously think that it's ok to add entries to DMI tables for random new machines coming out? So I think that commit was (a) totally inappropriate to send at this point in the late -rc series _anyway_ (it sure as hell isn't a refression fix), and that makes me wonder about the other ones. But (b) I don't think I want to ever see anything like that during a merge window either, because it's quite seriously the wrong thing to do. What are the _actual_ problems on legacy-free machines? And keep in mind that I ask that exactly because I actually _have_ two Apple Mac Mini's in my household, and have never seen any problems with keyboard/mouse handling. So if somebody saw "could potentially lock up/hang/wait" issues, then dangit, say what those issues are, AND LET'S FIX THEM! And not like this, trying to hide them for some particular machines, rather than fixing the actual underlying detection bug. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bastien Nocera on 13 May 2010 10:50 On Thu, 2010-05-13 at 07:35 -0700, Linus Torvalds wrote: > > On Thu, 13 May 2010, Dmitry Torokhov wrote: > > > > Bastien Nocera (1): > > Input: i8042 - do not try to probe ports on Intel Apple Macs > > I pulled, but I skipped the last commit, because I think this one is > fundamentally _wrong_. > > It is _not_ maintainable to create random tables of exceptions ("DMI > tables"), and it's actively _wrong_ to do for something like this where we > not only have historically worked perfectly well, and this apparently > tries to hide some other bug (the commit says "could potentially lock > up/hang/wait for timeout for long periods of time"). <snip> > So if somebody saw "could potentially lock up/hang/wait" issues, then > dangit, say what those issues are, AND LET'S FIX THEM! And not like this, > trying to hide them for some particular machines, rather than fixing the > actual underlying detection bug. I'm waiting for your debug instructions on that one, because we already looked at that with Dmitry. I already got that patch in my distribution, and now my machine boots up uninterrupted. The lock is somewhat random, and will go away as soon as I press the power button on my machine. 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 13 May 2010 11:10 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. 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? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 13 May 2010 11:30 On Thu, 13 May 2010, Linus Torvalds wrote: > > 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? Hah. On the other one, I get PNP: No PS/2 controller found. Probing ports directly. mice: PS/2 mouse device common for all mice but that works fine too. As mentioned, the controller hardware should all be there - whether it's then enabled or not is a firmware issue. At the same time, I do think our detection is likely pretty dang weak too. Do you get any interesting messages if you just enable DEBUG in drivers/input/serio/i8042.h? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 13 May 2010 12:00
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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |