Date: Tue, 25 Aug 1998 08:37:31 +1000 From: Bruce Evans <bde@zeta.org.au> To: current@FreeBSD.ORG, dag-erli@ifi.uio.no Subject: Re: SCSI cd driver and SLICE Message-ID: <199808242237.IAA25725@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>The cd driver has been broken for some time now on SLICE systems. With >a SLICE kernel, any attempt at doing anything with an audio CD results >in a deadlock (e.g. 'tosha -i' hanging in vn_lock state). The drive SLICE systems have no special blo^H^H^Hsupport for SCSI cd devices (or non-SCSI cd devices, or od devices, or worm devices, or wfd devices ...), so the old DEVFS code gets used. Apparently it still has deadlock problems in the drivers that support slices (mainly cd, od and wfd). dsopen() calls devfs_remove_dev() on possibly-open devices, expecting it to much the same things as unlink() (just remove the device from the namespace), but DEVFS apparently does something with the possibly-open vnode and deadlocks. >bay is locked solid, cdcontrol can't unlock it (and hangs in vn_lock). >If I try to reboot, the system may or may not succeed in syncing the >disks, but does not set the clean flag on the root filesystem, and >either hangs after the sync or complains about a deadlock and panics >(no dump available, despite running with the fixed kern_shutdown.c and >autoconf.c). This is normal for a panic for an fs problem in -current. Something is likely to be locked and the sync is likely to run into it. The unmount of all file systems is certain to run in to any lock. >One other thing is that the device nodes for the CD aren't present >(except for /dev/cd0) - I have to try to mount the CD first (which >won't work since it's an audio CD, but will make the device nodes >appear). This is normal for old DEVFS/slice devices - you have to open the whole disk device to get slices and partitions generated. The open routine then flounders around looking for MBRs and labels. New DEVFS/SLICE devices are completely different. Slices and partitions are added asynchronously, initially at boot time, automatically at least for the media that is present at boot time. The mbr interrupt routines flounder and race around looking for MBRs and labels. >Mounting cd9660 CDs seems to work fine. Strange. It thought I tested it, but now always hangs on vn_loc (sic). Workaround 1: never use cd0a or cd0c. They are just compatibility cruft (aliases for cd0). dsopen() only calls devfs_remove_dev() on cd0a and cd0c, so there are no problems if they are possibly-but-not-actually open. Workaround 2: open cd0 first and keep it open until you change the disk. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808242237.IAA25725>