Mailinglist Archive: packet-writing (23 mails)
| < Previous | Next > |
Re: 2.4 -> 2.6 change: mount with disk not in drive semantics changed to something silly
- From: Nix <nix@xxxxxxxxxxxxx>
- Date: Sun, 27 Feb 2005 17:16:37 +0000 (UTC)
- Message-id: <87650dq5y6.fsf@xxxxxxxxxxxxxxxxxx>
On Sat, 26 Feb 2005, Peter Osterlund mused:
> On Sat, 26 Feb 2005, Nix wrote:
>
>> Further experimentation at this end shows that it does indeed work as
>> you say --- the *first* time one mounts. (i.e., if you have three
>> states, EJECTED_BROKEN, EJECTED_READY and MOUNTED, it's as if the system
>> starts in EJECTED_READY, but sn eject after umount puts it into
>> EJECTED_BROKEN and only a (failed) mount attempt will put it back
>> into the same state it was in post-boot.
>>
>> It's almost as if the kernel doesn't realise the disc is ejected until
>> the first mount attempt fails...
>
> I still can't make it fail on my computer. When the mount command fails on
> your computer, does the tray get closed by the failed mount command? How
No.
> did you open the tray between the first and second try? Pressing the eject
> button or running the eject program?
Doesn't matter; both have the same effect.
>> No, that works --- but is buggered up in a much more catastrophic
>> fashion; after umount, the drive door is locked, and nothing can unlock
>> it again; IIRC, anyone who tries gets an EINVAL.
>
> What exactly does "nothing" mean? Did you try these things?
>
> 1. Running pktsetup -d before trying to eject.
Before trying to eject a non-packetwritten disk?
That never occurred to me; I'll try it.
Oh-HO! You're on to something.
With the pktsetup association in place, I can't eject following a
mount/umount cycle (except as below); with it deleted, I can eject.
The peculiar thing is that ejection of packetwritten CDs is fine: their
problem is with remounting after an ejection.
> 2. Running eject as root.
This one has an interesting effect. The disk ejects, and then eject says
eject: unable to eject, last error: Invalid argument
strace of this, with timestamps:
17:07:30.690373 open("/dev/hde", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 3
17:07:30.690928 ioctl(3, CDROMEJECT, 0x9) = -1 EIO (Input/output error)
17:07:30.696360 ioctl(3, FIBMAP, 0xbffff2b0) = 0
17:07:30.697142 ioctl(3, FIBMAP, 0xbffff2b0) = 0
17:07:31.936029 ioctl(3, FIBMAP, 0xbffff2b0) = 0
[Here a three-second pause while the eject happens]
17:07:34.910139 ioctl(3, BLKRRPART, 0) = -1 EINVAL (Invalid argument)
17:07:34.910488 ioctl(3, FDEJECT, 0x9) = -1 EINVAL (Invalid argument)
17:07:34.910752 ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 0xbffff3c0) = -1 EINVAL (Invalid argument)
> 3. Reboot the computer.
> 4. Power cycle the computer.
The last two unlock the door (I have a feeling that POST on this machine
unconditionally unlocks the door).
--
> ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
--- John M. Ford
> On Sat, 26 Feb 2005, Nix wrote:
>
>> Further experimentation at this end shows that it does indeed work as
>> you say --- the *first* time one mounts. (i.e., if you have three
>> states, EJECTED_BROKEN, EJECTED_READY and MOUNTED, it's as if the system
>> starts in EJECTED_READY, but sn eject after umount puts it into
>> EJECTED_BROKEN and only a (failed) mount attempt will put it back
>> into the same state it was in post-boot.
>>
>> It's almost as if the kernel doesn't realise the disc is ejected until
>> the first mount attempt fails...
>
> I still can't make it fail on my computer. When the mount command fails on
> your computer, does the tray get closed by the failed mount command? How
No.
> did you open the tray between the first and second try? Pressing the eject
> button or running the eject program?
Doesn't matter; both have the same effect.
>> No, that works --- but is buggered up in a much more catastrophic
>> fashion; after umount, the drive door is locked, and nothing can unlock
>> it again; IIRC, anyone who tries gets an EINVAL.
>
> What exactly does "nothing" mean? Did you try these things?
>
> 1. Running pktsetup -d before trying to eject.
Before trying to eject a non-packetwritten disk?
That never occurred to me; I'll try it.
Oh-HO! You're on to something.
With the pktsetup association in place, I can't eject following a
mount/umount cycle (except as below); with it deleted, I can eject.
The peculiar thing is that ejection of packetwritten CDs is fine: their
problem is with remounting after an ejection.
> 2. Running eject as root.
This one has an interesting effect. The disk ejects, and then eject says
eject: unable to eject, last error: Invalid argument
strace of this, with timestamps:
17:07:30.690373 open("/dev/hde", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 3
17:07:30.690928 ioctl(3, CDROMEJECT, 0x9) = -1 EIO (Input/output error)
17:07:30.696360 ioctl(3, FIBMAP, 0xbffff2b0) = 0
17:07:30.697142 ioctl(3, FIBMAP, 0xbffff2b0) = 0
17:07:31.936029 ioctl(3, FIBMAP, 0xbffff2b0) = 0
[Here a three-second pause while the eject happens]
17:07:34.910139 ioctl(3, BLKRRPART, 0) = -1 EINVAL (Invalid argument)
17:07:34.910488 ioctl(3, FDEJECT, 0x9) = -1 EINVAL (Invalid argument)
17:07:34.910752 ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 0xbffff3c0) = -1 EINVAL (Invalid argument)
> 3. Reboot the computer.
> 4. Power cycle the computer.
The last two unlock the door (I have a feeling that POST on this machine
unconditionally unlocks the door).
--
> ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
--- John M. Ford
| < Previous | Next > |