Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 29 Dec 2003 02:41:37 -0500 | From | Ed Sweetman <> | Subject | Re: Can't eject a previously mounted CD? |
| |
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 :) >>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |