Re: Can't eject a previously mounted CD?

Re: Can't eject a previously mounted CD?

[Matt]

If you are on debian i have noticed recently that gnomevfs (on unstable) 
requires famd. famd will open /cdrom after it is mounted and run a dir 
notification on it. now i think famd needs some fixing, firstly to not 
bother running dir notice on ro filesystems, and secondly allow an 
authorised user (other than the original program (in this case 
nautilus)) to drop specific mount point dirs from the notification list. 
so yes this is a userland problem as far as i can see.

    matt

Re: Can't eject a previously mounted CD?

[Rob Love]

On Fri, 2003-12-26 at 19:31, Matt wrote:
> If you are on debian i have noticed recently that gnomevfs (on unstable) 
> requires famd. famd will open /cdrom after it is mounted and run a dir 
> notification on it. now i think famd needs some fixing, firstly to not 
> bother running dir notice on ro filesystems, and secondly allow an 
> authorised user (other than the original program (in this case 
> nautilus)) to drop specific mount point dirs from the notification list. 
> so yes this is a userland problem as far as i can see.

Yup.

But it sure is lame that our directory notification system (dnotify)
needs to hold open a file descriptor on the directory, and thus really
wrecks havoc on removable media.

Would be nice to have a saner replacement - for other reasons, too.

	Rob Love

Re: Can't eject a previously mounted CD?

[Ed Sweetman]

Rob Love wrote:
> On Fri, 2003-12-26 at 19:31, Matt wrote:
> 
>>If you are on debian i have noticed recently that gnomevfs (on unstable) 
>>requires famd. famd will open /cdrom after it is mounted and run a dir 
>>notification on it. now i think famd needs some fixing, firstly to not 
>>bother running dir notice on ro filesystems, and secondly allow an 
>>authorised user (other than the original program (in this case 
>>nautilus)) to drop specific mount point dirs from the notification list. 
>>so yes this is a userland problem as far as i can see.
> 
> 
> Yup.
> 
> But it sure is lame that our directory notification system (dnotify)
> needs to hold open a file descriptor on the directory, and thus really
> wrecks havoc on removable media.
> 
> Would be nice to have a saner replacement - for other reasons, too.
> 
> 	Rob Love
> 
> 

This may be true for mounted media, but people are having these problems 
with audio cds too. And it doesn't explain why this never happened with 
any of the test kernels.  does famd also mess with cds that are loaded 
and not mounted?

Re: Can't eject a previously mounted CD?

[Matt]

Ed Sweetman wrote:

> Rob Love wrote:
>
>> On Fri, 2003-12-26 at 19:31, Matt wrote:
>>
>>> If you are on debian i have noticed recently that gnomevfs (on 
>>> unstable) requires famd. famd will open /cdrom after it is mounted 
>>> and run a dir notification on it. now i think famd needs some 
>>> fixing, firstly to not bother running dir notice on ro filesystems, 
>>> and secondly allow an authorised user (other than the original 
>>> program (in this case nautilus)) to drop specific mount point dirs 
>>> from the notification list. so yes this is a userland problem as far 
>>> as i can see.
>>
>>
>>
>> Yup.
>>
>> But it sure is lame that our directory notification system (dnotify)
>> needs to hold open a file descriptor on the directory, and thus really
>> wrecks havoc on removable media.
>>
>> Would be nice to have a saner replacement - for other reasons, too.
>>
>>     Rob Love
>>
>>
>
> This may be true for mounted media, but people are having these 
> problems with audio cds too. And it doesn't explain why this never 
> happened with any of the test kernels.  does famd also mess with cds 
> that are loaded and not mounted?
>
>
Ack, just noticed that. I haven't seen famd messing with audio CDs, but 
also Joshua said that he didn't have famd installed on his machine, so 
that cuts that out. Strange how he said that eject(1) worked. Not sure, 
but just to reiterate to people though if you have mounted removable 
media it might not eject if you have famd installed on your machine, not 
sure if nautilus has been updated to drop its proxied dnotify when they 
are umounted.

    Matt

Re: Can't eject a previously mounted CD?

[Joshua Kwan]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On Sat, Dec 27, 2003 at 12:31:55AM +0000, Matt wrote:
> If you are on debian i have noticed recently that gnomevfs (on unstable) 
> requires famd. famd will open /cdrom after it is mounted and run a dir 
> notification on it. now i think famd needs some fixing, firstly to not 
> bother running dir notice on ro filesystems, and secondly allow an 
> authorised user (other than the original program (in this case 
> nautilus)) to drop specific mount point dirs from the notification list. 
> so yes this is a userland problem as far as i can see.

I am using Debian. This is a good point. However, I have no component of
fam installed on this Debian machine at all.

And why does the eject command work? I decided to strace it to see where
it gets this invalid argument from..

open("/dev/hdc", O_RDONLY|O_NONBLOCK)   = 3
ioctl(3, 0x5309, 0xbffff948)            = -1 EIO (Input/output error)
ioctl(3, FIBMAP, 0xbffff7f0)            = 0
ioctl(3, FIBMAP, 0xbffff7f0)            = 0
ioctl(3, FIBMAP, 0xbffff7f0)            = 0
ioctl(3, BLKRRPART, 0xbffff7f0)         = -1 EINVAL (Invalid argument)
ioctl(3, FDEJECT, 0xbffff948)           = -1 EINVAL (Invalid argument)
ioctl(3, SNDCTL_MIDI_MPUMODE, 0xbffff900) = -1 EINVAL (Invalid argument)

It wasn't as revealing as I thought it would be, but does this mean
anything to someone more knowledgeable than I?

Note that as mentioned in a previous message, eject _does_ eject the CD.

-- 
Joshua Kwan

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: Can't eject a previously mounted CD?

[Walt H]

> Does everyone who has this problem by chance have it occuring on an 
> atapi cd recorder.  As of 2.6.0-mm1 my cd recorder is being labeled read 
> only by the ide-cd driver.  Meaning, no matter if i set the readonly 
> flag in hdparm to 0, cdrecord and others will refuse to write to the 
> drive because it's being told it's read only.  I do not have fam loaded 
> at the time of this testing.  Are there new ide-cd arguments required to 
> use atapi cd writers in native mode?
> 
> 

I have it happening on both my optical drives. One is a lite-on ATAPI cd-rw, the
other an ATAPI Pioneer dvd-rw/cd-rw.  No fam/gnome running. I do use automount
with these drives, but I can see that the mounts have been expired, yet I can't
eject them using the button. Tested last night using both ide-cd and ide-scsi.
Same result with either access. When they're locked, fuser shows nothing
attached, as does lsof. I can eject them with the eject command.

-Walt

Re: Can't eject a previously mounted CD?

[Ed Sweetman]

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.


Walt H wrote:
>>Does everyone who has this problem by chance have it occuring on an 
>>atapi cd recorder.  As of 2.6.0-mm1 my cd recorder is being labeled read 
>>only by the ide-cd driver.  Meaning, no matter if i set the readonly 
>>flag in hdparm to 0, cdrecord and others will refuse to write to the 
>>drive because it's being told it's read only.  I do not have fam loaded 
>>at the time of this testing.  Are there new ide-cd arguments required to 
>>use atapi cd writers in native mode?
>>
>>
> 
> 
> I have it happening on both my optical drives. One is a lite-on ATAPI cd-rw, the
> other an ATAPI Pioneer dvd-rw/cd-rw.  No fam/gnome running. I do use automount
> with these drives, but I can see that the mounts have been expired, yet I can't
> eject them using the button. Tested last night using both ide-cd and ide-scsi.
> Same result with either access. When they're locked, fuser shows nothing
> attached, as does lsof. I can eject them with the eject command.
> 
> -Walt

Re: Can't eject a previously mounted CD?

[Walt H]

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 :)
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 :)

-Walt

--- /usr/src/linux/drivers/cdrom/cdrom.c        2003-12-25 09:53:59.000000000 -0800
+++ linux-2.6.0-mm1/drivers/cdrom/cdrom.c       2003-12-28 19:42:04.174098225 -0800
@@ -744,4 +744,7 @@
        }

+       if (cdi->use_count > 0)
+               cdi->use_count--;
+
        /* if this was a O_NONBLOCK open and we should honor the flags,
         * do a quick open without drive/disc integrity checks. */
@@ -931,5 +934,5 @@
        struct cdrom_device_ops *cdo = cdi->ops;

-       cdinfo(CD_CLOSE, "entering cdrom_release\n");
+       cdinfo(CD_CLOSE, "entering cdrom_release\n");

        if (cdi->use_count > 0)

Re: Can't eject a previously mounted CD?

[Ed Sweetman]

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 :)
> 
> -Walt
> 
> --- /usr/src/linux/drivers/cdrom/cdrom.c        2003-12-25 09:53:59.000000000 -0800
> +++ linux-2.6.0-mm1/drivers/cdrom/cdrom.c       2003-12-28 19:42:04.174098225 -0800
> @@ -744,4 +744,7 @@
>         }
> 
> +       if (cdi->use_count > 0)
> +               cdi->use_count--;
> +
>         /* if this was a O_NONBLOCK open and we should honor the flags,
>          * do a quick open without drive/disc integrity checks. */
> @@ -931,5 +934,5 @@
>         struct cdrom_device_ops *cdo = cdi->ops;
> 
> -       cdinfo(CD_CLOSE, "entering cdrom_release\n");
> +       cdinfo(CD_CLOSE, "entering cdrom_release\n");
> 
>         if (cdi->use_count > 0)
> 

Re: Can't eject a previously mounted CD?

[Ed Sweetman]

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 :)
>>

Re: Can't eject a previously mounted CD?

[Ed Sweetman]

In your patch here i think the person who made the code originally 
confused or got wrong the conditions of success for opening the cdrom 
drive. This is in the same function as the patch applies to.

        if ((fp->f_flags & O_NONBLOCK) && (cdi->options & 
CDO_USE_FFLAGS))
                 ret = cdi->ops->open(cdi, 1); 

         else 

                 ret = open_for_data(cdi); 

 

         if (!ret) cdi->use_count++;

Here we see that if the open fails we incriment our use_count.  But this 
doesn't make sense. We increment the use_count at the  beginning of the 
function as a "lock" so that we can't do anything while the open 
function is executing like rmmod the cdrom (supposedly?).  Now removing 
the if(!ret) line makes sense. Under the out: label, if the open fails, 
then we close our makeshift lock on the device because our function is 
done. If it succeeded, then the use_count stays at 1 we go along our 
merry way.

> -Walt
> 
> --- /usr/src/linux/drivers/cdrom/cdrom.c        2003-12-25 09:53:59.000000000 -0800
> +++ linux-2.6.0-mm1/drivers/cdrom/cdrom.c       2003-12-28 19:42:04.174098225 -0800
> @@ -744,4 +744,7 @@
>         }
> 
> +       if (cdi->use_count > 0)
> +               cdi->use_count--;
> +
>         /* if this was a O_NONBLOCK open and we should honor the flags,
>          * do a quick open without drive/disc integrity checks. */
> @@ -931,5 +934,5 @@
>         struct cdrom_device_ops *cdo = cdi->ops;
> 
> -       cdinfo(CD_CLOSE, "entering cdrom_release\n");
> +       cdinfo(CD_CLOSE, "entering cdrom_release\n");
> 
>         if (cdi->use_count > 0)
> 
> 
> 
> -
> 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/
> 

Re: Can't eject a previously mounted CD?

[Walt H]

Ed Sweetman wrote:
> In your patch here i think the person who made the code originally
> confused or got wrong the conditions of success for opening the cdrom
> drive. This is in the same function as the patch applies to.
> 
>        if ((fp->f_flags & O_NONBLOCK) && (cdi->options & CDO_USE_FFLAGS))
>                 ret = cdi->ops->open(cdi, 1);
>         else
>                 ret = open_for_data(cdi);
> 
> 
>         if (!ret) cdi->use_count++;

Doesn't this increment it if the call succeeds? In open_for_data, ret is the
return code from the open call, which should be zero upon success. Problem is,
we already incremented it when we entered cdrom_open.

> 
> Here we see that if the open fails we incriment our use_count.  But this
> doesn't make sense. We increment the use_count at the  beginning of the
> function as a "lock" so that we can't do anything while the open
> function is executing like rmmod the cdrom (supposedly?).  Now removing
> the if(!ret) line makes sense. Under the out: label, if the open fails,
> then we close our makeshift lock on the device because our function is
> done. If it succeeded, then the use_count stays at 1 we go along our
> merry way.
> 

Yeah, my patch is just a hack :)  Not really for general use i think, but it
allows me to open the door using the button. The cdrom.c from test11-mm1 never
incremented use_count until after the success of one of the preceeding calls. I
was just undoing the original increment that now happens upon entering
cdrom_open. The use_count does control the door lock though. If you look under
cdrom_release, the door unlock code never gets executed until use_count=0. I
haven't checked overall operation of my cdrom drives enough to know what else is
wrong.

-Walt

Re: Can't eject a previously mounted CD?

[Ed Sweetman]

check out test11-mm1's cdrom.c.  I think it'll make things clear.  I 
just replaced the cdrom.c and ide-cd.h and ide-cd.c files in 2.6.0-mm1 
with 2.6.0-test11-mm1's and things are working perfect.

Re: Can't eject a previously mounted CD?

[Walt H]

Ed Sweetman wrote:
> check out test11-mm1's cdrom.c.  I think it'll make things clear.  I
> just replaced the cdrom.c and ide-cd.h and ide-cd.c files in 2.6.0-mm1
> with 2.6.0-test11-mm1's and things are working perfect.
> 
> 
> 
> 

I was just about to that stage as well :)  Just noticed that -mm2 is out, and it
has specific fixes unlocking tray as well.

-Walt

Re: Can't eject a previously mounted CD?

[Walt H]

Ed Sweetman wrote:
> check out test11-mm1's cdrom.c.  I think it'll make things clear.  I
> just replaced the cdrom.c and ide-cd.h and ide-cd.c files in 2.6.0-mm1
> with 2.6.0-test11-mm1's and things are working perfect.
> 
> 
> 

Ed,

I can confirm that 2.6.0-mm2 fixes the tray lock issue. On my setup, the drive's
capabilities are reported correctly as well. Haven't done serious testing yet,
but I could at least blank a cd-rw :) yay!

-Walt

Re: Can't eject a previously mounted CD?

[Jens Axboe]

On Mon, Dec 29 2003, Walt H wrote:
> Ed Sweetman wrote:
> > check out test11-mm1's cdrom.c.  I think it'll make things clear.  I
> > just replaced the cdrom.c and ide-cd.h and ide-cd.c files in 2.6.0-mm1
> > with 2.6.0-test11-mm1's and things are working perfect.
> > 
> > 
> > 
> 
> Ed,
> 
> I can confirm that 2.6.0-mm2 fixes the tray lock issue. On my setup,
> the drive's capabilities are reported correctly as well. Haven't done
> serious testing yet, but I could at least blank a cd-rw :) yay!

It was a merge error in -mm1 that caused the problem.

-- 
Jens Axboe

Can't eject a previously mounted CD?

[Joshua Kwan]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

Hi Vojtech,

I suspect this problem has something to do with my nForce2 motherboard.
When I mount a CD, unmount it, and try to eject it from my drive, the
drive flashes the red 'busy / locked' light and refuses to let me eject
it. I'm using the AMD / nVidia IDE kernel support and the obvious
conclusion is that it's failing to release the device or something. Is
this true?

I suspect the fix would be a one liner.

-- 
Joshua Kwan

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: Can't eject a previously mounted CD?

[Vojtech Pavlik]

On Fri, Dec 26, 2003 at 12:15:35AM -0800, Joshua Kwan wrote:

> I suspect this problem has something to do with my nForce2 motherboard.
> When I mount a CD, unmount it, and try to eject it from my drive, the
> drive flashes the red 'busy / locked' light and refuses to let me eject
> it. I'm using the AMD / nVidia IDE kernel support and the obvious
> conclusion is that it's failing to release the device or something. Is
> this true?

No. :) There isn't anything in that driver that'd be called upon mount
or unmount, it just sets the timings on boottime or when hdparm is
called.

> I suspect the fix would be a one liner.

If you're using SUSE 9.0 ...

	kill suseplugger

... perhaps?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: Can't eject a previously mounted CD?

[Joshua Kwan]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

On Fri, Dec 26, 2003 at 11:34:27AM +0100, Vojtech Pavlik wrote:
> If you're using SUSE 9.0 ...

No, Debian.

The reason I said it was something to do with my motherboard is that
I've not experienced this before, even on another motherboard with
the original nForce.

Traditionally (as in Windows), the only thing that would keep the CD
from being ejected is an ongoing recording session. Of course, in
Linux, it just has to be mounted, and that's normal behavior. Just that
the drive doesn't want to eject my CD even after unmounting it.
Does that mean that this is a userspace problem?

-- 
Joshua Kwan

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: Can't eject a previously mounted CD?

[Samuel Flory]

Joshua Kwan wrote:
> On Fri, Dec 26, 2003 at 11:34:27AM +0100, Vojtech Pavlik wrote:
> 
>>If you're using SUSE 9.0 ...
> 
> 
> No, Debian.
> 
> The reason I said it was something to do with my motherboard is that
> I've not experienced this before, even on another motherboard with
> the original nForce.
> 
> Traditionally (as in Windows), the only thing that would keep the CD
> from being ejected is an ongoing recording session. Of course, in
> Linux, it just has to be mounted, and that's normal behavior. Just that
> the drive doesn't want to eject my CD even after unmounting it.
> Does that mean that this is a userspace problem?
> 

   What does fuser -kv /mnt/cdrom claim?

-- 
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>

Re: Can't eject a previously mounted CD?

[Joshua Kwan]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

On Fri, Dec 26, 2003 at 11:54:34AM -0800, Samuel Flory wrote:
>   What does fuser -kv /mnt/cdrom claim?

It's /cdrom here. I tried it on both /cdrom and /dev/cdrom after
unmounting it, and the output was blank.

While mounted, here was the output:

                     USER        PID ACCESS COMMAND
/cdrom               root     kernel mount  /cdrom
No automatic removal. Please use  umount /cdrom

I guess that doesn't say much though...

-- 
Joshua Kwan

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: Can't eject a previously mounted CD?

[Ed Sweetman]

I've had 2.6.0-mm1 not able to allow the button on the cdrom eject the 
cd. the command  eject   however, does work.  No errors are reported 
relating to why the eject button on the cdrom doesn't eject the cd.


Joshua Kwan wrote:
> On Fri, Dec 26, 2003 at 11:54:34AM -0800, Samuel Flory wrote:
> 
>>  What does fuser -kv /mnt/cdrom claim?
> 
> 
> It's /cdrom here. I tried it on both /cdrom and /dev/cdrom after
> unmounting it, and the output was blank.
> 
> While mounted, here was the output:
> 
>                      USER        PID ACCESS COMMAND
> /cdrom               root     kernel mount  /cdrom
> No automatic removal. Please use  umount /cdrom
> 
> I guess that doesn't say much though...
> 

Re: Can't eject a previously mounted CD?

[Nuno Silva]

Ed Sweetman wrote:
> 
> I've had 2.6.0-mm1 not able to allow the button on the cdrom eject the 
> cd. the command  eject   however, does work.  No errors are reported 
> relating to why the eject button on the cdrom doesn't eject the cd.


This happens to me too, running 2.6.0-mm1. Even a music CD gets stuck 
and can only be ejected with the "eject" command. eject, after ejecting 
sucessfully the CD outputs this:

# eject
eject: unable to eject, last error: Invalid argument
#

Regards,
Nuno Silva

> 
> 
> Joshua Kwan wrote:
> 
>> On Fri, Dec 26, 2003 at 11:54:34AM -0800, Samuel Flory wrote:
>>
>>>  What does fuser -kv /mnt/cdrom claim?
>>
>>
>>
>> It's /cdrom here. I tried it on both /cdrom and /dev/cdrom after
>> unmounting it, and the output was blank.
>>
>> While mounted, here was the output:
>>
>>                      USER        PID ACCESS COMMAND
>> /cdrom               root     kernel mount  /cdrom
>> No automatic removal. Please use  umount /cdrom
>>
>> I guess that doesn't say much though...
>>
> 
> 
> -
> 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/
> 

Re: Can't eject a previously mounted CD?

[Joshua Kwan]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

On Fri, Dec 26, 2003 at 11:56:50PM +0000, Nuno Silva wrote:
> This happens to me too, running 2.6.0-mm1. Even a music CD gets stuck 
> and can only be ejected with the "eject" command. eject, after ejecting 
> sucessfully the CD outputs this:
> 
> # eject
> eject: unable to eject, last error: Invalid argument
> #

Exactly! This must be a -mm problem then... Andrew?

-- 
Joshua Kwan

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: Can't eject a previously mounted CD?

[Samuel Flory]

Joshua Kwan wrote:

> On Fri, Dec 26, 2003 at 11:54:34AM -0800, Samuel Flory wrote:
> 
>>  What does fuser -kv /mnt/cdrom claim?
> 
> 
> It's /cdrom here. I tried it on both /cdrom and /dev/cdrom after
> unmounting it, and the output was blank.
> 
> While mounted, here was the output:
> 
>                      USER        PID ACCESS COMMAND
> /cdrom               root     kernel mount  /cdrom
> No automatic removal. Please use  umount /cdrom
> 
> I guess that doesn't say much though...
> 

   It does seem to imply that the cdrom is still mounted, or that 
something thinks it's still mounted.

Re: Can't eject a previously mounted CD?

[Ed Sweetman]

Samuel Flory wrote:
> Joshua Kwan wrote:
> 
>> On Fri, Dec 26, 2003 at 11:54:34AM -0800, Samuel Flory wrote:
>>
>>>  What does fuser -kv /mnt/cdrom claim?
>>
>>
>>
>> It's /cdrom here. I tried it on both /cdrom and /dev/cdrom after
>> unmounting it, and the output was blank.
>>
>> While mounted, here was the output:
>>
>>                      USER        PID ACCESS COMMAND
>> /cdrom               root     kernel mount  /cdrom
>> No automatic removal. Please use  umount /cdrom
>>
>> I guess that doesn't say much though...
>>
> 
>   It does seem to imply that the cdrom is still mounted, or that 
> something thinks it's still mounted.


I dont believe this unable to eject problem has anything to do with 
anything thinking it's mounted.

famd upon load seems to cause this error.
end_request: I/O error, dev hdc, sector 0

That's my cdrom.  Perhaps the kernel has a bug in the code dealing with 
an access to the cdrom where no media is mounted and/or loaded.  Either 
way, this is at boot and seems to be a kernel bug initiated by FAM. At 
least the version distributed with debian-unstable.  I dont use gnome (i 
do have some gnome programs installed to test on) and the error message 
was reported soon after the loading of FAM.

Re: Can't eject a previously mounted CD?

[Ed Sweetman]

Does everyone who has this problem by chance have it occuring on an 
atapi cd recorder.  As of 2.6.0-mm1 my cd recorder is being labeled read 
only by the ide-cd driver.  Meaning, no matter if i set the readonly 
flag in hdparm to 0, cdrecord and others will refuse to write to the 
drive because it's being told it's read only.  I do not have fam loaded 
at the time of this testing.  Are there new ide-cd arguments required to 
use atapi cd writers in native mode?





Ed Sweetman wrote:
> Samuel Flory wrote:
> 
>> Joshua Kwan wrote:
>>
>>> On Fri, Dec 26, 2003 at 11:54:34AM -0800, Samuel Flory wrote:
>>>
>>>>  What does fuser -kv /mnt/cdrom claim?
>>>
>>>
>>>
>>>
>>> It's /cdrom here. I tried it on both /cdrom and /dev/cdrom after
>>> unmounting it, and the output was blank.
>>>
>>> While mounted, here was the output:
>>>
>>>                      USER        PID ACCESS COMMAND
>>> /cdrom               root     kernel mount  /cdrom
>>> No automatic removal. Please use  umount /cdrom
>>>
>>> I guess that doesn't say much though...
>>>
>>
>>   It does seem to imply that the cdrom is still mounted, or that 
>> something thinks it's still mounted.
> 
> 
> 
> I dont believe this unable to eject problem has anything to do with 
> anything thinking it's mounted.
> 
> famd upon load seems to cause this error.
> end_request: I/O error, dev hdc, sector 0
> 
> That's my cdrom.  Perhaps the kernel has a bug in the code dealing with 
> an access to the cdrom where no media is mounted and/or loaded.  Either 
> way, this is at boot and seems to be a kernel bug initiated by FAM. At 
> least the version distributed with debian-unstable.  I dont use gnome (i 
> do have some gnome programs installed to test on) and the error message 
> was reported soon after the loading of FAM.
>