From owner-freebsd-scsi Sun Jun 8 04:51:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA10138 for freebsd-scsi-outgoing; Sun, 8 Jun 1997 04:51:55 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA10132 for ; Sun, 8 Jun 1997 04:51:52 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA07286; Sun, 8 Jun 1997 13:51:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id NAA08817; Sun, 8 Jun 1997 13:40:08 +0200 (MET DST) Message-ID: <19970608134008.SK05770@uriah.heep.sax.de> Date: Sun, 8 Jun 1997 13:40:08 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@freebsd.org Cc: tom@tomqnx.com (Tom Torrance at home) Subject: Re: CD-R & SCSI Problems References: <19970607234548.VE42744@uriah.heep.sax.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Tom Torrance at home on Jun 8, 1997 03:59:00 -0400 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Tom Torrance at home wrote: > That SCSI debugging is really neat stuff! Here are the results of > doing the scsi command followed by an 'mt rewind'. > Jun 8 03:45:39 tomqnx /kernel: st0(ahc0:6:0): command: 1e,0,0,0,1,0-[0 bytes] > Jun 8 03:45:39 tomqnx /kernel: st0(ahc0:6:0): back in cmd() > Jun 8 03:45:40 tomqnx /kernel: st0(ahc0:6:0): sc_err1,err = 0x1 > Jun 8 03:45:40 tomqnx /kernel: code70 valid0 seg0 key5 ili0 eom0 fmark0 > Jun 8 03:45:40 tomqnx /kernel: info: 0 0 0 0 followed by 16 extra bytes > Jun 8 03:45:40 tomqnx /kernel: extra: 1 5 0 0 0 0 0 0 0 0 0 0 0 0 80 9a > Jun 8 03:45:40 tomqnx /kernel: st0(ahc0:6:0): calling private err_handler() > Jun 8 03:45:40 tomqnx /kernel: st0(ahc0:6:0): private err_handler() returned -1 > Jun 8 03:45:40 tomqnx /kernel: st0(ahc0:6:0): ILLEGAL REQUEST asc:20,0 Invalid command operation code 0x1e is PREVENT ALLOW MEDIUM REMOVAL. Thus, the failure is benign. The command is optional per the standard (thus FreeBSD shouldn't be that verbose about the returned error), but all the better drives seem to implement it -- even those that don't really have a chance to prevent you from removing the medium, like QIC. At least, your drive returns the correct error code. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sun Jun 8 11:29:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA07744 for freebsd-scsi-outgoing; Sun, 8 Jun 1997 11:29:16 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA07727 for ; Sun, 8 Jun 1997 11:29:11 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id LAA24046; Sun, 8 Jun 1997 11:28:39 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199706081828.LAA24046@GndRsh.aac.dev.com> Subject: Re: 3940uw with long cables In-Reply-To: <199706071831.UAA00806@yedi.iaf.nl> from Wilko Bulte at "Jun 7, 97 08:31:18 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Sun, 8 Jun 1997 11:28:39 -0700 (PDT) Cc: gibbs@plutotech.com, asami@CS.Berkeley.EDU, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As Justin T. Gibbs wrote... > > > Perhaps. There are a few important things to keep in mind when > > tuning the bus length. > > > > 1) Having equal distances between all devices is sometimes more > > important than total bus length since the varying RC constants > > can cause strange signal skew conditions if the lengths aren't > > matched. > > In addition to this: don't use both the internal and the external > connector of a SCSI adapter (assuming the internal & external > connector are on the same bus). The differences in external versus > internal (flat)cable are also no-good. I haven't seen much problem with that as long as you use consitent impedence cables. Ie, as long as the whole bus is run with 90 Ohm cable it works, but you have to spend the bucks for high quality teflon or twisted pair internal cables to get any place close to 90 ohms. And of cource you have to buy double sheilded twisted pair 90 ohm external cables with gold contacts. One thing about doing what you state above is that this means you are pretty much stuck with what ever type of termination is on the SCSI controller. I don't know of any controllers that have FPT on them, and for long busses FPT is a _must_. > > 6) Honor the 6m and 3m bus length limits. 6m is the longest for 10MHz > > and 3m is the longest for 20MHz single ended SCSI. This assumes > > proper stub/gap matching, so real life buses may need to be shorter. > > Hm. The company I work for (==DEC) uses the rule that a single ended > F10 (10MHz) bus can be a max of 3 meters. Justin, can you double check these numbers, I'm seeming to recall that it is 6 meters for async upto 5Mhz, 3 meters for sync upto 10Mhz and 1 meter for sync upto 20Mhz, unless your running differential, which is a whole other set of numbers. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-scsi Sun Jun 8 14:35:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA18698 for freebsd-scsi-outgoing; Sun, 8 Jun 1997 14:35:32 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA18693 for ; Sun, 8 Jun 1997 14:35:29 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id PAA16830; Sun, 8 Jun 1997 15:34:52 -0600 (MDT) Message-Id: <199706082134.PAA16830@pluto.plutotech.com> To: Wilko Bulte cc: gibbs@plutotech.com (Justin T. Gibbs), asami@cs.berkeley.edu, scsi@FreeBSD.ORG Subject: Re: 3940uw with long cables In-reply-to: Your message of "Sat, 07 Jun 1997 20:31:18 +0200." <199706071831.UAA00806@yedi.iaf.nl> Date: Sun, 08 Jun 1997 16:33:46 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >As Justin T. Gibbs wrote... > >> Perhaps. There are a few important things to keep in mind when >> tuning the bus length. >> >> 1) Having equal distances between all devices is sometimes more >> important than total bus length since the varying RC constants >> can cause strange signal skew conditions if the lengths aren't >> matched. > >In addition to this: don't use both the internal and the external >connector of a SCSI adapter (assuming the internal & external >connector are on the same bus). The differences in external versus >internal (flat)cable are also no-good. If you get quality external cables, along with high quatlity connectors, this need not be an issue. When dealing with cabling, it is the impedance of the cable and its length that are important, not its "external" or "internal" nature. I would only recommend a single external cable though, for example to an external enclosure that strings multiple devices together via ribbon cable, since it is almost impossible to meet requirement 1 (spacing) using external cables with mixed internal/external devices. Having two "clusters" of devices like this is how Adaptec recomends filling a fast20-wide bus since most external drive enclosures still don't seat 15 devices. >> 6) Honor the 6m and 3m bus length limits. 6m is the longest for 10MHz >> and 3m is the longest for 20MHz single ended SCSI. This assumes >> proper stub/gap matching, so real life buses may need to be shorter. > >Hm. The company I work for (==DEC) uses the rule that a single ended >F10 (10MHz) bus can be a max of 3 meters. Yes, my mistake. The actual numbers are: 6m - 5MHz sync 3m - 10MHz sync (Fast10) 1.5m - 20MHz sync (Fast20) >Wilko >_ ____________________________________________________________________ > | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands > |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda >-------------------------------------------------------------------------- > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sun Jun 8 14:49:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA19139 for freebsd-scsi-outgoing; Sun, 8 Jun 1997 14:49:10 -0700 (PDT) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA19125 for ; Sun, 8 Jun 1997 14:49:06 -0700 (PDT) Received: by iafnl.es.iaf.nl with UUCP id AA20099 (5.67b/IDA-1.5 for scsi@FreeBSD.ORG); Sun, 8 Jun 1997 23:49:03 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id WAA00434; Sun, 8 Jun 1997 22:56:32 +0200 (MET DST) From: Wilko Bulte Message-Id: <199706082056.WAA00434@yedi.iaf.nl> Subject: Re: 3940uw with long cables To: rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes) Date: Sun, 8 Jun 1997 22:56:32 +0200 (MET DST) Cc: gibbs@plutotech.com, asami@CS.Berkeley.EDU, scsi@FreeBSD.ORG In-Reply-To: <199706081828.LAA24046@GndRsh.aac.dev.com> from "Rodney W. Grimes" at Jun 8, 97 11:28:39 am X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Rodney W. Grimes wrote... > > As Justin T. Gibbs wrote... > > > > > Perhaps. There are a few important things to keep in mind when > > > tuning the bus length. > I haven't seen much problem with that as long as you use consitent > impedence cables. Ie, as long as the whole bus is run with 90 Ohm > cable it works, but you have to spend the bucks for high quality > teflon or twisted pair internal cables to get any place close to 90 ohms. > And of cource you have to buy double sheilded twisted pair 90 ohm > external cables with gold contacts. The Adaptec 1742[A] comes to mind as a very picky card when external and internal cables were used at the same time. It is of course very dependent on both card and cable characteristics. > One thing about doing what you state above is that this means you > are pretty much stuck with what ever type of termination is on the > SCSI controller. I don't know of any controllers that have FPT > on them, and for long busses FPT is a _must_. I agree. > > > 6) Honor the 6m and 3m bus length limits. 6m is the longest for 10MHz > > > and 3m is the longest for 20MHz single ended SCSI. This assumes > > > proper stub/gap matching, so real life buses may need to be shorter. > > > > Hm. The company I work for (==DEC) uses the rule that a single ended > > F10 (10MHz) bus can be a max of 3 meters. > > Justin, can you double check these numbers, I'm seeming to recall that > it is 6 meters for async upto 5Mhz, 3 meters for sync upto 10Mhz and Right, those are match my numbers. > 1 meter for sync upto 20Mhz, unless your running differential, which We assume 1.5m for 20MHz (half of what F10 uses). Be *very* conservative with stubs in case of F20 though. > is a whole other set of numbers. Yep, something like 20 or 25 meters for F10 diff. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-scsi Mon Jun 9 09:21:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA29714 for freebsd-scsi-outgoing; Mon, 9 Jun 1997 09:21:19 -0700 (PDT) Received: from stevenson.cogsci.ed.ac.uk (stevenson144.cogsci.ed.ac.uk [129.215.144.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA29629 for ; Mon, 9 Jun 1997 09:19:03 -0700 (PDT) Received: (from richard@localhost) by stevenson.cogsci.ed.ac.uk (8.8.5/8.8.5) id RAA16264; Mon, 9 Jun 1997 17:18:25 +0100 (BST) Date: Mon, 9 Jun 1997 17:18:25 +0100 (BST) Message-Id: <199706091618.RAA16264@stevenson.cogsci.ed.ac.uk> From: Richard Tobin Subject: Re: CD-R & SCSI Problems To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), scsi@FreeBSD.ORG In-Reply-To: J Wunsch's message of Sat, 7 Jun 1997 23:45:48 +0200 Organization: just say no Cc: tom@tomqnx.com (Tom Torrance at home) Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Present Mode: Density = 0x45 Blocksize = 512 bytes I didn't see the start of this thread - what exactly is the question? Last year I posted fairly trivial patches for the T4000s, which I thought had been incorporated but I'm still running 2.1.5 on the relevant machine. > That's probably a vendor density code for the compressed mode. It is the right density code, but the drive doesn't have hardware compression. > > Is there any possibility that the density table listed in > > scsiconf.h is seriously out of date? > > It's the table from the SCSI-2 specs, and as such, represents the > official standard. Maybe the standard is out of date :-) Incidentally, the QIC standard (whose number escapes me) for Travan-4 does not specify how it is accessed as a SCSI device; I believe there is another standard (which I don't have) concerning SCSI implementation of QIC standards. -- Richard From owner-freebsd-scsi Mon Jun 9 12:17:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA09202 for freebsd-scsi-outgoing; Mon, 9 Jun 1997 12:17:12 -0700 (PDT) Received: from pat.idi.ntnu.no (0@pat.idi.ntnu.no [129.241.103.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA09175 for ; Mon, 9 Jun 1997 12:16:58 -0700 (PDT) Received: from idt.unit.no (tegge@ikke.idi.ntnu.no [129.241.111.65]) by pat.idi.ntnu.no (8.8.5/8.8.5) with ESMTP id VAA16067 for ; Mon, 9 Jun 1997 21:16:40 +0200 (MET DST) Message-Id: <199706091916.VAA16067@pat.idi.ntnu.no> To: freebsd-scsi@freebsd.org Subject: scsi recovery code causes system freeze X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Jun__9_21:12:56_1997)--" Content-Transfer-Encoding: 7bit Date: Mon, 09 Jun 1997 21:16:39 +0200 From: Tor Egge Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ----Next_Part(Mon_Jun__9_21:12:56_1997)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have some problems with heavy write activity on a scsi bus causing scsi timeouts. Sometimes the machine freezes during the error recovery. I have reproduced the timeout problems on two machines: ikke.idi.ntnu.no: 5 external disks of type , all located in a single external enclosure. AHA 2940UW controller, < 3 m scsi cable. DDB configured. skarven.itea.ntnu.no: 7 external disks of type , 1 external disks of type , located in two external enclosures (4 disks in each). AHA 2940UW controller, < 3 m scsi cable. DDB not configured, since the machine should be able to boot after a trap 12. The timeout problem only seem to happen during periods with intense write activity on multiple disks on the same scsi bus. For both machines, the number of openings on drives supporting tagged commands has been reduced from 8 to 4. This does not help. :-( The freeze problem has currently only occured on skarven.itea.ntnu.no. In all freezes, the messages file has ended in ``Clearing bus reset'', with no following ``Clearing 'in-reset' flag''. This indicates a serious problem with the SCSI bus reset code. The /var/log/messages file is accessed via a different SCSI controller, thus I suspect the timeout is never occuring for some reason. One possible scenario is: - Bus reset cleared, bus reset settle timeout scheduled - New scsi command to a target on the same scsi bus arrives before the bus reset settle timeout has been triggered. - Infinite retry loop in scsi_scsi_cmd blocking the bus reset settle timeout: - scsi_scsi_cmd calls ahc_scsi_cmd, which sets xs->error to XS_BUSY, increases the retry count and returns immediately with the value COMPLETE. - scsi_scsi_cmd then calls sc_err1, which delays 1 ms, decreases the retry count by one, and returns the value SCSIRET_DO_RETRY. This causes scsi_scsi_cmd to never actually finish, since the timeout to remove the bus reset is blocked by the retry loop. This also causes the system to freeze. - Tor Egge ----Next_Part(Mon_Jun__9_21:12:56_1997)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: "cut from the messages file" Jun 5 21:32:00 skarven /kernel: sd7: SCB 0x1c - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:32:00 skarven /kernel: SEQADDR = 0x9 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:32:00 skarven /kernel: Ordered Tag queued Jun 5 21:32:00 skarven /kernel: sd12: SCB 0x8 timedout while recovery in progress Jun 5 21:32:00 skarven /kernel: Ordered Tag sent Jun 5 21:32:05 skarven /kernel: sd7: SCB 0x1c - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:32:05 skarven /kernel: SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:32:05 skarven /kernel: sd7: Queueing an Abort SCB Jun 5 21:32:05 skarven /kernel: sd7: Abort Message Sent Jun 5 21:32:05 skarven /kernel: sd7: SCB 28 - Abort Tag Completed. Jun 5 21:32:05 skarven /kernel: sd7: no longer in timeout Jun 5 21:32:10 skarven /kernel: sd12: SCB 0x8 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:32:10 skarven /kernel: SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x27 SSTAT1 = 0xb Jun 5 21:32:10 skarven /kernel: Ordered Tag queued Jun 5 21:32:10 skarven /kernel: Ordered Tag sent Jun 5 21:32:15 skarven /kernel: sd12: SCB 0x8 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:32:15 skarven /kernel: SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:32:15 skarven /kernel: sd12: Queueing an Abort SCB Jun 5 21:32:15 skarven /kernel: sd12: Abort Message Sent Jun 5 21:32:15 skarven /kernel: sd12: SCB 8 - Abort Tag Completed. Jun 5 21:32:15 skarven /kernel: sd12: no longer in timeout Jun 5 21:34:59 skarven ftpd[19495]: FTP LOGIN FAILED FROM inetgw.guidant.com, dir Jun 5 21:49:42 skarven /kernel: sd11: SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:49:42 skarven /kernel: SEQADDR = 0x4 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:49:42 skarven /kernel: Ordered Tag queued Jun 5 21:49:42 skarven /kernel: sd12: SCB 0xf timedout while recovery in progress Jun 5 21:49:42 skarven /kernel: sd12: SCB 0xe timedout while recovery in progress Jun 5 21:49:42 skarven /kernel: sd13: SCB 0xb timedout while recovery in progress Jun 5 21:49:42 skarven /kernel: sd13: SCB 0x12 timedout while recovery in progress Jun 5 21:49:47 skarven /kernel: sd11: SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:49:47 skarven /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:49:47 skarven /kernel: sd11: Queueing an Abort SCB Jun 5 21:49:47 skarven /kernel: sd11: Abort Message Sent Jun 5 21:49:47 skarven /kernel: sd11: SCB 2 - Abort Tag Completed. Jun 5 21:49:47 skarven /kernel: sd11: no longer in timeout Jun 5 21:49:47 skarven /kernel: Ordered Tag sent Jun 5 21:49:52 skarven /kernel: sd13: SCB 0x12 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:49:52 skarven /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:49:52 skarven /kernel: Ordered Tag queued Jun 5 21:49:52 skarven /kernel: sd13: SCB 0xb timedout while recovery in progress Jun 5 21:49:52 skarven /kernel: sd12: SCB 0xe timedout while recovery in progress Jun 5 21:49:52 skarven /kernel: sd12: SCB 0xf timedout while recovery in progress Jun 5 21:49:57 skarven /kernel: sd13: SCB 0x12 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:49:57 skarven /kernel: SEQADDR = 0x4 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:49:57 skarven /kernel: sd13: Queueing an Abort SCB Jun 5 21:49:57 skarven /kernel: sd13: Abort Message Sent Jun 5 21:49:57 skarven /kernel: sd13: SCB 18 - Abort Tag Completed. Jun 5 21:49:57 skarven /kernel: sd13: no longer in timeout Jun 5 21:49:57 skarven /kernel: Ordered Tag sent Jun 5 21:50:02 skarven /kernel: sd12: SCB 0xf - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:50:02 skarven /kernel: SEQADDR = 0x7 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:50:02 skarven /kernel: Ordered Tag queued Jun 5 21:50:02 skarven /kernel: sd12: SCB 0xe timedout while recovery in progress Jun 5 21:50:02 skarven /kernel: sd13: SCB 0xb timedout while recovery in progress Jun 5 21:50:02 skarven /kernel: Ordered Tag sent Jun 5 21:50:07 skarven /kernel: sd12: SCB 0xf - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:50:07 skarven /kernel: SEQADDR = 0x9 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:50:07 skarven /kernel: sd12: Queueing an Abort SCB Jun 5 21:50:07 skarven /kernel: sd12: Abort Message Sent Jun 5 21:50:07 skarven /kernel: sd12: SCB 15 - Abort Tag Completed. Jun 5 21:50:07 skarven /kernel: sd12: no longer in timeout Jun 5 21:50:12 skarven /kernel: sd13: SCB 0xb - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:50:12 skarven /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:50:12 skarven /kernel: Ordered Tag queued Jun 5 21:50:12 skarven /kernel: sd12: SCB 0xe timedout while recovery in progress Jun 5 21:50:12 skarven /kernel: Ordered Tag sent Jun 5 21:50:17 skarven /kernel: sd13: SCB 0xb - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:50:17 skarven /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:50:17 skarven /kernel: sd13: Queueing an Abort SCB Jun 5 21:50:17 skarven /kernel: sd13: Abort Message Sent Jun 5 21:50:17 skarven /kernel: sd13: SCB 11 - Abort Tag Completed. Jun 5 21:50:17 skarven /kernel: sd13: no longer in timeout Jun 5 21:50:22 skarven /kernel: sd12: SCB 0xe - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:50:22 skarven /kernel: SEQADDR = 0x9 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:50:22 skarven /kernel: Ordered Tag queued Jun 5 21:50:22 skarven /kernel: Ordered Tag sent Jun 5 21:50:27 skarven /kernel: sd12: SCB 0xe - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:50:27 skarven /kernel: SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:50:27 skarven /kernel: sd12: Queueing an Abort SCB Jun 5 21:50:27 skarven /kernel: sd12: Abort Message Sent Jun 5 21:50:27 skarven /kernel: sd12: SCB 14 - Abort Tag Completed. Jun 5 21:50:27 skarven /kernel: sd12: no longer in timeout Jun 5 21:52:47 skarven /kernel: sd11: SCB 0x3 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:52:47 skarven /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:52:47 skarven /kernel: Ordered Tag queued Jun 5 21:52:47 skarven /kernel: sd11: SCB 0xe timedout while recovery in progress Jun 5 21:52:47 skarven /kernel: sd12: SCB 0x19 timedout while recovery in progress Jun 5 21:52:52 skarven /kernel: sd11: SCB 0x3 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:52:52 skarven /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:52:52 skarven /kernel: sd11: Queueing an Abort SCB Jun 5 21:52:52 skarven /kernel: sd11: Abort Message Sent Jun 5 21:52:52 skarven /kernel: sd11: SCB 3 - Abort Tag Completed. Jun 5 21:52:52 skarven /kernel: sd11: no longer in timeout Jun 5 21:52:52 skarven /kernel: Ordered Tag sent Jun 5 21:52:57 skarven /kernel: sd12: SCB 0x19 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:52:57 skarven /kernel: SEQADDR = 0x4 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:52:57 skarven /kernel: Ordered Tag queued Jun 5 21:52:57 skarven /kernel: sd11: SCB 0xe timedout while recovery in progress Jun 5 21:53:02 skarven /kernel: sd12: SCB 0x19 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:53:02 skarven /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:53:02 skarven /kernel: sd12: Queueing an Abort SCB Jun 5 21:53:02 skarven /kernel: sd12: Abort Message Sent Jun 5 21:53:02 skarven /kernel: sd12: SCB 25 - Abort Tag Completed. Jun 5 21:53:02 skarven /kernel: sd12: no longer in timeout Jun 5 21:53:02 skarven /kernel: Ordered Tag sent Jun 5 21:53:07 skarven /kernel: sd11: SCB 0xe - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:53:07 skarven /kernel: SEQADDR = 0x7 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:53:07 skarven /kernel: Ordered Tag queued Jun 5 21:53:07 skarven /kernel: Ordered Tag sent Jun 5 21:53:12 skarven /kernel: sd11: SCB 0xe - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:53:12 skarven /kernel: SEQADDR = 0x9 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:53:12 skarven /kernel: sd11: Queueing an Abort SCB Jun 5 21:53:12 skarven /kernel: sd11: Abort Message Sent Jun 5 21:53:12 skarven /kernel: sd11: SCB 14 - Abort Tag Completed. Jun 5 21:53:12 skarven /kernel: sd11: no longer in timeout Jun 5 21:55:48 skarven ftpd[19613]: warning: can't verify hostname: gethostbyname(ppp3-cst100.warszawa.tpnet.pl) failed Jun 5 21:55:48 skarven ftpd[19613]: refused connect from 195.116.251.100 Jun 5 21:55:58 skarven /kernel: sd13: SCB 0x1b - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:55:58 skarven /kernel: SEQADDR = 0x7 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:55:58 skarven /kernel: Ordered Tag queued Jun 5 21:55:58 skarven /kernel: sd11: SCB 0x12 timedout while recovery in progress Jun 5 21:55:58 skarven /kernel: sd11: SCB 0x9 timedout while recovery in progress Jun 5 21:55:58 skarven /kernel: sd11: SCB 0xd timedout while recovery in progress Jun 5 21:55:58 skarven /kernel: sd11: SCB 0x13 timedout while recovery in progress Jun 5 21:55:58 skarven /kernel: sd7: SCB 0x2 timedout while recovery in progress Jun 5 21:56:03 skarven /kernel: sd13: SCB 0x1b - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:56:03 skarven /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:56:03 skarven /kernel: sd13: Queueing an Abort SCB Jun 5 21:56:03 skarven /kernel: sd13: Abort Message Sent Jun 5 21:56:03 skarven /kernel: sd13: SCB 27 - Abort Tag Completed. Jun 5 21:56:03 skarven /kernel: sd13: no longer in timeout Jun 5 21:56:03 skarven /kernel: Ordered Tag sent Jun 5 21:56:08 skarven /kernel: sd11: SCB 0x13 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:56:08 skarven /kernel: SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:56:08 skarven /kernel: Ordered Tag queued Jun 5 21:56:08 skarven /kernel: sd11: SCB 0xd timedout while recovery in progress Jun 5 21:56:08 skarven /kernel: sd11: SCB 0x9 timedout while recovery in progress Jun 5 21:56:08 skarven /kernel: sd11: SCB 0x12 timedout while recovery in progress Jun 5 21:56:08 skarven /kernel: sd7: SCB 0x2 timedout while recovery in progress Jun 5 21:56:13 skarven /kernel: sd11: SCB 0x13 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:56:13 skarven /kernel: SEQADDR = 0x7 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:56:13 skarven /kernel: sd11: Queueing an Abort SCB Jun 5 21:56:13 skarven /kernel: sd11: Abort Message Sent Jun 5 21:56:13 skarven /kernel: sd11: SCB 19 - Abort Tag Completed. Jun 5 21:56:13 skarven /kernel: sd11: no longer in timeout Jun 5 21:56:13 skarven /kernel: Ordered Tag sent Jun 5 21:56:18 skarven /kernel: sd11: SCB 0x12 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:56:18 skarven /kernel: SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:56:18 skarven /kernel: Ordered Tag queued Jun 5 21:56:18 skarven /kernel: sd11: SCB 0x9 timedout while recovery in progress Jun 5 21:56:18 skarven /kernel: sd11: SCB 0xd timedout while recovery in progress Jun 5 21:56:18 skarven /kernel: sd7: SCB 0x2 timedout while recovery in progress Jun 5 21:56:18 skarven /kernel: Ordered Tag sent Jun 5 21:56:23 skarven /kernel: sd11: SCB 0x12 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:56:23 skarven /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:56:23 skarven /kernel: sd11: Queueing an Abort SCB Jun 5 21:56:23 skarven /kernel: sd11: Abort Message Sent Jun 5 21:56:23 skarven /kernel: sd11: SCB 18 - Abort Tag Completed. Jun 5 21:56:23 skarven /kernel: sd11: no longer in timeout Jun 5 21:56:25 skarven xntpd[109]: time reset (step) 1.406288 s Jun 5 21:56:30 skarven /kernel: sd11: SCB 0xd - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:56:30 skarven /kernel: SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:56:30 skarven /kernel: Ordered Tag queued Jun 5 21:56:30 skarven /kernel: sd11: SCB 0x9 timedout while recovery in progress Jun 5 21:56:30 skarven /kernel: sd7: SCB 0x2 timedout while recovery in progress Jun 5 21:56:30 skarven /kernel: Ordered Tag sent Jun 5 21:56:35 skarven /kernel: sd11: SCB 0xd - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:56:35 skarven /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:56:35 skarven /kernel: sd11: Queueing an Abort SCB Jun 5 21:56:35 skarven /kernel: sd11: Abort Message Sent Jun 5 21:56:35 skarven /kernel: sd11: SCB 13 - Abort Tag Completed. Jun 5 21:56:35 skarven /kernel: sd11: no longer in timeout Jun 5 21:56:40 skarven /kernel: sd11: SCB 0x9 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:56:40 skarven /kernel: SEQADDR = 0x7 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:56:40 skarven /kernel: Ordered Tag queued Jun 5 21:56:40 skarven /kernel: sd7: SCB 0x2 timedout while recovery in progress Jun 5 21:56:40 skarven /kernel: Ordered Tag sent Jun 5 21:56:45 skarven /kernel: sd11: SCB 0x9 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:56:45 skarven /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:56:45 skarven /kernel: sd11: Queueing an Abort SCB Jun 5 21:56:45 skarven /kernel: sd11: Abort Message Sent Jun 5 21:56:45 skarven /kernel: sd11: SCB 9 - Abort Tag Completed. Jun 5 21:56:45 skarven /kernel: sd11: no longer in timeout Jun 5 21:56:50 skarven /kernel: sd7: SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:56:50 skarven /kernel: SEQADDR = 0x4 SCSISEQ = 0x12 SSTAT0 = 0x27 SSTAT1 = 0xb Jun 5 21:56:50 skarven /kernel: Ordered Tag queued Jun 5 21:56:50 skarven /kernel: Ordered Tag sent Jun 5 21:56:55 skarven /kernel: sd7: SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:56:55 skarven /kernel: SEQADDR = 0x9 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:56:55 skarven /kernel: sd7: Queueing an Abort SCB Jun 5 21:56:55 skarven /kernel: sd7: Abort Message Sent Jun 5 21:56:55 skarven /kernel: sd7: SCB 2 - Abort Tag Completed. Jun 5 21:56:55 skarven /kernel: sd7: no longer in timeout Jun 5 21:57:36 skarven /kernel: sd6: SCB 0xd - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:57:36 skarven /kernel: SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:57:36 skarven /kernel: Ordered Tag queued Jun 5 21:57:41 skarven /kernel: sd6: SCB 0xd - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 21:57:41 skarven /kernel: SEQADDR = 0x7 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 21:57:41 skarven /kernel: sd6: Queueing an Abort SCB Jun 5 21:57:41 skarven /kernel: sd6: Abort Message Sent Jun 5 21:57:41 skarven /kernel: sd6: SCB 13 - Abort Tag Completed. Jun 5 21:57:41 skarven /kernel: sd6: no longer in timeout Jun 5 21:57:41 skarven /kernel: Ordered Tag sent Jun 5 22:01:12 skarven /kernel: sd12: SCB 0x7 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:01:12 skarven /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:01:12 skarven /kernel: Ordered Tag queued Jun 5 22:01:12 skarven /kernel: sd13: SCB 0xa timedout while recovery in progress Jun 5 22:01:12 skarven /kernel: sd11: SCB 0x10 timedout while recovery in progress Jun 5 22:01:12 skarven /kernel: sd13: SCB 0xd timedout while recovery in progress Jun 5 22:01:12 skarven /kernel: sd13: SCB 0x0 timedout while recovery in progress Jun 5 22:01:17 skarven /kernel: sd12: SCB 0x7 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:01:17 skarven /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:01:17 skarven /kernel: sd12: Queueing an Abort SCB Jun 5 22:01:17 skarven /kernel: sd12: Abort Message Sent Jun 5 22:01:17 skarven /kernel: sd12: SCB 7 - Abort Tag Completed. Jun 5 22:01:17 skarven /kernel: sd12: no longer in timeout Jun 5 22:01:17 skarven /kernel: Ordered Tag sent Jun 5 22:01:22 skarven /kernel: sd13: SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:01:22 skarven /kernel: SEQADDR = 0x9 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:01:22 skarven /kernel: Ordered Tag queued Jun 5 22:01:22 skarven /kernel: sd13: SCB 0xd timedout while recovery in progress Jun 5 22:01:22 skarven /kernel: sd11: SCB 0x10 timedout while recovery in progress Jun 5 22:01:22 skarven /kernel: sd13: SCB 0xa timedout while recovery in progress Jun 5 22:01:27 skarven /kernel: sd13: SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:01:27 skarven /kernel: SEQADDR = 0x4 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:01:27 skarven /kernel: sd13: Queueing an Abort SCB Jun 5 22:01:27 skarven /kernel: sd13: Abort Message Sent Jun 5 22:01:27 skarven /kernel: sd13: SCB 0 - Abort Tag Completed. Jun 5 22:01:27 skarven /kernel: sd13: no longer in timeout Jun 5 22:01:27 skarven /kernel: Ordered Tag sent Jun 5 22:01:32 skarven /kernel: sd13: SCB 0xa - timed out in command phase, SCSISIGI == 0xe6 Jun 5 22:01:32 skarven /kernel: SEQADDR = 0x4f SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x13 Jun 5 22:01:32 skarven /kernel: Ordered Tag queued Jun 5 22:01:32 skarven /kernel: sd11: SCB 0x10 timedout while recovery in progress Jun 5 22:01:32 skarven /kernel: sd13: SCB 0xd timedout while recovery in progress Jun 5 22:01:32 skarven /kernel: Ordered Tag sent Jun 5 22:01:37 skarven /kernel: sd13: SCB 0xa - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:01:37 skarven /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:01:37 skarven /kernel: sd13: Queueing an Abort SCB Jun 5 22:01:37 skarven /kernel: sd13: Abort Message Sent Jun 5 22:01:37 skarven /kernel: sd13: SCB 10 - Abort Tag Completed. Jun 5 22:01:37 skarven /kernel: sd13: no longer in timeout Jun 5 22:01:42 skarven /kernel: sd13: SCB 0xd - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:01:42 skarven /kernel: SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:01:42 skarven /kernel: Ordered Tag queued Jun 5 22:01:42 skarven /kernel: sd11: SCB 0x10 timedout while recovery in progress Jun 5 22:01:42 skarven /kernel: Ordered Tag sent Jun 5 22:01:47 skarven /kernel: sd13: SCB 0xd - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:01:47 skarven /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:01:47 skarven /kernel: sd13: Queueing an Abort SCB Jun 5 22:01:47 skarven /kernel: sd13: Abort Message Sent Jun 5 22:01:47 skarven /kernel: sd13: SCB 13 - Abort Tag Completed. Jun 5 22:01:47 skarven /kernel: sd13: no longer in timeout Jun 5 22:01:52 skarven /kernel: sd11: SCB 0x10 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:01:52 skarven /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:01:52 skarven /kernel: Ordered Tag queued Jun 5 22:01:52 skarven /kernel: Ordered Tag sent Jun 5 22:01:57 skarven /kernel: sd11: SCB 0x10 - timed out in command phase, SCSISIGI == 0xe6 Jun 5 22:01:57 skarven /kernel: SEQADDR = 0x4f SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x13 Jun 5 22:01:57 skarven /kernel: sd6: abort message in message buffer Jun 5 22:01:57 skarven /kernel: ahc1:A:2: Missed busfree. Jun 5 22:01:57 skarven /kernel: sd6: SCB 0x13 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0xb6 Jun 5 22:01:57 skarven /kernel: SEQADDR = 0x5 SCSISEQ = 0x5a SSTAT0 = 0x7 SSTAT1 = 0x13 Jun 5 22:01:57 skarven /kernel: ahc1: Issued Channel A Bus Reset. 5 SCBs aborted Jun 5 22:01:57 skarven /kernel: Clearing bus reset Jun 5 22:01:58 skarven /kernel: Clearing 'in-reset' flag Jun 5 22:01:58 skarven /kernel: sd11: no longer in timeout Jun 5 22:01:58 skarven /kernel: sd6: no longer in timeout Jun 5 22:01:58 skarven /kernel: sd8: UNIT ATTENTION asc:29,2 Jun 5 22:01:58 skarven /kernel: , retries:3 Jun 5 22:01:58 skarven /kernel: sd6: UNIT ATTENTION asc:29,2 Jun 5 22:01:58 skarven /kernel: , retries:3 Jun 5 22:01:58 skarven /kernel: sd11: UNIT ATTENTION asc:29,2 Jun 5 22:01:58 skarven /kernel: , retries:3 Jun 5 22:01:58 skarven /kernel: sd7: UNIT ATTENTION asc:29,2 Jun 5 22:01:58 skarven /kernel: , retries:3 Jun 5 22:01:58 skarven /kernel: sd10: UNIT ATTENTION asc:29,2 Jun 5 22:01:58 skarven /kernel: , retries:4 Jun 5 22:01:58 skarven /kernel: sd9: UNIT ATTENTION asc:29,2 Jun 5 22:01:58 skarven /kernel: , retries:4 Jun 5 22:01:58 skarven /kernel: sd12: UNIT ATTENTION asc:29,2 Jun 5 22:01:58 skarven /kernel: , retries:4 Jun 5 22:01:58 skarven /kernel: sd13: UNIT ATTENTION asc:29,2 Jun 5 22:01:58 skarven /kernel: , retries:4 Jun 5 22:04:18 skarven /kernel: sd11: SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:04:18 skarven /kernel: SEQADDR = 0x7 SCSISEQ = 0x12 SSTAT0 = 0x27 SSTAT1 = 0xb Jun 5 22:04:18 skarven /kernel: Ordered Tag queued Jun 5 22:04:18 skarven /kernel: sd11: SCB 0x0 timedout while recovery in progress Jun 5 22:04:18 skarven /kernel: sd11: SCB 0x15 timedout while recovery in progress Jun 5 22:04:18 skarven /kernel: sd11: SCB 0x5 timedout while recovery in progress Jun 5 22:04:23 skarven /kernel: sd11: SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:04:23 skarven /kernel: SEQADDR = 0x4 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:04:23 skarven /kernel: sd11: Queueing an Abort SCB Jun 5 22:04:23 skarven /kernel: sd11: Abort Message Sent Jun 5 22:04:23 skarven /kernel: sd11: SCB 2 - Abort Tag Completed. Jun 5 22:04:23 skarven /kernel: sd11: no longer in timeout Jun 5 22:04:23 skarven /kernel: Ordered Tag sent Jun 5 22:04:28 skarven /kernel: sd11: SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:04:28 skarven /kernel: SEQADDR = 0x8 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:04:28 skarven /kernel: Ordered Tag queued Jun 5 22:04:28 skarven /kernel: sd11: SCB 0x5 timedout while recovery in progress Jun 5 22:04:28 skarven /kernel: sd11: SCB 0x15 timedout while recovery in progress Jun 5 22:04:28 skarven /kernel: Ordered Tag sent Jun 5 22:04:33 skarven /kernel: sd11: SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:04:33 skarven /kernel: SEQADDR = 0x7 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:04:33 skarven /kernel: sd11: Queueing an Abort SCB Jun 5 22:04:33 skarven /kernel: sd11: Abort Message Sent Jun 5 22:04:33 skarven /kernel: sd11: SCB 0 - Abort Tag Completed. Jun 5 22:04:33 skarven /kernel: sd11: no longer in timeout Jun 5 22:04:38 skarven /kernel: sd11: SCB 0x15 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:04:38 skarven /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:04:38 skarven /kernel: Ordered Tag queued Jun 5 22:04:38 skarven /kernel: sd11: SCB 0x5 timedout while recovery in progress Jun 5 22:04:38 skarven /kernel: Ordered Tag sent Jun 5 22:04:43 skarven /kernel: sd11: SCB 0x15 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:04:43 skarven /kernel: SEQADDR = 0x7 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:04:43 skarven /kernel: sd11: Queueing an Abort SCB Jun 5 22:04:43 skarven /kernel: sd11: Abort Message Sent Jun 5 22:04:43 skarven /kernel: sd11: SCB 21 - Abort Tag Completed. Jun 5 22:04:43 skarven /kernel: sd11: no longer in timeout Jun 5 22:04:48 skarven /kernel: sd11: SCB 0x5 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Jun 5 22:04:48 skarven /kernel: SEQADDR = 0x4 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa Jun 5 22:04:48 skarven /kernel: Ordered Tag queued Jun 5 22:04:48 skarven /kernel: Ordered Tag sent Jun 5 22:04:53 skarven /kernel: sd11: SCB 0x5 - timed out in command phase, SCSISIGI == 0xe6 Jun 5 22:04:53 skarven /kernel: SEQADDR = 0x4f SCSISEQ = 0x12 SSTAT0 = 0x7 SSTAT1 = 0x13 Jun 5 22:04:53 skarven /kernel: sd6: abort message in message buffer Jun 5 22:04:53 skarven /kernel: ahc1:A:2: Missed busfree. Jun 5 22:04:53 skarven /kernel: sd6: SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0xb6 Jun 5 22:04:53 skarven /kernel: SEQADDR = 0x5 SCSISEQ = 0x5a SSTAT0 = 0x7 SSTAT1 = 0x13 Jun 5 22:04:53 skarven /kernel: ahc1: Issued Channel A Bus Reset. 7 SCBs aborted Jun 5 22:04:53 skarven /kernel: Clearing bus reset ----Next_Part(Mon_Jun__9_21:12:56_1997)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Description: "scsi driver patch" Index: aic7xxx.c =================================================================== RCS file: /home/ncvs/src/sys/i386/scsi/aic7xxx.c,v retrieving revision 1.118 diff -u -r1.118 aic7xxx.c --- aic7xxx.c 1997/04/26 05:03:18 1.118 +++ aic7xxx.c 1997/05/29 16:31:23 @@ -1906,7 +1906,7 @@ if (ahc->scb_data->maxhscbs >= 16 || (ahc->flags & AHC_PAGESCBS)) { /* Default to 8 tags */ - xs->sc_link->opennings += 6; + xs->sc_link->opennings += 2; } else { /* * Default to 4 tags on whimpy ----Next_Part(Mon_Jun__9_21:12:56_1997)---- From owner-freebsd-scsi Mon Jun 9 13:06:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA11782 for freebsd-scsi-outgoing; Mon, 9 Jun 1997 13:06:26 -0700 (PDT) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA11774 for ; Mon, 9 Jun 1997 13:06:23 -0700 (PDT) Received: by iafnl.es.iaf.nl with UUCP id AA04869 (5.67b/IDA-1.5 for scsi@FreeBSD.ORG); Mon, 9 Jun 1997 22:06:24 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id UAA00957; Mon, 9 Jun 1997 20:26:22 +0200 (MET DST) From: Wilko Bulte Message-Id: <199706091826.UAA00957@yedi.iaf.nl> Subject: Re: 3940uw with long cables To: gibbs@plutotech.com (Justin T. Gibbs) Date: Mon, 9 Jun 1997 20:26:22 +0200 (MET DST) Cc: gibbs@plutotech.com, asami@cs.berkeley.edu, scsi@FreeBSD.ORG In-Reply-To: <199706082134.PAA16830@pluto.plutotech.com> from "Justin T. Gibbs" at Jun 8, 97 04:33:46 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Justin T. Gibbs wrote... > >> 1) Having equal distances between all devices is sometimes more > >> important than total bus length since the varying RC constants > >> can cause strange signal skew conditions if the lengths aren't > >> matched. > >In addition to this: don't use both the internal and the external > >connector of a SCSI adapter (assuming the internal & external > >connector are on the same bus). The differences in external versus > >internal (flat)cable are also no-good. > If you get quality external cables, along with high quatlity > connectors, this need not be an issue. When dealing with cabling, And high quality terminators. > it is the impedance of the cable and its length that are important, > not its "external" or "internal" nature. I would only recommend Exactly, but matching internal and external cable impedance might be a problem. It is hard to determine impedances, and at least well beyond the scope of the average SCSI user. I think the following is valid: - if it works: fine - if it does not: try external and internal buses on seperate hostadapters. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-scsi Mon Jun 9 15:49:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA19106 for freebsd-scsi-outgoing; Mon, 9 Jun 1997 15:49:03 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA19096 for ; Mon, 9 Jun 1997 15:48:58 -0700 (PDT) Received: from huset.fm.unit.no (huset.fm.unit.no [129.241.211.212]) by agora.rdrop.com (8.8.5/8.8.5) with SMTP id PAA19284 for ; Mon, 9 Jun 1997 15:48:25 -0700 (PDT) Message-Id: <199706092248.PAA19284@agora.rdrop.com> Received: (qmail 22226 invoked from network); 9 Jun 1997 22:40:45 -0000 Received: from huset.fm.unit.no (HELO stud.math.ntnu.no) (129.241.211.212) by huset.fm.unit.no with SMTP; 9 Jun 1997 22:40:45 -0000 To: Tor.Egge@idi.ntnu.no Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: scsi recovery code causes system freeze In-Reply-To: Your message of "Mon, 09 Jun 1997 21:16:39 +0200" References: <199706091916.VAA16067@pat.idi.ntnu.no> X-Mailer: Mew version 1.06 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Date: Tue, 10 Jun 1997 00:40:44 +0200 From: Arne Henrik Juul Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id PAA19102 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk *jeg* har ihvertfall problemer med å skjønne hva denne: > Index: aic7xxx.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/scsi/aic7xxx.c,v > retrieving revision 1.118 > diff -u -r1.118 aic7xxx.c > --- aic7xxx.c 1997/04/26 05:03:18 1.118 > +++ aic7xxx.c 1997/05/29 16:31:23 > @@ -1906,7 +1906,7 @@ > if (ahc->scb_data->maxhscbs >= 16 > || (ahc->flags & AHC_PAGESCBS)) { > /* Default to 8 tags */ > - xs->sc_link->opennings += 6; > + xs->sc_link->opennings += 2; > } else { > /* > * Default to 4 tags on whimpy har å gjøre med problemet ditt. Er det en patch som fikser noe, eller er den med bare for å beskrive konfigurasjonen du kjører med? -arnej From owner-freebsd-scsi Tue Jun 10 12:56:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA28166 for freebsd-scsi-outgoing; Tue, 10 Jun 1997 12:56:53 -0700 (PDT) Received: from dragon.cmnsens.zoom.com (mail-relay.cmnsens.zoom.com [207.33.155.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA28159 for ; Tue, 10 Jun 1997 12:56:50 -0700 (PDT) Received: from cmnsens (cmnsens.cmnsens.zoom.com [207.33.155.2]) by dragon.cmnsens.zoom.com (8.8.5/8.8.5) with SMTP id MAA03316 for ; Tue, 10 Jun 1997 12:56:51 -0700 (PDT) Message-Id: <199706101956.MAA03316@dragon.cmnsens.zoom.com> From: "Mike Burgett" To: "scsi@freebsd.org" Date: Tue, 10 Jun 97 12:56:48 -0700 Reply-To: "Mike Burgett" Priority: Normal X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: twisted pair "flat" cable, vs teflon cable... Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been observing the scsi cable info flying around the list, and since I'm having some problems I believe are related to a fully loaded cable, I've been looking for a replacement. I've not found a local supplier of the 'flat' twisted cable, but I have found someone that wants to sell me teflon flat cable, claiming it's noise/crosstalk rejection is as good as, or superior to twisted pair... Anyone know if this is gospel, or sales smoke-and-mirrors? Thanks, Mike From owner-freebsd-scsi Wed Jun 11 11:07:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA07599 for freebsd-scsi-outgoing; Wed, 11 Jun 1997 11:07:53 -0700 (PDT) Received: from niagara.dataphone.net (niagara.se.dataphone.net [194.23.94.254]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA07585 for ; Wed, 11 Jun 1997 11:07:47 -0700 (PDT) Received: by niagara.se.dataphone.net with Internet Mail Service (5.0.1457.3) id ; Wed, 11 Jun 1997 20:08:33 +0200 Message-ID: <71859F034878D011AB8500A024E7C93C11BC@niagara.se.dataphone.net> From: Mikael Hugo To: "'freebsd-scsi@freebsd.org'" Subject: URGENT - SCSI bad sector Date: Wed, 11 Jun 1997 20:08:28 +0200 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I get the following: CANNOT READ: BLK 3801152 CONTINUE? [yn] I have put the auto bad block handeler on afterwards (was off). Still no luck, and I cant find any utility that helps in any way. It is the home dir of 50 users (all g******), so its a _bit_ urgent. Regards Mikael Hugo From owner-freebsd-scsi Wed Jun 11 17:40:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA26046 for freebsd-scsi-outgoing; Wed, 11 Jun 1997 17:40:59 -0700 (PDT) Received: from mail.webspan.net (root@mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA26041 for ; Wed, 11 Jun 1997 17:40:57 -0700 (PDT) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970608) with ESMTP id UAA23390; Wed, 11 Jun 1997 20:40:55 -0400 (EDT) Received: from orion.webspan.net (localhost [127.0.0.1]) by orion.webspan.net (WEBSPAN/970608) with ESMTP id UAA28692; Wed, 11 Jun 1997 20:40:51 -0400 (EDT) To: Mikael Hugo cc: "'freebsd-scsi@freebsd.org'" From: "Gary Palmer" Subject: Re: URGENT - SCSI bad sector In-reply-to: Your message of "Wed, 11 Jun 1997 20:08:28 +0200." <71859F034878D011AB8500A024E7C93C11BC@niagara.se.dataphone.net> Date: Wed, 11 Jun 1997 20:40:51 -0400 Message-ID: <28690.866076051@orion.webspan.net> Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mikael Hugo wrote in message ID <71859F034878D011AB8500A024E7C93C11BC@niagara.se.dataphone.net>: > > I get the following: > > CANNOT READ: BLK 3801152 > CONTINUE? [yn] > > I have put the auto bad block handeler on afterwards (was off). > > Still no luck, and I cant find any utility that helps in any way. > > It is the home dir of 50 users (all g******), so its a _bit_ urgent. If you have an Adaptec controller, go into the BIOS and do a verify. It can forcibly remap bad blocks on SCSI disks. I do not know about other controllers. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-scsi Fri Jun 13 10:48:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA09620 for freebsd-scsi-outgoing; Fri, 13 Jun 1997 10:48:12 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA09602 for ; Fri, 13 Jun 1997 10:47:59 -0700 (PDT) Received: (qmail 17417 invoked by uid 1000); 13 Jun 1997 17:47:32 -0000 Resent-Message-ID: <19970613174732.17416.qmail@sendero-ppp.i-connect.net> Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Resent-Date: Wed, 04 Jun 1997 22:40:01 -0700 (PDT) Resent-From: Simon Shapiro Resent-To: "Justin T. Gibbs" Date: Fri, 13 Jun 1997 10:47:32 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: FreeBSD-hackers@FreeBSD.ORG, FreeBSD-SCSI@FreeBSD.ORG Subject: Announcement: New DPT RAID Controller Driver Available Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Everyone! [ I am NOT an employee of Distributed Processing Technology. I do not represent DPT, not do i represent Atlas Telecom, my employer; I do it all by myself... ] DPT manufactures RAID controllers for PC's. These controllers allow you to create and manage RAID-{0,1,5} arrays and accomplish very high speed and reliability in disk storage. Up to 64MB of ECC cache can be installed on a controller and up to 3 SCSI busses attached. I have recently completed a FreeBSD driver for these controllers and made it publicly available to FreeBSD users. The driver supports the PM3334{U,W,D} which is a PCI controller sporting a 68030 processor, up to 3 SCSI ultra-wide-differential busses. It is also available (I think) as narrow, non-ultra and definitely single-ended. The driver was tested thoroughly only with the above controller but should also work with lower-end PCI cards. It will NOT work with non-PCI DPT Host Bus Adapters, nor do I have plans to add this support. The driver is still, in some ways, work in progress: The character I/O (to allow you to ``talk'' to the controller) is stable but not functional. So is support for in-driver RAID. The character I/O will allow you to run RAID configuration and management by opening /dev/dpt{0-n} and performing IOCTL, READ, and WRITE to the controller. These controls will allow you to monitor power supplies in the disk bay, fans, temperature, etc. It will also alow you to monitor disk I/O statistics, error logs, and performance statistics. In addition, you can destroy, build, and repair RAID arrays, with the system running. Interfaces will include a library, SNMP MIB, X based interface and some command line interfaces. The interface also allows you to dynamically configure hot spares (devices that will automatically go on-line when another device fails). The in-driver RAID allows you to build RAID arrays that span HBAs. This interface is O/S independent, so, you can have a boot device that will boot NT, Win95, Dos, FreeBSD, Linux, Unixware, Netware, etc. from a RAID array that spans disks. Extensive testing was done on the driver to assure high reliability. Highly qualified help was enlisted in reviewing and debugging the code. Having said that, the code only runs on 7-8 test machines and 2-3 workstations. It should be considered ALPHA and no mission critical data should be put on it, before YOU are satisfied with the product. The driver is available, now from sendero-ppp.i-connect.net and from ftp-i.connect.net, in the /crash directory. All this wonderful stuff is O/S independent, and RAID arrays, hot spares and normal devices all appear as standard disks to the O/S. The large cache can increase performance, on busy systems, dramatically, while reducing system load incredibly. The driver was tested with DPT firmware 07H and 07L. DPT provides (what amounts to) lifetime of free support and firmware upgrades. Firmware can be FLASH'ed in from the ftp.dpt.com server. Later versions of the driver will allow flash rom updates from Unix. I would like you to help me in posting an announcement on the proper FreeBSD lists and in checking it in. All the work was done against RELENG_2_2, and the patch provided was made, today, against a pristine source tree. For your convenience, I am also providing the latest DPT firmware and DOS utility to manage the controller, until the Unix interfaces are done. Testing was done on several industrial PC's. Either Pentium-100 or PentiumPro-200. The systems had 54-128MB of RAM and 1-2 controllers each. There were a minimum of 6 disks per SCSI channel per controller and all possible combinations of devices and configurations tried. Testing was assisted by few simple utilities: blob.c: Creates a unique barber pole, exactly 16MB in length and neatly slicable to sectors. st.c: performs random seek tests on a given file/device. nasty: A nasty little shell script to spawn 256 sessions of dd (or st) and try to see what breaks - Nothing. Tunable Parameters: As this is still an evolving driver, there are (too many) tunable parameters. the following are of interest: DPT_COMMAND_SPLHIGH: Forces the actual submitting of a command to the DPT to run at very high priority. Can/should be OFF. DPT_OPENNINGS: How many concurrent SCSI commands to send to a given device. Should be positive integer. Currently less than 64. The driver will bump this number up for devices that are very busy. It has nothing to do with linked/queued commands, as the DPT does linking automagically. Leave at 2, nice number. DPT_VERIFY_HINTR: Certain noisy motherboards generate bogus data on the PCI bus. If you get mysterious crashes, enable this option and tell me what you see on the console. Leave OFF unless you are seeing crashes you cannot explain. DPT_RESTRICTED_FREELIST: Under normal conditions, the driver will queue as many requests as the O/S submits. With this option ON, the driver will restrict itself to no more requests than the DPT can accept (normal firmware == 64). Leave OFF for normal operation. DPT_TRACK_CCB_STATES: When enabled will track, in details, the queue management. Only meaningful when combined with VERIFY_HINTR. Leave OFF. DPT_MEASURE_PERFORMANCE: Enables certain internal metrics. There is currently no clean way to extract these. Leave OFF for slightly better performance. DPT_USE_SINTR: The driver can work either in a traditional manner (as far as command submittal is concerned), or use Software interrupts for queue management. Leaving it OFF will give slightly better performance at low loads while dramatically slow things down at high loads. Running the ``nasty'' script, OFF will give you Load average of 110-120 at peak load. Turning it ON will take LA to 5-9. Yup. No typo here. Disk subsystem performance will stay very close, though. DPT_FREELIST_IS_STACK: If ON, more optimal use of the processor's cache will be realized, at a cost of slightly increased chance of cache overruns. Try both ways and tell me. Performance: With DPT_USE_SINTR off, we get about 3.5-4MB/Sec on single disks and about 15-18 on RAID-0 arrays. As Expected, RAID-1 performance is in the 10MB/Sec, and RAID-5 is about 15 READ and 5-7 WRITE. There is still excessive instrumentation and monitoring code in the driver. When complete, much of this will go away. System Load: It is interesting to learn that with DPT_USE_SINTR off, the dd test reaches LA of about 110-120 with 64 dd's. With DPT_USE_SINTR on, the load goes down to about 5-9. If this was a FreeBSD vs. Linux or FreeBSD vs. NT I would have left this statement alone at this point :-)) The reality is that the system's real load is almost identical. The difference probably comes from how LA is computed and interacting with the I/O queues. System responsiveness was excellent in all cases. Support: The DPT driver is an integral part of my employer's strategic product for the next few years. As the architect for that product, I can assure you it will be supported. Even in the unlikely event that my employer will not have vested interest in this driver, I will personally continue to support it. Thanx: In no particular order: Mike Neuffer: For helping so much with the early low-level wire twitching code and for deciphering, in realtime the documentation. Fragments of his Linux driver should still be scattered throughout the driver. Justin Gibbs: For lots of patience, knowledge of FreeBSD SCSI, excellent aic7xxx driver, form which I stole code shamelessly and many hours of debugging. Dan Eischen: For the hours spent hunting bugs, common sense and friendly help. Mark Salyzyn: For explaining, again and again, how a DPT card works and for critical debugging. The Atlas Telecom PrePay Team for listening and patiently waiting for me to get back to the keyboard and finish this code. I can be reached at my indicated e-mail address, or at 503.799.2313. Simon