Most recent kernel where this bug did *NOT* occur: This happens with all the ACPI-enabled kernels I have tried. Distribution: Ubuntu 7.04 development packages FC7 development packages Hardware Environment: HP dv1240us Software Environment: Problem Description: Synaptics touchpad events do not wake the laptop from suspend state Steps to reproduce:
http://bugzilla.kernel.org/attachment.cgi?id=10990&action=view http://bugzilla.kernel.org/attachment.cgi?id=10991&action=view http://bugzilla.kernel.org/attachment.cgi?id=10996&action=view http://bugzilla.kernel.org/attachment.cgi?id=10997&action=view
Do you mean it works well with the boot option "acpi=off"? Please attach the content of /proc/acpi/wakeup.
Here you go: Device Sleep state Status PCIB 5 disabled LAN 5 disabled PS2K 3 disabled PSM1 3 disabled USB0 3 disabled USB1 3 disabled USB2 3 disabled USB7 3 disabled I just tried. Neither keyboard button presses or mousepad clicks/touches cause the machine to resume. I have to press the laptop lid button to get resume to start. I will test with acpi=off.
Using acpi=off, afaics, doesn't leave me a working suspend.
>Using acpi=off, afaics, doesn't leave me a working suspend. Sorry, my mistake. :p >PS2K 3 disabled >PSM1 3 disabled #echo PS2K > /proc/acpi/wakeup #echo PSM1 >/proc/acpi/wakeup and try again.
Is this the expected outcome? I see no change: # echo PS2K > /proc/acpi/wakeup # echo PSM1 >/proc/acpi/wakeup # cat /proc/acpi/wakeup Device Sleep state Status PCIB 5 disabled LAN 5 disabled PS2K 3 disabled PSM1 3 disabled
This patch looks like it might be helpful: http://lkml.org/lkml/2007/4/3/359
Oh, I see. They must share the same GPE. Change one of them is enough. So please try: #echo PS2K >/proc/acpi/wakeup If you got the following result Device Sleep state Status PS2K 3 enabled PSM1 3 enabled then try to resume the machine by keyboard button presses or mousepad clicks/touches. Thanks.
You are correct that PS2K and PSM1 are linked. Also, LAN and PCIB are linked, I find. I tried enabling all the USB entries as well. THe outcome is not perfect. I can now get the machine to wake by touching the keyboard and by inserting a USB device. However, touching the synaptics mousepad or pressing the mousepad buttons fails to wake up the laptop. So, is it intended that the user must enable all these wakeup settings on a per-user basis, or is it desired that the keyboard and and mouse are enabled for wakeup by default? This would certainly be my desired default. It is what laptop users are used to. I don't know whether Gnome or KDE surface these settings in their power management configuration apps. It would be great if they would. # cat /proc/acpi/wakeup Device Sleep state Status PCIB 5 enabled LAN 5 enabled PS2K 3 enabled PSM1 3 enabled USB0 3 enabled USB1 3 enabled USB2 3 enabled USB7 3 enabled
Created attachment 11241 [details] the 1st patch of getting rid of /proc/acpi/wakeup
Created attachment 11242 [details] the 2nd patch of get rid of /proc/acpi/wakeup These two patches are written by David Brownell to get rid of /proc/acpi/wakeup. Please have a try. :)
Created attachment 11243 [details] show more information in /proc/acpi/wakeup Hmmm, you'd better apply this patch as well. And attach the content of /proc/acpi/wakeup. Thanks.
Created attachment 11245 [details] update to "more info in /proc/acpi/wakeup" I'm going to attach two more patches. But mostly this is going to all be informative ... I wouldn't expect anything to change with respect to handling of those i8042 input devices, but you'll see more info about how ACPI views things. The patches "getting rid of" the wakeup file will mostly affect PCI devices on the motherboard, making it so you don't need to manually enable them in /proc/acpi/wakeup. The "more info" patches update /proc/acpi/wakeup to show the device associated with each wakeup-capable ACPI device ... modulo some glitches in the device tree support for ACPI. (This being the second of those two patches.) The other two patches (a) hook up PNP devices to their ACPI siblings, which will make /proc/acpi/wakeup show something for the i8042 devices, and (b) set up cross-links in sysfs so that such hookups, and their PCI analogues, show up too. Should help diagnostics, and be more comprehensible than ACPI table dumps. You'll likely observe that the touchpad has three (!) sysfs nodes, rather than the one you'd expect or the two found for most other PNP or PCI nodes. ... but I would really expect the root cause here to be that the i8042 stack (mouse, touchpad, keyboard, etc) is doing something wrong.
Created attachment 11246 [details] link PNP and ACPI nodes I think I submitted these patches in the wrong order; 11245 updates this one.
Created attachment 11247 [details] crosslink sysfs nodes for acpi and "real" devices
Note that if Gnome or KDE surfaces anything, it should be the /sys/devices/.../wakeup entries, not /proc/acpi/wakeup, since not every system has ACPI. Also, that requiring a manual "make the system work right" step is kind of the wrong model. Moving away from that. :)
I am doing the build now. I ran into only one patching quirk: # patch -p1 --dry-run < /home/miles/11243.patch patching file drivers/acpi/sleep/proc.c Hunk #1 succeeded at 350 (offset -10 lines). I patched in the order 11241, 11242, 11243, 11246, 11245 It'll be tomorrow when I can get down to testing. Thanks for the help! BTW, David, not sure if you remember me from the Yenta/Hotplug development days. I always enjoy working with you. Cheers, Miles
Ah. I notice I missed 11247. I've patched with it now and am proceeding.
With patches applied, this is what I get: # cat /proc/acpi/wakeup Device S-state Status Sysfs node PCIB S5 enabled pci:0000:00:1e.0 LAN S5 enabled pci:0000:01:00.0 PS2K S3 enabled pnp:00:05 PSM1 S3 enabled pnp:00:06 USB0 S3 enabled pci:0000:00:1d.0 USB1 S3 enabled pci:0000:00:1d.1 USB2 S3 enabled pci:0000:00:1d.2 USB7 S3 enabled pci:0000:00:1d.7
Created attachment 11249 [details] lspci -vv output This may help you interpret the contents of /proc/acpi/wakeup.
Cool! This build works correctly. It resumes when I use the mousepad buttons or touch the mousepad. I get the impression that these are not patches you necessarily want to submit to Linus, but this is a big improvement.
Unfortunately, this build (2.6.21-rc7 + your patches) never suspends when I press the laptop lid button. [ 1198.337000] [ACPI Debug] String: [0x08] "In _Q8A:" [ 1198.337000] [ACPI Debug] String: [0x0E] "SW3S and IGDS:" [ 1198.338000] [ACPI Debug] Integer: 0x00000000 [ 1198.338000] [ACPI Debug] Integer: 0x00000001 [ 1210.547000] [ACPI Debug] String: [0x08] "In _Q8A:" [ 1210.548000] [ACPI Debug] String: [0x0E] "SW3S and IGDS:" [ 1210.548000] [ACPI Debug] Integer: 0x00000001 [ 1210.548000] [ACPI Debug] Integer: 0x00000001 [ 1215.116000] [ACPI Debug] String: [0x08] "In _Q8A:" [ 1215.117000] [ACPI Debug] String: [0x0E] "SW3S and IGDS:" [ 1215.117000] [ACPI Debug] Integer: 0x00000000 [ 1215.117000] [ACPI Debug] Integer: 0x00000001 [ 1225.365000] [ACPI Debug] String: [0x08] "In _Q8A:" [ 1225.365000] [ACPI Debug] String: [0x0E] "SW3S and IGDS:" [ 1225.366000] [ACPI Debug] Integer: 0x00000001 [ 1225.366000] [ACPI Debug] Integer: 0x00000001 [ 1229.542000] [ACPI Debug] String: [0x08] "In _Q8A:" [ 1229.542000] [ACPI Debug] String: [0x0E] "SW3S and IGDS:" [ 1229.543000] [ACPI Debug] Integer: 0x00000000 [ 1229.543000] [ACPI Debug] Integer: 0x00000001 [ 1239.170000] [ACPI Debug] String: [0x08] "In _Q8A:" [ 1239.170000] [ACPI Debug] String: [0x0E] "SW3S and IGDS:" [ 1239.171000] [ACPI Debug] Integer: 0x00000001 [ 1239.171000] [ACPI Debug] Integer: 0x00000001
Actually I think all except the "crosslink sysfs nodes" patch are in the MM tree and queued for 2.6.22 (possibly via detours through the ACPI or driver model queues). If this resumes correctly from mousepad events ... I can't see why it had anything at all to do with these patches. (Miles, yes I remember you from remote debugging of USB related issues. The reason I got into this ACPI wake stuff was so that USB remote wake could work sanely... kind of a detour!)
Ah. I have been testing ACPI suspend/resume problems on this laptop. Since I was having severe problems with that on the most recent kernel code, I had dropped back to 2.6.20. 2.6.20 displayed the problem where my machine would only suspend every other attempt. Perhaps the resume on mousepad event problem is fixed in 2.6.21-rc7. Zhang pointed out the need to tweak settings in /proc/acpi/wakeup. So now I'll test that on vanilla 2.6.21-rc7. Still, tweaking these wakeup values is going to go away, right? It bugs me to have to hack initscripts to get devices to do the right thing. On this same laptop, I have to tweak settings to get my WIFI activation LED to light up. I also have a tweak so that the Audio Mute button LED is operational. I have written to developers to see whether these can be made to work by default, but so far they are ignoring me. :(
Okay, the "wake on synaptics mousepad event" issue is fixed for me in 2.6.21-rc7-git4. I just need to enable the right stuff in /proc/acpi/wakeup. It would be great to have at least the USB, keyboard and mousepad stuff set to wake by default.
>Still, tweaking these wakeup values is going to go away, right? That's right. :) >Unfortunately, this build (2.6.21-rc7 + your patches) never suspends when I >press the laptop lid button. That's strange. Anyway, Luming will help you debug this problem. :)
to comment#19: Hi, Miles, Did you still manually override /proc/acpi/wakeup after these patches? If so, you don't need to do it anymore. The USB, keyboard and mousepad should wake the system even if the corresponding status in /proc/acpi/wakeup is disabled. :)
Any notion about how soon these changes will land in a Linus release? Thanks!
I am still seeing this problem in 2.6.21-rc7-mm2.
As I commented before, this issue is completely unrelated to these patches. If updating the /proc/acpi/wakeup flags helps, then the root cause of the problem is that the i8042 driver stack is wakeup-unaware. Not ONE of those patches changes behavior for i8042 nodes like a synaptic touchpad. Once the 2.6.22 merges start, it will be possible to make that stack be wakeup-aware, but one issue will be that it still has some real stupidities in terms of driver model support. Specifically, that there are *THREE* device nodes where there should be just one. The three nodes are (a) a PNP node, which is ignored by the i8042 stack; (b) an ACPI node, which should probably be handled by moving the PNP node into the ACPI tree and adding some annotations; and (c) an i8042 node, which should not exist given the PNP node. This patch should probably not have been marked as "resolved", and should probably be moved over to the i8042 area ...
I was responding in light of http://bugzilla.kernel.org/show_bug.cgi?id=8286#c27 Okay, I'll reopen.
I hope I got this bug moved to the correct component. I don't see an i8042 selection.
Hi, Dave, >The three nodes are (a) a PNP node, which is ignored by the i8042 stack; >(b) an ACPI node, which should probably be handled by moving the PNP node >into the ACPI tree and adding some annotations; Do you mean you are planning to merge these two trees? Well, that's what I'm thinking about at least. Too many nodes for one device doesn't look good anyway. to Miles: at least the USB devices can wakeup the system without touching /proc/acpi/wakeup, right?
> Do you mean you are planning to merge these two trees? > Well, that's what I'm thinking about at least. I'm hoping someone else resolves those issues!! I'd hope the ACPI team would get rid of duplication between the ACPI and PNPACPI trees, but not necessarily between the PNP and i8042 trees.
Re Comment #27, evidently bugzilla discarded my email reply ... that's incorrect, none of the patches update the i8042 drivers to make them become wakeup-aware. The only drivers for which a manual update of the /proc/acpi/wakeup file is no longer necessary would be wakeup-aware PCI drivers, or certain drivers for ACPI buttons.
>I'm hoping someone else resolves those issues!! >I'd hope the ACPI team would get rid of duplication between the ACPI >and PNPACPI trees, but not necessarily between the PNP and i8042 trees. As I said, I'm investigating it. :) >Re Comment #27, evidently bugzilla discarded my email reply ... >none of the patches update the i8042 drivers to make them become wakeup-aware. I know. That's why we move this bug to i8042 area.
zhang, in reply to comment#33, yes, USB connection events do wake up 2.6.21-rc7-mm2. Thanks.
i8042 doe snot ignore PNP - it attaches to keyboard and/or mouse nodes either via PNPBIOS or PNPACPI and retrieves configuration data from there. Can we adjust PNPACPI to take care of enabling wakeup?
The i8042 code may not ignore PNP, but it doesn't actually use those nodes in a normal way. http://lkml.org/lkml/2007/4/17/357 points out that there are THREE (count'em, three!) sysfs nodes for each i8042 device. (Well, it shows it for that touchpad, but I've observed the same on other systems for keyboards and mice. Even on systems where /proc/acpi/wakeup lists the i8042 keyboard and mouse nodes.) The root cause seems to be the device_add() in the serio code: it's making new nodes in /sys/devices/platform/i8042 rather than using the PNP nodes. (I speculate that's because a few years back, having the PNP nodes was the exception not the rule ... today it's the other way around, but the driver still uses a "legacy with band-aids" driver model structure. In any case the "why" doesn't matter as much as the result.) ACPI can mark the PNP nodes as wakeup-capable -- and given pending patches, does exactly that -- but i8042 uses the node it created instead. Those are the ones associated with the input class devices, /proc/interrupts listings, etc.
The input correctly parents keyboard and mouse to i8042 (keyboard controller) as that's where they are physically attached to. PNP and ACPI nodes are auxullary and may even go away if disabled (acpi=off). i8042 could enable wakeup when attaching to PNP nodes in drivers/input/serio/i8042-x86ia64io.h but: 1. Will this facuility be available for both PBPBIOS and PNPACPI? 2. Why doesn't PNPACPI enables wakeup automatcally?
You're mixing up various issues here ... - If PNP nodes don't exist, then just fall back into a legacy mode, possibly looking pretty much like what you've got now. But when they do exist, what you're doing is "unclean" from the driver model perspective: don't device_add(), especially when you've been handed an appropriate node already! (In fact, the i8042 stack seems to like creating five nodes where two should suffice... only one AUX present.) - The ACPI nodes ... I'd suggest you don't worry about those (at least not yet!); they should eventually not duplicate the PNP nodes. - Wakeup for i8042 has two aspects. * One is device_may_wakeup(), a driver input; once the extra device nodes get sorted out, that will just work ... at least for ACPI. That's mostly a platform setup issue, other than the way userspace can overide the "wakeup enabled by default" setting. * The other is the driver awareness, and somewhere in the i8042 stack will need to be a call_platform_enable_wakeup() call on the suspend path when it may_wakeup(). (Then undoing it on the resume path.) - Why doesn't PNPACPI enable wakeup automatically? I can't answer for the "old model". But the upcoming patches *do* enable it automatically. Thing is, the driver needs to check whether user space has disabled it -- i.e. call device_may_wakeup() -- then set things up accordingly. In the general case, drivers need to do a few special things if they're going to be wakeup event sources. It's possible that i8042 is an exception, and doesn't have much to do except call the platform hook ... I wouldn't know that. On embedded platforms it's more likely that a serio suspend() method would enable_irq_wake() if it may_wakeup() and its clock can stay enabled, otherwise clk_disable(). (Though I think that i8042 clones would mostly just do the irq_wake stuff.)
It looks bugzzilla did not like my reply email... > You're mixing up various issues here ... > > - If PNP nodes don't exist, then just fall back into a legacy mode, > possibly looking pretty much like what you've got now. But when > they do exist, what you're doing is "unclean" from the driver model > perspective: don't device_add(), especially when you've been handed > an appropriate node already! (In fact, the i8042 stack seems to like > creating five nodes where two should suffice... only one AUX present.) You are mistaken here - if a box has an active multiplexing controller (which many HP's do have) then you have 4 independent AUX ports + 1 KBD port. They also physically belong to the keyboard controller (i8042) not ACPI or PNP. Therefore I do not think why I would want to use PNP nodes, especially given the fact that I am quite often 4 nodes short. You do not suggest that PCI layer stop creating device nodes and use ACPI tree instead? > > - The ACPI nodes ... I'd suggest you don't worry about those (at least > not yet!); they should eventually not duplicate the PNP nodes. > And I don't want to. > - Wakeup for i8042 has two aspects. > > * One is device_may_wakeup(), a driver input; once the extra device > nodes get sorted out, that will just work ... at least for ACPI. > That's mostly a platform setup issue, other than the way userspace > can overide the "wakeup enabled by default" setting. > > * The other is the driver awareness, and somewhere in the i8042 > stack will need to be a call_platform_enable_wakeup() call on > the suspend path when it may_wakeup(). (Then undoing it on the > resume path.) > > - Why doesn't PNPACPI enable wakeup automatically? I can't answer > for the "old model". But the upcoming patches *do* enable it > automatically. Thing is, the driver needs to check whether user > space has disabled it -- i.e. call device_may_wakeup() -- then > set things up accordingly. Well, if driver needs to check anything then it is not automatic. Anyway, I recommend adding this support to drivers/input/serio/i8042-x86ia64io.h where we setup PNP driver for AUX and KBD nodes. This will leave core i8042 blissfully unaware of PNP/ACPI.
> You are mistaken here - if a box has an active multiplexing controller (which > many HP's do have) then you have 4 independent AUX ports + 1 KBD port. Not mistaken. There's a difference between ports that are present in silicon vs those which are actually wired up. In this case, ACPI reported that only two ports (KBD, one of the AUX == touchpad) are wired. Ergo "too many". As a rule, controllers that aren't usable shouldn't show in sysfs. > also physically belong to the keyboard controller (i8042) not ACPI or PNP. > Therefore I do not think why I would want to use PNP nodes, especially given > the fact that I am quite often 4 nodes short. As above. The i8042 code is being told how many nodes *really* exist; it's not a case of being "short", the others aren't wired up/usable. A PCI analogy: sysfs won't show slots, it shows cards plugged into slots. > Well, if driver needs to check anything then it is not automatic. And as I explained: "automatic" is in general not possible. > Anyway, I recommend adding this support to > drivers/input/serio/i8042-x86ia64io.h where we > setup PNP driver for AUX and KBD nodes. That's a reasonable solution on x86 and ia64 ... given the rather strange driver structure. > This will leave core i8042 blissfully unaware of PNP/ACPI. But also: unfortunately unaware of wakeup. (And I didn't say a thing about making the core know about PNP.)
> > You are mistaken here - if a box has an active multiplexing controller (which > > many HP's do have) then you have 4 independent AUX ports + 1 KBD port. > > Not mistaken. There's a difference between ports that are present in silicon > vs those which are actually wired up. Do you have this laptop? Just for fun please plug an external mouse in it and you will be surprised (If it does not have external PS/2 ports you need to get a hold of a docking station). > In this case, ACPI reported that only two ports (KBD, one of the > AUX == touchpad) are wired. Ergo "too many". If I go by this logic I have to immediately pull external mouse from my Compaq becauase (oh horror!) it is not mentioned in ACPI and surely it is illusion that it is working. Seriously, ACPI does not care about number of AUX ports present. They share the same IRQ and the same IO ports and so look the same to ACPI. There is not a single box that I have seen that has a special DSDT because its i8042 supports active multiplexing mode. Also, I would not trust keyboard/mouse data it DSDT - in many cases they report either wrong ports or forget about IRQ, etc. If you look in i8042 you will see that most of PNP code deals with recovering from bad data provided to it.
> If I go by this logic I have to immediately pull external mouse > from my Compaq because (oh horror!) it is not mentioned in ACPI > and surely it is illusion that it is working. That strange conclusion is entirely your own invention! I was only remarking on one of the bizarre consequences of what the i8042 code now does. A mouse that's actually present should obviously be usable, and show in sysfs. It may be that the odd behavior of muxed AUX ports has some reason attributable to the hardware ... because in my small sample, non-muxed AUX ports do not have that problem of showing phantom/non-existent devices. It's certainly suggestive that the logic creating those phantom device nodes is *also* discarding platform-provided data which reports which devices are wakeup-capable, and which does not have such a "phantom device" problem. And while it does so, it also makes a mess in sysfs (one more nodes for each PS2 device). To someone not versed in the details of i8042 hardware, those look like facets of one core problem. > Also, I would not trust keyboard/mouse data it DSDT - in many > cases they report either wrong ports or forget about IRQ, etc. > If you look in i8042 you will see that most of PNP code deals > with recovering from bad data provided to it. A quick glance at that code shows that the main thing it tests for is a table not using the "standard" values for any of those resources. No wonder the table values are sometimes invalid; they were never needed, because of hardware standards that predated PNP or ACPI! But that's all beside the point. The core issue is that the i8042 code isn't wakeup-aware, and it should be. It'd be good if it were generic enough to work on non-ACPI systems.
Can anyone please tell me what the current status of this issue is?
Well, I think it's better to close it.