From owner-freebsd-scsi Sun Jan 7 5:35:50 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from viemta05.chello.at (viemta05.chello.at [195.34.133.55]) by hub.freebsd.org (Postfix) with ESMTP id 52C7637B400; Sun, 7 Jan 2001 05:35:29 -0800 (PST) Received: from chello.at ([212.186.125.116]) by viemta05.chello.at (InterMail vK.4.03.01.00 201-232-122 license 9caa03a7df1d31c048ffcc0d31ac5855) with ESMTP id <20010107133525.HYWQ29538.viemta05@chello.at>; Sun, 7 Jan 2001 14:35:25 +0100 Message-ID: <3A5870B9.D4402452@chello.at> Date: Sun, 07 Jan 2001 14:35:53 +0100 From: cristian nicolae X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org Subject: SCSI DAT tape detection on Compaq DL380 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear all, I have a Compaq DL380 with an integrated Compaq Smart Array Controller. I have succesfully managed to install the FreeBSD 4.2-20010104 and everything is fine but the DAT drive which is not detected. The DAT is connected to the same Controller as the RAID system. I have checked the archives and noticed that I am not the first one who has this problem. But I could not find any resource which could lead me to a solution. If any of you could give me any hints on that, I would be very grateful. I am at the point where I am considering switching to Linux because of that. On the other hand does any of you have info whether Compaq will support officially FreeBSD in the future? TIA, Cristian Nicolae To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 7 6:54:46 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id 7714237B79C for ; Sun, 7 Jan 2001 06:43:54 -0800 (PST) Received: from nas1-7.mea.club-internet.fr (nas1-7.mea.club-internet.fr [195.36.139.7]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id PAA11800; Sun, 7 Jan 2001 15:43:44 +0100 (MET) Date: Sun, 7 Jan 2001 14:43:17 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Darren Joy Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Continuing Problems with DC390W and 4.2 Release In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 6 Jan 2001, Darren Joy wrote: > I wrote to this list at the end of November with a problem I was having > with 4.2 Release and my Tekram DC390W. I had the machine running 3.2 > Release happily, without any problems. Then as I reinstalled with 4.2, I > found that the machine would lock up with errors reported from the SYM > driver. >=20 > I have revisited this hardware now with the intention of getting it > running rather than sitting there switched off. I want my machine back! >=20 > In response to my last post, Gerard suggested a using the "ncr" driver > instead of "sym", as this was the one used in 3.2. You said NCR worked for you in 3.2, and SYM stated about a device problem it was unable to work around. The device seemed to forget about IOs that wasn't finished yet and to reselect for IOs that didn't exist anymore as seen from the driver. > By doing a 4.2 install, and omitting the ports and src, I managed to get > FreeBSD installed on this machine before it locked up. Then post > installation, added the sources distribution and made my custom kernel > using the "ncr" driver. >=20 > Alas, I am still seeing problems, the symptoms being the same as those > experienced with the "sym" driver. >=20 > If I try to install the ports distibution, I get the following errors : >=20 > ncr0: queue empty > ncr0: queue empty > ncr0: queue empty > ncr0: queue empty > Looks like the device is returning QUEUE FULL status and the NCR does not see any command currently pending at device side (i.e. SCSI I/O having been disconnected). > A colleague once suggested to me that disabling Tagged Command Queueing > could help. This I did in the controller BIOS, however upon bootup I see = : Tagged Commands + Write Behind Caching is good at stressing SCSI device=20 firmware and revealing firmware bugs. Disabling either may help, but,=20 depending on actual I/O pattern, the latter may help better. - Synchronous writes (waited for completion synchronously) are helped by Write Caching. The device is just lying to the O/S by deferring the actual write of data to the medium. - Multi-threaded I/Os (i.e. can be several sequential I/O streams running concurrently or kind of random I/Os) are helped by Tagged Command Queuing. Btw, disabling Write Caching only tells the device to signal completion once the data have been actually written to the medium, but doesn't disallow the device to use its ram buffers neither to reorder concurrent I/Os. > /kernel: ncr0: port 0xe400-0xe4ff mem > 0xeb001000-0xeb001fff,0xeb000000-0xeb0000f > f irq 15 at device 15.0 on pci0 >=20 > /kernel: da0 at ncr0 bus 0 target 0 lun 0 > /kernel: da0: Fixed Direct Access SCSI-2 d= evice > /kernel: da0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing= Enabled > /kernel: da0: 2048MB (4194304 512 byte sectors: 255H 63S/T 261C) >=20 > My thinking here is that disabling Tagged Command Queueing may cure my > woes, but FreeBSD seems to be enabling it regardless! Not regardless IMO. It does so if: - The SIM returns this feature to CAM as user setting for the device. _and_ (&&) - The device claims support for this feature in INQUIRY response. > I have double-checked the controller BIOS, and Tagged Command Queueing is > definitely disabled for this device ( there's no option to disable it > globally ), indeed, disabled for every individual device. I even tried > reducing the queue length to the minimum setting allowed in the BIOS, but > to no avail. And of course, I have tried it with Tagged Queueing enabled. What you tell to the board BIOS is stored in the controller NVRAM. The NVRAM content may be read by the SIM (low-level driver) and its content reported to CAM appropriately. This is what the SYM driver wants to do. But NCR does not try to read the NVRAM of your controller. After boot you can use `camcontrol' to disable Tagged Queueing for your disk. > Can anyone offer any help as to how I might get the NCR ( or SYM ) to > disable Tagged Command Queueing? SYM may report to CAM your disabling of TCQ in NVRAM. I just never tested it personnaly with Tekram boards for the reason I haven't any of these boards. I bought a Promise and a Tyan 53C8xx board in the past and all my recent 53C8xx boards are SYMBIOS/LSILOGIC boards that have been donated to me (1 by Varesearch and 3 by Symbios/LsiLogic). > Any ideas appreciated. FYI, the CONNER CFT2107* (not the 2105) is blacklisted for Tagged Queuing in CAM. Dunno how different/similar these devices actually are. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 7 8:29:52 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 420F837B6BC for ; Sun, 7 Jan 2001 08:28:56 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f07GSHs61375; Sun, 7 Jan 2001 09:28:18 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101071628.f07GSHs61375@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: Darren Joy , freebsd-scsi@FreeBSD.ORG Subject: Re: Continuing Problems with DC390W and 4.2 Release In-Reply-To: Your message of "Sun, 07 Jan 2001 14:43:17 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 07 Jan 2001 09:28:17 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> If I try to install the ports distibution, I get the following errors = : >> = >> ncr0: queue empty >> ncr0: queue empty >> ncr0: queue empty >> ncr0: queue empty >> > >Looks like the device is returning QUEUE FULL status and the NCR does no= t >see any command currently pending at device side (i.e. SCSI I/O having >been disconnected). You still pass this code up to CAM, right? The XPT should be treating it as a BUSY status and deferring I/O for a bit. Perhaps some recent change in CAM has broken this behavior. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 7 10:22:38 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.zuhause.org (zuhause.org [205.215.217.178]) by hub.freebsd.org (Postfix) with ESMTP id 4B59D37B400 for ; Sun, 7 Jan 2001 10:22:21 -0800 (PST) Received: by mail.zuhause.org (Postfix, from userid 1001) id 749217C64; Sun, 7 Jan 2001 12:22:20 -0600 (CST) From: Bruce Albrecht MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14936.46044.178154.903656@celery.zuhause.org> Date: Sun, 7 Jan 2001 12:22:20 -0600 (CST) To: "Kelsey Womack" Cc: Subject: Re: SCSI Controller Recommendation In-Reply-To: <001e01c0783a$f0b8c0d0$0301a8c0@nordec> References: <001e01c0783a$f0b8c0d0$0301a8c0@nordec> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kelsey Womack writes: > I have 3 IBM Ultrastar ES SCSI LVD/SE drives I'm putting into a new server, > however, I cannot find anyone that knows a thing about controllers. The > model number for these drives is DNES-318350 E182115, they are 18 gig, 7200 > rpm U2L drives according to yet another sticker on these drives. I am > looking for some Adaptec card, but cannot find one that I am 100% will work, > could someone point me towards a card, and perhaps an online vendor that > isn't too expensive? Thank you. If you're not set on Adaptec, I having been running with several LVD drives on a TekRAM-390U2W controller. It works fine, and it's a lot cheaper than Adaptec. If you only have LVD drives, you could use the TekRAM-390U2B, which only has one SCSI bus. The 390U2W has two busses so you can have the LVD on one bus and SE on the second, although I believe there's only one SCSI master for the two busses. I'm presently only using the LVD bus on my 390U2W. Check http://www.pricewatch.com or http://xshopper.cnet.com for comparison price checks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 7 11:45:58 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by hub.freebsd.org (Postfix) with ESMTP id 5874D37B400 for ; Sun, 7 Jan 2001 11:45:40 -0800 (PST) Received: from nas1-162.mea.club-internet.fr (nas1-162.mea.club-internet.fr [195.36.139.162]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA12413; Sun, 7 Jan 2001 20:45:33 +0100 (MET) Date: Sun, 7 Jan 2001 19:45:06 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: "Justin T. Gibbs" Cc: Darren Joy , freebsd-scsi@FreeBSD.ORG Subject: Re: Continuing Problems with DC390W and 4.2 Release In-Reply-To: <200101071628.f07GSHs61375@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 7 Jan 2001, Justin T. Gibbs wrote: > >> If I try to install the ports distibution, I get the following errors = : > >>=20 > >> ncr0: queue empty > >> ncr0: queue empty > >> ncr0: queue empty > >> ncr0: queue empty > >> > > > >Looks like the device is returning QUEUE FULL status and the NCR does no= t > >see any command currently pending at device side (i.e. SCSI I/O having > >been disconnected). >=20 > You still pass this code up to CAM, right? =20 It is what the NCR code is doing. It completes the command with QUEUE FULL status. The above message looks to me informational only. The SYM does the same but silently (+ returns to XPT for requeuing all commands for this device not yet started, in order to preserve initial ordering of IOs). > The XPT should be treating > it as a BUSY status and deferring I/O for a bit. Perhaps some recent > change in CAM has broken this behavior. We should check. If CAM does not delay the retry, a storm of QUEUE FULL statuses may occur, but this should not harm in theory (just load uselessly the machine). Practice could be pretty different. The SYM reported bad reselections on this system under 4.2 (device selecting for tasks that didn't exist in driver context). In the same situation the NCR also aborts the IO using appropriate messages, but silently. The same system was reported by Darren to works flawlessly with the NCR in FreeBSD-3.2. Darren should check if tagged command queuing was enabled for his Conner hard disk in the configuration that worked. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 7 12:38:37 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 8E47E37B402; Sun, 7 Jan 2001 12:38:06 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id NAA55171; Sun, 7 Jan 2001 13:37:57 -0700 (MST) (envelope-from ken) Date: Sun, 7 Jan 2001 13:37:57 -0700 From: "Kenneth D. Merry" To: cristian nicolae Cc: freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DAT tape detection on Compaq DL380 Message-ID: <20010107133757.A55049@panzer.kdm.org> References: <3A5870B9.D4402452@chello.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3A5870B9.D4402452@chello.at>; from cristian.nicolae@chello.at on Sun, Jan 07, 2001 at 02:35:53PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jan 07, 2001 at 14:35:53 +0100, cristian nicolae wrote: > Dear all, > I have a Compaq DL380 with an integrated Compaq Smart Array Controller. > I have succesfully managed to install the FreeBSD 4.2-20010104 > and everything is fine but the DAT drive which is not detected. > The DAT is connected to the same Controller as the RAID system. > > I have checked the archives and noticed that I am not the first one who > has this problem. But I could not find any resource which could lead me > to a > solution. > > If any of you could give me any hints on that, I would be very grateful. > I am at the point where I am considering switching to Linux because of > that. I don't think the ida driver in FreeBSD has SCSI passthrough capability. That is to say that it doesn't hook into the CAM subsystem so that generic tape, CDROM, changer, etc., devices will work. I don't know whether or not the hardware itself has passthrough capability; someone more familiar with those controllers will have to comment on that. If the hardware can't handle it, switching to Linux won't help you. If it does handle it, switching will only help if the Linux driver supports that functionality. > On the other hand does any of you have info whether Compaq will support > officially FreeBSD in the future? I don't know. They offer FreeBSD in their test drive program, though: http://www.testdrive.compaq.com Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 7 14:18:17 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from boat.mail.pipex.net (our.mail.pipex.net [158.43.128.75]) by hub.freebsd.org (Postfix) with SMTP id DAFC537B400 for ; Sun, 7 Jan 2001 14:17:59 -0800 (PST) Received: (qmail 25533 invoked from network); 7 Jan 2001 22:17:57 -0000 Received: from mailhost.puck.pipex.net (HELO mailhost.uk.internal) (194.130.147.54) by our.mail.pipex.net with SMTP; 7 Jan 2001 22:17:57 -0000 Received: (qmail 12885 invoked from network); 7 Jan 2001 22:17:56 -0000 Received: from yukon.cam.uk.internal (172.31.3.155) by mailhost.uk.internal with SMTP; 7 Jan 2001 22:17:56 -0000 Date: Sun, 7 Jan 2001 22:17:51 +0000 (GMT) From: Darren Joy X-Sender: darrenj@yukon.cam.uk.internal To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Cc: "Justin T. Gibbs" , freebsd-scsi@FreeBSD.ORG Subject: Re: Continuing Problems with DC390W and 4.2 Release In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 7 Jan 2001, G=E9rard Roudier wrote: > The same system was reported by Darren to works flawlessly with the NCR i= n > FreeBSD-3.2. Darren should check if tagged command queuing was enabled fo= r > his Conner hard disk in the configuration that worked. I am 99% sure it was enabled when I was running 3.2 Release. I can confirm that since disabling Tagged Commmand Queueing in 4.2 Release as suggested by Ken ( thanks! ), I see no more problems from the NCR driver. I will now rebuild the box (for various reasons), and make those same changes to the SYM driver ( disabling the Tagged Command Queueing ) and see if that cures the problems I saw there. This box isn't doing much, so I would be happy to try some tests on it if it will help you identify some bugs. I can trash it at will for the moment, but I will need to get it working again eventually =3D) Regards --=20 Darren Joy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jan 7 19:59: 5 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.tor.axxent.ca (smtp.tor.axxent.ca [209.250.128.26]) by hub.freebsd.org (Postfix) with ESMTP id B6BBC37B404 for ; Sun, 7 Jan 2001 19:58:45 -0800 (PST) Received: from dial-1039.tor.axxent.ca (dial-1039.tor.axxent.ca [216.249.4.23]) by mail.tor.axxent.ca (8.11.0/8.9.3) with ESMTP id f083wg701179; Sun, 7 Jan 2001 22:58:43 -0500 (EST) Date: Sun, 7 Jan 2001 22:58:42 -0500 (EST) From: lwh Reply-To: lwh@fpsn.net To: scsi@freebsd.org Cc: lwh@fpsn.net Subject: Python Autoloader + Tekram card 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 Hi I don't know that I've investigated this exhaustively, and I'm using a 3rd party driver but I'm hoping someone can shed some light on this. I have a Tekram 315U PCI card and an Archive Python DDS autoloader. I replaced pci/amd.c and amd.h with files from tekram's ftp site. It boots up and finds : sa0 at tekram_trm0 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: Serial Number DT010CJ which operates fine using dump and tar. I know the changer is at 0:6:1 so I wired it in the kernel for ch0 but it didnt seem to ever probe any luns but 0. I don't know alot about scsi, I was wondering if anyone else has had any experience with this, or is it something silly like this cheap card doesnt support multiple luns .. I'm not on the list so please cc me Thanks Luke To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 8 5:55:50 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by hub.freebsd.org (Postfix) with ESMTP id 864B337B69B; Mon, 8 Jan 2001 05:54:17 -0800 (PST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id FAA05848; Mon, 8 Jan 2001 05:53:04 -0800 (PST) Received: from otcexc01.otc.adaptec.com ([10.12.1.27]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id FAA26375; Mon, 8 Jan 2001 05:46:46 -0800 (PST) Received: by otcexc01.otc.adaptec.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Jan 2001 08:53:11 -0500 Message-ID: <50DB155AD0CED411988E009027D61DB30FFFD6@otcexc01.otc.adaptec.com> From: "Robinson, Kimberly" To: "Salyzyn, Mark" , "'Micah Anderson'" , "'Chris Snell'" Cc: "'Mike Smith'" , "'noah'" , "'freebsd-scsi@freebsd.org'" Subject: RE: update Date: Mon, 8 Jan 2001 08:53:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello All, I think that what we are seeing in this instance is an issue with the firmware (microcode) on the drives. There is a known issue when these drives are in a RAID configuration, they frustratingly drop out randomly on reboots. I have been told by IBM that all DDYS/DPSS drives manufactured after December 15th need updated to microcode S96H. I have been that the IBM DDYS/DPSS development team have a team standing by if S96H microcode fails to fix spin down issue. The easiest way to update the drive's microcode is to connect all drives to another Adaptec controller like a 2940 or 29160 and create a bootable disk with the ASPI driver to run their update program. IBM's support info as follows: IBM TG Technical Support Center 888.426.5214 drive@us.ibm.com There is nothing else required after the firmware update and no one else has been reporting problems after updating. Thanks, Kimberly Robinson > -----Original Message----- > From: Salyzyn, Mark > Sent: Friday, January 05, 2001 1:18 PM > To: 'Micah Anderson'; Chris Snell > Cc: 'Mike Smith'; noah; freebsd-scsi@freebsd.org; Robinson, Kimberly > Subject: RE: update > > > I feel this *must* be a controller firmware issue. To resolve > this, our technical support department is going to need to > duplicate this problem so our Firmware engineers can > understand why the drives are going offline. It Feels like > the combination of Hardware is making the Firmware `brittle' > where subtle changes cause the issues to come and go. The > controller Firmware contains *all* the smarts associated with > the SCSI bus communications. > > Technical support may be able to supply you a different > hardware versioned card with debugging (UART 115200 Baud) > port installed to capture the needed information to resolve > this. IMHO, this is the *best* way to resolve this to > fruition. You have effectively swapped enough things around > to have isolated away the hardware domain validation possibilities. > > In any case, escalating this to Adaptec Technical support to > see if they have any other practical ideas. > > Sincerely -- Mark Salyzyn > > -----Original Message----- > From: Micah Anderson [mailto:micah@indymedia.org] > Sent: Friday, January 05, 2001 12:45 PM > To: Chris Snell > Cc: Micah Anderson; Salyzyn, Mark; 'Mike Smith'; noah; > freebsd-scsi@freebsd.org > Subject: Re: update > > > Chris, > > I would be interested in seeing your kernel config so I could > comapre it to > the one I made. When I tried the card in a different machine > that machine > had a totally different motherboard and BIOS. I have been finding that > Debian does work, but it is sensitive. For example, if I try > to boot from > the RAID I get the same behavior, but if I boot from a > separate IDE drive > and just mount the raid partitions things are fine. I have a > feeling that > perhaps there is a RAID header at the beginning of the > logicial volume that > can be overwritten by a master boot record or a boot loader > like Lilo, or > Grub, or the FreeBSD loader...? > > Micah > > On Thu, 04 Jan 2001, Chris Snell wrote: > > > > > Micah, > > > > Would it be of any help if I sent you the kernel config for > our server that > > has one of these cards in it? As I said earlier, it's been > working great > > for us. Also, when you tried this card in a different > machine, did that > > machine have the same motherboard and BIOS? You mentioned > that Debian > > works on your setup. Did you try installing it (Debian) > and then hammering > > on the disks or did you just verify that it installed? > > > > Chris > > > > At 03:25 PM 12/26/2000 -0800, Micah Anderson wrote: > > >So I have tried pretty much everything, the alarm still > goes off at the same > > >time during boot up, at asr0: major=154. I am trying a > last experiment > > >today, if it doesn't work, I am sad to say that I am going > to have to use > > >Debian since it works fine there. I have had this server > for over a month > > >trying everything on the planet to get it to work, we need > this server > > >running in a bad way and although I want to go with > FreeBSD we unfortunately > > >are going to have to go with what works. > > > > > >Right now I am trying to recompile the kernel by pulling > everything out of > > >the config file, except what is needed. It seems as if the > problem has to do > > >with the FreeBSD scsi or asr driver. Because thats when > things go, and if I > > >can boot off the CD without this happening, then something > is funky. > > > > > >I was called by Ida at Adaptec to follow up on the call > that I originally > > >placed, ID #2843, but I was given the wrong number to call > her back. > > > > > >I've done practically everything in my power, besides > getting a job at > > >adaptec or delving into the FreeBSD driver code, neither > of which I can do > > >at this point. Do you guys have any other ideas, or > suggestions where to go > > >next? > > > > > >Just a reminder, this is an adaptec 3200s, using freebsd > 4.2, 4 IBM 9 gig > > >10,000 RPM LVD drives making up a Raid-5, using a nice > Intel motherboard > > >(which has another adaptec on board controller, but I've > tried the card in a > > >different machine with the drives, same results).... > > > > > >Micah > > > > > > > > > > > >On Mon, 18 Dec 2000, Salyzyn, Mark wrote: > > > > > > > Although I figure Adaptec's Tech Support would be the > best to know about > > > > generic issues with drive access, the possibilities for > this issue > > > could be: > > > > > > > > 1) No cable and/or drive cabinet domain validation, so > one might have to > > > > roll the SCSI speed down a bit to compensate for cable > and/or drive > > > > combination issues. > > > > 2) Some drives are more comfortable with either over > (more than just > > > the two > > > > endpoints) or under (only the last drive or controller) > termination. > > > > 3) Contact tech support for a later Firmware release, > there may be known > > > > issues with your drives, cabinets and/or drive > combinations that might have > > > > been addressed with either drive firmware, or > controller firmware updates. > > > > Currently the customer has better access to Technical > Support than I do at > > > > this moment :-( even though I virtually end up driving > over top them each > > > > morning as I head to the parking lot ... > > > > > > > > In any case, I will report this to the Firmware > engineers to see if they > > > > have any additional comments to add about this issue. > > > > > > > > Keep in mind that at initial negotiation, the speed is > lower, the transfers > > > > less stressful, than at operating system time. Edge > issues may surface as a > > > > result, sometimes appearing different from OS to OS. > For instance, I > > > believe > > > > the ASR driver can request up to 58 (~4KB) > scatter/gather elements in one > > > > request, allowing up to 256 requests/device. NT's > scsiport driver, on the > > > > other hand, limits request to 64KB/each and only 16 > requests/controller. > > > > Stresses vary. > > > > > > > > However, OS issues do not typically affect drive > failures, which is > > > curious. > > > > I have an issue that comes up in FreeBSD, for instance, > with the array > > > > performance in an impacted (read failures do not fail > an array since data > > > > can be reconstructed) state since the requests take > much longer to fulfill > > > > than in the genuine failed state. Impacted means every > request still tries > > > > to be fulfilled by first trying to talk to the not-yet > failed component. > > > > This has the catch-22 effect of not being able to mount > the array head due > > > > to the protracted responses on some failed drive > scenarios before the > > > > adapter has considered the component to be marked as > failed. Pulling the > > > > errant drive might be the only way. Later adapter > Firmware may deal with > > > > this through careful consideration of request response > time. Tech support > > > > may supply a select fail-on-read firmware/NVRAM, or one > can chose to > > > bump up > > > > the timeout in the SCSI layer. This issue, for > instance, does not occur > > > > under Solaris because their SCSI layer is set to 2 > minute timeouts. > > > > > > > > Sincerely -- Mark Salyzyn > > > > > > > > -----Original Message----- > > > > From: Mike Smith [mailto:msmith@freebsd.org] > > > > Sent: Monday, December 18, 2000 5:37 AM > > > > To: Micah Anderson > > > > Cc: noah; freebsd-scsi@freebsd.org; mark_salyzyn@adaptec.com > > > > Subject: Re: update > > > > > > > > > > > > > > > > Mark; I miscopied you on my previous reply to this > message, sorry about > > > > that. Do you have any ideas? > > > > > > > > > On Sat, 16 Dec 2000, Mike Smith wrote: > > > > > > > > > > > > At "asr0: major=154" the raid card begins a high > pitched beep > > > > indicating > > > > > > > that two of the drives have failed and that a > rebuild of the raid is > > > > > > > required, but we've tested all of the drives and > replaced the raid > > > > card > > > > > > > with a new one, and still get the same problem. > The reason I'm asking > > > > > > > about possible software issues is that other OS's > have worked on this > > > > raid > > > > > > > setup. > > > > > > > > > > > > I've copied Mark at Adaptec, who is the author and > principle > > > maintainer > > > > > > of the 'asr' driver, since he's going to have the > best idea of what's > > > > > > actually going on here. Without saying which OS' > you've used, it's > > > > tough > > > > > > to know whether they simply aren't enabling the > card alarm though. > > > > > > > > > > We have gone through exhaustive troubleshooting > lengths to try to > > > > determine > > > > > what the problem is. I have swapped RAID cards, > swapped cables, tried a > > > > > different motherboard, different powersupply in every > possible > > > combination > > > > > of configuration. Each time I have to start from the > beginning, > > > destroying > > > > > the RAID configuration and then creating a new one, > which takes over an > > > > > hour, so this process has taken literally three weeks > to try all the > > > > > potential configurations. > > > > > > > > > > The RAID alarm goes off on the card during the > FreeBSD boot process, the > > > > OS > > > > > continues to boot, but the alarm continues. Rebooting > and going into the > > > > > Adaptec setup tells us that a drive has failed, it is > not the same drive > > > > > every time. During bootup after the RAID POST when > the SMOR utility is > > > > > loading it will usually show the RAID-5 drive as well > as the single > > > drive. > > > > > It is almost as if one of the drives of the RAID is > pushed out of the > > > > RAID. > > > > > Individually, each drive works fine. If I install > FreeBSD on a single > > > > drive, > > > > > without a RAID constructed things act as normal. > These are IBM 10k RPM > > > > LVD > > > > > drives and I ran IBM's drive test utility on each one > of them and it came > > > > > back with no errors. > > > > > > > > > > I have been able to install Debian Linux and use the > card/drives without > > > > > this problem. I have called Adaptec to ask them about > this and was > > > told to > > > > > try changing the drive speed from Ultra 3 to Ultra as > well as change the > > > > > delay from the default to 30 seconds, all of these do > not change the > > > > > behavior whatsoever. > > > > > > > > > > I have spoken with one other person who had a similar > type of problem, > > > > > except what was happening to him was he was loading > some DOS drivers, one > > > > of > > > > > which would wipe the RAID card configuration when it > was loaded (ASAPI? I > > > > > can't recall right now)... I am wondering if there > are some other drivers > > > > > that are being probed in the generic FreeBSD kernel > that are doing a > > > > similar > > > > > thing to the config. > > > > > > > > > > > > > > > > > Have you tried running the Adaptec management > software to check the > > > > > > status of the card? > > > > > > > > > > In FreeBSD? If there is such a thing it would be > interesting to know > > > where > > > > > one could get it. The CD that was included with the > card has no FreeBSD > > > > > anything on it - the website has no FreeBSD > information or downloads > > > on it > > > > > (except for the breif mention that it is supported, > but if you call for > > > > > support you can't get it). Or are you talking about > the SMOR utility that > > > > > you can access from the BIOS? > > > > > > > > > > Thanks for any help that you can offer. > > > > > > > > > > Micah > > > > > > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > On 12/15, Mike Smith wrote: > > > > > > > > > > > > > > > > > Hi, I'm working on trying to install FreeBSD > 4.2 on a dual p3 700 > > > > with > > > > > > > > > an Adaptec 3200S raid card. From what I can > tell everyone > > > that has > > > > tried > > > > > > > > > this card has had good luck. When we install > FreeBSD (booting off > > > > cd) it > > > > > > > > > recognizes the card and installs on it > perfectly, but when it > > > > loads the OS > > > > > > > > > off the raid it does something to damage the > hardware raid, > > > > requiring us > > > > > > > > > to rebuild the RAID in the 3200S' bios. We're > pretty sure that > > > > this isn't > > > > > > > > > a hardware problem. > > > > > > > > > > > > > > > > You haven't actually included anything that > suggests that > > > there's a > > > > > > > > problem occurring, so it's somewhat difficult > to guess what's going > > > > on. > > > > > > > > > > > > > > > > However, I don't lend much credibility to the > suggestion that > > > > "FreeBSD > > > > > > > > does something to damage the hadware raid" - > things just don't > > > > happen > > > > > > > > like that. > > > > > > > > > > > > > > > > I would be inclined to suspect that you > probably have a suspect > > > > disk, or > > > > > > > > cabling/enclosure problems, but without more > details it's hard > > > to be > > > > sure. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > ... every activity meets with opposition, > everyone who acts has his > > > > > > > > rivals and unfortunately opponents also. But > not because people > > > > want > > > > > > > > to be opponents, rather because the tasks and > relationships force > > > > > > > > people to take different points of view. [Dr. > Fritz Todt] > > > > > > > > V I C T O R Y N O T V E N G E A N C E > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > noah .. email for pgp/gpg key > > > > > > > > > > > > > > > > > > > -- > > > > > > ... every activity meets with opposition, everyone > who acts has his > > > > > > rivals and unfortunately opponents also. But not > because people want > > > > > > to be opponents, rather because the tasks and > relationships force > > > > > > people to take different points of view. [Dr. Fritz Todt] > > > > > > V I C T O R Y N O T V E N G E A N C E > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > ... every activity meets with opposition, everyone who > acts has his > > > > rivals and unfortunately opponents also. But not > because people want > > > > to be opponents, rather because the tasks and > relationships force > > > > people to take different points of view. [Dr. Fritz Todt] > > > > V I C T O R Y N O T V E N G E A N C E > > > > > > > > > > > > >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 Mon Jan 8 6:35: 8 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from smtpgate1.syd.iprimus.com.au (smtpgate1.syd.iprimus.com.au [203.134.64.91]) by hub.freebsd.org (Postfix) with ESMTP id 78E2737B69E; Mon, 8 Jan 2001 06:29:37 -0800 (PST) Received: from iprimus.com.au ([203.134.49.250]) by smtpgate1.syd.iprimus.com.au with Microsoft SMTPSVC(5.5.1877.537.53); Tue, 9 Jan 2001 01:29:56 +1100 Message-ID: <3A59CE21.54406DA6@iprimus.com.au> Date: Tue, 09 Jan 2001 01:26:41 +1100 From: Justin Clift X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith , freebsd-scsi@freebsd.org Subject: Re: Mylex DAC960 RAID Controller - bus_dmamap_load errors References: <200101080224.f082Ol801623@mass.osd.bsdi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Mike, Hmmmm... I'm wasn't subscribed to any of the freebsd lists, although I thought I was. I'll subscribe to the freebsd-scsi list again. If it's of any interest, I come from a Solaris background and have run Solaris 7 x86 on these same Mylex controllers before with no huge problems. Only real problem with Solaris is that it doesn't seem to like booting from partitions bigger than 2 Gig or so with these controllers, so I always have to boot from a floppy, but that's another story. The actual cards and Solaris drivers themselves work fine. If you need someone to do testing of FreeBSD patches, revisions, etc for these controllers, the RAID cards and PC in question is just a play-around with PC and doesn't hold any critical data. I can format/destroy/reload stuff at will with no problems. Just let me know. Also, by chance does anyone know the type of EEPROM chips that should be used for flashing a 2.xx BIOS to a revision 3.xx BIOS? As Mylex no longer offers this service, I'm thinking about doing it myself. Firstly need to find the correct capacity EEPROM chips though. Regards and best wishes, Justin Clift Mike Smith wrote: > > > Have you had any errors reported from users lately with Mylex DAC960P > > RAID Contollers with v2.xx firmware? > > Yes; I'm painfully aware of this problem, but I don't know what's causing > it, and I don't have any adapters to hand to fix it. I've been trying to > get testers to experiment with some changes, but most haven't come back > to me with the results I've asked for. > > My 2.x adapters are all Alpha-only (and don't exhibit this problem), and > my 3.x adapter (which is supposedly also vulnerable to it) was sent to > Matt Dodd who was going to take over legacy support for these controllers > (but who is I think still moving house...). > > Matt, are you back with us yet? > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] > V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 8 16:22: 5 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 4574937B401; Mon, 8 Jan 2001 16:21:47 -0800 (PST) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id TAA62967; Mon, 8 Jan 2001 19:21:41 -0500 (EST) Date: Mon, 8 Jan 2001 19:21:41 -0500 (EST) From: "Matthew N. Dodd" To: cristian nicolae Cc: freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DAT tape detection on Compaq DL380 In-Reply-To: <3A5870B9.D4402452@chello.at> 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, 7 Jan 2001, cristian nicolae wrote: > I have a Compaq DL380 with an integrated Compaq Smart Array Controller. > I have succesfully managed to install the FreeBSD 4.2-20010104 > and everything is fine but the DAT drive which is not detected. The SCSI passthrough interface on that controller isn't supported by FreeBSD's 'ida' driver. My impression from reading various docs is that it is likely to be quite slow as well. Hook the DAT drive up to the internal SCSI adapter (I assume it has one since it would be fairly silly not to.) -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 8 17:31:42 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (dhcp244.osd.bsdi.com [204.216.28.244]) by hub.freebsd.org (Postfix) with ESMTP id 1CD6C37B401; Mon, 8 Jan 2001 17:31:20 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id f091i1e02711; Mon, 8 Jan 2001 17:44:02 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200101090144.f091i1e02711@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Matthew N. Dodd" Cc: cristian nicolae , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DAT tape detection on Compaq DL380 In-reply-to: Your message of "Mon, 08 Jan 2001 19:21:41 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Jan 2001 17:44:01 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hook the DAT drive up to the internal SCSI adapter (I assume it has one > since it would be fairly silly not to.) Actually, I'm not sure that it does. They use the Symbios part with the integrated ARM processor, and assume that SCSI passthrough works. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 8 17:46: 4 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (dhcp244.osd.bsdi.com [204.216.28.244]) by hub.freebsd.org (Postfix) with ESMTP id CA7AC37B401 for ; Mon, 8 Jan 2001 17:45:45 -0800 (PST) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id f091wwe02821; Mon, 8 Jan 2001 17:58:59 -0800 (PST) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200101090158.f091wwe02821@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Justin Clift Cc: freebsd-scsi@freebsd.org Subject: Re: Mylex DAC960 RAID Controller - bus_dmamap_load errors In-reply-to: Your message of "Tue, 09 Jan 2001 01:26:41 +1100." <3A59CE21.54406DA6@iprimus.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Jan 2001 17:58:58 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If you need someone to do testing of FreeBSD patches, revisions, etc for > these controllers, the RAID cards and PC in question is just a > play-around with PC and doesn't hold any critical data. I can > format/destroy/reload stuff at will with no problems. Just let me know. I'll keep you on file. 8) If you have any C hacking experience, I *really* need to know why the 'too many segs' error is being thrown. All the indications I've received so far are that the region in question shouldn't have "too many" segments, so I'm a bit confused. > Also, by chance does anyone know the type of EEPROM chips that should be > used for flashing a 2.xx BIOS to a revision 3.xx BIOS? As Mylex no > longer offers this service, I'm thinking about doing it myself. Firstly > need to find the correct capacity EEPROM chips though. I don't, actually. I think they're 256kbit parts, but I don't have one handy to check. Programming them will be a bit of a challenge unless you have a 3.x controller's parts to copy, since the image file is not just a 1:1 image of the flash area. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jan 8 17:46:48 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 0BA8337B402; Mon, 8 Jan 2001 17:46:29 -0800 (PST) Received: from bellatlantic.net (client-151-198-117-214.nnj.dialup.bellatlantic.net [151.198.117.214]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA15224; Mon, 8 Jan 2001 20:46:18 -0500 (EST) Message-ID: <3A5A6D6A.4115A4BD@bellatlantic.net> Date: Mon, 08 Jan 2001 20:46:18 -0500 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: en, ru MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: cristian nicolae , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DAT tape detection on Compaq DL380 References: <3A5870B9.D4402452@chello.at> <20010107133757.A55049@panzer.kdm.org> 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: > > On Sun, Jan 07, 2001 at 14:35:53 +0100, cristian nicolae wrote: > > Dear all, > > I have a Compaq DL380 with an integrated Compaq Smart Array Controller. > > I have succesfully managed to install the FreeBSD 4.2-20010104 > > and everything is fine but the DAT drive which is not detected. > > The DAT is connected to the same Controller as the RAID system. > I don't think the ida driver in FreeBSD has SCSI passthrough capability. > > I don't know whether or not the hardware itself has passthrough capability; I think it does (I suspect that UnixWare supports it) but I'm not 100% sure. > > On the other hand does any of you have info whether Compaq will support > > officially FreeBSD in the future? > > I don't know. They offer FreeBSD in their test drive program, though: It may be worth it calling them and asking anyway. If they hear from the customers that the customers want FreeBSD they would eventually add its support. I think this is approximately how they started supporting Linux. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 9 3:32:22 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from weirdo.netcraft.com (unknown [195.92.95.47]) by hub.freebsd.org (Postfix) with ESMTP id 06A6037B402 for ; Tue, 9 Jan 2001 03:32:05 -0800 (PST) Received: (from sketchy@localhost) by weirdo.netcraft.com (8.11.1/8.11.1) id f09BVVX01842 for freebsd-scsi@freebsd.org; Tue, 9 Jan 2001 11:31:31 GMT (envelope-from sketchy) Date: Tue, 9 Jan 2001 11:31:31 +0000 From: Jonathan Perkin To: freebsd-scsi@freebsd.org Subject: Aborted commands and parity errors Message-ID: <20010109113131.B1688@netcraft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD/i386 4.2-RELEASE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey guys, Found these in the logfiles this morning - box is: o 2.2.8-STABLE as of around Feb 1999 (with cam patches) o Adaptec 2940 Controller Card o 3 * Quantum XP34300W 4Gb disks held in an external enclosure sd1(ahc0:3:0): ABORTED COMMAND asc:48,0 sd1(ahc0:3:0): Initiator detected error message received, retries:4 sd1(ahc0:3:0): parity error during Data-In phase. sd1(ahc0:3:0): ABORTED COMMAND asc:48,0 sd1(ahc0:3:0): Initiator detected error message received , retries:3 sd1(ahc0:3:0): parity error during Data-In phase. sd1(ahc0:3:0): ABORTED COMMAND asc:48,0 sd1(ahc0:3:0): Initiator detected error message received , retries:2 sd1(ahc0:3:0): parity error during Data-In phase. sd1(ahc0:3:0): ABORTED COMMAND asc:48,0 sd1(ahc0:3:0): Initiator detected error message received , retries:1 sd1(ahc0:3:0): parity error during Data-In phase. sd1(ahc0:3:0): ABORTED COMMAND asc:48,0 sd1(ahc0:3:0): Initiator detected error message received , FAILURE [ lather rinse repeat ] swap_pager: I/O error - pagein failed; blkno 77352, size 12288, error 0 vm_fault: pager input (probably hardware) error, PID 29846 failure [ no doubt caused by not being able to access the swap partition ] I'd normally guess at a cabling/termination problem, but as this box has been running fine for years with no problems like this, and the fact all drives are external shared off the same cable, I'm wondering if there could be a different problem? The box is still running fine, but obviously I can't chance this happening again and the server crashing. sd1 and sd2 are striped over ccd. -- Jonathan Perkin +44 (0)1225 867914 Netcraft Ltd, Bradford on Avon, UK - http://www.netcraft.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 9 6:19:39 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 0F4E637B401 for ; Tue, 9 Jan 2001 06:19:22 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f09EJFs89920; Tue, 9 Jan 2001 07:19:16 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200101091419.f09EJFs89920@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Jonathan Perkin Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Aborted commands and parity errors In-Reply-To: Your message of "Tue, 09 Jan 2001 11:31:31 GMT." <20010109113131.B1688@netcraft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Jan 2001 07:19:15 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Hey guys, > >Found these in the logfiles this morning - box is: > > o 2.2.8-STABLE as of around Feb 1999 (with cam patches) > o Adaptec 2940 Controller Card > o 3 * Quantum XP34300W 4Gb disks held in an external enclosure > >sd1(ahc0:3:0): ABORTED COMMAND asc:48,0 >sd1(ahc0:3:0): Initiator detected error message received, retries:4 >sd1(ahc0:3:0): parity error during Data-In phase. Something has changed on this box to start causing parity errors. It could be a hardware fault on either the drives or the controller, or a cable that was loose to begin with (perhaps the cable inside your drive enclosure), but has shifted due to fan vibration or thermal variance. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 9 9:35:59 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6A53F37B69C for ; Tue, 9 Jan 2001 09:35:38 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id JAA09476; Tue, 9 Jan 2001 09:35:20 -0800 Date: Tue, 9 Jan 2001 09:35:18 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jonathan Perkin Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Aborted commands and parity errors In-Reply-To: <20010109113131.B1688@netcraft.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 It's either a bad cable or something that is corrupting data. Be thankful parity caught it. When was the last time you power cycled things? Sometimes a resetting termpwr fuse gets frotzed and termpwr stops being supplied by the drive that's supplying it, thus nullifying termination. It's also true, tho rare, that traces just sometimes go on drive or PC motherboards. Does your system and/or drives run hot? Try a powercycle. Let it cool down. Then boot up again and see. It always could be s/w but in this case I doubt it. > Hey guys, > > Found these in the logfiles this morning - box is: > > o 2.2.8-STABLE as of around Feb 1999 (with cam patches) > o Adaptec 2940 Controller Card > o 3 * Quantum XP34300W 4Gb disks held in an external enclosure > > sd1(ahc0:3:0): ABORTED COMMAND asc:48,0 > sd1(ahc0:3:0): Initiator detected error message received, retries:4 > sd1(ahc0:3:0): parity error during Data-In phase. > sd1(ahc0:3:0): ABORTED COMMAND asc:48,0 > sd1(ahc0:3:0): Initiator detected error message received , retries:3 > sd1(ahc0:3:0): parity error during Data-In phase. > sd1(ahc0:3:0): ABORTED COMMAND asc:48,0 > sd1(ahc0:3:0): Initiator detected error message received , retries:2 > sd1(ahc0:3:0): parity error during Data-In phase. > sd1(ahc0:3:0): ABORTED COMMAND asc:48,0 > sd1(ahc0:3:0): Initiator detected error message received , retries:1 > sd1(ahc0:3:0): parity error during Data-In phase. > sd1(ahc0:3:0): ABORTED COMMAND asc:48,0 > sd1(ahc0:3:0): Initiator detected error message received , FAILURE > > [ lather rinse repeat ] > > swap_pager: I/O error - pagein failed; blkno 77352, size 12288, error 0 > vm_fault: pager input (probably hardware) error, PID 29846 failure > > [ no doubt caused by not being able to access the swap partition ] > > I'd normally guess at a cabling/termination problem, but as this box > has been running fine for years with no problems like this, and the > fact all drives are external shared off the same cable, I'm wondering > if there could be a different problem? > > The box is still running fine, but obviously I can't chance this > happening again and the server crashing. sd1 and sd2 are striped > over ccd. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 9 9:41: 4 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 54DD337B6D2; Tue, 9 Jan 2001 09:40:45 -0800 (PST) Received: from localhost (winter@localhost) by sasami.jurai.net (8.9.3/8.8.7) with ESMTP id MAA77292; Tue, 9 Jan 2001 12:40:44 -0500 (EST) Date: Tue, 9 Jan 2001 12:39:47 -0500 (EST) From: "Matthew N. Dodd" To: Mike Smith Cc: cristian nicolae , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DAT tape detection on Compaq DL380 In-Reply-To: <200101090144.f091i1e02711@mass.osd.bsdi.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, 8 Jan 2001, Mike Smith wrote: > Actually, I'm not sure that it does. They use the Symbios part with > the integrated ARM processor, and assume that SCSI passthrough works. Maybe I was reading the docs for the passthrough interface incorrectly but I was under the impression that the RAID is paused while the passthrough interface is open. Granted, we don't have very current documentation... -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 9 9:48:15 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from weirdo.netcraft.com (unknown [195.92.95.47]) by hub.freebsd.org (Postfix) with ESMTP id 4827937B6D5 for ; Tue, 9 Jan 2001 09:47:58 -0800 (PST) Received: (from sketchy@localhost) by weirdo.netcraft.com (8.11.1/8.11.1) id f09HkOj02827; Tue, 9 Jan 2001 17:46:24 GMT (envelope-from sketchy) Date: Tue, 9 Jan 2001 17:46:24 +0000 From: Jonathan Perkin To: Matthew Jacob Cc: freebsd-scsi@freebsd.org Subject: Re: Aborted commands and parity errors Message-ID: <20010109174624.G2152@netcraft.com> References: <20010109113131.B1688@netcraft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjacob@feral.com on Tue, Jan 09, 2001 at 09:35:18am -0800 X-Operating-System: FreeBSD/i386 4.2-RELEASE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jan 09, 2001 at 09:35:18am -0800, Matthew Jacob wrote: > It's either a bad cable or something that is corrupting data. Be thankful > parity caught it. > > When was the last time you power cycled things? Sometimes a resetting > termpwr fuse gets frotzed and termpwr stops being supplied by the drive > that's supplying it, thus nullifying termination. 5:42PM up 53 days, 1:39, 3 users, load averages: 0.18, 0.48, 0.93 > It's also true, tho rare, that traces just sometimes go on drive or PC > motherboards. Does your system and/or drives run hot? Justin's earlier suggestions fit quite close - the room has been quite hot recently, so I put a fan in there, which is balanced on top of this very SCSI enclosure :) It does vibrate quite a bit, so I guess it could have shaken the cable slightly loose or something. > Try a powercycle. Let it cool down. Then boot up again and see. It always > could be s/w but in this case I doubt it. Yes, I intend to. Many thanks. -- Jonathan Perkin +44 (0)1225 867914 Netcraft Ltd, Bradford on Avon, UK - http://www.netcraft.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jan 9 12:20:45 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from viemta06.chello.at (viemta06.chello.at [195.34.133.56]) by hub.freebsd.org (Postfix) with ESMTP id BEA2D37B401; Tue, 9 Jan 2001 12:20:18 -0800 (PST) Received: from chello.at ([212.186.125.116]) by viemta06.chello.at (InterMail vK.4.03.01.00 201-232-122 license 9caa03a7df1d31c048ffcc0d31ac5855) with ESMTP id <20010109202004.TXO17545.viemta06@chello.at>; Tue, 9 Jan 2001 21:20:04 +0100 Message-ID: <3A5B7295.2ECE4210@chello.at> Date: Tue, 09 Jan 2001 21:20:37 +0100 From: cristian nicolae X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Sergey Babkin Cc: "Kenneth D. Merry" , freebsd-hackers@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI DAT tape detection on Compaq DL380 References: <3A5870B9.D4402452@chello.at> <20010107133757.A55049@panzer.kdm.org> <3A5A6D6A.4115A4BD@bellatlantic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear all, I continued investigating the problem and at http://www5.compaq.com/products/servers/linux/OptionsMatrix.html I was surprised to find out that not even Linux supports tape drives (cpqarray) driver with the Compaq Integrated Smart Array Controller. I say "not even" as Compaq claims that officially supports Linux and DL380 is one of their certified Linux servers. I was in contact with one of the Compaq support engineers who told me that if I connect the tape to the controller SCSI Port 1 it should work. Well, it gets detected at boot time by the BIOS but not by the OS. I've deciced to give up in favor of a network based backup. The alternative is to stick another SCSI controller which is detectable by FreeBSD. Actually with a plain Adaptec UW2940 everything is just fine. But sticking an Adaptec into a Compaq machine covered by warranty and support will lead to other complications I don't even want to think about. Thanks for all your time spent on this. Yours, Cristian Nicolae Sergey Babkin wrote: > > "Kenneth D. Merry" wrote: > > > > On Sun, Jan 07, 2001 at 14:35:53 +0100, cristian nicolae wrote: > > > Dear all, > > > I have a Compaq DL380 with an integrated Compaq Smart Array Controller. > > > I have succesfully managed to install the FreeBSD 4.2-20010104 > > > and everything is fine but the DAT drive which is not detected. > > > The DAT is connected to the same Controller as the RAID system. > > > I don't think the ida driver in FreeBSD has SCSI passthrough capability. > > > > I don't know whether or not the hardware itself has passthrough capability; > > I think it does (I suspect that UnixWare supports it) but I'm not > 100% sure. > > > > On the other hand does any of you have info whether Compaq will support > > > officially FreeBSD in the future? > > > > I don't know. They offer FreeBSD in their test drive program, though: > > It may be worth it calling them and asking anyway. If they hear from > the customers that the customers want FreeBSD they would eventually > add its support. I think this is approximately how they started > supporting Linux. > > -SB > > 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 Thu Jan 11 9:56: 5 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from arutam.inch.com (ns.inch.com [216.223.192.21]) by hub.freebsd.org (Postfix) with ESMTP id E4A9637B401 for ; Thu, 11 Jan 2001 09:55:47 -0800 (PST) Received: from inch.com (inch.com [216.223.192.20]) by arutam.inch.com (8.9.3/8.9.3/UTIL-INCH-2.2.0) with ESMTP id MAA27750 for ; Thu, 11 Jan 2001 12:55:47 -0500 (EST) Date: Thu, 11 Jan 2001 12:55:47 -0500 (EST) From: Charles Sprickman To: Subject: recommended/supported raid 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 Hi, We're in a crunch and have to go the pre-built route for a fairly large web server box. We'll be ditching a setup with the old external Mylex controller (not that we're unhappy with the controller - we need a better chassis with room to expand) and moving to a pre-built system. My question is this... Which "built-in" raid controllers out there work with FreeBSD? I was looking at the IBM Netfinity with "IBM ServeRaid", and I can't tell what kind of controller this is or if it's supported... I noticed that there's support for certain Dell controllers, are these current models? Compaq support is some sort of third party driver at this point as well, correct? Any input would be much appreciated. I've also checked the BSDI website, but I can't get past voicemail on the sales side. Anyone know how their prices compare? Thanks, Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork@inch.com | access@inch.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 11 10: 7:40 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from peitho.fxp.org (peitho.fxp.org [209.26.95.40]) by hub.freebsd.org (Postfix) with ESMTP id 74EEE37B400 for ; Thu, 11 Jan 2001 10:07:23 -0800 (PST) Received: by peitho.fxp.org (Postfix, from userid 1501) id 74D411360C; Thu, 11 Jan 2001 13:07:35 -0500 (EST) Date: Thu, 11 Jan 2001 13:07:35 -0500 From: Chris Faulhaber To: Charles Sprickman Cc: freebsd-scsi@freebsd.org Subject: Re: recommended/supported raid Message-ID: <20010111130735.A12629@peitho.fxp.org> Mail-Followup-To: Chris Faulhaber , Charles Sprickman , freebsd-scsi@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from spork@inch.com on Thu, Jan 11, 2001 at 12:55:47PM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 11, 2001 at 12:55:47PM -0500, Charles Sprickman wrote: > > My question is this... Which "built-in" raid controllers out there work > with FreeBSD? I was looking at the IBM Netfinity with "IBM ServeRaid", > and I can't tell what kind of controller this is or if it's supported... > Generically, supported RAID controller info can be found at: http://people.FreeBSD.org/~msmith/RAID/ -- Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org -------------------------------------------------------- FreeBSD: The Power To Serve - 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 Thu Jan 11 10: 8:27 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id BA2CD37B400 for ; Thu, 11 Jan 2001 10:08:09 -0800 (PST) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 14GlRJ-00017M-00; Thu, 11 Jan 2001 09:23:05 -0800 Date: Thu, 11 Jan 2001 09:23:04 -0800 (PST) From: Tom Samplonius To: Charles Sprickman Cc: freebsd-scsi@freebsd.org Subject: Re: recommended/supported raid 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 On Thu, 11 Jan 2001, Charles Sprickman wrote: > My question is this... Which "built-in" raid controllers out there work > with FreeBSD? I was looking at the IBM Netfinity with "IBM ServeRaid", > and I can't tell what kind of controller this is or if it's supported... The IBM ServeRAID is not supported, but you can order the server without the ServeRAID card and order an IBM Mylex AccelRAID 352 instead! IBM owns Mylex. I don't think you can order Mylex cards via IBM re-sellers yet, but IBM re-sellers certainly can complain about your choice of RAID cards. The Netfinity 4500R (now the x340) is very nice. 3U, dual CPU, three hot swap drive bays, and support for three more hot swap drive bays, and redundant power supplies. Dell has nothing quite like this. Plus the lightguide diagnostic system is pretty cool too, and Dell doesn't have that either. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 11 14: 8:23 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from matavnet.hu (mail.matavnet.hu [195.228.240.10]) by hub.freebsd.org (Postfix) with SMTP id 8F2CB37B400 for ; Thu, 11 Jan 2001 14:08:03 -0800 (PST) Received: (qmail 27270 invoked from network); 11 Jan 2001 23:08:00 +0100 Received: from line-181-71.dial.matav.net (HELO outsider.bzmot.net) (mail@145.236.181.71) by mail.matavnet.hu with SMTP; 11 Jan 2001 23:08:00 +0100 Received: from steer (helo=localhost) by outsider.bzmot.net with local-esmtp (Exim 3.16 #1 (Debian)) id 14Gpu9-0000FO-00 for ; Thu, 11 Jan 2001 23:09:09 +0100 Date: Thu, 11 Jan 2001 23:09:09 +0100 (CET) From: VENESZ Roland X-Sender: steer@outsider.bzmot.net To: freebsd-scsi@freebsd.org Subject: Tekram u3w 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 Hi list! Just some simple questions for now: Would FreeBSD 4.1.2 support a Tekram dc-390u3w SCSI-160 card? 390U is listed as supported hardware, but that's a U2W controller as I know. If so, would you recommend using it in a 4.1.2-RELEASE system? What I am really curious about is stability and things like that... Thanks in advance, and Happy New Year to y'all, VENESZ Roland steer@Projex.hu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jan 11 14:42:16 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from firebat.bushong.net (c128625-a.frmt1.sfba.home.com [24.176.225.90]) by hub.freebsd.org (Postfix) with ESMTP id 4F89137B400 for ; Thu, 11 Jan 2001 14:41:57 -0800 (PST) Received: (from dbushong@localhost) by firebat.bushong.net (8.11.0/8.11.0) id f0BMfO061281; Thu, 11 Jan 2001 14:41:24 -0800 (PST) (envelope-from dbushong) Date: Thu, 11 Jan 2001 14:41:24 -0800 From: David Bushong To: VENESZ Roland Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Tekram u3w Message-ID: <20010111144124.B45265@bushong.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from steer@projex.hu on Thu, Jan 11, 2001 at 11:09:09PM +0100 X-Floating-Sheep-Port: 0xbaa Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm using a DC-390U3W with an August 4th 4.1-STABLE and it's just peachy. --David Bushong On Thu, Jan 11, 2001 at 11:09:09PM +0100, VENESZ Roland wrote: > Hi list! > > Just some simple questions for now: > Would FreeBSD 4.1.2 support a Tekram dc-390u3w SCSI-160 card? 390U is > listed as supported hardware, but that's a U2W controller as I know. > If so, would you recommend using it in a 4.1.2-RELEASE system? What I > am really curious about is stability and things like that... > > Thanks in advance, and Happy New Year to y'all, > VENESZ Roland > steer@Projex.hu > > > > 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 Thu Jan 11 15: 4: 1 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from matavnet.hu (mail.matavnet.hu [195.228.240.10]) by hub.freebsd.org (Postfix) with SMTP id 630F237B699 for ; Thu, 11 Jan 2001 15:03:40 -0800 (PST) Received: (qmail 29258 invoked from network); 12 Jan 2001 00:03:33 +0100 Received: from line-181-71.dial.matav.net (HELO outsider.bzmot.net) (mail@145.236.181.71) by mail.matavnet.hu with SMTP; 12 Jan 2001 00:03:33 +0100 Received: from steer (helo=localhost) by outsider.bzmot.net with local-esmtp (Exim 3.16 #1 (Debian)) id 14Gqlu-0000Hj-00 for ; Fri, 12 Jan 2001 00:04:42 +0100 Date: Fri, 12 Jan 2001 00:04:42 +0100 (CET) From: VENESZ Roland X-Sender: steer@outsider.bzmot.net To: freebsd-scsi@freebsd.org Subject: Re: Tekram u3w In-Reply-To: <20010111144124.B45265@bushong.net> 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 Hi list, On Thu, 11 Jan 2001, David Bushong wrote: > I'm using a DC-390U3W with an August 4th 4.1-STABLE and it's just peachy. thanks a lot! > > Would FreeBSD 4.1.2 support a Tekram dc-390u3w SCSI-160 card? 390U is > > If so, would you recommend using it in a 4.1.2-RELEASE system? What I Ah yeah, I meant 4.2 here.. I need some sleep. seriously. :p Bye, VENESZ Roland steer@projex.hu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 12 9:43:35 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from relay2.flashnet.it (libra.cyb.it [212.11.95.209]) by hub.freebsd.org (Postfix) with ESMTP id 728BA37B400 for ; Fri, 12 Jan 2001 09:43:17 -0800 (PST) Received: from smtp.flashnet.it (ip232.pool-173.cyb.it [195.191.181.233]) by relay2.flashnet.it (EMS-RELAY/8.10.0) with SMTP id f0CHh3L15966 for ; Fri, 12 Jan 2001 18:43:04 +0100 Message-Id: <200101121743.f0CHh3L15966@relay2.flashnet.it> To: freebsd-scsi@FreeBSD.ORG X-Mailer: Post Road Mailer for OS/2 (Green Edition Ver 3.0) Date: Fri, 12 Jan 2001 18:43:02 EST From: Andrea Venturoli Reply-To: Andrea Venturoli Subject: Tekram u3w Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ** Reply to note from VENESZ Roland Thu, 11 Jan 2001 23:09:09 +0100 (CET) > Hi list! > > Just some simple questions for now: > Would FreeBSD 4.1.2 support a Tekram dc-390u3w SCSI-160 card? 390U is > listed as supported hardware, but that's a U2W controller as I know. > If so, would you recommend using it in a 4.1.2-RELEASE system? What I > am really curious about is stability and things like that... 390U is Ultra, 390U2W is U2W. I've used a couple of the latter and had no problems. Never used U3W though. Bye av. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 12 20: 2:56 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from lafontaine.cybercable.fr (lafontaine.cybercable.fr [212.198.0.202]) by hub.freebsd.org (Postfix) with SMTP id EF9D637B400 for ; Fri, 12 Jan 2001 20:02:38 -0800 (PST) Received: (qmail 24720831 invoked from network); 13 Jan 2001 04:02:36 -0000 Received: from s011.dhcp212-229.cybercable.fr (HELO gits.dyndns.org) ([212.198.229.11]) (envelope-sender ) by lafontaine.cybercable.fr (qmail-ldap-1.03) with SMTP for ; 13 Jan 2001 04:02:36 -0000 Received: (from root@localhost) by gits.dyndns.org (8.11.1/8.11.1) id f0D41CG23945; Sat, 13 Jan 2001 05:01:12 +0100 (CET) (envelope-from clefevre@citeweb.net) To: freebsd-scsi@freebsd.org Subject: SCSI suspend/resume X-Face: V|+c;4!|B?E%BE^{E6);aI.[<97Zd*>^#%Y5Cxv;%Y[PT-LW3;A:fRrJ8+^k"e7@+30g0YD0*^^3jgyShN7o?a]C la*Zv'5NA,=963bM%J^o]C From: Cyrille Lefevre Reply-To: clefevre@poboxes.com Mail-Copies-To: never Date: 13 Jan 2001 05:01:10 +0100 Message-ID: Lines: 12 User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there a way to suspend/resume SCSI devices as IDE devices does ? currently, if an SCSI device is manually suspended using camcontrol, it couldn't be automatically resumed except using camcontrol as well. while EDI devices maybe suspended/resumed through apm -z... if really not supported, is this planned in the future ? Cyrille. -- home: mailto:clefevre@citeweb.net work: mailto:Cyrille.Lefevre@edf.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jan 12 20:12:36 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 4510C37B400 for ; Fri, 12 Jan 2001 20:12:19 -0800 (PST) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA32790; Fri, 12 Jan 2001 21:12:18 -0700 (MST) (envelope-from ken) Date: Fri, 12 Jan 2001 21:12:18 -0700 From: "Kenneth D. Merry" To: clefevre@poboxes.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI suspend/resume Message-ID: <20010112211218.A32720@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from clefevre@citeweb.net on Sat, Jan 13, 2001 at 05:01:10AM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jan 13, 2001 at 05:01:10 +0100, Cyrille Lefevre wrote: > Is there a way to suspend/resume SCSI devices as IDE devices does ? > > currently, if an SCSI device is manually suspended using camcontrol, > it couldn't be automatically resumed except using camcontrol as well. The only thing I can figure you mean by "suspend" is "spin down". You can do that with camcontrol, like this: camcontrol stop da0 As soon as you try to access the drive, the SCSI subsystem will spin it back up. You can also spin a drive up with camcontrol: camcontrol start da0 > while EDI devices maybe suspended/resumed through apm -z... EDI devices? What are those? Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 13 14:21:49 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from h23.estsatnet (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id 7EE1437B400 for ; Sat, 13 Jan 2001 14:21:30 -0800 (PST) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by h23.estsatnet (8.9.3/8.9.3) with ESMTP id PAA06423 for ; Sat, 13 Jan 2001 15:23:13 -0700 Date: Sat, 13 Jan 2001 15:23:13 -0700 (MST) From: Eric Lee Green X-Sender: eric@h23.estsatnet To: freebsd-scsi@freebsd.org Subject: Why filemarks in sardpos? 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 This is under FreeBSD 4.2, as installed off of an ftp.freebsd.org mirror yesterday. In /usr/src/sys/cam/scsi/scsi_sa.c, in the sardpos routine, there is the following code: if (softc->flags & SA_FLAG_TAPE_WRITTEN) { error = sawritefilemarks(periph, 0, 0); if (error && error != EACCES) return (error); } I am using the GENERIC kernel. The above code makes the MTIOCRDSPOS ioctl have the following performance (kdump): 36104 bru 0.000025 CALL ioctl(0x5,MTIOCRDSPOS,0xbfbfecc4) 36104 bru 1.359931 RET ioctl 0 By contrast, when I comment that out, the MTIOCRDSPOS ioctl has the following performance: 391 bru 0.000025 CALL ioctl(0x5,MTIOCRDSPOS,0xbfbfed6c) 391 bru 0.001554 RET ioctl 0 Please note that this problem was noticed when I ported the QFA (Quick File Access) code in BRU 16.1 from Linux to FreeBSD (please do not ask me general questions about BRU, I will not know the answer -- I am EST's FreeBSD, tape drive, and tape changer person, I am not particularly knowledgable about BRU). QFA does a READ_POSITION during write time prior to writing each file (or each buffer, if we can fit multiple files into a BRU buffer) and saves that location data to a file or database. Then when it comes time to restore a single file, we tell BRU the filename and its tape position. The QFA code in BRU does a LOCATE to that location on the tape, grabs a buffer full of data (and perhaps additional bufferfulls if needed for a large file), and voila. Under Linux, this does not affect the performance of BRU during backups. Under FreeBSD *WITHOUT* the patch, BRU runs at snail's pace in QFA mode -- it is basically unusable, with a 1.35 second delay between each file written to tape, meaning we cannot build a QFA database this way (note that we can't just rely on how many buffers of data we've written out to tape -- we have no control over how the underlying OS does blocking, one BRU buffer could be multiple tape blocks). Under FreeBSD *WITH* the patch (that zaps sawritefilemarks), BRU runs at full speed. Note that the behavior of the Linux st.c driver corresponds to the behavior of my patched FreeBSD sa.c driver (where I zapped the sawritefilemarks). We have thoroughly tested the QFA code in BRU 16.1 with the st.c driver under Linux with every currently available enterprise-class tape drive and it correctly reports a logical tape position that is usable for restoring files. We have had over a dozen beta testers using BRU 16.1's QFA code under Linux for the past month without any reports of problems (and with much appreciation of being able to restore a lost file without having to read through the entire tape!). Here is my patch, BTW: -----------------------------snip--------------------------------------- --- sys/cam/scsi/scsi_sa.c.orig Sat Jan 13 14:25:44 2001 +++ sys/cam/scsi/scsi_sa.c Sat Jan 13 13:53:56 2001 @@ -3033,11 +3033,13 @@ * wary about trying to figure out the actual block location value * if data is in the tape drive buffer. */ +#ifdef STUPID_IDIOTIC_MORONIC_STUFF if (softc->flags & SA_FLAG_TAPE_WRITTEN) { error = sawritefilemarks(periph, 0, 0); if (error && error != EACCES) return (error); } +#endif ccb = cam_periph_getccb(periph, 1); scsi_read_position(&ccb->csio, 1, sadone, MSG_SIMPLE_Q_TAG, ------------------------------snip--------------------------------- Here is the corresponding code from Linux's st.c (this code is called directly from Linux's MTIOCPOS ioctl): memset (scmd, 0, 10); if ((STp->device)->scsi_level < SCSI_2) { scmd[0] = QFA_REQUEST_BLOCK; scmd[4] = 3; } else { scmd[0] = READ_POSITION; if (!logical && !STp->scsi2_logical) scmd[1] = 1; } SCpnt = st_do_scsi(NULL, STp, scmd, 20, STp->timeout, MAX_READY_RETRIES, TRUE); As I have mentioned, we have verified that the Linux behavior (simply issue the SSC READ_POSITION command *WITHOUT* a preceding FILEMARK command) works with all modern tape drives. If you want to see a subset of the tapedrives that we have tested this QFA code with, see http://www.linuxtapecert.org (please note that these are a severely limited subset of the drives we've actually tested). I have personally used: Tandberg SLR-50, Seagate DDS-3, Seagate DDS-4, HP DDS-3, HP DDS-4, Exabyte Mammoth, Exabyte Mammoth II, Ecrix VXA, Quantum DLT 4000, Quantum DLT 7000, Quantum DLT 8000, Seagate LTO, Sony AIT. On all of these drives, LOCATE properly finds the file using the READ POSITION number as reported without the preceding sawritefilemarks(). My conclusion is that the stuff commented out via #ifdef STUPID_IDIOTIC_MORONIC_STUFF is not necessary for proper operation of modern drives, and for drives that do need it, it slows down MTIOCRDSPOS to the point that it's useless anyhow (if we can't get the location of each file on tape because the call is so slow, why bother?) Final aside: It seems amazing that nobody else has ever run into this problem. Are we the only people who think that FreeBSD has potential for tape appliances in an enterprise backup setting? Are we the only people who have ever decided that FreeBSD is worthy of a port of an enterprise tape backup product? Surely our competitors aren't so lame that they would ignore QFA for quick restores? Oh well. At least we can still support backing up a FreeBSD machine to a Linux or Solaris box via BRU Professional, even though we can't officially support using FreeBSD as a BP tape server until we have an "official" version of FreeBSD with the capability of doing so (I will try to get an "unsupported" version of the BRU Professional tape server onto the CD, along with the patch, but obviously we can't officially support a product that requires a kernel patch in order to properly operate). -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 13 14:43:44 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 69D4737B69D for ; Sat, 13 Jan 2001 14:43:26 -0800 (PST) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA00682; Sat, 13 Jan 2001 14:43:25 -0800 Date: Sat, 13 Jan 2001 14:43:24 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Eric Lee Green Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? 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 On Sat, 13 Jan 2001, Eric Lee Green wrote: > > if (softc->flags & SA_FLAG_TAPE_WRITTEN) { > error = sawritefilemarks(periph, 0, 0); > if (error && error != EACCES) > return (error); > } > The current implementation is somewhat simplistic, and yes, it's a performance problem. If you read the SCSI-2 spec, you'll notice that there are 2 entities of interest with respect to this: First Block Location Last Block Location The paragraphs of interest are: --- The first block location field indicates the block address associated with the current logical position. The value shall inidcate the block address of the next data block to be transferred between the initiator and the target if a a READ or WRITE command is issued. The last block location field indicates the block address (see 10.1.6) associated with the next block to be transferred from the buffer to the medium. The value shall indicate the block address of the ntext data block to be transferred between the buffer and the medium. If the buffer does not contain a whole block of data or is empty, the value reported for the last block location shall be equal to the value reported for the first block location. ---- I elected to not trust tape firmware to get it right with respect to last block location and played it safe by flushing any pending buffers to be written when reading position. There is a lot of precedent for this- and considering that any real formal testing is not done within *BSD, let alone Linux, playing it safe with data integrity is a good idea. I'd certainly be more open rethinking this, or making this a quirk. However, your tone leads me to distrust statements of "we've tested", and since I'm the moron responsible, all I can say is, "Dude! Have a nice day!". -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 13 15:44:50 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from h23.estsatnet (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id 24C4E37B400 for ; Sat, 13 Jan 2001 15:44:32 -0800 (PST) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by h23.estsatnet (8.9.3/8.9.3) with ESMTP id QAA06567 for ; Sat, 13 Jan 2001 16:46:18 -0700 Date: Sat, 13 Jan 2001 16:46:18 -0700 (MST) From: Eric Lee Green X-Sender: eric@h23.estsatnet To: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? 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 On Sat, 13 Jan 2001, Eric Lee Green wrote: > +#ifdef STUPID_IDIOTIC_MORONIC_STUFF > if (softc->flags & SA_FLAG_TAPE_WRITTEN) { .... One final note, since apparently there is some misunderstanding -- the above #ifdef was put in during a caffeine-fueled midnight hacking session where I was about ready to toss the computer out the window. It has nothing to do with Matthew Jacob, FreeBSD, or anything other than the idiotic moronic tape drive firmware authors who conspire to make things difficult for those of us attempting to use their devices for more than doorstops. The Linux equivalent of sardpos in st.c has been tested with every drive that is listed on the Linux Tape Cerification page ( http://www.linuxtapecert.org ) as well as with various other drives that were not "officially" certified. I did not do this testing. I was not involved in this testing. The QFA code in BRU 16.1 has been thoroughly tested under Linux using the st.c driver as part of the BRU Professional product, which has been in beta test in production environments since late November. Again, I did not write the Linux code, and I was not involved in testing the Linux code, the author of that code and our QA department did that. Comments upon reliability: BRU 16.1 (and BRU Professional) do not require the logical tape position as reported by the tape subsystem during backups to be absolutely, 100% accurate. I know of no enterprise tape backup product with such a requirement, because tape drives just don't work that way. As long as the logical tape position reported is within 100 blocks or so of the "real" logical tape position, we'll find the file on tape, thanks to various retry and fallback mechanisms that will go on a "hunt" in the general neighborhood. EST has been in the tape backup business since 1984. The guy who spec'ed the QFA for BRU 16.1 had over 20 years experience in the tape backup business (including being project manager for a predecessor to Legato Netbackup). The guy who designed and wrote the QFA code in BRU 16.1 has been in the business for more time than I like to think about. As a matter of course he put things into that code to handle things that I would never have thought of as being potential problems. *IN PRACTICE* we have found that the Linux st.c driver reports numbers that can be directly fed to LOCATE to position exactly to where we need to be, but nowhere do we absolutely require that to be true. We do require accurate logical tape positions for where the start of an archive is located, but we can handle that at the applications level. We rely more on tape marks for that anyhow. I have a copy of the SSC standards here, but use it only as a guideline. As with the SMC standards (which I have pretty much memorized as the maintainer of mtx), any relationship to what tape drive vendors' products actually do is coincidental. I also have a shelf-full of vendors' SCSI-level drive manuals, which are more useful in many cases because they say what the drives really do, rather than what the SSC committee wished they'd do. EST also has a lab full of tape hardware which EST employees are busily certifying with BRU Professional, and that actual tape hardware is what is the final detirminant of what works and what doesn't work. Again, my apologies to those offended by the #ifdef. As for the tone of my messages, I realize I'm not the most diplomatic person in the world. The code as currently exists in the FreeBSD sa.c driver is useless in real world applications because it's too slow. I know there's sleazy salesmen types who could sugar-coat that to be more palatable, but if I had that gift, I'd be a manager, not an engineer. (shrug). Feel free to ignore the tone of any of my messages and focus upon the content. -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 13 20:51:27 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id F0AE837B6C5 for ; Sat, 13 Jan 2001 20:24:34 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id UAA01468; Sat, 13 Jan 2001 20:24:32 -0800 Date: Sat, 13 Jan 2001 20:24:32 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Eric Lee Green Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? 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 I've been giving this some thought and rereading the spec some more. I'm inclined to think that the difference between first and last logical block and the likelihood of a drive vendor pooching it has to do with whether one is using LOGICAL or HARDWARE block positioning. The paragraphs I quoted earlier, to recap, are: +The first block location field indicates the block address associated with +the current logical position. The value shall inidcate the block address of +the next data block to be transferred between the initiator and the target +if a READ or WRITE command is issued. + +The last block location field indicates the block address (see 10.1.6) +associated with the next block to be transferred from the buffer to the +medium. The value shall indicate the block address of the ntext data block to +be transferred between the buffer and the medium. If the buffer does not +contain a whole block of data or is empty, the value reported for the last +block location shall be equal to the value reported for the first block +location. A diagram of the tape model must be something like: Tape Buffer +----------------+ Initiator --->>-----| Z .. E D C B A |-->>---> Tape +----------------+ ^ ^ First Block Value Last Block Value So, all other things being equal, "First Block Value" should be good enough if one assumes that blocks Z..A get flushed to tape. The thing I would expect to break with drives is HARDWARE block positions... That is because actual HARDWARE block position might not in fact be known until data is actually on the media. One would *hope* that such a device would flush before reporting hardware position anyway, but, well.. LOGICAL block position is different- I would expect block #Z to be 26 more than block #A above- this shouldn't change. Again, assuming Z..A make it to tape (if they don't that's a catastrophic error). I notice you're using MTIOCRSPOS- I think I would tend agree that this wouldn't require a flush. Hardware position should probably stay where it is now. Anyone else out there have an opinion on this? -matt p.s.: Not all drives, btw, have a horrible speed loss with the flush operation. DAT drives seem fine. DLTs are horribly affected. p.p.s: [ yes, I'll ignore your barbarous manners. the content *is* important- not because BRU or ESTinc (ESTINK? New Unix errno?) is all that important- but the problem *has* been seen before... And, oh, btw, NetBackup ended up owned by Veritas, not Legato, I believe ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 13 23: 4:50 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from smtpgate2.syd.iprimus.com.au (smtpgate2.syd.iprimus.com.au [203.134.65.91]) by hub.freebsd.org (Postfix) with ESMTP id 5B6C737B402 for ; Sat, 13 Jan 2001 23:04:33 -0800 (PST) Received: from iprimus.com.au ([203.134.49.250]) by smtpgate2.syd.iprimus.com.au with Microsoft SMTPSVC(5.5.1877.537.53); Sun, 14 Jan 2001 18:04:46 +1100 Message-ID: <3A614EB7.D72489A7@iprimus.com.au> Date: Sun, 14 Jan 2001 18:01:11 +1100 From: Justin Clift X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Matthew, NetBackup is a Legato product which Veritas bought from them (Sun's Solstice Backup is also a rebadged version of the Legato NetBackup... er Veritas Netbackup I mean). Regards and best wishes, Justin Clift Matthew Jacob wrote: > > p.p.s: > > [ yes, I'll ignore your barbarous manners. the content *is* important- not > because BRU or ESTinc (ESTINK? New Unix errno?) is all that important- but the > problem *has* been seen before... And, oh, btw, NetBackup ended up owned by > Veritas, not Legato, I believe ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jan 13 23:17:12 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7C09937B401 for ; Sat, 13 Jan 2001 23:16:55 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id XAA01727; Sat, 13 Jan 2001 23:16:50 -0800 Date: Sat, 13 Jan 2001 23:16:50 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Justin Clift Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Why filemarks in sardpos? In-Reply-To: <3A614EB7.D72489A7@iprimus.com.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 Huh? Well, whaddya know... I worked at Legato and *I* don't recall what the hell that was... Oh well....I guess I should go check it out more closely.. On Sun, 14 Jan 2001, Justin Clift wrote: > Hi Matthew, > > NetBackup is a Legato product which Veritas bought from them (Sun's > Solstice Backup is also a rebadged version of the Legato NetBackup... er > Veritas Netbackup I mean). > > Regards and best wishes, > > Justin Clift > > Matthew Jacob wrote: > > > > > p.p.s: > > > > [ yes, I'll ignore your barbarous manners. the content *is* important- not > > because BRU or ESTinc (ESTINK? New Unix errno?) is all that important- but the > > problem *has* been seen before... And, oh, btw, NetBackup ended up owned by > > Veritas, not Legato, I believe ] > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message