From owner-freebsd-bugs@FreeBSD.ORG Sat Mar 26 18:30:15 2011 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7678C106564A for ; Sat, 26 Mar 2011 18:30:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4C0A08FC0A for ; Sat, 26 Mar 2011 18:30:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2QIUF0d039214 for ; Sat, 26 Mar 2011 18:30:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2QIUFkf039206; Sat, 26 Mar 2011 18:30:15 GMT (envelope-from gnats) Date: Sat, 26 Mar 2011 18:30:15 GMT Message-Id: <201103261830.p2QIUFkf039206@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Alexander Best Cc: Subject: Re: misc/155925: CD tray is not locked even if using /dev/adc0. X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Best List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 18:30:15 -0000 The following reply was made to PR misc/155925; it has been noted by GNATS. From: Alexander Best To: Jaakko Heinonen Cc: koie@suri.co.jp, bug-followup@FreeBSD.org Subject: Re: misc/155925: CD tray is not locked even if using /dev/adc0. Date: Sat, 26 Mar 2011 18:27:02 +0000 On Sat Mar 26 11, Jaakko Heinonen wrote: > On 2011-03-25, Alexander Best wrote: > > this issue is not limited to acd. using cdcontrol -f /dev/cd gives the same > > behavior. > > I think this is because cdcontrol(1) first issues the CDIOCALLOW ioctl > to unlock the tray. Does this patch fix your problem? > > http://www.saunalahti.fi/~jh3/patches/cdcontrol-no-CDIOCALLOW.diff > > I am inclined to think that the behavior is intentional. i think the actual issue is not cdcontrol(1) so much, as CDIOCALLOW itself. looking at this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=125139 shouldn't CDIOCALLOW and CDIOCPREVENT have the same busy checks like CDIOCEJECT (as pointed out in the PR)? i haven't tested your patch, but i think it works. CDIOCEJECT checks the ref count. without the CDIOCALLOW and a ref count >= 1 the cd won't be ejected. i'm not sure whether CDIOCALLOW and CDIOCPREVENT should stay the way they are or not. making them dependent on the ref count won't allow ejecting a CD at all. this might cause problems if or some reason the ref count cannot be set to 0. e. g. unmounting a broken CD/DVD might fail. i'm not sure if umount -f will always suceeded, so we might not be able to reduce the ref count to 0 in certain situations. if in fact CDIOCALLOW/CDIOCPREVENT should work regardless of the ref count i think your patch is good to go. here are the other places CDIOCALLOW is being used: otaku% grep -r CDIOCALLOW * share/man/man4/cd.4:.It Dv CDIOCALLOW sys/cam/scsi/scsi_cd.c: case CDIOCALLOW: sys/dev/ata/atapi-cd.c: case CDIOCALLOW: sys/dev/mcd/mcd.c: case CDIOCALLOW: sys/dev/scd/scd.c: case CDIOCALLOW: sys/sys/cdio.h:#define CDIOCALLOW _IO('c',26) usr.sbin/cdcontrol/cdcontrol.c: (void) ioctl (fd, CDIOCALLOW); usr.sbin/cdcontrol/cdcontrol.c: (void) ioctl (fd, CDIOCALLOW); usr.sbin/cdcontrol/cdcontrol.c: (void) ioctl (fd, CDIOCALLOW); usr.sbin/sysinstall/cdrom.c: ioctl(fd, CDIOCALLOW); cheers. alex > > -- > Jaakko -- a13x