Bug 15770
Summary: | PS/2 peripherals not powered off - Asus M2N-E motherboard | ||
---|---|---|---|
Product: | Drivers | Reporter: | Bruno Jacquet (maxijac) |
Component: | Input Devices | Assignee: | Lan Tianyu (tianyu.lan) |
Status: | NEEDINFO --- | ||
Severity: | blocking | CC: | acelists, alan, bonesisaac1982, dmitry.torokhov, florian, lenb, m.b.anti666, maciej.rutecki, patryk, rjw, rui.zhang, tianyu.lan |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.10 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 14885 | ||
Attachments: |
acpidump
https://docs.digitalocean.com/reference/api/api-reference/#section/Introduction/Requests |
Description
Bruno Jacquet
2010-04-12 17:17:22 UTC
the lights went out on 2.6.32 and stopped going out using 2.6.33? Please show the output from "cat /proc/acpi/wakeup" for the old and new kernels. I don't have the 2.6.32 installed right now but I think it started when I switched to 2.6.33. I have another kernel installed : 2.6.27.46, with this one, no problem, lights go out (all of the 3 LED blink then all shut doww with previous kernels, with 2.6.33 there's no blink, it just stays with NumLock on and nothing happens) If you want me to reinstall a 2.6.32 I can. Here are my results for /proc/acpi/wakeup : Device S-state Status Sysfs node HUB0 S5 disabled pci:0000:00:06.0 XVR0 S5 disabled pci:0000:00:0f.0 XVR1 S5 disabled XVR2 S5 disabled XVR3 S5 disabled XVR4 S5 disabled XVR5 S5 disabled UAR1 S5 disabled pnp:00:08 PS2K S4 disabled pnp:00:0a USB0 S4 disabled pci:0000:00:02.0 USB2 S4 disabled pci:0000:00:02.1 AZAD S5 disabled pci:0000:00:06.1 MMAC S5 disabled pci:0000:00:08.0 Both 2.6.27 and 2.6.33 gave the same output ( I diffed them ) Could it be a kernel .config in ACPI section problem ? (I've tried to find an option about shutdown of peripherals but didn't find any) In 2.6.33 input switched from full reset to "light" reset for keyboards and mice. During full reset of the keyboard LEDs blink and then are turned off automatically, "light" reset does not do that. However the fact that LEDs on keyboard are turned off does not prove that we powered off PS/2 ports... It looks like you're right Dmitry. With 2.6.27 (that I thought was successfully shutting down my keyboard), LEDs are reinitialized and then none are glowing but if I plug my USB (converted to PS/2) mouse, the light on it is still glowing... So even with 2.6.27 my PS/2 peripherals are still powered. So where can the problem be ? Is it really a kernel bug ? Or a BIOS configuration ? Or even a Motherboard/Alimentation hardware problem ? I _think_ that we should be powering off PS/2 ports unless they are configured as wakeup sources, but I'll let Len to decide... In my bios configuration, I have : Power on by PS/2 Mouse -> [Disabled] Power on by PS/2 Keyboard -> [Disabled] *** Bug 15710 has been marked as a duplicate of this bug. *** please attach the output of "grep . /sys/bus/*/devices/*/power/wakeup" grep . /sys/bus/*/devices/*/power/wakeup: /sys/bus/pci/devices/0000:00:01.1/power/wakeup:disabled /sys/bus/pci/devices/0000:00:02.0/power/wakeup:disabled /sys/bus/pci/devices/0000:00:02.1/power/wakeup:disabled /sys/bus/pci/devices/0000:00:06.0/power/wakeup:disabled /sys/bus/pci/devices/0000:00:06.1/power/wakeup:disabled /sys/bus/pci/devices/0000:00:08.0/power/wakeup:enabled /sys/bus/pci/devices/0000:00:0f.0/power/wakeup:disabled /sys/bus/pnp/devices/00:05/power/wakeup:enabled /sys/bus/pnp/devices/00:08/power/wakeup:disabled /sys/bus/pnp/devices/00:0a/power/wakeup:enabled /sys/bus/usb/devices/2-4/power/wakeup:enabled /sys/bus/usb/devices/usb1/power/wakeup:enabled /sys/bus/usb/devices/usb2/power/wakeup:enabled Note that I am now using a 2.6.34 kernel. please try "echo disabled > /sys/bus/pnp/devices/00:0a/power/wakeup" and see if the problem still exists. in /proc/acpi/wakeup: PS2K S4 disabled pnp:00:0a in sysfs: /sys/bus/pnp/devices/00:0a/power/wakeup:enabled this seems to be a problem, I'll look at the code first and update my findings later. I did and the problem still exists. I even tried to disable all the devices. Thanks for your implication ;) per comment #4, clearing the "regression" flag > In my bios configuration, I have : > Power on by PS/2 Mouse -> [Disabled] > Power on by PS/2 Keyboard -> [Disabled] Hmm, then perhaps Linux is doing something wrong... I would think we'd D3 these devices on a proper shutdown... please provide the output from acpidump Created attachment 27085 [details]
acpidump
Not fixed in 2.6.35. I also have an ASUS motherboard (M2N68) - AM2+ based. The original reporter also mentions a x86_64 CPU. Maybe there is a common BIOS/ACPI problem on these boards? Issue still present in 2.6.36 Regarding what aceman told, could it be the DSDT or something similar ? (I have no clue, just suggesting) Not fixed in 2.6.37 It's great that kernel bugzilla is back. can you please verify if the problem still exists in the latest upstream kernel? Yes, the bug is still in 3.2 Confirming, still exists. Sorry, please check again whether the problem still exists in the latest kernel (v3.9-rc5). From your comments, there is no problem when use usb mouse and keyboard, right? The problem still exists in 3.8. I do not have USB keyboard, but the original reported seems to say USB is fine. We both report the problem is on PS/2. How about these device status after cool shut down and not boot up? What do you mean? The computer is completely shut down but the Num lock keyboard LED still glows. Of course the computer is still plugged to the mains and devides that charge through USB ports get power. (In reply to comment #25) > What do you mean? I mean power off the machine > The computer is completely shut down but the Num lock keyboard LED still > glows. > Of course the computer is still plugged to the mains and devices that charge > through USB ports get power. How about cut the power (unplugged to the mains) and then repower the machine but not boot? What's these devices state? From the acpi table on this machine, there is no power resource for PS2K and PS2M. This means linux ACPI can't power off these devices. Cut power (for at least 1 min or capacitors remain charged and it is not relevant I guess) and then replug power but no boot : LED stay off. Windows can bring these devices off, would it be some kind of broken ACPI table as usual? I have no idea how windows does it. Do you have a usb keyboard and mouse? If yes, Can you try to unload these device driver and check these devices's state? Or not load drivers after boot up and check devices' states again? Any update? Since no response for a long time, close this bug as will_fix_later. What response did you expect? What kind of bug closure is this? Is the bug fixed now? Please follow Comment #28 to debug. Reopen this bug. Comment 28 is not applicable, as I have a PS/2 keyboard. Sorry, for later response. Currently, I have no good idea and hope some PS/2 expert can help. Hello, I'm actually having the same problem. I've just switched to a new keyboard which is ps/2 in turn (previously had usb keyboard and there was no problem). I have no wake-on-* enabled in bios. I have also no suspend/resume functionality compiled into the kernel. My system is: 3.10.33 #2 SMP PREEMPT Tue Mar 25 10:58:35 CET 2014 x86_64 Can I help with any debug info? *** Bug 207027 has been marked as a duplicate of this bug. *** *** Bug 206937 has been marked as a duplicate of this bug. *** *** Bug 207029 has been marked as a duplicate of this bug. *** (In reply to Mahdi Bahrami Motlagh from comment #37) > *** Bug 206937 has been marked as a duplicate of this bug. *** Simply stop opening bugs which are duplicates of this one! Hello I have a USB keyboard and mouse, and I have the same problem. It's unfortunate that the bug hasn't gone away in ten years, so where's the legendary power of Linux and its professional programmers? Alas, it is embarrassing. Woe to you Mr. Lan Tianyu, there is no driver for my keyboard and mouse for Linux, but it is for Windows. I tested Unix Free BSD, this problem did not exist there, since the source is open, you can get help from them to solve this problem. In addition, this problem is due to sabotage when Mr. Linus Torvalds wrote code for the inputs. |