Re: Can't eject a previously mounted CD?

[Ed Sweetman <ed.sweetman@wmich.edu>]

Just to add to my previous post about the problem with the ide-cd 
driver. It appears that loading and unloading it and loading it again a 
couple times causes the driver to mess up it's interrupts. Now i get a 
recurring "lost interrupt to hdc" message and the device is 
non-responsive, causing any attempt to rmmod or modprobe ide-cd to hang, 
and the /dev entry is missing according to hdparm.




Ed Sweetman wrote:
> Walt H wrote:
> 
>> Ed Sweetman wrote:
>>
>>> I'd have to say the december 17th listed changes are the culprit here.
>>> I'm definitely not up to figuring out what change is the bad one.  If
>>> any of the cdrom/ide-cd people wanna have me get some data from them
>>> then just tell me how.  I've tried viewing the debug output from the
>>> modules with no success in figuring out the problem.
>>>
>>>
> 
>>
>> Luckily for me, I built my cdrom drivers as modules, so I could play :)
> 
> 
> so did i. I looked at the debugging output and noticed the increments 
> increasing. This had no effect on me unloading the module so i didn't 
> care. It also should have nothing to do with not being able to eject it 
> since being unable to eject would imply that the door is locked, in 
> which case the command "eject" should also fail but it does not. I think 
> the kernel is really really fubarred since the dec 17th patches dealing 
> with ide-cd.  My cd writer is no longer able to write in atapi direct 
> mode because the driver isn't giving it the capabalities it should have. 
> It's being shown as a simple cdrom as far as the kernel is concerned. 
> Also, the drive throws errors about being unable to access sector 0, as 
> many others have pointed out. This is an error that should be caught 
> prior to actually sending such a command since media is not in the drive 
> in the first place.
> 
> It's definitely not up to me but i would roll back the cdrom and ide-cd 
> changes from dec 17th and re-add them much more carefully because 
> something is really messed up.
> 
> cdrecord is showing the TOC as just CdRom and reports the drive as 
> readonly.  That's about all the irregular information i can find on my 
> own. I dont know where to look for anything else, the cdrom debugging 
> output doesn't report anything irregular except for the behavior 
> described below and that really doesn't help me with anything except to 
> prove that the patches that went in last are the cause of the problem, 
> not necessarily famd's hackish behavior or hardware.
> 
>> I turned on debugging, and noticed that cdi->use_count continues to 
>> increment by
>> 2 for each access. In cdrom_release, only one cdi->use_count-- exists, 
>> so the
>> driver never gets to 0 use count and releases. I noticed in
>> drivers/cdrom/cdrom.c line 753:
>>
>>         if (!ret) cdi->use_count++;
>>
>> Which is our second increment, but I can't find two decrements, 
>> because the
>> check further down won't ever be true if the above is true. Hence, two
>> increments and only 1 dec when we reach cdrom_release. What I did, was 
>> add a
>> conditional decrement right before the open_for_data call, which makes 
>> the value
>> of use_count like it used to be prior to the Mt. Rainier patches. 
>> Seems kinda
>> hacky :)
>>