Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#25740 - [linux] cdrom_id hangs after second dock and prevents suspending

Attached to Project: Arch Linux
Opened by Nico Schottelius (telmich) - Wednesday, 24 August 2011, 07:16 GMT
Last edited by Tom Gundersen (tomegun) - Friday, 25 November 2011, 11:46 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

I'm using a Lenovo X200/X201 with Ultrabase docking station. The second time I'm docking,
the program /lib/udev/cdrom_id hangs in the D state and never finishes. This is reproducable,
happened with latest Linux 2.6.x series and happens with 3.x.

Using the correct undock button does not prevent this from happening.

Additional info:
* package version(s)

linux 3.0.3-1
udev 173-3

* config and/or log files etc.


Steps to reproduce:

- Dock X200/X201 once into dock
- Release
- Dock again
- Try to suspend (pm-suspend or echo mem > /sys/power/state), it fails

I assume this will happen with other docking stations as well, but do not have other parts here to test.
This task depends upon

Closed by  Tom Gundersen (tomegun)
Friday, 25 November 2011, 11:46 GMT
Reason for closing:  Upstream
Additional comments about closing:  Fix available from git, see the last LKML link.
Comment by Nico Schottelius (telmich) - Thursday, 25 August 2011, 11:45 GMT
Dmesg of 2.6.39, but same problem in 3.0 as well.
Comment by Thomas Bächler (brain0) - Sunday, 28 August 2011, 10:56 GMT
You have a pretty good trace of the cdrom_id task hanging in that log file. You should report this to the kernel.org bugzilla.
Comment by Tom Gundersen (tomegun) - Wednesday, 31 August 2011, 17:07 GMT
It looks like the machine was suspended before the problem happened. Is that correct? If so, can you reproduce without suspending first?

I mentioned this in #udev. The suggestion was that it might be related to media polling (which is now done in the kernel), and that it might not interact well with suspend. Please open a bug report at bugzilla.kernel.org and add "Tejun Heo <tj@kernel.org>" to cc.
Comment by Tom Gundersen (tomegun) - Saturday, 03 September 2011, 23:37 GMT Comment by Nico Schottelius (telmich) - Tuesday, 06 September 2011, 09:56 GMT
Yep, suspending _once_ works, but not again. Currently I'm on linux 3.0.4-1 and it seems it takes more than one suspend to run into this problem.

Added bug at kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=42452
Comment by Tom Gundersen (tomegun) - Friday, 25 November 2011, 11:44 GMT
This seems to have been fixed upstream (or at least a fix is on the way to Linus' tree): https://lkml.org/lkml/2011/10/31/55 . You can try the git tree linked to in that thread, and if it still does not work, please pursue the problem upstream (possibly asking them to push some fixes to stable). Closing bug here.

Loading...