Date: Wed, 27 Sep 95 21:16 CDT From: uhclem%nemesis@fw.ast.com To: FreeBSD-gnats-submit@freebsd.org Subject: kern/750: cd9660 confused by not-ready or I/O errors FDIV030 Message-ID: <m0sy8W1-0004w0C@nemesis.lonestar.org> Resent-Message-ID: <199509280230.TAA23778@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 750 >Category: kern >Synopsis: cd9660 confused by not-ready or I/O errors FDIV030 >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Sep 27 19:30:03 PDT 1995 >Last-Modified: >Originator: Frank Durda IV >Organization: Hey Moe! This pipe is full of wires! >Release: FreeBSD 2.0.5-SNAP950726 i386 >Environment: A stock system with Matsushita CD-ROM (matcd0a), or SCSI CD-ROM (cd0a) that has a drive that allows media to be removed while mounted (including via emergency eject) >Description: If a mounted CD-ROM becomes not ready or returns other error codes associated with a media read error, or a media change or incompatible media error caused by incompatible media being loaded in place of compatible media (such as White or Red book vs Orange book HS/ISO), the cd9660 filesystem control layer will get in a state where it will not umount the device, and will keep the device mounted (but not usable) and the dev busy until the system is rebooted. >How-To-Repeat: Boot system Insert mountable (I used 2.0.5R CDROM) mount -t cd9660 /dev/your_scsi_device /mnt (I tried both with matcd0a and cd0a and both do the same thing) df (to confirm the device is listed as mounted) Now, eject the media, either by pressing the eject button, or if the drive is locked, use the emergency eject pin or tab. Remove 2.0.5R CD. Now, insert an audio CD into the player. Wait until the media has had ample time to come to speed and read the TOC. Allow 30 seconds. Now, type ls /mnt You should get one or more error messages. This is normal and the messages will vary with the drive type and driver. The ls command should abort. That is all normal. Now do a umount /dev/your_scsi_device I see: umount: /mnt: Input/output error That isn't a good thing. What is it waiting on? Writing the cache? :-) If you then do a df you will see that the file system is still mounted. So, you can't get the device unmounted at this point. Now remove the audio media in the drive, and replace the same disc you used earlier (2.0.5R in above example). Wait 30 seconds for it to become ready. Repeat the umount /dev/your_scsi_device still get: umount: /mnt: Input/output error (You can try another ls /mnt, but it won't work either.) At this point, that drive is dead, unusable until the system reboots. Attempting to issue a second mount for another mount point (say /mnt1) fails with "Device busy". A cat of the raw device also fails with a busy error. I originally stumbled into this by installing from the CD and was unaware that after rebooting, the 2.0.5 system silently mounted the 2.0.5R CD as part of the normal boot. It never occurred to me that this would happen. I then changed CDs to play an audio CD using xcdplayer, not knowing the device was mounted at this point, and ran into this very condition. First I ran xcdplayer and it complained about not being able to access the device, then I did a df and discovered the mount issue. Since not all drives (SCSI and otherwise) support and/or enforce door locking, it seems that cd9660 (or whatever is to blame) should not gag in this state and that a umount of a read-only file system should *always* work and close the dev. FYI, debug in the matcd driver shows that no open/close/read/ioctl calls are made to the driver at all after the first media change is discovered by the "ls" command, so the subsequent errors are all occurring somewhere above the driver. The driver never gets asked any more questions. >Fix: None known at this time. >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0sy8W1-0004w0C>