Date: Fri, 1 Dec 2000 03:32:07 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dkelly@hiwaay.net (David Kelly) Cc: tlambert@primenet.com (Terry Lambert), questions@FreeBSD.ORG Subject: Re: ATAPI CD-RW drive: how? Message-ID: <200012010332.UAA19181@usr09.primenet.com> In-Reply-To: <200011300028.eAU0SeS59757@grumpy.dyndns.org> from "David Kelly" at Nov 29, 2000 06:28:40 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> [...]
>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012010332.UAA19181>