Date: Thu, 28 May 1998 07:34:50 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: paulz@trantor.stuyts.nl (Paul van der Zwan) Cc: freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Message-ID: <199805281134.HAA20418@hda.hda.com> In-Reply-To: <199805271425.QAA00517@trantor.stuyts.nl> from Paul van der Zwan at "May 27, 98 04:25:34 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I am getting write errors on my Philips 2600 CD-R using cd-write and burncd.sh > (from /usr/share/examples/worm/ ) so I thought , I'l compile cdrecord and try > that. But I get the following error when truying to do a dummy burn: > > $ sudo cdrecord -dev=0,4,0 -data -dummy /scratch/img/psnl > Cdrecord release 1.6 Copyright (C) 1995-1998 Jörg Schilling > cdrecord: Function not implemented. WARNING: Cannot set RR-scheduler > Bus error (core dumped) > > > This is a freshly compiled port on a current cvsupped today. (I wonder why he is trying to use the round robin scheduler - I expect he wants the FIFO one). Cdrecord has autoconf'd in the P1003.1B scheduler interface. I'm probably going to have to change how I did things, but the program may need fixing also. By default, with nothing defined, the new system calls are setup to be LKM'd in for development and will fail at run time with ENOSYS or if you check for their presense with sysconf(). You can add build time support with the _KPOSIX_PRIORITY_SCHEDULING option in the kernel. See how cdrecord is deciding to use priority scheduling. If it decides that a program that links OK without checking any compile time feature test macros means that priority scheduling is supported, then that should be changed. I've been told some programs are doing this (not specifically cdrecord). If you set _POSIX_C_SOURCE to 199009L with a -D in the makefile and cderecord still tries to use the round robin scheduler then someone has screwed up - either us or cdrecord - so try that too. I wasn't as naive as it might seem by setting this up the way I have (configured for an LKM). These (POSIX required) run time options are a pain to figure out how to support, and eventually there will be a mixture of systems supporting different options. Either everything becomes required, adding to kernel bloat, or programs will fail this way when there is a mixture of systems out there. You will build on one system with all support configured in and then run on another system and the programs won't handle ENOSYS properly. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval 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?199805281134.HAA20418>