Bugzilla – Bug 357401
lenovo X60: cdrom in docking station not initializing
Last modified: 2008-06-02 15:39:05 UTC
The cdrom drive (actually a dvdrw) of the docking station is dead. It only comes alive, if I reboot the laptop while in the docking station.
Can you try 'docker dock' as root after docking and post the output please? ata_piix is loaded, right? If booted with docking station, the cdrom is /dev/sr0 (sata) not something like /dev/hdc?
Do you have an X60s? If so please add it to /usr/lib/dockutils/hooks/thinkpad/60x60 where it says: [ "$MODEL" = "THINKPAD X60" ] || [ "$MODEL" = "THINKPAD X40" ] || exit 0; to something link [ "$MODEL" = "THINKPAD X60" ] || [ "$MODEL" = "THINKPAD X40" ] || [ "$MODEL = "THINKPAD X60s" ] || exit 0; Thanks.
Yes, ata_piix is loaded. Yes, it is /dev/sr0 no change after adding [ "$MODEL" = "THINKPAD X60x" ] directly after reboot in docking station, cdrom works: # docker dock Fri Feb 1 00:41:53 CET 2008: running thinkpad hooks for event dock. docking should have been done automatically by the dock driver... while still in docking station: suspend to ram, resume. eject cdrom now fails: open("/dev/sr0", O_RDONLY|O_NONBLOCK) = 3 ioctl(3, CDROMEJECT, 0x804c456) = -1 EIO (Input/output error) # . /usr/lib/dockutils/common_functions # unregister_cdroms # scan_scsi_hosts brings it back to life. scan_scsi_hosts also helps with the original scenario "standalone reboot, dock" - it reliably awakens the drive. Any additional hints how to debug why the docking hooks do not trigger? (An open filedescriptor on /dev/ttyS0 -- the serial port on the docking station -- is still open, and fully functional. cool)
(In reply to comment #3 from Juergen Weigert) > no change after adding [ "$MODEL" = "THINKPAD X60x" ] ^ This is a typing error? Anyway, it has to match what $ hal-get-property --udi /org/freedesktop/Hal/devices/computer --key smbios.system.version reports, in upper case. For testing, it would be good enough to remove the whole line, the script just must not exit. > while still in docking station: > suspend to ram, resume. > eject cdrom now fails: > open("/dev/sr0", O_RDONLY|O_NONBLOCK) = 3 > ioctl(3, CDROMEJECT, 0x804c456) = -1 EIO (Input/output error) After fixing the above, can you 'docker undock' before suspend and 'docker dock' after resume? That's what is supposed to be done automatically. > (An open filedescriptor on /dev/ttyS0 -- the serial port on the docking > station -- is still open, and fully functional. cool) Without the dock station? Feature, not a bug ;-)
Typo in my report. I'll comment out the line, and test docker tonight.
Created attachment 193118 [details] Fixing the hook causes resume to hang.
Ok, I experienced this some days ago and already did some debugging. This seems like a race where HAL tries to read from /dev/sr0 in the same moment when the device disappears. At least this was the outcome from the strace. I'll still have to track this down but didn't find the time yet. Will do this week...
Can you please test the kernel from my home project: https://build.opensuse.org/package/show?package=kernel-default&project=home%3Ahmacht Also, please remove package dockutils before testing, the new kernel obsoletes this package. Thanks.
Created attachment 201478 [details] yat comes up with a long conflicts list for this kernel Is this kernel supposed to work with 10.3? I need a stable laptop. Installing stable was not helpful, last time I tried...
No idea, I didn't test on 10.3. Let's wait if AJ reports any results.
*** This bug has been marked as a duplicate of bug 390822 ***