Bugzilla – Bug 390822
docking broken on systems with bay device in a dock station
Last modified: 2018-07-03 19:39:54 UTC
Just tried to debug with Timo: * If I undock (pressing the key on the docking station) my Thinkpad, dmesg and /var/log/messages gets send endlessly the message: "ACPI:: \_SB_.PCI0.IDE0.PRIM.MSTR: Bay event). kacpi-notify uses 100 % of cpu time, the system becomes unusable. * If I blacklist the bay module, I can undock the thinkpad. But once I redock, the system freezes completely.
This got broken once again with 2.6.25. I've got a patch for the "bay consuming 100%" (already send upstream) and will try to get it into 11.0. For the hard freeze, I still need time to debug. This is very time consuming.
Adding Duncan since he has similar hardware.
I'm working on a patch...
*** Bug 386543 has been marked as a duplicate of this bug. ***
Test kernel is here: ftp://ftp.suse.com/pub/people/hmacht/11.0/ Would be great if someone could give it a try. Tejun, I'm attaching a patch which changes the dock/bay handling to what was lately discussed on linux-ide. Would be great if you could give it a short review before I'm sending it upstream.
Created attachment 215963 [details] Patch for handling bay devices inside dock stations Handle bay devices in dock stations * Differentiate between bay devices in dock stations and others: - When an ACPI_NOTIFY_EJECT_REQUEST appears, just signal uevent to userspace (that is when the optional eject button on a bay device is pressed/pulled) giving the possibility to unmount file systems and to clean up - In case of a dock event, which in turn signals an ACPI_NOTIFY_EJECT_REQUEST, immediately detach the device, because it may already have been gone * In case of an ACPI_NOTIFY_DEVICE/BUS_CHECK, evaluate _STA to check if the device has been plugged or unplugged. If plugged, hotplug it, if unplugged, just signal event to userspace (initial patch by Matthew Garrett <mjg59@srcf.ucam.org>)
Holger, this is from upstream change, right? What about the other case this change broke? Is there a proposed solution?
What other case you're exactly referring to? If you're referring to the "semantic change in bay handling" Matthew Garrett noticed, this reverts this "semantic change" making it possible to write user scripts at a BAY_EJECT event.
Yeah, that one was what I was talking about. I don't really have much idea about docking stations. Is this going upstream too?
Yes, that's my plan. I just wanted to have a short review from you before sending it to linux-ide and friends.
Holger, I need a x86-64 kernel for testing.
Here you go: ftp://ftp.suse.com/pub/people/hmacht/11.0/
Works for me with minimal testing!
I take it, the new Kernel isn't in Factory, yet? Just a status update on the Factory kernel, then, as long as I have internet access: I could update to Factory, yesterday. Using the GNOME-applet didn't seem to have any effect. I take it, you use KDE, Andreas?) Pressing the undock-button on the docking-station itself made the status LEDs on it blink for some time but in the end it still indicated the machine was locked. I removed the laptop anyway, and it didn't crash but became very sluggish.
You tried the kernel in this bugreport? Or the one from FACTORY?
Sorry about the delay. I'll follow up on kernel@suse.de and upstream. Thanks.
*** This bug has been marked as a duplicate of bug 395082 ***
*** Bug 357401 has been marked as a duplicate of this bug. ***
I tried the Factory kernel. Now, running RC1, the docking applet worked for me most of the time (one freeze) but just today I undocked my ThinkPad, closed the lid, and after I tried to bring it back out of standby a few minuted later, the screen stayed black (not dimmed, though).
We got one more fix for that after RC1, so hopefully this is resolved.