Description of problem: I am trying to be able to undock my ThinkPad X41, and the current problem is that I first have to turn off /dev/hdc, the cd/dvd drive. I found an acpi script on the net that suggested /usr/local/sbin/idectl 0 off but this does nothing because the drive is actually on ide1, not ide0. (There is no ide0; the hard disk is /dev/sda.) So I tried /usr/local/sbin/idectl 1 off and got the error message "/dev/hda: No such file or directory". Then I had the brilliant(?) idea to say ln -s /dev/hdc /dev/hda and tried it again. Lots of bells ringing and error messages (attached)! By the way, it'd be really great if, besides fixing the error messages, someone could tell me how to get rid of the drive correctly. Thanks! Version-Release number of selected component (if applicable): hdparm v6.6 How reproducible: Yes, but it might depend on this particular hardware setup. Steps to Reproduce: 1. ln -s /dev/hdc /dev/hda 2. /usr/local/sbin/idectl 1 off Actual results: kernel oops Expected results: /dev/hdc turned off Additional info:
Created attachment 145657 [details] Output from dmesg after doing it.
I have no idea what idectl is, but it isn't in Fedora Core or Fedora Extras. It definitely isn't part of hdparm. If it is a script you'll have to find out what it actually does, maybe it even calls hdparm. Please try to find out and reopen this report with the exact hdparm parameters if it does.
Sorry for the lack of detail. idectl is a shell script that's in the hdparm source rpm. When I try to turn off the drive, it does this: /sbin/hdparm -U 1 /dev/hdc and when I try to reattach it, it does this: /sbin/hdparm -R 0x170 0 0 /dev/hdc The confusion about hda vs. hdc was in that script, which had hda wired in. Changing that to hdc simplifies the problem. So, the -U is the one that sort of works but generates the error messages attached in the original report; the -R complains (correctly) that there's no /dev/hdc. But just doing a mknod isn't good enough; hdparm still says there's no such device.
It looks like there are some special routines available for ultrabay devices like the CDROM in your dockingstation I've found http://www.thinkwiki.org/wiki/How_to_hotswap_UltraBay_devices#When_using_the_ata_piix_driver with the following suggestions (no hdparm required) to unregister the device: echo 1 > /sys/class/scsi_device/1\:0\:0\:0/device/delete echo eject > /proc/acpi/ibm/bay Does this work ?
Yes! Thank you so much. (I had to reconfigure the kernel as described in that wiki page.)
Oops -- I spoke too soon. When I redock, the drive is indeed sensed, and /dev/scd0 is created, but when I try to mount a disc, I get: mount: wrong fs type, bad option, bad superblock on /dev/scd0, missing codepage or other error dmesg says: isofs_fill_super: bread failed, dev=sr0, iso_blknum=16, block=16 I have to reboot to make the drive usable again.
Well, there are more hints on that page from comment #4 Have you tried echo 0 0 0 > /sys/class/scsi_host/host1/scan as used in ultrabay_open in the hotplug script ?
Yes, if I didn't have that echo 0 0 0 > /sys/class/scsi_host/host1/scan command, then /dev/scd0 wouldn't be recreated. I found something possibly relevant in dmesg. This is in the initial system boot: ata2.01: qc timeout (cmd 0xa1) ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata2: failed to recover some devices, retrying in 5 secs ata2.01: qc timeout (cmd 0xa1) ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata2: failed to recover some devices, retrying in 5 secs ata2.01: qc timeout (cmd 0xa1) ata2.01: failed to IDENTIFY (I/O error, err_mask=0x4) ata2: failed to recover some devices, retrying in 5 secs ata2.00: configured for UDMA/33 The same thing happens when I redock the laptop, except that the conclusion is different: ata2.00: failed to IDENTIFY (I/O error, err_mask=0x2) ata2.00: revalidation failed (errno=-5) ata2: failed to recover some devices, retrying in 5 secs ata2: soft resetting port ata2.00: failed to IDENTIFY (I/O error, err_mask=0x2) ata2.00: revalidation failed (errno=-5) ata2: failed to recover some devices, retrying in 5 secs ata2: soft resetting port ata2.00: failed to IDENTIFY (I/O error, err_mask=0x2) ata2.00: revalidation failed (errno=-5) ata2.00: disabled ata2: EH complete Maybe that "disabled" is relevant? P.S. This discussion isn't really about hdparm anymore; should we change its category?
Is this still happening with the latest available kernel or can we close this bugreport ? I'm asking for the kernel as that's what I suspect as the culprit.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.