[Bug 760729] New: Issues with mouse and powermanagement
https://bugzilla.novell.com/show_bug.cgi?id=760729 https://bugzilla.novell.com/show_bug.cgi?id=760729#c0 Summary: Issues with mouse and powermanagement Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: i586 OS/Version: openSUSE 12.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: schaefer.frank@gmx.net QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0 I'm observing the following strange mouse behavior related to powermanagement: When I unplug the power connector of my netbook, the mouse stops working (can't move the pointer anymore). The USB-port seems to be suspended. The mouse only wakes up again, when I click a button, but when I stop moving the pointer, the devices immediately suspends again (after ~2s). The expected behavior would be a) the mouse wakes up when moving the pointer (preferred) b) longer interval until the mouse is suspended again (if a) is not possible) c) no autosupend of the mouse (if a) and b) are not possible) The second issue is, that when I unplug and replug the mouse (with the power connector still disconnected), everything works fine. The mouse seems to be never suspended. I can see no reason why the mouse should behave different after an unplugg-replug cycle. I tested 3 different USB-mouses and the behavior was always the same. I also tried kernel 3.3.4 and 3.4-rc5. Im using KDE 4.7.4 with default powermanagement settings. Reproducible: Always -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c
kk zhang
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c
Andreas Jaeger
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c
Jeff Mahoney
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c1
Oliver Neukum
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c2
Frank Schäfer
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c3
Oliver Neukum
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c4
--- Comment #4 from Frank Schäfer
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c5
Frank Schäfer
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c6
--- Comment #6 from Frank Schäfer
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c7
Rafael Wysocki
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c8
Frank Schäfer
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c9
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c10
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c11
Frank Schäfer
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c12
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c13
--- Comment #13 from Frank Schäfer
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c14
--- Comment #14 from Joey Lee
BIOS seem to be the latest one: Version: 04MY You may want to double check, though.
Even it may "only" produce some nasty error messages in syslog (still has to be verified once ACPI table overriding is easier). The missing VDRV declaration is unfortunate and should get fixed in BIOS (I guess the only way to get it fixed).
Afaik we do not have that much contacts to Samsung. If, Joey may know.
Yes! we do NOT have any contact with Samsung, now. And, Samsung also never leak their ACPI/WMI spec to SUSE and kernel upstream. For this issue, another thing worth to try is always turn on the power of usb port: echo on > /sys/bus/usb/devices/usb1/power/level echo on > /sys/bus/usb/devices/usb2/power/level ... echo on > /sys/bus/usb/devices/usb?/power/level (dependent on how many usb port on issue machine) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c17
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c18
--- Comment #18 from Frank Schäfer
I close this one won't fix for now.
Sorry...why ??? This is a severe issue. Once again Windows works fine and Linux not and you set this to WONTFIX without even considering a workaround solution (although it has been mentioned) ? So, why the hell should people spend time for reporting bugs like this ? Or don't you want getting bug reports ? Isn't this what openSUSE is about ? Sure, this makes life is easier for you but also your product worse. I'm just trying to understand from your point of view... SUSE is clearly on downward spiral. :-( Good luck ! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=760729 https://bugzilla.novell.com/show_bug.cgi?id=760729#c19 --- Comment #19 from Thomas Renninger2012-07-25 15:43:14 UTC --- > Sorry...why ??? Because this bug has to be fixed in BIOS! It cannot be fixed on Linux side. So these resolutions are left and all make sense: - invalid - won't fix - documented Ok, I double checked and with 12.1 it should be possible to override the DSDT BIOS table via initrd. Let's keep the emotional stuff out here to not waste peoples precious time. I'll provide details in the next comment. > without even considering a workaround solution > (although it has been mentioned) but not yet tried. So the most important info is missing in your comment. > So, why the hell should people spend time for reporting bugs like this ? Because they want things working. > SUSE is clearly on downward spiral. :-( I cannot see that. You can try to report this bug on another platform (Ubuntu, Debian, Fedora, ...), but it will take longer until things get resolved in this case and in the end the resolution will be the same. > Once again Windows works fine Sigh. Not every BIOS bug is exposed through Windows, but may be through Linux. Seldom the other way around, because vendors only test the supported OSes which mostly are only Windows. You can buy a SUSE pre-loaded HP laptop. In this case you would have full support and HP would fix this bug in BIOS within days. In fact you would never ever have run into such a stupid bug, because HP tests these models thoroughly that every single piece of hardware runs like a charm on the supported Linux versions (hundred of suspend cycles, close communication to (graphics/wireless/...) device vendors), etc. You get what you pay for..., sometimes less. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c20
--- Comment #20 from Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c21
--- Comment #21 from Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c22
--- Comment #22 from Frank Schäfer
Sorry...why ??? Because this bug has to be fixed in BIOS!
Correct me if I'm wrong, but as far as I understood we don't know yet if the bug in the BIOS is really the reason for the USB-runtime-pm issues this bug report is about ?! Shouldn't we find out first ? I will test the DSDTs you provided in comments #20 and #21 when I'm back at home and let you know the result !
It cannot be fixed on Linux side. So these resolutions are left and all make sense: - invalid - won't fix - documented
Sure, given that the first assumption is true, I agree.
Ok, I double checked and with 12.1 it should be possible to override the DSDT BIOS table via initrd. Let's keep the emotional stuff out here to not waste peoples precious time. I'll provide details in the next comment.
No emotions from my side, I'm just wondering about your attitude which seems to be against your own interests... Isn't it way to early to declare the USB-runtime-pm issues as not fixable ??? Even if the buggy BIOS is the root cause, shouldn't we try to find a workaround to make things working !? I'm sure you agree that getting a new BIOS from Samsung is (unfortunately) an illusion, epecially because Windows is working fine. Makes no sense to complain about that, we simply have to make the best of the situation. Buggy hardware/firmware is nothing unusual, that's why quirks have been introduced.
without even considering a workaround solution (although it has been mentioned) but not yet tried. So the most important info is missing in your comment.
Sorry, I will test it when my holiday is over and I'm back at home next weekend !
So, why the hell should people spend time for reporting bugs like this ? Because they want things working.
But they don't get things working when you're just setting the reports to WONTFIX instead of resolving the issue when it is possible. Then they are just wasting their time. What about YOU ? Don't YOU want things working ? ;-)
SUSE is clearly on downward spiral. :-( I cannot see that. You can try to report this bug on another platform (Ubuntu, Debian, Fedora, ...), but it will take longer until things get resolved in this case and in the end the resolution will be the same.
Unfortuneately, my experiences are different. I'm using other distros, too (Kubuntu, Fedroa) and am reporting bugs frequently. I'm afraid I have to say that openSUSEs bug management has degraded and is currently the worst of them. :-( Want an example ? See bug 727586 (security related !).
Once again Windows works fine Sigh. Not every BIOS bug is exposed through Windows, but may be through Linux. Seldom the other way around, because vendors only test the supported OSes which mostly are only Windows.
Sigh, the same old Linux mistake again. It's a desease. People don't care why things are not working and they don't have to. They just want things working. Windows works fine, Linux not. So guess what they do. We really need more pragmatism instead of narrow minds in the Linux world.
You can buy a SUSE pre-loaded HP laptop. In this case you would have full support and HP would fix this bug in BIOS within days. In fact you would never ever have run into such a stupid bug, because HP tests these models thoroughly that every single piece of hardware runs like a charm on the supported Linux versions (hundred of suspend cycles, close communication to (graphics/wireless/...) device vendors), etc.
You get what you pay for..., sometimes less.
You're misunderstanding me completely. :-( I'm involved as developer in several OpenSource projects, so I know the business. You don't pay for it, so fix it yourself or shut up. If you're lucky, someone does this for you, but you cannot claim that. But you want people to pay for your products, right ? So you should be interested in getting things working, right ? And you're setting this to WONTFIX at this early point ? Hmmmm... Just my two cents... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c23
--- Comment #23 from Frank Schäfer
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c24
--- Comment #24 from Frank Schäfer
... For this issue, another thing worth to try is always turn on the power of usb port:
echo on > /sys/bus/usb/devices/usb1/power/level ...
Ssetting level to "on" causes the mouse to wake up again (as expected). So the question is what prevents the mouse from waking up when moving it ? Concerning the second issue: (From bug description)
... when I unplug and replug the mouse (with the power connector still disconnected), everything works fine. The mouse seems to be never suspended.
It seems that in this case USB runtime PM is not activated: cat control says "on" instead of "auto". I would say this is wrong, because power management policy (runtime PM enable/disable) should depend on the power state of the machine only and it shouldn't matter at which time a device is plugged in. I don't know who is responsible for enabling/disabling runtime PM. I assume userspace ? So we have two separate issues here: 1.) mouse doesn't wake up when moving it 2.) USB runtime powermanagment gets not enabled when plugging the device in AFTER the power connector has been disconnected The question is, if the BIOS bug has something to do with it or not. Thomas, I couldn't test your DSDTs from comments #20+#21: When trying to boot, I get "initramfs unpacking failed: junk in compressed archieve" -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c25
--- Comment #25 from Oliver Neukum
I don't know who is responsible for enabling/disabling runtime PM. I assume userspace ?
Yes
So we have two separate issues here: 1.) mouse doesn't wake up when moving it
Most mice are simply not capable of doing so. When they are suspended they switch off the laser and react only to buttons -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c26
--- Comment #26 from Frank Schäfer
(In reply to comment #24)
I don't know who is responsible for enabling/disabling runtime PM. I assume userspace ?
Yes
What exactly is responsible for this ?
So we have two separate issues here: 1.) mouse doesn't wake up when moving it
Most mice are simply not capable of doing so. When they are suspended they switch off the laser and react only to buttons
Hmmm... If most mice are affected, then it doesn't make much sense to enable USB auto-suspend for them, right ? At least not with the standard delay of 2s. What do you think Oliver ? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c27
--- Comment #27 from Frank Schäfer
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c28
Oliver Neukum
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c29
Thomas Renninger
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c30
--- Comment #30 from Frank Schäfer
We cannot simply close this bug. Yes, the mice don't behave as desirable. However, then our response must be to not use the features that don't work as we would like them to work.
I'm really glad to hear that. Anyway, I din't expect this to be reopened (or commented) again and we have tracked it down to two separate issues, so I created the new bug reports: Bug 776530 - Inconsistent policy concerning USB runtime powermanagement configuration Bug 776531 - Wrong timeout policy for USB auto-suspend and mice describing the issues in more detail. So we can keep this report closed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=760729
https://bugzilla.novell.com/show_bug.cgi?id=760729#c31
Oliver Neukum
participants (1)
-
bugzilla_noreply@novell.com