From owner-freebsd-current Fri May 29 10:04:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17170 for freebsd-current-outgoing; Fri, 29 May 1998 10:04:52 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.175.134.209]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17161 for ; Fri, 29 May 1998 10:04:48 -0700 (PDT) (envelope-from schilling@fokus.gmd.de) Received: from sherwood.gmd.de (sherwood [193.175.133.102]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id TAA21109; Fri, 29 May 1998 19:03:43 +0200 (MET DST) Received: (from jes@localhost) by sherwood.gmd.de (8.8.8+Sun/8.8.8) id TAA14897; Fri, 29 May 1998 19:03:23 +0200 (MET DST) Date: Fri, 29 May 1998 19:03:23 +0200 (MET DST) From: Joerg Schilling Message-Id: <199805291703.TAA14897@sherwood.gmd.de> To: mike@smith.net.au, schilling@fokus.gmd.de Cc: freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From mike@antipodes.cdrom.com Fri May 29 18:26:05 1998 >> First some notes. You are discussing things related to cdrecord. >> If you like to see your effort back in the main stream cdrecord, this >> is definitely the wring mailing list. >It's a good place to deal with the specifics of making cdrecord work on = >FreeBSD though. It's certainly unlikely that Peter would have been = I see that this should be discussed on the FreeBSD list too, but if you like to get help from me, you could not get it from freebsd-current, I am not subscribed. >The FreeBSD Posix implementation is still under development, and the = >scheduler module is an optional addition (as allowed for under the = >spec.). Cdrecord doesn't make the required runtime check for the = >presence of the desired functionality. OK, but this is a new issue. It never has been nessecary before. If other operating systems will start to behave similar, it would make autoconfiguration a lot more complex. >> >> > Bus error (core dumped) >> = >> If you are not able to analyze the core with adb and send a usable >> bug description, I cannot help.. >The bus error is (in my case at any rate) due to a buffer overrun = >elsewhere. I haven't been able to ascertain the cause of this yet, but = >there are indications that winding back the visible Posix interface = >resolves the issue. I am interested to find the reason for this core dump as it should not happen. Some versions of HP-UX have the definition for POSIX RR and do not implement it. On such HP_UX versions you usually get a warning about the non existence of RR scheduling and cdrecord then uses nice(2). I even may remove the warning if I an sure that no-one cares about the non existing RR class. I am testing cdrecord on all systems I can get hold of in a way that allows testing to me (root access). As the SCSI implementations usually are not sufficient, development and testing is mainly done on Solaris. >We're not talking about "rubbish". We're talking about an >in-development implementation of the Posix environment. OK, I understand. BTW: I would be happy if the user interface of the new SCSI user transport calls would be easier to access and to understand. In other words: I like to have the device files be present by default so that programs like cdrecord onlu have to open the right file to get access to the device. >> On SVr4 systems the _POSIX_PRIORITY_SCHEDULING is definitely worse >> than the RT priocntl() interface and proicntl with RR scheduling is eve= >n >> available since the early days of SVr4. I cannot change the source in a= > way >> that only makes sure that nothing works after the change. >This sounds like "rubbish" in SysV. I I would not call this rubbish, it is available since 1988/1989 - years before POSIX realtime enhanceements have beendefined and it grants you to be able to run a process at a higher priority than you pager. >> The scg drvier which I wrote in 1986 is based on this interface and >> itself is the base for my portable SCSI user-level command transport >> system. It should be faily easy to make a CAM adoption layer for scg. >It was. The real problems with scg have to do with the lack of visible >documentation. It is unclear how to do any sort of meaningful error >handling, or whether this should be managed at a lower level. Again, >this is an issue I was postponing until I had established that >everything else was going to behave and the interface had stabilised. OK, here is what I send to Sun some weeks ago: If you like to do a quick hack: - scsi_open() is currenltly not able to use anything but busno,target,lun You would get into trouble if you like to open /dev/rdsk/* - The interface funkctions are (currently): scsi_open() prepare a handle for later use with scsi_send() scsi_maxdma() return the max. amount of contiguous DMA on the current architecture scsi_getbuf(amt) allocate a (currently global - later open-specific) buffer of size 'amt' but not grater than scsi_maxdma() scsi_havebuf(busno) return TRUE/FALSE on whether the current machine includes a SCSI bus 'busno' scsi_fileno(bus, tgt, lun) return a filedescriptor to be used for the SCSI send ioctl. The filedesscriptor mus be the right one for bus/tgt/lun scsieset() as it says, need not to be implemented. scsi_send(f, struct scg_cmd *) Simulate the scg SCSI send command ioctl. returns: -1 usage error(e.g. EINVAL ....) 0 All other see scgio.h for a description of the fields in the struct. cmd->resid is set to the DMA residual count cmd-error is set to one of: SCG_NO_ERROR SCSI transport without error this is true for most failed commands too !!!! SCG_FATAL could not select target SCG_TIMEOUT a SCSI timeout occured SCG_RETRYABLE any other case cmd->ux_errno is set to the UNIX errno for a failed command (note: parameter error are covered above) cmd->scb is set to the SCSI Status byte for the command note there is currently no sense status cmd->sense must be filled with auto-sense data if the comand fails. cmd->sense_count must be set to the # of valid sense bytes /*--------------------------------------------------------------------------*/ I decided to make the SCSI ABI testuite available before I start to create a separate SCSI library. Jörg EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message