From owner-freebsd-scsi Sun Jun 6 6: 1:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from slarti.muc.de (slarti.muc.de [193.149.48.10]) by hub.freebsd.org (Postfix) with SMTP id B934114DE8 for ; Sun, 6 Jun 1999 06:01:18 -0700 (PDT) (envelope-from jhs@jhs.muc.de) Received: (qmail 16205 invoked from network); 6 Jun 1999 13:00:40 -0000 Received: from jhs.muc.de (193.149.49.84) by slarti.muc.de with SMTP; 6 Jun 1999 13:00:40 -0000 Received: (from jhs@localhost) by jhs.muc.de (8.9.3/8.9.3) id MAA06230; Sun, 6 Jun 1999 12:57:49 GMT (envelope-from jhs) Date: Sun, 6 Jun 1999 12:57:49 GMT Message-Id: <199906061257.MAA06230@jhs.muc.de> To: freebsd-scsi@freebsd.org Subject: sea driver - anyone porting from 2.2.8 to 3.?/current ? From: "Julian Stacey" Reply-To: "Julian Stacey" X-Net: jhs@muc.de jhs@freebsd.org www.jhs.muc.de www.freebsd.org/~jhs/ Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anyone thought about porting the sea driver from 2.2.8 to 3.* ? ( sea adapter is for Seagate ST01/ST02, Future Domain TMC-885, TMC-950 SCSI ) I upgraded a system from 2.2.8 to 3.2 only to find support for the controller had been removed :-( Now wasting time going back to 2.2.8 ! If customers or users of other OS's had been watching, they would have had a good laugh at FreeBSD; It's hard to convince people: "FreeBSD is nice, you should try it" when a valid response is "No Thanks - Maybe they'll feel free to abandon my hardware too" I guess SEA was deleted in the move to CAM, but that's not a justification, just a temporary excuse, & 2.2.8 to 3.2 is beyond temporary ! I'm not up to merging sea + cam, but I'll happily test any code anyone can lash up, & if no one else has a card, I can even find a spare card .... Help :-) PS please CC jhs@freebsd.org or jhs@jhs.muc.de, as I'm not on scsi@ (but can subscribe if someone wants to send patches to try, hopefully ! ) Julian H. Stacey http://www.freebsd.org/~jhs/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 6 8:42:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 8BDEE14F66; Sun, 6 Jun 1999 08:42:24 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id RAA26577; Sun, 6 Jun 1999 17:03:27 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id QAA74044; Sun, 6 Jun 1999 16:50:34 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199906061450.QAA74044@yedi.iaf.nl> Subject: Re: sea driver - anyone porting from 2.2.8 to 3.?/current ? In-Reply-To: <199906061257.MAA06230@jhs.muc.de> from Julian Stacey at "Jun 6, 1999 12:57:49 pm" To: jhs@FreeBSD.ORG Date: Sun, 6 Jun 1999 16:50:34 +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+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Julian Stacey wrote ... > Anyone thought about porting the sea driver from 2.2.8 to 3.* ? > ( sea adapter is for Seagate ST01/ST02, Future Domain TMC-885, TMC-950 SCSI ) > > I upgraded a system from 2.2.8 to 3.2 only to find support for the controller > had been removed :-( Now wasting time going back to 2.2.8 ! IRRC it is in the README somewhere.. > If customers or users of other OS's had been watching, they would have had a > good laugh at FreeBSD; It's hard to convince people: > "FreeBSD is nice, you should try it" > when a valid response is > "No Thanks - Maybe they'll feel free to abandon my hardware too" Just like any commercial vendor will do BTW. > I guess SEA was deleted in the move to CAM, but that's not a justification, > just a temporary excuse, & 2.2.8 to 3.2 is beyond temporary ! My guess is that Ken & Justin did not pull the sea driver into CAM because they A. did not have the hardware and B. think the hardware is not worth the time to do so anyway. | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 6 13:55:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (unknown [209.179.127.11]) by hub.freebsd.org (Postfix) with ESMTP id 31C9C15669; Sun, 6 Jun 1999 13:55:56 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.conference.usenix.org [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id NAA01685; Sun, 6 Jun 1999 13:53:28 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199906062053.NAA01685@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Julian Stacey" Cc: freebsd-scsi@freebsd.org Subject: Re: sea driver - anyone porting from 2.2.8 to 3.?/current ? In-reply-to: Your message of "Sun, 06 Jun 1999 12:57:49 GMT." <199906061257.MAA06230@jhs.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 Jun 1999 13:53:27 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If customers or users of other OS's had been watching, they would have had a > good laugh at FreeBSD; It's hard to convince people: > "FreeBSD is nice, you should try it" > when a valid response is > "No Thanks - Maybe they'll feel free to abandon my hardware too" The only laugh target here is you... -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ 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 Jun 6 14:32:27 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 031B614FD6; Sun, 6 Jun 1999 14:32:24 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA21341; Sun, 6 Jun 1999 15:32:23 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA01173; Sun, 6 Jun 1999 15:30:43 -0600 (MDT) Message-Id: <199906062130.PAA01173@harmony.village.org> To: "Julian Stacey" Subject: Re: sea driver - anyone porting from 2.2.8 to 3.?/current ? Cc: freebsd-scsi@FreeBSD.ORG In-reply-to: Your message of "Sun, 06 Jun 1999 12:57:49 GMT." <199906061257.MAA06230@jhs.muc.de> References: <199906061257.MAA06230@jhs.muc.de> Date: Sun, 06 Jun 1999 15:30:43 -0600 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199906061257.MAA06230@jhs.muc.de> "Julian Stacey" writes: : Anyone thought about porting the sea driver from 2.2.8 to 3.* ? I don't think so. I've not heard anything. There are only two drivers in progress right now that I'm aware of: aic and uha. While aic is being worked on, the uha driver is languishing. I've not had the time to work on it in some time, as there have been bigger fish to fry in my world (eg the pccard stuff, and many chores around the house). I wrote the probe code, then got distracted by other things. To be honest, I don't even think that the CAM team has even seen these cards in literally years, and I don't know what kind of hardware docs are still available. Still, it should be possible to port the old sea driver to cam if someone had the hardware and the motivation to do it... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 6 15: 5:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by hub.freebsd.org (Postfix) with ESMTP id E5CFA1503E; Sun, 6 Jun 1999 15:05:38 -0700 (PDT) (envelope-from se@dialup124.zpr.Uni-Koeln.DE) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.9.3) id XAA00500; Sun, 6 Jun 1999 23:16:14 +0200 (CEST) (envelope-from se) Date: Sun, 6 Jun 1999 23:16:14 +0200 From: Stefan Esser To: Nigel Roles Cc: freebsd-scsi@FreeBSD.ORG, Stefan Esser Subject: Re: Assertion in ncr.c Message-ID: <19990606231614.E326@dialup124.mi.uni-koeln.de> Reply-To: se@FreeBSD.ORG References: <199906040724.AAA23122@mailhub.Cadence.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199906040724.AAA23122@mailhub.Cadence.COM>; from Nigel Roles on Fri, Jun 04, 1999 at 08:18:27AM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-06-04 08:18 +0100, Nigel Roles wrote: > Kernel: RELENG_3 as of yesterday (and all previous versions) > Controller: Symbios 22910 (53c896 dual channel Ultra2 wide) > Problem: Assertion at line 5000 (first assertion in ncr_setsync()) Sorry, but the driver in RELENG_3 assumes a register to be available for SCRIPTS micro-code, which became a status register in the 895 and 896 chips. You have to use the driver as in -current (I can send diffs if you do not have a local CVS tree). I wanted to wait a little longer before I merge the Ultra-2 changes into -stable. (But if you find that the modifications work for you as well as they do for me, I'll commit them very soon, say next weekend ;-) Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 6 15:19:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 595FC1503E; Sun, 6 Jun 1999 15:19:08 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id QAA17451; Sun, 6 Jun 1999 16:19:07 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199906062219.QAA17451@panzer.plutotech.com> Subject: Re: sea driver - anyone porting from 2.2.8 to 3.?/current ? In-Reply-To: <199906061257.MAA06230@jhs.muc.de> from Julian Stacey at "Jun 6, 1999 12:57:49 pm" To: jhs@FreeBSD.ORG (Julian Stacey) Date: Sun, 6 Jun 1999 16:19:07 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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 [ I think Mike, Warner and Wilko have all said good things, but I think I should say something as well. ] Julian Stacey wrote... > Anyone thought about porting the sea driver from 2.2.8 to 3.* ? > ( sea adapter is for Seagate ST01/ST02, Future Domain TMC-885, TMC-950 SCSI ) > > I upgraded a system from 2.2.8 to 3.2 only to find support for the controller > had been removed :-( Now wasting time going back to 2.2.8 ! > > If customers or users of other OS's had been watching, they would have had a > good laugh at FreeBSD; It's hard to convince people: > "FreeBSD is nice, you should try it" > when a valid response is > "No Thanks - Maybe they'll feel free to abandon my hardware too" > > I guess SEA was deleted in the move to CAM, but that's not a justification, > just a temporary excuse, & 2.2.8 to 3.2 is beyond temporary ! All I can say is "where have you been for the past couple of years"?? More than a year before CAM was merged into the tree Justin and I made it clear that some SCSI adapters would not be supported. The length of time that those adapters would go unsupported would vary based on developer time to re-do the driver and developer time would probably be spent on cards that most people wanted to be supported. So it has been clear, probably from around the summer/fall of 1997 time frame that we would lose support for a number of cards when the CAM switchover happened. Believe it or not, you are the first person I've heard asking for the sea driver. That puts it way down on the list of things to do. > I'm not up to merging sea + cam, but I'll happily test any code anyone can lash > up, & if no one else has a card, I can even find a spare card .... There isn't any code that I know of, and isn't likely to be until someone with the: - knowledge - hardware - documentation - motivation to do the driver shows up. I don't know of anyone with all four of those, and until someone pops up with all of the above, the driver won't happen. The following drivers are more important, IMO, than the sea driver: - aic (Adpatec 6260/6360) - BusLogic Flashpoint - uha (UltraStor) We've just recently gotten the AMD 53c974 driver cleaned up and checked into the tree, so that one is off the list now. (it still needs error recovery work) Many thanks to the guys at Tekram for getting it ported to CAM. (And thanks to Justin for substantially cleaning it up.) People ask about the Flashpoint driver on a regular basis, and I suspect that that may be the first one of the three above to get done. (At this point, I know someone is going to mail me and ask about that driver. Don't. I'm tired of anwering questions about it, and you'll hear about it when something gets done on it.) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 6 22:58:46 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns1.portal2.com (ns1.portal2.com [203.85.226.193]) by hub.freebsd.org (Postfix) with SMTP id E8414156A4 for ; Sun, 6 Jun 1999 22:58:37 -0700 (PDT) (envelope-from yusufg@outblaze.com) Received: (qmail 11385 invoked from network); 7 Jun 1999 06:18:26 -0000 Received: from yusufg.portal2.com (203.85.226.249) by ns1.portal2.com with SMTP; 7 Jun 1999 06:18:26 -0000 Received: (qmail 22466 invoked by uid 500); 7 Jun 1999 05:58:31 -0000 Date: 7 Jun 1999 05:58:31 -0000 Message-ID: <19990607055831.22465.qmail@yusufg.portal2.com> From: Yusuf Goolamabbas To: freebsd-stable@freebsd.org Cc: freebsd-scsi@freebsd.org Subject: Are these untar times appropiate ? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 3.2-STABLE System: Dual P3/500 with 512MB RAM with Adapatec 2049U2W controller connected to two disks (9GB and 18GB). 18GB is a Seagate ST 318275LW camcontrol shows that this is capable of 80 MB/s with Tagged Queuing Enabled I have a tar file of around 1.6 GB. The directory tree is not very deep These are the times I am getting for untar the tar file on the 18GB disk. Also, times for rm -rf of the directory created Softupdates enabled Real User Sys untar: 13043.72 14.19 434.53 rm -rf 7036.8 8.05 172.84 I looked at the results from iostat in another virtual console and I was getting around 0.8 MB/s. Top was showing the machine mostly idle in CPU usage Mounting with async mode (single user mode) untar: 10799 13.17 462.69 rm -rf: 6537 7.82 259.64 The normal sync mode took quite a while also. I seem to have misplaced the numbers As a totally unscientific comparision. These are the untar times of glibc-2.1.1 on a softupate system glibc untar: 49 1 3.66 glibc rm -rf 2.06 0.05 0.88 Are these times appropiate ? Is there any way to make the untar go faster. What does 80 MB/s really mean in real-life ? Cheers, Yusuf -- Yusuf Goolamabbas yusufg@outblaze.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 7 11:40:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from clif.pcinternet.net (clif.pcinternet.net [209.203.111.6]) by hub.freebsd.org (Postfix) with ESMTP id B66ED152FE for ; Mon, 7 Jun 1999 11:40:51 -0700 (PDT) (envelope-from sysop@pcinternet.net) Received: from crap (rivbn02041.pcinternet.net [209.203.111.170]) by clif.pcinternet.net (2.5 Build 2639 (Berkeley 8.8.6)/8.8.4) with SMTP id LAA03182 for ; Mon, 07 Jun 1999 11:49:40 -0700 Message-Id: <4.1.19990607113211.00a20c20@mail.pcinternet.net> X-Sender: sysop@mail.pcinternet.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 Jun 1999 11:33:41 -0700 To: scsi@FreeBSD.ORG From: Joe Bissot Subject: AMI MegaRAID Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_36391448==_.ALT" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --=====================_36391448==_.ALT Content-Type: text/plain; charset="us-ascii" There was some talk here a while back about a driver for AMI MegaRAID controllers. Does anybody know what the current state of development is? ----------------------------------------- Joe Bissot - sysop@PCInternet.net Phone (909)307-2861 / Pager (909)265-3595 -- Trust the computer industry to shorten Year 2000 to Y2K. It was this thinking that caused the problem in the first place. --=====================_36391448==_.ALT Content-Type: text/html; charset="us-ascii" There was some talk here a while back about a driver for AMI MegaRAID controllers. Does anybody know what the current state of development is?
-----------------------------------------
Joe Bissot - sysop@PCInternet.net
Phone (909)307-2861 / Pager (909)265-3595
--
  Trust the computer industry to shorten Year 2000 to Y2K. It
  was this thinking that caused the problem in the first place. --=====================_36391448==_.ALT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 7 11:43:38 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from clif.pcinternet.net (clif.pcinternet.net [209.203.111.6]) by hub.freebsd.org (Postfix) with ESMTP id 278E81541F for ; Mon, 7 Jun 1999 11:43:35 -0700 (PDT) (envelope-from jblist@pcinternet.net) Received: from crap (rivbn02041.pcinternet.net [209.203.111.170]) by clif.pcinternet.net (2.5 Build 2639 (Berkeley 8.8.6)/8.8.4) with SMTP id LAA03193 for ; Mon, 07 Jun 1999 11:52:24 -0700 Message-Id: <4.1.19990607113622.00d26e10@mail.pcinternet.net> X-Sender: jblist@mail.pcinternet.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 Jun 1999 11:36:28 -0700 To: scsi@FreeBSD.ORG From: Joe Bissot Subject: AMI MegaRAID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org There was some talk here a while back about a driver for AMI MegaRAID controllers. Does anybody know what the current state of development is? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 7 13: 6:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp5.mindspring.com (smtp5.mindspring.com [207.69.200.82]) by hub.freebsd.org (Postfix) with ESMTP id 9023A14C57 for ; Mon, 7 Jun 1999 13:06:07 -0700 (PDT) (envelope-from stevensl@mindspring.net) Received: from freelove.mindspring.net (freelove.mindspring.net [207.69.192.92]) by smtp5.mindspring.com (8.8.5/8.8.5) with ESMTP id QAA08632 for ; Mon, 7 Jun 1999 16:06:05 -0400 (EDT) Date: Mon, 7 Jun 1999 16:10:32 -0400 (EDT) From: steven To: scsi@freebsd.org Subject: Invalid Pack w/ CAM (SCSI) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've seen the threads for awhile, i've experienced this since i went to 3.x, reguardless of version, except the pre-releases which didn't. It only happens with my secondary drive (seagate hawk 4.2 gig) and never my primary drive. I've been inclined to believe the source of the problem is the drives power requirements since it is a power hog. When i get the invalid pack error i can hear the drive spindown, then it usually recovers and spins back up but the os never seems to recover. Eventually it locks up. For a fluke i did some testing. I got the error twice in a row on a cold startup and then a warm reboot. Afterwards everything was fine for about a week. Cold startups, reboots etc. Nothing could shake it. Then it starts up again for no reason. I was running fsck on the drive after rebooting and saw this in the logs during the fsck... Jun 7 15:54:00 pangaea /kernel: (da1:ahc0:0:4:0): WRITE(06). CDB: a e 66 2b 2 0 Jun 7 15:54:00 pangaea /kernel: (da1:ahc0:0:4:0): WRITE(06). CDB: a e 66 2b 2 0 Jun 7 15:54:00 pangaea /kernel: (da1:ahc0:0:4:0): RECOVERED ERROR info:e662b asc:3,0 Jun 7 15:54:00 pangaea /kernel: (da1:ahc0:0:4:0): RECOVERED ERROR info:e662b asc:3,0 Jun 7 15:54:00 pangaea /kernel: (da1:ahc0:0:4:0): Peripheral device write fault field replaceable unit: 9 sks:80,1 Jun 7 15:54:00 pangaea /kernel: (da1:ahc0:0:4:0): Peripheral device write fault field replaceable unit: 9 sks:80,1 Jun 7 15:56:43 pangaea /kernel: (da1:ahc0:0:4:0): SCB 0x3d - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xc Jun 7 15:56:43 pangaea /kernel: (da1:ahc0:0:4:0): SCB 0x3d - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xc Jun 7 15:56:44 pangaea /kernel: (da1:ahc0:0:4:0): Queuing a BDR SCB Jun 7 15:56:44 pangaea /kernel: (da1:ahc0:0:4:0): Queuing a BDR SCB Jun 7 15:56:44 pangaea /kernel: (da1:ahc0:0:4:0): Bus Device Reset Message Sent Jun 7 15:56:44 pangaea /kernel: (da1:ahc0:0:4:0): Bus Device Reset Message Sent Jun 7 15:56:44 pangaea /kernel: (da1:ahc0:0:4:0): no longer in timeout, status = 353 Jun 7 15:56:44 pangaea /kernel: (da1:ahc0:0:4:0): no longer in timeout, status = 353 Jun 7 15:56:44 pangaea /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jun 7 15:56:44 pangaea /kernel: Unexpected busfree. LASTPHASE == 0xa0 Jun 7 15:56:44 pangaea /kernel: SEQADDR == 0x151 Jun 7 15:56:44 pangaea /kernel: SEQADDR == 0x151 is this of any help? anyone got any ideas on how to fix this? I've gone thru 2 powersupplies thinking thats the culprit on the drive timing out. I've replaced the cables, the terminations etc. I've got 3 devices in the chain and this is in the middle. I might put another drive in the middle to see if it happens again. ~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~ Steven S. linux.com freebsd.org gnustep.org stevensl@mindspring.net 403forbidden.net ~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~'~ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 7 13:25:37 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from slarti.muc.de (slarti.muc.de [193.149.48.10]) by hub.freebsd.org (Postfix) with SMTP id AFC4B14C36 for ; Mon, 7 Jun 1999 13:25:27 -0700 (PDT) (envelope-from jhs@jhs.muc.de) Received: (qmail 17088 invoked from network); 7 Jun 1999 20:24:43 -0000 Received: from jhs.muc.de (193.149.49.84) by slarti.muc.de with SMTP; 7 Jun 1999 20:24:43 -0000 Received: from wall.jhs.no_domain (localhost [127.0.0.1]) by jhs.muc.de (8.9.3/8.9.3) with ESMTP id SAA05421; Mon, 7 Jun 1999 18:00:52 GMT (envelope-from jhs@wall.jhs.no_domain) Message-Id: <199906071800.SAA05421@jhs.muc.de> To: "Wilko Bulte" , "Warner Losh" , "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: sea driver - anyone porting from 2.2.8 to 3.?/current ? From: "Julian Stacey" Reply-To: "Julian Stacey" X-Net: jhs@muc.de jhs@freebsd.org www.jhs.muc.de www.freebsd.org/~jhs/ In-reply-to: Your message of "Sun, 06 Jun 1999 16:50:34 +0200." <199906061450.QAA74044@yedi.iaf.nl> Date: Mon, 07 Jun 1999 20:00:50 +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks to "Kenneth D. Merry" "Warner Losh" "Kenneth D. Merry" For replies to my: > > Anyone thought about porting the sea driver from 2.2.8 to 3.* ? > > ( sea adapter is for Seagate ST01/ST02, Future Domain TMC-885, TMC-950 SCSI > From "Warner Losh" > To be honest, I don't even think that the CAM team has even seen these > cards in literally years, and I don't know what kind of hardware docs > are still available. Still, it should be possible to port the old sea > driver to cam if someone had the hardware and the motivation to do > it... I have a spare one in a drawer, I could post (OK, my 2 card aren't quite the same, but nearly), but yes the motivation is the problem. > From "Kenneth D. Merry" > All I can say is "where have you been for the past couple of years"?? Ah, well although I read the hatchet wielding plans from the CAM team, I also read the protests, & found it hard to believe such drastic hatchet work would actually happen. BTW Re. docu. I have a box (2 inch thick, PC style) of docu. but it's just user/DOS stuff, nothing useful; but I was surmising as it ran on 228, more docu wouldn't be necessary ? I doubt I'll ever get time to learn the new FreeBSD scsi, so that PC is doomed to stay 2.2.8, but thanks for taking time to reply folks :-) Julian Julian H. Stacey http://www.freebsd.org/~jhs/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 8 15:29:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 42E0715963 for ; Tue, 8 Jun 1999 15:29:33 -0700 (PDT) (envelope-from asteffes@broome.nuxi.com) Received: from broome.nuxi.com (d60-110.leach.ucdavis.edu [169.237.60.110]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id PAA10106 for ; Tue, 8 Jun 1999 15:29:32 -0700 (PDT) (envelope-from asteffes@broome.nuxi.com) Received: from localhost (localhost [127.0.0.1]) by broome.nuxi.com (8.9.3/8.9.1) with ESMTP id PAA47528 for ; Tue, 8 Jun 1999 15:29:32 -0700 (PDT) (envelope-from asteffes@broome.nuxi.com) Date: Tue, 8 Jun 1999 15:29:32 -0700 (PDT) From: Adam Steffes X-Sender: asteffes@localhost To: freebsd-scsi@freebsd.org Subject: Tekram SCSI cards 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 all. Is there any support right now, under 3.x or 4-C, for Tekram's UW-SCSI or U2W-SCSI cards? tekram.com says they are using Symbios 53C895, 53C141, 53C875, and AMD 53C974A, for various versions of SCSI, UltraSCSI, UW-SCSI, and U2W-SCSI cards. If support exists, or might occur soon, that would be great. These cards are a lot less expensive than Adaptec's offerings. Thanks! -Adam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 8 15:52:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 884E0150E3 for ; Tue, 8 Jun 1999 15:52:07 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id QAA31398; Tue, 8 Jun 1999 16:51:55 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199906082251.QAA31398@panzer.plutotech.com> Subject: Re: Tekram SCSI cards In-Reply-To: from Adam Steffes at "Jun 8, 1999 03:29:32 pm" To: asteffes@broome.nuxi.com (Adam Steffes) Date: Tue, 8 Jun 1999 16:51:55 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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 Adam Steffes wrote... > > Hi all. Is there any support right now, under 3.x or 4-C, for Tekram's > UW-SCSI or U2W-SCSI cards? tekram.com says they are using Symbios 53C895, > 53C141, 53C875, and AMD 53C974A, for various versions of SCSI, UltraSCSI, > UW-SCSI, and U2W-SCSI cards. > > If support exists, or might occur soon, that would be great. These cards > are a lot less expensive than Adaptec's offerings. The Symbios chips are all supported by the ncr driver, in FreeBSD 3.* and 4.0-current. The AMD 53c974 is supported by the amd driver, but *only* in -current at the moment. If you want support in 3.2-stable, bug Justin to merge it into -stable. You might also want to try a QLogic or Advansys board. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 9 0:58:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1]) by hub.freebsd.org (Postfix) with ESMTP id 70AF414E61 for ; Wed, 9 Jun 1999 00:58:54 -0700 (PDT) (envelope-from ngr@symbionics.co.uk) Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id AAA00461 for ; Wed, 9 Jun 1999 00:58:54 -0700 (PDT) Received: from symnt3.Cadence.COM(194.32.101.100) by mailgate.cadence.com via smap (mjr-v1.2) id xma928915132.000454; Wed, 9 Jun 99 00:58:52 -0700 Received: by symnt3.cadence.com with Internet Mail Service (5.5.2232.9) id ; Wed, 9 Jun 1999 08:55:50 +0100 Message-ID: <1E485299309FD211A2100090271E27A4143016@symnt3.cadence.com> From: Nigel Roles To: freebsd-scsi@FreeBSD.ORG Subject: RE: Tekram SCSI cards Date: Wed, 9 Jun 1999 08:55:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The 53c141 is the single-ended to LVDS auto converter, which with the right far end terminator allows LVDS and SE drives to be mixed without forcing the LVDS drives into SE. This is the case for the Tekram DC390U2W, but not the Tekram DC390U2B. So the 53c141 is not a SCSI chip, but a support chip. The 53c895 is the important bit. -----Original Message----- From: Adam Steffes [mailto:asteffes@broome.nuxi.com] Sent: Tuesday, June 08, 1999 11:30 PM To: freebsd-scsi@FreeBSD.ORG Subject: Tekram SCSI cards Hi all. Is there any support right now, under 3.x or 4-C, for Tekram's UW-SCSI or U2W-SCSI cards? tekram.com says they are using Symbios 53C895, 53C141, 53C875, and AMD 53C974A, for various versions of SCSI, UltraSCSI, UW-SCSI, and U2W-SCSI cards. If support exists, or might occur soon, that would be great. These cards are a lot less expensive than Adaptec's offerings. Thanks! -Adam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 9 5:32:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (nat192.211.mpoweredpc.net [142.177.192.211]) by hub.freebsd.org (Postfix) with ESMTP id 900CC14BD6; Wed, 9 Jun 1999 05:32:34 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA90919; Wed, 9 Jun 1999 09:32:52 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Wed, 9 Jun 1999 09:32:52 -0300 (ADT) From: The Hermit Hacker To: freebsd-stable@freebsd.org Cc: freebsd-scsi@freebsd.org Subject: System hangs...SCSI/CAM related? Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1313891218-928931572=:49155" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1313891218-928931572=:49155 Content-Type: TEXT/PLAIN; charset=US-ASCII Morning all... Late last week, I upgraded the INN news server running on my box to the latest code, due to major changes in the XOVER code. Within 12hrs or so, the system hung solid. You could ping it, but nothing else. Previous to the code upgrade, the server had been running consistently, and without problems, since its last reboot. I've included both the dmesg output, and the kernel config file I'm using, and, according to uname -rv: 3.2-STABLE FreeBSD 3.2-STABLE #0: Tue Jun 8 12:56:16 EDT 1999 Basically, my attitude has been that if my machine crashes or reboots, for whatever reason, take that day (its down anyway) to upgrade to the newest -STABLE release, just to catch any bugs/instabilities that may have been found since the last one. Now I'm getting these hangs almost like clockwork...every 24hrs or so. My impression has always been that a hang where you can still ping the machine is a SCSI problem, so that is why I'm CC'ng the SCSI mailing list... I have 11 SCSI drives on that machine...if its a drive problem, narrowing it down is going to be next to impossible without *some* sort of help from the operating system. I work in an exclusively Solaris shop at work, and one of the very nice things about Solaris is that it will at least give you WARNING messages if something appears off...if the machine is still pingable, and if I have a serial console up, and assuming that there is some sort of 'race condition' at work, is there no way of having the kernel issue a message to the console telling me that its having a problem talking to drive rdaXs1X? Something to indicate that there is a problem and which drive it suspects? Thanks... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org --0-1313891218-928931572=:49155 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=dmesg Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=dmesg Q29weXJpZ2h0IChjKSAxOTkyLTE5OTkgRnJlZUJTRCBJbmMuDQpDb3B5cmln aHQgKGMpIDE5ODIsIDE5ODYsIDE5ODksIDE5OTEsIDE5OTMNCglUaGUgUmVn ZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLg0KRnJlZUJTRCAzLjItU1RBQkxFICMwOiBUdWUgSnVu ICA4IDEyOjU2OjE2IEVEVCAxOTk5DQogICAgcm9vdEBodWIub3JnOi91c3Iv c3JjL3N5cy9jb21waWxlL2h1Yl9vcmcNClRpbWVjb3VudGVyICJpODI1NCIg IGZyZXF1ZW5jeSAxMTkzMTgyIEh6DQpUaW1lY291bnRlciAiVFNDIiAgZnJl cXVlbmN5IDQwMDkxMDkyMCBIeg0KQ1BVOiBQZW50aXVtIElJL1hlb24vQ2Vs ZXJvbiAoNDAwLjkxLU1IeiA2ODYtY2xhc3MgQ1BVKQ0KICBPcmlnaW4gPSAi R2VudWluZUludGVsIiAgSWQgPSAweDY1MiAgU3RlcHBpbmc9Mg0KICBGZWF0 dXJlcz0weDE4M2Y5ZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNF LENYOCxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LE1NWCw8YjI0 Pj4NCnJlYWwgbWVtb3J5ICA9IDQwMjY1MzE4NCAoMzkzMjE2SyBieXRlcykN CmF2YWlsIG1lbW9yeSA9IDM4ODkxNTIwMCAoMzc5ODAwSyBieXRlcykNClBy ZWxvYWRlZCBlbGYga2VybmVsICJrZXJuZWwiIGF0IDB4YzAyYTgwMDAuDQpQ cm9iaW5nIGZvciBkZXZpY2VzIG9uIFBDSSBidXMgMDoNCmNoaXAwOiA8SW50 ZWwgODI0NDNCWCBob3N0IHRvIFBDSSBicmlkZ2U+IHJldiAweDAyIG9uIHBj aTAuMC4wDQpjaGlwMTogPEludGVsIDgyNDQzQlggaG9zdCB0byBBR1AgYnJp ZGdlPiByZXYgMHgwMiBvbiBwY2kwLjEuMA0KY2hpcDI6IDxJbnRlbCA4MjM3 MUFCIFBDSSB0byBJU0EgYnJpZGdlPiByZXYgMHgwMiBvbiBwY2kwLjQuMA0K Y2hpcDM6IDxJbnRlbCA4MjM3MUFCIFBvd2VyIG1hbmFnZW1lbnQgY29udHJv bGxlcj4gcmV2IDB4MDIgb24gcGNpMC40LjMNCmFoYzA6IDxBZGFwdGVjIDI5 NDAgVWx0cmEgU0NTSSBhZGFwdGVyPiByZXYgMHgwMSBpbnQgYSBpcnEgMTQg b24gcGNpMC45LjANCmFoYzA6IGFpYzc4ODAgV2lkZSBDaGFubmVsIEEsIFND U0kgSWQ9NywgMTYvMjU1IFNDQnMNCmFoYzE6IDxBZGFwdGVjIDI5NDAgVWx0 cmEgU0NTSSBhZGFwdGVyPiByZXYgMHgwMSBpbnQgYSBpcnEgMTUgb24gcGNp MC4xMC4wDQphaGMxOiBhaWM3ODgwIFdpZGUgQ2hhbm5lbCBBLCBTQ1NJIElk PTcsIDE2LzI1NSBTQ0JzDQp4bDA6IDwzQ29tIDNjOTA1LVRYIEZhc3QgRXRo ZXJsaW5rIFhMPiByZXYgMHgwMCBpbnQgYSBpcnEgMTIgb24gcGNpMC4xMS4w DQp4bDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjYwOjA4OmM4OjM2OjA1DQp4 bDA6IGF1dG9uZWcgbm90IGNvbXBsZXRlLCBubyBjYXJyaWVyIChmb3JjaW5n IGhhbGYtZHVwbGV4LCAxME1icHMpDQp4bDE6IDwzQ29tIDNjOTA1LVRYIEZh c3QgRXRoZXJsaW5rIFhMPiByZXYgMHgwMCBpbnQgYSBpcnEgMTAgb24gcGNp MC4xMi4wDQp4bDE6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjYwOjk3OmQwOjNj OmY1DQp4bDE6IGF1dG9uZWcgY29tcGxldGUsIGxpbmsgc3RhdHVzIGdvb2Qg KGhhbGYtZHVwbGV4LCAxME1icHMpDQpQcm9iaW5nIGZvciBkZXZpY2VzIG9u IFBDSSBidXMgMToNCnZnYTA6IDxTMyBtb2RlbCA4OTA0IGdyYXBoaWNzIGFj Y2VsZXJhdG9yPiByZXYgMHgwMSBpbnQgYSBpcnEgMTAgb24gcGNpMS4wLjAN ClByb2JpbmcgZm9yIFBuUCBkZXZpY2VzOg0KQ1NOIDEgVmVuZG9yIElEOiBV TUM5MDA4IFsweDA4OTBhMzU1XSBTZXJpYWwgMHhhYjhkMWFmMCBDb21wIElE OiBQTlA4MGQ2IFsweGQ2ODBkMDQxXQ0KZWQxOiBhZGRyZXNzIDAwOmMwOmYw OjFhOjhkOmFiLCB0eXBlIE5FMjAwMCAoMTYgYml0KSANCmVkMSAoZWRwbnAg PE5FMjAwMD4gc24gMHhhYjhkMWFmMCkgYXQgMHgyMjAtMHgyM2YgaXJxIDEx IG9uIGlzYQ0KUHJvYmluZyBmb3IgZGV2aWNlcyBvbiB0aGUgSVNBIGJ1czoN CnNjMCBvbiBpc2ENCnNjMDogVkdBIGNvbG9yIDw0IHZpcnR1YWwgY29uc29s ZXMsIGZsYWdzPTB4MD4NCmVkMCBub3QgZm91bmQgYXQgMHgyODANCmF0a2Jk YzAgYXQgMHg2MC0weDZmIG9uIG1vdGhlcmJvYXJkDQphdGtiZDAgaXJxIDEg b24gaXNhDQpzaW8wIGF0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAg b24gaXNhDQpzaW8wOiB0eXBlIDE2NTUwQSwgY29uc29sZQ0KZmRjMCBhdCAw eDNmMC0weDNmNyBpcnEgNiBkcnEgMiBvbiBpc2ENCmZkYzA6IEZJRk8gZW5h YmxlZCwgOCBieXRlcyB0aHJlc2hvbGQNCmZkMDogMS40NE1CIDMuNWluDQp2 Z2EwIGF0IDB4M2IwLTB4M2RmIG1hZGRyIDB4YTAwMDAgbXNpemUgMTMxMDcy IG9uIGlzYQ0KbnB4MCBvbiBtb3RoZXJib2FyZA0KbnB4MDogSU5UIDE2IGlu dGVyZmFjZQ0KSVAgcGFja2V0IGZpbHRlcmluZyBpbml0aWFsaXplZCwgZGl2 ZXJ0IGVuYWJsZWQsIHJ1bGUtYmFzZWQgZm9yd2FyZGluZyBkaXNhYmxlZCwg ZGVmYXVsdCB0byBhY2NlcHQsIGxvZ2dpbmcgbGltaXRlZCB0byAxMDAgcGFj a2V0cy9lbnRyeQ0KV2FpdGluZyAyIHNlY29uZHMgZm9yIFNDU0kgZGV2aWNl cyB0byBzZXR0bGUNCmNkYTQgYXQgYWhjMCBidXMgMCB0YXJnZXQgNSBsdW4g MA0KZGE0OiA8UVVBTlRVTSBYUDM0NTUwVyBMWUs4PiBGaXhlZCBEaXJlY3Qg QWNjZXNzIFNDU0ktMiBkZXZpY2UgDQpkYTQ6IDQwLjAwME1CL3MgdHJhbnNm ZXJzICgyMC4wMDBNSHosIG9mZnNldCA4LCAxNmJpdCksIFRhZ2dlZCBRdWV1 ZWluZyBFbmFibGVkDQpkYTQ6IDQzNDFNQiAoODg5MDc2MCA1MTIgYnl0ZSBz ZWN0b3JzOiAyNTVIIDYzUy9UIDU1M0MpDQpkYTMgYXQgYWhjMCBidXMgMCB0 YXJnZXQgNCBsdW4gMA0KZGEzOiA8Q09NUEFRIERHSFMwOVkgMDFDMD4gRml4 ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTMgZGV2aWNlIA0KZGEzOiA0MC4wMDBN Qi9zIHRyYW5zZmVycyAoMjAuMDAwTUh6LCBvZmZzZXQgOCwgMTZiaXQpLCBU YWdnZWQgUXVldWVpbmcgRW5hYmxlZA0KZGEzOiA4Njc4TUIgKDE3NzczNTAw IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgMTEwNkMpDQpkYTEwIGF0 IGFoYzEgYnVzIDAgdGFyZ2V0IDUgbHVuIDANCmRhMTA6IDxRdWFudHVtIFhQ MzQzMDAgTDkxMj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTIgZGV2aWNl IA0KZGExMDogNS4wMDBNQi9zIHRyYW5zZmVycyAoNS4wMDBNSHosIG9mZnNl dCAxNSksIFRhZ2dlZCBRdWV1ZWluZyBFbmFibGVkDQpkYTEwOiA0MTAxTUIg KDgzOTk1MjAgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCA1MjJDKQ0K ZGE1IGF0IGFoYzAgYnVzIDAgdGFyZ2V0IDYgbHVuIDANCmRhNTogPFFVQU5U VU0gWFAzNDU1MFcgTFlLOD4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTIg ZGV2aWNlIA0KZGE1OiA0MC4wMDBNQi9zIHRyYW5zZmVycyAoMjAuMDAwTUh6 LCBvZmZzZXQgOCwgMTZiaXQpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxlZA0K ZGE1OiA0MzQxTUIgKDg4OTA3NjAgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2 M1MvVCA1NTNDKQ0KZGE4IGF0IGFoYzEgYnVzIDAgdGFyZ2V0IDIgbHVuIDAN CmRhODogPFFVQU5UVU0gWFAzNDMwMSAxMDcxPiBGaXhlZCBEaXJlY3QgQWNj ZXNzIFNDU0ktMiBkZXZpY2UgDQpkYTg6IDUuMDAwTUIvcyB0cmFuc2ZlcnMg KDUuMDAwTUh6LCBvZmZzZXQgMTUpLCBUYWdnZWQgUXVldWVpbmcgRW5hYmxl ZA0KZGE4OiA0MTA2TUIgKDg0MTAyMDAgNTEyIGJ5dGUgc2VjdG9yczogMjU1 SCA2M1MvVCA1MjNDKQ0KZGE5IGF0IGFoYzEgYnVzIDAgdGFyZ2V0IDQgbHVu IDANCmRhOTogPFFVQU5UVU0gWFAzNDMwMSAxMDcxPiBGaXhlZCBEaXJlY3Qg QWNjZXNzIFNDU0ktMiBkZXZpY2UgDQpkYTk6IDUuMDAwTUIvcyB0cmFuc2Zl cnMgKDUuMDAwTUh6LCBvZmZzZXQgMTUpLCBUYWdnZWQgUXVldWVpbmcgRW5h YmxlZA0KZGE5OiA0MTA2TUIgKDg0MTAyMDAgNTEyIGJ5dGUgc2VjdG9yczog MjU1SCA2M1MvVCA1MjNDKQ0KZGExIGF0IGFoYzAgYnVzIDAgdGFyZ2V0IDEg bHVuIDANCmRhMTogPENPTVBBUSBER0hTMThZIDAxQTA+IEZpeGVkIERpcmVj dCBBY2Nlc3MgU0NTSS0zIGRldmljZSANCmRhMTogNDAuMDAwTUIvcyB0cmFu c2ZlcnMgKDIwLjAwME1Ieiwgb2Zmc2V0IDgsIDE2Yml0KSwgVGFnZ2VkIFF1 ZXVlaW5nIEVuYWJsZWQNCmRhMTogMTczNjZNQiAoMzU1NjYwMDAgNTEyIGJ5 dGUgc2VjdG9yczogMjU1SCA2M1MvVCAyMjEzQykNCmRhNyBhdCBhaGMxIGJ1 cyAwIHRhcmdldCAxIGx1biAwDQpkYTc6IDxRVUFOVFVNIFhQMzQzMDEgMTA3 MT4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTIgZGV2aWNlIA0KZGE3OiA1 LjAwME1CL3MgdHJhbnNmZXJzICg1LjAwME1Ieiwgb2Zmc2V0IDE1KSwgVGFn Z2VkIFF1ZXVlaW5nIEVuYWJsZWQNCmRhNzogNDEwNk1CICg4NDEwMjAwIDUx MiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgNTIzQykNCmRhMiBhdCBhaGMw IGJ1cyAwIHRhcmdldCAyIGx1biAwDQpkYTI6IDxTRUFHQVRFIFNUMTUyMzBX IDA2Mzg+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0yIGRldmljZSANCmRh MjogMjAuMDAwTUIvcyB0cmFuc2ZlcnMgKDEwLjAwME1Ieiwgb2Zmc2V0IDgs IDE2Yml0KSwgVGFnZ2VkIFF1ZXVlaW5nIEVuYWJsZWQNCmRhMjogNDA5NU1C ICg4Mzg2NzMzIDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgNTIyQykN CmRhMCBhdCBhaGMwIGJ1cyAwIHRhcmdldCAwIGx1biAwDQpkYTA6IDxRVUFO VFVNIFZJS0lORyBJSSA0LjVXU0UgMzUwNj4gRml4ZWQgRGlyZWN0IEFjY2Vz cyBTQ1NJLTIgZGV2aWNlIA0KZGEwOiA0MC4wMDBNQi9zIHRyYW5zZmVycyAo MjAuMDAwTUh6LCBvZmZzZXQgOCwgMTZiaXQpLCBUYWdnZWQgUXVldWVpbmcg RW5hYmxlZA0KZGEwOiA0MzUwTUIgKDg5MTA0MjMgNTEyIGJ5dGUgc2VjdG9y czogMjU1SCA2M1MvVCA1NTRDKQ0KZGE2IGF0IGFoYzAgYnVzIDAgdGFyZ2V0 IDggbHVuIDANCmRhNjogPFNFQUdBVEUgU1QzOTEwMkxXIDAwMDQ+IEZpeGVk IERpcmVjdCBBY2Nlc3MgU0NTSS0yIGRldmljZSANCmRhNjogNDAuMDAwTUIv cyB0cmFuc2ZlcnMgKDIwLjAwME1Ieiwgb2Zmc2V0IDgsIDE2Yml0KSwgVGFn Z2VkIFF1ZXVlaW5nIEVuYWJsZWQNCmRhNjogODY4M01CICgxNzc4MzI0MCA1 MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDExMDZDKQ0KaGFuZ2luZyBy b290IGRldmljZSB0byBkYTBzMWENCg0K --0-1313891218-928931572=:49155 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=config Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=config bWFjaGluZQkJImkzODYiDQpjcHUJCSJJNjg2X0NQVSIJCSMgYWthIFBlbnRp dW0gUHJvKHRtKQ0KaWRlbnQJCWh1Yl9vcmcNCg0KbWF4dXNlcnMJMTI4DQoN CmNvbmZpZwkJa2VybmVsCXJvb3Qgb24gZGEwIA0KDQpvcHRpb25zCQlOTUJD TFVTVEVSUz0yMDQ4DQpvcHRpb25zCQkiTUFYRFNJWj0oMTAyNCoxMDI0KjEw MjQpIg0Kb3B0aW9ucwkJIkRGTERTSVo9KDEwMjQqMTAyNCoxMDI0KSINCm9w dGlvbnMgICAgICAgICBJTkNMVURFX0NPTkZJR19GSUxFICAgICAjIEluY2x1 ZGUgdGhpcyBmaWxlIGluIGtlcm5lbA0Kb3B0aW9ucwkJIkNQVV9ESVNBQkxF XzVYODZfTFNTRVIiDQpvcHRpb25zCQkiQ1BVX0ZBU1RFUl81WDg2X0ZQVSIN Cm9wdGlvbnMJCSJOT19GMDBGX0hBQ0siDQpvcHRpb25zCQkiQ09NUEFUXzQz Ig0Kb3B0aW9ucwkJU1lTVlNITQ0Kb3B0aW9ucwkJU1lTVlNFTQ0Kb3B0aW9u cwkJU1lTVk1TRw0Kb3B0aW9ucwkJS1RSQUNFCQkJI2tlcm5lbCB0cmFjaW5n DQpvcHRpb25zCQlJTkVUCQkJI0ludGVybmV0IGNvbW11bmljYXRpb25zIHBy b3RvY29scw0KDQpwc2V1ZG8tZGV2aWNlCWV0aGVyCQkJI0dlbmVyaWMgRXRo ZXJuZXQNCnBzZXVkby1kZXZpY2UJbG9vcAkJCSNOZXR3b3JrIGxvb3BiYWNr IGRldmljZQ0KcHNldWRvLWRldmljZQlicGZpbHRlcgk0CSNCZXJrZWxleSBw YWNrZXQgZmlsdGVyDQoNCiMgTVJPVVRJTkcgZW5hYmxlcyB0aGUga2VybmVs IG11bHRpY2FzdCBwYWNrZXQgZm9yd2FyZGVyLCB3aGljaCB3b3Jrcw0KIyB3 aXRoIG1yb3V0ZWQoOCkuDQojDQojIElQRklSRVdBTEwgZW5hYmxlcyBzdXBw b3J0IGZvciBJUCBmaXJld2FsbCBjb25zdHJ1Y3Rpb24sIGluDQojIGNvbmp1 bmN0aW9uIHdpdGggdGhlIGBpcGZ3JyBwcm9ncmFtLiAgSVBGSVJFV0FMTF9W RVJCT1NFIHNlbmRzDQojIGxvZ2dlZCBwYWNrZXRzIHRvIHRoZSBzeXN0ZW0g bG9nZ2VyLiAgSVBGSVJFV0FMTF9WRVJCT1NFX0xJTUlUDQojIGxpbWl0cyB0 aGUgbnVtYmVyIG9mIHRpbWVzIGEgbWF0Y2hpbmcgZW50cnkgY2FuIGJlIGxv Z2dlZC4NCiMNCiMgV0FSTklORzogIElQRklSRVdBTEwgZGVmYXVsdHMgdG8g YSBwb2xpY3kgb2YgImRlbnkgaXAgZnJvbSBhbnkgdG8gYW55Ig0KIyBhbmQg aWYgeW91IGRvIG5vdCBhZGQgb3RoZXIgcnVsZXMgZHVyaW5nIHN0YXJ0dXAg dG8gYWxsb3cgYWNjZXNzLA0KIyBZT1UgV0lMTCBMT0NLIFlPVVJTRUxGIE9V VC4gIEl0IGlzIHN1Z2dlc3RlZCB0aGF0IHlvdSBzZXQgZmlyZXdhbGw9b3Bl bg0KIyBpbiAvZXRjL3JjLmNvbmYgd2hlbiBmaXJzdCBlbmFibGluZyB0aGlz IGZlYXR1cmUsIHRoZW4gcmVmaW5pbmcgdGhlDQojIGZpcmV3YWxsIHJ1bGVz IGluIC9ldGMvcmMuZmlyZXdhbGwgYWZ0ZXIgeW91J3ZlIHRlc3RlZCB0aGF0 IHRoZSBuZXcga2VybmVsDQojIGZlYXR1cmUgd29ya3MgcHJvcGVybHkuDQoj DQojIElQRklSRVdBTExfREVGQVVMVF9UT19BQ0NFUFQgY2F1c2VzIHRoZSBk ZWZhdWx0IHJ1bGUgKGF0IGJvb3QpIHRvDQojIGFsbG93IGV2ZXJ5dGhpbmcu ICBVc2Ugd2l0aCBjYXJlLCBpZiBhIGNyYWNrZXIgY2FuIGNyYXNoIHlvdXIN CiMgZmlyZXdhbGwgbWFjaGluZSwgdGhleSBjYW4gZ2V0IHRvIHlvdXIgcHJv dGVjdGVkIG1hY2hpbmVzLiAgSG93ZXZlciwNCiMgaWYgeW91IGFyZSB1c2lu ZyBpdCBhcyBhbiBhcy1uZWVkZWQgZmlsdGVyIGZvciBzcGVjaWZpYyBwcm9i bGVtcyBhcw0KIyB0aGV5IGFyaXNlLCB0aGVuIHRoaXMgbWF5IGJlIGZvciB5 b3UuICBDaGFuZ2luZyB0aGUgZGVmYXVsdCB0byAnYWxsb3cnDQojIG1lYW5z IHRoYXQgeW91IHdvbid0IGdldCBzdHVjayBpZiB0aGUga2VybmVsIGFuZCAv c2Jpbi9pcGZ3IGJpbmFyeSBnZXQNCiMgb3V0IG9mIHN5bmMuDQojDQojIElQ RElWRVJUIGVuYWJsZXMgdGhlIGRpdmVydCBJUCBzb2NrZXRzLCB1c2VkIGJ5 IGBgaXBmdyBkaXZlcnQnJw0KIw0KIyBUQ1BERUJVRyBpcyB1bmRvY3VtZW50 ZWQuDQojDQpvcHRpb25zCQlNUk9VVElORwkJIyBNdWx0aWNhc3Qgcm91dGlu Zw0Kb3B0aW9ucyAgICAgICAgIElQRklSRVdBTEwgICAgICAgICAgICAgICNm aXJld2FsbA0Kb3B0aW9ucyAgICAgICAgIElQRklSRVdBTExfVkVSQk9TRSAg ICAgICNwcmludCBpbmZvcm1hdGlvbiBhYm91dA0KCQkJCQkjIGRyb3BwZWQg cGFja2V0cw0Kb3B0aW9ucwkJIklQRklSRVdBTExfVkVSQk9TRV9MSU1JVD0x MDAiICNsaW1pdCB2ZXJib3NpdHkNCm9wdGlvbnMJCUlQRklSRVdBTExfREVG QVVMVF9UT19BQ0NFUFQgI2FsbG93IGV2ZXJ5dGhpbmcgYnkgZGVmYXVsdA0K b3B0aW9ucwkJSVBESVZFUlQJCSNkaXZlcnQgc29ja2V0cw0KDQpvcHRpb25z CQlGRlMJCQkjRmFzdCBmaWxlc3lzdGVtDQpvcHRpb25zCQlORlMJCQkjTmV0 d29yayBGaWxlIFN5c3RlbQ0KDQpvcHRpb25zCQlQUk9DRlMJCQkjUHJvY2Vz cyBmaWxlc3lzdGVtDQpvcHRpb25zCQlGRlNfUk9PVAkJI0ZGUyB1c2FibGUg YXMgcm9vdCBkZXZpY2UNCg0KIyBBbGxvdyB0aGlzIG1hbnkgc3dhcC1kZXZp Y2VzLg0Kb3B0aW9ucwkJTlNXQVBERVY9MTENCg0Kb3B0aW9ucwkJUVVPVEEJ CQkjZW5hYmxlIGRpc2sgcXVvdGFzDQoNCmNvbnRyb2xsZXIJc2NidXMwCSNi YXNlIFNDU0kgY29kZQ0KZGV2aWNlCQlwYXNzMA0KDQpkZXZpY2UJCWRhMAkj U0NTSSBkaXNrcw0KDQpvcHRpb25zCQlTQ1NJX1JFUE9SVF9HRU9NRVRSWQ0K DQpwc2V1ZG8tZGV2aWNlCXB0eQkyNTYJI1BzZXVkbyB0dHlzIC0gY2FuIGdv IGFzIGhpZ2ggYXMgMjU2DQoNCmNvbnRyb2xsZXIJaXNhMA0KDQojIEVuYWJs ZSBQblAgc3VwcG9ydCBpbiB0aGUga2VybmVsLiAgVGhpcyBhbGxvd3MgeW91 IHRvIGF1dG9tYXRpY2x5DQojIGF0dGFjaCB0byBQblAgY2FyZHMgZm9yIGRy aXZlcnMgdGhhdCBzdXBwb3J0IGl0IGFuZCBhbGxvd3MgeW91IHRvDQojIGNv bmZpZ3VyZSBjYXJkcyBmcm9tIFVTRVJDT05GSUcuICBTZWUgcG5wKDQpIGZv ciBtb3JlIGluZm8uDQpjb250cm9sbGVyCXBucDANCg0KIyBUaGUgc3lzY29u cyBjb25zb2xlIGRyaXZlciAoc2NvIGNvbG9yIGNvbnNvbGUgY29tcGF0aWJs ZSkuDQogDQpjb250cm9sbGVyICAgICAgYXRrYmRjMCBhdCBpc2E/IHBvcnQg SU9fS0JEIHR0eSANCmRldmljZSAgICAgICAgICBhdGtiZDAgIGF0IGlzYT8g dHR5IGlycSAxIA0KZGV2aWNlICAgICAgICAgIHZnYTAgICAgYXQgaXNhPyBw b3J0ID8gY29uZmxpY3RzIA0KZGV2aWNlICAgICAgICAgIHNjMCAgICAgYXQg aXNhPyB0dHkgDQpwc2V1ZG8tZGV2aWNlICAgc3BsYXNoIA0KDQpvcHRpb25z CQlNQVhDT05TPTQJCSMgbnVtYmVyIG9mIHZpcnR1YWwgY29uc29sZXMNCm9w dGlvbnMJCSJTVEQ4WDE2Rk9OVCIJCSMgQ29tcGlsZSBmb250IGluDQptYWtl b3B0aW9ucwkiU1REOFgxNkZPTlQiPSJjcDg1MCINCm9wdGlvbnMJCVNDX0hJ U1RPUllfU0laRT0yMDAJIyBudW1iZXIgb2YgaGlzdG9yeSBidWZmZXIgbGlu ZXMNCg0KIyBUaGUgTnVtZXJpYyBQcm9jZXNzaW5nIGVYdGVuc2lvbiBkcml2 ZXIuICBUaGlzIHNob3VsZCBiZSBjb25maWd1cmVkIGlmDQojIHlvdXIgbWFj aGluZSBoYXMgYSBtYXRoIGNvLXByb2Nlc3NvciwgdW5sZXNzIHRoZSBjb3By b2Nlc3NvciBpcyB2ZXJ5DQojIGJ1Z2d5LiBJZiBpdCBpcyBub3QgY29uZmln dXJlZCB0aGVuIHlvdSAqbXVzdCogY29uZmlndXJlIG1hdGggZW11bGF0aW9u DQojIChzZWUgYWJvdmUpLiAgSWYgYm90aCBucHgwIGFuZCBlbXVsYXRpb24g YXJlIGNvbmZpZ3VyZWQsIHRoZW4gb25seSBucHgwDQojIGlzIHVzZWQgKHBy b3ZpZGVkIGl0IHdvcmtzKS4NCmRldmljZQkJbnB4MAlhdCBpc2E/IHBvcnQg IklPX05QWCIgaW9zaXogMHgwIGZsYWdzIDB4MCBpcnEgMTMgdmVjdG9yIG5w eGludHINCg0KIyBTdGFuZGFyZCBmbG9wcHkgZGlzayBjb250cm9sbGVycyBh bmQgZmxvcHB5IHRhcGVzOiBgZmRjJywgYGZkJywgYW5kIGBmdCcNCiMNCmNv bnRyb2xsZXIJZmRjMAlhdCBpc2E/IHBvcnQgIklPX0ZEMSIgYmlvIGlycSA2 IGRycSAyIHZlY3RvciBmZGludHINCmRpc2sJCWZkMAlhdCBmZGMwIGRyaXZl IDANCiNkaXNrCQlmZDEJYXQgZmRjMCBkcml2ZSAxDQoNCiNjb250cm9sbGVy ICAgICAgcHBidXMwDQojZGV2aWNlCQlscHQwCWF0IGlzYT8gcG9ydD8gdHR5 IGlycSA3IHZlY3RvciBscHRpbnRyDQoNCmRldmljZQkJc2lvMAlhdCBpc2E/ IHBvcnQgIklPX0NPTTEiIHR0eSBmbGFncyAweDEwIGlycSA0IHZlY3RvciBz aW9pbnRyDQoNCiMNCiMgYGZsYWdzJyBmb3Igc2VyaWFsIGRyaXZlcnMgdGhh dCBzdXBwb3J0IGNvbnNvbGVzIChvbmx5IGZvciBzaW8gbm93KToNCiMJMHgx MAllbmFibGUgY29uc29sZSBzdXBwb3J0IGZvciB0aGlzIHVuaXQuICBUaGUg b3RoZXIgY29uc29sZSBmbGFncw0KIwkJYXJlIGlnbm9yZWQgdW5sZXNzIHRo aXMgaXMgc2V0LiAgRW5hYmxpbmcgY29uc29sZSBzdXBwb3J0IGRvZXMNCiMJ CW5vdCBtYWtlIHRoZSB1bml0IHRoZSBwcmVmZXJyZWQgY29uc29sZSAtIGJv b3Qgd2l0aCAtaCBvciBzZXQNCiMJCXRoZSAweDIwIGZsYWcgZm9yIHRoYXQu ICBDdXJyZW50bHksIGF0IG1vc3Qgb25lIHVuaXQgY2FuIGhhdmUNCiMJCWNv bnNvbGUgc3VwcG9ydDsgdGhlIGZpcnN0IG9uZSAoaW4gY29uZmlnIGZpbGUg b3JkZXIpIHdpdGgNCiMJCXRoaXMgZmxhZyBzZXQgaXMgcHJlZmVycmVkLiAg U2V0dGluZyB0aGlzIGZsYWcgZm9yIHNpbzAgZ2l2ZXMNCiMJCXRoZSBvbGQg YmVoYXZpb3VyLg0KIwkweDIwCWZvcmNlIHRoaXMgdW5pdCB0byBiZSB0aGUg Y29uc29sZSAodW5sZXNzIHRoZXJlIGlzIGFub3RoZXINCiMJCWhpZ2hlciBw cmlvcml0eSBjb25zb2xlKS4gIFRoaXMgcmVwbGFjZXMgdGhlIENPTUNPTlNP TEUgb3B0aW9uLg0KIwkweDQwCXJlc2VydmUgdGhpcyB1bml0IGZvciBsb3cg bGV2ZWwgY29uc29sZSBvcGVyYXRpb25zLiAgRG8gbm90DQojDQojIFBuUCBg ZmxhZ3MnIChzZXQgdmlhIHVzZXJjb25maWcgdXNpbmcgcG5wIHggZmxhZ3Mg eSkNCiMJMHgxCWRpc2FibGUgcHJvYmluZyBvZiB0aGlzIGRldmljZS4gIFVz ZWQgdG8gcHJldmVudCB5b3VyIG1vZGVtDQojCQlmcm9tIGJlaW5nIGF0dGFj aGVkIGFzIGEgUG5QIG1vZGVtLg0KIw0KDQpvcHRpb25zCQlDT05TUEVFRD05 NjAwCSNkZWZhdWx0IHNwZWVkIGZvciBzZXJpYWwgY29uc29sZSAoZGVmYXVs dCA5NjAwKQ0Kb3B0aW9ucwkJIkVYVFJBX1NJTz0yIgkjbnVtYmVyIG9mIGV4 dHJhIHNpbyBwb3J0cyB0byBhbGxvY2F0ZQ0KDQojIFBDSSBkZXZpY2VzOg0K Iw0KIyBUaGUgbWFpbiBQQ0kgYnVzIGRldmljZSBpcyBgcGNpJy4gIEl0IHBy b3ZpZGVzIGF1dG8tZGV0ZWN0aW9uIGFuZA0KIyBjb25maWd1cmF0aW9uIHN1 cHBvcnQgZm9yIGFsbCBkZXZpY2VzIG9uIHRoZSBQQ0kgYnVzLCB1c2luZyBl aXRoZXINCiMgY29uZmlndXJhdGlvbiBtb2RlIGRlZmluZWQgaW4gdGhlIFBD SSBzcGVjaWZpY2F0aW9uLg0KIw0KIyBUaGUgYGFoYycgZGV2aWNlIHByb3Zp ZGVzIHN1cHBvcnQgZm9yIHRoZSBBZGFwdGVjIDI5LzM5NDAoVSkoVykNCiMg YW5kIG1vdGhlcmJvYXJkIGJhc2VkIEFJQzc4NzAvQUlDNzg4MCBhZGFwdGVy cy4NCiMNCiMgVGhlIGBkZScgZGV2aWNlIHByb3ZpZGVzIHN1cHBvcnQgZm9y IHRoZSBEaWdpdGFsIEVxdWlwbWVudCBEQzIxMDQwDQojIHNlbGYtY29udGFp bmVkIEV0aGVybmV0IGFkYXB0ZXIuDQojDQojIFRoZSBgdngnIGRldmljZSBw cm92aWRlcyBzdXBwb3J0IGZvciB0aGUgM0NvbSAzQzU5MCBhbmQgM0M1OTUN CiMgZWFybHkgc3VwcG9ydA0KIw0KY29udHJvbGxlcglwY2kwDQpjb250cm9s bGVyCWFoYzENCmRldmljZSBkZTANCmRldmljZSBmeHAwDQpkZXZpY2UgdGww DQpkZXZpY2UgdHgwDQpkZXZpY2UgdngwDQpkZXZpY2UgeGwwDQoNCmRldmlj ZSBlZDAgYXQgaXNhPyBwb3J0IDB4MjgwIG5ldCBpcnEgNSBpb21lbSAweGQ4 MDAwIHZlY3RvciBlZGludHINCg0K --0-1313891218-928931572=:49155-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 9 22:49:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misery.sdf.com (misery.sdf.com [204.244.213.49]) by hub.freebsd.org (Postfix) with ESMTP id 7AEE915032 for ; Wed, 9 Jun 1999 22:49:32 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 10rwe9-0005DL-00; Wed, 9 Jun 1999 21:40:57 -0700 Date: Wed, 9 Jun 1999 21:40:54 -0700 (PDT) From: Tom To: Julian Stacey Cc: Wilko Bulte , Warner Losh , "Kenneth D. Merry" , freebsd-scsi@FreeBSD.ORG Subject: Re: sea driver - anyone porting from 2.2.8 to 3.?/current ? In-Reply-To: <199906071800.SAA05421@jhs.muc.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 7 Jun 1999, Julian Stacey wrote: > > From "Kenneth D. Merry" > > All I can say is "where have you been for the past couple of years"?? > > Ah, well although I read the hatchet wielding plans from the CAM team, > I also read the protests, & found it hard to believe such drastic hatchet > work would actually happen. Drastic? We are talking about 8 bit controller cards that haven't been made in years! I'm surprised this stuff still works, or that you haven't upgraded. These days, I can get newer controller cards for free out of the garbage. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 11 9:34:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gatekeeper.iserver.com (gatekeeper.iserver.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id 97DFF154C8 for ; Fri, 11 Jun 1999 09:34:25 -0700 (PDT) (envelope-from steveb@iserver.com) Received: by gatekeeper.iserver.com; Fri, 11 Jun 1999 10:34:25 -0600 (MDT) Received: from unknown(192.168.1.7) by gatekeeper.iserver.com via smap (V3.1.1) id xma020934; Fri, 11 Jun 99 10:34:04 -0600 Received: from iserver.com (glacier.orem.iserver.com [192.168.1.111]) by orca.orem.iserver.com [Verio Web Hosting, Inc. 801.437.0200] (8.8.5) id KAA18639 for ; Fri, 11 Jun 1999 10:34:00 -0600 (MDT) Message-ID: <37613B04.958D33C4@iserver.com> Date: Fri, 11 Jun 1999 10:36:21 -0600 From: Steve Bishop X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: scsi probe at boot time Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I am having trouble using a Spectralogic 10000 SCSI tape changer. The tape changer locks up during the FreeBSD boot sequence. It locks up right when FreeBSD prints the message: "Waiting 10 seconds for SCSI devices to settle" The changer does not respond anymore after this, and only the two tape drives in the changer are recognized (SONY SDX-500C). This is right when FreeBSD probes the SCSI devices, right? I also used to have the same problem occur earlier in the boot sequence, before the OS even started loading. This was when the SCSI host adapter did it's own probing of the bus. So, I went into the SCSI BIOS, and disabled the "probe-at-boot" function. There is a workaround that I have used successfully. I don't turn the changer on until the server or FreeBSD computer has booted completely. Once that is finished, I issue the following command: "camcontrol rescan bus 0" This successfully recognizes everything and enables or configures the changer for use. The changer does not lock up. How come I can do a rescan and everything is OK, but the SCSI probe during boot causes the tape changer to lock up? Does anyone know a solution or better (i.e. permanent) workaround than the one I currently use? thanks, Steve Bishop Sysadmin/Developer Verio Web Services, Inc. tapehound# camcontrol devlist -v scbus-1 on xpt-193593352 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) scbus0 on ahc0 bus 0: at scbus0 target 2 lun 0 (pass0,sa0) at scbus0 target 3 lun 0 (pass1,sa1) at scbus0 target 6 lun 0 (pass2,ch0) < > at scbus0 target -1 lun -1 () scbus1 on ahc1 bus 0: at scbus1 target 0 lun 0 (pass3,da0) at scbus1 target 2 lun 0 (pass4,da1) < > at scbus1 target -1 lun -1 () scbus2 on ahc2 bus 0: < > at scbus2 target -1 lun -1 () tapehound# dmesg Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-RELEASE #1: Wed May 26 12:18:05 MDT 1999 root@tapehound.orem.iserver.com:/usr/src/sys/compile/TAPEHOUND Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (350.80-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping=2 Features=0x183fbff> real memory = 67043328 (65472K bytes) avail memory = 62074880 (60620K bytes) Bad DMI table checksum! Preloaded elf kernel "kernel" at 0xf02ff000. Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x03 on pci0.1.0 chip2: rev 0x02 on pci0.7.0 chip3: rev 0x02 on pci0.7.3 fxp0: rev 0x08 int a irq 11 on pci0.15.0 fxp0: Ethernet address 00:90:27:62:d1:b7 vga0: rev 0x01 int a irq 10 on pci0.16.0 ahc0: rev 0x01 int a irq 12 on pci0.19.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x04 int a irq 12 on pci0.20.0 ahc1: aic7895 Wide Channel A, SCSI Id=7, 255 SCBs ahc2: rev 0x04 int b irq 11 on pci0.20.1 ahc2: aic7895 Wide Channel B, SCSI Id=7, 255 SCBs Probing for devices on PCI bus 1: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode nlpt0: on ppbus 0 nlpt0: Interrupt-driven port ppi0: on ppbus 0 plip0: on ppbus 0 vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Waiting 10 seconds for SCSI devices to settle ---------------------------------------------------------------------------- sa0 at ahc0 bus 0 target 2 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit) sa1 at ahc0 bus 0 target 3 lun 0 sa1: Removable Sequential Access SCSI-2 device sa1: 40.0MB/s transfers (20.0MHz, offset 8, 16bit) da0 at ahc1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) da1 at ahc1 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) ch0 at ahc0 bus 0 target 6 lun 0 ch0: Removable Changer SCSI-2 device ch0: 3.300MB/s transfers ch0: 42 slots, 2 drives, 1 picker, 1 portal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 11 9:39: 2 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from slarti.muc.de (slarti.muc.de [193.149.48.10]) by hub.freebsd.org (Postfix) with SMTP id B9177154C8 for ; Fri, 11 Jun 1999 09:39:00 -0700 (PDT) (envelope-from jhs@jhs.muc.de) Received: (qmail 27751 invoked from network); 11 Jun 1999 16:38:02 -0000 Received: from jhs.muc.de (193.149.49.84) by slarti.muc.de with SMTP; 11 Jun 1999 16:38:02 -0000 Received: from wall.jhs.no_domain (localhost [127.0.0.1]) by jhs.muc.de (8.9.3/8.9.3) with ESMTP id LAA22415 for ; Fri, 11 Jun 1999 11:34:27 GMT (envelope-from jhs@wall.jhs.no_domain) Message-Id: <199906111134.LAA22415@jhs.muc.de> To: freebsd-scsi@freebsd.org Subject: Re: sea driver - anyone porting from 2.2.8 to 3.?/current ? From: "Julian Stacey" Reply-To: "Julian Stacey" X-Net: jhs@muc.de jhs@freebsd.org www.jhs.muc.de www.freebsd.org/~jhs/ In-reply-to: Your message of "Thu, 10 Jun 1999 06:40:54 +0200." Date: Fri, 11 Jun 1999 13:34:25 +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Reference: > From: Tom > Date: Thu, 10 Jun 1999 06:40:54 +0200 > Message-id: > Drastic? We are talking about 8 bit controller cards that haven't been > made in years! I hadn't looked to realise it was 8 bit transfer (I had realised it was slow, but it was sufficient that it worked). The spare Future Domain TMC 885 on my desk has no C1-C18 connectors, & just D3-7 (IRQ10-14), D16(+5V), D18(0V). > I'm surprised this stuff still works, or that you haven't upgraded. It's a useful old box: all new cards get plugged in here first, if they don't fry the computer, the cards move on to my new computers. A friend with a record of frying parallel ports, tested his ICE hardware control program on this box (after cross compiling from a faster box). > These days, I can get newer controller cards for free out of the garbage. You're lucky, better for free Eh ? Still seems a shame to dump support for old hardware: - Green/Conservationist principle is against scrapping a functional box. - Though the rich Western world buys & dumps regularly, some places people can't afford the latest & greatest, ... but if our OS still could still run (walk ;-) , they could still use old hardware, & even contribute ports docu etc, even if we'll not hear of them in new hardware forums. (I see occasional appeals for free hardware in 3rd world ... makes one realise). Julian Julian H. Stacey http://www.freebsd.org/~jhs/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 11 9:48:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with SMTP id 9B331154E1 for ; Fri, 11 Jun 1999 09:48:41 -0700 (PDT) (envelope-from jedgar@fxp.org) Received: (qmail 42024 invoked by uid 1003); 11 Jun 1999 16:48:40 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Jun 1999 16:48:40 -0000 Date: Fri, 11 Jun 1999 12:48:40 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: jedgar@pawn.primelocation.net To: Steve Bishop Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: scsi probe at boot time In-Reply-To: <37613B04.958D33C4@iserver.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 In my previous life, I had to service many Spectra Logic changers...they can be very picky with the system probing them while they are still initializing. Is the changer initializing (arm moving, etc) when FreeBSD is booting? If so, you may want to try using a longer SCSI_DELAY in your kernel's config and see what happens. Also, it should be ok if the scsi controller resets the changer, scans the bus and does not see it since the OS will scan the bus for itself (and not depend on the card's bios). ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 11 10: 2:18 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gatekeeper.iserver.com (gatekeeper.iserver.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id A82F3152C3 for ; Fri, 11 Jun 1999 10:02:15 -0700 (PDT) (envelope-from steveb@iserver.com) Received: by gatekeeper.iserver.com; Fri, 11 Jun 1999 11:02:14 -0600 (MDT) Received: from unknown(192.168.1.7) by gatekeeper.iserver.com via smap (V3.1.1) id xma025647; Fri, 11 Jun 99 11:01:50 -0600 Received: from iserver.com (glacier.orem.iserver.com [192.168.1.111]) by orca.orem.iserver.com [Verio Web Hosting, Inc. 801.437.0200] (8.8.5) id LAA20728; Fri, 11 Jun 1999 11:01:45 -0600 (MDT) Message-ID: <37614186.383B1A01@iserver.com> Date: Fri, 11 Jun 1999 11:04:07 -0600 From: Steve Bishop X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Chris D. Faulhaber" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: scsi probe at boot time References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Chris D. Faulhaber" wrote: > In my previous life, I had to service many Spectra Logic changers...they > can be very picky with the system probing them while they are still > initializing. > > Is the changer initializing (arm moving, etc) when FreeBSD is booting? If > so, you may want to try using a longer SCSI_DELAY in your kernel's > config and see what happens. Also, it should be ok if the scsi controller > resets the changer, scans the bus and does not see it since the OS will > scan the bus for itself (and not depend on the card's bios). > > ----- > Chris D. Faulhaber | All the true gurus I've met never > System/Network Administrator, | claimed they were one, and always > Reality Check Information, Inc. | pointed to someone better. The SCSI Controller (host adapter) resets the bus, and then scans it, and sees everything. It is the OS that locks up the changer with a bus reset, and then just sees the drives. The bus reset seems to lock the changer up immediately, so that as soon as the SCSI_DELAY period begins, it's already locked up. This, of course, points to this being a Spectralogic problem since the bus reset causes the changer to lock up regardless of whether it's the OS, or the SCSI controller. I don't remember seeing this problem with Solaris, but maybe it doesn't do a bus reset during boot. -Steve Bishop Verio Web Hosting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 11 10: 5:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with SMTP id 6EC4E14CB5 for ; Fri, 11 Jun 1999 10:05:51 -0700 (PDT) (envelope-from jedgar@fxp.org) Received: (qmail 42065 invoked by uid 1003); 11 Jun 1999 17:05:50 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Jun 1999 17:05:50 -0000 Date: Fri, 11 Jun 1999 13:05:50 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: jedgar@pawn.primelocation.net To: Steve Bishop Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: scsi probe at boot time In-Reply-To: <37614186.383B1A01@iserver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 11 Jun 1999, Steve Bishop wrote: > The SCSI Controller (host adapter) resets the bus, and then scans it, and sees > everything. It is the OS that locks up the changer with a bus reset, and then > just sees the drives. The bus reset seems to lock the changer up immediately, so > that as soon as the SCSI_DELAY period begins, it's already locked up. > > This, of course, points to this being a Spectralogic problem since the bus > reset causes the changer to lock up regardless of whether it's the OS, or > the SCSI controller. > > I don't remember seeing this problem with Solaris, but maybe it doesn't do > a bus reset during boot. > Unfortunately, we never put one of these on a FreeBSD system; but they seemed ok on other Unices (and Windoze NT for that matter). On occasion, they would lock during the probes and not be seem by the OS, but it wasn't consistent. ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 11 10:26:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BF9414FCC; Fri, 11 Jun 1999 10:26:24 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id LAA50058; Fri, 11 Jun 1999 11:26:15 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199906111726.LAA50058@panzer.plutotech.com> Subject: Re: scsi probe at boot time In-Reply-To: <37614186.383B1A01@iserver.com> from Steve Bishop at "Jun 11, 1999 11:04:07 am" To: steveb@iserver.com (Steve Bishop) Date: Fri, 11 Jun 1999 11:26:14 -0600 (MDT) Cc: jedgar@fxp.org (Chris D. Faulhaber), freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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 Steve Bishop wrote... > "Chris D. Faulhaber" wrote: > > > In my previous life, I had to service many Spectra Logic changers...they > > can be very picky with the system probing them while they are still > > initializing. > > > > Is the changer initializing (arm moving, etc) when FreeBSD is booting? If > > so, you may want to try using a longer SCSI_DELAY in your kernel's > > config and see what happens. Also, it should be ok if the scsi controller > > resets the changer, scans the bus and does not see it since the OS will > > scan the bus for itself (and not depend on the card's bios). > > > > ----- > > Chris D. Faulhaber | All the true gurus I've met never > > System/Network Administrator, | claimed they were one, and always > > Reality Check Information, Inc. | pointed to someone better. > > The SCSI Controller (host adapter) resets the bus, and then scans it, and sees > everything. It is the OS that locks up the changer with a bus reset, and then > just sees the drives. The bus reset seems to lock the changer up immediately, so > that as soon as the SCSI_DELAY period begins, it's already locked up. > > This, of course, points to this being a Spectralogic problem since the bus > reset causes the changer to lock up regardless of whether it's the OS, or > the SCSI controller. > > I don't remember seeing this problem with Solaris, but maybe it doesn't do > a bus reset during boot. Generally, the reason for doing a bus reset at boot is to clear out any previously negotiated transfer settings. I think there may be a way to boot your machine without resetting the bus in question. Justin put in some logic in the transport layer to handle negotiating transfer settings without resetting the bus beforehand. That sort of thing would also be handy in a multiple-initiator environment. I think the only way to enable it currently for Adaptec controllers is to enable target mode for the controller. Of course that currently disables initiator mode, which you don't want to do. :) Anyway, if you really think the bus reset is the problem, you'll probably need to talk to Justin (gibbs@FreeBSD.ORG) about it. You probably won't get a response until he gets back from USENIX. It does sound like your changer may be kinda buggy, though. The fact that your changer works on rescan does make it sound like the bus reset is causing the problems. What happens if you reset the bus with camcontrol? camcontrol reset 0 (if the changer is on bus 0) 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 11 13: 3:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gatekeeper.iserver.com (gatekeeper.iserver.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id 4A25114CB0 for ; Fri, 11 Jun 1999 13:03:55 -0700 (PDT) (envelope-from steveb@iserver.com) Received: by gatekeeper.iserver.com; Fri, 11 Jun 1999 14:03:54 -0600 (MDT) Received: from unknown(192.168.1.7) by gatekeeper.iserver.com via smap (V3.1.1) id xma027129; Fri, 11 Jun 99 14:03:43 -0600 Received: from iserver.com (glacier.orem.iserver.com [192.168.1.111]) by orca.orem.iserver.com [Verio Web Hosting, Inc. 801.437.0200] (8.8.5) id OAA03315; Fri, 11 Jun 1999 14:03:37 -0600 (MDT) Message-ID: <37616C26.7A482F12@iserver.com> Date: Fri, 11 Jun 1999 14:05:58 -0600 From: Steve Bishop X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: "Chris D. Faulhaber" , freebsd-scsi@FreeBSD.ORG Subject: Re: scsi probe at boot time References: <199906111726.LAA50058@panzer.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nothing happens when I run the command "camcontrol reset 0" Everything's the same as before I ran the command. The changer still works and everything. -Steve "Kenneth D. Merry" wrote: > Steve Bishop wrote... > > "Chris D. Faulhaber" wrote: > > > > > In my previous life, I had to service many Spectra Logic changers...they > > > can be very picky with the system probing them while they are still > > > initializing. > > > > > > Is the changer initializing (arm moving, etc) when FreeBSD is booting? If > > > so, you may want to try using a longer SCSI_DELAY in your kernel's > > > config and see what happens. Also, it should be ok if the scsi controller > > > resets the changer, scans the bus and does not see it since the OS will > > > scan the bus for itself (and not depend on the card's bios). > > > > > > ----- > > > Chris D. Faulhaber | All the true gurus I've met never > > > System/Network Administrator, | claimed they were one, and always > > > Reality Check Information, Inc. | pointed to someone better. > > > > The SCSI Controller (host adapter) resets the bus, and then scans it, and sees > > everything. It is the OS that locks up the changer with a bus reset, and then > > just sees the drives. The bus reset seems to lock the changer up immediately, so > > that as soon as the SCSI_DELAY period begins, it's already locked up. > > > > This, of course, points to this being a Spectralogic problem since the bus > > reset causes the changer to lock up regardless of whether it's the OS, or > > the SCSI controller. > > > > I don't remember seeing this problem with Solaris, but maybe it doesn't do > > a bus reset during boot. > > Generally, the reason for doing a bus reset at boot is to clear out any > previously negotiated transfer settings. > > I think there may be a way to boot your machine without resetting the bus > in question. Justin put in some logic in the transport layer to handle > negotiating transfer settings without resetting the bus beforehand. That > sort of thing would also be handy in a multiple-initiator environment. > > I think the only way to enable it currently for Adaptec controllers is to > enable target mode for the controller. Of course that currently disables > initiator mode, which you don't want to do. :) > > Anyway, if you really think the bus reset is the problem, you'll probably > need to talk to Justin (gibbs@FreeBSD.ORG) about it. You probably won't > get a response until he gets back from USENIX. > > It does sound like your changer may be kinda buggy, though. > > The fact that your changer works on rescan does make it sound like the bus > reset is causing the problems. What happens if you reset the bus with > camcontrol? > > camcontrol reset 0 > > (if the changer is on bus 0) > > 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 11 13:28: 3 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 0727B15249 for ; Fri, 11 Jun 1999 13:28:01 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA50884; Fri, 11 Jun 1999 14:27:52 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199906112027.OAA50884@panzer.plutotech.com> Subject: Re: scsi probe at boot time In-Reply-To: <37616C26.7A482F12@iserver.com> from Steve Bishop at "Jun 11, 1999 02:05:58 pm" To: steveb@iserver.com (Steve Bishop) Date: Fri, 11 Jun 1999 14:27:52 -0600 (MDT) Cc: jedgar@fxp.org, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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 Steve Bishop wrote... > Nothing happens when I run the command "camcontrol reset 0" > Everything's the same as before I ran the command. The changer > still works and everything. So it's not the reset itself that causes the problem, but rather the time the reset is sent. Sounds like screwy firmware on the changer. 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 11 13:29:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with SMTP id 0EB4715249 for ; Fri, 11 Jun 1999 13:29:52 -0700 (PDT) (envelope-from jedgar@fxp.org) Received: (qmail 42442 invoked by uid 1003); 11 Jun 1999 20:29:50 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Jun 1999 20:29:50 -0000 Date: Fri, 11 Jun 1999 16:29:50 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: jedgar@pawn.primelocation.net To: "Kenneth D. Merry" Cc: Steve Bishop , freebsd-scsi@FreeBSD.ORG Subject: Re: scsi probe at boot time In-Reply-To: <199906112027.OAA50884@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 Fri, 11 Jun 1999, Kenneth D. Merry wrote: > Steve Bishop wrote... > > Nothing happens when I run the command "camcontrol reset 0" > > Everything's the same as before I ran the command. The changer > > still works and everything. > > So it's not the reset itself that causes the problem, but rather the time > the reset is sent. Sounds like screwy firmware on the changer. > I wouldn't doubt it; we saw many problems w/Spectra Logic firmware on various changers. ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 11 14:56:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by hub.freebsd.org (Postfix) with ESMTP id 04A1D14D55; Fri, 11 Jun 1999 14:56:40 -0700 (PDT) (envelope-from gjp@noop.colo.erols.net) Received: from localhost ([127.0.0.1] helo=noop.colo.erols.net) by noop.colo.erols.net with esmtp (Exim 2.12 #1) id 10sZIN-0002Zi-00; Fri, 11 Jun 1999 17:57:03 -0400 To: alpha@freebsd.org Cc: scsi@freebsd.org From: "Gary Palmer" Subject: SPL bug? Date: Fri, 11 Jun 1999 17:57:03 -0400 Message-ID: <9901.929138223@noop.colo.erols.net> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I just tried putting a newer kernel on the Alphastation I have at work, and ran into an unusual problem. For months and months, I've had `boot_osflags' set to include `v'. It seems a kernel from todays (i.e. fri 11th June) source tree, refuses to boot properly with the `-v' flag set. Why? Because when its going through listing the SCSI devices (specifically the pass devices), it seems to not always register the corresponding da device. e.g., without -v da2 at isp0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da2: 4095MB (8388315 512 byte sectors: 255H 63S/T 522C) da1 at isp0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da1: 4095MB (8388315 512 byte sectors: 255H 63S/T 522C) da0 at isp0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled da0: 2007MB (4110480 512 byte sectors: 255H 63S/T 255C) cd0 at isp0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.032MB/s transfers (4.032MHz, offset 12) cd0: Attempt to query device size failed: NOT READY, Medium not present However, with -v, it would never register all the da devices, it would print out the large ammount of info from pass, and OCCASIONALLY see one or two of the disks as da, but never all of them. The only guess that I have is that while the SCSI layer is printing the pass info, its blocking da registration (like I said, this is a guess, I don't understand all the ins-and-outs of CAM). Since the console on this box is a 9600 baud serial console, printing the pass diags takes a non-trivial ammount of time. Without the diags, the system works fine. Any ideas? Thanks, Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 11 15: 2:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id AA5B415066; Fri, 11 Jun 1999 15:02:36 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id QAA51435; Fri, 11 Jun 1999 16:02:35 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199906112202.QAA51435@panzer.plutotech.com> Subject: Re: SPL bug? In-Reply-To: <9901.929138223@noop.colo.erols.net> from Gary Palmer at "Jun 11, 1999 05:57:03 pm" To: gpalmer@FreeBSD.ORG (Gary Palmer) Date: Fri, 11 Jun 1999 16:02:35 -0600 (MDT) Cc: alpha@FreeBSD.ORG, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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 Gary Palmer wrote... > > I just tried putting a newer kernel on the Alphastation I have at > work, and ran into an unusual problem. For months and months, I've had > `boot_osflags' set to include `v'. It seems a kernel from todays > (i.e. fri 11th June) source tree, refuses to boot properly with the > `-v' flag set. Why? Because when its going through listing the SCSI > devices (specifically the pass devices), it seems to not always > register the corresponding da device. e.g., without -v > > da2 at isp0 bus 0 target 2 lun 0 > da2: Fixed Direct Access SCSI-2 device > da2: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled > da2: 4095MB (8388315 512 byte sectors: 255H 63S/T 522C) > da1 at isp0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled > da1: 4095MB (8388315 512 byte sectors: 255H 63S/T 522C) > da0 at isp0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 20.000MB/s transfers (10.000MHz, offset 12, 16bit), Tagged Queueing Enabled > da0: 2007MB (4110480 512 byte sectors: 255H 63S/T 255C) > cd0 at isp0 bus 0 target 5 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 4.032MB/s transfers (4.032MHz, offset 12) > cd0: Attempt to query device size failed: NOT READY, Medium not present > > However, with -v, it would never register all the da devices, it > would print out the large ammount of info from pass, and > OCCASIONALLY see one or two of the disks as da, but never all of > them. > > The only guess that I have is that while the SCSI layer is printing > the pass info, its blocking da registration (like I said, this is a > guess, I don't understand all the ins-and-outs of CAM). Since the > console on this box is a 9600 baud serial console, printing the > pass diags takes a non-trivial ammount of time. Without the diags, > the system works fine. How does the system not work with -v is turned on? It "refuses to boot properly" doesn't really come close to describing the problem. I think the disappearing messages can probably be traced to your 9600 baud console. My guess is that some of the messages are getting dropped. Matt Jacob had a similar problem one time, I think. 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 11 15:10:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by hub.freebsd.org (Postfix) with ESMTP id 5CFA414D55; Fri, 11 Jun 1999 15:10:48 -0700 (PDT) (envelope-from gjp@noop.colo.erols.net) Received: from localhost ([127.0.0.1] helo=noop.colo.erols.net) by noop.colo.erols.net with esmtp (Exim 2.12 #1) id 10sZVp-0002bV-00; Fri, 11 Jun 1999 18:10:57 -0400 To: "Kenneth D. Merry" Cc: gpalmer@FreeBSD.ORG (Gary Palmer), alpha@FreeBSD.ORG, scsi@FreeBSD.ORG From: "Gary Palmer" Subject: Re: SPL bug? In-reply-to: Your message of "Fri, 11 Jun 1999 16:02:35 MDT." <199906112202.QAA51435@panzer.plutotech.com> Date: Fri, 11 Jun 1999 18:10:57 -0400 Message-ID: <10012.929139057@noop.colo.erols.net> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" wrote in message ID <199906112202.QAA51435@panzer.plutotech.com>: > How does the system not work with -v is turned on? It "refuses to boot > properly" doesn't really come close to describing the problem. Sorry. The few times I sat in there with a laptop to try and diagnose this, if the `da' message for a disk wasn't printed, then fsck hung (interuptably) trying to check the disk. I could CTRL-C out of fsck, but couldn't find the disk... disklabel also just sat there. Which makes me think its not just messages vanishing. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 11 15:21:38 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 00BE415494; Fri, 11 Jun 1999 15:20:54 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id QAA51558; Fri, 11 Jun 1999 16:20:53 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199906112220.QAA51558@panzer.plutotech.com> Subject: Re: SPL bug? In-Reply-To: <10012.929139057@noop.colo.erols.net> from Gary Palmer at "Jun 11, 1999 06:10:57 pm" To: gpalmer@FreeBSD.ORG (Gary Palmer) Date: Fri, 11 Jun 1999 16:20:53 -0600 (MDT) Cc: alpha@FreeBSD.ORG, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (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 Gary Palmer wrote... > "Kenneth D. Merry" wrote in message ID > <199906112202.QAA51435@panzer.plutotech.com>: > > How does the system not work with -v is turned on? It "refuses to boot > > properly" doesn't really come close to describing the problem. > > Sorry. The few times I sat in there with a laptop to try and diagnose > this, if the `da' message for a disk wasn't printed, then fsck hung > (interuptably) trying to check the disk. I could CTRL-C out of fsck, > but couldn't find the disk... disklabel also just sat there. Which > makes me think its not just messages vanishing. Hmm, yeah, it does kinda sound like the probe process wasn't finishing or something. I dunno what the problem is. I'll try running it by Justin when he gets back from USENIX, he may have some ideas. Until then, just don't boot with -v. :) 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 12 0:27:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 8E3FC15024; Sat, 12 Jun 1999 00:27:40 -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 RAA32501; Sat, 12 Jun 1999 17:27:39 +1000 Date: Sat, 12 Jun 1999 17:27:39 +1000 From: Bruce Evans Message-Id: <199906120727.RAA32501@godzilla.zeta.org.au> To: alpha@FreeBSD.ORG, gpalmer@FreeBSD.ORG Subject: Re: SPL bug? Cc: scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >The only guess that I have is that while the SCSI layer is printing >the pass info, its blocking da registration (like I said, this is a >guess, I don't understand all the ins-and-outs of CAM). Since the >console on this box is a 9600 baud serial console, printing the >pass diags takes a non-trivial ammount of time. Without the diags, >the system works fine. Try it at 50 bps for a really nontrivial amount of time (up to 400 seconds per 80x25 screen). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message