From owner-freebsd-scsi Mon Jan 8 01:55:30 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA26648 for freebsd-scsi-outgoing; Mon, 8 Jan 1996 01:55:30 -0800 (PST) Received: from tuminfo2.informatik.tu-muenchen.de (root@tuminfo2.informatik.tu-muenchen.de [131.159.0.81]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA26634 for ; Mon, 8 Jan 1996 01:55:13 -0800 (PST) Received: from sunsystem5.informatik.tu-muenchen.de ([131.159.0.125]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26482-2>; Mon, 8 Jan 1996 10:54:04 +0100 Received: by sunsystem5.informatik.tu-muenchen.de id <15879>; Mon, 8 Jan 1996 10:53:46 +0100 To: freebsd-scsi@freefall.FreeBSD.org Path: news From: kowa@sunbayer45.informatik.tu-muenchen.de (Wolfgang Kowarschick) Newsgroups: muc.lists.freebsd.scsi Subject: scsi problems Date: 08 Jan 1996 10:53:14 +0100 Organization: tu muenchen Lines: 47 Fake-Sender: kowa@sunbayer45.informatik.tu-muenchen.de Message-ID: NNTP-Posting-Host: sunbayer45.informatik.tu-muenchen.de X-Newsreader: Gnus v5.1 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk Hi, I've some problems with my scsi bus. At unpredictable times, but usually if there is havy scsi transfer (e.g., dump disc to dat), I get input/output-errors on the scsi bus. In this case, all I can do is to press the reset button. I'm running FreeBSD 2.1.0 on an Asus P55TP4XE Board with an Asus PCI-SC200 controller (NCR 53c810). I've three internal devices (Quantum Atlas 2GB, NEC CD-Rom 512, SQ 555 (44MB)) and one external device (HP Dat Streamer). The termination of the scsi-bus seems to be correct (I'm not quite sure with the disk as I've no description of the jumper settings, but I think it's ok). kernel output (copied by hand, so there may be some typos): /kernel: st0(ncr0:3:0): NOT READY asc:4,1 logical unit is in process of becomming ready phase change 2-7 10@004fc558 resid=9 ncr0:0: ERROR(81:0) (f-aa-0) (8/13) @ (eq8:48000000) script cond = c0000008 reg: da 10 00 13 47 08 00 1f 78 0f 80 aa 80 00 02 00 ncr0: target 0 doesn't release the bus ncr: handshake timeout sd0(ncr0:0:0): COMMAND failed (6ff) @f09fdcc From owner-freebsd-scsi Mon Jan 8 03:14:40 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA01799 for freebsd-scsi-outgoing; Mon, 8 Jan 1996 03:14:40 -0800 (PST) Received: from haywire.DIALix.COM (news@haywire.DIALix.COM [192.203.228.65]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA01794 for ; Mon, 8 Jan 1996 03:14:31 -0800 (PST) Received: (from news@localhost) by haywire.DIALix.COM (sendmail) id TAA09084 for freebsd-scsi@freebsd.org; Mon, 8 Jan 1996 19:14:15 +0800 (WST) Received: from GATEWAY by haywire.DIALix.COM with netnews for freebsd-scsi@freebsd.org (problems to: usenet@haywire.dialix.com) To: freebsd-scsi@freebsd.org Date: Mon, 8 Jan 1996 09:04:21 GMT From: mark@seeware.DIALix.oz.au (Mark Hannon) Message-ID: Organization: Private FreeBSD site Subject: Future domain driver Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk Hi, I have been offered a Future Domain 1680 ISA SCSI card. I have currently two IDE HDs and am in desperate need to increase my disk capacity. Is there a FreeBSD driver to support this configuration? I can only find mention of Future domain 8xxxx drivers in the Release notes. Which driver would I use in this case? Regards, Mark -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Mark Hannon,| FreeBSD - Free Unix for your PC| mark@seeware.DIALix.oz.au| | Melbourne, | PGP key available by fingering | epamha@epa.ericsson.se | | Australia | seeware@melbourne.DIALix.oz.au | | From owner-freebsd-scsi Mon Jan 8 05:42:55 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA09414 for freebsd-scsi-outgoing; Mon, 8 Jan 1996 05:42:55 -0800 (PST) Received: from tuminfo2.informatik.tu-muenchen.de (root@tuminfo2.informatik.tu-muenchen.de [131.159.0.81]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id FAA09396 for ; Mon, 8 Jan 1996 05:42:17 -0800 (PST) Received: from sunsystem5.informatik.tu-muenchen.de ([131.159.0.125]) by tuminfo2.informatik.tu-muenchen.de with ESMTP id <26478-1>; Mon, 8 Jan 1996 14:13:32 +0100 Received: by sunsystem5.informatik.tu-muenchen.de id <15879>; Mon, 8 Jan 1996 14:13:18 +0100 To: freebsd-scsi@freefall.FreeBSD.org Path: news From: kowa@sunbayer45.informatik.tu-muenchen.de (Wolfgang Kowarschick) Newsgroups: muc.lists.freebsd.scsi Subject: Re: scsi problems (Repost) Date: 08 Jan 1996 14:12:58 +0100 Organization: TU Muenchen Lines: 50 Fake-Sender: kowa@sunbayer45.informatik.tu-muenchen.de Message-ID: References: NNTP-Posting-Host: sunbayer45.informatik.tu-muenchen.de In-reply-to: kowa@sunbayer45.informatik.tu-muenchen.de's message of 8 Jan 1996 11:59:39 +0100 X-Newsreader: Gnus v5.1 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk OOPS, there is missing a part of my message. Sorry! Here is my qusetion again (hope, now it's ok): Hi, I've some problems with my scsi bus. At unpredictable times, but usually if there is havy scsi transfer (e.g., dump disc to dat), I get input/output-errors on the scsi bus. In this case, all I can do is to press the reset button. I'm running FreeBSD 2.1.0 on an Asus P55TP4XE Board with an Asus PCI-SC200 controller (NCR 53c810). I've three internal devices (Quantum Atlas 2GB, NEC CD-Rom 512, SQ 555 (44MB)) and one external device (HP Dat Streamer). The termination of the scsi-bus seems to be correct (I'm not quite sure with the disk as I've no description of the jumper settings, but I think it's ok). kernel output (copied by hand, so there may be some typos): /kernel: st0(ncr0:3:0): NOT READY asc:4,1 logical unit is in process of becomming ready phase change 2-7 10@004fc558 resid=9 ncr0:0: ERROR(81:0) (f-aa-0) (8/13) @ (eq8:48000000) script cond = c0000008 reg: da 10 00 13 47 08 00 1f 78 0f 80 aa 80 00 02 00 ncr0: target 0 doesn't release the bus ncr: handshake timeout sd0(ncr0:0:0): COMMAND failed (6ff) @f09fdcc etc. sd0(ncr0:0:0): RECOVERED ERROR info?:1c1018a, retries 3 sd0(ncr0:0:0): FAST SCSI-2 100 ns (10 Mb/sec) offset 8 st0(ncr0:3:0): 200ns (5Mb/sec) offset 8 st0(ncr0:3:0): UNIT ATTENTION asc:29,0 st0(ncr0:3:0): power on, reset, or bus device reset occurred st0: oops not queued vnode_papger_input: I/O read error vm_fault: pager input (problably hardware) error, PID 310 failes Note that the vm_fault error does also occur sometimes when the dat-streamer is switched off. I'm grateful for every hint. Many thanks in advance!! Wolfgang From owner-freebsd-scsi Mon Jan 8 07:38:57 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA16062 for freebsd-scsi-outgoing; Mon, 8 Jan 1996 07:38:57 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA16037 for ; Mon, 8 Jan 1996 07:38:25 -0800 (PST) Received: by Sysiphos id AA26449 (5.67b/IDA-1.5 for freebsd-scsi@freefall.freebsd.org); Mon, 8 Jan 1996 16:38:08 +0100 Message-Id: <199601081538.AA26449@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 8 Jan 1996 16:38:07 +0100 In-Reply-To: kowa@sunbayer45.informatik.tu-muenchen.de (Wolfgang Kowarschick) "scsi problems" (Jan 8, 10:53) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: kowa@sunbayer45.informatik.tu-muenchen.de (Wolfgang Kowarschick) Subject: Re: scsi problems Cc: freebsd-scsi@freefall.freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk On Jan 8, 10:53, Wolfgang Kowarschick wrote: } Subject: scsi problems } } Hi, } } I've some problems with my scsi bus. At unpredictable times, } but usually if there is havy scsi transfer (e.g., dump } disc to dat), I get input/output-errors on the scsi bus. } In this case, all I can do is to press the reset button. } } I'm running FreeBSD 2.1.0 on an Asus P55TP4XE Board with } an Asus PCI-SC200 controller (NCR 53c810). I've three internal } devices (Quantum Atlas 2GB, NEC CD-Rom 512, SQ 555 (44MB)) } and one external device (HP Dat Streamer). } The termination of the scsi-bus seems to be correct } (I'm not quite sure with the disk as I've no description } of the jumper settings, but I think it's ok). } } kernel output (copied by hand, so there may be some typos): } } /kernel: st0(ncr0:3:0): NOT READY asc:4,1 } logical unit is in process of becomming ready } phase change 2-7 10@004fc558 resid=9 } ncr0:0: ERROR(81:0) (f-aa-0) (8/13) @ (eq8:48000000) } script cond = c0000008 } reg: da 10 00 13 47 08 00 1f 78 0f 80 aa 80 00 02 00 } ncr0: target 0 doesn't release the bus } ncr: handshake timeout } sd0(ncr0:0:0): COMMAND failed (6ff) @f09fdcc I'll look into this in detail later ... Just wanted to acknowledge reception of your bug report. Regards, STefan From owner-freebsd-scsi Mon Jan 8 13:35:12 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA10586 for freebsd-scsi-outgoing; Mon, 8 Jan 1996 13:35:12 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA10476 Mon, 8 Jan 1996 13:34:19 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA09249; Mon, 8 Jan 1996 22:34:01 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA08317; Mon, 8 Jan 1996 22:34:01 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id WAA16985; Mon, 8 Jan 1996 22:20:27 +0100 (MET) From: J Wunsch Message-Id: <199601082120.WAA16985@uriah.heep.sax.de> Subject: Good News :) To: freebsd-current@FreeBSD.org (FreeBSD-current users), freebsd-scsi@FreeBSD.org Date: Mon, 8 Jan 1996 22:20:26 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.org Precedence: bulk I've burnt my first CD today! Well, i sorta mis-burnt two of them, but the first step has been done. :-) -- 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. ;-) From owner-freebsd-scsi Mon Jan 8 17:42:36 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA26896 for freebsd-scsi-outgoing; Mon, 8 Jan 1996 17:42:36 -0800 (PST) Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA26890 for ; Mon, 8 Jan 1996 17:42:32 -0800 (PST) Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id UAA24177; Mon, 8 Jan 1996 20:44:15 -0500 From: Peter Dufault Message-Id: <199601090144.UAA24177@hda.com> Subject: Re: Good News :) To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 8 Jan 1996 20:44:14 -0500 (EST) Cc: freebsd-scsi@FreeBSD.org In-Reply-To: <199601082120.WAA16985@uriah.heep.sax.de> from "J Wunsch" at Jan 8, 96 10:20:26 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.org Precedence: bulk > I've burnt my first CD today! > > Well, i sorta mis-burnt two of them, but the first step has been done. Details on the tools you used, please. And did you do it single user or multi user? Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-scsi Mon Jan 8 23:21:57 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA17164 for freebsd-scsi-outgoing; Mon, 8 Jan 1996 23:21:57 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA17158 for ; Mon, 8 Jan 1996 23:21:46 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA25596 for ; Tue, 9 Jan 1996 08:21:40 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA12720 for freebsd-scsi@FreeBSD.org; Tue, 9 Jan 1996 08:21:40 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id IAA09073 for freebsd-scsi@FreeBSD.org; Tue, 9 Jan 1996 08:16:08 +0100 (MET) From: J Wunsch Message-Id: <199601090716.IAA09073@uriah.heep.sax.de> Subject: Re: Good News :) To: freebsd-scsi@FreeBSD.org Date: Tue, 9 Jan 1996 08:16:07 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199601090144.UAA24177@hda.com> from "Peter Dufault" at Jan 8, 96 08:44:14 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.org Precedence: bulk As Peter Dufault wrote: > > > I've burnt my first CD today! > > > > Well, i sorta mis-burnt two of them, but the first step has been done. > > Details on the tools you used, please. And did you do it single > user or multi user? This was just the proof-of-concept stage. The tools were scsi(8) (actually, a bunch of them -- thanks, Peter!) and team(1), wrapped together by a Perl script. Using dd(1), the burner starved immediately. With team(1), it looks better. You can run enough processes pre-reading data from the disk, thus caching it in memory. This was running in ``slight multi- user'' mode, i.e. multi-user stage with just a single user logged in, no X11, no heavy background tasks. I forgot to raise the process into rtprio, however. While the first attempt went through but rendered me with an unusable disk since i've totally misunderstood team's man page, the second one starved after burning about 50 MB. The CD is mountable, the directory structure is intact, but it experiences lotta errors when reading most of the files. Anyway, the ~ 50 MB are way more than the machine has RAM, so it's still proving that it can be made work. Burner and source disk are on different SCSI busses, but i'm not sure if this is really necessary. It's just the configuration of that machine (one bus for the dis[s], another one for the slow peripheral devices). The bad news is, manufacturers of CD burners disagree about the command set. My experiment ran with a ``Plasmon Data RF4100'', and with some minor hassles (downloading from an US BBS via transatlantic phone lines, ick) i could get their SCSI manual. Judging from Linux' cdwrite, most burners seem to be only slightly different in the command handling, with the major exception of Yamaha. They do just everything different. So when stuffing all the invocations of scsi(8) back into the kernel, i'm thinking of an lkm-based interface, where the actual CD-R handler must be plugged in as a loadable module. Who is interested in dicussing further issues of the concept (once i've got further)? Should i do this in this list? -- 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. ;-) From owner-freebsd-scsi Tue Jan 9 03:08:33 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA01775 for freebsd-scsi-outgoing; Tue, 9 Jan 1996 03:08:33 -0800 (PST) Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA01768 for ; Tue, 9 Jan 1996 03:08:19 -0800 (PST) Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id GAA25461; Tue, 9 Jan 1996 06:05:33 -0500 From: Peter Dufault Message-Id: <199601091105.GAA25461@hda.com> Subject: Re: Good News :) To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 9 Jan 1996 06:05:33 -0500 (EST) Cc: freebsd-scsi@FreeBSD.org In-Reply-To: <199601090716.IAA09073@uriah.heep.sax.de> from "J Wunsch" at Jan 9, 96 08:16:07 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.org Precedence: bulk > > > I've burnt my first CD today! > > > > > > Well, i sorta mis-burnt two of them, but the first step has been done. > > > > Details on the tools you used, please. And did you do it single > > user or multi user? > > This was just the proof-of-concept stage. > > The tools were scsi(8) (actually, a bunch of them -- thanks, Peter!) > and team(1), wrapped together by a Perl script. > > Using dd(1), the burner starved immediately. With team(1), it looks > better. You can run enough processes pre-reading data from the disk, > thus caching it in memory. This was running in ``slight multi- user'' > mode, i.e. multi-user stage with just a single user logged in, no X11, > no heavy background tasks. I forgot to raise the process into rtprio, > however. While the first attempt went through but rendered me with an > unusable disk since i've totally misunderstood team's man page, the > second one starved after burning about 50 MB. The CD is mountable, > the directory structure is intact, but it experiences lotta errors > when reading most of the files. Anyway, the ~ 50 MB are way more than > the machine has RAM, so it's still proving that it can be made work. Eventually I'd like the system to schedule I/O requests based on the rtprio priority. I have a scratch kernel around that prefers rtprio requests to normal ones. It makes xcdplayer snappy. One problem with scsi(3) and therefore scsi(8) is these don't use the start queue and so you'll get the latency to resume each process even with a "team" approach to running scsi(8). I assume you're doing some combination of scsi(8) scripts to setup then some "team" dd incantations to transfer the data to the CD-R? > Burner and source disk are on different SCSI busses, but i'm not sure > if this is really necessary. It's just the configuration of that > machine (one bus for the dis[s], another one for the slow peripheral > devices). > > The bad news is, manufacturers of CD burners disagree about the > command set. My experiment ran with a ``Plasmon Data RF4100'', and > with some minor hassles (downloading from an US BBS via transatlantic > phone lines, ick) i could get their SCSI manual. Judging from Linux' > cdwrite, most burners seem to be only slightly different in the > command handling, with the major exception of Yamaha. They do just > everything different. So when stuffing all the invocations of scsi(8) > back into the kernel, i'm thinking of an lkm-based interface, where > the actual CD-R handler must be plugged in as a loadable module. But don't forget some people may have more than one CD-R, though I don't know if they'll need more than one "personality" loaded at once. The scsi code can accept user defined types loaded via an LKM. If you wanted to do it your way you could have the base code in the kernel as a WORM type and then LKM in support for specific devices that use the WORM code as a library. We do have to clean up that conf code to make this work cleanly. An aside - one thing I'll point out is it would be easy to hack scsi(8) to spit out a C code interface for one of its command strings. I don't know if that is of interest or not. > Who is interested in dicussing further issues of the concept (once > i've got further)? Should i do this in this list? If no one else chimes in we'll take it off line. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-scsi Tue Jan 9 05:28:17 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA09361 for freebsd-scsi-outgoing; Tue, 9 Jan 1996 05:28:17 -0800 (PST) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.101]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id FAA09354 for ; Tue, 9 Jan 1996 05:28:11 -0800 (PST) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.203]) by innocence.interface-business.de (8.6.11/8.6.9) with ESMTP id OAA18899 for ; Tue, 9 Jan 1996 14:29:44 +0100 Received: (from j@localhost) by ida.interface-business.de (8.6.11/8.6.9) id OAA02956 for freebsd-scsi@freebsd.org; Tue, 9 Jan 1996 14:28:08 +0100 From: J Wunsch Message-Id: <199601091328.OAA02956@ida.interface-business.de> Subject: Tape density&blocksize To: freebsd-scsi@freebsd.org Date: Tue, 9 Jan 1996 14:28:07 +0100 (MET) Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) X-Phone: +49-351-31809-14 X-Fax: +49-351-3361187 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk Why is this? switch ((int)st->density) { case HALFINCH_800: case HALFINCH_1600: case HALFINCH_6250: case DDS: st->flags &= ~ST_FIXEDBLOCKS; st->blksiz = 0; SC_DEBUG(sc_link, SDEV_DB3, ("density specified variable\n")); goto done; case QIC_11: case QIC_24: case QIC_120: case QIC_150: >>> case QIC_525: >>> case QIC_1320: st->flags |= ST_FIXEDBLOCKS; if (st->media_blksiz > 0) { st->blksiz = st->media_blksiz; } else { st->blksiz = DEF_FIXED_BSIZE; } To the best of my knowledge, QIC >= 525 is also variable-length. Is there any particular reason for the above? Where could i find what a tape density code 0x92 might be? I'm currently helping somebody to diagnose the Exabyte-2501 problems several people have been reporting. It looks like these are related to density and/or blocksize probs. (EXB-2501 is a 2-gig QIC drive, apparently rather new, and it doesn't work right out of the box under FreeBSD.) -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de [private: http://www.sax.de/~joerg/] From owner-freebsd-scsi Tue Jan 9 10:51:21 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA28291 for freebsd-scsi-outgoing; Tue, 9 Jan 1996 10:51:21 -0800 (PST) Received: from Sysiphos (Sysiphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA28283 for ; Tue, 9 Jan 1996 10:51:17 -0800 (PST) Received: by Sysiphos id AA13775 (5.67b/IDA-1.5 for freebsd-scsi@freebsd.org); Tue, 9 Jan 1996 19:51:10 +0100 Message-Id: <199601091851.AA13775@Sysiphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Tue, 9 Jan 1996 19:51:09 +0100 In-Reply-To: kowa@sunbayer45.informatik.tu-muenchen.de (Wolfgang Kowarschick) "Re: scsi problems (Repost)" (Jan 8, 14:12) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: kowa@sunbayer45.informatik.tu-muenchen.de (Wolfgang Kowarschick) Subject: Re: scsi problems (Repost) Cc: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk On Jan 8, 14:12, Wolfgang Kowarschick wrote: } Subject: Re: scsi problems (Repost) } I'm running FreeBSD 2.1.0 on an Asus P55TP4XE Board with } an Asus PCI-SC200 controller (NCR 53c810). I've three internal } devices (Quantum Atlas 2GB, NEC CD-Rom 512, SQ 555 (44MB)) } and one external device (HP Dat Streamer). } The termination of the scsi-bus seems to be correct } (I'm not quite sure with the disk as I've no description } of the jumper settings, but I think it's ok). } } kernel output (copied by hand, so there may be some typos): } } /kernel: st0(ncr0:3:0): NOT READY asc:4,1 } logical unit is in process of becomming ready } phase change 2-7 10@004fc558 resid=9 } ncr0:0: ERROR(81:0) (f-aa-0) (8/13) @ (eq8:48000000) } script cond = c0000008 The 81 dstat indicates an illegal instruction. There are two possible reasons: 1) The current instruction is not defined at all. 2) The current instruction can't be executed in the current context (e.g. state of the SCSI bus). In your case 1) seems to apply. There is no instruction starting with 48. This indicates a memory problem, IMHO. Guess that the DRAM speed is marginally sufficient, but sometimes just a little to low ... If this can be reproduced, then please send more such logs. (You mentioned the possibility of typos: Please make sure those numbers are excactly what was written in the error log. At least ALL numbers in the two lines quoted above MUST match reality, or I'm at a loss :-) } vnode_papger_input: I/O read error } vm_fault: pager input (problably hardware) error, PID 310 failes } Note that the vm_fault error does also occur sometimes when the dat-streamer } is switched off. Well, then just DON't do it ... SCSI is not meant to be hot-pluggable! And switching off devices may cause spikes on the bus lines. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se From owner-freebsd-scsi Tue Jan 9 11:25:47 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA00279 for freebsd-scsi-outgoing; Tue, 9 Jan 1996 11:25:47 -0800 (PST) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.101]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA00271 for ; Tue, 9 Jan 1996 11:25:34 -0800 (PST) Received: from ida.interface-business.de (ida.interface-business.de [193.101.57.203]) by innocence.interface-business.de (8.6.11/8.6.9) with ESMTP id UAA19760 for ; Tue, 9 Jan 1996 20:27:12 +0100 Received: (from j@localhost) by ida.interface-business.de (8.6.11/8.6.9) id UAA01102 for freebsd-scsi@freebsd.org; Tue, 9 Jan 1996 20:25:13 +0100 From: J Wunsch Message-Id: <199601091925.UAA01102@ida.interface-business.de> Subject: More CD-R news To: freebsd-scsi@freebsd.org Date: Tue, 9 Jan 1996 20:25:11 +0100 (MET) Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) X-Phone: +49-351-31809-14 X-Fax: +49-351-3361187 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk Well, i've finally got the first successfully burnt CD. Here's a bit more about the equipment: . The burner is a: (ahc1:0:0): "PLASMON RF4100 1.28" type 4 removable SCSI 2 It has 2 MB cache, and burns @ 360 KB/s. . There were still some show-stoppers in the driver, i will cleanup and commit the fixes RSN. The most annoying show-stopper was the CD block count limitation, that didn't account for the CD blocks being 2048 bytes long, while the struct buf blocks are DEV_BSIZE long, so one of my attempts ended up prematurely since the driver thought the CD were full while it was only 1/4 filled. :( . Before running the successful burn, i've made a couple of dummy burns (pretend a burn, but don't actually turn on the laser). I've been using one of them as a ``load test'', to see how much i could do on the machine while the CD writing was in progress. The machine is an i486/100 with (only) 16 MB RAM, and 2 AHA2940s. One of the controllers is dedicated to the hard disk, the other one drives a CD-ROM, a DAT tape, and the CD-R. The actual driver for burning the CD is a combination of team(1) and dd(1). Team is used in order to have a multiplexed disk read / pipe write utility that serves as a user-program cache. I ran team with 5 processes and one MB buffer for each of them. Top shows that the processes actually account for about 1 MB RSS, so this seems to work as expected. The dd was needed in order to `slice' team's output stream into multiples of the blocksize of the CD (i've used 10 * blocksize). This is not as much a problem for data CDs, but would really be necessary when it comes to audio CDs which have a blocksize of 2352 bytes. Team ran with `rtprio', in order to increase its probability to get the required resources. . The load test consisted of running the entire dummy burn running under X11 in the normal multi-user environment. Everything went fine, including a minor test compilation (about 5 smaller C sources, linked together with a bunch of X11 libs), and running `beforelight' as the screen saver (which even under normal circumstances tends to cause larger paging activity when the screen saver becomes active, or when it's de-activated). The average swap usage levelled about 33 MB. :) The test burn finally starved (CD-R write buffer underrun) when one of my colleages piped a larger PostScript file through lpd, not thinking of the fact that the ghostscript converter would also ran on my PC. :--) Anyway, this seems to be not too bad. I've made another test run after this, without X11, and this one even survived the ghostscript test. ;-) . After all these tests, the `hot' run was rather unimpressive. Still full multiuser, no X11, but i used to do some regular user activity from the text consoles (login, elm, rlogin, rcp), without affecting the CD-R too much. It finally completed to burn 460 MB of test data after 1500 seconds. Now back to thinking about the worm driver architecture. :) p.s.: Just to provide an impression about what's needed to burn a CD, here's the Perl script: #!/usr/bin/perl # $ENV{'PATH'} = "/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin"; # For FreeBSD <= 2.1, the control device didn't work, use the regular # device: ##$wormctl = "/dev/rworm0"; $wormctl = "/dev/rworm0.ctl"; $wormdata = "/dev/rworm0"; # set dummy to yes if the command should be faked #$dummy = "yes"; $dummy = "no"; $verbose = 1; $mode = "data"; $preempt = 0; $toc_type = "ROM"; # timeouts $medium = 30; $long = 10 * 60; $bsize_data = 2048; $bsize_audio = 2352; # direct SCSI operations sub test_unit_ready { $verbose && print "test_unit_ready\n"; system ("scsi", "-f", $wormctl, "-c", "0 0 0 0 0 0") && die "scsi failed\n"; } sub clear_unit_attn { $verbose && print "clear_unit_attn\n"; # test unit ready with stderr supressed if(fork == 0) { close STDOUT; close STDERR; close STDIN; exec "scsi", "-f", $wormctl, "-c", "0 0 0 0 0 0"; } else { wait; } } sub rezero_unit { $verbose && print "rezero_unit\n"; system ("scsi", "-s", $medium, "-f", $wormctl, "-c", "1 0 0 0 0 0") && die "scsi failed\n"; } sub start_stop { local($start) = @_; $verbose && printf "start_stop(%d)\n", $start; system ("scsi", "-s", $medium, "-f", $wormctl, "-c", "1b 0 0 0 0:b7 v:b1 0", $start? "1": "0") && die "scsi failed\n"; } sub synchronize_cache { $verbose && print "synchronize_cache\n"; system ("scsi", "-s", $medium, "-f", $wormctl, "-c", "35 0 v:i4 0 v:i2 0", "0", "0") && die "scsi failed\n"; } sub prevent_allow_medium_removal { local($prevent) = @_; $verbose && printf "prevent_allow_medium_removal(%d)\n", $prevent; system ("scsi", "-f", $wormctl, "-c", "1e 0 0 0 0:b7 v:b1 0", $prevent? "1": "0") && die "scsi failed\n"; } sub fixation { local($toc_type) = @_; $verbose && printf "fixation(%s)\n", $toc_type; system ("scsi", "-s", $long, "-f", $wormctl, "-c", "e9 0 0 0 0 0 0 0 0:b4 v:b1 v:b3 0", "0", $toc_type eq "ROM"? "1": "0") && die "scsi failed\n"; } sub recover { system ("scsi", "-s", $medium, "-f", $wormctl, "-c", "ec 0 0 0 0 0 0 0 0 0") && die "scsi failed\n"; } sub reserve_track { local($len) = @_; system ("scsi", "-f", $wormctl, "-c", "e4 0 0 0 0 v:i4 0", "$len") && die "scsi failed\n"; } sub write_track { local($audio, $preemp) = @_; local($x); $verbose && printf "write_track(%s, %d)\n", $audio, $preemp; if($audio eq "audio") { $x = $preemp? "5": "4"; } else { $x = "1"; } system ("scsi", "-f", $wormctl, "-c", "e6 0 0 0 0 v:i1 0:b4 v:b4 0 0 0", "0", $x) && die "scsi failed\n"; } sub load_unload { local($load) = @_; $verbose && printf "load_unload(%d)\n", $load; system ("scsi", "-s", $medium, "-f", $wormctl, "-c", "e7 0 0 0 0 0 0 0 0:b7 v:b1 0", $load? "0": "1") && die "scsi failed\n"; } sub per_disk_select { local($dummy, $speed) = @_; $verbose && printf "per_disk_select(%s, %s)\n", $dummy, $speed; system ("scsi", "-f", $wormctl, "-c", "15 0:b3 v:b1 0:b3 v:b1 0 0 0c 0", "1", "0", "-o", "12", "0 0 0 0 23 06 v:i1 v:i1 0 0 0 0", $speed eq "audio"? "1": "2", $dummy eq "yes"? "1": "0") && die "scsi failed\n"; } sub per_track_select { local($audio, $preemp) = @_; local($x, $blksiz); $verbose && printf "per_track_select(%s, %d)\n", $audio, $preemp; if($audio eq "audio") { $blksiz = "2352"; $x = $preemp? "5": "4"; } else { $blksiz = "2048"; $x = "1"; } system ("scsi", "-f", $wormctl, "-c", "15 0:b3 v:b1 0:b3 v:b1 0 0 1c 0", "1", "0", "-o", "28", "0 0 0 8 0 v:i3 0 v:i3 21 0e 0 0:b4 v:b4 0 0 0 0 0 0 0 0 0 0 0 0", "0", $blksiz, $x) && die "scsi failed\n"; } die "usage: $0 inputfile\n" unless $#ARGV == 0; die "Must be root to run this\n" unless $< == 0; print "Preparing unit\n"; &clear_unit_attn; &load_unload(1); &clear_unit_attn; &prevent_allow_medium_removal(1); &start_stop(1); &rezero_unit; &test_unit_ready; &start_stop(1); &per_disk_select($dummy, $mode); print "Preparing track\n"; &per_track_select($mode, 0); #&reserve_track(0); #&write_track($mode, 0); print "Writing track\n"; $bsize = $mode eq "audio"? $bsize_audio: $bsize_data; $bsize *= 10; #system "dd", "if=$ARGV[0]", "of=$wormdata", "obs=$bsize", "conv=sync"; system "rtprio 5 team -v 1m 5 < $ARGV[0] | dd of=$wormdata obs=$bsize"; &synchronize_cache; if($dummy ne "yes") { print "Fixating\n"; &fixation($toc_type); } print "Stopping\n"; &start_stop(0); &prevent_allow_medium_removal(0); &load_unload(0); print "Done.\n"; -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de [private: http://www.sax.de/~joerg/] From owner-freebsd-scsi Tue Jan 9 13:10:16 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA06920 for freebsd-scsi-outgoing; Tue, 9 Jan 1996 13:10:16 -0800 (PST) Received: from omega.physik.fu-berlin.de (omega.physik.fu-berlin.de [130.133.3.51]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA06812 Tue, 9 Jan 1996 13:09:22 -0800 (PST) Received: from mordillo (oberon.physik.fu-berlin.de [130.133.3.126]) by omega.physik.fu-berlin.de (8.7.1/8.7.1) with ESMTP id WAA11429; Tue, 9 Jan 1996 22:09:15 +0100 (MET) Received: (from graichen@localhost) by mordillo (8.6.12/8.6.12) id TAA00286; Tue, 9 Jan 1996 19:48:35 +0100 From: Thomas Graichen Message-Id: <199601091848.TAA00286@mordillo> Subject: Re: Good News :) To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 9 Jan 1996 19:48:34 +0100 (MET) Cc: freebsd-current@freebsd.org, freebsd-scsi@freebsd.org In-Reply-To: <199601082120.WAA16985@uriah.heep.sax.de> from "J Wunsch" at Jan 8, 96 10:20:26 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk hasn't J Wunsch said ? ... > > I've burnt my first CD today! > > Well, i sorta mis-burnt two of them, but the first step has been done. > > :-) > using FreeBSD ? t _______________________________________________________||___________________ __|| Perfection is reached, not when there is no __|| thomas graichen longer anything to add, but when there __|| freie universitaet berlin is no longer anything to take away __|| fachbereich physik __|| - Antoine de Saint-Exupery - __|| graichen@mail.physik.fu-berlin.de ___________________________||__________________graichen@FreeBSD.org_________ From owner-freebsd-scsi Tue Jan 9 14:53:21 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA14792 for freebsd-scsi-outgoing; Tue, 9 Jan 1996 14:53:21 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA14761 Tue, 9 Jan 1996 14:52:55 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA12307; Tue, 9 Jan 1996 23:51:24 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA22556; Tue, 9 Jan 1996 23:51:24 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id XAA01271; Tue, 9 Jan 1996 23:23:22 +0100 (MET) From: J Wunsch Message-Id: <199601092223.XAA01271@uriah.heep.sax.de> Subject: Re: Good News :) To: graichen@omega.physik.fu-berlin.de (Thomas Graichen) Date: Tue, 9 Jan 1996 23:23:21 +0100 (MET) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-current@freebsd.org, freebsd-scsi@freebsd.org Reply-To: freebsd-scsi@freebsd.org In-Reply-To: <199601091848.TAA00286@mordillo> from "Thomas Graichen" at Jan 9, 96 07:48:34 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk As Thomas Graichen wrote: > > > I've burnt my first CD today! > using FreeBSD ? Of course. It wouldn't have been worth mentioning it otherwise. :) -- 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. ;-) From owner-freebsd-scsi Tue Jan 9 14:53:43 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA14829 for freebsd-scsi-outgoing; Tue, 9 Jan 1996 14:53:43 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA14773 for ; Tue, 9 Jan 1996 14:53:07 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA12360 for ; Tue, 9 Jan 1996 23:52:26 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA22625 for freebsd-scsi@FreeBSD.org; Tue, 9 Jan 1996 23:52:26 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id XAA01300 for freebsd-scsi@FreeBSD.org; Tue, 9 Jan 1996 23:49:15 +0100 (MET) From: J Wunsch Message-Id: <199601092249.XAA01300@uriah.heep.sax.de> Subject: Re: Good News :) To: freebsd-scsi@FreeBSD.org Date: Tue, 9 Jan 1996 23:49:15 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199601091105.GAA25461@hda.com> from "Peter Dufault" at Jan 9, 96 06:05:33 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.org Precedence: bulk As Peter Dufault wrote: > > Eventually I'd like the system to schedule I/O requests > based on the rtprio priority. I have a scratch kernel around > that prefers rtprio requests to normal ones. It makes xcdplayer > snappy. Sounds interesting. Anyway, see my more detailed posting today, the system seems to be up to the task already. > One problem with scsi(3) and therefore scsi(8) is these don't use the > start queue and so you'll get the latency to resume each process even > with a "team" approach to running scsi(8). The scsi(8) invocations aren't time-critical. Well, the final one is (the SYNCHRONISE CACHE), since it tells the drive that the write process has finished now, and there's no longer a need to complain about a buffer underrun. The actual write is finally done by write(2) anyway. Unlike Linux' cdwrite, i refuse to re-invent the wheel. (cdwrite has at least 200 lines of code that perform a task similar to dd(1) or team(1).) > I assume you're doing some combination of scsi(8) scripts to setup > then some "team" dd incantations to transfer the data to the CD-R? You're assuming right. :) See my recent posting. Peter, i owe you a frame of German beer for providing us with scsi(3) and scsi(8). Without them, it would have been much harder to get this proof of concept running! [LKMs] > But don't forget some people may have more than one > CD-R, though I don't know if they'll need more than one "personality" > loaded at once. Hmm. Well, i think it's unrealistic to drive multiple burners at once. So, a single loaded module might suffice? My current ideas are about these: . think about refining the structure of worm(4) . create an ioctl interface of WORM* commands, that allow to prepare the drive for a burning process, perform the `fixation' etc.; the device-dependant part of this ioctl might be laid out as an LKM, perhaps dispatched by a switch table (for more than one worm device) . the first write(2) after all parameters have been set should ``open the write channel'' (read: prepare a new track on the CD-R); this eliminates any timing problems between the ioctl's and the actual write, only the sequence of all following writes must be tight . i'm not sure when to close the write channel: at special request? at close(2) time? this is done by a SYNCHRONIZE CACHE command . the `fixation' is independent of the tight write cycles and could be performed separately (this includes writing a TOC, and making the CD-R recognizable for CD readers) . the ioctl should be wired to the outside world by a wormcontrol(8) command (cmp. the cdcontrol(8)) . it might be convenient to create something like cdwrite(1) that wraps all necessary pieces together, consisting of some calls to wormcontrol(8), and the rtprio/team/dd pipeline to actually dump the data to the disk . perhaps the driver should also `clone' the cd(4) driver, in order to allow read operations; i don't care very much about this. Interest- ing detail: the device announces itself either as type 4 or 5, depending on the medium. This might force us to either collect a table of all recognized CD burners, forcing them to belong to the worm driver, or find some better-suited method (no idea on this however). > An aside - one thing I'll point out is it would be easy to hack > scsi(8) to spit out a C code interface for one of its command strings. > I don't know if that is of interest or not. I'm not yet sure if i would need it. For the kernel code, it seems that i could understand it well enough to know what has to be done. :-) Another idea would be to create a ``worm description language''. It's a bit hard however, without having access to all possibly supported devices (and their manuals). > > Who is interested in dicussing further issues of the concept (once > > i've got further)? Should i do this in this list? > > If no one else chimes in we'll take it off line. Many people expressed their interest in personal email. I think we should best keep it in this list here, and all interested parties might subscribe. (Yup, i know about your problems with freebsd-scsi, Peter -- don't care! :) About the drive: the `Plasmon' is an incident. I've just got it since it was the only one available immediately when my ``boss'' went shopping for a CD burner. They don't seem to be uncooperative, but o well, i had to fetch the SCSI manual as an (ick!) m$ word file via a transatlantic phone line from an US BBS. :) The sales/support person answering my email didn't seem to be able to mail me the document, nor does it seem that they ever knew anyone who doesn't like m$ file formats and would have prefered a postscript doc instead. At least, i've annoyed him enough to finally un-protect the originally password protected doc on the BBS. ;) I do know the procedure from Yamaha, and despite of them doing _everything_ different from all other CD-R vendors, they were requesting many silly things from me when i've been asking for a SCSI manual (``What has been your sales volume last year?'' ``How many copies of your software do you estimate to sell?''). Programming a CD-R without a SCSI manual appears to be Russian Roulette. I've misburnt three of them, even _with_ the manual in the back. -- 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. ;-) From owner-freebsd-scsi Wed Jan 10 02:32:38 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA28795 for freebsd-scsi-outgoing; Wed, 10 Jan 1996 02:32:38 -0800 (PST) Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA28788 for ; Wed, 10 Jan 1996 02:32:31 -0800 (PST) Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id FAA28904; Wed, 10 Jan 1996 05:29:58 -0500 From: Peter Dufault Message-Id: <199601101029.FAA28904@hda.com> Subject: Re: Good News :) To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 10 Jan 1996 05:29:58 -0500 (EST) Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <199601092249.XAA01300@uriah.heep.sax.de> from "J Wunsch" at Jan 9, 96 11:49:15 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk > Peter, i owe you a frame of German beer for providing us with scsi(3) > and scsi(8). Without them, it would have been much harder to get this > proof of concept running! Share some with your boss for evidently hiring you at least part time to work on FreeBSD. Next time I'm in Dresden (Well, first time I'm in Dresden) I'll collect in person. > [LKMs] > > > But don't forget some people may have more than one > > CD-R, though I don't know if they'll need more than one "personality" > > loaded at once. > > Hmm. Well, i think it's unrealistic to drive multiple burners at > once. So, a single loaded module might suffice? I don't know the economics of the situation. But someone might need to burn two or three of the same disk in parallel (read-disk write-rom0 ... write-romn). Also, if things were working perfectly you might be burning a disk on the Plasma Torch and evaluating a new unit. > My current ideas are about these: > > . think about refining the structure of worm(4) > > . create an ioctl interface of WORM* commands, that allow to prepare > the drive for a burning process, perform the `fixation' etc.; the > device-dependant part of this ioctl might be laid out as an LKM, > perhaps dispatched by a switch table (for more than one worm device) You can evaluate moving ioctl calls into the kernel versus doing them with scsi(8). It will be invisible to the end user since you anticipate a wormcontrol anyway. You may find that there are few enough differences in the actual write transfer that a flag field settable either via ioctl or as part of config is all that is needed in the driver to support the data transfer to the different worms. "scsi_device_register" can add a new device in an LKM init entry point, and then you must either reprobe the bus or poke around in the unknown devices for any we should adopt. This needs more work. The easiest thing to do now is hardwire things in with an eye toward making it work via LKM. > . the first write(2) after all parameters have been set should ``open > the write channel'' (read: prepare a new track on the CD-R); this > eliminates any timing problems between the ioctl's and the actual > write, only the sequence of all following writes must be tight > > . i'm not sure when to close the write channel: at special request? > at close(2) time? this is done by a SYNCHRONIZE CACHE command > > . the `fixation' is independent of the tight write cycles and could be > performed separately (this includes writing a TOC, and making the > CD-R recognizable for CD readers) > > . the ioctl should be wired to the outside world by a wormcontrol(8) > command (cmp. the wormcontrol(8)) > > . it might be convenient to create something like cdwrite(1) that > wraps all necessary pieces together, consisting of some calls to > wormcontrol(8), and the rtprio/team/dd pipeline to actually dump the > data to the disk When to close the write channel: It depends on whether this is time critical or not. If it isn't time critical close(2) is good. Opening the write channel during open and closing the write channel during close sounds intuitive. Then the sequence is "wormcontrol setup"... "dd write"... "wormcontrol fixate". > . perhaps the driver should also `clone' the cd(4) driver, in order to > allow read operations; i don't care very much about this. Interest- > ing detail: the device announces itself either as type 4 or 5, > depending on the medium. This might force us to either collect a > table of all recognized CD burners, forcing them to belong to the > worm driver, or find some better-suited method (no idea on this > however). Or attach the device twice to two separate drivers. There may be locking issues here. > > An aside - one thing I'll point out is it would be easy to hack > > scsi(8) to spit out a C code interface for one of its command strings. > > I don't know if that is of interest or not. > > I'm not yet sure if i would need it. For the kernel code, it seems > that i could understand it well enough to know what has to be > done. :-) I know you won't need it - it is attractive to have a minimal specification for commands to make it easy to change interfaces. Plus you've tested with scsi(8) - it would be nice to then throw the "-S" switch. Assuming you elect to move all commands into the kernel. Peter -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-scsi Wed Jan 10 04:09:31 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA03819 for freebsd-scsi-outgoing; Wed, 10 Jan 1996 04:09:31 -0800 (PST) Received: from whyy.org (jehrenkrantz@[199.234.236.254]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA03813 for ; Wed, 10 Jan 1996 04:09:28 -0800 (PST) Received: (from jehrenkrantz@localhost) by whyy.org (8.6.12/8.6.9) id HAA09176; Wed, 10 Jan 1996 07:09:47 -0500 Date: Wed, 10 Jan 1996 07:09:46 -0500 (EST) From: Jeff Ehrenkrantz To: Peter Dufault cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG Subject: Re: Good News :) In-Reply-To: <199601091105.GAA25461@hda.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk Peter, Hello at the risk of interjecting myself at an inapproiate moment i would be willing to get the manual from the bbs for you compressit and leave it on a priviate site you could ftp from. pass me the bbs info & let me know ..je 'JE293' (ps: i typicaly lerk and read for a long time before i bother anyone) On Tue, 9 Jan 1996, Peter Dufault wrote: > > command set. My experiment ran with a ``Plasmon Data RF4100'', and > > with some minor hassles (downloading from an US BBS via transatlantic > > phone lines, ick) i could get their SCSI manual. Judging from Linux' > > cdwrite, most burners seem to be only slightly different in the > > command handling, with the major exception of Yamaha. They do just From owner-freebsd-scsi Wed Jan 10 10:45:39 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA23007 for freebsd-scsi-outgoing; Wed, 10 Jan 1996 10:45:39 -0800 (PST) Received: from kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA22952 for ; Wed, 10 Jan 1996 10:43:36 -0800 (PST) Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by kitten.mcs.com (8.6.10/8.6.9) with SMTP id MAA17257 for ; Wed, 10 Jan 1996 12:43:00 -0600 Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Wed, 10 Jan 96 12:42 CST Received: by mercury.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Wed, 10 Jan 96 12:42 CST Message-Id: Subject: Anyone have any experience with a Sony CDU 55 CD-ROM? To: scsi@freebsd.org Date: Wed, 10 Jan 1996 12:42:58 -0600 (CST) From: "Lars Fredriksen" X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk Hi, A friend of mine is thinking of buying a Sony CDU 55 SCSI CD-ROM to use with FreeBSD. Anyone have any experience with this unit? Any incompatibilities? He is running 2.1 Thanks a bunch. Lars -- ------------------------------------------------------------------- Lars Fredriksen fredriks@mcs.com (home) lars@fredriks.pr.mcs.net (home-home) fredriks@asiago.cs.wisc.edu From owner-freebsd-scsi Wed Jan 10 11:57:57 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA26447 for freebsd-scsi-outgoing; Wed, 10 Jan 1996 11:57:57 -0800 (PST) Received: from gaudi.diatel.upm.es (gaudi.diatel.upm.es [138.100.49.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA26420 for ; Wed, 10 Jan 1996 11:56:46 -0800 (PST) Received: by gaudi.diatel.upm.es (4.1/SMI-4.1) Wed, 10 Jan 96 20:51:39 +0100 X400-Received: by mta diatel.upm in /PRMD=/ADMD=/C=/; Relayed; Wed, 10 Jan 1996 20:51:36 UTC+0100 X400-Received: by /PRMD=iris/ADMD=mensatex/C=es/; Relayed; Wed, 10 Jan 1996 20:51:36 UTC+0100 Date: Wed, 10 Jan 1996 20:51:36 UTC+0100 X400-Originator: jmrueda@diatel.upm.es X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=iris/ADMD=mensatex/C=es/;960110205136] Content-Identifier: 881 From: Javier Martin Rueda To: freebsd-scsi@freebsd.org Message-Id: <881*/S=jmrueda/OU=diatel/O=upm/PRMD=iris/ADMD=mensatex/C=es/@MHS> Subject: The Adaptec 2842 no longer probes my DAT drive Mime-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk I've just received my FreeBSD 2.1 CD. I tried installing the system, but I had problems with the SCSI subsystem. Under FreeBSD 2.0, in the same computer, everything works fine. These are the messages output by the kernel while it is probing for devices under FreeBSD 2.0: ahc0: reading board settings ahc0: 284x Single Channel, 4 SCBs, int=11, SCSI Id=7 ahc0: Downloading Sequencer Program ahc0 at 0x1000-0x1fff irq 11 on eisa ahc0 targ 0 lun 0: type 0(direct) fixed SCSI2 ahc0 targ 0 lun 0: sd0: 1013MB (2074880 total sec), 2756 cyl, 8 head, 94 sec, bytes/sec 512 ahc0 targ 3 lun 0: type 5(readonly) removable SCSI2 ahc0 targ 3 lun 0: cd0: could not get size cd0: drive empty ahc0 targ 6 lun 0: type 1(sequential) removable SCSI2 ahc0 targ 6 lun 0: st0: density code 0x13, drive empty As you can see, I'm using an Adaptec 2842 (VESA local bus), a hard disk, a CD-ROM reader, and a DAT tape drive (2 GB, no compression). This has been working mostly OK since I installed FreeBSD 2.0, when it was released. However, when I boot FreeBSD 2.1 with the GENERIC kernel, the system panics when it is probing for the DAT tape drive. If I disconnect the DAT tape drive, there is no problem. I've installed FreeBSD 2.1 on another computer, compiled a new kernel with just the hardware configuration of my computer (just in case some of the unsuccesful probes of the GENERIC kernel was interacting badly with the 2842, but the results are exactly the same). The messages that are output are the following (they are copied by hand, so don't expect exact format, number of spaces, etc. as on screen): ahc1: 284x Single Channel, SCSI Id=7, aic7770 >= Rev E, 4 SCBs ahc1 at 0x1000-0x10ff irq11 on eisa slot1 ahc1 waiting for scsi devices to settle (ahc1:0:0): "CONNER CFP1060S 1.05GB 2035" type 0 fixed SCSI 2 sd0(ahc1:0:0): Direct-Access 1013 MB (2074880 512 byte sectors) (ahc0:3:0): "TOSHIBA CD-ROM XM-5201TA 3014" type 5 removable SCSI 2 cd0(ahc0:3:0): Logical unit is in process of becoming ready ... now, the computer halts for a long time (1 minute, maybe) ... ahc1: board not responding cmd fail (ahc1:6:0): BUS DEVICE RESET message queued ahc1: board not responding ... more delay ... cmd fail cmd fail ahc1: Issued Channel A Bus Reset #2. 0 SCBs aborted (ahc1:6:0): UNIT ATTENTION asc:29,0 (ahc1:6:0): Power on, reset, or bus device reset occurred field replaceable unit: 14 (ahc1:6:0): "unknown unknown ????" type 0 fixed SCSI 0 sd1(ahc1:2:0): Direct-Access panic: ahc1: brkadrint, Illegal Sequencer Address referenced at seqaddr = 0xa Automatic reboot in 15 seconds - press any key...etc, etc. Looking at the kernel sources, I turned on SCSI debugging, by editing /sys/scsi/scsi_debug.h, defining SCSIDEBUG, setting DEBUGLEVEL to SDEV_DB1 through SDEV_DB4, and setting DEBUGTARG to 6 (the DAT drive). The results, when the system gets to probing the DAT tape drive, are: probe0(ahc0:6:0): scsi_cmd probe0(ahc0:6:0): get_xs probe0(ahc0:6:0): returning xs(0xf057ea80): flg(0x63)sc_link(0xf057e880)retr(0x2)timo(0x186a0)cmd(0xf057ead8)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)(ahc0:6:0): command: 0,0,0,0,0,0-[0 bytes] probe0(ahc0:6:0): ahc_scsi_cmd probe0(ahc0:6:0): start scb(0xf06dd000) scb:0xf06dd000control:0x50 tcl:0x60 cmdlen:6 cmdpointer:0x30ad8 datlen:0 data:0x0 res:0x0 segs:0x0 segp:0x0 sg_addr:308ac sg_len:44 size:32 probe0(ahc0:6:0): cmd_wait scb:0xf06dd000control:0x58 tcl:0x60 cmdlen:6 cmdpointer:0x30ad8 datlen:0 data:0x0 res:0x0 segs:0x0 segp:0x0 sg_addr:308ac sg_len:44 size:32 (ahc0:6:0): requests Check Status (ahc0:6:0): Sending Sense And now's when the system halts for a long time, and eventually panics. Does anyone know what to do, please? From owner-freebsd-scsi Wed Jan 10 13:19:14 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA02119 for freebsd-scsi-outgoing; Wed, 10 Jan 1996 13:19:14 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA02103 Wed, 10 Jan 1996 13:19:04 -0800 (PST) Message-Id: <199601102119.NAA02103@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: Javier Martin Rueda cc: freebsd-scsi@freebsd.org Subject: Re: The Adaptec 2842 no longer probes my DAT drive In-reply-to: Your message of "Wed, 10 Jan 1996 20:51:36 +0100." <881*/S=jmrueda/OU=diatel/O=upm/PRMD=iris/ADMD=mensatex/C=es/@MHS> Date: Wed, 10 Jan 1996 13:19:02 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk >I've just received my FreeBSD 2.1 CD. I tried installing the system, but >I had problems with the SCSI subsystem. > >Under FreeBSD 2.0, in the same computer, everything works fine. These are >the messages output by the kernel while it is probing for devices under >FreeBSD 2.0: ... >As you can see, I'm using an Adaptec 2842 (VESA local bus), a hard disk, >a CD-ROM reader, and a DAT tape drive (2 GB, no compression). > >This has been working mostly OK since I installed FreeBSD 2.0, when it >was released. > >However, when I boot FreeBSD 2.1 with the GENERIC kernel, the system >panics when it is probing for the DAT tape drive. The problem is due to an overflow in the sync negotiation code of the kernel driver (was using char and should have been using short). If you can upgrade to 2.1-STABLE, you should (there have been many bug fixes to the aic7xxx driver since 2.1 including this one) otherwise, you can change the code in the MSG_SDTR case of the driver to pass a short to its sync rate checking function. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Wed Jan 10 13:54:55 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA04848 for freebsd-scsi-outgoing; Wed, 10 Jan 1996 13:54:55 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA04807 for ; Wed, 10 Jan 1996 13:54:20 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA05533; Wed, 10 Jan 1996 22:52:09 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA05804; Wed, 10 Jan 1996 22:52:08 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id WAA06962; Wed, 10 Jan 1996 22:34:11 +0100 (MET) From: J Wunsch Message-Id: <199601102134.WAA06962@uriah.heep.sax.de> Subject: Re: Good News :) To: freebsd-scsi@freebsd.org Date: Wed, 10 Jan 1996 22:34:11 +0100 (MET) Cc: jehrenkrantz@whyy.org (Jeff Ehrenkrantz) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Jeff Ehrenkrantz" at Jan 10, 96 07:09:46 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk As Jeff Ehrenkrantz wrote: > > Peter, Hello at the risk of interjecting myself at an inapproiate moment > i would be willing to get the manual from the bbs for you compressit and > leave it on a priviate site you could ftp from. pass me the bbs info & > let me know ..je 'JE293' Which manual are you talking about? I've already got the Plasmon manual, and it's rather been a problem of convincing the guy on the other end of a slow mail connection (UUCP via netcom.com) about my wishes, than actually downloading it. It took me five or six mails until i got the right BBS phone number, the file wasn't password- protected anymore etc. > On Tue, 9 Jan 1996, Peter Dufault wrote: > > > > command set. My experiment ran with a ``Plasmon Data RF4100'', and > > > with some minor hassles (downloading from an US BBS via transatlantic > > > phone lines, ick) i could get their SCSI manual. Judging from Linux' You've mis-quoted Peter here, this were my words. (Just to avoid confusion.) -- 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. ;-) From owner-freebsd-scsi Wed Jan 10 14:07:18 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA05895 for freebsd-scsi-outgoing; Wed, 10 Jan 1996 14:07:18 -0800 (PST) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA05885 for ; Wed, 10 Jan 1996 14:07:12 -0800 (PST) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA27784; Wed, 10 Jan 96 23:07:54 +0100 Date: Wed, 10 Jan 96 23:07:54 +0100 Message-Id: <9601102207.AA27784@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: fredriks@mcs.com Cc: scsi@freebsd.org In-Reply-To: (fredriks@mcs.com) Subject: Re: Anyone have any experience with a Sony CDU 55 CD-ROM? X-Mailer: Emacs Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk >>>>> "Lars Fredriksen" writes: > Hi, > A friend of mine is thinking of buying a Sony CDU 55 > SCSI CD-ROM to use with FreeBSD. Anyone have any experience with this unit? > Any incompatibilities? He is running 2.1 I have one since 6 months. Works fine with data, audio and digital audio. Jean-Marc > Thanks a bunch. > Lars > -- > ------------------------------------------------------------------- > Lars Fredriksen fredriks@mcs.com (home) > lars@fredriks.pr.mcs.net (home-home) > fredriks@asiago.cs.wisc.edu _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-scsi Wed Jan 10 14:53:22 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA09273 for freebsd-scsi-outgoing; Wed, 10 Jan 1996 14:53:22 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA09238 for ; Wed, 10 Jan 1996 14:52:30 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id XAA07282 for ; Wed, 10 Jan 1996 23:51:59 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id XAA06771 for freebsd-scsi@FreeBSD.ORG; Wed, 10 Jan 1996 23:51:58 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id XAA07466 for freebsd-scsi@FreeBSD.ORG; Wed, 10 Jan 1996 23:40:31 +0100 (MET) From: J Wunsch Message-Id: <199601102240.XAA07466@uriah.heep.sax.de> Subject: Re: Good News :) To: freebsd-scsi@FreeBSD.ORG Date: Wed, 10 Jan 1996 23:40:31 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199601101029.FAA28904@hda.com> from "Peter Dufault" at Jan 10, 96 05:29:58 am X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk As Peter Dufault wrote: > > > Peter, i owe you a frame of German beer for providing us with scsi(3) > > and scsi(8). Without them, it would have been much harder to get this > > proof of concept running! > > Share some with your boss for evidently hiring you at least part > time to work on FreeBSD. Next time I'm in Dresden (Well, first time > I'm in Dresden) I'll collect in person. Well, i don't even know whether he drinks beer. :) I'm not really paid for my work on FreeBSD (except where it comes to customers), but there's an ``overlap of interests'', and to the very least, he didn't look angry after mis-burning three CD-R's. ;-) > You can evaluate moving ioctl calls into the kernel versus doing > them with scsi(8). It will be invisible to the end user since you > anticipate a wormcontrol anyway. You may find that there are few Right. > enough differences in the actual write transfer that a flag field > settable either via ioctl or as part of config is all that is needed > in the driver to support the data transfer to the different worms. A write seems to be just a write. Even the Linux cdwrite does appear to use write(2) for the actual data transfer. The differences are in the command sequence before and after the write. > "scsi_device_register" can add a new device in an LKM init entry > point, and then you must either reprobe the bus or poke around in > the unknown devices for any we should adopt. This needs more work. Hmm, our reprobing is still broken. It turns on adapter polling, which causes it to hang when used on a PCI adapter. Anybody keen to revamp it? I think it requires minor changes (the functions that are responsible for the bus probing must get passed an argument that tells whether this is at system initialization time or not), but they have to be done throughout the entire SCSI code. > When to close the write channel: It depends on whether this is > time critical or not. If it isn't time critical close(2) > is good. Opening the write channel during open and closing the > write channel during close sounds intuitive. It is time critical. Perhaps it should be done inside close(2) anyway. The sequence of write(2)'s is not less time critical, and there's no particular reason why the writing program (dd or team) should be allowed to defer the final close(2) much more than all the write's. Opening the write channel with open(2) doesn't seem to be that good, since we also have to open it in order to prepare the medium. Well, thinking more about it, we could do it just when opening the `real' device, while all ioctl's will be done via the control device (so the worm_open() is never being called for them). worm_open() could also reject an open intend on a non-prepared disk. (Btw., Julian, devfs is missing all the SCSI control devices. Ya' know, those funny thingies with the 0x20000000 bit set in the minor number.) > Then the sequence is "wormcontrol setup"... "dd write"... > "wormcontrol fixate". Yup. -- 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. ;-) From owner-freebsd-scsi Wed Jan 10 15:24:26 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA11816 for freebsd-scsi-outgoing; Wed, 10 Jan 1996 15:24:26 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA11750 Wed, 10 Jan 1996 15:24:19 -0800 (PST) Message-Id: <199601102324.PAA11750@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Good News :) In-reply-to: Your message of "Wed, 10 Jan 1996 23:40:31 +0100." <199601102240.XAA07466@uriah.heep.sax.de> Date: Wed, 10 Jan 1996 15:24:16 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk >> "scsi_device_register" can add a new device in an LKM init entry >> point, and then you must either reprobe the bus or poke around in >> the unknown devices for any we should adopt. This needs more work. > >Hmm, our reprobing is still broken. It turns on adapter polling, >which causes it to hang when used on a PCI adapter. Depends on the driver. The aic7xxx driver doesn't poll *ever* anymore since it is only an EISA/PCI driver and it has access to its interrupts from the get-go. This change went into the tree a week ago. >Anybody keen to revamp it? I think it requires minor changes (the >functions that are responsible for the bus probing must get passed an >argument that tells whether this is at system initialization time or >not), but they have to be done throughout the entire SCSI code. Actually, you could entirely remove the polling if ISA devices had access to their interrupts at attach time. I think this should happen regardless of what the SCSi code wants. The probes and attaches shouldn't be running at splhigh for ISA devices unless a particular device goes to splhigh. >-- >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. ;-) -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Wed Jan 10 16:10:46 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA14255 for freebsd-scsi-outgoing; Wed, 10 Jan 1996 16:10:46 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA14249 for ; Wed, 10 Jan 1996 16:10:36 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id BAA09137 for ; Thu, 11 Jan 1996 01:10:25 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id BAA07743 for freebsd-scsi@FreeBSD.ORG; Thu, 11 Jan 1996 01:10:25 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id AAA08390 for freebsd-scsi@FreeBSD.ORG; Thu, 11 Jan 1996 00:56:06 +0100 (MET) From: J Wunsch Message-Id: <199601102356.AAA08390@uriah.heep.sax.de> Subject: Re: Good News :) To: freebsd-scsi@FreeBSD.ORG Date: Thu, 11 Jan 1996 00:56:06 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199601102324.PAA11750@freefall.freebsd.org> from "Justin T. Gibbs" at Jan 10, 96 03:24:16 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk As Justin T. Gibbs wrote: > > >Hmm, our reprobing is still broken. It turns on adapter polling, > >which causes it to hang when used on a PCI adapter. > > Depends on the driver. The aic7xxx driver doesn't poll *ever* anymore > since it is only an EISA/PCI driver and it has access to its interrupts > from the get-go. This change went into the tree a week ago. Hmm, i will have to install 2.1 on these machines, and apply your recent patch. -- 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. ;-) From owner-freebsd-scsi Fri Jan 12 09:46:28 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id JAA23898 for freebsd-scsi-outgoing; Fri, 12 Jan 1996 09:46:28 -0800 (PST) Received: from gallux.gallaudet.edu (gallux.gallaudet.edu [134.231.4.22]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA23893 for ; Fri, 12 Jan 1996 09:46:24 -0800 (PST) Received: by gallux.gallaudet.edu; id AA20659; Fri, 12 Jan 1996 12:49:46 -0500 Date: Fri, 12 Jan 1996 12:49:45 -0500 (EST) From: Kevin Casey Subject: subscribe To: freebsd-scsi@freebsd.org In-Reply-To: <199601092218.XAA01188@uriah.heep.sax.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk -- Kevin Casey Computer Services Gallaudet University 800 Florida Ave, NE (202)651-5300 Washington, DC 20002-3695 (202)651-5477 FAX From owner-freebsd-scsi Fri Jan 12 19:17:46 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA01303 for freebsd-scsi-outgoing; Fri, 12 Jan 1996 19:17:46 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA01294 for ; Fri, 12 Jan 1996 19:17:42 -0800 (PST) Received: (from root@localhost) by time.cdrom.com (8.6.12/8.6.9) id TAA01336 for freebsd-scsi@freebsd.org; Fri, 12 Jan 1996 19:17:40 -0800 Date: Fri, 12 Jan 1996 19:17:40 -0800 From: "Jordan K. Hubbard" Message-Id: <199601130317.TAA01336@time.cdrom.com> To: freebsd-scsi@freebsd.org Subject: Testing Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk one more test From owner-freebsd-scsi Fri Jan 12 20:03:57 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id UAA03726 for freebsd-scsi-outgoing; Fri, 12 Jan 1996 20:03:57 -0800 (PST) Received: from ids.net (ids.net [155.212.1.2]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id UAA03714 Fri, 12 Jan 1996 20:03:52 -0800 (PST) Date: Fri, 12 Jan 1996 23:03:50 -0500 (EST) From: "Andy Green, IDS World Network Internet Access Service, 401-885-6855" To: OWNER-FREEBSD-SCSI@FREEBSD.ORG CC: FREEBSD-SCSI@FREEBSD.ORG Message-Id: <960112230350.221a7@ids.net> Subject: Please remove me from the list Sender: owner-freebsd-scsi@FREEBSD.ORG Precedence: bulk Please remove me from the list From owner-freebsd-scsi Sat Jan 13 19:08:54 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id TAA07491 for freebsd-scsi-outgoing; Sat, 13 Jan 1996 19:08:54 -0800 (PST) Received: from localhost.cdrom.com (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA07484 for ; Sat, 13 Jan 1996 19:08:49 -0800 (PST) Message-Id: <199601140308.TAA07484@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: Host localhost.cdrom.com [127.0.0.1] didn't use HELO protocol To: freebsd-scsi Subject: Calling st_unmount for nrst* devices Date: Sat, 13 Jan 1996 19:08:48 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk I don't like the fact that after closing the nrst* devices, we don't reenable the eject button. In fact, although I haven't tracked down exactly why, even if you rewind the tape via an "mt rewind" after doing some operations on the nrst* devices, the drive is still locked. I think these patches fix the problem, but I'll have to do some more testing tomorrow to make sure. Perhaps some of you would be interested in testing these as well? -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== Index: st.c =================================================================== RCS file: /usr/cvs/src/sys/scsi/st.c,v retrieving revision 1.57 diff -c -r1.57 st.c *** st.c 1996/01/08 12:25:06 1.57 --- st.c 1996/01/13 22:06:16 *************** *** 89,102 **** static int32 st_chkeod __P((u_int32 unit, boolean position, int32 *nmarks, u_int32 flags)); static void ststart(u_int32 unit, u_int32 flags); ! static void st_unmount __P((int unit, boolean eject)); static errval st_mount_tape __P((dev_t dev, u_int32 flags)); static void st_loadquirks __P((struct scsi_link *sc_link)); static errval st_interpret_sense __P((struct scsi_xfer *xs)); #define ESUCCESS 0 ! #define NOEJECT 0 ! #define EJECT 1 struct scsi_data { /*--------------------present operating parameters, flags etc.----------------*/ --- 89,105 ---- static int32 st_chkeod __P((u_int32 unit, boolean position, int32 *nmarks, u_int32 flags)); static void ststart(u_int32 unit, u_int32 flags); ! static void st_unmount __P((int unit, u_int32 flags)); static errval st_mount_tape __P((dev_t dev, u_int32 flags)); static void st_loadquirks __P((struct scsi_link *sc_link)); static errval st_interpret_sense __P((struct scsi_xfer *xs)); #define ESUCCESS 0 ! ! /* SCSI tape umount flags */ ! #define NOOPS 0 /* Don't do anything to the tape */ ! /* REWIND is a tape opcode (0x01), so we just use that */ ! #define EJECT 2 /* Implies a rewind too */ struct scsi_data { /*--------------------present operating parameters, flags etc.----------------*/ *************** *** 491,497 **** */ if ( (errno = scsi_test_unit_ready(sc_link, 0)) ) { uprintf("st%d: not ready\n", unit); ! st_unmount(unit, NOEJECT); return (errno); } /* --- 494,500 ---- */ if ( (errno = scsi_test_unit_ready(sc_link, 0)) ) { uprintf("st%d: not ready\n", unit); ! st_unmount(unit, REWIND); return (errno); } /* *************** *** 501,507 **** */ if ((st->last_dsty != dsty) || (!(sc_link->flags & SDEV_MEDIA_LOADED))) { ! st_unmount(unit, NOEJECT); } /* * If we are not mounted, then we should start a new --- 504,510 ---- */ if ((st->last_dsty != dsty) || (!(sc_link->flags & SDEV_MEDIA_LOADED))) { ! st_unmount(unit, REWIND); } /* * If we are not mounted, then we should start a new *************** *** 545,556 **** switch (mode & 0x3) { case 0: case 3: /* for now */ ! st_unmount(unit, NOEJECT); break; ! case 1: /*leave mounted unless media seems to have been removed */ ! if (!(sc_link->flags & SDEV_MEDIA_LOADED)) { ! st_unmount(unit, NOEJECT); ! } break; case 2: st_unmount(unit, EJECT); --- 548,557 ---- switch (mode & 0x3) { case 0: case 3: /* for now */ ! st_unmount(unit, REWIND); break; ! case 1: ! st_unmount(unit, NOOPS); break; case 2: st_unmount(unit, EJECT); *************** *** 672,678 **** * operations require another mount operation */ void ! st_unmount(int unit, boolean eject) { struct scsi_link *sc_link = SCSI_LINK(&st_switch, unit); struct scsi_data *st = sc_link->sd; --- 673,679 ---- * operations require another mount operation */ void ! st_unmount(int unit, u_int32 flags) { struct scsi_link *sc_link = SCSI_LINK(&st_switch, unit); struct scsi_data *st = sc_link->sd; *************** *** 682,690 **** return; SC_DEBUG(sc_link, SDEV_DB1, ("unmounting\n")); st_chkeod(unit, FALSE, &nmarks, SCSI_SILENT); ! st_rewind(unit, FALSE, SCSI_SILENT); scsi_prevent(sc_link, PR_ALLOW, SCSI_SILENT); ! if (eject) { st_load(unit, LD_UNLOAD, SCSI_SILENT); } st->flags &= ~(ST_MOUNTED | ST_NEW_MOUNT); --- 683,693 ---- return; SC_DEBUG(sc_link, SDEV_DB1, ("unmounting\n")); st_chkeod(unit, FALSE, &nmarks, SCSI_SILENT); ! ! if (flags & (REWIND|EJECT) ) ! st_rewind(unit, FALSE, SCSI_SILENT); scsi_prevent(sc_link, PR_ALLOW, SCSI_SILENT); ! if (flags & EJECT) { st_load(unit, LD_UNLOAD, SCSI_SILENT); } st->flags &= ~(ST_MOUNTED | ST_NEW_MOUNT);