From owner-freebsd-scsi Sun Oct 12 00:50:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA05910 for freebsd-scsi-outgoing; Sun, 12 Oct 1997 00:50:37 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA05898 for ; Sun, 12 Oct 1997 00:50:27 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by innocence.interface-business.de (8.6.11/8.6.9) with UUCP id JAA16069 for scsi@FreeBSD.ORG; Sun, 12 Oct 1997 09:50:20 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id JAA02436; Sun, 12 Oct 1997 09:45:15 +0200 (MET DST) Message-ID: <19971012094515.RT52487@uriah.heep.sax.de> Date: Sun, 12 Oct 1997 09:45:15 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@FreeBSD.ORG Subject: Re: Trouble with dump on ncr References: <19971011091605.32335@mi.uni-koeln.de> <199710120615.AAA18578@pluto.plutotech.com> 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: <199710120615.AAA18578@pluto.plutotech.com>; from Kenneth Merry on Oct 12, 1997 00:15:56 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Kenneth Merry wrote: > FWIW, that's what the new CAM SCSI code does. The da (i.e. sd) > driver does a read capacity upon open. If the read capacity returns with > 0x04, 0x02 ("Logical unit not ready, initializing cmd. required"), the error > recovery code issues a start unit command to the drive. Hmm, why doing it at open time? Quite a number of people have been asking for a disk auto-spindown in the past (for filesystems that are seldom used). I'm using a crock of an auto-spindown in the od driver (the device is spun down at close time, and spun up at open time), but i think the more generic solution would be to trigger the spindown by a period of disc inactivity. Then, simply try the next command, and if the drive is not ready, attempt to start it, and retry. Back to the original question: i've looked into the existing code, and it seems to be not that simple to add a fallback scsi_start_unit() there once a command failed with NOT READY. The code is too twisted. Given that there's enough evidence that the existing scsi_start_unit() call in sd_open() didn't work at all, does anybody mind me simply removing this call? Sticking a START UNIT command into sd_attach() might perhaps make some sense, in case it's not spinning at boot or reconfigure time. > One interesting thing about that, though.. Apparantly not all > drives return 0x04,0x02 when they aren't spun up. I ran into some Quantum > Fireball ST (Stratus) drives that return 0x04,0x0b when they aren't spun > up. Strange, 'eh? That sense code qualifier isn't in the SCSI specs (not > even SCSI-3), and it isn't in Quantum's documentation on the drive. Quantum seems to be the Microsoft of the SCSI vendors. They are proud of this kind of crap. They have once been telling my colleague with much pride that they don't support customer disk formatting even for their SCSI drives (the colleague was asking for an IDE drive which he's accidentally dropped on the floor), but only fake it there by sitting for a couple of minutes upon receipt of a FORMAT UNIT command. One of the disks of sax.sax.de (a Quantum LPS540) recently logged a medium error, with a vendor-specific ASC (0xaa). Why the heck do they require a vendor-specific ASC if there are dozens of ASC/ASCQ pairs available already? I can understand the need for vendor-specific things for stuff like a CD-R, but not for a plain disk drive. I usually avoid Quantum like the plague. With a Seacrate drive, i know what i've got. It works, or it fails. If it fails, chances are good that i can repair it by reformatting, but i've been warned. With a Quantum, i'm at my own once something unforseeable happens. Speaking about opinions: apart from the weird behaviour with tagged commands, and a START UNIT command, does anybody have seen any complaints about the IBM drives so far? I'm pleasently surprised about the new drive i've got. It's got a good bang-per-buck ratio (maybe that's for being produced in Hungary?, so still cheap enough, but not too much customs fees?), is surprisingly fast for a 5400 rpm drive (8.5 MB dd(1) rate on the outer tracks), is fairly quiet, and stays really cool. -- 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 Sun Oct 12 01:39:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA08846 for freebsd-scsi-outgoing; Sun, 12 Oct 1997 01:39:03 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA08841 for ; Sun, 12 Oct 1997 01:39:00 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id BAA21725; Sun, 12 Oct 1997 01:36:18 -0700 (PDT) Message-ID: <19971012013618.36452@hydrogen.nike.efn.org> Date: Sun, 12 Oct 1997 01:36:18 -0700 From: John-Mark Gurney To: Joerg Wunsch Cc: scsi@FreeBSD.ORG Subject: Re: Trouble with dump on ncr References: <19971011091605.32335@mi.uni-koeln.de> <199710120615.AAA18578@pluto.plutotech.com> <19971012094515.RT52487@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19971012094515.RT52487@uriah.heep.sax.de>; from J Wunsch on Sun, Oct 12, 1997 at 09:45:15AM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch scribbled this message on Oct 12: > As Kenneth Merry wrote: > > > FWIW, that's what the new CAM SCSI code does. The da (i.e. sd) > > driver does a read capacity upon open. If the read capacity returns with > > 0x04, 0x02 ("Logical unit not ready, initializing cmd. required"), the error > > recovery code issues a start unit command to the drive. > > Hmm, why doing it at open time? Quite a number of people have been > asking for a disk auto-spindown in the past (for filesystems that are > seldom used). I'm using a crock of an auto-spindown in the od driver > (the device is spun down at close time, and spun up at open time), but > i think the more generic solution would be to trigger the spindown by > a period of disc inactivity. Then, simply try the next command, and > if the drive is not ready, attempt to start it, and retry. actually.. I'm about to get the CAM scsi code up and running on a test box of mine (ahc2842 w/ an IBM WDS-3200 !J S560)... and would VERY much like to have this hd auto spin down... right now it's open air and is quite loud... hmm... would a simple timeout that is rescheduled upon no remaining commands outstanding for the drive work? (I haven't looked at the CAM scsi code yet, so I don't know how this would work exactly) -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-scsi Sun Oct 12 02:33:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA11176 for freebsd-scsi-outgoing; Sun, 12 Oct 1997 02:33:33 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id CAA11109; Sun, 12 Oct 1997 02:32:24 -0700 (PDT) (envelope-from se@zpr.uni-koeln.de) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA02411 (5.67b/IDA-1.5); Sun, 12 Oct 1997 11:32:22 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id JAA00743; Sun, 12 Oct 1997 09:44:27 +0200 (CEST) X-Face: " Date: Sun, 12 Oct 1997 09:44:26 +0200 From: Stefan Esser To: Kenneth Merry Cc: scsi@FreeBSD.ORG, Stefan Esser Subject: Re: Trouble with dump on ncr References: <19971011091605.32335@mi.uni-koeln.de> <199710120615.AAA18578@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <199710120615.AAA18578@pluto.plutotech.com>; from Kenneth Merry on Sun, Oct 12, 1997 at 12:15:56AM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 1997-10-12 00:15 -0600, Kenneth Merry wrote: > > The start unit command should instead be issued from the > > recovery code in the generic SCSI layer, IMHO, whenever > > the return status from the SCSI card driver indicates a > > drive has (been) stopped in an attempt to recover from > > that situation. > > FWIW, that's what the new CAM SCSI code does. The da (i.e. sd) > driver does a read capacity upon open. If the read capacity returns with > 0x04, 0x02 ("Logical unit not ready, initializing cmd. required"), the error > recovery code issues a start unit command to the drive. I downloaded that code, but did not have time to look into it in detail. It is unfortunate, that many parts outside /sys have to me made aware of the CAM driver, IMHO. > One interesting thing about that, though.. Apparantly not all > drives return 0x04,0x02 when they aren't spun up. I ran into some Quantum > Fireball ST (Stratus) drives that return 0x04,0x0b when they aren't spun > up. Strange, 'eh? That sense code qualifier isn't in the SCSI specs (not > even SCSI-3), and it isn't in Quantum's documentation on the drive. Well, I guess it is save to just exclude those ASCQ values for ASC 0x04 that indicate a simple motor start command is not sufficient (0x04/0x03 surely does not ask for a START STOP UNIT command :) How about "issue a start unit command for ASC 0x04 and ASCQ equal 0x02 or greater-equal 0x09. Can't see how that could cause problems ... Regards, STefan From owner-freebsd-scsi Sun Oct 12 03:12:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA12441 for freebsd-scsi-outgoing; Sun, 12 Oct 1997 03:12:35 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA12391; Sun, 12 Oct 1997 03:11:18 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id DAA26167; Sun, 12 Oct 1997 03:11:16 -0700 (PDT) Message-ID: <19971012031116.19283@hydrogen.nike.efn.org> Date: Sun, 12 Oct 1997 03:11:16 -0700 From: John-Mark Gurney To: Stefan Esser Cc: scsi@FreeBSD.ORG Subject: Re: Trouble with dump on ncr References: <19971011091605.32335@mi.uni-koeln.de> <199710120615.AAA18578@pluto.plutotech.com> <19971012094426.47163@mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19971012094426.47163@mi.uni-koeln.de>; from Stefan Esser on Sun, Oct 12, 1997 at 09:44:26AM +0200 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Stefan Esser scribbled this message on Oct 12: > On 1997-10-12 00:15 -0600, Kenneth Merry wrote: > > > The start unit command should instead be issued from the > > > recovery code in the generic SCSI layer, IMHO, whenever > > > the return status from the SCSI card driver indicates a > > > drive has (been) stopped in an attempt to recover from > > > that situation. > > > > FWIW, that's what the new CAM SCSI code does. The da (i.e. sd) > > driver does a read capacity upon open. If the read capacity returns with > > 0x04, 0x02 ("Logical unit not ready, initializing cmd. required"), the error > > recovery code issues a start unit command to the drive. > > I downloaded that code, but did not have time > to look into it in detail. It is unfortunate, > that many parts outside /sys have to me made > aware of the CAM driver, IMHO. well.. right now I'm compiling a kernel, with the new CAM code, to boot one of my crash machines with.. the only really thing that needs to be changed is config and MAKEDEV.. the others I believe are just support files for interfacing with the code (libcam and include/Makefile)... if I remeber right, I just looked at the patches about 10-15 minutes ago.. :) ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-scsi Sun Oct 12 03:50:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA13802 for freebsd-scsi-outgoing; Sun, 12 Oct 1997 03:50:52 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA13790 for ; Sun, 12 Oct 1997 03:50:40 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by innocence.interface-business.de (8.6.11/8.6.9) with UUCP id MAA16693 for scsi@FreeBSD.ORG; Sun, 12 Oct 1997 12:50:36 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id MAA09594; Sun, 12 Oct 1997 12:29:11 +0200 (MET DST) Message-ID: <19971012122910.ZX36246@uriah.heep.sax.de> Date: Sun, 12 Oct 1997 12:29:10 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@FreeBSD.ORG Subject: Re: Trouble with dump on ncr References: <19971011091605.32335@mi.uni-koeln.de> <199710120615.AAA18578@pluto.plutotech.com> <19971012094426.47163@mi.uni-koeln.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: <19971012094426.47163@mi.uni-koeln.de>; from Stefan Esser on Oct 12, 1997 09:44:26 +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Stefan Esser wrote: > Well, I guess it is save to just exclude those > ASCQ values for ASC 0x04 that indicate a simple > motor start command is not sufficient (0x04/0x03 > surely does not ask for a START STOP UNIT command :) Hmm, but it can't hurt to attempt a START STOP UNIT for any NOT READY, as long as you: . make sure you'll abort after a number of failed retries for the original command, . make sure to immediately abort after getting a nested NOT READY. -- 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 Sun Oct 12 07:31:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA24074 for freebsd-scsi-outgoing; Sun, 12 Oct 1997 07:31:10 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from mail.ruhrgebiet.individual.net (in-ruhr.ruhr.de [141.39.224.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA24064 for ; Sun, 12 Oct 1997 07:31:03 -0700 (PDT) (envelope-from robsch@robkaos.ruhr.de) Received: from robkaos.ruhr.de (admin@localhost) by mail.ruhrgebiet.individual.net (8.8.5-r-beta/8.8.5) with UUCP id PAA01817 for freebsd.org!scsi; Sun, 12 Oct 1997 15:08:53 +0100 (MET) Received: by robkaos.ruhr.de (Smail-3.2 1996-Jul-4 #1) id ; Sun, 12 Oct 1997 16:07:35 +0200 (MET DST) Message-Id: From: robsch@robkaos.ruhr.de (Robert Schien) Subject: CD-RW support To: scsi@freebsd.org Date: Sun, 12 Oct 1997 16:07:35 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL28 (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 Anyone using a CD-RW drive under FreeBSD (Of course, other than as a CD-reader :-))? Robert From owner-freebsd-scsi Sun Oct 12 07:31:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA24083 for freebsd-scsi-outgoing; Sun, 12 Oct 1997 07:31:11 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from mail.ruhrgebiet.individual.net (in-ruhr.ruhr.de [141.39.224.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA24068 for ; Sun, 12 Oct 1997 07:31:05 -0700 (PDT) (envelope-from robsch@robkaos.ruhr.de) Received: from robkaos.ruhr.de (admin@localhost) by mail.ruhrgebiet.individual.net (8.8.5-r-beta/8.8.5) with UUCP id PAA01816 for freebsd.org!scsi; Sun, 12 Oct 1997 15:08:52 +0100 (MET) Received: by robkaos.ruhr.de (Smail-3.2 1996-Jul-4 #1) id ; Sun, 12 Oct 1997 16:05:08 +0200 (MET DST) Message-Id: From: robsch@robkaos.ruhr.de (Robert Schien) Subject: Kodak photo CDs and video CDs To: scsi@freebsd.org Date: Sun, 12 Oct 1997 16:05:08 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL28 (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 3.0-current is unable to read Kodak Photo CDs whereas 2.2.2-RELEASE can. Video CDs can read bei 2.2.2, but only the directory. When you try to access the *.dat files you get read errors. 3.0-current complains about a wrong mode for the track. Will it soon be possible to access both type of CDs? Don't want to use winloose :-) (Yes, of course, when I write the drivers, but his whole SCSI things is quite complicated :-)))) Robert From owner-freebsd-scsi Sun Oct 12 14:25:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA17286 for freebsd-scsi-outgoing; Sun, 12 Oct 1997 14:25:34 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA17276 for ; Sun, 12 Oct 1997 14:25:27 -0700 (PDT) (envelope-from se@zpr.uni-koeln.de) Received: from x14.mi.uni-koeln.de ([134.95.219.124]) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA05428 (5.67b/IDA-1.5 for ); Sun, 12 Oct 1997 23:25:25 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.7/8.6.9) id XAA01824; Sun, 12 Oct 1997 23:25:31 +0200 (CEST) X-Face: " Date: Sun, 12 Oct 1997 23:25:31 +0200 From: Stefan Esser To: Joerg Wunsch Cc: scsi@FreeBSD.ORG Subject: Re: Trouble with dump on ncr References: <19971011091605.32335@mi.uni-koeln.de> <199710120615.AAA18578@pluto.plutotech.com> <19971012094426.47163@mi.uni-koeln.de> <19971012122910.ZX36246@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <19971012122910.ZX36246@uriah.heep.sax.de>; from J Wunsch on Sun, Oct 12, 1997 at 12:29:10PM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 1997-10-12 12:29 +0200, J Wunsch wrote: > As Stefan Esser wrote: > > > Well, I guess it is save to just exclude those > > ASCQ values for ASC 0x04 that indicate a simple > > motor start command is not sufficient (0x04/0x03 > > surely does not ask for a START STOP UNIT command :) > > Hmm, but it can't hurt to attempt a START STOP UNIT for any NOT READY, > as long as you: > > . make sure you'll abort after a number of failed retries for the > original command, > . make sure to immediately abort after getting a nested NOT READY. >From the list ASC/ASCQ codes: 04h/00h DTLPWRSOMCAE LOGICAL UNIT NOT READY, CAUSE NOT REPORTABLE 04h/01h DTLPWRSOMCAE LOGICAL UNIT IS IN PROCESS OF BECOMING READY 04h/02h DTLPWRSOMCAE LOGICAL UNIT NOT READY, INITIALIZING CMD. REQUIRED 04h/03h DTLPWRSOMCAE LOGICAL UNIT NOT READY, MANUAL INTERVENTION REQUIRED 04h/04h DTL O LOGICAL UNIT NOT READY, FORMAT IN PROGRESS 04h/05h DT W OMCA LOGICAL UNIT NOT READY, REBUILD IN PROGRESS 04h/06h DT W OMCA LOGICAL UNIT NOT READY, RECALCULATION IN PROGRESS 04h/07h DTLPWRSOMCAE LOGICAL UNIT NOT READY, OPERATION IN PROGRESS 04h/08h R LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS You probably don't want to send a START UNIT after ASC=4 and ASCQ=3 has been returned. Same for ASCQ=4 to 8 ... You never know how robust the firmware of a device is ... Regards, STefan From owner-freebsd-scsi Sun Oct 12 16:49:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA28696 for freebsd-scsi-outgoing; Sun, 12 Oct 1997 16:49:56 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from cse.psu.edu (root@claven.cse.psu.edu [130.203.3.50]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA28691 for ; Sun, 12 Oct 1997 16:49:51 -0700 (PDT) (envelope-from keefe@cse.psu.edu) Received: from [146.186.16.119] (nb8ppp119.cac.psu.edu [146.186.16.119]) by cse.psu.edu (8.8.6/8.7.3) with ESMTP id TAA20037 for ; Sun, 12 Oct 1997 19:49:47 -0400 (EDT) X-Sender: tfk1@email.psu.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Oct 1997 19:56:45 -0500 To: freebsd-scsi@FreeBSD.ORG From: "Thomas F. Keefe" Subject: timeouts with adaptec 1742 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I have been trying to get a Seagate ST32151N (Hawk 2-XL 2GB) to work with an adaptec 1742. During the install at the commit step, the system hangs (the activity LED on the adaptec remains on) and after about 15sec. The message "Panic(adaptec 1742) for historical reasons" is displayed. After another short delay, the system reboots. The drive works fine (in the same system) using DOS 6.22 and Windows 3.1. Initially, I had timeout problems there as well, but after downloading the latest eisa configuriation files from adaptec the problem went away. These configuration files allowed me to set a specific IRQ (11) and to specify edge trigerring. I have installed FreeBSD on another disk and tried to label the ST32151N under FreeBSD. I can usually fdisk and disklabel it, but when I try to create a file system, the timeout occurs and the system panics. The problem is similar if I run the card as a 1542 and use the aha driver. Using EZ-SCSI I found that the drive doesnot support SCSI-Linking (?) while the older drive does. I am not sure if this is pertinent but I thought it might be useful. I have been struggling with this for about 3 weeks. Any help would be appreciated. Tom Keefe From owner-freebsd-scsi Sun Oct 12 17:22:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA00756 for freebsd-scsi-outgoing; Sun, 12 Oct 1997 17:22:52 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from pluto.plutotech.com (ken@mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA00739; Sun, 12 Oct 1997 17:21:42 -0700 (PDT) (envelope-from ken@plutotech.com) Received: (from ken@localhost) by pluto.plutotech.com (8.8.5/8.8.5) id SAA06431; Sun, 12 Oct 1997 18:21:41 -0600 (MDT) From: Kenneth Merry Message-Id: <199710130021.SAA06431@pluto.plutotech.com> Subject: Re: Trouble with dump on ncr In-Reply-To: <19971012094426.47163@mi.uni-koeln.de> from Stefan Esser at "Oct 12, 97 09:44:26 am" To: se@freebsd.org (Stefan Esser) Date: Sun, 12 Oct 1997 18:21:41 -0600 (MDT) Cc: scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28s (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 Stefan Esser wrote... > On 1997-10-12 00:15 -0600, Kenneth Merry wrote: > > One interesting thing about that, though.. Apparantly not all > > drives return 0x04,0x02 when they aren't spun up. I ran into some Quantum > > Fireball ST (Stratus) drives that return 0x04,0x0b when they aren't spun > > up. Strange, 'eh? That sense code qualifier isn't in the SCSI specs (not > > even SCSI-3), and it isn't in Quantum's documentation on the drive. > > Well, I guess it is save to just exclude those > ASCQ values for ASC 0x04 that indicate a simple > motor start command is not sufficient (0x04/0x03 > surely does not ask for a START STOP UNIT command :) > > How about "issue a start unit command for ASC 0x04 > and ASCQ equal 0x02 or greater-equal 0x09. Can't > see how that could cause problems ... Actually, that's just what I did to fix the problem, at least temporarily. The check (in cam_periph_error()) now looks like: else if (asc == 0x04 && ((ascq == 0x02) || (ascq > 0x08)) && save_ccb != NULL && ccb->ccb_h.retry_count > 0) { That probably isn't the best thing to do, though. What if another vendor returns the exact same sense code, but it means something else? In light of that, I'm planning to add a sense code quirk table, so that we can adequately deal with strange sense codes like 0x04,0x0b. The sense code quirk table will have suggested action flags, opcodes or something like that, to tell the error recovery code what to do in the case of a particular sense code for that particular vendor/model/etc. Ken -- Kenneth Merry ken@plutotech.com From owner-freebsd-scsi Sun Oct 12 18:00:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA03064 for freebsd-scsi-outgoing; Sun, 12 Oct 1997 18:00:27 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA03058 for ; Sun, 12 Oct 1997 18:00:24 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA24720; Sun, 12 Oct 1997 17:50:10 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd024707; Mon Oct 13 00:50:05 1997 Date: Sun, 12 Oct 1997 17:48:51 -0700 (PDT) From: Julian Elischer To: "Thomas F. Keefe" cc: scsi@freebsd.org Subject: Re: timeouts with adaptec 1742 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 I originally wrote that driver, but I 1/ don't have one any more 2/ haven't looked at for a long time.. I'm not sure if you can compile kernels elsewhere.. if you can, can you make one with the scsi debug option turned on, (man 4 scsi) options SCSIDEBUG then in scsi_debug.h set DEBUGTARG and DEBUGLUN to the LUN and target of the device giving problems. this shoul ddump ou tevery SCSI commnad as it is sent etc. then let us know what's up On Sun, 12 Oct 1997, Thomas F. Keefe wrote: > I have been trying to get a Seagate ST32151N (Hawk 2-XL 2GB) to > work with an adaptec 1742. During the install at the commit step, the > system hangs (the activity LED on the adaptec remains on) and after > about 15sec. The message "Panic(adaptec 1742) for historical reasons" is > displayed. After another short delay, the system reboots. > > The drive works fine (in the same system) using DOS 6.22 and > Windows 3.1. Initially, I had timeout problems there as well, > but after downloading the latest eisa configuriation files from adaptec > the problem went away. These configuration files allowed me > to set a specific IRQ (11) and to specify edge trigerring. > > I have installed FreeBSD on another disk and tried to label the > ST32151N under FreeBSD. I can usually fdisk and disklabel it, > but when I try to create a file system, the timeout occurs and > the system panics. The problem is similar if I run the card as > a 1542 and use the aha driver. > > Using EZ-SCSI I found that the drive doesnot support > SCSI-Linking (?) while the older drive does. I am not sure > if this is pertinent but I thought it might be useful. > I have been struggling with this for about 3 weeks. > Any help would be appreciated. > > Tom Keefe > > > > > From owner-freebsd-scsi Mon Oct 13 11:27:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA12765 for freebsd-scsi-outgoing; Mon, 13 Oct 1997 11:27:00 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA12760 for ; Mon, 13 Oct 1997 11:26:56 -0700 (PDT) (envelope-from mrcpu@cdsnet.net) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id LAA04913 for ; Mon, 13 Oct 1997 11:26:44 -0700 (PDT) Date: Mon, 13 Oct 1997 11:26:43 -0700 (PDT) From: Jaye Mathisen To: scsi@freebsd.org Subject: Still having some amusing DPT problems. 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 Looking for suggestions on what to try next. I am building a new mail server, using the DPT3332UW, and 64MB RAM, and a superMicro dual P6 board, although only running 2.2.5-beta at the time. I am getting consistent reproducible crashes in the DPT subsystem, that a parallel maching running adaptec's isn't seeing in the same way. I have 4 IBM 4GB disks in it. 2 of them configured as RAID-0, 2 of them as RAID-1. (Using dptmgr/fw0). FreeBSD is installed, and seems to run fine under light load. I'm using INETLOAD from MS, to simulate hundreds of users hitting it with mail, and another box running inetload to simulate hundreds of simultaneous POP readers. Invariably, after 20-30 hours of getting hammered, the box dies with "DPT: Undocumented error", and drops into DDB. If I take out DDB, I get a kazillion messages about stale transactions that aren't really dead, and a bunch of other errors. I have also tried a similar set up on a Digital ZX6000, with 7 Seagate Barracuda's in it, and see a similar problem. Completely different motherboard/cabling/chassis, etc. So I guess the question is. How do I help figure out what exactly is killing the DPT controller, and is development of the 2.2.x driver still on? Or is it something I just need to dump, and wait for 3.x to be solid and stable enough to use? From owner-freebsd-scsi Mon Oct 13 11:41:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA13991 for freebsd-scsi-outgoing; Mon, 13 Oct 1997 11:41:00 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from locust.net.ohio-state.edu (mail.net.ohio-state.edu [128.146.222.110]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA13952 for ; Mon, 13 Oct 1997 11:40:41 -0700 (PDT) (envelope-from maf@net.ohio-state.edu) Received: from bedbugs.net.ohio-state.edu (bedbugs [128.146.222.2]) by locust.net.ohio-state.edu (8.6.12/8.6.9) with ESMTP id OAA06343; Mon, 13 Oct 1997 14:40:39 -0400 Received: (from maf@localhost) by bedbugs.net.ohio-state.edu (8.6.12/8.6.9) id OAA04927; Mon, 13 Oct 1997 14:40:38 -0400 From: "Mark A. Fullmer" Message-Id: <199710131840.OAA04927@bedbugs.net.ohio-state.edu> Subject: Re: libdisk question To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 13 Oct 1997 14:40:38 -0400 (EDT) Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <2337.876126678@critter.freebsd.dk> from "Poul-Henning Kamp" at Oct 6, 97 10:31:18 am Reply-To: maf@net.ohio-state.edu X-Mailer: ELM [version 2.4 PL24 PGP1] 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 >In message <199710052137.RAA25492@bedbugs.net.ohio-state.edu>, "Mark A. Fullmer >" writes: >> >>Does your freebsd disk library work properly for SCSI disks? The >>'whole disk' chunk seems to be larger than it should be: > >This is correct. It's the c/h/s number that is wrong. I have multiple "MICROP 3391WS x43h" type 0 fixed SCSI 2" disks that all fail to newfs properly with a partition table created with All_FreeBSD(); archive1# uname -r 2.2.2-RELEASE not using the last 80058 or so sectors on the disk will allow newfs to finish without an error. any ideas? archive1# newfs -i 8192 /dev/rsd3e Warning: 678 sector(s) in last cylinder unallocated /dev/rsd3e: 17780058 sectors in 4341 cylinders of 1 tracks, 4096 sectors 8681.7MB in 272 cyl groups (16 c/g, 32.00MB/g, 3840 i/g) super-block backups (for fsck -b #) at: 32, 65568, 131104, 196640, 262176, 327712, 393248, 458784, 524320, 589856, 655392, 720928, 786464, 852000, 917536, 983072, 1048608, 1114144, 1179680, 1245216, 1310752, 1376288, 1441824, 1507360, 1572896, 1638432, 1703968, 1769504, 1835040, 1900576, 1966112, 2031648, 2097184, 2162720, 2228256, 2293792, 2359328, 2424864, 2490400, 2555936, 2621472, 2687008, 2752544, 2818080, 2883616, 2949152, 3014688, 3080224, 3145760, 3211296, 3276832, 3342368, 3407904, 3473440, 3538976, 3604512, 3670048, 3735584, 3801120, 3866656, 3932192, 3997728, 4063264, 4128800, 4194336, 4259872, 4325408, 4390944, 4456480, 4522016, 4587552, 4653088, 4718624, 4784160, 4849696, 4915232, 4980768, 5046304, 5111840, 5177376, 5242912, 5308448, 5373984, 5439520, 5505056, 5570592, 5636128, 5701664, 5767200, 5832736, 5898272, 5963808, 6029344, 6094880, 6160416, 6225952, 6291488, 6357024, 6422560, 6488096, 6553632, 6619168, 6684704, 6750240, 6815776, 6881312, 6946848, 7012384, 7077920, 7143456, 7208992, 7274528, 7340064, 7405600, 7471136, 7536672, 7602208, 7667744, 7733280, 7798816, 7864352, 7929888, 7995424, 8060960, 8126496, 8192032, 8257568, 8323104, 8388640, 8454176, 8519712, 8585248, 8650784, 8716320, 8781856, 8847392, 8912928, 8978464, 9044000, 9109536, 9175072, 9240608, 9306144, 9371680, 9437216, 9502752, 9568288, 9633824, 9699360, 9764896, 9830432, 9895968, 9961504, 10027040, 10092576, 10158112, 10223648, 10289184, 10354720, 10420256, 10485792, 10551328, 10616864, 10682400, 10747936, 10813472, 10879008, 10944544, 11010080, 11075616, 11141152, 11206688, 11272224, 11337760, 11403296, 11468832, 11534368, 11599904, 11665440, 11730976, 11796512, 11862048, 11927584, 11993120, 12058656, 12124192, 12189728, 12255264, 12320800, 12386336, 12451872, 12517408, 12582944, 12648480, 12714016, 12779552, 12845088, 12910624, 12976160, 13041696, 13107232, 13172768, 13238304, 13303840, 13369376, 13434912, 13500448, 13565984, 13631520, 13697056, 13762592, 13828128, 13893664, 13959200, 14024736, 14090272, 14155808, 14221344, 14286880, 14352416, 14417952, 14483488, 14549024, 14614560, 14680096, 14745632, 14811168, 14876704, 14942240, 15007776, 15073312, 15138848, 15204384, 15269920, 15335456, 15400992, 15466528, 15532064, 15597600, 15663136, 15728672, 15794208, 15859744, 15925280, 15990816, 16056352, 16121888, 16187424, 16252960, 16318496, 16384032, 16449568, 16515104, 16580640, 16646176, 16711712, 16777248, 16842784, 16908320, 16973856, 17039392, 17104928, 17170464, 17236000, 17301536, 17367072, 17432608, 17498144, 17563680, 17629216, 17694752,write error: 17760464 wtfs: Input/output error archive1# newfs -i 8192 /dev/rsd2e Warning: 678 sector(s) in last cylinder unallocated /dev/rsd2e: 17780058 sectors in 4341 cylinders of 1 tracks, 4096 sectors 8681.7MB in 272 cyl groups (16 c/g, 32.00MB/g, 3840 i/g) super-block backups (for fsck -b #) at: 32, 65568, 131104, 196640, 262176, 327712, 393248, 458784, 524320, 589856, 655392, 720928, 786464, 852000, 917536, 983072, 1048608, 1114144, 1179680, 1245216, 1310752, 1376288, 1441824, 1507360, 1572896, 1638432, 1703968, 1769504, 1835040, 1900576, 1966112, 2031648, 2097184, 2162720, 2228256, 2293792, 2359328, 2424864, 2490400, 2555936, 2621472, 2687008, 2752544, 2818080, 2883616, 2949152, 3014688, 3080224, 3145760, 3211296, 3276832, 3342368, 3407904, 3473440, 3538976, 3604512, 3670048, 3735584, 3801120, 3866656, 3932192, 3997728, 4063264, 4128800, 4194336, 4259872, 4325408, 4390944, 4456480, 4522016, 4587552, 4653088, 4718624, 4784160, 4849696, 4915232, 4980768, 5046304, 5111840, 5177376, 5242912, 5308448, 5373984, 5439520, 5505056, 5570592, 5636128, 5701664, 5767200, 5832736, 5898272, 5963808, 6029344, 6094880, 6160416, 6225952, 6291488, 6357024, 6422560, 6488096, 6553632, 6619168, 6684704, 6750240, 6815776, 6881312, 6946848, 7012384, 7077920, 7143456, 7208992, 7274528, 7340064, 7405600, 7471136, 7536672, 7602208, 7667744, 7733280, 7798816, 7864352, 7929888, 7995424, 8060960, 8126496, 8192032, 8257568, 8323104, 8388640, 8454176, 8519712, 8585248, 8650784, 8716320, 8781856, 8847392, 8912928, 8978464, 9044000, 9109536, 9175072, 9240608, 9306144, 9371680, 9437216, 9502752, 9568288, 9633824, 9699360, 9764896, 9830432, 9895968, 9961504, 10027040, 10092576, 10158112, 10223648, 10289184, 10354720, 10420256, 10485792, 10551328, 10616864, 10682400, 10747936, 10813472, 10879008, 10944544, 11010080, 11075616, 11141152, 11206688, 11272224, 11337760, 11403296, 11468832, 11534368, 11599904, 11665440, 11730976, 11796512, 11862048, 11927584, 11993120, 12058656, 12124192, 12189728, 12255264, 12320800, 12386336, 12451872, 12517408, 12582944, 12648480, 12714016, 12779552, 12845088, 12910624, 12976160, 13041696, 13107232, 13172768, 13238304, 13303840, 13369376, 13434912, 13500448, 13565984, 13631520, 13697056, 13762592, 13828128, 13893664, 13959200, 14024736, 14090272, 14155808, 14221344, 14286880, 14352416, 14417952, 14483488, 14549024, 14614560, 14680096, 14745632, 14811168, 14876704, 14942240, 15007776, 15073312, 15138848, 15204384, 15269920, 15335456, 15400992, 15466528, 15532064, 15597600, 15663136, 15728672, 15794208, 15859744, 15925280, 15990816, 16056352, 16121888, 16187424, 16252960, 16318496, 16384032, 16449568, 16515104, 16580640, 16646176, 16711712, 16777248, 16842784, 16908320, 16973856, 17039392, 17104928, 17170464, 17236000, 17301536, 17367072, 17432608, 17498144, 17563680, 17629216, 17694752, 17760288, read error: 48 rdfs: Input/output error -- mark From owner-freebsd-scsi Mon Oct 13 11:55:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15118 for freebsd-scsi-outgoing; Mon, 13 Oct 1997 11:55:07 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA14674 for ; Mon, 13 Oct 1997 11:49:44 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id UAA00535; Mon, 13 Oct 1997 20:49:11 +0200 (CEST) To: maf@net.ohio-state.edu cc: freebsd-scsi@FreeBSD.ORG Subject: Re: libdisk question In-reply-to: Your message of "Mon, 13 Oct 1997 14:40:38 EDT." <199710131840.OAA04927@bedbugs.net.ohio-state.edu> Date: Mon, 13 Oct 1997 20:49:11 +0200 Message-ID: <533.876768551@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199710131840.OAA04927@bedbugs.net.ohio-state.edu>, "Mark A. Fullmer " writes: >>In message <199710052137.RAA25492@bedbugs.net.ohio-state.edu>, "Mark A. Fullm >er >>" writes: >>> >>>Does your freebsd disk library work properly for SCSI disks? The >>>'whole disk' chunk seems to be larger than it should be: >> >>This is correct. It's the c/h/s number that is wrong. > >I have multiple "MICROP 3391WS x43h" type 0 fixed SCSI 2" disks >that all fail to newfs properly with a partition table created with What does the dmesg say about the size of the disk ? Send me the output of: fdisk sd0 disklabel sd0 disklabel -r sd0 -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-scsi Mon Oct 13 11:58:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA15376 for freebsd-scsi-outgoing; Mon, 13 Oct 1997 11:58:53 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from locust.net.ohio-state.edu (mail.net.ohio-state.edu [128.146.222.110]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA15370 for ; Mon, 13 Oct 1997 11:58:49 -0700 (PDT) (envelope-from maf@net.ohio-state.edu) Received: from bedbugs.net.ohio-state.edu (bedbugs [128.146.222.2]) by locust.net.ohio-state.edu (8.6.12/8.6.9) with ESMTP id OAA06467; Mon, 13 Oct 1997 14:58:41 -0400 Received: (from maf@localhost) by bedbugs.net.ohio-state.edu (8.6.12/8.6.9) id OAA05034; Mon, 13 Oct 1997 14:58:41 -0400 From: "Mark A. Fullmer" Message-Id: <199710131858.OAA05034@bedbugs.net.ohio-state.edu> Subject: Re: libdisk question To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 13 Oct 1997 14:58:41 -0400 (EDT) Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <533.876768551@critter.freebsd.dk> from "Poul-Henning Kamp" at Oct 13, 97 08:49:11 pm Reply-To: maf@net.ohio-state.edu X-Mailer: ELM [version 2.4 PL24 PGP1] 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 have multiple "MICROP 3391WS x43h" type 0 fixed SCSI 2" disks >>that all fail to newfs properly with a partition table created with > >What does the dmesg say about the size of the disk ? (ahc0:1:0): "MICROP 3391WS x43h" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 8681MB (17780058 512 byte sectors) >Send me the output of: > > fdisk sd0 archive1# fdisk sd1 ******* Working on device /dev/rsd1 ******* parameters extracted from in-core disklabel are: cylinders=10183 heads=194 sectors/track=9 (1746 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=10183 heads=194 sectors/track=9 (1746 blks/cyl) Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 0 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 17780058 (8681 Meg), flag 80 beg: cyl 0/ sector 1/ head 0; end: cyl 1023/ sector 9/ head 193 The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: > disklabel sd0 archive1# disklabel sd1 # /dev/rsd1c: type: SCSI disk: sd1s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 1106 sectors/unit: 17780058 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 17780058 0 unused 0 0 # (Cyl. 0 - 1106*) e: 17780058 0 4.2BSD 0 0 0 # (Cyl. 0 - 1106*) > disklabel -r sd0 archive1# disklabel -r sd1 # /dev/rsd1c: type: SCSI disk: sd1s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 1106 sectors/unit: 17780058 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 17780058 0 unused 0 0 # (Cyl. 0 - 1106*) e: 17780058 0 4.2BSD 0 0 0 # (Cyl. 0 - 1106*) -- mark From owner-freebsd-scsi Mon Oct 13 12:22:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA16806 for freebsd-scsi-outgoing; Mon, 13 Oct 1997 12:22:05 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from critter.freebsd.dk (critter.freebsd.dk [195.8.129.26]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA16562 for ; Mon, 13 Oct 1997 12:18:49 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.cybercity.dk [127.0.0.1]) by critter.freebsd.dk (8.8.7/8.8.7) with ESMTP id VAA00612; Mon, 13 Oct 1997 21:03:03 +0200 (CEST) To: maf@net.ohio-state.edu cc: freebsd-scsi@FreeBSD.ORG Subject: Re: libdisk question In-reply-to: Your message of "Mon, 13 Oct 1997 14:58:41 EDT." <199710131858.OAA05034@bedbugs.net.ohio-state.edu> Date: Mon, 13 Oct 1997 21:03:03 +0200 Message-ID: <610.876769383@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199710131858.OAA05034@bedbugs.net.ohio-state.edu>, "Mark A. Fullmer " writes: >>>I have multiple "MICROP 3391WS x43h" type 0 fixed SCSI 2" disks >>>that all fail to newfs properly with a partition table created with >> >>What does the dmesg say about the size of the disk ? > >(ahc0:1:0): "MICROP 3391WS x43h" type 0 fixed SCSI 2 >sd1(ahc0:1:0): Direct-Access 8681MB (17780058 512 byte sectors) > >>Send me the output of: >> >> fdisk sd0 > >8 partitions: ># size offset fstype [fsize bsize bps/cpg] > c: 17780058 0 unused 0 0 # (Cyl. 0 - 1106*) > e: 17780058 0 4.2BSD 0 0 0 # (Cyl. 0 - 1106*) Hmm, and if you do a dd if=/dev/rsd0 of=/dev/null bs=1m how much data does it transfer before it stops ? -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." From owner-freebsd-scsi Mon Oct 13 12:40:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA17941 for freebsd-scsi-outgoing; Mon, 13 Oct 1997 12:40:37 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from mail.kcwc.com (h1.kcwc.com [206.139.252.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA17932 for ; Mon, 13 Oct 1997 12:40:28 -0700 (PDT) (envelope-from curt@kcwc.com) Received: by mail.kcwc.com (NX5.67c/NeXT-2.0-KCWC-1.0) id AA12601; Mon, 13 Oct 97 15:40:09 -0400 Date: Mon, 13 Oct 97 15:40:09 -0400 From: curt@kcwc.com (Curt Welch) Message-Id: <9710131940.AA12601@mail.kcwc.com> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: Jaye Mathisen Subject: Re: Still having some amusing DPT problems. Cc: scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Invariably, after 20-30 hours of getting hammered, the > box dies with "DPT: Undocumented error", and drops into > DDB. If I take out DDB, I get a kazillion messages about > stale transactions that aren't really dead, and a bunch > of other errors. I had similar symptoms. I'm running the DPT on a busy usenet news server. It would never run for more than a day or two without crashing. Messages about stale transactions were one of the problems I saw. I never used DDB. I've never seen the "Undocumented error" diagnostic. However, once I upgraded to version 1.2.3 of the DPT driver, my problems went away (2 months of no problems). But what happened with that release is that the disk performance improved enough to allow my news server to keep up with the news for the first time. This means that every 5 minutes or so, the incoming feeds completes and the disks get to "catch up" - i.e. flush their cache. Before version 1.2.3 the news server could never keep up and was therefor busy non-stop 24 hours a day. I've always wondered if the new version of the driver really fixed all the previous problems I had seen or if it had just gotten around them by improving the performance. Your report makes me wonder. What DPT options do you have set? (and what version of the driver are you useing?). Are you using the DPT_HANDLE_TIMEOUTS? If you are getting messages about stale transactions I think you must have it on. Try turing it off. As I understand it, this makes the DPT driver check for transactions that take too long to complete. But "Too long" is just a calculated value that could well be too short for a very heavilly loaded system. This was one of the problems I was having. The DPT driver was aborting transactions that took too long (>20 seconds or so), when it shouldn't have. If it would have waited a bit long, the transaction would finish fine on their own. These long waits are side-effect of a large cache on the controller. I had the full 64Meg cahce on mine. If you are having real problems with lost transactions, then you might have to leave the option on, and instead try changing how it calculates the timeout values. The only options I'm using are: DPT_MEASURE_PERFORMANCE DPT_TIMEOUT_FACTOR=4 Simon of course can correct anything wrong I might have said above.... -- Curt Welch http://CurtWelch.Com/ (Just trying to take some of the load off of Simon after all the time he spent helping get my system stable...) From owner-freebsd-scsi Mon Oct 13 12:43:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA18041 for freebsd-scsi-outgoing; Mon, 13 Oct 1997 12:43:20 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA18020 for ; Mon, 13 Oct 1997 12:42:33 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA12609 (5.67b/IDA-1.5 for scsi@FreeBSD.ORG); Mon, 13 Oct 1997 21:42:35 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA01175; Mon, 13 Oct 1997 19:58:58 +0100 (MET) From: Wilko Bulte Message-Id: <199710131858.TAA01175@yedi.iaf.nl> Subject: Re: timeouts with adaptec 1742 To: julian@whistle.com (Julian Elischer) Date: Mon, 13 Oct 1997 19:58:58 +0100 (MET) Cc: keefe@cse.psu.edu, scsi@FreeBSD.ORG In-Reply-To: from "Julian Elischer" at Oct 12, 97 05:48:51 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] 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 As Julian Elischer wrote... > I originally wrote that driver, but I > 1/ don't have one any more > 2/ haven't looked at for a long time.. FWIW on 2.2.2R it still works, at least for my old 486 box here. This is with an old 640 Mb Micropolis (1588 to be exact). > I'm not sure if you can compile kernels elsewhere.. > if you can, can you make one with the scsi debug option turned on, > (man 4 scsi) _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ----------------------------------------------------------------------Yoda From owner-freebsd-scsi Mon Oct 13 15:01:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA27506 for freebsd-scsi-outgoing; Mon, 13 Oct 1997 15:01:06 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA27497 for ; Mon, 13 Oct 1997 15:00:54 -0700 (PDT) (envelope-from shimon@sendero-ppp.i-connect.net) Received: (qmail 16412 invoked by uid 1000); 13 Oct 1997 22:01:04 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-100797 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <9710131940.AA12601@mail.kcwc.com> Date: Mon, 13 Oct 1997 15:01:04 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: (Curt Welch) Subject: Re: Still having some amusing DPT problems. Cc: scsi@FreeBSD.ORG, Jaye Mathisen Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Curt Welch; On 13-Oct-97 you wrote: > > Invariably, after 20-30 hours of getting hammered, the > > box dies with "DPT: Undocumented error", and drops into > > DDB. If I take out DDB, I get a kazillion messages about > > stale transactions that aren't really dead, and a bunch > > of other errors. If you remove a species you upset the delicate balance of nature :-) Instead, change the lines: default: Debugger("DPT: Undocumented Error"); With: default: Debugger("DPT: Undocumented Error %x", ccb->status_packet.hba_stat); at the end of dpt_process_completion(). This will give us a clue what is the DPT moaning about :-) > I had similar symptoms. I'm running the DPT on a busy > usenet news server. It would never run for more than a day > or two without crashing. Messages about stale transactions > were one of the problems I saw. I never used DDB. I've > never seen the "Undocumented error" diagnostic. > > However, once I upgraded to version 1.2.3 of the DPT driver, > my problems went away (2 months of no problems). But what > happened with that release is that the disk performance > improved enough to allow my news server to keep up with the > news for the first time. This means that every 5 minutes > or so, the incoming feeds completes and the disks get to > "catch up" - i.e. flush their cache. Before version 1.2.3 > the news server could never keep up and was therefor busy > non-stop 24 hours a day. 1.2.4 made some performance improvement and fixed some bugs. It is a (proud) fact that FreeBSD allows very hevey loads to be imposed on the system. Let's debug these... > Are you using the DPT_HANDLE_TIMEOUTS? If you are getting messages > about stale transactions I think you must have it on. Try turing > it off. As I understand it, this makes the DPT driver check > for transactions that take too long to complete. But "Too long" > is just a calculated value that could well be too short for a very > heavilly loaded system. This was one of the problems I was > having. The DPT driver was aborting transactions that took too > long (>20 seconds or so), when it shouldn't have. If it would have > waited a bit long, the transaction would finish fine on their own. > These long waits are side-effect of a large cache on the controller. > I had the full 64Meg cahce on mine. The ``Undocumented Error'' should not crop up, regardless of load. The long delays are not exactly a result of the large cache. They are despite the large cache. There is a starvation condition with certain disks. The only time a large cache slows things down, in in flushing. The bigger, the more to flush the more to wait. > If you are having real problems with lost transactions, then you > might have to leave the option on, and instead try changing > how it calculates the timeout values. > > The only options I'm using are: > > DPT_MEASURE_PERFORMANCE > DPT_TIMEOUT_FACTOR=4 Change this factor to increase the timeout. > > > Simon of course can correct anything wrong I might have > said above.... > > -- > > Curt Welch > http://CurtWelch.Com/ > > (Just trying to take some of the load off of Simon after all > the time he spent helping get my system stable...) > > > --- Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313 From owner-freebsd-scsi Tue Oct 14 04:15:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA09900 for freebsd-scsi-outgoing; Tue, 14 Oct 1997 04:15:08 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id EAA09892 for ; Tue, 14 Oct 1997 04:15:01 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from skirfir.ifi.uio.no (2602@skirfir.ifi.uio.no [129.240.64.212]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Tue, 14 Oct 1997 13:14:56 +0200 MIME-Version: 1.0 Received: from localhost (dag-erli@localhost) by skirfir.ifi.uio.no ; Tue, 14 Oct 1997 11:14:54 GMT To: scsi@freebsd.org Subject: UFS on MO disks Organization: Not unless it can't be avoided. X-url: http://www.ifi.uio.no/~dag-erli/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Date: 14 Oct 1997 13:14:49 +0200 Message-ID: Lines: 21 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have an Olympus MO330S magneto-optical drive connected to my 2.2.1R system. When I mount it with a FAT-formatted disk in the drive, it works just fine (at least I've never experienced any data errors) but I get a bunch of "Illegal logical block address" or somesuch error messages on the console. (Sorry if the error messages are not exact; the box with the MO is two miles from here and I didn't remember to write them down) So I thought I'd try to format a disk with UFS and see if it worked better (plus the added benefit of a more efficient FS with proper access control and long file names). /stand/sysinstall slices it up nicely, but when I try to write changes from the labler, newfs dies with an "invalid argument" error. Now disklabel -r /dev/od0 won't work (though that isn't a big problem since I can copy an MBR back from another disk) Does anyone have experience newfs'ing MO disks? -- * Finrod (INTJ) * Unix weenie * dag-erli@ifi.uio.no * cellular +47-92835919 * RFC1123: "Be liberal in what you accept, and conservative in what you send" From owner-freebsd-scsi Tue Oct 14 10:40:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA04457 for freebsd-scsi-outgoing; Tue, 14 Oct 1997 10:40:51 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA04450 for ; Tue, 14 Oct 1997 10:40:47 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA29498 (5.67b/IDA-1.5 for scsi@FreeBSD.ORG); Tue, 14 Oct 1997 19:40:32 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id TAA01460; Tue, 14 Oct 1997 19:14:53 +0100 (MET) From: Wilko Bulte Message-Id: <199710141814.TAA01460@yedi.iaf.nl> Subject: Re: UFS on MO disks To: dag-erli@ifi.uio.no (Dag-Erling Coidan Smxrgrav) Date: Tue, 14 Oct 1997 19:14:52 +0100 (MET) Cc: scsi@FreeBSD.ORG In-Reply-To: from "Dag-Erling Coidan Smxrgrav" at Oct 14, 97 01:14:49 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] 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 As Dag-Erling Coidan Smxrgrav wrote... > I have an Olympus MO330S magneto-optical drive connected to my 2.2.1R > system. When I mount it with a FAT-formatted disk in the drive, it > works just fine (at least I've never experienced any data errors) but > I get a bunch of "Illegal logical block address" or somesuch error > messages on the console. (Sorry if the error messages are not exact; > the box with the MO is two miles from here and I didn't remember to > write them down) Sounds like the driver has gotten bad geometry data or something like that from the drive. > So I thought I'd try to format a disk with UFS and see if it worked > better (plus the added benefit of a more efficient FS with proper > access control and long file names). /stand/sysinstall slices it up > nicely, but when I try to write changes from the labler, newfs dies > with an "invalid argument" error. Now disklabel -r /dev/od0 won't work > (though that isn't a big problem since I can copy an MBR back from > another disk) > > Does anyone have experience newfs'ing MO disks? Yep. I have a Digital RWZ01 (a Sony 650Mb 5.25" in disguise) and that worked just fine with UFS some time back. But the RWZ reports itself as type 0 (?) so just like a normal random access device. And therefore uses the sd driver. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ----------------------------------------------------------------------Yoda From owner-freebsd-scsi Tue Oct 14 14:48:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA19912 for freebsd-scsi-outgoing; Tue, 14 Oct 1997 14:48:33 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA19878; Tue, 14 Oct 1997 14:48:17 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id VAA25982; Tue, 14 Oct 1997 21:48:04 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id XAA17036; Tue, 14 Oct 1997 23:47:55 +0200 (MET DST) Date: Tue, 14 Oct 1997 23:47:55 +0200 (MET DST) Message-Id: <199710142147.XAA17036@bitbox.follo.net> From: Eivind Eklund To: Simon Shapiro CC: greg@lightningweb.com, freebsd-scsi@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG In-reply-to: Simon Shapiro's message of Wed, 23 Jul 1997 23:21:48 -0700 (PDT) Subject: RE: adding RAID to the OS without re-partitioning References: Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > Hi "Greg K. Cagle"; On 23-Jul-97 you wrote: > > I plan on adding a RAID disk array to my existing server. Ther server > > has > > three HDD's in it now, with "/" as one, "/usr/" as another, and a spare > > that's partitioned as "/scratch/". > > > > The disk array will be an independent unit, and will hook up to the > > external port on my Adaptec 2940UW. The company (Baydel) says that the > > array will appear as one large volume to FreeBSD. > > > > My question: How do I include the new array as part of the filesystem, > > without re-installing? I know I can make those choices when I first > > install the OS, but can I add a partition now, without messing up > > anything? I want to end up with the large RAID as my "/usr/" partition. > > > > Thanks for suggestions, > > > > Greg > > > > ps I have 2.1.5 on a Pentium Pro 200 with 128MB ram. > > Since no on else took it on, I will donate my $0.02. > > This is really not a SCSI issue at all. > > essentially, this is what you do: [Long and complicated description deleted] This use an MS-DOS partition table, and is not how I would have done it - I would have done ## Find SCSI device number $ dmesg | grep sd sd17(dpt0:1:0): Direct-Access 16394MB (32542592 528 byte sectors) ## Initial labelling of disk $ disklabel -rw sd17 auto (you'll likely get a warning about "wrong magic number" in the syslog about here - ignore it) ## Set up partitions $ disklabel -e sd17 (Remember to check that it all sum up correctly, and that the sum of each offset+size is equal to the offset of the next slice - and slice c should cover the entire disk) ## Install filesystems $ newfs /dev/rsd17a for each of a,e,f,g (or whatever filesystems you use) And now just mount them. (Shimon was more detailed - I just say that this is described both in the handbook and the FAQ ;-) Eivind. From owner-freebsd-scsi Tue Oct 14 16:13:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA25062 for freebsd-scsi-outgoing; Tue, 14 Oct 1997 16:13:14 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA25048; Tue, 14 Oct 1997 16:12:59 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id JAA27330; Wed, 15 Oct 1997 09:00:45 +1000 Date: Wed, 15 Oct 1997 09:00:45 +1000 From: Bruce Evans Message-Id: <199710142300.JAA27330@godzilla.zeta.org.au> To: perhaps@yes.no, Shimon@i-Connect.Net Subject: RE: adding RAID to the OS without re-partitioning Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, greg@lightningweb.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >[Long and complicated description deleted] > >This use an MS-DOS partition table, and is not how I would have done >it - I would have done > >## Find SCSI device number >$ dmesg | grep sd >sd17(dpt0:1:0): Direct-Access 16394MB (32542592 528 byte sectors) > >## Initial labelling of disk >$ disklabel -rw sd17 auto If there is already a DOS partition (slice) table, then this won't work. I recently fixed a bug that allowed disklabel on an empty BSD compatibility slice to corrupt the slice table. Empty BSD compatibility slices occur naturally on all disks that have a slice table but don't have a BSD slice. You should remove the partition table using $ dd if=/dev/zero of=/dev/rsd17 count=1 before running disklabel. It may also be necessary to remove a stale label in the second sector of the disk by using a count of 2 instead of 1. You should check existing partition tables and labels before removing them. >(you'll likely get a warning about "wrong magic number" in the syslog >about here - ignore it) Someone recently removed the warning. Previously, if you didn't get the warning, it meant that there was a probably a partition table and you should have been careful removing it :-). >... >And now just mount them. (Shimon was more detailed - I just say that >this is described both in the handbook and the FAQ ;-) I think the dd step is described there. Bruce From owner-freebsd-scsi Thu Oct 16 01:11:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA14728 for freebsd-scsi-outgoing; Thu, 16 Oct 1997 01:11:57 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from ujf.ujf-grenoble.fr (ujf.ujf-grenoble.fr [193.54.232.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA14662; Thu, 16 Oct 1997 01:11:34 -0700 (PDT) (envelope-from Gilles.Bruno@ujf-grenoble.fr) Received: from adm.ujf-grenoble.fr (adm.ujf-grenoble.fr [193.54.232.78]) by ujf.ujf-grenoble.fr (8.8.5/8.8.5) with ESMTP id KAA26641; Thu, 16 Oct 1997 10:11:20 +0200 (MET DST) Received: from antigua.ujf-grenoble.fr (adm-bruno.ujf-grenoble.fr [193.54.232.177]) by adm.ujf-grenoble.fr (8.8.5/8.8.5) with SMTP id KAA26461; Thu, 16 Oct 1997 10:10:18 +0200 (MET DST) Message-Id: <3.0.3.32.19971016101018.00725e18@adm.ujf-grenoble.fr> X-Sender: bruno@adm.ujf-grenoble.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 16 Oct 1997 10:10:18 +0200 To: hardware@FreeBSD.ORG From: Gilles Bruno Subject: SEAGATE 6800 4/8Go DAT anyone ? Cc: 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, does any of you knows if this particular DAT drive (seagate 6800 4/8Go dat drive) works fine under FreeBSD -i'm planning to purchase one for a 2.2.2-release box What about reliability and scsi "behaviour" ? -- Gilles BRUNO Universite Joseph Fourier - CRIP Domaine Universitaire 38041 St Martin d'Heres FRANCE Tel (33) 04 76 63 56 68 - Fax (33) 04 76 51 42 74 From owner-freebsd-scsi Thu Oct 16 08:35:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA05722 for freebsd-scsi-outgoing; Thu, 16 Oct 1997 08:35:23 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from kaori.communique.net (kaori.communique.net [204.27.67.55]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA05717; Thu, 16 Oct 1997 08:35:20 -0700 (PDT) (envelope-from mango@staff.communique.net) Received: by kaori.communique.net with Internet Mail Service (5.0.1458.49) id ; Thu, 16 Oct 1997 10:34:30 -0500 Message-ID: From: Raul Zighelboim To: "'scsi@freefall.freebsd.org'" Cc: "'questions@freefall.freebsd.org'" Subject: Adaptec 7895 Dual UltraSCSI Channels Date: Thu, 16 Oct 1997 10:34:28 -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 Hello there! I am considering the http://www.micronics.com/products/spitfire.html motherboar for a FreeBSD box, so I must ask: Is the Adaptec 7895 compatible with the 3940 ? or supported under 2.2.2 or 2.2.5 ? Please email me directly, as I am not subscribed to scsi@freebsd.org: mailto:mango@staff.communique.net Thanks From owner-freebsd-scsi Thu Oct 16 11:15:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA14908 for freebsd-scsi-outgoing; Thu, 16 Oct 1997 11:15:57 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA14891 for ; Thu, 16 Oct 1997 11:15:48 -0700 (PDT) (envelope-from mrcpu@cdsnet.net) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.8.6/8.8.6) with SMTP id LAA07390; Thu, 16 Oct 1997 11:14:06 -0700 (PDT) Date: Thu, 16 Oct 1997 11:14:06 -0700 (PDT) From: Jaye Mathisen To: David Luyer cc: Hyunchul Kim , Masaaki NABESHIMA , cache@apan.net, squid-users@nlanr.net, scsi@freebsd.org Subject: Re: Tokyo Root Server Specification 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 While I don't want to start a flame war, I personally find the following comments pretty suspect. Since about the last half of 1996, I haven't been able to get a BusLogic controller to function anywhere near as well as the Adaptec's under any version of FreeBSD. I used to be an all-buslogic shop, so I have a vested interest in keeping it all the same. Justin's work on the AHC driver has turned it into a very high-performance card. In fact, looking at sites that spec FreeBSD boxes for newsservers and other high-performance type work, I see Adaptec being recommended over BusLogic in every circumstance. I personally have removed almost all the BusLogic's except on the lower-end boxes I have. One other issue to think about is that the Buslogic driver doesn't appear to be being actively maintained in FreeBSD. Not to say it doesn't work, but nobody leaps to mind as the "maintainer". I would use Adaptec exclusively myself. I've also heard good things about the NCR driver, but don't use it myself. On Thu, 16 Oct 1997, David Luyer wrote: > On Thu, 16 Oct 1997, Hyunchul Kim wrote: > > >> Ultra Wide SCSI IF X 2 > > ^^^^^^^^^^^^^^^^^^^^^^^ > > Adaptec's AHA 2940UW/3940UW. > > I'm not sure whether FREEBSD supports those devices or not. > > Yuck. BusLogic's are much better. Or if you have the money, DPT's. Even > a cheap card like the ones ASUS sell usually performs better than an > Adaptec. Just because Adaptec have the market doesn't mean they're any > good. > > I'd go with a BusLogic 958C (or more than one) for any server which really > had to perform, or a DPT controller if I had the extra $$$ around. > > David. > From owner-freebsd-scsi Thu Oct 16 12:17:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA19217 for freebsd-scsi-outgoing; Thu, 16 Oct 1997 12:17:58 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.238.120.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA19157 for ; Thu, 16 Oct 1997 12:16:30 -0700 (PDT) (envelope-from paulo@nlink.com.br) Received: from localhost (paulo@localhost) by mirage.nlink.com.br (8.8.5/8.8.5) with SMTP id QAA11602 for ; Thu, 16 Oct 1997 16:20:33 -0300 (EST) Date: Thu, 16 Oct 1997 16:20:33 -0300 (EST) From: Paulo Fragoso To: freebsd-scsi@freebsd.org Subject: Formating HD SCSI. 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, When I format HD SCSI my sistem halt!! Why it is happing? Are there really any bugs in driver for AHA2940? I have another prolem whith wormiofixation errors whith CD Writer HP6020i. My system is FBSD 2.2.2 whith pentium 200MHz, 2 HD 3GB SCSI, AHA2940 whith 64MB. Are there any solution in FBSD 2.2.5? Thanks, Paulo. From owner-freebsd-scsi Thu Oct 16 13:21:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA22830 for freebsd-scsi-outgoing; Thu, 16 Oct 1997 13:21:12 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from grapenuts.bellcore.com (grapenuts.bellcore.com [192.4.4.35]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA22797; Thu, 16 Oct 1997 13:21:05 -0700 (PDT) (envelope-from ath@bellcore.com) Received: from bellcore.com (localhost [127.0.0.1]) by grapenuts.bellcore.com (8.6.9/8.6.10) with ESMTP id QAA01841; Thu, 16 Oct 1997 16:20:26 -0400 Message-Id: <199710162020.QAA01841@grapenuts.bellcore.com> From: Andrew Heybey To: questions@freebsd.org, scsi@freebsd.org Subject: NCR 53c810 & DAT tape Date: Thu, 16 Oct 1997 16:20:22 -0400 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk So after I post about the wonders of my new SCSI controller & DAT drive, then I run into a problem. I try to do a large dump on the drive (about 300 MB), and it dies after 26340 tape blocks with a write error, and the drive wedges with both LEDs on. By "wedged" I mean that it doesn't respond to pushing the eject button, dump is stuck in a disk wait, and an attempt to make something happen by causing a reprobe ("scsi -f /dev/rst0.ctl -p") also hangs in a disk wait. Log messages after the error were: ncr0:6: ERROR (a0:0) (a-2a-0) (48/13) @ script (1bc:7c094800). ncr0: script cmd = 900b0000 ncr0: regdump: da 10 80 13 47 48 06 1f 01 0a 86 2a 80 00 0a 00. ncr0: restart (fatal error). st0: COMMAND FAILED (9 ff) @f064ea00. ncr0: timeout ccb=f064ea00 (skip) Boot-time probe messages for the machine, tape & controller are: FreeBSD 3.0-970807-SNAP #0: Thu Aug 7 09:39:34 GMT 1997 root@make.ican.net:/usr/src/sys/compile/GENERIC CPU: Pentium (232.96-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping=3 Features=0x8001bf ncr0: rev 0x01 int a irq 9 on pci0.10.0 ncr0: minsync=25, maxsync=206, maxoffs=8, 16 dwords burst, normal dma fifo ncr0: waiting for scsi devices to settle scbus0 at ncr0 bus 0 st0 at scbus0 target 6 lun 0 st0: type 1 removable SCSI 2 st0: Sequential-Access st0: 6.7 MB/s (150 ns, offset 8) density code 0x13, drive empty The tape drive is the only thing on the bus. It is not clear to me from the log messages whether the error is from the tape drive or some kind of problem with the controller. Any hints? thanks, andrew From owner-freebsd-scsi Thu Oct 16 16:34:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA01671 for freebsd-scsi-outgoing; Thu, 16 Oct 1997 16:34:00 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from freebie.lemis.com (gregl1.lnk.telstra.net [139.130.136.133]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA01648; Thu, 16 Oct 1997 16:33:49 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.7/8.8.5) id JAA16412; Fri, 17 Oct 1997 09:03:25 +0930 (CST) Message-ID: <19971017090324.50542@lemis.com> Date: Fri, 17 Oct 1997 09:03:24 +0930 From: Greg Lehey To: Andrew Heybey Cc: questions@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: NCR 53c810 & DAT tape References: <199710162020.QAA01841@grapenuts.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <199710162020.QAA01841@grapenuts.bellcore.com>; from Andrew Heybey on Thu, Oct 16, 1997 at 04:20:22PM -0400 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 Fight-Spam-Now: http://www.cauce.org Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Oct 16, 1997 at 04:20:22PM -0400, Andrew Heybey wrote: > So after I post about the wonders of my new SCSI controller & DAT > drive, then I run into a problem. > > I try to do a large dump on the drive (about 300 MB), and it dies > after 26340 tape blocks with a write error, and the drive wedges with > both LEDs on. By "wedged" I mean that it doesn't respond to pushing > the eject button, dump is stuck in a disk wait, and an attempt to make > something happen by causing a reprobe ("scsi -f /dev/rst0.ctl -p") > also hangs in a disk wait. > > Log messages after the error were: > > ncr0:6: ERROR (a0:0) (a-2a-0) (48/13) @ script (1bc:7c094800). > ncr0: script cmd = 900b0000 > ncr0: regdump: da 10 80 13 47 48 06 1f 01 0a 86 2a 80 00 0a 00. > ncr0: restart (fatal error). > st0: COMMAND FAILED (9 ff) @f064ea00. > ncr0: timeout ccb=f064ea00 (skip) > > Boot-time probe messages for the machine, tape & controller are: > > FreeBSD 3.0-970807-SNAP #0: Thu Aug 7 09:39:34 GMT 1997 > root@make.ican.net:/usr/src/sys/compile/GENERIC > CPU: Pentium (232.96-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x543 Stepping=3 > Features=0x8001bf > ncr0: rev 0x01 int a irq 9 on pci0.10.0 > ncr0: minsync=25, maxsync=206, maxoffs=8, 16 dwords burst, normal dma fifo > ncr0: waiting for scsi devices to settle > scbus0 at ncr0 bus 0 > st0 at scbus0 target 6 lun 0 > st0: type 1 removable SCSI 2 > st0: Sequential-Access > st0: 6.7 MB/s (150 ns, offset 8) > density code 0x13, drive empty > > The tape drive is the only thing on the bus. It is not clear to me > from the log messages whether the error is from the tape drive or some > kind of problem with the controller. Any hints? Is this repeatable? Do you have your termination set up correctly? Greg From owner-freebsd-scsi Thu Oct 16 23:51:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA25115 for freebsd-scsi-outgoing; Thu, 16 Oct 1997 23:51:00 -0700 (PDT) (envelope-from owner-freebsd-scsi) 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 XAA25108 for ; Thu, 16 Oct 1997 23:50:56 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA20708; Fri, 17 Oct 1997 08:50:54 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA08015; Fri, 17 Oct 1997 08:44:18 +0200 (MET DST) Message-ID: <19971017084418.JR57181@uriah.heep.sax.de> Date: Fri, 17 Oct 1997 08:44:18 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@FreeBSD.ORG Cc: ath@bellcore.com (Andrew Heybey) Subject: Re: NCR 53c810 & DAT tape References: <199710162020.QAA01841@grapenuts.bellcore.com> 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: <199710162020.QAA01841@grapenuts.bellcore.com>; from Andrew Heybey on Oct 16, 1997 16:20:22 -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Andrew Heybey wrote: > I try to do a large dump on the drive (about 300 MB), and it dies > after 26340 tape blocks with a write error, and the drive wedges with > both LEDs on. > ncr0:6: ERROR (a0:0) (a-2a-0) (48/13) @ script (1bc:7c094800). > ncr0: script cmd = 900b0000 > ncr0: regdump: da 10 80 13 47 48 06 1f 01 0a 86 2a 80 00 0a 00. > ncr0: restart (fatal error). > st0: COMMAND FAILED (9 ff) @f064ea00. > ncr0: timeout ccb=f064ea00 (skip) If this happens randomly, at different spots, and not on each dump, this awfully smells like the similar problems people (including me) have been reporting for these drives on the ahc driver. Symptoms there: ``timed out in command phase'', resetting SCSI bus, etc. You should be able to find the traces in the -scsi list archives, by searching for "ARCHIVE Python 25501-XXX". -- 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 Oct 16 23:51:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA25139 for freebsd-scsi-outgoing; Thu, 16 Oct 1997 23:51:08 -0700 (PDT) (envelope-from owner-freebsd-scsi) 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 XAA25131 for ; Thu, 16 Oct 1997 23:51:04 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA20709; Fri, 17 Oct 1997 08:51:01 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA08027; Fri, 17 Oct 1997 08:47:19 +0200 (MET DST) Message-ID: <19971017084719.CU29767@uriah.heep.sax.de> Date: Fri, 17 Oct 1997 08:47:19 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Cc: paulo@nlink.com.br (Paulo Fragoso) Subject: Re: Formating HD SCSI. 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 Paulo Fragoso on Oct 16, 1997 16:20:33 -0300 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Paulo Fragoso wrote: > When I format HD SCSI my sistem halt!! Why it is happing? What are you doing exactly? Any low-level SCSI error messages (e.g. on the console)? > Are there really any bugs in driver for AHA2940? I have another prolem > whith wormiofixation errors whith CD Writer HP6020i. With 2.2.2? Hmm, no, the only known bug regarding worm fixation was in 2.2-stable until very recently. The worst bug in 2.2.2 regarding the HP6020 drive was that you had to unload and reload the medium after burning one. (Fix: remove the call to scsi_stop_unit() in wormclose().) Again, what fixation errors? We need SCSI error messages in order to help you. -- 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 Oct 17 06:20:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id GAA10961 for freebsd-scsi-outgoing; Fri, 17 Oct 1997 06:20:38 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from mirage.nlink.com.br (mirage.nlink.com.br [200.238.120.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA10793 for ; Fri, 17 Oct 1997 06:18:02 -0700 (PDT) (envelope-from paulo@nlink.com.br) Received: from localhost (paulo@localhost) by mirage.nlink.com.br (8.8.5/8.8.5) with SMTP id KAA28965; Fri, 17 Oct 1997 10:11:51 -0300 (EST) Date: Fri, 17 Oct 1997 10:11:50 -0300 (EST) From: Paulo Fragoso To: Joerg Wunsch cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Formating HD SCSI. In-Reply-To: <19971017084719.CU29767@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 Hi, On Fri, 17 Oct 1997, J Wunsch wrote: > Again, what fixation errors? We need SCSI error messages in order to > help you. Nothing works, I have to hardware reset. This is happening when I format another HD in FBSD running in multi-user mode. When I boot my ssytem in single user mode it's work fine! If I boot my system in single user and mount all partitions after run fsck I have the same problem. I have this problem in two diferent computer. > > -- > 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. ;-) > Paulo. From owner-freebsd-scsi Fri Oct 17 08:12:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA16284 for freebsd-scsi-outgoing; Fri, 17 Oct 1997 08:12:41 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from grapenuts.bellcore.com (grapenuts.bellcore.com [192.4.4.35]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id IAA16276 for ; Fri, 17 Oct 1997 08:12:38 -0700 (PDT) (envelope-from ath@bellcore.com) Received: from bellcore.com (localhost [127.0.0.1]) by grapenuts.bellcore.com (8.6.9/8.6.10) with ESMTP id LAA04572; Fri, 17 Oct 1997 11:10:54 -0400 Message-Id: <199710171510.LAA04572@grapenuts.bellcore.com> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), Greg Lehey cc: scsi@freebsd.org Subject: Re: NCR 53c810 & DAT tape In-reply-to: Your message of Fri, 17 Oct 1997 08:44:18 +0200. <19971017084418.JR57181@uriah.heep.sax.de> Date: Fri, 17 Oct 1997 11:10:46 -0400 From: Andrew T Heybey Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>On Fri, 17 Oct 1997 08:44:18 +0200, j@uriah.heep.sax.de (J Wunsch) said: j> If this happens randomly, at different spots, and not on each j> dump, this awfully smells like the similar problems people j> (including me) have been reporting for these drives on the ahc j> driver. Symptoms there: ``timed out in command phase'', j> resetting SCSI bus, etc. You should be able to find the traces j> in the -scsi list archives, by searching for "ARCHIVE Python j> 25501-XXX". It does happen randomly. Last night I managed to dump all of /usr (~300 MB) without complaint. This morning I tried to dump / and it died after 1670 blocks. Then I tried again and got through / and the first 206 MB of /usr before it crapped out. This is trying to use different tapes, so I don't think it is a tape problem. (Though they are all the same brand of tape (Digital 60m DDS)--maybe I should get a different brand?) A search for "ARCHIVE Python" and then "DAT wunsch" failed to reveal any -scsi messages that looked like my problem. Was there any kind of resolution in the earlier messages? I also tried the Windoze NT backup program on it last night. It claimed to write the tape fine (two backup sets of about 200 & 300 MB) but complained of read errors when trying to verify the backup. Greg Lehey wrote: > Is this repeatable? Do you have your termination set up correctly? It is definitely repeatable (see above). There are passive terminators on the controller and active termination in the DAT drive. All the terminators have been installed/turned on since the beginning. The DAT drive has the ability to supply terminator power; at first that was turned off but I have since turned it on. The drive can enable or disable parity, so I tried that both ways as well (not that I really thought it would make a difference). andrew From owner-freebsd-scsi Sat Oct 18 04:51:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA13376 for freebsd-scsi-outgoing; Sat, 18 Oct 1997 04:51:21 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA13366 for ; Sat, 18 Oct 1997 04:51:03 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by innocence.interface-business.de (8.6.11/8.6.9) with UUCP id NAA21499; Sat, 18 Oct 1997 13:50:09 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id NAA16272; Sat, 18 Oct 1997 13:34:49 +0200 (MET DST) Message-ID: <19971018133448.KA36748@uriah.heep.sax.de> Date: Sat, 18 Oct 1997 13:34:48 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Cc: paulo@nlink.com.br (Paulo Fragoso) Subject: Re: Formating HD SCSI. References: <19971017084719.CU29767@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 Paulo Fragoso on Oct 17, 1997 10:11:50 -0300 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Paulo Fragoso wrote: > > Again, what fixation errors? We need SCSI error messages in order to > > help you. > > Nothing works, I have to hardware reset. This is happening when I format > another HD in FBSD running in multi-user mode. When I boot my ssytem in > single user mode it's work fine! This sounds like a screwed SCSI bus configuration (mistermination or such). scsiformat itself does nothing very magic, it simply issues a single SCSI command (FORMAT UNIT), and waits for up to two hours until completion. Again, without any console messages or such, we are almost helpless here. -- 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 Oct 18 04:51:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA13395 for freebsd-scsi-outgoing; Sat, 18 Oct 1997 04:51:39 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA13388 for ; Sat, 18 Oct 1997 04:51:31 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by innocence.interface-business.de (8.6.11/8.6.9) with UUCP id NAA21506; Sat, 18 Oct 1997 13:51:26 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id NAA16303; Sat, 18 Oct 1997 13:41:58 +0200 (MET DST) Message-ID: <19971018134157.TY58447@uriah.heep.sax.de> Date: Sat, 18 Oct 1997 13:41:57 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@FreeBSD.ORG Cc: ath@bellcore.com (Andrew T Heybey) Subject: Re: NCR 53c810 & DAT tape References: <19971017084418.JR57181@uriah.heep.sax.de> <199710171510.LAA04572@grapenuts.bellcore.com> 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: <199710171510.LAA04572@grapenuts.bellcore.com>; from Andrew T Heybey on Oct 17, 1997 11:10:46 -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Andrew T Heybey wrote: > A search for "ARCHIVE Python" and then "DAT wunsch" failed to reveal > any -scsi messages that looked like my problem. Strange. I can find four thread in August and September after a quick search in my archives. Here are the respective subjects and one reference ID for these threads: Bus resets. Grrrr. <19970817153114.20533@lemis.com> No go <19970821105023.LN03569@ida.interface-business.de> Adaptec 1542CP on Compaq Prosignia VS problems <199709161115.MAA27536@guinness.acucobol.ie> Possible ncr problem? <199709280439.SAA00307@caliban.dihelix.com> > Was there any kind of > resolution in the earlier messages? Not that i know of. -- 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 Oct 18 05:51:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA16464 for freebsd-scsi-outgoing; Sat, 18 Oct 1997 05:51:07 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA16452 for ; Sat, 18 Oct 1997 05:51:01 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by innocence.interface-business.de (8.6.11/8.6.9) with UUCP id OAA21825 for freebsd-scsi@FreeBSD.org; Sat, 18 Oct 1997 14:50:57 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id OAA16447; Sat, 18 Oct 1997 14:31:18 +0200 (MET DST) Message-ID: <19971018143116.KS08343@uriah.heep.sax.de> Date: Sat, 18 Oct 1997 14:31:16 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.org (FreeBSD SCSI list) Subject: Cannot happen? 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 It can: Oct 18 14:28:26 uriah /kernel: sd0: ILLEGAL REQUEST asc:21,0 Logical block address out of range field replaceable unit: d sks:cf,7 Oct 18 14:28:26 uriah /kernel: spec_getpages: I/O read error Oct 18 14:28:27 uriah /kernel: vm_fault: pager input (probably hardware) error, PID 16207 failure But the questions is: how can this happen? Ain't the driver supposed to limit the requests before calling the SCSI layers? Ain't the filesystem supposed to never attempt to access outside the disk limits? Puzzling. (The disk in question is an old Seagate Hawk.) -- 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 Oct 18 07:40:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA20433 for freebsd-scsi-outgoing; Sat, 18 Oct 1997 07:40:50 -0700 (PDT) (envelope-from owner-freebsd-scsi) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA20428 for ; Sat, 18 Oct 1997 07:40:46 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id AAA28420; Sun, 19 Oct 1997 00:38:58 +1000 Date: Sun, 19 Oct 1997 00:38:58 +1000 From: Bruce Evans Message-Id: <199710181438.AAA28420@godzilla.zeta.org.au> To: freebsd-scsi@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: Cannot happen? Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Oct 18 14:28:26 uriah /kernel: sd0: ILLEGAL REQUEST asc:21,0 Logical block address out of range field replaceable unit: d sks:cf,7 >Oct 18 14:28:26 uriah /kernel: spec_getpages: I/O read error >Oct 18 14:28:27 uriah /kernel: vm_fault: pager input (probably hardware) error, PID 16207 failure > >But the questions is: how can this happen? 1. a slice table or label can override the driver's idea of the disk size. This is a feature. 2. the frobbing of the sector size in the current sd and od is still broken. It allows writing beyond the disk. This shouldn't happen for paging. 3. some drivers don't do any bounds checking for the raw partition. This is not a problem for sd and the raw partition shouldn't be used for paging. >Ain't the driver supposed >to limit the requests before calling the SCSI layers? Ain't the Sort of. SCSI drivers can probably rely on the device to do the checking. OTOH, the floppy device does bad things when asked to seek to a huge cylinder number. My version of the driver supports slices and used to seek to garbage offsets to attempt to read labels pointed to by garbage in the slice table. >filesystem supposed to never attempt to access outside the disk >limits? The above error message is for paging, probably nor for filesystem i/o. Perhaps the partition size is just wrong, or the swap pager runs off the end and bug (2) allows the request to get as far as the drive. Bruce From owner-freebsd-scsi Sat Oct 18 09:50:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA25477 for freebsd-scsi-outgoing; Sat, 18 Oct 1997 09:50:52 -0700 (PDT) (envelope-from owner-freebsd-scsi) 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 JAA25472 for ; Sat, 18 Oct 1997 09:50:47 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA11623 for freebsd-scsi@FreeBSD.org; Sat, 18 Oct 1997 18:50:45 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id SAA17329; Sat, 18 Oct 1997 18:46:10 +0200 (MET DST) Message-ID: <19971018184608.DL48173@uriah.heep.sax.de> Date: Sat, 18 Oct 1997 18:46:08 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.org (FreeBSD SCSI list) Subject: Re: Cannot happen? References: <19971018143116.KS08343@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: <19971018143116.KS08343@uriah.heep.sax.de>; from J Wunsch on Oct 18, 1997 14:31:17 +0200 Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I wrote: > Oct 18 14:28:26 uriah /kernel: sd0: ILLEGAL REQUEST asc:21,0 Logical block address out of range field replaceable unit: d sks:cf,7 > But the questions is: how can this happen? Ain't the driver supposed > to limit the requests before calling the SCSI layers? Ain't the > filesystem supposed to never attempt to access outside the disk > limits? The driver does, but accesses through the buffer cache cause harm. Maybe this was a faulty filesystem, but somehow there's a bug that causes a problem when i try to access the very last block of the disk through the buffer cache. Access to the raw device works as expected: j@uriah 55% ./dd if=/dev/rsd0 skip=4197400 of=/dev/null 5+0 records in 5+0 records out 2560 bytes transferred in 0.204268 secs (12533 bytes/sec) (The disk capacity is indeed 4197405 blocks.) j@uriah 56% ./dd if=/dev/sd0 skip=4197400 of=/dev/null dd: /dev/sd0: Invalid argument 4+0 records in 4+0 records out 2048 bytes transferred in 0.055174 secs (37119 bytes/sec) j@uriah 57% Oct 18 18:44:59 uriah /kernel: sd0: ILLEGAL REQUEST asc:21,0 Logical block address out of range field replaceable unit: d sks:cf,7 ...but access to the buffered device bails out when getting at the last block on the disk. -- 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 Oct 18 10:51:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA27255 for freebsd-scsi-outgoing; Sat, 18 Oct 1997 10:51:14 -0700 (PDT) (envelope-from owner-freebsd-scsi) 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 KAA27250 for ; Sat, 18 Oct 1997 10:51:10 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id TAA12353 for freebsd-scsi@FreeBSD.ORG; Sat, 18 Oct 1997 19:51:01 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id TAA00466; Sat, 18 Oct 1997 19:32:10 +0200 (MET DST) Message-ID: <19971018193207.SI11932@uriah.heep.sax.de> Date: Sat, 18 Oct 1997 19:32:07 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.ORG Subject: Re: Cannot happen? References: <199710181438.AAA28420@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: <199710181438.AAA28420@godzilla.zeta.org.au>; from Bruce Evans on Oct 19, 1997 00:38:58 +1000 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > >But the questions is: how can this happen? > > 1. a slice table or label can override the driver's idea of the disk size. > This is a feature. (Not the case.) > 2. the frobbing of the sector size in the current sd and od is still broken. > It allows writing beyond the disk. This shouldn't happen for paging. This seems to be the problem. > 3. some drivers don't do any bounds checking for the raw partition. This > is not a problem for sd and the raw partition shouldn't be used for > paging. It wasn't happening together with paging. The last block of this disk was assigned to my /home filesystem. I think the error message from the pager was due to the IO being done through mmap() (or due to the similar effect of the merged VM/buffer cache). > >Ain't the driver supposed > >to limit the requests before calling the SCSI layers? Ain't the > > Sort of. SCSI drivers can probably rely on the device to do the checking. But well, they should return a short read instead of blasting the console with error messages, and even worse, delivering a signal to the application. -- 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. ;-)