From owner-freebsd-scsi Sun Nov 21 0: 0:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (castles556.castles.com [208.214.165.120]) by hub.freebsd.org (Postfix) with ESMTP id 6F6DE1517A; Sun, 21 Nov 1999 00:00:46 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id XAA03550; Sat, 20 Nov 1999 23:51:04 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199911210751.XAA03550@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Andrey A. Chernov" Cc: Mike Smith , Wilko Bulte , current@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: Mount before SCSI comes up ? (was Re: Root mount failed:22 ???) In-reply-to: Your message of "Sat, 20 Nov 1999 02:45:55 +0300." <19991120024554.B5091@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 20 Nov 1999 23:51:04 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Fri, Nov 19, 1999 at 02:52:13PM -0800, Mike Smith wrote: > > > > The diagnostic is relatively harmless, but it suggests that /etc/fstab > > > > is wrong. > > > > > > Here is fstab line, please point what is wrong? > > > /dev/da0s4a / ufs rw,userquota 1 1 > > > > I have no idea; it'd be handy to know what it's trying to mount that's > > failing, but I don't recall that in your output. > > It is NOT say, what it tries to mount that failing :-( That's because it's not actually trying to mount anything. vfs_mountroot_try() is being called with a NULL argument, almost certainly because your loader is out of date (vfs.root.mountfrom does not exist in the environment). It's possible that there's a problem with the loader that's resulting in it not being set; you should instrument /sys/boot/common/boot.c:getrootmount() to determine this. It's also possible that it's being called for some other reason; you should look at vfs_mountroot() to see what else might be the culprit. > Here is quote in more wide scope. > Is it tries to mount root before SCSI devices come up? No; 22 is EINVAL, wheras you would exepect ENXIO (6) for that case. > Waiting 2 seconds for SCSI devices to settle > Creating DISK da0 > Creating DISK da1 > Root mount failed: 22 > Mounting root from ufs:da0s4a This completes successfully, so everything looks happy. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ 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 Nov 21 1:54:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (castles519.castles.com [208.214.165.83]) by hub.freebsd.org (Postfix) with ESMTP id 4176414F7F for ; Sun, 21 Nov 1999 01:54:39 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id BAA00395; Sun, 21 Nov 1999 01:45:16 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199911210945.BAA00395@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Tom Cc: freebsd-scsi@freebsd.org Subject: Re: AMI MegaRAID driver In-reply-to: Your message of "Fri, 19 Nov 1999 16:22:33 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Nov 1999 01:45:16 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > What MegaRAID cards have you used and work? What MegaRAID cards don't > work for sure (I know the Enterprise 1500 is currently in this category)? I have tested with the 418 and 428 (Enterprise 1200). I have reason to believe that the 438 (Enterprise 1300) also works. I've tested one of the Express family (466), however I expect all of them to work. > Basically, as you suggested, I decided to commit to the MegaRAID card > for a production server, but I'm totally lost on which card to order. The > MegaRAID Express 300 is a card that I'm considering. > > BTW, AMI has a cool buy one, get one free deal going on at > http://www.ami.com right now. I'd like to take advantage of this offer, > and get a bunch of cards. I'd go with Geoff's suggestion. Buy the card(s) that meet your requirements, and if they don't work send one to me. Easy fix. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ 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 Nov 21 5:53:10 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 5341414EFC; Sun, 21 Nov 1999 05:53:03 -0800 (PST) (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 OAA24866; Sun, 21 Nov 1999 14:28:53 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id NAA38134; Sun, 21 Nov 1999 13:54:05 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911211254.NAA38134@yedi.iaf.nl> Subject: Re: strange panic on Alpha, SCSI disk *type* related In-Reply-To: <14390.62100.488036.94592@grasshopper.cs.duke.edu> from Andrew Gallatin at "Nov 20, 1999 2:21:37 pm" To: gallatin@cs.duke.edu (Andrew Gallatin) Date: Sun, 21 Nov 1999 13:54:05 +0100 (CET) Cc: freebsd-scsi@FreeBSD.ORG, freebsd-alpha@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 Andrew Gallatin wrote ... > > Wilko Bulte writes: > > > > Best guess is currently that something in the isp driver changed that made > > the marriage of the IBM disk and the isp card a less than happy one. > > > <...> > > > isp0: Board Revision 1040B, resident F/W Revision 2.10.0 > > <..> > > The isp change is that due to problems with the Qlogic firmware > copyright, Matt felt he had to remove the Qlogic firmware from the > FreeBSD (and NetBSD) trees. Your card is now running with the > firmware that is loaded by the SRM console (2.10) rather than the > firmware that the isp driver was previously able to download (7.x). > This may be the cause of your problems. Argh. I followed the thread on the isp copyright stuff but never realised it might > If it is possible, try to upgrade your SRM console firmware to a more > recent version. Modern revs of the srm console tend to load 5.x of 5.57 is the current one I think. But for the EB64+ srm I am at the latest rev. :-( W/ -- | / 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 Nov 21 5:53:17 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 5FF2C1510F; Sun, 21 Nov 1999 05:53:03 -0800 (PST) (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 OAA24870; Sun, 21 Nov 1999 14:28:55 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id OAA38385; Sun, 21 Nov 1999 14:18:50 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911211318.OAA38385@yedi.iaf.nl> Subject: Re: strange panic on Alpha, SCSI disk *type* related In-Reply-To: <14390.62100.488036.94592@grasshopper.cs.duke.edu> from Andrew Gallatin at "Nov 20, 1999 2:21:37 pm" To: gallatin@cs.duke.edu (Andrew Gallatin) Date: Sun, 21 Nov 1999 14:18:50 +0100 (CET) Cc: freebsd-scsi@FreeBSD.ORG, freebsd-alpha@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 Andrew Gallatin wrote ... > <...> > > > isp0: Board Revision 1040B, resident F/W Revision 2.10.0 > > <..> New evidence: It looks like the problems are Ultra SCSI related. Meaning that if I use the EEROMCFG.EXE utility*) and set everything to FAST-10 mode (as opposed to UltraSCSI) the system at least boots OK. I.e. it does not panic anymore: Mounting root from ufs:/dev/dda0 at isp0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 3.906MB/s transfers (1.953MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) a0a WARNING: preposterous clock chip time -- CHECK AND RESET THE DATE! swapon: adding /dev/da0b as swap device etc. I'm not too thrilled about the negotiated SCSI parameters, but it sure beats a panic ;-) Wilko *) run from the ARC console which was in turn booted from floppy; cute that the board does not have both ARC and SRM onboard at the same time. The ARC image can be found on the Alpha Eval Board SDK cdrom. -- | / 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 Nov 21 5:53:26 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 2E9A7157BB; Sun, 21 Nov 1999 05:53:03 -0800 (PST) (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 OAA24865; Sun, 21 Nov 1999 14:28:52 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id NAA37853; Sun, 21 Nov 1999 13:28:18 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911211228.NAA37853@yedi.iaf.nl> Subject: Re: strange panic on Alpha, SCSI disk *type* related In-Reply-To: from Matthew Jacob at "Nov 20, 1999 2:46:47 pm" To: mjacob@feral.com Date: Sun, 21 Nov 1999 13:28:18 +0100 (CET) Cc: gallatin@cs.duke.edu, freebsd-scsi@FreeBSD.ORG, freebsd-alpha@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 Matthew Jacob wrote ... > > I have an excellent case that (copyrights aside) this should be possible > > (putting the f/w in the driver): > > > > my machine is an Aspen Alpine, which has EB64+ firmware running. It runs > > the latest SRM available (which is ancient) and to add to the problem it > > has the SRM in EPROM, not in flash. > > Tsk. Right, tsk. ;-) > > > the driver supports multiple cards with multiple f/w sets, the f/w was > > > beggining to add 100KB to the driver.... completely outta hand...). > > > > Big, I agree. But I rather have a bigger kernel than a panic :-( > > We're talking 192KB big. I know... :-( > > > > recent version. Modern revs of the srm console tend to load 5.x of > > > > the qlogic firmware which might help you. I'm running with 5.54.1 on > > > > a number of machines here & have not seen problems. I think 5.57 is the current f/w for KZPBA (aka isp1040) > > Isn't it possible to flash the f/w onto the isp card itself? Or does the > > Alpha always use the f/w contained in the SRM? The same cards also run > > in a PC, so without the notion of SRM... > > It's not quite clear what the SRM does or does not do. It may or may not > download from the card. Likely not. It also probably depends on the SRM > version and the platform. Well, Tru64 5.0 tells me: Alpha 21064A Evaluation Board 274 MHz DECchip 21072 pci0 (primary bus:0) at nexus Loading SIOP: script c0000000, reg 81051000, data 410dc000 scsi0 at psiop0 slot 0 isp0 at pci0 slot 6 isp0: QLOGIC ISP1040B/V2 isp0: Firmware revision 2.10 (loaded by console) isp0: Failed to enable fast RAM timing. scsi1 at isp0 slot 0 So, in this case the SRM has loaded the f/w onto the isp card. But on the same Tru64 5.0: # strings isp.mod | grep load isp_unload DMA map_unload failed (sg_loop) DMA map unload failed isp_segment_load Bad header/payload flags set in status entry: 0x%x Fatal Error - No firmware image is present to load Error detected in isp_chip_init, firmware load failure likely RAM load failure (loaded from root filesystem) !!!!! (loaded by console) !!!!! isp_load_ram It appears the Tru64 driver can also load f/w onto the isp. > Insofar as updating the cards themselves- this is a pretty much > undocumented procedure that I would rather not become responsible for. > There are tools available from the Qlogic website which allow you to do > this (on a PC executing from DOS), but it's not really clear whether the > SRM will pull this out of the BIOS flashrom and then download it to the > SRAM on the card and set that running- I believe that SRM just downloads > the code *it* has. This is what I think happens, judging from the experiment above. > The reason the f/w will be going back in the tree is to provide a > *selection* of features such as Fabric or Target Mode support. The INSTALL > kernel should not have any of this compiled in because it makes things > probably too big to fit on floppies. Well, it's there for Alpha because > there are so few other boards supported that there is room for it. Hell, :-) I agree that this is a kind of a mess. SRM can only handle ncr and isp (for PCI machines) IIRC. > It's a hard problem to get right solution for, sorry. I'll have a little discussion with one of my colleagues to see if one can merge new isp f/w into the EB64+ SRM console binary. This guy used to write repair diagnostics etc for Alpha so he knows a lot of the console bit banging stuff. Wilko -- | / 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 Nov 21 9:53: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id AED6B157D8; Sun, 21 Nov 1999 09:53:03 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA01848; Sun, 21 Nov 1999 09:53:42 -0800 Date: Sun, 21 Nov 1999 09:53:42 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: Andrew Gallatin , freebsd-scsi@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: strange panic on Alpha, SCSI disk *type* related In-Reply-To: <199911211318.OAA38385@yedi.iaf.nl> 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 Ah! Well, what you can also do is set the ISP_CFG_NONVRAM config option or do isp_no_nvram=1 # (1 << unit) in your loader defaults file (or at the loader prompt) and it won't 'believe' the NVRAM settings. It still might try and do Ultra though- that's a property of chip type, clock rate and (heh heh) a bit set in the Qlogic microengine's processor status register. I still would like more details (maybe in the mail to follow), but I probably can't look too closely at this until after December 1. On Sun, 21 Nov 1999, Wilko Bulte wrote: > As Andrew Gallatin wrote ... > > > <...> > > > > > isp0: Board Revision 1040B, resident F/W Revision 2.10.0 > > > > <..> > > New evidence: > > It looks like the problems are Ultra SCSI related. Meaning that if I > use the EEROMCFG.EXE utility*) and set everything to FAST-10 mode > (as opposed to UltraSCSI) the system at least boots OK. I.e. it does > not panic anymore: > > Mounting root from ufs:/dev/dda0 at isp0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 3.906MB/s transfers (1.953MHz, offset 8, 16bit), Tagged Queueing > Enabled > da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) > a0a > WARNING: preposterous clock chip time > -- CHECK AND RESET THE DATE! > swapon: adding /dev/da0b as swap device > > etc. > > I'm not too thrilled about the negotiated SCSI parameters, but it > sure beats a panic ;-) > > Wilko > > > *) run from the ARC console which was in turn booted from floppy; > cute that the board does not have both ARC and SRM onboard at the same time. > The ARC image can be found on the Alpha Eval Board SDK cdrom. > > > -- > | / 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-alpha" 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 Sun Nov 21 9:58:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gw-nl4.philips.com (gw-nl4.philips.com [192.68.44.36]) by hub.freebsd.org (Postfix) with ESMTP id 462E614D07 for ; Sun, 21 Nov 1999 09:58:31 -0800 (PST) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id SAA01945 for ; Sun, 21 Nov 1999 18:58:30 +0100 (MET) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma001943; Sun, 21 Nov 99 18:58:31 +0100 Received: from hal.mpn.cp.philips.com (hal.mpn.cp.philips.com [130.139.64.195]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with SMTP id SAA01717 for ; Sun, 21 Nov 1999 18:58:30 +0100 (MET) Received: (qmail 76529 invoked by uid 666); 21 Nov 1999 17:58:52 -0000 Date: Sun, 21 Nov 1999 18:58:52 +0100 From: Jos Backus To: freebsd-scsi@freebsd.org Subject: Tape eject problem Message-ID: <19991121185852.A75911@hal.mpn.cp.philips.com> Reply-To: Jos Backus Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [This is with a -current kernel & world as of today.] # mt rewoffl used to rewind and eject a tape cartrigde, if present. It rewinds but no longer ejects, instead the unit just goes off-line. Also, I'm seeing Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): READ(06). CDB: 8 0 2 0 0 0 Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): UNIT ATTENTION asc:28,0 Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): Not ready to ready change, medium may have changed The tape drive is detected as sa0 at ahc0 bus 0 target 3 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 32) ``camcontrol eject 0:3:0'' does eject the media. Is the new mt behavior intentional? Is ``camcontrol eject'' the preferred way to eject media? Thanks, -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Nov 21 10: 6:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 44F5714C81 for ; Sun, 21 Nov 1999 10:06:06 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id KAA01923; Sun, 21 Nov 1999 10:06:42 -0800 Date: Sun, 21 Nov 1999 10:06:42 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jos Backus Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Tape eject problem In-Reply-To: <19991121185852.A75911@hal.mpn.cp.philips.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 Sounds like a bug to me. Sorry, I'll check it out today. On Sun, 21 Nov 1999, Jos Backus wrote: > [This is with a -current kernel & world as of today.] > > # mt rewoffl > > used to rewind and eject a tape cartrigde, if present. It rewinds but no > longer ejects, instead the unit just goes off-line. > Also, I'm seeing > > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): READ(06). CDB: 8 0 2 0 0 0 > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): UNIT ATTENTION asc:28,0 > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): Not ready to ready change, > medium may have changed > > The tape drive is detected as > > sa0 at ahc0 bus 0 target 3 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 10.000MB/s transfers (10.000MHz, offset 32) > > ``camcontrol eject 0:3:0'' does eject the media. > > Is the new mt behavior intentional? Is ``camcontrol eject'' the preferred way > to eject media? > > Thanks, > -- > Jos Backus _/ _/_/_/ "Reliability means never > _/ _/ _/ having to say you're sorry." > _/ _/_/_/ -- D. J. Bernstein > _/ _/ _/ _/ > Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; > > > 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 Sun Nov 21 10:22:36 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 49E9E14C88; Sun, 21 Nov 1999 10:22:10 -0800 (PST) (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 TAA01926; Sun, 21 Nov 1999 19:05:44 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id TAA42068; Sun, 21 Nov 1999 19:15:45 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911211815.TAA42068@yedi.iaf.nl> Subject: Re: strange panic on Alpha, SCSI disk *type* related In-Reply-To: <199911211228.NAA37853@yedi.iaf.nl> from Wilko Bulte at "Nov 21, 1999 1:28:18 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Sun, 21 Nov 1999 19:15:45 +0100 (CET) Cc: mjacob@feral.com, gallatin@cs.duke.edu, freebsd-scsi@FreeBSD.ORG, freebsd-alpha@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 Hi Matt, My previous email must have crossed your cvs update: I can confirm that the resurrection of the f/w into the kernel appears to solve the problems I was experiencing on my Alpha box. Thanks! Also to Qlogic for accepting a more usable copyright on the firmware. Suggestion: a couple of lines in /usr/src/UPDATING explaining the kernel options for the inclusion of the isp firmware might be practical I think. Wilko -- | / 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 Nov 21 12: 2:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (castles519.castles.com [208.214.165.83]) by hub.freebsd.org (Postfix) with ESMTP id A86871582E; Sun, 21 Nov 1999 12:02:10 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id LAA03269; Sun, 21 Nov 1999 11:52:26 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199911211952.LAA03269@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Wilko Bulte Cc: mjacob@feral.com, gallatin@cs.duke.edu, freebsd-scsi@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: strange panic on Alpha, SCSI disk *type* related In-reply-to: Your message of "Sun, 21 Nov 1999 19:15:45 +0100." <199911211815.TAA42068@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Nov 1999 11:52:26 -0800 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Suggestion: a couple of lines in /usr/src/UPDATING explaining the kernel > options for the inclusion of the isp firmware might be practical I think. Matt also proposed having the loader deal with loading the firmware; I can think of a couple of ways to do this that are consistent with the way that we plan to do module auto-loading, and which ought to work in the manual context as well. I guess I need to talk to him about this sometime when we get around to the autoloading implementation. *sigh* So much to do... -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ 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 Nov 21 12: 2:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by hub.freebsd.org (Postfix) with ESMTP id 5F5D1158F2 for ; Sun, 21 Nov 1999 12:02:24 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-111-226.villette.club-internet.fr [194.158.111.226]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA29668; Sun, 21 Nov 1999 21:02:03 +0100 (MET) Date: Sun, 21 Nov 1999 22:26:29 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Nick Hibma Cc: "David O'Brien" , scsi@freebsd.org Subject: Re: SYM-0.10.0 available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 19 Nov 1999, Nick Hibma wrote: =20 > You are aware of the machine beast.freebsd.org that you can use for > build testing of your alpha software? That way you can at least get the > compilation to work. A memcmp() that disappears since being a gcc built-in and a function that= =20 vanished recently from the main branch are not common compilation problems= =20 as far as I can tell. Btw, the changes were pretty trivial for the thing=20 to be immediately fixed. =20 > Hope this helps. This would help if I wanted to propose changes in the Alpha specific code, but I dont. And I donnot intend to check by myself all driver changes against anything else than i386. This never had been a problem under Linux, and AFAIK the drivers I maintain for Linux are used on PPC, SPARCs, ALPHA and INTEL (at least).=20 G=E9rard. > Nick >=20 > On Fri, 19 Nov 1999, Gerard Roudier wrote: >=20 > >=20 > > Thanks for having tried the driver and sorry for the problems. I donnot > > have access to an Alpha system. The -UNTESTED- status for Alpha was the= re > > for reasons. > >=20 > > If you want to continue with this driver version, you can just #if 0 th= e > > call to alpha_register_pci_scsi() and change occurrences of memcmp() by= =20 > > bcmp(). > >=20 > > I will made available a new patch in a couple of days with Ultra2 mode > > tested for the C1010 (Ultra3 will come later due to some changes needed= in > > CAM and camcontrol) and with the compilation problems hopefully fixed. = You > > may wait for that one, if you prefer (as you want).=20 > >=20 > > Regards, > > G=E9rard. > >=20 > >=20 > > On Thu, 18 Nov 1999, David O'Brien wrote: > >=20 > > > On Sat, Nov 13, 1999 at 11:45:03PM +0100, Gerard Roudier wrote: > > > > * SYM-0.10.0-19991111 (diff file PATCH-SYM-0.10.0-19991111) > > > > Add support for Alpha - UNTESTED. Consists in some minor changes = picked=20 > > >=20 > > > This will not compile for me. I changed where I installed the files,= but > > > I can't see how that would cause these errors: > > >=20 > > > linking kernel.debug > > > sym_hipd.o: In function `sym_cam_attach': /sys/compile/QUYNH/../../co= ntrib/dev/sym/sym_hipd.c:10254: undefined reference to `alpha_register_pci_= scsi' > > > /sys/compile/QUYNH/../../contrib/dev/sym/sym_hipd.c:10254: undefined = reference to `alpha_register_pci_scsi' sym_hipd.o: In function `sym_read_Sy= mbios_nvram': > > > /sys/compile/QUYNH/../../contrib/dev/sym/sym_hipd.c:10759: undefined = reference to `memcmp' > > > /sys/compile/QUYNH/../../contrib/dev/sym/sym_hipd.c:10759: undefined = reference to `memcmp' > > > *** Error code 1 > > >=20 > > > --=20 > > > -- David (obrien@NUXI.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Nov 21 14:36: 2 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 5B94C1526A for ; Sun, 21 Nov 1999 14:35:59 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.03 #1) id 11pfaR-0000EQ-00 for freebsd-scsi@freebsd.org; Sun, 21 Nov 1999 14:35:59 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-scsi@freebsd.org Subject: DLT2000 must have tape at boot to write Message-Id: Date: Sun, 21 Nov 1999 14:35:59 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ASUS P2B-DS 3.3-stable DLT2000 if i reset and bopot with no tape in drive, i can read the tape. but if i try to dump, i get write errors in the second file. if i put a tape in the drive, ready the tape, and then reset and boot, i can dump just fine. this is similar to the cd-rom writer. clues? randy 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.3-STABLE #0: Sun Nov 21 14:23:24 PST 1999 root@rip.psg.com:/usr/src/sys/compile/RIP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Features=0x183fbff real memory = 134217728 (131072K bytes) avail memory = 127434752 (124448K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02db000. Preloaded userconfig_script "/kernel.config" at 0xc02db09c. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.1.0 chip2: rev 0x02 on pci0.4.0 chip3: rev 0x02 on pci0.4.3 ahc0: rev 0x00 int a irq 19 on pci0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs fxp0: rev 0x05 int a irq 19 on pci0.9.0 fxp0: Ethernet address 00:a0:c9:df:c8:4e bktr0: rev 0x02 int a irq 18 on pci0.10.0 bti2c0: iicbb0: on bti2c0 iicbus0: on iicbb0 master-only smbus0: on bti2c0 smb0: on smbus0 bktr0: Hauppauge Model 61111 A M bktr0: Detected a MSP3430G-A1 at 0x80 Hauppauge WinCast/TV, Philips NTSC tuner, msp3400c stereo. Probing for devices on PCI bus 1: vga0: rev 0x00 int a irq 16 on pci1.0.0 Probing for PnP devices: CSN 1 Vendor ID: CTL00c3 [0xc3008c0e] Serial 0x1fd0a682 Comp ID: PNPb02f [0x2fb0d041] pcm1 (SB16pnp sn 0x1fd0a682) at 0x220-0x22f irq 5 drq 1 flags 0x15 on isa 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 psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A pcm0 not probed due to drq conflict with pcm1 at 1 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface wl0 at 0x300-0x30f irq 7 on isa wl0: address 08:00:6a:2b:dd:cb, NWID 0xaaaa APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 ccd0-5: Concatenated disk drivers Waiting 30 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! sa0 at ahc0 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 15) changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ahc0 bus 0 target 5 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 8.333MB/s transfers (8.333MHz, offset 31) cd1: cd present [140956 x 2048 byte records] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Nov 21 14:37:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 6B0B214E67 for ; Sun, 21 Nov 1999 14:37:08 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.03 #1) id 11pfbY-0000FG-00 for freebsd-scsi@freebsd.org; Sun, 21 Nov 1999 14:37:08 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-scsi@freebsd.org Subject: Re: DLT2000 must have tape at boot to write References: Message-Id: Date: Sun, 21 Nov 1999 14:37:08 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org i lied. it just took longer to fail rip.psg.com:/root# /do-dump DUMP: Date of this level 0 dump: Sun Nov 21 14:28:48 1999 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rsd0s1a (/) to /dev/nrsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 26344 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: DUMP: 26356 tape blocks on 1 volume DUMP: finished in 21 seconds, throughput 1255 KBytes/sec DUMP: level 0 dump on Sun Nov 21 14:28:48 1999 DUMP: Closing /dev/nrsa0 DUMP: DUMP IS DONE DUMP: Date of this level 0 dump: Sun Nov 21 14:29:14 1999 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rsd1s1e (/root) to /dev/nrsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 92 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: DUMP: 91 tape blocks on 1 volume DUMP: finished in less than a second DUMP: level 0 dump on Sun Nov 21 14:29:14 1999 DUMP: Closing /dev/nrsa0 DUMP: DUMP IS DONE DUMP: Date of this level 0 dump: Sun Nov 21 14:29:18 1999 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rccd3c (/var) to /dev/nrsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 53700 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: DUMP: 53674 tape blocks on 1 volume DUMP: finished in 42 seconds, throughput 1277 KBytes/sec DUMP: level 0 dump on Sun Nov 21 14:29:18 1999 DUMP: Closing /dev/nrsa0 DUMP: DUMP IS DONE DUMP: Date of this level 0 dump: Sun Nov 21 14:30:04 1999 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rccd4c (/var/spool) to /dev/nrsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 22075 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: DUMP: 22067 tape blocks on 1 volume DUMP: finished in 18 seconds, throughput 1225 KBytes/sec DUMP: level 0 dump on Sun Nov 21 14:30:04 1999 DUMP: Closing /dev/nrsa0 DUMP: DUMP IS DONE DUMP: Date of this level 0 dump: Sun Nov 21 14:30:26 1999 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rccd5c (/usr) to /dev/nrsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 4086561 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: write error 274140 blocks into volume 1 DUMP: Do you want to restart?: ("yes" or "no") randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Nov 21 14:37:12 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 597491526A for ; Sun, 21 Nov 1999 14:37:08 -0800 (PST) (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 XAA12584; Sun, 21 Nov 1999 23:18:31 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id TAA42168; Sun, 21 Nov 1999 19:19:18 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911211819.TAA42168@yedi.iaf.nl> Subject: Re: Tape eject problem In-Reply-To: from Matthew Jacob at "Nov 21, 1999 10: 6:42 am" To: mjacob@feral.com Date: Sun, 21 Nov 1999 19:19:18 +0100 (CET) Cc: Jos.Backus@nl.origin-it.com, 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 Matthew Jacob wrote ... FWIW: similar thing here on a TZ87 DLT. After the rewind completes the mt command just sits there, apparantly waiting for something that never occurs to it ;-) > Sounds like a bug to me. Sorry, I'll check it out today. > > On Sun, 21 Nov 1999, Jos Backus wrote: > > > [This is with a -current kernel & world as of today.] > > > > # mt rewoffl > > > > used to rewind and eject a tape cartrigde, if present. It rewinds but no > > longer ejects, instead the unit just goes off-line. > > Also, I'm seeing > > > > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): READ(06). CDB: 8 0 2 0 0 0 > > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): UNIT ATTENTION asc:28,0 > > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): Not ready to ready change, > > medium may have changed > > > > The tape drive is detected as > > > > sa0 at ahc0 bus 0 target 3 lun 0 > > sa0: Removable Sequential Access SCSI-2 device > > sa0: 10.000MB/s transfers (10.000MHz, offset 32) > > > > ``camcontrol eject 0:3:0'' does eject the media. > > > > Is the new mt behavior intentional? Is ``camcontrol eject'' the preferred way > > to eject media? -- | / 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 Nov 21 14:39:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 099BE1581A for ; Sun, 21 Nov 1999 14:39:16 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id OAA01111; Sun, 21 Nov 1999 14:39:54 -0800 Date: Sun, 21 Nov 1999 14:39:54 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: Jos.Backus@nl.origin-it.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Tape eject problem In-Reply-To: <199911211819.TAA42168@yedi.iaf.nl> 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 Fixed, integrated. On Sun, 21 Nov 1999, Wilko Bulte wrote: > As Matthew Jacob wrote ... > > FWIW: similar thing here on a TZ87 DLT. After the rewind completes the > mt command just sits there, apparantly waiting for something that never > occurs to it ;-) > > > Sounds like a bug to me. Sorry, I'll check it out today. > > > > On Sun, 21 Nov 1999, Jos Backus wrote: > > > > > [This is with a -current kernel & world as of today.] > > > > > > # mt rewoffl > > > > > > used to rewind and eject a tape cartrigde, if present. It rewinds but no > > > longer ejects, instead the unit just goes off-line. > > > Also, I'm seeing > > > > > > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): READ(06). CDB: 8 0 2 0 0 0 > > > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): UNIT ATTENTION asc:28,0 > > > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): Not ready to ready change, > > > medium may have changed > > > > > > The tape drive is detected as > > > > > > sa0 at ahc0 bus 0 target 3 lun 0 > > > sa0: Removable Sequential Access SCSI-2 device > > > sa0: 10.000MB/s transfers (10.000MHz, offset 32) > > > > > > ``camcontrol eject 0:3:0'' does eject the media. > > > > > > Is the new mt behavior intentional? Is ``camcontrol eject'' the preferred way > > > to eject media? > > -- > | / 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 Nov 21 14:40:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 85C9B15859 for ; Sun, 21 Nov 1999 14:40:25 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id OAA01125; Sun, 21 Nov 1999 14:40:58 -0800 Date: Sun, 21 Nov 1999 14:40:58 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Randy Bush Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: DLT2000 must have tape at boot to write In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org How about some context here? As far as I know, this is the first mail on this subject I've seen. This is also completely content free in terms of actual information. So there's a write error... What are the kernel messages? On Sun, 21 Nov 1999, Randy Bush wrote: > i lied. it just took longer to fail > > rip.psg.com:/root# /do-dump > DUMP: Date of this level 0 dump: Sun Nov 21 14:28:48 1999 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /dev/rsd0s1a (/) to /dev/nrsa0 > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 26344 tape blocks. > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > DUMP: DUMP: 26356 tape blocks on 1 volume > DUMP: finished in 21 seconds, throughput 1255 KBytes/sec > DUMP: level 0 dump on Sun Nov 21 14:28:48 1999 > DUMP: Closing /dev/nrsa0 > DUMP: DUMP IS DONE > DUMP: Date of this level 0 dump: Sun Nov 21 14:29:14 1999 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /dev/rsd1s1e (/root) to /dev/nrsa0 > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 92 tape blocks. > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > DUMP: DUMP: 91 tape blocks on 1 volume > DUMP: finished in less than a second > DUMP: level 0 dump on Sun Nov 21 14:29:14 1999 > DUMP: Closing /dev/nrsa0 > DUMP: DUMP IS DONE > DUMP: Date of this level 0 dump: Sun Nov 21 14:29:18 1999 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /dev/rccd3c (/var) to /dev/nrsa0 > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 53700 tape blocks. > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > DUMP: DUMP: 53674 tape blocks on 1 volume > DUMP: finished in 42 seconds, throughput 1277 KBytes/sec > DUMP: level 0 dump on Sun Nov 21 14:29:18 1999 > DUMP: Closing /dev/nrsa0 > DUMP: DUMP IS DONE > DUMP: Date of this level 0 dump: Sun Nov 21 14:30:04 1999 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /dev/rccd4c (/var/spool) to /dev/nrsa0 > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 22075 tape blocks. > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > DUMP: DUMP: 22067 tape blocks on 1 volume > DUMP: finished in 18 seconds, throughput 1225 KBytes/sec > DUMP: level 0 dump on Sun Nov 21 14:30:04 1999 > DUMP: Closing /dev/nrsa0 > DUMP: DUMP IS DONE > DUMP: Date of this level 0 dump: Sun Nov 21 14:30:26 1999 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /dev/rccd5c (/usr) to /dev/nrsa0 > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 4086561 tape blocks. > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > DUMP: write error 274140 blocks into volume 1 > DUMP: Do you want to restart?: ("yes" or "no") > > randy > > > 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 Sun Nov 21 14:48:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id C48B214C2E for ; Sun, 21 Nov 1999 14:48:19 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id OAA01149; Sun, 21 Nov 1999 14:49:02 -0800 Date: Sun, 21 Nov 1999 14:49:02 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Randy Bush Cc: scsi@freebsd.org Subject: Re: DLT2000 must have tape at boot to write In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (I sure didn't see it - did you send it to SCSI@freebsd.org?) Posibly not a tape driver problem- this is where a disconnected command timed out while disconnected. Justing could say ore accurately what these messages mean. Try turning on CAMDEBUG and do debug -Ic for this device - it'll fill up your messages file, but at least we'll know what the last CDB active was before things died. I should note that I've seen this before on DLTs a lot- they seem to just go completely out to lunch sometimes near EOT. I haven't had the time or proper h/w to track it down (I have one 19th hand DLT4000 that was some random Sun OEM'd model). Since I've spent > 5K$ on FreeBSD h/w not tied to any paying project this year already, I'm not inclined to buy another tape drive until at least January. -matt On Sun, 21 Nov 1999, Randy Bush wrote: > sorry my prev message has context > > Nov 21 14:35:06 rip /kernel: Unexpected busfree. LASTPHASE == 0x0 > Nov 21 14:35:06 rip /kernel: SEQADDR == 0x5e > Nov 21 14:40:35 rip /kernel: (sa0:ahc0:0:6:0): SCB 0x67 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > Nov 21 14:40:35 rip /kernel: (sa0:ahc0:0:6:0): Queuing a BDR SCB > Nov 21 14:40:35 rip /kernel: (sa0:ahc0:0:6:0): Bus Device Reset Message Sent > Nov 21 14:40:35 rip /kernel: (sa0:ahc0:0:6:0): no longer in timeout, status = 34 > b > Nov 21 14:40:35 rip /kernel: ahc0: Bus Device Reset on A:6. 1 SCBs aborted > > > How about some context here? As far as I know, this is the first mail on > > this subject I've seen. This is also completely content free in terms of > > actual information. So there's a write error... What are the kernel > > messages? > > > > > > On Sun, 21 Nov 1999, Randy Bush wrote: > > > > > i lied. it just took longer to fail > > > > > > rip.psg.com:/root# /do-dump > > > DUMP: Date of this level 0 dump: Sun Nov 21 14:28:48 1999 > > > DUMP: Date of last level 0 dump: the epoch > > > DUMP: Dumping /dev/rsd0s1a (/) to /dev/nrsa0 > > > DUMP: mapping (Pass I) [regular files] > > > DUMP: mapping (Pass II) [directories] > > > DUMP: estimated 26344 tape blocks. > > > DUMP: dumping (Pass III) [directories] > > > DUMP: dumping (Pass IV) [regular files] > > > DUMP: DUMP: 26356 tape blocks on 1 volume > > > DUMP: finished in 21 seconds, throughput 1255 KBytes/sec > > > DUMP: level 0 dump on Sun Nov 21 14:28:48 1999 > > > DUMP: Closing /dev/nrsa0 > > > DUMP: DUMP IS DONE > > > DUMP: Date of this level 0 dump: Sun Nov 21 14:29:14 1999 > > > DUMP: Date of last level 0 dump: the epoch > > > DUMP: Dumping /dev/rsd1s1e (/root) to /dev/nrsa0 > > > DUMP: mapping (Pass I) [regular files] > > > DUMP: mapping (Pass II) [directories] > > > DUMP: estimated 92 tape blocks. > > > DUMP: dumping (Pass III) [directories] > > > DUMP: dumping (Pass IV) [regular files] > > > DUMP: DUMP: 91 tape blocks on 1 volume > > > DUMP: finished in less than a second > > > DUMP: level 0 dump on Sun Nov 21 14:29:14 1999 > > > DUMP: Closing /dev/nrsa0 > > > DUMP: DUMP IS DONE > > > DUMP: Date of this level 0 dump: Sun Nov 21 14:29:18 1999 > > > DUMP: Date of last level 0 dump: the epoch > > > DUMP: Dumping /dev/rccd3c (/var) to /dev/nrsa0 > > > DUMP: mapping (Pass I) [regular files] > > > DUMP: mapping (Pass II) [directories] > > > DUMP: estimated 53700 tape blocks. > > > DUMP: dumping (Pass III) [directories] > > > DUMP: dumping (Pass IV) [regular files] > > > DUMP: DUMP: 53674 tape blocks on 1 volume > > > DUMP: finished in 42 seconds, throughput 1277 KBytes/sec > > > DUMP: level 0 dump on Sun Nov 21 14:29:18 1999 > > > DUMP: Closing /dev/nrsa0 > > > DUMP: DUMP IS DONE > > > DUMP: Date of this level 0 dump: Sun Nov 21 14:30:04 1999 > > > DUMP: Date of last level 0 dump: the epoch > > > DUMP: Dumping /dev/rccd4c (/var/spool) to /dev/nrsa0 > > > DUMP: mapping (Pass I) [regular files] > > > DUMP: mapping (Pass II) [directories] > > > DUMP: estimated 22075 tape blocks. > > > DUMP: dumping (Pass III) [directories] > > > DUMP: dumping (Pass IV) [regular files] > > > DUMP: DUMP: 22067 tape blocks on 1 volume > > > DUMP: finished in 18 seconds, throughput 1225 KBytes/sec > > > DUMP: level 0 dump on Sun Nov 21 14:30:04 1999 > > > DUMP: Closing /dev/nrsa0 > > > DUMP: DUMP IS DONE > > > DUMP: Date of this level 0 dump: Sun Nov 21 14:30:26 1999 > > > DUMP: Date of last level 0 dump: the epoch > > > DUMP: Dumping /dev/rccd5c (/usr) to /dev/nrsa0 > > > DUMP: mapping (Pass I) [regular files] > > > DUMP: mapping (Pass II) [directories] > > > DUMP: estimated 4086561 tape blocks. > > > DUMP: dumping (Pass III) [directories] > > > DUMP: dumping (Pass IV) [regular files] > > > DUMP: write error 274140 blocks into volume 1 > > > DUMP: Do you want to restart?: ("yes" or "no") > > > > > > randy > > > > > > > > > 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 Sun Nov 21 15: 2:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dialup124.zpr.uni-koeln.de (1-118.K.dial.o-tel-o.net [212.144.1.118]) by hub.freebsd.org (Postfix) with ESMTP id 6DA5C14E47; Sun, 21 Nov 1999 15:02:34 -0800 (PST) (envelope-from se@zpr.uni-koeln.de) Received: by dialup124.zpr.uni-koeln.de (Postfix, from userid 200) id 56228C24; Sun, 21 Nov 1999 21:26:59 +0100 (CET) Date: Sun, 21 Nov 1999 21:26:59 +0100 From: Stefan Esser To: Jos Backus Cc: freebsd-scsi@FreeBSD.ORG, Stefan Esser Subject: Re: Tape eject problem Message-ID: <19991121212659.A5103@dialup124.zpr.uni-koeln.de> Reply-To: se@freebsd.org References: <19991121185852.A75911@hal.mpn.cp.philips.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <19991121185852.A75911@hal.mpn.cp.philips.com>; from Jos Backus on Sun, Nov 21, 1999 at 06:58:52PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-11-21 18:58 +0100, Jos Backus wrote: > [This is with a -current kernel & world as of today.] > > # mt rewoffl > > used to rewind and eject a tape cartrigde, if present. It rewinds but no > longer ejects, instead the unit just goes off-line. > Also, I'm seeing > > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): READ(06). CDB: 8 0 2 0 0 0 > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): UNIT ATTENTION asc:28,0 > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): Not ready to ready change, > medium may have changed > > The tape drive is detected as > > sa0 at ahc0 bus 0 target 3 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 10.000MB/s transfers (10.000MHz, offset 32) > > ``camcontrol eject 0:3:0'' does eject the media. > > Is the new mt behavior intentional? Is ``camcontrol eject'' the preferred way > to eject media? The problem appears to be caused by recent changes to scsi_sa.c. You may want to try the following patch: Index: /sys/cam/scsi/scsi_sa.c =================================================================== RCS file: /usr/cvs/src/sys/cam/scsi/scsi_sa.c,v retrieving revision 1.38 diff -u -2 -r1.38 scsi_sa.c --- scsi_sa.c 1999/11/17 17:11:21 1.38 +++ scsi_sa.c 1999/11/21 20:25:15 @@ -1037,7 +1037,7 @@ */ + saprevent(periph, PR_ALLOW); softc->flags &= ~(SA_FLAG_TAPE_LOCKED| SA_FLAG_TAPE_FROZEN|SA_FLAG_TAPE_MOUNTED); - saprevent(periph, PR_ALLOW); if (error == 0) error = saloadunload(periph, FALSE); 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 Nov 21 15: 6: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1C50B152A5; Sun, 21 Nov 1999 15:06:01 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id PAA01194; Sun, 21 Nov 1999 15:06:46 -0800 Date: Sun, 21 Nov 1999 15:06:46 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Stefan Esser Cc: Jos Backus , freebsd-scsi@FreeBSD.ORG Subject: Re: Tape eject problem In-Reply-To: <19991121212659.A5103@dialup124.zpr.uni-koeln.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 Why don't you catch up on your mail before blasting away. It's already been noted and checked in for crap's sake... On Sun, 21 Nov 1999, Stefan Esser wrote: > On 1999-11-21 18:58 +0100, Jos Backus wrote: > > [This is with a -current kernel & world as of today.] > > > > # mt rewoffl > > > > used to rewind and eject a tape cartrigde, if present. It rewinds but no > > longer ejects, instead the unit just goes off-line. > > Also, I'm seeing > > > > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): READ(06). CDB: 8 0 2 0 0 0 > > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): UNIT ATTENTION asc:28,0 > > Nov 21 17:49:50 jos /kernel: (sa0:ahc0:0:3:0): Not ready to ready change, > > medium may have changed > > > > The tape drive is detected as > > > > sa0 at ahc0 bus 0 target 3 lun 0 > > sa0: Removable Sequential Access SCSI-2 device > > sa0: 10.000MB/s transfers (10.000MHz, offset 32) > > > > ``camcontrol eject 0:3:0'' does eject the media. > > > > Is the new mt behavior intentional? Is ``camcontrol eject'' the preferred way > > to eject media? > > The problem appears to be caused by recent changes to scsi_sa.c. > You may want to try the following patch: > > Index: /sys/cam/scsi/scsi_sa.c > =================================================================== > RCS file: /usr/cvs/src/sys/cam/scsi/scsi_sa.c,v > retrieving revision 1.38 > diff -u -2 -r1.38 scsi_sa.c > --- scsi_sa.c 1999/11/17 17:11:21 1.38 > +++ scsi_sa.c 1999/11/21 20:25:15 > @@ -1037,7 +1037,7 @@ > */ > > + saprevent(periph, PR_ALLOW); > softc->flags &= ~(SA_FLAG_TAPE_LOCKED| > SA_FLAG_TAPE_FROZEN|SA_FLAG_TAPE_MOUNTED); > - saprevent(periph, PR_ALLOW); > if (error == 0) > error = saloadunload(periph, FALSE); > > Regards, STefan > > > 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 Sun Nov 21 15:11:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dialup124.zpr.uni-koeln.de (1-115.K.dial.o-tel-o.net [212.144.1.115]) by hub.freebsd.org (Postfix) with ESMTP id 8132A158DE; Sun, 21 Nov 1999 15:10:55 -0800 (PST) (envelope-from se@zpr.uni-koeln.de) Received: by dialup124.zpr.uni-koeln.de (Postfix, from userid 200) id 242D0D16; Mon, 22 Nov 1999 00:10:34 +0100 (CET) Date: Mon, 22 Nov 1999 00:10:34 +0100 From: Stefan Esser To: Wilko Bulte Cc: mjacob@feral.com, Jos.Backus@nl.origin-it.com, freebsd-scsi@FreeBSD.ORG, Stefan Esser Subject: Re: Tape eject problem Message-ID: <19991122001034.A5673@dialup124.zpr.uni-koeln.de> Reply-To: se@freebsd.org References: <199911211819.TAA42168@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199911211819.TAA42168@yedi.iaf.nl>; from Wilko Bulte on Sun, Nov 21, 1999 at 07:19:18PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-11-21 19:19 +0100, Wilko Bulte wrote: > As Matthew Jacob wrote ... > > FWIW: similar thing here on a TZ87 DLT. After the rewind completes the > mt command just sits there, apparantly waiting for something that never > occurs to it ;-) Had the same problem with my DLT7000 (in an EXB18D tape library). The patch following should fix it (already submitted) : Index: /sys/cam/scsi/scsi_sa.c =================================================================== RCS file: /usr/cvs/src/sys/cam/scsi/scsi_sa.c,v retrieving revision 1.38 diff -u -2 -r1.38 scsi_sa.c --- scsi_sa.c 1999/11/17 17:11:21 1.38 +++ scsi_sa.c 1999/11/21 20:25:15 @@ -1037,7 +1037,7 @@ */ + saprevent(periph, PR_ALLOW); softc->flags &= ~(SA_FLAG_TAPE_LOCKED| SA_FLAG_TAPE_FROZEN|SA_FLAG_TAPE_MOUNTED); - saprevent(periph, PR_ALLOW); if (error == 0) error = saloadunload(periph, FALSE); 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 Nov 21 17:30:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 60B3914F53 for ; Sun, 21 Nov 1999 17:29:51 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.03 #1) id 11piIY-0000II-00; Sun, 21 Nov 1999 17:29:42 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Jacob Cc: freebsd-scsi@freebsd.org Subject: Re: DLT2000 must have tape at boot to write References: Message-Id: Date: Sun, 21 Nov 1999 17:29:42 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > (I sure didn't see it - did you send it to SCSI@freebsd.org?) yes. i will append the copy i received. > Try turning on CAMDEBUG and do debug -Ic for this device - it'll fill up > your messages file, but at least we'll know what the last CDB active was > before things died. results of camdebug kernel appended as well. i believe the error was at Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): \ error 5 resid 10240 count 10240 > I should note that I've seen this before on DLTs a lot- they seem to just > go completely out to lunch sometimes near EOT. I haven't had the time or > proper h/w to track it down (I have one 19th hand DLT4000 that was some > random Sun OEM'd model). Since I've spent > 5K$ on FreeBSD h/w not tied to > any paying project this year already, I'm not inclined to buy another tape > drive until at least January. > > -matt randy From: Randy Bush To: freebsd-scsi@freebsd.org Subject: DLT2000 must have tape at boot to write Date: Sun, 21 Nov 1999 14:35:59 -0800 ASUS P2B-DS 3.3-stable DLT2000 if i reset and bopot with no tape in drive, i can read the tape. but if i try to dump, i get write errors in the second file. if i put a tape in the drive, ready the tape, and then reset and boot, i can dump just fine. this is similar to the cd-rom writer. clues? randy 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.3-STABLE #0: Sun Nov 21 14:23:24 PST 1999 root@rip.psg.com:/usr/src/sys/compile/RIP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Features=0x183fbff real memory = 134217728 (131072K bytes) avail memory = 127434752 (124448K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02db000. Preloaded userconfig_script "/kernel.config" at 0xc02db09c. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.1.0 chip2: rev 0x02 on pci0.4.0 chip3: rev 0x02 on pci0.4.3 ahc0: rev 0x00 int a irq 19 on pci0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs fxp0: rev 0x05 int a irq 19 on pci0.9.0 fxp0: Ethernet address 00:a0:c9:df:c8:4e bktr0: rev 0x02 int a irq 18 on pci0.10.0 bti2c0: iicbb0: on bti2c0 iicbus0: on iicbb0 master-only smbus0: on bti2c0 smb0: on smbus0 bktr0: Hauppauge Model 61111 A M bktr0: Detected a MSP3430G-A1 at 0x80 Hauppauge WinCast/TV, Philips NTSC tuner, msp3400c stereo. Probing for devices on PCI bus 1: vga0: rev 0x00 int a irq 16 on pci1.0.0 Probing for PnP devices: CSN 1 Vendor ID: CTL00c3 [0xc3008c0e] Serial 0x1fd0a682 Comp ID: PNPb02f [0x2fb0d041] pcm1 (SB16pnp sn 0x1fd0a682) at 0x220-0x22f irq 5 drq 1 flags 0x15 on isa 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 psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A pcm0 not probed due to drq conflict with pcm1 at 1 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface wl0 at 0x300-0x30f irq 7 on isa wl0: address 08:00:6a:2b:dd:cb, NWID 0xaaaa APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 ccd0-5: Concatenated disk drivers Waiting 30 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! sa0 at ahc0 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 15) changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ahc0 bus 0 target 5 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 8.333MB/s transfers (8.333MHz, offset 31) cd1: cd present [140956 x 2048 byte records] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message -------------------- Nov 21 17:14:28 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_compile_path Nov 21 17:14:28 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:14:28 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:14:28 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:14:28 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:14:28 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:14:28 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:40 rip /kernel.cam: (sa0:ahc0:0:6:0): saopen(0): dev=0x0 softc=0x0 Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): RESERVE(06). CDB: 16 0 0 0 0 0 Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 42 Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): RESERVE(06). CDB: 16 0 0 0 0 0 Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 49 Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:42 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 42 Nov 21 17:16:44 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 42 Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): READ BLOCK LIMITS. CDB: 5 0 0 0 0 0 Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 49 Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): MODE SENSE(06). CDB: 1a 0 f 0 1c 0 Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 42 Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): Mode Sense Data= 0x1b 0x84 0x10 0x08 0x19 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0f 0x0e 0xc0 0x80 0x00 0x00 0x00 0x10 0x00 0x00 0x00 0x10 0x00 0x00 0x00 0x00 Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:16:46 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:16:47 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:48 rip /kernel.cam: (sa0:ahc0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 42 Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): saioctl: op=0x5 count=0x1 Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): REWIND. CDB: 1 0 0 0 0 0 Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 42 Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): saclose(0): dev=0x0 softc=0xc0d Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 0 0 Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 49 Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): RELEASE(06). CDB: 17 0 0 0 0 0 Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 42 Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:49 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr Nov 21 17:16:51 rip /kernel.cam: (sa0:ahc0:0:6:0): saopen(0): dev=0x0 softc=0xc08 Nov 21 17:16:52 rip /kernel.cam: (sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:16:52 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:16:53 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:16:53 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:53 rip /kernel.cam: (sa0:ahc0:0:6:0): RESERVE(06). CDB: 16 0 0 0 0 0 Nov 21 17:16:53 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:53 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 4 Nov 21 17:16:53 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:53 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:16:53 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:16:53 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:16:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:55 rip /kernel.cam: (sa0:ahc0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Nov 21 17:16:56 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:57 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 4 Nov 21 17:16:57 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:16:57 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:16:57 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:16:57 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:16:57 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:16:57 rip /kernel.cam: (sa0:ahc0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 Nov 21 17:16:58 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:16:59 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 4 Nov 21 17:16:59 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:17:00 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:17:00 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:17:01 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:17:02 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:17:02 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:17:02 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:17:03 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:17:03 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 42 Nov 21 17:17:03 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:17:04 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:17:04 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:17:04 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:17:05 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:17:05 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:17:05 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:17:07 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:17:08 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 4 Nov 21 17:17:08 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:17:09 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:17:10 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:17:11 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:17:12 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:17:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:17:15 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:17:16 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:17:16 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 52 Nov 21 17:17:17 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:17:18 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:17:19 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:17:19 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:17:21 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:17:21 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:17:22 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:17:22 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:17:23 rip /kernel.cam: (sa0:ahc0:0: Nov 21 17:17:24 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:17:24 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:17:25 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:17:25 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:17:26 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 52 Nov 21 17:17:26 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:17:27 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:17:29 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:17:30 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:17:31 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:17:32 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:17:33 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:17:34 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:17:35 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 33 Nov 21 17:17:36 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:17:37 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:17:37 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:17:38 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:17:39 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:17:41 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:17:42 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:17:43 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_actio_ccb Nov 21 17:17:43 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:17:44 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:17:45 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:17:46 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:17:47 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 59 Nov 21 17:17:48 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:17:49 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:17:51 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:17:51 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:17:52 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:17:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:17:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:17:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:17:56 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 16 Nov 21 17:17:57 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:17:58 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:17:59 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:18:01 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:18:02 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:03 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:04 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:06 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:07 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:08 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:09 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:11 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 59 Nov 21 17:18:12 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:18:13 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:18:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:18:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:18:14 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:14 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:14 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:14 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 33 Nov 21 17:18:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:18:15 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:18:15 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:18:15 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:18:15 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:16 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:17 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:17 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:18 rip /kernel.cam: (s(sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:19 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:21 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:22 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:22 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 33 Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 54 Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:18:23 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:24 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:24 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:24 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:25 rip /kernel.cam: (sa0:ahc0(sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:26 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:26 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:26 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:27 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 58 Nov 21 17:18:27 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:18:28 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:18:29 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:18:31 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:18:31 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:32 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:34 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:35 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:35 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 46 Nov 21 17:18:36 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:18:36 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:18:37 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:18:37 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:18:37 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:37 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:37 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:37 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:37 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:37 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:37 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:37 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:37 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 58 Nov 21 17:18:37 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:18:38 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:18:38 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:18:39 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:18:40 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:40 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:41 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:41 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:41 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 58 Nov 21 17:18:41 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:18:42 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:18:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:18:43 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:18:44 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:44 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:45 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:46 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:46 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:47 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:47 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:48 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:49 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 59 Nov 21 17:18:50 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:18:50 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:18:51 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:18:52 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:18:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:18:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:18:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:18:56 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:18:57 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 58 Nov 21 17:18:58 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:18:59 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:19:00 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:19:05 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:19:06 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:06 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:19:07 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:19:07 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:19:09 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:19:10 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:19:11 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:11 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:19:11 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:19:11 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:19:12 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 46 Nov 21 17:19:12 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:19:13 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:19:13 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:19:13 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:19:13 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:13 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:19:13 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:19:13 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:19:13 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 34 Nov 21 17:19:13 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:19:13 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:19:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:19:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:19:14 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_actiob Nov 21 17:19:14 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:19:14 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:19:15 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:19:15 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 59 Nov 21 17:19:15 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:19:15 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:19:15 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:19:16 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:19:18 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:18 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:19:19 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:19:21 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:19:21 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 34 Nov 21 17:19:21 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:19:22 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:19:23 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:19:23 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:19:23 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:23 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:19:23 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:19:24 rip /kernel.cam: (sa0:ahc0:0 Nov 21 17:19:25 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:25 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:19:25 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:19:25 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:19:26 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 58 Nov 21 17:19:26 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:19:27 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:19:28 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:19:29 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:19:29 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:29 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:19:29 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:19:29 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:19:29 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 59 Nov 21 17:19:29 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:19:29 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:19:29 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:19:29 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:19:29 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:30 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:19:30 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:19:31 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_actionwrite queue count now 1 Nov 21 17:19:31 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:19:32 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:19:33 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:33 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:19:34 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:19:35 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:19:36 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 58 Nov 21 17:19:37 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:19:37 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:19:37 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:19:37 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:19:38 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:38 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:19:39 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:19:39 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:19:39 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 16 Nov 21 17:19:40 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:19:41 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:19:41 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:19:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:19:42 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:42 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:19:43 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:19:43 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:19:44 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:19:44 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 33 Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 52 Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:04 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 46 Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:06 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:07 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:07 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 59 Nov 21 17:20:07 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:08 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:09 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:10 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:10 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:10 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:10 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:10 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:10 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:10 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:11 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:11 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:12 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 58 Nov 21 17:20:13 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:13 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:15 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:15 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:16 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:16 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:17 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:17 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 16 Nov 21 17:20:18 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:18 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:18 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:19 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:19 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:20 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:20 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:21 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:23 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:24 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:24 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:24 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:24 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:25 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:26 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 4 Nov 21 17:20:27 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:27 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:28 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:28 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:29 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:30 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:34 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:34 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:34 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 16 Nov 21 17:20:35 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:35 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:35 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:36 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:36 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:37 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_acte write queue count now 1 Nov 21 17:20:37 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:37 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:38 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:38 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:38 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:39 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:39 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 42 Nov 21 17:20:40 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:41 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:42 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:43 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:44 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:45 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:46 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:46 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 56 Nov 21 17:20:47 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:47 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:48 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:48 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:49 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:51 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 4 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 54 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 58 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 34 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 34 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 34 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 58 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 54 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 58 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 4 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:54 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 54 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 33 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 47 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 58 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 34 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 56 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 20 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 20 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 42 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 47 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 47 Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_action Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): error 5 resid 10240 count 10240 Nov 21 17:21:04 rip /kernel.cam: (sa0:ahc0:0:6:0): saclose(0): dev=0x0 softc=0xc25 Nov 21 17:21:04 rip /kernel.cam: (sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:21:04 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:21:04 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:21:04 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:21:04 rip /kernel.cam: (sa0:ahc0:0:6:0): WRITE FILEMARKS. CDB: 10 0 0 0 2 0 Nov 21 17:21:04 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:21:09 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 52 Nov 21 17:21:10 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:21:10 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:21:10 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:21:10 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:21:10 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 0 0 Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 52 Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): SPACE. CDB: 11 1 ff ff ff 0 Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 54 Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): RELEASE(06). CDB: 17 0 0 0 0 0 Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 52 Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:21:11 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): saopen(0): dev=0x0 softc=0xc00 Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): RESERVE(06). CDB: 16 0 0 0 0 0 Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 20 Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 20 Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): xpt_action Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 Nov 21 17:21:14 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:21:19 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 20 Nov 21 17:21:19 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:21:19 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): xpt_action Nov 21 17:21:19 rip /kernel.cam: (sa0:ahc0:0:6:0): READ BLOCK LIMITS. CDB: 5 0 0 0 0 0 Nov 21 17:21:19 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:21:19 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 20 Nov 21 17:21:19 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): MODE SENSE(06). CDB: 1a 0 f 0 1c 0 Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 20 Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr(sa0:ahc0:0:6:0): Mode Sense Data= 0x1b 0x84 0x10 0x08 0x19 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x0f 0x0e 0xc0 0x80 0x00 0x00 0x00 0x10 0x00 0x00 0x00 0x10 0x00 0x00 0x00 0x00 Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): entering cdgetccb Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_schedule Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_setup_ccb Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): xpt_action Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_action Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): ahc_done - scb 20 Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): xpt_done Nov 21 17:21:20 rip /kernel.cam: (sa0:ahc0:0:6:0): camisr Nov 21 17:21:28 rip /kernel.cam: (sa0:ahc0:0:6:0): saopen(0): dev=0x0 softc=0xc0d ------------------- and the dump failure rip.psg.com:/root# /do-dump DUMP: Date of this level 0 dump: Sun Nov 21 17:16:49 1999 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rsd0s1a (/) to /dev/nrsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 28131 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: write error 2150 blocks into volume 1 DUMP: Do you want to restart?: ("yes" or "no") no DUMP: The ENTIRE dump is aborted. ^C^C^C^C^C^C^C^C^C^C DUMP: Date of this level 0 dump: Sun Nov 21 17:21:11 1999 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/rsd1s1e (/root) to /dev/nrsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 92 tape blocks. ^C^C DUMP: Interrupt received. DUMP: Do you want to abort dump?: ("yes" or "no") DUMP: DUMP: Terminated To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Nov 21 18:20:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 343D314DAF for ; Sun, 21 Nov 1999 18:20:29 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id SAA01746; Sun, 21 Nov 1999 18:21:12 -0800 Date: Sun, 21 Nov 1999 18:21:12 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Randy Bush Cc: freebsd-scsi@freebsd.org Subject: Re: DLT2000 must have tape at boot to write In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org - > > (I sure didn't see it - did you send it to SCSI@freebsd.org?) > > yes. i will append the copy i received. > > > Try turning on CAMDEBUG and do debug -Ic for this device - it'll fill up > > your messages file, but at least we'll know what the last CDB active was > > before things died. > > results of camdebug kernel appended as well. i believe the error was at > > Nov 21 17:20:55 rip /kernel.cam: (sa0:ahc0:0:6:0): \ > error 5 resid 10240 count 10240 > ASUS P2B-DS > 3.3-stable > DLT2000 > if i reset and bopot with no tape in drive, i can read the tape. but if i > try to dump, i get write errors in the second file. > if i put a tape in the drive, ready the tape, and then reset and boot, i can > dump just fine. This is pretty strange. I'm not disputing what you're saying, but it doesn't make much sense. An error is being reported back up - and I'm not seeing all the information- did you do a 'camcontrol debug -Ic 0:6:0' I'm seeing the CDBs, but not any sense data. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Nov 21 21:50:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id A0069158B0 for ; Sun, 21 Nov 1999 21:50:12 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.03 #1) id 11pmMb-0000tY-00; Sun, 21 Nov 1999 21:50:09 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Jacob Cc: freebsd-scsi@freebsd.org Subject: Re: DLT2000 must have tape at boot to write References: Message-Id: Date: Sun, 21 Nov 1999 21:50:09 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > And this tells me that while we were writing to the tape, the tape just > gave up and dropped off the bus. > > Nov 21 20:40:43 (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 > Nov 21 20:40:43 (sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 > Nov 21 20:40:43 (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 > Nov 21 20:40:43 (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 > Nov 21 20:40:43 Unexpected busfree. LASTPHASE == 0x0 > Nov 21 20:40:43 SEQADDR == 0x5e > Nov 21 20:40:43 (sa0:ahc0:0:6:0): Cam Status 0x13 > Nov 21 20:40:43 (sa0:ahc0:0:6:0): error 5 resid 10240 count 10240 > > is a giveaway. > > it really sounds like broken h/w to me. What do you think? hmmmm. not disagreeing, but am trying to think of all possibilities before rmaing the wrong part or buying new. what if i have some parameter mistuned on the cmos? could it be a p2b-ds motherboard multi-scsi issue with the tape and the disks being dumped on the same controller? to kind of test this hypothesis, i just rdumped another (even larger) system to this tape drive over 100baseT. the rdump was successful. randy 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.3-STABLE #4: Sun Nov 21 20:21:24 PST 1999 root@rip.psg.com:/usr/src/sys/compile/RIP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Features=0x183fbff real memory = 134217728 (131072K bytes) avail memory = 127721472 (124728K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.1.0 chip2: rev 0x02 on pci0.4.0 chip3: rev 0x02 on pci0.4.3 ahc0: rev 0x00 int a irq 19 on pci0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs fxp0: rev 0x05 int a irq 19 on pci0.9.0 fxp0: Ethernet address 00:a0:c9:df:c8:4e bktr0: rev 0x02 int a irq 18 on pci0.10.0 bti2c0: iicbb0: on bti2c0 iicbus0: on iicbb0 master-only smbus0: on bti2c0 smb0: on smbus0 bktr0: Hauppauge Model 61111 A M bktr0: Detected a MSP3430G-A1 at 0x80 Hauppauge WinCast/TV, Philips NTSC tuner, msp3400c stereo. Probing for devices on PCI bus 1: vga0: rev 0x00 int a irq 16 on pci1.0.0 Probing for PnP devices: CSN 1 Vendor ID: CTL00c3 [0xc3008c0e] Serial 0x1fd0a682 Comp ID: PNPb02f [0x2fb0d041] pcm1 (SB16pnp sn 0x1fd0a682) at 0x220-0x22f irq 5 drq 1 flags 0x15 on isa 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 psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A pcm0 not probed due to drq conflict with pcm1 at 1 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface wl0 at 0x300-0x30f irq 7 on isa wl0: address 08:00:6a:2b:dd:cb, NWID 0xaaa APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 ccd0-5: Concatenated disk drivers Waiting 30 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! sa0 at ahc0 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 15) changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ahc0 bus 0 target 5 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 8.333MB/s transfers (8.333MHz, offset 31) cd1: cd present [140956 x 2048 byte records] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Nov 21 21:58:38 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 850451517C for ; Sun, 21 Nov 1999 21:57:41 -0800 (PST) (envelope-from mjacob@feral.com) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.8.7/8.8.7) with ESMTP id VAA02192; Sun, 21 Nov 1999 21:58:24 -0800 Date: Sun, 21 Nov 1999 21:58:24 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Randy Bush Cc: freebsd-scsi@freebsd.org Subject: Re: DLT2000 must have tape at boot to write In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > it really sounds like broken h/w to me. What do you think? > > hmmmm. not disagreeing, but am trying to think of all possibilities before > rmaing the wrong part or buying new. > > what if i have some parameter mistuned on the cmos? > > could it be a p2b-ds motherboard multi-scsi issue with the tape and the > disks being dumped on the same controller? > > to kind of test this hypothesis, i just rdumped another (even larger) system > to this tape drive over 100baseT. the rdump was successful. > Not disagreeing, but it still sounds like h/w to me. The question is 'which'? Do you have another SCSI controller to put your drive on? You have a wide ultra2 mixex with narrow/fast. Seems like asking for trouble (I'm sure ken/justin will tell me if I'm all wet..) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Nov 21 22:26:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 9739E14C1A for ; Sun, 21 Nov 1999 22:26:13 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id XAA17718; Sun, 21 Nov 1999 23:26:04 -0700 (MST) (envelope-from ken) Message-Id: <199911220626.XAA17718@panzer.kdm.org> Subject: Re: DLT2000 must have tape at boot to write In-Reply-To: from Matthew Jacob at "Nov 21, 1999 09:58:24 pm" To: mjacob@feral.com Date: Sun, 21 Nov 1999 23:26:04 -0700 (MST) Cc: randy@psg.com (Randy Bush), freebsd-scsi@FreeBSD.ORG From: "Kenneth D. Merry" 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 Matthew Jacob wrote... > > > it really sounds like broken h/w to me. What do you think? > > > > hmmmm. not disagreeing, but am trying to think of all possibilities before > > rmaing the wrong part or buying new. > > > > what if i have some parameter mistuned on the cmos? > > > > could it be a p2b-ds motherboard multi-scsi issue with the tape and the > > disks being dumped on the same controller? > > > > to kind of test this hypothesis, i just rdumped another (even larger) system > > to this tape drive over 100baseT. the rdump was successful. > > > > Not disagreeing, but it still sounds like h/w to me. The question is 'which'? > Do you have another SCSI controller to put your drive on? You have a > wide ultra2 mixex with narrow/fast. Seems like asking for trouble > (I'm sure ken/justin will tell me if I'm all wet..) That isn't bad in and of itself. The ASUS boards are essentially like a 2940U2W. They've got a 7890 on board, plus a 3860 SCSI-SCSI bridge to separate the Ultra2 part of the bus from the single ended part of the bus. The thing that's bad is the Unexpected Busfree Randy reported in an earlier message. That smells like a firmware problem, although it's hard to say for sure. Justin might have a more concrete idea. (You may need to mail him directly with the relevant error messages.) It could be that the tape drive doens't play well on the SCSI bus with other devices, or doesn't work well when there's a lot of load on its bus. I think Matt's suggestion is a good one -- see if you can grab another controller to put your drive on to separate it from your disks. Your dump over 100BaseT would be similar, from the tape drive's standpoint, to having the tape drive on a different SCSI bus. (since you weren't dumping from disks on the same SCSI bus) Even if the DLT drive has broken firmware, you may be able to work around the problem by putting it on a separate SCSI bus. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Nov 22 5:51: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id CABD214C23 for ; Mon, 22 Nov 1999 05:51:03 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.03 #1) id 11ptrx-0000dY-00; Mon, 22 Nov 1999 05:51:01 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Jacob Cc: freebsd-scsi@freebsd.org Subject: Re: DLT2000 must have tape at boot to write References: Message-Id: Date: Mon, 22 Nov 1999 05:51:01 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Nov 21 20:40:43 (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 >> Nov 21 20:40:43 (sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 >> Nov 21 20:40:43 (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 >> Nov 21 20:40:43 (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 >> Nov 21 20:40:43 Unexpected busfree. LASTPHASE == 0x0 >> Nov 21 20:40:43 SEQADDR == 0x5e >> Nov 21 20:40:43 (sa0:ahc0:0:6:0): Cam Status 0x13 >> Nov 21 20:40:43 (sa0:ahc0:0:6:0): error 5 resid 10240 count 10240 > Not disagreeing, but it still sounds like h/w to me. The question is > 'which'? Do you have another SCSI controller to put your drive on? You > have a wide ultra2 mixex with narrow/fast. Seems like asking for trouble > (I'm sure ken/justin will tell me if I'm all wet..) the morning news: a second rdump failed. and the hard disks did not seem busy during the rdump. note that the system with the tape is a personal workstation with few services, i.e. the disks are not being hammered. i upgraded the asus p2b-ds flash bios. a local dump failed the same old way. i can not find a flash upgrade for the dec dlt2000 tape itself. one thing i forgot to mention, this used to work. i.e. it was either the change from 4.0-current to 3.3-stable or hardware rot. as i tried your back-revved scsi_sa.c, i doubt the former. i do not have a spare scsi controller. i can order one if folk think this will likely solve it. (again note this used to work) as it seems more and more like a hardware issue, i will chase this as an rma through the digital/compaq maze after a bit more coffee. randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Nov 22 5:52:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0CFE815922 for ; Mon, 22 Nov 1999 05:52:50 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id FAA03338; Mon, 22 Nov 1999 05:53:18 -0800 Date: Mon, 22 Nov 1999 05:53:18 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Randy Bush Cc: freebsd-scsi@freebsd.org Subject: Re: DLT2000 must have tape at boot to write In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I believe we cannot help you any further at this time. On Mon, 22 Nov 1999, Randy Bush wrote: > >> Nov 21 20:40:43 (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 > >> Nov 21 20:40:43 (sa0:ahc0:0:6:0): sastrategy: enqueuing a 10240 variable byte write queue count now 1 > >> Nov 21 20:40:43 (sa0:ahc0:0:6:0): sastart(sa0:ahc0:0:6:0): Variable Record Count is 10240 > >> Nov 21 20:40:43 (sa0:ahc0:0:6:0): WRITE(06). CDB: a 0 0 28 0 0 > >> Nov 21 20:40:43 Unexpected busfree. LASTPHASE == 0x0 > >> Nov 21 20:40:43 SEQADDR == 0x5e > >> Nov 21 20:40:43 (sa0:ahc0:0:6:0): Cam Status 0x13 > >> Nov 21 20:40:43 (sa0:ahc0:0:6:0): error 5 resid 10240 count 10240 > > > Not disagreeing, but it still sounds like h/w to me. The question is > > 'which'? Do you have another SCSI controller to put your drive on? You > > have a wide ultra2 mixex with narrow/fast. Seems like asking for trouble > > (I'm sure ken/justin will tell me if I'm all wet..) > > the morning news: > > a second rdump failed. and the hard disks did not seem busy during the > rdump. note that the system with the tape is a personal workstation with > few services, i.e. the disks are not being hammered. > > i upgraded the asus p2b-ds flash bios. a local dump failed the same old > way. > > i can not find a flash upgrade for the dec dlt2000 tape itself. > > one thing i forgot to mention, this used to work. i.e. it was either the > change from 4.0-current to 3.3-stable or hardware rot. as i tried your > back-revved scsi_sa.c, i doubt the former. > > i do not have a spare scsi controller. i can order one if folk think this > will likely solve it. (again note this used to work) > > as it seems more and more like a hardware issue, i will chase this as an rma > through the digital/compaq maze after a bit more coffee. > > randy > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Nov 22 20:15:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 73C2D14ED7 for ; Mon, 22 Nov 1999 20:15:38 -0800 (PST) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id WAA96502; Mon, 22 Nov 1999 22:15:09 -0600 (CST) From: Joe Greco Message-Id: <199911230415.WAA96502@aurora.sol.net> Subject: Re: ncrcontrol-like utility for CAM? To: ken@plutotech.com Date: Mon, 22 Nov 1999 22:15:09 -0600 (CST) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Joe Greco wrote... > > Will there be an ncrcontrol-like utility for CAM? I'm mainly interested > > in statistics, and was unable to find anything obvious after looking over > > the CAM stuff in 3.0-19981015-BETA. It'd be a nice addition, and it was > > a feature I had always missed with the ahc (and others) driver. > > What kind of statistics? Most interesting statistics should be available > through systat(1), iostat(8) and vmstat(8). > > There are other stats that are recorded in the devstat(9) system, but that > aren't displayed in the stats-display utilities. (like the number of > ordered tags, number of outstanding transactions) There's a program on my > ftp site that will dump out the contents of all the devstat(9) structures > in the system: > > ftp://ftp.kdm.org/pub/FreeBSD/cam/ds.c > > If there are stats that aren't available that you'd like to see, let me > know so I can keep them in mind for future enhancements. Well, yes... heh, I sort of lost this thread a year ago. :-) I'd really like to see per-bus statistics. i.e. I'd like to be able to tell that the reason I'm seeing 3MB/sec to an UW drive on scbus0 is because scbus0 is maxxed out (which you could determine if you had overall bus stats for scbus0...) I _think_ ncrcontrol provided that sort of information... ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Nov 22 20:54:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id CBDF214BF6 for ; Mon, 22 Nov 1999 20:54:35 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id VAA86891; Mon, 22 Nov 1999 21:52:58 -0700 (MST) (envelope-from ken) Message-Id: <199911230452.VAA86891@panzer.kdm.org> Subject: Re: ncrcontrol-like utility for CAM? In-Reply-To: <199911230415.WAA96502@aurora.sol.net> from Joe Greco at "Nov 22, 1999 10:15:09 pm" To: jgreco@ns.sol.net (Joe Greco) Date: Mon, 22 Nov 1999 21:52:58 -0700 (MST) Cc: scsi@FreeBSD.ORG From: "Kenneth D. Merry" 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 Joe Greco wrote... > > Joe Greco wrote... > > > Will there be an ncrcontrol-like utility for CAM? I'm mainly interested > > > in statistics, and was unable to find anything obvious after looking over > > > the CAM stuff in 3.0-19981015-BETA. It'd be a nice addition, and it was > > > a feature I had always missed with the ahc (and others) driver. > > > > What kind of statistics? Most interesting statistics should be available > > through systat(1), iostat(8) and vmstat(8). > > > > There are other stats that are recorded in the devstat(9) system, but that > > aren't displayed in the stats-display utilities. (like the number of > > ordered tags, number of outstanding transactions) There's a program on my > > ftp site that will dump out the contents of all the devstat(9) structures > > in the system: > > > > ftp://ftp.kdm.org/pub/FreeBSD/cam/ds.c > > > > If there are stats that aren't available that you'd like to see, let me > > know so I can keep them in mind for future enhancements. > > Well, yes... heh, I sort of lost this thread a year ago. :-) No kidding. > I'd really like to see per-bus statistics. i.e. I'd like to be able to > tell that the reason I'm seeing 3MB/sec to an UW drive on scbus0 is because > scbus0 is maxxed out (which you could determine if you had overall bus stats > for scbus0...) It would certianly be possible to do, but it would be tricky. You'd run into tricky situations in multi-path environments, and I suppose you'd have to charge the transactions against one path or another. > I _think_ ncrcontrol provided that sort of information... It's possible, I dunno for sure. I'll keep it in mind as a possible future enhancement. Obviously, don't hold your breath. :) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Nov 23 8: 0:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from metis.salford.ac.uk (metis.salford.ac.uk [146.87.232.15]) by hub.freebsd.org (Postfix) with SMTP id A4BD114BD7 for ; Tue, 23 Nov 1999 08:00:39 -0800 (PST) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 17101 invoked by alias); 23 Nov 1999 15:59:50 -0000 Received: (qmail 17095 invoked from network); 23 Nov 1999 15:59:49 -0000 Received: from plato.salford.ac.uk (146.87.255.76) by metis.salford.ac.uk with SMTP; 23 Nov 1999 15:59:49 -0000 Received: (qmail 19925 invoked by uid 141); 23 Nov 1999 15:59:49 -0000 Date: Tue, 23 Nov 1999 15:59:49 +0000 (GMT) From: Mark Powell X-Sender: mark@localhost To: freebsd-scsi@freebsd.org Subject: 3.3S won't see a DPT RAID array Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been trying to get a RAID array setup on a box using 3.3S. I've done exactly the same before using a DPT PM3224A with 6x4GB SCSI drives. I want the first drive to appear as the drive itself and the remaining 5 to form a RAID0 array. I can set up the array and at boot time the controller displays it. Booting into DOS sees the 4GB drive and the ~20GB array. Booting FreeBSD shows the usual before starting the kernel: C: is disk 1 D: is disk 2 However, when FBSD boots up it sees all 6 drives individually. Any ideas why? I've not seen this before. I've another machine using exactly; same DPT model, same revision, same firmware; and 3.3S on that machine sees drive and array, as planned. I just can't see what's wrong. I don't want to use vinum, when I shouldn't have to. Cheers. Mark Powell - UNIX System Administrator - Clifford Whitworth Building A.I.S., University of Salford, Salford, Manchester, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key M.S.Powell@ais.salfrd.ac.uk (spell salford correctly to reply to me) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Nov 23 12:38:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front4m.grolier.fr (front4m.grolier.fr [195.36.216.54]) by hub.freebsd.org (Postfix) with ESMTP id AFAB8153A3 for ; Tue, 23 Nov 1999 12:38:21 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-115-171.villette.club-internet.fr [194.158.115.171]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA24846 for ; Tue, 23 Nov 1999 21:38:11 +0100 (MET) Date: Tue, 23 Nov 1999 23:02:45 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: scsi@FreeBSD.org Subject: NEWS: SYM53C1010 and Ultra3 support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I just got the appropriate cable this evening and started testing ultra3=20 support for the C1010. After a tiny fix in the SYM driver I got the following: Nov 23 22:39:58 /T35: (probe0:sym1:0:3:0): nego msgout:: 1-6-4-9-0-3e-1-2. Nov 23 22:39:58 /T35: (probe0:sym1:0:3:0): ppr msg in: 1-6-4-9-0-1f-1-2. Nov 23 22:39:58 /T35: (probe0:sym1:0:3:0): ppr: dt=3D2 ofs=3D31 per=3D9 wi= de=3D1 div=3D0 fak=3D0 chg=3D0. Nov 23 22:39:58 /T35: da2 at sym1 bus 0 target 3 lun 0 Nov 23 22:39:58 /T35: da2: Fixed Direct Acc= ess SCSI-3 device=20 Nov 23 22:39:58 /T35: da2: 160.000MB/s transfers (80.000MHz, offset 31, 16= bit), Tagged Queueing Enabled Nov 23 22:39:58 /T35: da2: 17522MB (35885168 512 byte sectors: 255H 63S/T = 2233C) For now, I just tried reads, and they seemed to work reliably. By the way, the only hack I applied to SCSI is the following (scsi_all.c): static struct { u_int period_factor; u_int period;=09/* in 10ths of ns */ } scsi_syncrates[] =3D { + { 0x09, 125 }, { 0x0a, 250 }, { 0x0b, 303 }, { 0x0c, 500 } }; The sync period factor 9 is read by the driver from the controller NVRAM. I will continue testing the beast. For the full support of Ultra3, Justin will provide changes in CAM and SCSI. The cam/scsi hacks I may add with further driver patches are just minimal things that will be obviously discarded.=20 G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Nov 23 13:27: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mayhem.com (mayhem.com [204.254.116.10]) by hub.freebsd.org (Postfix) with ESMTP id 76743153D9 for ; Tue, 23 Nov 1999 13:25:36 -0800 (PST) (envelope-from jacob@mayhem.com) Received: (from jacob@localhost) by mayhem.com (8.9.1/8.9.1) id QAA04177 for freebsd-scsi@freebsd.org; Tue, 23 Nov 1999 16:25:22 -0500 (EST) (envelope-from jacob) From: Jacob DeGlopper Message-Id: <199911232125.QAA04177@mayhem.com> Subject: SCSI/CAM errors with Yamaha CRW6416sz CD-RW and NCR 815 card To: freebsd-scsi@freebsd.org Date: Tue, 23 Nov 1999 16:25:22 -0500 (EST) 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 I am running FreeBSD 3.0-RELEASE. I have recently acquired a Yamaha CRZ6416sz SCSI CD-RW drive. I have an existing SCSI chain with a NCR 815 card, Seagate disk, and HP DAT drive; all those have been working fine. When booting the system with the new drive installed, I get some errors, and then the system halts. Running a kernel without the SCSI cd device configured gets the CD-ROM recognized by the pass driver without errors. I have double-checked the terminator, and tried other SCSI ids with no change. The drive appears to work fine in Windows. I have also tried adjusting the SCSI_DELAY timeout up to 20 seconds with no change. The specific errors I get are: cd0:ncr0:0:2:0: got CAM status 0x4a fatal error, failed to attach to device (cd0:ncr0:0:2:0) removing device entry then, I get the message ncr0: timeout nccb= (skip) I've also tried the drive in another FreeBSD system with an NCR 875 card, and it failed with the same messages, as did booting with the 3.3 boot disks. I haven't found anything very promising in the archives related to these NCR timeout problems; does anyone have any ideas, or do I have to go out and get a more expensive SCSI card? -- Jacob DeGlopper, FF/EMT-B, N3RHI jacob@mayhem.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Nov 23 15:53:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 0ED4215494 for ; Tue, 23 Nov 1999 15:53:54 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id AAA19104 for scsi@FreeBSD.org; Wed, 24 Nov 1999 00:53:51 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id E2B728864; Wed, 24 Nov 1999 00:42:26 +0100 (CET) Date: Wed, 24 Nov 1999 00:42:26 +0100 From: Ollivier Robert To: scsi@FreeBSD.org Subject: Re: NEWS: SYM53C1010 and Ultra3 support Message-ID: <19991124004226.A8912@keltia.freenix.fr> Mail-Followup-To: scsi@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0pre2i In-Reply-To: X-Operating-System: FreeBSD 4.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Gerard Roudier: > I just got the appropriate cable this evening and started testing ultra3 > support for the C1010. After a tiny fix in the SYM driver I got the > following: BTW I'd support the import of the sym driver in FreeBSD -CURRENT. I'd love to see this for 4.0 ! I use it on two machines and it works splendidely. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #75: Tue Nov 2 21:03:12 CET 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Nov 23 16:50:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by hub.freebsd.org (Postfix) with ESMTP id 777F41548A for ; Tue, 23 Nov 1999 16:50:41 -0800 (PST) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (cdillon@mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (8.9.3/8.9.3) with ESMTP id SAA04896; Tue, 23 Nov 1999 18:49:41 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Tue, 23 Nov 1999 18:49:40 -0600 (CST) From: Chris Dillon To: Ollivier Robert Cc: scsi@FreeBSD.ORG Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: <19991124004226.A8912@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 24 Nov 1999, Ollivier Robert wrote: > According to Gerard Roudier: > > I just got the appropriate cable this evening and started testing ultra3 > > support for the C1010. After a tiny fix in the SYM driver I got the > > following: > > BTW I'd support the import of the sym driver in FreeBSD -CURRENT. > I'd love to see this for 4.0 ! I use it on two machines and it > works splendidely. Actually, shouldn't it be possible to bring it into -STABLE as well? As long as it isn't in GENERIC by default, I can't see any harm in doing so (similar to what was done with Netgraph). I know that support for certain cards has to be turned off in the older ncr driver, but I assume that can be conditionalized to happen only when the new sym driver is compiled in. I'd really love to see this driver in -STABLE. I've been using 0.9.0 since it was released and haven't had any problems. -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures (SPARC under development). ( http://www.freebsd.org ) "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Nov 23 22:23:24 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 B084B14FE2 for ; Tue, 23 Nov 1999 22:23:20 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom (helo=localhost) by misery.sdf.com with local-esmtp (Exim 2.12 #1) id 11qUHQ-0003kE-00; Tue, 23 Nov 1999 20:43:44 -0800 Date: Tue, 23 Nov 1999 20:43:43 -0800 (PST) From: Tom To: Mark Powell Cc: freebsd-scsi@freebsd.org Subject: Re: 3.3S won't see a DPT RAID array In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 23 Nov 1999, Mark Powell wrote: > controller displays it. Booting into DOS sees the 4GB drive and the ~20GB > array. Booting FreeBSD shows the usual before starting the kernel: > > C: is disk 1 > D: is disk 2 > > However, when FBSD boots up it sees all 6 drives individually. Any ideas > why? I've not seen this before. I've another machine using exactly; same > DPT model, same revision, same firmware; and 3.3S on that machine sees > drive and array, as planned. I just can't see what's wrong. I don't want > to use vinum, when I shouldn't have to. > Cheers. Well, I suspect that you didn't choose the right host type in dptmgr. You should choose "linux". Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 24 3:36:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from metis.salford.ac.uk (metis.salford.ac.uk [146.87.232.15]) by hub.freebsd.org (Postfix) with SMTP id 3815014FC2 for ; Wed, 24 Nov 1999 03:36:38 -0800 (PST) (envelope-from M.S.Powell@salford.ac.uk) Received: (qmail 12690 invoked by alias); 24 Nov 1999 11:36:37 -0000 Received: (qmail 12684 invoked from network); 24 Nov 1999 11:36:37 -0000 Received: from plato.salford.ac.uk (146.87.255.76) by metis.salford.ac.uk with SMTP; 24 Nov 1999 11:36:37 -0000 Received: (qmail 21961 invoked by uid 141); 24 Nov 1999 11:36:37 -0000 Date: Wed, 24 Nov 1999 11:36:37 +0000 (GMT) From: Mark Powell X-Sender: mark@localhost To: Tom Cc: freebsd-scsi@freebsd.org Subject: Re: 3.3S won't see a DPT RAID array In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 23 Nov 1999, Tom wrote: > > controller displays it. Booting into DOS sees the 4GB drive and the ~20GB > > array. Booting FreeBSD shows the usual before starting the kernel: > > > > C: is disk 1 > > D: is disk 2 > > > > However, when FBSD boots up it sees all 6 drives individually. Any ideas > > why? I've not seen this before. I've another machine using exactly; same > > DPT model, same revision, same firmware; and 3.3S on that machine sees > > drive and array, as planned. I just can't see what's wrong. I don't want > > to use vinum, when I shouldn't have to. > > Cheers. > > Well, I suspect that you didn't choose the right host type in dptmgr. > You should choose "linux". Linux isn't an option. In dptmgr 1.KN, at least. SVR4.2 worked just fine though. Cheers. Mark Powell - UNIX System Administrator - Clifford Whitworth Building A.I.S., University of Salford, Salford, Manchester, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key M.S.Powell@ais.salfrd.ac.uk (spell salford correctly to reply to me) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 24 10:49: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by hub.freebsd.org (Postfix) with SMTP id EFF6515278 for ; Wed, 24 Nov 1999 10:48:57 -0800 (PST) (envelope-from maex@Space.Net) Received: (qmail 920 invoked by uid 1013); 24 Nov 1999 18:48:35 -0000 Date: Wed, 24 Nov 1999 19:48:35 +0100 From: Markus Stumpf To: scsi@FreeBSD.ORG Subject: [Q] SCSI speed and CD-ROM Message-ID: <19991124194835.F95710@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Organization: SpaceNet GmbH, Muenchen, Germany Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a machine (2.2.7) with the following hardware: Controller ahc0 rev 1 int a irq 10 on pci0:6:0 ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs Disks (ahc0:0:0): "IBM DDRS-34560W S97B" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4357MB (8925000 512 byte sectors) (ahc0:1:0): "IBM DDRS-34560W S97B" type 0 fixed SCSI 2 sd1(ahc0:1:0): Direct-Access 4357MB (8925000 512 byte sectors) CD-ROM (ahc0:4:0): "TOSHIBA CD-ROM XM-6201TA 1030" type 5 removable SCSI 2 On bootup I see a message ahc0:A:4: refuses WIDE negotiation. Using 8bit transfers A friend of mine said that the CD-ROM slows down the SCSI bus (and thus the disk I/O). Is this true a) generally b) only if the CD-ROM is active/mounted/used for I/O. If a) I would remove the CD-ROM, as I only use it 1 or 2 times a year anyway and if b) I'd keep it :-))) Thanks \Maex -- SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses Research & Development | mailto:maex-sig@Space.Net | you funny and you need Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0 | a mouse to delete files D-80807 Muenchen | Fax: +49 (89) 32356-299 | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 24 11:54: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by hub.freebsd.org (Postfix) with ESMTP id A40751539F for ; Wed, 24 Nov 1999 11:53:57 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-224-113.villette.club-internet.fr [195.36.224.113]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id UAA20120; Wed, 24 Nov 1999 20:52:59 +0100 (MET) Date: Wed, 24 Nov 1999 22:17:36 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Chris Dillon Cc: Ollivier Robert , scsi@FreeBSD.ORG Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 23 Nov 1999, Chris Dillon wrote: > On Wed, 24 Nov 1999, Ollivier Robert wrote: >=20 > > According to Gerard Roudier: > > > I just got the appropriate cable this evening and started testing ult= ra3=20 > > > support for the C1010. After a tiny fix in the SYM driver I got the > > > following: > >=20 > > BTW I'd support the import of the sym driver in FreeBSD -CURRENT. > > I'd love to see this for 4.0 ! I use it on two machines and it > > works splendidely. >=20 > Actually, shouldn't it be possible to bring it into -STABLE as well? =20 Indeed my primary goal is -STABLE, but the driver will not make problem=20 in -CURRENT if it does not in -STABLE. :-) > As long as it isn't in GENERIC by default, I can't see any harm in The kernel is also not GENERIC given that it does not support 80286 anymore. ;-) > doing so (similar to what was done with Netgraph). I know that > support for certain cards has to be turned off in the older ncr > driver, but I assume that can be conditionalized to happen only when > the new sym driver is compiled in. The SYM driver needs LOAD/STORE SCRIPTS instructions to be supported by the PCI/SCSI chip.=20 As a result, 810 rev < 0x10, 825 rev < 0x10 and 815 all revisions support is dropped. LOAD/STORE have lots of advantages (I have detailed some in the Linux README.ncr53c8xx file and I will add those explanations also for the FreeBSD driver README file) and some may be astonishing: for example, PCI-2.2 requires pci devices that access their target part as a master to read the PCI bus signals internally. Only LOAD/STORE allow to be PCI-2.2 compliant with SYMBIOS chips, MEMORY MOVEs for accessing IO registers do=20 not. > I'd really love to see this driver in -STABLE. I've been using 0.9.0 > since it was released and haven't had any problems. My goal was to propose the driver for inclusion when Ultra-3 support will be tested. It seems to work fine at the moment and I will make some heavy testings prior to announce it as available. The next point I have to solve is to make the ncr and the sym live in vertue rather than in sin. :)=20 My plan is to have driver version 1.0.0 in about 2 weeks, with a better integration in the kernel than the current one (options, etc ...) and a minimal documentation. Regards,=20 G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 24 14:53: 6 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 830F1155DA for ; Wed, 24 Nov 1999 14:52:53 -0800 (PST) (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 XAA03688; Wed, 24 Nov 1999 23:36:28 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id XAA85020; Wed, 24 Nov 1999 23:27:49 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911242227.XAA85020@yedi.iaf.nl> Subject: Re: [Q] SCSI speed and CD-ROM In-Reply-To: <19991124194835.F95710@Space.Net> from Markus Stumpf at "Nov 24, 1999 7:48:35 pm" To: maex-lists-freebsd-scsi@Space.Net (Markus Stumpf) Date: Wed, 24 Nov 1999 23:27:49 +0100 (CET) Cc: 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 Markus Stumpf wrote ... > On bootup I see a message > ahc0:A:4: refuses WIDE negotiation. Using 8bit transfers > > A friend of mine said that the CD-ROM slows down the SCSI bus (and thus > the disk I/O). > > Is this true > a) generally No. > b) only if the CD-ROM is active/mounted/used for I/O. > > If a) I would remove the CD-ROM, as I only use it 1 or 2 times a year > anyway and if b) I'd keep it :-))) SCSI negotiates the max speed between any 2 SCSI devices (normally the host adapter and a device). The speed of the bus is *not* the speed of the slowest device. If you had a slow-as-molasses device on your bus that one would take a looong time (compared to the fast devices) to do a data transfer. And it could get in the way (performance wise) of a faster device. A device sitting idle get's in nobody's way. Wilko -- | / 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 Wed Nov 24 14:53:38 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 304641550F for ; Wed, 24 Nov 1999 14:52:53 -0800 (PST) (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 XAA03685; Wed, 24 Nov 1999 23:36:25 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id XAA84898; Wed, 24 Nov 1999 23:19:13 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911242219.XAA84898@yedi.iaf.nl> Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: from Gerard Roudier at "Nov 24, 1999 10:17:36 pm" To: groudier@club-internet.fr (Gerard Roudier) Date: Wed, 24 Nov 1999 23:19:13 +0100 (CET) Cc: cdillon@wolves.k12.mo.us, roberto@keltia.freenix.fr, 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 Gerard Roudier wrote ... > > > On Tue, 23 Nov 1999, Chris Dillon wrote: > > > On Wed, 24 Nov 1999, Ollivier Robert wrote: > > > > > According to Gerard Roudier: [...] > > support for certain cards has to be turned off in the older ncr > > driver, but I assume that can be conditionalized to happen only when > > the new sym driver is compiled in. > > The SYM driver needs LOAD/STORE SCRIPTS instructions to be supported by > the PCI/SCSI chip. > As a result, 810 rev < 0x10, 825 rev < 0x10 and 815 all revisions support > is dropped. LOAD/STORE have lots of advantages (I have detailed some in Allow me to make a remark here: where does that leave people with older *mainboards with embedded NCR chips* ? Might be not too interesting for Intel folks, but most likely *is* for the Alpha folks. Mind you, I have not checked this on my Alphas (and the one Intel with embedded ncr) but I have a *bad* feeling over it as they are older stuff. The 'lets throw away the old hardware' that reigns the Intel world is less applicable to the Alpha world. A driver that cannot accomodate older hardware is a step in the wrong direction here. Just my $ 0.02 W/ -- | / 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 Wed Nov 24 18:45:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mayhem.com (mayhem.com [204.254.116.10]) by hub.freebsd.org (Postfix) with ESMTP id 2128015185; Wed, 24 Nov 1999 18:45:14 -0800 (PST) (envelope-from jacob@mayhem.com) Received: (from jacob@localhost) by mayhem.com (8.9.1/8.9.1) id VAA00378; Wed, 24 Nov 1999 21:44:02 -0500 (EST) (envelope-from jacob) From: Jacob DeGlopper Message-Id: <199911250244.VAA00378@mayhem.com> Subject: Re: SCSI/CAM errors with Yamaha CRW6416sz CD-RW and NCR 815 card In-Reply-To: From jacob at "Nov 23, 1999 4:25:22 pm" To: freebsd-scsi@freebsd.org Date: Wed, 24 Nov 1999 21:44:02 -0500 (EST) Cc: freebsd-questions@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 Followup on this problem. I have an Adaptec 2940 SCSI card on the way, which seems to be more of a standard, but maybe that's not the problem. I discovered that if there is no CD in the drive when I boot FreeBSD, it works fine. What does that indicate? cd0 at ncr0 bus 0 target 2 lun 0 cd0: Removable CD-ROM SCSI2 device cd0: 10.0MB/s transfers (10.0MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray c losed Put a CD in, and you can mount it just fine and use it. Leave the CD in when you reboot, and it locks up with the same NCR timeout errors I was seeing below. > I am running FreeBSD 3.0-RELEASE. I have recently acquired a Yamaha > CRZ6416sz SCSI CD-RW drive. I have an existing SCSI chain with a > NCR 815 card, Seagate disk, and HP DAT drive; all those have been > working fine. > > When booting the system with the new drive installed, I get some errors, > and then the system halts. Running a kernel without the SCSI cd device > configured gets the CD-ROM recognized by the pass driver without errors. > > I have double-checked the terminator, and tried other SCSI ids with no > change. The drive appears to work fine in Windows. I have also tried > adjusting the SCSI_DELAY timeout up to 20 seconds with no change. > > The specific errors I get are: > > cd0:ncr0:0:2:0: got CAM status 0x4a > fatal error, failed to attach to device (cd0:ncr0:0:2:0) removing device > entry > > then, I get the message > > ncr0: timeout nccb= (skip) > > I've also tried the drive in another FreeBSD system with an NCR 875 card, > and it failed with the same messages, as did booting with the 3.3 boot > disks. > > I haven't found anything very promising in the archives related to these > NCR timeout problems; does anyone have any ideas, or do I have to > go out and get a more expensive SCSI card? -- Jacob DeGlopper, FF/EMT-B, N3RHI jacob@mayhem.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 24 21:42:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 8000F14C36 for ; Wed, 24 Nov 1999 21:42:56 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id AAA23615; Thu, 25 Nov 1999 00:42:32 -0500 (EST) Date: Thu, 25 Nov 1999 00:42:32 -0500 (EST) From: "Matthew N. Dodd" To: Wilko Bulte Cc: scsi@FreeBSD.ORG Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: <199911242219.XAA84898@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 24 Nov 1999, Wilko Bulte wrote: > Allow me to make a remark here: where does that leave people with older > *mainboards with embedded NCR chips* ? Might be not too interesting > for Intel folks, but most likely *is* for the Alpha folks. > > Mind you, I have not checked this on my Alphas (and the one Intel > with embedded ncr) but I have a *bad* feeling over it as they are > older stuff. > > The 'lets throw away the old hardware' that reigns the Intel world is > less applicable to the Alpha world. A driver that cannot accomodate > older hardware is a step in the wrong direction here. I think thats why the conversation was about turning off support in the NCR driver for devices that the SYM supported; no support would be lost but the most efficient driver would be used for some of the newer chips. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 24 22: 0:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 37C5F14C9E; Wed, 24 Nov 1999 22:00:42 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id WAA00813; Wed, 24 Nov 1999 22:58:16 -0700 (MST) (envelope-from ken) Message-Id: <199911250558.WAA00813@panzer.kdm.org> Subject: Re: SCSI/CAM errors with Yamaha CRW6416sz CD-RW and NCR 815 card In-Reply-To: <199911250244.VAA00378@mayhem.com> from Jacob DeGlopper at "Nov 24, 1999 09:44:02 pm" To: jacob@mayhem.com (Jacob DeGlopper) Date: Wed, 24 Nov 1999 22:58:16 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG From: "Kenneth D. Merry" 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 Jacob DeGlopper wrote... > Followup on this problem. I have an Adaptec 2940 SCSI card on the way, > which seems to be more of a standard, but maybe that's not the problem. > I discovered that if there is no CD in the drive when I boot FreeBSD, > it works fine. What does that indicate? > > cd0 at ncr0 bus 0 target 2 lun 0 > cd0: Removable CD-ROM SCSI2 device > cd0: 10.0MB/s transfers (10.0MHz, offset 8) > cd0: Attempt to query device size failed: NOT READY, Medium not present - tray c > losed > > Put a CD in, and you can mount it just fine and use it. Leave the CD in > when you reboot, and it locks up with the same NCR timeout errors I > was seeing below. This sounds like it may be a drive firmware problem, although it's difficult to say for sure. How long does it take to mount the CD? How long does it take for the error messages to pop up when there isn't a CD in the drive? > > I am running FreeBSD 3.0-RELEASE. I have recently acquired a Yamaha > > CRZ6416sz SCSI CD-RW drive. I have an existing SCSI chain with a > > NCR 815 card, Seagate disk, and HP DAT drive; all those have been > > working fine. > > > > When booting the system with the new drive installed, I get some errors, > > and then the system halts. Running a kernel without the SCSI cd device > > configured gets the CD-ROM recognized by the pass driver without errors. The primary difference between the CD and pass drivers in terms of attach behavior is that the CD driver attempts to do a read capacity on the CDROM drive, but the pass driver attaches no matter what. The system shouldn't halt, though. That indicates a definite problem. > > I have double-checked the terminator, and tried other SCSI ids with no > > change. The drive appears to work fine in Windows. I have also tried > > adjusting the SCSI_DELAY timeout up to 20 seconds with no change. > > > > The specific errors I get are: > > > > cd0:ncr0:0:2:0: got CAM status 0x4a > > fatal error, failed to attach to device (cd0:ncr0:0:2:0) removing device > > entry Oooh, that's not good at all. Status 0x4a is a selection timeout. That means the drive isn't responding to attempts to contact it over the SCSI bus. > > then, I get the message > > > > ncr0: timeout nccb= (skip) I think that's just the NCR driver's generic timeout message. > > I've also tried the drive in another FreeBSD system with an NCR 875 card, > > and it failed with the same messages, as did booting with the 3.3 boot > > disks. > > > > I haven't found anything very promising in the archives related to these > > NCR timeout problems; does anyone have any ideas, or do I have to > > go out and get a more expensive SCSI card? Well, since you've already ordered a 2940, it'll be good to see what happens with that. The Adaptec driver is generally less buggy than the ncr driver. If you can, try out the 3.3 boot disk with the 2940, and see how that works as well. I think we fixed several CAM problems after 3.0 went out the door, so trying 3.3 would be a good thing. Have you tried different CDs in the drive? It could be that there is something about the CD you're using that makes the drive barf. This really sounds like a firmware issue of some sort with your CDROM drive, although I'll be more confident in saying that once you've tried the drive with an Adaptec controller. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 24 22: 8:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 5F6C714CD2 for ; Wed, 24 Nov 1999 22:08:16 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.10 #1) id 11qs3m-000Lmy-00; Wed, 24 Nov 1999 22:07:14 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Kenneth D. Merry" Cc: freebsd-scsi@freebsd.org Subject: Re: SCSI/CAM errors with Yamaha CRW6416sz CD-RW and NCR 815 card References: <199911250244.VAA00378@mayhem.com> <199911250558.WAA00813@panzer.kdm.org> Message-Id: Date: Wed, 24 Nov 1999 22:07:14 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org just to add a possibly relevant data point, i have a different yamaha cd reader/writer on an aic7890, and if a platter is not in the drive at boot, the puppy hangs. randy 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.3-STABLE #0: Mon Nov 22 22:44:32 PST 1999 root@rip.psg.com:/usr/src/sys/compile/RIP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = "GenuineIntel" Id = 0x651 Stepping = 1 Features=0x183fbff real memory = 134217728 (131072K bytes) avail memory = 127434752 (124448K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02db000. Preloaded userconfig_script "/kernel.config" at 0xc02db09c. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x02 on pci0.0.0 chip1: rev 0x02 on pci0.1.0 chip2: rev 0x02 on pci0.4.0 chip3: rev 0x02 on pci0.4.3 ahc0: rev 0x00 int a irq 19 on pci0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs fxp0: rev 0x05 int a irq 19 on pci0.9.0 fxp0: Ethernet address 00:a0:c9:df:c8:4e bktr0: rev 0x02 int a irq 18 on pci0.10.0 bti2c0: iicbb0: on bti2c0 iicbus0: on iicbb0 master-only smbus0: on bti2c0 smb0: on smbus0 bktr0: Hauppauge Model 61111 A M bktr0: Detected a MSP3430G-A1 at 0x80 Hauppauge WinCast/TV, Philips NTSC tuner, msp3400c stereo. Probing for devices on PCI bus 1: vga0: rev 0x00 int a irq 16 on pci1.0.0 Probing for PnP devices: CSN 1 Vendor ID: CTL00c3 [0xc3008c0e] Serial 0x1fd0a682 Comp ID: PNPb02f [0x2fb0d041] pcm1 (SB16pnp sn 0x1fd0a682) at 0x220-0x22f irq 5 drq 1 flags 0x15 on isa 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 psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A pcm0 not probed due to drq conflict with pcm1 at 1 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface wl0 at 0x300-0x30f irq 7 on isa wl0: address 08:00:6a:2b:dd:cb, NWID 0xaaaa APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 ccd0-5: Concatenated disk drivers Waiting 5 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! changing root device to da0s1a da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ahc0 bus 0 target 5 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 8.333MB/s transfers (8.333MHz, offset 31) cd1: cd present [140956 x 2048 byte records] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Nov 24 22:13:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 6879C14CC9 for ; Wed, 24 Nov 1999 22:13:14 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id XAA00973; Wed, 24 Nov 1999 23:12:04 -0700 (MST) (envelope-from ken) Message-Id: <199911250612.XAA00973@panzer.kdm.org> Subject: Re: SCSI/CAM errors with Yamaha CRW6416sz CD-RW and NCR 815 card In-Reply-To: from Randy Bush at "Nov 24, 1999 10:07:14 pm" To: randy@psg.com (Randy Bush) Date: Wed, 24 Nov 1999 23:12:04 -0700 (MST) Cc: freebsd-scsi@freebsd.org From: "Kenneth D. Merry" 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 Randy Bush wrote... > just to add a possibly relevant data point, i have a different yamaha cd > reader/writer on an aic7890, and if a platter is not in the drive at boot, > the puppy hangs. That sounds kinda like the HP/Philips CD-R drives that take a *long* time to respond to a read capacity if there isn't media in the drive. So do you get any error messages when the hang happens? Does it hang the whole system, or does the CDROM drive just not show up, or what? > cd1 at ahc0 bus 0 target 5 lun 0 > cd1: Removable CD-ROM SCSI-2 device > cd1: 8.333MB/s transfers (8.333MHz, offset 31) > cd1: cd present [140956 x 2048 byte records] Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 25 5: 3:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 1674814DFA for ; Thu, 25 Nov 1999 05:03:50 -0800 (PST) (envelope-from hibma@skylink.it) Received: from skylink.it (va-151.skylink.it [194.185.55.151]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id OAA12312 for ; Thu, 25 Nov 1999 14:04:16 +0100 Received: from localhost (localhost [127.0.0.1]) by skylink.it (8.9.3/8.9.3) with ESMTP id CAA00746 for ; Thu, 25 Nov 1999 02:20:09 +0100 (CET) (envelope-from hibma@skylink.it) Date: Thu, 25 Nov 1999 02:20:08 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: FreeBSD SCSI Mailing List Subject: found device. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org How do I make sure the bus is rescanned when a new target has appeared? Whenever a new device is attached, I would like the SCSI bus to which it is connected to be rescanned. The following code however doesn't do the job it seems (FYI: All USB Zip drives are connected to 1 SCSI bus, bus 0). Nick static int umass_cam_rescan(umass_softc_t *sc) { union ccb *ccb; struct cam_path *path; struct cam_periph *periph; if (xpt_create_path(&path, NULL, CAM_XPT_PATH_ID, CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) != CAM_REQ_CMP) return(ENOMEM); periph = cam_periph_find(path, NULL/*name*/); if (!periph) return(EINVAL); if (xpt_create_path(&sc->path, periph, cam_sim_path(umass_sim), device_get_unit(sc->sc_dev), CAM_LUN_WILDCARD) != CAM_REQ_CMP) return(ENOMEM); ccb = malloc(sizeof(union ccb), M_DEVBUF, M_WAITOK); xpt_setup_ccb(&ccb->ccb_h, sc->path, 5/*priority (low)*/); ccb->ccb_h.func_code = XPT_SCAN_LUN; ccb->ccb_h.cbfcnp = umass_cam_attach_callback; ccb->crcn.flags = CAM_FLAG_NONE; xpt_action(ccb); return(0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 25 7:13:53 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 65F0614D4D for ; Thu, 25 Nov 1999 07:13:50 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id IAA99696; Thu, 25 Nov 1999 08:03:37 -0700 (MST) Date: Thu, 25 Nov 1999 08:03:37 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199911251503.IAA99696@narnia.plutotech.com> To: Nick Hibma Cc: scsi@FreeBSD.org Subject: Re: found device. X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > How do I make sure the bus is rescanned when a new target has appeared? > > Whenever a new device is attached, I would like the SCSI bus to which it > is connected to be rescanned. The following code however doesn't do the > job it seems (FYI: All USB Zip drives are connected to 1 SCSI bus, bus > 0). > > Nick > > > static int > umass_cam_rescan(umass_softc_t *sc) > { > union ccb *ccb; > struct cam_path *path; > struct cam_periph *periph; > > if (xpt_create_path(&path, NULL, CAM_XPT_PATH_ID, > CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) > != CAM_REQ_CMP) > return(ENOMEM); > > periph = cam_periph_find(path, NULL/*name*/); > if (!periph) > return(EINVAL); The only time you will ever find a peripheral on the wildcard node is if you are using the target mode black hole device. You probably want to use 0 and 0 for the target and lun respectively. (cam_periph_find looks for exact matches, and will not exand wildcards). > if (xpt_create_path(&sc->path, periph, cam_sim_path(umass_sim), > device_get_unit(sc->sc_dev), CAM_LUN_WILDCARD) > != CAM_REQ_CMP) > return(ENOMEM); > > ccb = malloc(sizeof(union ccb), M_DEVBUF, M_WAITOK); > xpt_setup_ccb(&ccb->ccb_h, sc->path, 5/*priority (low)*/); > ccb->ccb_h.func_code = XPT_SCAN_LUN; > ccb->ccb_h.cbfcnp = umass_cam_attach_callback; > ccb->crcn.flags = CAM_FLAG_NONE; > xpt_action(ccb); > > return(0); > } If you simply want to rescan the bus, try XPT_SCAN_BUS. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 25 7:27:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id ABA1014E60 for ; Thu, 25 Nov 1999 07:27:43 -0800 (PST) (envelope-from hibma@skylink.it) Received: from skylink.it (va-151.skylink.it [194.185.55.151]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id QAA17637 for ; Thu, 25 Nov 1999 16:28:08 +0100 Received: from localhost (localhost [127.0.0.1]) by skylink.it (8.9.3/8.9.3) with ESMTP id PAA01676 for ; Thu, 25 Nov 1999 15:53:31 +0100 (CET) (envelope-from hibma@skylink.it) Date: Thu, 25 Nov 1999 15:53:31 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: FreeBSD SCSI Mailing List Subject: AC_LOST_DEVICE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If I want to indicate an added device, should I specify the path of the the path of the new device (sc->path) or of the controller it is attached to (umass_path)? xpt_async(AC_LOST_DEVICE, sc->path, NULL); Nick -- hibma@skylink.it n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 25 7:27:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 021B414E68 for ; Thu, 25 Nov 1999 07:27:45 -0800 (PST) (envelope-from hibma@skylink.it) Received: from skylink.it (va-151.skylink.it [194.185.55.151]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id QAA17646 for ; Thu, 25 Nov 1999 16:28:11 +0100 Received: from localhost (localhost [127.0.0.1]) by skylink.it (8.9.3/8.9.3) with ESMTP id PAA01663 for ; Thu, 25 Nov 1999 15:38:13 +0100 (CET) (envelope-from hibma@skylink.it) Date: Thu, 25 Nov 1999 15:38:13 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: FreeBSD SCSI Mailing List Subject: Re: found device. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org For your information: The following code fails as well: union ccb *ccb = NULL; struct ccb_getdev *cgd = (struct ccb_getdev *)ccb; ccb = malloc(sizeof(union ccb), M_USBDEV, M_WAITOK); memset(ccb, 0, sizeof(union ccb)); cgd->ccb_h.func_code = XPT_GDEV_TYPE; if (xpt_create_path(&sc->path, NULL, cam_sim_path(umass_sim), device_get_unit(sc->sc_dev), CAM_LUN_WILDCARD) != CAM_REQ_CMP) return(ENOMEM); xpt_async(AC_FOUND_DEVICE, sc->path, cgd); free(ccb, M_USBDEV); This code bombs passasync() (the code fragment below just silently fails). Cheers, Nick > How do I make sure the bus is rescanned when a new target has appeared? > > Whenever a new device is attached, I would like the SCSI bus to which it > is connected to be rescanned. The following code however doesn't do the > job it seems (FYI: All USB Zip drives are connected to 1 SCSI bus, bus > 0). > > Nick > > > static int > umass_cam_rescan(umass_softc_t *sc) > { > union ccb *ccb; > struct cam_path *path; > struct cam_periph *periph; > > if (xpt_create_path(&path, NULL, CAM_XPT_PATH_ID, > CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) > != CAM_REQ_CMP) > return(ENOMEM); > > periph = cam_periph_find(path, NULL/*name*/); > if (!periph) > return(EINVAL); > > if (xpt_create_path(&sc->path, periph, cam_sim_path(umass_sim), > device_get_unit(sc->sc_dev), CAM_LUN_WILDCARD) > != CAM_REQ_CMP) > return(ENOMEM); > > ccb = malloc(sizeof(union ccb), M_DEVBUF, M_WAITOK); > xpt_setup_ccb(&ccb->ccb_h, sc->path, 5/*priority (low)*/); > ccb->ccb_h.func_code = XPT_SCAN_LUN; > ccb->ccb_h.cbfcnp = umass_cam_attach_callback; > ccb->crcn.flags = CAM_FLAG_NONE; > xpt_action(ccb); > > return(0); > } > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > -- hibma@skylink.it n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 25 11:26:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by hub.freebsd.org (Postfix) with ESMTP id 333C814C97 for ; Thu, 25 Nov 1999 11:26:11 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-115-161.villette.club-internet.fr [194.158.115.161]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id UAA16498; Thu, 25 Nov 1999 20:25:55 +0100 (MET) Date: Thu, 25 Nov 1999 21:50:37 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Wilko Bulte Cc: cdillon@wolves.k12.mo.us, roberto@keltia.freenix.fr, scsi@FreeBSD.ORG Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: <199911242219.XAA84898@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 24 Nov 1999, Wilko Bulte wrote: > As Gerard Roudier wrote ... > >=20 > >=20 > > On Tue, 23 Nov 1999, Chris Dillon wrote: > >=20 > > > On Wed, 24 Nov 1999, Ollivier Robert wrote: > > >=20 > > > > According to Gerard Roudier: >=20 > [...] >=20 > > > support for certain cards has to be turned off in the older ncr > > > driver, but I assume that can be conditionalized to happen only when > > > the new sym driver is compiled in. > >=20 > > The SYM driver needs LOAD/STORE SCRIPTS instructions to be supported by > > the PCI/SCSI chip.=20 > > As a result, 810 rev < 0x10, 825 rev < 0x10 and 815 all revisions suppo= rt > > is dropped. LOAD/STORE have lots of advantages (I have detailed some in >=20 > Allow me to make a remark here: where does that leave people with older > *mainboards with embedded NCR chips* ? Might be not too interesting=20 > for Intel folks, but most likely *is* for the Alpha folks. >=20 > Mind you, I have not checked this on my Alphas (and the one Intel > with embedded ncr) but I have a *bad* feeling over it as they are > older stuff. >=20 > The 'lets throw away the old hardware' that reigns the Intel world is > less applicable to the Alpha world. A driver that cannot accomodate > older hardware is a step in the wrong direction here.=20 >=20 > Just my $ 0.02 You just lost your money. There is no problem using the both drivers on either Linux or FreeBSD. On Linux, user can enter boot commands options in order to assign any cards to the driver it desires, providing the desired driver supports the board. This is not so easy under FreeBSD now, but I do use the both drivers at the same time on my box. The right direction is, in my opinion, to have drivers that allows users to get IN TIME functionnalities and performances they pay for. By the way, this not only requires development but also maintainance.=20 I have decided to have 2 drivers for the SYM53C8XX family and, as you should have known, nobody else seemed to have decided to do differently for _actually_ providing users features users pay for and not having to deal for a long time with to complex driver code. By the way, SYMBIOS did the same, independantly. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 25 11:37:29 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 29D7414D5D for ; Thu, 25 Nov 1999 11:37:25 -0800 (PST) (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 UAA32181; Thu, 25 Nov 1999 20:25:47 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id TAA00842; Thu, 25 Nov 1999 19:48:51 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911251848.TAA00842@yedi.iaf.nl> Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: from "Matthew N. Dodd" at "Nov 25, 1999 0:42:32 am" To: winter@jurai.net (Matthew N. Dodd) Date: Thu, 25 Nov 1999 19:48:51 +0100 (CET) Cc: 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 Matthew N. Dodd wrote ... > On Wed, 24 Nov 1999, Wilko Bulte wrote: > > Allow me to make a remark here: where does that leave people with older > > *mainboards with embedded NCR chips* ? Might be not too interesting > > for Intel folks, but most likely *is* for the Alpha folks. > > > > Mind you, I have not checked this on my Alphas (and the one Intel > > with embedded ncr) but I have a *bad* feeling over it as they are > > older stuff. > > > > The 'lets throw away the old hardware' that reigns the Intel world is > > less applicable to the Alpha world. A driver that cannot accomodate > > older hardware is a step in the wrong direction here. > > I think thats why the conversation was about turning off support in the > NCR driver for devices that the SYM supported; no support would be lost > but the most efficient driver would be used for some of the newer chips. Hmm. Playing the daemons advocate once again: IIRC one of the most pressing reasons for the new sym driver is that the ncr driver is not really actively maintained and only understood by the happy(?) few. If sym goes mainstream ncr will quickly grow stale I'm afraid. And stale stuff get's axed pretty quickly (there are ample precedents). Isn't there a way to have sym understand both old and new chips, with the new chips result in a full featured driver, whereas at the same time the older chip revs run in 'compatibility mode'. Or does this introduce too much bloat? Don't misunderstand: I think getting a better NCR driver is an excellent development! Wilko -- | / 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 Thu Nov 25 11:37:58 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 6CA8B14DEF; Thu, 25 Nov 1999 11:37:52 -0800 (PST) (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 UAA32174; Thu, 25 Nov 1999 20:25:40 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id UAA01014; Thu, 25 Nov 1999 20:00:46 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911251900.UAA01014@yedi.iaf.nl> Subject: Re: strange panic on Alpha, SCSI disk *type* related In-Reply-To: from Matthew Jacob at "Nov 21, 1999 9:53:42 am" To: mjacob@feral.com Date: Thu, 25 Nov 1999 20:00:46 +0100 (CET) Cc: gallatin@cs.duke.edu, freebsd-scsi@FreeBSD.ORG, freebsd-alpha@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 Matthew Jacob wrote ... Hi Matt, Ever since the firmware is back in the driver the machine just works like a charm. Are you still interested in digging into my ancient isp f/w ;-) ? I'm happy with things the way they are. Wilko > Ah! Well, what you can also do is set the ISP_CFG_NONVRAM config option > or do > > isp_no_nvram=1 # (1 << unit) > > in your loader defaults file (or at the loader prompt) and it won't > 'believe' the NVRAM settings. It still might try and do Ultra though- > that's a property of chip type, clock rate and (heh heh) a bit set in the > Qlogic microengine's processor status register. > > I still would like more details (maybe in the mail to follow), but I > probably can't look too closely at this until after December 1. -- | / 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 Thu Nov 25 11:52:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 1D71214DB8 for ; Thu, 25 Nov 1999 11:52:33 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id MAA99902; Thu, 25 Nov 1999 12:42:21 -0700 (MST) Date: Thu, 25 Nov 1999 12:42:21 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199911251942.MAA99902@narnia.plutotech.com> To: Nick Hibma Cc: scsi@FreeBSD.org Subject: Re: found device. X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > For your information: The following code fails as well: > > union ccb *ccb = NULL; > struct ccb_getdev *cgd = (struct ccb_getdev *)ccb; > > ccb = malloc(sizeof(union ccb), M_USBDEV, M_WAITOK); > memset(ccb, 0, sizeof(union ccb)); > cgd->ccb_h.func_code = XPT_GDEV_TYPE; When was cgd initialized to anything other than NULL? There is also no need to cast the ccb, just use &ccb->cgd; > if (xpt_create_path(&sc->path, NULL, cam_sim_path(umass_sim), > device_get_unit(sc->sc_dev), CAM_LUN_WILDCARD) > != CAM_REQ_CMP) > return(ENOMEM); > > xpt_async(AC_FOUND_DEVICE, sc->path, cgd); > free(ccb, M_USBDEV); > > This code bombs passasync() (the code fragment below just silently > fails). And no wonder. The cgd is not fully initialized. It needs to have inquiry information that I'm sure several async handlers require. AC_FOUND_DEVICE should only be issued by the XPT. I suppose I should add some mechanism to catch rogue code that attempts to send one. Take the path of your SIM and issue an XPT_SCAN_BUS request. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 25 11:53:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 41F9C14DB8 for ; Thu, 25 Nov 1999 11:53:51 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id MAA99910; Thu, 25 Nov 1999 12:43:37 -0700 (MST) Date: Thu, 25 Nov 1999 12:43:37 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199911251943.MAA99910@narnia.plutotech.com> To: Nick Hibma Cc: scsi@FreeBSD.org Subject: Re: AC_LOST_DEVICE X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > If I want to indicate an added device, should I specify the path of the > the path of the new device (sc->path) or of the controller it is > attached to (umass_path)? > > xpt_async(AC_LOST_DEVICE, sc->path, NULL); AC_LOST_DEVICE indicates that a device has gone away, not been found. In general, your path should be as specific as possible, so use the fully qualified address of the device that has arrived. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 25 12:28:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front1m.grolier.fr (front1m.grolier.fr [195.36.216.51]) by hub.freebsd.org (Postfix) with ESMTP id 6DCA114A1B for ; Thu, 25 Nov 1999 12:28:22 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-106-115.villette.club-internet.fr [194.158.106.115]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA09835; Thu, 25 Nov 1999 21:28:10 +0100 (MET) Date: Thu, 25 Nov 1999 22:52:52 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Wilko Bulte Cc: "Matthew N. Dodd" , scsi@FreeBSD.ORG Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: <199911251848.TAA00842@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 25 Nov 1999, Wilko Bulte wrote: > As Matthew N. Dodd wrote ... > > On Wed, 24 Nov 1999, Wilko Bulte wrote: > > > Allow me to make a remark here: where does that leave people with old= er > > > *mainboards with embedded NCR chips* ? Might be not too interesting= =20 > > > for Intel folks, but most likely *is* for the Alpha folks. > > >=20 > > > Mind you, I have not checked this on my Alphas (and the one Intel > > > with embedded ncr) but I have a *bad* feeling over it as they are > > > older stuff. > > >=20 > > > The 'lets throw away the old hardware' that reigns the Intel world is > > > less applicable to the Alpha world. A driver that cannot accomodate > > > older hardware is a step in the wrong direction here.=20 > >=20 > > I think thats why the conversation was about turning off support in the > > NCR driver for devices that the SYM supported; no support would be lost > > but the most efficient driver would be used for some of the newer chips= =2E >=20 > Hmm. Playing the daemons advocate once again: IIRC one of the most > pressing reasons for the new sym driver is that the ncr driver is not > really actively maintained and only understood by the happy(?) few. If > sym goes mainstream ncr will quickly grow stale I'm afraid. And stale > stuff get's axed pretty quickly (there are ample precedents). >=20 > Isn't there a way to have sym understand both old and new chips, with the > new chips result in a full featured driver, whereas at the same time > the older chip revs run in 'compatibility mode'. Or does this introduce > too much bloat?=20 There is no way from me for either developing or maintaining the driver you seem to want to have and I will _never_ use such a driver since I know of either the complexity=3Dless reliability or the lacking of feature support such a driver would suffer of. If such a driver ever comes from another source, this will not be a problem for me at all, as you can guess. > Don't misunderstand: I think getting a better NCR driver is an excellent > development! I do misunderstood all of your postings, and btw, if the ncr driver would have appeared to me way broken or too much under-featured I would have proposed fixes for that. This did happen for the CTEST0 fix, and some years ago I did propose the ULTRA/ULTRA2 support for the ncr.=20 NCR has sold its micro-electronic department since about 7 years IIRC.=20 Advertising NCR when talking about the SYM53C8XX family does not make sense since years. SYMBIOS ingenieers have done a _great_ job in the enhancement of the 53C8XX family and AFAIK the SYMBIOS brand name still exists (you may have a look at LSILOGIC site).=20 FYI, I have plans for some minimal cleanups, fixes, and enhancements of the ncr driver. This work is only deferred after SYM-0.1.0.=20 G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 25 13: 5:54 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 38AD914CB1 for ; Thu, 25 Nov 1999 13:05:43 -0800 (PST) (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 VAA02298; Thu, 25 Nov 1999 21:29:50 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id VAA02381; Thu, 25 Nov 1999 21:40:01 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911252040.VAA02381@yedi.iaf.nl> Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: from Gerard Roudier at "Nov 25, 1999 9:50:37 pm" To: groudier@club-internet.fr (Gerard Roudier) Date: Thu, 25 Nov 1999 21:40:01 +0100 (CET) Cc: cdillon@wolves.k12.mo.us, roberto@keltia.freenix.fr, 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 Gerard Roudier wrote ... > On Wed, 24 Nov 1999, Wilko Bulte wrote: > > > As Gerard Roudier wrote ... > > > > > > > > > On Tue, 23 Nov 1999, Chris Dillon wrote: > > > > > > > On Wed, 24 Nov 1999, Ollivier Robert wrote: > > > > > > > > > According to Gerard Roudier: > > > > [...] > > > The SYM driver needs LOAD/STORE SCRIPTS instructions to be supported by > > > the PCI/SCSI chip. > > > As a result, 810 rev < 0x10, 825 rev < 0x10 and 815 all revisions support > > > is dropped. LOAD/STORE have lots of advantages (I have detailed some in > > > > Allow me to make a remark here: where does that leave people with older > > *mainboards with embedded NCR chips* ? Might be not too interesting > > for Intel folks, but most likely *is* for the Alpha folks. > > > > Mind you, I have not checked this on my Alphas (and the one Intel > > with embedded ncr) but I have a *bad* feeling over it as they are > > older stuff. > > > > The 'lets throw away the old hardware' that reigns the Intel world is > > less applicable to the Alpha world. A driver that cannot accomodate > > older hardware is a step in the wrong direction here. > > > > Just my $ 0.02 > > You just lost your money. There is no problem using the both drivers on I can afford $0.02 ;-) I was just worried about the maintenance on the ncr driver as it is only used on old hardware. But read on.. > The right direction is, in my opinion, to have drivers that allows users > to get IN TIME functionnalities and performances they pay for. By the way, > this not only requires development but also maintainance. > > I have decided to have 2 drivers for the SYM53C8XX family and, as you > should have known, nobody else seemed to have decided to do differently > for _actually_ providing users features users pay for and not having to > deal for a long time with to complex driver code. By the way, SYMBIOS did > the same, independantly. I'm not sure I understand completely what you are saying. I agree that one wants to have drivers that take full advantage of the features the hardware has to offer. So a nice new clean driver is a good thing. But from pulling the sym tarball over onto one of my Alpha's and reading the README (I know, should have done that earlier, but I was too busy with other stuff.. :-( ) I understand that you make the 'ncr' driver take the older chips and have the sym take the new ones. Being curious I put the sym into -current on the Alpha box and got: EB64+ Alpha 21064A Evaluation Board 274 MHz, 274MHz 8192 byte page size, 1 processor. CPU: EV45 (21064A) major=6 minor=2 OSF PAL rev: 0x100070002012d real memory = 132136960 (129040K bytes) avail memory = 122773504 (119896K bytes) Preloaded elf kernel "kernel" at 0xfffffc00005e6000. pci0: on pcib0 sym0: <810a> irq 7 at device 5.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, parity checking CACHE TEST FAILED: script execution failed. start=47c625c8, pc=47c625d4, end=47c625e8 sym0: CACHE INCORRECTLY CONFIGURED. device_probe_and_attach: sym0 attach returned 6 isp0: irq 1 at device 7.0 on pci0 isp0: interrupting at APECS irq 1 So, I do have an ncr810a chip after all embedded on this Alpha mainboard. My other PCI Alpha is on loan to another FreeBSD developer (of sigset fame ;-) so I can't check that one. After spending some time digging in my equipment stock I found a original NCR-built PCI card. Installing that gives me: sym1: <810a> irq 1 at device 7.0 on pci0 sym1: No NVRAM, ID 7, Fast-10, parity checking CACHE TEST FAILED: script execution failed. start=47c625c8, pc=47c625d4, end=47c625e8 sym1: CACHE INCORRECTLY CONFIGURED. device_probe_and_attach: sym1 attach returned 6 In both cases there are no devices connect to the SCSI buses that the sym driver controls. Cheers, Wilko -- | / 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 Thu Nov 25 13:22:48 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 858DC14EC9 for ; Thu, 25 Nov 1999 13:22:42 -0800 (PST) (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 WAA03873; Thu, 25 Nov 1999 22:06:01 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id VAA02714; Thu, 25 Nov 1999 21:59:12 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911252059.VAA02714@yedi.iaf.nl> Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: from Gerard Roudier at "Nov 25, 1999 10:52:52 pm" To: groudier@club-internet.fr (Gerard Roudier) Date: Thu, 25 Nov 1999 21:59:12 +0100 (CET) Cc: winter@jurai.net, 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 Gerard Roudier wrote ... > > Isn't there a way to have sym understand both old and new chips, with the > > new chips result in a full featured driver, whereas at the same time > > the older chip revs run in 'compatibility mode'. Or does this introduce > > too much bloat? > > There is no way from me for either developing or maintaining the driver > you seem to want to have and I will _never_ use such a driver since I > know of either the complexity=less reliability or the lacking of feature > support such a driver would suffer of. OK, that is clear. > If such a driver ever comes from another source, this will not be a > problem for me at all, as you can guess. > > Don't misunderstand: I think getting a better NCR driver is an excellent > > development! > > I do misunderstood all of your postings, and btw, if the ncr driver would Please!! I am not attacking anyone, especially not you. > have appeared to me way broken or too much under-featured I would have It is my impression, but I could be wrong (read the freebsd-scsi archives) that the complexity and/or difficulty of the ncr driver was spurring the development of a successor (sym). > NCR has sold its micro-electronic department since about 7 years IIRC. > Advertising NCR when talking about the SYM53C8XX family does not make > sense since years. SYMBIOS ingenieers have done a _great_ job in the > enhancement of the 53C8XX family and AFAIK the SYMBIOS brand name still > exists (you may have a look at LSILOGIC site). I know. And we almost lost Symbios to Adaptec too. Fortunately that did not happen. Wilko -- | / 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 Thu Nov 25 14:24:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by hub.freebsd.org (Postfix) with ESMTP id 9086C14F79 for ; Thu, 25 Nov 1999 14:24:33 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-170-204.villette.club-internet.fr [195.36.170.204]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id XAA08407; Thu, 25 Nov 1999 23:24:24 +0100 (MET) Date: Fri, 26 Nov 1999 00:49:05 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Wilko Bulte Cc: winter@jurai.net, scsi@FreeBSD.ORG Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: <199911252059.VAA02714@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 25 Nov 1999, Wilko Bulte wrote: > As Gerard Roudier wrote ... >=20 > > > Don't misunderstand: I think getting a better NCR driver is an excell= ent > > > development! > >=20 > > I do misunderstood all of your postings, and btw, if the ncr driver wou= ld >=20 > Please!! I am not attacking anyone, especially not you. I didn't feel attacked. :) I felt mostly the ncr driver maintainance criticized and I cannot accept that for obvious reasons even if I wasn't the official maintainer. I felt that indirectly STefan was attacked and I cannot accept that given that I know how hard it is to maintain and support (mainly user questions and reports) such drivers for an O/S and that I have been fortunate to have found time for that. Without LSILOGIC helping Linux driver development and user support, it would have been hard for me to port the sym driver to FreeBSD. And I was nervous about this 'still another person that wanted a single driver for all the SYM53C[8/10/15]XX family' thread, since it is obvious that this is not the first time that such a thread occurs. I have had strong reasons to take decision of having 2 drivers per O/S and the only way to convince me I have been wrong can only be _real_ code. Anything different can only be wasting time for me, since I cannot ignore such=20 topic. BTW, I need both the Linux ncr53c8xx driver and FreeBSD ncr driver to work for me since I still use a pair of SCSI-2 devices (IBMS12 and Atlas I) connected to a 825 controller and a old DEC SCSI-2 disk connected to a 810 controller. This let me quite aware that the ncr* drivers are still to be maintained in a reasonnable working state.=20 If someone wanted to kill any ncr* driver, it wasn't me at all. Neither=20 I desired to suggest people to criticize any ancient driver that has been= =20 the greatest driver code I found in 1995 (my opinion still unchanged nowadays). =20 > > have appeared to me way broken or too much under-featured I would have >=20 > It is my impression, but I could be wrong (read the freebsd-scsi archives= ) > that the complexity and/or difficulty of the ncr driver was spurring the > development of a successor (sym). Reading archives is generally boring. ;-) The ncr driver has had 3 successors and all of these 4 drivers (2 per OS) are still alive nowadays and there is no reasons to kill or drop any of them for the moment, in my opinion. > > NCR has sold its micro-electronic department since about 7 years IIRC.= =20 > > Advertising NCR when talking about the SYM53C8XX family does not make > > sense since years. SYMBIOS ingenieers have done a _great_ job in the > > enhancement of the 53C8XX family and AFAIK the SYMBIOS brand name still > > exists (you may have a look at LSILOGIC site).=20 >=20 > I know. And we almost lost Symbios to Adaptec too. Fortunately that did n= ot > happen. I fully agree on this point. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 25 14:58:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51]) by hub.freebsd.org (Postfix) with ESMTP id 8D42414D21 for ; Thu, 25 Nov 1999 14:58:25 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-162-184.villette.club-internet.fr [195.36.162.184]) by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id XAA06280; Thu, 25 Nov 1999 23:58:03 +0100 (MET) Date: Fri, 26 Nov 1999 01:22:44 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Wilko Bulte Cc: cdillon@wolves.k12.mo.us, roberto@keltia.freenix.fr, scsi@FreeBSD.ORG Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: <199911252040.VAA02381@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 25 Nov 1999, Wilko Bulte wrote: [ ... ] > Being curious I put the sym into -current on the Alpha box and got: >=20 > EB64+ > Alpha 21064A Evaluation Board 274 MHz, 274MHz [ ... ] > sym0: <810a> irq 7 at device 5.0 on pci0 > sym0: No NVRAM, ID 7, Fast-10, parity checking > CACHE TEST FAILED: script execution failed. > start=3D47c625c8, pc=3D47c625d4, end=3D47c625e8 > sym0: CACHE INCORRECTLY CONFIGURED. SYM-0.9.0 was not checked for Alpha and in fact could only fail with Alpha (The source said 'only i386 supported') :-) SYM-0.10.0 should work on paper for Alpha but needed some trivial=20 changes in order to work for some Alpha. SYM-0.11.0 should be ok for Alpha The sym driver performs MMIOs with a mb() after each access, as it seemed to be the default for the ncr driver. In my opinion, using normal IOs =20 should be more safe for Alpha. If you still want to give the sym driver=20 (0.11.0) a try, you should uncomment the following define in sym_conf.h. /* * Use Normal IO instead of MMIO. */ /* #define SYMCONF_IOMAPPED */ G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 25 15:12:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by hub.freebsd.org (Postfix) with ESMTP id 7E62D14D21 for ; Thu, 25 Nov 1999 15:12:43 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-224-246.villette.club-internet.fr [195.36.224.246]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id AAA27340; Fri, 26 Nov 1999 00:12:26 +0100 (MET) Date: Fri, 26 Nov 1999 01:35:45 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Wilko Bulte Cc: cdillon@wolves.k12.mo.us, roberto@keltia.freenix.fr, scsi@FreeBSD.ORG Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: <199911252040.VAA02381@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I may have misunderstood your report in my previous reply. If you mean that the sym driver detected a 810A that is in fact=20 a normal 810, then I fully understand the driver failure. Will try to understand the cause of the problem to-morrow evening. Thanks for the report. G=E9rard. On Thu, 25 Nov 1999, Wilko Bulte wrote: > Being curious I put the sym into -current on the Alpha box and got: >=20 > EB64+ > Alpha 21064A Evaluation Board 274 MHz, 274MHz > 8192 byte page size, 1 processor. > CPU: EV45 (21064A) major=3D6 minor=3D2 > OSF PAL rev: 0x100070002012d > real memory =3D 132136960 (129040K bytes) > avail memory =3D 122773504 (119896K bytes) > Preloaded elf kernel "kernel" at 0xfffffc00005e6000. > pci0: on pcib0 > sym0: <810a> irq 7 at device 5.0 on pci0 > sym0: No NVRAM, ID 7, Fast-10, parity checking > CACHE TEST FAILED: script execution failed. > start=3D47c625c8, pc=3D47c625d4, end=3D47c625e8 > sym0: CACHE INCORRECTLY CONFIGURED. > device_probe_and_attach: sym0 attach returned 6 > isp0: irq 1 at device 7.0 on pci0 > isp0: interrupting at APECS irq 1 >=20 > So, I do have an ncr810a chip after all embedded on this Alpha mainboard.= =20 > My other PCI Alpha is on loan to another FreeBSD developer=20 > (of sigset fame ;-) so I can't check that one.=20 >=20 > After spending some time digging in my equipment stock I found a=20 > original NCR-built PCI card. Installing that gives me: >=20 > sym1: <810a> irq 1 at device 7.0 on pci0 > sym1: No NVRAM, ID 7, Fast-10, parity checking > CACHE TEST FAILED: script execution failed. > start=3D47c625c8, pc=3D47c625d4, end=3D47c625e8 > sym1: CACHE INCORRECTLY CONFIGURED. > device_probe_and_attach: sym1 attach returned 6 >=20 > In both cases there are no devices connect to the SCSI buses that the > sym driver controls. >=20 > Cheers, >=20 > Wilko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Nov 25 15:18:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front1m.grolier.fr (front1m.grolier.fr [195.36.216.51]) by hub.freebsd.org (Postfix) with ESMTP id D59C914D21 for ; Thu, 25 Nov 1999 15:18:26 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-224-246.villette.club-internet.fr [195.36.224.246]) by front1m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id AAA02572; Fri, 26 Nov 1999 00:18:22 +0100 (MET) Date: Fri, 26 Nov 1999 01:43:03 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Wilko Bulte Cc: scsi@FreeBSD.ORG Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry for the stupid trivial bug. The below untested change should help=20 for the driver to ignore the 810. --- sym_hipd.c.991126=09Fri Nov 26 01:37:51 1999 +++ sym_hipd.c=09Fri Nov 26 01:40:35 1999 @@ -9515,6 +9515,9 @@ #endif /* FreeBSD_4_Bus */ =20 static struct sym_pci_chip sym_pci_dev_table[] =3D { + {PCI_ID_SYM53C810, 0x01, "810", 4, 8, 4, + 0} + , {PCI_ID_SYM53C810, 0xff, "810a", 4, 8, 4, FE_CACHE_SET|FE_LDSTR|FE_PFEN|FE_BOF} , G=E9rard. On Fri, 26 Nov 1999, Gerard Roudier wrote: =20 > Hello, >=20 > I may have misunderstood your report in my previous reply. > If you mean that the sym driver detected a 810A that is in fact=20 > a normal 810, then I fully understand the driver failure. > Will try to understand the cause of the problem to-morrow evening. >=20 > Thanks for the report. >=20 > G=E9rard. >=20 > On Thu, 25 Nov 1999, Wilko Bulte wrote: >=20 > > Being curious I put the sym into -current on the Alpha box and got: > >=20 > > EB64+ > > Alpha 21064A Evaluation Board 274 MHz, 274MHz > > 8192 byte page size, 1 processor. > > CPU: EV45 (21064A) major=3D6 minor=3D2 > > OSF PAL rev: 0x100070002012d > > real memory =3D 132136960 (129040K bytes) > > avail memory =3D 122773504 (119896K bytes) > > Preloaded elf kernel "kernel" at 0xfffffc00005e6000. > > pci0: on pcib0 > > sym0: <810a> irq 7 at device 5.0 on pci0 > > sym0: No NVRAM, ID 7, Fast-10, parity checking > > CACHE TEST FAILED: script execution failed. > > start=3D47c625c8, pc=3D47c625d4, end=3D47c625e8 > > sym0: CACHE INCORRECTLY CONFIGURED. > > device_probe_and_attach: sym0 attach returned 6 > > isp0: irq 1 at device 7.0 on pc= i0 > > isp0: interrupting at APECS irq 1 > >=20 > > So, I do have an ncr810a chip after all embedded on this Alpha mainboar= d.=20 > > My other PCI Alpha is on loan to another FreeBSD developer=20 > > (of sigset fame ;-) so I can't check that one.=20 > >=20 > > After spending some time digging in my equipment stock I found a=20 > > original NCR-built PCI card. Installing that gives me: > >=20 > > sym1: <810a> irq 1 at device 7.0 on pci0 > > sym1: No NVRAM, ID 7, Fast-10, parity checking > > CACHE TEST FAILED: script execution failed. > > start=3D47c625c8, pc=3D47c625d4, end=3D47c625e8 > > sym1: CACHE INCORRECTLY CONFIGURED. > > device_probe_and_attach: sym1 attach returned 6 > >=20 > > In both cases there are no devices connect to the SCSI buses that the > > sym driver controls. > >=20 > > Cheers, > >=20 > > Wilko >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 26 0:30: 0 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 494DA14F92 for ; Fri, 26 Nov 1999 00:29:55 -0800 (PST) (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 IAA27799; Fri, 26 Nov 1999 08:47:52 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id AAA44174; Fri, 26 Nov 1999 00:10:15 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911252310.AAA44174@yedi.iaf.nl> Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: from Gerard Roudier at "Nov 26, 1999 0:49: 5 am" To: groudier@club-internet.fr (Gerard Roudier) Date: Fri, 26 Nov 1999 00:10:15 +0100 (CET) Cc: winter@jurai.net, 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 Gerard Roudier wrote ... > On Thu, 25 Nov 1999, Wilko Bulte wrote: > > As Gerard Roudier wrote ... > > > > > > Don't misunderstand: I think getting a better NCR driver is an excellent > > > > development! > > > > > > I do misunderstood all of your postings, and btw, if the ncr driver would > > > > Please!! I am not attacking anyone, especially not you. > > I didn't feel attacked. :) OK, let's consider that one settled ;-) > I felt mostly the ncr driver maintainance criticized and I cannot accept > that for obvious reasons even if I wasn't the official maintainer. I felt > that indirectly STefan was attacked and I cannot accept that given that I Wrong impression, at least as far as I'm concerned. I've met STefan in person and he has helped me a number of times via private email when I had questions around (for example) the ncr driver messages. Always had a good relationship with STefan. > And I was nervous about this 'still another person that wanted a single > driver for all the SYM53C[8/10/15]XX family' thread, since it is obvious It was just a person nervous about his Alpha's potentially starving for disks ;-) ;-) Lack of information on my part obviously. > I desired to suggest people to criticize any ancient driver that has been > the greatest driver code I found in 1995 (my opinion still unchanged > nowadays). I've used ncr/symbios cards ever since I got my first PCI-capable mainboard. Has worked just fine for me. I never understood why (for home systems that is, as opposed to big server stuff) people spend lots of $$ on Adaptecs. I only got anything else than ncr/symbios cards when I could get Qlogic and Adaptec cards for a few $ a piece. Wilko -- | / 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 Fri Nov 26 1:23:11 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 6D8C414FAD for ; Fri, 26 Nov 1999 01:23:07 -0800 (PST) (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 KAA31645; Fri, 26 Nov 1999 10:00:03 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id KAA49959; Fri, 26 Nov 1999 10:09:54 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911260909.KAA49959@yedi.iaf.nl> Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: from Gerard Roudier at "Nov 26, 1999 1:43: 3 am" To: groudier@club-internet.fr (Gerard Roudier) Date: Fri, 26 Nov 1999 10:09:54 +0100 (CET) Cc: 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 Gerard Roudier wrote ... Hi Gerard, After patching the table now looks like: static struct sym_pci_chip sym_pci_dev_table[] = { {PCI_ID_SYM53C810, 0x01, "810", 4, 8, 4, 0} , {PCI_ID_SYM53C810, 0xff, "810a", 4, 8, 4, FE_CACHE_SET|FE_LDSTR|FE_PFEN|FE_BOF} , {PCI_ID_SYM53C825, 0xff, "825a", 6, 8, 4, FE_WIDE|FE_CACHE0_SET|FE_BOF|FE_DFS|FE_LDSTR|FE_PFEN|FE_RAM|FE_DIFF} , {PCI_ID_SYM53C860, 0xff, "860", 4, 8, 5, FE_ULTRA|FE_CLK80|FE_CACHE_SET|FE_BOF|FE_LDSTR|FE_PFEN} But I'm afraid it does not work like expected: a fresh kernel says: pci0: on pcib0 sym0: <810a> irq 7 at device 5.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, parity checking sym0: open drain IRQ line driver CACHE TEST FAILED: script execution failed. start=47c625c8, pc=47c625d4, end=47c625e8 sym0: CACHE INCORRECTLY CONFIGURED. device_probe_and_attach: sym0 attach returned 6 Qlogic ISP Driver, FreeBSD Version 4.0, Core Version 1.11 Can I enable extra debugging output maybe to help nail it down? Cheers, Wilko > Sorry for the stupid trivial bug. The below untested change should help > for the driver to ignore the 810. > > --- sym_hipd.c.991126 Fri Nov 26 01:37:51 1999 > +++ sym_hipd.c Fri Nov 26 01:40:35 1999 > @@ -9515,6 +9515,9 @@ > #endif /* FreeBSD_4_Bus */ > > static struct sym_pci_chip sym_pci_dev_table[] = { > + {PCI_ID_SYM53C810, 0x01, "810", 4, 8, 4, > + 0} > + , > {PCI_ID_SYM53C810, 0xff, "810a", 4, 8, 4, > FE_CACHE_SET|FE_LDSTR|FE_PFEN|FE_BOF} > , -- | / 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 Fri Nov 26 1:33:43 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 AD22414E15 for ; Fri, 26 Nov 1999 01:33:31 -0800 (PST) (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 KAA31643; Fri, 26 Nov 1999 10:00:01 +0100 (MET) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id JAA49461; Fri, 26 Nov 1999 09:13:54 +0100 (CET) (envelope-from wilko) From: Wilko Bulte Message-Id: <199911260813.JAA49461@yedi.iaf.nl> Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: from Gerard Roudier at "Nov 26, 1999 1:22:44 am" To: groudier@club-internet.fr (Gerard Roudier) Date: Fri, 26 Nov 1999 09:13:54 +0100 (CET) Cc: cdillon@wolves.k12.mo.us, roberto@keltia.freenix.fr, 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=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Gerard Roudier wrote ... > On Thu, 25 Nov 1999, Wilko Bulte wrote: > > [ ... ] > > > Being curious I put the sym into -current on the Alpha box and got: > > > > EB64+ > > Alpha 21064A Evaluation Board 274 MHz, 274MHz > > [ ... ] > > > sym0: <810a> irq 7 at device 5.0 on pci0 > > sym0: No NVRAM, ID 7, Fast-10, parity checking > > CACHE TEST FAILED: script execution failed. > > start=47c625c8, pc=47c625d4, end=47c625e8 > > sym0: CACHE INCORRECTLY CONFIGURED. > > SYM-0.9.0 was not checked for Alpha and in fact could only fail with > Alpha (The source said 'only i386 supported') :-) > SYM-0.10.0 should work on paper for Alpha but needed some trivial > changes in order to work for some Alpha. > SYM-0.11.0 should be ok for Alpha OK, what I have on the Alpha box is: PATCH-SYM-0.10.0-19991111 SYM-0.9.0-19991024.tar.gz PATCH-SYM-0.11.0-19991120 The markings of the motherboard's chip say: - NCR810 609-03911399 XP05901 9426N <- probably a datecode of 1994, week 2 The markings on the chip of the PCI expansion board say: - NCR810 609-0391635 9503N <- probably a datecode of 1995, week 3 So, is not an 810A but an 810-plain. At least, I assume the 810A is marked as such (?). > The sym driver performs MMIOs with a mb() after each access, as it seemed > to be the default for the ncr driver. In my opinion, using normal IOs > should be more safe for Alpha. If you still want to give the sym driver > (0.11.0) a try, you should uncomment the following define in sym_conf.h. > > /* > * Use Normal IO instead of MMIO. > */ > /* #define SYMCONF_IOMAPPED */ > > Gérard. -- | / 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 Fri Nov 26 1:36: 8 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 1393614E15 for ; Fri, 26 Nov 1999 01:36:04 -0800 (PST) (envelope-from hibma@skylink.it) Received: from skylink.it (va-159.skylink.it [194.185.55.159]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id KAA29637 for ; Fri, 26 Nov 1999 10:36:27 +0100 Received: from localhost (localhost [127.0.0.1]) by skylink.it (8.9.3/8.9.3) with ESMTP id AAA00553 for ; Fri, 26 Nov 1999 00:39:58 +0100 (CET) (envelope-from hibma@skylink.it) Date: Fri, 26 Nov 1999 00:39:57 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: FreeBSD SCSI Mailing List Subject: Re: AC_LOST_DEVICE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If I want to indicate an added device, should I specify the path of the ^^^^^ should have been removed Sorry about that. > the path of the new device (sc->path) or of the controller it is > attached to (umass_path)? > > xpt_async(AC_LOST_DEVICE, sc->path, NULL); -- hibma@skylink.it n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 26 12: 4:33 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by hub.freebsd.org (Postfix) with ESMTP id 24A94150AF for ; Fri, 26 Nov 1999 12:04:28 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-173-122.villette.club-internet.fr [195.36.173.122]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id VAA02350; Fri, 26 Nov 1999 21:03:34 +0100 (MET) Date: Fri, 26 Nov 1999 22:28:19 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: Wilko Bulte Cc: scsi@FreeBSD.ORG Subject: Re: NEWS: SYM53C1010 and Ultra3 support In-Reply-To: <199911260909.KAA49959@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It was about midnight when I sent you the patch and may-be I should have gone to bed. The patch is obviously wrong. The 2rd parameter is the highest PCI revision id (and not the least) that must match (the ncr uses the least). Since 810a series started ar revision 0x10, the right patch should be: (0x01 changed to 0xf) static struct sym_pci_chip sym_pci_dev_table[] =3D { + {PCI_ID_SYM53C810, 0xf, "810", 4, 8, 4, + 0} + , {PCI_ID_SYM53C810, 0xff, "810a", 4, 8, 4, FE_CACHE_SET|FE_LDSTR|FE_PFEN|FE_BOF} , Btw, I will made a new diff available over the week-end that contains the= =20 fix for this problem and some tiny other ones related to Ultra3. My 810 and 825 are in a separate box that does not need the sym driver. This may explain I missed the chip table was wrong. Btw, it is right on Linux but I indeed cut too many entries in the port.:) Thanks for the help. G=E9rard. On Fri, 26 Nov 1999, Wilko Bulte wrote: > As Gerard Roudier wrote ... >=20 > Hi Gerard, >=20 > After patching the table now looks like: >=20 > static struct sym_pci_chip sym_pci_dev_table[] =3D { > {PCI_ID_SYM53C810, 0x01, "810", 4, 8, 4, > 0} > , > {PCI_ID_SYM53C810, 0xff, "810a", 4, 8, 4, =20 > FE_CACHE_SET|FE_LDSTR|FE_PFEN|FE_BOF} > , > {PCI_ID_SYM53C825, 0xff, "825a", 6, 8, 4, > FE_WIDE|FE_CACHE0_SET|FE_BOF|FE_DFS|FE_LDSTR|FE_PFEN|FE_RAM|FE_DIFF} > , > {PCI_ID_SYM53C860, 0xff, "860", 4, 8, 5, > FE_ULTRA|FE_CLK80|FE_CACHE_SET|FE_BOF|FE_LDSTR|FE_PFEN} >=20 > But I'm afraid it does not work like expected: a fresh kernel says: >=20 > pci0: on pcib0 > sym0: <810a> irq 7 at device 5.0 on pci0 > sym0: No NVRAM, ID 7, Fast-10, parity checking > sym0: open drain IRQ line driver > CACHE TEST FAILED: script execution failed. > start=3D47c625c8, pc=3D47c625d4, end=3D47c625e8 > sym0: CACHE INCORRECTLY CONFIGURED. > device_probe_and_attach: sym0 attach returned 6 > Qlogic ISP Driver, FreeBSD Version 4.0, Core Version 1.11 >=20 > Can I enable extra debugging output maybe to help nail it down? >=20 > Cheers, > =09Wilko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 26 14:22:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id 04F81151F2 for ; Fri, 26 Nov 1999 14:22:34 -0800 (PST) (envelope-from hibma@skylink.it) Received: from skylink.it (va-184.skylink.it [194.185.55.184]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id XAA01069; Fri, 26 Nov 1999 23:22:53 +0100 Received: from localhost (localhost [127.0.0.1]) by skylink.it (8.9.3/8.9.3) with ESMTP id WAA00299; Fri, 26 Nov 1999 22:43:05 +0100 (CET) (envelope-from hibma@skylink.it) Date: Fri, 26 Nov 1999 22:43:05 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: found device. In-Reply-To: <199911251503.IAA99696@narnia.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > if (xpt_create_path(&sc->path, NULL, cam_sim_path(umass_sim), if (xpt_create_path(&sc->path, xpt_periph, cam_sim_path(umass_sim), > > device_get_unit(sc->sc_dev), CAM_LUN_WILDCARD) device_get_unit(sc->sc_dev), 0) > > != CAM_REQ_CMP) > > return(ENOMEM); > > > > ccb = malloc(sizeof(union ccb), M_DEVBUF, M_WAITOK); memset(ccb, 0, sizeof(union ccb)); > > xpt_setup_ccb(&ccb->ccb_h, sc->path, 5/*priority (low)*/); > > ccb->ccb_h.func_code = XPT_SCAN_LUN; ccb->ccb_h.func_code = XPT_SCAN_BUS; > > ccb->ccb_h.cbfcnp = umass_cam_attach_callback; > > ccb->crcn.flags = CAM_FLAG_NONE; > > xpt_action(ccb); > > > > return(0); > > } > > If you simply want to rescan the bus, try XPT_SCAN_BUS. It still requires periph to be set in xpt_done to decide in which queue to queue the ccb (BIO or NET). After the changes made above the code works (and makes sense). I suggest the following: When using camcontrol to scan the bus, the peripheral that is used is xpt_periph. If xpt_periph is exported in cam_periph.h that peripheral can be used as a place holder. Nick -- hibma@skylink.it n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 26 14:29: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id DC73B14C07 for ; Fri, 26 Nov 1999 14:29:05 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA92935 for ; Fri, 26 Nov 1999 14:29:05 -0800 (PST) Date: Fri, 26 Nov 1999 14:29:05 -0800 (PST) From: Julian Elischer To: scsi@freebsd.org Subject: docs on FreeBSD CAM? 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 For a long while now there has been talk of a brief overview of FfreeBSD's variant of the CAM system. It has been apparently 'in the works' now for most of teh time CAM has been in existence. Is it progressing? Some diagrams and one or tow pages would be really helpful. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 26 18:45:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 1463414BE4 for ; Fri, 26 Nov 1999 18:45:08 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id TAA09755; Fri, 26 Nov 1999 19:43:14 -0700 (MST) (envelope-from ken) Message-Id: <199911270243.TAA09755@panzer.kdm.org> Subject: Re: docs on FreeBSD CAM? In-Reply-To: from Julian Elischer at "Nov 26, 1999 02:29:05 pm" To: julian@whistle.com (Julian Elischer) Date: Fri, 26 Nov 1999 19:43:14 -0700 (MST) Cc: scsi@FreeBSD.ORG From: "Kenneth D. Merry" 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 Julian Elischer wrote... > > For a long while now there has been talk of a brief overview of FfreeBSD's > variant of the CAM system. It has been apparently 'in the works' now for > most of teh time CAM has been in existence. Is it progressing? > > Some diagrams and one or tow pages would be really helpful. http://www.FreeBSD.ORG/~gibbs http://www.t10.org That's all there is, besides the man pages in the tree. If all you want is some diagrams and one or two pages, Justin's talk from USENIX '98 (the first URL above) should be sufficient. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Nov 26 20: 2:26 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80]) by hub.freebsd.org (Postfix) with ESMTP id 4B09C14C84 for ; Fri, 26 Nov 1999 20:02:18 -0800 (PST) (envelope-from gibbs@caspian.plutotech.com) Received: from caspian.plutotech.com (localhost [127.0.0.1]) by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id UAA03942; Fri, 26 Nov 1999 20:02:58 -0700 (MST) (envelope-from gibbs@caspian.plutotech.com) Message-Id: <199911270302.UAA03942@caspian.plutotech.com> X-Mailer: exmh version 2.1.0 09/18/1999 To: Nick Hibma Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: found device. In-reply-to: Your message of "Fri, 26 Nov 1999 22:43:05 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Nov 1999 20:02:58 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >It still requires periph to be set in xpt_done to decide in which queue >to queue the ccb (BIO or NET). > >After the changes made above the code works (and makes sense). > > >I suggest the following: > >When using camcontrol to scan the bus, the peripheral that is used is >xpt_periph. If xpt_periph is exported in cam_periph.h that peripheral >can be used as a place holder. The correct long term solution is to use the device discovery model from CAM3 that supports 'auto discovery'. This is required for fiber-channel too. Take a peek at the spec if you are interested (somewhere on www.t10.org). -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message