From owner-freebsd-scsi Sun Apr 8 0:59: 6 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by hub.freebsd.org (Postfix) with ESMTP id 3A3DA37B424 for ; Sun, 8 Apr 2001 00:58:59 -0700 (PDT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id C4A6F17D24; Sun, 8 Apr 2001 09:58:57 +0200 (CEST) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.11.1/8.11.1) id f387vX701072; Sun, 8 Apr 2001 09:57:33 +0200 (CEST) (envelope-from schweikh) Date: Sun, 8 Apr 2001 09:57:33 +0200 From: Jens Schweikhardt To: "Justin T. Gibbs" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Trouble with timeouts after installing an U160LVD Message-ID: <20010408095733.A581@schweikhardt.net> References: <20010407195642.A1309@schweikhardt.net> <200104071818.f37IIas88838@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104071818.f37IIas88838@aslan.scsiguy.com>; from gibbs@scsiguy.com on Sat, Apr 07, 2001 at 12:18:36PM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin, On Sat, Apr 07, 2001 at 12:18:36PM -0600, Justin T. Gibbs wrote: # > # >hello, world\n # > # >I bought me a brand new shiny IBM DDYS-T18350N Ultra160LVD drive. My # >host adapter at this time does not support U160 SCSI, it's an ASUS P2L97S with # >on-board SCSI provided by an Adaptec AIC 7880. My understanding however # >is that the U160 drive will adapt to the slower bus (I may well be doing # >something silly here...) , which it apparently does (snippet from # >dmesg): # # What version of FreeBSD are you using? If you boot verbose, what messages # are printed while probing the SCSI controller? It may be that the # driver is not properly enabling termination. It could also be that one # of your cables is marginal. It's a 4.2-R system. Here's the relevant part of the verbose boot (without the new DDYS-T18350N because this makes the system hard to use). The 68pin cable is about 60cm with 4 connectors every 20cm. The active terminator was way expensive (DM50 = US$25). The 50pin cable is 150cm long, with 8 connectors spaced 1--------2-3-4-5-6-7-8, aic7880 being at position 1, the terminated IBM DCAS at position 8 and other unterminated SCSI2 devices at 5 and 7. I'll try different cables as soon as I can get hold of one. Thanks for your aid in tracking this down. Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.2-RELEASE #0: Wed Apr 4 19:13:21 CEST 2001 toor@hal9000.schweikhardt.net:/usr/src/sys/compile/HAL9000 ... ahc0: port 0xd000-0xd0ff mem 0xdf800000-0xdf800fff irq 15 at device 6.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: High byte termination Enabled ahc0: Downloading Sequencer Program... 432 instructions downloaded aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs using shared irq15. ... (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. (probe3:ahc0:0:3:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe3:ahc0:0:3:0): ILLEGAL REQUEST asc:24,0 (probe3:ahc0:0:3:0): Invalid field in CDB (probe4:ahc0:0:4:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe4:ahc0:0:4:0): ILLEGAL REQUEST asc:24,0 (probe4:ahc0:0:4:0): Invalid field in CDB (ahc0:A:3:0): Sending SDTR period c, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f ahc0: target 3 synchronous at 10.0MHz, offset = 0xf (ahc0:A:4:0): Sending SDTR period c, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f ahc0: target 4 synchronous at 10.0MHz, offset = 0xf (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:2:0): Sending SDTR period c, offset f (ahc0:A:2:0): Received SDTR period c, offset f Filtered to period c, offset f ahc0: target 2 synchronous at 20.0MHz, offset = 0xf (ahc0:A:8:0): Sending WDTR 1 (ahc0:A:8:0): Received WDTR 1 filtered to 1 ahc0: target 8 using 16bit transfers (ahc0:A:8:0): Sending SDTR period c, offset 8 (ahc0:A:8:0): Received SDTR period c, offset 8 Filtered to period c, offset 8 ahc0: target 8 synchronous at 20.0MHz, offset = 0x8 Creating DISK da0 Creating DISK da1 Creating DISK cd0 Creating DISK cd1 pass0 at ahc0 bus 0 target 2 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number F3T57609 pass0: 20.000MB/s transfers (20.000MHz, offset 15) pass1 at ahc0 bus 0 target 3 lun 0 pass1: Removable CD-ROM SCSI-2 device pass1: 10.000MB/s transfers (10.000MHz, offset 15) pass2 at ahc0 bus 0 target 4 lun 0 pass2: Removable CD-ROM SCSI-2 device pass2: 10.000MB/s transfers (10.000MHz, offset 15) pass3 at ahc0 bus 0 target 8 lun 0 pass3: Fixed Direct Access SCSI-2 device pass3: Serial Number 50000826 pass3: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1 at ahc0 bus 0 target 8 lun 0 da1: Fixed Direct Access SCSI-2 device da1: Serial Number 50000826 da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 17422MB (35680750 512 byte sectors: 255H 63S/T 2221C) Mounting root from ufs:da0s1g (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (cd1:ahc0:0:4:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd1:ahc0:0:4:0): NOT READY asc:3a,0 (cd1:ahc0:0:4:0): Medium not present cd1 at ahc0 bus 0 target 4 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 10.000MB/s transfers (10.000MHz, offset 15) cd1: Attempt to query device size failed: NOT READY, Medium not present da0 at ahc0 bus 0 target 2 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number F3T57609 da0: 20.000MB/s transfers (20.000MHz, offset 15) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da0s1: type 0xa5, start 63, end = 6538454, size 6538392 : OK da0s2: type 0xa5, start 6538455, end = 8466254, size 1927800 : OK start_init: trying /sbin/init (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f da1s1: type 0xa5, start 63, end = 8916074, size 8916012 : OK da1s2: type 0xa5, start 8916075, end = 17832149, size 8916075 : OK da1s3: type 0xa5, start 17832150, end = 26748224, size 8916075 : OK da1s4: type 0xa5, start 26748225, end = 35680364, size 8932140 : OK (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f i4b: unit 0, assigned TEI = 103 = 0x67 (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:3:0): Sending SDTR period 19, offset f (ahc0:A:3:0): Received SDTR period 19, offset f Filtered to period 19, offset f ...This repeats at 3Hz for a minute until this comes: (cd0:ahc0:0:3:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ahc0:0:3:0): NOT READY asc:3a,1 (cd0:ahc0:0:3:0): Medium not present - tray closed cd0 at ahc0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed 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 Sun Apr 8 7: 3:14 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp5.xs4all.nl (smtp5.xs4all.nl [194.109.6.49]) by hub.freebsd.org (Postfix) with ESMTP id 9B74F37B422 for ; Sun, 8 Apr 2001 07:03:07 -0700 (PDT) (envelope-from cor@xs4all.net) Received: from xs4.xs4all.nl (cor@xs4.xs4all.nl [194.109.6.45]) by smtp5.xs4all.nl (8.9.3/8.9.3) with ESMTP id QAA02818 for ; Sun, 8 Apr 2001 16:03:06 +0200 (CEST) Received: (from cor@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) id QAA04705 for freebsd-scsi@freebsd.org; Sun, 8 Apr 2001 16:03:06 +0200 (CEST) Date: Sun, 8 Apr 2001 16:03:06 +0200 (CEST) From: Cor Bosman Message-Id: <200104081403.QAA04705@xs4.xs4all.nl> To: freebsd-scsi@freebsd.org Subject: parity error Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, I tried upgrading a box from 4.1-rel to 4.2-rel. This box has been running for about 7 months as a heavily used diablo news server. It's got a vinum mirror filesystem. After installing 4.2 I suddenly got: (da2:ahc0:0:1:0): parity error detected in Data-in phase. SEQADDR(0x19f) SCSIRATE(0xc2) CRC Value Mismatch (da2:ahc0:0:1:0): parity error detected in Data-in phase. SEQADDR(0x4b) SCSIRATE(0xc2) CRC Value Mismatch (da2:ahc0:0:1:0): parity error detected in Data-in phase. SEQADDR(0x83) SCSIRATE(0xc2) CRC Value Mismatch (da2:ahc0:0:1:0): parity error detected in Data-in phase. SEQADDR(0x54) SCSIRATE(0xc2) CRC Value Mismatch (da2:ahc0:0:1:0): parity error detected in Data-in phase. SEQADDR(0x4b) SCSIRATE(0xc2) CRC Value Mismatch And so on. One of the vinum mirrors is then corrupt, and I cant revive it. First thought ofcourse is a bad disk. But since this box has been running flawlessly for months I tried booting with a 4.1 kernel again. And then im suddenly able to revive the vinum mirror again, and no more parity errors occur. Reboot into 4.2, and i immediately get parity errors again. And so on. Anyone seen this before? Bad disk or cable even though 4.1 doesnt complain? Or maybe go to stable? Here's the dmesg output. FreeBSD 4.1-RELEASE #1: Sun Apr 8 04:59:20 CEST 2001 root@:/usr/src/sys/compile/TRANSIT Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (746.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x387fbff real memory = 1073676288 (1048512K bytes) avail memory = 1042706432 (1018268K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02de000. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib2: at device 1.0 on pci0 pci1: on pcib2 pcib3: at device 15.0 on pci1 pci2: on pcib3 pcib4: at device 4.0 on pci2 pci3: on pcib4 ahc0: port 0x3000-0x30ff mem 0xf4200000-0xf4200fff irq 20 at device 4.0 on pci3 ahc0: aic7892 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: port 0x2000-0x20ff mem 0xf4100000-0xf4100fff irq 19 at device 12.0 on pci0 ahc1: aic7896/97 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc2: port 0x2400-0x24ff mem 0xf4101000-0xf4101fff irq 19 at device 12.1 on pci0 ahc2: aic7896/97 Wide Channel B, SCSI Id=7, 16/255 SCBs fxp0: port 0x2800-0x283f mem 0xf4000000-0xf40fffff,0xf4102000-0xf4102fff irq 21 at device 14.0 on pci0 fxp0: Ethernet address 00:d0:b7:88:50:ee isab0: at device 18.0 on pci0 isa0: on isab0 pci0: at 18.1 pci0: at 18.2 irq 21 Timecounter "PIIX" frequency 3579545 Hz chip1: port 0x1040-0x104f at device 18.3 on pci0 pci0: at 20.0 pcib1: on motherboard pci4: on pcib1 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 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Waiting 15 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da0s1a da0 at ahc1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da4 at ahc0 bus 0 target 3 lun 0 da4: Fixed Direct Access SCSI-3 device da4: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da4: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da3 at ahc0 bus 0 target 2 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da3: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da2 at ahc0 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da2: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da7 at ahc0 bus 0 target 6 lun 0 da7: Fixed Direct Access SCSI-3 device da7: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da7: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da6 at ahc0 bus 0 target 5 lun 0 da6: Fixed Direct Access SCSI-3 device da6: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da6: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da5 at ahc0 bus 0 target 4 lun 0 da5: Fixed Direct Access SCSI-3 device da5: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da5: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da8 at ahc0 bus 0 target 8 lun 0 da8: Fixed Direct Access SCSI-3 device da8: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da8: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 8 8:24:14 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 77FAC37B424 for ; Sun, 8 Apr 2001 08:24:12 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f38FNRs98477; Sun, 8 Apr 2001 09:23:38 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200104081523.f38FNRs98477@aslan.scsiguy.com> To: Cor Bosman Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: parity error In-Reply-To: Your message of "Sun, 08 Apr 2001 16:03:06 +0200." <200104081403.QAA04705@xs4.xs4all.nl> Date: Sun, 08 Apr 2001 09:23:27 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >And then im suddenly able to revive the vinum mirror again, and no more >parity errors occur. Reboot into 4.2, and i immediately get parity errors >again. And so on. Anyone seen this before? Bad disk or cable even though >4.1 doesnt complain? Or maybe go to stable? IIRC, 4.1R did not run the U160 controllers in U160 mode. By booting back to 4.1, you effectively reduce the negotiated transfer speed and avoid stressing the bus to the point of failure. The moral of the story is that some part of your bus is not up to running at 160MB/s. It could be the cable, or the terminator, or the bus length. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 8 23:12:49 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from relay.comm2000.it (mindseal.comm2000.it [194.133.0.6]) by hub.freebsd.org (Postfix) with ESMTP id C6CD237B422 for ; Sun, 8 Apr 2001 23:12:44 -0700 (PDT) (envelope-from massimo@datacode.it) Received: from purtroppo.local.lan ([212.97.62.126]) by relay.comm2000.it (8.11.2/MFAGMM-19990726) with ESMTP id f396COI05065; Mon, 9 Apr 2001 08:12:24 +0200 X-SMTP-Peer: [212.97.62.126] Received: (from nobody@localhost) by purtroppo.local.lan (8.11.3/8.11.3) id f39692p03810; Mon, 9 Apr 2001 08:09:02 +0200 (CEST) (envelope-from massimo@datacode.it) X-Authentication-Warning: purtroppo.local.lan: nobody set sender to massimo@datacode.it using -f To: "Justin T. Gibbs" Subject: Re: Trouble with timeouts after installing an U160LVD Message-ID: <986796542.3ad151fed36af@webapps.datacode.it> Date: Mon, 09 Apr 2001 08:09:02 +0200 (CEST) From: Massimo Lusetti Cc: freebsd-scsi@freebsd.org References: <200104071818.f37IIas88838@aslan.scsiguy.com> In-Reply-To: <200104071818.f37IIas88838@aslan.scsiguy.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Scrive "Justin T. Gibbs" : > > > >hello, world\n > > > >I bought me a brand new shiny IBM DDYS-T18350N Ultra160LVD drive. My > >host adapter at this time does not support U160 SCSI, it's an ASUS > P2L97S with > >on-board SCSI provided by an Adaptec AIC 7880. My understanding > however > >is that the U160 drive will adapt to the slower bus (I may well be > doing > >something silly here...) , which it apparently does (snippet from > >dmesg): > > What version of FreeBSD are you using? If you boot verbose, what > messages > are printed while probing the SCSI controller? It may be that the > driver is not properly enabling termination. It could also be that > one > of your cables is marginal. Well, here i've the same problem on a Netfinity x220 with aic7892, i've replaced the cable and things are going slitghly better but error message came out sometime. I don't think i've hardware problem cause Linux and Window$ on the same machine work without any problem. Or do you tell me that FreeBSD is much more fine tuned ot catch that error ? :) Regards. ----- Massimo Lusetti Network Department Manager url: http://www.datacode.it email: info@datacode.it ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 9 4:59: 0 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mail-internal.nextra.de (mail.nextra.de [212.169.184.81]) by hub.freebsd.org (Postfix) with ESMTP id 0BFCA37B423 for ; Mon, 9 Apr 2001 04:58:58 -0700 (PDT) (envelope-from O.Blasnik@nextra.de) Received: from f-ex-01.intern.nextra.de (f-euro.fw.nextra.de [212.169.184.9]) by mail-internal.nextra.de (8.9.3/8.9.3) with ESMTP id NAA92579 for ; Mon, 9 Apr 2001 13:58:51 +0200 (CEST) Received: from omnilinkw63 ([10.49.96.101]) by f-ex-01.intern.nextra.de with Microsoft SMTPSVC(5.0.2195.1600); Mon, 9 Apr 2001 13:54:37 +0100 Message-ID: <017601c0c0ec$c2f2f0d0$6560310a@intern.nextra.de> From: "Oliver Blasnik" To: Subject: Support for Adaptec 7899W/7902 U320? Date: Mon, 9 Apr 2001 14:01:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-OriginalArrivalTime: 09 Apr 2001 12:54:37.0091 (UTC) FILETIME=[3B9A8730:01C0C0F4] Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, hi Justin, is this already supported in -current? There's a nice Serverboard with them on, and it will help me to decide. Thanks, Oliver -- -- http://www.nextra.de - INTERNET@WORK ----- oliver.blasnik@nextra.de -- Nextra Deutschland | Oliver Blasnik Senior System Administrator GmbH & Co KG | Lyoner Strasse 26 D-60528 Frankfurt Engineering TA&S | tel +49-69-66441-0 fax +49-69-66441-199 ------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 9 6:54:52 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 9E5E137B423 for ; Mon, 9 Apr 2001 06:54:50 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f39Dsjs10913; Mon, 9 Apr 2001 07:54:45 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200104091354.f39Dsjs10913@aslan.scsiguy.com> To: "Oliver Blasnik" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Support for Adaptec 7899W/7902 U320? In-Reply-To: Your message of "Mon, 09 Apr 2001 14:01:07 +0200." <017601c0c0ec$c2f2f0d0$6560310a@intern.nextra.de> Date: Mon, 09 Apr 2001 07:54:45 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Hi all, hi Justin, > >is this already supported in -current? >There's a nice Serverboard with them on, and it will help me to decide. The 7902 hasn't shipped yet. The 7899W has been supported since 4.2R. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 9 7:14:11 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mail-internal.nextra.de (mail.nextra.de [212.169.184.81]) by hub.freebsd.org (Postfix) with ESMTP id 153A937B423 for ; Mon, 9 Apr 2001 07:14:09 -0700 (PDT) (envelope-from O.Blasnik@nextra.de) Received: from f-ex-01.intern.nextra.de (f-euro.fw.nextra.de [212.169.184.9]) by mail-internal.nextra.de (8.9.3/8.9.3) with ESMTP id QAA97298; Mon, 9 Apr 2001 16:13:58 +0200 (CEST) Received: from omnilinkw63 ([10.49.96.101]) by f-ex-01.intern.nextra.de with Microsoft SMTPSVC(5.0.2195.1600); Mon, 9 Apr 2001 16:09:43 +0100 Message-ID: <023001c0c0ff$a2cf4520$6560310a@intern.nextra.de> From: "Oliver Blasnik" To: "Oliver Blasnik" , "Justin T. Gibbs" Cc: References: <200104091354.f39Dsjs10913@aslan.scsiguy.com> Subject: Re: Support for Adaptec 7899W/7902 U320? Date: Mon, 9 Apr 2001 16:16:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-OriginalArrivalTime: 09 Apr 2001 15:09:43.0299 (UTC) FILETIME=[1B47B530:01C0C107] Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Justin wrote: > The 7902 hasn't shipped yet. This explains why I could not get clear infos about ;) > The 7899W has been supported since 4.2R. Yes :/ I do have them in use ;) (first think, _then_ write...) I have sthg in mind that the 7902 is an addon / accelerator for raid, is that correct? > Justin Cu, Oliver -- -- http://www.nextra.de - INTERNET@WORK ----- oliver.blasnik@nextra.de -- Nextra Deutschland | Oliver Blasnik Senior System Administrator GmbH & Co KG | Lyoner Strasse 26 D-60528 Frankfurt Engineering TA&S | tel +49-69-66441-0 fax +49-69-66441-199 ------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 9 7:34:19 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 660E537B422 for ; Mon, 9 Apr 2001 07:34:17 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f39EXbs11298; Mon, 9 Apr 2001 08:34:12 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200104091434.f39EXbs11298@aslan.scsiguy.com> To: "Oliver Blasnik" Cc: "Oliver Blasnik" , freebsd-scsi@FreeBSD.ORG Subject: Re: Support for Adaptec 7899W/7902 U320? In-Reply-To: Your message of "Mon, 09 Apr 2001 16:16:10 +0200." <023001c0c0ff$a2cf4520$6560310a@intern.nextra.de> Date: Mon, 09 Apr 2001 08:33:37 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I have sthg in mind that the 7902 is an addon / accelerator for >raid, is that correct? The 7902 is Adaptec's U320 chip. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 9 7:39:28 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from hercules.icarz.com (ns1.icarz.com [207.99.22.7]) by hub.freebsd.org (Postfix) with ESMTP id 10A1937B422 for ; Mon, 9 Apr 2001 07:39:25 -0700 (PDT) (envelope-from kenm@icarz.com) Received: from newken (dhcp113.icarz.com [207.99.22.113]) by hercules.icarz.com (8.10.1/8.10.1) with SMTP id f39ENm206300 for ; Mon, 9 Apr 2001 10:23:49 -0400 (EDT) Message-ID: <00c201c0c100$b25bdf20$711663cf@icarz.com> From: "Ken Menzel" To: Subject: 'ch' Errors using chio w-sony changer Date: Mon, 9 Apr 2001 10:23:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi All, I have looked at the man pages and manual and archives and source for chio. My 'guess' is that there is soemthing in the return of the status of the drive that the 'ch' driver doesn't like. The error is a follows: janeway# chio return drive 0 chio: /dev/ch0: CHIOGSTATUS: Invalid argument And /var/log/messages gets: Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): READ ELEMENT STATUS. CDB: b8 30 0 1 0 1 0 0 4 0 0 0 Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): ILLEGAL REQUEST asc:24,0 Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): Invalid field in CDB sks:cc,1 However: janeway# chio status picker 0: slot 0: slot 1: slot 2: slot 3: slot 4: slot 5: slot 6: slot 7: drive 0: dmesg reports: ch0 at ahc0 bus 0 target 6 lun 1 ch0: Removable Changer SCSI-2 device ch0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) ch0: 8 slots, 1 drive, 1 picker, 0 portals chio params /dev/ch0: 8 slots, 1 drive, 1 picker /dev/ch0: current picker: 0 janeway# The only thing I can't seem to do is move a tape! Can anyone point me in the right direction? The kernel is compiled with CAMDEBUG if that helps. Thanks in advance, Ken ----------------------------------------------------- Ken Menzel ICQ# 9325188 www.icarz.com kenm@icarz.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 9 9:21:41 2001 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 7104737B424 for ; Mon, 9 Apr 2001 09:21:36 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id KAA82714; Mon, 9 Apr 2001 10:21:15 -0600 (MDT) (envelope-from ken) Date: Mon, 9 Apr 2001 10:21:14 -0600 From: "Kenneth D. Merry" To: Ken Menzel Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: 'ch' Errors using chio w-sony changer Message-ID: <20010409102114.A82661@panzer.kdm.org> References: <00c201c0c100$b25bdf20$711663cf@icarz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <00c201c0c100$b25bdf20$711663cf@icarz.com>; from kenm@icarz.com on Mon, Apr 09, 2001 at 10:23:49AM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Apr 09, 2001 at 10:23:49 -0400, Ken Menzel wrote: > Hi All, > I have looked at the man pages and manual and archives and source > for chio. My 'guess' is that there is soemthing in the return of the > status of the drive that the 'ch' driver doesn't like. The error is a > follows: > > janeway# chio return drive 0 > chio: /dev/ch0: CHIOGSTATUS: Invalid argument > > And /var/log/messages gets: > > Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): READ ELEMENT > STATUS. CDB: b8 > 30 0 1 0 1 0 0 4 0 0 0 > Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): ILLEGAL REQUEST > asc:24,0 > Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): Invalid field in > CDB sks:cc,1 Have you tried 'chio move'? > However: > janeway# chio status > picker 0: > slot 0: > slot 1: > slot 2: > slot 3: > slot 4: > slot 5: > slot 6: > slot 7: > drive 0: Can you send the output of 'chio status -S'? > dmesg reports: > ch0 at ahc0 bus 0 target 6 lun 1 > ch0: Removable Changer SCSI-2 device > ch0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > ch0: 8 slots, 1 drive, 1 picker, 0 portals > > chio params > /dev/ch0: 8 slots, 1 drive, 1 picker > /dev/ch0: current picker: 0 > janeway# > > The only thing I can't seem to do is move a tape! Can anyone point me > in the right direction? The kernel is compiled with CAMDEBUG if that > helps. Well, first off, you can only 'return' something if it has a valid source address. chio status -S will likely tell you if that is the case. If it doesn't have a valid source address (this can happen if the drive doesn't support source element addresses or if the changer was powered on or reset after the element made it into its current location), you can't return it. chio move should always work, as long as the source and destination are valid. 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 Apr 9 10: 3:20 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from relay2.mail.uk.psi.net (relay2.mail.uk.psi.net [154.32.107.6]) by hub.freebsd.org (Postfix) with ESMTP id 572B437B422 for ; Mon, 9 Apr 2001 10:03:17 -0700 (PDT) (envelope-from dbhague@allstor-sw.co.uk) Received: from mail.plasmon.co.uk ([193.115.5.217]) by relay2.mail.uk.psi.net with esmtp (Exim 2.12 #2) id 14mf4M-0006qJ-00 for freebsd-scsi@FreeBSD.ORG; Mon, 9 Apr 2001 18:03:15 +0100 From: dbhague@allstor-sw.co.uk Subject: SCSI transfer sizes, To: freebsd-scsi@FreeBSD.ORG Date: Mon, 9 Apr 2001 18:02:44 +0100 Message-ID: X-MIMETrack: Serialize by Router on Melbourn01/SVR/Plasmon(Release 5.0.6a |January 17, 2001) at 04/09/2001 06:03:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We having been doing performance optimisation on optical drives. These are particularly sensitive to transfer size and we would like your advice as to which adapter card would give us the largest possible transfer size. We have noticed between 3.0 and 4.2 the standard transfer size has changed from 128KB to 60KB. After some experimentation we have taken Adaptec up to 256KB but Symbios only goes to 128KB before we have problems. Could you help by advising us on the adapter that will allow us to use the largest transfer size for each SCSI operation ? Regards Dave To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 9 14:55:56 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 7563637B423 for ; Mon, 9 Apr 2001 14:55:53 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f39Lsgs19172; Mon, 9 Apr 2001 15:55:43 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200104092155.f39Lsgs19172@aslan.scsiguy.com> To: Jens Schweikhardt Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Trouble with timeouts after installing an U160LVD In-Reply-To: Your message of "Sun, 08 Apr 2001 09:57:33 +0200." <20010408095733.A581@schweikhardt.net> Date: Mon, 09 Apr 2001 15:54:42 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >It's a 4.2-R system. Here's the relevant part of the verbose boot >(without the new DDYS-T18350N because this makes the system hard to >use). The 68pin cable is about 60cm with 4 connectors every 20cm. The >active terminator was way expensive (DM50 = US$25). The 50pin cable is >150cm long, with 8 connectors spaced 1--------2-3-4-5-6-7-8, aic7880 >being at position 1, the terminated IBM DCAS at position 8 and other >unterminated SCSI2 devices at 5 and 7. The narrow cable is quite long. You might try distributing the devices more evenly along the cable. This gives better transmission line qualities. One other thing that might be affecting you is the firmware version on the DDYS drive. S80D is really bad. The latest is S96H. >(ahc0:A:3:0): Sending SDTR period 19, offset f >(ahc0:A:3:0): Received SDTR period 19, offset f > Filtered to period 19, offset f > >...This repeats at 3Hz for a minute until this comes: That's to be expected. Any time a check condition occurs without a data transfer, we renegotiate. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 9 16:22:37 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from ct980320-b.blmngtn1.in.home.com (ct980320-b.blmngtn1.in.home.com [65.8.207.32]) by hub.freebsd.org (Postfix) with ESMTP id 8A34E37B422 for ; Mon, 9 Apr 2001 16:22:35 -0700 (PDT) (envelope-from mikes@ct980320-b.blmngtn1.in.home.com) Received: (from mikes@localhost) by ct980320-b.blmngtn1.in.home.com (8.11.1/8.11.1) id f39NMHL03140 for freebsd-scsi@freebsd.org; Mon, 9 Apr 2001 18:22:17 -0500 (EST) (envelope-from mikes) From: Mike Squires Message-Id: <200104092322.f39NMHL03140@ct980320-b.blmngtn1.in.home.com> Subject: Re: 'ch' Errors using chio w-sony changer In-Reply-To: <20010409102114.A82661@panzer.kdm.org> "from Kenneth D. Merry at Apr 9, 2001 10:21:14 am" To: freebsd-scsi@freebsd.org Date: Mon, 9 Apr 2001 18:22:17 -0500 (EST) X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > janeway# chio return drive 0 chio move drive 0 slot 0 worked. MLS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 9 16:30:57 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from england.inhouse (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id 4A48137B42C for ; Mon, 9 Apr 2001 16:30:54 -0700 (PDT) (envelope-from eric@estinc.com) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by england.inhouse (8.9.3/8.9.3) with ESMTP id QAA15608; Mon, 9 Apr 2001 16:32:16 -0700 Date: Mon, 9 Apr 2001 16:32:16 -0700 (MST) From: Eric Lee Green X-Sender: eric@england.inhouse To: "Kenneth D. Merry" Cc: Ken Menzel , freebsd-scsi@FreeBSD.ORG Subject: Re: 'ch' Errors using chio w-sony changer In-Reply-To: <20010409102114.A82661@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 9 Apr 2001, Kenneth D. Merry wrote: > On Mon, Apr 09, 2001 at 10:23:49 -0400, Ken Menzel wrote: > > Hi All, > > I have looked at the man pages and manual and archives and source > > for chio. My 'guess' is that there is soemthing in the return of the > > status of the drive that the 'ch' driver doesn't like. The error is a > > follows: > > > > janeway# chio return drive 0 > > chio: /dev/ch0: CHIOGSTATUS: Invalid argument > > > > And /var/log/messages gets: > > > > Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): READ ELEMENT > > STATUS. CDB: b8 > > 30 0 1 0 1 0 0 4 0 0 0 > > Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): ILLEGAL REQUEST > > asc:24,0 > > Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): Invalid field in > > CDB sks:cc,1 Let's see. b8 is read element status alright. But what's that 30? According to my trusty T10 SMC draft specs, 30 is an illegal byte 1 for a Read Element Status command. If it was 03 you would be requesting import/export elements, if it was 10 you'd be requesting anything with bar codes, but 30... no. Bits 6 and 5 are reserved, according to the T10 specs. (bit 4 is okay, that's the voltag bit). Do note that the above message IS normal if you send a bit 4 in byte 1 of the CDB to autoloaders which have no bar code reader. They spit up, and at least in mtx I then back down to a plain 00 for byte 1 of the CDB (no bar codes). Thus that entry in /var/log/messages is not an error, assuming that chio does a similar thing (backs off and tries to get status without bar codes). > Have you tried 'chio move'? > > > However: > > janeway# chio status > > picker 0: > > slot 0: > > Can you send the output of 'chio status -S'? > > Well, first off, you can only 'return' something if it has a valid source > address. chio status -S will likely tell you if that is the case. Another possibility: Many loaders require you to eject the tape from the drive prior to returning it to its source slot. I have no idea if chio deals with that situation. I know I don't deal with it in mtx (http://mtx.sourceforge.net), I just blithely spew guts all over and expect you to figure it out for yourself. -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 9 16:47:19 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 9B41737B422 for ; Mon, 9 Apr 2001 16:47:17 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f39NkDs21942; Mon, 9 Apr 2001 17:46:23 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200104092346.f39NkDs21942@aslan.scsiguy.com> To: Eric Lee Green Cc: "Kenneth D. Merry" , Ken Menzel , freebsd-scsi@FreeBSD.ORG Subject: Re: 'ch' Errors using chio w-sony changer In-Reply-To: Your message of "Mon, 09 Apr 2001 16:32:16 PDT." Date: Mon, 09 Apr 2001 17:46:13 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Let's see. b8 is read element status alright. But what's that 30? >According to my trusty T10 SMC draft specs, 30 is an illegal byte 1 for a >Read Element Status command. If it was 03 you would be requesting >import/export elements, if it was 10 you'd be requesting anything with bar >codes, but 30... no. Bits 6 and 5 are reserved, according to the T10 >specs. (bit 4 is okay, that's the voltag bit). This is a SCSI2 changer, so the top three bits of byte one are always the lun. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 9 16:51:48 2001 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 9B21F37B424 for ; Mon, 9 Apr 2001 16:51:43 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id RAA86508; Mon, 9 Apr 2001 17:51:37 -0600 (MDT) (envelope-from ken) Date: Mon, 9 Apr 2001 17:51:37 -0600 From: "Kenneth D. Merry" To: Eric Lee Green Cc: Ken Menzel , freebsd-scsi@FreeBSD.ORG Subject: Re: 'ch' Errors using chio w-sony changer Message-ID: <20010409175137.C86267@panzer.kdm.org> References: <20010409102114.A82661@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: ; from eric@estinc.com on Mon, Apr 09, 2001 at 04:32:16PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Apr 09, 2001 at 16:32:16 -0700, Eric Lee Green wrote: > On Mon, 9 Apr 2001, Kenneth D. Merry wrote: > > On Mon, Apr 09, 2001 at 10:23:49 -0400, Ken Menzel wrote: > > > Hi All, > > > I have looked at the man pages and manual and archives and source > > > for chio. My 'guess' is that there is soemthing in the return of the > > > status of the drive that the 'ch' driver doesn't like. The error is a > > > follows: > > > > > > janeway# chio return drive 0 > > > chio: /dev/ch0: CHIOGSTATUS: Invalid argument > > > > > > And /var/log/messages gets: > > > > > > Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): READ ELEMENT > > > STATUS. CDB: b8 > > > 30 0 1 0 1 0 0 4 0 0 0 > > > Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): ILLEGAL REQUEST > > > asc:24,0 > > > Apr 9 10:17:54 janeway /kernel: (ch0:ahc0:0:6:1): Invalid field in > > > CDB sks:cc,1 > > Let's see. b8 is read element status alright. But what's that 30? > According to my trusty T10 SMC draft specs, 30 is an illegal byte 1 for a > Read Element Status command. If it was 03 you would be requesting > import/export elements, if it was 10 you'd be requesting anything with bar > codes, but 30... no. Bits 6 and 5 are reserved, according to the T10 > specs. (bit 4 is okay, that's the voltag bit). They're reserved for the LUN number in SCSI-2 and below. The changer is at LUN 1, thus the '1' in the top three bits. (It claims to be SCSI-2, thus the reason we put the LUN there.) The sense key specific information is complaining about the voltag request, not the LUN. Evidently his changer doesn't like to return voltags. Ken, does your changer return an error (in dmesg) from 'chio status'? > Do note that the above message IS normal if you send a bit 4 in byte 1 of > the CDB to autoloaders which have no bar code reader. They spit up, and at > least in mtx I then back down to a plain 00 for byte 1 of the CDB (no bar > codes). Thus that entry in /var/log/messages is not an error, assuming > that chio does a similar thing (backs off and tries to get status without > bar codes). It doesn't attempt to get the status without voltags, so that's probably a bug. > > Have you tried 'chio move'? > > > > > However: > > > janeway# chio status > > > picker 0: > > > slot 0: > > > > Can you send the output of 'chio status -S'? > > > > Well, first off, you can only 'return' something if it has a valid source > > address. chio status -S will likely tell you if that is the case. > > Another possibility: Many loaders require you to eject the tape from the > drive prior to returning it to its source slot. I have no idea if chio > deals with that situation. I know I don't deal with it in mtx > (http://mtx.sourceforge.net), I just blithely spew guts all over and > expect you to figure it out for yourself. The problem was that his changer doesn't report source elements. He was able to fix the problem by using 'chio move', but he didn't CC that message to the list. 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 Apr 10 4:21: 9 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from serv.iaas.msu.ru (serv.iaas.msu.ru [212.192.224.252]) by hub.freebsd.org (Postfix) with ESMTP id 8058D37B422; Tue, 10 Apr 2001 04:20:43 -0700 (PDT) (envelope-from master@iaas.msu.ru) Received: from localhost (master@localhost) by serv.iaas.msu.ru (8.11.2/8.11.2) with ESMTP id f3ABL7Q67891; Tue, 10 Apr 2001 15:21:15 +0400 (MSD) (envelope-from master@iaas.msu.ru) Date: Tue, 10 Apr 2001 15:21:06 +0400 (MSD) From: Michail Vidiassov To: Cc: Subject: no active SCB for reconnecting target 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 Dear All, please, explain me the meaning of the following kernel message: (cabling/termination are not likely to be the cause of the problem, since the the machine worked for about a year untouched before the error appeared). The error is rare (about one in 2 weeks). ahc0: Bus Device Reset on A:1. 2 SCBs aborted ahc0:A:1: no active SCB for reconnecting target - issuing BUS DEVICE RESET SAVED_SCSIID == 0x17, SAVED_LUN == 0x0, ARG_1 == 0x3a ACCUM = 0x0 SEQ_FLAGS == 0x0, SCBPTR == 0xe, BTT == 0xff, SINDEX == 0x31 SCSIID == 0x17, SCB_SCSIID == 0x17, SCB_LUN == 0x0, SCB_TAG == 0xff, SCB_CONTROL == 0x62 SCSIBUSL == 0x3a, SCSISIGI == 0xe6 SXFRCTL0 == 0x88 SEQCTL == 0x10 ahc0: Dumping Card State at SEQADDR 0x198 SCB count = 110 Kernel NEXTQSCB = 58 Card NEXTQSCB = 58 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: 2:5 5:55 11:44 QOUTFIFO entries: Sequencer Free SCB List: 14 9 4 12 10 1 15 7 0 3 6 13 8 Pending list: 5 55 44 Kernel Free SCB list: 52 11 15 34 47 57 19 13 46 37 10 12 45 49 50 17 ... ahc0: Bus Device Reset on A:1. 3 SCBs aborted The relevant dmesg lines are: ed0: port 0x6000-0x601f irq 11 at device 17.0 on pci0 ahc0: port 0x6100-0x61ff mem 0xf0000000-0xf0000fff irq 11 at device 18.0 on pci0 aic7870: Wide Channel A, SCSI Id=7, 16/255 SCBs de0: port 0x6200-0x627f mem 0xf0001000-0xf000107f irq 11 at device 19.0 on pci0 ... Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 8.064MB/s transfers (8.064MHz, offset 15), Tagged Queueing Enabled da1: 1030MB (2109840 512 byte sectors: 64H 32S/T 1030C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15) da0: 4134MB (8467200 512 byte sectors: 64H 32S/T 4134C) uname -a: FreeBSD serv.iaas.msu.ru 4.2-STABLE FreeBSD 4.2-STABLE #15: Mon Feb 12 Machine: iP100, FX motherboard The actual question is : what is to be replaced: SCSI card, kernel driver, SCSI disk? Sincerely, Michail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 10 5:12:47 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mobile.hub.org (mobile.acadiau.ca [131.162.137.70]) by hub.freebsd.org (Postfix) with ESMTP id 916E937B423; Tue, 10 Apr 2001 05:12:34 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by mobile.hub.org (8.11.1/8.11.1) with ESMTP id f3AC2WH82779; Tue, 10 Apr 2001 09:02:32 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: mobile.hub.org: scrappy owned process doing -bs Date: Tue, 10 Apr 2001 09:02:32 -0300 (ADT) From: The Hermit Hacker To: Cc: Subject: Netfinity 7100 & 4.3- 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 Morning ... I've been getting this for awhile, and until this morning, haven't had a moment to actually write down what is/was on the screen ... its a 4.3 system, on a Netfinity 7100 ... dmesg output included at the bottom. The system is running a concat vinum drive for a mirror drive ... Thoughts, based on the following? Periodically, more often then not when there is heavy disk activity, the thing will panic, as follows: Fatal Trap 12: page fault while in kernel mode fault virtual address = 0x8084 fault code = supervisor read, page at present instruction pointer = 0x8:0xc012341e stack pointer = 0x10:0xc0257b94 frame pointer = 0x10:0x0c257b98 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 interrupt mask = trap number = 12 I can break into DDB, and do a trace, which shows: Debugger scgetc sckbdevent atkbd_intr atkbd_isa_intr Xresume1 --- interrupt, ip = 0xc020e6d21, esp = 0xc0257878, ebp = 0xc02578bc --- vec1 bwrite vop_stdbwrite vop_defaultop ufs_vnoperate bwrite cluster_wbuild vfs_bio_awrite ffs_fscync ffs_sync boot panic trap_fatal trap_pfault trap calltrap --- trap 0xc, eip = 0xc012341e, esp = 0xc4257b94, ebp = 0xc257b98 --- xpt_setup_ccb camperiphdone camisr scsi_cambio splz_scsi Xresume9 --- interrupt, eip = 0xc0219016, eip = 0xc0257c94, ebp = 0 --- default_halt ==================== Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.3-RC #3: Mon Apr 2 11:54:44 ADT 2001 root@demeter.acadiau.ca:/usr/obj/usr/src/sys/demeter Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 699179279 Hz CPU: Pentium III/Pentium III Xeon/Celeron (699.18-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6a0 Stepping = 0 Features=0x383fbff real memory = 1073717248 (1048552K bytes) avail memory = 1042833408 (1018392K bytes) Preloaded elf kernel "kernel" at 0xc02d9000. Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface pcib1: on motherboard pci1: on pcib1 pcib0: on motherboard pci0: on pcib0 ahc0: port 0x2000-0x20ff mem 0xfebff000-0xfebfffff irq 9 at device 1.0 on pci0 aic7896/97: Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: port 0x2100-0x21ff mem 0xfebfe000-0xfebfefff irq 9 at device 1.1 on pci0 aic7896/97: Wide Channel B, SCSI Id=7, 32/255 SCBs pci0: at 6.0 isab0: at device 15.0 on pci0 isa0: on isab0 pci0: at 15.2 irq 7 pcib2: on motherboard pci2: on pcib2 rl0: port 0x2200-0x22ff mem 0xf7fffc00-0xf7fffcff irq 11 at device 5.0 on pci2 rl0: Ethernet address: 00:e0:29:67:4e:d0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: port 0x2300-0x23ff mem 0xf7fff800-0xf7fff8ff irq 15 at device 6.0 on pci2 rl1: Ethernet address: 00:e0:29:67:4a:eb miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcib3: on motherboard pci3: on pcib3 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 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> Waiting 15 seconds for SCSI devices to settle pass7 at ahc1 bus 0 target 15 lun 0 pass7: Fixed Processor SCSI-2 device pass7: 3.300MB/s transfers da0 at ahc1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 8678MB (17774160 512 byte sectors: 255H 63S/T 1106C) da4 at ahc1 bus 0 target 5 lun 0 da4: Fixed Direct Access SCSI-3 device da4: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da4: 17357MB (35548320 512 byte sectors: 255H 63S/T 2212C) da3 at ahc1 bus 0 target 4 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da3: 17357MB (35548320 512 byte sectors: 255H 63S/T 2212C) da2 at ahc1 bus 0 target 3 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da2: 17357MB (35548320 512 byte sectors: 255H 63S/T 2212C) da1 at ahc1 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 17357MB (35548320 512 byte sectors: 255H 63S/T 2212C) da6 at ahc1 bus 0 target 10 lun 0 da6: Fixed Direct Access SCSI-3 device da6: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da6: 34715MB (71096640 512 byte sectors: 255H 63S/T 4425C) da5 at ahc1 bus 0 target 9 lun 0 da5: Fixed Direct Access SCSI-3 device da5: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da5: 34715MB (71096640 512 byte sectors: 255H 63S/T 4425C) Mounting root from ufs:/dev/da0s1a WARNING: / was not properly dismounted To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 10 5:30: 2 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 2E19437B423; Tue, 10 Apr 2001 05:29:57 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f3ACTds28942; Tue, 10 Apr 2001 06:29:49 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200104101229.f3ACTds28942@aslan.scsiguy.com> To: Michail Vidiassov Cc: freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: no active SCB for reconnecting target In-Reply-To: Your message of "Tue, 10 Apr 2001 15:21:06 +0400." Date: Tue, 10 Apr 2001 06:29:39 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >FreeBSD serv.iaas.msu.ru 4.2-STABLE FreeBSD 4.2-STABLE #15: Mon Feb 12 Upgrade to a newer -stable. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 10 6: 8:39 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mailrouter1.strath.ac.uk (orkney.cc.strath.ac.uk [130.159.248.40]) by hub.freebsd.org (Postfix) with ESMTP id 12E2737B423 for ; Tue, 10 Apr 2001 06:08:33 -0700 (PDT) (envelope-from jethro.binks@strath.ac.uk) Received: from orkney.cc.strath.ac.uk ([130.159.248.40]) by mailrouter1.strath.ac.uk with esmtp (Exim 3.12 #2) id 14mxrq-0004jr-00 for freebsd-scsi@freebsd.org; Tue, 10 Apr 2001 14:07:34 +0100 Date: Tue, 10 Apr 2001 14:07:34 +0100 (BST) From: Jethro R Binks X-Sender: ras99101@orkney.cc.strath.ac.uk To: freebsd-scsi@freebsd.org Subject: Missing SCSI disk on Compaq (others visible) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've a problem with a Compaq ProLiant 1600 which on which I've been installing FreeBSD (stable, as of about a week ago). I have 3 4.3Gb disks, and 2 18.2Gb disks connected to the internal SCSI (no SMART Array controller). This machine has had Linux installed for the best part of two years and has been fine, but times move on and now the hardware is supported in FreeBSD, and I want to Go There. The problem is that the kernel can see all the disks except one of the 18.2Gbs. They are all visible in the BIOS as the machine boots up, and "lsdev" in the BTX loader will display them all, but when the kernel boots, it doesn't see the second 18.2. Moving disks into different bays or removing some makes no difference: it flawlessly detects all installed installed disks except this particular one. As I mentioned, Linux can see it and use it OK. I guess it must be something to do with the firmware revision of this disk, and FreeBSD not liking it for some reason, but I'm at a loss as to how to proceed, so am seeking advice, or maybe some recognition of this problem from others. The problem disk has a slightly different code/revision from the one that is detected fine, and I think this must be the issue, but quite why FreeBSD doesn't like it when Linux is happy, I don't know. If it's helpful, the working 18.2 Gb disk is: AD018322C8 Rev A019 (Linux also reports scsi rev 02, and offset 15) (A Fujitsu, according to Compaq) The non-working one is: AD01832375 Rev ACJC (Linux also reports scsi rev 03, and offset 16) (A Quantum) I don't understand the significance of the difference in the scsi rev/offset numbers, not being a low-level hardware techie: forgive me. I've tried to upgrade the disks firmware, but according to the Options ROMPaq there are more recent ROM upgrades for the 18.3 disks available. The 4.3s were upgraded by it though. There's a similar-sounding problem at: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=487847+489731+/usr/local/www/db/text/2000/freebsd-questions/20001015.freebsd-questions which could boil down to the same issue: I couldn't find any follow-ups to that. Any advice welcome. Ta, Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks Computing Officer, IT Services Webmaster, Cachemaster, Listmaster; University Of Strathclyde, Glasgow, UK jethro.binks@strath.ac.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 10 6:41:48 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 1632137B43E for ; Tue, 10 Apr 2001 06:41:47 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f3ADfgs30010; Tue, 10 Apr 2001 07:41:43 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200104101341.f3ADfgs30010@aslan.scsiguy.com> To: Jethro R Binks Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Missing SCSI disk on Compaq (others visible) In-Reply-To: Your message of "Tue, 10 Apr 2001 14:07:34 BST." Date: Tue, 10 Apr 2001 07:41:42 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I have 3 4.3Gb disks, and 2 18.2Gb disks connected to the internal SCSI >(no SMART Array controller). What kind of SCSI controller does this machine use? During installation, if you hit "scroll-lock" followed by page-up, what messages do you see about these disks? Are any errors reported? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 10 6:52:10 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mailrouter1.strath.ac.uk (orkney.cc.strath.ac.uk [130.159.248.40]) by hub.freebsd.org (Postfix) with ESMTP id 877F437B424 for ; Tue, 10 Apr 2001 06:52:06 -0700 (PDT) (envelope-from jethro.binks@strath.ac.uk) Received: from orkney.cc.strath.ac.uk ([130.159.248.40]) by mailrouter1.strath.ac.uk with esmtp (Exim 3.12 #2) id 14myY0-0001aU-00 for freebsd-scsi@freebsd.org; Tue, 10 Apr 2001 14:51:08 +0100 Date: Tue, 10 Apr 2001 14:51:08 +0100 (BST) From: Jethro R Binks X-Sender: ras99101@orkney.cc.strath.ac.uk To: freebsd-scsi@freebsd.org Subject: Re: Missing SCSI disk on Compaq (others visible) In-Reply-To: <200104101341.f3ADfgs30010@aslan.scsiguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Apologies, I should have included some of that output. I'm kinda past the "installation" stage just now (the disk in question wasn't critical to the OS install, and in fact the machine was installed and running for a few days before I actually noticed it was 'missing'). Here's some dmesg output: sym0: <875> port 0x2000-0x20ff mem 0xc6fff000-0xc6ffffff,0xc6ffdf00-0xc6ffdfff irq 10 at device 9.0 on pci1 sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym1: <875> port 0x2400-0x24ff mem 0xc6ffe000-0xc6ffefff,0xc6ffde00-0xc6ffdeff irq 11 at device 9.1 on pci1 sym1: No NVRAM, ID 7, Fast-20, SE, parity checking ... Waiting 5 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a da2 at sym0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da2: 17366MB (35566000 512 byte sectors: 255H 63S/T 2213C) da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4094MB (8386000 512 byte sectors: 255H 63S/T 522C) da3 at sym0 bus 0 target 4 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da3: 4094MB (8386000 512 byte sectors: 255H 63S/T 522C) da1 at sym0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4094MB (8386000 512 byte sectors: 255H 63S/T 522C) As you can see, there's nothing on sym0 bus 0 target 3, where the disk physically is. I've never noted any errors at all regarding these disks, which is why it's only now when I've gone to partition the 2 18 Gigs I've only just noticed one missing! The controller is the on-board Symbios-based one. Is there any significance to the order the disks are detected and displayed in dmesg, above? I have another identical machine (running Linux) with two more 18.2Gs, unfortunately it is in production so I can't play around with that and see how it compares. Jethro. On Tue, 10 Apr 2001, Justin T. Gibbs wrote: > >I have 3 4.3Gb disks, and 2 18.2Gb disks connected to the internal SCSI > >(no SMART Array controller). > > What kind of SCSI controller does this machine use? > During installation, if you hit "scroll-lock" followed by page-up, > what messages do you see about these disks? Are any errors reported? > > -- > Justin > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks Computing Officer, IT Services Webmaster, Cachemaster, Listmaster; University Of Strathclyde, Glasgow, UK jethro.binks@strath.ac.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 10 7:46:47 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from hercules.icarz.com (ns1.icarz.com [207.99.22.7]) by hub.freebsd.org (Postfix) with ESMTP id 16F8637B422 for ; Tue, 10 Apr 2001 07:46:41 -0700 (PDT) (envelope-from kenm@icarz.com) Received: from newken (dhcp113.icarz.com [207.99.22.113]) by hercules.icarz.com (8.10.1/8.10.1) with SMTP id f3AEkU204917; Tue, 10 Apr 2001 10:46:30 -0400 (EDT) Message-ID: <01be01c0c1cd$03d4ad60$711663cf@icarz.com> From: "Ken Menzel" To: "Kenneth D. Merry" , "Eric Lee Green" Cc: References: <20010409102114.A82661@panzer.kdm.org> <20010409175137.C86267@panzer.kdm.org> Subject: Re: 'ch' Errors using chio w-sony changer Date: Tue, 10 Apr 2001 10:46:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I only get errors on status from chio status -v or -V. All other flags (sSbI) except of course the -a flag work fine. > Ken, does your changer return an error (in dmesg) from 'chio status'? > janeway# chio status -v chio: /dev/ch0: CHIOGSTATUS: Invalid argument janeway# chio status -V chio: /dev/ch0: CHIOGSTATUS: Invalid argument janeway# dmesg (ch0:ahc0:0:6:1): READ ELEMENT STATUS. CDB: b8 30 0 0 0 1 0 0 4 0 0 0 (ch0:ahc0:0:6:1): ILLEGAL REQUEST asc:24,0 (ch0:ahc0:0:6:1): Invalid field in CDB sks:cc,1 (ch0:ahc0:0:6:1): READ ELEMENT STATUS. CDB: b8 30 0 0 0 1 0 0 4 0 0 0 (ch0:ahc0:0:6:1): ILLEGAL REQUEST asc:24,0 (ch0:ahc0:0:6:1): Invalid field in CDB sks:cc,1 janeway# > The problem was that his changer doesn't report source elements. He was > able to fix the problem by using 'chio move', but he didn't CC that message > to the list. Ooops I thought I cc'ed the list must have hit the wrong button, sorry. The tape drive does not have a bar code reader, it is a rather inexpensive DDS4 changer, that gives me 192 gig capacity, plus I can order it right in the computer from Dell. Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 10 10:33: 8 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from hercules.icarz.com (ns1.icarz.com [207.99.22.7]) by hub.freebsd.org (Postfix) with ESMTP id 05CC437B422 for ; Tue, 10 Apr 2001 10:33:03 -0700 (PDT) (envelope-from kenm@icarz.com) Received: from newken (dhcp113.icarz.com [207.99.22.113]) by hercules.icarz.com (8.10.1/8.10.1) with SMTP id f3AHWv211365 for ; Tue, 10 Apr 2001 13:32:57 -0400 (EDT) Message-ID: <03f201c0c1e4$426b33c0$711663cf@icarz.com> From: "Ken Menzel" To: Subject: Fw: 'ch' Errors using chio w-sony changer Date: Tue, 10 Apr 2001 13:32:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I did not see my post from this morning, If anyone sees this please let me know. Ken ----------------------------------------------------- Ken Menzel ICQ# 9325188 www.icarz.com kenm@icarz.com ----- Original Message ----- From: "Ken Menzel" To: "Kenneth D. Merry" ; "Eric Lee Green" Cc: Sent: Tuesday, April 10, 2001 10:46 AM Subject: Re: 'ch' Errors using chio w-sony changer > I only get errors on status from chio status -v or -V. All other > flags (sSbI) except of course the -a flag work fine. > > Ken, does your changer return an error (in dmesg) from 'chio > status'? > > > janeway# chio status -v > chio: /dev/ch0: CHIOGSTATUS: Invalid argument > janeway# chio status -V > chio: /dev/ch0: CHIOGSTATUS: Invalid argument > janeway# dmesg > > (ch0:ahc0:0:6:1): READ ELEMENT STATUS. CDB: b8 30 0 0 0 1 0 0 4 0 0 0 > (ch0:ahc0:0:6:1): ILLEGAL REQUEST asc:24,0 > (ch0:ahc0:0:6:1): Invalid field in CDB sks:cc,1 > (ch0:ahc0:0:6:1): READ ELEMENT STATUS. CDB: b8 30 0 0 0 1 0 0 4 0 0 0 > (ch0:ahc0:0:6:1): ILLEGAL REQUEST asc:24,0 > (ch0:ahc0:0:6:1): Invalid field in CDB sks:cc,1 > janeway# > > > > The problem was that his changer doesn't report source elements. He > was > > able to fix the problem by using 'chio move', but he didn't CC that > message > > to the list. > Ooops I thought I cc'ed the list must have hit the wrong button, > sorry. > > The tape drive does not have a bar code reader, it is a rather > inexpensive DDS4 changer, that gives me 192 gig capacity, plus I can > order it right in the computer from Dell. > > Ken > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 10 10:55: 9 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from hercules.icarz.com (ns1.icarz.com [207.99.22.7]) by hub.freebsd.org (Postfix) with ESMTP id A15B937B422 for ; Tue, 10 Apr 2001 10:55:07 -0700 (PDT) (envelope-from kenm@icarz.com) Received: from newken (dhcp113.icarz.com [207.99.22.113]) by hercules.icarz.com (8.10.1/8.10.1) with SMTP id f3AHt6212210 for ; Tue, 10 Apr 2001 13:55:07 -0400 (EDT) Message-ID: <048d01c0c1e7$5a6a5ca0$711663cf@icarz.com> From: "Ken Menzel" To: Subject: Fw: 'ch' Errors using chio w-sony changer Date: Tue, 10 Apr 2001 13:54:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry for the noise, I missed the message it was user stupidity. Ignore my message from 1:32 PM EDT. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 10 12:56:31 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by hub.freebsd.org (Postfix) with ESMTP id A588C37B422 for ; Tue, 10 Apr 2001 12:56:27 -0700 (PDT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id EE0E617D23; Tue, 10 Apr 2001 21:56:25 +0200 (CEST) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.11.1/8.11.1) id f3AJqdw04279; Tue, 10 Apr 2001 21:52:39 +0200 (CEST) (envelope-from schweikh) Date: Tue, 10 Apr 2001 21:52:39 +0200 From: Jens Schweikhardt To: "Justin T. Gibbs" Cc: freebsd-scsi@FreeBSD.ORG Subject: SOLVED: Trouble with timeouts after installing an U160LVD Message-ID: <20010410215239.A2621@schweikhardt.net> References: <20010408095733.A581@schweikhardt.net> <200104092155.f39Lsgs19172@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104092155.f39Lsgs19172@aslan.scsiguy.com>; from gibbs@scsiguy.com on Mon, Apr 09, 2001 at 03:54:42PM -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin et al, On Mon, Apr 09, 2001 at 03:54:42PM -0600, Justin T. Gibbs wrote: # >It's a 4.2-R system. Here's the relevant part of the verbose boot # >(without the new DDYS-T18350N because this makes the system hard to # >use). The 68pin cable is about 60cm with 4 connectors every 20cm. The # >active terminator was way expensive (DM50 = US$25). The 50pin cable is # >150cm long, with 8 connectors spaced 1--------2-3-4-5-6-7-8, aic7880 # >being at position 1, the terminated IBM DCAS at position 8 and other # >unterminated SCSI2 devices at 5 and 7. # # The narrow cable is quite long. You might try distributing the # devices more evenly along the cable. This gives better transmission # line qualities. One other thing that might be affecting you is the # firmware version on the DDYS drive. S80D is really bad. The latest # is S96H. S96H is exactly what I've got... Anyway, I found the culprit: it's the removable mobile rack. The disk is connected to the removable chassis with a short (4inches) flat ribbon. This makes sort of a T shaped bus, I think, and in my case the T-ness seems to be not negligible. As soon as I connect the drive directly to the 68pin cable, everything works fine. Even though the packaging of the removable rack says "LVD", its cabling and/or connector seating is obviously crap. This impression is confirmed by trying the disk with a second removable rack (same model) -- same symptoms. BTW, it's a "A4 Tech H.D.D. Mobile Rack". Stay away from that. Is anyone using removable racks with LVD drives? What brand/model? PS: the DDYS's 10min interval of FPA/SMART or whatever it does is funny. Screeek; thrrrrrt. I can tune my watch using that. :-) 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 Tue Apr 10 15:49:10 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from england.inhouse (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id 27E1637B42C for ; Tue, 10 Apr 2001 15:49:01 -0700 (PDT) (envelope-from eric@estinc.com) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by england.inhouse (8.9.3/8.9.3) with ESMTP id PAA09926; Tue, 10 Apr 2001 15:50:48 -0700 Date: Tue, 10 Apr 2001 15:50:48 -0700 (MST) From: Eric Lee Green X-Sender: eric@england.inhouse To: Ken Menzel Cc: "Kenneth D. Merry" , freebsd-scsi@FreeBSD.ORG Subject: Re: 'ch' Errors using chio w-sony changer In-Reply-To: <01be01c0c1cd$03d4ad60$711663cf@icarz.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 10 Apr 2001, Ken Menzel wrote: > I only get errors on status from chio status -v or -V. All other > flags (sSbI) except of course the -a flag work fine. > chio: /dev/ch0: CHIOGSTATUS: Invalid argument > janeway# dmesg > > (ch0:ahc0:0:6:1): READ ELEMENT STATUS. CDB: b8 30 0 0 0 1 0 0 4 0 0 0 > (ch0:ahc0:0:6:1): ILLEGAL REQUEST asc:24,0 > (ch0:ahc0:0:6:1): Invalid field in CDB sks:cc,1 > (ch0:ahc0:0:6:1): READ ELEMENT STATUS. CDB: b8 30 0 0 0 1 0 0 4 0 0 0 Yep, that's the bar code reader (or lack thereof). When I implemented the bar code stuff in 'mtx' for the Exabyte 220 I had the same problem when I tried it with an autoloader, that's when I put in the 'back-off' stuff to re-issue the request without the barcode flag if I got that error (except that the Linux request sense chops off the tail of the sense data and I couldn't get at which field was in error on Linux, GRR!! FreeBSD was much more sensible there). Probably ch0 should do the same thing, though I have my doubts about the desirability of kernel-mode changer drivers in the first place, given the existence of pass and the slow speed of changers, which makes a user-mode driver plenty fast... but then, I'm biased because I wrote a user-mode changer driver for FreeBSD that uses pass :-). Since ch0 is part of the FreeBSD kernel, it probably should work right (shrug), even if it's not really necessary now that the pass0 device works (and works well, I might add). BTW, if you want to try it, 'mtx' works fine on FreeBSD. http://mtx.sourceforge.net . Also works fine on Linux, Solaris 8, Solaris 2.[67], and IRIX. Uses same syntax on all of these guys, just uses a different device name for the passthru driver (e.g. /dev/pass1 on FreeBSD, /dev/sg1 on Linux, some godaweful concoction on Solaris, ....). With the latest version 1.2.11, it's just a case of "./configure ; make ; make install", thanks to the wonders of GNU Autoconf. -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 11 7:41: 9 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from hercules.icarz.com (ns1.icarz.com [207.99.22.7]) by hub.freebsd.org (Postfix) with ESMTP id 9B2A237B422 for ; Wed, 11 Apr 2001 07:41:06 -0700 (PDT) (envelope-from kenm@icarz.com) Received: from newken (dhcp113.icarz.com [207.99.22.113]) by hercules.icarz.com (8.10.1/8.10.1) with SMTP id f3BEev208711; Wed, 11 Apr 2001 10:40:57 -0400 (EDT) Message-ID: <06b301c0c295$5154c700$711663cf@icarz.com> From: "Ken Menzel" To: "Eric Lee Green" Cc: References: Subject: Re: 'ch' Errors using chio w-sony changer Date: Wed, 11 Apr 2001 10:40:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks Eric! I guess it's my drive returning an error when the VOLTAG bit is set in Element 1 of the READ ELEMENT STAUS command. OK that I understand. What really confused me was that chio seems to need this bit set to execute 'chio return drive 0'. I would guess that this is because the 'return' command gets the source information from the VOLTAG info, and if there is no VOLTAG(bar code) info, of course it can't return the tape! I am learning alot from this. I think the man page could mention this. I wonder if I should give someone(freebsd-stable?) a patch for what I feel would be appropriate? I will try 'mtx' now also, I am hoping it will also run on BSDi, because I need this for BSD/OS also. From reading the web page it looks as if 'mtx' works like 'chio' but supports more features and drives and runs in users land. I wonder why 'mtx' is not in the /usr/ports or a part of freebsd! Thanks for your help everyone. Ken > BTW, if you want to try it, 'mtx' works fine on FreeBSD. > http://mtx.sourceforge.net . Also works fine on Linux, Solaris 8, Solaris > 2.[67], and IRIX. Uses same syntax on all of these guys, just uses a > different device name for the passthru driver (e.g. /dev/pass1 on FreeBSD, > /dev/sg1 on Linux, some godaweful concoction on Solaris, ....). With the > latest version 1.2.11, it's just a case of "./configure ; make ; make > install", thanks to the wonders of GNU Autoconf. > > -- > Eric Lee Green eric@estinc.com > Software Engineer "The BRU Guys" > Enhanced Software Technologies, Inc. http://www.estinc.com/ > (602) 470-1115 voice (602) 470-1116 fax > > > > 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 Apr 11 14: 3:47 2001 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 9ADE137B422 for ; Wed, 11 Apr 2001 14:03:42 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA02046; Wed, 11 Apr 2001 15:03:01 -0600 (MDT) (envelope-from ken) Date: Wed, 11 Apr 2001 15:03:01 -0600 From: "Kenneth D. Merry" To: Ken Menzel Cc: Eric Lee Green , freebsd-scsi@FreeBSD.ORG Subject: Re: 'ch' Errors using chio w-sony changer Message-ID: <20010411150301.B1830@panzer.kdm.org> References: <20010409102114.A82661@panzer.kdm.org> <20010409175137.C86267@panzer.kdm.org> <01be01c0c1cd$03d4ad60$711663cf@icarz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <01be01c0c1cd$03d4ad60$711663cf@icarz.com>; from kenm@icarz.com on Tue, Apr 10, 2001 at 10:46:23AM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Apr 10, 2001 at 10:46:23 -0400, Ken Menzel wrote: > I only get errors on status from chio status -v or -V. All other > flags (sSbI) except of course the -a flag work fine. > > Ken, does your changer return an error (in dmesg) from 'chio > status'? > > > janeway# chio status -v > chio: /dev/ch0: CHIOGSTATUS: Invalid argument > janeway# chio status -V > chio: /dev/ch0: CHIOGSTATUS: Invalid argument > janeway# dmesg > > (ch0:ahc0:0:6:1): READ ELEMENT STATUS. CDB: b8 30 0 0 0 1 0 0 4 0 0 0 > (ch0:ahc0:0:6:1): ILLEGAL REQUEST asc:24,0 > (ch0:ahc0:0:6:1): Invalid field in CDB sks:cc,1 > (ch0:ahc0:0:6:1): READ ELEMENT STATUS. CDB: b8 30 0 0 0 1 0 0 4 0 0 0 > (ch0:ahc0:0:6:1): ILLEGAL REQUEST asc:24,0 > (ch0:ahc0:0:6:1): Invalid field in CDB sks:cc,1 > janeway# Makes sense, your changer doesn't support volume tags. > > The problem was that his changer doesn't report source elements. He > was > > able to fix the problem by using 'chio move', but he didn't CC that > message > > to the list. > Ooops I thought I cc'ed the list must have hit the wrong button, > sorry. > > The tape drive does not have a bar code reader, it is a rather > inexpensive DDS4 changer, that gives me 192 gig capacity, plus I can > order it right in the computer from Dell. Sounds pretty cool. Changers don't need barcode readers to support volume tags. Some changers allow you to set a volume tag for a given tape. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 11 14: 7:28 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 192A837B423 for ; Wed, 11 Apr 2001 14:07:25 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA04723; Wed, 11 Apr 2001 14:06:54 -0700 Date: Wed, 11 Apr 2001 14:06:46 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: Ken Menzel , Eric Lee Green , freebsd-scsi@FreeBSD.ORG Subject: Re: 'ch' Errors using chio w-sony changer In-Reply-To: <20010411150301.B1830@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Sounds pretty cool. Changers don't need barcode readers to support volume > tags. Some changers allow you to set a volume tag for a given tape. > And STK allows you to also set a Pool tag with each tape as well. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 11 14:15:31 2001 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 D877F37B422 for ; Wed, 11 Apr 2001 14:15:21 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA02132; Wed, 11 Apr 2001 15:15:01 -0600 (MDT) (envelope-from ken) Date: Wed, 11 Apr 2001 15:15:01 -0600 From: "Kenneth D. Merry" To: Eric Lee Green Cc: Ken Menzel , freebsd-scsi@FreeBSD.ORG Subject: Re: 'ch' Errors using chio w-sony changer Message-ID: <20010411151501.C1830@panzer.kdm.org> References: <01be01c0c1cd$03d4ad60$711663cf@icarz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from eric@estinc.com on Tue, Apr 10, 2001 at 03:50:48PM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Apr 10, 2001 at 15:50:48 -0700, Eric Lee Green wrote: > On Tue, 10 Apr 2001, Ken Menzel wrote: > > I only get errors on status from chio status -v or -V. All other > > flags (sSbI) except of course the -a flag work fine. > > > chio: /dev/ch0: CHIOGSTATUS: Invalid argument > > janeway# dmesg > > > > (ch0:ahc0:0:6:1): READ ELEMENT STATUS. CDB: b8 30 0 0 0 1 0 0 4 0 0 0 > > (ch0:ahc0:0:6:1): ILLEGAL REQUEST asc:24,0 > > (ch0:ahc0:0:6:1): Invalid field in CDB sks:cc,1 > > (ch0:ahc0:0:6:1): READ ELEMENT STATUS. CDB: b8 30 0 0 0 1 0 0 4 0 0 0 > > Yep, that's the bar code reader (or lack thereof). Rather lack of volume tag support. You don't necessarily need barcode reader to support volume tags. > When I implemented the > bar code stuff in 'mtx' for the Exabyte 220 I had the same problem when I > tried it with an autoloader, that's when I put in the 'back-off' stuff to > re-issue the request without the barcode flag if I got that error (except > that the Linux request sense chops off the tail of the sense data and I > couldn't get at which field was in error on Linux, GRR!! FreeBSD was much > more sensible there). Probably ch0 should do the same thing, The only problem is in chio(1). It blindly asks for volume tags for 'chio return', even if the user hasn't specified a voltag. Otherwise it does the right thing from what I can tell; it only asks the changer for voltags if the user asks for them. > though I have > my doubts about the desirability of kernel-mode changer drivers in the > first place, given the existence of pass and the slow speed of > changers, which makes a user-mode driver plenty fast... but then, I'm > biased because I wrote a user-mode changer driver for FreeBSD that uses > pass :-). Since ch0 is part of the FreeBSD kernel, it probably should > work right (shrug), even if it's not really necessary now that the pass0 > device works (and works well, I might add). One advantage of having a kernel driver is the ability to cache state somewhat. (With a userland program, unless you have some sort of config file, you'd need to ask the changer about its configuration, etc., every time you open the device.) > BTW, if you want to try it, 'mtx' works fine on FreeBSD. > http://mtx.sourceforge.net . Also works fine on Linux, Solaris 8, Solaris > 2.[67], and IRIX. Uses same syntax on all of these guys, just uses a > different device name for the passthru driver (e.g. /dev/pass1 on FreeBSD, > /dev/sg1 on Linux, some godaweful concoction on Solaris, ....). With the > latest version 1.2.11, it's just a case of "./configure ; make ; make > install", thanks to the wonders of GNU Autoconf. Sounds pretty cool. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 11 15:41:32 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from england.inhouse (gw.estinc.com [216.216.240.51]) by hub.freebsd.org (Postfix) with ESMTP id EAFAC37B423 for ; Wed, 11 Apr 2001 15:41:28 -0700 (PDT) (envelope-from eric@estinc.com) Received: from localhost (IDENT:eric@localhost.localdomain [127.0.0.1]) by england.inhouse (8.9.3/8.9.3) with ESMTP id PAA27712; Wed, 11 Apr 2001 15:43:16 -0700 Date: Wed, 11 Apr 2001 15:43:15 -0700 (MST) From: Eric Lee Green X-Sender: eric@england.inhouse To: "Kenneth D. Merry" Cc: Ken Menzel , freebsd-scsi@FreeBSD.ORG Subject: Re: 'ch' Errors using chio w-sony changer In-Reply-To: <20010411151501.C1830@panzer.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 11 Apr 2001, Kenneth D. Merry wrote: > On Tue, Apr 10, 2001 at 15:50:48 -0700, Eric Lee Green wrote: > > though I have > > my doubts about the desirability of kernel-mode changer drivers in the > > first place, given the existence of pass and the slow speed of > > changers, which makes a user-mode driver plenty fast... but then, I'm > > biased because I wrote a user-mode changer driver for FreeBSD that uses > > pass :-). Since ch0 is part of the FreeBSD kernel, it probably should > > work right (shrug), even if it's not really necessary now that the pass0 > > device works (and works well, I might add). > > One advantage of having a kernel driver is the ability to cache state > somewhat. (With a userland program, unless you have some sort of config > file, you'd need to ask the changer about its configuration, etc., every > time you open the device.) Given how slow tape robotics currently are, that's pretty trivial overhead. I've had people use 'mtx' on 100+ tape libraries and they tell me it works fine, they just need to pipe the results of 'mtx status' through 'more' :-). It takes an Ecrix Autopack exactly 3 minutes and 35 seconds between the time you issue a 'mtx load' and the time that the tape actually comes online. I measured it because I was astounded at how slow it seemed to be (agh!). A few hundred milliseconds delay fetching some configuration info seems trivial beside that. This is also why I am not particularly worried about the fact that the storage management subsystem in BRU Professional is currently written in Python, not the world's fastest computer language. As slow as it is, it still takes far less time to decide which tape to place in the drive than the robot takes to actually move the tape to the drive. > > BTW, if you want to try it, 'mtx' works fine on FreeBSD. > > http://mtx.sourceforge.net . Also works fine on Linux, Solaris 8, Solaris > > 2.[67], and IRIX. Uses same syntax on all of these guys, just uses a > > different device name for the passthru driver (e.g. /dev/pass1 on FreeBSD, > > /dev/sg1 on Linux, some godaweful concoction on Solaris, ....). With the > > latest version 1.2.11, it's just a case of "./configure ; make ; make > > install", thanks to the wonders of GNU Autoconf. > > Sounds pretty cool. Alas, it turns out that I jumped the gun on 1.2.11 w/FreeBSD. 1.2.10 works fine, but I made some timeout changes that appear to have broke 1.2.11 on FreeBSD (I'm starting to make my timeouts adjustable so that, e.g., a 'mtx inquiry' uses a short timeout and a 'mtx inventory' uses a VERY long timeout). The odd thing is that I tried 1.2.11pre3 on FreeBSD and it worked fine, so apparently I broke it on 1.2.11pre[456] which I did not try on FreeBSD (sigh!). Guess 1.2.12 will come out Real Soon Now with fixes for FreeBSD and IRIX. -- Eric Lee Green eric@estinc.com Software Engineer "The BRU Guys" Enhanced Software Technologies, Inc. http://www.estinc.com/ (602) 470-1115 voice (602) 470-1116 fax To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 12 1:21:27 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from cx587235-a.chnd1.az.home.com (cx587235-a.chnd1.az.home.com [24.1.255.253]) by hub.freebsd.org (Postfix) with ESMTP id A60AC37B61F for ; Thu, 12 Apr 2001 01:21:22 -0700 (PDT) (envelope-from jjreynold@home.com) Received: from whale.home-net (whale [192.168.1.2]) by cx587235-a.chnd1.az.home.com (8.11.3/8.11.3) with ESMTP id f3C8LM437315 for ; Thu, 12 Apr 2001 01:21:22 -0700 (MST) (envelope-from jjreynold@home.com) Received: (from jjreynold@localhost) by whale.home-net (8.11.3/8.11.3) id f3C8LLB07215; Thu, 12 Apr 2001 01:21:21 -0700 (MST) (envelope-from jjreynold@home.com) From: John Reynolds MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15061.25985.258225.414036@whale.home-net> Date: Thu, 12 Apr 2001 01:21:21 -0700 To: scsi@freebsd.org Subject: yamaha 8824s CD-RW drive -- anybody using? X-Mailer: VM 6.88 under Emacs 20.7.1 Cc: Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ a search of -stable and -scsi came up with "not much" on this topic ] Hi all, I perused the "supported drive" list for cdrecord tonight and didn't see the Yamaha 8824s (8xW/8xRW/24xR) explicitly in the list of "supported" drives but the 8832s was. I'm wondering if somebody on this list is using the 8824s successfully with cdrecord (and it's just not in his supported table yet)? I'm considering upgrading from my 4416s and have been happy with my Yamaha, so I'm just wondering about this drive. Please cc: me on the reply. Thanks! -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Reynolds Chandler Capabilities Engineering, CDS, Intel Corporation jreynold@sedona.ch.intel.com My opinions are mine, not Intel's. Running jjreynold@home.com FreeBSD 4.2-STABLE. FreeBSD: The Power to Serve. http://www.reynoldsnet.org/ Come join us!!! @ http://www.FreeBSD.org/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 12 6:16:46 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from hercules.icarz.com (ns1.icarz.com [207.99.22.7]) by hub.freebsd.org (Postfix) with ESMTP id BA36E37B440 for ; Thu, 12 Apr 2001 06:16:43 -0700 (PDT) (envelope-from kenm@icarz.com) Received: from newken (dhcp113.icarz.com [207.99.22.113]) by hercules.icarz.com (8.10.1/8.10.1) with SMTP id f3CDGa212677; Thu, 12 Apr 2001 09:16:37 -0400 (EDT) Message-ID: <0aaf01c0c352$8fed44c0$711663cf@icarz.com> From: "Ken Menzel" To: "Kenneth D. Merry" , "Eric Lee Green" Cc: References: <01be01c0c1cd$03d4ad60$711663cf@icarz.com> <20010411151501.C1830@panzer.kdm.org> Subject: Re: 'ch' Errors using chio w-sony changer Date: Thu, 12 Apr 2001 09:14:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ----- Original Message ----- From: "Kenneth D. Merry" > The only problem is in chio(1). It blindly asks for volume tags for 'chio > return', even if the user hasn't specified a voltag. Otherwise it does the Hi Ken, so a chio return drive 0 should have worked because I did not use a voltag! I know not to do this now, but maybe the behaviour of chio could be improved for the next guy? While I'm asking maybe for the status -A for all status without voltags. Eric, I'll up the timeout and recompile mtx to try out the new version. Thanks everyone, Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 12 6:53:24 2001 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 7337837B43F for ; Thu, 12 Apr 2001 06:53:21 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id HAA06790; Thu, 12 Apr 2001 07:53:17 -0600 (MDT) (envelope-from ken) Date: Thu, 12 Apr 2001 07:53:17 -0600 From: "Kenneth D. Merry" To: Ken Menzel Cc: Eric Lee Green , freebsd-scsi@FreeBSD.ORG Subject: Re: 'ch' Errors using chio w-sony changer Message-ID: <20010412075317.A6776@panzer.kdm.org> References: <01be01c0c1cd$03d4ad60$711663cf@icarz.com> <20010411151501.C1830@panzer.kdm.org> <0aaf01c0c352$8fed44c0$711663cf@icarz.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <0aaf01c0c352$8fed44c0$711663cf@icarz.com>; from kenm@icarz.com on Thu, Apr 12, 2001 at 09:14:52AM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Apr 12, 2001 at 09:14:52 -0400, Ken Menzel wrote: > ----- Original Message ----- > From: "Kenneth D. Merry" > > The only problem is in chio(1). It blindly asks for volume tags for > 'chio > > return', even if the user hasn't specified a voltag. Otherwise it > does the > > Hi Ken, so a chio return drive 0 should have worked because I did not > use a voltag! I know not to do this now, but maybe the behaviour of > chio could be improved for the next guy? While I'm asking maybe for > the status -A for all status without voltags. It probably wouldn't have worked, since your changer doesn't report the source element. As for the new status option, I'll keep that in mind next time I'm working on chio. 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 Apr 12 7: 8: 3 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from relay.comm2000.it (mindseal.comm2000.it [194.133.0.6]) by hub.freebsd.org (Postfix) with ESMTP id E238037B424 for ; Thu, 12 Apr 2001 07:07:59 -0700 (PDT) (envelope-from massimo@datacode.it) Received: from purtroppo.local.lan ([212.97.62.126]) by relay.comm2000.it (8.11.2/MFAGMM-19990726) with ESMTP id f3CE7Gn32486 for ; Thu, 12 Apr 2001 16:07:16 +0200 X-SMTP-Peer: [212.97.62.126] Received: (from nobody@localhost) by purtroppo.local.lan (8.11.3/8.11.3) id f3CE3id27963 for freebsd-scsi@freebsd.org; Thu, 12 Apr 2001 16:03:44 +0200 (CEST) (envelope-from massimo@datacode.it) X-Authentication-Warning: purtroppo.local.lan: nobody set sender to massimo@datacode.it using -f To: freebsd-scsi@freebsd.org Subject: ICP Vortex controllers Message-ID: <987084224.3ad5b5c01eb4c@webapps.datacode.it> Date: Thu, 12 Apr 2001 16:03:44 +0200 (CEST) From: Massimo Lusetti MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Are the ICP Vortex - 64 Bit Wide/Ultra 160 SCSI RAID Controllers supported ? I didn't find any issue about that but daemonnews promote them... ----- Massimo Lusetti Network Department Manager url: http://www.datacode.it email: info@datacode.it ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 13 10:55:32 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from eterna.binary.net (eterna.binary.net [216.229.0.25]) by hub.freebsd.org (Postfix) with ESMTP id B03C337B446; Fri, 13 Apr 2001 10:55:26 -0700 (PDT) (envelope-from nathan@binary.net) Received: from matrix.binary.net (matrix.binary.net [216.229.0.2]) by eterna.binary.net (Postfix) with ESMTP id C51242D1; Fri, 13 Apr 2001 12:53:07 -0500 (CDT) Received: by matrix.binary.net (Postfix, from userid 1007) id 85ECD835CC; Fri, 13 Apr 2001 12:55:28 -0500 (CDT) Date: Fri, 13 Apr 2001 13:55:28 -0400 From: Nathan Dorfman To: Harold Gutch Cc: Guido van Rooij , freebsd-multimedia@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: tosha & cdrecord Message-ID: <20010413135528.A73999@rtfm.net> References: <20010323195355.A21097@gvr.gvr.org> <20010323205639.A41316@foobar.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010323205639.A41316@foobar.franken.de>; from logix@foobar.franken.de on Fri, Mar 23, 2001 at 08:56:39PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Mar 23, 2001 at 08:56:39PM +0100, Harold Gutch wrote: > On Fri, Mar 23, 2001 at 07:53:56PM +0100, Guido van Rooij wrote: > > I have a PHILIPS CDD3600 CD-R/RW and I never got it to work with > > tosha and cdrecord. If I run tosha with -f wav but when I burn > > these tracks later with cdrecord, I get noice only. It's probably > > a forgotten option somewhere, but I have no clue which one. > > Try omitting the -f parameter to tosha and thus dumping raw PCM > files, and then burning them with the -swab parameter. > That works for me (with a TEAC CD-R58S though). Careful. You only want to use -swab with drives whose byte ordering differs from that of your system and PCM files. cdrecord will tell you if you need to use -swab in one of its info/diagnostic modes. > bye, > Harold -- Nathan Dorfman [http://www.rtfm.net] "The light at the end of the tunnel is the headlight of an approaching train." --/usr/games/fortune To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 13 11: 6:40 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from foobar.franken.de (foobar.franken.de [194.94.249.81]) by hub.freebsd.org (Postfix) with ESMTP id 9EA4D37B440; Fri, 13 Apr 2001 11:06:33 -0700 (PDT) (envelope-from logix@foobar.franken.de) Received: (from logix@localhost) by foobar.franken.de (8.11.1/8.11.1) id f3DI7jg91002; Fri, 13 Apr 2001 20:07:45 +0200 (CEST) (envelope-from logix) Date: Fri, 13 Apr 2001 20:07:43 +0200 From: Harold Gutch To: Nathan Dorfman Cc: Guido van Rooij , freebsd-multimedia@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: tosha & cdrecord Message-ID: <20010413200743.A90877@foobar.franken.de> References: <20010323195355.A21097@gvr.gvr.org> <20010323205639.A41316@foobar.franken.de> <20010413135528.A73999@rtfm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010413135528.A73999@rtfm.net>; from nathan@rtfm.net on Fri, Apr 13, 2001 at 01:55:28PM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Apr 13, 2001 at 01:55:28PM -0400, Nathan Dorfman wrote: > On Fri, Mar 23, 2001 at 08:56:39PM +0100, Harold Gutch wrote: > > Try omitting the -f parameter to tosha and thus dumping raw PCM > > files, and then burning them with the -swab parameter. > > That works for me (with a TEAC CD-R58S though). > > Careful. You only want to use -swab with drives whose byte ordering > differs from that of your system and PCM files. According to the manpage, cdrecord automatically recognizes what byte-order the cd-burner requires, but cdrecord itself assumes the PCM files to be in big-endian order. Tosha dumps the tracks in host-order, which is little-endian on x86, so you'll need -swab in my scenario above. bye, Harold To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 13 11:14:55 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from nu.binary.net (nu.binary.net [216.229.0.6]) by hub.freebsd.org (Postfix) with ESMTP id CD6C737B50C; Fri, 13 Apr 2001 11:14:49 -0700 (PDT) (envelope-from nathan@binary.net) Received: from matrix.binary.net (matrix.binary.net [216.229.0.2]) by nu.binary.net (Postfix) with ESMTP id 39CFC9C1E7; Fri, 13 Apr 2001 13:22:48 -0500 (CDT) Received: by matrix.binary.net (Postfix, from userid 1007) id AA459835CC; Fri, 13 Apr 2001 13:14:52 -0500 (CDT) Date: Fri, 13 Apr 2001 14:14:52 -0400 From: Nathan Dorfman To: Harold Gutch Cc: Guido van Rooij , freebsd-multimedia@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: tosha & cdrecord Message-ID: <20010413141452.A74659@rtfm.net> References: <20010323195355.A21097@gvr.gvr.org> <20010323205639.A41316@foobar.franken.de> <20010413135528.A73999@rtfm.net> <20010413200743.A90877@foobar.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010413200743.A90877@foobar.franken.de>; from logix@foobar.franken.de on Fri, Apr 13, 2001 at 08:07:43PM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Apr 13, 2001 at 08:07:43PM +0200, Harold Gutch wrote: > On Fri, Apr 13, 2001 at 01:55:28PM -0400, Nathan Dorfman wrote: > > On Fri, Mar 23, 2001 at 08:56:39PM +0100, Harold Gutch wrote: > > > Try omitting the -f parameter to tosha and thus dumping raw PCM > > > files, and then burning them with the -swab parameter. > > > That works for me (with a TEAC CD-R58S though). > > > > Careful. You only want to use -swab with drives whose byte ordering > > differs from that of your system and PCM files. > > According to the manpage, cdrecord automatically recognizes what > byte-order the cd-burner requires, but cdrecord itself assumes > the PCM files to be in big-endian order. Tosha dumps the tracks > in host-order, which is little-endian on x86, so you'll need > -swab in my scenario above. Also from the manpage: Note that the verbose output of cdrecord will show you if swapping is necessary to make the byte order of the input data fit the required byte order of the recorder. Cdrecord will not show you if the -swab flag was actually present for a track. > bye, > Harold -- Nathan Dorfman [http://www.rtfm.net] "The light at the end of the tunnel is the headlight of an approaching train." --/usr/games/fortune To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 13 17:37:57 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from boco.fee.vutbr.cz (boco.fee.vutbr.cz [147.229.9.11]) by hub.freebsd.org (Postfix) with ESMTP id 3E9D037B50B for ; Fri, 13 Apr 2001 17:37:54 -0700 (PDT) (envelope-from cejkar@dcse.fee.vutbr.cz) Received: from kazi.dcse.fee.vutbr.cz (kazi.dcse.fee.vutbr.cz [147.229.8.12]) by boco.fee.vutbr.cz (8.11.3/8.11.3) with ESMTP id f3E0bft23401 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sat, 14 Apr 2001 02:37:42 +0200 (CEST) Received: (from cejkar@localhost) by kazi.dcse.fee.vutbr.cz (8.11.2/8.11.2) id f3E0bea79161 for freebsd-scsi@FreeBSD.ORG; Sat, 14 Apr 2001 02:37:40 +0200 (CEST) Date: Sat, 14 Apr 2001 02:37:40 +0200 From: Cejka Rudolf To: freebsd-scsi@FreeBSD.ORG Subject: Getting information from SCSI devices? [and Mammoth2 example] Message-ID: <20010414023740.A78784@dcse.fee.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, if you remember, I had troubles with one Mammoth2 drive some time ago. At now, I think I can say that difficulties have been solved by firmware upgrade (in my opipion v03a was the first usable firmware for M2) - I can not repeat FreeBSD freezes any more, because medium errors disappeared... However I have one question/micro-announce: Does anybody know about any "more mature" tool such as "camcontrol modepage ...", which can communicate with SCSI devices and write out data from them in a human readable format? Just for FreeBSD of course (I know about M2 monitor for Windows.) camcontrol does know mode sense command only (log sense would be great), numbers are only up to 4 bytes and so on and I'm not sure if it is desirable to extend libcam further, because it is in a base system. I have written very small and simple perl wrapper around camcontrol to get some interesting information from Mammoth2 drive: Number of read/write errors, hardware compression information (! great thing !), drive usage statistics and an environmental temperature. EZ17 is the next on the plate... M2 owners can just copy & paste & run: fetch ftp://ftp.FreeBSD.cz/pub/FreeBSD-local/scsi/m2 -- Rudolf Cejka (cejkar@dcse.fee.vutbr.cz; http://www.fee.vutbr.cz/~cejkar) Brno University of Technology, Faculty of El. Engineering and Comp. Science Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 14 6:41:59 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from catastrophe.net (ss189-189.dvsn-chi-il.outlook.net [208.45.189.189]) by hub.freebsd.org (Postfix) with SMTP id B21AF37B43E for ; Sat, 14 Apr 2001 06:41:57 -0700 (PDT) (envelope-from eric@catastrophe.net) Received: (qmail 3613 invoked by uid 1002); 14 Apr 2001 13:41:56 -0000 Date: Sat, 14 Apr 2001 08:41:56 -0500 (CDT) From: Reply-To: To: Subject: Internal SCSI Cabling. Message-ID: Organization: http://www.catastrophe.net MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have an extremely tight rack case that I'm having trouble cabling to SCSI3 LVD standards. It seems like once in a while a drive will fall back to SCSI2 on the chain (there's 5 drives on the chain). Adaptec has mentioned that this is due to the cable not being up the the 160 spec. Any suggestions? I've tried an internal ribbon and an internal round cable from QVS. Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 14 7:53:14 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by hub.freebsd.org (Postfix) with ESMTP id 64CA237B424 for ; Sat, 14 Apr 2001 07:53:11 -0700 (PDT) (envelope-from steven@magicnet.net) Received: from [129.250.38.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 14oRQF-0003wh-00 for freebsd-scsi@freebsd.org; Sat, 14 Apr 2001 14:53:11 +0000 Received: from sdn-ar-018florlap219.dialsprint.net ([63.180.61.235] helo=magicnet.net) by dfw-mmp4.email.verio.net with esmtp id 14oRQE-0007Sm-00 for freebsd-scsi@FreeBSD.ORG; Sat, 14 Apr 2001 14:53:10 +0000 Message-ID: <3AD86452.CDE397AA@magicnet.net> Date: Sat, 14 Apr 2001 10:53:07 -0400 From: "Steven G. Bradley" Reply-To: steven@magicnet.net Organization: http://myweb.magicnet.net/steven X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "freebsd-scsi@FreeBSD.ORG" Subject: Compaq C2490A / IBM / HP 2.1G drive & AHA1542B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I realize this is a discussion forum for BSDI/FreeBSD SCSI, but I am hoping someone can help me with a SCSI problem. Feel free to use private e-mail to reply. Bought a C2490A SCSI 2.1G drive on eBay (listed as "From IBM described as used and tested"). It was originally used in a Compaq system and has their numbers (and spare to use label) on it as well. It was made by HP. It is in great condition with no shipping damage of any kind. Just does not spin up, green LED comes on, does not ID itself to the controller at boot. Another gentleman in Wisconsin bought another of the same identical drives from the same auction and has the same results. Question: Did Compaq do something in the OEMing of these from HP that makes them unusable with standard SCSI controllers and non Compaq hardware? I have written to the guy who sold it as it appears DOA (as was the opinion of the HP tech who indicated I did not need to have more than 12v and 5v drive power connected and it should spinup ok), so far no reply. If I do not receive one, I will deduct it and have a chargeback issued when VISA comes due. Seriously guys, is there something "special" about these drives that would cause two strangers in different parts of the US to have the same outcome? I see them listed frequently, am I the rule or exception? Do they all fail to work on a 1542B on a standard 486 Linux system? Thanks for reading, Steven -- Steven Bradley 121 Cambridge Drive steven@magicnet.net Longwood, FL 32779-5707 USA CompuServe: 102555,3031 Tel: (407) 862-7226 URL: http://www.magicnet.net/~steven To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 14 11:40:17 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (Postfix) with ESMTP id A516B37B446 for ; Sat, 14 Apr 2001 11:40:01 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.9.3/8.9.3) with UUCP id UAA05751 for freebsd-scsi@freebsd.org; Sat, 14 Apr 2001 20:39:58 +0200 (CEST) Received: (from j@localhost) by uriah.heep.sax.de (8.11.3/8.11.3) id f3EIdP663349 for freebsd-scsi@freebsd.org; Sat, 14 Apr 2001 20:39:25 +0200 (MET DST) (envelope-from j) Date: Sat, 14 Apr 2001 20:39:25 +0200 From: J Wunsch To: freebsd-scsi@freebsd.org Subject: Re: Problem with current sa(4) driver Message-ID: <20010414203925.A63281@uriah.heep.sax.de> Reply-To: Joerg Wunsch References: <20010410233410.A9305@uriah.heep.sax.de> <20010411083552.A8646@uriah.heep.sax.de> <20010413000553.A5245@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010413000553.A5245@uriah.heep.sax.de>; from j@uriah.heep.sax.de on Fri, Apr 13, 2001 at 12:05:53AM +0200 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 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi folks, it seems the latest cleanup in CAMs error handling code (ken's commit from 2001/03/27) has broken the ability for the sa(4) driver to handle residuals properly. I first noticed it on a new kernel that the implied test read for any mt(1) operation broke on my Tandberg TDC4222 drive. The test attempts to read 8 KB from the tape, but tape blocking was usually 10 or 32 KB, depending on how the supplied cartridge has been written. The symptom was that the driver continued to read the entire tape, until it eventually hit EOM. Thus, a `mt blocksize variable' took usually an hour if a full backup cartridge was in the drive... I then noticed that any form of tape block size vs. read(2) buffer sice mismatch causes this behaviour, also for other drive types (see below). Since Matt replied that he has no idea why, i got interested in investigating myself :), and pursued it a little. Let me first start with my recent mail to Matt that contains a summary of the code paths involved. > Since i got hold of an old > > # camcontrol inquiry sa1 > pass6: Removable Sequential Access SCSI-2 device > pass6: Serial Number DR0J340 > pass6: 7.812MB/s transfers (7.812MHz, offset 8) > > drive as well, i've tried the same procedure there. Similar behaviour > to the Tandberg TDC4222 drive. As soon as i request a too large block > from the drive, it starts reading the entire tape (until i reset the > SCSI bus, or it will eventually encounter EOM). > > I've now DDB'ed it, and can tell you at least the following: > > sadone() calls saerror(), which will always return ERESTART (== -1), > thus it loops at this point. > > saerror(), when called, bcopy()s the sense data, resid etc. into > softc, then (most likely) enters the SSD_ILI handling, and eventually > calls cam_periph_error() to handle the error. I think something > might be wrong with this. > > cam_periph_error() eventually calls camperiphscsisenseerror(), which > in turn calls scsi_error_action(). err_action will (apparently) be > set by this to SS_RETRY. In the end, this will cause > cam_periph_error() to return ERESTART. > > I did not investigate yet scsi_error_action() itself, nor examined its > return value directly (only indirectly based on the code path inside > cam_periph_error()). So now, i think it's rather in the domain of the sa(4) driver to handle an illegal length indication properly by itself, since it's rather special to handling tapes that a `short read' from the tape (supplied blocksize to read(2) is larger than logical block size on the tape) is basically a normal operating condition which is never to be returned as an EIO, but always to be reported (in the b_resid) filed to the bio layer. So my first attempt was to catch this case, and never call cam_periph_error() in the first place at all, but return 0 from saerror(), indicating it not actually to be an error at all. Copying the residual value over to csio->resid has already been properly handled in saerror(). This procedure solves the initial problem; a test read with a 32 KB blocksize dd command from a 10 KB blocked tar tape results in 10240 bytes being read. However, using this method, saclose() always jams the process waiting in state "cbwait", as a result of the final call to "saprevent(..., PR_ALLOW)". Somehow i thought it's necessary to actually call cam_periph_error(), in order to fetch the check condition from the device. OK, i did so, and rearranged my modification to first call cam_periph_error(), but to then ignore its returned ERESTART, and have saerror() return 0. This reproducibly causes a segmentation violation panic with the following stack trace: (gdb) bt #0 0xc011f683 in heap_down (queue_array=0xc04e66fc, index=-1, num_entries=0) at ../../cam/cam_queue.c:345 #1 0xc011f390 in camq_remove (queue=0xc0851a44, index=-1) at ../../cam/cam_queue.c:180 #2 0xc0121f0c in xpt_run_dev_sendq (bus=0xc08229c0) at ../../cam/cam_queue.h:199 #3 0xc012487f in camisr (V_queue=0xc02bc4b4) at ../../cam/cam_xpt.c:6946 #4 0xc015e857 in ithread_loop (arg=0xc04f1980) at ../../kern/kern_intr.c:517 #5 0xc015da01 in fork_exit (callout=0xc015e618 , arg=0xc04f1980, frame=0xc39c8fa8) at ../../kern/kern_fork.c:731 The error happens because of: (gdb) up #1 0xc011f390 in camq_remove (queue=0xc0851a44, index=-1) at ../../cam/cam_queue.c:180 (gdb) p index $1 = -2 (I have also observed -1 once.) cam_pinfo * camq_remove(struct camq *queue, int index) { cam_pinfo *removed_entry; if (index == 0 || index > queue->entries) return (NULL); removed_entry = queue->queue_array[index]; if (queue->entries != index) { queue->queue_array[index] = queue->queue_array[queue->entries]; queue->queue_array[index]->index = index; => heap_down(queue->queue_array, index, queue->entries - 1); } removed_entry->index = CAM_UNQUEUED_INDEX; queue->entries--; return (removed_entry); } Now, is this a bug somewhere in the CAM code, or did i overlook something in my attempt to fix the sa driver? I've also reviewed the old (working) code, and it seems that one always returned 0 from cam_periph_error(), after first decrementing the retry count: case SSD_CURRENT_ERROR: { switch (sense_key) { case SSD_KEY_NO_SENSE: ^^^^^^^^^^^^^^^^^^^^^^ <- we do have no sense for an ILI cond. /* Why were we called then? Well don't bail now */ /* FALLTHROUGH */ case SSD_KEY_EQUAL: /* These should be filtered by the peripheral drivers */ /* FALLTHROUGH */ case SSD_KEY_MISCOMPARE: print_sense = FALSE; /* FALLTHROUGH */ case SSD_KEY_RECOVERED_ERROR: /* decrement the number of retries */ retry = ccb->ccb_h.retry_count > 0; if (retry) ccb->ccb_h.retry_count--; error = 0; break; [I've finally subscribed to this list again, so no need to send me a personal Cc.] -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 14 13:47:16 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.dada.it (mail3.dada.it [195.110.96.70]) by hub.freebsd.org (Postfix) with SMTP id 75EF337B61A for ; Sat, 14 Apr 2001 13:47:11 -0700 (PDT) (envelope-from ale@unixmania.net) Received: (qmail 22781 invoked from network); 14 Apr 2001 20:47:04 -0000 Received: from unknown (HELO libero.sunshine.ale) (195.110.114.252) by mail.dada.it with SMTP; 14 Apr 2001 20:47:04 -0000 Received: by libero.sunshine.ale (Postfix, from userid 1001) id 67ABD5E33; Sat, 14 Apr 2001 22:47:07 +0200 (CEST) Date: Sat, 14 Apr 2001 22:47:07 +0200 From: Alessandro de Manzano To: scsi@freebsd.org Cc: questions@freebsd.org Subject: memory mapped I/O on adaptec ? Message-ID: <20010414224707.C42900@libero.sunshine.ale> Reply-To: Alessandro de Manzano Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.3-RC Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I've just noticed in LINT the "AHC_ALLOW_MEMIO" option, and I wonder how much this setting would speed the Adaptec controllers. Would it be a "big" advantage ? LINT says also that it's not default because does not work on some motherboards. There is maybe a list of these of something ? Trying is the only option I've to know if it will work on my motherboards ? :-) Any hint is welcome! Thanks a lot in advance! -- bye! Ale ale@unixmania.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 14 22: 4:36 2001 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 44DF137B423 for ; Sat, 14 Apr 2001 22:04:25 -0700 (PDT) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f3F544s00932; Sat, 14 Apr 2001 23:04:05 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200104150504.f3F544s00932@aslan.scsiguy.com> To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Problem with current sa(4) driver In-Reply-To: Your message of "Sat, 14 Apr 2001 20:39:25 +0200." <20010414203925.A63281@uriah.heep.sax.de> Date: Sat, 14 Apr 2001 23:04:04 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >So now, i think it's rather in the domain of the sa(4) driver to >handle an illegal length indication properly by itself, since it's >rather special to handling tapes that a `short read' from the tape >(supplied blocksize to read(2) is larger than logical block size on >the tape) is basically a normal operating condition which is never to >be returned as an EIO, but always to be reported (in the b_resid) >filed to the bio layer. While it is true that the sa driver should be filtering out this particular case because there is no error, returning ERESTART for NO_SENSE is also wrong. You should be able to fix that by changing the table entry for that sense code in cam_periph.c. >Somehow i thought it's necessary to actually call cam_periph_error(), >in order to fetch the check condition from the device. This would only be the case if a controller either did not support "auto sense" or the CAM status was "auto sense failed". >OK, i did so, >and rearranged my modification to first call cam_periph_error(), but >to then ignore its returned ERESTART, and have saerror() return 0. >This reproducibly causes a segmentation violation panic with the >following stack trace: ERESTART means the error recovery code has already re-queued the CCB to retry the operation. By ignoring this code, you are telling the caller of saerror() to complete the command normally resulting in an eventual release of this particular ccb back to the free pool. A ccb can only be doing one thing at a time. 8-) To understand the symptoms of the panic, look at these definitions in cam.h: #define CAM_UNQUEUED_INDEX -1 #define CAM_ACTIVE_INDEX -2 #define CAM_DONEQ_INDEX -3 So, depending on exactly when the CCB was reused, the ccbq was manipulated, and perhaps the error recovery code's retry completed, you might see any of these three indexes or a valid index. >[I've finally subscribed to this list again, so no need to send >me a personal Cc.] I can feel a David O'Brien moment coming one. 8-) -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message