From owner-freebsd-scsi Sun May 31 07:30:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA28196 for freebsd-scsi-outgoing; Sun, 31 May 1998 07:30:54 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns1.dpt.com (root@ns1.dpt.com [206.138.241.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA28041 for ; Sun, 31 May 1998 07:29:19 -0700 (PDT) (envelope-from mark@bohica.net) Received: from deathstar.deathstar.dpt.com (salyzyn-mark.dpt.com [198.242.63.87]) by ns1.dpt.com (8.8.7/8.8.7) with SMTP id KAA18923; Sun, 31 May 1998 10:32:04 -0400 Received: by deathstar.deathstar.dpt.com [198.242.63.87] (NX5.67g/NX3.0M) id AA11443; Sun, 31 May 98 10:28:06 -0400 Reply-To: Mark Gregory Salyzyn Message-Id: <9805311428.AA11443@deathstar.deathstar.dpt.com> Mime-Version: 1.0 (NeXT Mail 4.2mach v148) Content-Type: multipart/alternative; boundary=NeXT-Mail-2114881306-1 Content-Transfer-Encoding: 7bit Received: by NeXT.Mailer (1.148) From: Mark Gregory Salyzyn Date: Sun, 31 May 98 10:28:02 -0400 To: freebsd-scsi@FreeBSD.ORG, shimon@simon-shapiro.org, tcobb@staff.circle.net Subject: Re: DPT Redux Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --NeXT-Mail-2114881306-1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Trou Cobb writes: > With RAID-5 and a new drive to rebuild on, the DPT hardware begins automatic rebuilds of the > array. However, in these conditions the DPT driver (or other FreeBSD component) does not > correctly sense the size information and panics the kernel during bootup. This symptom goes > away after the rebuild is complete. This symptom does not appear when in DOS under the > same circumstances. DOS DPTmgr checks show the array of the correct size. BIOS bootup > screen for DPT shows the array of the correct size. There is not supposed to be any difference to the command access to the DPT controller whether optimal, degraded or rebuilding. However, the following realities exist: 1) The Logical Array Status page will indicate the appropriate status of the array and it's components. This goes without saying, and has no operational affects. 2) Accesses to a degraded or rebuilding array are significantly slower. 3) A controller performing a rebuild uses some of the available CCBs to perform it's duties, *possibly* exausting the available CCBs I believe that Simon's driver works under condition 2, simply because the driver functions under the stress of a degraded array. Rebuilding, if the user has selected a particularily aggressive scheduling, is more extreme and may cause timeouts. However, ReadCapacity calls will not fail as they are not delayed. I believe a failed ReadCapacity SCSI command is the reason for the problem. Condition 3, I believe, is the more likely cause, and is a direct result of the number of components within the array and a possible driver assumption that 64 CCBs are always available for commands under this condition. Externally, the DPT controller fibs, and indicates that there are 64 concurrent CCBs available. Internally, the controller has 128 CCBs available to process commands. This is to allow the single access commands to be spread into several internal SCSI device commands to the components of the array. This is also to buffer a rebuild which utilizes these (possibly scarce) CCB resources. Lacking some theory, I'd say these CCBs are being used up by the combination of an aggressive rebuild, low amount of controller board cache and concurrent RAID operations. The driver is affected by the above because it is apparently denied issuing a CCB because the board is `busy' for far too long a period. I suggest the following: 1) Troy Cobb, please adjust the various rebuild parameters to support a considerably less aggresive RAID rebuild. Yes, it will take longer, but then your seven drive RAID array will not be exhausting the CCB resources of the controller preventing the lockup of the system as it waits for the controller to no longer be busy. An aggresive schedule (defaults may be inappropriate for a seven drive RAID-5) may even lock up all accesses to the controller, which is not the case since Storage Managers single-command-at-a-time-I- can-wait-forever-to-get-a-command-to-the-controller approach to things appears to work. I do not have dptmgr handy to indicate the exact parameters you need to adjust, but I believe they are associated with the drive cache parameters as well. I question the rapid number of drive failures you have experienced, is there a possibility that your SCSI bus is *now* having troubles and is affecting the appropriate operation of the rebuild, which heavily utilizes the SCSI bus? You may have had incorrect drive termination, and aging of *all* the components may have moved you from working to marginally working? Any untoward kinks or nicks now added to the SCSI cable? Or, maybe the SCSI cable to the 7 drives is a bit too long? DPT recommends using a SCSI backplane with more than 4 drives rather than cables. How much Cache is on the DPT controller board, this affects background (rebuild and parity writeback) accesses to the SCSI devices and may be limiting the performance of the system significantly so as to make the driver and OS's life miserable ... Would you consider dividing the RAID-5 into (I know, capacity robbing) two arrays, or dividing them up amoungst two SCSI busses (three on BUS 0 where you have the RAID-0, and four on BUS1 where you have the hotspare) to help improve the performance by dividing the SCSI activity amoungst the busses? 2) Simon, you may want to consider what happens when the controller is indicating busy, do you perform a timeout on the busy bit of the auxilliary status register, and if you do, what do you show to the OS (failed command? spawn a separate command issue thread to try again later? spin forever waiting for ready?). The BSDi BSD/OS driver, for example, simply `locks' waiting for the controller to get out of busy, which is the simplest approach to deal with, what should be a transitory situation. Also, you may wish to limit the number of outstanding commands to the controller (the UNIXWARE driver uses the lock on wait, and 32 CCB limit to reduce the chances of this problem affecting performance). The highest performance DPT driver in a Networking operating system (NETWARE) does the `spawn an issuing task' approach to allow processing of network card interrupts while waiting for the controller to come free. This may be your best approach considering you will no doubt be issuing `next' commands to the controller while in the context of the controller interrupt service routine. My assumption is that you timeout and send a fail up to the OS, which may explain the 0MB read capacity result shown in the log? I hope this helps -- Sincerely -- Mark Salyzyn --NeXT-Mail-2114881306-1 Content-Type: text/enriched; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Trou Cobb < writes: > With RAID-5 and a new drive to rebuild on, the DPT hardware begins automatic rebuilds of the > array. However, in these conditions the DPT driver (or other FreeBSD component) does not > correctly sense the size information and panics the kernel during bootup. This symptom goes > away after the rebuild is complete. This symptom does not appear when in DOS under the > same circumstances. DOS DPTmgr checks show the array of the correct size. BIOS bootup > screen for DPT shows the array of the correct size. There is not supposed to be any difference to the command access to the DPT controller whether optimal, degraded or rebuilding. However, the following realities exist: 1) The Logical Array Status page will indicate the appropriate status of the array and it's components. This goes without saying, and has no operational = affects. 2) Accesses to a degraded or rebuilding array are significantly slower. 3) A controller performing a rebuild uses some of the available CCBs to perform it's duties, *possibly* exausting the available CCBs I believe that Simon's driver works under condition 2, simply because the driver functions under the stress of a degraded array. Rebuilding, if the user has selected a particularily aggressive scheduling, is more extreme and may cause timeouts. However, ReadCapacity calls will not fail as they are not delayed. I believe a failed ReadCapacity SCSI command is the reason for the problem. Condition 3, I believe, is the more likely cause, and is a direct result of the number of components within the array and a possible driver assumption that 64 CCBs are always available for commands under this condition. Externally, the DPT controller fibs, and indicates that there are 64 concurrent CCBs available. Internally, the controller has 128 CCBs available to process commands. This is to allow the single access commands to be spread into several internal SCSI device commands to the components of the array. This is also to buffer a rebuild which utilizes these (possibly scarce) CCB resources. Lacking some theory, I'd say these CCBs are being used up by the combination of an aggressive rebuild, low amount of controller board cache and concurrent RAID operations. The driver is affected by the above because it is apparently denied issuing a CCB because the board is `busy' for far too long a period. I suggest the following: 1) Troy Cobb, please adjust the various rebuild parameters to support a considerably less aggresive RAID rebuild. Yes, it will take = longer, but then your seven drive RAID array will not be exhausting the CCB resources of the controller preventing the lockup of the system as it waits for the controller to no longer be busy. An aggresive schedule (defaults may be inappropriate for a seven drive RAID-5) may even lock up all accesses to the controller, which is not the case since Storage Managers single-command-at-a-time-I- can-wait-forever-to-get-a-command-to-the-controller approach to things appears to work. I do not have dptmgr handy to indicate the exact parameters you need to adjust, but I believe they are associated with the drive cache parameters as well. I question the rapid number of drive failures you have experienced, is there a possibility that your SCSI bus is *now* having troubles and is affecting the appropriate operation of the rebuild, which heavily utilizes the SCSI bus? You may have had incorrect drive termination, and aging of *all* the components may have moved you from working to marginally working? Any untoward kinks or nicks now added to the SCSI cable? Or, maybe the SCSI cable to the 7 drives is a bit too long? DPT recommends using a SCSI backplane with more than 4 drives rather than cables. How much Cache is on the DPT controller board, this affects background (rebuild and parity writeback) accesses to the SCSI devices and may be limiting the performance of the system significantly so as to make the driver and OS's life miserable ... Would you consider dividing the RAID-5 into (I know, capacity robbing) two arrays, or dividing them up amoungst two SCSI busses (three on BUS 0 where you have the RAID-0, and four on BUS1 where you have the hotspare) to help improve the performance by dividing the SCSI activity amoungst the busses? 2) Simon, you may want to consider what happens when the controller is indicating busy, do you perform a timeout on the busy bit of the auxilliary status register, and if you do, what do you show to the OS (failed command? spawn a separate command issue thread to try again later? spin forever waiting for ready?). The BSDi BSD/OS driver, for example, simply `locks' waiting for the controller to get out of busy, which is the simplest approach to deal with, what should be a transitory situation. Also, you may wish to limit the number of outstanding commands to the controller (the UNIXWARE driver uses the lock on wait, and 32 CCB limit to reduce the chances of this problem affecting performance). The highest performance DPT driver in a Networking operating system (NETWARE) does the `spawn an issuing task' approach to allow processing of network card interrupts while waiting for the controller to come free. This may be your best approach considering you will no doubt be issuing `next' commands to the controller while in the context of the controller interrupt service routine. My assumption is that you timeout and send a fail up to the OS, which may explain the 0MB read capacity result shown in the log? I hope this helps -- Sincerely -- Mark Salyzyn --NeXT-Mail-2114881306-1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 31 08:10:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA02530 for freebsd-scsi-outgoing; Sun, 31 May 1998 08:10:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dragon.awen.com (dragon.awen.com [207.33.155.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA02525 for ; Sun, 31 May 1998 08:10:17 -0700 (PDT) (envelope-from mburgett@dragon.awen.com) Received: (from mburgett@localhost) by dragon.awen.com (8.8.8/8.8.7) id IAA06108; Sun, 31 May 1998 08:10:17 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 31 May 1998 08:09:26 -0700 (PDT) Reply-To: Mike Burgett From: Mike Burgett To: freebsd-scsi@FreeBSD.ORG Subject: wide scsi woes... Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm trying to bring up a new machine, and having a world of grief. I really don't think this is a freebsd problem, but hope maybe someone here has dealt with this before. The only system on the machine is freebsd, so I can't testing with other systems would be problematic. I hope this is the right place to ask these questions... I've been bringing up a new machine, p6 with an adaptec 2940uw controller, with two drives on it. drive 0 is an IBM DCAS 32160W, drive 1 is a DCAS 34330. I'm using the cable that came with the controller currently, but I have tried another cable. I get the same error, running 2.2.6-RELEASE or the 980523-SNAP of current (generic and custom kernels on both), but I'm mainly been working with current, since that's what I intend to run on this machine, and more importantly right now, current recovers from the error without a hard reset. :) First, here's my probes: Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-980523-SNAP #0: Sat May 23 10:51:06 GMT 1998 root@make.ican.net:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz cost 3329 ns Timecounter "TSC" frequency 199432992 Hz cost 216 ns CPU: Pentium Pro (199.43-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x617 Stepping=7 Features=0xfbff real memory = 134217728 (131072K bytes) avail memory = 127688704 (124696K bytes) Probing for devices on PCI bus 0: Correcting Natoma config for non-SMP chip0: rev 0x02 on pci0.0.0 chip1: rev 0x01 on pci0.1.0 ide_pci0: rev 0x00 on pci0.1.1 vga0: rev 0x01 int a irq 0 on pci0.9.0 ncr0: rev 0x12 int a irq 9 on pci0.10.0 ncr0: waiting for scsi devices to settle scbus0 at ncr0 bus 0 st0 at scbus0 target 5 lun 0 st0: type 1 removable SCSI 2 st0: Sequential-Access st0: 10.0 MB/s (100 ns, offset 8) density code 0x13, variable blocks, write-enabled cd0 at scbus0 target 6 lun 0 cd0: type 5 removable SCSI 2 cd0: CD-ROM cd0: asynchronous. can't get the size fxp0: rev 0x04 int a irq 10 on pci0.11.0 fxp0: Ethernet address 00:a0:c9:b7:e3:87 ahc0: rev 0x01 int a irq 11 on pci0.12.0 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs ahc0: waiting for scsi devices to settle scbus1 at ahc0 bus 0 sd0 at scbus1 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 2063MB (4226725 512 byte sectors) Sending SDTR!! sd1 at scbus1 target 1 lun 0 sd1: type 0 fixed SCSI 2 sd1: Direct-Access 4134MB (8467200 512 byte sectors) [isa probing deleted .... ] Then, after logging in, I can generate the below error at will, running something like bonnie, or a large make (world, buildworld) sd1: SCB 0x1 - timed out in dataout phase, SCSISIGI == 0xe6 SEQADDR = 0x129 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 sd1: abort message in message buffer sd1: SCB 0x0 timedout while recovery in progress sd0: SCB 0x2 timedout while recovery in progress sd1: SCB 0x1 - timed out in dataout phase, SCSISIGI == 0xf6 SEQADDR = 0x129 SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x13 sd1: no longer in timeout ahc0: Issued Channel A Bus Reset. 4 SCBs aborted sd1: SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x15f SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 sd1: Queueing an Abort SCB sd1: SCB 0x1 timedout while recovery in progress sd0: SCB 0x2 timedout while recovery in progress sd0: SCB 0x3 timedout while recovery in progress sd1: SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 SEQADDR = 0x15f SCSISEQ = 0x12 SSTAT0 = 0x2 SSTAT1 = 0x0 sd1: no longer in timeout ahc0: Issued Channel A Bus Reset. 4 SCBs aborted sd0: UNIT ATTENTION asc:29,0 sd0: Power on, reset, or bus device reset occurred , retries:2 Sending SDTR!! The last line is related to how I have drive 1 jumpered currently, so that it doesn't generate unit attention, and initiates wide negeotiation after a reset. I've tried it without those jumpers as well, and the errors still occur. What I've tried: Different cables. Both drives as the end of the chain with termination enabled. Unit Atten on POR disabled Initiate Sync/Wide negeotiation on reset enabled. Manually setting HBA termination to 'ON/ON' as per manual. (HBA Bios setup) (there is nothing hooked to the external, or internal 50 pin connectors) Limiting speed to 10Mhz (HBA Bios setup) Different kernels (2.2.6-Rel, 980523-SNAP) generic and custom. This is a first experience for me on several fronts: Freebsd/2940 combination Ultra-wide scsi with any OS Freebsd/P6 combination I'm seeing this error on both drives, (both new) so I don't think it's a problem with the drives themselves. It 'feels' like a termination problem, though I've tried each of the drives in the last position with termination enabled. I suppose it could be a HBA problem, but it's also new, and this seems like an odd failure mode. Any suggestions would be helpful, I'm kind of at the end of my interrupt chain here. Thanks, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 31 12:21:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA02977 for freebsd-scsi-outgoing; Sun, 31 May 1998 12:21:32 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from base486.home.org (imdave@imdave.pr.mcs.net [205.164.3.77]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA02928; Sun, 31 May 1998 12:21:24 -0700 (PDT) (envelope-from imdave@mcs.net) Received: (from imdave@localhost) by base486.home.org (8.8.8/8.8.8) id OAA02146; Sun, 31 May 1998 14:21:06 -0500 (CDT) Date: Sun, 31 May 1998 14:21:06 -0500 (CDT) From: Dave Bodenstab Message-Id: <199805311921.OAA02146@base486.home.org> To: dufault@hda.com, freebsd-scsi@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG, skynyrd@opus.cts.cwu.edu Subject: Re: Micropolis 4345WS (Toshiba "Equium" 6200M) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I received a couple of those Toshiba computers which Insight had the > special on (intel dual p6 mb, integrated pro100 ethernet, aha-7880, etc.) > The 12x atapi cd-room boots our freebsd CD's so quickly that you forget > that you're booting from a CD. Really nice systems, but mine came with > Micropolis 4345WS drives at firmware revision zC19. The manufacture date > of my systems was around 4/97. I took the plunge and got two of these boxes. I am very interested in sharing experiences amoung other FreeBSD folks using these machines. I plan to take the CPU, memory, disk and cdrom from the second machine and install them in the first. I'm hoping to sell the remaining MB and case to recoup some of the cost. > Unfortunately I couldn't get any version of FreeBSD to install without the > aha driver complaining about the drive timing out, and aborting the > install. No matter what the settings on the 7880 (disable wide > negotiation, throttle down xfer rate, etc) and after verifying drive > jumpers, termination. As soon as sysinstall started doing anything disk > intensive, the drives would lose it. I had both systems side by side with > a pile of FreeBSD CD's and each behaved the same whether it was 2.2.2, > 10/6/97 3.0-snap, 2/2/98 3.0-snap, etc. I booted the 2.2.5 floppy, and it came up fine -- I have not yet blown away NT and attempted an install. > I did some searching around the net and learned that Micropolis has been > history for a while. Fortunately firmware kit X502_4.exe is available > from an ftp server in germany. I built an ASPI floppy (adaptec now gives > away their dos/aspi drivers at their www page) and was able to upgrade the > drive firmware. As soon as the firmware was upgraded all problems ceased. > I haven't really thrashed the drive yet and cranked back up the xfer rate > (& wide negotiation) so we'll see how the drive works under real load. I found the reference: http://www.addit.de/SUPPORT/micr-eproms.htm but the site seems to be down (Sun, 5/31) Any chance you could send it to me? > Since other people have been buying these systems, I'm a little surprised > that I'm the only person so far to have reported the problem. Fortunately > it appears that there is a workaround (forget about any 5-year warranty on > the tomahawk drives though :( I called Toshiba before the purchase and they told me that they would be honoring the warrenty for the drives -- perhaps only for the 3-year Toshiba warrenty tho. I also found that Toshiba does not have email access to their technical support -- only via compuserve. I'll have to wait until tomorrow to give them a call... but I'll ask here also: - what are USB ports and what can I use them for? - any hints/cautions/etc. about removing and reinstalling the CPU? - what version of FreeBSD current/smp do I need to start downloading? - the user's guide implies that only 128M memory modules are supported for DIMM sockets 1-3, but a page on their web site implied that each socket would accept 16/32/64/128M dimms. I intended to take the 32M from the second machine and install it in the first. - I want to enable the 2nd UART port and wire a cable, but the user's guide doesn't have a description of the pinout. Hopefully Toshiba will supply this on Mon. Also, what list would be appropriate for this subject? -questions or -smp. I suspect that -scsi isn't really applicable anymore. Dave Bodenstab imdave@mcs.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 31 12:40:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA06741 for freebsd-scsi-outgoing; Sun, 31 May 1998 12:40:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dragon.awen.com (dragon.awen.com [207.33.155.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06736 for ; Sun, 31 May 1998 12:40:13 -0700 (PDT) (envelope-from mburgett@dragon.awen.com) Received: (from mburgett@localhost) by dragon.awen.com (8.8.8/8.8.7) id MAA00886; Sun, 31 May 1998 12:40:12 -0700 (PDT) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sun, 31 May 1998 12:39:20 -0700 (PDT) Reply-To: Mike Burgett From: Mike Burgett To: freebsd-scsi@FreeBSD.ORG Subject: wide scsi woes...more info Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmmmm. If I disable negeotiation of disconnect in the 2940uw bios, eveything seems to work fine. (Perhaps it's obvious from the error that it would, but I'm not that familiar with scsi errors...) Am I missing some kind of quirk for these ibm dcas drives, or is there something I could tweak to allow them more time to reconnect (or are they failing to reconnect at all??) Disabling disconnect, while fine as a workaround, doesn't seem to be a permanent answer... Thanks, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 31 13:40:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16702 for freebsd-scsi-outgoing; Sun, 31 May 1998 13:40:43 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles208.castles.com [208.214.165.208]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA16650; Sun, 31 May 1998 13:40:36 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA12957; Sun, 31 May 1998 12:36:06 -0700 (PDT) Message-Id: <199805311936.MAA12957@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Dave Bodenstab cc: dufault@hda.com, freebsd-scsi@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG, skynyrd@opus.cts.cwu.edu Subject: Re: Micropolis 4345WS (Toshiba "Equium" 6200M) In-reply-to: Your message of "Sun, 31 May 1998 14:21:06 CDT." <199805311921.OAA02146@base486.home.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 May 1998 12:36:05 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > I received a couple of those Toshiba computers which Insight had the > > special on (intel dual p6 mb, integrated pro100 ethernet, aha-7880, etc.) > > The 12x atapi cd-room boots our freebsd CD's so quickly that you forget > > that you're booting from a CD. Really nice systems, but mine came with > > Micropolis 4345WS drives at firmware revision zC19. The manufacture date > > of my systems was around 4/97. > > I took the plunge and got two of these boxes. I am very interested in > sharing experiences amoung other FreeBSD folks using these machines. > I plan to take the CPU, memory, disk and cdrom from the second machine > and install them in the first. I'm hoping to sell the remaining MB and > case to recoup some of the cost. We bought several of these for the FreeBSD Project as well; one is off making ELF happen faster, and another will be keeping the -stable packages up to date for Satoshi. (We have other plans for it too, suffice to say that it will be busy 8). All of these came with the same configuration (including the disk and firmware). > > Unfortunately I couldn't get any version of FreeBSD to install without the > > aha driver complaining about the drive timing out, and aborting the > > install. No matter what the settings on the 7880 (disable wide > > negotiation, throttle down xfer rate, etc) and after verifying drive > > jumpers, termination. As soon as sysinstall started doing anything disk > > intensive, the drives would lose it. I had both systems side by side with > > a pile of FreeBSD CD's and each behaved the same whether it was 2.2.2, > > 10/6/97 3.0-snap, 2/2/98 3.0-snap, etc. This is interesting, insofar as I've installed on three of these systems, 2.2 and 3.0, built kernels, built the world, and I expect that Satoshi has been package-building too. None of them exhibit these symptoms (and I wound the Adaptec options right up). > > Since other people have been buying these systems, I'm a little surprised > > that I'm the only person so far to have reported the problem. Fortunately > > it appears that there is a workaround (forget about any 5-year warranty on > > the tomahawk drives though :( > > I called Toshiba before the purchase and they told me that they would be > honoring the warrenty for the drives -- perhaps only for the 3-year Toshiba > warrenty tho. This is extremely good to know - thanks! > them a call... but I'll ask here also: > > - what are USB ports and what can I use them for? USB is the "universal serial bus". Right now, you can't use it for much, although in the next 12-18 months you can expect to be plugging your keyboard, mouse, speakers, modem, scanner, etc. into it. > - any hints/cautions/etc. about removing and reinstalling the CPU? Don't do it unless you have to. You will need a VRM module before you can put the second CPU into the first system. > - what version of FreeBSD current/smp do I need to start downloading? Go for the lastest -SNAP once you've got the hardware in place. > - I want to enable the 2nd UART port and wire a cable, but the user's > guide doesn't have a description of the pinout. Hopefully Toshiba > will supply this on Mon. IICR the motherboard is the Intel Providence board. I do believe that Intel have full documentation on their site (it's likely to be the same pinout as their other boards). > Also, what list would be appropriate for this subject? -questions or -smp. > I suspect that -scsi isn't really applicable anymore. Probably -hardware for the hardware, -smp for SMP related issues. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 31 13:45:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA17970 for freebsd-scsi-outgoing; Sun, 31 May 1998 13:45:54 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles208.castles.com [208.214.165.208]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17514; Sun, 31 May 1998 13:44:13 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id MAA12982; Sun, 31 May 1998 12:39:29 -0700 (PDT) Message-Id: <199805311939.MAA12982@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: tcobb cc: "'Mike Smith'" , "'shimon@simon-shapiro.org'" , "freebsd-scsi@freebsd.org" , "freebsd-current@freebsd.org" Subject: Re: DPT Redux In-reply-to: Your message of "Sun, 31 May 1998 00:26:07 EDT." <509A2986E5C5D111B7DD0060082F32A402FAF6@freya.circle.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 31 May 1998 12:39:29 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > -----Original Message----- > > From: Mike Smith [mailto:mike@smith.net.au] > > > I shutdown and rebooted machine (SYNC failed on shutdown) > > > Allowed FreeBSD to boot, it returned the following for sd1 > > > sd1: type 0 fixed SCSI 2 > > > sd1: Direct-Access 0MB (1 512 byte sectors) > > > > > > Then, system continued booting and finally panic'd with a > > "Page Fault in > > > Supervisor Mode" error prior to mounting drives. > > > > Did you happen to write down the details from this message? In > > conjunction with your kernel image, these are required in order to > > determine what happened. > > This is the one thing I neglected to do, unfortunately - I just got the > error name, not the rest of the info. The situation was a surprise and > had become an emergency at the point it was clear that FreeBSD wasn't > going to reboot. Grr. This makes identifying the culprit extremely difficult. 8( > > It's possible that something doesn't like being asked to boot from a > > zero-sized disk. It's also possible that something else later got > > upset - it's not clear where in the chain of events the panic > > occurred > > (see above). > > Actually, it wasn't booting from the "zero-sized" disk. From my earlier > email, I noted that I have two arrays configured, the first sd0, is the > boot disk and RAID-1 and contains all relevant system directories, the > second sd1, is simply an NFS export partition and is RAID-5. It was the > second disk (sd1) which showed the "0 MB/1 sector" problem. Gotcha - I had discarded the reference to the specific disk in question. > > Thanks for the extra info. Are you able to simulate the > > failure by eg. > > disconnecting one of the 'active' drives? If you can't do this on a > > regular basis, I believe we are able to arrange temporary access to a > > similar but idle system where this can be simulate. Simon > > may also be > > able to offer some suggestions inre. possible poor > > interaction between > > the dpt driver and some firmware revisions. > > I'm hoping to be able to create a duplicate array to this one for > testing, also. I'm getting resistance to budgeting additional funds for > DPT/FreeBSD at the moment :( The machine in question is currently (and > still) a live NFS server. I'm working on scheduling some downtime for > it in the next few days get a hotswap drive back in there. I expect > that I'll have to keep it down (1.5hrs) for a complete array rebuild on > the RAID-5 given the interactions I've seen recently. If you can boot while the array is rebuilding and obtain a traceback (and preferably a kernel core dump), this would be *invaluable* in determining the actual problem. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 31 14:45:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA26931 for freebsd-scsi-outgoing; Sun, 31 May 1998 14:45:18 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hub.org (hub.org [209.47.148.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA26921; Sun, 31 May 1998 14:45:12 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by hub.org (8.8.8/8.7.5) with SMTP id RAA06956; Sun, 31 May 1998 17:45:06 -0400 (EDT) Date: Sun, 31 May 1998 17:45:05 -0400 (EDT) From: The Hermit Hacker To: freebsd-current@FreeBSD.ORG cc: freebsd-scsi@FreeBSD.ORG Subject: May29th kernel with May20th CAM drivers: panic? 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'm not going to bother submitting a problem report on this, mainly because I don't even have a core to analyze, but I figured I'd at least put a 'head up' on this, in case this anything to someone... Fatal trap 12: page fault while in kernel mode fault virtual address = 0xefcb5b1c fault code = supervisor read, page not present instruction pointer = 0x8:0xf01a88ad stack pointer = 0x10:0xf6951af4 frame pointer = 0x10:0xf6951b28 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 7011 (innfeed) interrupt mask = net bio kernel: type 12 trap, code=0 Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx db> panic panic: from debugger syncing disks... 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 giving up dumping to dev 20401, offset 262144 dump Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xf01118a6 stack pointer = 0x10:0xf6951710 frame pointer = 0x10:0xf69517cc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 7011 (innfeed) interrupt mask = net tty bio cam kernel: type 12 trap, code=0 Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx db> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 31 15:20:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03388 for freebsd-scsi-outgoing; Sun, 31 May 1998 15:20:28 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA03363; Sun, 31 May 1998 15:20:18 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id QAA04786; Sun, 31 May 1998 16:20:07 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199805312220.QAA04786@panzer.plutotech.com> Subject: Re: May29th kernel with May20th CAM drivers: panic? In-Reply-To: from The Hermit Hacker at "May 31, 98 05:45:05 pm" To: scrappy@hub.org (The Hermit Hacker) Date: Sun, 31 May 1998 16:20:07 -0600 (MDT) Cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The Hermit Hacker wrote... > > Hi... > > I'm not going to bother submitting a problem report on this, > mainly because I don't even have a core to analyze, but I figured I'd at > least put a 'head up' on this, in case this anything to someone... > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xefcb5b1c > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf01a88ad > stack pointer = 0x10:0xf6951af4 > frame pointer = 0x10:0xf6951b28 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 7011 (innfeed) > interrupt mask = net bio > kernel: type 12 trap, code=0 > Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx tulip_txput() is in the DEC 2114x driver. I kinda doubt this really has anything to do with CAM. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 31 15:29:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA05524 for freebsd-scsi-outgoing; Sun, 31 May 1998 15:29:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hub.org (hub.org [209.47.148.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA05497; Sun, 31 May 1998 15:29:34 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by hub.org (8.8.8/8.7.5) with SMTP id SAA12178; Sun, 31 May 1998 18:29:29 -0400 (EDT) Date: Sun, 31 May 1998 18:29:28 -0400 (EDT) From: The Hermit Hacker To: "Kenneth D. Merry" cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: May29th kernel with May20th CAM drivers: panic? In-Reply-To: <199805312220.QAA04786@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 31 May 1998, Kenneth D. Merry wrote: > The Hermit Hacker wrote... > > > > Hi... > > > > I'm not going to bother submitting a problem report on this, > > mainly because I don't even have a core to analyze, but I figured I'd at > > least put a 'head up' on this, in case this anything to someone... > > > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0xefcb5b1c > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xf01a88ad > > stack pointer = 0x10:0xf6951af4 > > frame pointer = 0x10:0xf6951b28 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 7011 (innfeed) > > interrupt mask = net bio > > kernel: type 12 trap, code=0 > > Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx > > > tulip_txput() is in the DEC 2114x driver. Hrmmm...are there any known problems with the 2114x driver? I do see the following periodically: de0: abnormal interrupt: transmit underflow (raising TX threshold to 96|256) de0: abnormal interrupt: transmit underflow (raising TX threshold to 8|512) On: de0: rev 0x22 int a irq 9 on pci0.10.0 de0: 21140A [10-100Mb/s] pass 2.2 de0: address 00:60:67:30:75:ef In 100Mb/s mode... > I kinda doubt this > really has anything to do with CAM. The reason I included the bit about the CAM driver was the second panic, which mentioned 'cam' in the interrupt_mask, whereas the first didn't...:( db> panic panic: from debugger syncing disks... 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 98 giving up dumping to dev 20401, offset 262144 dump Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xf01118a6 stack pointer = 0x10:0xf6951710 frame pointer = 0x10:0xf69517cc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 7011 (innfeed) interrupt mask = net tty bio cam kernel: type 12 trap, code=0 Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx db> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 31 19:09:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA07758 for freebsd-scsi-outgoing; Sun, 31 May 1998 19:09:25 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA07752 for ; Sun, 31 May 1998 19:09:21 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.0/frmug-2.3/nospam) with UUCP id EAA01942 for freebsd-scsi@FreeBSD.ORG; Mon, 1 Jun 1998 04:09:19 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.9.0.Beta4/keltia-2.14/nospam) id BAA08588 for freebsd-scsi@FreeBSD.ORG; Mon, 1 Jun 1998 01:05:16 +0200 (CEST) (envelope-from roberto) Message-ID: <19980601010516.A8583@keltia.freenix.fr> Date: Mon, 1 Jun 1998 01:05:16 +0200 From: Ollivier Robert To: freebsd-scsi@FreeBSD.ORG Subject: Re: wide scsi woes...more info Mail-Followup-To: freebsd-scsi@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.92.3i In-Reply-To: ; from Mike Burgett on Sun, May 31, 1998 at 12:39:20PM -0700 X-Operating-System: FreeBSD 3.0-CURRENT ctm#4311 AMD-K6 MMX @ 225 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Mike Burgett: > Am I missing some kind of quirk for these ibm dcas drives, or is there > something I could tweak to allow them more time to reconnect (or are they > failing to reconnect at all??) Disabling disconnect, while fine as a > workaround, doesn't seem to be a permanent answer... I'm surprised because I have three IBM drives (two DACS and one DORS) and none of them has ever need something special to work. I use a NCR/Symbios 875 based card though... ncr0: rev 0x03 int a irq 9 on pci0.11.0 scbus0 at ncr0 bus 0 sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access sd0: WIDE SCSI (16 bit) enabled sd0: 40.0 MB/s (50 ns, offset 15) 4134MB (8467200 512 byte sectors) sd1 at scbus0 target 1 lun 0 sd1: type 0 fixed SCSI 2 sd1: Direct-Access sd1: WIDE SCSI (16 bit) enabled sd1: 40.0 MB/s (50 ns, offset 15) 4134MB (8467200 512 byte sectors) sd2 at scbus0 target 2 lun 0 sd2: type 0 fixed SCSI 2 sd2: Direct-Access sd2: 20.0 MB/s (50 ns, offset 15) 2063MB (4226725 512 byte sectors) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #60: Fri May 15 21:04:22 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 31 19:25:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA09794 for freebsd-scsi-outgoing; Sun, 31 May 1998 19:25:58 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA09775; Sun, 31 May 1998 19:25:56 -0700 (PDT) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id TAA23977; Sun, 31 May 1998 19:25:25 -0700 (PDT) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA127557924; Sun, 31 May 1998 19:25:24 -0700 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.7.1/8.7.3 TIS 5.0) id TAA08223; Sun, 31 May 1998 19:25:23 -0700 (PDT) Message-Id: <199806010225.TAA08223@mina.sr.hp.com> To: Dave Bodenstab Cc: dufault@hda.com, freebsd-scsi@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG, skynyrd@opus.cts.cwu.edu Subject: Re: Micropolis 4345WS (Toshiba "Equium" 6200M) Reply-To: darrylo@sr.hp.com In-Reply-To: Your message of "Sun, 31 May 1998 14:21:06 CDT." <199805311921.OAA02146@base486.home.org> Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Sun, 31 May 1998 19:25:22 -0700 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dave Bodenstab wrote: > I found the reference: > > http://www.addit.de/SUPPORT/micr-eproms.htm > > but the site seems to be down (Sun, 5/31) Any chance you could send it > to me? How about someone making it available somewhere? I've been trying www.addit.de all weekend, without any luck. This seems to be the only place with Micropolis firmware. > - any hints/cautions/etc. about removing and reinstalling the CPU? Supposedly, the Intel PR440FX motherboard is used. If so, Intel has tons of documentation for this at: http://support.intel.com/support/motherboards/desktop/PR440FX/ Other useful information: * Toshiba has a fair amount (click on the links on the left pane to get to the Equium 6200M info): http://www.csd.toshiba.com/tais/csd/support/techsupport.html * In particular, Toshiba's info on adding a second CPU can be found under the tech support bulletins of the 6200M. * Unfortunately, Toshiba's link doesn't seem to mention some important facts about adding a second processor. See the PR440FX FAQ: http://developer.intel.com/design/motherbd/pr/pr_inst.htm In particular, see: http://developer.intel.com/design/motherbd/pr/pr_inst.htm#1A It appears that a BIOS upgrade may be necessary (one newer than that available from Toshiba). -- Darryl Okahata Internet: darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 31 22:38:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA04577 for freebsd-scsi-outgoing; Sun, 31 May 1998 22:38:06 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA04571; Sun, 31 May 1998 22:38:02 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id WAA09607; Sun, 31 May 1998 22:37:33 -0700 (PDT) Message-Id: <199806010537.WAA09607@implode.root.com> To: The Hermit Hacker cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: May29th kernel with May20th CAM drivers: panic? In-reply-to: Your message of "Sun, 31 May 1998 17:45:05 EDT." From: David Greenman Reply-To: dg@root.com Date: Sun, 31 May 1998 22:37:32 -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm not going to bother submitting a problem report on this, >mainly because I don't even have a core to analyze, but I figured I'd at >least put a 'head up' on this, in case this anything to someone... > > >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0xefcb5b1c >fault code = supervisor read, page not present >instruction pointer = 0x8:0xf01a88ad >stack pointer = 0x10:0xf6951af4 >frame pointer = 0x10:0xf6951b28 >code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 >processor eflags = interrupt enabled, resume, IOPL = 0 >current process = 7011 (innfeed) >interrupt mask = net bio >kernel: type 12 trap, code=0 >Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx It appears that the mbuf chain is getting corrupted somehow. The above trap info indicates that the m_data pointer is bogus, resulting in a panic when the system attempts to get the physical address from the page tables. I don't see anything obvious in the 'de' driver that could cause this, so I suspect the buffer corruption is external to the driver. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 31 23:25:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA09387 for freebsd-scsi-outgoing; Sun, 31 May 1998 23:25:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA09382; Sun, 31 May 1998 23:25:12 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id QAA13930; Mon, 1 Jun 1998 16:24:47 +1000 Date: Mon, 1 Jun 1998 16:24:47 +1000 From: Bruce Evans Message-Id: <199806010624.QAA13930@godzilla.zeta.org.au> To: dg@root.com, scrappy@hub.org Subject: Re: May29th kernel with May20th CAM drivers: panic? Cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > It appears that the mbuf chain is getting corrupted somehow. The above >trap info indicates that the m_data pointer is bogus, resulting in a panic >when the system attempts to get the physical address from the page tables. >I don't see anything obvious in the 'de' driver that could cause this, so >I suspect the buffer corruption is external to the driver. I recently fixed one source of mbuf chain corruption: diff -c2 uipc_socket.c~ uipc_socket.c *** uipc_socket.c~ Sun May 17 04:45:15 1998 --- uipc_socket.c Thu May 28 14:21:40 1998 *************** *** 689,694 **** orig_resid = 0; if (psa) ! *psa = dup_sockaddr(mtod(m, struct sockaddr *), ! mp0 == 0); if (flags & MSG_PEEK) { m = m->m_next; --- 689,693 ---- orig_resid = 0; if (psa) ! *psa = dup_sockaddr(mtod(m, struct sockaddr *), 0); if (flags & MSG_PEEK) { m = m->m_next; It is apparently not OK for the MALLOC() in dup_sockaddr() to wait if the call is from here. Even lowering the ipl is not OK. To see corruption, add a reverse splx()/splnet() here and do a `ping -f' to an ethernet host. This normally causes a panic in sbdrop() within a second or two. OTOH, the reverse splx()/splnet() doesn't seem to cause any problems under light network loads, and MALLOC() doesn't normally sleep, so this bug probably only shows up under very heavy loads. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 1 01:43:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA25590 for freebsd-scsi-outgoing; Mon, 1 Jun 1998 01:43:56 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from coventry.ac.uk (mercury.coventry.ac.uk [193.61.107.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA25585 for ; Mon, 1 Jun 1998 01:43:53 -0700 (PDT) (envelope-from justin@mw65-3.coventry.ac.uk) Received: from mw65-3 (mw65-3.coventry.ac.uk [194.66.38.122]) by coventry.ac.uk (8.8.7/8.6.11) with SMTP id JAA19222 for <@mercury.coventry.ac.uk:freebsd-scsi@FreeBSD.ORG>; Mon, 1 Jun 1998 09:43:43 +0100 (BST) Received: (from justin@localhost) by mw65-3 (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA06477 for freebsd-scsi@FreeBSD.ORG; Mon, 1 Jun 1998 09:40:32 +0100 Date: Mon, 1 Jun 1998 09:40:32 +0100 From: justin@mw65-3.coventry.ac.uk (Justin Murdock) Message-Id: <199806010840.JAA06477@mw65-3> To: freebsd-scsi@FreeBSD.ORG Subject: Flash Qlogic SCSI card? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org how do you falsh the bios on on scsi card? Apologies if this should be sent to a more general list. Many thanks, Justin. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 1 03:17:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA08629 for freebsd-scsi-outgoing; Mon, 1 Jun 1998 03:17:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from polaris.we.lc.ehu.es (polaris.we.lc.ehu.es [158.227.6.43]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA08612; Mon, 1 Jun 1998 03:17:09 -0700 (PDT) (envelope-from jose@we.lc.ehu.es) Received: from we.lc.ehu.es by polaris.we.lc.ehu.es (SMI-8.6/SMI-SVR4) id MAA17035; Mon, 1 Jun 1998 12:17:04 +0200 Message-ID: <35727FA0.E394F452@we.lc.ehu.es> Date: Mon, 01 Jun 1998 12:17:04 +0200 From: "Jose M. Alcaide" Organization: Universidad del País Vasco - Dept. Electricidad y Electrónica X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-STABLE i386) MIME-Version: 1.0 To: Gary Palmer CC: freebsd-scsi@FreeBSD.ORG, gibbs@narnia.plutotech.com, borjam@we.lc.ehu.es Subject: Re: AHC: "cheksum error" reading SEEPROM with Iwill PIILS mb References: <25690.896579042@gjp.erols.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Gary Palmer wrote: > > "Jose M. Alcaide" wrote in message ID > <356D9CF8.1E7667F5@we.lc.ehu.es>: > > When the AHC driver tries to read the 7880's SEEPROM, the operation > > fails with a "cheksum error". I'm afraid that the 7880 chip on my > > PIILS motherboard is different (perhaps another version?): for > > example, I cannot choose the termination type using the Adaptec > > SCSI BIOS ("High ON/Low ON", "High ON/Low Off"...); instead, I can > > only select "Enable" or "Disable". However, the "cheksum error" > > trying to read the 7880's SEEPROM does not prevent the AHC driver > > from working properly. Until now, I can use both the SCSI disk and > > CD-ROM without any problem. > > The SEEPROM (Serial EEPROM) is something that Adaptec PCI cards use > to store their configuration on. However, on-board controllers don't > have an SEEPROM as they normally have the settings in the BIOS. Hence, > the SEEPROM checksum fails because there isn't one :) > > The AHC driver has sensible enough defaults that it should Just Work (TM) > when an SEEPROM is not found. > Mmmm... I have two Dell Poweredges with embedded 7880s, and they _have_ SEEPROM; there is no "checksum error" on these machines. Well, perhaps the Iwill PIILS mb has no SEEPROM, but... perhaps it has one, but there is _indeed_ a checksum error because of some difference in the format of the data. I have examined carefully sys/pci/aic7870.c. The format of the SEEPROM registers is defined in this file. It can be seen (lines 154-155, version 1.41.2.8) that there are two bits in the "Host Adapter Control Bits", labeled CFSTERM and CFWSTERM, which inform about the low/high byte termination of the SCSI bus. I insist that the SCSISelect utility of my PIILS motherboard only permits the "Enable" and "Disable" states for the SCSI host adapter termination; instead, when using SCSISelect on the Dell Poweredges, I can choose all combinations of high/low byte termination. I have just edited sys/pci/aic7870.c, adding to it code for printing the contents of scarray[], which supposedly stores the contents of the SEEPROM after calling read_seeprom(). This is the result: 808e 808e 808e 808e 862d bfc0 bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff Strange, isn't it? Also, although I have a IBM DDRS 34560W HD, which support Ultra speed, the AHC driver reports that it's using 10 MHz transfers with this drive. The reason is that it uses the BIOS defaults, which (I don't know why) have the Ultra speed disabled. I made another slight modification to aic7870.c, setting ultra_enb=1, and now the AHC driver uses 20 MHz transfers with my HD. In summary, I don't know if the Iwill PIILS mb has SEEPROM or not. If it has one, the AHC driver does not read it correctly. If the mb hasn't a SEEPROM, then the Ultra SCSI speed is not enabled in the BIOS defaults used by the driver. However, I enabled this feature using the SCSISelect utility. Thanks for your patience, -- JM ----------------------------------------------------------------------- Jose M. Alcaide | mailto:jose@we.lc.ehu.es Universidad del Pais Vasco | http://www.we.lc.ehu.es/~jose Dpto. de Electricidad y Electronica | Facultad de Ciencias - Campus de Lejona | Tel.: +34-944647700 x2624 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-944858139 ----------------------------------------------------------------------- "Go ahead... make my day." - H. Callahan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 1 09:24:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA06152 for freebsd-scsi-outgoing; Mon, 1 Jun 1998 09:24:55 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns.mauswerks.net (root@ns.mauswerks.com [204.152.96.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA06147 for ; Mon, 1 Jun 1998 09:24:54 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (root@gw100.feral.com [192.67.166.129]) by ns.mauswerks.net (8.8.0/8.6.9) with ESMTP id JAA20155; Mon, 1 Jun 1998 09:26:28 -0700 Received: from feral-gw (mjacob@gw100.feral.com [192.67.166.129]) by feral.com (8.8.6/8.8.6) with SMTP id JAA02604; Mon, 1 Jun 1998 09:24:44 -0700 Message-ID: <3572D5CC.2E74240B@feral.com> Date: Mon, 01 Jun 1998 09:24:44 -0700 From: Matthew Jacob Organization: Feral Software X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: Justin Murdock CC: freebsd-scsi@FreeBSD.ORG Subject: Re: Flash Qlogic SCSI card? References: <199806010840.JAA06477@mw65-3> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Which Qlogic is this? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 1 10:44:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20903 for freebsd-scsi-outgoing; Mon, 1 Jun 1998 10:44:05 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns.mauswerks.net (root@ns.mauswerks.com [204.152.96.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA20839 for ; Mon, 1 Jun 1998 10:44:01 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (root@gw100.feral.com [192.67.166.129]) by ns.mauswerks.net (8.8.0/8.6.9) with ESMTP id KAA20227; Mon, 1 Jun 1998 10:45:36 -0700 Received: from feral-gw (mjacob@gw100.feral.com [192.67.166.129]) by feral.com (8.8.6/8.8.6) with SMTP id KAA02840; Mon, 1 Jun 1998 10:43:51 -0700 Message-ID: <3572E856.50416943@feral.com> Date: Mon, 01 Jun 1998 10:43:50 -0700 From: Matthew Jacob Organization: Feral Software X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: ken@plutotech.com CC: freebsd-scsi@FreeBSD.ORG Subject: long erase in CAM driver? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org May I suggest using the 'count' field for the mt erase command to indicate a desire for the LONG erase option? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 1 12:36:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA12321 for freebsd-scsi-outgoing; Mon, 1 Jun 1998 12:36:02 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA12283 for ; Mon, 1 Jun 1998 12:35:58 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id NAA10489; Mon, 1 Jun 1998 13:35:54 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806011935.NAA10489@panzer.plutotech.com> Subject: Re: long erase in CAM driver? In-Reply-To: <3572E856.50416943@feral.com> from Matthew Jacob at "Jun 1, 98 10:43:50 am" To: mjacob@feral.com (Matthew Jacob) Date: Mon, 1 Jun 1998 13:35:54 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote... > May I suggest using the 'count' field for the mt erase command > to indicate a desire for the LONG erase option? Good idea, I'll add it in. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 1 20:34:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA24240 for freebsd-scsi-outgoing; Mon, 1 Jun 1998 20:34:35 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA24117 for ; Mon, 1 Jun 1998 20:34:12 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 11763 invoked by uid 1000); 1 Jun 1998 15:08:47 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199805300300.WAA05097@dyson.iquest.net> Date: Mon, 01 Jun 1998 11:08:47 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: "John S. Dyson" Subject: Re: DPT install problem Cc: tom@sdf.com, freebsd-stable@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, (Mike Smith) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 30-May-98 John S. Dyson wrote: >> > > >> > > On 22-May-98 Mike Smith wrote: >> > > >> >> > > >> > However, there are a couple of things that you personally (and >> > > >> > other >> > > >> > concerned users) can do to help the situation. >> > > >> > >> > > >> > - Contribute commentary (as you have), documentation and >> > > >> > source/ >> > > >> > procedural fixes. Remeber that FreeBSD is a volunteer >> > > >> > project - >> > > >> > your support means that it will continue to improve. >> > > >> > - Donate a DPT controller to our testing pool so that we can >> > > >> > test >> > > >> > with it. Chances are we can scrape enough disks together in >> > > >> > one >> > > >> > place to meet the 20GB mark if we have one. >> > > >> >> > > >> I recently donated TWO DPT controllers and FIVE disk drives. >> > > >> They went >> > > >> to >> > > >> two separate FreeBSD prominent figures, but still do not add up >> > > >> to 20GB. >> > > > >> > > > Then we need some accountability from these prominent figures. >> > > > Where >> > > > is their feedback on this discussion? >> > > >> > Do you want working kernel threads and SMP or DPT support? I am >> > working >> > feverishly on the SMP and kernel threads stuff, and physically cannot >> > do >> > any more in the day. >> >> I just want to know what these people are doing if not answering >> questions. Guessing and begging users for input is traditional stuff, >> but if there's a better alternative, I'm all for it. >> >> > I do plan to work on the DPT stuff, but I can only do one type of >> > thing >> > at a time... >> >> Sounds reasonable to me. What we need are some underlings for you to >> boss around doing your grunt work. JD and the moonshine gang? >> > I have worked in mgmt before, I make a much better 'grunt'. :-). Also, > if we can find someone who can do things more quickly or efficiently, > and Simon agrees, I am willing to ship the equipment to someone else. > I consider the equipment as a project resource donated by Simon, and am > willing to do what I can do to make things move more quickly as needed > and agreed by everyone concerned!!! I'd rather have John keep the equipment he has. It is rather old and slow, and will not make for a good maximal/stress-test system. Having John use a DPT subsystem for routine development work is already valuable. Until I can convince DPT that donating a large subsystem to other FreeBSD resources than myself, I volunteer to continue and stress-test large arrays. I should remind ourselves that I have in the past (without publishing it) convinced the DPT folks to run FreeBSD in their test labs, to verify some specific issues. We can continue and do that. To make the case for such, I need well documented failure modes, along the guidelines I published on Friday. Simon > > John --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 1 21:05:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA00333 for freebsd-scsi-outgoing; Mon, 1 Jun 1998 21:05:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAB00314 for ; Mon, 1 Jun 1998 21:05:07 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 953 invoked by uid 1000); 2 Jun 1998 01:06:24 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <509A2986E5C5D111B7DD0060082F32A402FAE8@freya.circle.net> Date: Mon, 01 Jun 1998 21:06:24 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: tcobb Subject: RE: DPT Redux Cc: "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I simply am tired of this thread. There will be no more response from me on this isuue. The author displays complete lack of understanding of how the FreeBSD kernel, the SCSI abstraction layer, the DPT driver, and the DPT firmware operate and interact. While this lack of knowledge is understandable, the attempt to diagnose the problem in this context is irritating. Simon On 30-May-98 tcobb wrote: > I won't respond to each of Simon's many emails over the past 24 hours, > simply because most of them were out-of-context reactions to a thread > that grew from my original DPT post yesterday. > > Instead, I think that the most productive thing is to provide a bit more > of the information requested. > > The system is using a single PM3334UW/2 with drives configured in the > following logical arrays: > > 2 1GB drives as RAID-1 (sd0) > 7 4GB drives as RAID-5 (sd1) > 1 4GB hot swap > > Event #1: > 1 of the RAID-5 drives fails, DPT hardware begins to auto-rebuild with > the hot swap drive > DPT driver freezes access to sd1, system remains running but access to > sd1 hangs > > I shutdown and rebooted machine (SYNC failed on shutdown) > Allowed FreeBSD to boot, it returned the following for sd1 > sd1: type 0 fixed SCSI 2 > sd1: Direct-Access 0MB (1 512 byte sectors) > > Then, system continued booting and finally panic'd with a "Page Fault in > Supervisor Mode" error prior to mounting drives. > > I then booted the system with a DOS floppy, used DPTmgr to examine > array. The array was complete, but in degraded mode. It had begun > rebuilding itself, which specs say can happen in the background while > other accesses are going on. I tested redundancy info on the array AND > tested random reads on the array -- all succeeded. > > So, I exited DPTmgr, and tried booting back to FreeBSD, same problem as > above occurred (0MB 1 sector, panic). Then, I rebooted into DOS and let > the DPT card run its rebuild from there. It completed about 1.5 hours > later, and showed the array optimal. > > I then rebooted into FreeBSD which showed the correct info again. > > Event #2: > This was the next day. Hard drive fails in array (this was the ex-hot > swap from above). This leaves the array with no hotswap to insert, but > no data lost. The array is now again in degraded mode. The card > screams bloody murder. HOWEVER, the DPT driver does NOT hang on access > to the sd1 partition. I successfully shutdown the machine (SYNC > succeeded this time). I insert a new harddrive into the array so that > the DPT hardware will begin rebuilding with this new drive. On reboot, > FreeBSD showed the same results as above (0MB, 1 sector, panic). > Rebooting back to DOS and running DPTmgr showed that the array was in > degraded mode, but that no data was lost and that redundancy information > was all there. It automatically began rebuilding with the new drive. I > tested rebooting into FreeBSD, same results (0/1/panic). Rebooted back > to DOS, allowed the hardware to finish its rebuild (1.5 hours), rebooted > to FreeBSD and it showed the correct results. > > > So, here's the summary for those of you who've stayed with me. > > With RAID-5 and a HOT SWAP drive, a single drive failure caused the DPT > driver in FreeBSD to hang on access to the partition. This appears to > be because DPT was doing a background rebuild automatically. > > With RAID-5 and NO hot swap drive, a single drive failure does NOT cause > the DPT driver in FreeBSD to hang on access to the partition. This > appears to be because DPT was NOT doing a background rebuild -- there > being no drives to rebuild into. > > With RAID-5 and a new drive to rebuild on, the DPT hardware begins > automatic rebuilds of the array. However, in these conditions the DPT > driver (or other FreeBSD component) does not correctly sense the size > information and panics the kernel during bootup. This symptom goes away > after the rebuild is complete. This symptom does not appear when in DOS > under the same circumstances. DOS DPTmgr checks show the array of the > correct size. BIOS bootup screen for DPT shows the array of the correct > size. > > The super-summary is that it appears the the DPT driver or other FreeBSD > code component is not correctly coordinating with the DPT hardware (or > sensing status properly) when the DPT hardware is doing a background > rebuild of the array. > > This array has been running non-stop since November 1997. Cabling is > good. Active terminators and custom cables created by Granite are used. > Seagate and Micropolis drives are used. The RAID-5 array is in an > external rackmount case. > > -Troy Cobb > Circle Net, Inc. > http://www.circle.net > > > Here's the dmesg ouput, trimmed to show relevant data. > > FreeBSD 3.0-CURRENT #0: Sun May 24 04:30:04 EDT 1998 > root@kali.circle.net:/usr/src/sys/compile/BENZAITEN-4 > CPU: Pentium (232.67-MHz 586-class CPU) > Origin = "GenuineIntel" Id = 0x543 Stepping=3 > Features=0x8001bf > real memory = 134217728 (131072K bytes) > avail memory = 128147456 (125144K bytes) > DEVFS: ready for devices > DPT: RAID Manager driver, Version 1.0.5 > Probing for devices on PCI bus 0: > DPT: PCI SCSI HBA Driver, version 1.4.2 > chip0: rev 0x02 on pci0.0.0 > chip1: rev 0x01 on pci0.7.0 > dpt0: rev 0x02 int a irq 9 on > pci0.20.0 > dpt0: DPT type 3, model PM3334UW firmware 07M0, Protocol 0 > on port 6310 with Write-Back cache. LED = 0000 0000 > dpt0: Enabled Options: > Recover Lost Interrupts > Collect Metrics > Optimize CPU Cache > dpt0: waiting for scsi devices to settle > scbus0 at dpt0 bus 0 > dpt0: Initializing Lost IRQ Timer > sd0 at scbus0 target 0 lun 0 > sd0: type 0 fixed SCSI 2 > sd0: Direct-Access 1029MB (2109328 512 byte sectors) > dpt0: waiting for scsi devices to settle > scbus1 at dpt0 bus 1 > sd1 at scbus1 target 2 lun 0 > sd1: type 0 fixed SCSI 2 > sd1: Direct-Access 20503MB (41990720 512 byte sectors) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 1 21:20:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03224 for freebsd-scsi-outgoing; Mon, 1 Jun 1998 21:20:23 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA03049 for ; Mon, 1 Jun 1998 21:20:00 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 1047 invoked by uid 1000); 2 Jun 1998 01:21:14 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199805310309.UAA09016@antipodes.cdrom.com> Date: Mon, 01 Jun 1998 21:21:13 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: DPT Redux Cc: "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" , tcobb Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 31-May-98 Mike Smith wrote: ... > Thanks for the extra info. Are you able to simulate the failure by eg. > disconnecting one of the 'active' drives? If you can't do this on a > regular basis, I believe we are able to arrange temporary access to a > similar but idle system where this can be simulate. Simon may also be > able to offer some suggestions inre. possible poor interaction between > the dpt driver and some firmware revisions. I have tested and simpulated this problem. Again, the DPT driver in FreeBSD does not know a disk from an onion. It simply passes SCSI SCBs formatted by the abstraction layer to the controller, and passes results back. >From the controller model I can guess the firmware revisions range in question. I have run tests on most of them, and, under normal conditions, what is described, simply does not happen. I did find a window with these conditions: * During boot (and only during boot), while the scsi abstraction layer still runs in polled mode (interrupts off). * The DPT controller has enough bandwidth to accept commands one at a time. * The DPT controller then delays responding to commands 1,000 longer than the SCSI abstraction layer (sd.c, in this case) specified. In 3.0 I reduced this to only 50 times longer. * When command completion is probed, the DPT will NOT report error, but successful condition, or no condition at all. Under these conditions, the DPT driver could return a ``successful'' completion code. In this case, the abstraction layer will post the device with whatever capacity value was there before calling the DPT driver. It is possible, under these conditions that nonsense will be assumed. The panic may be triggered by the SCSI abstraction layer trying to interpret some of its trash as valid data. Since the DPT driver does not supply, in its callback, any pointers, the memory reference failure is most likely not directly induced by the DPT driver. A patch to close this window was submitted for review and will be checked in as soon as the FreeBSD committer accepts the code as valid and acceptable. Summary: Theyre is a bit of ``pointing elsewhere'' here as, after thorough review, I do not see the memory failure in the driver. Neither do I see any other defect. As a historical curiosity, I have seen this failure mode in certain interm DPT firmware version. The failure was in the firmware, and was induced by a large array re-build. It was not restricted to while-building, but caused the array to trash permanently. I doubt that version of the firmware was supplied to the complainer in this case. Since I have not recived any direct info, as I asked for, this is but a wild guess. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 1 21:22:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03768 for freebsd-scsi-outgoing; Mon, 1 Jun 1998 21:22:38 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA03687 for ; Mon, 1 Jun 1998 21:22:16 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 1063 invoked by uid 1000); 2 Jun 1998 01:23:33 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199805310309.UAA09016@antipodes.cdrom.com> Date: Mon, 01 Jun 1998 21:23:33 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: DPT Redux Cc: "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" , tcobb Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 31-May-98 Mike Smith wrote: >> I shutdown and rebooted machine (SYNC failed on shutdown) >> Allowed FreeBSD to boot, it returned the following for sd1 >> sd1: type 0 fixed SCSI 2 >> sd1: Direct-Access 0MB (1 512 byte sectors) This version of the firmware (7M0) is newer than any I have ever seen. If it is a decendant of 7L7, then the failure mode well known. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 1 21:29:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA05252 for freebsd-scsi-outgoing; Mon, 1 Jun 1998 21:29:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA05222 for ; Mon, 1 Jun 1998 21:28:57 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 1109 invoked by uid 1000); 2 Jun 1998 01:30:14 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <509A2986E5C5D111B7DD0060082F32A402FAE9@freya.circle.net> Date: Mon, 01 Jun 1998 21:30:14 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: tcobb Subject: RE: DPT driver fails and panics with Degraded Array Cc: Karl Pielorz , "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 30-May-98 tcobb wrote: >> -----Original Message----- >> From: Simon Shapiro [mailto:shimon@simon-shapiro.org] > [SNIP] >> At this point, the load on >> the system will >> reach 140-400 (we run the tests against RAID-0 and RAID-1, the >> performance differs) > >>From my quick review of the replies of FreeBSD DPT RAID users, all of > them appear to be using their arrays in RAID-0 or RAID-1 configurations. > > According to Simon's test procedure for his releases (portion copied > above), he too only uses the DPT RAID-0 and RAID-1 features. > > In my setup, I'm using both RAID-5 and RAID-1. I have yet to have a > drive failure on the RAID-1 array (*knock on wood*), the problems I saw > were with the RAID-5 array and rebuilds. Assume is an acronym for making an A-s out of You and Me. I routinely use and test RAID-0, 1, 5, in configurations of 6, 7, 14, and 21 drives. > *PERHAPS* the key point is that the driver developer hasn't tested the > FreeBSD DPT driver with a RAID-5 array. Perhaps not. Perhaps your attitude can sustain improvement. You are making presumptions left and right. Go read the code and then say where the failure is. I have yet to see ANY direct communications from you, with ANY data. The only thing that appears to be useful is the quote in the INQUIRY message you posted here. This indicates a very new release of the DPT FIRMWARE. So new, in fact, that my own internal contact at DPT has not sent it to me yet. The release prior to that was broken. Have you had bothered to ASK me about it, I may have told you that days ago. Even supply you with a known, reliable firmware version. > What is clear from my prior post (the really long one) is that in my > configuration the DPT driver or some other FreeBSD software component > does not correctly deal with the DPT hardware doing a background > rebuild. This is not clear at all. Not to me. What is clear to me is that I completely lost any patience for you. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 1 21:40:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07568 for freebsd-scsi-outgoing; Mon, 1 Jun 1998 21:40:59 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA07516 for ; Mon, 1 Jun 1998 21:40:42 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 12203 invoked by uid 1000); 1 Jun 1998 16:15:18 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <9805311428.AA11443@deathstar.deathstar.dpt.com> Date: Mon, 01 Jun 1998 12:15:17 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mark Gregory Salyzyn Subject: Re: DPT Redux Cc: freebsd-scsi@FreeBSD.ORG, tcobb@staff.circle.net Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 31-May-98 Mark Gregory Salyzyn wrote: ... Some excellent suggestions deleted ... > 2) Simon, you may want to consider what happens when the controller is > indicating busy, do you > perform a timeout on the busy bit of the auxilliary status register, > and if you do, what do > you show to the OS (failed command? spawn a separate command issue > thread to try again later? > spin forever waiting for ready?). Depends on wht the O/S is doing: a. If we are booting, then I poll the commands one at a time, sequentially. b. If we are shutting down, I immediately fail the command. c. In all other cases, I put the command in a queue, tell the O/S the command has been queued and check the busy bit. If the busy bit is set, I (essentially) sleep on the (driver's private) witing commands queue until a command completes. When a command completes, I scan the wait queue and try to submit a command. Before submitting, I check the busy bit. If the busy bit is set, I (essentially) sleep until another command completes. There is no timeout on any command in the wait queue. The reason is that there is no reasonable value to use. Commands that have been submitted to the DPT can be timed out. To do that, you need the options DPT_HANDLE_TIMEOUTS and possible DPT_TIMEOUT_FACTOR defined in the kernel configuration. In this scenario, we check the age of each transaction already committed to the DPT. If it timed out, we abort it and return to the OS a failure status. Please note that this timeout mechanism only works on commands in the submitted queue. > The BSDi BSD/OS driver, for example, simply `locks' waiting for the > controller to get out of > busy, which is the simplest approach to deal with, what should be a > transitory situation. Also, > you may wish to limit the number of outstanding commands to the > controller (the UNIXWARE driver > uses the lock on wait, and 32 CCB limit to reduce the chances of this > problem affecting > performance). The highest performance DPT driver in a Networking > operating system (NETWARE) > does the `spawn an issuing task' approach to allow processing of > network card interrupts while > waiting for the controller to come free. This may be your best > approach > considering you will > no doubt be issuing `next' commands to the controller while in the > context of the controller > interrupt service routine. This is essentially what is being done. As long as the DPT driver can malloc memory for requests, it takes them from the OS. If commands cannot be submitted to the DPT hardware, they simply wait. The assumption is that if the DPT is too busy, it is too busy. The other assumption is that every time a command completes, the DPT hardware is a bit less busy. We then try to submit a request. We do check if the controller is busy before submitting a command. Now, if between looking at the external busy bit and completing the transfer of a command, the DPT becomes too busy, this will result in a corrupted transfer. AFAIK, from discussing it with you, once the DPT marked not-busy and transfer of a command started, the DPT will not clobber the partial command. > > My assumption is that you timeout and send a fail up to the OS, which > may explain the 0MB > read capacity result shown in the log? (Conditionally) Correct assumption. The report capacity bit is done during boot. At this point the DPT driver is in polled mode. In polled mode, if the number of commands submitted but not completed is less than the hardware queue depth, we assume that the hardware should not be busy and try to send a command. If this failed (due to the aux-bit busy bit being set), we send failure to the O/S. If, in polled mode, we have submitted as many commands to the hardware as the hardware queue length is reported, and none completed (stalled HBA) we immediately fail. If we submitted a command successfully, we then wait 50us * the amount of wait the OS indicated (in xs->timeout). Once a command completetion is indicated (or we timed-out), we process the command completion, and return to the OS, using normal processing. >From this description, it is clear that if a command takes inordinately long during boot, it may timeout and fail. Please remember that this is ONLY TRUE DURING O/S BOOT. I am reluctant to change the timeout logic as there is no telling what correct timeout is. Too short and we will timeout good but busy builds. Too long and the system will stall on problems. I am adding a bit of more error reporting to the boot section. A patch against 3.0-current and against 2.2-releng will be submitted today, and be available in my ftp server in about an hour or two. The extent of testing on these patches will be to verify that they compile and that a normal system, equipped with these patches boots and operates normally. Later on I will perfrom complete regression testing on the code. > I hope this helps -- Sincerely -- Mark Salyzyn Thanx Mark. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 1 21:48:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA08844 for freebsd-scsi-outgoing; Mon, 1 Jun 1998 21:48:36 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA08792 for ; Mon, 1 Jun 1998 21:48:20 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 12259 invoked by uid 1000); 1 Jun 1998 16:22:58 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <9805311428.AA11443@deathstar.deathstar.dpt.com> Date: Mon, 01 Jun 1998 12:22:58 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mark Gregory Salyzyn Subject: Re: DPT Redux - Correction Cc: freebsd-scsi@FreeBSD.ORG, tcobb@staff.circle.net Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 31-May-98 Mark Gregory Salyzyn wrote: ... Please note that: a. The delay, waiting for completion in polled mode, in 2.2 is 1000 * xs-> timeout, 200 times longer than in 3.0. b. In 2.2, to activate runtime (not-boot!) commands timeout, you also need the kernel option DPT_TRACK_CCB_STATES. c. You can activate (in 2.2 only) debugging of all this mess, by turning on kernel option DPT_DEBUG_POLLING. These last two options were removed in 3.0 due to lack of interest (we had, until last week) zero cases of invokation of this debugging code. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 2 00:59:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA08852 for freebsd-scsi-outgoing; Tue, 2 Jun 1998 00:59:32 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from d183-205.uoregon.edu (d183-205.uoregon.edu [128.223.183.205]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA08830; Tue, 2 Jun 1998 00:59:28 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by d183-205.uoregon.edu (8.8.8/8.8.7) id AAA24629; Tue, 2 Jun 1998 00:59:11 -0700 (PDT) Message-ID: <19980602005908.13903@hydrogen.nike.efn.org> Date: Tue, 2 Jun 1998 00:59:08 -0700 From: John-Mark Gurney To: The Hermit Hacker Cc: "Kenneth D. Merry" , freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: May29th kernel with May20th CAM drivers: panic? References: <199805312220.QAA04786@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from The Hermit Hacker on Sun, May 31, 1998 at 06:29:28PM -0400 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.6-STABLE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The Hermit Hacker scribbled this message on May 31: > On Sun, 31 May 1998, Kenneth D. Merry wrote: > > > The Hermit Hacker wrote... > > > > > > Hi... > > > > > > I'm not going to bother submitting a problem report on this, > > > mainly because I don't even have a core to analyze, but I figured I'd at > > > least put a 'head up' on this, in case this anything to someone... > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address = 0xefcb5b1c > > > fault code = supervisor read, page not present > > > instruction pointer = 0x8:0xf01a88ad > > > stack pointer = 0x10:0xf6951af4 > > > frame pointer = 0x10:0xf6951b28 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, def32 1, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 7011 (innfeed) > > > interrupt mask = net bio > > > kernel: type 12 trap, code=0 > > > Stopped at _tulip_txput+0x111: movl _PTmap(,%eax,4),%edx > > > > > > tulip_txput() is in the DEC 2114x driver. > > Hrmmm...are there any known problems with the 2114x driver? I do > see the following periodically: > > de0: abnormal interrupt: transmit underflow (raising TX threshold to > 96|256) > de0: abnormal interrupt: transmit underflow (raising TX threshold to > 8|512) > > On: > > de0: rev 0x22 int a irq 9 on pci0.10.0 > de0: 21140A [10-100Mb/s] pass 2.2 > de0: address 00:60:67:30:75:ef > > In 100Mb/s mode... actually, I'm running -stable and I keep getting: de0: abnormal interrupt: transmit underflow de0: receive: 08:00:09:39:2b:b8: bad crc but I see the bad crc's from multiple machines, it just depends upon the amount of traffic from that machine, I even get them from the cisco router.... I didn't get these messages when I had a ne2k clone in the machine... de0 rev 17 int a irq 11 on pci0:10:0 de0: 21041 [10Mb/s] pass 1.1 de0: address 00:80:19:35:21:93 it works great besides the 1second lockups when a transmit underflow happen... the machine is nothing special... k6-200, 48megs ram, buslogic scsi.. -- John-Mark Gurney Modem Rev/FAX: +1 541 346 9237 Cu Networking P.O. Box 5693, 97405 Live in Peace, destroy Micro$oft, support free software, run FreeBSD Don't trust anyone you don't have the source for To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 2 08:17:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA11515 for freebsd-scsi-outgoing; Tue, 2 Jun 1998 08:17:49 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA11502; Tue, 2 Jun 1998 08:17:43 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id JAA06810; Tue, 2 Jun 1998 09:16:51 -0600 (MDT) Message-Id: <199806021516.JAA06810@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: "Jose M. Alcaide" cc: Gary Palmer , freebsd-scsi@FreeBSD.ORG, gibbs@plutotech.com, borjam@we.lc.ehu.es Subject: Re: AHC: "cheksum error" reading SEEPROM with Iwill PIILS mb In-reply-to: Your message of "Mon, 01 Jun 1998 12:17:04 +0200." <35727FA0.E394F452@we.lc.ehu.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jun 1998 09:12:19 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I have examined carefully sys/pci/aic7870.c. The format of the >SEEPROM registers is defined in this file. It can be seen >(lines 154-155, version 1.41.2.8) that there are two bits in >the "Host Adapter Control Bits", labeled CFSTERM and CFWSTERM, >which inform about the low/high byte termination of the SCSI bus. >I insist that the SCSISelect utility of my PIILS motherboard >only permits the "Enable" and "Disable" states for the SCSI >host adapter termination; instead, when using SCSISelect on >the Dell Poweredges, I can choose all combinations of high/low >byte termination. They probably have a jumper on the motherboard for high termination. >I have just edited sys/pci/aic7870.c, adding to it code for >printing the contents of scarray[], which supposedly stores >the contents of the SEEPROM after calling read_seeprom(). >This is the result: > > 808e 808e 808e 808e 862d bfc0 bfff bfff bfff bfff bfff bfff bfff > bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff > bfff bfff bfff bfff bfff > >Strange, isn't it? I would have expected either valid SEEPROM contents or all ff's indicating that the SEEPROM is not present. Did you find a 93cx6 chip on the MB? >Also, although I have a IBM DDRS 34560W HD, which support Ultra >speed, the AHC driver reports that it's using 10 MHz transfers with >this drive. The reason is that it uses the BIOS defaults, which >(I don't know why) have the Ultra speed disabled. I made another >slight modification to aic7870.c, setting ultra_enb=1, and now >the AHC driver uses 20 MHz transfers with my HD. This has been corrected in the CAM version of the driver. > >In summary, I don't know if the Iwill PIILS mb has SEEPROM or not. >If it has one, the AHC driver does not read it correctly. Or, the seeprom is not in the standard format. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 2 09:40:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA27089 for freebsd-scsi-outgoing; Tue, 2 Jun 1998 09:40:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from iworks.InterWorks.org (deischen@iworks.interworks.org [128.255.18.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA27060; Tue, 2 Jun 1998 09:40:09 -0700 (PDT) (envelope-from deischen@iworks.InterWorks.org) Received: (from deischen@localhost) by iworks.InterWorks.org (8.8.7/8.8.7) id LAA15386; Tue, 2 Jun 1998 11:50:16 -0500 (CDT) Date: Tue, 2 Jun 1998 11:50:16 -0500 (CDT) From: "Daniel M. Eischen" Message-Id: <199806021650.LAA15386@iworks.InterWorks.org> To: jose@we.lc.ehu.es, owner-freebsd-scsi@FreeBSD.ORG Subject: Re: AHC: "cheksum error" reading SEEPROM with Iwill PIILS mb Cc: borjam@we.lc.ehu.es, freebsd-scsi@FreeBSD.ORG, gibbs@plutotech.com, gpalmer@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 808e 808e 808e 808e 862d bfc0 bfff bfff bfff bfff bfff bfff bfff > > bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff bfff > > bfff bfff bfff bfff bfff > > > >Strange, isn't it? > > I would have expected either valid SEEPROM contents or all ff's indicating > that the SEEPROM is not present. Did you find a 93cx6 chip on the MB? It might be a 93C56 or 93C66 (64 words) with the checksum at the end. > >In summary, I don't know if the Iwill PIILS mb has SEEPROM or not. > >If it has one, the AHC driver does not read it correctly. > > Or, the seeprom is not in the standard format. You might want to change the driver so that if the C46 seeprom read fails, it tries to read the C56/C66 seeprom. Instead of basing the SEEPROM type on the controller type... Dan Eischen deischen@iworks.InterWorks.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 2 11:13:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12141 for freebsd-scsi-outgoing; Tue, 2 Jun 1998 11:13:11 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles327.castles.com [208.214.167.27]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA12095; Tue, 2 Jun 1998 11:12:55 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id KAA00985; Tue, 2 Jun 1998 10:07:18 -0700 (PDT) Message-Id: <199806021707.KAA00985@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: Mike Smith , "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" , tcobb Subject: Re: DPT Redux In-reply-to: Your message of "Mon, 01 Jun 1998 21:21:13 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jun 1998 10:07:18 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I did find a window with these conditions: > > * During boot (and only during boot), while the scsi abstraction layer > still runs in polled mode (interrupts off). > > * The DPT controller has enough bandwidth to accept commands one at a time. > > * The DPT controller then delays responding to commands 1,000 longer than > the SCSI abstraction layer (sd.c, in this case) specified. In 3.0 I > reduced this to only 50 times longer. > > * When command completion is probed, the DPT will NOT report error, but > successful condition, or no condition at all. > > Under these conditions, the DPT driver could return a ``successful'' > completion code. In this case, the abstraction layer will post the device > with whatever capacity value was there before calling the DPT driver. > It is possible, under these conditions that nonsense will be assumed. > The panic may be triggered by the SCSI abstraction layer trying to > interpret some of its trash as valid data. ... > Summary: Theyre is a bit of ``pointing elsewhere'' here as, after thorough > review, I do not see the memory failure in the driver. Neither do I see > any other defect. Then could you characterise "returning a successful completion code for an incomplete/failed transfer"? The SCSI stack has to assume at this point that the transaction is complete, even though you're admitting that it's not. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 2 13:11:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA01558 for freebsd-scsi-outgoing; Tue, 2 Jun 1998 13:11:59 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA01543 for ; Tue, 2 Jun 1998 13:11:45 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 22441 invoked by uid 1000); 2 Jun 1998 21:13:05 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199806021707.KAA00985@antipodes.cdrom.com> Date: Tue, 02 Jun 1998 17:13:05 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: DPT Redux Cc: "freebsd-scsi@freebsd.org" , "freebsd-current@freebsd.org" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am deleting the cross-post to current.... On 02-Jun-98 Mike Smith wrote: ... > Then could you characterise "returning a successful completion code for > an incomplete/failed transfer"? The SCSI stack has to assume at this > point that the transaction is complete, even though you're admitting > that it's not. There was one specific failure mode, yes. To get there, especially on a RAID array, you had to have so many ducks lined up: * DPT free enough to accept commands * DPT so busy it will not reply to INQUIRY on a RAID array (there is no SCSI bus involved here) * DPT not setting the hardware registers as busy, while oh, so busy. This condition had to persist for several minutes. The patch checked in against current fixes that. the same patch will/should be checked in against 2.2 any moment now. BTW, for this to exist, the DPT firmware has to be rather sick. I can rplicate this scsnario with some broken, unpublished versions of the firmware. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 2 15:13:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA22017 for freebsd-scsi-outgoing; Tue, 2 Jun 1998 15:13:16 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from freya.circle.net (freya.circle.net [209.95.95.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA22008; Tue, 2 Jun 1998 15:13:14 -0700 (PDT) (envelope-from tcobb@staff.circle.net) Received: by freya.circle.net with Internet Mail Service (5.5.1960.3) id ; Tue, 2 Jun 1998 18:12:38 -0400 Message-ID: <509A2986E5C5D111B7DD0060082F32A402FB1D@freya.circle.net> From: tcobb To: "'shimon@simon-shapiro.org'" , Mike Smith Cc: "freebsd-scsi@freebsd.org" , "freebsd-current@freebsd.org" Subject: RE: DPT Redux Date: Tue, 2 Jun 1998 18:12:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > -----Original Message----- > From: Simon Shapiro [mailto:shimon@simon-shapiro.org] > I am deleting the cross-post to current.... > > On 02-Jun-98 Mike Smith wrote: > ... > > > Then could you characterise "returning a successful > completion code for > > an incomplete/failed transfer"? The SCSI stack has to > assume at this > > point that the transaction is complete, even though you're > admitting > > that it's not. > > There was one specific failure mode, yes. To get there, > especially on a > RAID array, you had to have so many ducks lined up: > > * DPT free enough to accept commands > * DPT so busy it will not reply to INQUIRY on a RAID array > (there is no > SCSI bus involved here) > * DPT not setting the hardware registers as busy, while oh, so busy. > > This condition had to persist for several minutes. The patch > checked in > against current fixes that. the same patch will/should be checked in > against 2.2 any moment now. > > BTW, for this to exist, the DPT firmware has to be rather sick. I can > rplicate this scsnario with some broken, unpublished versions of the > firmware. In your test case, please try to replicate this problem with the firmware version available for download from DPT's site right now. That was the version I used on my card (or, at least, the one available mid last week). -Troy Cobb Circle Net, Inc. http://www.circle.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 2 22:30:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA26076 for freebsd-scsi-outgoing; Tue, 2 Jun 1998 22:30:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA26056 for ; Tue, 2 Jun 1998 22:30:15 -0700 (PDT) (envelope-from zdenek@mediaone.net) Received: from zdenek (guarcello.ne.mediaone.net [24.128.24.252]) by chmls05.mediaone.net (8.8.7/8.8.7) with SMTP id BAA17254 for ; Wed, 3 Jun 1998 01:30:12 -0400 (EDT) Message-Id: <199806030530.BAA17254@chmls05.mediaone.net> X-Sender: zdenek@pop.ne.mediaone.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 03 Jun 1998 01:37:01 -0400 To: freebsd-scsi@FreeBSD.ORG From: Zdenek Radouch Subject: buslogic problems Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have the following problem. I recently switched from Linux to Freebsd on one of my old machines (386). Somehow, I installed 2.2.5 from a CD, rebuilt the kernel a few times and when everything looked tailored to my satisfaction I noticed that I can't use the CD any more (with either my new or the GENERIC kernel). Everything else looks and runs fine. When I try to mount a CD, I get a message "bt0: Try to abort" from bt_timeout() and keep getting them until I open the CD drive. Repeating "od /dev/cd0a" sometimes gives me data, but usually results in the same timeout. My HW config: bt0: Bt54xC/ 0-ISA(24bit) bus bt0: This driver is designed for using 32 bit addressing bt0: mode firmware and EISA/PCI/VLB bus architectures bt0: Bounce-buffering will be used (and is necessary) bt0: if you have more than 16MBytes memory. bt0: reading board settings, dma=5, int=11 bt0: version 4.25J, fast sync, parity, 32 mbxs, 32 ccbs bt0: targ 0 sync rate= 5.00MB/s(200ns), offset=15 bt0: Using Strict Round robin scheme bt0 at 0x330 irq 11 drq 5 on isa bt0 waiting for scsi devices to settle (bt0:0:0): "FUJITSU M2694ES-512 812A" type 0 fixed SCSI 2 sd0(bt0:0:0): Direct-Access 1033MB (2117025 512 byte sectors) (bt0:1:0): "SEAGATE ST296N ???" type 0 fixed SCSI 1 sd1(bt0:1:0): Direct-Access 80MB (165851 512 byte sectors) (bt0:6:0): "MEDIAVIS RENO CD-ROMX2A 2.03" type 5 removable SCSI 2 cd0(bt0:6:0): CD-ROM cd present [400000 x 2048 byte records] I am using the same HW under Linux and it runs without a single glitch, so I am guessing there's something misconfigured about the bsd bt driver. My questions: Any obvious things I could try for workarounds? I have no idea how the installation process mounted the CD... Should I just give up given that it's older hardware? I'd very much appreciate any pointers. Please respond to zdenek@mediaone.net. Thanks. -Zdenek To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 2 22:57:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA28902 for freebsd-scsi-outgoing; Tue, 2 Jun 1998 22:57:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from rubicon.hasler.ascom.ch (rubicon.hasler.ascom.ch [139.79.129.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA28890 for ; Tue, 2 Jun 1998 22:57:35 -0700 (PDT) (envelope-from abladtn@autelca.ascom.ch) Received: from autelca.ascom.ch (aut.autelca.ascom.ch [136.232.4.1]) by rubicon.hasler.ascom.ch (8.8.7/8.8.7) with SMTP id HAA04158 for ; Wed, 3 Jun 1998 07:57:34 +0200 (MET DST) Received: from sabg20.autelca.ascom.ch ([136.232.135.5]) by autelca.ascom.ch (4.1/SMI-4.1) id AA17642; Wed, 3 Jun 98 07:57:33 +0200 Received: from sun113 by sabg20.autelca.ascom.ch (SMI-8.6/SMI-SVR4) id HAA04123; Wed, 3 Jun 1998 07:57:23 +0200 Message-Id: <3574E5E1.41B0@autelca.ascom.ch> Date: Wed, 03 Jun 1998 07:57:53 +0200 From: Norbert Bladt X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: Adaptec 7880 on-board supported ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello you SCSI /FreeBSD experts ! I am about to upgrade my system at home. Now I saw a special offer for the Gigabyte GA-686DLX mainboard. This is a Dual Pentium-II mainboard with all the bells and whistles and it includes an on-board Adaptec 7880 Ultra-SCSI controller. Now an essential question for me is the support of FreeBSD and whether anyone has any experience with this board/setup. So, will it work with FreeBSD 2.2.x or even 3.x ? Thanks in advance for your help ! Best regards, Norbert Bladt. P.S. I did take a look in the FreeBSD online handbook and just the on-board Adaptec 7850 was mentioned in the supported configurations. I don't know what the difference is between the 7850 and the 7880, though. -- Norbert Bladt Payphone Management System Software Development ascom Autelca AG Worbstrasse 201 CH-3073 Guemligen, Switzerland abladtn@autelca.ascom.ch VOICE: +41 31 999 6552, FAX: +41 31 999 6575 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 2 23:39:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA05837 for freebsd-scsi-outgoing; Tue, 2 Jun 1998 23:39:14 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA05754; Tue, 2 Jun 1998 23:39:04 -0700 (PDT) (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (root@greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id IAA07435; Wed, 3 Jun 1998 08:38:56 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id IAA00337; Wed, 3 Jun 1998 08:38:53 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199806030638.IAA00337@greenpeace.grondar.za> To: gibbs@FreeBSD.ORG cc: scsi@FreeBSD.ORG Subject: Error: "Timedout SCB handled by another timeout" Date: Wed, 03 Jun 1998 08:38:53 +0200 From: Mark Murray Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I am still getting the error "Timedout SCB handled by another timeout", which only happens in SMP mode. I ran for 8 days in UP mode, and the machine was rock-steady. There is no other error when this happens, no panic, nothing; I just get one repetition approx. every 5-10 secs until the machine locks up solid enough to require a reset. It usually happens when something involving a big file (like say "make checksum" in /usr/ports/x11/XFree86) is done on a busy system ("cvs -q update -PdA" in /usr/src, "make clean" in /usr/ports and X running). The "big file" seems to be the trigger. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 3 03:28:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA15587 for freebsd-scsi-outgoing; Wed, 3 Jun 1998 03:28:05 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from colossus.dyn.ml.org (dburr@199-170-160-89.la.inreach.net [199.107.160.89]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA15520 for ; Wed, 3 Jun 1998 03:27:41 -0700 (PDT) (envelope-from dburr@colossus.dyn.ml.org) Received: (from dburr@localhost) by colossus.dyn.ml.org (8.8.8/8.8.7) id DAA07247 for freebsd-scsi@freebsd.org; Wed, 3 Jun 1998 03:28:33 -0700 (PDT) (envelope-from dburr) Message-ID: X-Mailer: XFMail 1.2 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 03 Jun 1998 03:28:32 -0700 (PDT) Organization: Computer Help From: Donald Burr To: FreeBSD SCSI Subject: Adaptec AHA-1540A and "aha0: type 00 is an unknown board" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- I just installed an Adaptec AHA-1540A in one of my system. Yes, folks, you read correctly: the AHA-1540A, the very first ever SCSI card in the 154x line... **FULL LENGTH**, ISA card with a copyright date of *1988*. A true museum piece. Anyway, I figured "what the hell" and compiled in the aha0 driver for it. Upon bootup, I am now seeing: ===== aha0: type 00 is an unknown board. aha0 at 0x330-0x333 irq 11 drq 5 on isa aha0 waiting for scsi devices to settle ===== However, the board appears, in so far as I have tested, to work fine. I have an oldish Conner 540MB SCSI hard drive attached to it, and so far it has worked great, with no console messages or anything. Shoule I be worrying about the "type 00 is an unknown board" message? FYI: the system in question is an AMD 486/100, 20 MB RAM, running 2.2.6-RELEASE. - --- Donald Burr - Ask me for my PGP key | PGP: Your WWW HomePage: http://DonaldBurr.base.org/ ICQ #1347455 | right to Address: P.O. Box 91212, Santa Barbara, CA 93190-1212 | 'Net privacy. Phone: (805) 957-9666 FAX: (800) 492-5954 | USE IT. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNXUlUPjpixuAwagxAQFGvwP/WKXlqMa266DQ0JI6CR8HnS84dG1aHPG4 FjBdGwYHPvpVi7sfZ9F/7uCKQR9uQXEeILgu7mxJ5LgVh/k6ppnbVs3WhcH5JlPJ x7TW0rghsWND7DCWmM4aEvf9l1iIYWRVEiTnT8RxY5398ZDbXHuzxPEuX851KVJC rYAG3dlmJuI= =q40e -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 3 07:24:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA19151 for freebsd-scsi-outgoing; Wed, 3 Jun 1998 07:24:56 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA19123 for ; Wed, 3 Jun 1998 07:24:54 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id IAA22526; Wed, 3 Jun 1998 08:24:43 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806031424.IAA22526@panzer.plutotech.com> Subject: Re: Adaptec 7880 on-board supported ? In-Reply-To: <3574E5E1.41B0@autelca.ascom.ch> from Norbert Bladt at "Jun 3, 98 07:57:53 am" To: abladtn@autelca.ascom.ch (Norbert Bladt) Date: Wed, 3 Jun 1998 08:24:43 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Norbert Bladt wrote... > Hello you SCSI /FreeBSD experts ! > > I am about to upgrade my system at home. > Now I saw a special offer for the Gigabyte GA-686DLX mainboard. > This is a Dual Pentium-II mainboard with all the bells and whistles > and it includes an on-board Adaptec 7880 Ultra-SCSI controller. > > Now an essential question for me is the support of FreeBSD and whether > anyone has any experience with this board/setup. > So, will it work with FreeBSD 2.2.x or even 3.x ? It should work fine with either 2.2.x or 3.x. The Adaptec driver is pretty much the same in -stable and -current. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 3 15:05:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA13446 for freebsd-scsi-outgoing; Wed, 3 Jun 1998 15:05:11 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA13399 for ; Wed, 3 Jun 1998 15:04:59 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA00132 (5.67b/IDA-1.5); Wed, 3 Jun 1998 23:35:59 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id XAA01584; Wed, 3 Jun 1998 23:35:22 +0200 (CEST) From: Wilko Bulte Message-Id: <199806032135.XAA01584@yedi.iaf.nl> Subject: Re: Adaptec AHA-1540A and "aha0: type 00 is an unknown board" In-Reply-To: from Donald Burr at "Jun 3, 98 03:28:32 am" To: dburr@POBoxes.com (Donald Burr) Date: Wed, 3 Jun 1998 23:35:22 +0200 (CEST) Cc: freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Donald Burr wrote... > I just installed an Adaptec AHA-1540A in one of my system. Yes, folks, > you read correctly: the AHA-1540A, the very first ever SCSI card in the > 154x line... **FULL LENGTH**, ISA card with a copyright date of > *1988*. A true museum piece. > > Anyway, I figured "what the hell" and compiled in the aha0 driver for it. > Upon bootup, I am now seeing: > > ===== > aha0: type 00 is an unknown board. > aha0 at 0x330-0x333 irq 11 drq 5 on isa > aha0 waiting for scsi devices to settle > ===== > > However, the board appears, in so far as I have tested, to work fine. I > have an oldish Conner 540MB SCSI hard drive attached to it, and so far it > has worked great, with no console messages or anything. > > Shoule I be worrying about the "type 00 is an unknown board" message? I'll see if I can find my 2 AH1542A. If so, I'll try wat 2.2.6R thinks of them. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW: http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 3 18:55:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA29624 for freebsd-scsi-outgoing; Wed, 3 Jun 1998 18:55:33 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA29607 for ; Wed, 3 Jun 1998 18:55:27 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.0/8.9.0) id LAA10894; Thu, 4 Jun 1998 11:25:21 +0930 (CST) Message-ID: <19980604112521.L22406@freebie.lemis.com> Date: Thu, 4 Jun 1998 11:25:21 +0930 From: Greg Lehey To: Donald Burr , FreeBSD SCSI Subject: Re: Adaptec AHA-1540A and "aha0: type 00 is an unknown board" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: ; from Donald Burr on Wed, Jun 03, 1998 at 03:28:32AM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 X-Mutt-References: Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 3 June 1998 at 3:28:32 -0700, Donald Burr wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > I just installed an Adaptec AHA-1540A in one of my system. Yes, folks, > you read correctly: the AHA-1540A, the very first ever SCSI card in the > 154x line... I thought the 1540 was the first in line. > **FULL LENGTH**, ISA card with a copyright date of *1988*. A true > museum piece. That's a couple of years older than my 1542A, anyway. > Anyway, I figured "what the hell" and compiled in the aha0 driver for it. > Upon bootup, I am now seeing: > > ===== > aha0: type 00 is an unknown board. > aha0 at 0x330-0x333 irq 11 drq 5 on isa > aha0 waiting for scsi devices to settle > ===== > > However, the board appears, in so far as I have tested, to work fine. I > have an oldish Conner 540MB SCSI hard drive attached to it, and so far it > has worked great, with no console messages or anything. > > Shoule I be worrying about the "type 00 is an unknown board" message? I'd guess not, if it still works. I'd guess that there were minor differences in the 154xA microcode, and that you have a very early version. Be warned, however, that there's a bug in the driver that hits many 154xAs: it writes a block of 16 0xff characters at not-quite-random places in large transfers (typically after 32 kB). You might like to check that with non-critical data first. It would be interesting to know whether it happens to your version. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 3 23:24:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA07640 for freebsd-scsi-outgoing; Wed, 3 Jun 1998 23:24:05 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles348.castles.com [208.214.167.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA07609 for ; Wed, 3 Jun 1998 23:24:02 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id WAA00468 for ; Wed, 3 Jun 1998 22:19:46 -0700 (PDT) Message-Id: <199806040519.WAA00468@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: scsi@FreeBSD.ORG Subject: Re: Micropolis 4345WS (Toshiba "Equium" 6200M) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 03 Jun 1998 22:19:45 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris Timmons wrote: > I received a couple of those Toshiba computers which Insight had the > special on (intel dual p6 mb, integrated pro100 ethernet, aha-7880, etc.) > The 12x atapi cd-room boots our freebsd CD's so quickly that you forget > that you're booting from a CD. Really nice systems, but mine came with > Micropolis 4345WS drives at firmware revision zC19. The manufacture date > of my systems was around 4/97. > > Unfortunately I couldn't get any version of FreeBSD to install without the > aha driver complaining about the drive timing out, and aborting the > install. No matter what the settings on the 7880 (disable wide > negotiation, throttle down xfer rate, etc) and after verifying drive > jumpers, termination. As soon as sysinstall started doing anything disk > intensive, the drives would lose it. I had both systems side by side with > a pile of FreeBSD CD's and each behaved the same whether it was 2.2.2, > 10/6/97 3.0-snap, 2/2/98 3.0-snap, etc. ... to which I followed up indicating that I had successfully installed and deployed several of these systems with no observed problems. To continue the story: tonight I was loading one of these systems heavily (stock 2.2.6, copying a CD full of data onto the disk) when the disk ceased to cooperate. Resuscitation of the system was a failure, and subsequent attempts at reinstalling now encounter the same problems that Chris described. I can hazard a guess that this has something to do with the drive's handling of forwarded blocks, but it'd be no more than that. Regardless, I would count this as a strong indication that if you are using one of these drives, or know someone who is, that you should consider the firmware upgrade as a matter of some urgency. (btw. where was that dang upgrade kit? I can't find the message with the URL in it now. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 4 08:24:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA25970 for freebsd-scsi-outgoing; Thu, 4 Jun 1998 08:24:46 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero.simon-shapiro.org.142.69.207.in-addr.arpa [207.69.142.25] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA25946 for ; Thu, 4 Jun 1998 08:24:32 -0700 (PDT) (envelope-from shimon@sendero.simon-shapiro.org) Received: (qmail 12042 invoked by uid 1000); 4 Jun 1998 16:26:09 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <509A2986E5C5D111B7DD0060082F32A402FB1D@freya.circle.net> Date: Thu, 04 Jun 1998 12:26:09 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: tcobb Subject: RE: DPT Redux Cc: "freebsd-current@freebsd.org" , "freebsd-scsi@freebsd.org" , Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 02-Jun-98 tcobb wrote: ... >> BTW, for this to exist, the DPT firmware has to be rather sick. I can >> rplicate this scsnario with some broken, unpublished versions of the >> firmware. > > In your test case, please try to replicate this problem with the > firmware version available for download from DPT's site right now. That > was the version I used on my card (or, at least, the one available mid > last week). While logically an excellent idea, it is a bit impractical. I tested several firmware versions, and rejected them for instability. This was noted to my DPT technical/OEM contact. The version I use currently, is 7LR. I tried later versions but they did very ugly things to my RAID-5 arrays. Not the symptoms you describe, but just as ugly. The firmware versions I use are always available from my ftp server. Maybe I should include the firmware with the driver release. That is difficult to do as it is a copyrighted material, NOT under Berkeley license. I am open to suggenstions. The thing that is pretty clear here, is that we need a way to make a ``FreeBSD-Certified'' firmware revision known and available. Let me inquire as to what can be done beyond what we are already doing. Simon --- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG 770.265.7340 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 4 10:39:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21075 for freebsd-scsi-outgoing; Thu, 4 Jun 1998 10:39:49 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA21069; Thu, 4 Jun 1998 10:39:44 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id LAA06499; Thu, 4 Jun 1998 11:39:21 -0600 (MDT) Message-Id: <199806041739.LAA06499@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Mark Murray cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Error: "Timedout SCB handled by another timeout" In-reply-to: Your message of "Wed, 03 Jun 1998 08:38:53 +0200." <199806030638.IAA00337@greenpeace.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jun 1998 11:34:51 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Hi > >I am still getting the error "Timedout SCB handled by another timeout", >which only happens in SMP mode. I ran for 8 days in UP mode, and the >machine was rock-steady. Can you change that printf into a panic and poke around the timeout code when it occurs. You'll probably want to have remote GDB setup for this. I really think that the problem has little to do with CAM, but is some kind of race in the processing of clock interrupts that causes the timeout queues to become corrupted. Just going up the stack should bring you into the generic timeout facility code and hopefully something will be obviously corrupted. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 4 10:47:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA22027 for freebsd-scsi-outgoing; Thu, 4 Jun 1998 10:47:20 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA22018; Thu, 4 Jun 1998 10:47:10 -0700 (PDT) (envelope-from mark@grondar.za) Received: from greenpeace.grondar.za (root@greenpeace.grondar.za [196.7.18.132]) by gratis.grondar.za (8.8.8/8.8.8) with ESMTP id TAA11253; Thu, 4 Jun 1998 19:46:58 +0200 (SAST) (envelope-from mark@grondar.za) Received: from grondar.za (mark@localhost [127.0.0.1]) by greenpeace.grondar.za (8.8.8/8.8.8) with ESMTP id TAA03903; Thu, 4 Jun 1998 19:46:57 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199806041746.TAA03903@greenpeace.grondar.za> To: "Justin T. Gibbs" cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Error: "Timedout SCB handled by another timeout" Date: Thu, 04 Jun 1998 19:46:57 +0200 From: Mark Murray Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" wrote: > >I am still getting the error "Timedout SCB handled by another timeout", > >which only happens in SMP mode. I ran for 8 days in UP mode, and the > >machine was rock-steady. > > Can you change that printf into a panic and poke around the timeout > code when it occurs. You'll probably want to have remote GDB setup > for this. I really think that the problem has little to do with CAM, > but is some kind of race in the processing of clock interrupts that > causes the timeout queues to become corrupted. Just going up the > stack should bring you into the generic timeout facility code and > hopefully something will be obviously corrupted. OK - will do. It will have to wait a few weeks, though. I'm off on a bit of well deserved vacation (and Usenix; see you there?). I'll do this properly when I am back and rested. Right now I am stressed an panicky, and I have the concentation of a 5-year old. ;-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 4 13:38:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA00980 for freebsd-scsi-outgoing; Thu, 4 Jun 1998 13:38:17 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA00885 for ; Thu, 4 Jun 1998 13:37:51 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id OAA00542; Thu, 4 Jun 1998 14:33:02 -0600 (MDT) Date: Thu, 4 Jun 1998 14:33:02 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199806042033.OAA00542@narnia.plutotech.com> To: Zdenek Radouch cc: scsi@FreeBSD.ORG Subject: Re: buslogic problems Newsgroups: pluto.freebsd.scsi In-Reply-To: <199806030530.BAA17254@chmls05.mediaone.net> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199806030530.BAA17254@chmls05.mediaone.net> you wrote: > > I have the following problem. I recently switched from Linux to Freebsd on > one > of my old machines (386). Somehow, I installed 2.2.5 from a CD, rebuilt > the kernel > a few times and when everything looked tailored to my satisfaction I > noticed that > I can't use the CD any more (with either my new or the GENERIC kernel). > Everything else looks and runs fine. > When I try to mount a CD, I get a message "bt0: Try to abort" from > bt_timeout() > and keep getting them until I open the CD drive. Repeating "od /dev/cd0a" > sometimes gives me data, but usually results in the same timeout. You may want to try using the CAM SCSI patches. You will need to use 2.2-stable sources, but CAM does provide a better driver for the BusLogic cards: ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/README -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 5 10:27:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA04731 for freebsd-scsi-outgoing; Fri, 5 Jun 1998 10:27:04 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from unox.student.tue.nl (unox.student.tue.nl [131.155.210.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA04631 for ; Fri, 5 Jun 1998 10:26:34 -0700 (PDT) (envelope-from marijn@stack.nl) Received: from hoop.student.tue.nl (hoop.student.tue.nl [192.168.0.1]) by unox.student.tue.nl (8.9.0/8.8.8) with ESMTP id TAA00938 for ; Fri, 5 Jun 1998 19:26:29 +0200 Received: (from marijn@localhost) by hoop.student.tue.nl (8.8.7/8.8.3) id TAA01815; Fri, 5 Jun 1998 19:26:17 +0200 (CEST) Message-ID: <19980605192617.15017@hoop.student.tue.nl> Date: Fri, 5 Jun 1998 19:26:17 +0200 From: Marijn Meijles To: freebsd-scsi@FreeBSD.ORG Subject: SEEK command or locate tape position Reply-To: marijn@stack.nl Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hi, I just bought a HP-DAT drive. It works great, except for searching within archives. When I use Linux, there is a program called dds2tar that uses a MTSEEK call to position the heads within an archive so it can extract files very quickly. However, fbsd does not have this. Is there a patch that either implements a seek command or let's you read the current position of the heads? Oh, I use FreeBSD 2.2-STABLE. -- Marijn --- Waiting for inspiration is a big frustration To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 5 11:55:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA20072 for freebsd-scsi-outgoing; Fri, 5 Jun 1998 11:55:43 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA20043 for ; Fri, 5 Jun 1998 11:55:27 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id MAA07259; Fri, 5 Jun 1998 12:55:18 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806051855.MAA07259@panzer.plutotech.com> Subject: Re: SEEK command or locate tape position In-Reply-To: <19980605192617.15017@hoop.student.tue.nl> from Marijn Meijles at "Jun 5, 98 07:26:17 pm" To: marijn@stack.nl Date: Fri, 5 Jun 1998 12:55:18 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Marijn Meijles wrote... > hi, > > I just bought a HP-DAT drive. It works great, except for searching > within archives. When I use Linux, there is a program called dds2tar > that uses a MTSEEK call to position the heads within an archive so it > can extract files very quickly. However, fbsd does not have this. Is > there a patch that either implements a seek command or let's you read > the current position of the heads? > Oh, I use FreeBSD 2.2-STABLE. Hans Huebner is working on putting fast locate and read position support into the CAM tape driver. Once he finishes that work, it will be available in CAM. The CAM snapshots are released for both current and stable, so you'll be able to run them on your system. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 5 14:23:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA18615 for freebsd-scsi-outgoing; Fri, 5 Jun 1998 14:23:16 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from unox.student.tue.nl (unox.student.tue.nl [131.155.210.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18467 for ; Fri, 5 Jun 1998 14:22:42 -0700 (PDT) (envelope-from marijn@stack.nl) Received: from hoop.student.tue.nl (hoop.student.tue.nl [192.168.0.1]) by unox.student.tue.nl (8.9.0/8.8.8) with ESMTP id XAA01336; Fri, 5 Jun 1998 23:22:36 +0200 Received: (from marijn@localhost) by hoop.student.tue.nl (8.8.7/8.8.3) id XAA02050; Fri, 5 Jun 1998 23:22:24 +0200 (CEST) Message-ID: <19980605232223.55786@hoop.student.tue.nl> Date: Fri, 5 Jun 1998 23:22:23 +0200 From: Marijn Meijles To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SEEK command or locate tape position Reply-To: marijn@stack.nl References: <19980605192617.15017@hoop.student.tue.nl> <199806051855.MAA07259@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199806051855.MAA07259@panzer.plutotech.com>; from Kenneth D. Merry on Fri, Jun 05, 1998 at 12:55:18PM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Hans Huebner is working on putting fast locate > and read position support into the CAM tape driver. Once he finishes that > work, it will be available in CAM. The CAM snapshots are released for both > current and stable, so you'll be able to run them on your system. I looked at it, but I have a Tekram DC390 SCSI host which isn't supported. Is it really hard to 'port' a driver from the current stable tree? > > Ken -- Marijn --- There is a chance that today is the first of May To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 5 14:32:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20839 for freebsd-scsi-outgoing; Fri, 5 Jun 1998 14:32:36 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA20780 for ; Fri, 5 Jun 1998 14:32:14 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id PAA07961; Fri, 5 Jun 1998 15:32:06 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806052132.PAA07961@panzer.plutotech.com> Subject: Re: SEEK command or locate tape position In-Reply-To: <19980605232223.55786@hoop.student.tue.nl> from Marijn Meijles at "Jun 5, 98 11:22:23 pm" To: marijn@stack.nl Date: Fri, 5 Jun 1998 15:32:05 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Marijn Meijles wrote... > > > > Hans Huebner is working on putting fast locate > > and read position support into the CAM tape driver. Once he finishes that > > work, it will be available in CAM. The CAM snapshots are released for both > > current and stable, so you'll be able to run them on your system. > I looked at it, but I have a Tekram DC390 SCSI host which isn't supported. > Is it really hard to 'port' a driver from the current stable tree? I wouldn't recommend trying it unless you've had prior experience writing drivers. It isn't exactly a trivial task. I take it your card is one of the ones with the AMD 53c974 chip on board? From looking at Tekram's web page, it looks like some of their DC390 series boards are based on NCR/Symbios chips. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 6 12:14:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA08927 for freebsd-scsi-outgoing; Sat, 6 Jun 1998 12:14:31 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from unox.student.tue.nl (unox.student.tue.nl [131.155.210.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA08922 for ; Sat, 6 Jun 1998 12:14:27 -0700 (PDT) (envelope-from marijn@stack.nl) Received: (from marijn@localhost) by unox.student.tue.nl (8.9.0/8.8.8) id VAA02786; Sat, 6 Jun 1998 21:14:14 +0200 Message-ID: <19980606211414.65285@unox.student.tue.nl> Date: Sat, 6 Jun 1998 21:14:14 +0200 From: Marijn Meijles To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SEEK command or locate tape position Reply-To: marijn@stack.nl References: <19980605232223.55786@hoop.student.tue.nl> <199806052132.PAA07961@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <199806052132.PAA07961@panzer.plutotech.com>; from Kenneth D. Merry on Fri, Jun 05, 1998 at 03:32:05PM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You wrote: > > I wouldn't recommend trying it unless you've had prior experience > writing drivers. It isn't exactly a trivial task. > Well, I did it the other way around, I implemented the SEEK command in the stable kernel. A bit Q&D, but it works.... > I take it your card is one of the ones with the AMD 53c974 chip on > board? From looking at Tekram's web page, it looks like some of their > DC390 series boards are based on NCR/Symbios chips. > It's an AMD.. > Ken > -- > Kenneth Merry > ken@plutotech.com -- Marijn --- Getting up is merely a stage of going to bed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message