From owner-freebsd-scsi Sun Jun 25 0: 3:12 2000 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 F0D3937B5D2; Sun, 25 Jun 2000 00:03:07 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id BAA19355; Sun, 25 Jun 2000 01:02:54 -0600 (MDT) (envelope-from ken) Date: Sun, 25 Jun 2000 01:02:54 -0600 From: "Kenneth D. Merry" To: Nat Lanza Cc: scsi@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: SCSI HBA device detection? Message-ID: <20000625010254.A19247@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from magus@cs.cmu.edu on Fri, Jun 23, 2000 at 01:10:26PM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jun 23, 2000 at 13:10:26 -0400, Nat Lanza wrote: > I'm writing a SCSI HBA driver that simulates a bus with some > ramdisk-backed disks attached to it. I've read through the HBA > tutorial in Daemon News, but I'm still unsure how to tell the system > about my pretend disk devices. I suspect part of the problem is that > I don't actually have real devices or a real IO bus. > > Anyone feel like explaining this? Well, when the system boots, it sends out a SCSI INQUIRY command to each target on each bus. Each target that responds and sends back inquiry data will get further along in the probe process. The same thing happens when you do 'camcontrol rescan 4' to rescan SCSI bus 4. You need to have your "disks" respond to the inquiry command with inquiry data, as well as have them respond suitably to the various other commands that CAM will send. The commands you'll need to support include (but are not limited to), inquiry, test unit ready, read capacity, read (6, 10 and maybe 12 byte), write (6, 10 and maybe 12 byte) and perhaps mode sense. Those commands will probably get you most of the way towards probing and attaching with the da(4) driver. Another alternative to a ramdisk-like driver is a target mode driver. There is a target mode processor target device in sys/cam/scsi/scsi_target.c that you can look at as an example. You'd be limited to the SCSI bus speed (40, 80, 160MB/sec) for throughput though. You'll need specific hardware (Adaptec or QLogic) to do it as well. 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 Sun Jun 25 17:59:56 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from gateway.brisbane.qld.gov.au (gateway.brisbane.qld.gov.au [203.56.233.5]) by hub.freebsd.org (Postfix) with ESMTP id 1FC2637B577 for ; Sun, 25 Jun 2000 17:59:34 -0700 (PDT) (envelope-from Ctdm1@brisbane.qld.gov.au) Received: by gateway.brisbane.qld.gov.au; id KAA01513; Mon, 26 Jun 2000 10:45:48 +1000 (EST) X-Authentication-Warning: gateway.bcc.qld.gov.au: gproxy set sender to using -f Received: from mailhub.bcc.qld.gov.au(136.236.0.68) by gateway via smap (3.1) id xma001438; Mon, 26 Jun 00 10:45:42 +1000 Received: from brisbane.qld.gov.au (unverified [136.236.17.37]) by mailhub.bcc.qld.gov.au (Integralis SMTPRS 2.0.15) with SMTP id for ; Mon, 26 Jun 2000 10:39:12 +1000 Received: from BCC1-Message_Server by brisbane.qld.gov.au with Novell_GroupWise; Mon, 26 Jun 2000 10:47:16 +1000 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 26 Jun 2000 10:49:55 +1000 From: David Elkin To: freebsd-scsi@freebsd.org Subject: PCI parity error for SCSI 2940u2w MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a server running 3.3 and Iam using 2940u2w scsi card. When I boot my server it comes up with a continuos error ach0: Data Parity Error Detected durring address or write data phase Going by what Justin Gibbs has said, it is a PCI parity error. I have since replaced scsi card, cable and moved slots on the motherboard. Also I removed all other pci devices. The error still remains. Any suggestions ?? ---- This mail item has passed through an insecure network. All enquiries should be directed to the message author. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Jun 25 23:53:43 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from alemail1.firewall.lucent.com (alemail1.lucent.com [192.11.221.161]) by hub.freebsd.org (Postfix) with ESMTP id F389B37B84D for ; Sun, 25 Jun 2000 23:53:39 -0700 (PDT) (envelope-from rgrabow@lucent.com) Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id CAA20467 for ; Mon, 26 Jun 2000 02:53:37 -0400 (EDT) Received: from bya1.pl.lucent.com (h135-171-20-10.lucent.com [135.171.20.10]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id CAA20463 for ; Mon, 26 Jun 2000 02:53:36 -0400 (EDT) Received: from bya1c104.SUBDOMAIN.lucent.com by bya1.pl.lucent.com (SMI-8.6/EMS-1.5 sol2) id IAA17914; Mon, 26 Jun 2000 08:52:23 +0200 Received: from lucent.com by bya1c104.SUBDOMAIN.lucent.com (8.8.8+Sun/EMS-1.4.1 client sol2) id IAA06020; Mon, 26 Jun 2000 08:53:35 +0200 (MET DST) Message-ID: <3956FDEF.B9629441@lucent.com> Date: Mon, 26 Jun 2000 08:53:35 +0200 From: Rafal Grabowski X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: (null): MODE_SENSE_BIG - UNIT ATTENTION asc=29 ascq=00 error=04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I am running FreeBSD 4.0 Release. When I boot my system I am getting the following message from the kernel: (null): MODE_SENSE_BIG - UNIT ATTENTION asc=29 ascq=00 error=04 The system works fine, but I would like to know what that message means. Can someone help me? What documentation should I check? Thanks, Rafal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 26 0: 4:20 2000 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 890A937B827 for ; Mon, 26 Jun 2000 00:04:17 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id BAA26384; Mon, 26 Jun 2000 01:04:10 -0600 (MDT) (envelope-from ken) Date: Mon, 26 Jun 2000 01:04:09 -0600 From: "Kenneth D. Merry" To: Rafal Grabowski Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: (null): MODE_SENSE_BIG - UNIT ATTENTION asc=29 ascq=00 error=04 Message-ID: <20000626010409.A26314@panzer.kdm.org> References: <3956FDEF.B9629441@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3956FDEF.B9629441@lucent.com>; from rgrabow@lucent.com on Mon, Jun 26, 2000 at 08:53:35AM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jun 26, 2000 at 08:53:35 +0200, Rafal Grabowski wrote: > Hello, > > I am running FreeBSD 4.0 Release. When I boot my system I am getting the > following message from the kernel: > > (null): MODE_SENSE_BIG - UNIT ATTENTION asc=29 ascq=00 error=04 > > The system works fine, but I would like to know what that message means. > Can someone help me? What documentation should I check? That's actually an ATAPI error, not a SCSI error. If you want to know whether or not it is a problem, I would suggest contacting Soren Schmidt , who is the author of the ATA subsystem. FWIW, in the SCSI world, a unit attention is the expected error condition after a bus or bus device reset. (In most cases, SCSI adapters reset the bus when the system boots.) Once you've gotten the error condition, the state is cleared and the next command will proceed without a unit attention error. 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 Jun 26 2:11:23 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp.www-service.de (smtp.www-service.de [212.77.161.16]) by hub.freebsd.org (Postfix) with SMTP id 7425337C660 for ; Mon, 26 Jun 2000 02:11:14 -0700 (PDT) (envelope-from thz@Lennartz-electronic.de) Received: (qmail 19166 invoked from network); 26 Jun 2000 09:11:00 -0000 Received: from p3e9e1238.dip.t-dialin.net (HELO fw.tue.le) (62.158.18.56) by smtp.www-service.de with SMTP; 26 Jun 2000 09:11:00 -0000 Received: from mezcal.tue.le (mezcal.tue.le [192.168.201.20]) by fw.tue.le (8.8.8/8.8.8) with ESMTP id LAA12791; Mon, 26 Jun 2000 11:08:30 +0200 (CEST) (envelope-from thz@mezcal.tue.le) Received: (from thz@localhost) by mezcal.tue.le (8.9.3/8.9.3) id LAA00705; Mon, 26 Jun 2000 11:08:29 +0200 (CEST) (envelope-from thz) Date: Mon, 26 Jun 2000 11:08:29 +0200 From: Thomas Zenker To: Don Lewis Cc: scsi@FreeBSD.org Subject: Re: Invalidating pack messages Message-ID: <20000626110829.A563@mezcal.tue.le> References: <20000620172810.A84355@albury.net.au> <200006200754.AAA28201@salsa.gv.tsc.tdk.com> <20000621143609.A3012@albury.net.au> <200006220729.AAA07327@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200006220729.AAA07327@salsa.gv.tsc.tdk.com>; from Don.Lewis@tsc.tdk.com on Thu, Jun 22, 2000 at 12:29:59AM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jun 22, 2000 at 12:29:59AM -0700, Don Lewis wrote: > On Jun 21, 2:36pm, Nick Slager wrote: > } Subject: Re: Invalidating pack messages > > } I pulled out the power supply this morning, and replaced it with a brand new > } unit. The system has just crashed again with the 'Invalidating pack' error > } messages. > > [ snip ] > > } If this is the case (and I'm not doubting what you say), what else could cause > } this problem? > > If your seeing funny blinking lights on the drive, and you are not the only > person having problems with this particular drive model, I would be very > suspicious that a drive firmware bug is being tickled. The best solution > in this case would be to obtain a better version of the firmware from the > vendor, but lacking that you might try turning off tagged command queueing > or just reducing the number of tagged openings. I've noticed interactions > between tagged command queueing and write caching on Seagate drives, so you > might try turning off write caching and leaving the number of tagged > openings alone. You can do all this with camcontrol. > > I'm not a fan of write caching since it violates the assumptions behind > softupdates, so I turn it off on all my drives. I haven't seen any > real performance penalty in doing so, though I think I've heard reports > that it makes newfs run slower. > > > You may be seeing this in FreeBSD and not NT because I think the CAM SCSI > system can push the drives a lot harder than the SCSI drivers in NT. > I am seeing the same problem here with an aic7892 onboard controller on a new SuperMicro PMIIIDM3 motherboard and Seagate drive (ST39236LW) here. If tagged queueing enabled it falls in timeout with heavy writes (iozone 10 suffices). I have disabled write caching: no change. Disabling tagged queuing helps (does a buildworld and izone 6000 flawless), but write performance drops to a third. I have tried to change the drive with a ST39175LW, which I took from an other computer with aic7890 onboard and works there very well: it shows the same problems on the aic7892 as the original drive. -- Thomas Zenker c/o Lennartz electronic GmbH Phone: +49-(0)7071-93550 Email: thz@lennartz-electronic.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 26 4:37:15 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from obsidian.noc.dfn.de (obsidian.noc.dfn.de [193.174.247.193]) by hub.freebsd.org (Postfix) with ESMTP id DDBC537BB3F for ; Mon, 26 Jun 2000 04:37:11 -0700 (PDT) (envelope-from schweikh@obsidian.noc.dfn.de) Received: (from schweikh@localhost) by obsidian.noc.dfn.de (8.9.3/8.9.3) id NAA06530 for freebsd-scsi@FreeBSD.ORG; Mon, 26 Jun 2000 13:37:09 +0200 (MET DST) Message-ID: <20000626133709.C27420@obsidian.noc.dfn.de> Date: Mon, 26 Jun 2000 13:37:09 +0200 From: Jens Schweikhardt To: freebsd-scsi@FreeBSD.ORG Subject: Termination question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org hello, world\n just a quick question if my understanding is right: I've got an ASUS P2L97-S mobo with on-board SCSI. It has both 50 and 68 pin connectors and I'm having at least one device on each of them. I have terminated the last device on the 50 pin cable, put an active terminator plug at the end of the 68 pin cable and disabled termination of the host adapter. Everything works so far, but I want to be sure that's the Right Thing (TM). Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 26 14:17:14 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from cicero2.cybercity.dk (cicero2.cybercity.dk [212.242.40.53]) by hub.freebsd.org (Postfix) with ESMTP id 5E73437BD5D for ; Mon, 26 Jun 2000 14:17:01 -0700 (PDT) (envelope-from john@hertell.nu) Received: from usr00.netlink.se (usr00.netlink.se [212.242.41.186]) by cicero2.cybercity.dk (8.9.3/8.9.3) with ESMTP id XAA09464 for ; Mon, 26 Jun 2000 23:10:39 +0200 (CEST) Received: from hertell.nu (IDENT:chucky@cvx-sto-1-1087.ppp.netlink.se [212.242.106.223]) by usr00.netlink.se (8.9.3/8.9.3) with ESMTP id XAA59692 for ; Mon, 26 Jun 2000 23:10:38 +0200 (CEST) (envelope-from john@hertell.nu) Message-ID: <3957C694.7FE3FDC@hertell.nu> Date: Mon, 26 Jun 2000 23:09:40 +0200 From: John Hertell X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdksmp i686) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: mlx problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a Mylex DAC 960 with Firmware V2.73. I have upgraded the mlx driver,made a new kernel. now when the kernel boots it detects my mylex but I get an error: Jun 26 21:35:22 freebsd /kernel: mlx0: port 0x9100-0x917f irq 11 at device 16.0 on pci0 Jun 26 21:35:22 freebsd /kernel: mlx0: couldn't allocate mailbox window Jun 26 21:35:22 freebsd /kernel: device_probe_and_attach: mlx0 attach returned 6 Whats wrong and how to fix it? newbe when it comes to FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 26 19:19:50 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (ppp-171.dialup.clari.net.au [203.57.253.171]) by hub.freebsd.org (Postfix) with ESMTP id 49DE037B6AA for ; Mon, 26 Jun 2000 19:19:46 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id TAA01180; Mon, 26 Jun 2000 19:25:29 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200006270225.TAA01180@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: John Hertell Cc: freebsd-scsi@freebsd.org Subject: Re: mlx problem In-reply-to: Your message of "Mon, 26 Jun 2000 23:09:40 +0200." <3957C694.7FE3FDC@hertell.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Jun 2000 19:25:28 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I have a Mylex DAC 960 with Firmware V2.73. > > I have upgraded the mlx driver,made a new kernel. now when the kernel > boots it detects my mylex > but I get an error: > > Jun 26 21:35:22 freebsd /kernel: mlx0: > port 0x9100-0x917f irq 11 at device 16.0 on pci0 > Jun 26 21:35:22 freebsd /kernel: mlx0: couldn't allocate mailbox window > Jun 26 21:35:22 freebsd /kernel: device_probe_and_attach: mlx0 attach > returned 6 > > Whats wrong and how to fix it? newbe when it comes to FreeBSD Your BIOS is only assigning an I/O range to the card and not a memory range. The driver doesn't support using I/O space to talk to the card at this time, sorry. -- \\ 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 Mon Jun 26 22:23:55 2000 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 8A2EF37BDD5 for ; Mon, 26 Jun 2000 22:23:46 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id XAA36553; Mon, 26 Jun 2000 23:23:36 -0600 (MDT) (envelope-from ken) Date: Mon, 26 Jun 2000 23:23:36 -0600 From: "Kenneth D. Merry" To: Gustavo Vieira Goncalves Coelho Rios Cc: scsi@FreeBSD.ORG Subject: Re: modifying scsi device param! Message-ID: <20000626232336.A36275@panzer.kdm.org> References: <39541CED.DBFBF2F5@tdnet.com.br> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39541CED.DBFBF2F5@tdnet.com.br>; from kernel@tdnet.com.br on Sat, Jun 24, 2000 at 02:29:01AM +0000 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jun 24, 2000 at 02:29:01 +0000, Gustavo Vieira Goncalves Coelho Rios wrote: > I am trying to switch some parameters, but what i do get is nothing > updated, look: > > etosha# camcontrol negotiate -n da -u 0 -T enable -ac > Current Parameters: > (pass0:ahc0:0:6:0): sync parameter: 12 > (pass0:ahc0:0:6:0): frequency: 20.000MHz > (pass0:ahc0:0:6:0): offset: 8 > (pass0:ahc0:0:6:0): bus width: 16 bits > (pass0:ahc0:0:6:0): disconnection is disabled > (pass0:ahc0:0:6:0): tagged queueing is disabled > New Parameters: > (pass0:ahc0:0:6:0): sync parameter: 12 > (pass0:ahc0:0:6:0): frequency: 20.000MHz > (pass0:ahc0:0:6:0): offset: 8 > (pass0:ahc0:0:6:0): bus width: 16 bits > (pass0:ahc0:0:6:0): disconnection is disabled > (pass0:ahc0:0:6:0): tagged queueing is disabled > > I tried to get tag queueing enabled, but could not. Hmm, it works okay here under -current: {vladivostok:/usr/home/ken:8:0} camcontrol negotiate da1 -T disable -ac Current Parameters: (pass1:ahc1:0:1:0): sync parameter: 12 (pass1:ahc1:0:1:0): frequency: 20.000MHz (pass1:ahc1:0:1:0): offset: 15 (pass1:ahc1:0:1:0): bus width: 8 bits (pass1:ahc1:0:1:0): disconnection is enabled (pass1:ahc1:0:1:0): tagged queueing is enabled New Parameters: (pass1:ahc1:0:1:0): sync parameter: 12 (pass1:ahc1:0:1:0): frequency: 20.000MHz (pass1:ahc1:0:1:0): offset: 15 (pass1:ahc1:0:1:0): bus width: 8 bits (pass1:ahc1:0:1:0): disconnection is enabled (pass1:ahc1:0:1:0): tagged queueing is disabled I can see several possible reasons why you can't enable tagged queueing, but the most likely is because you've disabled disconnection. You can't do tagged queueing without enabling disconnection. > Another thing, look the output of the following command: > > etosha# camcontrol inquiry -n da -u 0 > pass0: Fixed Direct Access SCSI-2 device > pass0: Serial Number 199910440080 > pass0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged > Queueing Enabled > > Question: How can Tag queueing being enabled here and the first command > show as not being enabled! Well, this is because the information that camcontrol uses in its inquiry subcommand to determine whether or not tagged queueing is enabled is derived from the cached inquiry data in the kernel. That cached inquiry data indicates the actual capabilities of the drive, which can do tagged queueing. Tagged queueing is actually disabled, though, as the 'negotiate' subcommand shows. So try the attached patch for src/sbin/camcontrol/camcontrol.c. It should make 'camcontrol inquiry' report the correct information. The patch is against -current, but it will likely apply to whatever version of FreeBSD you are running. (If not, the changes should be pretty obvious.) Ken -- Kenneth Merry ken@kdm.org --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="camcontrol.c.inquiry.20000626" ==== //depot/FreeBSD-ken/src/sbin/camcontrol/camcontrol.c#12 - /a/ken/perforce/FreeBSD-ken/src/sbin/camcontrol/camcontrol.c ==== *** /tmp/tmp.36518.0 Mon Jun 26 23:20:33 2000 --- /a/ken/perforce/FreeBSD-ken/src/sbin/camcontrol/camcontrol.c Mon Jun 26 23:17:47 2000 *************** *** 932,938 **** fprintf(stdout, ")"); } ! if (device->inq_data.flags & SID_CmdQue) fprintf(stdout, ", Tagged Queueing Enabled"); fprintf(stdout, "\n"); --- 932,939 ---- fprintf(stdout, ")"); } ! if (((ccb->cts.valid & CCB_TRANS_TQ_VALID) != 0) ! && (ccb->cts.flags & CCB_TRANS_TAG_ENB)) fprintf(stdout, ", Tagged Queueing Enabled"); fprintf(stdout, "\n"); --/04w6evG8XlLl3ft-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 26 22:45:54 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from dastor.albury.net.au (dastor.albury.NET.AU [203.15.244.203]) by hub.freebsd.org (Postfix) with ESMTP id EEC2637BDEE for ; Mon, 26 Jun 2000 22:45:50 -0700 (PDT) (envelope-from nicks@dastor.albury.net.au) Received: (from nicks@localhost) by dastor.albury.net.au (8.10.2/8.10.2) id e5R5jaM35821; Tue, 27 Jun 2000 15:45:36 +1000 (EST) Date: Tue, 27 Jun 2000 15:45:36 +1000 From: Nick Slager To: Don Lewis Cc: scsi@FreeBSD.ORG Subject: Re: Invalidating pack messages Message-ID: <20000627154536.A35696@albury.net.au> References: <20000620172810.A84355@albury.net.au> <200006200754.AAA28201@salsa.gv.tsc.tdk.com> <20000621143609.A3012@albury.net.au> <200006220729.AAA07327@salsa.gv.tsc.tdk.com> <20000623173844.A51332@albury.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000623173844.A51332@albury.net.au>; from nicks@albury.net.au on Fri, Jun 23, 2000 at 05:38:44PM +1000 X-Homer: Whoohooooooo! Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thus spake Nick Slager (nicks@albury.net.au): > Thus spake Don Lewis (Don.Lewis@tsc.tdk.com): > > > If your seeing funny blinking lights on the drive, and you are not the only > > person having problems with this particular drive model, I would be very > > suspicious that a drive firmware bug is being tickled. The best solution > > in this case would be to obtain a better version of the firmware from the > > vendor, but lacking that you might try turning off tagged command queueing > > or just reducing the number of tagged openings. I've noticed interactions > > between tagged command queueing and write caching on Seagate drives, so you > > might try turning off write caching and leaving the number of tagged > > openings alone. You can do all this with camcontrol. > > This morning I disabled write back caching in the SCSI BIOS, and the machine > has been copying files here and there for ~7 hours now with no problems at > all. As you say the performance difference is pretty much negligible. > > I'm going to leave the machine copying and rm'ing files all weekend to make > sure this all is OK, but at this stage it appears disabling write caching has > fixed the problem (or at least worked around it). The machine ran fine for ~2.5 days without a problem. Just to confirm that the problem had been isolated, I turned write caching back on this morning, expecting the box to die again. It steadfastly refuses to die In any case, it would appear there is something odd going on that involves write caching. I will turn write caching off again, do a 'make world', and hopefully the confidence factor will start to rise :-) Regards, Nick. -- From a Sun Microsystems bug report (#4102680): "Workaround: don't pound on the mouse like a wild monkey." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 26 22:55:36 2000 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 41B6637BDEE for ; Mon, 26 Jun 2000 22:55:33 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id XAA36880; Mon, 26 Jun 2000 23:55:23 -0600 (MDT) (envelope-from ken) Date: Mon, 26 Jun 2000 23:55:23 -0600 From: "Kenneth D. Merry" To: Jens Schweikhardt Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Termination question Message-ID: <20000626235523.A36809@panzer.kdm.org> References: <20000626133709.C27420@obsidian.noc.dfn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000626133709.C27420@obsidian.noc.dfn.de>; from schweikh@noc.dfn.de on Mon, Jun 26, 2000 at 01:37:09PM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jun 26, 2000 at 13:37:09 +0200, Jens Schweikhardt wrote: > > hello, world\n > > just a quick question if my understanding is right: I've got an ASUS > P2L97-S mobo with on-board SCSI. It has both 50 and 68 pin connectors > and I'm having at least one device on each of them. I have terminated > the last device on the 50 pin cable, put an active terminator plug at > the end of the 68 pin cable and disabled termination of the host > adapter. Everything works so far, but I want to be sure that's the Right > Thing (TM). Actually, you probably want to enable high-byte termination if the onboard SCSI BIOS has that option. The reason is that you've got the lower 8 data bits terminated at both ends of the bus, which is correct, but you only have the upper 8 bits terminated on the end with the active terminator. You'll want to terminate the upper 8 bits on the adapter as well, since they don't pass through to the end of the 50-pin cable. 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 Jun 27 16:37:42 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from wat-border.sentex.ca (waterloo-hespler.sentex.ca [199.212.135.66]) by hub.freebsd.org (Postfix) with ESMTP id D9B8737C3CA for ; Tue, 27 Jun 2000 16:36:21 -0700 (PDT) (envelope-from mike@sentex.net) Received: from granite.sentex.net (granite-atm.sentex.ca [209.112.4.1]) by wat-border.sentex.ca (8.9.3/8.9.3) with ESMTP id TAA12105; Tue, 27 Jun 2000 19:36:19 -0400 (EDT) (envelope-from mike@sentex.net) Received: from chimp.simianscience.com (cage.simianscience.com [64.7.134.1]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id TAA05457; Tue, 27 Jun 2000 19:36:18 -0400 (EDT) From: mike@sentex.net (Mike Tancsa) To: john@hertell.nu (John Hertell) Cc: freebsd-scsi@freebsd.org Subject: Re: mlx problem Date: Tue, 27 Jun 2000 23:31:52 GMT Message-ID: <39593930.269683985@mail.sentex.net> References: In-Reply-To: X-Mailer: Forte Agent .99e/32.227 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 26 Jun 2000 17:18:57 -0400, in sentex.lists.freebsd.misc you wrote: >I have a Mylex DAC 960 with Firmware V2.73. > >I have upgraded the mlx driver,made a new kernel. now when the kernel >boots it detects my mylex >but I get an error: > >Jun 26 21:35:22 freebsd /kernel: mlx0: >port 0x9100-0x917f irq 11 at device 16.0 on pci0 >Jun 26 21:35:22 freebsd /kernel: mlx0: couldn't allocate mailbox window >Jun 26 21:35:22 freebsd /kernel: device_probe_and_attach: mlx0 attach >returned 6 > > >Whats wrong and how to fix it? newbe when it comes to FreeBSD I thought that version of the Mylex BIOS did not work ? Do a quick search through the archives to make sure, but I recall something special about that firmware version. ---Mike Mike Tancsa (mdtancsa@sentex.net) Sentex Communications Corp, Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers could setup a national IP network." (KDW2) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 27 19:34:40 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from fanying.fynet.com (fanying.fy-net.com [208.51.149.66]) by hub.freebsd.org (Postfix) with ESMTP id E238F37C50F for ; Tue, 27 Jun 2000 19:34:34 -0700 (PDT) (envelope-from fanying@fynet.com) Received: from localhost (fanying@localhost) by fanying.fynet.com (8.9.3/8.9.3) with ESMTP id WAA12517 for ; Tue, 27 Jun 2000 22:39:31 -0400 Date: Tue, 27 Jun 2000 22:39:30 -0400 (EDT) From: Fanying Jen To: freebsd-scsi@freebsd.org Subject: DPT RAID and FreeBSD 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 Does FreeBSD now contain robust support for the DPT SmartRAID V and SmartRAID VI? ------------------------------------------------------------------ Fanying Jen (Network Administrator) Email: fanying@fynet.com fanying@fy-net.com fanying@fanying.com fanying@fanying.fynet.com fanying@fanying.fy-net.com fanying@fanying.fanying.com Ham Radio: KC2FRL (Tech No-Code) Pgp Key: http://www.fynet.com/fanying/pgpkey.html Forsale: http://www.fynet.com/fanying/forsale.html The Fanying Jen Network http://www.fy-net.com/ http://www.fynet.com/ ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 27 21:33:33 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from postoffice.aims.com.au (advanc2.lnk.telstra.net [139.130.119.73]) by hub.freebsd.org (Postfix) with ESMTP id 60FA237BA7C for ; Tue, 27 Jun 2000 21:33:24 -0700 (PDT) (envelope-from chris@aims.com.au) Received: from postoffice.aims.com.au (nts-ts1.aims.private [192.168.10.2]) by postoffice.aims.com.au with ESMTP id OAA64343 for ; Wed, 28 Jun 2000 14:33:21 +1000 (EST) (envelope-from chris@aims.com.au) Received: from ntsts1 by aims.com.au with SMTP (MDaemon.v3.0.3.R) for ; Wed, 28 Jun 2000 14:33:23 +1000 Reply-To: From: "Chris Knight" To: Subject: RE: DPT RAID and FreeBSD Date: Wed, 28 Jun 2000 14:33:21 +1000 Message-ID: <001501bfe0b9$fe496e20$020aa8c0@aims.private> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal X-MDaemon-Deliver-To: freebsd-scsi@FreeBSD.ORG X-Return-Path: chris@aims.com.au X-MDRcpt-To: freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Howdy, Depends what you mean by robust. An I2O driver is available from ftp://simon-shapiro.org as patches to 3-STABLE in /crash/patches, or as a distribution in /FreeBSD. However, I get kernel panics when I try running the SmartRAID card in an Intel Lancewood server. Alternatively, you can pester techsupport@dpt.com for the pre-release driver for FreeBSD 2.2.8. It works like a charm, and we've got it running in production environments. Hope this helps. Regards, Chris Knight Systems Administrator AIMS Independent Computer Professionals Tel: +61 3 6334 6664 Fax: +61 3 6331 7032 Mob: +61 419 528 795 Web: http://www.aims.com.au > -----Original Message----- > From: owner-freebsd-scsi@FreeBSD.ORG > [mailto:owner-freebsd-scsi@FreeBSD.ORG]On Behalf Of Fanying Jen > Sent: Wednesday, 28 June 2000 12:40 > To: freebsd-scsi@FreeBSD.ORG > Subject: DPT RAID and FreeBSD > > > Does FreeBSD now contain robust support for the DPT SmartRAID V and > SmartRAID VI? > > ------------------------------------------------------------------ > Fanying Jen (Network Administrator) > Email: fanying@fynet.com > fanying@fy-net.com > fanying@fanying.com > fanying@fanying.fynet.com > fanying@fanying.fy-net.com > fanying@fanying.fanying.com > > Ham Radio: KC2FRL (Tech No-Code) > > Pgp Key: http://www.fynet.com/fanying/pgpkey.html > Forsale: http://www.fynet.com/fanying/forsale.html > > The Fanying Jen Network > http://www.fy-net.com/ > http://www.fynet.com/ > ------------------------------------------------------------------ > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 28 0:19:13 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from viper.dmpriest.com (viper.dmpriest.com [195.188.177.3]) by hub.freebsd.org (Postfix) with ESMTP id 69E1837BB44 for ; Wed, 28 Jun 2000 00:19:09 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca.tdx.co.uk [195.188.177.195]) by viper.dmpriest.com (8.9.3/8.9.3/Kp) with ESMTP id IAA70792; Wed, 28 Jun 2000 08:18:58 +0100 (BST) Message-ID: <3959A6E1.3585BE36@tdx.co.uk> Date: Wed, 28 Jun 2000 08:18:57 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fanying Jen Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: DPT RAID and FreeBSD References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Fanying Jen wrote: > > Does FreeBSD now contain robust support for the DPT SmartRAID V and > SmartRAID VI? Simon Shapiro has working drivers for the SmartRAID V's. I believe the same drivers work on the SmartRAID VI's (as they are also i2o 'engines'). You can get these from his website at http://www.simon-shapiro.org We're using them extensively now, both on development and 'non-critical' production machines. We've had no problems whatsoever so far :) If you use them, make sure you apply his latest set of patches 20000514. If you get stuck, mail me off-list - like I said, we've got quite a few of these now :) -Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 28 1: 5: 6 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp.www-service.de (smtp.www-service.de [212.77.161.16]) by hub.freebsd.org (Postfix) with SMTP id 0CCDB37B530 for ; Wed, 28 Jun 2000 01:05:01 -0700 (PDT) (envelope-from thz@Lennartz-electronic.de) Received: (qmail 14539 invoked from network); 28 Jun 2000 08:04:42 -0000 Received: from p3e9e1340.dip.t-dialin.net (HELO fw.tue.le) (62.158.19.64) by smtp.www-service.de with SMTP; 28 Jun 2000 08:04:42 -0000 Received: from mezcal.tue.le (mezcal.tue.le [192.168.201.20]) by fw.tue.le (8.8.8/8.8.8) with ESMTP id KAA17325; Wed, 28 Jun 2000 10:03:29 +0200 (CEST) (envelope-from thz@mezcal.tue.le) Received: (from thz@localhost) by mezcal.tue.le (8.9.3/8.9.3) id KAA00921; Wed, 28 Jun 2000 10:03:29 +0200 (CEST) (envelope-from thz) Date: Wed, 28 Jun 2000 10:03:29 +0200 From: Thomas Zenker To: scsi@FreeBSD.ORG Cc: Nick Slager Subject: Re: Invalidating pack messages Message-ID: <20000628100329.A867@mezcal.tue.le> References: <20000620172810.A84355@albury.net.au> <200006200754.AAA28201@salsa.gv.tsc.tdk.com> <20000621143609.A3012@albury.net.au> <200006220729.AAA07327@salsa.gv.tsc.tdk.com> <20000623173844.A51332@albury.net.au> <20000627154536.A35696@albury.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000627154536.A35696@albury.net.au>; from nicks@albury.net.au on Tue, Jun 27, 2000 at 03:45:36PM +1000 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jun 27, 2000 at 03:45:36PM +1000, Nick Slager wrote: > Thus spake Nick Slager (nicks@albury.net.au): > > > Thus spake Don Lewis (Don.Lewis@tsc.tdk.com): > > > > > If your seeing funny blinking lights on the drive, and you are not the only > > > person having problems with this particular drive model, I would be very > > > suspicious that a drive firmware bug is being tickled. The best solution > > > in this case would be to obtain a better version of the firmware from the > > > vendor, but lacking that you might try turning off tagged command queueing > > > or just reducing the number of tagged openings. I've noticed interactions > > > between tagged command queueing and write caching on Seagate drives, so you > > > might try turning off write caching and leaving the number of tagged > > > openings alone. You can do all this with camcontrol. > > > > This morning I disabled write back caching in the SCSI BIOS, and the machine > > has been copying files here and there for ~7 hours now with no problems at > > all. As you say the performance difference is pretty much negligible. > > > > I'm going to leave the machine copying and rm'ing files all weekend to make > > sure this all is OK, but at this stage it appears disabling write caching has > > fixed the problem (or at least worked around it). > > The machine ran fine for ~2.5 days without a problem. > > Just to confirm that the problem had been isolated, I turned write caching > back on this morning, expecting the box to die again. It steadfastly refuses > to die > > In any case, it would appear there is something odd going on that involves > write caching. I will turn write caching off again, do a 'make world', and > hopefully the confidence factor will start to rise :-) Hi, having at least the same symptoms like you, I could isolate the problem here to tagged queuing + heavy writes. It never happens for reading only, seeks etc. So I can read the whole disk (9G) to /dev/null without problems, but writing a big file with iozone or dd failes very quickly. I could eliminate the problem by switching of tagged queuing, with bad performance loss (write cache is turned off, bad this didn't help very much), but it survives buildworlds and writes of 6G files. best regards, -- Thomas Zenker c/o Lennartz electronic GmbH Bismarckstrasse 136, D-72072 Tuebingen, Germany Phone: +49-(0)7071-93550 Email: thz@lennartz-electronic.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 28 5:44:33 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from dastor.albury.net.au (dastor.albury.NET.AU [203.15.244.203]) by hub.freebsd.org (Postfix) with ESMTP id DD7CC37B597 for ; Wed, 28 Jun 2000 05:44:23 -0700 (PDT) (envelope-from nicks@dastor.albury.net.au) Received: (from nicks@localhost) by dastor.albury.net.au (8.10.2/8.10.2) id e5SCi9q63692; Wed, 28 Jun 2000 22:44:09 +1000 (EST) Date: Wed, 28 Jun 2000 22:44:08 +1000 From: Nick Slager To: Thomas Zenker Cc: scsi@FreeBSD.ORG Subject: Re: Invalidating pack messages Message-ID: <20000628224408.A63626@albury.net.au> References: <20000620172810.A84355@albury.net.au> <200006200754.AAA28201@salsa.gv.tsc.tdk.com> <20000621143609.A3012@albury.net.au> <200006220729.AAA07327@salsa.gv.tsc.tdk.com> <20000623173844.A51332@albury.net.au> <20000627154536.A35696@albury.net.au> <20000628100329.A867@mezcal.tue.le> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000628100329.A867@mezcal.tue.le>; from thz@Lennartz-electronic.de on Wed, Jun 28, 2000 at 10:03:29AM +0200 X-Homer: Whoohooooooo! Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thus spake Thomas Zenker (thz@Lennartz-electronic.de): > On Tue, Jun 27, 2000 at 03:45:36PM +1000, Nick Slager wrote: > > In any case, it would appear there is something odd going on that involves > > write caching. I will turn write caching off again, do a 'make world', and > > hopefully the confidence factor will start to rise :-) > > Hi, having at least the same symptoms like you, I could isolate > the problem here to tagged queuing + heavy writes. It never happens > for reading only, seeks etc. So I can read the whole disk (9G) to > /dev/null without problems, but writing a big file with iozone or > dd failes very quickly. I could eliminate the problem by switching of > tagged queuing, with bad performance loss (write cache is turned off, bad > this didn't help very much), but it survives buildworlds and writes of 6G files. So far, I can't kill the thing with write caching disabled. That also has the least performance hit, so until it fails, I can live with it :-) Regards, Nick. -- From a Sun Microsystems bug report (#4102680): "Workaround: don't pound on the mouse like a wild monkey." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 28 8:24:15 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from pegasus.freibergnet.de (pegasus.freibergnet.de [194.123.255.9]) by hub.freebsd.org (Postfix) with ESMTP id C377437B9EB for ; Wed, 28 Jun 2000 08:24:08 -0700 (PDT) (envelope-from holm@pegasus.freibergnet.de) Received: (from holm@localhost) by pegasus.freibergnet.de (8.9.3/8.9.1) id RAA95020 for freebsd-scsi@freebsd.org; Wed, 28 Jun 2000 17:24:06 +0200 (CEST) (envelope-from holm) Date: Wed, 28 Jun 2000 17:24:06 +0200 From: Holm Tiffe To: freebsd-scsi@freebsd.org Subject: BDR with Quantum VIKING (I) Message-ID: <20000628172406.A94663@pegasus.freibergnet.de> Reply-To: holm@freibergnet.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95i Organization: FreibergNet Internet Services X-Phone: +49-3731-781279 X-Fax: +49-3731-781377 X-PGP-fingerprint: 86 EC A5 63 B5 28 78 13 8B FC E9 09 04 6E 86 FC Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, yesterday I've upgraded my old dual Pentium/100 to an Athlon 750 and this old Quantum disk makes me some trouble. Here the dmesg output: Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Tue Jun 27 18:28:45 MET DST 2000 holm@unicorn.pppnet.tu-freiberg.de:/usr1/src/sys/compile/UNICORN Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 751708632 Hz CPU: AMD Athlon(tm) Processor (751.71-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x622 Stepping = 2 Features=0x183f9ff AMD Features=0xc0400000 real memory = 134152192 (131008K bytes) avail memory = 127209472 (124228K bytes) Preloaded elf kernel "kernel" at 0xc0343000. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at 7.1 pci0: at 7.2 irq 11 pci0: at 7.3 irq 11 chip1: at device 7.4 on pci0 sym0: <875> port 0xd800-0xd8ff mem 0xdfffa000-0xdfffafff,0xdfffbf00-0xdfffbfff i rq 10 at device 9.0 on pci0 sym0: Tekram NVRAM, ID 7, Fast-20, SE, parity checking de0: port 0xcc00-0xcc7f mem 0xdfffbe80-0xdfffbeff irq 1 0 at device 13.0 on pci0 de0: Cogent 21040 [10Mb/s] pass 2.3 de0: address 00:00:92:90:09:8d pcm0: port 0xc800-0xc83f irq 9 at device 14.0 on pci0 pci0: at 15.0 irq 11 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A dgb0: PC/Xe 64K dgb0 at port 0x300-0x303 iomem 0xd0000-0xdffff on isa0 dgb0: 8 ports dgb0: driver is using old-style compatability shims ppc0: This ppc chipset does not support the extended I/O port range...no problem ppc0: at port 0x378-0x37b irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold pps0: on ppbus0 ppi0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port unknown0: at iomem 0-0x9fbff,0x9fc00-0x9ffff,0xec000-0xeffff,0xf0000-0 xfffff,0x100000-0x7feffff,0x7ff0000-0x7ff7fff,0x7ff8000-0x7ffffff,0xffff0000-0xf fffffff on isa0 unknown: can't assign resources vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A dgb0: PC/Xe 64K dgb0 at port 0x300-0x303 iomem 0xd0000-0xdffff on isa0 dgb0: 8 ports dgb0: driver is using old-style compatability shims ppc0: This ppc chipset does not support the extended I/O port range...no problem ppc0: at port 0x378-0x37b irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold pps0: on ppbus0 ppi0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port unknown0: at iomem 0-0x9fbff,0x9fc00-0x9ffff,0xec000-0xeffff,0xf0000-0 xfffff,0x100000-0x7feffff,0x7ff0000-0x7ff7fff,0x7ff8000-0x7ffffff,0xffff0000-0xf fffffff on isa0 unknown: can't assign resources unknown1: at port 0-0xf,0x80-0x90,0x94-0x9f,0xc0-0xde drq 4 on isa0 unknown2: at port 0x40-0x43 irq 0 on isa0 unknown3: at port 0x70-0x71 irq 8 on isa0 unknown: can't assign resources unknown4: at port 0x61 on isa0 npxisa0: at port 0xf0-0xff irq 13 on isa0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown5: at port 0x22,0x72-0x75,0x400-0x40f,0x4d0-0x4d1,0xcf8-0xcff,0 x800-0x87f,0xc00-0xc7f on isa0 unknown: can't assign resources de0: enabling AUI/BNC port Waiting 2 seconds for SCSI devices to settle sa0 at sym0 bus 0 target 3 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 4.807MB/s transfers (4.807MHz, offset 8) Mounting root from ufs:/dev/da1a da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-CCS device da0: 3.968MB/s transfers (3.968MHz, offset 8) da0: 203MB (415872 512 byte sectors: 64H 32S/T 203C) da4 at sym0 bus 0 target 6 lun 0 da4: Fixed Direct Access SCSI-2 device da4: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da4: 4345MB (8899737 512 byte sectors: 255H 63S/T 553C) da2 at sym0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da2: 1910MB (3912172 512 byte sectors: 255H 63S/T 243C) da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 2033MB (4165272 512 byte sectors: 255H 63S/T 259C) cd0 at sym0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present da3 at sym0 bus 0 target 5 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da3: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) After some heavy disk activity the scsi bus stops working and after an timeout the console prints this: (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. and the machine is working again for a while. I have now disabled tagged queueing for this device and an parrallel cvs update for ports and src seems to work without any stops now. (the cvs three is on this device) I know, those Quantum disks are basicaly crap, but is there a known workaround to get those working with tagged queueing ? (I've got this drive for free) The disk seems to have the latest firmware revision from Quantum (880R). The controller is an Tekram DC390 Wide SCSI and booth the se und the wide connectors are used. Does anyone know how stable the autotermination on those controllers works ? I can't therminate the upper 8 bits manually by jumpers or in the bios settings. The OS is an 5.0-current from June 2 2000, cvs update is running currently... Holm -- FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development Systemhaus für Daten- und Netzwerktechnik phone +49 3731 781279 Unternehmensgruppe Liebscher & Partner fax +49 3731 781377 D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 28 13:56:52 2000 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 2E8C237BCE8 for ; Wed, 28 Jun 2000 13:56:42 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from Guyancourt-1-253.club-internet.fr (Guyancourt-1-253.club-internet.fr [195.36.205.253]) by front4m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA17759; Wed, 28 Jun 2000 22:52:16 +0200 (MET DST) Date: Wed, 28 Jun 2000 22:34:52 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Holm Tiffe Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: BDR with Quantum VIKING (I) In-Reply-To: <20000628172406.A94663@pegasus.freibergnet.de> 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, 28 Jun 2000, Holm Tiffe wrote: > Hi, >=20 > yesterday I've upgraded my old dual Pentium/100 to an Athlon 750 > and this old Quantum disk makes me some trouble. >=20 > Here the dmesg output: [ ... ] > sa0 at sym0 bus 0 target 3 lun 0 > sa0: Removable Sequential Access SCSI-2 device= =20 > sa0: 4.807MB/s transfers (4.807MHz, offset 8) > Mounting root from ufs:/dev/da1a > da0 at sym0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-CCS device= =20 > da0: 3.968MB/s transfers (3.968MHz, offset 8) > da0: 203MB (415872 512 byte sectors: 64H 32S/T 203C) > da4 at sym0 bus 0 target 6 lun 0 > da4: Fixed Direct Access SCSI-2 device=20 > da4: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing = Enabled > da4: 4345MB (8899737 512 byte sectors: 255H 63S/T 553C) > da2 at sym0 bus 0 target 2 lun 0 > da2: Fixed Direct Access SCSI-2 device=20 > da2: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled > da2: 1910MB (3912172 512 byte sectors: 255H 63S/T 243C) > da1 at sym0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device=20 > da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled > da1: 2033MB (4165272 512 byte sectors: 255H 63S/T 259C) > cd0 at sym0 bus 0 target 4 lun 0 > cd0: Removable CD-ROM SCSI-2 device=20 > cd0: 4.237MB/s transfers (4.237MHz, offset 16) > cd0: Attempt to query device size failed: NOT READY, Medium not present > da3 at sym0 bus 0 target 5 lun 0 > da3: Fixed Direct Access SCSI-2 device=20 > da3: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > da3: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) >=20 >=20 > After some heavy disk activity the scsi bus stops working and after an > timeout the console prints this: >=20 > (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. >=20 > and the machine is working again for a while. The driver messages are sometimes too verbose and sometimes too sparse. The latter probably applied here.:) Given your description, it seems that for some reason the SCSI BUS hung up. There are numerous reasons for this to happen. A device, for example, can hang while it owns the BUS for obscure reasons. When a SCSI IO times out, the driver first tries to synchronize with the SCSI SCRIPTS and if it succeeds within less than 10 seconds, it will try to send a ABORT (or ABORT TAG if command is tagged) message to the device. If the new delay of 10 seconds also expires without the abort to have occurred, then the driver resets BUS, chip and SCRIPTS, and requeue all the commands to CAM. (All that with quite sparse messaging by default. :-) ) By the way, I maintain some slightly broken hardwares and firmwares in by box, in order to check error recovery. I notably use a FAST-40 BUS with a dubious cable that locks or experiences a SCSI ERROR every 3 to 5 minutes when stressed with IOs and gives errors from time to time when used normally (btw using another cable fixes the problem). I never saw a single bit having been lost from the 2 disks plugged on this BUS (Cheetah + DRVS) that contains also some useful data (but not critical:) ). > I have now disabled tagged queueing for this device and an parrallel cvs = update > for ports and src seems to work without any stops now. (the cvs three is = on this > device) >=20 > I know, those Quantum disks are basicaly crap, but is there a known worka= round > to get those working with tagged queueing ? (I've got this drive for free= ) I donnot know about the VIKING (I?), but I have a VIKING II LVD that works fine for me with tagged command queuing. The drive accepts up to 63 tagged commands simultaneously without whining about QUEUE FULL as ATLASes in a unpredicable way. Note that the ATLASes are a lot more silent= =20 about QUEUE FULL when write-caching is disabled. > The disk seems to have the latest firmware revision from Quantum (880R). > The controller is an Tekram DC390 Wide SCSI and booth the se und the > wide connectors are used. But the drive seems to use SCA connector and I heard that some SCA->68 converters can make problems, especially with SYMBIOS chips. This should be investigated, in my opinion. > Does anyone know how stable the autotermination on those controllers work= s ? The auto-termination of the Tekram boards never has been reported to me to make problems and seems to be quite smart. > I can't therminate the upper 8 bits manually by jumpers or in the bios se= ttings. IMO, Unless it is broken, the Tekram board should have detected that the narrow part of the BUS is also used and have properly terminated the upper BUS lines at the controller. > The OS is an 5.0-current from June 2 2000, cvs update is running currentl= y... >=20 > Holm > --=20 > FreibergNet Systemhaus GbR Holm Tiffe * Administration, Development > Systemhaus f=FCr Daten- und Netzwerktechnik phone +49 3731 7812= 79 > Unternehmensgruppe Liebscher & Partner fax +49 3731 781377 > D-09599 Freiberg * Am St. Niclas Schacht 13 http://www.freibergnet.de/ 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 Jun 28 23: 7:52 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id 8A52837B86C for ; Wed, 28 Jun 2000 23:07:33 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e5T67VR04256 for ; Thu, 29 Jun 2000 08:07:31 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e5T67UN15728 for ; Thu, 29 Jun 2000 08:07:30 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.10.2/8.10.2) id e5T67Un00572 for freebsd-scsi@freebsd.org; Thu, 29 Jun 2000 08:07:30 +0200 (CEST) Date: Thu, 29 Jun 2000 08:07:30 +0200 From: Andre Albsmeier To: freebsd-scsi@freebsd.org Subject: Curiuos Problem with CAM and a 2940U2W with several devices Message-ID: <20000629080730.A66792@curry.mchp.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a really curious SCSI problem here and I think it is not CAM/FreeBSD related but I just want to be sure... This is an Adaptec 2940U2W controller. The external LVD connector is unused. The internal LVD connector has 2 IBM DNES-318350W LVD drives and a LVD terminator at the end of the cable. The LVD terminator of the 2940U2W is set to on. So the LVD segement is terminated properly. The 50-pin (8bit) single ended connector has a SEAGATE ST31230N drive and a PIONEER CD-ROM DR-766 1.00 cdrom drive attached to it. On the end of this cable is an active 50-pin SE terminator. The 68-pin (16bit) single ended connector has a IBM DDRS-34560W connected to it. On the end of this cable is an active 68-pin SE terminator. The SE terminator of the 2940U2W is set to LOW/Off and HIGH/On. So the SE segment is terminated properly. The cable lengths are below 1 meter. I have changed them. I have replaced the external terminators. I have set the 2940U2Ws terminators to automatic. I have lowered the transfer speeds for the SE devices. I have removed the CDROM. I still get these SCSI Error messages. I might think this is due to the old SEAGATE drive in there but I am not sure. When removing the DDRS-34560W and correcting the termination accordingly, the system ran fine for a long time. Now I just wanted to replace the SEAGATE drive with the bigger DDRS-34560W but as soon as I connect it to copy the stuff over, the problems start. Here is the dmesg with the relevant parts. Maybe someone (Ken ?!? :-)) can give me a hint about this. Thanks, -Andre 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.5-STABLE #8: Wed Jun 21 08:06:04 CEST 2000 root@bali.ofw.tld:/src/src-3/sys/compile/CURRY Calibrating clock(s) ... TSC clock: 463551935 Hz, i8254 clock: 1193183 Hz Timecounter "i8254" frequency 1193183 Hz Timecounter "TSC" frequency 463551935 Hz CPU: Pentium II/Pentium II Xeon/Celeron (463.55-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ff real memory = 402653184 (393216K bytes) ... ahc0: rev 0x00 int a irq 15 on pci0.9.0 ahc0: Reading SEEPROM...done. ahc0: Manual LVD Termination ahc0: BIOS eeprom is present ahc0: Secondary High byte termination Enabled ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc0: Downloading Sequencer Program... 399 instructions downloaded ... (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. (probe6:ahc0:0:6:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe6:ahc0:0:6:0): ILLEGAL REQUEST asc:24,0 (probe6:ahc0:0:6:0): Invalid field in CDB ahc0: target 6 synchronous at 20.0MHz, offset = 0x10 ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: target 1 using 16bit transfers ahc0: target 1 synchronous at 5.0MHz, offset = 0xf ahc0: target 2 using 16bit transfers ahc0: target 2 synchronous at 40.0MHz, offset = 0x1e ahc0: target 3 using 16bit transfers ahc0: target 3 synchronous at 40.0MHz, offset = 0x1e ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0: target 1 using 8bit transfers ahc0: target 1 using asynchronous transfers ahc0: target 2 using 8bit transfers ahc0: target 2 using asynchronous transfers ahc0: target 3 using 8bit transfers ahc0: target 3 using asynchronous transfers ahc0: target 6 using asynchronous transfers ahc0: target 3 using 16bit transfers ahc0: target 3 synchronous at 40.0MHz, offset = 0x1e ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_TCL == 0x6, ARG_1 == 0xff, SEQ_FLAGS == 0x0 ahc0:A:0: Target did not send an IDENTIFY message. LASTPHASE = 0x40, SAVED_TCL == 0x6 ahc0: target 0 using asynchronous transfers ahc0: target 3 using 8bit transfers ahc0: target 3 using asynchronous transfers ahc0: Issued Channel A Bus Reset. 0 SCBs aborted ahc0: target 3 using 16bit transfers ahc0: target 3 synchronous at 40.0MHz, offset = 0x1e ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0: target 3 using 8bit transfers ahc0: target 3 using asynchronous transfers ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_TCL == 0x0, ARG_1 == 0xff, SEQ_FLAGS == 0x0 pass0 at ahc0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number 00583991 pass0: 3.300MB/s transfers, Tagged Queueing Enabled pass1 at ahc0 bus 0 target 1 lun 0 pass1: Fixed Direct Access SCSI-2 device pass1: Serial Number RDH24915 pass1: 3.300MB/s transfers, Tagged Queueing Enabled pass2 at ahc0 bus 0 target 2 lun 0 pass2: Fixed Direct Access SCSI-3 device pass2: Serial Number AKG0E356 pass2: 3.300MB/s transfers, Tagged Queueing Enabled pass3 at ahc0 bus 0 target 3 lun 0 pass3: Fixed Direct Access SCSI-3 device pass3: Serial Number AKG08315 pass3: 3.300MB/s transfers, Tagged Queueing Enabled pass6 at ahc0 bus 0 target 6 lun 0 pass6: Removable CD-ROM SCSI-2 device pass6: 3.300MB/s transfers Considahc0: Bus Device Reset on A:0. 0 SCBs aborted ering FFS root f/s. changing root device to da0s1a ahc0: target 6 synchronous at 20.0MHz, offset = 0x10 (cd0:ahc0:0:6:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ahc0:0:6:0): NOT READY asc:3a,0 (cd0:ahc0:0:6:0): Medium not present cd0 at ahc0 bus 0 target 6 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 ahc0: target 1 using 16bit transfers ahc0: target 1 synchronous at 5.0MHz, offset = 0xf ahc0: target 1 using asynchronous transfers ahc0: target 1 synchronous at 5.0MHz, offset = 0xf ahc0: target 2 using 16bit transfers ahc0: target 2 synchronous at 40.0MHz, offset = 0x1e ahc0: target 2 using asynchronous transfers ahc0: target 2 synchronous at 40.0MHz, offset = 0x1e ahc0: target 3 using 16bit transfers ahc0: target 3 synchronous at 40.0MHz, offset = 0x1e ahc0: target 3 using asynchronous transfers ahc0: target 3 synchronous at 40.0MHz, offset = 0x1e ahc0: target 0 synchronous at 10.0MHz, offset = 0xf da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number 00583991 da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 1001MB (2051460 512 byte sectors: 64H 32S/T 1001C) da3 at ahc0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-3 device da3: Serial Number AKG08315 da3: 80.000MB/s transfers (40.000MHz, offset 30, 16bit), Tagged Queueing Enabled da3: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: Serial Number AKG0E356 da2: 80.000MB/s transfers (40.000MHz, offset 30, 16bit), Tagged Queueing Enabled da2: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da0s1: type 0xa5, start 0, end = 2051459, size 2051460 : OK da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: Serial Number RDH24915 da1: 10.000MB/s transfers (5.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) start_init: trying /sbin/init ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0: target 1 using 8bit transfers ahc0: target 1 using asynchronous transfers ahc0: target 2 using 8bit transfers ahc0: target 2 using asynchronous transfers ahc0: target 3 using 8bit transfers ahc0: target 3 using asynchronous transfers ahc0: target 6 using asynchronous transfers ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_TCL == 0x0, ARG_1 == 0xb, SEQ_FLAGS == 0x0 ahc0: Someone reset channel A ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_TCL == 0x0, ARG_1 == 0xe, SEQ_FLAGS == 0x0 ahc0: Bus Device Reset on A:0. 0 SCBs aborted ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_TCL == 0x0, ARG_1 == 0xe, SEQ_FLAGS == 0x0 ahc0: Bus Device Reset on A:0. 0 SCBs aborted ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers (da0:ahc0:0:0:0): SCB 0xe - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x44 (da0:ahc0:0:0:0): Queuing a BDR SCB (da0:ahc0:0:0:0): SCB 0xe - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x42 (da0:ahc0:0:0:0): no longer in timeout, status = 34b ahc0: Issued Channel A Bus Reset. 1 SCBs aborted ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_TCL == 0x0, ARG_1 == 0xe, SEQ_FLAGS == 0x0 ahc0: Bus Device Reset on A:0. 0 SCBs aborted ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_TCL == 0x0, ARG_1 == 0xe, SEQ_FLAGS == 0x0 ahc0: Someone reset channel A ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0:A:0: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_TCL == 0x0, ARG_1 == 0xe, SEQ_FLAGS == 0x0 ahc0: Bus Device Reset on A:0. 0 SCBs aborted ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: Someone reset channel A ahc0: target 0 using asynchronous transfers ahc0: target 0 synchronous at 10.0MHz, offset = 0xf To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 29 5: 9:15 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from web1904.mail.yahoo.com (web1904.mail.yahoo.com [128.11.23.53]) by hub.freebsd.org (Postfix) with SMTP id CC79837BB35 for ; Thu, 29 Jun 2000 05:09:11 -0700 (PDT) (envelope-from p_k_nandan@yahoo.com) Received: (qmail 22793 invoked by uid 60001); 29 Jun 2000 12:09:11 -0000 Message-ID: <20000629120911.22792.qmail@web1904.mail.yahoo.com> Received: from [203.197.180.208] by web1904.mail.yahoo.com; Thu, 29 Jun 2000 05:09:11 PDT Date: Thu, 29 Jun 2000 05:09:11 -0700 (PDT) From: "NandaKumar P.K." Subject: System panic with new HBA driver To: freebsd-scsi@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I am in the process of testing all the error conditions of my FreeBSD 3.4 driver for the HBA. I have 4 partitions on the Fibre Channel disk and a copy is done from one partition to other. Now if remove the disk when this is going on the firmware reports timeout error and i report back the CAM_CMD_TIMEOUT status. Now after sometime system comes with a sync cache command and i report the same status CAM_CMD_TIMEOUT for this command also. After this system panic. Is there any way to avoid this condition ? Since the disks are hot swapable this may be condition i can expect in the real situation. Regards, Nandan __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 29 11:53:22 2000 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 ADF6237C0B0 for ; Thu, 29 Jun 2000 11:53:13 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id MAA61227; Thu, 29 Jun 2000 12:53:05 -0600 (MDT) (envelope-from ken) Date: Thu, 29 Jun 2000 12:53:05 -0600 From: "Kenneth D. Merry" To: Andre Albsmeier Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Curiuos Problem with CAM and a 2940U2W with several devices Message-ID: <20000629125305.A61135@panzer.kdm.org> References: <20000629080730.A66792@curry.mchp.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000629080730.A66792@curry.mchp.siemens.de>; from andre.albsmeier@mchp.siemens.de on Thu, Jun 29, 2000 at 08:07:30AM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jun 29, 2000 at 08:07:30 +0200, Andre Albsmeier wrote: > I have a really curious SCSI problem here and I think it is not > CAM/FreeBSD related but I just want to be sure... > > This is an Adaptec 2940U2W controller. > > The external LVD connector is unused. The internal LVD connector > has 2 IBM DNES-318350W LVD drives and a LVD terminator at the end > of the cable. The LVD terminator of the 2940U2W is set to on. > So the LVD segement is terminated properly. > > The 50-pin (8bit) single ended connector has a SEAGATE ST31230N > drive and a PIONEER CD-ROM DR-766 1.00 cdrom drive attached to it. > On the end of this cable is an active 50-pin SE terminator. > The 68-pin (16bit) single ended connector has a IBM DDRS-34560W > connected to it. On the end of this cable is an active 68-pin SE > terminator. The SE terminator of the 2940U2W is set to LOW/Off > and HIGH/On. > So the SE segment is terminated properly. > > The cable lengths are below 1 meter. I have changed them. I have > replaced the external terminators. I have set the 2940U2Ws > terminators to automatic. I have lowered the transfer speeds for > the SE devices. I have removed the CDROM. > > I still get these SCSI Error messages. > > I might think this is due to the old SEAGATE drive in there but I > am not sure. When removing the DDRS-34560W and correcting the > termination accordingly, the system ran fine for a long time. Now I > just wanted to replace the SEAGATE drive with the bigger DDRS-34560W > but as soon as I connect it to copy the stuff over, the problems > start. > > Here is the dmesg with the relevant parts. > > Maybe someone (Ken ?!? :-)) can give me a hint about this. As far as I can tell, you've done all the normal things to isolate the problem. It could be a problem with the Seagate drive, since that is the drive the Adaptec driver is complaining about but I don't know what that problem is. This is probably something that Justin will need to look at. 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 Jun 29 23:26:48 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from goliath.siemens.de (goliath.siemens.de [194.138.37.131]) by hub.freebsd.org (Postfix) with ESMTP id 0674337B785 for ; Thu, 29 Jun 2000 23:26:42 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer goliath.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.10.1/8.10.1) with ESMTP id e5U6NBB01289; Fri, 30 Jun 2000 08:23:15 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e5U6NBn00369; Fri, 30 Jun 2000 08:23:11 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.10.2/8.10.2) id e5U6NB300642; Date: Fri, 30 Jun 2000 08:23:10 +0200 From: Andre Albsmeier To: "Kenneth D. Merry" Cc: Andre Albsmeier , freebsd-scsi@FreeBSD.ORG Subject: Re: Curiuos Problem with CAM and a 2940U2W with several devices Message-ID: <20000630082310.A8783@curry.mchp.siemens.de> References: <20000629080730.A66792@curry.mchp.siemens.de> <20000629125305.A61135@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000629125305.A61135@panzer.kdm.org>; from ken@kdm.org on Thu, Jun 29, 2000 at 12:53:05PM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ Ken, thanks for the reply. I did not CC: Justin know, because I don't want to flood his mailbox. Please feel free to copy it over to him if you think he might be interested (I think it IS really interesting).] Today in the morning I have investigated this further, it is really curious. I will sum up all what I have done to make it easier to understand. I will just desribe what was attached to the 2940U2W and what happend. The connectors are referred to as follows: LVD-ext: external accessible LVD connector of the 2940U2W LVD-int: the internal LVD connector 50p-int: the SE 50 pin connector 68p-int: the SE 68 pin connector LVD-Trm and SE-Trm will show the settings of the two corresponding entries in the 2940U2W BIOS. If any cable was attached to any connector, it was terminated properly with an appropriate, active terminator. The 2940U2W was flashed with BIOS 2.57.2. The word "Errors" means errors in the dmesg already during the boot phase when booting with 'boot -s'. These errors are always as being written in my previous mail. Original situation: LVD-ext: noting LVD-int: 2 x DNES-318350W LVD LVD-Trm: enable 50p-int: ST31230N, LPS525S, PIONEER CD-ROM DR-766 68p-int: nothing SE-Trm : low/on high/on Result : worked great In order to replace the ST31230N with a bigger DDRS-34560W, I connected the DDRS-34560W to the 68p-int connector to be able to copy the data over: LVD-ext: nothing LVD-int: 2 x DNES-318350W LVD LVD-Trm: enable 50p-int: ST31230N, LPS525S, PIONEER CD-ROM DR-766 68p-int: DDRS-34560W SE-Trm : low/off high/on Result : Errors I started playing around with the stuff attached to the 50p-int connector: removed the LPS525S, removed the CD-ROM, ... Nothing helped, same results. I assumed it was the fault of the SEAGATE (it is old). In order to be finally able to copy my stuff over, I remove the LVD drives and attached the DDRS-34560W to the LVD-int connector: LVD-ext: nothing LVD-int: DDRS-34560W LVD-Trm: enable 50p-int: ST31230N, LPS525S, PIONEER CD-ROM DR-766 68p-int: nothing SE-Trm : low/on high/on Result : worked great (I copied the whole SEAGATE over) Now, I thought I would be able to remove the SEAGATE and use the DDRS-34560W. I also removed the LPS525S since it was only the swap drive and this would be on the DDRS-34560W now: LVD-ext: nothing LVD-int: 2 x DNES-318350W LVD LVD-Trm: enable 50p-int: PIONEER CD-ROM DR-766 68p-int: DDRS-34560W SE-Trm : low/off high/on Result : Errors I changed the 2940U2W which didn't help. I started playing around with the cables which didn't help. I temporarly set the Adaptec Termination(s) to Automatic which didn't help. I did some final tests: LVD-ext: nothing LVD-int: 2 x DNES-318350W LVD LVD-Trm: enable 50p-int: only a terminated cable 68p-int: DDRS-34560W SE-Trm : low/off high/on Result : Errors Now the same swapped: LVD-ext: nothing LVD-int: 2 x DNES-318350W LVD LVD-Trm: enable 50p-int: ST31230N 68p-int: only a terminated cable SE-Trm : low/off high/on Result : Errors But look here: LVD-ext: nothing LVD-int: 2 x DNES-318350W LVD LVD-Trm: enable 50p-int: nothing 68p-int: DDRS-34560W SE-Trm : low/on high/on Result : worked As a result we can say: As soon as both of the two SE connectors of the 2940U2W get a cable (with or without devices, but always terminated properly) attached to it, we get the errors. I will try around more on my private machine (the one referenced above is my gateway for 100 people :-() and post new results here. Thanks for any help. -Andre On Thu, 29-Jun-2000 at 12:53:05 -0600, Kenneth D. Merry wrote: > On Thu, Jun 29, 2000 at 08:07:30 +0200, Andre Albsmeier wrote: > > I have a really curious SCSI problem here and I think it is not > > CAM/FreeBSD related but I just want to be sure... > > > > This is an Adaptec 2940U2W controller. > > > > The external LVD connector is unused. The internal LVD connector > > has 2 IBM DNES-318350W LVD drives and a LVD terminator at the end > > of the cable. The LVD terminator of the 2940U2W is set to on. > > So the LVD segement is terminated properly. > > > > The 50-pin (8bit) single ended connector has a SEAGATE ST31230N > > drive and a PIONEER CD-ROM DR-766 1.00 cdrom drive attached to it. > > On the end of this cable is an active 50-pin SE terminator. > > The 68-pin (16bit) single ended connector has a IBM DDRS-34560W > > connected to it. On the end of this cable is an active 68-pin SE > > terminator. The SE terminator of the 2940U2W is set to LOW/Off > > and HIGH/On. > > So the SE segment is terminated properly. > > > > The cable lengths are below 1 meter. I have changed them. I have > > replaced the external terminators. I have set the 2940U2Ws > > terminators to automatic. I have lowered the transfer speeds for > > the SE devices. I have removed the CDROM. > > > > I still get these SCSI Error messages. > > > > I might think this is due to the old SEAGATE drive in there but I > > am not sure. When removing the DDRS-34560W and correcting the > > termination accordingly, the system ran fine for a long time. Now I > > just wanted to replace the SEAGATE drive with the bigger DDRS-34560W > > but as soon as I connect it to copy the stuff over, the problems > > start. > > > > Here is the dmesg with the relevant parts. > > > > Maybe someone (Ken ?!? :-)) can give me a hint about this. > > As far as I can tell, you've done all the normal things to isolate the > problem. It could be a problem with the Seagate drive, since that is the > drive the Adaptec driver is complaining about but I don't know what that > problem is. > > This is probably something that Justin will need to look at. > > Ken > -- > Kenneth Merry > ken@kdm.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message -- Your mouse has moved. Windows NT must be restarted for the change to take effect! Reboot now? [OK] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 30 0:40:36 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id 421D337B60C; Fri, 30 Jun 2000 00:40:31 -0700 (PDT) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.10.1/8.10.1) with ESMTP id e5U7eQR10932; Fri, 30 Jun 2000 09:40:26 +0200 (MET DST) Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7]) by mail2.siemens.de (8.10.1/8.10.1) with ESMTP id e5U7eQ023629; Fri, 30 Jun 2000 09:40:26 +0200 (MET DST) Received: (from localhost) by curry.mchp.siemens.de (8.10.2/8.10.2) id e5U7c3301238; Date: Fri, 30 Jun 2000 09:38:03 +0200 From: Andre Albsmeier To: Andre Albsmeier , SUCCESS@FreeBSD.ORG, FAILURE@curry.mchp.siemens.de, DELAY@curry.mchp.siemens.de Cc: "Kenneth D. Merry" , Andre Albsmeier , freebsd-scsi@freebsd.org, gibbs@freebsd.org Subject: Re: Curiuos Problem with CAM and a 2940U2W with several devices Message-ID: <20000630093803.A1035@curry.mchp.siemens.de> References: <20000629080730.A66792@curry.mchp.siemens.de> <20000629125305.A61135@panzer.kdm.org> <20000630082310.A8783@curry.mchp.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20000630082310.A8783@curry.mchp.siemens.de>; from andre@curry.mchp.siemens.de on Fri, Jun 30, 2000 at 08:23:10AM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ Now CC'ing Justin myself ] On Fri, 30-Jun-2000 at 08:23:10 +0200, Andre Albsmeier wrote: > > ... > > Today in the morning I have investigated this further, it is really > curious. I will sum up all what I have done to make it easier to > understand. I will just desribe what was attached to the 2940U2W > and what happend. The connectors are referred to as follows: > > LVD-ext: external accessible LVD connector of the 2940U2W > LVD-int: the internal LVD connector > 50p-int: the SE 50 pin connector > 68p-int: the SE 68 pin connector > > LVD-Trm and SE-Trm will show the settings of the two corresponding > entries in the 2940U2W BIOS. > If any cable was attached to any connector, it was terminated properly > with an appropriate, active terminator. > > The 2940U2W was flashed with BIOS 2.57.2. > > The word "Errors" means errors in the dmesg already during the > boot phase when booting with 'boot -s'. These errors are always > as being written in my previous mail. > Quoting myself but there are interesting news: I can easily reproduce the problem on a different machine with another 2940U2W: da0: Fixed Direct Access SCSI-2 device da1: Fixed Direct Access SCSI-2 device da2: Fixed Direct Access SCSI-2 device da3: Fixed Direct Access SCSI-2 device da4: Fixed Direct Access SCSI-2 device cd0: Removable CD-ROM SCSI-2 device This is the configuration: LVD-ext: noting LVD-int: MAE3182LP LVD LVD-Trm: enable 50p-int: CD-532S 68p-int: all Quantum drives from above SE-Trm : low/off high/on Result : errors (someone reset channel A, ...) But as soon as I remove one of the 3 connected cables (no matter if it is LVD-int, 50p-int or 68p-int) and adjust the termination settings properly, it works. I already wanted to send this email when I got another idea: LVD-ext: nothing LVD-int: only a terminated cable LVD-Trm: enable 50p-int: only a terminated cable 68p-int: all Quantum drives from above SE-Trm : low/off high/on Result : errors (someone reset channel A, ...), as expected And here comes the funny thing: LVD-ext: nothing LVD-int: only a terminated cable BUT TERMINATED WITH AN SE TERMINATOR LVD-Trm: enable 50p-int: only a terminated cable 68p-int: all Quantum drives from above SE-Trm : low/off high/on Result : works As a result we can say: It fails if both of the SE connectors are in use and an LVD path is connected to the LVD-int connector. When using an SE path on the LVD-int connector it works. The funny thing is that Winblows95 has no problems with all of the above configurations. So I slowly might come to the point that there is indeed a problem with the way how FreeBSD uses the 2940U2W. First, I thought it would be one of the devices but as we can see, this isn't the case. Since I have now reproduced the problem on my own machine, I can easily test any suggestions in order to fix this. Thanks, -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message