From owner-freebsd-scsi Sun Mar 14 0: 8:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B91D14F3B for ; Sun, 14 Mar 1999 00:08:14 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id BAA11545; Sun, 14 Mar 1999 01:07:52 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903140807.BAA11545@panzer.plutotech.com> Subject: Re: Strange SCSI QIC tape behaviour In-Reply-To: <19990314083709.50127@uriah.heep.sax.de> from J Wunsch at "Mar 14, 1999 8:37: 9 am" To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 14 Mar 1999 01:07:52 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org J Wunsch wrote... [ Matt can handle the tape problems ] > I also noticed that the sa driver doesn't claim device entries in > DEVFS. This should be easy to fix (and a lot more of the CAM entries > are missing, only the da's are there), so i could try to fix this > myself. IIRC, the problem is that the version of DEVFS that we have now can't handle device arrival/removal events from an interrupt context. Julian had a version of DEVFS/SLICE at one point that could handle being called from an interrupt context, however. Bruce looked into the DEVFS/CAM thing a while back, and conculded it wouldn't work for now. If you want details, ask him. So, the bottom line is, if you're using CAM, you can't use DEVFS. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 0:28:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 32A1F15129 for ; Sun, 14 Mar 1999 00:28:41 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id BAA11613; Sun, 14 Mar 1999 01:28:20 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903140828.BAA11613@panzer.plutotech.com> Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <19990314084849.47902@uriah.heep.sax.de> from J Wunsch at "Mar 14, 1999 8:48:49 am" To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 14 Mar 1999 01:28:20 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM921400100-11414-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM921400100-11414-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit J Wunsch wrote... > Well, as i wrote in the other message, i'm now (finally) also with CAM > at home. Basically, everything's working fine so far. (Unlike what > Ken wrote, i can't confirm the problems with the IBM DCAS with tagged > queuing, but i'll try to collect bonnie and iozone data first.) Yeah, I'm interested to see your results. If you want, I can send you camcontrol diffs that will allow you to set the number of tags for a device on the fly. It's likely that you wouldn't notice a problem under light load. Take a look at the PR (10398) for a more complete description of what happens. > Well, the subject says what's not working yet: my old SONY MO drive. > Upon booting, i get (after a rather long timeout, i. e. while the > system is already proceeding with the boot): > > (da2:ncr1:0:3:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da2:ncr1:0:3:0): NOT READY asc:4,0 > (da2:ncr1:0:3:0): Logical unit not ready, cause not reportable > (da2:ncr1:0:3:0): fatal error, failed to attach to device > (da2:ncr1:0:3:0): lost device > (da2:ncr1:0:3:0): removing device entry > > Hmm, yes, the drive ain't spinning by that time (i keep it down when > not used), but i was under the impression the probe routine would spin > it up anyway? At least the old od(4) driver did so (and in my hacked > version, automatically brought the drive down when not openened by > anyone.) > > I can then spin it up manually using the associated pass device, but a > `camcontrol rescan' doesn't get it back as a `da2' as i would have > expected. Here's all i could get so far: > > uriah # camcontrol inquiry -n pass -u 4 > Removable Direct Access SCSI-CCS device > Serial Number 0.0MB/s transfers > uriah # camcontrol start -n pass -u 4 > Unit started successfully > uriah # camcontrol tur -n pass -u 4 > Unit is ready > uriah # camcontrol rescan 1 > Re-scan of bus 1 was successful > uriah # camcontrol rescan 0 > Re-scan of bus 0 was successful > uriah # camcontrol devlist > < > at scbus-1 target -1 lun -1 (xpt0) > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 2 lun 0 (pass1,cd0) > at scbus0 target 4 lun 0 (pass2,sa0) > < > at scbus0 target -1 lun -1 () > at scbus1 target 1 lun 0 (pass3,da1) > at scbus1 target 3 lun 0 (pass4) > < > at scbus1 target -1 lun -1 () > > Does anybody have a hint, maybe an idea for the quirk entry that's > required in order to get the drive working? (Yes, it's SCSI-CCS only, > and it actually ain't even a SCSI drive, but rather an ESDI-to-SCSI > bridge. :) The problem is that your drive returns a non-standard response when it isn't spun up. The only response that can really conclusively be read as "I need to be spun up" is 0x04, 0x02, or "Logical unit not ready, initializing cmd. required". When the error recovery code sees 0x04,0x00 or 0x04,0x01, it assumes that the drive is just taking a while to become ready. So it sends a test unit ready every .5 seconds for a minute to see if the drive is ready. If the drive isn't ready after that, it just assumes that it won't be ready. That's why it takes so long for the error message to show up on your console. It has to go through the error recovery proces at least once, and probably twice. So that's 1 or 2 minutes. If you want your drive to be spun up when it returns 0x04,0x00, you need to add a quirk entry to the sense code table that will tell the error recovery code to do what you want it to do. I've attached a quirk entry that may do the trick. Let me know if it works. I'm not sure why the da driver didn't attach when you rescanned the drive. I'd have to think on that to figure it out, and it's too late for thinking too much. :) Ken -- Kenneth Merry ken@plutotech.com --ELM921400100-11414-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=scsi_all.c.diffs.031499 Content-Description: scsi_all.c.diffs.031499 Content-Transfer-Encoding: 7bit ==== //depot/cam/sys/cam/scsi/scsi_all.c#59 - /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_all.c ==== *** /tmp/tmp.11596.0 Sun Mar 14 01:23:00 1999 --- /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_all.c Sun Mar 14 01:22:24 1999 *************** *** 725,730 **** --- 725,739 ---- * WARNING: You must update the num_ascs field below for this quirk table * entry if you add more entries. */ + static struct asc_table_entry sony_mo_entries[] = { + {SST(0x04, 0x00, SS_START|SSQ_DECREMENT_COUNT|ENXIO, + "Logical unit not ready, cause not reportable")} + }; + + /* + * WARNING: You must update the num_ascs field below for this quirk table + * entry if you add more entries. + */ static struct asc_table_entry quantum_fireball_entries[] = { {SST(0x04, 0x0b, SS_START|SSQ_DECREMENT_COUNT|ENXIO, "Logical unit not ready, initializing cmd. required")} *************** *** 741,746 **** --- 750,765 ---- {T_DIRECT, SIP_MEDIA_FIXED, "QUANTUM", "FIREBALL S*", "*"}, 1, /* number of vendor-specific sense codes for this entry */ quantum_fireball_entries + }, + { + /* + * This Sony MO drive likes to return 0x04, 0x00 when it + * isn't spun up. + * Reported by: Joerg Wunsch + */ + {T_DIRECT, SIP_MEDIA_REMOVABLE, "SONY", "SMO-C501-09*", "*"}, + 1, /* number of vendor-specific sense codes for this entry */ + sony_mo_entries } }; --ELM921400100-11414-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 5:48:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 03CB514E08 for ; Sun, 14 Mar 1999 05:47:10 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id OAA28599 for freebsd-scsi@FreeBSD.ORG; Sun, 14 Mar 1999 14:46:48 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id OAA00424; Sun, 14 Mar 1999 14:24:16 +0100 (MET) (envelope-from j) Message-ID: <19990314142415.23439@uriah.heep.sax.de> Date: Sun, 14 Mar 1999 14:24:15 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM Reply-To: Joerg Wunsch References: <19990314084849.47902@uriah.heep.sax.de> <199903140828.BAA11613@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88 In-Reply-To: <199903140828.BAA11613@panzer.plutotech.com>; from Kenneth D. Merry on Sun, Mar 14, 1999 at 01:28:20AM -0700 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 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote: (IBM DCAS & tagged queuing) > Yeah, I'm interested to see your results. If you want, I can send > you camcontrol diffs that will allow you to set the number of tags > for a device on the fly. That would be great. > The problem is that your drive returns a non-standard response when > it isn't spun up. The only response that can really conclusively be > read as "I need to be spun up" is 0x04, 0x02, or "Logical unit not > ready, initializing cmd. required". This is not very surprising. By the time the firmware of this device has been designed (cca. 1990), SCSI-2 wasn't available yet. I guess 0x04, 0x00 was the standard response for a device not being ready then, kinda. > When the error recovery code sees 0x04,0x00 or 0x04,0x01, it assumes > that the drive is just taking a while to become ready. So it sends > a test unit ready every .5 seconds for a minute to see if the drive > is ready. If the drive isn't ready after that, it just assumes that > it won't be ready. What surprises me however is, it's a removable device (and properly announced as this), so a medium shouldn't even be required to be in the drive at boot time, should it? > If you want your drive to be spun up when it returns 0x04,0x00, you > need to add a quirk entry to the sense code table that will tell the > error recovery code to do what you want it to do. I've attached a > quirk entry that may do the trick. Let me know if it works. Thanks!, i was hoping for some advice like this. (Btw., it's IMHO safe to only test for SONY SMO-*, they are all such old devices.) Alas, it doesn't work. :( Right after probing the CD-ROM drive (which is on the other bus), it now jams its SCSI bus. (The following has been written on a sheet of paper, so typos are mine.) ncr1: SCSI phase error fixup: CCB already dequeued (0xc07b0000) ncr1: timeout nccb=0xc07b0000 (skip) ncr1: timeout nccb=0xc07b0000 (skip) ncr1: timeout nccb=0xc07b0000 (skip) (da2:ncr1:0:3:0) got CAM status 0x4b (da2:ncr1:0:3:0) fatal error, failed to attach device (da2:ncr1:0:3:0) lost device (da2:ncr1:0:3:0) removing device entry At this point, the system effectively halts. Upon waiting indefinitely, it would eventually timeout a few more CCBs, but i lost my patience and hit reset. With a spinning medium in the drive, it boots well (and da2 even `arrives' before da1). > I'm not sure why the da driver didn't attach when you rescanned the > drive. I'd have to think on that to figure it out, and it's too > late for thinking too much. :) Understood. My suspicion (just guessing, i don't have an idea of the program flow in the CAM code) is that my attempt to spinup the drive using the pass device (which succeeded) caused the drive to become `half-known', as a subsequent camcontrol devlist seems to confirm (device assigned to pass4, but not to any other driver). A following camcontrol rescan didn't notice it as a new entry, so nothing happened. I played a little, turned off the drive, camcontrol rescan so it had to remove the entry completely. Then turned on the drive again (which also causes it to spin up), and voilá, the next camcontrol rescan makes the drive accessible as both, pass4 and da2. -- 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. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 5:48:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id EFEA814E8A for ; Sun, 14 Mar 1999 05:47:13 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id OAA28600 for freebsd-scsi@FreeBSD.ORG; Sun, 14 Mar 1999 14:46:55 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id OAA00436; Sun, 14 Mar 1999 14:25:12 +0100 (MET) (envelope-from j) Message-ID: <19990314142512.45269@uriah.heep.sax.de> Date: Sun, 14 Mar 1999 14:25:12 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: Strange SCSI QIC tape behaviour Reply-To: Joerg Wunsch References: <19990314083709.50127@uriah.heep.sax.de> <199903140807.BAA11545@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199903140807.BAA11545@panzer.plutotech.com>; from Kenneth D. Merry on Sun, Mar 14, 1999 at 01:07:52AM -0700 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 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote: > So, the bottom line is, if you're using CAM, you can't use DEVFS. Hmm, too bad, but probably nothing i'll be looking into soon. DEVFS is only here in the kernel to play with it, nothing more serious. Thanks for the explanation. -- 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. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 6:16:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 65691154D0; Sun, 14 Mar 1999 06:16:32 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id PAA28294; Sun, 14 Mar 1999 15:16:14 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 6728B87B6; Sun, 14 Mar 1999 13:35:28 +0100 (CET) Date: Sun, 14 Mar 1999 13:35:28 +0100 From: Ollivier Robert To: Kenneth Merry Cc: "FreeBSD SCSI Users' list" Subject: Re: cvs commit: src/sys/cam cam_xpt.c Message-ID: <19990314133528.A4071@keltia.freenix.fr> Mail-Followup-To: Kenneth Merry , FreeBSD SCSI Users' list References: <199903140515.VAA29957@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.3i In-Reply-To: <199903140515.VAA29957@freefall.freebsd.org>; from Kenneth Merry on Sat, Mar 13, 1999 at 09:15:39PM -0800 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5130 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Kenneth Merry: > Log: > Disable tagged queueing for the IBM DCAS drives. These drives have poor > write performance when tagged queueing is enabled. Do you call that poor performance ? I have two 4 gig drives and they don't seem that slow for me... Seeker 1...Seeker 3...Seeker 2...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU dcas4 256 2891 37.3 2534 9.8 1797 7.9 5913 48.2 5916 19.2 96.0 3.5 Writing the 256 Megabyte file, 'iozone.tmp'...95.656250 seconds Reading the file...43.687500 seconds IOZONE performance measurements: 2806251 bytes/second for writing the file 6144445 bytes/second for reading the file ncr0: rev 0x03 int a irq 9 on pci0.11.0 da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.00MB/s transfers (20.00MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.00MB/s transfers (20.00MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 6:42:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from qix (cabri.obs-besancon.fr [193.52.184.3]) by hub.freebsd.org (Postfix) with ESMTP id 2252815159; Sun, 14 Mar 1999 06:42:12 -0800 (PST) (envelope-from jmz@FreeBSD.ORG) Received: (from jmz@localhost) by qix (8.9.3/8.8.7) id PAA71438; Sun, 14 Mar 1999 15:41:29 +0100 (MET) Date: Sun, 14 Mar 1999 15:41:29 +0100 (MET) Message-Id: <199903141441.PAA71438@qix> X-Authentication-Warning: qix: jmz set sender to jmz@qix using -f From: Jean-Marc Zucconi To: roberto@keltia.freenix.fr Cc: ken@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-reply-to: <19990314133528.A4071@keltia.freenix.fr> (message from Ollivier Robert on Sun, 14 Mar 1999 13:35:28 +0100) Subject: Re: cvs commit: src/sys/cam cam_xpt.c X-Mailer: Emacs Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> Ollivier Robert writes: > According to Kenneth Merry: >> Log: >> Disable tagged queueing for the IBM DCAS drives. These drives have poor >> write performance when tagged queueing is enabled. > Do you call that poor performance ? I have two 4 gig drives and they don't > seem that slow for me... > Seeker 1...Seeker 3...Seeker 2...start 'em...done...done...done... > -------Sequential Output-------- ---Sequential Input-- --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > dcas4 256 2891 37.3 2534 9.8 1797 7.9 5913 48.2 5916 19.2 96.0 3.5 > Writing the 256 Megabyte file, 'iozone.tmp'...95.656250 seconds > Reading the file...43.687500 seconds > IOZONE performance measurements: > 2806251 bytes/second for writing the file > 6144445 bytes/second for reading the file Yes this is very poor for a wide drive. On my narrow DCAS-34330: Writing the 250 Megabyte file, 'iozone.tmp'...80.351562 seconds Reading the file...38.601562 seconds IOZONE performance measurements: 3262463 bytes/second for writing the file 6791020 bytes/second for reading the file da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > ncr0: rev 0x03 int a irq 9 on pci0.11.0 > da1 at ncr0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.00MB/s transfers (20.00MHz, offset 15, 16bit), Tagged Queueing Enabled > da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > da0 at ncr0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.00MB/s transfers (20.00MHz, offset 15, 16bit), Tagged Queueing Enabled > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Jean-Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 11:20:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 752DF14BE6 for ; Sun, 14 Mar 1999 11:20:41 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id UAA03991 for freebsd-scsi@FreeBSD.ORG; Sun, 14 Mar 1999 20:20:23 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id UAA19391; Sun, 14 Mar 1999 20:19:47 +0100 (MET) (envelope-from j) Message-ID: <19990314201946.00024@uriah.heep.sax.de> Date: Sun, 14 Mar 1999 20:19:46 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c Reply-To: Joerg Wunsch References: <19990314133528.A4071@keltia.freenix.fr> <199903141441.PAA71438@qix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199903141441.PAA71438@qix>; from Jean-Marc Zucconi on Sun, Mar 14, 1999 at 03:41:29PM +0100 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 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Jean-Marc Zucconi wrote: > Yes this is very poor for a wide drive. On my narrow DCAS-34330: > Writing the 250 Megabyte file, 'iozone.tmp'...80.351562 seconds > Reading the file...38.601562 seconds > > IOZONE performance measurements: > 3262463 bytes/second for writing the file > 6791020 bytes/second for reading the file I get about 4.4 MB/s writing and 5.8 MB/s reading, with tagged queuing still enabled. I also get better bonnie figures than those mentioned in PR kern/10398, about 4 MB/s `Per Char' and 5 MB/s `Block'. However, as Ken already mentioned, see the audit-trail from PR 10398 for a counterexample. -- 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. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 12:53:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 45A30156FE; Sun, 14 Mar 1999 12:53:29 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id NAA13995; Sun, 14 Mar 1999 13:53:10 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903142053.NAA13995@panzer.plutotech.com> Subject: Re: cvs commit: src/sys/cam cam_xpt.c In-Reply-To: <199903141441.PAA71438@qix> from Jean-Marc Zucconi at "Mar 14, 1999 3:41:29 pm" To: jmz@FreeBSD.ORG (Jean-Marc Zucconi) Date: Sun, 14 Mar 1999 13:53:10 -0700 (MST) Cc: roberto@keltia.freenix.fr, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jean-Marc Zucconi wrote... > >>>>> Ollivier Robert writes: > > > According to Kenneth Merry: > >> Log: > >> Disable tagged queueing for the IBM DCAS drives. These drives have poor > >> write performance when tagged queueing is enabled. > > > Do you call that poor performance ? I have two 4 gig drives and they don't > > seem that slow for me... > > > Seeker 1...Seeker 3...Seeker 2...start 'em...done...done...done... > > -------Sequential Output-------- ---Sequential Input-- --Random-- > > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- > > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU > > dcas4 256 2891 37.3 2534 9.8 1797 7.9 5913 48.2 5916 19.2 96.0 3.5 > > > Writing the 256 Megabyte file, 'iozone.tmp'...95.656250 seconds > > Reading the file...43.687500 seconds > > > IOZONE performance measurements: > > 2806251 bytes/second for writing the file > > 6144445 bytes/second for reading the file > > Yes this is very poor for a wide drive. On my narrow DCAS-34330: > Writing the 250 Megabyte file, 'iozone.tmp'...80.351562 seconds > Reading the file...38.601562 seconds > > IOZONE performance measurements: > 3262463 bytes/second for writing the file > 6791020 bytes/second for reading the file > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled > da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > > > ncr0: rev 0x03 int a irq 9 on pci0.11.0 > > da1 at ncr0 bus 0 target 1 lun 0 > > da1: Fixed Direct Access SCSI-2 device > > da1: 40.00MB/s transfers (20.00MHz, offset 15, 16bit), Tagged Queueing Enabled > > da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > > da0 at ncr0 bus 0 target 0 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > da0: 40.00MB/s transfers (20.00MHz, offset 15, 16bit), Tagged Queueing Enabled > > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) The issue isn't really whether it's "poor performance" or "poor for a wide drive", but whether the performance you're getting out of the drive is what the drive is capable of. If you look at PR 10398, you'll see that the 4G DCAS drive is *capable* of 6.8MB/sec sequential write performance for block writes. Both of you have just shown write performance for the same drive that is substantially less than that. My goal in disabling tagged queueing for the DCAS drives is to increase performance, based on the assertion that they don't perform as well when tagged queueing is enabled. That is very unusual for an IBM drive, but I guess I've come to expect the unexpected from drive vendors. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 13:26:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from milf18.bus.net (milf18.bus.net [207.41.25.18]) by hub.freebsd.org (Postfix) with ESMTP id 30ECF14BE6 for ; Sun, 14 Mar 1999 13:26:08 -0800 (PST) (envelope-from cao@milf18.bus.net) Received: (from cao@localhost) by milf18.bus.net (8.8.8/8.8.8) id QAA13207; Sun, 14 Mar 1999 16:25:42 -0500 (EST) (envelope-from cao) Date: Sun, 14 Mar 1999 16:25:42 -0500 From: "Chuck O'Donnell" To: "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Re: error messages from bt driver Message-ID: <19990314162542.C11051@milf18.bus.net> References: <19990313183436.B11051@milf18.bus.net> <199903140053.RAA13024@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199903140053.RAA13024@pluto.plutotech.com>; from Justin T. Gibbs on Sat, Mar 13, 1999 at 05:44:29PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Mar 13, 1999 at 05:44:29PM -0700, Justin T. Gibbs wrote: > >Thanks for the reply Justin. > > > >I tried 5.06I from the Mylex site, but no improvement. Same error > >messages show up. Any thoughts on other things I can check? > > > >Thanks. > > > >Chuck > > One thing I don't know about on the MultiMasters is how they deal > with a disk returning queue full status. Your Seagate will only > handle 64 commands at a time, but we've queued up 191 to the > Buslogic. Perhaps it will not release the mailbox for a transaction > that is in the queue full state? This would cause the first error > message to occur. My guess is that a quirk entry in sys/cam/cam_xpt.c > limiting the number of tags for your drive to 64 will prevent the > problem from happening. Okay, it looks like that did the trick. I reinstalled the original flash bios (5.07B), edited sys/cam/cam_xpt.c (see attached diffs for quirk entry below), and rebuilt the kernel. I don't know if there is a good known way to overload the queue for testing, but since the daily script seems to be a repeatable way to trigger the problem, I have been using it as a test by running it 10 times consecutively. Q: Is there any way to query the driver to find out how many tags are currently enabled for the drive? e.g., a camcontrol(8) option or some such? After I rebuilt the kernel and rebooted I couldn't tell for sure if the drive inquiry data had matched my new quirk entry and correctly adjusted the queue size for the drive. Attached below is a diff for the quirk, can you take a look and make sure I did it correctly? > > I'll also contact Mylex to see if they can give me any more information > about how their controllers react. It's really a shame that they don't > report queue full status back up to the driver so that we can be smarter > about limiting the number of commands we send. RAID arrays can really > make use of the extra tags, so I'd rather not place an artificial limit > on them. > Let me know if there is anything I can do to assist in this... Thanks very much for your help! Chuck *** cam_xpt.c.orig Sat Mar 6 19:39:49 1999 --- cam_xpt.c Sun Mar 14 15:52:13 1999 *************** *** 307,312 **** --- 307,328 ---- { T_DIRECT, SIP_MEDIA_FIXED, "SEAGATE", "ST410800*", "71*" }, /*quirks*/0, /*mintags*/0, /*maxtags*/0 }, + { + /* + * Explicitly set number of tags for Seagate connected + * to BusLogic MultiMaster. + */ + { T_DIRECT, SIP_MEDIA_FIXED, "SEAGATE", "ST39173*", "*" }, + /*quirks*/0, /*mintags*/0, /*maxtags*/64 + }, + { + /* + * Explicitly set number of tags for Seagate connected + * to BusLogic MultiMaster. + */ + { T_DIRECT, SIP_MEDIA_FIXED, "SEAGATE", "ST34573*", "*" }, + /*quirks*/0, /*mintags*/0, /*maxtags*/64 + }, { /* Broken tagged queuing drive */ { T_DIRECT, SIP_MEDIA_REMOVABLE, "iomega", "jaz*", "*" }, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 15:42:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 7ACEB14F2A for ; Sun, 14 Mar 1999 15:42:34 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id QAA14908; Sun, 14 Mar 1999 16:42:06 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903142342.QAA14908@panzer.plutotech.com> Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <19990314142415.23439@uriah.heep.sax.de> from J Wunsch at "Mar 14, 1999 2:24:15 pm" To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 14 Mar 1999 16:42:06 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org J Wunsch wrote... > As Kenneth D. Merry wrote: > > (IBM DCAS & tagged queuing) > > > Yeah, I'm interested to see your results. If you want, I can send > > you camcontrol diffs that will allow you to set the number of tags > > for a device on the fly. > > That would be great. Well, to avoid having to send the patches to too many more people, I've put them here: http://www.FreeBSD.ORG/~ken/camcontrol.diffs.031499 Generally, you should test under the following conditions: With write caching enabled: 64, 32, 16, 8, 4, 3, 2 and 1 tags With write caching disabled: 64, 32, 16, 8, 4, 3, 2 and 1 tags To view the current number of tags: camcontrol tags To view the maximum and minimum number of tags: camcontrol tags -v To set the number of tags: camcontrol tags -n da -u 3 -N 32 To disable tagged queueing (i.e. set the number of tags to 1): camcontrol negotiate -T disable The man page in the above patch should explain things. There are a number of other options to the 'tags' and 'negotiate' arguments. The patches are almost ready to be checked in. I think they just need some cleanup and the man page is missing descriptions of a couple of things. > > The problem is that your drive returns a non-standard response when > > it isn't spun up. The only response that can really conclusively be > > read as "I need to be spun up" is 0x04, 0x02, or "Logical unit not > > ready, initializing cmd. required". > > This is not very surprising. By the time the firmware of this device > has been designed (cca. 1990), SCSI-2 wasn't available yet. I guess > 0x04, 0x00 was the standard response for a device not being ready > then, kinda. Probably so. > > When the error recovery code sees 0x04,0x00 or 0x04,0x01, it assumes > > that the drive is just taking a while to become ready. So it sends > > a test unit ready every .5 seconds for a minute to see if the drive > > is ready. If the drive isn't ready after that, it just assumes that > > it won't be ready. > > What surprises me however is, it's a removable device (and properly > announced as this), so a medium shouldn't even be required to be in > the drive at boot time, should it? Right, media should not be required. What we *do* require is that the device tell us in some intelligible way that there is no media in it. The da driver looks for a "medium not present" type of error code (i.e., asc == 0x3a). If it sees an error message like that, it determines that media isn't present and attaches anyway. But I thought that you were trying to get the system to boot with a disk in the drive, but not spinning. > > If you want your drive to be spun up when it returns 0x04,0x00, you > > need to add a quirk entry to the sense code table that will tell the > > error recovery code to do what you want it to do. I've attached a > > quirk entry that may do the trick. Let me know if it works. > > Thanks!, i was hoping for some advice like this. (Btw., it's IMHO > safe to only test for SONY SMO-*, they are all such old devices.) > > Alas, it doesn't work. :( Right after probing the CD-ROM drive (which > is on the other bus), it now jams its SCSI bus. > > (The following has been written on a sheet of paper, so typos are > mine.) > > ncr1: SCSI phase error fixup: CCB already dequeued (0xc07b0000) > ncr1: timeout nccb=0xc07b0000 (skip) > ncr1: timeout nccb=0xc07b0000 (skip) > ncr1: timeout nccb=0xc07b0000 (skip) > (da2:ncr1:0:3:0) got CAM status 0x4b > (da2:ncr1:0:3:0) fatal error, failed to attach device > (da2:ncr1:0:3:0) lost device > (da2:ncr1:0:3:0) removing device entry > > At this point, the system effectively halts. Upon waiting > indefinitely, it would eventually timeout a few more CCBs, but i lost > my patience and hit reset. Hmm. The CAM status 0x4b means that the command timed out, and that the queue for that device was frozen. I don't know why it hung your system. > With a spinning medium in the drive, it boots well (and da2 even > `arrives' before da1). Okay, let me see if I've got this straight: - It works with media in the drive and spinning. - If there is no media in the drive, it doesn't work. What happens in this case? - If there is media in the drive that isn't spinning, and you've got the quirk entry in scsi_all.c, the spinup command may be timing out. How long does the start unit command take for that drive? The timeout for the start unit command in the error recovery code is 50 seconds. (The start unit is done in cam_periph.c) > > I'm not sure why the da driver didn't attach when you rescanned the > > drive. I'd have to think on that to figure it out, and it's too > > late for thinking too much. :) > > Understood. > > My suspicion (just guessing, i don't have an idea of the program flow > in the CAM code) is that my attempt to spinup the drive using the pass > device (which succeeded) caused the drive to become `half-known', as a > subsequent camcontrol devlist seems to confirm (device assigned to > pass4, but not to any other driver). A following camcontrol rescan > didn't notice it as a new entry, so nothing happened. > > I played a little, turned off the drive, camcontrol rescan so it had > to remove the entry completely. Then turned on the drive again (which > also causes it to spin up), and voilá, the next camcontrol rescan > makes the drive accessible as both, pass4 and da2. Hmm, yeah, could be something like that. The pass device will attach to anything that responds to an inquiry. You wouldn't have been able to spin up the drive using the pass driver if the pass driver weren't attached. You're correct -- when you did a rescan, since there was no new device found, it didn't broadcast a "found device" async callback, so no new peripheral drivers attached. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 15:47: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id AA2D214C5A for ; Sun, 14 Mar 1999 15:47:04 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id QAA14931; Sun, 14 Mar 1999 16:46:41 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903142346.QAA14931@panzer.plutotech.com> Subject: Re: error messages from bt driver In-Reply-To: <19990314162542.C11051@milf18.bus.net> from "Chuck O'Donnell" at "Mar 14, 1999 4:25:42 pm" To: cao@bus.net (Chuck O'Donnell) Date: Sun, 14 Mar 1999 16:46:41 -0700 (MST) Cc: gibbs@pluto.plutotech.com, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chuck O'Donnell wrote... > On Sat, Mar 13, 1999 at 05:44:29PM -0700, Justin T. Gibbs wrote: > > >Thanks for the reply Justin. > > > > > >I tried 5.06I from the Mylex site, but no improvement. Same error > > >messages show up. Any thoughts on other things I can check? > > > > > >Thanks. > > > > > >Chuck > > > > One thing I don't know about on the MultiMasters is how they deal > > with a disk returning queue full status. Your Seagate will only > > handle 64 commands at a time, but we've queued up 191 to the > > Buslogic. Perhaps it will not release the mailbox for a transaction > > that is in the queue full state? This would cause the first error > > message to occur. My guess is that a quirk entry in sys/cam/cam_xpt.c > > limiting the number of tags for your drive to 64 will prevent the > > problem from happening. > > Okay, it looks like that did the trick. I reinstalled the original > flash bios (5.07B), edited sys/cam/cam_xpt.c (see attached diffs for > quirk entry below), and rebuilt the kernel. > > I don't know if there is a good known way to overload the queue for > testing, but since the daily script seems to be a repeatable way to > trigger the problem, I have been using it as a test by running it 10 > times consecutively. > > Q: Is there any way to query the driver to find out how many tags are > currently enabled for the drive? e.g., a camcontrol(8) option or some > such? After I rebuilt the kernel and rebooted I couldn't tell for sure > if the drive inquiry data had matched my new quirk entry and correctly > adjusted the queue size for the drive. Yes, I've got some camcontrol mods that will do that for you. Grab the patches from here: http://www.FreeBSD.ORG/~ken/camcontrol.diffs.031499 Type 'camcontrol tags -n da -u 4' (where "4" is the unit number of the disk in question) to find out how many tags are allowed for that device. camcontrol tags -v will give you more detailed information. > Attached below is a diff for the quirk, can you take a look and make > sure I did it correctly? I would set the minimum to 2, but if the controller never tells us that the queue is full for the drive in question, you'll never get down that low.. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 17:45:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id A8A6715B54 for ; Sun, 14 Mar 1999 17:45:13 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id UAA13298; Sun, 14 Mar 1999 20:44:49 -0500 (EST) Date: Sun, 14 Mar 1999 20:44:49 -0500 (EST) From: "Matthew N. Dodd" To: Joerg Wunsch Cc: FreeBSD SCSI list Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <19990314084849.47902@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, J Wunsch wrote: > Well, as i wrote in the other message, i'm now (finally) also with CAM > at home. Basically, everything's working fine so far. (Unlike what > Ken wrote, i can't confirm the problems with the IBM DCAS with tagged > queuing, but i'll try to collect bonnie and iozone data first.) > > Well, the subject says what's not working yet: my old SONY MO drive. > Upon booting, i get (after a rather long timeout, i. e. while the > system is already proceeding with the boot): I can't get the device to attach to the DA driver unless a platter is loaded. My C1716T and C1716C don't have this problem but the 2 SMO-C501-00s and the 2 SMO-C501-25s (With HP firmware) in my library do. > (da2:ncr1:0:3:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da2:ncr1:0:3:0): NOT READY asc:4,0 > (da2:ncr1:0:3:0): Logical unit not ready, cause not reportable > (da2:ncr1:0:3:0): fatal error, failed to attach to device > (da2:ncr1:0:3:0): lost device > (da2:ncr1:0:3:0): removing device entry > > Hmm, yes, the drive ain't spinning by that time (i keep it down when > not used), but i was under the impression the probe routine would spin > it up anyway? At least the old od(4) driver did so (and in my hacked > version, automatically brought the drive down when not openened by > anyone.) Hummm. The external I just plugged into my running system (was on the Mac which has problems with it right now. (Damn you Steve Jobs, damn you to hell.)) da5 at dpt0 bus 0 target 4 lun 0 da5: Removable Direct Access SCSI-CCS device da5: 281MB (576999 512 byte sectors: 64H 32S/T 281C) > I can then spin it up manually using the associated pass device, but a > `camcontrol rescan' doesn't get it back as a `da2' as i would have > expected. Here's all i could get so far: Indeed. Same problem when I plug it in and rescan without a platter. > uriah # camcontrol inquiry -n pass -u 4 > Removable Direct Access SCSI-CCS device > Serial Number 0.0MB/s transfers > uriah # camcontrol start -n pass -u 4 > Unit started successfully > uriah # camcontrol tur -n pass -u 4 > Unit is ready > uriah # camcontrol rescan 1 > Re-scan of bus 1 was successful > uriah # camcontrol rescan 0 > Re-scan of bus 0 was successful > uriah # camcontrol devlist > < > at scbus-1 target -1 lun -1 (xpt0) > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 2 lun 0 (pass1,cd0) > at scbus0 target 4 lun 0 (pass2,sa0) > < > at scbus0 target -1 lun -1 () > at scbus1 target 1 lun 0 (pass3,da1) > at scbus1 target 3 lun 0 (pass4) > < > at scbus1 target -1 lun -1 () > > Does anybody have a hint, maybe an idea for the quirk entry that's > required in order to get the drive working? (Yes, it's SCSI-CCS only, > and it actually ain't even a SCSI drive, but rather an ESDI-to-SCSI > bridge. :) You wouldn't happen to have the docs on the bridge would you? -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 18: 3:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 5044415247 for ; Sun, 14 Mar 1999 18:03:22 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id VAA13573; Sun, 14 Mar 1999 21:02:54 -0500 (EST) Date: Sun, 14 Mar 1999 21:02:54 -0500 (EST) From: "Matthew N. Dodd" To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <19990314142415.23439@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, J Wunsch wrote: > Thanks!, i was hoping for some advice like this. (Btw., it's IMHO > safe to only test for SONY SMO-*, they are all such old devices.) Just different names in the firmware for the same bridge/mechanism. > Alas, it doesn't work. :( Right after probing the CD-ROM drive (which > is on the other bus), it now jams its SCSI bus. > > (The following has been written on a sheet of paper, so typos are > mine.) > > ncr1: SCSI phase error fixup: CCB already dequeued (0xc07b0000) > ncr1: timeout nccb=0xc07b0000 (skip) > ncr1: timeout nccb=0xc07b0000 (skip) > ncr1: timeout nccb=0xc07b0000 (skip) > (da2:ncr1:0:3:0) got CAM status 0x4b > (da2:ncr1:0:3:0) fatal error, failed to attach device > (da2:ncr1:0:3:0) lost device > (da2:ncr1:0:3:0) removing device entry > > At this point, the system effectively halts. Upon waiting > indefinitely, it would eventually timeout a few more CCBs, but i lost > my patience and hit reset. > > With a spinning medium in the drive, it boots well (and da2 even > `arrives' before da1). > > > I'm not sure why the da driver didn't attach when you rescanned the > > drive. I'd have to think on that to figure it out, and it's too > > late for thinking too much. :) > > Understood. > > My suspicion (just guessing, i don't have an idea of the program flow > in the CAM code) is that my attempt to spinup the drive using the pass > device (which succeeded) caused the drive to become `half-known', as a > subsequent camcontrol devlist seems to confirm (device assigned to > pass4, but not to any other driver). A following camcontrol rescan > didn't notice it as a new entry, so nothing happened. > > I played a little, turned off the drive, camcontrol rescan so it had > to remove the entry completely. Then turned on the drive again (which > also causes it to spin up), and voilá, the next camcontrol rescan > makes the drive accessible as both, pass4 and da2. Same thing I get. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 18:15:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from milf18.bus.net (milf18.bus.net [207.41.25.18]) by hub.freebsd.org (Postfix) with ESMTP id 035841580E for ; Sun, 14 Mar 1999 18:15:29 -0800 (PST) (envelope-from cao@milf18.bus.net) Received: (from cao@localhost) by milf18.bus.net (8.8.8/8.8.8) id VAA13655; Sun, 14 Mar 1999 21:14:54 -0500 (EST) (envelope-from cao) Date: Sun, 14 Mar 1999 21:14:54 -0500 From: "Chuck O'Donnell" To: "Kenneth D. Merry" Cc: scsi@FreeBSD.ORG Subject: Re: error messages from bt driver Message-ID: <19990314211454.A13537@milf18.bus.net> References: <19990314162542.C11051@milf18.bus.net> <199903142346.QAA14931@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199903142346.QAA14931@panzer.plutotech.com>; from Kenneth D. Merry on Sun, Mar 14, 1999 at 04:46:41PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Mar 14, 1999 at 04:46:41PM -0700, Kenneth D. Merry wrote: > Chuck O'Donnell wrote... > > > > Q: Is there any way to query the driver to find out how many tags are > > currently enabled for the drive? e.g., a camcontrol(8) option or some > > such? After I rebuilt the kernel and rebooted I couldn't tell for sure > > if the drive inquiry data had matched my new quirk entry and correctly > > adjusted the queue size for the drive. > > Yes, I've got some camcontrol mods that will do that for you. Grab the > patches from here: > > http://www.FreeBSD.ORG/~ken/camcontrol.diffs.031499 > > Type 'camcontrol tags -n da -u 4' (where "4" is the unit number of > the disk in question) to find out how many tags are allowed for that > device. > > camcontrol tags -v will give you more detailed information. > Works great! thanks. > > Attached below is a diff for the quirk, can you take a look and make > > sure I did it correctly? > > I would set the minimum to 2, but if the controller never tells us > that the queue is full for the drive in question, you'll never get > down that low.. I haven't quite figured out exactly what mintags does in the big picture yet, still reading through the code and doc. I think I found where it is used in cam_periph.c, I'll look more tomorrow. Thanks again. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 18:48:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id A9E1C154AB for ; Sun, 14 Mar 1999 18:48:48 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id TAA16122; Sun, 14 Mar 1999 19:48:27 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903150248.TAA16122@panzer.plutotech.com> Subject: Re: error messages from bt driver In-Reply-To: <19990314211454.A13537@milf18.bus.net> from "Chuck O'Donnell" at "Mar 14, 1999 9:14:54 pm" To: cao@bus.net (Chuck O'Donnell) Date: Sun, 14 Mar 1999 19:48:27 -0700 (MST) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chuck O'Donnell wrote... > On Sun, Mar 14, 1999 at 04:46:41PM -0700, Kenneth D. Merry wrote: > > Chuck O'Donnell wrote... > > > Attached below is a diff for the quirk, can you take a look and make > > > sure I did it correctly? > > > > I would set the minimum to 2, but if the controller never tells us > > that the queue is full for the drive in question, you'll never get > > down that low.. > > I haven't quite figured out exactly what mintags does in the big > picture yet, still reading through the code and doc. I think I found > where it is used in cam_periph.c, I'll look more tomorrow. mintags is the hard minimum for the number of oustanding tags for a given device. If you look at the quirk entries for the Quantum Atlas II drives, you'll notice that the maximum is 32, and the minimum is 24. That's because the Atlas II continually returns queue full, until we have reached the minimum. So, we set the minimum to 24, and then just retry if we get a queue full and we're already at the minimum. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 20: 7:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 649DD14EB7 for ; Sun, 14 Mar 1999 20:07:46 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id VAA16427; Sun, 14 Mar 1999 21:07:15 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903150407.VAA16427@panzer.plutotech.com> Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: from "Matthew N. Dodd" at "Mar 14, 1999 8:44:49 pm" To: winter@jurai.net (Matthew N. Dodd) Date: Sun, 14 Mar 1999 21:07:15 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew N. Dodd wrote... > On Sun, 14 Mar 1999, J Wunsch wrote: > > Well, as i wrote in the other message, i'm now (finally) also with CAM > > at home. Basically, everything's working fine so far. (Unlike what > > Ken wrote, i can't confirm the problems with the IBM DCAS with tagged > > queuing, but i'll try to collect bonnie and iozone data first.) > > > > Well, the subject says what's not working yet: my old SONY MO drive. > > Upon booting, i get (after a rather long timeout, i. e. while the > > system is already proceeding with the boot): > > I can't get the device to attach to the DA driver unless a platter is > loaded. My C1716T and C1716C don't have this problem but the 2 > SMO-C501-00s and the 2 SMO-C501-25s (With HP firmware) in my library do. Do you get any error messages back when the da driver fails to attach? My guess is that the device may be sending back a non-standard "medium not present" error code. If that is the case, we can either quirk it or put it in as an acceptable error code and continue the attach. I had a similar situation pop up with the CD driver. It turns out that there are some Philips/HP CD-R drives that return 0x04,* when there is no media in them. So an Additional Sense Code of 0x04 is acceptable to the CD driver on probe now, and it will still attach. > > (da2:ncr1:0:3:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > > (da2:ncr1:0:3:0): NOT READY asc:4,0 > > (da2:ncr1:0:3:0): Logical unit not ready, cause not reportable > > (da2:ncr1:0:3:0): fatal error, failed to attach to device > > (da2:ncr1:0:3:0): lost device > > (da2:ncr1:0:3:0): removing device entry > > > > Hmm, yes, the drive ain't spinning by that time (i keep it down when > > not used), but i was under the impression the probe routine would spin > > it up anyway? At least the old od(4) driver did so (and in my hacked > > version, automatically brought the drive down when not openened by > > anyone.) > > Hummm. The external I just plugged into my running system (was on the > Mac which has problems with it right now. (Damn you Steve Jobs, damn you > to hell.)) > da5 at dpt0 bus 0 target 4 lun 0 > da5: Removable Direct Access SCSI-CCS device > da5: 281MB (576999 512 byte sectors: 64H 32S/T 281C) > > > I can then spin it up manually using the associated pass device, but a > > `camcontrol rescan' doesn't get it back as a `da2' as i would have > > expected. Here's all i could get so far: > > Indeed. Same problem when I plug it in and rescan without a platter. I suspect that i just misinterpreted what Joerg was saying. I thought that he meant that the above error (0x04,0x00) came up when there was a disc inserted, but it wasn't spinning. Did he really mean that the above error happens when there is no disc inserted? (i.e. medium not present) I'm sure we can get the thing working properly, if I can just get a handle on what error codes the device returns for these two situations: - no disc in the drive - disc is in, but isn't spinning Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 20:32:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from duey.wolves.k12.mo.us (duey.wolves.k12.mo.us [207.160.214.9]) by hub.freebsd.org (Postfix) with ESMTP id 651CE1506C for ; Sun, 14 Mar 1999 20:32:18 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from duey.wolves.k12.mo.us (cdillon@duey.wolves.k12.mo.us [207.160.214.9]) by duey.wolves.k12.mo.us (8.8.8/8.8.8) with ESMTP id WAA04819; Sun, 14 Mar 1999 22:31:55 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Sun, 14 Mar 1999 22:31:55 -0600 (CST) From: Chris Dillon To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam cam_xpt.c In-Reply-To: <19990314201946.00024@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, J Wunsch wrote: > As Jean-Marc Zucconi wrote: > > > Yes this is very poor for a wide drive. On my narrow DCAS-34330: > > Writing the 250 Megabyte file, 'iozone.tmp'...80.351562 seconds > > Reading the file...38.601562 seconds > > > > IOZONE performance measurements: > > 3262463 bytes/second for writing the file > > 6791020 bytes/second for reading the file > > I get about 4.4 MB/s writing and 5.8 MB/s reading, with tagged queuing > still enabled. I also get better bonnie figures than those mentioned > in PR kern/10398, about 4 MB/s `Per Char' and 5 MB/s `Block'. > > However, as Ken already mentioned, see the audit-trail from PR 10398 > for a counterexample. I just did some tests with tagging totally disabled, enabled, and with only 2 tags. This is long. Sorry in advance for the messy wrapping. Hopefully everybody can parse it... da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Without tagged queueing - single drive: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 200 4742 96.0 7154 47.3 2540 20.1 5739 95.7 7422 30.2 91.7 4.4 IOZONE performance measurements: 6816542 bytes/second for writing the file 7593647 bytes/second for reading the file Without tagged queueing - 64 block striped ccd partition: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 200 4499 95.5 9556 86.6 3383 30.5 5537 93.8 12330 65.7 133.9 6.6 IOZONE performance measurements: 6629672 bytes/second for writing the file 11590477 bytes/second for reading the file da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) With tagged queueing - single drive: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 200 4883 97.0 4103 25.8 2263 23.6 5789 95.8 7420 32.4 99.6 4.8 IOZONE performance measurements: 6839119 bytes/second for writing the file 7425600 bytes/second for reading the file With tagged queueing - 64 block striped ccd partition: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 200 4570 96.2 6725 55.1 2534 23.0 5575 94.0 11776 65.2 148.3 7.5 IOZONE performance measurements: 6687480 bytes/second for writing the file 11481413 bytes/second for reading the file da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) With tagged queueing (min/max 2 tags) - single drive: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 200 4882 97.1 6961 46.4 2897 24.1 5761 95.6 7427 32.7 100.9 4.6 IOZONE performance measurements: 6759895 bytes/second for writing the file 7600097 bytes/second for reading the file With tagged queueing (min/max 2 tags) - 64 block striped ccd partition: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 200 4562 96.5 9323 86.9 3275 30.4 5663 95.1 12382 68.4 143.2 7.1 IOZONE performance measurements: 6603578 bytes/second for writing the file 11226911 bytes/second for reading the file By these measurements, completely turning off tagging helped certain write scenarios and hurt others. You'll notice, however, 2 tags gained almost as much performance increase as disabling them totally, and didn't hurt the other scenarios as much. 2 tags may not be be the optimal selection... its just a starting point that I used, after noticing some Seagate drives had similar quirks. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net /* FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and compatibles (SPARC and Alpha under development) ( http://www.freebsd.org ) */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 21:23:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 40CFD14EEE for ; Sun, 14 Mar 1999 21:23:47 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id AAA15469; Mon, 15 Mar 1999 00:23:24 -0500 (EST) Date: Mon, 15 Mar 1999 00:23:24 -0500 (EST) From: "Matthew N. Dodd" To: "Kenneth D. Merry" Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <199903150407.VAA16427@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, Kenneth D. Merry wrote: > I'm sure we can get the thing working properly, if I can just get a handle > on what error codes the device returns for these two situations: > > - no disc in the drive eisa-test# camcontrol rescan 2 (da5:dpt0:0:3:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da5:dpt0:0:3:0): NOT READY asc:a,0 (da5:dpt0:0:3:0): Error log overflow (da5:dpt0:0:3:0): fatal error, failed to attach to device (da5:dpt0:0:3:0): lost device (da5:dpt0:0:3:0): removing device entry eisa-test# camcontrol devlist ... at scbus2 target 3 lun 0 (pass13) ... > - disc is in, but isn't spinning eisa-test# camcontrol stop -n pass -u 13 Unit stopped successfully eisa-test# camcontrol rescan 2 eisa-test# camcontrol rescan 2 da5 at dpt0 bus 0 target 3 lun 0 da5: Removable Direct Access SCSI-CCS device da5: 281MB (576999 512 byte sectors: 64H 32S/T 281C) eisa-test# camcontrol tur -n da -u 5 Unit is not ready eisa-test# camcontrol start -n da -u 5 Unit started successfully This only means that the drive remembered the capacity of the disk I had in before I spun the disk down. My unit automatically spins up the platter when I insert it so I'm not sure I'll be able to provide you with a test of the rescan with the unit stopped. :/ Any specific commands you want me to test? I'm guessing I should compile CAMDEBUG into the kernel if I'm to be of any use to you. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 21:48:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 5027514CD5 for ; Sun, 14 Mar 1999 21:48:52 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id WAA17045; Sun, 14 Mar 1999 22:48:27 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903150548.WAA17045@panzer.plutotech.com> Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: from "Matthew N. Dodd" at "Mar 15, 1999 0:23:24 am" To: winter@jurai.net (Matthew N. Dodd) Date: Sun, 14 Mar 1999 22:48:27 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew N. Dodd wrote... > On Sun, 14 Mar 1999, Kenneth D. Merry wrote: > > I'm sure we can get the thing working properly, if I can just get a handle > > on what error codes the device returns for these two situations: > > > > - no disc in the drive > > eisa-test# camcontrol rescan 2 > > (da5:dpt0:0:3:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da5:dpt0:0:3:0): NOT READY asc:a,0 > (da5:dpt0:0:3:0): Error log overflow > (da5:dpt0:0:3:0): fatal error, failed to attach to device > (da5:dpt0:0:3:0): lost device > (da5:dpt0:0:3:0): removing device entry I must say, that is truly bizarre. Well, here's a quick and dirty way to make the drive attach without media present. In scsi_da.c, in the DA_CCB_PROBE case of dadone(), you'll see an if statement. Make it look like this: ================================================= /* * With removable media devices, we expect * 0x3a (Medium not present) errors, since not * everyone leaves a disk in the drive. If * the error is anything else, though, we * shouldn't attach. */ if ((have_sense) && ((asc == 0x3a) || (asc == 0xa)) && (error_code == SSD_CURRENT_ERROR)) snprintf(announce_buf, sizeof(announce_buf), "Attempt to query device " "size failed: %s, %s", scsi_sense_key_text[sense_key], scsi_sense_desc(asc,ascq, &cgd.inq_data)); else { ================================================= i.e., just add the asc == 0xa part in. That isn't the best solution for the problem, certainly. A more permanent solution will require some more work. I've got two ideas that would fix it, but I'll have to think about which one would be the best. I don't think it's a good idea to have 0xa be an "acceptable" error code for the da driver in the general case. It's fine for this special case, but I'd rather not enable it for all devices. > eisa-test# camcontrol devlist > ... > at scbus2 target 3 lun 0 (pass13) > ... > > > - disc is in, but isn't spinning > > > eisa-test# camcontrol stop -n pass -u 13 > Unit stopped successfully > > eisa-test# camcontrol rescan 2 > > eisa-test# camcontrol rescan 2 > > da5 at dpt0 bus 0 target 3 lun 0 > da5: Removable Direct Access SCSI-CCS device > da5: 281MB (576999 512 byte sectors: 64H 32S/T 281C) > eisa-test# camcontrol tur -n da -u 5 > Unit is not ready > > eisa-test# camcontrol start -n da -u 5 > > Unit started successfully > > This only means that the drive remembered the capacity of the disk I had > in before I spun the disk down. My unit automatically spins up the > platter when I insert it so I'm not sure I'll be able to provide you with > a test of the rescan with the unit stopped. :/ Hmm, oh well. Well, maybe Joerg's behaves differently. Perhaps he can boot his system without the disc spinning. > Any specific commands you want me to test? I'm guessing I should compile > CAMDEBUG into the kernel if I'm to be of any use to you. Well, I think I've got a handle on things I suppose. Does the drive return the 0xa error on boot when there is no media inserted? What I want to make sure of is that the "Error log overflow" error wasn't brought on somehow by inserting/removing the device from the bus or from some other activity. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 22:46:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 8907614F9A for ; Sun, 14 Mar 1999 22:46:23 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id BAA16230; Mon, 15 Mar 1999 01:46:01 -0500 (EST) Date: Mon, 15 Mar 1999 01:46:00 -0500 (EST) From: "Matthew N. Dodd" To: "Kenneth D. Merry" Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <199903150548.WAA17045@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 14 Mar 1999, Kenneth D. Merry wrote: > i.e., just add the asc == 0xa part in. Indeed. > That isn't the best solution for the problem, certainly. A more > permanent solution will require some more work. I've got two ideas > that would fix it, but I'll have to think about which one would be the > best. > > I don't think it's a good idea to have 0xa be an "acceptable" error > code for the da driver in the general case. It's fine for this > special case, but I'd rather not enable it for all devices. Agree. > Hmm, oh well. Well, maybe Joerg's behaves differently. Perhaps he can > boot his system without the disc spinning. Its probably a DIP switch setting. I've no doc for the drives and controller. > > Any specific commands you want me to test? I'm guessing I should compile > > CAMDEBUG into the kernel if I'm to be of any use to you. > > Well, I think I've got a handle on things I suppose. Does the drive > return the 0xa error on boot when there is no media inserted? What I > want to make sure of is that the "Error log overflow" error wasn't > brought on somehow by inserting/removing the device from the bus or > from some other activity. I'm fairly sure it does but I've not rebooted the box with the drive attached. I'll do so when I get a chance. I've almost half a mind to ship you my spare but its not in an enclosure and I really would rather have an extra in case one of the ones in the library decides to go south. I'll see if I can't pick up another one and a media cart this week so I can ship you one. Or we can wait a few weeks until the box is on net and I give you a sandbox account to play around in. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 23:51: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id 766931517B for ; Sun, 14 Mar 1999 23:50:30 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA15520 for freebsd-scsi@FreeBSD.ORG; Mon, 15 Mar 1999 08:50:11 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id IAA21914; Mon, 15 Mar 1999 08:39:37 +0100 (MET) (envelope-from j) Message-ID: <19990315083937.29224@uriah.heep.sax.de> Date: Mon, 15 Mar 1999 08:39:37 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM Reply-To: Joerg Wunsch References: <19990314142415.23439@uriah.heep.sax.de> <199903142342.QAA14908@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199903142342.QAA14908@panzer.plutotech.com>; from Kenneth D. Merry on Sun, Mar 14, 1999 at 04:42:06PM -0700 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 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote: > Well, to avoid having to send the patches to too many more people, > I've put them here: > http://www.FreeBSD.ORG/~ken/camcontrol.diffs.031499 (OK, will have to test this later on.) > Right, media should not be required. What we *do* require is that > the device tell us in some intelligible way that there is no media > in it. Hmm, what we'd probably need here is a document describing the SCSI CCS. See my below. > Hmm. The CAM status 0x4b means that the command timed out, and that > the queue for that device was frozen. I don't know why it hung your > system. Weird. Is there any way to further debug this. > Okay, let me see if I've got this straight: > > - It works with media in the drive and spinning. Yep. > - If there is no media in the drive, it doesn't work. What happens > in this case? I didn't test myself, but it probably won't attach. Here's the result i get from an attempted `start' command without a medium: uriah # camcontrol tur -v -u 2 Unit is not ready (pass4:ncr1:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (pass4:ncr1:0:3:0): NOT READY asc:a,0 (pass4:ncr1:0:3:0): Error log overflow Right now that i see it, i can remember i've seen the `Error log overflow' before. > - If there is media in the drive that isn't spinning, and you've got > the quirk entry in scsi_all.c, the spinup command may be timing > out. Yep, although camcontrol's spinup command would work later. > How long does the start unit command take for that drive? A few seconds, about 5 to 10 if the medium is (optically) clean. In the case of an unclean medium, it might take up to one minute approximately, until the drive will eject the medium. > The timeout for the start unit command in the error recovery code > is 50 seconds. (The start unit is done in cam_periph.c) That should suffice. Btw., IIRC the medium did _not_ spin up in the case where it hung the bus, so the START STOP UNIT command apparently didn't make it to the drive. -- 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. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 14 23:51:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id A0D56151A8 for ; Sun, 14 Mar 1999 23:50:34 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA15521 for freebsd-scsi@FreeBSD.ORG; Mon, 15 Mar 1999 08:50:15 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id IAA21929; Mon, 15 Mar 1999 08:42:00 +0100 (MET) (envelope-from j) Message-ID: <19990315084159.51913@uriah.heep.sax.de> Date: Mon, 15 Mar 1999 08:41:59 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM Reply-To: Joerg Wunsch References: <199903150407.VAA16427@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199903150407.VAA16427@panzer.plutotech.com>; from Kenneth D. Merry on Sun, Mar 14, 1999 at 09:07:15PM -0700 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 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote: > If that is the case, we can either quirk it or put it in as an > acceptable error code and continue the attach. I had a similar > situation pop up with the CD driver. It turns out that there are > some Philips/HP CD-R drives that return 0x04,* when there is no > media in them. So an Additional Sense Code of 0x04 is acceptable to > the CD driver on probe now, and it will still attach. As shown in the other mail, it's 0x0a, 0x00. That's certainly worth a quirk entry, since it's too far off from the SCSI-2 standard response. > I suspect that i just misinterpreted what Joerg was saying. I > thought that he meant that the above error (0x04,0x00) came up when > there was a disc inserted, but it wasn't spinning. Yep, that was my (first) case. -- 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. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 15 3:29:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rose.niw.com.au (app3022-2.gw.connect.com.au [203.63.119.4]) by hub.freebsd.org (Postfix) with ESMTP id 2429614CE2 for ; Mon, 15 Mar 1999 03:29:29 -0800 (PST) (envelope-from ian@apdata.com.au) Received: from apdata.com.au (localhost [127.0.0.1]) by rose.niw.com.au (Postfix) with ESMTP id 617B2A372B for ; Mon, 15 Mar 1999 21:59:10 +1030 (CST) Message-ID: <36ECEF06.80D63F63@apdata.com.au> Date: Mon, 15 Mar 1999 21:59:10 +1030 From: Ian West Organization: Applied Data Control X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: cam_periph_mapmem: attempt to map 66560 bytes, which is greater than DFLTPHYS(65536) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have the following error when trying to write a cd using the latest version of cdrecord (1.8a17). I worked around it by (probably wrongly, but it works) doubling the sizes of DFLTPHYS, and MAXPHYS in src/i386/param.h. The system is running fine, and it allowed me to write my cd. cam_periph_mapmem: attempt to map 66560 bytes, which is greater than DFLTPHYS(65536) Looking into this for a 'proper' answer, the section of code in cam_periph (line 552) which seems to relate is below... if ((lengths[i] + (((vm_offset_t)(*data_ptrs[i])) & PAGE_MASK)) > DFLTPHYS){ printf("cam_periph_mapmem: attempt to map %u bytes, " "which is greater than DFLTPHYS(%d)\n", lengths[i] + (((vm_offset_t)(*data_ptrs[i])) & PAGE_MASK), DFLTPHYS); return(E2BIG); seems to be where the error is ocuring. As I understand it, this allows for the possibility of having the users buffer offset from the start of a page. If the user is allowed to request up to DFLTPHYS bytes of transfer, should the comparison not be for MAXPHYS ? Am I missing the point completely ? Is this simply a code error in cdrecord ? Thankyou... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 15 8:49: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F2E6150AF for ; Mon, 15 Mar 1999 08:46:23 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id JAA19568; Mon, 15 Mar 1999 09:45:57 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903151645.JAA19568@panzer.plutotech.com> Subject: Re: cam_periph_mapmem: attempt to map 66560 bytes, which is greater than DFLTPHYS(65536) In-Reply-To: <36ECEF06.80D63F63@apdata.com.au> from Ian West at "Mar 15, 1999 9:59:10 pm" To: ian@apdata.com.au (Ian West) Date: Mon, 15 Mar 1999 09:45:57 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ian West wrote... > I have the following error when trying to write a cd using the latest > version of cdrecord (1.8a17). The latest version of cdrecord is 1.8a19. Joerg fixed this bug in that release: ============================ - Fixed a bug with non page aligned buffers if the FIFO was present. This caused problems with FreeBSD/current/CAM due to the fact that the max. number of DMA pages was exceeded. ============================ Thanks to Bjoern Fischer for figuring it out. > I worked around it by (probably wrongly, > but it works) doubling the sizes of DFLTPHYS, and MAXPHYS in > src/i386/param.h. The system is running fine, and it allowed me to write > my cd. Well, you can do that, but that's not the "right" thing to do, really. And it probably would have broken again if you recompiled cdrecord using the new value for DFLTPHYS. > cam_periph_mapmem: attempt to map 66560 bytes, which is greater than > DFLTPHYS(65536) > > Looking into this for a 'proper' answer, the section of code in > cam_periph (line 552) which seems to relate is below... > > if ((lengths[i] + > (((vm_offset_t)(*data_ptrs[i])) & PAGE_MASK)) > DFLTPHYS){ > printf("cam_periph_mapmem: attempt to map %u bytes, " > "which is greater than DFLTPHYS(%d)\n", > lengths[i] + > (((vm_offset_t)(*data_ptrs[i])) & PAGE_MASK), > DFLTPHYS); > return(E2BIG); > > seems to be where the error is ocuring. As I understand it, this allows > for the possibility of having the users buffer offset from the start of > a page. If the user is allowed to request up to DFLTPHYS bytes of > transfer, should the comparison not be for MAXPHYS ? > Am I missing the point completely ? I think so. The comparison needs to be against DFLTPHYS, because there are some controllers (e.g. the Adaptec 1542) that cannot handle transfer sizes greater than 64k. When userland buffers are mapped into the kernel, they will be truncated to start on a page boundary if they do not already start on a page boundary. If you've got a buffer that is 64k long that does not start on a page boundary, it will end up taking up more than 64k. Eventually we plan on adding fields to the path inquiry (XPT_PATH_INQ) CCB that will specify the maximum transfer size allowed by the controller and the maximum allowed by the system. (or something along those lines) Then userland programs will be able to inquire what the maximum transfer size is for a given device. If we can get some sort of buffer chaining system in place, the limiting factor will be the controller. This will also be helpful for people who want to read/write tapes with large block sizes. You can do it now by changing DFLTPHYS/MAXPHYS, but it would be easier if it just worked by default. > Is this simply a code error in > cdrecord ? Yes. cdrecord wasn't page-aligning all of its transfers, and was using the full DFLTPHYS transfer size. So some buffers, once they were truncated to a page boundary, exceeded DFLTPHYS. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 15 10:12:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id B2A01153FE for ; Mon, 15 Mar 1999 10:12:41 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from herkules.siemens.de (herkules.siemens.de [139.23.33.14]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id TAA09370 for ; Mon, 15 Mar 1999 19:12:20 +0100 (MET) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [146.180.31.23]) by herkules.siemens.de (8.9.3/8.9.3) with ESMTP id TAA02199 for ; Mon, 15 Mar 1999 19:12:37 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id TAA08367 for ; Mon, 15 Mar 1999 19:12:21 +0100 (CET) Date: Mon, 15 Mar 1999 19:12:20 +0100 From: Andre Albsmeier To: "Kenneth D. Merry" Cc: Ian West , freebsd-scsi@FreeBSD.ORG Subject: Re: cam_periph_mapmem: attempt to map 66560 bytes, which is greater than DFLTPHYS(65536) Message-ID: <19990315191220.A1300@internal> References: <36ECEF06.80D63F63@apdata.com.au> <199903151645.JAA19568@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199903151645.JAA19568@panzer.plutotech.com>; from Kenneth D. Merry on Mon, Mar 15, 1999 at 09:45:57AM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 15-Mar-1999 at 09:45:57 -0700, Kenneth D. Merry wrote: > Ian West wrote... > > I have the following error when trying to write a cd using the latest > > version of cdrecord (1.8a17). > > The latest version of cdrecord is 1.8a19. Joerg fixed this bug in that > release: Any known reason why the port is still at cdrecord-1.6.1 ? Just wondering, -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 15 10:24:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id EA2F0154A9 for ; Mon, 15 Mar 1999 10:24:37 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id LAA20107; Mon, 15 Mar 1999 11:22:10 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903151822.LAA20107@panzer.plutotech.com> Subject: Re: cam_periph_mapmem: attempt to map 66560 bytes, which is greater than DFLTPHYS(65536) In-Reply-To: <19990315191220.A1300@internal> from Andre Albsmeier at "Mar 15, 1999 7:12:20 pm" To: andre.albsmeier@mchp.siemens.de (Andre Albsmeier) Date: Mon, 15 Mar 1999 11:22:10 -0700 (MST) Cc: ian@apdata.com.au, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andre Albsmeier wrote... > On Mon, 15-Mar-1999 at 09:45:57 -0700, Kenneth D. Merry wrote: > > Ian West wrote... > > > I have the following error when trying to write a cd using the latest > > > version of cdrecord (1.8a17). > > > > The latest version of cdrecord is 1.8a19. Joerg fixed this bug in that > > release: > > Any known reason why the port is still at cdrecord-1.6.1 ? > Probably because that was the last release. The 1.8 series is still in alpha. If you think this should change, you can talk to Jean-Marc (the maintainer) about it. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 15 11:50:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id DB3CA151C8 for ; Mon, 15 Mar 1999 11:50:27 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id UAA26340 for freebsd-scsi@FreeBSD.ORG; Mon, 15 Mar 1999 20:50:07 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id UAA23405; Mon, 15 Mar 1999 20:37:47 +0100 (MET) (envelope-from j) Message-ID: <19990315203746.43024@uriah.heep.sax.de> Date: Mon, 15 Mar 1999 20:37:46 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM Reply-To: Joerg Wunsch References: <199903150548.WAA17045@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Matthew N. Dodd on Mon, Mar 15, 1999 at 01:46:00AM -0500 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 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew N. Dodd wrote: > > Hmm, oh well. Well, maybe Joerg's behaves differently. Perhaps > > he can boot his system without the disc spinning. > Its probably a DIP switch setting. I've no doc for the drives and > controller. I don't have docs for it either. Mine was from an old Data General machine (back when their machines were m88k-based). However ISTR you couldn't do that much on the DIP switches anyway. Nope, i get the same results as Matt: 0x0a, 0x00 for no medium in the drive, 0x04, 0x00 for medium not spinning. Both are fatal right now. Perhaps those ASCs were common for SCSI-CCS devices? Anybody around who has old enough docs? -- 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. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 15 21:47:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id AB88F14FD4 for ; Mon, 15 Mar 1999 21:47:42 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from herkules.siemens.de (herkules.siemens.de [139.23.33.14]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id GAA13778 for ; Tue, 16 Mar 1999 06:47:20 +0100 (MET) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [146.180.31.23]) by herkules.siemens.de (8.9.3/8.9.3) with ESMTP id GAA00586 for ; Tue, 16 Mar 1999 06:47:38 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id GAA11652 for ; Tue, 16 Mar 1999 06:47:21 +0100 (CET) Date: Tue, 16 Mar 1999 06:47:20 +0100 From: Andre Albsmeier To: "Kenneth D. Merry" Cc: Andre Albsmeier , freebsd-scsi@FreeBSD.ORG Subject: Re: cam_periph_mapmem: attempt to map 66560 bytes, which is greater than DFLTPHYS(65536) Message-ID: <19990316064720.A1283@internal> References: <19990315191220.A1300@internal> <199903151822.LAA20107@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199903151822.LAA20107@panzer.plutotech.com>; from Kenneth D. Merry on Mon, Mar 15, 1999 at 11:22:10AM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 15-Mar-1999 at 11:22:10 -0700, Kenneth D. Merry wrote: > Andre Albsmeier wrote... > > On Mon, 15-Mar-1999 at 09:45:57 -0700, Kenneth D. Merry wrote: > > > Ian West wrote... > > > > I have the following error when trying to write a cd using the latest > > > > version of cdrecord (1.8a17). > > > > > > The latest version of cdrecord is 1.8a19. Joerg fixed this bug in that > > > release: > > > > Any known reason why the port is still at cdrecord-1.6.1 ? > > > > Probably because that was the last release. The 1.8 series is still in > alpha. I see. > > If you think this should change, you can talk to Jean-Marc (the maintainer) > about it. Hmm, I got no reason to do that. I have no experience with both versions under CAM. I was just wondering... BTW, did you get my message about the JAZ now working really fast under CAM? It still works very well... -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 15 21:52:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A0FC151A8 for ; Mon, 15 Mar 1999 21:52:18 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id WAA23497; Mon, 15 Mar 1999 22:50:26 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903160550.WAA23497@panzer.plutotech.com> Subject: Re: cam_periph_mapmem: attempt to map 66560 bytes, which is greater than DFLTPHYS(65536) In-Reply-To: <19990316064720.A1283@internal> from Andre Albsmeier at "Mar 16, 1999 6:47:20 am" To: andre.albsmeier@mchp.siemens.de (Andre Albsmeier) Date: Mon, 15 Mar 1999 22:50:25 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andre Albsmeier wrote... > On Mon, 15-Mar-1999 at 11:22:10 -0700, Kenneth D. Merry wrote: > > If you think this should change, you can talk to Jean-Marc (the maintainer) > > about it. > > Hmm, I got no reason to do that. I have no experience with both versions > under CAM. I was just wondering... There are advantages to the 1.8 series. It supports DAO (Disk At Once), for instance. And before someone asks me what that is, go look it up.. I'm no expert on recordable CDs. > BTW, did you get my message about the JAZ now working really fast under > CAM? It still works very well... Yes, I did. Thanks for the report. I suppose it could have been VM-related, since nothing changed in CAM that would have caused a performance difference like that. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 15 22: 1:26 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from outreach.wolfnet.org (outreach.wolfnet.org [207.173.133.202]) by hub.freebsd.org (Postfix) with ESMTP id DB0B51509A for ; Mon, 15 Mar 1999 22:01:05 -0800 (PST) (envelope-from jkf@wolfnet.org) Received: from outreach.wolfnet.org ([207.173.133.202]) by outreach.wolfnet.org with esmtp (Exim 2.12 #1) id 10MmuE-0008mj-00 for freebsd-scsi@freebsd.org; Mon, 15 Mar 1999 22:00:46 -0800 Date: Mon, 15 Mar 1999 22:00:45 -0800 (PST) From: "Jason K. Fritcher" To: freebsd-scsi@freebsd.org Subject: Boot-time scsi probe problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello. I am trying to get FreeBSD 3.1-Stable to boot reliably on a machine I have. It was cvsup'ed from Sunday night about 11pm or so. The system was originally installed with the 3.1-19990227 snapshot. I can somewhat reliably boot from the generic kernel included with the snapshot, but I can not boot at all with a kernel compiled from the cvsup. The problems I am having are this. When booting with the generic kernel, the system will boot all the way through if I power-cycle the machine, or reboot it with the reset boot, basically a cold-boot. If I reboot the machine with a warm boot, ie Ctrl-Alt-Del, the system will lockup when it tries to probe the scsi bus for devices. It will wait the 15 seconds for things to settle, and then it locks one the probe starts. I am forced to use the reset button to restart it. With the new kernel, when the machine gets to the probe, it does not lock up, but the probe doesn't work either. It sits there for a few, and then starts giving error messages about timeouts. At the end of the message I have included the entire boot sequence for reference. The hardware I have ia an Asus P2B-LS motherboard with onboard AIC-7890 SCSI controller + 3860 bridge. For those not familiar with the P2B-LS, the SCSI bus is divided into three segments, a U2W, UW, and UN buses. On the U2W bus I have a Quantum Viking II 9.1 GB hard drive in LVD mode, on the UW bus is nothing but a terminator, and on the UN bus is a Plextor 40x cdrom drive. The hard drive is scsi id 0, and the cdrom is scsi id 6. After looking through the archives for anything similar, I came across similar problems which were caused by termination problems. I have checked the termination and all seems well. Any suggestions about what the cause could and possible solutions would be much appriciated. I have spent a good 4-5 hours compiling kernels with different options, and reading through list archives to try and solve this problem. If there is any more information that anyone needs, or have questions, please, write me and I will do what I can. Also, please CC me, as I don't subscribe to this mailing list. Thanx. :) -- Jason K. Fritcher jkf@wolfnet.org This is the kernel config that I am using. # # Architecture type. # machine "i386" # # Identification for kernel. # ident TEST # # Set size of internal tables. # maxusers 25 # # Include this file in the compiled kernel. # Use: strings /kernel | grep ^___ | sed 's/^___//' # options INCLUDE_CONFIG_FILE # # Set kernel name & location. # config kernel root on da0 ##################################################################### # CPU Options # # Specify cpu specs. # cpu "I686_CPU" ##################################################################### # Compatibility Options # # Implement system calls compatible with 4.3BSD and older systems. # options "COMPAT_43" # # This provides support for System V Inter-Process Communications. # options SYSVSHM options SYSVSEM options SYSVMSG options SHMMAXPGS=4096 ##################################################################### # Debugging Options # # Enable the kernel debugger. # options DDB # # Enable the system-call tracing facility. # options KTRACE # # Allow users to take the console. # options UCONSOLE # # Add boot -c editor, and visual boot -c editor. # options USERCONFIG options VISUAL_USERCONFIG ##################################################################### # Networking Options # # Enable IP networking protocols. # options INET # # Network interfaces # The 'loop' pseudo-device is MANDATORY for networking. # The 'ether' pseudo-device provides generic ethernet code. # The 'bpfilter' pseudo-device enables the Berkeley Packet Filter. # pseudo-device loop pseudo-device ether pseudo-device bpfilter 3 # # Include the IP FIREWALL in the kernel. # options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_DEFAULT_TO_ACCEPT ##################################################################### # Filesystem Options # # Mandatory Filesystems. # options FFS # Fast File System # # Optional filesystems. # options "CD9660" # ISO 9660 File System options PROCFS # Process File System options MFS # Memory File System ##################################################################### # Miscellaneous Devices And Options # # The 'pty' pseudo-device is mandatory. # The 'snp' pseudo-device is used to snoop on ttys. # The 'vn' pseudo-device is the vnode device. # The 'gzip' pseudo-device is used to execute gzip'ed binaries. # pseudo-device pty 32 pseudo-device snp 3 pseudo-device vn 3 pseudo-device gzip ##################################################################### # Hardware Device Configuration # # Base ISA controller. # controller isa0 # # Enables 'automatic EOI' for the master/slave interrupt controller. # options "AUTO_EOI_1" options "AUTO_EOI_2" # # syscons is the default console driver, resembling an SCO console # controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device vga0 at isa? port ? conflicts device sc0 at isa? tty options MAXCONS=16 options "SC_HISTORY_SIZE=256" # # Numeric Processing eXtension. # device npx0 at isa? port "IO_NPX" flags 0x0 irq 13 vector npxintr # # Add controller for floppy/tape drives. # controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 disable drive 1 # # Add devices for serial ports. # device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr options CONSPEED=9600 # # Add devices for parallel port(s). # controller ppbus0 device nlpt0 at ppbus? # # Base PCI controller. # controller pci0 # # Adaptec PCI SCSI Controller. # controller ahc0 options "SCSI_DELAY=10000" # # Generic SCSI Bus + devices. # controller scbus0 device da0 # Fixed Disk Device device cd0 # CDROM Device device sa0 # SCSI Tape Device device pass0 # CAM passthrough device # # PCI driver for Intel EtherExpress 10/100Mb ethernet cards. # device fxp0 Here is the boot log, Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-STABLE #0: Mon Mar 15 19:30:09 PST 1999 jkf@test.wolfnet.org:/usr/src/sys/compile/TEST Calibrating clock(s) ... TSC clock: 400915746 Hz, i8254 clock: 1193202 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter "TSC" frequency 400910826 Hz CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x653 Stepping=3 Features=0x183f9ff> real memory = 134217728 (131072K bytes) Physical memory chunk(s): 0x00001000 - 0x0009ffff, 651264 bytes (159 pages) 0x00272000 - 0x07ffdfff, 131645440 bytes (32140 pages) avail memory = 128073728 (125072K bytes) Found BIOS32 Service Directory header at 0xf00f9cf0 Entry = 0xf0520 (0xf00f0520) Rev = 0 Len = 1 PCI BIOS entry at 0x720 DMI header at 0xf00f58f0 Version 2.0 Table at 0xf590a, 32 entries, 1050 bytes Other BIOS signatures found: ACPI: 00000000 $PnP: 000fd120 Preloaded elf kernel "kernel" at 0xf0265000. pci_open(1): mode 1 addr port (0x0cf8) is 0x8000005c pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) Probing for devices on PCI bus 0: found-> vendor=0x8086, dev=0x7190, revid=0x02 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[0]: type 3, range 32, base e4000000, size 26 chip0: rev 0x02 on pci0.0.0 found-> vendor=0x8086, dev=0x7191, revid=0x02 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1 secondarybus=1 chip1: rev 0x02 on pci0.1.0 found-> vendor=0x8086, dev=0x7110, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 chip2: rev 0x02 on pci0.4.0 found-> vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[0]: type 4, range 32, base 0000d800, size 4 found-> vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=d, irq=15 map[0]: type 4, range 32, base 0000d400, size 5 found-> vendor=0x8086, dev=0x7113, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 chip3: rev 0x02 on pci0.4.3 found-> vendor=0x9005, dev=0x001f, revid=0x00 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=15 map[0]: type 4, range 32, base 0000d000, size 8 map[1]: type 1, range 64, base df800000, size 12 map[2]: type 0, range 0, base 00000000, size 0 ahc0: rev 0x00 int a irq 15 on pci0.6.0 ahc0: Reading SEEPROM...done. ahc0: BIOS eeprom not present ahc0: Secondary High byte termination Enabled ahc0: Secondary Low byte termination Enabled ahc0: Primary Low Byte termination Enabled ahc0: Primary High Byte termination Enabled ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc0: Downloading Sequencer Program... 391 instructions downloaded found-> vendor=0x8086, dev=0x1229, revid=0x05 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=10 map[0]: type 3, range 32, base e2000000, size 12 map[1]: type 4, range 32, base 0000b800, size 5 map[2]: type 1, range 32, base df000000, size 20 fxp0: rev 0x05 int a irq 10 on pci0.7.0 fxp0: Ethernet address 00:e0:18:98:0d:91 bpf: fxp0 attached Probing for devices on PCI bus 1: found-> vendor=0x10de, dev=0x0020, revid=0x04 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=11 map[0]: type 1, range 32, base e0000000, size 24 map[1]: type 3, range 32, base e3000000, size 24 vga0: rev 0x04 int a irq 11 on pci1.0.0 Probing for devices on the ISA bus: atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa sc0 on isa sc0: fb0 kbd0 sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa kbd0: atkbd0, AT 101/102 (2), config:0x10000, flags:0x3d0000 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xf00b8000 size:32k gran:32k, buf:0x0 size:0k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff npx0 on motherboard npx0: INT 16 interface imasks: bio c0080040, tty c003001a, net c0060400 BIOS Geometries: 0:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 1:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 2:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 3:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 4:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 5:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 6:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 7:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 0 accounted for Device configuration finished. IP packet filtering initialized, divert disabled, rule-based forwarding disabled, default to accept, unlimited logging bpf: lo0 attached Waiting 10 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. ahc0: Selection Timeout on A:1. 1 SCBs aborted (probe0:ahc0:0:0:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x21 (probe0:ahc0:0:0:0): Queuing a BDR SCB ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_TCL == 0x0, ARG_1 == 0xff, SEQ_FLAGS == 0x0 (probe0:ahc0:0:0:0): SCB 0x0 - timed out in datain phase, SEQADDR == 0x15e (probe0:ahc0:0:0:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 14 SCBs aborted ahc0: Selection Timeout on A:2. 1 SCBs aborted Timedout SCB handled by another timeout (probe3:ahc0:0:3:0): SCB 0xe - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x44 (probe3:ahc0:0:3:0): Queuing a BDR SCB (probe3:ahc0:0:3:0): no longer in timeout, status = 35b ahc0: Selection Timeout on A:3. 1 SCBs aborted Timedout SCB handled by another timeout ahc0: Selection Timeout on A:4. 1 SCBs aborted (probe0:ahc0:0:0:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x7 (probe0:ahc0:0:0:0): SCB 2: Immediate reset. Flags = 0x4040 (probe0:ahc0:0:0:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 12 SCBs aborted ahc0: Selection Timeout on A:5. 1 SCBs aborted Timedout SCB handled by another timeout (probe6:ahc0:0:6:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 (probe6:ahc0:0:6:0): Queuing a BDR SCB (probe6:ahc0:0:6:0): no longer in timeout, status = 300 ahc0: Selection Timeout on A:8. 1 SCBs aborted Timedout SCB handled by another timeout ahc0: Selection Timeout on A:9. 1 SCBs aborted (probe3:ahc0:0:3:0): SCB 0xc - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x7 (probe3:ahc0:0:3:0): SCB 12: Immediate reset. Flags = 0x4040 (probe3:ahc0:0:3:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 9 SCBs aborted ahc0: Selection Timeout on A:10. 1 SCBs aborted Timedout SCB handled by another timeout (probe10:ahc0:0:11:0): SCB 0xc - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x44 (probe10:ahc0:0:11:0): Queuing a BDR SCB (probe10:ahc0:0:11:0): no longer in timeout, status = 35b ahc0: Selection Timeout on A:11. 1 SCBs aborted Timedout SCB handled by another timeout ahc0: Selection Timeout on A:12. 1 SCBs aborted (probe6:ahc0:0:6:0): SCB 0x5 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x7 (probe6:ahc0:0:6:0): SCB 5: Immediate reset. Flags = 0x4040 (probe6:ahc0:0:6:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 7 SCBs aborted To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 15 22: 7:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id C4F05150EB for ; Mon, 15 Mar 1999 22:07:38 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id XAA23750; Mon, 15 Mar 1999 23:07:10 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903160607.XAA23750@panzer.plutotech.com> Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <19990315083937.29224@uriah.heep.sax.de> from J Wunsch at "Mar 15, 1999 8:39:37 am" To: joerg_wunsch@uriah.heep.sax.de Date: Mon, 15 Mar 1999 23:07:10 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org J Wunsch wrote... > As Kenneth D. Merry wrote: > > > Well, to avoid having to send the patches to too many more people, > > I've put them here: > > > http://www.FreeBSD.ORG/~ken/camcontrol.diffs.031499 > > (OK, will have to test this later on.) > > > Right, media should not be required. What we *do* require is that > > the device tell us in some intelligible way that there is no media > > in it. > > Hmm, what we'd probably need here is a document describing the SCSI > CCS. See my below. > > > Hmm. The CAM status 0x4b means that the command timed out, and that > > the queue for that device was frozen. I don't know why it hung your > > system. > > Weird. Is there any way to further debug this. I think so. See my comments on read capacity below. > > Okay, let me see if I've got this straight: > > > > - It works with media in the drive and spinning. > > Yep. > > > - If there is no media in the drive, it doesn't work. What happens > > in this case? > > I didn't test myself, but it probably won't attach. Here's the result > i get from an attempted `start' command without a medium: > > uriah # camcontrol tur -v -u 2 > Unit is not ready > (pass4:ncr1:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (pass4:ncr1:0:3:0): NOT READY asc:a,0 > (pass4:ncr1:0:3:0): Error log overflow > > Right now that i see it, i can remember i've seen the `Error log > overflow' before. Okay, that's the same error Matthew Dodd was getting. What happens if you do what I suggested that he do? i.e., change the code in the probe case in dadone(), so that 0xa is an acceptable ASC? My guess is that will allow you to attach without media. > > - If there is media in the drive that isn't spinning, and you've got > > the quirk entry in scsi_all.c, the spinup command may be timing > > out. > > Yep, although camcontrol's spinup command would work later. > > > How long does the start unit command take for that drive? > > A few seconds, about 5 to 10 if the medium is (optically) clean. In > the case of an unclean medium, it might take up to one minute > approximately, until the drive will eject the medium. > > > The timeout for the start unit command in the error recovery code > > is 50 seconds. (The start unit is done in cam_periph.c) > > That should suffice. Btw., IIRC the medium did _not_ spin up in the > case where it hung the bus, so the START STOP UNIT command apparently > didn't make it to the drive. The command that timed out in that case, I'm pretty sure, was the read capacity. One question I have is this -- once the media is spinning, how long does it take to do a read capacity? You can find out like this: /usr/bin/time camcontrol cmd -t 60 -v -n da -u 2 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" What happens if the media is not spinning and you do a read capacity? Does the drive try to spin itself up? The default timeout for the read capacity in the DA driver is 5 seconds. If the MO drive attempts, for whatever reason, to spin itself up when it gets a read capacity, we may need to bump the timeout on the read capacity command. Of course I could be barking up the wrong tree here... But it does kinda fit what you were saying -- that starting the drive from camcontrol worked, even when the DA driver failed to attach. Anyway, I think we're starting to get a handle on what this device does... Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 15 22:25:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 6590214CAB for ; Mon, 15 Mar 1999 22:25:47 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id XAA23822; Mon, 15 Mar 1999 23:25:17 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903160625.XAA23822@panzer.plutotech.com> Subject: Re: Boot-time scsi probe problem In-Reply-To: from "Jason K. Fritcher" at "Mar 15, 1999 10: 0:45 pm" To: jkf@wolfnet.org (Jason K. Fritcher) Date: Mon, 15 Mar 1999 23:25:17 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jason K. Fritcher wrote... > > Hello. I am trying to get FreeBSD 3.1-Stable to boot reliably on a machine I > have. It was cvsup'ed from Sunday night about 11pm or so. The system was > originally installed with the 3.1-19990227 snapshot. I can somewhat reliably > boot from the generic kernel included with the snapshot, but I can not boot > at all with a kernel compiled from the cvsup. The problems I am having are > this. When booting with the generic kernel, the system will boot all the way > through if I power-cycle the machine, or reboot it with the reset boot, > basically a cold-boot. If I reboot the machine with a warm boot, ie > Ctrl-Alt-Del, the system will lockup when it tries to probe the scsi bus for > devices. It will wait the 15 seconds for things to settle, and then it locks > one the probe starts. I am forced to use the reset button to restart it. > > With the new kernel, when the machine gets to the probe, it does not lock > up, but the probe doesn't work either. It sits there for a few, and then > starts giving error messages about timeouts. At the end of the message I > have included the entire boot sequence for reference. > > The hardware I have ia an Asus P2B-LS motherboard with onboard AIC-7890 SCSI > controller + 3860 bridge. For those not familiar with the P2B-LS, the SCSI > bus is divided into three segments, a U2W, UW, and UN buses. On the U2W bus > I have a Quantum Viking II 9.1 GB hard drive in LVD mode, on the UW bus is > nothing but a terminator, and on the UN bus is a Plextor 40x cdrom drive. > The hard drive is scsi id 0, and the cdrom is scsi id 6. > > After looking through the archives for anything similar, I came across > similar problems which were caused by termination problems. I have checked > the termination and all seems well. > > Any suggestions about what the cause could and possible solutions would be > much appriciated. I have spent a good 4-5 hours compiling kernels with > different options, and reading through list archives to try and solve this > problem. If there is any more information that anyone needs, or have > questions, please, write me and I will do what I can. This sounds and looks like a known problem with the Adaptec 7890 chips. A number of people have reported this. Justin has reproduced the problem (with a lot of help from Tor Egge) and has a PCI bus trace showing the problem. He said that there may be a bug in the 7890 that causes it to hang in certain circumstances; he has mailed Adaptec asking for information. Since he's not in town at the moment, I wouldn't expect any response from him on this for a few days. I suggest that you stick with the kernel that boots for now, if you can. The hang seems to be timing related in some way, so you might get different results if you stick your hard disk on the Ultra-Wide bus instead of the Ultra-2 bus. Hopefully Justin will be able to come up with a fix for it before too long. You also may want to subscribe to the -scsi list, there's a lot less noise on this list than on many of the other FreeBSD lists. (for now, at least) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 4: 0:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ms2.eranet.net (ms2.eranet.net [203.95.230.35]) by hub.freebsd.org (Postfix) with ESMTP id 4BF2F151D3 for ; Tue, 16 Mar 1999 03:59:09 -0800 (PST) (envelope-from kevlo@hello.com.tw) Received: from hello.com.tw (n020.n203-95-234.eranet.net [203.95.234.20]) by ms2.eranet.net (8.9.1a/8.9.1) with ESMTP id TAA21679 for ; Tue, 16 Mar 1999 19:58:49 +0800 (CST) Message-ID: <36EE474D.2E949140@hello.com.tw> Date: Tue, 16 Mar 1999 19:58:05 +0800 From: Kevin Lo X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: Recommended scsi cards. Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Would anyone recommend me scsi cards? Because I have an AHA-2930U, but FreeBSD can't detect it :( Thanks in advance, Kevin. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 5:21:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from shadows.aeon.net (shadows.aeon.net [195.197.32.30]) by hub.freebsd.org (Postfix) with ESMTP id 527A41513F for ; Tue, 16 Mar 1999 05:21:08 -0800 (PST) (envelope-from bsdscsi@shadows.aeon.net) Received: (from bsdscsi@localhost) by shadows.aeon.net (8.9.1/8.8.3) id PAA29688; Tue, 16 Mar 1999 15:21:50 +0200 (EET) From: mika ruohotie Message-Id: <199903161321.PAA29688@shadows.aeon.net> Subject: Re: Boot-time scsi probe problem In-Reply-To: from "Jason K. Fritcher" at "Mar 15, 1999 10: 0:45 pm" To: jkf@wolfnet.org (Jason K. Fritcher) Date: Tue, 16 Mar 1999 15:21:50 +0200 (EET) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The hardware I have ia an Asus P2B-LS motherboard with onboard AIC-7890 SCSI > controller + 3860 bridge. For those not familiar with the P2B-LS, the SCSI i rise my hand up with booting probs with that particular hardware. also, i volunteer myself to test _any_ patches which might help... my current is current as of march 15th around noon GMT. mickey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 8:22:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from outreach.wolfnet.org (outreach.wolfnet.org [207.173.133.202]) by hub.freebsd.org (Postfix) with ESMTP id 45C8D150D3 for ; Tue, 16 Mar 1999 08:22:08 -0800 (PST) (envelope-from jkf@wolfnet.org) Received: from outreach.wolfnet.org ([207.173.133.202]) by outreach.wolfnet.org with esmtp (Exim 2.12 #1) id 10Mwb7-0009X6-00; Tue, 16 Mar 1999 08:21:41 -0800 Date: Tue, 16 Mar 1999 08:21:41 -0800 (PST) From: "Jason K. Fritcher" To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Boot-time scsi probe problem In-Reply-To: <199903160625.XAA23822@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 15 Mar 1999, Kenneth D. Merry wrote: > This sounds and looks like a known problem with the Adaptec 7890 chips. A > number of people have reported this. Hmmm... Was this reported to the list, and if so, how long ago? I checked the archives for -scsi and didn't see anything in there on this. > Justin has reproduced the problem (with a lot of help from Tor Egge) and > has a PCI bus trace showing the problem. > > He said that there may be a bug in the 7890 that causes it to hang in > certain circumstances; he has mailed Adaptec asking for information. Joy... I guess those certain circumstances are happening almost all the time for me. > Since he's not in town at the moment, I wouldn't expect any response from > him on this for a few days. > > I suggest that you stick with the kernel that boots for now, if you can. > The hang seems to be timing related in some way, so you might get different > results if you stick your hard disk on the Ultra-Wide bus instead of the > Ultra-2 bus. Hopefully Justin will be able to come up with a fix for it > before too long. Ok. I will give this a try later this evening and see if it helps. I did try to take the drive out of LVD mode and put it in SE mode on the U2W bus, but I didn't try it on the UW bus. Thanx for the idea. > You also may want to subscribe to the -scsi list, there's a lot less noise > on this list than on many of the other FreeBSD lists. (for now, at least) I did this too. Thanx for the help. -- Jason K. Fritcher jkf@wolfnet.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 8:30: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EEF7153F8 for ; Tue, 16 Mar 1999 08:29:56 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id JAA26181; Tue, 16 Mar 1999 09:29:33 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903161629.JAA26181@panzer.plutotech.com> Subject: Re: Boot-time scsi probe problem In-Reply-To: from "Jason K. Fritcher" at "Mar 16, 1999 8:21:41 am" To: jkf@wolfnet.org (Jason K. Fritcher) Date: Tue, 16 Mar 1999 09:29:33 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jason K. Fritcher wrote... > On Mon, 15 Mar 1999, Kenneth D. Merry wrote: > > This sounds and looks like a known problem with the Adaptec 7890 chips. A > > number of people have reported this. > > Hmmm... Was this reported to the list, and if so, how long ago? I checked > the archives for -scsi and didn't see anything in there on this. Oops, it was on -hackers. The subject was "adaptec 2940u2w hangs on external disks". Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 8:33:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from outreach.wolfnet.org (outreach.wolfnet.org [207.173.133.202]) by hub.freebsd.org (Postfix) with ESMTP id 0346F15022 for ; Tue, 16 Mar 1999 08:33:04 -0800 (PST) (envelope-from jkf@wolfnet.org) Received: from outreach.wolfnet.org ([207.173.133.202]) by outreach.wolfnet.org with esmtp (Exim 2.12 #1) id 10Mwla-0009YF-00; Tue, 16 Mar 1999 08:32:30 -0800 Date: Tue, 16 Mar 1999 08:32:30 -0800 (PST) From: "Jason K. Fritcher" To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Boot-time scsi probe problem In-Reply-To: <199903161629.JAA26181@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 16 Mar 1999, Kenneth D. Merry wrote: > > Hmmm... Was this reported to the list, and if so, how long ago? I checked > > the archives for -scsi and didn't see anything in there on this. > > Oops, it was on -hackers. The subject was "adaptec 2940u2w hangs on > external disks". Oops myself. I did see that thread, but I didn't read it since I am not using external drives. I'll have a look at the thread later this afternoon. Thanx. -- Jason K. Fritcher jkf@wolfnet.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 8:43: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B3231505C for ; Tue, 16 Mar 1999 08:43:03 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id JAA26300; Tue, 16 Mar 1999 09:42:32 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903161642.JAA26300@panzer.plutotech.com> Subject: Re: Recommended scsi cards. In-Reply-To: <36EE474D.2E949140@hello.com.tw> from Kevin Lo at "Mar 16, 1999 7:58: 5 pm" To: kevlo@hello.com.tw (Kevin Lo) Date: Tue, 16 Mar 1999 09:42:32 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kevin Lo wrote... > > Would anyone recommend me scsi cards? > Because I have an AHA-2930U, but FreeBSD can't detect it :( Is it a 2930, or a 2930U2? If it's a 2930U2, support was added in -current on March 5th, and in -stable on March 6th. So you'll have to get a more recent snapshot. If it isn't a 2930U2, what Adaptec chip does it have on board? Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 10:11:33 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from relay2.mail.uk.psi.net (relay2.mail.uk.psi.net [154.32.107.6]) by hub.freebsd.org (Postfix) with ESMTP id B3940153FB for ; Tue, 16 Mar 1999 10:11:31 -0800 (PST) (envelope-from amobbs@allstor-sw.co.uk) Received: from mail.plasmon.co.uk ([193.115.5.217]) by relay2.mail.uk.psi.net with smtp (Exim 2.02 #3) id 10MyJ6-0002Ui-00 for freebsd-scsi@freebsd.org; Tue, 16 Mar 1999 18:11:12 +0000 Received: by mail.plasmon.co.uk(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 80256736.0063A37F ; Tue, 16 Mar 1999 18:08:19 +0000 X-Lotus-FromDomain: PLASNOTES From: amobbs@allstor-sw.co.uk To: freebsd-scsi@freebsd.org Message-ID: <80256736.0063A310.00@mail.plasmon.co.uk> Date: Tue, 16 Mar 1999 18:08:17 +0000 Subject: Userland CAM drivers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm trying to write a userland driver using camlib to do fairly straightforward device control and I/O on a passthrough driver. So far, I've had no problem with control type commands (test unit ready, mode sense/select etc.) but read and write are giving me problems. Just using read(2)/write(2) on the fd in the cam_device seemed to cause serious problems, and I'm not sure that even using scsi_read_write followed by a cam_send_ccb is working. (I'm getting constent Device in Reset Sequence with that, but I'm willing to believe that that's a bug in my code.) So my questions: Do I have to use scsi_read_write followed by cam_send_ccb rather than read/write on the fd? In general, how should I do I/O through a passthrough device? Is there an documentation on this sort of thing, even that written in C? I used camcontrol.c to get the control side working, but the I/O side seems to only be done by kernel drivers, which use scsi_read_write followed by xpt_action which doesn't appear to be available to me. Andrew. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 10:48:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D5C715143 for ; Tue, 16 Mar 1999 10:48:20 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id LAA27060; Tue, 16 Mar 1999 11:47:54 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903161847.LAA27060@panzer.plutotech.com> Subject: Re: Userland CAM drivers In-Reply-To: <80256736.0063A310.00@mail.plasmon.co.uk> from "amobbs@allstor-sw.co.uk" at "Mar 16, 1999 6: 8:17 pm" To: amobbs@allstor-sw.co.uk Date: Tue, 16 Mar 1999 11:47:54 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org amobbs@allstor-sw.co.uk wrote... > > I'm trying to write a userland driver using camlib to do fairly > straightforward device control and I/O on a passthrough driver. > > So far, I've had no problem with control type commands (test unit ready, > mode sense/select etc.) but read and write are giving me problems. > > Just using read(2)/write(2) on the fd in the cam_device seemed to cause > serious problems, and I'm not sure that even using scsi_read_write followed > by a cam_send_ccb is working. (I'm getting constent Device in Reset > Sequence with that, but I'm willing to believe that that's a bug in my > code.) You can't use read or write on the pass devices. (which is what is behind the file descriptor in the cam_device structure) That is an ioctl-only interface. > So my questions: > > Do I have to use scsi_read_write followed by cam_send_ccb rather than > read/write on the fd? In general, how should I do I/O through a passthrough > device? scsi_read_write(), scsi_test_unit_ready() and other functions like that only serve to setup a CCB. They don't do any actual I/O to the device. Once you've setup the CCB with one of the helper functions, or with cam_fill_csio() (for generic SCSI CCBs), you then use cam_send_ccb() to send the CCB. cam_send_ccb() is just a wrapper to the CAMIOCOMMAND ioctl. > Is there an documentation on this sort of thing, even that written in C? I > used camcontrol.c to get the control side working, but the I/O side seems > to only be done by kernel drivers, which use scsi_read_write followed by > xpt_action which doesn't appear to be available to me. Well, the equivalent of xpt_action for you is cam_send_ccb(). You should be able to setup read and write CCBs and read from and write to the device using scsi_read_write() and cam_send_ccb(). I know that this works, because we (i.e. my employer) has a very large application that does just that. As far as documentation written in C on this, camcontrol is the main example. But, really, doing an inquiry is no different than doing a read. In both cases, you call a helper function (scsi_inquiry() or scsi_read_write()). In both cases, you supply a buffer and a length and some other parameters. Once that is setup, you just pass the CCB into cam_send_ccb(). Anyway, hopefully this explains things. If you've got more questions, don't hesitate to ask. I wrote most of that code (userland code, passthrough driver, etc.), so I can certainly explain how it works. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 10:51:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mailserver.c-lab.de (mailserver.c-lab.de [131.234.80.124]) by hub.freebsd.org (Postfix) with ESMTP id 4674514ED8 for ; Tue, 16 Mar 1999 10:51:16 -0800 (PST) (envelope-from joost@c-lab.de) Received: from badlab.c-lab.de (badlab.c-lab.de [131.234.80.79]) by mailserver.c-lab.de (8.8.8/8.8.8) with ESMTP id TAA15984; Tue, 16 Mar 1999 19:50:50 +0100 (MET) Received: (from joost@localhost) by badlab.c-lab.de (8.7.5/8.7.3) id TAA07871; Tue, 16 Mar 1999 19:50:49 +0100 (MET) Date: Tue, 16 Mar 1999 19:50:49 +0100 (MET) Message-Id: <199903161850.TAA07871@badlab.c-lab.de> From: Michael Joosten To: scsi@freebsd.org Cc: joost@c-lab.de Subject: UltraStor 24F in rewrite for CAM, anybody docs for 124F (RAID!) ?? Reply-To: joost@c-lab.de Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Somebody seems to have adapted the old UltraStor driver to CAM, and even that somebody has asked for 24F for testing. I've here a nice, old 124F (yes, the RAID one with 3 channels on NCR 53C710 and 68K320 controller) EISA version with a similarly old EISA box, and I have the hope that changing some port offsets and other minor stuff might be enough to get it at least running under the old ultra14.c driver. Has anybody docs for this clunker ? If so, could he/she judge the amount of changes necessary? Currently, when just hacked to recognize the 124 as a 24F, it apparently does the uha24_init, but once the XX_attach_devs tries to send out INQUIREs, it is just blocks. Probably tickling the wrong registers. Another one is that I'm currently unable to boot even from floppy when both 124F with configured disk AND an AHA1742 with bootable disk is attached. The manual says that this should work, but does not describe what the difference between the 124 being the primary or secondary adapter is (disable BIOS, I'd guess ??). I'm currently trying to look at the disassembly of the NT 3.5 drivers, to see where coincidences are between 24F and 124F. Using the AHA1742 source in NT DDK as reference, I can at least identify similar code parts. Not quite easy, but since I began hacking 20 years ago with a 6502 board in hex, let's see... Regards, Michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 12:27:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E5F36150C6 for ; Tue, 16 Mar 1999 12:27:49 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id MAA14074 for ; Tue, 16 Mar 1999 12:27:27 -0800 Date: Tue, 16 Mar 1999 12:27:27 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: freebsd-scsi@freebsd.org Subject: sa0: Removable Sequential Access SCSI-2 device Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have to report that I've been terribly confused about this device. *I* don't have one, and I've been dependent upon some folks to give me information I can use about it. I was under the impression that it is a QIC device. I find out that I'm quite wrong on this. I'm trying to get one myself now so it can be properly supported, as well as a more representative QIC device than the ancient QIC-150 that I have. I apologize for the problems that have been occurring with support for these devices. I'll try and get it into better shape soon. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 14:23:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3BA8714D52 for ; Tue, 16 Mar 1999 14:23:22 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id OAA14648; Tue, 16 Mar 1999 14:22:33 -0800 Date: Tue, 16 Mar 1999 14:22:33 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG Subject: Re: Strange SCSI QIC tape behaviour In-Reply-To: <199903140807.BAA11545@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I also noticed that the sa driver doesn't claim device entries in > > DEVFS. This should be easy to fix (and a lot more of the CAM entries > > are missing, only the da's are there), so i could try to fix this > > myself. > > IIRC, the problem is that the version of DEVFS that we have now can't > handle device arrival/removal events from an interrupt context. Julian had > a version of DEVFS/SLICE at one point that could handle being called from > an interrupt context, however. Bruce looked into the DEVFS/CAM thing a > while back, and conculded it wouldn't work for now. If you want details, > ask him. > > So, the bottom line is, if you're using CAM, you can't use DEVFS. > Doesn't this effectively mean "not at all?". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 14:25:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C113153CC for ; Tue, 16 Mar 1999 14:25:06 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id PAA28232; Tue, 16 Mar 1999 15:24:37 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903162224.PAA28232@panzer.plutotech.com> Subject: Re: Strange SCSI QIC tape behaviour In-Reply-To: from Matthew Jacob at "Mar 16, 1999 2:22:33 pm" To: mjacob@feral.com Date: Tue, 16 Mar 1999 15:24:37 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote... > > > > I also noticed that the sa driver doesn't claim device entries in > > > DEVFS. This should be easy to fix (and a lot more of the CAM entries > > > are missing, only the da's are there), so i could try to fix this > > > myself. > > > > IIRC, the problem is that the version of DEVFS that we have now can't > > handle device arrival/removal events from an interrupt context. Julian had > > a version of DEVFS/SLICE at one point that could handle being called from > > an interrupt context, however. Bruce looked into the DEVFS/CAM thing a > > while back, and conculded it wouldn't work for now. If you want details, > > ask him. > > > > So, the bottom line is, if you're using CAM, you can't use DEVFS. > > > > Doesn't this effectively mean "not at all?". It means you shouldn't use it in place of /dev. You can start it, but just mount it elsewhere. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 14:30: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1A7F2153BB for ; Tue, 16 Mar 1999 14:29:41 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id OAA14692; Tue, 16 Mar 1999 14:28:51 -0800 Date: Tue, 16 Mar 1999 14:28:51 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG Subject: Re: Strange SCSI QIC tape behaviour In-Reply-To: <199903162224.PAA28232@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > So, the bottom line is, if you're using CAM, you can't use DEVFS. > > > > > > > Doesn't this effectively mean "not at all?". > > It means you shouldn't use it in place of /dev. You can start it, but > just mount it elsewhere. > > Ken Oh. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 15: 2:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from hpcs14.dv.fal.de (hpcs14e.dv.fal.de [134.110.18.14]) by hub.freebsd.org (Postfix) with ESMTP id 6416514CD2 for ; Tue, 16 Mar 1999 15:02:20 -0800 (PST) (envelope-from kraft@hpcs14.dv.fal.de) Received: (from kraft@localhost) by hpcs14.dv.fal.de (8.9.1/8.9.1) id BAA13911 for freebsd-scsi@freebsd.org; Wed, 17 Mar 1999 01:02:01 +0200 (MET) From: Martin Kraft Message-Id: <199903162302.BAA13911@hpcs14.dv.fal.de> Subject: i/o error with larger QIC To: freebsd-scsi@freebsd.org Date: Wed, 17 Mar 1999 01:02:01 +0200 (MET) Reply-To: martin.kraft@fal.de X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I know, the problem with some SCSI tape drives was already reported and discussed during the last days. Maybe the following information can help to address the problem better. If not, please do not spend time on responding. I will follow this list and wait for the solution. My personal situation is, that after upgrading from FreeBSD 2.2.7 to 3.1 on sunday, I am not able to restore from part of my QIC tapes. The drive is a: sa0 at bt0 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI-CCS device sa0: 4.32MB/s transfers (4.32MHz, offset 14) I can read DC 6150 tapes (written under 2.2.7) without problems. But it is impossible to read from a DC 6525: su-2.02# tar -t tar: read error on /dev/rsa0 : Input/output error su-2.02# mt status Mode Density Blocksize bpi Compression Current: QIC-320 512 bytes 16000 unsupported ---------available modes--------- 0: QIC-320 512 bytes 16000 unsupported 1: QIC-320 512 bytes 16000 unsupported 2: QIC-320 512 bytes 16000 unsupported 3: QIC-320 512 bytes 16000 unsupported --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 su-2.02# Thanks, Matthew, and everybody working on these drivers. Martin Kraft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 15:10:46 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D8BF614C9F for ; Tue, 16 Mar 1999 15:10:44 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id PAA14964; Tue, 16 Mar 1999 15:10:08 -0800 Date: Tue, 16 Mar 1999 15:10:08 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: martin.kraft@fal.de Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: i/o error with larger QIC In-Reply-To: <199903162302.BAA13911@hpcs14.dv.fal.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I know, the problem with some SCSI tape drives was already > reported and discussed during the last days. Maybe the following > information can help to address the problem better. If not, please > do not spend time on responding. I will follow this list and wait > for the solution. > > My personal situation is, that after upgrading from FreeBSD 2.2.7 to 3.1 > on sunday, I am not able to restore from part of my QIC tapes. > > The drive is a: > > sa0 at bt0 bus 0 target 4 lun 0 > sa0: Removable Sequential Access SCSI-CCS device > sa0: 4.32MB/s transfers (4.32MHz, offset 14) > > I can read DC 6150 tapes (written under 2.2.7) without problems. But it > is impossible to read from a DC 6525: > > su-2.02# tar -t > tar: read error on /dev/rsa0 : Input/output error > su-2.02# mt status > Mode Density Blocksize bpi Compression > Current: QIC-320 512 bytes 16000 unsupported > ---------available modes--------- > 0: QIC-320 512 bytes 16000 unsupported > 1: QIC-320 512 bytes 16000 unsupported > 2: QIC-320 512 bytes 16000 unsupported > 3: QIC-320 512 bytes 16000 unsupported > --------------------------------- > Current Driver State: at rest. > --------------------------------- > File Number: 0 Record Number: 0 > su-2.02# > If you set to 1KB blocksize, can you read those tapes? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 21:34:38 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B3E4E15497 for ; Tue, 16 Mar 1999 21:34:34 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony [10.0.0.6]) by rover.village.org (8.9.3/8.6.6) with ESMTP id FAA81267; Wed, 17 Mar 1999 05:34:15 GMT Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id WAA07327; Tue, 16 Mar 1999 22:34:02 -0700 (MST) Message-Id: <199903170534.WAA07327@harmony.village.org> To: joost@c-lab.de Subject: Re: UltraStor 24F in rewrite for CAM, anybody docs for 124F (RAID!) ?? Cc: scsi@FreeBSD.ORG In-reply-to: Your message of "Tue, 16 Mar 1999 19:50:49 +0100." <199903161850.TAA07871@badlab.c-lab.de> References: <199903161850.TAA07871@badlab.c-lab.de> Date: Tue, 16 Mar 1999 22:34:02 -0700 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199903161850.TAA07871@badlab.c-lab.de> Michael Joosten writes: : Somebody seems to have adapted the old UltraStor driver to CAM, and even : that somebody has asked for 24F for testing. CAM doesn't support any UltraStor cards. I have a 14F, a 14FB, a 24F and two 34F's sitting here waiting for me to write a driver for them. I've been swamped with other things and haven't had the time to spend on them. Or, if I'm misunderstanding what you are saying, where can I find this driver that somebody has ported to CAM? :-) : I've here a nice, old 124F (yes, the RAID one with 3 channels on NCR : 53C710 and 68K320 controller) EISA version with a similarly old EISA : box, and I have the hope that changing some port offsets and other : minor stuff might be enough to get it at least running under the old : ultra14.c driver. I've been told that the 124F has a different sw interface, but it wasn't the most reliable source that told me this. : I'm currently trying to look at the disassembly of the NT 3.5 drivers, to see : where coincidences are between 24F and 124F. Using the AHA1742 source in NT : DDK as reference, I can at least identify similar code parts. Not quite easy, : but since I began hacking 20 years ago with a 6502 board in hex, let's see... Good luck! If the register set does turn out to be approximately that of the 14F, then I'd like to coordinate driver things with you. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 21:38:49 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id DBE1315534 for ; Tue, 16 Mar 1999 21:38:46 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony [10.0.0.6]) by rover.village.org (8.9.3/8.6.6) with ESMTP id FAA81284; Wed, 17 Mar 1999 05:38:27 GMT Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id WAA07362; Tue, 16 Mar 1999 22:38:14 -0700 (MST) Message-Id: <199903170538.WAA07362@harmony.village.org> To: mjacob@feral.com Subject: Re: sa0: Removable Sequential Access SCSI-2 device Cc: freebsd-scsi@FreeBSD.ORG In-reply-to: Your message of "Tue, 16 Mar 1999 12:27:27 PST." References: Date: Tue, 16 Mar 1999 22:38:14 -0700 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Matthew Jacob writes: : I'm trying to get one myself now so it can be properly supported, as well : as a more representative QIC device than the ancient QIC-150 that I have. : : I apologize for the problems that have been occurring with support for : these devices. I'll try and get it into better shape soon. I have a standing offer for a SCSI HP tape drive. Even comes with a few scratch 9 track tapes. However, it has to be local (boulder colorado) since the tape drive is a sob to move. It isn't mine, but a friend would loan it to me... I don't have the time right now to deal with it. Somehow I don't think that is the HP tape drive we're talking about :-) And I do have an ancient QIC-24 and QIC-150 (Archive Viper, known rogue that one) that are sitting in Ken's office that he has my permission to loan out. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 21:42:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id A1CC11554A for ; Tue, 16 Mar 1999 21:42:50 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id VAA16343; Tue, 16 Mar 1999 21:42:24 -0800 Date: Tue, 16 Mar 1999 21:42:23 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Warner Losh Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: sa0: Removable Sequential Access SCSI-2 device In-Reply-To: <199903170538.WAA07362@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In message Matthew Jacob writes: > : I'm trying to get one myself now so it can be properly supported, as well > : as a more representative QIC device than the ancient QIC-150 that I have. > : > : I apologize for the problems that have been occurring with support for > : these devices. I'll try and get it into better shape soon. > > I have a standing offer for a SCSI HP tape drive. Even comes with a > few scratch 9 track tapes. However, it has to be local (boulder > colorado) since the tape drive is a sob to move. It isn't mine, but a > friend would loan it to me... I don't have the time right now to deal > with it. Somehow I don't think that is the HP tape drive we're > talking about :-) Uh- no - this actually sounds like the HP-88780 reel drive - 800, 1600, 6250 BPI and a proprietary compression for 6250. I tried to snag one from Sun last time I was through there, but it was inconvenient. Useful to try things out on for interchange reasons. > And I do have an ancient QIC-24 and QIC-150 (Archive Viper, known > rogue that one) that are sitting in Ken's office that he has my > permission to loan out. Ah, yes, I have these. But if you want to test things- please do and yell at me! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 16 21:45: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 4793F14EA4 for ; Tue, 16 Mar 1999 21:45:04 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony [10.0.0.6]) by rover.village.org (8.9.3/8.6.6) with ESMTP id FAA81308; Wed, 17 Mar 1999 05:44:45 GMT Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id WAA07427; Tue, 16 Mar 1999 22:44:33 -0700 (MST) Message-Id: <199903170544.WAA07427@harmony.village.org> To: mjacob@feral.com Subject: Re: sa0: Removable Sequential Access SCSI-2 device Cc: freebsd-scsi@FreeBSD.ORG In-reply-to: Your message of "Tue, 16 Mar 1999 21:42:23 PST." References: Date: Tue, 16 Mar 1999 22:44:33 -0700 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Matthew Jacob writes: : Uh- no - this actually sounds like the HP-88780 reel drive - 800, 1600, : 6250 BPI and a proprietary compression for 6250. I tried to snag one from : Sun last time I was through there, but it was inconvenient. Useful to try : things out on for interchange reasons. Yes. That's the ticket. Came off an old Solbourne test machine... : Ah, yes, I have these. But if you want to test things- please do and yell : at me! I would if I had tapes or a place to mount the suckers :-)... I'll see if I can get at least the QIC-150 mounted in my desktop unit at work w/o them noticing that I have odd hardware in it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 10:21:53 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from hpcs14.dv.fal.de (hpcs14e.dv.fal.de [134.110.18.14]) by hub.freebsd.org (Postfix) with ESMTP id 8B10C153C2 for ; Wed, 17 Mar 1999 10:21:38 -0800 (PST) (envelope-from kraft@hpcs14.dv.fal.de) Received: (from kraft@localhost) by hpcs14.dv.fal.de (8.9.1/8.9.1) id UAA04899; Wed, 17 Mar 1999 20:20:58 +0200 (MET) From: Martin Kraft Message-Id: <199903171820.UAA04899@hpcs14.dv.fal.de> Subject: Re: i/o error with larger QIC To: mjacob@feral.com Date: Wed, 17 Mar 1999 20:20:57 +0200 (MET) Cc: freebsd-scsi@freebsd.org In-Reply-To: from "Matthew Jacob" at Mar 16, 99 03:10:08 pm Reply-To: martin.kraft@fal.de X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > > > sa0: Removable Sequential Access SCSI-CCS device > > sa0: 4.32MB/s transfers (4.32MHz, offset 14) > > > > I can read DC 6150 tapes (written under 2.2.7) without problems. But it > > is impossible to read from a DC 6525: > > If you set to 1KB blocksize, can you read those tapes? I am not at all familiar with tape commands. I tried the followin - without success: su-2.02# mt status Mode Density Blocksize bpi Compression Current: QIC-320 512 bytes 16000 unsupported ---------available modes--------- 0: QIC-320 512 bytes 16000 unsupported 1: QIC-320 512 bytes 16000 unsupported 2: QIC-320 512 bytes 16000 unsupported 3: QIC-320 512 bytes 16000 unsupported --------------------------------- Current Driver State: at rest. su-2.02# mt blocksize 1024 su-2.02# mt status Mode Density Blocksize bpi Compression Current: QIC-320 1024 bytes 16000 unsupported ---------available modes--------- 0: QIC-320 1024 bytes 16000 unsupported 1: QIC-320 1024 bytes 16000 unsupported 2: QIC-320 1024 bytes 16000 unsupported 3: QIC-320 1024 bytes 16000 unsupported --------------------------------- Current Driver State: at rest. su-2.02# tar -t tar: read error on /dev/rsa0 : Input/output error su-2.02# mt status Mode Density Blocksize bpi Compression Current: 0x00 512 bytes 0 unsupported ---------available modes--------- 0: 0x00 512 bytes 0 unsupported 1: 0x00 512 bytes 0 unsupported 2: 0x00 512 bytes 0 unsupported 3: 0x00 512 bytes 0 unsupported --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 su-2.02# ---- For further tests, please advice commands and parameters. Thanks very much. Martin Kraft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 10:50:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mailserver.c-lab.de (mailserver.c-lab.de [131.234.80.124]) by hub.freebsd.org (Postfix) with ESMTP id 4E362150B4 for ; Wed, 17 Mar 1999 10:50:23 -0800 (PST) (envelope-from joost@c-lab.de) Received: from badlab.c-lab.de (badlab.c-lab.de [131.234.80.79]) by mailserver.c-lab.de (8.8.8/8.8.8) with ESMTP id TAA03898; Wed, 17 Mar 1999 19:49:57 +0100 (MET) Received: from badlab.c-lab.de (badlab.c-lab.de [131.234.80.79]) by badlab.c-lab.de (8.7.5/8.7.3) with ESMTP id TAA01284; Wed, 17 Mar 1999 19:49:57 +0100 (MET) Date: Wed, 17 Mar 1999 19:49:56 +0100 (MET) From: Michael Joosten Reply-To: Michael Joosten Subject: Re: UltraStor 24F in rewrite for CAM, anybody docs for 124F (RAID!) ?? To: Warner Losh Cc: joost@c-lab.de, scsi@freebsd.org In-Reply-To: <199903170534.WAA07327@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > CAM doesn't support any UltraStor cards. I have a 14F, a 14FB, a 24F > and two 34F's sitting here waiting for me to write a driver for them. > I've been swamped with other things and haven't had the time to spend > on them. > > Or, if I'm misunderstanding what you are saying, where can I find this > driver that somebody has ported to CAM? :-) Ummm, then I probably slightly misunderstood your e-mail from last september... Anyway, I grabbed an old disk, put 2.2.7 kernel src on it, and then tried to play with this one. > > If the register set does turn out to be approximately that of the 14F, > then I'd like to coordinate driver things with you. > Sure. Yesterday (yesternight?) I checked the code between NetBSD, FreeBSD and Linux for similarities for the 24F (quite interesting, there are (slight?) differences in initialization, board reset etc), and tried to see what the ultra124.sys driver of NT 3.5 does (3.5, because there is also a ultra124.dbg !). The differences seem to be a bit larger than I thought, but I haven't checked the whole 'SCSI CDB to adapter command block' stuff. But the regs are way off the 24F locations. Still, if I'm right, I hope I'll get at least a few sparks from the board... I'd like to use a similar source organization as NetBSD: they split the files in a common part and 14/34 and 24 specific 'stubs'. This is, anyway, cleaner than the current situation. In addition, looking at the differences in the Linux drivers for Ultra 14/34 might be interesting, too. And there is also the possibility that NT's Miniport model is similar to CAM, but I first have to delve into that a little. Let's see... But... > I've been swamped with other things and haven't had the time to spend > on them. Sounds terribly familiar... Regards, Michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 11:17:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Samizdat.uucom.com (samizdat.uucom.com [198.202.217.54]) by hub.freebsd.org (Postfix) with ESMTP id CFFCE1544D for ; Wed, 17 Mar 1999 11:17:23 -0800 (PST) (envelope-from cshenton@uucom.com) Received: (from cshenton@localhost) by Samizdat.uucom.com (8.9.3/8.9.3) id OAA03560; Wed, 17 Mar 1999 14:15:35 -0500 (EST) To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: sa0: Removable Sequential Access SCSI-2 device References: From: Chris Shenton Date: 17 Mar 1999 14:15:35 -0500 In-Reply-To: Matthew Jacob's message of "Tue, 16 Mar 1999 12:27:27 -0800 (PST)" Message-ID: Lines: 67 X-Mailer: Gnus v5.6.45/Emacs 20.3 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 16 Mar 1999 12:27:27 -0800 (PST), Matthew Jacob said: Matthew> I have to report that I've been terribly confused about this Matthew> device. *I* don't have one, and I've been dependent upon some Matthew> folks to give me information I can use about it. I was under Matthew> the impression that it is a QIC device. I find out that I'm Matthew> quite wrong on this. What can I do to help? I've got one of these, an HP T4000s. It uses a "travan TR-4" tape from Imation which holds 4-8GB depending on compresseion. It's basically a QIC, some sites call it QIC-wide I think, and I believe TR-4 may have a QIC-#### designation. Below are a couple descriptions of TR-4 and the HP T4000 drive. If you need a victim to try drivers on, let me know. I'm running 3.1-STABLE now. (I've also got a Achive/Connor/Seagate Python 4xDDS2 juke I wanna put through it's paces with your drivers :-) From http://www.travan.com/products/data/content/subindex/0,1085,1117,00.html ... With uncompressed capacities ranging from 400 MB to 4 GB, Travan products give you the capacity you need to handle the most demanding applications -- today and tomorrow. The key to higher capacity is the unique Travan cartridge design, which holds a longer, wider tape that can store more data within the standard 3.5" form factor. Based on proven QIC technology Any time you store data, reliability is key. And it's not often that a new technology offers a history of reliability. The Travan family does. It's based on Quarter-Inch Cartridge (QIC) technology -- the preferred backup solution for millions of computer users around the world. Easy to use Backing up with high-capacity Travan cartridges is simple. They can easily hold the entire contents of a hard drive. And since Travan-compatible drives can read QIC minicartridges, your existing backup library is still useful. For maximum security, Imation recommends that you back up your data every day. A search on HP's site turns up: Hewlett-Packard Company today announced a portable, external version of its HP Colorado T4000s 8GB QIC tape drive. The new drive, the HP Colorado T4000es, combines Travan minicartridge technology and SCSI-2 performance with support for DOS, Windows, Windows 95 and Windows NT operating systems. Using latest-generation Travan technology, the HP Colorado T4000es expands minicartridge capacity to 4GB native and 8GB compressed using Travan TR-4 minicartridges. With its SCSI-2 interface, the T4000es significantly increases backup speed compared to previous-generation minicartridge drives. Its 514KB/second burst SCSI data-transfer rate is approximately four times faster than floppy-interface systems, providing typical backup speeds of 25MB/minute to 35MB/minute on Pentium systems. Using a typical Pentium system, users can back up a 1GB hard drive in about 30 minutes to 40 minutes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 11:59:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 31D1315472 for ; Wed, 17 Mar 1999 11:59:01 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA19313; Wed, 17 Mar 1999 11:58:18 -0800 Date: Wed, 17 Mar 1999 11:58:18 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: martin.kraft@fal.de Cc: freebsd-scsi@freebsd.org Subject: Re: i/o error with larger QIC In-Reply-To: <199903171820.UAA04899@hpcs14.dv.fal.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > --------------------------------- > Current Driver State: at rest. > su-2.02# tar -t > tar: read error on /dev/rsa0 : Input/output error > su-2.02# mt status > Mode Density Blocksize bpi Compression > Current: 0x00 512 bytes 0 unsupported > ---------available modes--------- > 0: 0x00 512 bytes 0 unsupported > 1: 0x00 512 bytes 0 unsupported > 2: 0x00 512 bytes 0 unsupported > 3: 0x00 512 bytes 0 unsupported > --------------------------------- > Current Driver State: at rest. > --------------------------------- > File Number: 0 Record Number: 0 > ---- > For further tests, please advice commands and parameters. Thanks very much. Hmm. I'll have to finish what I'm doing. I have no idea why it shifted back to 512 bytes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 12: 7:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6CCBD14C41 for ; Wed, 17 Mar 1999 12:07:46 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id MAA19381; Wed, 17 Mar 1999 12:07:10 -0800 Date: Wed, 17 Mar 1999 12:07:09 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Chris Shenton Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: sa0: Removable Sequential Access SCSI-2 device In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Matthew> I have to report that I've been terribly confused about this > Matthew> device. *I* don't have one, and I've been dependent upon some > Matthew> folks to give me information I can use about it. I was under > Matthew> the impression that it is a QIC device. I find out that I'm > Matthew> quite wrong on this. > > What can I do to help? I've got one of these, an HP T4000s. It uses a > "travan TR-4" tape from Imation which holds 4-8GB depending on > compresseion. It's basically a QIC, some sites call it QIC-wide I > think, and I believe TR-4 may have a QIC-#### designation. > Well, I tried to treat it as a QIC to not do multiple filemarks, but I've been really beaten up on by an owner of such a drive saying that this isn't so. What I'm trying to do is to maybe get one myself- and not relying on indirect reports. The marketing info isn't germane. What I need to do is to look at a manual at least. Between being ill and having some other commitments, it'll take me a day or two to get to this. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 12:13:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 4C07C15391 for ; Wed, 17 Mar 1999 12:13:33 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id MAA19437; Wed, 17 Mar 1999 12:12:59 -0800 Date: Wed, 17 Mar 1999 12:12:59 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: martin.kraft@fal.de Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: i/o error with larger QIC In-Reply-To: <199903171820.UAA04899@hpcs14.dv.fal.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Matthew Jacob wrote: > > > > > sa0: Removable Sequential Access SCSI-CCS device > > > sa0: 4.32MB/s transfers (4.32MHz, offset 14) > > > > > > I can read DC 6150 tapes (written under 2.2.7) without problems. But it > > > is impossible to read from a DC 6525: This is slightly ambiguous. How were the DC6525 tapes written? Maybe also try the tar as 'tar tb 2'. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 12:20:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E5D5E150FD for ; Wed, 17 Mar 1999 12:20:55 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id MAA19457; Wed, 17 Mar 1999 12:20:19 -0800 Date: Wed, 17 Mar 1999 12:20:18 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Chris Shenton Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: sa0: Removable Sequential Access SCSI-2 device In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Checking HP's website- this is a discontinued product that writes in QIC3095 format. I couldn't find any real technical documents. Seeing that it is discontinued, I'd rather borrow one from somebody to make it work than try and buy one. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 14: 1:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from arjun.niksun.com (gw.niksun.com [206.20.52.122]) by hub.freebsd.org (Postfix) with ESMTP id 5501A154C4 for ; Wed, 17 Mar 1999 14:01:37 -0800 (PST) (envelope-from ath@niksun.com) Received: from stiegl.niksun.com (stiegl.niksun.com [10.0.0.44]) by arjun.niksun.com (8.8.8/8.8.8) with ESMTP id RAA16345 for ; Wed, 17 Mar 1999 17:01:19 -0500 (EST) Received: from stiegl.niksun.com (localhost.niksun.com [127.0.0.1]) by stiegl.niksun.com (8.8.8/8.8.7) with ESMTP id RAA02671 for ; Wed, 17 Mar 1999 17:01:17 -0500 (EST) (envelope-from ath@stiegl.niksun.com) Message-Id: <199903172201.RAA02671@stiegl.niksun.com> From: Andrew Heybey To: freebsd-scsi@freebsd.org Subject: NCR 895 performance Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 17 Mar 1999 17:01:17 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a machine running 3.1-RELEASE. It has three IBM DDRV 9LZX (10000RPM Ultra2) disks and a CCD partition striped across them. If I use an adaptec 7890 controller, bonnie reports: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU AHC 512 22432 96.3 33176 42.9 11995 18.6 21094 92.3 33897 28.4 403.3 4.2 If I use a Tekram 390U2W (which uses the NCR/SYMBIOS 895 chip), bonnie reports: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU NCR 512 21438 91.4 25026 32.8 10405 16.4 18871 83.4 25415 21.2 353.1 3.7 (after tweaking ncr.c to allow 40MHz transfers; before (with default 20Mhz transfers) I was only getting 20MB/s). Why is the ncr so much slower than the ahc? Is there something fundamental about the controller that prevents it from going any faster? Or is the driver not running the controller optimally? Is it because the NCR is limited to 32 tags (so sayeth the source)? (The ahc uses 64 tags (apparently the max that my disks can handle).) andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 14:16: 2 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from hpcs14.dv.fal.de (hpcs14e.dv.fal.de [134.110.18.14]) by hub.freebsd.org (Postfix) with ESMTP id 4FA1615863 for ; Wed, 17 Mar 1999 14:15:43 -0800 (PST) (envelope-from kraft@hpcs14.dv.fal.de) Received: (from kraft@localhost) by hpcs14.dv.fal.de (8.9.1/8.9.1) id AAA05135; Thu, 18 Mar 1999 00:14:50 +0200 (MET) From: Martin Kraft Message-Id: <199903172214.AAA05135@hpcs14.dv.fal.de> Subject: Re: i/o error with larger QIC To: mjacob@feral.com Date: Thu, 18 Mar 1999 00:14:50 +0200 (MET) Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: from "Matthew Jacob" at Mar 17, 99 12:12:59 pm Reply-To: martin.kraft@fal.de X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > sa0: Removable Sequential Access SCSI-CCS device > > sa0: 4.32MB/s transfers (4.32MHz, offset 14) > > > > I can read DC 6150 tapes (written under 2.2.7) without problems. But it > > is impossible to read from a DC 6525: > > This is slightly ambiguous. How were the DC6525 tapes written? I wrote them on sunday giving a "tar -cl usr" under FreeBSD 2.2.7. :-) > Maybe also try the tar as 'tar tb 2'. I tried it after inserting a DC6525: su-2.02# mt status Mode Density Blocksize bpi Compression Current: QIC-320 512 bytes 16000 unsupported ---------available modes--------- 0: QIC-320 512 bytes 16000 unsupported 1: QIC-320 512 bytes 16000 unsupported 2: QIC-320 512 bytes 16000 unsupported : QIC-320 512 bytes 16000 unsupported --------------------------------- Current Driver State: at rest. --------------------------------- File Number: 0 Record Number: 0 su-2.02# tar tb 2 tar: read error on /dev/rsa0 : Input/output error su-2.02# Thanks Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 18:30:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id 6841614DC0 for ; Wed, 17 Mar 1999 18:30:50 -0800 (PST) (envelope-from naddy@mips.rhein-neckar.de) Received: from mips.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id DAA06786 for freebsd-scsi@freebsd.org; Thu, 18 Mar 1999 03:30:31 +0100 (CET) (envelope-from naddy@mips.rhein-neckar.de) Received: by mips.rhein-neckar.de id m10NSUl-000WyWC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Thu, 18 Mar 1999 03:25:15 +0100 (CET) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Quantum Viking and NCR 53C875, anybody? Date: 18 Mar 1999 03:25:12 +0100 Message-ID: <7cpo68$vs6$1@mips.rhein-neckar.de> To: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does anybody out there successfully run a Quantum Viking SCA disk off a Symbios (nee NCR) 53C875 host adapter? I can't get the combination to work here. The Viking works elsewhere (albeit requires "wide negotiation off" on an AHA2940), and an old ST31080 (nee Conner 1080) I happened to have at hand has just proven to work fine off the on-board 53C875 in question. (No, it's not a FreeBSD box, and no, I can't boot FreeBSD there, but I doubt that the problem is OS specific.) -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de LinuxTag '99 - 26./27. Juni, Uni Kaiserslautern - http://www.linuxtag.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 19:17:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from helen.CS.Berkeley.EDU (helen.CS.Berkeley.EDU [128.32.131.251]) by hub.freebsd.org (Postfix) with ESMTP id 3CCBE1508F for ; Wed, 17 Mar 1999 19:17:21 -0800 (PST) (envelope-from jmacd@helen.CS.Berkeley.EDU) Received: (from jmacd@localhost) by helen.CS.Berkeley.EDU (8.9.1a/8.9.1) id TAA07990; Wed, 17 Mar 1999 19:16:57 -0800 (PST) Message-ID: <19990317191656.43093@helen.CS.Berkeley.EDU> Date: Wed, 17 Mar 1999 19:16:56 -0800 From: Josh MacDonald To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI Tape (HP SureStore T20) trouble References: <19990316235547.14559@helen.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Matthew Jacob on Wed, Mar 17, 1999 at 04:31:02AM -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quoting Matthew Jacob (mjacob@feral.com): > > > > (sa0:ncr0:0:5:0): SPACE. CDB: 11 1 ff ff ff 0 > > (sa0:ncr0:0:5:0): ILLEGAL REQUEST asc:2c,0 > > (sa0:ncr0:0:5:0): Command sequence error > > (sa0:ncr0:0:5:0): unable to backspace over one of double filemarks at EOD- opting for safety > > > > and it rewinds the tape even though I opened the nrsa0 device (which > > supposedly does NOT rewind). I am able to restore from the dump, but > > it seems broken that it does not rewind. Also, the drive says it supports > (I'm sure you mean "It is broken that it rewinds") > > hardware compression, but 'mt status' says it is unsupported. Does > > anyone know whats the trouble with either of these problems? > > There are actually three problems here: > > Problem #1: The driver apparently has a problem backspacing over a filemark. > This indicates to me that this should be treated as if it were a QIC drive > that only has one filemark at EOD. Frankly, I would have loved to enforce > only one filemark at EOD for all except 1/2" reel drives, but folks shot that > down months ago. > > Fix: Quirk the drive to have the SA_QUIRK_1FM. How does one go about that? > Problem #2: When this failed, the driver tried to eject the tape. > Well, that doesn't work for a lot of drives. This has been discussed on > this list quite a bit recently. > > Fix: I proposed a change that will not have the drive rewind, but will > disallow further writes until either a rewind, eject, or a space to EOD > is performed. This fix is in progress. If I didn't have a 100 degree > fever, it'd probably be done some time in the next day or so. Cool. > Problem #3: Compression is being reported as the driver tried to use some > 'standard' means to enable compression. Unfortunately, the method chosen > is for a mode page that's in SCSI-3, not for SCSI-2. > > Fix: use the Device Configuration page first and then try the Date > Compression page). However, this may not always guarantee compression if > compression is enabled via some drive specific mechanism, e.g. a density > code. A manual for this device may have this information. Passing that > information back to someone to fold into the driver will be appreciated. The manual has very little information. Only the following, much of which doesn't seem of interest to you. The entire "Tape Format" section from the appendix: Interface: SCSI-2 Tape Format: Format: QIC-3220 Media: HP 20GB/Travan TR-5 (QIC-3220) Number of tracks: 108 Bit density: 106400 bpi Encoding method RLL1,7 Error Correction: Level-10 Reed-Solomon So I dug for information and found some information at: http://www.qic.org/html/qicstan.html There is a complete specification for the QIC-3220 tape format. It says that it uses the ADLC-1 compression algorithm. In a seperate document at the same site, QIC-154 discusses the compression algorithm and QIC-157 is the latest standard available that discusses the SCSI command set (dated 1995). -josh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 19:42: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sakaki.communique.net (sakaki.communique.net [204.27.64.202]) by hub.freebsd.org (Postfix) with ESMTP id 0123C152CC for ; Wed, 17 Mar 1999 19:41:53 -0800 (PST) (envelope-from gjohnson@gs.verio.net) Received: from tony (ppp-204-27-127-140.ne.communique.net [204.27.127.140]) by sakaki.communique.net (8.8.8/8.8.8) with SMTP id VAA24874 for ; Wed, 17 Mar 1999 21:41:33 -0600 (CST) From: "Tony Johnson" To: Subject: RE: Recommended scsi cards. Date: Thu, 18 Mar 1999 21:39:19 -0600 Message-ID: <001901be71ba$124c7950$01646464@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 In-Reply-To: <36EE474D.2E949140@hello.com.tw> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've used a aha-3940 for the longest and it works well... -----Original Message----- From: owner-freebsd-scsi@FreeBSD.ORG [mailto:owner-freebsd-scsi@FreeBSD.ORG] On Behalf Of Kevin Lo Sent: Tuesday, March 16, 1999 5:58 AM To: freebsd-scsi@FreeBSD.ORG Subject: Recommended scsi cards. Hi, Would anyone recommend me scsi cards? Because I have an AHA-2930U, but FreeBSD can't detect it :( Thanks in advance, Kevin. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 20: 3:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sloth.metonymy.com (max3-248.aip.realtime.net [205.238.179.248]) by hub.freebsd.org (Postfix) with ESMTP id 43E4514E47 for ; Wed, 17 Mar 1999 20:03:26 -0800 (PST) (envelope-from khym@bga.com) Received: from localhost (localhost [[UNIX: localhost]]) by sloth.metonymy.com (8.8.8/8.8.7) with ESMTP id WAA03861; Wed, 17 Mar 1999 22:01:56 -0600 (CST) X-Authentication-Warning: sloth.metonymy.com: khym owned process doing -bs Date: Wed, 17 Mar 1999 22:01:37 -0600 (CST) From: Dave Huang X-Sender: khym@sloth.metonymy.com To: Christian Weisgerber Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Quantum Viking and NCR 53C875, anybody? In-Reply-To: <7cpo68$vs6$1@mips.rhein-neckar.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 18 Mar 1999, Christian Weisgerber wrote: > Does anybody out there successfully run a Quantum Viking SCA disk off a > Symbios (nee NCR) 53C875 host adapter? > (No, it's not a FreeBSD box, and no, I can't boot FreeBSD there, but I > doubt that the problem is OS specific.) Well, I've got two Viking 4.5 SCA drives running off an ASUS SC875 (Symbios 53c875 chip)... works fine under Windows NT and NetBSD (I haven't tried it with FreeBSD). FWIW, the drives have firmware rev. 880R. -- Name: Dave Huang | Mammal, mammal / their names are called / INet: khym@bga.com | they raise a paw / the bat, the cat / FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG Dahan: Hani G Y+C 23 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 20:17:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id E384E152F7 for ; Wed, 17 Mar 1999 20:17:34 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id XAA00452; Wed, 17 Mar 1999 23:16:47 -0500 (EST) Date: Wed, 17 Mar 1999 23:16:47 -0500 (EST) From: "Matthew N. Dodd" To: "Kenneth D. Merry" Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <199903160607.XAA23750@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 15 Mar 1999, Kenneth D. Merry wrote: > One question I have is this -- once the media is spinning, how long > does it take to do a read capacity? You can find out like this: > > /usr/bin/time camcontrol cmd -t 60 -v -n da -u 2 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" at scbus2 target 3 lun 0 (pass13,da5) 576998 512 0.04 real 0.01 user 0.01 sys > What happens if the media is not spinning and you do a read capacity? > Does the drive try to spin itself up? eisa-test# camcontrol stop -n da -u 5 Unit stopped successfully eisa-test# camcontrol tur -n da -u 5 Unit is not ready eisa-test# /usr/bin/time camcontrol cmd -t 60 -v -n da -u 5 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" 576998 512 0.04 real 0.00 user 0.02 sys eisa-test# camcontrol tur -n da -u 5 Unit is not ready It doesn't spin it up if its been spun down. > The default timeout for the read capacity in the DA driver is 5 > seconds. If the MO drive attempts, for whatever reason, to spin itself > up when it gets a read capacity, we may need to bump the timeout on > the read capacity commmand. Once the drive eats the disk it reads the capacity. My unit doesn't -not- do a read capacity. I haven't seen it 'forget' the capacity either. I just hooked up a second unit to the system and booted w/o a media unit. A start/tur on the pass device followd by a rescan doesn't result in the device being attached to the da driver. Any chance that camcontrol could gaing the ability to remove a device from the system? 'camcontrol detach' maybe? -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 20:49:37 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id E734015084 for ; Wed, 17 Mar 1999 20:49:19 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id VAA37060; Wed, 17 Mar 1999 21:48:27 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903180448.VAA37060@panzer.plutotech.com> Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: from "Matthew N. Dodd" at "Mar 17, 1999 11:16:47 pm" To: winter@jurai.net (Matthew N. Dodd) Date: Wed, 17 Mar 1999 21:48:27 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew N. Dodd wrote... > On Mon, 15 Mar 1999, Kenneth D. Merry wrote: > > One question I have is this -- once the media is spinning, how long > > does it take to do a read capacity? You can find out like this: > > > > /usr/bin/time camcontrol cmd -t 60 -v -n da -u 2 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" > > at scbus2 target 3 lun 0 (pass13,da5) > > 576998 512 > 0.04 real 0.01 user 0.01 sys Looks good. > > What happens if the media is not spinning and you do a read capacity? > > Does the drive try to spin itself up? > > eisa-test# camcontrol stop -n da -u 5 > Unit stopped successfully > eisa-test# camcontrol tur -n da -u 5 > Unit is not ready > eisa-test# /usr/bin/time camcontrol cmd -t 60 -v -n da -u 5 -c "25 0 0 0 0 > 0 0 0 0 0" -i 8 "i4 i4" > 576998 512 > 0.04 real 0.00 user 0.02 sys > eisa-test# camcontrol tur -n da -u 5 > Unit is not ready > > It doesn't spin it up if its been spun down. Okay, so it caches the information. > > The default timeout for the read capacity in the DA driver is 5 > > seconds. If the MO drive attempts, for whatever reason, to spin itself > > up when it gets a read capacity, we may need to bump the timeout on > > the read capacity commmand. > > Once the drive eats the disk it reads the capacity. My unit doesn't -not- > do a read capacity. I haven't seen it 'forget' the capacity either. What happens if you reset the device? Will it forget then? You can send a BDR to it like this: camcontrol reset 2:3:0 One difference between a probe and a rescan is that we send a bus reset before the probe. > I just hooked up a second unit to the system and booted w/o a media unit. > > A start/tur on the pass device followd by a rescan doesn't result in the > device being attached to the da driver. Nope, I'm sure it didn't. If the device hasn't changed, it won't get broadcasted out to all of the peripheral drivers. And did you have the patch I suggested in scsi_da.c? That will probably allow you to boot without media. > Any chance that camcontrol could gaing the ability to remove a device from > the system? 'camcontrol detach' maybe? I suppose that's possible, but I'd rather just fix things so that the da driver attaches properly. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 20:54:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 9EFFF14D75 for ; Wed, 17 Mar 1999 20:54:38 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id XAA00799; Wed, 17 Mar 1999 23:54:09 -0500 (EST) Date: Wed, 17 Mar 1999 23:54:09 -0500 (EST) From: "Matthew N. Dodd" To: "Kenneth D. Merry" Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <199903180448.VAA37060@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, Kenneth D. Merry wrote: > What happens if you reset the device? Will it forget then? You can send a > BDR to it like this: > > camcontrol reset 2:3:0 at scbus2 target 3 lun 0 (pass13,da5) at scbus2 target 4 lun 0 (pass14,da6) eisa-test# camcontrol reset 2:3:0 camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument eisa-test# camcontrol reset 2:4:0 camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument I think I broke something. :/ > One difference between a probe and a rescan is that we send a bus reset > before the probe. > > > I just hooked up a second unit to the system and booted w/o a media unit. > > > > A start/tur on the pass device followd by a rescan doesn't result in the > > device being attached to the da driver. > > Nope, I'm sure it didn't. If the device hasn't changed, it won't get > broadcasted out to all of the peripheral drivers. Ah. > And did you have the patch I suggested in scsi_da.c? That will probably > allow you to boot without media. No, not yet. > > Any chance that camcontrol could gaing the ability to remove a device from > > the system? 'camcontrol detach' maybe? > > I suppose that's possible, but I'd rather just fix things so that the > da driver attaches properly. Indeed. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 21: 3: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 807B215331 for ; Wed, 17 Mar 1999 21:02:54 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id WAA37209; Wed, 17 Mar 1999 22:02:23 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903180502.WAA37209@panzer.plutotech.com> Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: from "Matthew N. Dodd" at "Mar 17, 1999 11:54: 9 pm" To: winter@jurai.net (Matthew N. Dodd) Date: Wed, 17 Mar 1999 22:02:23 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM921733343-37119-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM921733343-37119-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Matthew N. Dodd wrote... > On Wed, 17 Mar 1999, Kenneth D. Merry wrote: > > What happens if you reset the device? Will it forget then? You can send a > > BDR to it like this: > > > > camcontrol reset 2:3:0 > > at scbus2 target 3 lun 0 (pass13,da5) > at scbus2 target 4 lun 0 (pass14,da6) > > eisa-test# camcontrol reset 2:3:0 > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > eisa-test# camcontrol reset 2:4:0 > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > > I think I broke something. :/ Oops. Matt must not have tested the BDR functionality in camcontrol or something...hmm. Well, try the attached patch for cam_xpt.c. > > And did you have the patch I suggested in scsi_da.c? That will probably > > allow you to boot without media. > > No, not yet. Well, try it out. :) Ken -- Kenneth Merry ken@plutotech.com --ELM921733343-37119-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=cam_xpt.c.reset.031799 Content-Description: cam_xpt.c.reset.031799 Content-Transfer-Encoding: 7bit ==== //depot/cam/sys/cam/cam_xpt.c#190 - /a/ken/perforce/cam/sys/cam/cam_xpt.c ==== *** /tmp/tmp.37177.0 Wed Mar 17 21:59:58 1999 --- /a/ken/perforce/cam/sys/cam/cam_xpt.c Wed Mar 17 21:59:01 1999 *************** *** 904,909 **** --- 904,910 ---- } /* FALLTHROUGH */ case XPT_SCAN_LUN: + case XPT_RESET_DEV: case XPT_ENG_INQ: /* XXX not implemented yet */ case XPT_ENG_EXEC: --ELM921733343-37119-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 21:24: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id A47E71532C for ; Wed, 17 Mar 1999 21:23:58 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id WAA39452; Wed, 17 Mar 1999 22:23:30 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903180523.WAA39452@panzer.plutotech.com> Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <199903180502.WAA37209@panzer.plutotech.com> from "Kenneth D. Merry" at "Mar 17, 1999 10: 2:23 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Wed, 17 Mar 1999 22:23:30 -0700 (MST) Cc: winter@jurai.net, joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kenneth D. Merry wrote... > Matthew N. Dodd wrote... > > On Wed, 17 Mar 1999, Kenneth D. Merry wrote: > > > What happens if you reset the device? Will it forget then? You can send a > > > BDR to it like this: > > > > > > camcontrol reset 2:3:0 > > > > at scbus2 target 3 lun 0 (pass13,da5) > > at scbus2 target 4 lun 0 (pass14,da6) > > > > eisa-test# camcontrol reset 2:3:0 > > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > > eisa-test# camcontrol reset 2:4:0 > > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > > > > I think I broke something. :/ > > Oops. Matt must not have tested the BDR functionality in camcontrol or > something...hmm. Well, try the attached patch for cam_xpt.c. Well, I just tried it out. It does send a BDR to the device, but it looks like there's some bogus behavior. The camcontrol process gets stuck in 'cbwait', so either the CCB isn't getting done(), or the queue is not getting un-frozen. My guess is that the queue is still frozen, since I can't send a TUR to the disk, and I/O times out. Ahh well, more bugs to fix. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 21:29:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id AFCA614BFA for ; Wed, 17 Mar 1999 21:29:23 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id AAA01155; Thu, 18 Mar 1999 00:28:57 -0500 (EST) Date: Thu, 18 Mar 1999 00:28:56 -0500 (EST) From: "Matthew N. Dodd" To: "Kenneth D. Merry" Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <199903180523.WAA39452@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, Kenneth D. Merry wrote: > Kenneth D. Merry wrote... > > > eisa-test# camcontrol reset 2:3:0 > > > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > > > eisa-test# camcontrol reset 2:4:0 > > > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > > Well, I just tried it out. It does send a BDR to the device, but it > looks like there's some bogus behavior. The camcontrol process gets > stuck in 'cbwait', so either the CCB isn't getting done(), or the > queue is not getting un-frozen. ? We still on the same problem? > My guess is that the queue is still frozen, since I can't send a TUR > to the disk, and I/O times out. Ahh well, more bugs to fix. Heh. When I first pluged in the SMO-C501 I thought the behavior was normal. I didn't expect such an ancient device to work without quirks. ("There are no bugs in this code.") -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 21:33:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D9EF14D61 for ; Wed, 17 Mar 1999 21:33:54 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id WAA39505; Wed, 17 Mar 1999 22:33:27 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903180533.WAA39505@panzer.plutotech.com> Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: from "Matthew N. Dodd" at "Mar 18, 1999 0:28:56 am" To: winter@jurai.net (Matthew N. Dodd) Date: Wed, 17 Mar 1999 22:33:27 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew N. Dodd wrote... > On Wed, 17 Mar 1999, Kenneth D. Merry wrote: > > Kenneth D. Merry wrote... > > > > eisa-test# camcontrol reset 2:3:0 > > > > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > > > > eisa-test# camcontrol reset 2:4:0 > > > > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > > > > Well, I just tried it out. It does send a BDR to the device, but it > > looks like there's some bogus behavior. The camcontrol process gets > > stuck in 'cbwait', so either the CCB isn't getting done(), or the > > queue is not getting un-frozen. > > ? We still on the same problem? Yes and no. What I tried was sending a BDR to a disk on my test machine. What I was getting at is that if you send a BDR to your MO drive, and you've got the patch to cam_xpt.c in your kernel, you'll probably just end up freezing the kernel's queue for the drive and you won't be able to talk to it again without rebooting. > > My guess is that the queue is still frozen, since I can't send a TUR > > to the disk, and I/O times out. Ahh well, more bugs to fix. > > Heh. When I first pluged in the SMO-C501 I thought the behavior was > normal. I didn't expect such an ancient device to work without quirks. > ("There are no bugs in this code.") Yeah, I'm sure it won't work without quirks. We've just got to figure out what those quirks are. I think my patch for scsi_da.c will get you up and running without media in the drive. And since it boots with media spinning, all we've got to do is figure out what exactly happens when there is media in the drive but not spinning. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 21:38:34 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id AD2E01530B for ; Wed, 17 Mar 1999 21:37:56 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id AAA01235; Thu, 18 Mar 1999 00:37:31 -0500 (EST) Date: Thu, 18 Mar 1999 00:37:30 -0500 (EST) From: "Matthew N. Dodd" To: "Kenneth D. Merry" Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <199903180533.WAA39505@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, Kenneth D. Merry wrote: > Yeah, I'm sure it won't work without quirks. We've just got to figure out > what those quirks are. (I knew I shouldn't have overloaded 'quirks') What I meant was that I thought the device was broken as designed. Ie: it wasn't possible to have it probe correctly unless there was a media unit in the drive. I mean, the thing is an ESDI disk using a converter. I didn't expect it to have much of a brain. > I think my patch for scsi_da.c will get you up and running without > media in the drive. And since it boots with media spinning, all we've > got to do is figure out what exactly happens when there is media in > the drive but not spinning. *nod* -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 22:14: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 142D614CA3 for ; Wed, 17 Mar 1999 22:14:03 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id BAA01607; Thu, 18 Mar 1999 01:13:37 -0500 (EST) Date: Thu, 18 Mar 1999 01:13:36 -0500 (EST) From: "Matthew N. Dodd" To: "Kenneth D. Merry" Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <199903180502.WAA37209@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 17 Mar 1999, Kenneth D. Merry wrote: > > > allow you to boot without media. > > > > No, not yet. > > Well, try it out. :) da5 at dpt0 bus 0 target 3 lun 0 da5: Removable Direct Access SCSI-CCS device da5: Attempt to query device size failed: NOT READY, Error log overflow Yay. eisa-test# camcontrol reset 2:3:0 Reset of 2:3:0 returned error 0x6 A somewhat different question for you... eisa-test# fdisk da5 ******* Working on device /dev/rda5 ******* parameters extracted from in-core disklabel are: cylinders=153 heads=64 sectors/track=32 (2048 blks/cyl) parameters to be used for BIOS calculations are: cylinders=153 heads=64 sectors/track=32 (2048 blks/cyl) Media sector size is 1024 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 1, size 313343 (305 Meg), flag 80 (active) beg: cyl 0/ sector 2/ head 0; end: cyl 152/ sector 32/ head 63 eisa-test# disklabel da5 disklabel: ioctl DIOCGDINFO: Invalid argument da5: cannot find label (no disk label) da5s4: cannot find label (no disk label) dscheck: b_bcount 512 is not on a sector boundary (ssize 1024) da5: cannot find label (no disk label) da5s4: cannot find label (no disk label) No, this isn't because I've got 1024 byte sector media loaded though that fact that it cares about blocksize is strange. 'disklabel /dev/da5' shows stuff. eisa-test# disklabel -R -r da5 foo disklabel: No space left on device eisa-test# disklabel -R -r /dev/da5 foo disklabel: ioctl DIOCWLABEL: Operation not supported by device I'm confused now. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 22:24:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 44B5A152FD for ; Wed, 17 Mar 1999 22:24:26 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id XAA39730; Wed, 17 Mar 1999 23:24:02 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903180624.XAA39730@panzer.plutotech.com> Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: from "Matthew N. Dodd" at "Mar 18, 1999 1:13:36 am" To: winter@jurai.net (Matthew N. Dodd) Date: Wed, 17 Mar 1999 23:24:02 -0700 (MST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew N. Dodd wrote... > On Wed, 17 Mar 1999, Kenneth D. Merry wrote: > > > > allow you to boot without media. > > > > > > No, not yet. > > > > Well, try it out. :) > > da5 at dpt0 bus 0 target 3 lun 0 > da5: Removable Direct Access SCSI-CCS device > da5: Attempt to query device size failed: NOT READY, Error log overflow > > Yay. Cool. I'll have to figure out the best way to put that quirk in. Until I figure that out, that patch should work for you. > eisa-test# camcontrol reset 2:3:0 > Reset of 2:3:0 returned error 0x6 That means CAM_REQ_INVALID. Hmm. I'll have to look into that one. Maybe the DPT driver doesn't support the BDR CCB? Indeed, that's the case. Oh well. > A somewhat different question for you... > > eisa-test# fdisk da5 > ******* Working on device /dev/rda5 ******* > parameters extracted from in-core disklabel are: > cylinders=153 heads=64 sectors/track=32 (2048 blks/cyl) > > parameters to be used for BIOS calculations are: > cylinders=153 heads=64 sectors/track=32 (2048 blks/cyl) > > Media sector size is 1024 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > > The data for partition 2 is: > > The data for partition 3 is: > > The data for partition 4 is: > sysid 165,(FreeBSD/NetBSD/386BSD) > start 1, size 313343 (305 Meg), flag 80 (active) > beg: cyl 0/ sector 2/ head 0; > end: cyl 152/ sector 32/ head 63 > > eisa-test# disklabel da5 > disklabel: ioctl DIOCGDINFO: Invalid argument > > da5: cannot find label (no disk label) > da5s4: cannot find label (no disk label) > dscheck: b_bcount 512 is not on a sector boundary (ssize 1024) > da5: cannot find label (no disk label) > da5s4: cannot find label (no disk label) > > No, this isn't because I've got 1024 byte sector media loaded though that > fact that it cares about blocksize is strange. > > 'disklabel /dev/da5' shows stuff. > > eisa-test# disklabel -R -r da5 foo > disklabel: No space left on device It's probably giving you that because you've already got a label on the device and you're trying to write a new one. > eisa-test# disklabel -R -r /dev/da5 foo > disklabel: ioctl DIOCWLABEL: Operation not supported by device > > I'm confused now. Try the raw device instead. Perhaps you can't write a label to a block device. If you want to get rid of the current label, this should do the trick: dd if=/dev/zero of=/dev/rda5 bs=64k count=1 If you really want the low-down on disklabel and slice stuff, ask Bruce. I generally end up just messing with it until it works. (I'm getting better at it, though.) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 17 22:55:33 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id F330714D61 for ; Wed, 17 Mar 1999 22:54:47 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id RAA13465; Thu, 18 Mar 1999 17:54:27 +1100 Date: Thu, 18 Mar 1999 17:54:27 +1100 From: Bruce Evans Message-Id: <199903180654.RAA13465@godzilla.zeta.org.au> To: ken@plutotech.com, winter@jurai.net Subject: Re: SONY SMO-C501-09 not recognized under CAM Cc: freebsd-scsi@FreeBSD.ORG, joerg_wunsch@uriah.heep.sax.de Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >eisa-test# disklabel da5 >disklabel: ioctl DIOCGDINFO: Invalid argument > >da5: cannot find label (no disk label) >da5s4: cannot find label (no disk label) >dscheck: b_bcount 512 is not on a sector boundary (ssize 1024) >da5: cannot find label (no disk label) >da5s4: cannot find label (no disk label) > >No, this isn't because I've got 1024 byte sector media loaded though that >fact that it cares about blocksize is strange. This is because disklabel (un)helpfully converts da5 to /dev/da5c (the 'c' partition on the first FreeBSD slice, aka da5s4c), and the slice containing this partition doesn't have a label, and the driver thinks that the media blocksize is 1024. Requesting an i/o size of less than the media blocksize is a bug somewhere (probably in disklabel(8)). Printing this message in dscheck() is a another bug. There is no portably way to determine the blocksize; applications may need to try various multiples of DEV_BSIZE. >'disklabel /dev/da5' shows stuff. This is because /dev/da5 is the whole disk, which is completely different from the 'c' partition on the first FreeBSD slice (if any). Whole disks always have a read-only in-core label. >eisa-test# disklabel -R -r da5 foo >disklabel: No space left on device This is because sectors/unit and/or one of the partition sizes specified in "foo" is larger than the number of physical sectors. This may be caused by confusion about the physical sector size. >eisa-test# disklabel -R -r /dev/da5 foo >disklabel: ioctl DIOCWLABEL: Operation not supported by device This is because the read-only in-core label for the whole disk is read-only. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 18 8:27:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id BCE801542C for ; Thu, 18 Mar 1999 08:26:16 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id LAA06644; Thu, 18 Mar 1999 11:25:47 -0500 (EST) Date: Thu, 18 Mar 1999 11:25:47 -0500 (EST) From: "Matthew N. Dodd" To: Bruce Evans Cc: ken@plutotech.com, freebsd-scsi@FreeBSD.ORG, joerg_wunsch@uriah.heep.sax.de Subject: Re: SONY SMO-C501-09 not recognized under CAM In-Reply-To: <199903180654.RAA13465@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 18 Mar 1999, Bruce Evans wrote: > This is because disklabel (un)helpfully converts da5 to /dev/da5c (the > 'c' partition on the first FreeBSD slice, aka da5s4c), and the slice > containing this partition doesn't have a label, and the driver thinks > that the media blocksize is 1024. Requesting an i/o size of less than > the media blocksize is a bug somewhere (probably in disklabel(8)). > Printing this message in dscheck() is a another bug. There is no > portably way to determine the blocksize; applications may need to try > various multiples of DEV_BSIZE. The same thing happens with 512 byt/sectored media. > This is because sectors/unit and/or one of the partition sizes specified > in "foo" is larger than the number of physical sectors. This may be > caused by confusion about the physical sector size. Humm... I've tried reducing the size of the 'c' partition, the only one specified in 'foo' but it doesn't work. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 18 11:31:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D5A5B14CF0 for ; Thu, 18 Mar 1999 11:31:07 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA24600 for ; Thu, 18 Mar 1999 11:30:43 -0800 Date: Thu, 18 Mar 1999 11:30:43 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: freebsd-scsi@freebsd.org Subject: SCSI resets in CAM during startup.... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (yes, I know I'm supposed to be working on tape stuff, but I had to put on another hat today...gawd, my head aches....) I'd like to make a request- I'd like the initial SCSI reset done currently by the CAM probe framework to be: a) The responsibility/discretion of the hba driver to perform. b) Config option'ed off (for a CAM_MULTI_INITIATOR) option. This doesn't mean that a camcontrol cannot occur, but I don't want to always have it on automatically. One reason for #a is that the Fibre Channel equivalent of this is pretty heavy weight. If I implement this in the Qlogic as the BUS_RESET command, it basically then has to traverse the entire loop and send a FCP CMND_IU to all logged in targets with the RESET_TARGET task management function. This can be really problematic for a lot of loop configurations, as well as being completely unnecessary from a state point of view. If I implement this as a Loop Reset or a LIP, that's even more drastic. What I've been doing up until now is ignoring the XPT_RESET_BUS for Fibre Channel, but that's not right either. This also plays all into #b, where you really don't want to issue bus resets at all if you can help it. The current Qlogic parallel SCSI code actually forces async/narrow as it's first state so state management is a bit easier. Opinions? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 18 11:36:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id ADF8815563 for ; Thu, 18 Mar 1999 11:36:35 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id OAA09299 for ; Thu, 18 Mar 1999 14:36:16 -0500 (EST) Date: Thu, 18 Mar 1999 14:36:15 -0500 (EST) From: "Matthew N. Dodd" To: freebsd-scsi@FreeBSD.ORG Subject: CAM entry point for SCSI-to-Ethernet device. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On a whim I purchased an old SCSI to Ethernet box which happens to be supported by NetBSD by the 'se' device. pt0: Fixed Processor SCSI-0 device Now, as I understand it, the various CAM devices are attached by announcing them to the csa.callback set by the XXinit routine specified in the periph_driver struct that gets added to the magicical CAM config via DATA_SET(periphdriver_set, chdriver); Which is all fine and dandy. In porting the driver from NetBSD I'm curious to know where to hook up the driver to CAM. My thought was to create 'scsi_se.[ch]' and let the driver live there (or I can split up the network parts to live elsewhere) and in my csa.callback routine examine the device name as well as the device type (T_PROCESSOR) before attaching (so I know I have a valid SE device). Since I'd like the device to show up as 'seX' (woo!) this means that the 'pt' driver will have to not attach (or attach in the way that the 'pass' device does). Any ideas? I really don't want to intrude on the 'PT" device. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 18 15:20:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from nebraska.utcorp.com (nebraska.utcorp.com [146.145.135.14]) by hub.freebsd.org (Postfix) with ESMTP id 623AA14D1B for ; Thu, 18 Mar 1999 15:20:01 -0800 (PST) (envelope-from kseel@utcorp.com) Received: from utcorp.com (x-kspc.utcorp.com [146.145.135.17]) by nebraska.utcorp.com (8.8.5/8.8.5) with ESMTP id WAA24104 for ; Thu, 18 Mar 1999 22:59:24 -0500 (EST) Message-ID: <36F18A72.CCF75506@utcorp.com> Date: Thu, 18 Mar 1999 18:21:22 -0500 From: Kurt Seel X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: buslogic bt958 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is the bt 958 still a viable card? I have a couple and would like to use them in my webserver. I am looking for _performance_, would I be better off with an adaptek 2940UW? I want to run a stripe across 2 or 3 cheetah's -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 18 16:52:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from milf18.bus.net (milf18.bus.net [207.41.25.18]) by hub.freebsd.org (Postfix) with ESMTP id 438F314E1C for ; Thu, 18 Mar 1999 16:52:43 -0800 (PST) (envelope-from cao@milf18.bus.net) Received: (from cao@localhost) by milf18.bus.net (8.8.8/8.8.8) id TAA27595; Thu, 18 Mar 1999 19:52:09 -0500 (EST) (envelope-from cao) Date: Thu, 18 Mar 1999 19:52:09 -0500 From: "Chuck O'Donnell" To: "Justin T. Gibbs" Cc: "Chuck O'Donnell" , scsi@FreeBSD.ORG Subject: Re: error messages from bt driver Message-ID: <19990318195209.A27547@milf18.bus.net> References: <19990313183436.B11051@milf18.bus.net> <199903140053.RAA13024@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199903140053.RAA13024@pluto.plutotech.com>; from Justin T. Gibbs on Sat, Mar 13, 1999 at 05:44:29PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Mar 13, 1999 at 05:44:29PM -0700, Justin T. Gibbs wrote: > >Thanks for the reply Justin. > > > >I tried 5.06I from the Mylex site, but no improvement. Same error > >messages show up. Any thoughts on other things I can check? > > > >Thanks. > > > >Chuck > > One thing I don't know about on the MultiMasters is how they deal > with a disk returning queue full status. Your Seagate will only > handle 64 commands at a time, but we've queued up 191 to the > Buslogic. Perhaps it will not release the mailbox for a transaction > that is in the queue full state? This would cause the first error > message to occur. My guess is that a quirk entry in sys/cam/cam_xpt.c > limiting the number of tags for your drive to 64 will prevent the > problem from happening. > I've had no disk errors since we made the quirk entries. If my understanding is correct, the quirk entries were made because the controller didn't handle SCSI_STATUS_QUEUE_FULL correctly (in cam_periph.c)? But now I see the following, which I understand to be only informational messages, but still curious as to the source: Mar 16 11:20:17 fern /kernel: (pass0:bt0:0:0:0): tagged openings now 32 Mar 16 11:20:23 fern /kernel: (pass0:bt0:0:0:0): tagged openings now 2 I would have thought that if the controller wasn't passing along the queue full message, then this code would never be triggered. Does the `pass' driver do something different that the `da' driver does not? Thanks. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 18 17: 7:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from milf18.bus.net (milf18.bus.net [207.41.25.18]) by hub.freebsd.org (Postfix) with ESMTP id 5AF59154CD for ; Thu, 18 Mar 1999 17:07:43 -0800 (PST) (envelope-from cao@milf18.bus.net) Received: (from cao@localhost) by milf18.bus.net (8.8.8/8.8.8) id UAA27680; Thu, 18 Mar 1999 20:07:05 -0500 (EST) (envelope-from cao) Date: Thu, 18 Mar 1999 20:07:05 -0500 From: "Chuck O'Donnell" To: Kurt Seel Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: buslogic bt958 Message-ID: <19990318200704.B27547@milf18.bus.net> References: <36F18A72.CCF75506@utcorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <36F18A72.CCF75506@utcorp.com>; from Kurt Seel on Thu, Mar 18, 1999 at 06:21:22PM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Mar 18, 1999 at 06:21:22PM -0500, Kurt Seel wrote: > > Is the bt 958 still a viable card? I have a couple and would like to > use them in my webserver. I am looking for _performance_, would I be > better off with an adaptek 2940UW? > I want to run a stripe across 2 or 3 cheetah's > I just set up two new servers using the BT-958: bt0: rev 0x08 ... bt0: BT-958 FW Rev. 5.07B Ultra Wide SCSI Host Adapter, SCSI ID 7, 192 CCBs I've had some trouble with errors related to the tagged queuing. Doesn't seem to be a show stopper, as you can add a quirk entry to abate the problem. See thread "error messages from bt driver" in the scsi archives (last week?). I haven't done any performance testing, I guess I was more interested in reliability. On a side note, I've never had a stitch of trouble from the Adaptec 2940's. Thanks. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 18 23: 8:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 147FD14BCF for ; Thu, 18 Mar 1999 23:08:19 -0800 (PST) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id IAA19515 for freebsd-scsi@FreeBSD.ORG; Fri, 19 Mar 1999 08:08:00 +0100 (CET) (envelope-from olli) Date: Fri, 19 Mar 1999 08:08:00 +0100 (CET) From: Oliver Fromme Message-Id: <199903190708.IAA19515@dorifer.heim3.tu-clausthal.de> To: freebsd-scsi@FreeBSD.ORG Subject: Re: Boot-time scsi probe problem Newsgroups: list.freebsd-scsi Organization: Administration Heim 3 Reply-To: freebsd-scsi@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kenneth D. Merry wrote in list.freebsd-scsi: > Jason K. Fritcher wrote... > > [...] > > Ctrl-Alt-Del, the system will lockup when it tries to probe the scsi bus for > > devices. It will wait the 15 seconds for things to settle, and then it locks > > one the probe starts. I am forced to use the reset button to restart it. > > > > The hardware I have ia an Asus P2B-LS motherboard with onboard AIC-7890 SCSI > > controller + 3860 bridge. > > This sounds and looks like a known problem with the Adaptec 7890 chips. A > number of people have reported this. Including me... By the way, I can _reliably_ reproduce the problem when I increase the "PCI latency" in the BIOS setup from 32 (the default) to 64. It _always_ locks up then after waiting for the SCSI devices to settle. So I set it back to 32 -- with that setting, it locks up only sometimes, but not always. Maybe there's a setting with which it will always work, but finding that out by pure experimentation would be very time consuming (and I don't really have a clue what that "PCI latency" means, and what things could break if I play with it). When booting in verbose mode, it also prints some error messages. Would those be helpful for the developers? If so, I can set it to 64 again to reproduce the problem and write all that stuff down. Just let me know. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 6:22:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.iol.ie (mail1.mail.iol.ie [194.125.2.192]) by hub.freebsd.org (Postfix) with ESMTP id CA57015018 for ; Fri, 19 Mar 1999 06:22:24 -0800 (PST) (envelope-from nick@iol.ie) Received: from beckett.earlsfort.iol.ie (beckett.earlsfort.iol.ie [194.125.21.2]) by mail.iol.ie Sendmail (v8.9.3) with ESMTP id OAA72888 for ; Fri, 19 Mar 1999 14:22:01 GMT Received: (from nick@localhost) by beckett.earlsfort.iol.ie Sendmail (v8.8.8) id OAA27845 for freebsd-scsi@freebsd.org; Fri, 19 Mar 1999 14:22:01 GMT From: Nick Hilliard Message-Id: <199903191422.OAA27845@beckett.earlsfort.iol.ie> Subject: dpt raid-5 performance To: freebsd-scsi@freebsd.org Date: Fri, 19 Mar 1999 14:22:00 +0000 (GMT) X-NCC-RegID: ie.iol Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org this particular topic comes up fairly regularly, but: I have a DPT 2044W RAID card (this is the Smartcache IV system with a RAID add-on module). The card has 64M non-ECC onboard RAM and is attached to 4 x barracuda 9Gb disks in a eurologic disk shelf. The cable is not long (1.5m), and the disk shelf is terminated mid-way on the shelf backplane, so the total bus length is pretty short. The terminator is the one recommended by Eurologic. The card is in a P-200 with 128Mb RAM and 3.1-RELEASE. Softupdates are enabled. If I set up a raid-5 system on these disks with a slice-size of 512K, the write performance is terrible. Bonnie reports: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 256 541 7.5 491 1.7 458 2.3 4293 59.1 4335 16.2 193.6 6.8 RAID creation and newfs take forever, but the disks never appear to be particularly busy. iostat suggests that the system is managing between 30 and 50 tps. Copying files on to the raid with tar takes forever: for long periods, the write rate would rarely exceed 250K/sec, according to iostat. In comparison, bonnie reports 2.1Mb/sec write speed when using the same system configured with RAID-0/512K. I'm aware that RAID-5 means piles of parity/verify overhead, but this sort of speed hit seems ridiculous and looks as if there's a serious problem somewhere. Does anyone have any ideas? Nick Hilliard Ireland On-Line System Operations To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 6:29:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id ED65514CEB for ; Fri, 19 Mar 1999 06:29:11 -0800 (PST) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id AAA24508; Sat, 20 Mar 1999 00:28:39 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma024500; Sat, 20 Mar 99 00:28:23 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id AAA15531; Sat, 20 Mar 1999 00:28:22 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id AAA10101; Sat, 20 Mar 1999 00:28:22 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id AAA12777; Sat, 20 Mar 1999 00:28:20 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199903191428.AAA12777@nymph.detir.qld.gov.au> To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG, syssgm@detir.qld.gov.au Subject: Re: Strange SCSI QIC tape behaviour References: In-Reply-To: from Matthew Jacob at "Sat, 13 Mar 1999 09:17:04 -0800" Date: Sat, 20 Mar 1999 00:28:19 +1000 From: Stephen McKay Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've discovered a little more about the behaviour of the TDC4200 as it relates to the current driver and fixed vs variable blocking. My earlier message described some of my difficulty reusing variable blocked tapes, even after 'mt erase'. I have just found that 'mt density 0' is required or you get nowhere. Strangely, it seems to have no effect as far as 'mt status' is concerned, though it certainly changed the behaviour of the drive. I think the SCSI tape driver maintains some sort of state that is out of date, and maintains it even over reinsertions of the tape media. So 'mt density 0' just gets it to resync with what the drive thinks is going on. I got as far as sasetparams() in scsi_sa.c, but now I know I need to read a lot more of the SCSI spec, and that could take quite some time. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 10:58: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 651E4150D4 for ; Fri, 19 Mar 1999 10:57:57 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id LAA15363; Fri, 19 Mar 1999 11:48:35 -0700 (MST) Date: Fri, 19 Mar 1999 11:48:35 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903191848.LAA15363@narnia.plutotech.com> To: "Matthew N. Dodd" Cc: scsi@FreeBSD.org Subject: Re: CAM entry point for SCSI-to-Ethernet device. X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > My thought was to create 'scsi_se.[ch]' and let the driver live there (or > I can split up the network parts to live elsewhere) and in my csa.callback > routine examine the device name as well as the device type (T_PROCESSOR) > before attaching (so I know I have a valid SE device). > > Since I'd like the device to show up as 'seX' (woo!) this means that the > 'pt' driver will have to not attach (or attach in the way that the 'pass' > device does). > > Any ideas? In CAM, multiple drivers may attach to the same underlying device (e.g there is no special code to handle the 'pass' driver). So long as the pt device is not 'active' the se driver shouldn't care a bit about whether it has also attached to the cabeltron or not. Eventually, there will be locking primitives available for you to claim exclusive or shared access to the underlying device, but I haven't found the time to write them yet. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 11:15:49 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id B4EA714BF4 for ; Fri, 19 Mar 1999 11:15:44 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id MAA15409; Fri, 19 Mar 1999 12:06:24 -0700 (MST) Date: Fri, 19 Mar 1999 12:06:24 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903191906.MAA15409@narnia.plutotech.com> To: "Kenneth D. Merry" Cc: scsi@FreeBSD.org Subject: Re: cvs commit: src/sys/cam cam_xpt.c X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199903142053.NAA13995@panzer.plutotech.com> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The issue isn't really whether it's "poor performance" or "poor for a wide > drive", but whether the performance you're getting out of the drive is what > the drive is capable of. Remember too that the type of controller the disk is attached to and the speed of the system will greatly affect the performance numbers. I don't know if all of this information has been provided along with the benchmark numbers. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 11:21:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 3435F14FED for ; Fri, 19 Mar 1999 11:21:31 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id OAA23144; Fri, 19 Mar 1999 14:21:07 -0500 (EST) Date: Fri, 19 Mar 1999 14:21:06 -0500 (EST) From: "Matthew N. Dodd" To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-Reply-To: <199903191848.LAA15363@narnia.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 19 Mar 1999, Justin T. Gibbs wrote: > In CAM, multiple drivers may attach to the same underlying device (e.g > there is no special code to handle the 'pass' driver). So long as the > pt device is not 'active' the se driver shouldn't care a bit about > whether it has also attached to the cabeltron or not. Eventually, > there will be locking primitives available for you to claim exclusive > or shared access to the underlying device, but I haven't found the > time to write them yet. Ah, so at bootup I'll see: pt0 at dpt0 bus 0 target 5 lun 0 pt0: Fixed Processor SCSI-0 device se0 at dpt0 bus 0 target 5 lun 0 se0: SCSI to Ethernet se0: address 00:00:1d:0a:23:d0 Or somesuch? -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 11:25: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id BCADE14FF8 for ; Fri, 19 Mar 1999 11:25:02 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id MAA12073; Fri, 19 Mar 1999 12:24:40 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903191924.MAA12073@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Matthew N. Dodd" Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-reply-to: Your message of "Fri, 19 Mar 1999 14:21:06 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Mar 1999 12:15:39 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Ah, so at bootup I'll see: > >pt0 at dpt0 bus 0 target 5 lun 0 >pt0: Fixed Processor SCSI-0 device >se0 at dpt0 bus 0 target 5 lun 0 >se0: SCSI to Ethernet >se0: address 00:00:1d:0a:23:d0 > >Or somesuch? Yup. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 11:31:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 141AE150EA for ; Fri, 19 Mar 1999 11:31:16 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id OAA23306; Fri, 19 Mar 1999 14:30:53 -0500 (EST) Date: Fri, 19 Mar 1999 14:30:53 -0500 (EST) From: "Matthew N. Dodd" To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-Reply-To: <199903191924.MAA12073@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 19 Mar 1999, Justin T. Gibbs wrote: > >pt0 at dpt0 bus 0 target 5 lun 0 > >pt0: Fixed Processor SCSI-0 device > >se0 at dpt0 bus 0 target 5 lun 0 > >se0: SCSI to Ethernet > >se0: address 00:00:1d:0a:23:d0 > > > >Or somesuch? > > Yup. So 'camcontrol devlist is gonna look like this: ... at scbus2 target 5 lun 0 (pass15,pt0) at scbus2 target 5 lun 0 (pass16,se0) ... Seems kind of redundant. Unless of course CAM does this: at scbus2 target 5 lun 0 (pass15,pt0,se0) Which I hope it does. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 11:41:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id CF34C14FDD for ; Fri, 19 Mar 1999 11:40:51 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id MAA15479; Fri, 19 Mar 1999 12:31:27 -0700 (MST) Date: Fri, 19 Mar 1999 12:31:27 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903191931.MAA15479@narnia.plutotech.com> To: mjacob@feral.com Cc: scsi@FreeBSD.org Subject: Re: SCSI resets in CAM during startup.... X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > (yes, I know I'm supposed to be working on tape stuff, but I had to put on > another hat today...gawd, my head aches....) > > > I'd like to make a request- I'd like the initial SCSI reset done currently > by the CAM probe framework to be: > > a) The responsibility/discretion of the hba driver to perform. Hmm. I've added the ability for the HBA to request that the initial bus reset not occur a little while ago. Take a look at the PIM_NOBUSRESET flag for the path inquiry ccb. This flag only effects bus reset requests during initial probe situations. I added it for target mode. > b) Config option'ed off (for a CAM_MULTI_INITIATOR) option. I agree that you should be able to indicate that a particular bus is connected to multiple initiators, but I don't know that a single option switch affecting all busses is the right solution. Before anything can happen here, the probe code in cam_xpt needs to be modified so that, in the case of no bus reset, the controller is told to perform negotiation with the first command on the bus. Otherwise outstanding transfer negotiations left over by the BIOS will screw things up. This is on my white board. > One reason for #a is that the Fibre Channel equivalent of this is > pretty heavy weight. For Fiber Channel, the initial bus reset is not necessary as no transfer negotiation ever occurs. The proper solution here is for the code in cam_xpt.c to query the controller to see if negotiation is possible on that controller and to only perform the bus reset if there is the posiblity of a stale negotiation. This should be an easy thing to fix. > If I implement this in the Qlogic as the BUS_RESET command, it basically > then has to traverse the entire loop and send a FCP CMND_IU to all logged > in targets with the RESET_TARGET task management function. This can be > really problematic for a lot of loop configurations, as well as being > completely unnecessary from a state point of view. > > If I implement this as a Loop Reset or a LIP, that's even more drastic. > > What I've been doing up until now is ignoring the XPT_RESET_BUS for Fibre > Channel, but that's not right either. > > This also plays all into #b, where you really don't want to issue bus > resets at all if you can help it. The current Qlogic parallel SCSI code > actually forces async/narrow as it's first state so state management is a > bit easier. > > Opinions? Perhaps we need to have a larger 'reset' vocabulary? For Fibre-Channel, these are only going to occur in the event of error recovery or an explicit user request, but even so, you should be able to better express what you are attempting to achieve with the reset. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 11:41:38 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id CE6C714BF4 for ; Fri, 19 Mar 1999 11:41:36 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id MAA12517; Fri, 19 Mar 1999 12:41:13 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903191941.MAA12517@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Matthew N. Dodd" Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-reply-to: Your message of "Fri, 19 Mar 1999 14:30:53 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Mar 1999 12:32:11 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Seems kind of redundant. Unless of course CAM does this: > > at scbus2 target 5 lun 0 (pass15,pt0,se0) > >Which I hope it does. Which is what it will do. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 11:49:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 509A915103 for ; Fri, 19 Mar 1999 11:49:33 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id OAA23578; Fri, 19 Mar 1999 14:49:12 -0500 (EST) Date: Fri, 19 Mar 1999 14:49:12 -0500 (EST) From: "Matthew N. Dodd" To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-Reply-To: <199903191941.MAA12517@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 19 Mar 1999, Justin T. Gibbs wrote: > >Seems kind of redundant. Unless of course CAM does this: > > > > at scbus2 target 5 lun 0 (pass15,pt0,se0) > > > >Which I hope it does. > > Which is what it will do. Good. Any opinions on filenames and such? sys/cam/scsi/scsi_se.[ch] works for me but of course this may not work for all SCSI to ethernet devices (There are a few others out there but I'm not sure if they use the same protocol.) I could use 'cse' and scsi_cse.[ch] for 'Cabletron Scsi Ethernet'. How about the network code? Does that belong in a 'scsi' directory? I'm not sure it makes much sense to separate it out but still. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 12:44:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 7BA2A15106 for ; Fri, 19 Mar 1999 12:44:24 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id NAA14226; Fri, 19 Mar 1999 13:44:03 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903192044.NAA14226@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Matthew N. Dodd" Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: CAM entry point for SCSI-to-Ethernet device. In-reply-to: Your message of "Fri, 19 Mar 1999 14:49:12 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Mar 1999 13:35:01 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Any opinions on filenames and such? se is probably best. If it turns out that we want to support other SCSI-ethernet protocols, we can break the driver out into common and device specific sub-modules. >How about the network code? Does that belong in a 'scsi' directory? I'm >not sure it makes much sense to separate it out but still. I would expect this to fall into the same category as for say a disk driver. These drivers are not split out into a buffer I/O portion and a SCSI portion. They are, in effect, buffer I/O to SCSI translators. The SE driver is a network to SCSI I/O translator. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 14:13:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from arjun.niksun.com (gw.niksun.com [206.20.52.122]) by hub.freebsd.org (Postfix) with ESMTP id E543A1579F for ; Fri, 19 Mar 1999 14:13:44 -0800 (PST) (envelope-from ath@niksun.com) Received: from stiegl.niksun.com (stiegl.niksun.com [10.0.0.44]) by arjun.niksun.com (8.8.8/8.8.8) with ESMTP id RAA25299; Fri, 19 Mar 1999 17:13:24 -0500 (EST) Received: from stiegl.niksun.com (localhost.niksun.com [127.0.0.1]) by stiegl.niksun.com (8.8.8/8.8.7) with ESMTP id RAA15833; Fri, 19 Mar 1999 17:13:22 -0500 (EST) (envelope-from ath@stiegl.niksun.com) Message-Id: <199903192213.RAA15833@stiegl.niksun.com> From: Andrew Heybey To: Gerard Roudier Cc: freebsd-scsi@freebsd.org Subject: Re: NCR 895 performance In-reply-to: Your message of Fri, 19 Mar 1999 22:06:00 +0100. Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 19 Mar 1999 17:13:22 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Things that can explain at least part of the difference may be, in my > opinion: > > 1 - Some important features of the chip not being enabled. > 2 - The different number of tags. > 3 - The way the FreeBSD ncr driver walk the CCB list on reselection. > 4 - Also the number of interrupts. > > Could you make the same benchmark using a small number of tags, for > example 8 and report the interrupts and IO statistics of both drivers for > that benchmark. Thanks for the reply. When I get a little time, I will try the same benchmark with the same number of tags for each controller. > It would also be interesting to know which of the following features: > - Prefetch > - Burst-op > - Cache Line size > - Write and Invalidate > - Bursting (and burst size max) > - On-chip RAM > were being used in your evaluation of the 895. I used whatever sys/pci/ncr.c gives me. Do you have any suggestions as to which features should be set how? andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 19 19:17:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from hydrogen.fircrest.net (metriclient-2.uoregon.edu [128.223.172.2]) by hub.freebsd.org (Postfix) with ESMTP id 336781530D for ; Fri, 19 Mar 1999 19:17:03 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.fircrest.net (8.9.1/8.8.7) id TAA08031; Fri, 19 Mar 1999 19:16:46 -0800 (PST) Message-ID: <19990319191646.63534@hydrogen.nike.efn.org> Date: Fri, 19 Mar 1999 19:16:46 -0800 From: John-Mark Gurney To: freebsd-scsi@freebsd.org Subject: 3.1R hangs while 3.0R w/ CAM as of Dec 18th doesn't... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-CURRENT 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 Precedence: bulk X-Loop: FreeBSD.org well, I was going to upgrade my server to 3.1R but it turns out that the scsi code hangs after it prints the waiting for devices to settle messages... but on 3.0-R w/ CAM as of Dec 18th, this isn't a problem, though I do have some cd-rom drives that are a bit non standard... this is the output from 3.0-R: [...] bt0: rev 0x00 int a irq 15 on pci0.8.0 bt0: BT-946C FW Rev. 4.28D Narrow SCSI Host Adapter, SCSI ID 7, 100 CCBs adv0: rev 0x02 int a irq 10 on pci0.10. 0 adv0: AdvanSys Ultra SCSI Host Adapter, SCSI ID 7, queue depth 240 [...] Waiting 2 seconds for SCSI devices to settle (probe4:bt0:0:4:1): INQUIRY. CDB: 12 20 0 0 24 0 (probe4:bt0:0:4:1): error code 67 (probe3:bt0:0:3:1): INQUIRY. CDB: 12 20 0 0 24 0 (probe3:bt0:0:3:1): error code 67 (probe0:bt0:0:4:2): INQUIRY. CDB: 12 40 0 0 24 0 (probe0:bt0:0:4:2): error code 67 (probe1:bt0:0:3:2): INQUIRY. CDB: 12 40 0 0 24 0 (probe1:bt0:0:3:2): error code 67 (probe0:bt0:0:4:3): INQUIRY. CDB: 12 60 0 0 24 0 (probe0:bt0:0:4:3): error code 67 (probe1:bt0:0:3:3): INQUIRY. CDB: 12 60 0 0 24 0 (probe1:bt0:0:3:3): error code 77 (probe0:bt0:0:4:4): INQUIRY. CDB: 12 80 0 0 24 0 (probe0:bt0:0:4:4): error code 77 (probe1:bt0:0:3:4): INQUIRY. CDB: 12 80 0 0 24 0 (probe1:bt0:0:3:4): error code 67 (probe0:bt0:0:4:5): INQUIRY. CDB: 12 a0 0 0 24 0 (probe0:bt0:0:4:5): error code 67 (probe1:bt0:0:3:5): INQUIRY. CDB: 12 a0 0 0 24 0 (probe1:bt0:0:3:5): error code 77 (probe0:bt0:0:4:6): INQUIRY. CDB: 12 c0 0 0 24 0 (probe0:bt0:0:4:6): error code 77 (probe1:bt0:0:3:6): INQUIRY. CDB: 12 c0 0 0 24 0 (probe1:bt0:0:3:6): error code 67 (probe0:bt0:0:4:7): INQUIRY. CDB: 12 e0 0 0 24 0 (probe0:bt0:0:4:7): error code 67 (probe1:bt0:0:3:7): INQUIRY. CDB: 12 e0 0 0 24 0 (probe1:bt0:0:3:7): error code 77 sa0 at adv0 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.0MB/s transfers (5.0MHz, offset 8) da3 at adv0 bus 0 target 1 lun 0 da3: Fixed Direct Access SCSI-CCS device da3: 3.300MB/s transfers da3: 1959MB (4014054 512 byte sectors: 255H 63S/T 249C) da5 at adv0 bus 0 target 4 lun 0 da5: Fixed Direct Access SCSI-CCS device da5: 3.300MB/s transfers da5: 992MB (2031705 512 byte sectors: 64H 32S/T 992C) da2 at adv0 bus 0 target 0 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.0MB/s transfers (20.0MHz, offset 15) da2: 2068MB (4236661 512 byte sectors: 255H 63S/T 263C) da6 at bt0 bus 0 target 1 lun 0 da6: Fixed Direct Access SCSI-CCS device da6: 10.0MB/s transfers (10.0MHz, offset 15) da6: 1959MB (4014054 512 byte sectors: 128H 32S/T 979C) da0 at bt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled da0: 1013MB (2074880 512 byte sectors: 64H 32S/T 1013C) da1 at bt0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled da1: 2047MB (4193360 512 byte sectors: 128H 32S/T 1023C) cd3 at adv0 bus 0 target 2 lun 0 cd3: Removable CD-ROM SCSI-2 device cd3: 3.300MB/s transfers cd3: cd present [345872 x 2048 byte records] cd4 at adv0 bus 0 target 5 lun 0 cd4: Removable CD-ROM SCSI-2 device cd4: 4.32MB/s transfers (4.32MHz, offset 15) cd4: cd present [80040 x 2048 byte records] cd0 at bt0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: cd present [275057 x 2048 byte records] cd1 at bt0 bus 0 target 3 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 3.300MB/s transfers cd1: cd present [300225 x 2048 byte records] cd2 at bt0 bus 0 target 4 lun 0 cd2: Removable CD-ROM SCSI-2 device cd2: 3.300MB/s transfers cd2: Attempt to query device size failed: NOT READY, Medium not present changing root device to da0s1a thanks for the help... if you want I can try newer scsi code that is from 3.1-stable... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD Don't trust anyone you don't have the source for To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 20 0:40:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from willy.interface-business.de (uriah.interface-business.de [193.101.57.162]) by hub.freebsd.org (Postfix) with ESMTP id 03D471504A for ; Sat, 20 Mar 1999 00:40:23 -0800 (PST) (envelope-from j@willy.interface-business.de) Received: (from j@localhost) by willy.interface-business.de (8.7.6/8.7.3) id RAA00345 for scsi@FreeBSD.ORG; Fri, 19 Mar 1999 17:38:16 +0100 (MET) Date: Fri, 19 Mar 1999 17:38:16 +0100 From: J Wunsch To: scsi@FreeBSD.org Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs Message-ID: <19990319173816.E284@uriah.heep.sax.de> Reply-To: Joerg Wunsch Mail-Followup-To: scsi@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Matthew Jacob on Thu, Mar 11, 1999 at 10:19:21AM -0800 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 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew Jacob wrote: > There was a lot of discussion about this some months back. The > consensus (which I didn't agree with) was that EIO should still be > propagated at early warning (the EOM bit in Sense Data- not the > VOLUME OVERFLOW which is hard physical EOT) rather than using a > (possibly deferred) residual count to an I/O operation to provide > the signification. Btw., i don't agree to this either, and we've had this before. If some data have been written, a `short write' should be returned to the application, and no error set (yet - unless the application attempts to continue writing). Only iff no data have been written at all, an error should be flagged (and that was my part of a compromise in a previous discussion with Justin -- i originally thought an error should never be flagged, just a `0 return', but i agree i've been wrong in this). Fixing this will automatically unbreak dump -a or multivolume tar. -- J"org Wunsch Unix support engineer joerg_wunsch@interface-business.de http://www.interface-business.de/~j To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 20 9:24:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D401014F93 for ; Sat, 20 Mar 1999 09:24:56 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id JAA32627; Sat, 20 Mar 1999 09:24:25 -0800 Date: Sat, 20 Mar 1999 09:24:24 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Joerg Wunsch Cc: scsi@FreeBSD.ORG Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs In-Reply-To: <19990319173816.E284@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > There was a lot of discussion about this some months back. The > > consensus (which I didn't agree with) was that EIO should still be > > propagated at early warning (the EOM bit in Sense Data- not the > > VOLUME OVERFLOW which is hard physical EOT) rather than using a > > (possibly deferred) residual count to an I/O operation to provide > > the signification. > > Btw., i don't agree to this either, and we've had this before. If > some data have been written, a `short write' should be returned to the > application, and no error set (yet - unless the application attempts > to continue writing). Only iff no data have been written at all, an > error should be flagged (and that was my part of a compromise in a > previous discussion with Justin -- i originally thought an error > should never be flagged, just a `0 return', but i agree i've been > wrong in this). No- I think you're right on this but we've been overrulled. Did you really have an agreement with Justin that the only time an error is returned is if no data was writtent at all? I can guarantee you that you'll always write up to hard EOT if this is the case. > Fixing this will automatically unbreak dump -a or multivolume tar. Is there a PR filed on this? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 20 10: 1: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with SMTP id 9016E1507A for ; Sat, 20 Mar 1999 10:00:57 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with esmtp (Exim 1.82 #3) id 10OP20-0005Gv-00; Sat, 20 Mar 1999 08:55:28 -0800 Date: Sat, 20 Mar 1999 08:55:27 -0800 (PST) From: Tom To: Nick Hilliard Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: dpt raid-5 performance In-Reply-To: <199903191422.OAA27845@beckett.earlsfort.iol.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 19 Mar 1999, Nick Hilliard wrote: > If I set up a raid-5 system on these disks with a slice-size of 512K, the > write performance is terrible. Bonnie reports: 512k will not result in very good single process write performance. In fact, 512k is suboptimal for many operations on RAID-5 arrays. If you are optimizing for a single process, use something smaller (like 8k). Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 20 13:16:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 18FF414A2F for ; Sat, 20 Mar 1999 13:16:36 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id HAA09701; Sun, 21 Mar 1999 07:46:15 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id HAA89826; Sun, 21 Mar 1999 07:46:13 +1030 (CST) Message-ID: <19990321074613.V429@lemis.com> Date: Sun, 21 Mar 1999 07:46:13 +1030 From: Greg Lehey To: Tom , Nick Hilliard Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: dpt raid-5 performance References: <199903191422.OAA27845@beckett.earlsfort.iol.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Tom on Sat, Mar 20, 1999 at 08:55:27AM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Saturday, 20 March 1999 at 8:55:27 -0800, Tom wrote: > > On Fri, 19 Mar 1999, Nick Hilliard wrote: > >> If I set up a raid-5 system on these disks with a slice-size of 512K, the >> write performance is terrible. Bonnie reports: > > 512k will not result in very good single process write performance. > In fact, 512k is suboptimal for many operations on RAID-5 arrays. I disagree. It's pretty much optimal for Vinum. I'd be interested in your reasoning. > If you are optimizing for a single process, use something smaller > (like 8k). That's far, far too small. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 20 14: 4:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with SMTP id CBD0514C4A for ; Sat, 20 Mar 1999 14:04:17 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with esmtp (Exim 1.82 #3) id 10OSpP-0005Pw-00; Sat, 20 Mar 1999 12:58:43 -0800 Date: Sat, 20 Mar 1999 12:58:40 -0800 (PST) From: Tom To: Greg Lehey Cc: Nick Hilliard , freebsd-scsi@FreeBSD.ORG Subject: Re: dpt raid-5 performance In-Reply-To: <19990321074613.V429@lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 21 Mar 1999, Greg Lehey wrote: > On Saturday, 20 March 1999 at 8:55:27 -0800, Tom wrote: > > > > On Fri, 19 Mar 1999, Nick Hilliard wrote: > > > >> If I set up a raid-5 system on these disks with a slice-size of 512K, the > >> write performance is terrible. Bonnie reports: > > > > 512k will not result in very good single process write performance. > > In fact, 512k is suboptimal for many operations on RAID-5 arrays. > > I disagree. It's pretty much optimal for Vinum. I'd be interested in > your reasoning. Not so optimum for a DPT card running RAID-5. FreeBSD will likely never send IOs big enough for the strip size of 512kb to ever be useful. > > If you are optimizing for a single process, use something smaller > > (like 8k). > > That's far, far too small. Why? > Greg > -- > See complete headers for address, home page and phone numbers > finger grog@lemis.com for PGP public key Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 20 14:15:18 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id EC50914ED6 for ; Sat, 20 Mar 1999 14:14:58 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id IAA09922; Sun, 21 Mar 1999 08:44:39 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA93881; Sun, 21 Mar 1999 08:44:37 +1030 (CST) Message-ID: <19990321084436.Z429@lemis.com> Date: Sun, 21 Mar 1999 08:44:36 +1030 From: Greg Lehey To: Tom Cc: Nick Hilliard , freebsd-scsi@FreeBSD.ORG Subject: Re: dpt raid-5 performance References: <19990321074613.V429@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Tom on Sat, Mar 20, 1999 at 12:58:40PM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Saturday, 20 March 1999 at 12:58:40 -0800, Tom wrote: > > On Sun, 21 Mar 1999, Greg Lehey wrote: > >> On Saturday, 20 March 1999 at 8:55:27 -0800, Tom wrote: >>> >>> On Fri, 19 Mar 1999, Nick Hilliard wrote: >>> >>>> If I set up a raid-5 system on these disks with a slice-size of 512K, the >>>> write performance is terrible. Bonnie reports: >>> >>> 512k will not result in very good single process write performance. >>> In fact, 512k is suboptimal for many operations on RAID-5 arrays. >> >> I disagree. It's pretty much optimal for Vinum. I'd be interested in >> your reasoning. > > Not so optimum for a DPT card running RAID-5. Why not? > FreeBSD will likely never send IOs big enough for the strip size of > 512kb to ever be useful. It does. The largest I/O transfer is 64 kB. You don't want to fragment requests, because that increases the I/O load on the array. >>> If you are optimizing for a single process, use something smaller >>> (like 8k). >> >> That's far, far too small. > > Why? From an earlier message: > On Thursday, 17 December 1998 at 1:05:29 -0500, Matthew Patton wrote: >> Here are my suggestions, all are predominantly HW based. In all cases, 1 >> hot spare per channel. Plenty of ambient cooling and power regulation is >> needed. In addition to the simple 'art' of RAID selection there is also >> 'slice/interleave' size to factor in. With drives doing full track read >> aheads with their own fancy algorithms and varying lamounts of onboard >> cache, precise numbers are very difficult to come up with. It depends on >> what kinds of IO you do. On a database, I would probably use 16 or >> 32kb. > > On FreeBSD, this is too small. > >> A media server (large files) 64kb or more. On boxes with lots of >> small sizes, accessed randomly and rapidly, 8 or 16kb. > > Far too small > >> But you dont' want to fill up the controller's command queue with >> too many commands. > > That's not the big problem. The fact is that the block I/O system > issues requests of between .5kB and 60 kB; a typical mix is somewhere > round 8 kB. You can't stop any striping system from breaking a > request into two physical requests, and if you do it wrong it can be > broken into several. This will result in a significant drop > in performance: the decrease in transfer time per disk is offset by > the order of magnitude greater increase in latency. > > With modern disk sizes and the FreeBSD block I/O system, you can > expect to have a reasonably small number of fragmented requests with a > stripe size between 256 kB and 512 kB; I can't see any reason not to > increase the size to 2 or 4 MB on a large disk. > > The easiest way to consider the impact of any transfer is the total > time it takes: since just about everything is cached, the time > relationship between the request and its completion is not important. > Consider, then, a typical news article of 24 kB, which will probably > be read in a single I/O. Take disks with a transfer rate of 6 MB/s > and an average positioning time of 8 ms, and a file system with 4 kB > blocks. Since it's 24 kB, we don't have to worry about fragments, so > the file will start on a 4 kB boundary. The number of transfers > required depends on where the block starts: it's (S + F - 1) / S, > where S is the stripe size in file system blocks, and F is the file > size in file system blocks. > > 1: Stripe size of 4 kB. You'll have 6 transfers. Total subsystem > load: 48 ms latency, 2 ms transfer, 50 ms total. > > 2: Stripe size of 8 kB. On average, you'll have 3.5 transfers. Total > subsystem load: 28 ms latency, 2 ms transfer, 30 ms total. > > 3: Stripe size of 16 kB. On average, you'll have 2.25 transfers. > Total subsystem load: 18 ms latency, 2 ms transfer, 20 ms total. > > 4: Stripe size of 256 kB. On average, you'll have 1.08 transfers. > Total subsystem load: 8.6 ms latency, 2 ms transfer, 10.6 ms total. > > These calculations are borne out in practice. I haven't yet replied to Nick's message because I wanted to check something here first, and I've been too busy so far. But I'll come back with some comparisons. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 20 16:49:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 86B7F14CC2 for ; Sat, 20 Mar 1999 16:49:11 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id RAA20800; Sat, 20 Mar 1999 17:39:47 -0700 (MST) Date: Sat, 20 Mar 1999 17:39:47 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903210039.RAA20800@narnia.plutotech.com> To: mjacob@feral.com Cc: scsi@FreeBSD.org Subject: Re: 3.1-STABLE: nrsa0 T4000 doesn't honor "no rewind"? SCSI errs in logs X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > >> >> > There was a lot of discussion about this some months back. The >> > consensus (which I didn't agree with) was that EIO should still be >> > propagated at early warning (the EOM bit in Sense Data- not the >> > VOLUME OVERFLOW which is hard physical EOT) rather than using a >> > (possibly deferred) residual count to an I/O operation to provide >> > the signification. >> >> Btw., i don't agree to this either, and we've had this before. If >> some data have been written, a `short write' should be returned to the >> application, and no error set (yet - unless the application attempts >> to continue writing). Only iff no data have been written at all, an >> error should be flagged (and that was my part of a compromise in a >> previous discussion with Justin -- i originally thought an error >> should never be flagged, just a `0 return', but i agree i've been >> wrong in this). > > No- I think you're right on this but we've been overrulled. > > Did you really have an agreement with Justin that the only time an error > is returned is if no data was writtent at all? I can guarantee you that > you'll always write up to hard EOT if this is the case. The only thing I recall about this was whether we should return ENOSPC or continually return 0 on EOM/EOT. If we decide to simply "pause" at EOM (i.e. return a short write or a 0 length write), then this is fine by me. I still believe that returning a real error at EOT is correct. dump understands ENOSPC, and should work correctly if ENOSPC is still returned at EOM or EOT. I believe that dump only cares about EOT because of the way it does its error handling, but I would have to look at the code again. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Mar 20 17:16:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id A10E214E26 for ; Sat, 20 Mar 1999 17:16:50 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id SAA77696; Sat, 20 Mar 1999 18:16:28 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903210116.SAA77696@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Chuck O'Donnell" Cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: error messages from bt driver In-reply-to: Your message of "Thu, 18 Mar 1999 19:52:09 EST." <19990318195209.A27547@milf18.bus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 20 Mar 1999 18:07:27 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I've had no disk errors since we made the quirk entries. If my >understanding is correct, the quirk entries were made because the >controller didn't handle SCSI_STATUS_QUEUE_FULL correctly (in >cam_periph.c)? > >But now I see the following, which I understand to be only >informational messages, but still curious as to the source: > >Mar 16 11:20:17 fern /kernel: (pass0:bt0:0:0:0): tagged openings now 32 >Mar 16 11:20:23 fern /kernel: (pass0:bt0:0:0:0): tagged openings now 2 My guess is that the controller is returning a data run error with a residual of 0. See the comment at ~ line 1613 of sys/dev/buslogic/bt.c or just search for "QUEUE_FULL" until you find the comment. If you could stick a printf in there to verify this, that would be great. In the mean time, I'm going to try to get some information out of Mylex on this issue. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message