From owner-freebsd-questions Thu Nov 30 19:36:47 2000 Delivered-To: freebsd-questions@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 69FA037B400 for ; Thu, 30 Nov 2000 19:36:44 -0800 (PST) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id UAA16701; Thu, 30 Nov 2000 20:33:28 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp05.primenet.com, id smtpdAAAIiaOSC; Thu Nov 30 20:29:06 2000 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id UAA19181; Thu, 30 Nov 2000 20:32:07 -0700 (MST) From: Terry Lambert Message-Id: <200012010332.UAA19181@usr09.primenet.com> Subject: Re: ATAPI CD-RW drive: how? To: dkelly@hiwaay.net (David Kelly) Date: Fri, 1 Dec 2000 03:32:07 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), questions@FreeBSD.ORG In-Reply-To: <200011300028.eAU0SeS59757@grumpy.dyndns.org> from "David Kelly" at Nov 29, 2000 06:28:40 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > [...] > > I don't think it was that exotic. The cdrecord man page says a lot about > priority levels and real time features of kernels, that on some systems > its unable to gain higher priority than internal kernel processes, and > says this about Solaris which I don't fully understand but maybe you do: > > Cdrecord runs at priority 59 on Solaris, you should run > mkisofs at no more than priority 58. On other systems, you > should run mkisofs at no less than nice --18. The "cdrecord" program just writes data. The mkisofs is reading it, and may result in faults. The swapper is a kernel process, so if you are polling on an I/O completion, and are higher priority than the process which is going to satisfy your request, well, you get to wait forever. The same goes for feeding cdrecord, if you are piping to it. > Under Irix, the system froze the first time cdrecord accesses the blank > CD-R. All other disk activity stops (as observed by LEDs on the > devices). The freeze was fairly long, 10 to 15 seconds and ended when > the CD-R LED started flickering. I believe it was exactly the same under > FreeBSD 2.2.8. > > Its very likely it was a timed hang with the intent of presetting VM > state. Maybe; it's more likely a driver problem, where a request is being completed synchronously for some reason. This may be a requirement: I was able to lock up my ATAPI CD-RW to the point of needing a reboot by doing a burncd -t (test, don't write), and then interrupting the process. The thing would not even acknowledge an eject requests using the manual eject butto, and the drive activity light was off ("Doctor, it hurts when I do this..."; not a fair equivalence, since OS' should never lock up hardware under any circumstances). I suspect that I interrupted a series of synchronous required commands in the middle of a sequence. If you look at the SCSI commands in the sample cdrecord script, I think it's pretty clear that they took the easy way out on guaranteeing order of operation. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message