From owner-freebsd-scsi Mon Mar 11 1:50:41 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from melchior.cuivre.fr.eu.org (melchior.enst.fr [137.194.161.6]) by hub.freebsd.org (Postfix) with ESMTP id EC1D937B402 for ; Mon, 11 Mar 2002 01:50:36 -0800 (PST) Received: from melusine.cuivre.fr.eu.org (melusine.enst.fr [137.194.160.34]) by melchior.cuivre.fr.eu.org (Postfix) with ESMTP id 4C7EC7817; Mon, 11 Mar 2002 10:50:33 +0100 (CET) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 4E8CD2C3D1; Mon, 11 Mar 2002 10:50:32 +0100 (CET) Date: Mon, 11 Mar 2002 10:50:32 +0100 From: Thomas Quinot To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: ATAPI/CAM boot-time hang Message-ID: <20020311105032.A32895@melusine.cuivre.fr.eu.org> Reply-To: thomas@cuivre.fr.eu.org References: <20020309001232.A96693@melusine.cuivre.fr.eu.org> <20020309161919.A59137@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20020309161919.A59137@panzer.kdm.org>; from ken@kdm.org on Sat, Mar 09, 2002 at 04:19:19PM -0700 X-message-flag: WARNING! Using Outlook can damage your computer. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Le 2002-03-10, Kenneth D. Merry écrivait : > That is illegal behavior (returning unit attention in response to an > inquiry). An inquiry should only result in a check condition when the > device can't fulfill the request. In this case, the device is sending back > a unit attention, which has nothing to do with not being able to fulfill > the request. Plus, the ATAPI generic code immediately issues a REQUEST SENSE in such a situation, which should clear the UA in any case. > The reason we set the SF_RETRY_UA flag is because unit attentions are > expected conditions, and will be cleared as soon as they are reported. OK. > They aren't cleared by an inquiry, but then they aren't supposed to be > reported in response to an inquiry. Agreed. > It's possible in -current that we might actually decrement the count for a > unit attention, depending on what ASC/ASCQ are returned. We get 0x2e/0x00, which is unassigned in SPC, and assigned to 'INSUFFICIENT TIME FOR OPERATION' in SPC-2 and higher. This ASC/ASCQ is specific to CD-ROM class devices, and in any case should be returned only with a CHECK CONDITION sense key. > > 1. consider that the device's behaviour is abnormal (ATAPI does > > always perform autosense, so UNIT ATTENTION should be cleared > > on the 2nd attempt) and create quirk entries for it; From what I infer from the above it is likely that we need to introduce these new quirk entries (CAM_QUIRK_NOFULLINQUIRY?) (or maybe CAM_NEW_TRAN_CODE provides another way of working around such issues -- I have yet to have a closer look at it). > > 2. decrement the retry count when receiving UNIT ATTENTION (but in > > that case, the probe machinery should not consider failure of > > full inquiry as an indication that the device has disappeared); Since UA is supposed to be a transient condition, couldn't we clear SF_RETRY_UA the first time we do a retry, so as to ensure that a command which yields a (bogus) UA at every retry finally fails? > > 3. get rid of the full inquiry altogether (anything besides > > SHORT_INQUIRY_LENGTH is vendor-specific anyway -- do we actually > > use it?) > Take a look at the scsi_inquiry_data structure in scsi_all.h. There > are fields used to indicate the ability to do QAS, DT clocking, etc. At > least the DT clocking bit is used in the transport layer, and the ses(4) > driver needs some of the extended data as well. Ah, yes, I see the SPI stuff there in SPC2 (in what were reserved bits in SPC), so the answer to my question above is 'yes we do use actually use it'. > Well, it would help to find out what ASC/ASCQ are actually getting returned > from the device. We know what the sense key is, but it would be useful to > find out what ASC/ASCQ are reported. atapi_interrupt: result = 0x60 ... cmd was 0x12, now doing autosense -> here the ATAPI layer reports an UA (the high-order nibble of result is a sense key) in response to our INQUIRY, and the atapi_interrupt routine automatically schedules a REQUEST SENSE atapi_interrupt: result = 0x60 -> here the unit has replied to the internally-generated REQUEST SENSE... atapi_cb: hcb@0xc1edac40 status = 60: (sk = 06) atapicam1s: cmd 03 - sk=06 asc=2e ascq=00 -> ... the xpt callback gets back control, and we see that we have a sense key of 6 UNIT ATTENTION, and an ASC/ASCQ of 2e/00 INSUFFICIENT TIME FOR OPERATION. Bogus. Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 13 6:28: 3 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mr3.ipartners.pl (mr3.ipartners.pl [157.25.5.21]) by hub.freebsd.org (Postfix) with ESMTP id 5915837B41B for ; Wed, 13 Mar 2002 06:27:50 -0800 (PST) Received: from quad.ikp.pl (st-gw.ipartners.pl [157.25.5.250]) by mr3.ipartners.pl (8.9.3/8.9.1/MR1.0) with ESMTP id PAA00958 for ; Wed, 13 Mar 2002 15:27:49 +0100 (CET) (envelope-from mjaw@ipartners.pl) Received: from quad.ikp.pl (localhost.ikp.pl [127.0.0.1]) by quad.ikp.pl (8.12.1/8.12.1) with ESMTP id g2DERmXd007291 for ; Wed, 13 Mar 2002 15:27:48 +0100 (CET) Received: (from mjaw@localhost) by quad.ikp.pl (8.12.1/8.12.1/Submit) id g2DERmHJ007290 for freebsd-scsi@freebsd.org; Wed, 13 Mar 2002 15:27:48 +0100 (CET) Date: Wed, 13 Mar 2002 15:27:48 +0100 From: Miroslaw Jaworski To: freebsd-scsi@freebsd.org Subject: QLA2200 - FC storage problem Message-ID: <20020313152748.M99710@quad.ikp.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi Initial problem : controller timeout with error isp0: mailbox timeout Solution : enable Qlogic's BIOS ( thanks to Matthew Jacob's answer on this group dated 7/23/2001. Second "problem": "isp0 WARNING-cannot determine Expanded LUN capability -limiting to one LUN" Solution : add controller firmware to the kernel (device ispfw) or load it at startup (add to /boot/loader.conf ispfw_load="YES" ) Again, although not clearly stated, it's in Matthew Jacob's answer ) Current problem : QLogic QLA2200 doesn't see any resources on a FC storage At machine startup QLogic shows a list of resources created on FC storage, with all informations about LUNs, IDs, RAID types. However, no devices ( except one local SCSI disk ) are detected at the end of detection process. So, communication FC storage<->HBA seems to be ok, but what to do next ? I have two intel boxes and two FC storages ( Clariion 5500 and 4700 ) for testing purposes, i can play with it a little if anyone needs some tests to be performed. Regards MJ. -- Miroslaw.Jaworski@ipartners.pl ( Psyborg ) MJ102-RIPE Internet Partners Server Administration Department Manager To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 13 9:59:20 2002 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 48B4C37B41A; Wed, 13 Mar 2002 09:59:08 -0800 (PST) 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 LAA35159; Wed, 13 Mar 2002 11:59:07 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Wed, 13 Mar 2002 11:59:06 -0600 (CST) From: Chris Dillon To: Cc: Subject: CD-MRW a.k.a Mt. Rainier support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org CC'd to freebsd-fs since this is somewhat fs-related... Is anyone working on implementing support for CD-MRW (apparently included in MMC-3) into either the SCSI cd driver or the ATAPI cd driver? Where/how would be the best place to implement this so that it will work with either ATAPI or SCSI drives? Would implementing it in the SCSI cd driver be best, since we now have the option of using ATAPI drives with CAM? In case anyone is wondering what CD-MRW (Mt. Rainier Re-Writable) is, it is a new standard (currently only available in the Yamaha CRW3200 series, that I know of), that allows on-the-fly transparent formatting, hardware defect management, and 2K-block logical addressing of CD-RW discs and specifies a specialized UDF filesystem to be used along with these hardware abilities. This will make drives supporting this standard act like a more traditional magnetic-media removable drive, thus greatly simplifying reading/writing to CD-RW discs. Since MRW uses a new format it is not backwards compatible with any existing CD-RW formats, though it is possible to _read_ a MRW formatted disc in a regular drive with the proper software support. MRW uses UDF as its standard filesystem, which we do not yet support, though I envision using the hardware MRW support of the drive to put just about anything you want onto it, including FAT or UFS, to use it as a "regular" drive. I'd love to take a shot at implementing this if someone isn't already, though I'll need to find the specs for the hardware side of Mt. Rainier. Apprently it is implemented in the new MMC-3 command set. Anyone have any pointers? -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - 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 Mar 13 10: 7:41 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from melchior.cuivre.fr.eu.org (melchior.enst.fr [137.194.161.6]) by hub.freebsd.org (Postfix) with ESMTP id 2F0F237B400; Wed, 13 Mar 2002 10:07:37 -0800 (PST) Received: from melusine.cuivre.fr.eu.org (melusine.enst.fr [137.194.160.34]) by melchior.cuivre.fr.eu.org (Postfix) with ESMTP id 86BDC8567; Wed, 13 Mar 2002 19:07:34 +0100 (CET) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 43A4D2C3D2; Wed, 13 Mar 2002 19:07:18 +0100 (CET) Date: Wed, 13 Mar 2002 19:07:18 +0100 From: Thomas Quinot To: Chris Dillon Cc: freebsd-scsi@freebsd.org, freebsd-fs@freebsd.org Subject: Re: CD-MRW a.k.a Mt. Rainier support Message-ID: <20020313190718.A3239@melusine.cuivre.fr.eu.org> Reply-To: thomas@cuivre.fr.eu.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: ; from cdillon@wolves.k12.mo.us on Wed, Mar 13, 2002 at 11:59:06AM -0600 X-message-flag: WARNING! Using Outlook can damage your computer. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Le 2002-03-13, Chris Dillon écrivait : > it will work with either ATAPI or SCSI drives? Would implementing it > in the SCSI cd driver be best, since we now have the option of using > ATAPI drives with CAM? I'd say implement in the SCSI cd driver, because this option allows you to support both proper SCSI devices and ATAPI units without duplicated code :). Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 13 11:36:41 2002 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 6667537B416 for ; Wed, 13 Mar 2002 11:36:38 -0800 (PST) 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 NAA37631; Wed, 13 Mar 2002 13:36:34 -0600 (CST) (envelope-from cdillon@wolves.k12.mo.us) Date: Wed, 13 Mar 2002 13:36:33 -0600 (CST) From: Chris Dillon To: Thomas Quinot Cc: Subject: Re: CD-MRW a.k.a Mt. Rainier support In-Reply-To: <20020313190718.A3239@melusine.cuivre.fr.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 13 Mar 2002, Thomas Quinot wrote: > Le 2002-03-13, Chris Dillon écrivait : > > > it will work with either ATAPI or SCSI drives? Would implementing it > > in the SCSI cd driver be best, since we now have the option of using > > ATAPI drives with CAM? > > I'd say implement in the SCSI cd driver, because this option allows > you to support both proper SCSI devices and ATAPI units without > duplicated code :). That's what I figured. :-) That would mean the ATAPI code for CAM would have to be integrated into FreeBSD, but we're planning on doing that anyway, right? -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - 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 Mar 13 13:29:40 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 091B637B405 for ; Wed, 13 Mar 2002 13:29:37 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g2DLTau47762 for freebsd-scsi@freebsd.org; Wed, 13 Mar 2002 22:29:36 +0100 (CET) (envelope-from wkb) Date: Wed, 13 Mar 2002 22:29:36 +0100 From: Wilko Bulte To: freebsd-scsi@freebsd.org Subject: test tools Message-ID: <20020313222936.G47476@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org People interested in test tools might be interestd in: http://www.bit-net.com/~rmiller/dt.html I have not tried it on FreeBSD yet. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 14 12:13:29 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from catalepsy.pdl.cmu.edu (CATALEPSY.PDL.CMU.EDU [128.2.134.92]) by hub.freebsd.org (Postfix) with ESMTP id 65CD237B416 for ; Thu, 14 Mar 2002 12:13:24 -0800 (PST) Received: (from bucy@localhost) by catalepsy.pdl.cmu.edu (8.11.4/8.11.4) id g2EKDLl08458 for freebsd-scsi@freebsd.org; Thu, 14 Mar 2002 15:13:21 -0500 Date: Thu, 14 Mar 2002 15:13:21 -0500 From: "John S. Bucy" To: freebsd-scsi@freebsd.org Subject: aic7xxx: data overrun detected in Data-in phase Message-ID: <20020314151321.E29131@catalepsy.pdl.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Continuing to hack on target mode stuff ... on the *initiator* side (unmodified 4.4 with a 29160), I occasionally see "data overrun detected in Data-in phase" which is sometimes followed by a crash from ahc_run_qoutfifo. Is this a fixed bug/do I need to upgrade the driver? If no, any idea what I might be doing on the target side to cause this (more specifically than sending too much data :P ) .. this usually only happens after I shutdown and restart my target emulator program without restarting the initiator... thanks john To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Mar 14 12:48:52 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id E2ECB37B402 for ; Thu, 14 Mar 2002 12:48:48 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.6/8.11.5) with ESMTP id g2EKp6I67089; Thu, 14 Mar 2002 13:51:07 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200203142051.g2EKp6I67089@aslan.scsiguy.com> To: "John S. Bucy" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: aic7xxx: data overrun detected in Data-in phase In-Reply-To: Your message of "Thu, 14 Mar 2002 15:13:21 EST." <20020314151321.E29131@catalepsy.pdl.cmu.edu> Date: Thu, 14 Mar 2002 13:51:06 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >Continuing to hack on target mode stuff ... > >on the *initiator* side (unmodified 4.4 with a 29160), I occasionally >see "data overrun detected in Data-in phase" which is sometimes >followed by a crash from ahc_run_qoutfifo. Is this a fixed bug/do I >need to upgrade the driver? I would need more information to be able to say. It doesn't ring a bell. >If no, any idea what I might be doing on >the target side to cause this (more specifically than sending too much >data :P ) .. this usually only happens after I shutdown and restart >my target emulator program without restarting the initiator... Do you have a SCSI bus trace? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Mar 15 9:41:13 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from boromir.vpop.net (dns1.vpop.net [206.117.147.2]) by hub.freebsd.org (Postfix) with ESMTP id 5B0B137B404 for ; Fri, 15 Mar 2002 09:40:53 -0800 (PST) Received: from vpop.net (bilbo.vpop.net [65.103.33.41]) by boromir.vpop.net (8.11.6/8.11.6) with ESMTP id g2FHeoF89736 for ; Fri, 15 Mar 2002 09:40:50 -0800 (PST) (envelope-from mreimer@vpop.net) Message-ID: <3C92325C.30403@vpop.net> Date: Fri, 15 Mar 2002 11:41:48 -0600 From: Matthew Reimer Organization: VPOP Technologies, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9) Gecko/20020312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: scsi@freebsd.org Subject: no active SCB for reconnecting target Content-Type: multipart/mixed; boundary="------------010807080702030209000708" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------010807080702030209000708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit We are getting errors like the following a dozen or so times per day, for several months now (maybe even a year): ahc0:A:13: no active SCB for reconnecting target - issuing BUS DEVICE RESET Mar 15 00:49:26 ring /kernel: SAVED_SCSIID == 0xd7, SAVED_LUN == 0x0, ARG_1 == 0x2a ACCUM = 0x17 ... (A few of these messages are included in full in an attachment.) What does this mean? Hardware or driver problems? How can I fix the problem? The box is running 4.5-STABLE: # uname -a FreeBSD ring.vpop.net 4.5-STABLE FreeBSD 4.5-STABLE #0: Wed Feb 20 15:20:24 PST 2002 mreimer@thorin.vpop.net:/usr/obj/usr/src/sys/RING i386 Also attached is dmesg output. The motherboard is an early L440GX+ (P/N 721242-003) with an onboard Adaptec 2940U2W with BIOS version 2.20S1B1, three IBM Ultrastar disks on one bus and an HP autoloader 418 on the second bus. The errors seem to occur more frequently while the tape drive is in use, but the errors still occur when the drive is not in use. Any help is much appreciated. Matt --------------010807080702030209000708 Content-Type: text/plain; name="msg" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="msg" Mar 15 00:49:26 ring /kernel: ahc0:A:13: no active SCB for reconnecting target - issuing BUS DEVICE RESET Mar 15 00:49:26 ring /kernel: SAVED_SCSIID == 0xd7, SAVED_LUN == 0x0, ARG_1 == 0x2a ACCUM = 0x17 Mar 15 00:49:26 ring /kernel: SEQ_FLAGS == 0x0, SCBPTR == 0x10, BTT == 0xff, SINDEX == 0x31 Mar 15 00:49:26 ring /kernel: SCSIID == 0x0, SCB_SCSIID == 0x17, SCB_LUN == 0x0, SCB_TAG == 0x2a, SCB_CONTROL == 0x64 Mar 15 00:49:26 ring /kernel: SCSIBUSL == 0x2a, SCSISIGI == 0xe6 Mar 15 00:49:26 ring /kernel: SXFRCTL0 == 0x88 Mar 15 00:49:26 ring /kernel: SEQCTL == 0x10 Mar 15 00:49:26 ring /kernel: ahc0: Dumping Card State in Message-in phase, at SEQADDR 0x1a0 Mar 15 00:49:26 ring /kernel: ACCUM = 0x17, SINDEX = 0x31, DINDEX = 0xe4, ARG_2 = 0xa Mar 15 00:49:26 ring /kernel: HCNT = 0x0 Mar 15 00:49:26 ring /kernel: SCSISEQ = 0x12, SBLKCTL = 0xa Mar 15 00:49:26 ring /kernel: DFCNTRL = 0x0, DFSTATUS = 0x89 Mar 15 00:49:26 ring /kernel: LASTPHASE = 0xe0, SCSISIGI = 0xe6, SXFRCTL0 = 0x88 Mar 15 00:49:26 ring /kernel: SSTAT0 = 0x2, SSTAT1 = 0x3 Mar 15 00:49:26 ring /kernel: STACK == 0x175, 0x15f, 0xe6, 0x13b Mar 15 00:49:26 ring /kernel: SCB count = 140 Mar 15 00:49:26 ring /kernel: Kernel NEXTQSCB = 43 Mar 15 00:49:26 ring /kernel: Card NEXTQSCB = 43 Mar 15 00:49:26 ring /kernel: QINFIFO entries: Mar 15 00:49:26 ring /kernel: Waiting Queue entries: Mar 15 00:49:27 ring /kernel: Disconnected Queue entries: 16:42 6:51 Mar 15 00:49:27 ring /kernel: QOUTFIFO entries: Mar 15 00:49:27 ring /kernel: Sequencer Free SCB List: 17 24 15 22 21 23 8 9 28 27 19 31 25 18 3 7 13 10 5 11 20 12 2 1 29 14 30 0 4 26 Mar 15 00:49:27 ring /kernel: Pending list: 42, 51 Mar 15 00:49:27 ring /kernel: Kernel Free SCB list: 58 129 54 104 72 31 14 48 76 11 125 33 124 117 93 12 121 92 26 126 46 34 59 4 17 0 44 96 91 30 56 68 10 105 19 55 45 108 98 137 41 29 7 20 90 49 13 39 107 102 32 139 65 103 109 3 113 8 128 100 97 81 52 101 71 120 27 94 75 122 114 95 67 136 73 89 28 25 135 106 69 15 1 23 138 38 87 80 5 99 6 85 9 84 74 123 83 36 50 53 57 22 115 110 119 127 66 40 18 86 118 24 82 111 112 16 21 2 88 116 47 35 37 70 77 78 79 60 61 62 63 64 134 133 132 131 130 Mar 15 00:49:27 ring /kernel: ahc0: Bus Device Reset on A:13. 0 SCBs aborted Mar 15 00:50:25 ring /kernel: (da1:ahc0:0:1:0): SCB 0x33 - timed out Mar 15 00:50:25 ring /kernel: ahc0: Dumping Card State while idle, at SEQADDR 0x8 Mar 15 00:50:25 ring /kernel: ACCUM = 0x0, SINDEX = 0x31, DINDEX = 0xe4, ARG_2 = 0x0 Mar 15 00:50:25 ring /kernel: HCNT = 0x0 Mar 15 00:50:25 ring /kernel: SCSISEQ = 0x12, SBLKCTL = 0xa Mar 15 00:50:25 ring /kernel: DFCNTRL = 0x0, DFSTATUS = 0x89 Mar 15 00:50:26 ring /kernel: LASTPHASE = 0x1, SCSISIGI = 0x0, SXFRCTL0 = 0x80 Mar 15 00:50:26 ring /kernel: SSTAT0 = 0x0, SSTAT1 = 0xa Mar 15 00:50:26 ring /kernel: STACK == 0x3, 0x107, 0x15f, 0xe6 Mar 15 00:50:26 ring /kernel: SCB count = 140 Mar 15 00:50:26 ring /kernel: Kernel NEXTQSCB = 4 Mar 15 00:50:26 ring /kernel: Card NEXTQSCB = 4 Mar 15 00:50:26 ring /kernel: QINFIFO entries: Mar 15 00:50:26 ring /kernel: Waiting Queue entries: Mar 15 00:50:26 ring /kernel: Disconnected Queue entries: 16:42 6:51 Mar 15 00:50:26 ring /kernel: QOUTFIFO entries: Mar 15 00:50:26 ring /kernel: Sequencer Free SCB List: 11 21 25 15 1 29 19 17 14 2 0 27 8 7 23 24 13 31 18 10 4 28 5 3 26 30 9 12 20 22 Mar 15 00:50:26 ring /kernel: Pending list: 42, 51 Mar 15 00:50:26 ring /kernel: Kernel Free SCB list: 49 0 54 105 117 72 93 17 102 125 30 108 126 3 43 39 31 81 96 48 19 107 109 100 56 10 91 129 90 29 137 12 97 13 55 20 32 46 26 104 76 58 52 124 7 113 8 44 71 98 103 11 33 101 128 139 45 34 14 59 65 92 68 41 121 120 27 94 75 122 114 95 67 136 73 89 28 25 135 106 69 15 1 23 138 38 87 80 5 99 6 85 9 84 74 123 83 36 50 53 57 22 115 110 119 127 66 40 18 86 118 24 82 111 112 16 21 2 88 116 47 35 37 70 77 78 79 60 61 62 63 64 134 133 132 131 130 Mar 15 00:50:26 ring /kernel: sg[0] - Addr 0x17728000 : Length 4096 Mar 15 00:50:26 ring /kernel: sg[1] - Addr 0x10229000 : Length 4096 Mar 15 00:50:26 ring /kernel: (da1:ahc0:0:1:0): Queuing a BDR SCB Mar 15 00:50:26 ring /kernel: (da1:ahc0:0:1:0): Bus Device Reset Message Sent Mar 15 00:50:26 ring /kernel: (da1:ahc0:0:1:0): no longer in timeout, status = 34b Mar 15 00:50:26 ring /kernel: ahc0: Bus Device Reset on A:1. 2 SCBs aborted Mar 15 04:01:34 ring /kernel: ahc0:A:12: no active SCB for reconnecting target - issuing BUS DEVICE RESET Mar 15 04:02:37 ring /kernel: SAVED_SCSIID == 0xc7, SAVED_LUN == 0x0, ARG_1 == 0x72 ACCUM = 0x7 Mar 15 04:02:37 ring /kernel: SEQ_FLAGS == 0x0, SCBPTR == 0x1a, BTT == 0xff, SINDEX == 0x31 Mar 15 04:02:37 ring /kernel: SCSIID == 0x0, SCB_SCSIID == 0x7, SCB_LUN == 0x0, SCB_TAG == 0x72, SCB_CONTROL == 0x64 Mar 15 04:02:37 ring /kernel: SCSIBUSL == 0x72, SCSISIGI == 0xe6 Mar 15 04:02:38 ring /kernel: SXFRCTL0 == 0x88 Mar 15 04:02:38 ring /kernel: SEQCTL == 0x10 Mar 15 04:02:38 ring /kernel: ahc0: Dumping Card State in Message-in phase, at SEQADDR 0x1a0 Mar 15 04:02:38 ring /kernel: ACCUM = 0x7, SINDEX = 0x31, DINDEX = 0xe4, ARG_2 = 0x1c Mar 15 04:02:38 ring /kernel: HCNT = 0x0 Mar 15 04:02:38 ring /kernel: SCSISEQ = 0x12, SBLKCTL = 0xa Mar 15 04:02:38 ring /kernel: DFCNTRL = 0x0, DFSTATUS = 0x89 Mar 15 04:02:38 ring /kernel: LASTPHASE = 0xe0, SCSISIGI = 0xe6, SXFRCTL0 = 0x88 Mar 15 04:02:38 ring /kernel: SSTAT0 = 0x2, SSTAT1 = 0x3 Mar 15 04:02:38 ring /kernel: STACK == 0x175, 0x175, 0xe6, 0x13b Mar 15 04:02:38 ring /kernel: SCB count = 140 Mar 15 04:02:38 ring /kernel: Kernel NEXTQSCB = 108 Mar 15 04:02:38 ring /kernel: Card NEXTQSCB = 108 Mar 15 04:02:38 ring /kernel: QINFIFO entries: Mar 15 04:02:38 ring /kernel: Waiting Queue entries: Mar 15 04:02:38 ring /kernel: Disconnected Queue entries: 26:114 16:103 1:123 22:5 6:16 30:127 23:119 31:24 9:71 3:17 11:94 29:69 27:136 14:138 18:137 21:28 13:46 7:126 28:122 8:116 10:73 24:59 20:112 2:23 17:82 15:98 0:110 4:0 12:13 5:97 19:50 25:35 Mar 15 04:02:38 ring /kernel: QOUTFIFO entries: Mar 15 04:02:38 ring /kernel: Sequencer Free SCB List: Mar 15 04:02:38 ring /kernel: Pending list: 139, 1, 103, 123, 5, 86, 16, 85, 127, 119, 24, 71, 34, 17, 94, 69, 113, 31, 12, 4, 102, 55, 45, 43, 125, 95, 105, 84, 106, 26, 81, 111, 88, 121, 91, 21, 74, 20, 114, 22, 93, 3, 6, 14, 40, 136, 138, 137, 28, 46, 126, 122, 116, 73, 59, 112, 23, 82, 98, 110, 0, 13, 97, 50, 35 Mar 15 04:02:39 ring /kernel: Kernel Free SCB list: 51 118 58 67 29 89 2 41 101 68 38 49 52 104 48 36 115 9 44 27 57 107 54 39 65 87 19 75 47 124 15 7 100 117 128 53 33 129 83 8 37 80 18 10 135 120 109 90 42 25 92 76 70 72 56 96 32 11 99 66 30 77 78 79 60 61 62 63 64 134 133 132 131 130 Mar 15 04:02:39 ring /kernel: ahc0: Bus Device Reset on A:12. 0 SCBs aborted Mar 15 04:02:39 ring /kernel: (da0:ahc0:0:0:0): SCB 0x23 - timed out Mar 15 04:02:39 ring /kernel: ahc0: Dumping Card State while idle, at SEQADDR 0x9 Mar 15 04:02:39 ring /kernel: ACCUM = 0x0, SINDEX = 0x6c, DINDEX = 0xe4, ARG_2 = 0x0 Mar 15 04:02:39 ring /kernel: HCNT = 0x0 Mar 15 04:02:39 ring /kernel: SCSISEQ = 0x12, SBLKCTL = 0xa Mar 15 04:02:39 ring /kernel: DFCNTRL = 0x0, DFSTATUS = 0x89 Mar 15 04:02:39 ring /kernel: LASTPHASE = 0x1, SCSISIGI = 0x0, SXFRCTL0 = 0x80 Mar 15 04:02:39 ring /kernel: SSTAT0 = 0x0, SSTAT1 = 0xa Mar 15 04:02:39 ring /kernel: STACK == 0x3, 0x107, 0x15f, 0xe6 Mar 15 04:02:39 ring /kernel: SCB count = 140 Mar 15 04:02:39 ring /kernel: Kernel NEXTQSCB = 1 Mar 15 04:02:39 ring /kernel: Card NEXTQSCB = 1 Mar 15 04:02:39 ring /kernel: QINFIFO entries: Mar 15 04:02:39 ring /kernel: Waiting Queue entries: Mar 15 04:02:39 ring /kernel: Disconnected Queue entries: 16:103 1:123 22:5 6:16 30:127 23:119 31:24 9:71 3:17 11:94 29:69 27:136 14:138 18:137 21:28 13:46 7:126 28:122 8:116 10:73 24:59 20:112 2:23 17:82 15:98 0:110 4:0 12:13 5:97 19:50 25:35 Mar 15 04:02:39 ring /kernel: QOUTFIFO entries: Mar 15 04:02:39 ring /kernel: Sequencer Free SCB List: 26 Mar 15 04:02:39 ring /kernel: Pending list: 139, 103, 123, 5, 86, 16, 85, 127, 119, 24, 71, 34, 17, 94, 69, 113, 31, 12, 4, 102, 55, 45, 43, 125, 95, 105, 84, 106, 26, 81, 111, 88, 121, 91, 21, 74, 20, 114, 22, 93, 3, 6, 14, 40, 136, 138, 137, 28, 46, 126, 122, 116, 73, 59, 112, 23, 82, 98, 110, 0, 13, 97, 50, 35 Mar 15 04:02:39 ring /kernel: Kernel Free SCB list: 108 51 118 58 67 29 89 2 41 101 68 38 49 52 104 48 36 115 9 44 27 57 107 54 39 65 87 19 75 47 124 15 7 100 117 128 53 33 129 83 8 37 80 18 10 135 120 109 90 42 25 92 76 70 72 56 96 32 11 99 66 30 77 78 79 60 61 62 63 64 134 133 132 131 130 Mar 15 04:02:39 ring /kernel: sg[0] - Addr 0x1060a000 : Length 4096 Mar 15 04:02:39 ring /kernel: sg[1] - Addr 0x1068b000 : Length 4096 Mar 15 04:02:39 ring /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Mar 15 04:02:39 ring /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Mar 15 04:02:39 ring /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 34b Mar 15 04:02:39 ring /kernel: ahc0: Bus Device Reset on A:0. 64 SCBs aborted Mar 15 07:46:58 ring /kernel: ahc0:A:13: no active SCB for reconnecting target - issuing BUS DEVICE RESET Mar 15 07:46:58 ring /kernel: SAVED_SCSIID == 0xd7, SAVED_LUN == 0x0, ARG_1 == 0x42 ACCUM = 0x17 Mar 15 07:46:58 ring /kernel: SEQ_FLAGS == 0x0, SCBPTR == 0x2, BTT == 0xff, SINDEX == 0x31 Mar 15 07:46:58 ring /kernel: SCSIID == 0x0, SCB_SCSIID == 0x17, SCB_LUN == 0x0, SCB_TAG == 0x42, SCB_CONTROL == 0x64 Mar 15 07:46:58 ring /kernel: SCSIBUSL == 0x42, SCSISIGI == 0xe6 Mar 15 07:46:58 ring /kernel: SXFRCTL0 == 0x88 Mar 15 07:46:58 ring /kernel: SEQCTL == 0x10 Mar 15 07:46:58 ring /kernel: ahc0: Dumping Card State in Message-in phase, at SEQADDR 0x1a0 Mar 15 07:46:58 ring /kernel: ACCUM = 0x17, SINDEX = 0x31, DINDEX = 0xa, ARG_2 = 0x1d Mar 15 07:46:58 ring /kernel: HCNT = 0x0 Mar 15 07:46:58 ring /kernel: SCSISEQ = 0x12, SBLKCTL = 0xa Mar 15 07:46:58 ring /kernel: DFCNTRL = 0x0, DFSTATUS = 0x89 Mar 15 07:46:58 ring /kernel: LASTPHASE = 0xe0, SCSISIGI = 0xe6, SXFRCTL0 = 0x88 Mar 15 07:46:58 ring /kernel: SSTAT0 = 0x2, SSTAT1 = 0x3 Mar 15 07:46:58 ring /kernel: STACK == 0x107, 0x15f, 0xe6, 0x13b Mar 15 07:46:58 ring /kernel: SCB count = 140 Mar 15 07:46:58 ring /kernel: Kernel NEXTQSCB = 92 Mar 15 07:46:58 ring /kernel: Card NEXTQSCB = 92 Mar 15 07:46:58 ring /kernel: QINFIFO entries: Mar 15 07:46:58 ring /kernel: Waiting Queue entries: Mar 15 07:46:58 ring /kernel: Disconnected Queue entries: 2:66 20:95 13:24 25:111 29:128 10:136 Mar 15 07:46:58 ring /kernel: QOUTFIFO entries: Mar 15 07:46:58 ring /kernel: Sequencer Free SCB List: 19 27 12 5 9 3 30 7 31 16 23 17 6 24 18 22 11 14 1 8 21 26 28 0 4 15 Mar 15 07:46:58 ring /kernel: Pending list: 95, 24, 111, 128, 66, 136 Mar 15 07:46:58 ring /kernel: Kernel Free SCB list: 22 112 44 97 129 32 86 28 15 102 39 114 137 38 7 25 26 3 4 18 14 70 5 122 41 90 27 59 46 107 127 113 106 34 23 83 101 89 42 19 13 82 100 2 69 17 30 117 108 87 115 57 43 93 8 116 55 126 68 81 71 45 56 54 139 53 67 37 138 73 36 75 119 104 16 10 6 58 110 47 88 76 99 120 52 33 123 29 91 40 109 51 84 48 118 50 94 49 20 96 9 85 80 12 103 1 105 124 31 98 121 65 0 135 125 35 74 72 21 11 77 78 79 60 61 62 63 64 134 133 132 131 130 Mar 15 07:46:58 ring /kernel: ahc0: Bus Device Reset on A:13. 0 SCBs aborted Mar 15 07:47:57 ring /kernel: (da1:ahc0:0:1:0): SCB 0x88 - timed out Mar 15 07:47:57 ring /kernel: ahc0: Dumping Card State while idle, at SEQADDR 0x9 Mar 15 07:47:57 ring /kernel: ACCUM = 0x0, SINDEX = 0x47, DINDEX = 0xe4, ARG_2 = 0x0 Mar 15 07:47:57 ring /kernel: HCNT = 0x0 Mar 15 07:47:57 ring /kernel: SCSISEQ = 0x12, SBLKCTL = 0xa Mar 15 07:47:57 ring /kernel: DFCNTRL = 0x0, DFSTATUS = 0x89 Mar 15 07:47:57 ring /kernel: LASTPHASE = 0x1, SCSISIGI = 0x0, SXFRCTL0 = 0x80 Mar 15 07:47:57 ring /kernel: SSTAT0 = 0x0, SSTAT1 = 0xa Mar 15 07:47:57 ring /kernel: STACK == 0x3, 0x107, 0x15f, 0xe6 Mar 15 07:47:57 ring /kernel: SCB count = 140 Mar 15 07:47:58 ring /kernel: Kernel NEXTQSCB = 34 Mar 15 07:47:58 ring /kernel: Card NEXTQSCB = 34 Mar 15 07:47:58 ring /kernel: QINFIFO entries: Mar 15 07:47:58 ring /kernel: Waiting Queue entries: Mar 15 07:47:58 ring /kernel: Disconnected Queue entries: 2:66 20:95 13:24 25:111 29:128 10:136 Mar 15 07:47:58 ring /kernel: QOUTFIFO entries: Mar 15 07:47:58 ring /kernel: Sequencer Free SCB List: 8 6 9 3 12 15 7 17 11 28 4 23 19 14 27 5 1 16 26 18 21 0 22 30 24 31 Mar 15 07:47:58 ring /kernel: Pending list: 95, 24, 111, 128, 66, 136 Mar 15 07:47:58 ring /kernel: Kernel Free SCB list: 71 117 115 26 97 112 54 139 122 43 19 113 17 68 107 116 14 39 8 86 82 38 32 101 55 27 15 2 129 100 25 92 42 90 45 3 102 126 18 108 28 23 53 114 13 69 93 59 70 57 137 56 4 83 30 7 87 127 22 46 5 89 41 106 81 44 67 37 138 73 36 75 119 104 16 10 6 58 110 47 88 76 99 120 52 33 123 29 91 40 109 51 84 48 118 50 94 49 20 96 9 85 80 12 103 1 105 124 31 98 121 65 0 135 125 35 74 72 21 11 77 78 79 60 61 62 63 64 134 133 132 131 130 Mar 15 07:47:58 ring /kernel: sg[0] - Addr 0x295a0000 : Length 4096 Mar 15 07:47:58 ring /kernel: sg[1] - Addr 0x47041000 : Length 4096 Mar 15 07:47:58 ring /kernel: (da1:ahc0:0:1:0): Queuing a BDR SCB Mar 15 07:47:58 ring /kernel: (da1:ahc0:0:1:0): Bus Device Reset Message Sent Mar 15 07:47:58 ring /kernel: (da1:ahc0:0:1:0): no longer in timeout, status = 34b Mar 15 07:47:58 ring /kernel: ahc0: Bus Device Reset on A:1. 6 SCBs aborted --------------010807080702030209000708 Content-Type: text/plain; name="dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg" Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.5-RC #0: Fri Jan 25 09:55:12 PST 2002 mreimer@thorin.vpop.net:/usr/obj/usr/src/sys/RING Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 547179037 Hz CPU: Pentium III/Pentium III Xeon/Celeron (547.18-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387fbff real memory = 1342111744 (1310656K bytes) avail memory = 1301118976 (1270624K bytes) Preloaded elf kernel "kernel" at 0xc03c0000. Preloaded elf module "vinum.ko" at 0xc03c009c. Preloaded elf module "accf_http.ko" at 0xc03c013c. Pentium Pro MTRR support enabled Using $PIR table, 12 entries at 0xc00fdf00 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib2: at device 1.0 on pci0 pci1: on pcib2 pcib3: at device 15.0 on pci1 pci2: on pcib3 ahc0: port 0x1400-0x14ff mem 0xf4100000-0xf4100fff irq 11 at device 12.0 on pci0 aic7896/97: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: port 0x1800-0x18ff mem 0xf4101000-0xf4101fff irq 11 at device 12.1 on pci0 aic7896/97: Ultra2 Wide Channel B, SCSI Id=7, 32/255 SCBs fxp0: port 0x1080-0x10bf mem 0xf4000000-0xf40fffff,0xf4102000-0xf4102fff irq 10 at device 14.0 on pci0 fxp0: Disabling dynamic standby mode in EEPROM fxp0: New EEPROM ID: 0x40a0 fxp0: EEPROM checksum @ 0x3f: 0x2e92 -> 0x2e94 fxp0: Ethernet address 00:a0:c9:fb:26:e6 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ahc2: port 0x2000-0x20ff mem 0xf4103000-0xf4103fff irq 5 at device 16.0 on pci0 aic7870: Wide Channel A, SCSI Id=7, 16/255 SCBs isab0: at device 18.0 on pci0 isa0: on isab0 pci0: at 18.1 pci0: at 18.2 irq 10 intpm0: port 0x1040-0x104f irq 9 at device 18.3 on pci0 intpm0: I/O mapped 1040 intpm0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped c00 pci0: at 20.0 pcib1: on motherboard pci3: on pcib1 orm0: