From owner-freebsd-scsi Sun Aug 17 00:07:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA13307 for freebsd-scsi-outgoing; Sun, 17 Aug 1997 00:07:31 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA13302 for ; Sun, 17 Aug 1997 00:07:26 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0wzzP8-0006qz-00; Sun, 17 Aug 1997 00:05:38 -0700 Date: Sun, 17 Aug 1997 00:05:37 -0700 (PDT) From: Tom Samplonius To: scsi@freebsd.org Subject: DPT message... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I get the following warning repeated: dpt0 ERROR: Marking 137 (Prevent/Allow Medium Removal [7.14]) on c0b0t0u0 as last after 19828979usec dpt0 ERROR: Stale 137 (Prevent/Allow Medium Removal [7.14]) on c0b0t0u0 (2982897 This error repeats over and over again, and the system requires a reset. This seems only to happen during filesystem mounts. DPT driver version 1.1.10 Tom From owner-freebsd-scsi Sun Aug 17 17:30:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA06803 for freebsd-scsi-outgoing; Sun, 17 Aug 1997 17:30:38 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA06790 for ; Sun, 17 Aug 1997 17:30:25 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0x0FgQ-0007OJ-00; Sun, 17 Aug 1997 17:28:34 -0700 Date: Sun, 17 Aug 1997 17:28:33 -0700 (PDT) From: Tom Samplonius To: scsi@freebsd.org Subject: expected performance with DPT RAID-5... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If I have 5 Barracuda 4LP 4GB drive (about 8MB/s raw read/write) on a single ultra wide channel on a DPT PM334/UW setup in a RAID-5 array, what kind of sequentional read/write performance should I expect? Tom From owner-freebsd-scsi Sun Aug 17 19:19:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA12854 for freebsd-scsi-outgoing; Sun, 17 Aug 1997 19:19:08 -0700 (PDT) Received: from mail.kcwc.com (h1.kcwc.com [206.139.252.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA12847 for ; Sun, 17 Aug 1997 19:19:04 -0700 (PDT) Received: by mail.kcwc.com (NX5.67c/NeXT-2.0-KCWC-1.0) id AA19946; Sun, 17 Aug 97 22:18:51 -0400 Date: Sun, 17 Aug 97 22:18:51 -0400 From: curt@kcwc.com (Curt Welch) Message-Id: <9708180218.AA19946@mail.kcwc.com> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: Tom Samplonius Subject: Re: expected performance with DPT RAID-5... Cc: scsi@FreeBSD.ORG, curt@kcwc.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tom wrote: > If I have 5 Barracuda 4LP 4GB drive (about 8MB/s raw > read/write) on a single ultra wide channel on a DPT > PM334/UW setup in a RAID-5 array, what kind of > sequentional read/write performance should I expect? Don't know what to expect, but I have a similar config. I have 5 Quantaum Atlas I 4G (fast wide) drives in a RAID-5 config on one bus of of PM3334UW/2 and 5 Quantum Viking 4.55G (ultra wide) also in a RAID-5 config on the other bus. The system is a 180MHz Pentium Pro with 128MB of memory. The DPT has a full 64MB of cache (non ecc). If you want me to run a test and tell you how it performs I will. What type of test would you like to see? BTW, the system still crashes every few days. Don't know for sure if it's probelms with the system, the DPT or the DPT driver - I'm still working on it. It was very stable before installing the DPT and the 10 new drives. Curt From owner-freebsd-scsi Sun Aug 17 20:04:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA15650 for freebsd-scsi-outgoing; Sun, 17 Aug 1997 20:04:00 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA15638 for ; Sun, 17 Aug 1997 20:03:54 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0x0I4y-0007Ss-00; Sun, 17 Aug 1997 20:02:04 -0700 Date: Sun, 17 Aug 1997 20:02:04 -0700 (PDT) From: Tom Samplonius To: Curt Welch cc: scsi@freebsd.org Subject: Re: expected performance with DPT RAID-5... In-Reply-To: <9708180218.AA19946@mail.kcwc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 17 Aug 1997, Curt Welch wrote: > Tom wrote: > > If I have 5 Barracuda 4LP 4GB drive (about 8MB/s raw > > read/write) on a single ultra wide channel on a DPT > > PM334/UW setup in a RAID-5 array, what kind of > > sequentional read/write performance should I expect? > > Don't know what to expect, but I have a similar config. > > I have 5 Quantaum Atlas I 4G (fast wide) drives in a RAID-5 > config on one bus of of PM3334UW/2 and 5 Quantum Viking 4.55G > (ultra wide) also in a RAID-5 config on the other bus. The > system is a 180MHz Pentium Pro with 128MB of memory. The > DPT has a full 64MB of cache (non ecc). > > If you want me to run a test and tell you how it performs > I will. What type of test would you like to see? "cd" to one of the RAID-5 file systems and do a "dd if=/dev/zero of=testfile bs=64k count=1000". That will create a file called "testfile" 64MB in length (64k x 1000), and tell you how long it took to write it. Then reboot (the only way I know of clearing the FreeBSD file cache, and the DPT cache), and do a "dd if=testfile bs=64k of=/dev/null" to read the file back. On the write test I get about 3500000 bps, and the write test about 9200000 bps. These results don't seem very good too me. > BTW, the system still crashes every few days. Don't know > for sure if it's probelms with the system, the DPT or the > DPT driver - I'm still working on it. It was very stable > before installing the DPT and the 10 new drives. > > Curt Tom From owner-freebsd-scsi Mon Aug 18 14:43:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA19994 for freebsd-scsi-outgoing; Mon, 18 Aug 1997 14:43:50 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA19987 for ; Mon, 18 Aug 1997 14:43:46 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA08972; Mon, 18 Aug 1997 23:43:31 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id XAA16081; Mon, 18 Aug 1997 23:11:04 +0200 (MET DST) Message-ID: <19970818231104.CG02430@uriah.heep.sax.de> Date: Mon, 18 Aug 1997 23:11:04 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: mandrews@termfrost.org (Mike Andrews) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: HP 4020i CD-R problems References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Mike Andrews on Aug 18, 1997 14:45:11 -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Mike Andrews wrote: > mindcrime# scsi -f /dev/rworm0.ctl -c "0 0 0 0 0 0" > SCIOCCOMMAND ioctl: Command accepted. > return status 3 (Sense Returned)Command out (6 of 6): > 00 00 00 00 00 00 > > No sense dump for error code 00. > sense (32 of 48): > 00 00 00 00 00 00 00 00 2e 00 00 00 88 01 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Looks weird. Sense returned, but no sense code? > mindcrime# wormcontrol select HP 4020i > wormcontrol: open(/dev/rworm0): Device not configured Does this even happen after reloading the medium? -- 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 Aug 18 14:44:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA20087 for freebsd-scsi-outgoing; Mon, 18 Aug 1997 14:44:21 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA20067; Mon, 18 Aug 1997 14:44:12 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA08983; Mon, 18 Aug 1997 23:44:08 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id XAA16135; Mon, 18 Aug 1997 23:20:27 +0200 (MET DST) Message-ID: <19970818232027.TU63680@uriah.heep.sax.de> Date: Mon, 18 Aug 1997 23:20:27 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: nick@webignite.com Cc: bugs@FreeBSD.org, freebsd-scsi@FreeBSD.org (FreeBSD SCSI list) Subject: Re: bin/4333: Dump backup utility completely crashes the machine 25% of the time. References: <199708182006.NAA14664@hub.freebsd.org> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199708182006.NAA14664@hub.freebsd.org>; from nick@webignite.com on Aug 18, 1997 13:06:15 -0700 Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk (Not sent for GNATS recording it.) As nick@webignite.com wrote: > The SCSI tape drive is a Seagate DDS-2, model CTD8000H-S > The machine is a Dell Poweredge Pentium Pro 200 w/. 96Mb RAM > > > The error message when the machine crashes is as follows: > > st0(ahc 0:6:0):SCB0x3 - timed out while idle, LASTPHASE == 0x1,SCSISIGI == 0x0 > SEQ ADDR == 0x5 > st0(ahc 0:6:0): Queueing an Abort SCB > st0(ahc 0:6:0): SCB0x3 - timed out while idle, LAST PHASE == 0x1, SCSISIGI == 0x0 > SEQ ADDR == 0x5 I have about the same problems with a similar (same?) Seagate drive. Just committed a supposed fix yesterday. Let's see how it does now. -- 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 Aug 18 15:49:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA23181 for freebsd-scsi-outgoing; Mon, 18 Aug 1997 15:49:55 -0700 (PDT) Received: from mindcrime.termfrost.org (root@mindcrime.termfrost.org [208.141.2.81]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA23170 for ; Mon, 18 Aug 1997 15:49:38 -0700 (PDT) Received: from localhost (mandrews@localhost) by mindcrime.termfrost.org (8.8.7/8.8.6/mindcrime-19970604) with SMTP id SAA12080; Mon, 18 Aug 1997 18:38:14 -0400 (EDT) Date: Mon, 18 Aug 1997 18:38:14 -0400 (EDT) From: Mike Andrews To: Joerg Wunsch cc: freebsd-scsi@FreeBSD.ORG Subject: Re: HP 4020i CD-R problems In-Reply-To: <19970818231104.CG02430@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 18 Aug 1997, J Wunsch wrote: > As Mike Andrews wrote: > > > mindcrime# scsi -f /dev/rworm0.ctl -c "0 0 0 0 0 0" > > SCIOCCOMMAND ioctl: Command accepted. > > return status 3 (Sense Returned)Command out (6 of 6): > > 00 00 00 00 00 00 > > > > No sense dump for error code 00. > > sense (32 of 48): > > 00 00 00 00 00 00 00 00 2e 00 00 00 88 01 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > Looks weird. Sense returned, but no sense code? > > > mindcrime# wormcontrol select HP 4020i > > wormcontrol: open(/dev/rworm0): Device not configured > > Does this even happen after reloading the medium? Yep. And to answer another question I got in email, I did rerun MAKEDEV worm just in case: mindcrime# ls -l /dev/*worm* crw-r----- 1 root operator 62, 0 Aug 14 21:36 rworm0 crw------- 1 root wheel 62, 0x20000000 Aug 14 21:36 rworm0.ctl brw-r----- 1 root operator 23, 0 Aug 14 21:36 worm0 -- Mike Andrews (MA12) network & systems guy, Digital Crescent, Frankfort KY -- mandrews@dcr.net -- mandrews@termfrost.org -- http://www.termfrost.org/ -- "Evil shall always prevail over good, because evil has better marketing..." -- Sick of junk e-mail? Visit http://www.cauce.org/ or http://spam.abuse.net/ From owner-freebsd-scsi Mon Aug 18 20:59:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA06906 for freebsd-scsi-outgoing; Mon, 18 Aug 1997 20:59:54 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA06901 for ; Mon, 18 Aug 1997 20:59:52 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id VAA10011; Mon, 18 Aug 1997 21:59:32 -0600 (MDT) Message-Id: <199708190359.VAA10011@pluto.plutotech.com> To: Greg Lehey cc: freebsd-scsi@FreeBSD.ORG (FreeBSD SCSI Mailing List) Subject: Re: Bus resets. Grrrr. In-reply-to: Your message of "Sun, 17 Aug 1997 10:59:43 +0930." <199708170129.KAA03776@freebie.lemis.com> Date: Mon, 18 Aug 1997 21:59:02 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >This is the third time in a row that I haven't been able to complete a backup >because of "recoverable" SCSI errors. Here's a pretty typical scenario: What version of the kernel are you using with what AHC options enabled in your kernel config file? >Aug 17 10:27:19 freebie /kernel: sd0: SCB 0x4 - timed out while idle, LASTPHAS >E == 0x1, SCSISIGI == 0x0 > >What does this mean? What can time out when nothing's happening? Or is >this a timeout accepting a new command when it shouldn't have to? Is this >a device or a driver logic error? The message simply indicates the state of the SCSI bus at the time the timeout occured. In this case, the sequencer was sitting in it's idle loop waiting for new work to be queued by the kernel driver or for a device to reconnect and continue a previously established connection. To understand why a timeout can occur in this state or any other, it's probably best to explain the timeout model that is used in FreeBSD. The "type" drivers (e.g. sd, cd, st, worm, etc) specifies a timeout value for each command it issues. When the adaptec driver queues a command to the controller, it sets up a "callout" that will occur timeout ms in the future for the just queued command. In this particular case, that "callout" fired while the sequencer wasn't working on any commands. So, what does a "timeout while idle" tell us? Well, it means that either the timeout that the type driver (in this case the "st" driver) specified was too short, or the aic7xxx driver lost the command somewhere either in route to or from the device. The latter problem did occur under heavy load prior to my latest "spin lock" change to the driver. The first problem seems really common in the st driver especially when older media or a rewind operation is involved. You can try bumping up the timeouts in sys/scsi/st.c to see if this solves your problem. > >Aug 17 10:27:31 freebie /kernel: SEQADDR = 0x9 SCSISEQ = 0x12 SSTAT0 = 0x5 SST >AT1 = 0xa >Aug 17 10:27:31 freebie /kernel: sd0: Queueing an Abort SCB >Aug 17 10:27:31 freebie /kernel: sd0: Abort Message Sent >Aug 17 10:27:31 freebie /kernel: sd0: SCB 0x4 - timed out in message out phase >, SCSISIGI == 0xa4 >Aug 17 10:27:31 freebie /kernel: SEQADDR = 0x9a SCSISEQ = 0x12 SSTAT0 = 0x5 SS >TAT1 = 0x2 > >If I understand this correctly, this means that the abort SCB wasn't received >either, so the driver does a bus reset: What it means is that the tape drive accepted the connection from the controller, most likely accepted the ABORT message, but took longer than the driver allowed for it to process the abort request, free the bus, and thus signal that the abort was successful. So, we take out the hammer and reset the bus. The timeout in the aic7xxx driver for abort requests may be too short. > >Aug 17 10:27:31 freebie /kernel: ahc0: Issued Channel A Bus Reset. 3 SCBs abor >ted >Aug 17 10:27:32 freebie /kernel: Clearing bus reset >Aug 17 10:27:32 freebie /kernel: Clearing 'in-reset' flag >Aug 17 10:27:32 freebie /kernel: sd0: no longer in timeout > >... which works. > >Aug 17 10:27:32 freebie /kernel: sd0: SCB 0x4 - timed out in command phase, SC >SISIGI == 0x84 > >So why do we get another timeout? Or is this overlapping? This is due to the way that timeout process occurs in the current driver. If I have 20 operations outstanding, each with a timeout queued, those timeouts are still in effect while I am doing recovery processing. So, even if I just unwedged the bus, a timeout for a pending command can fire "logically too soon". >Aug 17 10:27:32 freebie /kernel: SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SS >TAT1 = 0x2 >Aug 17 10:27:32 freebie /kernel: sd0: abort message in message buffer >Aug 17 10:27:32 freebie /kernel: sd1: SCB 0x3 timedout while recovery in progr >ess >Aug 17 10:27:32 freebie /kernel: sd0: SCB 1 - Abort Completed. >Aug 17 10:27:32 freebie /kernel: sd0: no longer in timeout >Aug 17 10:27:32 freebie /kernel: sd1: UNIT ATTENTION asc:29,0 >Aug 17 10:27:32 freebie /kernel: sd1: Power on, reset, or bus device reset oc >curred >Aug 17 10:27:32 freebie /kernel: , retries:3 > >So sd3 complains, but carries on with no harm done, Yup. The "sd" type driver seems to handle a bus reset gracefully. >Aug 17 10:27:32 freebie /kernel: st0: UNIT ATTENTION asc:29,0 >Aug 17 10:27:32 freebie /kernel: st0: Power on, reset, or bus > device reset occurred >Aug 17 10:27:32 freebie /kernel: st0: Target Busy > >but the tape dies. Is there a good reason for this? I would have >thought that it would make sense for a power on or reset, but not >for a bus reset. Does a tape unit lose its position or data when >it receives a bus reset? As you can tell by the sense code that is returned, your tape drive draws no distinction between "Power on", "reset" (i.e. bus reset), or "bus device reset" and is probably returning "Target Busy" because it is going through self test. Any information regarding tape position is almost certainly lost as is probably the case for the compression/density settings. The "st" driver should be able to restore the drive to the previous condition though since it knows all of the information to do so. This is a bug. >Is anybody doing anything about this? In a way I am, and in a way I'm not. All of these problems are well known to me and are being addressed in a complete rewrite of the FreeBSD SCSI layer. Ken Merry and myself are working diligently on this task and I have chosen to put 99% of my effort into completing this work instead of attempting to patch around the outstanding problems in the current implementation. The current status of the rewrite includes support for the Adaptec aic7xxx cards, disks, cdroms, application pass through (what scsi(8) would use to access devices), and fledgling target mode support. Once we have a tape driver, target mode, and some remaining error recovery issues dealt with, the code will be available for beta test while all remaining controller drivers are ported to the new system and a few remaining features are added. If you are willing to do without some features and device support and are interrested in giving early feedback on the work, contact me in private mail. > >Greg > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Mon Aug 18 22:01:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA10487 for freebsd-scsi-outgoing; Mon, 18 Aug 1997 22:01:11 -0700 (PDT) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA10482 for ; Mon, 18 Aug 1997 22:01:08 -0700 (PDT) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id WAA24101; Mon, 18 Aug 1997 22:00:43 -0700 (PDT) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id WAA29894; Mon, 18 Aug 1997 22:00:42 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA28433; Mon, 18 Aug 1997 22:00:41 -0700 (PDT) From: Don Lewis Message-Id: <199708190500.WAA28433@salsa.gv.tsc.tdk.com> Date: Mon, 18 Aug 1997 22:00:40 -0700 In-Reply-To: "Justin T. Gibbs" "Re: Bus resets. Grrrr." (Aug 18, 9:59pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: "Justin T. Gibbs" , Greg Lehey Subject: Re: Bus resets. Grrrr. Cc: freebsd-scsi@FreeBSD.ORG (FreeBSD SCSI Mailing List) Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Aug 18, 9:59pm, "Justin T. Gibbs" wrote: } Subject: Re: Bus resets. Grrrr. } } So, what does a "timeout while idle" tell us? Well, it means that either } the timeout that the type driver (in this case the "st" driver) specified } was too short [ deleted ] } The } first problem seems really common in the st driver especially when older } media or a rewind operation is involved. You can try bumping up the } timeouts in sys/scsi/st.c to see if this solves your problem. I had to increase the read/write timeout to 10 minutes from the default 2 minutes for a HP C1553 DAT using 90m tapes connected to a SunOS box. If the drive sees too many errors, it does a "head scrub" to try to dislodge any dirt from the head. This takes a really long time ... --- Truck From owner-freebsd-scsi Mon Aug 18 22:21:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA11452 for freebsd-scsi-outgoing; Mon, 18 Aug 1997 22:21:41 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA11445 for ; Mon, 18 Aug 1997 22:21:33 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id HAA13263; Tue, 19 Aug 1997 07:21:31 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id HAA19121; Tue, 19 Aug 1997 07:14:32 +0200 (MET DST) Message-ID: <19970819071432.KF58091@uriah.heep.sax.de> Date: Tue, 19 Aug 1997 07:14:32 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Cc: mandrews@termfrost.org (Mike Andrews) Subject: Re: HP 4020i CD-R problems References: <19970818231104.CG02430@uriah.heep.sax.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Mike Andrews on Aug 18, 1997 18:38:14 -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Mike Andrews wrote: > > > mindcrime# wormcontrol select HP 4020i > > > wormcontrol: open(/dev/rworm0): Device not configured > > > > Does this even happen after reloading the medium? > > Yep. Hmm. > And to answer another question I got in email, I did rerun MAKEDEV worm > just in case: That was no question. I can distinguish ENOENT from ENXIO. :-) Unless you can see the drive working again when booting an older kernel, i'd suspect the drive went south. Of course, you can turn on options SCSIDEBUG (plus ``scsi -f ... -d XX), and see what it's really doing. -- 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 Aug 18 23:01:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA13315 for freebsd-scsi-outgoing; Mon, 18 Aug 1997 23:01:07 -0700 (PDT) Received: from nico.telstra.net (nico.telstra.net [139.130.204.16]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA13306 for ; Mon, 18 Aug 1997 23:01:01 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by nico.telstra.net (8.6.10/8.6.10) with ESMTP id QAA05099; Tue, 19 Aug 1997 16:00:25 +1000 Received: (grog@localhost) by freebie.lemis.com (8.8.7/8.6.12) id PAA00370; Tue, 19 Aug 1997 15:30:24 +0930 (CST) Message-ID: <19970819153023.02433@lemis.com> Date: Tue, 19 Aug 1997 15:30:23 +0930 From: Greg Lehey To: "Justin T. Gibbs" Cc: FreeBSD SCSI Mailing List Subject: Re: Bus resets. Grrrr. References: <199708170129.KAA03776@freebie.lemis.com> <199708190359.VAA10011@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199708190359.VAA10011@pluto.plutotech.com>; from Justin T. Gibbs on Mon, Aug 18, 1997 at 09:59:02PM -0600 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, Aug 18, 1997 at 09:59:02PM -0600, Justin T. Gibbs wrote: >> This is the third time in a row that I haven't been able to complete a backup >> because of "recoverable" SCSI errors. Here's a pretty typical scenario: > > What version of the kernel are you using Recent versions of -current. The ones I reported it against were some time last week. I've just rebuilt with a version supped this morning. > with what AHC options enabled in your kernel config file? The version I was using when I got these messages had the following relevant options: controller ahc0 controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr controller aha1 at isa? port 0x334 bio irq ? drq 7 vector ahaintr controller scbus0 device sd0 device st0 device cd0 #Only need one of these, the code dynamically grows options SCSIDEBUG options SCSI_REPORT_GEOMETRY The machine does, in fact, have two SCSI controllers (the 2940A and a 1542B). At the moment I'm not having any problems on the 1542B, with the exception of lack of bounce buffers for the CD-ROM changer connected to it. >> Aug 17 10:27:19 freebie /kernel: sd0: SCB 0x4 - timed out while idle, LASTPHAS >> E == 0x1, SCSISIGI == 0x0 >> >> What does this mean? What can time out when nothing's happening? Or is >> this a timeout accepting a new command when it shouldn't have to? Is this >> a device or a driver logic error? > > The message simply indicates the state of the SCSI bus at the time the > timeout occured. In this case, the sequencer was sitting in it's idle > loop waiting for new work to be queued by the kernel driver or for a > device to reconnect and continue a previously established connection. > To understand why a timeout can occur in this state or any other, it's > probably best to explain the timeout model that is used in FreeBSD. > The "type" drivers (e.g. sd, cd, st, worm, etc) specifies a timeout value > for each command it issues. When the adaptec driver queues a command > to the controller, it sets up a "callout" that will occur timeout ms > in the future for the just queued command. In this particular case, > that "callout" fired while the sequencer wasn't working on any > commands. Aha (oops, ahc). So the state isn't usually very relevant to the problem? > So, what does a "timeout while idle" tell us? Well, it means that either > the timeout that the type driver (in this case the "st" driver) In fact, this was the sd driver, specifically sd0. It always seems to be sd0, although I have 3 disks connected to the bus, which tends to confirm the theory that there is something wrong with the physical bus. It could also, of course, indicate that the disk is dying. > specified was too short, or the aic7xxx driver lost the command > somewhere either in route to or from the device. The latter problem > did occur under heavy load prior to my latest "spin lock" change to > the driver. When was that? Would it also have the effect thtat the abort message wouldn't be taken? > The first problem seems really common in the st driver especially > when older media or a rewind operation is involved. You can try > bumping up the timeouts in sys/scsi/st.c to see if this solves your > problem. As I said, this wasn't a tape device timeout. In any case, this always seems to happen when the tape is writing, which makes it look more like the heavy load scenario. >> Aug 17 10:27:31 freebie /kernel: SEQADDR = 0x9 SCSISEQ = 0x12 SSTAT0 = 0x5 SST >> AT1 = 0xa >> Aug 17 10:27:31 freebie /kernel: sd0: Queueing an Abort SCB >> Aug 17 10:27:31 freebie /kernel: sd0: Abort Message Sent >> Aug 17 10:27:31 freebie /kernel: sd0: SCB 0x4 - timed out in message out phase >> , SCSISIGI == 0xa4 >> Aug 17 10:27:31 freebie /kernel: SEQADDR = 0x9a SCSISEQ = 0x12 SSTAT0 = 0x5 SS >> TAT1 = 0x2 >> >> If I understand this correctly, this means that the abort SCB wasn't received >> either, so the driver does a bus reset: > > What it means is that the tape drive accepted the connection from > the controller, most likely accepted the ABORT message, but took > longer than the driver allowed for it to process the abort request, > free the bus, and thus signal that the abort was successful. So, > we take out the hammer and reset the bus. The timeout in the > aic7xxx driver for abort requests may be too short. Would this still be the case for disks? >> Aug 17 10:27:31 freebie /kernel: ahc0: Issued Channel A Bus Reset. 3 SCBs abor >> ted >> Aug 17 10:27:32 freebie /kernel: Clearing bus reset >> Aug 17 10:27:32 freebie /kernel: Clearing 'in-reset' flag >> Aug 17 10:27:32 freebie /kernel: sd0: no longer in timeout >> >> ... which works. >> >> Aug 17 10:27:32 freebie /kernel: sd0: SCB 0x4 - timed out in command phase, SC >> SISIGI == 0x84 >> >> So why do we get another timeout? Or is this overlapping? > > This is due to the way that timeout process occurs in the current driver. > If I have 20 operations outstanding, each with a timeout queued, those > timeouts are still in effect while I am doing recovery processing. So, > even if I just unwedged the bus, a timeout for a pending command can > fire "logically too soon". OK. >> Aug 17 10:27:32 freebie /kernel: SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SS >> TAT1 = 0x2 >> Aug 17 10:27:32 freebie /kernel: sd0: abort message in message buffer >> Aug 17 10:27:32 freebie /kernel: sd1: SCB 0x3 timedout while recovery in progr >> ess >> Aug 17 10:27:32 freebie /kernel: sd0: SCB 1 - Abort Completed. >> Aug 17 10:27:32 freebie /kernel: sd0: no longer in timeout >> Aug 17 10:27:32 freebie /kernel: sd1: UNIT ATTENTION asc:29,0 >> Aug 17 10:27:32 freebie /kernel: sd1: Power on, reset, or bus device reset oc >> curred >> Aug 17 10:27:32 freebie /kernel: , retries:3 >> >> So sd3 complains, but carries on with no harm done, > > Yup. The "sd" type driver seems to handle a bus reset gracefully. > >> Aug 17 10:27:32 freebie /kernel: st0: UNIT ATTENTION asc:29,0 >> Aug 17 10:27:32 freebie /kernel: st0: Power on, reset, or bus >> device reset occurred >> Aug 17 10:27:32 freebie /kernel: st0: Target Busy >> >> but the tape dies. Is there a good reason for this? I would have >> thought that it would make sense for a power on or reset, but not >> for a bus reset. Does a tape unit lose its position or data when >> it receives a bus reset? > > As you can tell by the sense code that is returned, your tape drive > draws no distinction between "Power on", "reset" (i.e. bus reset), > or "bus device reset" and is probably returning "Target Busy" because > it is going through self test. Any information regarding tape position > is almost certainly lost as is probably the case for the compression/density > settings. The "st" driver should be able to restore the drive to > the previous condition though since it knows all of the information > to do so. This is a bug. Are you sure? I thought so at first too, but then it occurred to me that after the reset, the tape drive would probably not have enough information to continue. For example, it would probably have cleared its buffer memory (this is a DDS-2 drive). In this connection, it's interesting to report how I tried to recover from the problem. I'm writing several files to a non-rewinding device, and lately they've been dying in the same file. I check the return status from tar, and if it's non-0, do a bsf 1, an fsf 1, and restart the tar. The first bsf 1 always fails, apparently because the drive doesn't know where it is. The second bsf 1 succeeds. Greg From owner-freebsd-scsi Mon Aug 18 23:33:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA15139 for freebsd-scsi-outgoing; Mon, 18 Aug 1997 23:33:46 -0700 (PDT) Received: from mail.kcwc.com (h1.kcwc.com [206.139.252.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA15132 for ; Mon, 18 Aug 1997 23:33:43 -0700 (PDT) Received: by mail.kcwc.com (NX5.67c/NeXT-2.0-KCWC-1.0) id AA20893; Tue, 19 Aug 97 02:33:28 -0400 Date: Tue, 19 Aug 97 02:33:28 -0400 From: curt@kcwc.com (Curt Welch) Message-Id: <9708190633.AA20893@mail.kcwc.com> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: Tom Samplonius Subject: Re: expected performance with DPT RAID-5... Cc: scsi@FreeBSD.ORG, curt@kcwc.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tom wrote: > "cd" to one of the RAID-5 file systems and do a "dd > if=/dev/zero of=testfile bs=64k count=1000". That will > create a file called "testfile" 64MB in length (64k x > 1000), and tell you how long it took to write it. > Then reboot (the only way I know of clearing the FreeBSD > file cache, and the DPT cache), and do a "dd if=testfile > bs=64k of=/dev/null" to read the file back. > On the write test I get about 3500000 bps, and the > write test about 9200000 bps. These results don't seem > very good too me. On bus 0 I have fast/wide drives but I currently have the speed limited to 5Mhz (slow/wide?). On bus 1 I have ultra/wide drives and the bus is currently limted to 5Mhz (trying to work out SCSI problems), but I put it back to 20 Mhz for some of these tests. Numbers are all bytes per second (output from dd). On write, I see 1,800,000 on bus 0 at 5 Mhz 2,500,000 on bus 1 at 20 Mhz. 2,400,000 on bus 1 at 5 Mhz On read, I see 6,300,000 on bus 0 at 5 Mhz. 5,400,000 on bus 1 at 5 Mhz. This is with 2.2.2-RELEASE and the DPT 1.1.10 driver with the following options set: options DPT_USE_SINTR=1 options DPT_MEASURE_PERFORMANCE options DPT_TRACK_CCB_STATES options DPT_HANDLE_TIMEOUTS options DPT_COMMAND_SPLHIGH options DPT_INTR_CHECK_SOFTC The ultra-wide drives are Quantum Vikings. I also have one of these drives connected to an Adaptec 9240UW card in the same system. Your test on that drive produces: On write, I see 8,400,000 on AHA at 20 Mhz read is about the same - but I don't want to reboot again to do a "clean" no cache test. I suspect it would produce about the same number however. This test: dd if=/dev/rsd1c bs=8k of=/dev/null count=10000 produces a rate of 9.3 MB/S on the AHA. On the DPT (bus 1 at 5Mhz), it produces a rate of 4.0 MB/S. I'm not over impressed with these numbers for the DPT, but then I'm still dealing with unknown SCSI problems with this set-up. Curt From owner-freebsd-scsi Tue Aug 19 08:56:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA14548 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 08:56:51 -0700 (PDT) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA14532 for ; Tue, 19 Aug 1997 08:56:40 -0700 (PDT) Received: by kaori.communique.net with Internet Mail Service (5.0.1458.49) id ; Tue, 19 Aug 1997 10:56:39 -0500 Message-ID: From: Raul Zighelboim To: "'scsi@freebsd.org'" Subject: ahc drivers configuration question... Date: Tue, 19 Aug 1997 10:56:37 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a system with 5 internal drives, and I am about to move 3 drives from a different machine into this one. I am trying to minimise downtime. So, my questions are: Is the confiration as I have it correct ? (sd1, sd2 and sd3 will be added at the last minute). Is it possible to do 'disk sd1 at scbus1 target 0' when I have 'disk sd0 at scbus0 target 0' on the same controller ? Is there something I must change on the controller to allow this (ie, force termination) ? Thanks This is what I have on my kernel: ----------- controller ahc0 controller ahc1 controller scbus0 at ahc0 bus 0 controller scbus1 at ahc0 bus 1 controller scbus2 at ahc1 bus 0 disk sd0 at scbus0 target 0 disk sd1 at scbus1 target 1 disk sd2 at scbus1 target 2 disk sd3 at scbus1 target 3 disk sd4 at scbus2 target 1 disk sd5 at scbus2 target 2 disk sd6 at scbus2 target 3 disk sd7 at scbus2 target 4 ----------- From owner-freebsd-scsi Tue Aug 19 09:57:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA18834 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 09:57:12 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA18823 for ; Tue, 19 Aug 1997 09:57:07 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id KAA24228; Tue, 19 Aug 1997 10:54:29 -0600 (MDT) Message-Id: <199708191654.KAA24228@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey cc: FreeBSD SCSI Mailing List Subject: Re: Bus resets. Grrrr. In-reply-to: Your message of "Tue, 19 Aug 1997 15:30:23 +0930." <19970819153023.02433@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Aug 1997 10:53:54 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> What version of the kernel are you using > >Recent versions of -current. The ones I reported it against were some >time last week. I've just rebuilt with a version supped this morning. And it is still reproducible? >> The message simply indicates the state of the SCSI bus at the time the >> timeout occurred... > >Aha (oops, ahc). So the state isn't usually very relevant to the >problem? It depends on the problem. If the sequencer code has a protocol bug, it is usually indicated by a hang or timeout in a particular bus state. >> So, what does a "timeout while idle" tell us? Well, it means that either >> the timeout that the type driver (in this case the "st" driver) > >In fact, this was the sd driver, specifically sd0. It always seems to >be sd0, although I have 3 disks connected to the bus, which tends to >confirm the theory that there is something wrong with the physical >bus. It could also, of course, indicate that the disk is dying. Hmmm. How many devices are active at the time that the timeout occurs? Since you are not using tagged queuing, you would need 5 devices active at a time to overflow the QOUTFIFO (the bug that I fixed recently) on an aic7860 based controller. >> specified was too short, or the aic7xxx driver lost the command >> somewhere either in route to or from the device. The latter problem >> did occur under heavy load prior to my latest "spin lock" change to >> the driver. > >When was that? Would it also have the effect that the abort message >wouldn't be taken? The abort probably was taken, but the tape drive took a long time to release the bus, which was why the bus was reset. I put my fix in the kernel on 8/13 in rev 1.121 or aic7xxx.c. >> The first problem seems really common in the st driver especially >> when older media or a rewind operation is involved. You can try >> bumping up the timeouts in sys/scsi/st.c to see if this solves your >> problem. > >As I said, this wasn't a tape device timeout. In any case, this >always seems to happen when the tape is writing, which makes it look >more like the heavy load scenario. Could it be that you don't have disconnections enabled for your tape drive? You should check both SCSI-Select for the 2940 and any relevant jumpers on the tape drive itself. If disconnections are disabled, a tape write that required multiple retries could easily tie up the SCSI bus for the 10s needed to make a disk command time out. >> What it means is that the tape drive accepted the connection from >> the controller, most likely accepted the ABORT message, but took >> longer than the driver allowed for it to process the abort request, >> free the bus, and thus signal that the abort was successful. So, >> we take out the hammer and reset the bus. The timeout in the >> aic7xxx driver for abort requests may be too short. > >Would this still be the case for disks? > The analysis is the same regardless of the device type. >> As you can tell by the sense code that is returned, your tape drive >> draws no distinction between "Power on", "reset" (i.e. bus reset), >> or "bus device reset" and is probably returning "Target Busy" because >> it is going through self test. Any information regarding tape position >> is almost certainly lost as is probably the case for the compression/density >> settings. The "st" driver should be able to restore the drive to >> the previous condition though since it knows all of the information >> to do so. This is a bug. > >Are you sure? I thought so at first too, but then it occurred to me >that after the reset, the tape drive would probably not have enough >information to continue. For example, it would probably have cleared >its buffer memory (this is a DDS-2 drive). The device should flush any cached information for previous commands completed with "good status" to the media in the process of handling the reset. Any device that doesn't do this is broken. >In this connection, it's interesting to report how I tried to recover >from the problem. I'm writing several files to a non-rewinding >device, and lately they've been dying in the same file. I check the >return status from tar, and if it's non-0, do a bsf 1, an fsf 1, and >restart the tar. The first bsf 1 always fails, apparently because the >drive doesn't know where it is. The second bsf 1 succeeds. The first one probably fails because the device isn't ready. What error is reported on the console? >Greg -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Tue Aug 19 09:59:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA18963 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 09:59:50 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA18954 for ; Tue, 19 Aug 1997 09:59:46 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id KAA24398; Tue, 19 Aug 1997 10:59:44 -0600 (MDT) Message-Id: <199708191659.KAA24398@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Raul Zighelboim cc: "'scsi@freebsd.org'" Subject: Re: ahc drivers configuration question... In-reply-to: Your message of "Tue, 19 Aug 1997 10:56:37 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Aug 1997 10:59:09 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >I have a system with 5 internal drives, and I am about to move 3 drives >from a different machine into this one. I am trying to minimise >downtime. What kind of controller do you have? The "bus" keywords in your configuration only make sense for the 2742(A)T controllers. If you are using a 39XX controller, the extra channels show up as separate SCSI controllers since that is exactly how they are implemented on the card. >So, my questions are: > Is the confiration as I have it correct ? (sd1, sd2 and sd3 >will be added at the last minute). Apart from possibly the scbus declarations, it looks to be correct. > Is it possible to do 'disk sd1 at scbus1 target 0' when I have >'disk sd0 at scbus0 target 0' on the same controller ? Sure. > Is there something I must change on the controller to allow this >(ie, force termination) ? I don't understand this question. > Thanks -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Tue Aug 19 10:09:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA19921 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 10:09:40 -0700 (PDT) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA19915 for ; Tue, 19 Aug 1997 10:09:32 -0700 (PDT) Received: by kaori.communique.net with Internet Mail Service (5.0.1458.49) id ; Tue, 19 Aug 1997 12:09:27 -0500 Message-ID: From: Raul Zighelboim To: "'Justin T. Gibbs'" Cc: "'scsi@freebsd.org'" Subject: RE: ahc drivers configuration question... Date: Tue, 19 Aug 1997 12:09:25 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thanks for the answer.... The controller is an adaptec 2940UW: ahc0 rev 0 int a irq 9 on pci0:12 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs So, I imagine that the answer is no, I do not have 2 busses on the controller ... :-( > > Is it possible to do 'disk sd1 at scbus1 target 0' when I have > >'disk sd0 at scbus0 target 0' on the same controller > > Sure. > > > Is there something I must change on the controller to allow this > >(ie, force termination) ? > > I don't understand this question. > > > Thanks > > -- > Justin T. Gibbs > =========================================== > FreeBSD: Turning PCs into workstations > =========================================== > From owner-freebsd-scsi Tue Aug 19 10:14:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA20342 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 10:14:24 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA20334 for ; Tue, 19 Aug 1997 10:14:22 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id LAA24850; Tue, 19 Aug 1997 11:14:19 -0600 (MDT) Message-Id: <199708191714.LAA24850@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Raul Zighelboim cc: "'Justin T. Gibbs'" , "'scsi@freebsd.org'" Subject: Re: ahc drivers configuration question... In-reply-to: Your message of "Tue, 19 Aug 1997 12:09:25 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Aug 1997 11:13:43 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >Thanks for the answer.... > > The controller is an adaptec 2940UW: >ahc0 rev 0 int a irq 9 on pci0:12 >ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs > >So, I imagine that the answer is no, I do not have 2 busses on the >controller ... No, you only have one and you can only use 2 out of the three connectors on the card at a time. You user manual should have all of the details on this, or you can visit Adaptec's web site for details on the bus configuration issues for this card. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Tue Aug 19 14:00:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA05172 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 14:00:29 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA05159 for ; Tue, 19 Aug 1997 14:00:21 -0700 (PDT) Received: from tom by misery.sdf.com with smtp (Exim 1.62 #1) id 0x0vM3-00018r-00; Tue, 19 Aug 1997 13:58:19 -0700 Date: Tue, 19 Aug 1997 13:58:19 -0700 (PDT) From: Tom Samplonius To: Curt Welch cc: scsi@freebsd.org Subject: Re: expected performance with DPT RAID-5... In-Reply-To: <9708190633.AA20893@mail.kcwc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 19 Aug 1997, Curt Welch wrote: > Tom wrote: > > "cd" to one of the RAID-5 file systems and do a "dd > > if=/dev/zero of=testfile bs=64k count=1000". That will > > create a file called "testfile" 64MB in length (64k x > > 1000), and tell you how long it took to write it. > > > Then reboot (the only way I know of clearing the FreeBSD > > file cache, and the DPT cache), and do a "dd if=testfile > > bs=64k of=/dev/null" to read the file back. > > > On the write test I get about 3500000 bps, and the > > write test about 9200000 bps. These results don't seem > > very good too me. > > On bus 0 I have fast/wide drives but I currently have > the speed limited to 5Mhz (slow/wide?). > > On bus 1 I have ultra/wide drives and the bus is currently > limted to 5Mhz (trying to work out SCSI problems), but I > put it back to 20 Mhz for some of these tests. > > Numbers are all bytes per second (output from dd). > > On write, I see 1,800,000 on bus 0 at 5 Mhz > 2,500,000 on bus 1 at 20 Mhz. > 2,400,000 on bus 1 at 5 Mhz > > On read, I see 6,300,000 on bus 0 at 5 Mhz. > 5,400,000 on bus 1 at 5 Mhz. > > This is with 2.2.2-RELEASE and the DPT 1.1.10 driver with > the following options set: > > options DPT_USE_SINTR=1 > options DPT_MEASURE_PERFORMANCE > options DPT_TRACK_CCB_STATES > options DPT_HANDLE_TIMEOUTS > options DPT_COMMAND_SPLHIGH > options DPT_INTR_CHECK_SOFTC > > The ultra-wide drives are Quantum Vikings. I also have one > of these drives connected to an Adaptec 9240UW card in the > same system. Your test on that drive produces: > > On write, I see 8,400,000 on AHA at 20 Mhz > > read is about the same - but I don't want to reboot again to > do a "clean" no cache test. I suspect it would produce about > the same number however. > > This test: dd if=/dev/rsd1c bs=8k of=/dev/null count=10000 > > produces a rate of 9.3 MB/S on the AHA. > > On the DPT (bus 1 at 5Mhz), it produces a rate of 4.0 MB/S. > > I'm not over impressed with these numbers for the DPT, but > then I'm still dealing with unknown SCSI problems with this > set-up. > > Curt > > Call Granite Digital and order custom ribbon cables, and an external cable if you need it, and UW terminator. It will be expensive, but everything will run very clean after. Tom From owner-freebsd-scsi Tue Aug 19 16:50:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA14483 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 16:50:18 -0700 (PDT) Received: from nico.telstra.net (nico.telstra.net [139.130.204.16]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id QAA14471 for ; Tue, 19 Aug 1997 16:50:12 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by nico.telstra.net (8.6.10/8.6.10) with ESMTP id JAA23375; Wed, 20 Aug 1997 09:38:11 +1000 Received: (grog@localhost) by freebie.lemis.com (8.8.7/8.6.12) id JAA01942; Wed, 20 Aug 1997 09:08:10 +0930 (CST) Message-ID: <19970820090810.54774@lemis.com> Date: Wed, 20 Aug 1997 09:08:10 +0930 From: Greg Lehey To: "Justin T. Gibbs" Cc: FreeBSD SCSI Mailing List Subject: Re: Bus resets. Grrrr. References: <19970819153023.02433@lemis.com> <199708191654.KAA24228@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199708191654.KAA24228@pluto.plutotech.com>; from Justin T. Gibbs on Tue, Aug 19, 1997 at 10:53:54AM -0600 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, Aug 19, 1997 at 10:53:54AM -0600, Justin T. Gibbs wrote: >>> What version of the kernel are you using >> >> Recent versions of -current. The ones I reported it against were some >> time last week. I've just rebuilt with a version supped this morning. > > And it is still reproducible? I changed the configuration file and added (inter alia) AHC_SCBPAGING_ENABLE. The resultant kernel hung solid three times in the course of a couple of hours, once with a disk activity light on solid, and the other two without. I removed AHC_SCBPAGING_ENABLE, and last night the backup went through for the first time in a week. It ran fine until last Wednesday, however, so this could be a coincidence. >>> So, what does a "timeout while idle" tell us? Well, it means that either >>> the timeout that the type driver (in this case the "st" driver) >> >> In fact, this was the sd driver, specifically sd0. It always seems to >> be sd0, although I have 3 disks connected to the bus, which tends to >> confirm the theory that there is something wrong with the physical >> bus. It could also, of course, indicate that the disk is dying. > > Hmmm. How many devices are active at the time that the timeout occurs? > Since you are not using tagged queuing, you would need 5 devices active > at a time to overflow the QOUTFIFO (the bug that I fixed recently) on an > aic7860 based controller. No, at the moment the chain only has four devices connected, but I notice it finds two LUNs for the tape changer: ahc0: rev 0x03 int a irq 12 on pci0.18.0 ahc0: aic7870 Single Channel, SCSI Id=7, 16 SCBs ahc0: waiting for scsi devices to settle scbus0 at ahc0 bus 0 scbus0 target 0 lun 0: type 0 fixed SCSI 2 sd0 at scbus0 target 0 lun 0 sd0: Direct-Access 1001MB (2051615 512 byte sectors) sd0: with 1760 cyls, 15 heads, and an average 77 sectors/track scbus0 target 3 lun 0: type 0 fixed SCSI 2 sd1 at scbus0 target 3 lun 0 sd1: Direct-Access 2063MB (4226725 512 byte sectors) sd1: with 6703 cyls, 5 heads, and an average 126 sectors/track scbus0 target 4 lun 0: type 1 removable SCSI 2 st0 at scbus0 target 4 lun 0 st0: Sequential-Access density code 0x24, 512-byte blocks, write-enabled scbus0 target 4 lun 1: type 8 removable SCSI 2 uk0 at scbus0 target 4 lun 1 uk0: Unknown scbus0 target 5 lun 0: type 1 removable SCSI 1 st1 at scbus0 target 5 lun 0 st1: Sequential-Access density code 0x0, drive empty You can be pretty sure that the Tandberg tape is not active, though--I don't use it very often. >>> specified was too short, or the aic7xxx driver lost the command >>> somewhere either in route to or from the device. The latter problem >>> did occur under heavy load prior to my latest "spin lock" change to >>> the driver. >> >> When was that? Would it also have the effect that the abort message >> wouldn't be taken? > > The abort probably was taken, but the tape drive took a long time to > release the bus, which was why the bus was reset. I put my fix in > the kernel on 8/13 in rev 1.121 or aic7xxx.c. That looks about right for it to be this fix. The previous kernel was compiled (and current) on the 9th. >>> The first problem seems really common in the st driver especially >>> when older media or a rewind operation is involved. You can try >>> bumping up the timeouts in sys/scsi/st.c to see if this solves your >>> problem. >> >> As I said, this wasn't a tape device timeout. In any case, this >> always seems to happen when the tape is writing, which makes it look >> more like the heavy load scenario. > > Could it be that you don't have disconnections enabled for your tape drive? > You should check both SCSI-Select for the 2940 and any relevant jumpers > on the tape drive itself. If disconnections are disabled, a tape write that > required multiple retries could easily tie up the SCSI bus for the 10s > needed to make a disk command time out. You'd see that on the activity light, right? In any case, the host adapter is set correctly, and the tape doesn't seem to have any such config switch. Would there be another way to test that? >> In this connection, it's interesting to report how I tried to recover >> from the problem. I'm writing several files to a non-rewinding >> device, and lately they've been dying in the same file. I check the >> return status from tar, and if it's non-0, do a bsf 1, an fsf 1, and >> restart the tar. The first bsf 1 always fails, apparently because the >> drive doesn't know where it is. The second bsf 1 succeeds. > > The first one probably fails because the device isn't ready. That's what I thought, too, so I put a sleep 30 into the script. It still works the second time. > What error is reported on the console? I can't remember seeing one. I can't reproduce this at will, but I've looked through /var/adm/messages, and I don't see anything. Greg From owner-freebsd-scsi Tue Aug 19 19:33:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA21586 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 19:33:14 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA21578 for ; Tue, 19 Aug 1997 19:33:10 -0700 (PDT) Received: from gurney.reilly.home (d11.syd2.zeta.org.au [203.26.11.11]) by godzilla.zeta.org.au (8.8.5/8.6.9) with ESMTP id MAA05718 for ; Wed, 20 Aug 1997 12:29:59 +1000 Received: from gurney.reilly.home (localhost [127.0.0.1]) by gurney.reilly.home (8.8.5/8.8.5) with ESMTP id MAA21070 for ; Wed, 20 Aug 1997 12:29:33 +1000 (EST) Message-Id: <199708200229.MAA21070@gurney.reilly.home> Date: Wed, 20 Aug 1997 12:29:31 +1000 (EST) From: Andrew Reilly Subject: newfs on Fujitsu R640 (2k sector media) To: freebsd-scsi@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi all, I have a Fujitsu M2513A magneto-optical disk drive, and I've been using it quite happily with R230 media (230M, 512-byte sectors) for a while, because I was not confident that my pre-release 2.2 FreeBSD would support non-512-byte sectors. I have since upgraded to 2.2.2, and bought myself some R640 disks (640M, 2048-byte sectors), and lo: it doesn't work. Here's the skinny: This is what the boot probe says: Aug 8 09:09:21 gurney /kernel: (ahc0:6:0): "FUJITSU M2513A 1300" type 7 removab le SCSI 2 Aug 8 09:09:22 gurney /kernel: od0(ahc0:6:0): Optical 606MB (310352 2048 byte s ectors) Aug 8 09:09:22 gurney /kernel: od0(ahc0:6:0): with approximate 151 cyls, 64 hea For reference, here's what an earlier boot with an R230 disk in the drive looks like: Aug 7 10:25:48 gurney /kernel.vm86: (ahc0:6:0): "FUJITSU M2513A 1300" type 7 re movable SCSI 2 Aug 7 10:25:48 gurney /kernel.vm86: od0(ahc0:6:0): Optical 217MB (446325 512 by te sectors) Aug 7 10:25:48 gurney /kernel.vm86: od0(ahc0:6:0): with approximate 217 cyls, 6 4 heads, and 32 sectors/track On a side issue (I hope), I tried a few different things after the upgrade, including enabling the "Spindle automatic stop mode" on the drive, and setting the "Device type mode for INQUIRY command" to MO, and using the od driver, instead of the sd driver. I don't know what the difference is (I was hoping for an eject on unmount...) but now I get these messages occasionally: This one every time I mount one of the R230 disks I had formatted under the pre-release 2.2 FreeBSD: Aug 7 14:29:43 gurney /kernel: od0: invalid primary partition table: no magic This looks like a spin-down thing. Note at the end that I re-tried the mount, and it just worked: Aug 8 13:24:00 gurney /kernel: od0(ahc0:6:0): NOT READY asc:4,0 Aug 8 13:24:00 gurney /kernel: od0(ahc0:6:0): Logical unit not ready, cause no t reportable Aug 8 13:24:00 gurney /kernel: , retries:2 Aug 8 13:24:00 gurney /kernel: od0(ahc0:6:0): NOT READY asc:4,0 Aug 8 13:24:00 gurney /kernel: od0(ahc0:6:0): Logical unit not ready, cause no t reportable Aug 8 13:24:00 gurney /kernel: , retries:1 Aug 8 13:24:00 gurney /kernel: od0(ahc0:6:0): NOT READY asc:4,0 Aug 8 13:24:00 gurney /kernel: od0(ahc0:6:0): Logical unit not ready, cause no t reportable Aug 8 13:24:00 gurney /kernel: , FAILURE Aug 8 13:24:00 gurney /kernel: od0(ahc0:6:0): NOT READY asc:4,0 Aug 8 13:24:00 gurney /kernel: od0(ahc0:6:0): Logical unit not ready, cause no t reportable Aug 8 13:24:00 gurney /kernel: , retries:2 Aug 8 13:24:00 gurney /kernel: od0(ahc0:6:0): NOT READY asc:4,0 Aug 8 13:24:00 gurney /kernel: od0(ahc0:6:0): Logical unit not ready, cause no t reportable Aug 8 13:24:00 gurney /kernel: , retries:1 Aug 8 13:24:00 gurney /kernel: od0(ahc0:6:0): NOT READY asc:4,0 Aug 8 13:24:00 gurney /kernel: od0(ahc0:6:0): Logical unit not ready, cause no t reportable Aug 8 13:24:00 gurney /kernel: , FAILURE Aug 8 13:24:17 gurney /kernel: od0: invalid primary partition table: no magic This one caused a hang that I had to press the reset button to get out of: Aug 7 14:30:14 gurney /kernel: od0(ahc0:6:0): SCB 0x0 - timed out while idle, L ASTPHASE == 0x1, SCSISIGI == 0x0 Aug 7 14:30:14 gurney /kernel: SEQADDR = 0x4 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Aug 7 14:30:14 gurney /kernel: od0(ahc0:6:0): Queueing an Abort SCB Aug 7 14:30:14 gurney /kernel: od0(ahc0:6:0): Abort Message Sent Aug 7 14:30:14 gurney /kernel: od0(ahc0:6:0): SCB 0 - Abort Completed. Aug 7 14:30:14 gurney /kernel: od0(ahc0:6:0): no longer in timeout Aug 7 14:30:22 gurney /kernel: ahc0:A:6: no active SCB for reconnecting target - issuing BUS DEVICE RESET Aug 7 14:30:22 gurney /kernel: SAVED_TCL == 0x60 ARG_1 == 0x0 SEQADDR == 0x10d Aug 7 14:30:22 gurney /kernel: ahc0: Bus Device Reset delivered. 1 SCBs aborted Aug 7 14:30:22 gurney /kernel: ahc0: Bus Device Reset delivered. 1 SCBs aborted OK, those are unpleasant, but I figure I can get rid of them if I care to by preventing the drive from spinning down. What's bugging me at the moment is that I don't seem to be able to disklabel or newfs one of the R640 disks. I'm using this disktab entry, which I built out of the numbers reported at boot time, but it's essentially the same as the one that you get with disklabel -w -r auto: fuj640|R640|Fujitsu R640 media Meg 3.5inch Magneto-Optical:\ :ty=removeable:dt=SCSI:rm#3600:\ :se#2048:nt#64:ns#32:nc#151:sc#2048:su#310352:\ :pa#310352:oa#0:ba#16384:fa#2048:ta=4.2BSD:\ :pc#310352:oc#0: (Auto leavs ba and fa 0, which I guess causes newfs to pick sensible defaults?) # disklabel -e od0 disklabel: ioctl DIOCGDINFO: Invalid argument Here's a question: where do I find a description of DIOCGDINFO to figure out what this means? # disklabel -r -w od0 R640 # disklabel od0 disklabel: ioctl DIOCGDINFO: Invalid argument # disklabel -r od0 # /dev/rod0c: type: SCSI disk: fuj640 label: flags: bytes/sector: 2048 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 151 sectors/unit: 310352 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 3 partitions: # size offset fstype [fsize bsize bps/cpg] a: 310352 0 4.2BSD 2048 16384 0 # (Cyl. 0 - 151*) c: 310352 0 unused 0 0 # (Cyl. 0 - 151*) OK, that looks like it worked, but then: # newfs od0a newfs: /dev/rod0a: Invalid argument # newfs od0c newfs: ioctl (GDINFO): Invalid argument newfs: /dev/rod0c: can't read disk label; disk type must be specified # newfs -T R640 od0c write error: 310351. Tried 2048, wrote -1. wtfs: Invalid argument So, obviously there's something wrong with reading the disklabel. You can see that I've doctored the error printf() in the wtfs function in mkfs.c, in /usr/src/sbin/newfs, to see what was going on, and it was obviously trying to write a valid block size. Anyone care to offer suggestions? I'm happy to try patches or new things: I want this to work... Thanks in advance, -- Andrew "The steady state of disks is full." -- Ken Thompson From owner-freebsd-scsi Tue Aug 19 20:23:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA23963 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 20:23:14 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA23958 for ; Tue, 19 Aug 1997 20:23:12 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id VAA08483; Tue, 19 Aug 1997 21:20:38 -0600 (MDT) Message-Id: <199708200320.VAA08483@pluto.plutotech.com> To: Greg Lehey cc: FreeBSD SCSI Mailing List Subject: Re: Bus resets. Grrrr. In-reply-to: Your message of "Wed, 20 Aug 1997 09:08:10 +0930." <19970820090810.54774@lemis.com> Date: Tue, 19 Aug 1997 21:19:59 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >On Tue, Aug 19, 1997 at 10:53:54AM -0600, Justin T. Gibbs wrote: >>>> What version of the kernel are you using >>> >>> Recent versions of -current. The ones I reported it against were some >>> time last week. I've just rebuilt with a version supped this morning. >> >> And it is still reproducible? > >I changed the configuration file and added (inter alia) >AHC_SCBPAGING_ENABLE. The resultant kernel hung solid three times in >the course of a couple of hours, once with a disk activity light on >solid, and the other two without. I removed AHC_SCBPAGING_ENABLE, and >last night the backup went through for the first time in a week. It >ran fine until last Wednesday, however, so this could be a >coincidence. The system hung solid with no kernel messages or were you in X so you couldn't see them? There is no guarantee that driver messages will make it into the log file if the SCSI bus is wedged. I wasn't aware of any problems with SCB paging, so I'd be very interrested in any information you can provide on this problem. In most cases, BTW, SCB paging isn't a win unless you are also using tagged queuing (option AHC_TAGENABLE). >No, at the moment the chain only has four devices connected, but I >notice it finds two LUNs for the tape changer: Ahh. I thought you said you had a 2940A, not a 2940. This pretty much rules out the QOUTFIFO overflow problem (assuming you are not using tagged queueing, which your dmesg output seems to confirm) since the aic7870 has 16 slots meaning 9 active devices would be necessary. >ahc0: rev 0x03 int a irq 12 on pci0.18.0 >ahc0: aic7870 Single Channel, SCSI Id=7, 16 SCBs >ahc0: waiting for scsi devices to settle >scbus0 at ahc0 bus 0 >scbus0 target 0 lun 0: type 0 fixed SCSI 2 >sd0 at scbus0 target 0 lun 0 >sd0: Direct-Access 1001MB (2051615 512 byte sectors) >sd0: with 1760 cyls, 15 heads, and an average 77 sectors/track It looks like there is newer firmware available for this drive from Micropolis: ftp://techsupport.micropolis.com/pub/files/firmware/Aquaris/2105-2108-2112/4930010f.bin ftp://techsupport.micropolis.com/pub/files/Utils/ASPIUTIL.EXE >> Could it be that you don't have disconnections enabled for your tape drive? >> You should check both SCSI-Select for the 2940 and any relevant jumpers >> on the tape drive itself. If disconnections are disabled, a tape write that >> required multiple retries could easily tie up the SCSI bus for the 10s >> needed to make a disk command time out. > >You'd see that on the activity light, right? In any case, the host >adapter is set correctly, and the tape doesn't seem to have any such >config switch. Would there be another way to test that? Not really. Since the timeout was "while idle", chances are that disconnection is enabled and working. >> The first one probably fails because the device isn't ready. > >That's what I thought, too, so I put a sleep 30 into the script. It >still works the second time. Then it probably fails because there is a unit attention that needs to be cleared. The console error message would be enough to determine what is really happening. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Tue Aug 19 21:05:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA26410 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 21:05:09 -0700 (PDT) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA26394 for ; Tue, 19 Aug 1997 21:05:00 -0700 (PDT) Received: by kaori.communique.net with Internet Mail Service (5.0.1458.49) id ; Tue, 19 Aug 1997 23:04:59 -0500 Message-ID: From: Raul Zighelboim To: "'Justin T. Gibbs'" , Greg Lehey Cc: FreeBSD SCSI Mailing List Subject: RE: Bus resets. Grrrr. Date: Tue, 19 Aug 1997 23:04:57 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The system hung solid with no kernel messages or were you in X so > you couldn't see them? There is no guarantee that driver messages > will make it into the log file if the SCSI bus is wedged. I wasn't > aware of any problems with SCB paging, so I'd be very interrested > in any information you can provide on this problem. In most cases, > BTW, SCB paging isn't a win unless you are also using tagged queuing > (option AHC_TAGENABLE). > > [Raul Zighelboim] MMM... I set options AHC_SCBPAGING_ENABLE on the kernel a few days ago, and the system hanged solid while running the 'bytebench' benchmark. Removed the option, and run bytebench clean: This under 2.2.2-RELEASE with 2 AHC cards and some quantum viking drives: ahc0 rev 0 int a irq 9 on pci0:12 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle ahc0: target 0 Tagged Queuing Device (ahc0:0:0): "QUANTUM VIKING 4.5 WSE 8808" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4345MB (8899737 512 byte sectors) ahc1 rev 0 int a irq 10 on pci0:13 ahc1: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc1 waiting for scsi devices to settle ahc1: target 1 Tagged Queuing Device (ahc1:1:0): "QUANTUM VIKING 2.3 WSE 8808" type 0 fixed SCSI 2 sd4(ahc1:1:0): Direct-Access 2171MB (4446801 512 byte sectors) ahc1: target 2 Tagged Queuing Device (ahc1:2:0): "QUANTUM VIKING 2.3 WSE 8808" type 0 fixed SCSI 2 sd5(ahc1:2:0): Direct-Access 2171MB (4446801 512 byte sectors) ahc1: target 3 Tagged Queuing Device (ahc1:3:0): "QUANTUM VIKING 2.3 WSE 8808" type 0 fixed SCSI 2 sd6(ahc1:3:0): Direct-Access 2171MB (4446801 512 byte sectors) ahc1: target 4 Tagged Queuing Device (ahc1:4:0): "QUANTUM VIKING 2.3 WSE 8808" type 0 fixed SCSI 2 sd7(ahc1:4:0): Direct-Access 2171MB (4446801 512 byte sectors) From owner-freebsd-scsi Tue Aug 19 21:08:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA26510 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 21:08:00 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA26503 for ; Tue, 19 Aug 1997 21:07:56 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id WAA09344; Tue, 19 Aug 1997 22:07:46 -0600 (MDT) Message-Id: <199708200407.WAA09344@pluto.plutotech.com> To: Raul Zighelboim cc: "'Justin T. Gibbs'" , Greg Lehey , FreeBSD SCSI Mailing List Subject: Re: Bus resets. Grrrr. In-reply-to: Your message of "Tue, 19 Aug 1997 23:04:57 CDT." Date: Tue, 19 Aug 1997 22:07:07 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> The system hung solid with no kernel messages or were you in X so >> you couldn't see them? There is no guarantee that driver messages >> will make it into the log file if the SCSI bus is wedged. I wasn't >> aware of any problems with SCB paging, so I'd be very interrested >> in any information you can provide on this problem. In most cases, >> BTW, SCB paging isn't a win unless you are also using tagged queuing >> (option AHC_TAGENABLE). >> >> > [Raul Zighelboim] MMM... I set options AHC_SCBPAGING_ENABLE on >the kernel a few days ago, and the system hanged solid while running the >'bytebench' benchmark. Removed the option, and run bytebench clean: > > This under 2.2.2-RELEASE with 2 AHC cards and some quantum >viking drives: 2.2.2-RELEASE doesn't have the latest aic7xxx driver. Try running 2.2-stable or current instead. I'll try to repro this tomorrow using bytebech tomorrow as well. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Tue Aug 19 22:15:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA29710 for freebsd-scsi-outgoing; Tue, 19 Aug 1997 22:15:37 -0700 (PDT) Received: from nico.telstra.net (nico.telstra.net [139.130.204.16]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA29705 for ; Tue, 19 Aug 1997 22:15:33 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by nico.telstra.net (8.6.10/8.6.10) with ESMTP id PAA02566; Wed, 20 Aug 1997 15:14:23 +1000 Received: (grog@localhost) by freebie.lemis.com (8.8.7/8.6.12) id OAA00374; Wed, 20 Aug 1997 14:44:15 +0930 (CST) Message-ID: <19970820144413.04972@lemis.com> Date: Wed, 20 Aug 1997 14:44:13 +0930 From: Greg Lehey To: "Justin T. Gibbs" Cc: FreeBSD SCSI Mailing List Subject: Re: Bus resets. Grrrr. References: <19970820090810.54774@lemis.com> <199708200320.VAA08483@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <199708200320.VAA08483@pluto.plutotech.com>; from Justin T. Gibbs on Tue, Aug 19, 1997 at 09:19:59PM -0600 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, Aug 19, 1997 at 09:19:59PM -0600, Justin T. Gibbs wrote: >> On Tue, Aug 19, 1997 at 10:53:54AM -0600, Justin T. Gibbs wrote: >>>>> What version of the kernel are you using >>>> >>>> Recent versions of -current. The ones I reported it against were some >>>> time last week. I've just rebuilt with a version supped this morning. >>> >>> And it is still reproducible? >> >> I changed the configuration file and added (inter alia) >> AHC_SCBPAGING_ENABLE. The resultant kernel hung solid three times in >> the course of a couple of hours, once with a disk activity light on >> solid, and the other two without. I removed AHC_SCBPAGING_ENABLE, and >> last night the backup went through for the first time in a week. It >> ran fine until last Wednesday, however, so this could be a >> coincidence. > > The system hung solid with no kernel messages or were you in X so > you couldn't see them? That's right. > There is no guarantee that driver messages will make it into the log > file if the SCSI bus is wedged. Well, in this case the system disk is IDE, so I could put /var there and try again (currently, I note, it's on /dev/sd1h). > I wasn't aware of any problems with SCB paging, so I'd be very > interrested in any information you can provide on this problem. In > most cases, BTW, SCB paging isn't a win unless you are also using > tagged queuing (option AHC_TAGENABLE). Well, it looks like that wasn't the problem. It has happened again, and I wasn't able to get a dump (despite the kernel debugger; I must investigate why), so I don't suppose it was that option after all. >> No, at the moment the chain only has four devices connected, but I >> notice it finds two LUNs for the tape changer: > > Ahh. I thought you said you had a 2940A, not a 2940. Oops. So I did. I thought it was one. > This pretty much rules out the QOUTFIFO overflow problem (assuming > you are not using tagged queueing, which your dmesg output seems to > confirm) since the aic7870 has 16 slots meaning 9 active devices > would be necessary. OK. >> ahc0: rev 0x03 int a irq 12 on pci0.18.0 >> ahc0: aic7870 Single Channel, SCSI Id=7, 16 SCBs >> ahc0: waiting for scsi devices to settle >> scbus0 at ahc0 bus 0 >> scbus0 target 0 lun 0: type 0 fixed SCSI 2 >> sd0 at scbus0 target 0 lun 0 >> sd0: Direct-Access 1001MB (2051615 512 byte sectors) >> sd0: with 1760 cyls, 15 heads, and an average 77 sectors/track > > It looks like there is newer firmware available for this drive from > Micropolis: > > ftp://techsupport.micropolis.com/pub/files/firmware/Aquaris/2105-2108-2112/4930010f.bin > ftp://techsupport.micropolis.com/pub/files/Utils/ASPIUTIL.EXE OK, I'll take a look. >>> Could it be that you don't have disconnections enabled for your tape drive? >>> You should check both SCSI-Select for the 2940 and any relevant jumpers >>> on the tape drive itself. If disconnections are disabled, a tape write that >>> required multiple retries could easily tie up the SCSI bus for the 10s >>> needed to make a disk command time out. >> >> You'd see that on the activity light, right? In any case, the host >> adapter is set correctly, and the tape doesn't seem to have any such >> config switch. Would there be another way to test that? > > Not really. Since the timeout was "while idle", chances are that > disconnection is enabled and working. Yes, that's reasonable. >>> The first one probably fails because the device isn't ready. >> >> That's what I thought, too, so I put a sleep 30 into the script. It >> still works the second time. > > Then it probably fails because there is a unit attention that needs to > be cleared. The console error message would be enough to determine > what is really happening. OK, I'll try to capture it next time. Greg From owner-freebsd-scsi Wed Aug 20 00:32:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA05780 for freebsd-scsi-outgoing; Wed, 20 Aug 1997 00:32:38 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA05765 for ; Wed, 20 Aug 1997 00:32:34 -0700 (PDT) Received: (qmail 5011 invoked by uid 1000); 20 Aug 1997 07:32:51 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <9708180218.AA19946@mail.kcwc.com> Date: Wed, 20 Aug 1997 00:32:51 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: (Curt Welch) Subject: Re: expected performance with DPT RAID-5... Cc: scsi@FreeBSD.ORG, Tom Samplonius Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Curt Welch; On 18-Aug-97 you wrote: > Tom wrote: > > If I have 5 Barracuda 4LP 4GB drive (about 8MB/s raw > > read/write) on a single ultra wide channel on a DPT > > PM334/UW setup in a RAID-5 array, what kind of > > sequentional read/write performance should I expect? About 8-9MB/Sec on READ, 5-6 on write. Raid-5 is NOT optimal for sequential access and WRITE performance degrades with number of stripes. > Don't know what to expect, but I have a similar config. > > I have 5 Quantaum Atlas I 4G (fast wide) drives in a RAID-5 > config on one bus of of PM3334UW/2 and 5 Quantum Viking 4.55G > (ultra wide) also in a RAID-5 config on the other bus. The > system is a 180MHz Pentium Pro with 128MB of memory. The > DPT has a full 64MB of cache (non ecc). > > If you want me to run a test and tell you how it performs > I will. What type of test would you like to see? > > BTW, the system still crashes every few days. Don't know > for sure if it's probelms with the system, the DPT or the > DPT driver - I'm still working on it. It was very stable > before installing the DPT and the 10 new drives. Are you still having problems? What type? Simon From owner-freebsd-scsi Wed Aug 20 00:32:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA05789 for freebsd-scsi-outgoing; Wed, 20 Aug 1997 00:32:41 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA05766 for ; Wed, 20 Aug 1997 00:32:34 -0700 (PDT) Received: (qmail 5013 invoked by uid 1000); 20 Aug 1997 07:32:51 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 20 Aug 1997 00:32:51 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Tom Samplonius Subject: Re: expected performance with DPT RAID-5... Cc: scsi@FreeBSD.ORG, Curt Welch Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Tom Samplonius; On 18-Aug-97 you wrote: ... > "cd" to one of the RAID-5 file systems and do a "dd if=/dev/zero > of=testfile bs=64k count=1000". That will create a file called > "testfile" > 64MB in length (64k x 1000), and tell you how long it took to write it. > > Then reboot (the only way I know of clearing the FreeBSD file cache, > and > the DPT cache), and do a "dd if=testfile bs=64k of=/dev/null" to read the > file back. If you unmount the filesystems and make sure no other process has any of the device open, the caches will be flushed. The O/S must do so in case of removable media. The DPT firmware flushes caches in response to ALLOW MEDIA REMOVAL which is issued by sd.c in response to a close call. > On the write test I get about 3500000 bps, and the write test about > 9200000 bps. These results don't seem very good too me. For a RAID-5? Your WRITE is a bit (40%?) slow. READ is about right. Remember, these are sequential tests. You may want to adjust the read-ahead cache if this is your typical load (some people enjoy transferring many zeros from and to the disk :-). If you want a random test, pick up form my system st.c. It will do random seeks and either read, write, or read-modify-write and tell you how badly the system behaves. An interesting variation is to run, say 256 dd's and 1024 st's. Then measure throughput for a given stream. While (or soon after) the test is run do: (cd /dev;./MAKEDEV dpt0) echo -n "dump softc" > /dev/dpt0 get_dpt /dev/dpt0 Then look at the output. Yes, I will write a manpage and a front-end to this pair. Right now read the source in sys/dev/dpt/dpt_control.c Will answer many of your questions. Simon From owner-freebsd-scsi Wed Aug 20 00:32:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA05799 for freebsd-scsi-outgoing; Wed, 20 Aug 1997 00:32:42 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA05767 for ; Wed, 20 Aug 1997 00:32:34 -0700 (PDT) Received: (qmail 5018 invoked by uid 1000); 20 Aug 1997 07:32:51 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <9708190633.AA20893@mail.kcwc.com> Date: Wed, 20 Aug 1997 00:32:51 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: (Curt Welch) Subject: Re: expected performance with DPT RAID-5... Cc: scsi@FreeBSD.ORG, Tom Samplonius Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Curt Welch; On 19-Aug-97 you wrote: > Tom wrote: > > "cd" to one of the RAID-5 file systems and do a "dd > > if=/dev/zero of=testfile bs=64k count=1000". That will > > create a file called "testfile" 64MB in length (64k x > > 1000), and tell you how long it took to write it. > > > Then reboot (the only way I know of clearing the FreeBSD > > file cache, and the DPT cache), and do a "dd if=testfile > > bs=64k of=/dev/null" to read the file back. > > > On the write test I get about 3500000 bps, and the > > write test about 9200000 bps. These results don't seem > > very good too me. > > On bus 0 I have fast/wide drives but I currently have > the speed limited to 5Mhz (slow/wide?). > > On bus 1 I have ultra/wide drives and the bus is currently > limted to 5Mhz (trying to work out SCSI problems), but I > put it back to 20 Mhz for some of these tests. > > Numbers are all bytes per second (output from dd). > > On write, I see 1,800,000 on bus 0 at 5 Mhz > 2,500,000 on bus 1 at 20 Mhz. > 2,400,000 on bus 1 at 5 Mhz Read the original Berkeley papers on RAID-5 and then the DPT implementation notes. > > On read, I see 6,300,000 on bus 0 at 5 Mhz. > 5,400,000 on bus 1 at 5 Mhz. > > This is with 2.2.2-RELEASE and the DPT 1.1.10 driver with > the following options set: > > options DPT_USE_SINTR=1 > options DPT_MEASURE_PERFORMANCE > options DPT_TRACK_CCB_STATES ^ If you do not have crashes and other nasties, disable ths option. > options DPT_HANDLE_TIMEOUTS > options DPT_COMMAND_SPLHIGH > options DPT_INTR_CHECK_SOFTC Definitely disable this option. As a matter of fact, get 1.2.1 and test again. > > The ultra-wide drives are Quantum Vikings. I also have one > of these drives connected to an Adaptec 9240UW card in the > same system. Your test on that drive produces: > > On write, I see 8,400,000 on AHA at 20 Mhz > > read is about the same - but I don't want to reboot again to > do a "clean" no cache test. I suspect it would produce about > the same number however. > > This test: dd if=/dev/rsd1c bs=8k of=/dev/null count=10000 > > produces a rate of 9.3 MB/S on the AHA. > > On the DPT (bus 1 at 5Mhz), it produces a rate of 4.0 MB/S. > > I'm not over impressed with these numbers for the DPT, but > then I'm still dealing with unknown SCSI problems with this > set-up. You are comparing apples and oranges. RAID-5 is not RAID-0, nor is it a streight disk. There is no free lunch. Also, running the bus at 5MHz is not quite as fast as 20. Simon P.S. Let me try and help you with these problems. Call me if email is not the solution. 503.799.2313 PDT, my day starts at 1000 :-) Simon From owner-freebsd-scsi Wed Aug 20 01:08:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA07493 for freebsd-scsi-outgoing; Wed, 20 Aug 1997 01:08:16 -0700 (PDT) Received: from easynet.fr (qmailr@mail.easynet.fr [195.114.64.207]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA07484 for ; Wed, 20 Aug 1997 01:08:07 -0700 (PDT) Received: (qmail 20239 invoked from network); 20 Aug 1997 10:10:31 +0200 Received: from casimir.easynet.fr (195.114.64.17) by mail.easynet.fr with SMTP; 20 Aug 1997 10:10:31 +0200 Date: Wed, 20 Aug 1997 08:08:01 +0000 (GMT) From: David Ramahefason To: Simon Shapiro cc: curt@kcwc.com, scsi@FreeBSD.ORG, Tom Samplonius Subject: Re: expected performance with DPT RAID-5... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 20 Aug 1997, Simon Shapiro wrote: Hi, I'm really interested in RAID 5 solutions... Could you please tell me what you're using ... thanks /David Ramahefason Administrateur Systeme/Reseau/ /rama@easynet.fr Easynet France SA / /mobile: 0611647281 0144545333 / From owner-freebsd-scsi Thu Aug 21 01:51:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA08337 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 01:51:32 -0700 (PDT) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA08329 for ; Thu, 21 Aug 1997 01:51:27 -0700 (PDT) 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 SMTP id KAA19172 for ; Thu, 21 Aug 1997 10:51:22 +0200 Received: (from j@localhost) by ida.interface-business.de (8.8.7/8.7.3) id KAA01417; Thu, 21 Aug 1997 10:50:23 +0200 (MET DST) Message-ID: <19970821105023.LN03569@ida.interface-business.de> Date: Thu, 21 Aug 1997 10:50:23 +0200 From: j@ida.interface-business.de (J Wunsch) To: freebsd-scsi@freebsd.org Subject: No go X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Aug 21 03:15:29 ida /kernel: st0(ahc1:4:0): SCB 0x0 - timed out in command phase, SCSISIGI == 0x84 Aug 21 03:15:30 ida /kernel: SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 Aug 21 03:15:30 ida /kernel: st0(ahc1:4:0): abort message in message buffer Aug 21 03:15:30 ida /kernel: st0(ahc1:4:0): SCB 0x0 - timed out in command phase, SCSISIGI == 0x94 Aug 21 03:15:30 ida /kernel: SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x2 Aug 21 03:15:30 ida /kernel: ahc1: Issued Channel A Bus Reset. 1 SCBs aborted Aug 21 03:15:30 ida /kernel: Clearing bus reset Aug 21 03:15:30 ida /kernel: Clearing 'in-reset' flag Aug 21 03:15:30 ida /kernel: st0(ahc1:4:0): no longer in timeout Aug 21 03:15:31 ida /kernel: st0(ahc1:4:0): Target Busy Aug 21 03:15:33 ida last message repeated 22 times That's with a recent 2.2-stable system, during the nightly backup. The drive is a: Aug 21 08:27:58 ida /kernel: (ahc1:4:0): "ARCHIVE Python 28388-XXX 5.AC" type 1 removable SCSI 2 Aug 21 08:27:58 ida /kernel: st0(ahc1:4:0): Sequential-Access density code 0x13, 512-byte blocks, write-enabled The SCSI bus is only busy with the tape while this happens. There are only a CD-ROM and a CD-R drive (both duing nothing in the night hours) in addition to the tape. The disks are on another bus. Still, i have no idea whether to blame the tape drive, or the ahc driver. There were no problems previously with the HP-DAT drive. -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j From owner-freebsd-scsi Thu Aug 21 05:05:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA16102 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 05:05:14 -0700 (PDT) Received: from cenotaph.snafu.de (gw-deadnet.snafu.de [194.121.229.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id FAA16086 for ; Thu, 21 Aug 1997 05:05:05 -0700 (PDT) Received: by cenotaph.snafu.de from deadline.snafu.de using smtp id m0x1Vyx-00033DC; Thu, 21 Aug 1997 14:04:55 +0200 (CEST) (Smail-3.2 1996-Jul-4 #1) Received: by deadline.snafu.de id m0x1Vyx-000BmqC; Thu, 21 Aug 1997 14:04:55 +0200 (CEST) (Smail-3.2 1996-Jul-4 #1) Message-Id: Date: Thu, 21 Aug 1997 14:04:55 +0200 (CEST) Mime-Version: 1.0 X-Newsreader: knews 0.9.8 References: In-Reply-To: From: mickey@deadline.snafu.de (Andreas S. Wetzel) Subject: Re: newfs on Fujitsu R640 (2k sector media) X-Original-Newsgroups: lists.freebsd-scsi To: Andrew Reilly Cc: scsi@freebsd.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! --- In article , Andrew Reilly writes: > > I have a Fujitsu M2513A magneto-optical disk drive, and I've > been using it quite happily with R230 media (230M, 512-byte > sectors) for a while, because I was not confident that my > pre-release 2.2 FreeBSD would support non-512-byte sectors. > I have since upgraded to 2.2.2, and bought myself some R640 > disks (640M, 2048-byte sectors), and lo: it doesn't work. > > [...] > > What's bugging me at the moment is that I don't seem to be > able to disklabel or newfs one of the R640 disks. I just got my new Fujitsu 2513A6 drive with a 640 Mb media and had it running in less than an hour, using FreeBSD 3.0-current SMP as of 08/15/97. > I'm using this disktab entry, which I built out of the > numbers reported at boot time, but it's essentially the same > as the one that you get with disklabel -w -r auto: > > fuj640|R640|Fujitsu R640 media Meg 3.5inch Magneto-Optical:\ > :ty=removeable:dt=SCSI:rm#3600:\ > :se#2048:nt#64:ns#32:nc#151:sc#2048:su#310352:\ > :pa#310352:oa#0:ba#16384:fa#2048:ta=4.2BSD:\ > :pc#310352:oc#0: Obviously this disklabel is missing at least the number of tracks per cylinder (nt#XXX). So here is the disklabel I have constructed from the values given at boot time (number of sectors), and the information Fujitsu has online at their WWW pages: MO640|Fujitsu 2513A MO drive 640 Mb:\ :dt=SCSI:ty=removable:\ :nc#19397:ns#16:nt#1:\ :se#2048:rm#3600:\ :pa#310352:oa#0:ta=4.2BSD:ba#4096:fa#2048:\ :pc#310352:oc#0:\ :pd#310352:od#0: Labeling the drive using this disklabel works as well as a newfs onto the drive: # disklabel -w -r od0 MO640 # newfs -m 0 -o space -i 12288 -u 16 -t 1 -c 413 /dev/rod0a /dev/rod0a: 1241408 sectors in 19397 cylinders of 1 tracks, 64 sectors 606.2MB in 47 cyl groups (413 c/g, 12.91MB/g, 1088 i/g) super-block backups (for fsck -b #) at: 32, 26464, 52896, 79328, 105760, 132192, 158624, 185056, 211488, 237920, 264352, 290784, 317216, 343648, 370080, 396512, 422944, 449376, 475808, 502240, 528672, 555104, 581536, 607968, 634400, 660832, 687264, 713696, 740128, 766560, 792992, 819424, 845856, 872288, 898720, 925152, 951584, 978016, 1004448, 1030880, 1057312, 1083744, 1110176, 1136608, 1163040, 1189472, 1215904, # mount /dev/od0a /mnt # df -i Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mount /dev/od0a 613730 2 613728 0% 1 51133 0% /mnt Regards, Mickey -- (__) (@@) Andreas S. Wetzel Mail: mickey@deadline.snafu.de /-------\/ Utrechter Strasse 41 Web: http://cenotaph.snafu.de/ / | || 13347 Berlin Fon: <+4930> 456 066 90 * ||----|| Germany Fax: <+4930> 456 066 91/92 ~~ ~~ From owner-freebsd-scsi Thu Aug 21 06:34:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA20353 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 06:34:49 -0700 (PDT) Received: from birdland.rhein-neckar.de (root@birdland.rhein-neckar.de [193.197.88.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA20345; Thu, 21 Aug 1997 06:34:45 -0700 (PDT) Received: from localhost (bsd@localhost) by birdland.rhein-neckar.de (8.8.5/8.8.3) with SMTP id PAA22164; Thu, 21 Aug 1997 15:34:41 +0200 (MET DST) Date: Thu, 21 Aug 1997 15:34:41 +0200 (MET DST) From: Martin Jangowski To: questions@freebsd.org cc: scsi@freebsd.org Subject: Unable to install FBSD on HP Netserver LC Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! After running FBSD 2.1.x on our two HP Netserver LC for more than a year, I tried to upgrade them to 2.2.x. Initially, I had some problems with these machines, but got them to work with hints from this lists. In the FBSD Handbook, it is shown how to use the "eisa 12" command to get the onboard SCSI controller to work. The 2.1.6.1 kernel running for a year now was patched in the approbiate include file and was working flawlessly. To install 2.2-stable on our spare machine, I booted it with a 2.2.1-RELEASE CD in the drive. It came up, I booted with "boot: -c", selected the CLI editor, entered "eisa 12" and "quit" and it merrily started to boot the kernel. It recognized the controller ahc0: ahc0: on Eisa Slot 11 ... found the disks and other devices and continued to boot. However, after a few more lines it said: npx0: on Motherboard npx0: INT 16 interface apm0: disabled, not probed ahc0: Brkadrint, Illegal Host Access at seqaddr = 0x0 and hung. I tried to boot with a 2.2.2-RELEASE bootfloppy and got the same result... Any ideas how to get this machine up and running? Martin | Martin Jangowski E-Mail: maja@birdland.rhein-neckar.de | | Voice: +49 621/53 95 06 Fax: +49 621/53 95 07 | | Snail Mail: Koenigsbacher Str. 16 D-67067 Ludwigshafen Germany | | RNInet e.V. Rhein-Neckar Internet | From owner-freebsd-scsi Thu Aug 21 07:26:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA22967 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 07:26:49 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA22962 for ; Thu, 21 Aug 1997 07:26:47 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id AAA13070; Fri, 22 Aug 1997 00:23:50 +1000 Date: Fri, 22 Aug 1997 00:23:50 +1000 From: Bruce Evans Message-Id: <199708211423.AAA13070@godzilla.zeta.org.au> To: andrew@zeta.org.au, freebsd-scsi@FreeBSD.ORG Subject: Re: newfs on Fujitsu R640 (2k sector media) Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I have a Fujitsu M2513A magneto-optical disk drive, and I've >been using it quite happily with R230 media (230M, 512-byte >sectors) for a while, because I was not confident that my >pre-release 2.2 FreeBSD would support non-512-byte sectors. >I have since upgraded to 2.2.2, and bought myself some R640 >disks (640M, 2048-byte sectors), and lo: it doesn't work. I don't think it will work in any version of 2.2. (Only) -current has some hacks to support non-512-byte sectors. ># disklabel -e od0 >disklabel: ioctl DIOCGDINFO: Invalid argument > >Here's a question: where do I find a description of >DIOCGDINFO to figure out what this means? DIOCGDINFO just gets the in-core disk label. This is described with a moderate amount of detail in too many places (cd.4, matcd.4, mcd.4, od.4 and sd.4). It fails because there is no in-core disk label (drivers attempt to read the label using 512-byte sectors and this doesn't work for your disk). ># disklabel -r -w od0 R640 ># disklabel od0 >disklabel: ioctl DIOCGDINFO: Invalid argument ># disklabel -r od0 ># /dev/rod0c: >type: SCSI >disk: fuj640 >label: >flags: >bytes/sector: 2048 >sectors/track: 32 >tracks/cylinder: 64 >sectors/cylinder: 2048 >cylinders: 151 >sectors/unit: 310352 >rpm: 3600 >interleave: 1 >trackskew: 0 >cylinderskew: 0 >headswitch: 0 # milliseconds >track-to-track seek: 0 # milliseconds >drivedata: 0 > >3 partitions: ># size offset fstype [fsize bsize bps/cpg] > a: 310352 0 4.2BSD 2048 16384 0 # (Cyl. 0 - 151*) > c: 310352 0 unused 0 0 # (Cyl. 0 - 151*) > > >OK, that looks like it worked, but then: `disklabel -r ...' works because it bypasses the in-core label and writes 8K at a time. ># newfs od0a >newfs: /dev/rod0a: Invalid argument Newfs fails because it uses the in-core label. ># newfs od0c >newfs: ioctl (GDINFO): Invalid argument >newfs: /dev/rod0c: can't read disk label; disk type must be specified > ># newfs -T R640 od0c >write error: 310351. Tried 2048, wrote -1. >wtfs: Invalid argument Something like this might work for the 'c' partition only, because the 'c' partition can be accessed when there is no label (it has to be accessible so that the label can be written). The above error is probably caused by the last 3/4 of the disk not being accessible because the bounds checking routine assumes that sectors have size 512. Try using fake 512-byte sectors (`se#512', and sector counts 4 times as large as the actual counts). Bruce From owner-freebsd-scsi Thu Aug 21 07:46:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA24158 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 07:46:34 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA24151 for ; Thu, 21 Aug 1997 07:46:27 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id IAA16879; Thu, 21 Aug 1997 08:45:45 -0600 (MDT) Message-Id: <199708211445.IAA16879@pluto.plutotech.com> To: joerg_wunsch@interface-business.de (Joerg Wunsch) cc: freebsd-scsi@FreeBSD.ORG Subject: Re: No go In-reply-to: Your message of "Thu, 21 Aug 1997 10:50:23 +0200." <19970821105023.LN03569@ida.interface-business.de> Date: Thu, 21 Aug 1997 08:44:55 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Aug 21 03:15:29 ida /kernel: st0(ahc1:4:0): SCB 0x0 - timed out in command phase, SCSISIGI == 0x84 ^^^^^^^^^^^^^^^^ Figure out what command this is, and bump up it's timeout value. Do you have disconnection enabled??? Perhaps this is a command that the drive simply doesn't disconnect for. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Thu Aug 21 08:04:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA25129 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 08:04:12 -0700 (PDT) Received: from pluto.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA25107; Thu, 21 Aug 1997 08:04:05 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id JAA17441; Thu, 21 Aug 1997 09:03:14 -0600 (MDT) Message-Id: <199708211503.JAA17441@pluto.plutotech.com> To: Martin Jangowski cc: questions@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Unable to install FBSD on HP Netserver LC In-reply-to: Your message of "Thu, 21 Aug 1997 15:34:41 +0200." Date: Thu, 21 Aug 1997 09:02:24 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >found the disks and other devices and continued to boot. However, after a >few more lines it said: > >npx0: on Motherboard >npx0: INT 16 interface >apm0: disabled, not probed >ahc0: Brkadrint, Illegal Host Access at seqaddr = 0x0 Disable the uha device in userconfig. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Thu Aug 21 08:46:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA28784 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 08:46:54 -0700 (PDT) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA28740 for ; Thu, 21 Aug 1997 08:46:25 -0700 (PDT) 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 SMTP id RAA20491; Thu, 21 Aug 1997 17:44:36 +0200 Received: (from j@localhost) by ida.interface-business.de (8.8.7/8.7.3) id RAA04627; Thu, 21 Aug 1997 17:43:54 +0200 (MET DST) Message-ID: <19970821174354.EH52736@ida.interface-business.de> Date: Thu, 21 Aug 1997 17:43:54 +0200 From: j@ida.interface-business.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Cc: gibbs@plutotech.com (Justin T. Gibbs) Subject: Re: No go References: <19970821105023.LN03569@ida.interface-business.de> <199708211445.IAA16879@pluto.plutotech.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Reply-To: joerg_wunsch@interface-business.de (Joerg Wunsch) In-Reply-To: <199708211445.IAA16879@pluto.plutotech.com>; from Justin T. Gibbs on Aug 21, 1997 08:44:55 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Justin T. Gibbs wrote: > >Aug 21 03:15:29 ida /kernel: st0(ahc1:4:0): SCB 0x0 - timed out > in command phase, SCSISIGI == 0x84 > ^^^^^^^^^^^^^^^^ > > Figure out what command this is, and bump up it's timeout value. Do you Since it happens inmidst a tape backup operation, one would assume it's a WRITE. The current timeout is 100 seconds. That ought to be enough one would think, but i can bump the value. The odd thing is that one out of perhaps a million commands crashes. IMHO, different commands are only issued at open/close time. > have disconnection enabled??? I think so, but i gotta reboot to look. > Perhaps this is a command that the drive > simply doesn't disconnect for. This would be surprising. -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j From owner-freebsd-scsi Thu Aug 21 12:16:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA13326 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 12:16:17 -0700 (PDT) Received: from povray.cdrom.com (root@povray.cdrom.com [204.216.27.14]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA13321 for ; Thu, 21 Aug 1997 12:16:15 -0700 (PDT) Received: from cons.org (knight.cons.org [194.233.237.86]) by povray.cdrom.com (8.8.6/8.6.6) with ESMTP id MAA15984 for ; Thu, 21 Aug 1997 12:16:02 -0700 (PDT) Received: (from cracauer@localhost) by cons.org (8.8.5/8.7.3) id VAA05817; Thu, 21 Aug 1997 21:16:44 +0200 (CEST) Date: Thu, 21 Aug 1997 21:16:44 +0200 (CEST) Message-Id: <199708211916.VAA05817@cons.org> From: Martin Cracauer To: freebsd-scsi@freebsd.org Subject: Formatting DISK 256 bytes/sec => 512b/sec Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Moinmoin, I have a SCSI disk currently formatted at 256Bytes/sector. I can't change this to 512 bytes/sector, because a) scsi(8) refuses to work with it at all b) I tried 'scsiformat -p d -w', and it formatted without error message. However, the disk was still 256 Bytes/sec afterwards. Running 'scsiformat -p d' shows that the default configuration is in fact 512 bytes/sector and only the user-setable one is 256 bytes/sector. It looks to me scsiformat ignores '-p d' or is otherwise uncapable of doing this. Maybe I have to set the user-settable mode sense page to what I want first? If so, how, if scsi(8) refuses to work with the disk? Could someone tell me how to escape here? Is there somethis I could check about scsiformat to actually use the manufacturer's defaudlts, or can I make scsi(8) make work with this disk? Thanks for any help Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer cracauer@wavehh.hanse.de (batched, preferred for large mails) Tel.: (daytime) +4940 41478712 Fax.: (daytime) +4940 41478715 Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany From owner-freebsd-scsi Thu Aug 21 16:00:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA25517 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 16:00:36 -0700 (PDT) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA25510 for ; Thu, 21 Aug 1997 16:00:31 -0700 (PDT) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id SAA14579; Thu, 21 Aug 1997 18:13:50 -0400 (EDT) From: Peter Dufault Message-Id: <199708212213.SAA14579@hda.hda.com> Subject: Re: Formatting DISK 256 bytes/sec => 512b/sec In-Reply-To: <199708211916.VAA05817@cons.org> from Martin Cracauer at "Aug 21, 97 09:16:44 pm" To: cracauer@cons.org (Martin Cracauer) Date: Thu, 21 Aug 1997 18:13:49 -0400 (EDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I can't change this to 512 bytes/sector, because > a) scsi(8) refuses to work with it at all Are you using the control (.ctl) device? Modulo bugs it will bypass all checks and submit commands directly to the disk. If you're not using that try again and get back. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval From owner-freebsd-scsi Thu Aug 21 16:28:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA29338 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 16:28:25 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA29305 for ; Thu, 21 Aug 1997 16:28:17 -0700 (PDT) Received: from gurney.reilly.home (d30.syd2.zeta.org.au [203.26.11.30]) by godzilla.zeta.org.au (8.8.5/8.6.9) with ESMTP id JAA29949; Fri, 22 Aug 1997 09:23:23 +1000 Received: from gurney.reilly.home (localhost [127.0.0.1]) by gurney.reilly.home (8.8.5/8.8.5) with ESMTP id JAA26043; Fri, 22 Aug 1997 09:18:10 +1000 (EST) Message-Id: <199708212318.JAA26043@gurney.reilly.home> Date: Fri, 22 Aug 1997 09:18:08 +1000 (EST) From: Andrew Reilly Subject: Re: newfs on Fujitsu R640 (2k sector media) To: bde@zeta.org.au cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <199708211423.AAA13070@godzilla.zeta.org.au> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 22 Aug, Bruce Evans wrote: > I don't think it will work in any version of 2.2. (Only) > -current has some hacks to support non-512-byte sectors. Darn. Given all of the recent exhortations to the unwashed not to muck about with -current unless they were actively doing development, I'm loath to do that upgrade. Is there any chance of the relevant changes filtering back into 2.2? (I'm about to try tracking that, with CTM. Do you know whether the source from the 2.2.2 distribution corresponds to the last 30+M CTM level 0 update? Guess I'm about to find out.) > DIOCGDINFO [...] fails because there is no in-core disk label (drivers > attempt to read the label using 512-byte sectors and this doesn't work > for your disk). Thanks for that explanation. All is clear now. > `disklabel -r ...' works because it bypasses the in-core label and > writes 8K at a time. Ah. > Something like this might work for the 'c' partition only, because the > 'c' partition can be accessed when there is no label (it has to be accessible > so that the label can be written). The above error is probably caused by > the last 3/4 of the disk not being accessible because the bounds checking > routine assumes that sectors have size 512. Try using fake 512-byte > sectors (`se#512', and sector counts 4 times as large as the actual counts). Won't this be foiled when newfs attempts to write the last sector, to verify that it can, and uses a 512-byte write? I think I'll try tar'ing to the raw device for now. -- Andrew "The steady state of disks is full." -- Ken Thompson From owner-freebsd-scsi Thu Aug 21 16:31:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA29824 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 16:31:05 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA29806 for ; Thu, 21 Aug 1997 16:30:59 -0700 (PDT) Received: from gurney.reilly.home (d30.syd2.zeta.org.au [203.26.11.30]) by godzilla.zeta.org.au (8.8.5/8.6.9) with ESMTP id JAA30029; Fri, 22 Aug 1997 09:26:15 +1000 Received: from gurney.reilly.home (localhost [127.0.0.1]) by gurney.reilly.home (8.8.5/8.8.5) with ESMTP id JAA26191; Fri, 22 Aug 1997 09:26:00 +1000 (EST) Message-Id: <199708212326.JAA26191@gurney.reilly.home> Date: Fri, 22 Aug 1997 09:25:58 +1000 (EST) From: Andrew Reilly Subject: Re: newfs on Fujitsu R640 (2k sector media) To: mickey@deadline.snafu.de cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 21 Aug, Andreas S. Wetzel wrote: > I just got my new Fujitsu 2513A6 drive with a 640 Mb media and had it > running in less than an hour, using FreeBSD 3.0-current SMP as of 08/15/97. Bruce Evans has also suggested that 3.0-current would be needed. Good to hear that it works, though. Incidentally, what is the significance of the 6 after the 2513A model number? I don't think my drive had one of those. >> I'm using this disktab entry, which I built out of the >> numbers reported at boot time, but it's essentially the same >> as the one that you get with disklabel -w -r auto: >> >> fuj640|R640|Fujitsu R640 media Meg 3.5inch Magneto-Optical:\ >> :ty=removeable:dt=SCSI:rm#3600:\ >> :se#2048:nt#64:ns#32:nc#151:sc#2048:su#310352:\ >> :pa#310352:oa#0:ba#16384:fa#2048:ta=4.2BSD:\ >> :pc#310352:oc#0: > > Obviously this disklabel is missing at least the number of tracks per > cylinder (nt#XXX). No it isn't, nt# is on the third line, just after se#. The geometry is obviously ficticious, but I went with this (which was reported by the drive) because I read that the number of cylinders affected the number of super-block copies, and I didn't want to waste too much space on those. The capacity works out the same. Did I err? > So here is the disklabel I have constructed from > the values given at boot time (number of sectors), and the information > Fujitsu has online at their WWW pages: > > MO640|Fujitsu 2513A MO drive 640 Mb:\ > :dt=SCSI:ty=removable:\ > :nc#19397:ns#16:nt#1:\ > :se#2048:rm#3600:\ > :pa#310352:oa#0:ta=4.2BSD:ba#4096:fa#2048:\ > :pc#310352:oc#0:\ > :pd#310352:od#0: > > Labeling the drive using this disklabel works as well as a newfs onto > the drive: > > # disklabel -w -r od0 MO640 > # newfs -m 0 -o space -i 12288 -u 16 -t 1 -c 413 /dev/rod0a > /dev/rod0a: 1241408 sectors in 19397 cylinders of 1 tracks, 64 sectors > 606.2MB in 47 cyl groups (413 c/g, 12.91MB/g, 1088 i/g) > super-block backups (for fsck -b #) at: > 32, 26464, 52896, 79328, 105760, 132192, 158624, 185056, 211488, 237920, > 264352, 290784, 317216, 343648, 370080, 396512, 422944, 449376, 475808, > 502240, 528672, 555104, 581536, 607968, 634400, 660832, 687264, 713696, > 740128, 766560, 792992, 819424, 845856, 872288, 898720, 925152, 951584, > 978016, 1004448, 1030880, 1057312, 1083744, 1110176, 1136608, 1163040, > 1189472, 1215904, Many super-block backups. Are they nececssary? What is the significance of having so many? Do meta-data operations have to update all of them? > # mount /dev/od0a /mnt > # df -i > Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mount > /dev/od0a 613730 2 613728 0% 1 51133 0% /mnt Lovely to behold. Now to figure out how to get there from here. -- Andrew "The steady state of disks is full." -- Ken Thompson From owner-freebsd-scsi Thu Aug 21 17:51:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA04623 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 17:51:28 -0700 (PDT) Received: from cenotaph.snafu.de (gw-deadnet.snafu.de [194.121.229.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA04610 for ; Thu, 21 Aug 1997 17:51:03 -0700 (PDT) Received: by cenotaph.snafu.de from deadline.snafu.de using smtp id m0x1hw3-00035AC; Fri, 22 Aug 1997 02:50:43 +0200 (CEST) (Smail-3.2 1996-Jul-4 #1) Received: by deadline.snafu.de id m0x1hw2-000Bn9C; Fri, 22 Aug 1997 02:50:42 +0200 (CEST) (Smail-3.2 1996-Jul-4 #1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: Re: newfs on Fujitsu R640 (2k sector media) To: andrew@zeta.org.au (Andrew Reilly) Date: Fri, 22 Aug 1997 02:50:42 +0200 (CEST) Cc: scsi@freebsd.org Reply-To: mickey@deadline.snafu.de In-Reply-To: <199708212326.JAA26191@gurney.reilly.home> from Andrew Reilly at "Aug 22, 97 09:25:58 am" Organization: A world stranger than you have ever imagined. X-Mailer: ELM [version 2.4ME+ PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! --- Andrew Reilly writes: ] On 21 Aug, Andreas S. Wetzel wrote: ] > I just got my new Fujitsu 2513A6 drive with a 640 Mb media and had it ] > running in less than an hour, using FreeBSD 3.0-current SMP as of 08/15/97. ] ] Bruce Evans has also suggested that 3.0-current would be needed. Good ] to hear that it works, though. Incidentally, what is the significance ] of the 6 after the 2513A model number? I don't think my drive had one ] of those. AFAIK the 6 indicates that the drive has a 2 Mb cache. Drives with a 2 have 512k I think. Although I cannot say much about the cache, since I have not enabled it yet on the drive. The default setting is to disable the cache. Will check this real soon :-) ] >> I'm using this disktab entry, which I built out of the ] >> numbers reported at boot time, but it's essentially the same ] >> as the one that you get with disklabel -w -r auto: ] >> ] >> fuj640|R640|Fujitsu R640 media Meg 3.5inch Magneto-Optical:\ ] >> :ty=removeable:dt=SCSI:rm#3600:\ ] >> :se#2048:nt#64:ns#32:nc#151:sc#2048:su#310352:\ ] >> :pa#310352:oa#0:ba#16384:fa#2048:ta=4.2BSD:\ ] >> :pc#310352:oc#0: ] > ] > Obviously this disklabel is missing at least the number of tracks per ] > cylinder (nt#XXX). ] ] No it isn't, nt# is on the third line, just after se#. The geometry is ] obviously ficticious, but I went with this (which was reported by the ] drive) because I read that the number of cylinders affected the number ] of super-block copies, and I didn't want to waste too much space on ] those. The capacity works out the same. Did I err? Sure the capacity is in all cases 310352 x 2048 byte sectors. I think the number of super block backups is dependent from the number of cylinders per cylinder group. This is an option you can supply to the newfs command, so I think it isn't that important in the disklabel. But the maximum number of cylinders per group is affected by the blocksize and possibly some other parameters. Not quite sure about this, I used to choose the maximum value that newfs will suggest. A look at a similar disktab entry for a sony drive (should be contained in /usr/src/etc/etc.i386/disktab in 3.0-current) does also have nt#1, although the number of sectors seems to be different for this drive/entry, and hence, the drive does only physically use one surface :-) ] > [...] ] > ] > # disklabel -w -r od0 MO640 ] > # newfs -m 0 -o space -i 12288 -u 16 -t 1 -c 413 /dev/rod0a ] > /dev/rod0a: 1241408 sectors in 19397 cylinders of 1 tracks, 64 sectors ] > 606.2MB in 47 cyl groups (413 c/g, 12.91MB/g, 1088 i/g) ] > super-block backups (for fsck -b #) at: ] > 32, 26464, 52896, 79328, 105760, 132192, 158624, 185056, 211488, 237920, ] > 264352, 290784, 317216, 343648, 370080, 396512, 422944, 449376, 475808, ] > 502240, 528672, 555104, 581536, 607968, 634400, 660832, 687264, 713696, ] > 740128, 766560, 792992, 819424, 845856, 872288, 898720, 925152, 951584, ] > 978016, 1004448, 1030880, 1057312, 1083744, 1110176, 1136608, 1163040, ] > 1189472, 1215904, ] ] Many super-block backups. Are they nececssary? What is the ] significance of having so many? Do meta-data operations have to update ] all of them? I'm not quite sure if there is a real need for so much superblock backups, and I haven't been involved in filesystem tuning that much until now. I try to keep the number low by having as much cylinders per group as newfs permits, in this case it computed it to be 413 and I think 47 super-block backups is not that much for a 640 Mb media. ] > # mount /dev/od0a /mnt ] > # df -i ] > Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mount ] > /dev/od0a 613730 2 613728 0% 1 51133 0% /mnt ] ] Lovely to behold. Yes indeed. BTW: Did you manage to boot off your MO-drive? Regards, Mickey -- (__) (@@) Andreas S. Wetzel Mail: mickey@deadline.snafu.de /-------\/ Utrechter Strasse 41 Web: http://cenotaph.snafu.de/ / | || 13347 Berlin Fon: <+4930> 456 066 90 * ||----|| Germany Fax: <+4930> 456 066 91/92 ~~ ~~ From owner-freebsd-scsi Thu Aug 21 23:25:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA19209 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 23:25:13 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA19200 for ; Thu, 21 Aug 1997 23:25:10 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA27904; Fri, 22 Aug 1997 08:25:07 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA04788; Fri, 22 Aug 1997 08:09:05 +0200 (MET DST) Message-ID: <19970822080905.GV40553@uriah.heep.sax.de> Date: Fri, 22 Aug 1997 08:09:05 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Cc: andrew@zeta.org.au (Andrew Reilly) Subject: Re: newfs on Fujitsu R640 (2k sector media) References: <199708211423.AAA13070@godzilla.zeta.org.au> <199708212318.JAA26043@gurney.reilly.home> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Andrew Reilly wrote: > > I don't think it will work in any version of 2.2. (Only) > > -current has some hacks to support non-512-byte sectors. > > Darn. Given all of the recent exhortations to the unwashed not to muck > about with -current unless they were actively doing development, I'm > loath to do that upgrade. Is there any chance of the relevant changes > filtering back into 2.2? No. They are messy enough to have them in -current, but that's nothing one would love to see migrating into a branch marketed as `-stable'. Did we really ever announce them as an `officially available' feature? Hard to believe. > Won't this be foiled when newfs attempts to write the last sector, to > verify that it can, and uses a 512-byte write? Newfs doesn't write to a last sector to verify something. That's not a PC BIOS... Newfs just creates the required filesystem structures only. -- 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 Thu Aug 21 23:51:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA20764 for freebsd-scsi-outgoing; Thu, 21 Aug 1997 23:51:36 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA20743 for ; Thu, 21 Aug 1997 23:51:29 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA28082; Fri, 22 Aug 1997 08:51:23 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA04872; Fri, 22 Aug 1997 08:24:20 +0200 (MET DST) Message-ID: <19970822082420.JF08302@uriah.heep.sax.de> Date: Fri, 22 Aug 1997 08:24:20 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Cc: cracauer@cons.org (Martin Cracauer) Subject: Re: Formatting DISK 256 bytes/sec => 512b/sec References: <199708211916.VAA05817@cons.org> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199708211916.VAA05817@cons.org>; from Martin Cracauer on Aug 21, 1997 21:16:44 +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Martin Cracauer wrote: > b) I tried 'scsiformat -p d -w', and it formatted without error > message. However, the disk was still 256 Bytes/sec afterwards. You're miscomprehending the -p d option. It doesn't promise you to cause some kind of `default' formatting. The entire informational display in scsiformat(8) is fairly crude, it has only been inherited from the (defunct) 4.4BSD scsiformat(8) code. Our scsi(8) is a much better tool for this. > Running 'scsiformat -p d' shows that the default configuration is in > fact 512 bytes/sector and only the user-setable one is 256 > bytes/sector. No, that's just the block size from the block descriptor in a mode sense command. It isn't necessarily related to the physical sector size of the drive, it's just the granularity you're using in transfers to the device on the bus. There are at least two methods i remember how to convince a SCSI drive of another sector size (if possible at all). One was to issue a mode select with a new blocksize, and then immediately format the drive. I think that's been the IBM way. I think the other way was to edit mode page 3 (scsi -f /dev/rsdX.ctl -e -m 3 -P 3), and then reformat. ISTR that i've successfully did this with an older Maxtor drive (just to see whether it works). Of course, there's a third group of drives that have a fixed vendor format, and cannot be changed. I remember Quantum proudly claiming once that their drives cannot be reformatted. -- 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 Aug 22 00:35:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA23035 for freebsd-scsi-outgoing; Fri, 22 Aug 1997 00:35:41 -0700 (PDT) Received: from nico.telstra.net (nico.telstra.net [139.130.204.16]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA23029 for ; Fri, 22 Aug 1997 00:35:37 -0700 (PDT) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by nico.telstra.net (8.6.10/8.6.10) with ESMTP id RAA03654; Fri, 22 Aug 1997 17:34:59 +1000 Received: (grog@localhost) by freebie.lemis.com (8.8.7/8.6.12) id RAA26740; Fri, 22 Aug 1997 17:04:58 +0930 (CST) Message-ID: <19970822170457.50741@lemis.com> Date: Fri, 22 Aug 1997 17:04:57 +0930 From: Greg Lehey To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG, Martin Cracauer Subject: Re: Formatting DISK 256 bytes/sec => 512b/sec References: <199708211916.VAA05817@cons.org> <19970822082420.JF08302@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81e In-Reply-To: <19970822082420.JF08302@uriah.heep.sax.de>; from J Wunsch on Fri, Aug 22, 1997 at 08:24:20AM +0200 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8250 Fax: +61-8-8388-8250 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, Aug 22, 1997 at 08:24:20AM +0200, J Wunsch wrote: > > There are at least two methods i remember how to convince a SCSI drive > of another sector size (if possible at all). One was to issue a mode > select with a new blocksize, and then immediately format the drive. I > think that's been the IBM way. I think the other way was to edit mode > page 3 (scsi -f /dev/rsdX.ctl -e -m 3 -P 3), and then reformat. ISTR > that i've successfully did this with an older Maxtor drive (just to > see whether it works). I've done this before, with Tandem drives which were originally formatted with 516 bytes/sector. I think I edited mode page 3. If you have any trouble with this method, let me know and I'll try to drag out the info I had at the time. Greg From owner-freebsd-scsi Fri Aug 22 04:48:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA03869 for freebsd-scsi-outgoing; Fri, 22 Aug 1997 04:48:33 -0700 (PDT) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA03862 for ; Fri, 22 Aug 1997 04:48:25 -0700 (PDT) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id HAA16253 for scsi@freebsd.org; Fri, 22 Aug 1997 07:01:52 -0400 (EDT) From: Peter Dufault Message-Id: <199708221101.HAA16253@hda.hda.com> Subject: Re: Formatting DISK 256 bytes/sec => 512b/sec In-Reply-To: <19970822170457.50741@lemis.com> from Greg Lehey at "Aug 22, 97 05:04:57 pm" To: scsi@freebsd.org Date: Fri, 22 Aug 1997 07:01:52 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've done this before, with Tandem drives which were originally > formatted with 516 bytes/sector. I think I edited mode page 3. If > you have any trouble with this method, let me know and I'll try to > drag out the info I had at the time. Yes, page 3 is the format device page. I think you should edit page 3 and then format. There is a way to specify the range of block numbers in the mode select header which isn't supported by the scsi(8) mode page editor. Maybe some drives will have trouble formatting to new sector sizes without adding a flag to specify block ranges. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval From owner-freebsd-scsi Fri Aug 22 08:30:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA14120 for freebsd-scsi-outgoing; Fri, 22 Aug 1997 08:30:55 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA14114 for ; Fri, 22 Aug 1997 08:30:50 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id BAA30318; Sat, 23 Aug 1997 01:28:25 +1000 Date: Sat, 23 Aug 1997 01:28:25 +1000 From: Bruce Evans Message-Id: <199708221528.BAA30318@godzilla.zeta.org.au> To: freebsd-scsi@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: newfs on Fujitsu R640 (2k sector media) Cc: andrew@zeta.org.au Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Won't this be foiled when newfs attempts to write the last sector, to >> verify that it can, and uses a 512-byte write? It should write in multiples of the fs block size or maybe the fragment size. If not, (ab)using the buffered device might work. >Newfs doesn't write to a last sector to verify something. That's not >a PC BIOS... Newfs just creates the required filesystem structures >only. Nope, UTSL, newfs/mkfs.c has full support for PC BIOSes ;-): /* * Validate the given file system size. * Verify that its last block can actually be accessed. */ if (fssize <= 0) printf("preposterous size %d\n", fssize), exit(13); wtfs(fssize - (realsectorsize / DEV_BSIZE), realsectorsize, (char *)&sblock); Bruce From owner-freebsd-scsi Fri Aug 22 12:52:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA28655 for freebsd-scsi-outgoing; Fri, 22 Aug 1997 12:52:00 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA28645 for ; Fri, 22 Aug 1997 12:51:55 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA06142 for freebsd-scsi@FreeBSD.ORG; Fri, 22 Aug 1997 21:51:49 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id VAA06463; Fri, 22 Aug 1997 21:36:33 +0200 (MET DST) Message-ID: <19970822213633.XF58346@uriah.heep.sax.de> Date: Fri, 22 Aug 1997 21:36:33 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Subject: Re: newfs on Fujitsu R640 (2k sector media) References: <199708221528.BAA30318@godzilla.zeta.org.au> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199708221528.BAA30318@godzilla.zeta.org.au>; from Bruce Evans on Aug 23, 1997 01:28:25 +1000 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > >Newfs doesn't write to a last sector to verify something. That's not > >a PC BIOS... Newfs just creates the required filesystem structures > >only. > > Nope, UTSL, newfs/mkfs.c has full support for PC BIOSes ;-): Pah! :-) -- 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 Sat Aug 23 06:28:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA12765 for freebsd-scsi-outgoing; Sat, 23 Aug 1997 06:28:52 -0700 (PDT) Received: from freebee.tu-graz.ac.at (root@freebee.tu-graz.ac.at [129.27.193.128]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id GAA12752 for ; Sat, 23 Aug 1997 06:28:44 -0700 (PDT) Received: from dwarf.tu-graz.ac.at (isdn122.tu-graz.ac.at [129.27.240.122]) by freebee.tu-graz.ac.at (8.6.11/8.6.9) with ESMTP id PAA06926; Sat, 23 Aug 1997 15:28:38 +0200 Received: from localhost (rmike@localhost) by dwarf.tu-graz.ac.at (8.8.5/8.7.3) with SMTP id PAA06299; Sat, 23 Aug 1997 15:37:52 +0200 (MET DST) X-Authentication-Warning: dwarf.tu-graz.ac.at: rmike owned process doing -bs Date: Sat, 23 Aug 1997 15:37:52 +0200 (MET DST) From: Michael Ranner X-Sender: rmike@dwarf.tu-graz.ac.at Reply-To: rmike@sbox.tu-graz.ac.at To: Ken Krebs cc: freebsd-scsi@freebsd.org Subject: Re: Adaptec 2920 SCSI Driver for FreeBSD In-Reply-To: Message-ID: Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 22 Aug 1997, Ken Krebs wrote: } I've seen some of your posts on UseNet referring to a 2920 drive } for FreeBSD. I was wondering if you could possibly tell me where to } get the sources? } } My fiancee and I both have Adaptec 2920 SCSI cards in our machines and we } JUST found out last night that they are not supported by FreeBSD :( You can find the AHA 2920 SCSI driver sources on: http://www.sbox.tu-graz.ac.at/home/rmike/freebsd/ ================================================= The core driver source is extracted from the BSD Nomads PAO package See http://www.jp.freebsd.org/PAO/ for more info. This tmc18c30 source is ported from NetBSD/PC98 to FreeBSD an uses the scsi_low source from (dont know exactly) NetBSD because the SCSI low level source is different to FreeBSD. You can find the e-mail from the auhtor who has ported this driver in the tmc18c30 source files. Be warned, the README in the tmc18c30 directory of PAO says its a BAD port (because of scsi_low etc.), but I use it for more than a half year, and I had no problems with it. Only the PCI-probe code and the attach code is written by me, the rest is exact the same source as contained in the PAO package. Maby someone likes to spend some time to make the driver better... /\/\ichael Ranner - rmike@sbox.tu-graz.ac.at http://www.sbox.tu-graz.ac.at/home/rmike/ Watch the clock on the wall, feel the slowing of time... . . . + . + . + . - - - - - ----* . . + . . . From owner-freebsd-scsi Sat Aug 23 07:51:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA17028 for freebsd-scsi-outgoing; Sat, 23 Aug 1997 07:51:38 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id HAA17010 for ; Sat, 23 Aug 1997 07:51:34 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id QAA18231; Sat, 23 Aug 1997 16:51:33 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id QAA12641; Sat, 23 Aug 1997 16:29:38 +0200 (MET DST) Message-ID: <19970823162938.GF47522@uriah.heep.sax.de> Date: Sat, 23 Aug 1997 16:29:38 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Cc: rmike@sbox.tu-graz.ac.at, kkrebs@best.net (Ken Krebs) Subject: Re: Adaptec 2920 SCSI Driver for FreeBSD References: X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Michael Ranner on Aug 23, 1997 15:37:52 +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Michael Ranner wrote: > You can find the AHA 2920 SCSI driver sources on: > > http://www.sbox.tu-graz.ac.at/home/rmike/freebsd/ > ================================================= > > The core driver source is extracted from the BSD Nomads PAO package > See http://www.jp.freebsd.org/PAO/ for more info. > > This tmc18c30 source is ported from NetBSD/PC98 to FreeBSD an uses the > scsi_low source from (dont know exactly) NetBSD because the SCSI low level > source is different to FreeBSD. Well, and this (sorry, Michael) is the reason why i've never committed it to the FreeBSD tree, although i have promised so to Michael. :( I'm fairly reluctant to import a second set of lower-level SCSI routines into FreeBSD which is basically performing the same function as we've already got elsewhere. So if somebody would rewrite the driver to use the FreeBSD bottom layer, this would be great. (OTOH, i assume Justin's current CAM work would make this obsolete as well, sigh.) Other than this, i can confirm that the driver is doing it fine, i've once been testing it. -- 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. ;-)