Bug 222783 - idectl caused kernel oops trying to remove cdrom drive on ThinkPad
idectl caused kernel oops trying to remove cdrom drive on ThinkPad
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: hdparm (Show other bugs)
6
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
bzcl34nup
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-16 02:11 EST by Brian Harvey
Modified: 2008-08-02 19:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 13:21:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output from dmesg after doing it. (24.72 KB, text/plain)
2007-01-16 02:11 EST, Brian Harvey
no flags Details

  None (edit)
Description Brian Harvey 2007-01-16 02:11:05 EST
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:
Comment 1 Brian Harvey 2007-01-16 02:11:05 EST
Created attachment 145657 [details]
Output from dmesg after doing it.
Comment 2 Karsten Hopp 2007-01-18 06:45:13 EST
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.
Comment 3 Brian Harvey 2007-01-19 12:58:22 EST
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.
Comment 4 Karsten Hopp 2007-01-19 14:33:32 EST
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 ?
Comment 5 Brian Harvey 2007-01-21 01:20:52 EST
Yes!  Thank you so much.

(I had to reconfigure the kernel as described in that wiki page.)
Comment 6 Brian Harvey 2007-01-21 03:07:44 EST
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.
Comment 7 Karsten Hopp 2007-01-22 04:00:41 EST
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 ?
Comment 8 Brian Harvey 2007-01-22 14:46:36 EST
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?
Comment 9 Karsten Hopp 2008-04-03 10:40:28 EDT
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.
Comment 10 Bug Zapper 2008-04-04 01:37:24 EDT
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
Comment 11 Bug Zapper 2008-05-06 13:21:50 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.