From owner-freebsd-hackers Sun Jan 12 14:51:29 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA29087 for hackers-outgoing; Sun, 12 Jan 1997 14:51:29 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id OAA29072 for ; Sun, 12 Jan 1997 14:51:07 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA27764 for freebsd-hackers@freebsd.org; Sun, 12 Jan 1997 23:50:59 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id XAA06804; Sun, 12 Jan 1997 23:20:09 +0100 (MET) Message-ID: Date: Sun, 12 Jan 1997 23:20:09 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@freebsd.org Subject: Re: mount -o async on a news servre References: <199701122138.OAA26359@phaeton.artisoft.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701122138.OAA26359@phaeton.artisoft.com>; from Terry Lambert on Jan 12, 1997 14:38:08 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Terry Lambert wrote: > > You simply can't do this. Either, the drive reports a medium size, or > > it doesn't. If it doesn't, you're at wits end: the drive could > > support differently sized media as well, so you can't even guess which > > one Terry will insert next. ;-) > > Oh? > > So then why is the OS even looking until it gets an insertion event? Since you misinterpreting it. It doesn't wait for an `insertion event' (since this doesn't exist at all). > If the media isn't present, it has no business making observations > about geometry in the first place. Yes, that's an error. > > > (ncr0:1:0): "iomega jaz 1GB G.60" type 0 removable SCSI 2 > > > sd1(ncr0:1:0): Direct-Access > > > sd1(ncr0:1:0): FAST SCSI-2 100ns (10 Mb/sec) offset 8. > > > > > > sd1(ncr0:1:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB > > > > This one might be a FreeBSD driver problem. You can compile your > > kernel with SCSIDEBUG enabled, to learn which SCSI command triggered > > that problem. > > Mode sense on a drive it knows to (1) be removable and (2) to not have > media inserted. No. That doesn't make in invalid CDB, only a command returning with an error status. Please, don't guess, but have a look. Or send me the drive, so i can have a look. SCSIDEBUG is really your friend, even though the flood of data is hard to read. > > > (yes, the drive was spun up at the time, so you can't blame that). > > > > The drive was not read. It claimed the medium being not present. How (ready) > > should the driver know that there really was a medium in the drive, if > > it claims wrong? (FreeBSD had a problem with devices saying ``Device > > is in the process of becoming ready'', but i fixed this recently.) > > You are confusing the error on boot without media inserted with me > explaining that the delay on umount was not the driver waiting for > the drive to spin up. No. I am not. The drive said ``Media not present''. That's it. It didn't say ``...is in the process of becoming ready'' (which used to be fatal in FreeBSD but is no longer). > > (It doesn't even announce the arrival of a new medium unless you ask > > for it, sadly.) > > I think you can have a request outstanding with a long timeout, which will > be satisfied by insertion... No. It will be aborted by the drive with a ``Device not ready'' (or ``Media not present'') error before. You either need that click click click, or you have to live as it is. I prefer the latter. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)