From owner-freebsd-scsi Sun Jun 1 23:05:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA29188 for freebsd-scsi-outgoing; Sun, 1 Jun 1997 23:05:58 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA29183 for ; Sun, 1 Jun 1997 23:05:55 -0700 (PDT) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id IAA18904 for ; Mon, 2 Jun 1997 08:05:56 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id IAA02179 for freebsd-scsi@freebsd.org; Mon, 2 Jun 1997 08:10:20 +0200 (MEST) Date: Mon, 2 Jun 1997 08:10:20 +0200 (MEST) From: Christoph Kukulies Message-Id: <199706020610.IAA02179@gil.physik.rwth-aachen.de> To: freebsd-scsi@freebsd.org Subject: ncr timeout - command already dequeued... Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I posted the exact message already in hackers over the weekend: I'm getting spurious timeouts once every couple of days, sometimes within 24 hours. Symptom is that the whole system hangs - no disk access possible anymore. It is a system with two ncr/PCI controllers, now exchanged the cheapo ones against SC200 (ASUS) - no change. MB is a Chaintech, AmdK5/PR133, 64MB, 3GB+3GB Quantum Tempest (slow) wired to a 6GB ccd drive. I wonder if either, the two controller situation or the fact that ccd is running upon it leads to this weird behaviour or if the cause is in some other hardware component. I will be exchanging the MB this week but I'm posting this also here just in case someone else might have an idea if the culprit might be in either the ncr code or the scsi driver. -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-scsi Mon Jun 2 03:44:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA12181 for freebsd-scsi-outgoing; Mon, 2 Jun 1997 03:44:44 -0700 (PDT) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA12175 for ; Mon, 2 Jun 1997 03:44:39 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-38.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA06413 (5.67b/IDA-1.5 for ); Mon, 2 Jun 1997 12:44:27 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id MAA17846; Mon, 2 Jun 1997 12:44:17 +0200 (CEST) X-Face: " Date: Mon, 2 Jun 1997 12:43:30 +0200 From: Stefan Esser To: Wilko Bulte Cc: robsch@robkaos.ruhr.de, freebsd-scsi@FreeBSD.ORG Subject: Re: How to turn off DAT compression References: <19970530190429.35326@x14.mi.uni-koeln.de> <199705311739.TAA01227@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199705311739.TAA01227@yedi.iaf.nl>; from Wilko Bulte on Sat, May 31, 1997 at 07:39:21PM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 31, Wilko Bulte wrote: > As Stefan Esser wrote... > > The driver issued a write request, the drive didn't succeed > > executing it, and returned an error status. The generic SCSI > > driver than sent an INQUIRY command to find out about the > > A REQUEST SENSE I suppose. Yes, sure, a REQUEST SENSE, that was what I meant to write ... Seems I'm currently to busy working on QUITE different stuff ... :) Regards, STefan From owner-freebsd-scsi Mon Jun 2 05:34:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA17016 for freebsd-scsi-outgoing; Mon, 2 Jun 1997 05:34:26 -0700 (PDT) Received: from rigel.pcnet.com (root@ts3-pt13.pcnet.com [204.213.233.113]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id FAA17008; Mon, 2 Jun 1997 05:34:21 -0700 (PDT) Received: from rigel (deischen@localhost [127.0.0.1]) by rigel.pcnet.com (8.6.12/8.6.9) with SMTP id MAA01034; Mon, 2 Jun 1997 12:33:11 -0400 Message-ID: <3392F5C6.C24E501@iworks.InterWorks.org> Date: Mon, 02 Jun 1997 12:33:10 -0400 From: "Daniel M. Eischen" X-Mailer: Mozilla 3.0Gold (X11; I; Linux 2.1.26 i586) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-scsi@FreeBSD.org Subject: [Fwd: Looking for a SSA device driver author] Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by iworks.InterWorks.org (8.7.5/) with ESMTP id AAA25306 for ; Mon, 2 Jun 1997 00:51:18 -0500 (CDT) Return-Path: Received: from root@vger.rutgers.edu (port 47740 [128.6.190.2]) by nic.funet.fi with ESMTP id <256-11467>; Mon, 2 Jun 1997 08:40:28 +0300 Received: by vger.rutgers.edu id <973945-32359>; Mon, 2 Jun 1997 01:37:01 -0400 Received: from colin.muc.de ([193.174.4.1]) by vger.rutgers.edu with SMTP id <974188-32357>; Mon, 2 Jun 1997 01:33:29 -0400 Received: from seneca by colin.muc.de with UUCP id <86018-1>; Mon, 2 Jun 1997 07:34:19 +0200 Message-Id: From: hm@seneca.muc.de (Harald Milz) Subject: Looking for a SSA device driver author To: linux-scsi@vger.rutgers.edu Date: Mon, 2 Jun 1997 07:15:29 +0200 X-Pgp-signed: Id=0x7ADC4839; access-type=Finger; Address=hm@muc.de; X-Nospam: I do not want to receive unsolicited advertising! Content-Type: text Sender: owner-linux-scsi@vger.rutgers.edu Precedence: bulk Hi, As you may know, I got in contact with both IBM and Pathlight, Inc. to get a SSA (Serial Storage Architecture) device driver written (and their official support, of course!). The Pathlight single loop adapter will be handled by Michael Neuffer. They will freely loan us adapters and disks for an undetermined time. I haven't yet found someone to work on the driver for the IBM dual-loop adapter. If someone is interested, please tell me. I want to get her or him in contact with the respective IBM authorities. The driver developer should be an experienced SCSI device driver author and closely cooperate with Michael. -- What sane person could live in this world and not be crazy? -- Ursula K. LeGuin From owner-freebsd-scsi Mon Jun 2 08:36:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA24408 for freebsd-scsi-outgoing; Mon, 2 Jun 1997 08:36:58 -0700 (PDT) Received: from rdsw.com (rdsw.com [198.211.39.70]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA24402 for ; Mon, 2 Jun 1997 08:36:44 -0700 (PDT) Received: (from bob@localhost) by rdsw.com (8.7.5/8.7.3) id KAA28015 for scsi@freebsd.org; Mon, 2 Jun 1997 10:36:41 -0500 (CDT) From: Bob Dunaway Message-Id: <199706021536.KAA28015@rdsw.com> Subject: SCSI crashes with ahc on 2.2-STABLE To: scsi@freebsd.org Date: Mon, 2 Jun 1997 10:36:41 -0500 (CDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here is an example of SCSI AHC 2842 system crash after disk errors. I am running 2.2-STABLE as of 04:00 CST May 5. I added a Quantum 2gb Capello disk drive as target 2 several days ago. After putting about 400 meg of data on the drive, I ran a dump to a DAT tape. I got 11 read errors and then the system crashed. Both AWRE and ARRE are enabled on the drive. I then tried a tar to /dev/null to determine the files with errors. I had several system crashes after read errors. Shown below, is the error log from 1 test run. There were 2 bad files. The first showed unrecovered errors and the second only showed the abort messages. After I removed all of the files with bad sectors, I reran the dump to tape and had no problems. Following the error messages are the verbose boot messages and then the kernel configuration file. Thanks, Bob Dunaway bob@rdsw.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * May 29 13:28:25 rds1 /kernel: sd2(ahc0:2:0): MEDIUM ERROR info:2c297d asc:11,0 Unrecovered read error May 29 13:28:26 rds1 /kernel: , retries:4 May 29 13:28:28 rds1 /kernel: sd2(ahc0:2:0): MEDIUM ERROR info:2c297d asc:11,0 Unrecovered read error May 29 13:28:28 rds1 /kernel: , retries:3 May 29 13:28:31 rds1 /kernel: sd2(ahc0:2:0): MEDIUM ERROR info:2c297d asc:11,0 Unrecovered read error May 29 13:28:31 rds1 /kernel: , retries:2 May 29 13:28:33 rds1 /kernel: sd2(ahc0:2:0): MEDIUM ERROR info:2c297d asc:11,0 Unrecovered read error May 29 13:28:33 rds1 /kernel: , retries:1 May 29 13:28:36 rds1 /kernel: sd2(ahc0:2:0): MEDIUM ERROR info:2c297d asc:11,0 Unrecovered read error May 29 13:28:36 rds1 /kernel: , FAILURE May 29 13:36:31 rds1 /kernel: sd2(ahc0:2:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 May 29 13:36:31 rds1 /kernel: SEQADDR = 0x4 SCSISEQ = 0x12 SSTAT0 = 0x0 SSTAT1 = 0xa May 29 13:36:31 rds1 /kernel: sd2(ahc0:2:0): Queueing an Abort SCB May 29 13:36:31 rds1 /kernel: sd2(ahc0:2:0): Abort Message Sent May 29 13:36:31 rds1 /kernel: sd2(ahc0:2:0): SCB 0 - Abort Completed. May 29 13:36:31 rds1 /kernel: sd2(ahc0:2:0): no longer in timeout * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * May 29 11:46:28 rds1 /kernel: Copyright (c) 1992-1997 FreeBSD Inc. May 29 11:46:28 rds1 /kernel: Copyright (c) 1982, 1986, 1989, 1991, 1993 May 29 11:46:28 rds1 /kernel: The Regents of the University of California. All rights reserved. May 29 11:46:28 rds1 /kernel: May 29 11:46:28 rds1 /kernel: FreeBSD 2.2-STABLE #0: Thu May 22 14:37:21 CDT 1997 May 29 11:46:28 rds1 /kernel: root@rds1.rdsw.com:/usr/src-r2_2.2/sys/compile/HTI May 29 11:46:28 rds1 /kernel: Calibrating clock(s) ... i8254 clock: 1193461 Hz May 29 11:46:28 rds1 /kernel: CLK_USE_I8254_CALIBRATION not specified - using default frequency May 29 11:46:28 rds1 /kernel: CPU: i486 DX2 (486-class CPU) May 29 11:46:28 rds1 /kernel: Origin = "GenuineIntel" Id = 0x435 Stepping=5 May 29 11:46:28 rds1 /kernel: Features=0x3 May 29 11:46:28 rds1 /kernel: real memory = 16777216 (16384K bytes) May 29 11:46:29 rds1 /kernel: avail memory = 14671872 (14328K bytes) May 29 11:46:29 rds1 /kernel: ahc0: at 0x1c00-0x1cff irq 11 on eisa0 slot 1 May 29 11:46:29 rds1 /kernel: ahc0: Using Edge Triggered Interrupts May 29 11:46:29 rds1 /kernel: ahc0: aic7770 >= Rev E, Single Channel, SCSI Id=7, 4 SCBs May 29 11:46:29 rds1 /kernel: ahc0: Resetting Channel A May 29 11:46:29 rds1 /kernel: ahc0: Downloading Sequencer Program...ahc0: 369 instructions downloaded May 29 11:46:29 rds1 /kernel: Done May 29 11:46:29 rds1 /kernel: ahc0: Probing channel A May 29 11:46:29 rds1 /kernel: Choosing drivers for scbus configured at 0 May 29 11:46:29 rds1 /kernel: ahc0 waiting for scsi devices to settle May 29 11:46:29 rds1 /kernel: ahc0: target 0 synchronous at 10.0MHz, offset = 0xf May 29 11:46:29 rds1 /kernel: (ahc0:0:0): "MICROP 2217-15MZ1001905 HQ30" type 0 fixed SCSI 2 May 29 11:46:29 rds1 /kernel: sd0(ahc0:0:0): Direct-Access 1685MB (3450902 512 byte sectors) May 29 11:46:29 rds1 /kernel: sd0(ahc0:0:0): with 2372 cyls, 15 heads, and an average 96 sectors/track May 29 11:46:29 rds1 /kernel: ahc0: target 1 synchronous at 10.0MHz, offset = 0xf May 29 11:46:29 rds1 /kernel: (ahc0:1:0): "QUANTUM EMPIRE_1080S 1220" type 0 fixed SCSI 2 May 29 11:46:29 rds1 /kernel: sd1(ahc0:1:0): Direct-Access 1029MB (2109376 512 byte sectors) May 29 11:46:29 rds1 /kernel: sd1(ahc0:1:0): with 2874 cyls, 8 heads, and an average 91 sectors/track May 29 11:46:30 rds1 /kernel: ahc0: target 2 synchronous at 10.0MHz, offset = 0xf May 29 11:46:30 rds1 /kernel: (ahc0:2:0): "QUANTUM VP32210 81H8" type 0 fixed SCSI 2 May 29 11:46:30 rds1 /kernel: sd2(ahc0:2:0): Direct-Access 2103MB (4308352 512 byte sectors) May 29 11:46:30 rds1 /kernel: sd2(ahc0:2:0): with 4243 cyls, 8 heads, and an average 126 sectors/track May 29 11:46:30 rds1 /kernel: ahc0: target 5 synchronous at 5.0MHz, offset = 0xf May 29 11:46:30 rds1 /kernel: (ahc0:5:0): "ARCHIVE Python 00367-XXX 5.23" type 1 removable SCSI 2 May 29 11:46:30 rds1 /kernel: st is configured at 0 May 29 11:46:30 rds1 /kernel: st0(ahc0:5:0): Sequential-Access density code 0x13, drive empty May 29 11:46:30 rds1 /kernel: ahc0: target 6 synchronous at 4.0MHz, offset = 0xf May 29 11:46:30 rds1 /kernel: (ahc0:6:0): "TOSHIBA CD-ROM XM-3401TA 1094" type 5 removable SCSI 2 May 29 11:46:30 rds1 /kernel: cd0(ahc0:6:0): CD-ROM can't get the size May 29 11:46:30 rds1 /kernel: pcibus_setup(1): mode 1 addr port (0x0cf8) is 0xffffffff May 29 11:46:30 rds1 /kernel: pcibus_setup(2): mode 2 enable port (0x0cf8) is 0xff May 29 11:46:30 rds1 /kernel: Probing for devices on the ISA bus: May 29 11:46:30 rds1 /kernel: sc0: the current keyboard controller command byte 0045 May 29 11:46:30 rds1 /kernel: kbdio: RESET_KBD return code:00fa May 29 11:46:30 rds1 /kernel: kbdio: RESET_KBD status:00aa May 29 11:46:30 rds1 /kernel: sc0 at 0x60-0x6f irq 1 on motherboard May 29 11:46:30 rds1 /kernel: sc0: BIOS video mode:3 May 29 11:46:31 rds1 /kernel: sc0: VGA registers upon power-up May 29 11:46:31 rds1 /kernel: 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 May 29 11:46:31 rds1 /kernel: bf 1f 00 4f 0e 0f 00 00 ff ff 9c 8e 8f 28 1f 96 May 29 11:46:31 rds1 /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c May 29 11:46:31 rds1 /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff May 29 11:46:31 rds1 /kernel: sc0: video mode:24 May 29 11:46:31 rds1 /kernel: sc0: VGA color <16 virtual consoles, flags=0x0> May 29 11:46:31 rds1 /kernel: sio0 at 0x3f8-0x3ff irq 4 on isa May 29 11:46:31 rds1 /kernel: sio0: type 16450 May 29 11:46:31 rds1 /kernel: sio1 not found at 0x2f8 May 29 11:46:31 rds1 /kernel: sio2: disabled, not probed. May 29 11:46:31 rds1 /kernel: sio3: disabled, not probed. May 29 11:46:31 rds1 /kernel: lpt0 at 0x378-0x37f irq 7 on isa May 29 11:46:31 rds1 /kernel: lpt0: Interrupt-driven port May 29 11:46:31 rds1 /kernel: lp0: TCP/IP capable interface May 29 11:46:31 rds1 /kernel: lpt1 not found at 0xffffffff May 29 11:46:31 rds1 /kernel: mse0: wrong signature ff May 29 11:46:31 rds1 /kernel: mse0 not found at 0x23c May 29 11:46:32 rds1 /kernel: psm0: disabled, not probed. May 29 11:46:32 rds1 /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa May 29 11:46:32 rds1 /kernel: fdc0: NEC 72065B May 29 11:46:32 rds1 /kernel: fd0: 1.44MB 3.5in May 29 11:46:32 rds1 /kernel: wdc0 not found at 0x1f0 May 29 11:46:32 rds1 /kernel: wdc1 not found at 0x170 May 29 11:46:32 rds1 /kernel: 1 3C5x9 board(s) on ISA found at 0x300 May 29 11:46:32 rds1 /kernel: ep0 at 0x300-0x30f irq 10 on isa May 29 11:46:32 rds1 /kernel: ep0: aui/utp/bnc[*UTP*] address 00:20:af:52:37:4c May 29 11:46:32 rds1 /kernel: npx0 on motherboard May 29 11:46:32 rds1 /kernel: npx0: INT 16 interface May 29 11:46:32 rds1 /kernel: apm0: disabled, not probed. May 29 11:46:32 rds1 /kernel: imasks: bio c0000840, tty c0030492, net c0030492 May 29 11:46:32 rds1 /kernel: BIOS Geometries: May 29 11:46:32 rds1 /kernel: 0:03fe3f20 0..1022=1023 cylinders, 0..63=64 heads, 1..32=32 sectors May 29 11:46:32 rds1 /kernel: 1:03fe3f20 0..1022=1023 cylinders, 0..63=64 heads, 1..32=32 sectors May 29 11:46:32 rds1 /kernel: 0 accounted for May 29 11:46:32 rds1 /kernel: Device configuration finished. May 29 11:46:33 rds1 /kernel: Considering FFS root f/s. May 29 11:46:33 rds1 /kernel: changing root device to sd0a May 29 11:46:33 rds1 /kernel: configure() finished. May 29 11:46:33 rds1 /kernel: sd0s1: type 0x6, start 32, end = 204799, size 204768 : OK May 29 11:46:33 rds1 /kernel: sd0s2: type 0xa5, start 204800, end = 3450879, size 3246080 : OK May 29 11:46:33 rds1 /kernel: WARNING: / was not properly dismounted. May 29 11:46:33 rds1 /kernel: sd1s1: type 0xa5, start 0, end = 2109375, size 2109376 : OK May 29 11:46:33 rds1 /kernel: sd2s1: type 0xa5, start 63, end = 4305419, size 4305357 : OK May 29 11:46:33 rds1 /kernel: sd1s1: type 0xa5, start 0, end = 2109375, size 2109376 : OK May 29 11:46:33 rds1 /kernel: sd2s1: type 0xa5, start 63, end = 4305419, size 4305357 : OK May 29 11:46:36 rds1 lpd[106]: restarted * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * # # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks # # For more information read the handbook part System Administration -> # Configuring the FreeBSD Kernel -> The Configuration File. # The handbook is available in /usr/share/doc/handbook or online as # latest version from the FreeBSD World Wide Web server # # # An exhaustive list of options and more detailed explanations of the # device lines is present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $Id: GENERIC,v 1.77.2.2 1997/02/03 22:53:24 gibbs Exp $ machine "i386" #cpu "I386_CPU" cpu "I486_CPU" cpu "I586_CPU" cpu "I686_CPU" ident RDS maxusers 30 options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device options BOUNCE_BUFFERS #include support for DMA bounce buffers options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options CHILD_MAX=512 options OPEN_MAN=512 options SYSVSHM options SYSVSEM options SYSVMSG config kernel root on wd0 controller isa0 controller eisa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 tape ft0 at fdc0 drive 2 controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 #options ATAPI #Enable ATAPI support for IDE bus #options ATAPI_STATIC #Don't do it as an LKM #device wcd0 #IDE CD-ROM # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. #controller ncr0 #controller amd0 #controller ahb0 controller ahc0 #controller bt0 at isa? port "IO_BT0" bio irq ? vector bt_isa_intr #controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr #controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr #controller aic0 at isa? port 0x340 bio irq 11 vector aicintr #controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr #controller nca1 at isa? port 0x350 bio irq 5 vector ncaintr #controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr controller scbus0 at ahc0 tape st0 at scbus0 target 5 tape st1 at scbus0 target 4 controller scbus0 device sd0 device od0 #See LINT for possible `od' options. device st0 device cd0 #Only need one of these, the code dynamically grows #device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr #device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr #controller matcd0 at isa? port 0x230 bio #device scd0 at isa? port 0x230 bio # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint #options PCVT_FREEBSD=210 # pcvt running on FreeBSD >= 2.0.5 #options XSERVER # include code for XFree86 #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Mandatory, don't remove device npx0 at isa? port "IO_NPX" irq 13 vector npxintr # # Laptop support (see LINT for more options) # device apm0 at isa? disable # Advanced Power Management options APM_BROKEN_STATCLOCK # Workaround some buggy APM BIOS # PCCARD (PCMCIA) support #controller crd0 #device pcic0 at crd? #device pcic1 at crd? device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device sio2 at isa? disable port "IO_COM3" tty irq 5 vector siointr device sio3 at isa? disable port "IO_COM4" tty irq 9 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device lpt1 at isa? port? tty device mse0 at isa? port 0x23c tty irq 5 vector mseintr device psm0 at isa? disable port "IO_KBD" conflicts tty irq 12 vector psmintr # Order is important here due to intrusive probes, do *not* alphabetize # this list of network interfaces until the probes have been fixed. # Right now it appears that the ie0 must be probed before ep0. See # revision 1.20 of this file. #device de0 #device fxp0 #device vx0 #device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr #device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr #device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr device ep0 at isa? port 0x300 net irq 10 vector epintr #device fe0 at isa? port 0x300 net irq ? vector feintr #device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr #device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr #device lnc0 at isa? port 0x280 net irq 10 drq 0 vector lncintr #device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr #device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr pseudo-device loop pseudo-device ether pseudo-device log pseudo-device sl 1 # ijppp uses tun instead of ppp device #pseudo-device ppp 1 pseudo-device tun 1 pseudo-device pty 64 pseudo-device gzip # Exec gzipped a.out's # KTRACE enables the system-call tracing facility ktrace(2). # This adds 4 KB bloat to your kernel, and slightly increases # the costs of each syscall. options KTRACE #kernel tracing From owner-freebsd-scsi Mon Jun 2 09:36:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA27396 for freebsd-scsi-outgoing; Mon, 2 Jun 1997 09:36:09 -0700 (PDT) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA27340 for ; Mon, 2 Jun 1997 09:35:56 -0700 (PDT) Received: (from pete@localhost) by silver.sms.fi (8.8.5/8.7.3) id TAA02668; Mon, 2 Jun 1997 19:34:45 +0300 (EEST) Date: Mon, 2 Jun 1997 19:34:45 +0300 (EEST) Message-Id: <199706021634.TAA02668@silver.sms.fi> From: Petri Helenius To: Bob Dunaway Cc: scsi@FreeBSD.ORG Subject: SCSI crashes with ahc on 2.2-STABLE In-Reply-To: <199706021536.KAA28015@rdsw.com> References: <199706021536.KAA28015@rdsw.com> Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I've been complaining about the recovery code hanging my system when a single TIMEOUT happens for a month or two now. There has been definite improvements since it does not panic any longer but I'm not sure whether it should hang after recovery process. The messages I get are somewhat similar: May 20 11:26:29 silver /kernel: cd0(ahc0:6:0): SCB 0x5 - timed out while idle, L ASTPHASE == 0x1, SCSISIGI == 0x0 May 20 11:26:29 silver /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa May 20 11:26:29 silver /kernel: cd0(ahc0:6:0): Queueing an Abort SCB May 20 11:26:29 silver /kernel: cd0(ahc0:6:0): Abort Message Sent May 20 11:26:29 silver /kernel: cd0(ahc0:6:0): SCB 5 - Abort Completed. May 20 11:26:29 silver /kernel: cd0(ahc0:6:0): no longer in timeout May 20 11:26:30 silver /kernel: ahc0:A:6: no active SCB for reconnecting target - issuing BUS DEVICE RESET May 20 11:26:30 silver /kernel: SAVED_TCL == 0x60 ARG_1 == 0x5 SEQADDR == 0x114 May 20 11:26:30 silver /kernel: ahc0: Bus Device Reset delivered. 1 SCBs aborted May 20 11:26:30 silver /kernel: ahc0: Bus Device Reset delivered. 0 SCBs aborted ********HANG******** May 20 22:04:55 silver /kernel: cd0(ahc0:6:0): SCB 0x3 - timed out while idle, L ASTPHASE == 0x1, SCSISIGI == 0x0 May 20 22:04:55 silver /kernel: SEQADDR = 0x9 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa May 20 22:04:55 silver /kernel: cd0(ahc0:6:0): Queueing an Abort SCB May 20 22:04:55 silver /kernel: cd0(ahc0:6:0): Abort Message Sent May 20 22:04:55 silver /kernel: cd0(ahc0:6:0): SCB 3 - Abort Completed. May 20 22:04:56 silver /kernel: cd0(ahc0:6:0): no longer in timeout ********HANG******** May 21 08:54:10 silver /kernel: cd0(ahc0:6:0): SCB 0x4 - timed out while idle, L ASTPHASE == 0x1, SCSISIGI == 0x0 May 21 08:54:10 silver /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa May 21 08:54:10 silver /kernel: cd0(ahc0:6:0): Queueing an Abort SCB May 21 08:54:10 silver /kernel: cd0(ahc0:6:0): Abort Message Sent May 21 08:54:10 silver /kernel: cd0(ahc0:6:0): SCB 4 - Abort Completed. May 21 08:54:10 silver /kernel: cd0(ahc0:6:0): no longer in timeout ********HANG******** May 22 09:18:33 silver /kernel: cd0(ahc0:6:0): SCB 0x5 - timed out while idle, L ASTPHASE == 0x1, SCSISIGI == 0x0 May 22 09:18:33 silver /kernel: SEQADDR = 0x6 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa May 22 09:18:33 silver /kernel: cd0(ahc0:6:0): Queueing an Abort SCB May 22 09:18:33 silver /kernel: cd0(ahc0:6:0): Abort Message Sent May 22 09:18:33 silver /kernel: cd0(ahc0:6:0): SCB 5 - Abort Completed. May 22 09:18:33 silver /kernel: cd0(ahc0:6:0): no longer in timeout ********HANG******** May 16 20:13:10 silver /kernel: cd0(ahc0:6:0): SCB 0x0 - timed out while idle, L ASTPHASE == 0x1, SCSISIGI == 0x0 May 16 20:13:10 silver /kernel: SEQADDR = 0x5 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0xa May 16 20:13:10 silver /kernel: cd0(ahc0:6:0): Queueing an Abort SCB May 16 20:13:10 silver /kernel: cd0(ahc0:6:0): Abort Message Sent May 16 20:13:10 silver /kernel: cd0(ahc0:6:0): SCB 0 - Abort Completed. May 16 20:13:10 silver /kernel: cd0(ahc0:6:0): no longer in timeout ********HANG******** Bob Dunaway writes: > Here is an example of SCSI AHC 2842 system crash after disk errors. > I am running 2.2-STABLE as of 04:00 CST May 5. I added a Quantum 2gb > Capello disk drive as target 2 several days ago. After putting about > 400 meg of data on the drive, I ran a dump to a DAT tape. I got > 11 read errors and then the system crashed. Both AWRE and ARRE are > enabled on the drive. I then tried a tar to /dev/null to determine > the files with errors. I had several system crashes after read errors. > Shown below, is the error log from 1 test run. There were 2 bad files. > The first showed unrecovered errors and the second only showed the abort > messages. After I removed all of the files with bad sectors, I reran > the dump to tape and had no problems. Following the error messages > are the verbose boot messages and then the kernel configuration file. > > Thanks, > Bob Dunaway > bob@rdsw.com > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > May 29 13:28:25 rds1 /kernel: sd2(ahc0:2:0): MEDIUM ERROR info:2c297d asc:11,0 Unrecovered read error > May 29 13:28:26 rds1 /kernel: , retries:4 > May 29 13:28:28 rds1 /kernel: sd2(ahc0:2:0): MEDIUM ERROR info:2c297d asc:11,0 Unrecovered read error > May 29 13:28:28 rds1 /kernel: , retries:3 > May 29 13:28:31 rds1 /kernel: sd2(ahc0:2:0): MEDIUM ERROR info:2c297d asc:11,0 Unrecovered read error > May 29 13:28:31 rds1 /kernel: , retries:2 > May 29 13:28:33 rds1 /kernel: sd2(ahc0:2:0): MEDIUM ERROR info:2c297d asc:11,0 Unrecovered read error > May 29 13:28:33 rds1 /kernel: , retries:1 > May 29 13:28:36 rds1 /kernel: sd2(ahc0:2:0): MEDIUM ERROR info:2c297d asc:11,0 Unrecovered read error > May 29 13:28:36 rds1 /kernel: , FAILURE > May 29 13:36:31 rds1 /kernel: sd2(ahc0:2:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 > May 29 13:36:31 rds1 /kernel: SEQADDR = 0x4 SCSISEQ = 0x12 SSTAT0 = 0x0 SSTAT1 = 0xa > May 29 13:36:31 rds1 /kernel: sd2(ahc0:2:0): Queueing an Abort SCB > May 29 13:36:31 rds1 /kernel: sd2(ahc0:2:0): Abort Message Sent > May 29 13:36:31 rds1 /kernel: sd2(ahc0:2:0): SCB 0 - Abort Completed. > May 29 13:36:31 rds1 /kernel: sd2(ahc0:2:0): no longer in timeout > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > May 29 11:46:28 rds1 /kernel: Copyright (c) 1992-1997 FreeBSD Inc. > May 29 11:46:28 rds1 /kernel: Copyright (c) 1982, 1986, 1989, 1991, 1993 > May 29 11:46:28 rds1 /kernel: The Regents of the University of California. All rights reserved. > May 29 11:46:28 rds1 /kernel: > May 29 11:46:28 rds1 /kernel: FreeBSD 2.2-STABLE #0: Thu May 22 14:37:21 CDT 1997 > May 29 11:46:28 rds1 /kernel: root@rds1.rdsw.com:/usr/src-r2_2.2/sys/compile/HTI > May 29 11:46:28 rds1 /kernel: Calibrating clock(s) ... i8254 clock: 1193461 Hz > May 29 11:46:28 rds1 /kernel: CLK_USE_I8254_CALIBRATION not specified - using default frequency > May 29 11:46:28 rds1 /kernel: CPU: i486 DX2 (486-class CPU) > May 29 11:46:28 rds1 /kernel: Origin = "GenuineIntel" Id = 0x435 Stepping=5 > May 29 11:46:28 rds1 /kernel: Features=0x3 > May 29 11:46:28 rds1 /kernel: real memory = 16777216 (16384K bytes) > May 29 11:46:29 rds1 /kernel: avail memory = 14671872 (14328K bytes) > May 29 11:46:29 rds1 /kernel: ahc0: at 0x1c00-0x1cff irq 11 on eisa0 slot 1 > May 29 11:46:29 rds1 /kernel: ahc0: Using Edge Triggered Interrupts > May 29 11:46:29 rds1 /kernel: ahc0: aic7770 >= Rev E, Single Channel, SCSI Id=7, 4 SCBs > May 29 11:46:29 rds1 /kernel: ahc0: Resetting Channel A > May 29 11:46:29 rds1 /kernel: ahc0: Downloading Sequencer Program...ahc0: 369 instructions downloaded > May 29 11:46:29 rds1 /kernel: Done > May 29 11:46:29 rds1 /kernel: ahc0: Probing channel A > May 29 11:46:29 rds1 /kernel: Choosing drivers for scbus configured at 0 > May 29 11:46:29 rds1 /kernel: ahc0 waiting for scsi devices to settle > May 29 11:46:29 rds1 /kernel: ahc0: target 0 synchronous at 10.0MHz, offset = 0xf > May 29 11:46:29 rds1 /kernel: (ahc0:0:0): "MICROP 2217-15MZ1001905 HQ30" type 0 fixed SCSI 2 > May 29 11:46:29 rds1 /kernel: sd0(ahc0:0:0): Direct-Access 1685MB (3450902 512 byte sectors) > May 29 11:46:29 rds1 /kernel: sd0(ahc0:0:0): with 2372 cyls, 15 heads, and an average 96 sectors/track > May 29 11:46:29 rds1 /kernel: ahc0: target 1 synchronous at 10.0MHz, offset = 0xf > May 29 11:46:29 rds1 /kernel: (ahc0:1:0): "QUANTUM EMPIRE_1080S 1220" type 0 fixed SCSI 2 > May 29 11:46:29 rds1 /kernel: sd1(ahc0:1:0): Direct-Access 1029MB (2109376 512 byte sectors) > May 29 11:46:29 rds1 /kernel: sd1(ahc0:1:0): with 2874 cyls, 8 heads, and an average 91 sectors/track > May 29 11:46:30 rds1 /kernel: ahc0: target 2 synchronous at 10.0MHz, offset = 0xf > May 29 11:46:30 rds1 /kernel: (ahc0:2:0): "QUANTUM VP32210 81H8" type 0 fixed SCSI 2 > May 29 11:46:30 rds1 /kernel: sd2(ahc0:2:0): Direct-Access 2103MB (4308352 512 byte sectors) > May 29 11:46:30 rds1 /kernel: sd2(ahc0:2:0): with 4243 cyls, 8 heads, and an average 126 sectors/track > May 29 11:46:30 rds1 /kernel: ahc0: target 5 synchronous at 5.0MHz, offset = 0xf > May 29 11:46:30 rds1 /kernel: (ahc0:5:0): "ARCHIVE Python 00367-XXX 5.23" type 1 removable SCSI 2 > May 29 11:46:30 rds1 /kernel: st is configured at 0 > May 29 11:46:30 rds1 /kernel: st0(ahc0:5:0): Sequential-Access density code 0x13, drive empty > May 29 11:46:30 rds1 /kernel: ahc0: target 6 synchronous at 4.0MHz, offset = 0xf > May 29 11:46:30 rds1 /kernel: (ahc0:6:0): "TOSHIBA CD-ROM XM-3401TA 1094" type 5 removable SCSI 2 > May 29 11:46:30 rds1 /kernel: cd0(ahc0:6:0): CD-ROM can't get the size > May 29 11:46:30 rds1 /kernel: pcibus_setup(1): mode 1 addr port (0x0cf8) is 0xffffffff > May 29 11:46:30 rds1 /kernel: pcibus_setup(2): mode 2 enable port (0x0cf8) is 0xff > May 29 11:46:30 rds1 /kernel: Probing for devices on the ISA bus: > May 29 11:46:30 rds1 /kernel: sc0: the current keyboard controller command byte 0045 > May 29 11:46:30 rds1 /kernel: kbdio: RESET_KBD return code:00fa > May 29 11:46:30 rds1 /kernel: kbdio: RESET_KBD status:00aa > May 29 11:46:30 rds1 /kernel: sc0 at 0x60-0x6f irq 1 on motherboard > May 29 11:46:30 rds1 /kernel: sc0: BIOS video mode:3 > May 29 11:46:31 rds1 /kernel: sc0: VGA registers upon power-up > May 29 11:46:31 rds1 /kernel: 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 > May 29 11:46:31 rds1 /kernel: bf 1f 00 4f 0e 0f 00 00 ff ff 9c 8e 8f 28 1f 96 > May 29 11:46:31 rds1 /kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c > May 29 11:46:31 rds1 /kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff > May 29 11:46:31 rds1 /kernel: sc0: video mode:24 > May 29 11:46:31 rds1 /kernel: sc0: VGA color <16 virtual consoles, flags=0x0> > May 29 11:46:31 rds1 /kernel: sio0 at 0x3f8-0x3ff irq 4 on isa > May 29 11:46:31 rds1 /kernel: sio0: type 16450 > May 29 11:46:31 rds1 /kernel: sio1 not found at 0x2f8 > May 29 11:46:31 rds1 /kernel: sio2: disabled, not probed. > May 29 11:46:31 rds1 /kernel: sio3: disabled, not probed. > May 29 11:46:31 rds1 /kernel: lpt0 at 0x378-0x37f irq 7 on isa > May 29 11:46:31 rds1 /kernel: lpt0: Interrupt-driven port > May 29 11:46:31 rds1 /kernel: lp0: TCP/IP capable interface > May 29 11:46:31 rds1 /kernel: lpt1 not found at 0xffffffff > May 29 11:46:31 rds1 /kernel: mse0: wrong signature ff > May 29 11:46:31 rds1 /kernel: mse0 not found at 0x23c > May 29 11:46:32 rds1 /kernel: psm0: disabled, not probed. > May 29 11:46:32 rds1 /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > May 29 11:46:32 rds1 /kernel: fdc0: NEC 72065B > May 29 11:46:32 rds1 /kernel: fd0: 1.44MB 3.5in > May 29 11:46:32 rds1 /kernel: wdc0 not found at 0x1f0 > May 29 11:46:32 rds1 /kernel: wdc1 not found at 0x170 > May 29 11:46:32 rds1 /kernel: 1 3C5x9 board(s) on ISA found at 0x300 > May 29 11:46:32 rds1 /kernel: ep0 at 0x300-0x30f irq 10 on isa > May 29 11:46:32 rds1 /kernel: ep0: aui/utp/bnc[*UTP*] address 00:20:af:52:37:4c > May 29 11:46:32 rds1 /kernel: npx0 on motherboard > May 29 11:46:32 rds1 /kernel: npx0: INT 16 interface > May 29 11:46:32 rds1 /kernel: apm0: disabled, not probed. > May 29 11:46:32 rds1 /kernel: imasks: bio c0000840, tty c0030492, net c0030492 > May 29 11:46:32 rds1 /kernel: BIOS Geometries: > May 29 11:46:32 rds1 /kernel: 0:03fe3f20 0..1022=1023 cylinders, 0..63=64 heads, 1..32=32 sectors > May 29 11:46:32 rds1 /kernel: 1:03fe3f20 0..1022=1023 cylinders, 0..63=64 heads, 1..32=32 sectors > May 29 11:46:32 rds1 /kernel: 0 accounted for > May 29 11:46:32 rds1 /kernel: Device configuration finished. > May 29 11:46:33 rds1 /kernel: Considering FFS root f/s. > May 29 11:46:33 rds1 /kernel: changing root device to sd0a > May 29 11:46:33 rds1 /kernel: configure() finished. > May 29 11:46:33 rds1 /kernel: sd0s1: type 0x6, start 32, end = 204799, size 204768 : OK > May 29 11:46:33 rds1 /kernel: sd0s2: type 0xa5, start 204800, end = 3450879, size 3246080 : OK > May 29 11:46:33 rds1 /kernel: WARNING: / was not properly dismounted. > May 29 11:46:33 rds1 /kernel: sd1s1: type 0xa5, start 0, end = 2109375, size 2109376 : OK > May 29 11:46:33 rds1 /kernel: sd2s1: type 0xa5, start 63, end = 4305419, size 4305357 : OK > May 29 11:46:33 rds1 /kernel: sd1s1: type 0xa5, start 0, end = 2109375, size 2109376 : OK > May 29 11:46:33 rds1 /kernel: sd2s1: type 0xa5, start 63, end = 4305419, size 4305357 : OK > May 29 11:46:36 rds1 lpd[106]: restarted > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > # > # GENERIC -- Generic machine with WD/AHx/NCR/BTx family disks > # > # For more information read the handbook part System Administration -> > # Configuring the FreeBSD Kernel -> The Configuration File. > # The handbook is available in /usr/share/doc/handbook or online as > # latest version from the FreeBSD World Wide Web server > # > # > # An exhaustive list of options and more detailed explanations of the > # device lines is present in the ./LINT configuration file. If you are > # in doubt as to the purpose or necessity of a line, check first in LINT. > # > # $Id: GENERIC,v 1.77.2.2 1997/02/03 22:53:24 gibbs Exp $ > > machine "i386" > #cpu "I386_CPU" > cpu "I486_CPU" > cpu "I586_CPU" > cpu "I686_CPU" > ident RDS > maxusers 30 > > options MATH_EMULATE #Support for x87 emulation > options INET #InterNETworking > options FFS #Berkeley Fast Filesystem > options NFS #Network Filesystem > options MSDOSFS #MSDOS Filesystem > options "CD9660" #ISO 9660 Filesystem > options PROCFS #Process filesystem > options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] > options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device > options BOUNCE_BUFFERS #include support for DMA bounce buffers > options UCONSOLE #Allow users to grab the console > options FAILSAFE #Be conservative > options USERCONFIG #boot -c editor > options VISUAL_USERCONFIG #visual boot -c editor > options CHILD_MAX=512 > options OPEN_MAN=512 > > options SYSVSHM > options SYSVSEM > options SYSVMSG > > config kernel root on wd0 > > controller isa0 > controller eisa0 > controller pci0 > > controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr > disk fd0 at fdc0 drive 0 > disk fd1 at fdc0 drive 1 > tape ft0 at fdc0 drive 2 > > controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr > disk wd0 at wdc0 drive 0 > disk wd1 at wdc0 drive 1 > > controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr > disk wd2 at wdc1 drive 0 > disk wd3 at wdc1 drive 1 > > #options ATAPI #Enable ATAPI support for IDE bus > #options ATAPI_STATIC #Don't do it as an LKM > #device wcd0 #IDE CD-ROM > > # A single entry for any of these controllers (ncr, ahb, ahc, amd) is > # sufficient for any number of installed devices. > #controller ncr0 > #controller amd0 > #controller ahb0 > controller ahc0 > #controller bt0 at isa? port "IO_BT0" bio irq ? vector bt_isa_intr > #controller uha0 at isa? port "IO_UHA0" bio irq ? drq 5 vector uhaintr > #controller aha0 at isa? port "IO_AHA0" bio irq ? drq 5 vector ahaintr > #controller aic0 at isa? port 0x340 bio irq 11 vector aicintr > #controller nca0 at isa? port 0x1f88 bio irq 10 vector ncaintr > #controller nca1 at isa? port 0x350 bio irq 5 vector ncaintr > #controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr > > controller scbus0 at ahc0 > tape st0 at scbus0 target 5 > tape st1 at scbus0 target 4 > > controller scbus0 > > device sd0 > > device od0 #See LINT for possible `od' options. > > device st0 > > device cd0 #Only need one of these, the code dynamically grows > > #device wt0 at isa? port 0x300 bio irq 5 drq 1 vector wtintr > #device mcd0 at isa? port 0x300 bio irq 10 vector mcdintr > > #controller matcd0 at isa? port 0x230 bio > > #device scd0 at isa? port 0x230 bio > > # syscons is the default console driver, resembling an SCO console > device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr > # Enable this and PCVT_FREEBSD for pcvt vt220 compatible console driver > #device vt0 at isa? port "IO_KBD" tty irq 1 vector pcrint > #options PCVT_FREEBSD=210 # pcvt running on FreeBSD >= 2.0.5 > #options XSERVER # include code for XFree86 > #options FAT_CURSOR # start with block cursor > # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines > #options PCVT_SCANSET=2 # IBM keyboards are non-std > > # Mandatory, don't remove > device npx0 at isa? port "IO_NPX" irq 13 vector npxintr > > # > # Laptop support (see LINT for more options) > # > device apm0 at isa? disable # Advanced Power Management > options APM_BROKEN_STATCLOCK # Workaround some buggy APM BIOS > # PCCARD (PCMCIA) support > #controller crd0 > #device pcic0 at crd? > #device pcic1 at crd? > > device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr > device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr > device sio2 at isa? disable port "IO_COM3" tty irq 5 vector siointr > device sio3 at isa? disable port "IO_COM4" tty irq 9 vector siointr > > device lpt0 at isa? port? tty irq 7 vector lptintr > device lpt1 at isa? port? tty > device mse0 at isa? port 0x23c tty irq 5 vector mseintr > > device psm0 at isa? disable port "IO_KBD" conflicts tty irq 12 vector psmintr > > # Order is important here due to intrusive probes, do *not* alphabetize > # this list of network interfaces until the probes have been fixed. > # Right now it appears that the ie0 must be probed before ep0. See > # revision 1.20 of this file. > #device de0 > #device fxp0 > #device vx0 > > #device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr > #device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr > #device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr > device ep0 at isa? port 0x300 net irq 10 vector epintr > #device fe0 at isa? port 0x300 net irq ? vector feintr > #device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr > #device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr > #device lnc0 at isa? port 0x280 net irq 10 drq 0 vector lncintr > #device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr > #device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr > > pseudo-device loop > pseudo-device ether > pseudo-device log > pseudo-device sl 1 > # ijppp uses tun instead of ppp device > #pseudo-device ppp 1 > pseudo-device tun 1 > pseudo-device pty 64 > pseudo-device gzip # Exec gzipped a.out's > > # KTRACE enables the system-call tracing facility ktrace(2). > # This adds 4 KB bloat to your kernel, and slightly increases > # the costs of each syscall. > options KTRACE #kernel tracing > From owner-freebsd-scsi Tue Jun 3 04:08:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA22486 for freebsd-scsi-outgoing; Tue, 3 Jun 1997 04:08:12 -0700 (PDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.235]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA22422 for ; Tue, 3 Jun 1997 04:07:52 -0700 (PDT) Received: from tmbbwmc.bbn.hp.com (tmbbwmc.bbn.hp.com [15.136.25.181]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id EAA11708 for ; Tue, 3 Jun 1997 04:07:49 -0700 (PDT) Received: from localhost (michaelc@localhost) by tmbbwmc.bbn.hp.com with SMTP (8.7.1/8.7.1) id NAA20066 for ; Tue, 3 Jun 1997 13:06:59 +0200 (METDST) Date: Tue, 3 Jun 1997 13:06:59 +0200 (METDST) From: Michael Class To: freebsd-scsi@freebsd.org Subject: NCR-SCSI and CD-ROM Burner Problem on FBSD 2.2.2 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, i have a very nasty problem here when I try to burn CD's. Description: After transferrring approx 600-800MB of data to the CD-ROM burner, I get error-messages and the writing stops. Same thing happens when I am in "dummy"-mode (means just transfering the data, but not actually burning) The burner will only work again after a reboot. The messages are: (I get just one of the following for every single run) -------------------------------------------------------------------------- worm0(ncr0:3:0): ABORTED COMMAND asc:50,0 Write append error worm0(ncr0:3:0): ABORTED COMMAND info:80005783 asc:50,0 Write append error -------------------------------------------------------------------------- worm0(ncr0:3:0): ILLEGAL REQUEST asc:82,0 Vendor Specific ASC worm0(ncr0:3:0): ILLEGAL REQUEST asc:2c,0 Command sequence error worm0(ncr0:3:0): ILLEGAL REQUEST asc:a8,0 Vendor Specific ASC -------------------------------------------------------------------------- worm0(ncr0:3:0): ILLEGAL REQUEST asc:a8,0 Vendor Specific ASC -------------------------------------------------------------------------- worm1(ncr0:3:0): error code 0 worm1(ncr0:3:0): error code 0 -------------------------------------------------------------------------- worm0(ncr0:3:0): ILLEGAL REQUEST asc:2c,0 Command sequence error worm0(ncr0:3:0): error code 1 worm0(ncr0:3:0): error code 1 -------------------------------------------------------------------------- To produce these messages I simply have to use the burncd.sh script that came with FreeBSD. The error occurs either at the end of a very full cd (at approx 600MB) or at the beginning of the second run (within the next 100MB). It is reproducable (that means, that with the same data it will stop after a reboot at the very same position), it does not depend on the speed of the writer (single/double). The Setup is as follows: ASUS P6NP5-MB, 200Mhz P6, 64MB-RAM, Miro SV40-Graphics-Card, Symbios SYM8751SP-SCSI-Controller, SoundBlaster AWE32, NE2000-Clone, Quantum 34300W, Quantum PD1800S, Toshiba XM-3701, HP 4020i, HP34450. FreeBSD-2.2.2 (config-file included) I have already tried different MB, different SCSI-Controller (cheap NCR810 based) and different cabling for SCSI-Devices and stripped down system. Therefore I do not expect it to be a SCSI termination or cabeling-problem. I have not yet tried a different Burner and a SCSI-Controller that does not use the ncr-driver. Does anyone have any ideas, of what I could/should do next? Michael Config-File: ------------------------------------------------------------------------- # # MCSCSI # machine "i386" cpu "I586_CPU" cpu "I686_CPU" ident MCSCSI maxusers 32 options SYSVSHM options SYSVSEM options SYSVMSG options INET #InterNETworking options FFS #Berkeley Fast File System # these options are now run-time-loadable: options NFS #Network File System options MSDOSFS #MS-DOS File System options PROCFS #Process File System options KERNFS #Kernel File System options "CD9660" #CD ISO9660 File System # THis DEVFS is experimental but seems to work options DEVFS #devices filesystem options FIFO #Support for FIFO files options "COMPAT_43" #Compatible with BSD 4.3 options "SCSI_DELAY=10" #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab console options USER_LDT #allow user-level control of i386 ldt options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options TUN #IP Tunnel driver options "AUTO_EOI_1" options "AUTO_EOI_2" options "IBCS2" # make ibcs2-code loadable options "COMPAT_LINUX" # load linux-code options "LINUX" # load linux-code # Enable the following (IPFIREWALL_VERBOSE optional) to enable the IP firewall # code. This is used in conjunction with the ipfw(1) command. See the # man page for more details. options IPFIREWALL options IPFIREWALL_VERBOSE #print information about dropped packets options "IPFIREWALL_VERBOSE_LIMIT=100" options IPDIVERT options "FDSEEKWAIT=8" #fd-driver wait 1s / FDSEEKWAIT # pcvt needs XCONSOLE for Xfree options XCONSOLE options "PCVT_FREEBSD=210" # pcvt running on FreeBSD 2.1 # Allow this many swap-devices. options "NSWAPDEV=4" config kernel root on sd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 controller ncr0 controller ncr1 controller scbus0 #base SCSI code device sd0 #SCSI disks device st0 #SCSI tapes device cd0 #SCSI CD-ROMs # The previous devices (ch, sd, st, cd) are recognized by config. # config doesn't (and shouldn't) know about these newer ones, # so we have to specify that they are on a SCSI bus with the "at scbus?" # clause. device worm0 at scbus? # SCSI worm #syscons: device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device ed0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector edintr # Controls all sound devices controller snd0 device sb0 at isa? port 0x220 irq 5 conflicts drq 1 vector sbintr device sbxvi0 at isa? drq 5 device sbmidi0 at isa? port 0x330 pseudo-device loop pseudo-device ether pseudo-device tun 1 #Tunnel driver(user process ppp) pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device log pseudo-device pty 48 pseudo-device speaker pseudo-device gzip # Exec gzipped a.out's pseudo-device vn #Vnode driver (turns a file into a device) ------------------------------------------------------------------------- Boot-Messages (kernel -v): ------------------------------------------------------------------------- Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 2.2.2-RELEASE #0: Fri May 30 16:36:37 MEST 1997 michaelc@pc-micha.zdv.uni-tuebingen.de:/usr/src/sys/compile/MCSCSI Calibrating clock(s) ... i586 clock: 199306468 Hz, i8254 clock: 1193166 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency CLK_USE_I586_CALIBRATION not specified - using old calibration method CPU: Pentium Pro (199.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping=9 Features=0xf9ff,MTRR,PGE,MCA,CMOV> real memory = 67108864 (65536K bytes) avail memory = 63639552 (62148K bytes) DEVFS: ready for devices pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x8000005c pcibus_setup(1a): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 is there (id=12378086) Probing for devices on PCI bus 0: configuration mode 1 allows 32 devices. chip0 rev 2 on pci0:0 chip1 rev 1 on pci0:1:0 chip2 rev 0 on pci0:1:1 mapreg[20] type=1 addr=0000e800 size=0010. I/O Recovery Timing: 8-bit 3.5 clocks, 16-bit 3.5 clocks Extended BIOS: disabled Lower BIOS: disabled Coprocessor IRQ13: disabled Mouse IRQ12: disabled Interrupt Routing: A: , B: , C: , D: MB0: , MB1: vga0 rev 0 int a irq 15 on pci0:10 mapreg[10] type=0 addr=f8000000 size=2000000. ncr0 rev 3 int a irq 9 on pci0:11 mapreg[10] type=1 addr=0000e000 size=0100. mapreg[14] type=0 addr=f7800000 size=0100. mapreg[18] type=0 addr=f7000000 size=1000. reg20: virtual=0xf4daa000 physical=0xf7800000 size=0x100 initial value of SCNTL3 = 03, final = 13 ncr0: restart (scsi reset). ncr0 scanning for targets 0..6 and 8..15 (V2 pl24 96/12/14) ncr0 waiting for scsi devices to settle (ncr0:0:0): "QUANTUM PD1800S 3161" type 0 fixed SCSI 2 sd0(ncr0:0:0): Direct-Access sd0(ncr0:0:0): 10.0 MB/s (100 ns, offset 15) 1717MB (3517856 512 byte sectors) sd0(ncr0:0:0): with 3008 cyls, 14 heads, and an average 83 sectors/track (ncr0:5:0): "TOSHIBA CD-ROM XM-3701TA 3615" type 5 removable SCSI 2 cd0(ncr0:5:0): CD-ROM cd0(ncr0:5:0): 4.4 MB/s (225 ns, offset 15) cd present [187495 x 2048 byte records] (ncr0:8:0): "Quantum XP34300W L912" type 0 fixed SCSI 2 sd1(ncr0:8:0): Direct-Access sd1(ncr0:8:0): WIDE SCSI (16 bit) enabled sd1(ncr0:8:0): 20.0 MB/s (100 ns, offset 15) 4101MB (8399520 512 byte sectors) sd1(ncr0:8:0): with 3907 cyls, 20 heads, and an average 107 sectors/track ncr1 rev 1 int a irq 12 on pci0:12 mapreg[10] type=1 addr=0000d800 size=0100. mapreg[14] type=0 addr=f6800000 size=0100. reg20: virtual=0xf4dad000 physical=0xf6800000 size=0x100 ncr1: restart (scsi reset). ncr1 scanning for targets 0..6 (V2 pl24 96/12/14) ncr1 waiting for scsi devices to settle (ncr1:2:0): "HP HP35450A -A BE00" type 1 removable SCSI 2 st0(ncr1:2:0): Sequential-Access st0(ncr1:2:0): asynchronous. density code 0x13, drive empty (ncr1:3:0): "HP C4324/C4325 1.27" type 5 removable SCSI 2 worm0(ncr1:3:0): Write-Once pci0: uses 33559040 bytes of memory from f6800000 upto f9ffffff. pci0: uses 528 bytes of I/O space from d800 upto e80f. Probing for devices on the ISA bus: sc0: the current keyboard controller command byte 0067 kbdio: RESET_KBD return code:00fa kbdio: RESET_KBD status:00aa sc0 at 0x60-0x6f irq 1 on motherboard sc0: BIOS video mode:3 sc0: VGA registers upon power-up 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 ff ff 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: video mode:24 sc0: VGA registers for mode:24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 10 maddr 0xd8000 msize 16384 on isa ed0: address 00:00:c0:b0:12:9a, type WD8013EBT (16 bit) bpf: ed0 attached sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in fd1: 1.2MB 5.25in npx0 on motherboard npx0: INT 16 interface sb0 at 0x220 irq 5 drq 1 on isa sb0: sbxvi0 at 0x0 drq 5 on isa sbxvi0: sbmidi0 at 0x330 on isa imasks: bio c0001240, tty c003009a, net c0020400 BIOS Geometries: 0:00d9fe3f 0..217=218 cylinders, 0..254=255 heads, 1..63=63 sectors 1:03f8823f 0..1016=1017 cylinders, 0..130=131 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. configure() finished. DEVFS: ready to run bpf: tun0 attached bpf: lo0 attached IP packet filtering initialized, divert enabled, logging limited to 100 packets/entry sd0s1: type 0x6, start 2474010, end = 3518234, size 1044225 : OK sd0s4: type 0xa5, start 32, end = 2474009, size 2473978 : OK sd1s1: type 0x6, start 4200777, end = 5843123, size 1642347 : OK sd1s2: type 0x5, start 5843124, end = 8393300, size 2550177 : OK sd1s4: type 0xa5, start 63, end = 4194366, size 4194304 : OK sd1s5: type 0x7, start 5843187, end = 8393300, size 2550114 : OK ------------------------------------------------------------------------- ----------------------------------------------------------------------- Michael Class E-Mail: michael_class@hp.com Internet/Intranet Solutions Center Phone: +49 7031 14-3707 CSO Europe Fax: +49 7031 14-4196 Hewlett-Packard GmbH, PO Box 1430, 71004 Boeblingen ----------------------------------------------------------------------- From owner-freebsd-scsi Tue Jun 3 06:55:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA29679 for freebsd-scsi-outgoing; Tue, 3 Jun 1997 06:55:02 -0700 (PDT) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id GAA29667 for ; Tue, 3 Jun 1997 06:54:59 -0700 (PDT) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA10483; Tue, 3 Jun 97 15:53:32 +0100 Date: Tue, 3 Jun 97 15:53:32 +0100 Message-Id: <9706031453.AA10483@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: michaelc@tmbbwmc.bbn.hp.com Cc: freebsd-scsi@freebsd.org In-Reply-To: (message from Michael Class on Tue, 3 Jun 1997 13:06:59 +0200 (METDST)) Subject: Re: NCR-SCSI and CD-ROM Burner Problem on FBSD 2.2.2 X-Mailer: Emacs Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> Michael Class writes: > Hello, > i have a very nasty problem here when I try to burn CD's. > Description: After transferrring approx 600-800MB of data to the > CD-ROM burner, I get error-messages and the writing stops. > Same thing happens when I am in "dummy"-mode (means just > transfering the data, but not actually burning) > The burner will only work again after a reboot. > The messages are: (I get just one of the following > for every single run) > -------------------------------------------------------------------------- > worm0(ncr0:3:0): ABORTED COMMAND asc:50,0 Write append error > worm0(ncr0:3:0): ABORTED COMMAND info:80005783 asc:50,0 Write append error This means that you filled your disk. You can't write more than 640Mbytes on a disk. > The error occurs either at the end of a very full cd (at approx 600MB) > or at the beginning of the second run (within the next 100MB). It > is reproducable (that means, that with the same data it will stop > after a reboot at the very same position), it does not depend on > the speed of the writer (single/double). You must open and close the tray between 2 runs (even after a dummy write) to reset the drive capacity. Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-scsi Tue Jun 3 13:01:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA19574 for freebsd-scsi-outgoing; Tue, 3 Jun 1997 13:01:12 -0700 (PDT) Received: from sucks.to.be.you.net (moke@sucks.to.be.you.net [204.246.64.101]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA19569 for ; Tue, 3 Jun 1997 13:01:08 -0700 (PDT) Received: from localhost (moke@localhost) by sucks.to.be.you.net (8.8.5/8.8.5) with SMTP id OAA01647; Tue, 3 Jun 1997 14:59:17 -0500 (CDT) Date: Tue, 3 Jun 1997 14:59:17 -0500 (CDT) From: Jimbo Bahooli To: Michael Class cc: freebsd-scsi@FreeBSD.ORG Subject: Re: NCR-SCSI and CD-ROM Burner Problem on FBSD 2.2.2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 3 Jun 1997, Michael Class wrote: > > Hello, > > i have a very nasty problem here when I try to burn CD's. > > Description: After transferrring approx 600-800MB of data to the > CD-ROM burner, I get error-messages and the writing stops. > Same thing happens when I am in "dummy"-mode (means just > transfering the data, but not actually burning) > ASUS P6NP5-MB, 200Mhz P6, 64MB-RAM, Miro SV40-Graphics-Card, > Symbios SYM8751SP-SCSI-Controller, SoundBlaster AWE32, NE2000-Clone, > Quantum 34300W, Quantum PD1800S, Toshiba XM-3701, HP 4020i, HP34450. If possible try to return the the hp 4020i for a different cdr. Its known to be defective and is why they discontinued the model line. Personally I am on my second hp 4020i, my first was replaced free of charge when it started getting 'write append errors' after > 300 or megs written to the disk. The retailer admitted that this one will eventually suffer the same fate. In this whole mess up of purchasing a second rate cdr its going to cost me 15% restocking fee, plus the difference in price of the new cdr's which are coming in less then a month. These new cdr's supposedly have far few moving parts and are much more reliable. From owner-freebsd-scsi Thu Jun 5 09:43:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA23407 for freebsd-scsi-outgoing; Thu, 5 Jun 1997 09:43:29 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA23391; Thu, 5 Jun 1997 09:43:26 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id KAA28909; Thu, 5 Jun 1997 10:43:04 -0600 (MDT) Message-Id: <199706051643.KAA28909@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Kenneth Merry cc: freebsd-smp@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: 2xPP200 vs 2xPP150 In-reply-to: Your message of "Thu, 05 Jun 1997 03:10:10 EDT." <199706050710.DAA09276@housing1.stucen.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 1997 11:41:39 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [About the Quantum Atlas II] >upgrade the firmware on your drive from LXQ1 to LXY4. > - Justin said a little while back that there are bugs with the older > firware revisions on at least the Atlas II, and I think the Atlas I > that cause tagged command queueing to not work properly. I was able to > successfully upgrade my firmware, and I know that Satoshi has done it > as well. (he has a XP34550W as well) The Atlas I would return QUEUE FULL at very low tag counts with firmware revisions below L915. With L915, it seems that using up to 31 tags is possible. As for the Atlas II, Quantum still hasn't addressed the QUEUE FULL problem. On my test "CAM SCSI" system: da4 at ahc0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI2 device da4: Serial Number PCB=2011303101 ; HDA=189704332253 da4: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da4: 8682MB (17781520 512 byte sectors: 255H 63S/T 1106C) (da4:ahc0:0:4:0): tagged openings reduced to 30 (da4:ahc0:0:4:0): tagged openings reduced to 22 (da4:ahc0:0:4:0): tagged openings reduced to 18 (da4:ahc0:0:4:0): tagged openings reduced to 16 (da4:ahc0:0:4:0): tagged openings reduced to 8 (da4:ahc0:0:4:0): tagged openings reduced to 6 (da4:ahc0:0:4:0): tagged openings reduced to 4 This happens simply by performing a: cd /mnt; dump 0f - /usr | restore rf - Now, at least with the new CAM code, receiving QUEUE FULL status from a drive will only reduce performance since it takes time to handle the QUEUE FULL condition and it can result in a reduction in the number of transactions allowed to be queued to the device. In the current SCSI code, things are quite fragile, and repeated QUEUE FULL status can cause an infinite loop in the kernel. According to Quantum, the Atlas II's firmware should be able to handle up to 256 tags at a time. Unfortunately, they seem to hold on to the resource necessary to queue a transaction on writes until they are completely written to the media even though the drive may return good status long before this happens. This makes it really tough for the SCSI system to determine what is an appropriate tag count to use. The current algorithm used in CAM is to simply truncate the number of "openings" when a QUEUE FULL is encountered to the number of transactions that are still left on the device (e.g. if the 15th transaction caused a queue full, we'll drop to 14 and not queue any more to the device until we drop below that number). It may be that, for drives like the Atlas II, better performance could be achieved by adding some hysteresis on the count along with a delay in releasing new transactions, but I don't know how worth while the added complexity would be. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Thu Jun 5 10:05:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA24654 for freebsd-scsi-outgoing; Thu, 5 Jun 1997 10:05:17 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA24645; Thu, 5 Jun 1997 10:05:12 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA20396; Thu, 5 Jun 1997 10:00:18 -0700 From: Terry Lambert Message-Id: <199706051700.KAA20396@phaeton.artisoft.com> Subject: Re: 2xPP200 vs 2xPP150 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Thu, 5 Jun 1997 10:00:17 -0700 (MST) Cc: ken@housing1.stucen.gatech.edu, freebsd-smp@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199706051643.KAA28909@pluto.plutotech.com> from "Justin T. Gibbs" at Jun 5, 97 11:41:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > [About the Quantum Atlas II] [ ... ] > According to Quantum, the Atlas II's firmware should be able to handle up > to 256 tags at a time. Unfortunately, they seem to hold on to the resource > necessary to queue a transaction on writes until they are completely > written to the media even though the drive may return good status long > before this happens. This makes it really tough for the SCSI system to > determine what is an appropriate tag count to use. > > The current algorithm used in CAM is to simply truncate the number of > "openings" when a QUEUE FULL is encountered to the number of transactions > that are still left on the device (e.g. if the 15th transaction caused a > queue full, we'll drop to 14 and not queue any more to the device until we > drop below that number). It may be that, for drives like the Atlas II, > better performance could be achieved by adding some hysteresis on the count > along with a delay in releasing new transactions, but I don't know how > worth while the added complexity would be. >From your description, it seems that it would be worthwhile to seperate hysteresis for read vs. write, if the write problem is localized solely to the write path. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-scsi Thu Jun 5 11:54:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA00181 for freebsd-scsi-outgoing; Thu, 5 Jun 1997 11:54:07 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA00175; Thu, 5 Jun 1997 11:54:05 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id MAA01925; Thu, 5 Jun 1997 12:53:08 -0600 (MDT) Message-Id: <199706051853.MAA01925@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), ken@housing1.stucen.gatech.edu, freebsd-smp@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: 2xPP200 vs 2xPP150 In-reply-to: Your message of "Thu, 05 Jun 1997 10:00:17 PDT." <199706051700.KAA20396@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 1997 13:51:43 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From your description, it seems that it would be worthwhile to >seperate hysteresis for read vs. write, if the write problem is >localized solely to the write path. The problem is that you don't know if a QUEUE FULL is being returned because of a hard or temporary resource limitation. This could occur for different reasons on different devices, because of read activity or write activity. There is also no easy way for you to determine, even in the case of the Quantum, that the QUEUE FULL happened because of write activity. All queued transactions at the time of the QUEUE FULL could be reads, which the writes that actually caused the problem already completed successfully to the caller. Regardless, this is a general problem with the semantics of the QUEUE FULL status on SCSI devices and I'd rather solve it with a generic solution instead of one taylored to a specific device. Hysteresis and some amount of delay before opening the queue up again, may allow us to keep the tag count up even when confronted with the occasional QUEUE FULL due to a temporary resource shortage regardless of the cause of that shortage. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Fri Jun 6 16:38:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA19143 for freebsd-scsi-outgoing; Fri, 6 Jun 1997 16:38:00 -0700 (PDT) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA19132 for ; Fri, 6 Jun 1997 16:37:55 -0700 (PDT) Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.5/8.7.3) id QAA19597; Fri, 6 Jun 1997 16:37:54 -0700 (PDT) Date: Fri, 6 Jun 1997 16:37:54 -0700 (PDT) Message-Id: <199706062337.QAA19597@vader.cs.berkeley.edu> To: scsi@freebsd.org Subject: 3940uw with long cables From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Howdy, I've got a machine that has a bunch of disks -- unfortunately, some of the cables are quite long due to physical constraints (enclosures stacked on top of each other, etc.) I see the following kind of errors when the probe reaches one of the longer cables: === Probing for devices on PCI bus 3: ahc4 rev 0 int a irq 11 on pci3:4 ahc4: aic7880 Wide Channel A, SCSI Id=6, 16 SCBs ahc4 waiting for scsi devices to settle ahc4: target 0 Tagged Queuing Device (ahc4:0:0): "IBM OEM DCHS09Y 2424" type 0 fixed SCSI 2 sd28(ahc4:0:0): Direct-Access 8689MB (17796077 512 byte sectors) ahc4: target 1 Tagged Queuing Device (ahc4:1:0): "IBM OEM DCHS09Y 2424" type 0 fixed SCSI 2 sd29(ahc4:1:0): Direct-Access 8689MB (17796077 512 byte sectors) ahc4: target 2 Tagged Queuing Device (ahc4:2:0): "IBM OEM DCHS09Y 2424" type 0 fixed SCSI 2 sd30(ahc4:2:0): Direct-Access 8689MB (17796077 512 byte sectors) ahc4: target 3 Tagged Queuing Device (ahc4:3:0): "IBM OEM DCHS09Y 2424" type 0 fixed SCSI 2 sd31(ahc4:3:0): Direct-Access 8689MB (17796077 512 byte sectors) ahc4: target 4 Tagged Queuing Device (ahc4:4:0): "IBM OEM DCHS09Y 2424" type 0 fixed SCSI 2 sd32(ahc4:4:0): Direct-Access 8689MB (17796077 512 byte sectors) ahc4: target 5 Tagged Queuing Device (ahc4:5:0): "IBM OEM DCHS09Y 2424" type 0 fixed SCSI 2 sd33(ahc4:5:0): Direct-Access 8689MB (17796077 512 byte sectors) ahc4: target 8 Tagged Queuing Device (ahc4:8:0): "IBM OEM DCHS09Y 2424" type 0 fixed SCSI 2 sd34(ahc4:8:0): Direct-Access 8689MB (17796077 512 byte sectors) ahc4: board is not responding (ahc4:9:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0xb4 SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0x2 (ahc4:9:0): SCB 0: Immediate reset. Flags = 0x801 (ahc4:9:0): no longer in timeout ahc4: Issued Channel A Bus Reset. 1 SCBs aborted ahc4: board is not responding (ahc4:9:0): SCB 0x0 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0xb4 SEQADDR = 0x42 SCSISEQ = 0x12 SSTAT0 = 0x5 SSTAT1 = 0x2 (ahc4:9:0): SCB 0: Immediate reset. Flags = 0x801 (ahc4:9:0): no longer in timeout ahc4: Issued Channel A Bus Reset. 1 SCBs aborted === Is this something that can be only cured by somehow shortening the cables? This is 2.2-stable, IBM U-W disks on Adaptec 3940UW (with 20MHz mode disabled). We have 14-disk enclosures stacked on top of each other. The cables inside the enclosures are about 10 feet total in my eyeball test. The external cables are either 2, 2 1/2, 3 or 3 1/2 feet long. It's only the 3 or 3 1/2 feet cables that give us problems. (Which is also very interesting, does 12 1/2 and 13 make *that* much difference?!?) Satoshi From owner-freebsd-scsi Fri Jun 6 17:47:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA21711 for freebsd-scsi-outgoing; Fri, 6 Jun 1997 17:47:36 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA21705 for ; Fri, 6 Jun 1997 17:47:33 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id SAA07204; Fri, 6 Jun 1997 18:47:31 -0600 (MDT) Message-Id: <199706070047.SAA07204@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: asami@cs.berkeley.edu (Satoshi Asami) cc: scsi@FreeBSD.ORG Subject: Re: 3940uw with long cables In-reply-to: Your message of "Fri, 06 Jun 1997 16:37:54 PDT." <199706062337.QAA19597@vader.cs.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Jun 1997 19:45:54 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Is this something that can be only cured by somehow shortening the >cables? Perhaps. There are a few important things to keep in mind when tuning the bus length. 1) Having equal distances between all devices is sometimes more important than total bus length since the varying RC constants can cause strange signal skew conditions if the lengths aren't matched. 2) The ratio of the stub length (the length of the PCB traces going into a drive) to the distance between devices should be 1:3. If you are plugging a ribbon cable into a drive, the trace is usually about 3.3cm, so you should have 10cm of cable between devices. 3) If the bus is going to be really long, you'll have a better chance of making it work if each device places a similar capacitive load on the bus. So, an enclosure fitted with identical drive models will often work better than if you mix and match. Put devices like tape and cdrom devices on a separate bus if possible. 4) SCSI cables can range from 90ohm to 140ohms of impedance. Favor the 90ohm part of the spectrum. You may have to go with twisted pair SCSI ribon cables to get near the 90ohm mark. 5) Use FPT terminators instead of the active terminator on the last device in the chain or an active external terminator. For narrow SCSI, you'll want an FPT-18 terminator (18 lines including the data lines are regulated by the FPT logic, the rest are actively terminated) or FPT-27 terminators for wide buses. FPT-3 terminators are also availible (REQ, ACK, and SEL are the only signals protected), so buyer beware. 6) Honor the 6m and 3m bus length limits. 6m is the longest for 10MHz and 3m is the longest for 20MHz single ended SCSI. This assumes proper stub/gap matching, so real life buses may need to be shorter. 7) If you still can't get your bus to work after tweaking all of these other things, go differential. One company that specializes in SCSI cabling and termination is CS Electronics. You can find their product offerings at their web site http://www.scsi-cables.com/. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sat Jun 7 01:52:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA06972 for freebsd-scsi-outgoing; Sat, 7 Jun 1997 01:52:55 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA06967 for ; Sat, 7 Jun 1997 01:52:51 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA22064; Sat, 7 Jun 1997 10:52:50 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id KAA01738; Sat, 7 Jun 1997 10:36:47 +0200 (MET DST) Message-ID: <19970607103646.LS18353@uriah.heep.sax.de> Date: Sat, 7 Jun 1997 10:36:46 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@freebsd.org Cc: tom@tomqnx.com (Tom Torrance at home) Subject: Re: CD-R & SCSI Problems References: <33984DF9.2781E494@whistle.com> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Tom Torrance at home on Jun 7, 1997 00:36:37 -0400 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Moved to the scsi list, that's what it is for.) As Tom Torrance at home wrote: > You are absolutely correct. ANother unfounded assumption bites the > dust. I have absolutely no idea what is causing this, it seems to > happen every time the tape is either opened or closed - and 'seems' > to cause no harm. Turn on SCSIDEBUG, and see which command is causing it. It might be a LOAD UNLOAD MEDIUM, or PREVENT ALLOW MEDIUM REMOVAL. > THe tape drive is an HP Colorado T4000 running off my ahc AHA-2740A. It wouldn't surprise me if the SCSI implementation of these drives weren't the brightest. We've recently seen similar (worse, i think) examples for a cheap Conner tape. The behaviour of this drive made me shout that it's apparently a drive that has a 50-pin connector looking like SCSI, but it isn't really SCSI. (It violated the specs all over the place, they didn't even bother to implement some mandatory commands.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sat Jun 7 10:23:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA27188 for freebsd-scsi-outgoing; Sat, 7 Jun 1997 10:23:14 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA27175 for ; Sat, 7 Jun 1997 10:23:09 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id KAA23082; Sat, 7 Jun 1997 10:22:47 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199706071722.KAA23082@GndRsh.aac.dev.com> Subject: Re: 3940uw with long cables In-Reply-To: <199706070047.SAA07204@pluto.plutotech.com> from "Justin T. Gibbs" at "Jun 6, 97 07:45:54 pm" To: gibbs@plutotech.com (Justin T. Gibbs) Date: Sat, 7 Jun 1997 10:22:47 -0700 (PDT) Cc: asami@cs.berkeley.edu, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Someone PLEASE PLEASE PLEASE put this in the handbook!!! > >Is this something that can be only cured by somehow shortening the > >cables? > > Perhaps. There are a few important things to keep in mind when > tuning the bus length. > > 1) Having equal distances between all devices is sometimes more > important than total bus length since the varying RC constants > can cause strange signal skew conditions if the lengths aren't > matched. ... [chopped to save traffic] ... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-scsi Sat Jun 7 12:01:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA01026 for freebsd-scsi-outgoing; Sat, 7 Jun 1997 12:01:42 -0700 (PDT) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA01020 for ; Sat, 7 Jun 1997 12:01:39 -0700 (PDT) Received: by iafnl.es.iaf.nl with UUCP id AA28214 (5.67b/IDA-1.5 for scsi@FreeBSD.ORG); Sat, 7 Jun 1997 21:01:48 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.7.5/8.6.12) id UAA00806; Sat, 7 Jun 1997 20:31:18 +0200 (MET DST) From: Wilko Bulte Message-Id: <199706071831.UAA00806@yedi.iaf.nl> Subject: Re: 3940uw with long cables To: gibbs@plutotech.com (Justin T. Gibbs) Date: Sat, 7 Jun 1997 20:31:18 +0200 (MET DST) Cc: asami@cs.berkeley.edu, scsi@FreeBSD.ORG In-Reply-To: <199706070047.SAA07204@pluto.plutotech.com> from "Justin T. Gibbs" at Jun 6, 97 07:45:54 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Justin T. Gibbs wrote... > Perhaps. There are a few important things to keep in mind when > tuning the bus length. > > 1) Having equal distances between all devices is sometimes more > important than total bus length since the varying RC constants > can cause strange signal skew conditions if the lengths aren't > matched. In addition to this: don't use both the internal and the external connector of a SCSI adapter (assuming the internal & external connector are on the same bus). The differences in external versus internal (flat)cable are also no-good. > 6) Honor the 6m and 3m bus length limits. 6m is the longest for 10MHz > and 3m is the longest for 20MHz single ended SCSI. This assumes > proper stub/gap matching, so real life buses may need to be shorter. Hm. The company I work for (==DEC) uses the rule that a single ended F10 (10MHz) bus can be a max of 3 meters. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-scsi Sat Jun 7 12:07:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA01249 for freebsd-scsi-outgoing; Sat, 7 Jun 1997 12:07:46 -0700 (PDT) Received: from TomQNX.tomqnx.com (root@ott-pm1-14.comnet.ca [206.75.140.14]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA01243 for ; Sat, 7 Jun 1997 12:07:39 -0700 (PDT) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m0waQnx-000A2UC; Sat, 7 Jun 1997 15:05:37 -0400 (EDT) Message-Id: From: tom@tomqnx.com (Tom Torrance at home) Subject: Re: CD-R & SCSI Problems In-Reply-To: <19970607103646.LS18353@uriah.heep.sax.de> from J Wunsch at "Jun 7, 97 10:36:46 am" To: joerg_wunsch@uriah.heep.sax.de Date: Sat, 7 Jun 1997 15:05:37 -0400 (EDT) Cc: scsi@freebsd.org, tom@tomqnx.com X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > (Moved to the scsi list, that's what it is for.) > > As Tom Torrance at home wrote: > > > You are absolutely correct. ANother unfounded assumption bites the > > dust. I have absolutely no idea what is causing this, it seems to > > happen every time the tape is either opened or closed - and 'seems' > > to cause no harm. > > Turn on SCSIDEBUG, and see which command is causing it. It might be a > LOAD UNLOAD MEDIUM, or PREVENT ALLOW MEDIUM REMOVAL. Tried that. No additional information was output. > > THe tape drive is an HP Colorado T4000 running off my ahc AHA-2740A. Actually reports at boot as: "HP T4000s 1.07" type 1 removeable SCSI 2 This is the latest and greatest 4-8 GB Travan drive. > It wouldn't surprise me if the SCSI implementation of these drives > weren't the brightest. We've recently seen similar (worse, i think) > examples for a cheap Conner tape. The behaviour of this drive made me > shout that it's apparently a drive that has a 50-pin connector looking > like SCSI, but it isn't really SCSI. (It violated the specs all over > the place, they didn't even bother to implement some mandatory > commands.) Before the problems started, (while I was doing 'make world'), I decided to backup my Windows 95 machine, so I plugged it into that one, and did a backup with the supplied software. Naturally, I used compressed mode. The drive was never powered off since then as it has no on/off switch. The following is the output of an 'mt status' now: /kernel: st0(ahc0:6:0): ILLEGAL REQUEST asc:20,0 Invalid command operation code Present Mode: Density = 0x45 Blocksize = 512 bytes ---------available modes--------- Mode 0: Density = 0x00 Blocksize variable Mode 1: Density = X3.136-1986 Blocksize = 512 bytes Mode 2: Density = X3.39-1986 Blocksize variable Mode 3: Density = X3.54-1986 Blocksize variable Is there any possibility that the density table listed in scsiconf.h is seriously out of date? > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) > Regards, Tom From owner-freebsd-scsi Sat Jun 7 13:10:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA03583 for freebsd-scsi-outgoing; Sat, 7 Jun 1997 13:10:58 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA03577 for ; Sat, 7 Jun 1997 13:10:52 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id OAA09837; Sat, 7 Jun 1997 14:10:45 -0600 (MDT) Message-Id: <199706072010.OAA09837@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Wilko Bulte cc: scsi@FreeBSD.ORG Subject: Re: 3940uw with long cables In-reply-to: Your message of "Sat, 07 Jun 1997 20:31:18 +0200." <199706071831.UAA00806@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Jun 1997 14:10:45 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > In addition to this: don't use both the internal and the external > connector of a SCSI adapter (assuming the internal & external > connector are on the same bus). The differences in external versus > internal (flat)cable are also no-good. this has been my experience also. to get around this problem I use flat cables both internally and externally when I need to go both directions. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-scsi Sat Jun 7 14:54:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA09947 for freebsd-scsi-outgoing; Sat, 7 Jun 1997 14:54:00 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA09932 for ; Sat, 7 Jun 1997 14:53:55 -0700 (PDT) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id XAA00423; Sat, 7 Jun 1997 23:53:45 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.8.5) id XAA04072; Sat, 7 Jun 1997 23:45:48 +0200 (MET DST) Message-ID: <19970607234548.VE42744@uriah.heep.sax.de> Date: Sat, 7 Jun 1997 23:45:48 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@freebsd.org Cc: tom@tomqnx.com (Tom Torrance at home) Subject: Re: CD-R & SCSI Problems References: <19970607103646.LS18353@uriah.heep.sax.de> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Tom Torrance at home on Jun 7, 1997 15:05:37 -0400 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Tom Torrance at home wrote: > > Turn on SCSIDEBUG, and see which command is causing it. It might be a > > LOAD UNLOAD MEDIUM, or PREVENT ALLOW MEDIUM REMOVAL. > > Tried that. No additional information was output. Hmm, i forgot to mention that you need to actually turn it on using something like scsi -f /dev/rst0.ctl -d 0x7f (Don't ask me for the actual meaning of the possible numbers after the -d, i've never got a clue about them.) > Present Mode: Density = 0x45 Blocksize = 512 bytes That's probably a vendor density code for the compressed mode. Density codes 0x15 through 0x7e are marked as `reserved' in the SCSI-2 specs. I have no idea what the SCSI-3 drafts say about them. > Is there any possibility that the density table listed in > scsiconf.h is seriously out of date? It's the table from the SCSI-2 specs, and as such, represents the official standard. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)