From owner-freebsd-scsi Sun Mar 28 1:36:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by hub.freebsd.org (Postfix) with SMTP id ED93514CE2 for ; Sun, 28 Mar 1999 01:36:06 -0800 (PST) (envelope-from mikko@dynas.se) Received: (qmail 14891 invoked from network); 28 Mar 1999 09:35:46 -0000 Received: from spirit.sto.dynas.se (HELO spirit) (172.16.1.10) by karon.dynas.se with SMTP; 28 Mar 1999 09:35:46 -0000 Received: by spirit (Smail3.1.28.1 #32) id m10RByr-000iSCC; Sun, 28 Mar 99 11:35:45 +0200 Date: Sun, 28 Mar 1999 11:35:44 +0200 (MET DST) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= X-Sender: mikko@spirit.dynas.se Reply-To: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: ZIP drive probe problems In-Reply-To: <199903260013.RAA89750@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 25 Mar 1999, Kenneth D. Merry wrote: > > Oops, that last patch had a little syntax problem. Try this one instead. > Done. Here is dmesg output from boot -v, with and without disc inside the ZIP drive. The second one is ok, the first is not. Just let me know if there is anything else I should try, or if you need more information. /Mikko Mikko Tyo"la"ja"rvi________________________________mikko@securitydynamics.com SecurityDynamics ---------------------------------------------------------------------- dmesg, no disc present (The ZIP is target 5 @ aha0) intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 04 from port: 0000e002 intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 1 status: 04 from port: 0000e00a found-> vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=d, irq=14 map[0]: type 4, range 32, base 0000d800, size 5 found-> vendor=0x8086, dev=0x7113, revid=0x01 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 chip2: rev 0x01 on pci0.1.3 found-> vendor=0x102b, dev=0x0519, revid=0x01 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=10 map[0]: type 1, range 32, base e6800000, size 14 map[1]: type 3, range 32, base e7800000, size 23 vga0: rev 0x01 int a irq 10 on pci0.11.0 found-> vendor=0x1000, dev=0x0001, revid=0x11 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=11 map[0]: type 4, range 32, base 0000d400, size 8 map[1]: type 1, range 32, base e6000000, size 8 ncr0: rev 0x11 int a irq 11 on pci0.12.0 ncr0: minsync=25, maxsync=206, maxoffs=8, 16 dwords burst, normal dma fifo ncr0: single-ended, open drain IRQ driver Probing for devices on the ISA bus: atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa sc0 on isa sc0: fb0 kbd0 sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 15 on isa ed0: address 00:80:c8:1c:ed:e1, type NE2000 (16 bit) bpf: ed0 attached atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa kbd0: atkbd0, AT 101/102 (2), config:0x10000, flags:0x3d0000 psm0: current command byte:0047 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 90 03 3c psm: status 90 03 3c psm: status 90 03 3c psm: status 00 00 3c psm: data 08 00 00 psm: data 08 00 00 psm: status 00 02 64 psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0, 3 buttons psm0: config:00000000, flags:00000000, packet size:3 psm0: syncmask:c0, syncbits:00 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0: disabled, not probed. ppc: parallel port found at 0x378 ppc0: 0x87 - 0xc 0x0 0x2 0x10 0x0 0x0 0x5 0x0 0x0 0x8b 0x1f 0xc 0x28 0xab 0x0 0x0 0x0 0x0 0x0 0x0 0x7 0x0 0x0 0xfc 0x0 0x1 0xde 0xfe 0xbe 0x23 0x25 0x43 0x62 ppc0: ECP+EPP SPP ppc0 at 0x378 irq 7 on isa ppc0: W83877AF chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppb0: IEEE1284 device found /NIBBLE/NIBBLE_ID/Extensibility Link Probing for PnP devices on ppbus0: ppbus0: HP ENHANCED PCL5,PJL,POSTSCRIPT nlpt0: on ppbus 0 nlpt0: Interrupt-driven port ppi0: on ppbus 0 plip: irq 7 plip0: on ppbus 0 bpf: lp0 attached aha0 at 0x330-0x333 irq 9 drq 6 on isa aha0: AHA-1540/1542 64 head BIOS FW Rev. 1.2 (ID=41) SCSI Host Adapter, SCSI ID 7, 16 CCBs vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xf00b8000 size:32k gran:32k, buf:0x0 size:0k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff npx0 on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 175070028 bytes/sec bzero() bandwidth = 88401697 bytes/sec imasks: bio c0080040, tty c003101a, net c0068080 BIOS Geometries: 0:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 1:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 2:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 3:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 4:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 5:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 6:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 7:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 0 accounted for Device configuration finished. Intel Pentium detected, installing workaround for F00F bug bpf: tun0 attached bpf: lo0 attached Waiting 15 seconds for SCSI devices to settle ncr0: restart (scsi reset). (probe3:ncr0:0:3:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe3:ncr0:0:3:0): ILLEGAL REQUEST asc:24,0 (probe3:ncr0:0:3:0): Invalid field in CDB (probe12:aha0:0:5:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe12:aha0:0:5:0): error code 0 pass0 at ncr0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number US42900MK4 pass0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled pass1 at ncr0 bus 0 target 3 lun 0 pass1: Removable CD-ROM SCSI-2 device pass1: 8.064MB/s transfers (8.064MHz, offset 8) pass2 at ncr0 bus 0 target 6 lun 0 pass2: Fixed Direct Access SCSI-2 device pass2: Serial Number 334731211806 pass2: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled pass3 at aha0 bus 0 target 5 lun 0 pass3: Removable Direct Access SCSI-2 device pass3: 3.300MB/s transfers da1 at ncr0 bus 0 target 6 lun 0 da1: Fixed Direct Access SCSI-2 device da1: Serial Number 334731211806 da1: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da1: 4110MB (8418816 512 byte sectors: 255H 63S/T 524C) cd0 at ncr0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 8.064MB/s transfers (8.064MHz, offset 8) cd0: cd present [322265 x 2048 byte records] da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number US42900MK4 da0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da0: 1003MB (2056008 512 byte sectors: 64H 32S/T 1003C) Considering FFS root f/s. changing root device to da0s1a (da2:aha0:0:5:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da2:aha0:0:5:0): error code 0 (da2:aha0:0:5:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da2:aha0:0:5:0): error code 0 (da2:aha0:0:5:0): got CAM status 0x2cc (da2:aha0:0:5:0): SCSI status 0x2 (da2:aha0:0:5:0): fatal error, failed to attach to device (da2:aha0:0:5:0): lost device (da2:aha0:0:5:0): removing device entry da0s1: type 0xa5, start 63, end = 2040254, size 2040192 : OK da1s1: type 0xa5, start 0, end = 8418815, size 8418816 : OK ffs_mountfs: superblock updated for soft updates Linux-ELF exec handler installed splash: image decoder found: green_saver ---------------------------------------------------------------------- And with disc: intel_piix_status: primary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: primary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 04 from port: 0000e002 intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: secondary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: secondary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 1 status: 04 from port: 0000e00a found-> vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=d, irq=14 map[0]: type 4, range 32, base 0000d800, size 5 found-> vendor=0x8086, dev=0x7113, revid=0x01 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 chip2: rev 0x01 on pci0.1.3 found-> vendor=0x102b, dev=0x0519, revid=0x01 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=10 map[0]: type 1, range 32, base e6800000, size 14 map[1]: type 3, range 32, base e7800000, size 23 vga0: rev 0x01 int a irq 10 on pci0.11.0 found-> vendor=0x1000, dev=0x0001, revid=0x11 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=11 map[0]: type 4, range 32, base 0000d400, size 8 map[1]: type 1, range 32, base e6000000, size 8 ncr0: rev 0x11 int a irq 11 on pci0.12.0 ncr0: minsync=25, maxsync=206, maxoffs=8, 16 dwords burst, normal dma fifo ncr0: single-ended, open drain IRQ driver Probing for devices on the ISA bus: atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa sc0 on isa sc0: fb0 kbd0 sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 15 on isa ed0: address 00:80:c8:1c:ed:e1, type NE2000 (16 bit) bpf: ed0 attached atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa kbd0: atkbd0, AT 101/102 (2), config:0x10000, flags:0x3d0000 psm0: current command byte:0047 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 90 03 3c psm: status 90 03 3c psm: status 90 03 3c psm: status 00 00 3c psm: data 08 00 00 psm: data 08 00 00 psm: status 00 02 64 psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0, 3 buttons psm0: config:00000000, flags:00000000, packet size:3 psm0: syncmask:c0, syncbits:00 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0: disabled, not probed. ppc: parallel port found at 0x378 ppc0: 0x87 - 0xc 0x0 0x2 0x10 0x0 0x0 0x5 0x0 0x0 0x8b 0x1f 0xc 0x28 0xab 0x0 0x0 0x0 0x0 0x0 0x0 0x7 0x0 0x0 0xfc 0x0 0x1 0xde 0xfe 0xbe 0x23 0x25 0x43 0x62 ppc0: ECP+EPP SPP ppc0 at 0x378 irq 7 on isa ppc0: W83877AF chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppb0: IEEE1284 device found /NIBBLE/NIBBLE_ID/Extensibility Link Probing for PnP devices on ppbus0: ppbus0: HP ENHANCED PCL5,PJL,POSTSCRIPT nlpt0: on ppbus 0 nlpt0: Interrupt-driven port ppi0: on ppbus 0 plip: irq 7 plip0: on ppbus 0 bpf: lp0 attached aha0 at 0x330-0x333 irq 9 drq 6 on isa aha0: AHA-1540/1542 64 head BIOS FW Rev. 1.2 (ID=41) SCSI Host Adapter, SCSI ID 7, 16 CCBs vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xf00b8000 size:32k gran:32k, buf:0x0 size:0k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 60 4f 50 83 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff npx0 on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 175070028 bytes/sec bzero() bandwidth = 88409512 bytes/sec imasks: bio c0080040, tty c003101a, net c0068080 BIOS Geometries: 0:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 1:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 2:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 3:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 4:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 5:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 6:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 7:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 0 accounted for Device configuration finished. Intel Pentium detected, installing workaround for F00F bug bpf: tun0 attached bpf: lo0 attached Waiting 15 seconds for SCSI devices to settle ncr0: restart (scsi reset). (probe3:ncr0:0:3:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe3:ncr0:0:3:0): ILLEGAL REQUEST asc:24,0 (probe3:ncr0:0:3:0): Invalid field in CDB (probe12:aha0:0:5:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe12:aha0:0:5:0): error code 0 pass0 at ncr0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number US42900MK4 pass0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled pass1 at ncr0 bus 0 target 3 lun 0 pass1: Removable CD-ROM SCSI-2 device pass1: 8.064MB/s transfers (8.064MHz, offset 8) pass2 at ncr0 bus 0 target 6 lun 0 pass2: Fixed Direct Access SCSI-2 device pass2: Serial Number 334731211806 pass2: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled pass3 at aha0 bus 0 target 5 lun 0 pass3: Removable Direct Access SCSI-2 device pass3: 3.300MB/s transfers da1 at ncr0 bus 0 target 6 lun 0 da1: Fixed Direct Access SCSI-2 device da1: Serial Number 334731211806 da1: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da1: 4110MB (8418816 512 byte sectors: 255H 63S/T 524C) cd0 at ncr0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 8.064MB/s transfers (8.064MHz, offset 8) cd0: cd present [322265 x 2048 byte records] da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number US42900MK4 da0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da0: 1003MB (2056008 512 byte sectors: 64H 32S/T 1003C) da2 at aha0 bus 0 target 5 lun 0 da2: Removable Direct Access SCSI-2 device da2: 3.300MB/s transfers da2: 96MB (196608 512 byte sectors: 64H 32S/T 96C) Considering FFS root f/s. changing root device to da0s1a da0s1: type 0xa5, start 63, end = 2040254, size 2040192 : OK da1s1: type 0xa5, start 0, end = 8418815, size 8418816 : OK ffs_mountfs: superblock updated for soft updates Linux-ELF exec handler installed splash: image decoder found: green_saver To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 28 6:32:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id 0EC0815834 for ; Sun, 28 Mar 1999 06:31:15 -0800 (PST) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id QAA17190 for ; Sun, 28 Mar 1999 16:34:10 +0200 (MET DST) Date: Sun, 28 Mar 1999 16:30:51 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: freebsd-scsi@FreeBSD.ORG Subject: Re: fix for amanda chg-chio script to eject tape In-Reply-To: <36F681D6.E2234C61@enc.edu> 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 created an update on the script based on the discussions here. Added a flag forceeject to amanda.conf. Anyone wanting to play with the script can pick it up at the following location: http://www.etla.net/~n_hibma/amanda/chg-chio.pl.in One remark: do not use the script in an operational environment yet. It has not been tested at all yet. And remember: If things break, you get to keep the pieces. Cheers, Nick On Mon, 22 Mar 1999, Charles Owens wrote: > In order to get chg-chio from amanda 2.4.1p1 to work happily under > FreeBSD-3_stable I had to add a few statements to the Unload subroutine to > eject the tape prior to calling the chio command to move it back to its slot. > > Did the ch(4) driver used to handle the tape ejection step itself? If not, > then I'm not sure I understand how the chio-script ever worked, since > _somehow_ the st/sa tape driver needs to be told to release the tape before > the changer can play with it. > > If this is true (that the ch(4) driver used to, but no longer does, handle > the eject step) then the chio-chg as present in the amanda distribution > probably should be patched... or at least the FreeBSD amanda port should > include the patch to be applied at build time. > > Here's the diff to chg-chio: > > 240a241,244 > > system ("/usr/bin/mt -f $tapeDevice rew"); > > system ("/usr/bin/mt -f $tapeDevice offl"); > > sleep(1); > > > > I'm not sure if the sleep or separate rewind and offl steps are needed, just > thought I'd be careful. > > Thoughts? > --- > ------------------------------------------------------------------------- > Charles N. Owens Email: owensc@enc.edu > http://www.enc.edu/~owensc > Network & Systems Administrator > Information Technology Services "Outside of a dog, a book is a man's > Eastern Nazarene College best friend. Inside of a dog it's > too dark to read." - Groucho Marx > ------------------------------------------------------------------------- > > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 28 12: 5:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from friley-185-206.res.iastate.edu (friley-185-206.res.iastate.edu [129.186.185.206]) by hub.freebsd.org (Postfix) with ESMTP id 3544014D61 for ; Sun, 28 Mar 1999 12:05:41 -0800 (PST) (envelope-from cc@137.org) Received: from friley-185-205.res.iastate.edu (friley-185-205.res.iastate.edu [129.186.185.205]) by friley-185-206.res.iastate.edu (Postfix) with ESMTP id 53FEE6D for ; Sun, 28 Mar 1999 14:05:18 -0600 (CST) Received: from friley-185-205.res.iastate.edu (localhost [127.0.0.1]) by friley-185-205.res.iastate.edu (Postfix) with ESMTP id EB895142 for ; Sun, 28 Mar 1999 14:05:17 -0600 (CST) X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@freebsd.org Subject: CAM/SCSI command references? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 28 Mar 1999 14:05:17 -0600 From: Chris Csanady Message-Id: <19990328200517.EB895142@friley-185-205.res.iastate.edu> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am looking for online SCSI command references and was wondering if anyone had any pointers. Also I am interested in the various vender specific commands relating to CDDA functions. I know very little about the command formats and codes, so just about anything will help. Also, what is the standard API that one should code new software to in FreeBSD? I imagine cam(3) at the very least--what about cam_cdbparse(3)? In the cam_cdbparse man page, it mentions that some of the commands are meant to provide an easy migration path, although it does not specify explicitly which ones. It points to cam_fill_csio() and scsi_read_write() being desireable, although I have not found these formally documented anywhere. Thanks, Chris Csanady To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Mar 28 12:35:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id A3E1414DB5 for ; Sun, 28 Mar 1999 12:35:14 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id MAA22124; Sun, 28 Mar 1999 12:34:38 -0800 Date: Sun, 28 Mar 1999 12:34:38 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Chris Csanady Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: CAM/SCSI command references? In-Reply-To: <19990328200517.EB895142@friley-185-205.res.iastate.edu> 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 Online ANSI SCSI references can be found at http://www.symbios.com/x3t10 On Sun, 28 Mar 1999, Chris Csanady wrote: > I am looking for online SCSI command references and was wondering > if anyone had any pointers. Also I am interested in the various > vender specific commands relating to CDDA functions. I know very > little about the command formats and codes, so just about anything > will help. > > Also, what is the standard API that one should code new software > to in FreeBSD? I imagine cam(3) at the very least--what about > cam_cdbparse(3)? > > In the cam_cdbparse man page, it mentions that some of the commands > are meant to provide an easy migration path, although it does not > specify explicitly which ones. It points to cam_fill_csio() and > scsi_read_write() being desireable, although I have not found these > formally documented anywhere. > > Thanks, > Chris Csanady > > > > > > 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 Mon Mar 29 14:34:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33]) by hub.freebsd.org (Postfix) with ESMTP id F0BC9158D1 for ; Mon, 29 Mar 1999 14:32:31 -0800 (PST) (envelope-from dateck@ludd.luth.se) Received: from sister.ludd.luth.se (dateck@sister.ludd.luth.se [130.240.16.77]) by zed.ludd.luth.se (8.8.5/8.8.5) with ESMTP id AAA15360 for ; Tue, 30 Mar 1999 00:32:11 +0200 From: Tomas Klockar Received: (dateck@localhost) by sister.ludd.luth.se (8.6.11/8.6.11) id AAA15190 for freebsd-scsi@freebsd.org; Tue, 30 Mar 1999 00:32:09 +0200 Message-Id: <199903292232.AAA15190@sister.ludd.luth.se> Subject: Problem with tekram and 3.1-RELEASE To: freebsd-scsi@freebsd.org Date: Tue, 30 Mar 1999 00:32:09 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM922746727-14953-0_ Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM922746727-14953-0_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I tried to help a friend with a Tekram 390F SCSI card. I attached the source file which I got from Tekram this is what I did. cp PM300.GZ /usr/src cd /usr/src zcat PM300.GZ | patch -p0 config TEKRAM cd ../../compile/TEKRAM make depend make and this is what i got loading kernel syscons.o: In function `scvidprobe': syscons.o(.text+0x241): undefined reference to `vid_configure' syscons.o(.text+0x25e): undefined reference to `vid_allocate' syscons.o(.text+0x27b): undefined reference to `vid_get_adapter' syscons.o: In function `sckbdprobe': syscons.o(.text+0x2aa): undefined reference to `kbd_configure' syscons.o(.text+0x2ce): undefined reference to `kbd_allocate' syscons.o(.text+0x2eb): undefined reference to `kbd_get_keyboard' syscons.o: In function `scresume': syscons.o(.text+0x30c): undefined reference to `kbdsw' syscons.o: In function `sc_attach_unit': syscons.o(.text+0x3d3): undefined reference to `kbdsw' syscons.o: In function `scopen': syscons.o(.text+0x61a): undefined reference to `kbdsw' syscons.o: In function `sckbdevent': syscons.o(.text+0x88d): undefined reference to `kbd_release' syscons.o(.text+0x94b): undefined reference to `kbdsw' syscons.o: In function `scioctl': syscons.o(.text+0x1e09): undefined reference to `kbdsw' syscons.o(.text+0x1e7b): undefined reference to `kbdsw' syscons.o(.text+0x1eb6): undefined reference to `kbdsw' syscons.o(.text+0x1f8a): undefined reference to `kbdsw' syscons.o(.text+0x202a): undefined reference to `kbd_get_keyboard' syscons.o(.text+0x206a): undefined reference to `kbd_allocate' syscons.o(.text+0x2097): undefined reference to `kbd_release' syscons.o(.text+0x20a0): undefined reference to `kbd_get_keyboard' syscons.o(.text+0x20bd): undefined reference to `kbdsw' syscons.o(.text+0x2137): undefined reference to `kbd_release' syscons.o(.text+0x21b2): undefined reference to `kbdsw' syscons.o: In function `sccngetch': syscons.o(.text+0x2763): undefined reference to `kbdsw' syscons.o(.text+0x2790): undefined reference to `kbdsw' syscons.o(.text+0x27d8): undefined reference to `kbdsw' syscons.o(.text+0x27fd): undefined reference to `kbdsw' syscons.o: In function `scrn_timer': syscons.o(.text+0x299d): undefined reference to `kbd_allocate' syscons.o(.text+0x29af): undefined reference to `kbd_get_keyboard' syscons.o(.text+0x29c5): undefined reference to `kbdsw' syscons.o: In function `exchange_scr': syscons.o(.text+0x2f2b): undefined reference to `vidsw' syscons.o(.text+0x2f78): undefined reference to `kbdsw' syscons.o: In function `scinit': syscons.o(.text+0x445b): undefined reference to `vid_get_adapter' syscons.o(.text+0x4468): undefined reference to `vidsw' syscons.o(.text+0x4484): undefined reference to `vidsw' syscons.o(.text+0x462c): undefined reference to `vidsw' syscons.o(.text+0x464b): undefined reference to `vidsw' syscons.o: In function `init_scp': syscons.o(.text+0x490c): undefined reference to `vid_get_adapter' syscons.o(.text+0x4918): undefined reference to `vidsw' syscons.o: In function `scgetc': syscons.o(.text+0x4cd2): undefined reference to `kbdsw' syscons.o(.text+0x52b5): undefined reference to `kbdsw' syscons.o: In function `scmmap': syscons.o(.text+0x54ab): undefined reference to `vidsw' syscons.o: In function `save_kbd_state': syscons.o(.text+0x5547): undefined reference to `kbdsw' syscons.o: In function `update_kbd_state': syscons.o(.text+0x55ac): undefined reference to `kbdsw' syscons.o(.text+0x5603): undefined reference to `kbdsw' syscons.o: In function `update_kbd_leds': syscons.o(.text+0x5649): undefined reference to `kbdsw' syscons.o: In function `set_mode': syscons.o(.text+0x5685): undefined reference to `vidsw' syscons.o(.text+0x56bf): undefined reference to `vidsw' syscons.o(.text+0x574e): undefined reference to `vidsw' syscons.o(.text+0x57ab): undefined reference to `vidsw' syscons.o: In function `set_border': syscons.o(.text+0x57db): undefined reference to `vidsw' syscons.o(.text+0x5920): more undefined references to `vidsw' follow psm.o: In function `enable_aux_dev': psm.o(.text+0xd): undefined reference to `send_aux_command' psm.o: In function `disable_aux_dev': psm.o(.text+0x4d): undefined reference to `send_aux_command' psm.o: In function `get_mouse_status': psm.o(.text+0xa9): undefined reference to `empty_aux_buffer' psm.o(.text+0xb0): undefined reference to `send_aux_command' psm.o(.text+0xfa): undefined reference to `read_aux_data' psm.o: In function `get_aux_id': psm.o(.text+0x154): undefined reference to `empty_aux_buffer' psm.o(.text+0x15f): undefined reference to `send_aux_command' psm.o(.text+0x19c): undefined reference to `read_aux_data' psm.o: In function `set_mouse_sampling_rate': psm.o(.text+0x1d6): undefined reference to `send_aux_command_and_data' psm.o: In function `set_mouse_scaling': psm.o(.text+0x232): undefined reference to `send_aux_command'psm.o: In function `set_mouse_resolution': psm.o(.text+0x28e): undefined reference to `send_aux_command_and_data' psm.o: In function `recover_from_error': psm.o(.text+0x387): undefined reference to `empty_both_buffers' psm.o(.text+0x38d): undefined reference to `test_controller' psm.o(.text+0x3a9): undefined reference to `test_kbd_port' psm.o: In function `restore_controller': psm.o(.text+0x3df): undefined reference to `empty_both_buffers' psm.o(.text+0x3eb): undefined reference to `set_controller_command_byte' psm.o: In function `doopen': psm.o(.text+0x490): undefined reference to `kbdc_get_device_mask' psm.o(.text+0x49c): undefined reference to `set_controller_command_byte' psm.o: In function `psmprobe': psm.o(.text+0x53c): undefined reference to `kbdc_open'psm.o(.text+0x574): undefined reference to `kbdc_lock' psm.o(.text+0x5b5): undefined reference to `empty_both_buffers' psm.o(.text+0x5c0): undefined reference to `kbdc_get_device_mask' psm.o(.text+0x5cd): undefined reference to `get_controller_command_byte' psm.o(.text+0x617): undefined reference to `set_controller_command_byte' psm.o(.text+0x63c): undefined reference to `write_controller_command' psm.o(.text+0x64a): undefined reference to `test_aux_port' psm.o(.text+0x6dd): undefined reference to `reset_aux_dev' psm.o(.text+0x983): undefined reference to `send_aux_command' psm.o(.text+0xa09): undefined reference to `empty_aux_buffer' psm.o(.text+0xa67): undefined reference to `set_controller_command_byte' psm.o(.text+0xaa6): undefined reference to `kbdc_set_device_mask' psm.o(.text+0xab3): undefined reference to `kbdc_lock'psm.o(.text+0xadf): undefined reference to `kbdc_set_device_mask' psm.o(.text+0xae9): undefined reference to `kbdc_lock' psm.o: In function `psmopen': psm.o(.text+0xc82): undefined reference to `kbdc_lock' psm.o(.text+0xca4): undefined reference to `get_controller_command_byte' psm.o(.text+0xcb8): undefined reference to `kbdc_get_device_mask' psm.o(.text+0xcc4): undefined reference to `set_controller_command_byte' psm.o(.text+0xcd5): undefined reference to `kbdc_lock' psm.o(.text+0xd1a): undefined reference to `kbdc_lock'psm.o: In function `psmclose': psm.o(.text+0xd48): undefined reference to `kbdc_lock' psm.o(.text+0xd6b): undefined reference to `get_controller_command_byte' psm.o(.text+0xd80): undefined reference to `kbdc_lock' psm.o(.text+0xd9a): undefined reference to `kbdc_get_device_mask' psm.o(.text+0xda6): undefined reference to `set_controller_command_byte' psm.o(.text+0xdcd): undefined reference to `empty_aux_buffer' psm.o(.text+0xe2e): undefined reference to `kbdc_get_device_mask' psm.o(.text+0xe3a): undefined reference to `set_controller_command_byte' psm.o(.text+0xe63): undefined reference to `empty_aux_buffer' psm.o(.text+0xe71): undefined reference to `kbdc_lock' psm.o: In function `block_mouse_data': psm.o(.text+0x119e): undefined reference to `kbdc_lock'psm.o(.text+0x11bb): undefined reference to `get_controller_command_byte' psm.o(.text+0x11cf): undefined reference to `kbdc_get_device_mask' psm.o(.text+0x11db): undefined reference to `set_controller_command_byte' psm.o(.text+0x11f2): undefined reference to `kbdc_lock' psm.o(.text+0x1206): undefined reference to `empty_aux_buffer' psm.o(.text+0x120e): undefined reference to `read_aux_data_no_wait'psm.o: In function `unblock_mouse_data': psm.o(.text+0x1240): undefined reference to `empty_aux_buffer' psm.o(.text+0x124c): undefined reference to `kbdc_get_device_mask' psm.o(.text+0x1258): undefined reference to `set_controller_command_byte' psm.o(.text+0x126e): undefined reference to `kbdc_lock' psm.o: In function `psmintr': psm.o(.text+0x1778): undefined reference to `read_aux_data_no_wait' psm.o: In function `enable_kmouse': psm.o(.text+0x1ce6): undefined reference to `empty_aux_buffer' *** Error code 1 Stop. The source code from Tekram was supposed to be used with freebsd 3.0 not 3.1 that I tried it with. I would epreciate all help i can get. regards, /Tomas sorry for the large attachment 40Kbyte -- Tomas Klockar can be found at the following adresses: Kårhusvägen 4:23 | Furuvägen 102 | dateck@ludd.luth.se 977 54 Luleå | 871 52 Härnösand | dateck@solace.mh.se Tel: +46-920-231335 | Tel: +46-611-13393 | d94-tkl@sm.luth.se Mob: +46-70-664 33 26 | Mob: +46-70-374 0 347 --ELM922746727-14953-0_ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename=PM300.GZ Content-Description: PM300.GZ Content-Transfer-Encoding: base64 H4sICOyT1jYAA3BtMzAwAMw7a3ObypKf8a+YtW/d2LEsIcl2Ep9HggDZbPRaQHnUrS0dBCOLMq/D w5Kytf99u2cAgSQ7OSe+Veu60YGZfk13Tz9muBcXF6Tl0MdWkHme0I9d0qdz0rkm7Tc33Xc3VyJp v3v37uj8/Jy0siRuJbHdSjZJy+2+vW7ZYbBomepHXRpWUTviTadzI15y1A8fyIXYEMl5u9F++458 +HB0fgL/IxyPAP9bGtDYtYlv2Us3oGTlpkuiyN134rolDZXWZ6Ul3a1bI1lv9cw1WVi+622I4yYP SU6rH8bED2NK3GARxr6VumFAYmo5JF1SsrQCZx6GDySy4pQYmySlPpEc3w3cJI058MXvBAnJsCL3 Povd4J6h9mNKe4ZCPtI4oB5CmTBaQHHUvuvRJsM2q8zchFiPlutZcw/lytW3tGLackK7VcKB6GHg 4botXA7xrJQmKXmkcYLUF3Ho10T5HMaeQz67DiWfQd8JjQGUsf91qg9ulmka3bRaq9WqmWM0x/pt 6/dcU1JA6HppZUnqPlLigQJIuCBhhCsBgQOH69GhKYhOHQCOPCuw+DRAoiRIB1zGtZFAQBNcahTT hAYpLhRBmq2BNjKJXVPUgilKW5BNmBHQAyMECE6YzVNYPUlDhhxlcRQmFDUTUJsmiZtukLfF2DWI vaT2A1CLE8YPOTX58oR/aM5N7lmNR9JutjtX6IVvW22x1b4mYvumK9602yScxy4NiLqOyD+Ozo/O c9cThGN07OOjczvK4EWDl5k8mW4HLncHrnYHrssBMFGQDQoCFwd5rDOwViJ0O8gy17kgDCXzbqYO pwPJVAXhxMiiKAQ/BUcm67dvCPUzj+mvgqKNVFMQBAJ/J1qQ0hjeV2H8AG5bger3jRyIAfZo/EA9 uiF9CxSHXpuwrVDHmOnjsZmThleSJcyBwTpxGKaF3f/1QGkExnKT//jv6lLqHIcUnGlzmNWwzmr4 FKsGOYa5Y9jNf76iToXAqM5rRFPUwGFmozqz0TPMRgeZDQ1lbJQMT9jrYVbHsvLu+lo8LqxjjAm+ PwvMZAOME1m50MfDHdmapKC5L9dEH8tbsSZxiNuFbbQDvMbDiWTOLruFbHLoR+BZyIqFXIwul80u +ddHVZ0Q804zasY1ZEObKepA+vpb+0oURQE8ikS4PX0IIxC/rXmYpeQ/Q0oQNFdphcBUHo+M8UDN 2UueF64I2xK48+9ja862PwSNJPSqiH1JGxhSv0DscRgIfBZGsSoHQ9WBSV+7zUHnaNsLm1DHTcO4 AvlJM6bSYFZBOHl0k8zyyC4NCmxsFsUE4YElAYH5C4SzlSPms2kceh6NBTexxNoA3RuJbHcXa+HY omBBKEus94Rt/WNtPOsr7WMyd0Pixn+Sa+LAbweSgg0ykYXjAvbROaZAAfAZOpIBMAzr4naqvTPV xpg7DTx0EwzDDwHYABLIhqyo55HVEsBh/BXmgBDCSYN41AK8RSoSmOJEOg2CmjkBf/RDeEersQwG 8c6NKSRnlwd5JwxepRDEIZG44MfEjDcss4ZlZqAsBzB9WkEIhGKSBfDuu/fLlNiQqChJIB/EbkKT BmQ7SiY6QUu03rTfXEPcT60I4jbIt7PSepA9lofK9SVsyxPCwoQVhxkkOz4NChnFjcBfF64NWcHe 1MyzOmiez1XztC8Ly6xqlllxy6wOWGbFLbOqWWaXb/sQ306F79VTfDs58fY+3+7OVLumJ8mUJhpE IjVgIYi9ggG2KUlTVDLPkl2UmWFKpiYLJw0KM7kTolEtrCjI4CMkPx4MgL8NOhFOkA0KD3aVqUU5 1ffCKNqQU9q8b5KBcdHuiGdbwMeAXLJahiTgTR5zO3BglM4NCjZ5lZKwIJErMyGngR03iLWc448N P75zBqpFMkm24IZPSxJB5s/BE4GSGySp5WElxLknzZqRgCrbzidFBYV/PV2VPs7MMQTL3vT2VtVr KMCZo1THlvN6mAAZxTqIm0QcDapMqLe2MyDlAldoVaSu1125bA3YdyEU2bC+NGQ1XGhnPi4bdh0l 5ILtLtzLrHbDJMLLOWDnwLZGR9uwEtHDujXD/M+2rxNBcOA2SBkpVKOf2UuyyJiEBaNcHE6zWVsf z+JIaU83zuPO/nsPccFnG+D9LuhqR2vz9Idxl9aPgmZ7oLgzp3eSuN2a71nELvcnoPANWmPp7kYW cd2FaFRu73aBDpD76IG9K4a4bi/evt3iiwU+gB7Eb++xv9qyv3oWO6EV7lsUN/ShuRLX9luoEOAt cb/BWwdfcmqAyKnVHD6xIagw2xe73LFqr0n9NbKSOjjGlZNxALmHpZsQslERCBp5WQEdk7MJoHu0 YUdvoOAIV0mVxGrXWUAfYlUfaNLSJqs0D7k5tm87z6JvrQGQBzQAXesBDQqdLqNQ08TzYBDQNgnW R9iW4cIhr1mZlxZ1FQ/7EAyxY/PnHiZkiNKGPN5WXltWBxz9Y085ZhHGc+0UWEBz5lYVkxS+SvIk wiIIxo2J/Mmc9XVVxUoTg0RkP0Knm3Y6kIK3xWhdUCBUBv5dA/2IOJEN3Xy6DdGC8AWKvk+qDlXz SS21fcmb6SpsHypmeaobY51Bp3iCwIrluRdCE2pnccJLobytXWKxZGGMDh4mktKAagZWxqIsV4MX gr4ZBbRNTHkDjs+oHd5QVwVgOjNkaWSo5m8dFELrDaEA2sxDK3YS1kcHYXCRpE7VSYJofUBXo8mX Y66dbrm5o3XhjOyAYGBFaRiVejnFnMDzQXHGkot2xhANCn5W5IsYwXOWAlQbaHth4Vn3Ce6ENoGE 7TxagQ27cxKuIOQPrcC6p6gb7rcTWZZ0hZxO5KGsSWeFDPW4Y8OqxYpPQEHNnRQn3u9MtCsTFa92 wwO6gfYISrpCXtithSeVxR3g1bc8DBwo0YAQ1GgFdvc57E6JneurRqW7pXL1HJXus1Qut1Te7VHZ 0vGinc31vkR7U6ABzC5alPh/YU+WHQyglV5HxrED3gCbw/WRglVUJE5GsVVAwCzBUjWKwzl2AVBd voZm4TXspmhpzWnqfmOFCNthxZlWkB8IuHg+srCgdIO9mLoeP2JilPhunVOKZ1Nr6mBJQnTWeWBb hBVsFFEL+1PsixDRpSKUNsBhnhNx4GmB24JGYpMYlPK+CJpJrHXaTQhtbH+7vC1vFqqDsCyWz4t1 tH1Jvcrzevv8WHlee5XkB62qSHYTwlsRNVBkniItO28rmZg6VVdiSzuQvw5REStUXFqjAmr4DpWC e1THW9fx3hco70uEdQ1h8by4JdqiLp/3PNrV4UV6dFanEtjfUzkWC1v8wK7hf/txXVct9q2+lm/f 1fVhKnXN28mPKdJOii0bJTRzwos8BkA3EO2OUWwEdgcTT2jvjkVRtD+YZsEByHQjtK93R++/uREm RXVNbYIvEexIqxlm6auER5ePpi7JKvQnGBl5RcTPxi6wDCRpbNlYAkGEcD08aH7AEXraOWuWzZbl QKK9JB97mPUxEISY62PCD4QarLZJPIwbePQBPSG1EpbF88IzSdnZObWgJcLiDPg2q12jIChKjxBY B6cIsWGe3d/T6oEVX8YWJJe70hJCOHp0HVhitabJbzs+EXbz4BCfHcny4/Ltyd5X45NxN+S02C3G H/MIohUEzlekpu+aGssD5YllP1B2pAwYTWiAWRAk1g0Ki5O8uvHoveUxTVmVm5fH/Cjvz4wGGKFR S8iB37/w/jwvOJpcsm2TmzfkeFdBY59dRCAj31q7fuZvARmNBMY8SC00zBLSm/SJ7WHHz7R2H1t+ QuIsYGtD3dR9rNCFcClsD9EjvmY+c3TxN6/RoEhppfSh+05s2oK5zDjaFel0bjqXN93O3hXaVbd7 ze7QWq+Pzl+/yB/SEfraQCUjaagSwi5QUCJZEMoTdgbETze+4u8NkZuDJrnLLLCUcIq3J/cfYCWg yiYUvM10dYYopP6nxi5sAXkJCRf/TvHab3kATVBoAmU7s/sNUbjrKawdYF5tMgyiyBcg56l5xsUr LwOgktT4GXQPrD20YAvE5A62IVSgUN6CJZlsp/KZHEabmCV8UPTVBWq7IG5SexmEXni/IXLYbJBB ivXBi6m8dXT+4ka80wxzrH+9YXbjKimfdPXTiaDgFRO3MoQbRTVkXZuY2njEYdpNiPtEfNMSO613 14I8uCtV2me3bTG4PoQ2ZgNdHaiSoV50moBGDQr8NuC/bXXEXfxp5FjpPuKVUGJ2CGm3W+L1Puc1 zW8loQ0Kg5KKDKYjaDKtIGDxj2N3AbtzgO8wdNwFHniVUbHT7FxIg8mdJJCS9yXHBt5vvoO9Fb7T vOIEALcpwrMI0rdb4EBE1TX5jsh36ug5Et2m2FyDE0rDs/+/fsWJlv+IDkUjhG53nrGzPIzneETv BiSBjAi7FEfmbmDxA1kfqnXW7OKBCfwX8jIj46NWXJsdCDZYDxthDE9TMHWex5xt0b0I8aoIcwIk C8dlWYuRQUSfpjfspd3ckY6lk1wsdvrDDQr3GK+2+S21NQ9ZAspjQBGwoLVgd4G1dmLLmS2xLhZw tT3L9SH7MSKdfVGAZUUthSiwViez6b9Lmvw6viBVP4cFxBZ+fMAuXXzYnbFreclW/eUhRXUhfH3d Js/Fll/mdysD6yKdDUqM7RH4hYN+TwMnjPl1PtD2w5R1TrDsNCkFoxjbneJjB1hoEi5SVj7kXkOS iNroMoDrojPF6CwBd5skKSRjBPHmkhjjvvlZ0lUCzxN9/ElTVAVzl3mnEmlq3o118scfkgHTr14R aaTAv69E/TLRVcMgY50R0oaTgQZoQEeXRqamGg2ijeTBVNFGtw3Sm5pkNDbJQBtqJoCZ4wYjv4/G qI37ZKjq8h0MST1toJlfGd++Zo6QZx8kkshE0k1Nng4knUym+mRsgLSwCEUz5IGkDVWFG0AbAWei flJHJjHupMGguq6eDQoiST1I6IwmrEvRdFU2Ufj8KScig1ZAmkGDGBNV1vBB/aKC+JL+tQFaIHhj q/7XFIBgkijSULpVDXJaVwIjtqsIvJme6uoQJYSVG9OeYWrm1FTJ7XisoIoJHsNpsmr8QgZjVHqf TA2ViwaJSmICABlQEIDguqaGxlSljUxV16csc52Ru/FnUATIKgG6wnQ6HuGyc2dQISUicdQJU3uD fL5TYVxHNcINCrGyBuUYJoRtsw0KBjwhn/L1bddMRurtQLtVR9BVAMQYKX3WDPUMLKUZCKAx9mB/ 4Dtly0frgHTwuO+hDWZHovWJpHzScAk5Aljf0HJPYSqEpMJNUPr6y4X4f0/eIBo70sH73wBCQfEN Ux6UIf6FCd6yb3gPlbEiweH3w36EF1BZgGdDPM/m2Jg4LxTQ2WA8QfdqkPmGGCldQHGgJgmA/5rQ D+XHT/H97w2s7q4v2p2L9htO6+WWyPSGmiMneIEcUP7lGr/7Eyu1L0IehpqxLyugIgEHKeidQBvp ZZCzfmVtgoUF8vL3nNOXL1/ya7mQJnjdatlpxu40tmpjN/wfVX2kDvBojXN1mozBibuA93z26Lz4 hKbGEntkzvLgtA/sQvvp+Xm2eHqSt7D5evYgHv3W4xOcYSryrYhNnkBecRcE1JGvkqtuC4y9Ffx7 tGIOvzsR0/tchO1U/h0YiJ/MIjfcQazMPjFj461ATrU6b1t+y85NuDc6s+35EzPQtj4xs47SZ2bZ AcLe6nA2sROX/czwFGJf0kpHmqPnDgtBt9uByhg2crczS7cT0xmbAkNls3JyOz3O0t7po+U12OHS GREESOfzU3xpEBg/q4F+3gNdPQU62AP1aqBbYGgHYadhrplpykwaKldd+d2bSyLgzWRHbIudTubV wXuwGWeSougiawYEAa8EuK4SrJ9s8hi6Tr6L2Sd4cRal5JSNvn6MJLl39ksJOzUgL5s5tIGXSLjl TyHbyz2CsJAvFXxU2KOhwyP+VEhU2ClWasH6J0toxcQ6kQITHiFbQBERoamRxNOktOAlKMmh70MM fwlSoKA0S16C0jC5fyFFAaWX0VPVeO0XM95PUqoa7ydJVYz3k5Qqxvt5Si+jp1EY/aT5gcJfkqFO w6DplwWNdaiSniBShpGnYoeL3wYE1E4rBJ6A1WlCve9AAk8nDOjfCGX4dSFMzJQ6+hOyGKATPUkV mv6w6CzG9rLkOWgdT56T1KBB8jfWwL9v4H7aOWyQZ3Ge8IQn1qQFkNdcR/ad3RUdgk6h/4eUeMrH XlvxffswWfwMBBJXSbEClTskiZZQDIaPboya3/rrdDCGZmcNDikH6QFB0ti3fGcWhZ53mqQxNPwk r2nI6wh+OQYDJbkwbuCmoPSnTJEFeHAB5RIQwF+ksIcPshViJvEBGM8NHjhMTYl7dKQdOfhy3XDG iwyuGy3+s1Gkd/bhKpKCKojUSfFj579ODsob27XdWZp/0jcDGfeE5S4lL+5PC1Qfz64zv8GJQqEL npMbqFaKKPzTIFXFg5l97J1l1VBl/D9hcET2aGT+6V/BN8MhgO2iPLHc3A/z5TKmWqCMd7ArPDjM LU0xR7YPwVUpukFvgxH1e9qrLcANPoex8wNIzM4lkrL6IayagVkJ/QxG4T3zg9hqoPDPQmT1lOSQ fujQxq7ui/3+lBhcqSCMou1KM9kRh8/KVhxv9ukU4oDD7humBjmJKbS++5bZZcfecmf0D+wQnVrO Dzo574YO9cc8tAn20opfC0Vsw09ATkuvTa175sIOe9lEFCnW0VGuAttKU+gbd9AxeKA0iPpEj1uG 2WyGn5MV5OwwC9JffvIUpzxF3f3DO7X8Ehi8J/PoT55B8bOTfCE8PeA3W7OcBynSR/7+Gzk6/5+j c+EYxo4b8FC1QOWd6xQH/llVCw6MpgOw5v8yI+MB48xQzf9r79/707yVhWH4b/op1O632djBNmDn 0FBnbwLYYdcGB3DS7O48/DBctlnFQDnksNren/2Zg87SBdhxkrXv52V1xTYajaTRaDQajWZEFqeL mujCPphzW2WGuBd63ie1aBfJ4DaS/+20/CucU8tnnVqr2zg/fXf4Z/7vUgSyS76LhwKJ4JbTAZdA +svZDD0VfSheI5ke72IVgsgHxRWo3f407jcvL1GjiIGcFruVo2PYdt5bRSgfM6cFKmnVjq0SXNaq DihyOSF/P1qOaWICHk39kNnsXlcF9jF5DaOUR/4tpaiiLW9KB8Xf6Me7e5351816NdISTLsmR8RI kMPvgQIE/SxPYiSAVudbAjbQhRDaOeu7uIshtH2c93Dvh9B4xMo5c6ehD6LQhRToRyG0bQ7wevI4 DQrtksRAP7Gh/74/IXEb9ip8NfYqrGGvwm3Yq3A79irchr183N+OvfyerGSvwlr2+lzmgv/MEH7a 7x88Fheg8aprAYb4PA6SDQp1glfaNy+Wl8HG9Fuh+PTdvSwVHo08uwjkLbyEbiRXk7NkNpwM0JeP PD/xNpndgOrNtoBNiR1GROQzHMuuM3nukSLOh+4HulPqJi0rcSBEDia+kN911s2azyOuJZ7KWhnL VUt9HkuYx7uPU2GeSJhHu09SYZ5qGGxLRIENCnkJdJDeocK+hNlPhynijRnCFCUMcj9dKzztLhTQ AqM8dOegakhKIiGLj+5CSLy2iBASu7X/NEo/LDo4iJINix7lHWo5RU80jQ68osf7UfJh0ZO8pprf jSePddG+V/R0X9Jx36LjvXqb2etIqd59DlNwX824W1O79eK7h3Ci9003dCzAXkirC/zARxzy4EV2 IEEGK60ySgjYXOfTUb93k0U1P4PUyWxvq5cr/G4AL3Xwa8lPZJ07pIZ3nk/xipnxEtbLrLTe8d+y VxkXGGvDD/iikXxcmNoZ91ujgmPh3/wDevsxKzvvdJmdcqM9niWL5WycNXbFv7+7NwlMnzYcUWlq 7k0JQYXnu4et5EOPbHlocI8aY/XEqzmezy4NCqUUXvjcmcfZzVILOINVmtI30EE2Ym8Fk+7Ppt25 TFBfcoU73clonqzBavHIOqR2+QkGAIk1eVsOu29mDQouKb4cW90LV+FfcptH29t9SBiapWN5OQJH 7Z0d2Y7HfA0KxJc+h5LXAo50qymWDARRKvN9uB6OEtnI90FtbC6T+ZP2IN3ToIFM5m/VHa96mlh0 xmUNgVhYtUmQhnoWhFl4uum//7+0oMkirGjb6V016FFEyeY1+Pa0N/9dPICz5v/JFsTPP1Otra1S hlQI3LhEp3ysHlQoTv2GssK6uMr5EiMnbyRzkXvDe5cm1YmZndsoJSh5gP6LWQ7/UWx0v7oNCjL4 91mpfZT7+NYGmt0SDx7or+GfI0T+QGRbtXat063WOrVK56H8o9moqV9rr2FFBGtiMTPKEOBuLcet ycVwbK/d7xEoXKd2zZPh+HeoXbLLA5wIvpi5IgQop7+mby4ns6woEUUjbabgVFLI6wKTTwKc9j5K o4R4Lr+yRDRQ5q+/CFguUkZqLdwt7g7JR7XVIXlifaL6DK76z/BU82KW9H4vcenfpjRjUcMdkIHL GBnkos7wTPneSXxNiQhzNDI1CGcU8kPWVf9LdP+89J2epEYq8uJZtIayQWuWJlPYkqIZmO+kjIm3 ufj3uZj3hvIBATU65chYE3pmvBxP+v3ldJgMYgj27DmSzOrO98OHJR+Gtikz7SyPD7VKkYmRjefM l/ByB0iHlLJewUlGcLujZ9llIUIVbTXYfON40/arVGJodWMtEfSeHSgFtxhlJo52A1x+L1x4Z6VZ S/DvUK+4+yHt/g9nX+psBjg/MPfEtWhr+0NWCPSYuGqqmDvGADE4v3T9ATqigH2mjnXvB6B7NKXE Jo4ZIus70uRS/JA2U2N4o9lAXxEUVuEq4VddWJtMtMvpFPTKUe8Tesg02yQr7POQkU/wr9MYqzg0 R+4W7Z+iaIeOKEPm21vpQoEqZK0IXgu0DBQXXU0WE9FuVLu1X+sdwzy3WCIr8eNnbzsjtY/jZGEp pQi9VdJKuwINChpcd+i4tcHKmqEUxcKMQ+ADXhqu3JC1OrGZDQpxN7XhTqqCIaTPYqAVYL+h2f7v Qk4WukfqGtZEu9viqhNsqjCMAdubllL61CaZ1sidMTsyVe3rm01c4dYTBwcdOIbeavaue3MZr2ic 4DxwXDBYiIOJN5W2qdFwJVlLcbBq4T77l9jgfREvnE+FYxVefBLHtQY+Q5ahWGUkLTjNL8e0tYhn IuKqydtO4KwJ/wS+l/hmWZzJSM2ALRn/sUyWCcYhpCb7LIy9Hsp26P1J/2Yg0FEToCunVYF/ItLD lA9iwken2CMej5hfT5ajAb037fUp8m1v/GlxzW9gMWDh6JN5Uor1eWDLGQZ5IH8Q4Q0V2Hg7A79I SnQvgVz8AMR8WVIw6NjqQeBXVI5eYuZuK4Mk7OJzWSokHzC7cHK56FOJfkFjSqe9xXV3OADhskfj f2GFYcbXtvNEhhYD1s7T6zYLi0aDHmXdsbL+RBvCN0/QTlppb550F7PeeH6ZzLrzKSwm6hIcWX9/ sTcXKdVueh+7i97VVUIuVd3JNMFX+/O0VhB8EzgNCtNVYuaSz3bcm8RK+bTbrp92W7WTbqd+Wmue d7pntQa+38zkP+YLNIdq7kejyXLRxYjsoyTTl7+UHBB8UvX+Dzlf+GspA4OXkSleIecj/ZcyNgLN BzQvuId4+baSr7fFOa0uDHI+GokNCug86D04J2Qy4Mt82sPn9fjsrqfjodAWhTV5KTCucYKLQ73A prhtvfFwSmHEYWkA9rnYEUMMSoPxEun9/lz2226BsaFGNUjMt9jJWe8DdVL2CSBkrEEp4LHzCIeP 1EBWdKm2QUfNzK44+CiQTYFdgozXK9PImz/NTGQQ7How43tj+oMmAhMA9Cfj98A1GEhGeDVQ3gwn XGc+nJS8YtBIYUq5+GoQL8WX9xJg5EPgEh2O/2AE06FfPIM9cnjDpbO5Xw0K67eHd9ncuV6kWPdt HvQN1w0KBo68pvLBjV9OCxZx4MzPRX8RNA/c34chTm4SjN8NCiS9KmU8kN7FZMaipN+7CAcH2EF0 8OjixTgAKg76T5F7eGIW4bygUAfWgBIE6EUg7ImNFCfj7mg55uIkmLbhzQ2IJYyvcPkJIYZjH4LL oB+/E4pxMDvJ+KqrZz4JZh6Lk48Jz23iiBRFnX5P9m/Wt5tn5qZnnFw8uMBj1/ZKUYKyREksXie8 dlB8TdFpgvYT/KWkhSUsnjqWUDhODK2AMbDm/etksKQoTLL+H10O8AsIcLXiG4o5I1GrDyPcYgUZ W+PXsw4f6SIYcDNkDLoPMRQoQNNQoOPH9NpgSUFBgkhqC85WgjhmyPLSa1p2A/WnC1TgUfRMbqaj hDNXKK3J3b2z2/2Ly/54umVrTNwzse1oTFs0tUi5yZRCkeAeBki7+IemI9JMN0Vgfp+BdqQdO/PH HnBS9rL2B9ufmC8vONCZLQ0JB3UTZBZocvAvCdANCj8cHwj6Xu9h2HmsLZUQppvSSFS3z7BKvap3 kBk/qqKKoPqD/JRVzV+6boe+UfoMIMFKsGZVY7oOfOdXwjhArNKEZNINCgILaODs993eLOkpxsEv dPHcFJMSp8pcxUO+qDK94L/xtfHS2XEIwNUqVOVuX5KbS4Us1Ru1BJurlY4bIc0wsRcpOjLsC0Lj LMvQqByPltQwwdN5AzyEe/R10hsw93/WOSM4aig1ixrhsKk+WBb5Z+c5yaJdBtkSl8MEdHYimqrx WR3DJY6vNRJgBRZ3qPtVqi+6Z00NChTCPH8oQO3jTyGndGmAkv3BKH9iOqHDG8IrPK/Oa+e1bq1B 4VQ8PEXCg1KKjj6CjwcckpcPgwNh9+ek3vilVg26c0BokIo4lyC/5pzp5neojh20u9OulDvoUPm6 fAJrxUVUyHN/QE2DQexd9SiwD0UMgtHR20GDqFpvd8vnnWa71mj7AysyIvlMByP7wBlvjKpt0sPD k9Ojar0FSnb7dTAsiQS9M/kwhkItm88/Q5Vg9j4ZbLlI6g2jwRs0ByloDQrP8AWHqDe2vL6Aom+O CQbP0zieQp7xQC2vO41mo+aPqZKCpPBsPBED+NbvzGm5/ctmSPANCt6E2uO5bh51uq12p9s883AU JHHPYU7acHYU/Iazh6EIxxxV0cJTaxx3228blYxHk6LEcjRazq8RxXAgvYLN5peY4dRed18dtf4b GMfrzUHe5ReAFK8E6vL/hJ3YG5REU6v9t0/dp6o7WFFhmWC6qqTPwcZsPC/rxy9hgb/xl3dBMZ4y Bi96v5NRYjShwFlTijytSYzc3z3reEiKDQoJvQummXUEhD9RjOXlW48yBy4aJV0wVOf1pzlGocfI ojOFplM+7pYrGNOIl7fG8zRvzTdpNb0rKWx0ggaQsQ0Kz1m53e7WWrgsK02Mcy7xFPSiPOvN50or whAyIpnNdoED+hPMBGOLCIw71Ww0apWONbCiWd1yygfa/cInzTFIPWBhJI5NmwONon3MIg0KzXUO Wea7Fp5TQPTi/CjA81TjOU3m895VIi6WmA6DPAwsQuv+NNoxPAUjsOZmylNw0NMxf7aLeWtEey+4 Ew0KC28JiGfX2RB8JAcGCQ0KfmQYl1886tLKPkYC21ie5gPiWsf7ly/KsDldYZwTo1/QMwRY81fj 4T8x/DY+DzV7urthtGxpVLBF/dBsF733yR7Gtkf7KxEgwIOcZfAUHTxm30nnrM5xpwt7Zrf8ulw/ 0XgOLDxSS8SNVSfiiyChuEvd02a1prE8tbHIg8hsyUH86IUGE8jlzxdy1epBFe190GNP2o0z7lLp lDvnbW9nP7BxSD0/RCFs1gz68TTYj+OdkLxAcVJZ6cbglT4fgPZx2q033T3WGWqHovFitM/6XlMP fL6c7rp6gyVZRCYcrXHp4uWD0rxHKWg82VuVpEsZMd55qjuF3uVCL0uaRxzz33RY1geG1MP1Bp+4 kkznuiad++YiDkLJ/uB02NPHzM/tRqAW74Qfoc4J1qGTds35M5IkO8/h3yOiNQwBVKLmWc5MPNC2 RntzIhoTtrorSHo7Vm/mMuqspACt4yFot8gfEziQ9fTZGisfo47QeXtWM9WPE35O7eT3RJrJqJA6 PZODBAWji6OnA2jyMRCaHqk40qrmGaZjrDdemZp0vp3BsYwNC38sh8CEDQocDcwgHyzwlgyS28O7 h38mY+uEoOlTRoWsW3lharWhe2W0A17PJmMMUq1NEWcY/A1jXM9N/ZBEbXOK9illZqXcgN2vbSpl W8kWnBekuUUFTFbw2MhpuVN5yZOekUSsVTuU7WkI3Ey2R5Us9Q0KFIoxGhBQDTVIXpwfSwSy1Q6a iGECOco5BV/HHEeYViynJA/GzF8ST0T5lvpakUdfdadFXFsgri0Yri2/wPf9h1SUU+Moo0mTY8Fr DoKNwkwq3vQTqVQNiijj1aBeXFgU0x4Cph4SVF4TpKLweFeKWIPDSFSsjKtGXnMNCmdqT84bFj/g tJ5MrkifOsfoBnppQBc7LYCHvnbqjWMYpJxZmSloD3MyDQp11yO09VipEDxFuukoOmRHjQEWeLL3 YTiAZTROriaLIS9ghVhhqpRPKtC75mmt03qbUwOBddDHqwsevLZUT82qYO6RREQmZBqrVCf/5BuK 95PR8iahv3fT2MpSjmxJWCSeKhqeQsULRITgvU931aqujsq+uMCatV9rFTNRVEmKR1lZSsiUXkq9 hlQQu5f71Mv9I9MUcgT1cd/0UeZkwhJMz6fWm+a9cgv5Iyq7GRLZz3SQl1ilUnPr4hIj4z2rEx1L nUDNVs94s2FXY27HZT0cg7S0q2KrFVYH7L2ifnpaq8LG1KkfGY5psEXfri4PO5he4D1eOpktDWvC AH4x4y33MSnmKBlwbiKnUpRrXlOEY1xkQBWy29J8PKX5eKrn4/V5o/7qvCZYQ2HNw1iES59lB1tr qUNDnVIgFYBjnpMa0j3b5+x+xQ11rdorWEpnreZxzth/pD1MGZKHrHljpgYl9FTVyqmnktj1lBFj oKNIw0F3MnMQ0PZQq+bScNDlFxvVKZf4RBq2sf55mau7PTiXWc8mXNfB5nUdj+mpLbu9xxxtbu9h e3qbc2+9EYOy/KPhf4inhfknl9Z0PEht9UMPic3WQmNRIJUorIi5qke4jakrgGFYGbUIWGZdDJNc y9mVceuTWyMsWVFXqTb3OIukRWXcEdWGGJJ54Rw4YuRuGy8Ap/9SOrQpzB3KFWXT16f002q0orYu efCk+MqTHMxtk2ZXD5bmL8fpM3uKGemeZ8i2etvc0ar9FxyO0IiT082qw1Qr+Qd0GH68TzBuutM6 sAXrITmX0qiIsAYCJ6LFXivpU11D5kal2YKpblHoa4fQ/ckM7ZScWqxHN4Tcd3SOm80YicKjrcpd TNtsFC+UrMqS/EzPEJtb0PfnEo7oujONZhf2xZzD3BkS7bRf8nMeTE+P3XAMM63zhr2qMurM23yP Xln+Gjpv1H49Q5KhSTLnDDr5OOU2kHBolDTMhAHRKzw+u47kJoRng0pb5rURRzC2pcXSaLg4qTWi y38ESgAsprlaWrSkegNABRyuVyRHtA+6YBaFDONvnbb6vWnvgnMcaRFSbeEJ2hNgZckw1Za4mV+R RJhLTw1LW1ACJbY27TWoV2eKDG0Ah+Nkm/WihiINkjQi2syRsjKUnqgFkrzTbHZf1I/dBW5dR+I4 MAPuCMdgrjid3rRqfOEDPz08w7nhWXY7u5Col+xWOJX3GogqiKFAH9KH5Ql/gjnvQPlVXjywOcq0 pLSm5ulYPmD2HHU9jiRCo10yN/sDOUNqf6AULJdsZUc88vINCqQZJaWYjsinZ8D5JdjsGcch6eEf DITM2oH+dCOQUCsw0PmWIsMrlwHqzK4lTjAdNKmw+y6L1fEiFO1BRhj4LNFuVYC9yECYMxVBBnL0 eVgryixocSOogqBRUmYFqxLAGq0QWiJ98ELqmFpq19rt8jEyT+W1vSiN1JYiF6R9oBbr8fI2i/bh nDte3lZRfZ6tQKTwgIIf3bJPQAa6ssXdrjvQdqye0sOrK2sfwS6Cu71P9I5j99HmJsBAzptqHizx D4JZHb8Vkkbykf2CsQ5gwjxh82trC6un9R0TN2p+iaspaI/Hiau6bXaUYQTpjncUlC1y5m+eSO3y Sav6Fq+KvXHjUYsyv86S3gB2zt74AjVsWjTmKOfv4W/dfugtHP7/yd5u1b1cg0DZipozjeM1Gi9w vANge9SHPRJ8IC14ZTpLMuPs4w1lkOZDC47M3sfZlMqEtMZjdU8mOyITmZDKgNQGWH4hSWhj+T1h d211pLWxoCcnCeaqGmTRxoLzwrdgUi2DdTFE53BtdfOM7HgvKxHtH9FplZ5AXwylMPsHDQpCkmF8 Kvo3xPE3ewmz/839nIq2dQYJ55nOam/sadQdW5jABWV6lkOvedA/nbxY4G/tfJOzXGq+kw81mJVe nB9np9ahED19cqasSzkIcyL7g9PD/xn/sMWREinYCQYtwz5sqS53yb85q0L+DQq7LzgJdovGQ8gB RFtgFFCNITOHQ1L/Wjjd1x5WSB16orAXO8Hf9aO8+6NIN7St3w7p5/Q0ww8VMtvbodU+o18qZPqo uCpr/7OMJRZUeAcZHdVOc8JhHzDP9mX2B11bIGNYb5TwwxFNZVuZaWiAOBTeSVU9SyHvOYo1Tvyu nqJQD82TTH+Mqy8cEJL/tdwm2afUdHt7+0/7D+NJp3ws9Yf9kR1gWqYM64hZsQ0HDPJ6Lrnfk+Q+ W3CeQ4Rh/yo0cSrTl43eC41lNwDD7t70pqXgEIXYQeRC2ZRvNC4nm2NFid/FN/dpaCljmLxl3FMX 0CF65annfgYYTbwLR6AQPZ3itElZnpIiE4N/0PsS2qG61BVhfvfJLbwdDe+sUVnblCCMOdrjhk5V ym41aBFS7WyKvj+4YOSB+hxpQOnhbGL1Gyg8jrUwv8IJ6vbHi1UDUPMo7302Jg7Ng+exqrC3lL8q 6TYMdTuqk89SiNhMJjs1Ma88E8V/Jw1hujE3Svwx0nf03QbCLHujNa3gPC5iRyAsGE5KQRGfOtQ9 J84ozfGe9CLaeL3CCT5crrxepT+SXLM3rofCpvyD+G/NoOpEtOkoFr0r9fgqmO0315yReTCRKugV q316Z/usjdTuISnUlu+VsQMkQ/K1JNHHOYRAxZ98EFlM+4n+Bz0Hz3gy3uFHUbZNYAsvPfGxosyo KFN20SKiZuUMOYuE37fROpPFu9e7PGxF5bnIFoj+WzKGCPn873VE9nRL+1RA09nm1pSP/ADgtKES I6FZsnJarTRPz05qHenAh8oMebjsna6qV/u1U2tUa1XDJ+g+hBWbsCmvqNguv66hZU9688omixvU bNUwHW5NVmzLmvsb1DTOKXqMBxtUqzfqnXoZ2sTH42jPwoqPNiAO3SI4lHnMza2sZewN/yUd9KDi kw2aQ+XMXa/o9LRBRbYOs6VOKMr8tEFFdH0mY7rmHajY24CkQcUjrHmxQU20g+PhmGzhqq/9DchK k4HemHruBxs0V4FzbosPqbpesiHPKE/Nt6ri5UbcfaLrWZxTyG9QV3oYoBm5YtdNW4/GiAXCpCiF yao1iylQa91XSEXFJ8VNOvayVq52m0emJlbcREo0W9Vaq1Z1K24iJOrHje4bNKUDn9SrcvKgbpqY QNk5ADUIb5jVlrm3ZwQrL4RMenuYcbV+9PboxJDmaV6shSeZhJUyaOFZD5+Fk3GO3Ce3Mtlsln4R /wEj6+fFs6AnW+IvgTW2ttIRtzXqG0R5syUehHjWj+PkvKHd4nELOBI+fWsfF7BnYtJvzXPy1RTa dljPWsl+sNd029VOKyOf+q4Bw6sY2hlWQr5RCNeDKYTF9ZAopZ52X9Q7tI9uBg+KmKywemy6Ami3 skJRqkSh3eFODQqReXvtObDT6wl/ROs0PF+Xp9UB/IC6z1Amh0YzLllxs5btdGtjRRKrm3b8u3Nj I4bmQAv7cI3q24hvF+wm/i59PhmxvnKJYGMef6ciZCF5zUi28ZxAenxEddenA6H0zfIs6TnHQfw2 hUiImWr/Vm8CKPDuO8eG8TdBLJzvlMkoY+xF0ufzGYtCYy5iiwwM7HM8Wi3XVnvOgEZ0eES7jkzl RuYS857u2ukcCZDQ8ShA6jzCnO9+wQHsfeflMZH5iGyezf3DM6LJwEvWB8OWHFoBeDQkh5S0IXVU szA+/fyqz0Vn7dqxV21+JWtxOiunFojk3JT+RQsL/sRcMGdXZ/iOI4fxa+TvjCKwtaEJm5/lQymG oRjc9Lrz5A0K3a+AQ7cHN/jX3BubjEnlfoNu3LL117JFhx7BoDEIp4zBCY0rW7n5LJKbKZUZRC5K 6ro4FA+kMZMHYkNEDaYODQrbcqpYVRpPaTlp2yrheGbM54fix4FlI6c/oWLO2PqtUo1ON8ihr/AN ukx4NP9N13z3m6n5TiPeuMYqw6+er0uRhf+Zy4DnMkonhgHB1G8Un8u6ArDL8W8rrqbHDQrriW7T IbUHeC4WKzoQM3H7k1W/GuO9ltyvgI5Y8cfBymkNCkYToR4zX4oB3br+BdXOuxx1IjYGZnW/DR28 iAMesq1fhmXT8UtTuMBfsirk6QYMZAeqrXNaSHqkkcZvVohVWjK079AI72QBkjLf4MiQRzXfw563 xeFzN2WlAfzcZrlymMGCA4gRPdhrDkPP/iwwzw0KJ7dui0jY2FsuCUc8OAN8xpvMj08/5urVwx+L H3PAY/iT5ILIntcbnS0ZPyt21RhjLZu1edyZzMYzDvxXECFSwuNlE3UizqnEoV5gT1UdA5plPpuO wqajP2nPD51Zi8iQ6EysFCViY1kSJfpd5Yjb5bXChNqzBQ0Kh1DN/O2rQdE4khqL1invtMI0GtD0 YhG0lfpNge/Qw1N8SHT0uD4mO8WdixwOUNnEEtS8rZoXifIb3v2cjkp8RhRgpGaRzUZm64Hw3Bu2 MEi/62BNt+BKLY9f46ZxsI89RC5iPOzyGY0gCJ+3Ae9kMt4epL+PUOKvQ+G6jKhG7n9HKM/nw6sx et6Rmi2fK7K7Nj3I/qJbgon3SSFdVe7mYMcV31thqFGk0aFMvbMnxxw76PXKW3nLpW713CGHxSdN 9x0UBxTF7Nbh8Q6mLnqxHI4oWi3HOo2clZyosDKqaUABjjWfZc1/S9ap3AxeYMCUUgBbcIBRmwdS 0B3drj4oU6BP60tsIjY7O88x/QC0dZKw+4rGhjdmwYglgwlxM3mfyMhHk0sZ5YUdmyjKC4ohXUoN Cok6+9KYNBrzwaOwFx5TYRxMKClaJhPwF0bTHx7mS2L4s991MXz4cEtocWLXymwzwbetxAa6DL6j 4On+lwUOqa52Ay3e9StWFadRdNvHFANKAXit87A5pWimffzrSUBnH+JMZhVAZH8LiT0ntvEI7Fe1 CBQNCmJ+Js1yWMX+0EJYRRTZDQpoFhHpNiYn4MsWxpTPW1H48bO6IypWgVM1TbHBDymZPNvaGUNH b19VMTOdX9HaAcJtwWmY+f9YHuN/y/tnAbeuXMnH5GVwKM0NqeDzq77ML7sCCFYUvkJcTtmTj8Pi CDsszqo0cRlpyjDr1vimrKhlmR6QGEMMPa3qK8+ZtdXPZPX3iwlGfshaSEMJ79SnJD3AD7LzlO0j i9TicwIahhud1tstPaErZxT/IeuOJPZKQJgynG9cULhdmIHYp83Yx7IPBRVXthgdrEPBQxu5NeiV oybxk9pbEhTksj/Fqx9yOh0vhldLfLOdVYE6Rp+2WA0gt/hrlOZzzEG9Eit5nSZ0+cF16KZjZaU1 eQ4zGZe4DnUeYL6fs/Jx7aTWEDuisLW1JR4NCvnFDQraM+Kp5Au7gR1v9tbhQFmjlhnsMVeOqFk9 S4wA/1UdkYhKVv3wdOcjYO5+eMhY1g5adXbHVFjJ2r44sP/8PPLbpPNItrpH+M9GUsam4gYE5dez q1aO0Nca5NYol8/43xfWDQrKCYxwN7/m05XcO9YMaaUUx3+UZGItbL5mplWVQFEJgECuKr1lHXHU bkjBJqkT/VXYcU9XUs2W1GoeNrZAmAG5hoTmciGaoDwygQXHK/o+bogIPmnGSLfBIGFaLGlmevVY 1kxtv15rtrDeg60aEE+jdyJdN/y1BlMHu4yI7LDJWn6xMtusVrk8tsqXLOTOTztXjqDThqMepi+i u6p1GVcfyJLGvZEuFFmzEQ3MWBQyt9QefaIVSi6t5A9DsT/pOBqGX0yj2UoVOjKdUnRuoq0SinSC 33qiyBJQmUw/SUf5Gxk+V9aa8+O8yXKmPYC5Fz4eeUMH7Yts5AIvNu/Mp/Gp47LIAdTyVrbPoI50 dBlP9gyanndXKJURprNrrlcOJPTKXUO2YW0aQR6qlMmlmh7fhiRhrIabY1jSU4PpfqRKFWeB8L8m nxww0u3Pw94ausVKCDp9a+73GMU94ET4QQFsLHBS6Bg1hbWP6+NB8jFy0OJyevbcVltcHIafaK4B Op1fVXRvQlshJ36pJu87GEQNCmaLIxrUXpUrtXZbhPYLi2NaGJinYstUb6ix5IPx+itJ1XqxZozw zxFfHqSWI4YknZIT0L1+BdE9SwYn0eOvmrUz0JzLrEengXQmLxLEtRIRrGWOGSAp3mie5cnMqGNM 4YttGVcgbmusjQfKrz4yuxmd+4sTfskrMZXoxkWIKpFwrPTuqTie7saU0h6hMhCFj7NuE85NwctA IXWrBkfMYJu8apvMe5aDCSdvYCghbHMhGwLD11zhIy7hApKzvYzrxM+L4A9+WxTWMm5W82Q27I0w B8tvxUfFdxvCejtPCDoddJGUOiq5jgIfRLhjkoe4AJPcg5zMK/TqmPJ7jJLLBacRwcvHD5PZ7xy9 DZGuQ9ejXGuErGOeOswxnCYpGpOxfOsgp9ubHQfZH6ZzKX2T0Rioi+tG+keXocO+mZgOFwlHvljR r+tkpJ4IceCLOX2FwQHsGaD4U3MTdUJRD/ky487oTe/jAmNRMn4MIQf7x6A3+4Tn5IEV/n2sX9fI xyT6aeNcM7ywnQhv4Jee40e1rdLTOF/I9RMwugf2p27lP9M/4sUnELR5ccZpEV4teyNc4Wj/kF/B yha42wRE1h1nYpWia115oLbrVYqImFWLcYuBsuYL0OSYzR6gr/vl1g0KTK/OyychphRUtfyWeP5c PFqHsHty3pXPSmpV6R3L87+R5yAw2XfGNZRzYWl5Gax2hZrl7FzlWRt9UteUxOENCmokAwVimqhd ganbrHge/d54PFko0EHCEV0SjERCOhmyIkZxsCIlK1CiUbz1nBhqnPNrTHvUG805hRKtEDMiBfWH 5h2KgcKSTgWfrDdenddbb3XTMEsqtopFG41Cw2H4a+z9TUJhMGXsEt1zBceBDQr4GS5FXpSxbLTL 8O6t5nIDTmkeHZ3UG+o9Arp63w0KPwN3zCziLGAEoBE9MMMgHpPZQt79EaOs5idiJAU7kVHHbbYp ievJB8w8lUNUDQpSh/Q2vIDU1vyg4GymDHHvevTacL1k4mTGvzWlW+3XVf1gp7huXl6UqzA3Gn5f S8DPmBWih54ZvST0BFkLS1ERY7qqWfNJRXlwOOGdnIII+9NshyvMVhR4TdIOSO8rC0fXlsBQ4aXw pStsOTKuFF15TGeAZbLU7ePGR3uWvK3eFWVAPEHREemi3QUZhLA3S8wy5NwRZiNdISZ2bzs7q+e+ 3u6+rjWqzVaXAzla+0M2G9k0HtCrOjry8sXrLVfvJvtqAQ2MNyC8BsMehi+BRtV2itGAlKgzm6ql DqB6hrQq6o31HqlVhOXx5GgFUB2j1J02X2NiFYeS3ibLXSRiPs07xLzdqtuEmkVRbzdztcppOQcN lhtw8lLMm66cSIjSfZCPxBK2C7R5vVKTka0ykz1J0TwIHQ4nvD/Jf9x/uqIS0MEz8uU/VvJfiu77 olxr5EQHA8mdIelhmU8nOr4Qn/jS2FjBdhnsHueh1qj4hOPIralVOrObuszW4lQ6+GKkO1CRMDB1 pI7ZJiLaus2zBrLL1UtCeEJgbcuPco+1OF7RlAL5DY68WGKDbt7YE4yqXq7Ocm8ulvP9Iv0oPM61 P437uWTR9/UDuwMc2N+ZkGgfPoNdSKC1LxctyusWvMtz4So3g1dLBbhK4TjhFFAEl7JWuWEggmB8 hRTmJLg3L5Bmgt/iroHbLw0KifJgFShOigyAk1mxNATrW3L3bNf/uyae3v+C2PQT8IqgZL0gyDGM 829eT99J1pFBnuXb32HfDiEk7k3mnLWa1fNKh2kkDQqP/4WoxCmNUfEbLPuL3/zeMp3OuNQj0/3p F0Qk2BvrbXxlSlQ6+NejESrAuDv/FvQWqaRo1JJQMbOGfGDqvrDUiTHcN5a+8fZ2z8000q8TrSvF Grw6MUc0TJdJy8tFrmk34+ZB5RNbJD4XTpgwqo5KD4mpun9DytSrwXtYEUtI7ebXthpYjtFHnGJ1 yuybV8lYmuk8yBDrEO+EvA47Q5fBlbpJRsclNLCpTISJUYJ3uhuFdVO1vxmzpORikaohhyGX38av Byy+kGmbY+wjtMGfbwJXXw44L86lZo7MoLUONDG/lhq7tNqq18nt+ukehrReifP6oqcMsY4mg/Em hjfDPi4czEdxwbqSnetrJV75UGg+nS2cjLJHdHfrRShVJon1Xb0ZzvsGH4XXhG+oOzIvxjwFiYwx hUgwd3JfZuZV5nUnP8eSDPP2ocCdhyViIe3vt9fnUJMWMqHxEjaouNjD1G7J8GCczB4J4o2u93F4 s7xRBILF3lGBUNdg01lt01GdLMer8VD28K6r5nLEYBlPn/MNCslcs7PIGO3svtc6u6/NEC+HV9f4 wEDH+edrGzvFsIfTTvyrjaROiAfsYlUFu8KZnVh5iDirjoeTd1f4YFDR98PBb/jIR0potchYS9N4 MTxsOh7kEMSD4cclHsVqAaboYuLtA39FU4W/a0hU8uoSS/klRqxP9ozam4lNLkrjY8mPtYjQFSeI YCeTEsmEzYwDJWB0u1DZsNztQrNZKE3Fdn86tJ7DT4fB7fLtFBTVg1Vbjtzep0NtGEHykR+CUHsM lVqCFErP6hz/BW1Qf8EfFMAEflf7kkZqyUnHEUTjRIkXL5FiLCw0wgTKngi67H8iZ3LPGZJ6bH7o Pj7Xi50qwlTmrXdcXNNeeLo6u5LAIjMPwRmauQXgVNxe+MKJ2kuhG8b96acswctVmBM/oJvmi3b1 h5zQKzKljlxxUKfTOt0pn2IdvfpS6qilldMdw7+4Zzmh19uWS19rEVlDwm+9MRF0iqJSOT1LV1JW qCkrc8DZAPj9K+v7FFVlloygzxFNxdNzoyFo3QCXM25ZJzx0xYc6Z7VqJziV5ep/nVMG4loDU3tF AiqFdVTI7/IRukrK7CkxY8fqihho8PTshGoe3Krmq9rpWedtYDbxCaGdCTahlkr+vg0K9g+ea+mK Z+C8+/WIlFVJBO+mlKva30wp3zB34WpQSr+3YgnMkwVpOpEwSY7Hj70NCiwIa64ynM+ryx5M5P/B GhKndeCv5xTy2tTv9bt92VU8oW2rP9xWMH47Ec8AdEHGrz+W6YyQd2MBXf2b8kBK/kllHmsbNy66 oFp7QJtL5y1T6J3StE/WWvnHhwLcSdhbDQo1PLxdJB0IvuZOc+4zUG4xx+X6OYvbYzaes29ueUlL /2mRuJXMFQCn96QknUAz+LnH6sse6CKuRT06mTPCFD9sy3lMX764fdOGRV+FW1daQDZ6PK0SGFtN 2rnoZE1HoFAuk5PyMTspy/TE+XzOh6n9eoZJukA97VZelhvHNZkW22nsb9P9KBvJtKybcZHNJF7c KEbzTe14m+WGXb3qcZFS3Zig9yQ9UCki61000kaWMSYyG9RY3XQ0A3S7lD1dD63GBMrypf00xe2u 6YwiwfbmLWB/qHKyATC3smFnYE0uR4tMHLk3JdPJnO4MM/DL+v1M5w5+pp413Eo26urfjJtvlaTY ECNezROfRnZGROnuBrKUsEeWh8mAoD6rRSrhYckkVohVf2phzp6Zd3i3nlr4/itPK0J9zdQvG6Sn TkF6/xlqDEuH2bBT0mB7RiWGwuxsMyvG5koZzplPQw5VDJrKlpwvRWVL2SY8lCXFC3uKPdAZVtey LI36mc1st+Vaptu3EkZrko+T/iJzeyotbu0UoWPGwtQP7j9SdLI1lNaZ032571INo2xuaBgMT7uy hXWzoT6MjsiD1AHicLAk4VeW5rENCj0eOgzfR+F7RCEfJD7K5+kFYjwAZaZaOym/zRby+fxWiSKR vOkNF8Dci+GIXlPqVzPKKi/mCahMQ/3K03n5tBF3rTRVpXLWrdLT+3wmK27GanjISj3KZT6H20BZ 8LlNDU9UJxhgIPspWfzHlr7AYk8PCSEH29f5uXaVONq7jQlGduReRcTtFBadBZnc4feaKtiTmriO kyb5TBa2NhXp5PW/Pi3WqoO4K9sZ4Q0K4W7yOq9lBJnQYENlUy94ew0KJYpvZ0DBc/aJ9OSmm560 s+LJeYPPirc1OMjKX3mI3hlxD81AOo/XDKZ378NwsLjewxQF/A0KANhkz8njA+IDL/w1K+Mne1zr bGGSnB4cYfaWc2QdhVXDe5lpufpGfkIRNyR7MWBLXa9baS4EK9YEQdEpLkNZNEuc0WjYv2ZbFEV0 v56MJzPhV6NZk754mE+60yo32l0yA7bKnRrHKIja61fUbB4doSDTdQOTfbwuJhl4U692Xpqagck+ XhOzWshKMT/HlFqdV6oOlkf8HhVR45cccaSV81ar1oBlUut06LJjc9qdt2stU+8WhKPh1xov9IuS DcmGN5V2tYBucvzkGoA+TZNBGt8RyOTyEpg5DQQvBmmNSivb36XbLSHtv+W5IgGn4XA05Z4pyS2s j3LDiSy77f7CuDyQvFNOVvLpsn2fiAtxMbthHJTzcHuBP/QdKEbVp8DWJQ6hoL6/pT+dP6j10hZG YV2YL+a+4nmraNtK0yZahCF0Iw+5IyFwTfGexoZhBqFzO891YIfUlWM901BxOTBgJr/5ikhpc99N zXAMApqcXdwUurgXPMDnAdgSrRngfSsMIlfNWL07FOEa49HrkBtOhBf8oSfDIOEn+OOJ4B6YHUoH Y/lb19yg57Bq3Y6Hbf5l91yu8qDj1ACxjNWeJC8Bi3Waj822cvbgeGz6cShUYG+rbysD/NoBQYQ3 83KTzuImvZUy/3IO11DxvH0/889VNmEAXUlsNs/Yw8+eZzmg6DwjEW8/ybhDPfv8CbZE1s5za3OB TlLvQDzZm40NyFuMAQy2HPwQuN5uhDDgZv+5hURmuuEDiTPq1jOMmc55LLwSOxS1qe5VcoYYWA9k JR5XUIm/TqtEowvq0Ldpe4fe2lLCl906YAf9RhPACd1tDvXUSgwFn644OqWeauiUGeXP+Vppd3pn 3sDuwYCbnLbUGeIzjyISSxZQbMVwiHFyNUHnK8oU6hwUvCPdSi0oY58hYuqPGjprasvpAHrAd9yq BG1tGVchou+NvvN5DnrBAO6k8XCB1X8niM1n6R+MwMEN4heFNVc/bpZPSrbVbXVrjrLvqzrhMJym sK7f1D2qaXp+NlcYwxHz6n8QXadyuHKD39tGYw4uFu00423lNiEeeCSXWOwdfBXZ1TZuU1wrGSwm YruyJL+lOMptVuorVNMNirYa4YND8X9WYrT3yZVEQGawiCBr3JEIqvYqIljak9VlVdMjwkqEighx jOZHZEGF7KXkvc9cmGUDGYzkr+BIQrdisEABW0VaqYRF2EvI9tbxF6t9Dh24ps9eq/DZ7BVBqFIw mfFsyF2fRwJZeR1zbUyBVfhs3opTIOOqo+oDHHM6HPPzCXTnk6rpJXDOZJYx6SNWc6On6khiGG4k 1BYzOied8mn10X7/pycH2BOjXYIsPhB9TM4w36M3Ot6JNxvo07wSMKB5UPSzKBQfia2U44WrlAMk HWELe1n4dftgC2NA0QiK4hRfVu/Nk759mA0EcQ0KgWx9z+EXj9VC/T+FtSKd9+NOegTufUQCN9Wx ovCIc2DKwRDWaA+eA6haGCldmBikG4i11Sswpor457ldPWafDKX0OrqTfr9X1JHHqkPvoBXTflZv 3TGtx27tatIb3XZUVGfVqNLaWTcqrrfpQUlsdFD6jDMJfm1OJH9/Z92PVHqj/nKkLvGukskNxsQU U+NGzV5I8koWfYr4xjZBGSfmw39ykuT3k9HyJqG/d80jOce8e7umnKq6WU5HE2sVnWipdJ7qz2Q7 mPWhM13VB3m0cq9TNg0K1Gh55FPjXeyKdwmpIbi3aSD0ErH/aYRPcGfzkhtLyvIpvk56g9gTAhnH sT9HlseTm5NsCL1CSy5hgoNhpXxS6R7Xmqe1TuvtM//5VcYliENAOBn2je3bjBiH2r25iJWojqoR axgT6TCRabk3Oy5mvMtHZzQbvOXqX1knRGs0cgy42PtXsD2ZSRR7ILUNCvniwYmADQ9/bsFXBGWY QS/AjBoOxqzmcLW2+FPNPCdMuBEreF/qUQPEBYCp+OhRyS1xWQBAHu9LuSRi9lI1eIPy8UHJLQgw 7hc9+R3MpqIW49wWETzGYodlmvHjdE5nl/tzUfma/nrOu2L2AkFnvSI56xWjzno7X8dfr9Y4Ru/y Q+pNzu6ofEltPYI30sSSrPj+0H7k7juLWgI14iRqP8qWUgDw0dN2DQqbDQp7gOyO86x9OA/f5mPd IasTwsGmH2S0VOhaiVJGHLSr90ZXE686fhWtjgWz4eL6RgW+9YZlHm5JTDfJTTKZfYoigzIo4q1t rTeKnDTb4VBK7syGrhoSw1fx1FCIQ5cU4raPSX+50NOsPEDlHi0jbDIrITfeYA4j8icnF7F6MySZ x5zYgONVlIkwabobs/3kH7+bDmbvKcMAjhjdihYzTgcvA3YGQXlDxrCwwXC7N72pjYyCDfemUw5A cTlRz9YBdHclLp37QCEzDk8UchRDnV0sL/dUpoUVDGsSYUhcVaysrdAyJNiqzgCE7k+kM3K2Lygv DHdthViwUhCo5/MNOIRjmNFI9H71PmTV+OiJczLW6KrAc+gNCobGdOrNjYyTkDZUCxdUdUjlo4qg sAOxzGd9dGBUkQsw8vRkOevjhMOXS+AjRvBMFP99TvEwV/VGvSMVsjcd/ptDXa6isZa7smItLnat 9ZmG6f3SDQoWkQnCYUReS6UNCrnar7XK3R6/qdpf293uK2oVHSt0iq1V7JNWsf9ttQ0K8gM8pN7k gJfowItf9eZw5FtEopfYo9Hifr672mc0GXf5gUzqi921T3Yt5eNqNn3MUgG59ng2WU7FY/H6XFSq L2KrOIbgiY/gyVoERmpKy0BpAwWAnDRtptbr42u7Jtfu3+fzVn6tNalASKZC32NHifAcecst9KBC V97MNyWb7si3o1y530+mC/FyAqSSy+8Ulx9ya8qC61GV7iJw1FZMrV+Ipa07TPFrIpBxkmNeL+dj laYDO0C21r2pVBtMfX/JCJUzOMNagcxYQNW1ey4gXIFh0bvqcm4G6R7bo4DUg4mMUGVu59cgoVA4 gAGrDAcYmuOGYhNhhBSRtUJdba0aENboSlddHWAF8cGwPlxP4HA84kjma8VEuVKpuTz/zdjd78q3 43p8NjccgyJi8z1KjYr2yIhlfbHDBvTnwyEeExG4pGBD+1qzYdNefMPnI25Xvh3tG5PF8PKTQ3l5 SALepqAZq/f74c1NMuiOCYsngMwf6Zbc4JmgTLYzTzC+Mynr5lcb3ra4Yrne432BM0RfnLk+2ERR uNHKKJIarW2z1ilNhLXMXSSkcMzh4Di0EsO0ccsbYwIjGRnVictupWjhDE7dPkghblzldKqg6F9Z ByZs/tuTdyW7Vnl2teRMfmulUf30tFbtNpqd+pFrbt6Ui20E3+wZTbn/+3jyYZQMrhJKbaoYN4Vj mVdhe/n9DvxqwYSGMs0B9uwPrdn3a9t7DPeZK3NUmvBYFp1Epj6I81/uNIWm+v/FBzM//iMsLDqY PaWD2dNveTB7zakl6GT2NB+ZXwnwTHiXQff+XD4jnbaffblm8C/4D8e/fdcPVNX/fQYOIDIOB7Zx jOD03cPF7KZ3M+hOJ6NRVkkLjiAntil63HcP/5SLAsbBa6qu7ouzOtrcfHK56HO4OXKuvp/RYqty GcM+WB9TUsD8PdLg7LzystwSlHZmMXk/nMGQzjBTIKYLzAlK5SvQBInJGpEUPOPoaOp+cJ8+01l+ QxVtm3KYymLZqPUZyhJM6ukins6TK7qHzMgmrPiKhJMuDzlLJ7Mst8MQpg76A6QlJcY2ZOJpK5Wo LDS5aTFzvZ3CkxPTMpRaN6rBh7pFwKZSi6r1gt/p9LF/uz3VFSXVJRSnwMqKLM/YloKXvIb/uyd+ 0yxHb7lz/DtmrWzNF9VkAZrQva9BemheTd5TDDlgQHyyz+/2NcehC7Ngd9ecmA76F3qKXQ9YTKXA js7EVjLPKfoiNc5PTugNv5oqJqmUToQJ0CImU38wcWfXvCWg4zk5sJGTVKN23OxWmw0dUNR/dWBH BTVl2qXJ8n+OvPTZnabgcKEmNrZUKO1Cc9pGw2yn+wYDo6Lz/tPui3onVlU77Ams57nEir88t0j5 heUwan2j3fycZiqL2ai1D7iPym04I538Ug0Kiw+Q2kBn9NdrYZbaXzCneRTwr0NRK2N8yOKjRtuG kLMrs9WbeZYM8OF6OEqyzAffM6jQC+y+l9eXXlL9CZzmKA3spuuJBXCLvp/PMHMs/FtUMrv9EuOi 9MeLnBXP42suPo6ti3A7z48nw/EVdNUIyAx2VpdPFYAqRfuRSjGuc4rbDQqPkKMuUpLnmXadUd/L ryXrGMzqs0fJPUUr+dAbLjj7LtMW626VjDezJg13FMOFcFfDACMZGlTRtGnGZ6qVHPgA6aGeRctv BP+JpWhejSANCnXSk3mxA5ig68gEuh+mM8GMOhLMnU6DxSrt9K5Oe/Pf/WqGWLdf7J+53P3VqSND iWf25g0Ku7lamlsIdbacTSeg/gMUSHyMqil64ro3GwgG98KmZ8kVr3xaFf3r4XRrF1HUx9PlAkN8 PRP9m4HYUcYqHG7/GtRVuiHXWCiayT0O1BdDqYP905EqsCImaHBTkkOpl+5bJq02XrzvjUo+ApJJ /GXqqyZ1AqaSZzx6ffZ1n9vFH+vQCS7+REc/zeGhaKlYb57Bny9AcddSE/sP5cPxRZaBH1YanZNW 7big+kIQsI3BBg0Kh61OF5PKYLLwVltt0M3l4kUWwXIBDQryjw96KIxb/Mo4SUbrjUZAUvLSjnvE UvxWY0PN6W6Dg7HNkh3fc9canexB9ZRjjWN46TS0CFO5GWz5M1M5qZVb3aP6UXNVbew0FEO/DAJP lfWoWpVirFvFw7Ibm0ruoWV6b8DbqhR1drmMWWXJuurECGsPpe8Hrdk39HvW3Ks35ntWeqB3aCF4 RqGxyBMiy2wo/8qJbL83GMy6eGYC4K37UIlsIaRa5cjN273ZVcFSh0jtmfJ2KunN200Wi7YEgt8L Ufxebv94Dx/EI/ikfbPbp7/kNkz/vngraEeo7J7sipfL3vgNCr7PUsjW/1wkvwOn7sI2sbv4sCU4 2BBnKqdPNZn3Z8Mpbl7PVBiwKt8UoE7VoeogUXaAxiLb2RJnlTrvLQ0Kk/NKnfuznAvYsfE6kS4g KE9BMstoUKx3n7S5p7kiEXP72Qd4OTdmOWjyWqs3LJWLJiyQsbzaeAdyh4Xi7NS8hapl0l70ZrQr WOeGHB8XWKHV5iERbOMsF3NShtDFhrNzk/CkfwtwiMgJEz5f2qGMSYYtT+LDyGz1FFSMTPOKDQrb aPFZb3JSxiKsqKw8Vk1jRQ0K7UcMDA0KZkOll9gvlG65zfOJE+N86VQcWBrdTqq1dqfu7igOFmNQ SMXytlE5q7XqzdVImvb7oSiS5tFROg0KOmgX1u/W6ZX311TeX1X5YE3lg3U7Og0KGlAkjkbL+bXA b/X5bKNdXpoBgVXIIgv4SYFpNM84joyO2Hk5SxLBMKoBZzTyjvDT6VwpuXg0/D7rGZoeiFqjW+6A ntRpnm0Jz+aIVbLcJVBmXuALiN/y7/DYXW+8Oq+33m6Jv/5KgWjVXp0Dz3XbtUa7ZsPBP6RoPBDl 804TLS4SJDg1K30u//HFUQlf7jWawgmr4J59owTGKXAorDEXkLi1E4y9/gZJ4JzLVU9BaC1oFkC1 anfKrU7XBlOGCIegZLarNTAJUOzgbU+DNUlQ8UkaNb+36G2eSBqU3oh4ODSjJR8sOrDT9nHzvMMH aPM60Zyj1YH+T+ZtTDYvXfNzyg2L7sxzveViIpyvAutEjP/wzTAwy3m9cRwNhUod3/ThtD3izTiC YeXqQdtlu356Bur9K8BZuis62l/w9Wcp0kje+VLaC7jGAzlSZXpIm2+Fn3/+/DO/P9IwiiXoMsB6 l3v7gbjd+evQ2TklSLCXyXO06U/AnsUIhrT1toF9aSWbRN/Dfw6fpIgO7uFGgzEjIhmySjCmyEVP wpbuLghjewZy1KPPw5m/TfXP6TvfvBmvna/X64iItGpLs7Le0UGkn7jdm/IForp5cyW/DWiuDQpd G7MrF+QQtgEtr3tdtH4gminVkHBE9FpebiVakstdYJUiYaT+v5IG8f9XFdaoDQrugfrzVIW77fqZ 24RIuQ2Dh5sNEBIrLS+J2yL7vkFu7+XulvYvsJd/zv6cTpPCu5VQfJfi7uEbaKB33uZT+eJet/ZU xmhEx6HpULjFIDegV0QYW7ZvYY0DsHZgHNosiwKDRR5IgU6t1To/6+gznSAbLT/EwejujY64GC7E h+FwJC4w/AP8fo1pJumISVEZFPyArpLnoje27OJwDBtQNh+GUhI/OvxWrVx9q8Shy7E4g1lRQLb3 +VQrBsbsY1Hb2qfUCN0u6EO0dYourD1FZyLmcuvuWPZeFstrTOs62OmqViY0Fxbih39rPMofx0J0 P54Cvp1OWg6F/bF81gACl2GF3uE6E09vHvCiryetq7Iy1sionABTvPMaX6koI7r2fFcY8Psains5 KAJfuvfKR4Et9PRniWyMGTJF8h2IshgaBwb1jXRdMNPsmCWtiZbfT6/ZWodfyXSO2W3sYfJ6i62f bO3MKfOk4gFpziRqYeptBzeX4bRhyWE+h3D4K++FNMZDoQZnJAIXuK4Sqb68zkWmoeEzxkIomDN3 6eP49zq+vYEfxnqzphrahpLu+6yuYMm7rbsPMdKe1SUae+6Ogw+7wjeTZy/L7RpOnuyTnt0fix9z P+TUn6k3yYZNbIoRMRoBzZhbQlgb8HbdlShlb+VfKZ29zKoOPBB4/VxpNhqgUdeqntFRNqrtfN7V o6GtFJox9Hj/fpKOHO9SR3dELT2U0dgbxV0fU7gzUMrvgp2vqykTTBS749t1hway7fNKpdZuH52f dJtnD9u11ut6hdze8KgVGIBdLyy9JSq2z8irTH9PVB3SjlrBwcwch6oVfZjD/FiUti92GOIHxqyc FbLy9ohvi1ydSXVd2s+zLJO3fNM6OzMQ1DO9+ePHhPfF9LvaqQ4nhqDzv72DtS9+4AYwEsGnH5SX vYXDeFdDh9m9Okdl3GTebzP0xmZwCV+Iw1fYCSfEX4zDt8nhPoJ/Pw7fmEwVnPow/EEqfCENCv9I vn0a8d+7u6t0MAclT3mky49T4T0NCkr4J0bH470YuYM1gq3ILNOPdyWnhs13OfFA7w7uSQK68v+7 88cf1GdiSlGJD4W1dz4pmaWQzxVyxdx+7iD3KPc4Z5EsWE8uAv5svooNCnddRYXbraLCbVdR4Xar qPAtV9HaBVO43YIpfMaCKdxywShmIYn9xU43tuOHIWZENj8Tk3GCL/0i4l68p9CI88BbYnMxQmcj 4X2Gl3IaD/Oyi1/cYdIZs+uIYR7nKJ8JrX0adwzpKKlKcjGPScfjUr27mc6vNBx7YKBHG+hJ6PZt XqTc4aiwrfvpnHq+z3qWiAdkifj1qNY6K1ejV92WRDsrt+qdt104UoS6i4N3SXk4DHiz5dwLeGgr zfNGp1vs/net1Uy917E8HNGNkFtxLkmklfH7rDT2IBgOjB6KbMW0p3WoPdubtMRMFr3RrzA3swRv LvAFkXqm1Jm8SLDEv9CwXzHph0hG47OLrUdP/cmSX4FZURGponSpaR9j1CeNj4eEHGW8bhikFFZu H59df5qXB4MZOZNfjejNlHlRJpGF47LBeZib+blHMeUjN38xW3nE0CczE0ibpXAYwdxvFC7t79XS ov0al9uW4zd73ur82qk0Ov7lm1VN//rzz+JpFOavOO5OBbB2T+vVL4T5pPkmjvmhqSWFksUM6qVh lIPFjsYSY2bNP9CC+3Zu9VpJhfWZw2o8ZvV9A7Kl1q3WW3CgrTcbD9P8j6UXXOiB/M12V6WHf9vN tSAcgK+yx6qRf6ktNme5RHIIubvtt1RFPdUlmfjdBnuwEP937cCaN+59Bw6uCzfYgYW7F+DdyerV b19qpw0KARf3HTZ4X4a5e7y4/TZvLdbMip1erNjsIyg22e/FHbZ89UnzPtp84xdy78+oQ7foX/fG V8lAxvv506WojhHp3DWnKIyusrDlwUuulTyLSkPKbJDbhgW2hfcHhcgFtlB32JaHDQolU81bTiox T61MTCdN7b3Xte/dvqlW4s3gj6sJBvsajrscpTsTTivDUiRtbGFISSY+5i8vN8BuzVABLSEwr6WC +VZn6wgHk943L2GEU83JORjg24SsQRoNCvhQF565TaWLoBcn9KDakkG+Z81aGWSxDEYqcVjGH9gm gtlmEckfspdN9Ovo1FawrwkCFBJmDSUCYcyfWxDi9tp6pGZMrQ7ANtXZvwh+qbm7VW+pmAuxqW7u Qq5Vz33EqRq6DYySQi/zTRnXcUDh2F7bAsOkrRQYsF+Rs6AdT4VVSTmOYBVscwXPiUfEdsrIfhuj WhqYQ62dHXfHkxF6vv4BxLka+bYnkOJXPoE4Q7/dEeSLTlZkluwLqW87SfvW9HzFubIJcOfTYnhE 1EbYzU5za8QUAyn/LAzq2FaRu6ymtZPiBhgzUujJwINa3HEbtfFARR88NNYcLDdnTedtlF3Z8z1T u3/V7Rj69XHE0lo1+hbbdgcxnlpfU5SF9593WCF3Xx9maTz+4qvAHuTtV4HzhkLZGrI4+eeN2q9n 6LdNHiEP8St2M2iDQqxdhRBHJpWzvvQOFpnwzzCc3cd8P/kWgtAa9r3LwZz4QEsa/1X+o+l+fhyk ZzPBme4hE4hBEcpBz58tai8DQVVvdE/PTzr1mM2MG2B5ZryqVpvMlGg08I7JTJ+Cbdzt8uta96wT scbRARaTQj6OY3G6WPu1U2tUa1V+wMBFzwP3e0pbKSv+zKXNVrXW4sLIQw9veH8d+qQLrfDEb9rN 2+IcF8Z18bbKplDIEQAfeAgL76KEsMnQqv0XSiV7HJ7RD13A0CncbE0p5+vYM2LfFGc4qtrs6rhy kXtCnst5suj2MG9iyq1VwBzQ3Q7wM/LHbdhjPaj9GkmyPmoOAPLReG2B6PZmxJ5NeybNlaRTw3xt vVey+SOFQyOQIbemOL85/HUoirEYXf6add+aqPdvEeZzcRgPPS94mQSRQcgsEIy95cCoLqe+YaGw PqWSsCx+jq5NKHwH/+95pmwLm1fJJheSiYOeKXiHqqZSRvPR1UedADY0o5kX0caybEKwGUucW8lK Q5zSX9uW5NryNJwe1joXyFgbUVFutJpSUGGt62RK71I2JGuXWdHL2BwErax+TGFIGt+9yh2+dDF2 O404zUbK/XkWw2928c7N5p1wFUxbUt9hgJGnRzyv/kt0/Nee1WJ0VlPe54kUIRfs0I6Ek3Lq0frN l170eNvvQ2ffKXnC0O9MgR4y7tuPHHVZkcoNCvqOLUNhu/4BunD3Zn7luvJu9FLL1QOszTkmbMNd mYvXbcuW+NG+I84a073Yf0fDDr4/eOc69ug9GuN4Aw3w/Rb9bbl9ymFKFVXenbVesH6KHGKFc6Oq D/jHOLma+IT0XnDSHJvnqw/dYLWuP6z6yF7aidXTGjnzE3jbdWU42rS6kdi3Giw9v7S9t8ZBJ+l4 aRVsEl53XYUg0m60O5tH3A0pFEbEVXMznoy7lxh0U39iFDYhc/Mf9y9LqQBuqFxqoPhoPBdXoyG+ KEt6GKTLbYC3jFnSnc4mV86i8fytHG64HbvLAHW343Y8TqTy+lpW34xdH/B9Yz5CUQvqr0DfO3j3 OWvttPexAcPXyy0QRh4PfWAx6D2qcOED6A/yWXMxKKTLAvergqqwB/xi6zKsmzMI8hIlkP9g1MdA JSXQ+KNpKc3VEnhIv6DETufnGMNDj7g/cD54urIb3kDxX68PJUt/gsmjhdjHV7h748nsBkDR6CF0 8njCg/+sXHS86oS/7PAjcwvFHpNrERE+AA8FdJaDVyjLymox54pc+q6LLNrl734LgpGJHXEg3q0R nq50TglFllY5ENWb90rcVqhHuqYFk/vhr7e31U/EDEIRIyLSw5n+ZLyYTUYgLK+GGO7Qg7fvDqU8 fRbh/5TQbxIootNEQ8CloAyon4bRjwcXwacDu8UiPmhHWSe+W+B55UV52wDTgY+pnSzwlrMFi0gq 3GSXRMzeIzQEhx9oyni2wcXF/547CRF7PVFQluLw+Y2u+iXtx9hek2490yzHbB8eTqrDmR2blXwl bVfJtddp9B07VI7se6l1duKN/OIQUB2sJEvYHibiLx6B8jF6WGt0qbzRMZt7ZhM3QPaiivk6OBZJ +VnhfBd3xog63q1wrwic7pTaN7JNXNFXBxdKIeEQSlbskzD0R8wPRTVBP54/Nx7pd0AsHWjujDiG 2XP+2ZgugOkkO/KZ4FfjKxLHpKbQQSOieBDMQrTWRBPydaV5elpuVB/WG0dN9p61jN0bGrpXLZNM 2iKJIA+XiIWZo7fcA2q5LeAPsgDwQkYPHjHtGQ39T2uVRpxn/6StRr8NFfIu3skvGDwntZYfRUXW F/gvu83XQPrzBlqsW+cNd8+LuFoTOAOaleqHT1uz+DZZR7daEfELIOlrXkrnPWI7AOm+eNupbcp7 FElnJefZvAGwK5liDafdBpWa7C96Y+3fVzuaQOqNdeEzbqwLa2+s85rFxde+t3aGf+eba57s77Q2 AX+FT38kfzr6jv2+lvWbr6ARxlhAaXzfiAMNCjYHfLsXP/fNAa7D8b8MA4Qs4Lyh/0Y8ULR44Nt5 XN6BBUJflPAkEkaydz1chjlhxb3/FjHtN3QyjPk2bKbtSQRrkqiswuBda6aGEUVYpYX1pWd+EEfG Dei6UTBXJ+djarowGgv6bztjiYXL1aFeU5wlXMUnGjE4TrgwGOrqWECulSUtkvCmbaVrk6sIckvs QeBgtJkP/5lMLlW+Vi9zuJVs7QsPRaWuS/FnRc3VXVOxI9S3NBv5u4MdMeUbbQ775stv5uF9d+3g vjy8P0N2RrkRY8edt31mrHfq5U6TmBH+f3aij1bfjicjJkw7UM63fXvw+NscXWwC3P2lemoImHgq HkuDkWqP0nu+GiOv3MlWu+I2z8MoeXagd3Y1UcIecfUtsw19SV2IKQva/cfe4dM1BveqcSOdgUGN 0hAJ+qJ9ZZxI+Oylk+qthr5Cmaw3DQrLp4ggvcA07CS1gTPb5mFTdFOlTNB3Rx1zY9CL+w9C7779 3zD4e3h3LJ3oJlP1Nti4dCnAtfpEYKNLN7eKFUsHodL0S+zgM7cR25PsjvrZfknei5ZAObtaXKN0 Tj4ukvEgGYgb0CxX2FxXIi5oxDEHkFurkaEjxR0HbPxKmkdHcEa6tYYe2EBtr7vSplywyo3tWz3m tGLU3UF9/BwFUrAI0U9jtAHsmzyN+V+tQK575BKGnw0cS9v+q5UUxtc4Xcn1r3laivA7Roxcyei5 L6anfqGFc2Ctlq+4dJCQ/0IvoM2wIzO++hASzPjnybsvP+OPvvpM31I6fvO9LP+1KOQ4LhkS2RRS eVjFBjtHH4OIDd1DHBwqpKPtsktp1hf0Trw7HOTkb6PlmLYCrqaLXTPzznM0Sl/v6uKSAw44VoFz Ewi/NlO7RZJnurFD8eNAWP2lv/9n/EMuNhg/zj1zf1rKpvzH/JNozDPebuf93rjLyTLmv+nW3v1m mnsXniIry9nM8XiPeN+tPjjxrJnD8Mlw/Ltl1MV/5OmWyjlNMx5whQXhKMJBOlo/1s+KMyyRg3pk 48FjGDWRdkpSVbTfaiQbbA0K9EHoGBiH1ge3Q+8kZw5mpqKhqqxN78q0H7qf3eceM6P7giCuYyhJ pHNfGAnkiCNZaWdnR0drJ9muiv4NltgQdizaGsjXp3ne6QIF8inF9UYXCVQIi6VVm+hXDIvZzNil 4v2wGF0pFfUPosUFVfwoLKYHm+cdKn4cL643uPaT775GkGYr94UW1mLVbaF6uU6iXL5fJ3E0Xsgf l6PelSvEozY6V+SvFeUk/tZJWn9Q4gdfcurOYi9h2cyno37vJksnTvK12d7OqHdKOpMQfr23/uiy zuRnbNvmDaxJZIFle9vA+VcEcpi3npt8wR1sBWV17pVnfmdhs3r6EXYr8UMue17H8BY+RGzHiqS7 yjtkuUs6aue0VWt0MceZ/UBy8/Ni9LToPrpcc2q0LJnVyZvecMFPoL3kKbZXXmq7xi4ZS5RicppZ Tbo2U+tdl7IaU7l6l22ZjoMCB2t7xatuumQWK2+Z5eYvH363vafPBsApMevnCGbbB3VKhJsUzV5h LJyMVuKNYYPpSr/mtiy91sxl2zoB30PLiu88s/TBjY3hYduOIaRjT6AFsU1JhNDPYjG8gXPbcuF6 W0plcFP9Lmo6jtrHVTo9A9ZKPgCpmE5V5Q8UCey+Kma5F9hJ77u0ejv10xpn/jTV2DqNuRgLKXb6 9KVkCByqtWnzviFqPVmBMzt19Zk7Q9p8K114xHNRCO8pjDTzYhiUXKAgt2H2/2QptyHFOdiSnvsk LTF95Q1CyZdYzlVM+Gw8b893lCuOWrWaDQTfDSbjRHuIeXxhKaCw337Myu3X2XTla8nYnvs1lFY5 EN9E4SmvX9fMYHKH3Vo1i+tfH6zjtdG+OOy3eq9+j3qY6j8ea1P0sM/QppTYU5YE/JtkZXl2MVzM eiQtR5P5ArSGhVB9wS8/DMduEtGYOmaW8i2VL6vKhg0KWEr6QL0Co0T9DEsCtOfMQuaWu4dYH5gh kosV/1mxd5iXbJYEXBfSD07saiJlDfrx/0h+eQmzX692XwyVqvPB9ZC6kI+AFe+jNlMqRQwnOg0K NNVIyf5dkM0XVF5lXYrNGt85+jp6tayjubjEoF7/dShE1rgGplCGE3ZT3Fwd7PXkvGFiHq4wwaiE 0tja94diO5s9U6098A0ubjw7hTUwQCjnspV5bqNX1m7WbksHvkXWbmd9R+KtrEmwG9P9bp8bepPE hfQ8LkVHbMfC4PgrL2V8qQszPZTMmpzD+M+6GD+rWHzTZIxrtNJ4CKLNEjcq6JU5dVaG//GNanc9 ulpiK8WgmeIqUa21O/Wov3LKM+tN31evflkd603kUXX4CLqQ2g35/Lmwqvb+utr7q2of6MDXx35c Av6omVj3NttCHzyexv0IDiiz0ZyyVe+VK7+I+fBqDNDp6L+JO6L8+IYycqPNwLlkOkqA7ZOPSX9J utLkUvRUHAA6tCBcm4fWZ3A6lU5o4FfJGNiuzxUGMxAhROmvdvekjiH21Zy6bbJu6WwtmnVm62PZ NJXboflY+jKZM/+Ro0vM5Vxpz3d9C5E5I5lRb7xCYcMd8Z9fWB9posTNx7W/Wh/XFKuy9VgDXcxU mBSVt8d85h+s18LyTGB9Uo4HGeVmabXSSW4cp8tbvvdwWvtS5s9K+ZTV7qwNOO0trnOmrNtplSu1 XPYHyWZiR5j4gj8OUOP2j+xb6tgjT7nipN7GTfe0+bqWfWC1BWw0vOmOQB+b744SVQsqLMdo8Jks F1lesvKvnMj2e4PBrLtgj86cM0CG6favadtTEkj2gTuiqCTZV5doi+pcGWdCi03JTKRqUkMjtVq1 V+iKbdS71W6M38kc6iaP61y/Mu4tUawmfywTOMfR8wght3DnAGchB03MQV9ywNz3yHm3MNUqVXlZ q/wCGljVaHVDfLnBgFHIUE1Lo1Zo8jL+mP3f+93EUao0NVvJYvZJRsrLB62R8s7ZMR6E3qZbW3pe 28nVTTJe5OFbPTi9dO1XK5QyIvKUBVaBpJ6bwSHUQf3EGF4XDQomnqhRFaMVjZbIb9P/Az5euCLZ S6/TA3z+vkGn7Q/g78DOxpguh8loQBFxesPxXLzH9OsC3+u4cXBM1aPRcn4tK2OuDWDqsdo3EwUX scrZyimOUlGdXgkFDHreZsbrSh7V3rupTIdLpN1odynBvK1Dp7Cdp8vb06oY0cSdSn3/n48whbvm GOLzGXmj+gfR+gWzEDw+9Py1O+isfd6od9jOEc3K4qyj+OQ50iWzatLs+VbZ5zTHZ7yZM/np1wkg nxfsrocHSRkdgj4mtIi3kt058J8xOjWzQVUNCmGyFWEmGQ+GXjO0ydih+jTn2vF2ZRCcOPsFMikC FEu05rCHfnw1o+NbaAYXsQsXoVKXW1/A5le/9PFJA7goiGcBtAz8ZezmavMczq3vQF2Eoydb2MMG F/8+F/MeSKjFdW/Buvt0Nukn8/lkJuC0Km4ms4T8BXEo4yQZoL4/mHiYnJh/UUufdQy3KKjN+/pQ LVWBuJqiLuIx2SIP1TZFWV+v3pitztt3efGISXaA2uhXFoNEkiIzSZxbHYml5AOx3m2BRbMjSmDU 4I2KG+YlJigEYuOj87W8uXWG/bDA97jkk5GSVC+j/5FdfUi+R0U7qJIDix/TB/2yhEcgd2+1gZuh +Tt4ls4g+0VUePXZJBS1+GFjeiZuTFeUkzZ1s/QPf3z6MdeYLN6ys576xjg4xOQFqOFcyl2KpRGk Hklzu96XgeOycoAskPGgNsecoXjYqLdZJvMjH63fxbaWDcaqhtpiLbqNittu8LGuaGI9d2bTxhST dXKerXWt1ZHbaDF2P269J67SofWdbkxQoMW5dnR+cpKaNF3veWn+FA0KVmtElmXVuv0NM0GkC81g T7qLYhXX7lO0Ek2HrzETsYmwzkUpt002DQRGl0o5St0PQdKQb3auC8YsooN+cd5+G4uLl3pBaEQZ lT1T++XFcv5JwG7+41yZJrrdo/pJrdvF307qDfjNX/D2Yt+QKNjfku7JStYgUHma4vtF6mROwPFB 9K7gQCVGaJr9j4w6EW1EsVYN70aOTupuJpo7Ew42nGT2HlScL088q+sb0tBZXrB5/vrrryGp1i+W iA0K6xkVUlOEhKc9qzCyxIKLHEcb90vj6niII5L42IPZ8KzgPpzdXI8PslCEqvxtlfl7UefvU6E3 gZtXa/Mq74i332v2SktjjZ+Vjg/BEpU3DQrzxfLycjm97Q0KpfYiqxQ/t9rVIleAgYOgdYKhlQfd zuqQiVvhcSbj2Vut5aqWqtknHwSRFFN2yNQ9b/XWRfedgBVHjCK7PholV6D7yMfR2QnMwt4S1vFM zJbjrTSB7TnNUcfPyq165y2T8nbymnq8kh/uIq5laICVuRpSYFITKADFqtyzy95wxIsLEMKJ60ZM 4BdyTcoIL15m2mScNypNjBuJdAsUCX2tBm02JgLkw2Tm5nb/TJ2RLayL6wQEBsigsWwDDj5sjSe5 RHbQLYsL5CFerQDYu+0rRKghfkA/I6kHzH8Qg+Xik1wNpCU+M4f827gleYaAzc12fw0KvQFv3Jw7 8eqeX42RXyY+W+DFxRIWPsj93uCTu1CClZIWNMJbKCltDcd/LIegTFH4fqlioXFaZBefpkmu35v2 +sPFpxzUWV72+iCt6SAYeBLHWDHQaWMRNkjLbzTRlyOwQUo5K4OR2JedW9o8D33t4q0nDnCKGVkv e8vRQtJspXTQ+NWTO76i2911Wnr2Y/EjecZBI/TCrAN02USRU+5ddj30zaHXRrXXnbdnNfVMzZoj 72EQAGJB/mPhCH6cj38fTz6MBaxXWFRytnCeEMafEdn+oYVqS4R7KpP+GRVsRK4IyQCJ4Ld3n/lW MUbTSOu3Wm6cO0ZRi7KOGDEi+ElPPuUqhpzUXgm8Y9WKDeb3g82MfBeuYX3yg+gX5M7A19YxZOpK +9BzoxMi2vA86c3611q1Q/ywFQCDz+emN349csYTWdWUcatD1zzKAmD0ULo0kIDIpEEdV0+DLn24 BsUZB+12DQq2dFQZ8YaKn0/ZxQvYy2zCSZcPXUS65kVyiaqlXU9ViQwl4jIYoR/sHrz/fOjh9dno E2muWD+n+nkN2xB3YkK/01yqhvHk6Hk8Un4/6TfsUNGDWklLv6t2OwDYWo5bkwvY6la35UDeqj1n LbCfP8xHbwQbCJyjiZdloeRjxINwSolHv4bXL86Ptkh2mT7pp7d0yPNIqAvJMLmWgA22IKWP2AII Iw6Z3GXynTPtcMmArvqda+BIeZCDrSr7T9L70PF6Z4hA0lbL7Sr6ZbrfNs869Ur5JO2NMF0nZLO6 RxhCV6aTU2+zn2MWTk5LG4DtS7CjLU7WKS8afLAn79QGBJsbOqGRwc4GhpFKZ1rLk7Ybh8C439rJ tLsq2aLleeQfvTURxfc21JqcmxG7KDMNCj1t+dhY3pTU9q8rmnp24izXZzioZVdzn89l9LWE2z0/ AeeGncB4s+1O88zBbP38O9AUYuztegVIwJVqolG/EXLjjZWqaU0t+jT2u/WPY+EHSomY8sjXGvIQ fVpu/0L5tCxPIesCT44TDQq12894shCfYKvXbhOHz3lE3Vcg9ib/TMZy5B+niy7Kt38mOOQ/Ir5c BTZZRPr4lzz51l53Xx21/psyDmiaYAivVjJKQMsObSDWK1TpnKMkvv3W0HeXd98hBu8iXbuCqRnm z7Wcs6UDPwJZTym/P9Q+j+4SVMgccOeE6WFKe7/pZM21uoapfSP+6j6E+1LTdape9yB01VvQ4H6G tjMuS3n3x4W3faNmmKQxwSgcon8zEKRLE18iW9JfxJDczNd9ycYHALRsqxds0igJdVrzRRUWVX+h K3zJd21yMrpV1003fNYm1AzCOhtoF1HbWxeZhiMQaC9Wy03WiRsjvXLJLVf54xoeib2H0eXQtvta Ba2k+FOxtHxbPUCJEntbLRcZldsrVpZbD6h/Tg3STYOMLVUD0e9ba9ke4W2dDy0hvEbmOd2789tt Xvq01YULxWlCSPCiK6N8ytOeXnJKbVHbMFeasjT2lF5OO9cOHzQpSYtg3yv1vvQ1k2EEC/trRzvD d4h0ofFiOY+v5Gg+syDOUxA3ZIUaslGEDmaxsnxe9JdKAsA2KUK99tFpJN+OrBvkCA0Kkjmp+Pcy yyelyF1RPxaM4n/XG+lv+kTa2cHibBgPTMMPHuxHDuvZlb/b8PGz07P0F9DK3auQzyvpI4XLzg6X bVHq7GTU+yQNCmKe9IPUXdXaSfltFhF4EUa+ZJSbe1gia8J7rovW4izzB2aVu6p2ijDgZMrp4T1S hUjHigVKIhDO0Ge9We/GC/KCn73tjKfwSBDhOLwBnj7eqLWDSDHKYmI/nHX2L6eXt4o+879LxqgA E19LuLgebpu/JvsWqXDc9y/AqrHnL4GPvDhc61ofr1pYV/UgpWqBW83KelnlO2vcwvHZ+pZ46Lne xnFRN9LecLAFJD1l4Z709QkyF666J02/Ir19W5EhfdzlFKYWid4vJtPrT3N8KGa9ueH0MGkY2CNG YQjyzrhNGyeZBy4mF710+Tf21JgrD5ds8Fwj/zHPn30HmwbjmWV7WDy3jxOZIO1RRzhyq+eG5w7F Y48o6U8CVr8GuI0DkTTDaJ+hzTyFPsM/6PO9gqzdKtUXiPaFr58Pzopy6wYn+Frbhd1oMR4Y+Fbn ok2VMGZInUZDLU8V4//Wqc++/tTpY0POjW6TC2Y2x+Ewv/p8pgR6tuZTz4KVi8TKD8JAHot4oSm+ IuG/6XGtzq5CIHujZzVeBcY4EFkp0gI4tY1oU8fqpJXlSLSVaCC3lKB9QQDltcsxs+pgYyW8yIaL z9LO758XRPBZzG56N4Nuj+JhIcTRcsyxsZ4Ja9oks6AuA/REuLPlbDrBbNLPhFRxRsN/8sUzbT8Y FoLV3OUsmZOfQ09cwRyMhcRQH0+Xi7lADGgm3xHTCdVkfwLYxsh7CYvU/c8F7usG6/0yaTjMNH2f dXttQrZN1rUabKQ3GfzHlueZIJx5Bj3BcKdUERXWxVGwoifwAhXCD4ewcSCE1SEQzJnadpLIB9FH Aw8J5aNgnu/r2/3hzTSZzSdjXGfIIrMJKyQIRErICBTjpNe/Vo4NCte9gbiaTAaomOASQYpL+N4F Br103d5Qe0kGcMxloD23j55nhaGiuoBz3VDc87G5eDOeK76/jxy19O/BAY56dF+p/YgsZ6PVDj0O Yivz+nq3nr9lL2IuOx+Gi2vuk+PAo6RAqkdOaQVO5WZDa5VdqrS3jUbsIA3JJtzAYNqlhJ4IWgjg 37K+n3GK7JDtwmd7FwTDnx3aa8FtwxhKXONKeEkbFMYj5kYiaAU1wyuHiBdEwSmSXuQ4Kr0HWd85 sNXAIhR1j1GF+vxqDsLLNc2ApCM/TpZ8cAxLEvwF1R+s+u43S0jBya34zu2f9Ds5JEQ7z2u17mmz WvMHPJVAPm4JrpFG+m/FGUvxcXHMhCpz6seKdmhZFWXuvN0iVLXGCxGYEUOkT20/4dT4cVkPsx1/ +EJFAEzhYvugfOieIjwPFfe86pPIpAWLpY/4Pmu1T+5LXlaIlLt+q3ErE52SXlLo+r09sz3w3aKm 73ivF4/Ji4bc2UfFocuu/IXfNKu1gWur78S2KD7awlgDRdv8eTQcjdA/nSbIKB270gzqvAJYzpOZ eSkQ6UQpVmESZtAg4vyHKDwCpSgfrfRhOABRLnSyu+6baqdFd0tPuy/qHZptr54U2t5ThhiE85Ah DQrBza9p3cwEB31z5YcT1y7Ge/JlSOXlL92It4xECWvAvCDptmpnTW138JrH5BxH5XanWzn5pRQp x3QctXKn1uoWHzXaQb+U9HkgypVO/XUNV0W5U282Urp2gF0jmBraXsuVX9DhXHbubybQl1PqjQKL Wiv/hboHbD8bafcSztLub6ncSwSWck839ina/bfQ7Mlgxcd37Blr79LD6ez605x3amVylUD3cjQ3 2U2cafq89B7BGOV0r7yKF2TItfIpSXca7YSBfyhjL69dVG9koA0KLrYdVhhW+az428UQNVvGtiMD nTt7g8Lf7c1mvU+/Dd/tWi4kD4LihxSYZ81T15U4taux7d/Gz1FaL7YiTepoMh4baeaQe9cXX98W 52y0nsvBaf226xnPWdeT+SJY1deRRY2AosdaIhqZv8qCLntHdb7SH066HOucbUn12R85xf2k04Zr gj/D3D/0Gds+m9z0PnYpAMkTo2z6B2YFE9VUy9XymXQFqVe9N2p29Z2dEj/LkHTE2NaHT4TRAR03 03SdGHYsOPFwJI3IVTg2xvaAJ+maqw+adzbZNAcI/7WuPTp6MeSg1W+IbLCcCxN3mfDtb3TfpcJi 8/SXbMjwNYJVFn2MYJWnXL2Hfmyu7HDAlAxFBar8axeBKo2OA+Ke7pbWSYvduIPLSF+xih+TXOZz 6prY6Eg/ilkeIN2Kt8Ynarcr1rMQr6TeenWSvE8oGersD6dIe/jjaVfgS+NsZBDo0185rXYb56fv KLZ5sRT39XLSCVHJ8Q3ocMUNjpCfs6SgrH/9uzywm2XibcuOE4YTrdvsdk70bn/PcaqYuKL6wQ8Z Y4j5SJLbD+OM6HBSvGcd8fWwsCW0++mfJAjpMUfIarCtD2NvtxH5PxD5P1zkKEQY+z8iufjUJ/Jg Yfjut3+8U4QlikuS19lU20XvFQ2V96FwcXMp7vFoWBM3RC2RncNGOKGIIuSS0cVC8yANCn9rNN+U 6x0rbrhyTv/ym/3a3X5Itji9EbLsWL3hs+H0ejgVfTiugAZ+NZxDpfm/0P4eHdXtt3jYQ/rD/rCL D0bGl8Mr5O3bX77KwFockKoN5bVuvdGRanNZGud72kFHKRNwWB90h7M/XFnUY29iqIZhYHS7pEH0 2IW4ISNO4fdKvOAyzsKqySqgLLa8JXZoLQUNCrVCZ4tckrmRgHSZjNVT9xGcyUKxSTonObSedpQu +6knEdC8LkIzkm7aHa8OycAP/mANCm96U7onyeqZzAENXjdhZ/KvjyWHPOj3brpDzHXkOFrQG+rJ ZPE+mV3A+nBI56stamkIk7LyujcejOAbDQp98L305TQPxthPIwvzYrlBrGOiv2Oqjb5jTFFopEmx 8Gi/JDLm3nYPbVn5G1iZTpowO0tY1K9Sev7HovdXTn7BLE+vugf505f/XeK28GHWZAxEnGMTGEJg gv5KeZETCPZPQRa39DYB6VG5Em2v0TzjSPrOqOBbeUvYHyW9mb750XO0cni+26hJEnhUK3fOW7WH mC8QAIs6iD9f04ujpIfyTWBbCLBTXDEozhJQDNrR1qeMpt4l3sWsI1JaUoOotWqV0uJZrhzVRZuU 02xWq/oWZkTAmIXA2t0mE7TbaneAQzEQivQy1jkw+LGC8VVaRwcrNYRcZ/l7NsuoPefNZDbIqT9e fFok+o/qB1OE/bwv041yi2Cuq1xeZdVGcpP0r8fLG7XHAb/LrMRqG6Od0I2DCewgq/HDYXczIfqe AqcfHXdfLOc5cVap4x/F7lGz9abcqnblWgmgQf+woNl4bwOnOlHLXj/AO5CjikKtPN5PC4QdELkl wJPZrHRgZAxb9CD68tLu3UmWoHXHDQpw1oHV3m57Pfu/ik/kYoowilBp5uOMkHG4IJ8ynUKkWgSI 4vl0ame+BKn5crE+rjZzymFlsej1r++DrLSuFF15GjdffJ6bkqpnpddj7w6K6mospxTjlR5jXAwn WcWkgQjQzauGS5usb5naTK5ZOI6X7IKffz4UT51vaJkpLcNdZw0KzkrC9sGKbrvBet+PoNCsw9HF asfiL9WuizjgdTlqBUZPF4iY6hu5MVxIXPfIiPfCakRkw2soPzbntftkLdWYS/Z75ytGX3IRDMcf 7sxFFoovz0UfbC66Lz5y5FfuXrgNCjdIw1S09WTvpD2ETBUy3v8CNhspJhltxmd2hYCr7o2ZRoab 7nVrHKvO1HL2Zgn7dLWe87fP+9ZDSItYxWs5a490VJM0cfa/SJ5ZTvR3lWcWii8kz+5VeCnX/N6A Wer+jz+ambOScdBunwv2yLOIPIuoZM7J1HJ3uiEfJDQAkM5bqdma8bbEioeVvrrwMjMahXtqw1lL Q3VYwuYuPO6U/YBDc6QjG+DRTfLL38f5LzTlZ7Nk2iMz7/3OtxFVoR505skRLq70ZrNPaSp42nxT JW/5a6e8A/1YNpjRTafBXp32TOje/OWg3BBjHJUZ2F3Q3KNGzJN3nCwwEFnh3o9iZtNKOeK6s5/T slltu+FUhn6YERLeZiIM79wRkdVLr5POeTR1e2NgrF50TvdS6SjYMsITX7YN7Ysc2u93m1BnJ5fr 1rKGcnDiv/ooB46s4A8R1dbLDG7uSX8uPI45OGltQSf61q3oabR42dustWrhd+3v9KPIv+4k2bJd bhnr5Tr9xX2o3AzCGdT+OBKRTSkusAmuZuEf7kK3pvGn2CyG+5G3jHUbW7Fpzpr+PxD/2EIXXunB S6D/EM+fm67d72LjD/e/cp30f5ddwV/byxttvbi/mTU8EzFeyFtVeg/uT6WSd7n+jXqhIZ9vR1Lc DvX0qlDR+qW3ueqgdt6ZbG94RQRqXe2s1TylqN7h9JPQTucASwPV2mHOjO+BK4IzLq/7YDnskIbd 5oF4EswXCACkX79koLr5I+yh0RtzqukHwZnhC6iDcT67Z/tYNaGg37fkNCldNmMoTt+0gp8u/pnM JiILFTAvL3mK+MBbm7OYZICsHYX1L/cxyl/m4cVflh+8zR2YZ+3AO2v6AwjdDY3fYgxY3hQe+jeF FGf7L8vpSV3SxZDY7lnC9FEGL8h/ie1LesbcM+dF2FsZOU6B/RoW+8VdST/Q2ueB9+kAu23xIzOo YcdAqupGGHspqpiskIp8AayZ2FZhik9FafjwsJgTJGdsnZHwA2/Jriq1Ee+WP2g1s1DcPxDGL0xt Pyvjy7vhsMw4RR+JK+ZonpGYv/eyzzlZ5ww9LU9UYkap2Q0KdlW7RWccGSO+Fxs3HxNRzrTZmrdy C7Ew3PeDAuFZlu9/UXQmOD4th0+VHE7zsdLcc5pugjO30OLQINh5frGclxAAhA+WYW39ptfY69w6 89FkQZ4bWBKrcUQezFaNy+W4TzWwxK5hsRUWL+cJbTvi3w0K8HNxPRkEkdfMFbZUO/kjMK63la/S HSJ6sBYeb60AwjERVGEVFI6DQya5u8La+HSm14fix6eUEEPk7EasYWmHVVkX5oUr5ejfsK471lxs 6OwkpVdk8n5jjEiYXJxQNsoj8i7fDCVSMbeKqrYwCBxQvnighugSNx6h9ElxC9XOrRjtqIvu3mIb HTm3vrMdRSWGe3keInGRt+jmTqR71J9ZApMwGOKo5oBDJqiAapdqrPB7vzcaJYMcZ664Hk67lC+F k7KDjhajIIKS67VuT5yetzviuvc+ERcJtDJPFrv3OIcm8AkM39zPDRfZTd1XfZ0jELWW2kueqPJ1 /He2j2W6SuPuV7H4DkJ7mqa5S5cDd2l0lm7+ohVWduEsV6yw4yt26DC314+DZzDbYwz9rv3bEdv3 lN5L7bT2RAeZan2vTO3NqrR7chiNjcw75unHRlxDzx/NnKOrZSzSOz7MaTVz1qTGHXq/N17D0aSM ptSJkmCVquANKeXGbVdYDsalTf1/rRYcTPfWl2hnEDjPDQqvi8uZ+bw38bEXgzIfStnNh7KGjVbE DXX0TOSBZ9IuQfm/MFSJ40RMlbwm8Lv7MhZFtxR0reYnFh6Es9FgFG5P8ORoi6HVF8UtK3KKN1gX PUfoY5XP1k6doFK36i/KILnKBXqJY4oIsa0ySZRYhcTXMq+WyTLBbQs1QNz1aB9q10+1/qfsWkP9 nkl/M15gD5FRlAFCylsFyIGHjSywvTD0wwJeAfyCICMRIKOjTzz81RsP5zf6IIligsTQc35fRiaA WgsP5CK8HSjZDurqDaNaSyvAg71FnQzUfmKdBPxNRee0h/4jWBfXQtaeJ7wGr2sXVCNNZc1DAoDV Wa/UEK58Wn20X/npyYHK3kcfzOaFUVVwzq4oYQhIG5juC3wk2BsMQIuh2JzQDVFvDQqkv5tojedk bUdPy2fYU44Zxk5zR0dHOgMc46KXFTpV+OqBN2C6WudnHXf86rN624y8bPBEtPu8od7sngFfHv54 8DFXb706/PFjDvdUmcdesyX0f8uRu7o3/j7r7XlZB0fOvGSg/U4rH/6+5/ZZSgwOCUQTy/7/F8Dl 0E8n2FAmIxed9DPULcp+PIQNCph7ho8zeLKjuM3iDAcC8ljh00N1sk+pvkkf/iCnfRDAxGx/clHJ tY35FPi3bUoU8oGCX6F6irlurpJxMgO5Ror1qPcJc4cOKRubdJ2XT+LEhPO2XXDy2G0MKoyb/x9K ZrF7vczNNhyMEjGaTKa7Etj6VIAVFzoTN9eHtQFiLjvfkuBZeq5KkfH+q/mCXvGDbo5P+ubDm+5i 1hvPOYScymSb0Yl5DknGAtgfXVLgIqhK33HKIFOHn0EpOxObdRwxpMO0IP0WyWhEwwyJx0AcMmyy nCG5FAnqlyzPMWMc1P04XUh695EgyBA9UA0Kb+iQAYcODJra/EXWBbJi7FM+DQqNlWYNCuNXyH/9 9VfRvp4s4TzyIeEMf0OA48yEUBumdNjnaGjAr4RriPj/g+qHk6Q+uPmY1iSw4iUfFqlAb5cuezCz p5PBcpTMDTjmX4cBquS5NGxgLBo1jYwCssH6XMwmcNya7VpVpNKgUDHXYFQPvAgBNKNPEh/leJ3M Bnz+w65/QNaEucC8jde9GRL6Ill8gBOYwQdtzKG5I+jEcAyMPe4nOeiY7OlNT2GnILVud2FPHCcj 4GCDrSdulqPFcEeVmSGRhoK7O3LAvHej+N9Ht2uQ1eVx9EPvE58/uYYaE9BvxgPDzPH92QRmvifZ UyKzpmBCGQ1Tu4fNMr/ZYRppcp/hsOUXXTwaK85kyCnUl2zAkPiFDfcDQP3gsAvDjZEIOViN+o9D AIbF8YPY3dXnPHXMk8imZZOqRyHbnk8uF33eFwyyn5/HkPETWwvZznPSYzSyJdn5qbgQ8DkLImDJ QBABOEqbTvm47YMveldXySBey8yP1DgrUMINCiPKkMvhDB9vydnCFQknmZnKWqzOL8iVWvZJ0edM Y86eqxxPiHq9GMQCyIlCTo+Fblkoy19OKJmphajdvCVGUYJqQUxnHVOT8wgbySLT7fJeGFEW5WtG Sw/ROqGngfinof8ZS+UDX3ePcenjSlNb2u7u7v+M1aPK4FkkjQ4zA4EM76p3f9ZwcyKv08m1zyuV WrutYmzIbJc2rH3Es0NWqgkLKnRa5zUg1d4enRT50CDrODOuY8tEyacHwfKri9nosvLR/5RT0+1t Y6Cu6fX2HqLK6R4RqGlqK0cjhY30uNbpvqmfVCvlVpW/xPs69U2QYk/TRNESZLOiZlpbTKVU2uxt E02Qt7b3mFD/SkT/XJ7VXFvm86XiV24mlWHxr3vMlBE1CzsneP2tEiyzyUViTsMg8siGOKA/MOH1 fdwS8Tk8A+Jwtq0P4hu0/Kd8302W2zXnuj+d99Ui+0Mn+X3Wu+GTULaztUfgfQQnpUcNCk5RZX3h fWE3/0jkCzvwX+Gnn34iRfs9KjR65jJWmFe7JZKfJeMht7OzI/aA4Hvj5WiUOZoNxVFyIYqPReHJ s/2fnj3KC2zgu4cPH4q95Xy2N5/19+af5nsw+L1F8jt0d/c607lecrVHolh8Vjx49ugxV/vP/xQ7 +VxePCzknhYeif/8z3u+VsCgholo4Eb8THRqv2B3XlJCUhzzdyoCOJS0gELVyg4A4MQwVfEq7rRH r63pEkFR2aopDSdMd0B7v+b07x7CKh7jEZj73n0J38jU6uYbYEJgKYRajufDqzHoYcicGTqBlyKl 82s4HEorTax8NBlfZchcEysFIZHBI3PJbpmjPqvlmNk+8xuXUaBtCL99atGBkF3YixBIavvI2CIs JdpZtGrBvtEqN0CROG9lMvmP+QINCmM4IFDOSmmaHSeTK8xcghqnDDuEiEIk7DOCaPYRTXk+X94k ztmqR7GTZMzQFCzHzfIJ9eXA6ss4uZqoPlxNeqOUuuftGo/jqVUXw2U6COA8jMe6uYyCIzU6kFis AVKcT5ZLdEP4FGQVhbss2d9MdTxP/RVHzUQZX/LxcpBUDQqh6WFWEV9LnkCH/l8MF3PBY9zFDxs5 5KgzGRw2zJuKDkvTp6qquZNDpVZk6GaZBYQ02yg+0CwlumIaOoxQqyIvvFIYQ2xW7FqaUIWOZkRF NZP2htU9jfUVsZu+Pt0EebTfwqQy4SnLeLwgR8/qMX0DxzVFktVVkVdLqmeqau9yYXPk+GoNEhxR gGTVMAnf33eXEEryoE3dFjwYZ4VYe2+7tBP9yHRBooYHoTiI+8EGVXMqHZboto/lScrYAFkNCmY4 oVEp8vUZeSv9LWTdnNg+a9dYTOLus0lnNvjoW45LGRAEWQGDKKGRDc5l4n1vtEzut8E9W2b79nw9 PQcujHT4cxOUP/Vgjru1Rqf11szx/r4LwYpY28VSyLtA7lHUAO4XkWERQhdmMsW8LbpV4RmMBoPI 2c089jrLQfLcrnj1t30iaPOi+yk+spCfgQw5qTWEi/kg/9NjxTuCVku/f0F/nFPaB1zHo5GoYAB8 4F/2hvg9maEpYD5FO5tlDESDGWyBnDBiTuZAQjVOUC0FDRkDIBEGEE3D6XLEYgGQz8WOwG1gMh7R ToY7Kd9AJY79D/MhgFAbJOZL7OKs94G6KHuE13C8E0u9lpRugKOTaP+CzRMaGzUyu1rSkl5MNBSe wchDgvzJTRqMP/FPeaWWobwSgxnpg0Ra+qKUgTMcmvP6GDZoPEzG/UT41ThVjZ4PmdzOhYH9FKSe gbkapIBQPjORAYBRAIHH2+H4D9ZZ+9NhADCD48DwhmPI9WfzoBxWfW/+adyHM/G8FytVfYTysINo dLrpLfrXUH1wExTTDtBV2kqmvwjb7/dGfRjn5CYBkQffXJUyPkjvArVa7kPvIjJCaABO/9CFWUop jgFKw/7D1nMj5ymziMxRr99Ppqj2TDKZXgzAmuhMPwaQjDFWoARIwgkc3twkg+6Ykqxn+sNxAMBF 0JPfYQjjcIqS8VUXOUC2EHIAAiQfE5zhJLFLhSJQv6c6OOs7HWCWHyQXyysJMLi4KrFAwd2ZBfuX 2Z7Mh3Z7mb5SUEa8e9+dJLm6FPP7T/l+L5MxCfwoqqbWiBEus20lLbdiLsL38B0nBbnVkZfobkZt CezNEcBQ7HydnKlTo/zuISoUmYzMkagNCjDfCwhcVMOuQJzAD5I4PLlSPZHhxEv6izBDpVZkELY8 GMxKMh9gD1QLVqroYo/uo+TNtY76gPWsHITkrQ/yGjaWj5fYIWDixbUDrpJ30sy4XxZ+k9MlNSkB yGUXfrO1BgQyICpPpOz1Te932DvoWoYh8CZx75hps9DnBaCpZJbp6fyKVTh5JM6ohFzWV63k/ceP xZKQjaicuZrjKDscer4/pmHpL2Uetsc8Lvm9ldTTANvZPB0UFYp4Lv+ujQenMAG9q8SuedVY3lwk M/OVzJNpf0EJMs0X9SZnaUWygVL9tHC9Q3fROVHcmaFMd8cnSWJ3rYVQTufaDkpxkd8pLxcTkACU vDZ38XgHXe9zF092PsyGi0RddVuLh6od7NDOQ0EDcxePsF/DwRKO3u8xYZvQ73ShQZ08s+R8R2n6 7J7CkeV9Mtj/bf8dcmiJTP4YpQQ0meHV+EYdp/4uRc8EIDRUQszWC1LvZca3Ly1B8SMNWhW+kvvC cpQSo/3py0WT48lyTYTvOScSUQJJAkvJZDAqOd+d9OYL841KVuR94wLZ+fLMOrTyHFmr8w1nAcUv wwUq5R6nOXKQmRRHFi47w1BGsiT+UddJWKSfg0QvqzEILjHNyGOQfBRFeyIvbPu9mcO+JnOUbon2 TBYFGHVdZOmLJujgW7GacPIo2TVPJleg8lOjfk2z8k2CHrNEOKeJ9/e+9/eBLcTq4z/w+SBKt6eW zKv0QOEfLj7538vkKiVLCE7lF2bpyvwzOCQ0o91wLppsQaCmu/Usmxek824JmxZumhuqiOsbrRy7 jrDQmXwM0Cy5DQpgOKWP6oOGwmMJ4cyiA8F4eAE7iUdZpDsSSj4NViPnkOAOKTogZCzFhCSgb67j vD8eyXXOLPQeGl6KPHWQ74NRZOLmm5Cv+w0KgYarWvlwVUigVStfTaApm/3XEWhlKdAsdagckWQm WrBZ0U5WTUcPKPAazzhyBmkIYstklpNfWFH9zZc6lH9JVVXkoUDhT9/x2tHCUAb3N9JRh2d3tBaV HiUqy5RIUhNAIkn6s7iyjKOwl9wvOM/X52rG7frp3q9nnVtrx3I+1QUwqsjwo+QW4KEaDQrwh71s buZXw3GhuP/bgSWP5p42YyeGIlIpMnkS2RIWdhKCSB20KjniQeclsLQwGR3bUeY4D4HVNS1A9Fec TMCAcNx/G8LkVHAliBWsnrmM90vyDQqTueKRG41ThD1iJyK+YlKtGWVMuhrLbPaOpe3Dg0eV65wA Ve2QrshNLc3KcWFVNsKqzMKq/JWE1Yt6JzvfYruqvA35guZVaG2/kDEv99ySfAafdEdKij9BSTFa 8hRKDQrRkid0bxEreUzXJbGSR3QvEys5oAugWMk+lsiG3JIilRxESg0KVFKMlOSppBCWFH6iEm7I LXnKJQdhyRMuKYYlj7mkEJY84hJqyC05kCUHQcm+LCkGJUVZUghKDQqyBBtyS/Kq5MAr+UkVFL2C p6qg4BU8UQXQilPwWBccuAWPdEHRLTjQBQWPb3VB/qk7mabgwB2hKSg6BXlTUDCrH5YpLibMQ8I5 tG96/WusQRWH0kRt2f1RKh21avqyIJN3yzBkx1tVhv1xizkhtykuotzvzS6GixmZvh/CZtNFV98C 5pT7tEj8tgFBvWHh348Ud0/PTzp1JYMOXIhK8/S03KhqBI/cYr54MPgfp3TwobyNxN/9PppoEBLJ E68c4wP+elRrqUaeuuVYdFY2Xfwp6GLnvG2ROB+M8Oyk1qlVNYA3CZTMvtuuNVT/DQoWq1SbXR3B QiPwqHzeqP16hsEuWrV27UTwDQr2mQ0KPUpx33X5B2t08HbKmsN8WNxh4vksJIubjZrFQn7D1WjD PGhouOs07FbFdSA9JUK2b/5irtvcXhNuDMsfZ/zm61qr2zp3ii2KnzeqTrnH1iZJZlMzjMfTuszw dDguDQp05I4NChlRL8eQV7G43nAG/diZi3r1vHzSfV0+waO2v5pk8B1MTBHrt2aEfJQoerriJC2f d5roDwlM3K6lTqfSJ3lK3bG/lOuoe9xsUu9F3imsnXRlTg0u/GivopddmlN35jAChg1Cq4RSq2qB CSD7Noj0/Tx7WW7XukcNCuTABqk3iL7dDQqonc0zBfLYBjmpN36h8hflqursExsAvldNVestheOp DVI9PzupVzB9REUdpgDkJx8L9aLVbR9rkLINQrNm2AmD4h0dBcyI2j1bQ0nEC4yn4c0OXYLjBNH0 GBYEhIKODQriGHPLR7yaTE2KdwOCuKqrFrkqu1FQ6JKKeqmehgOqn9Y6VvMHjMNUPPUcokxlmPq3 Ttefcl15GrpYzj+tHgG9JhMWBtBfCAO9CblJBkPcstejMKNAHAcRHPrFPsbHSEEFKxYQHQGbKExy PGwf5qtrfAw2GvbTcFROq9CfUzOiYlHRk517OngzOaZnJ3EM5I1whCmWNA0K2Q1+7Hm0HI2EezQw la0lKSsfVbny+Tj5OEXfJfSRRHNB+pxiRhRriwIcNclXmBAX6/OrtEGyAISpA/EkDD48lGh05p8O WqRU6h9vEX0a97to7PPWDW7dMqgYsV7eK2OpzPf67iZm4lbh/qoALKH3pl6t+fWLXnFQf9/eELpW 3CwFcOAAlDsNoI6UcxLikTOXupfNo6M2r8yCu99pGYNhSqZ4lRGRLaSDAem7ng0Kq8tAjcRpKXhl lvqYKUamFdiDyva9skbzLK+4/iAsU29iMo+8MkzTrbZo27FGF0ptOPPEpQGr9UgFABIv3nZqLhGw qlIUM0o+5d3y2q+dGuxwVV1ecMvb5de17lmnpcuLbjkIjE6zRSBaBO67IEZV1kgOXIh6o96plwGP 0nIQ5pELQ9uOuQcDgMd+T/4L1VVHGD9xQTA/lSus3fJADQOQn1wQ3odPq0xYCVNeBdM9OjlGoBcu EAkZ1I80USqRAeNq0gBVb2rqOLXdVwCixaQ3uy/hpEYADQpH0ZveZgu1GwfCm2BY8Y1O/eitKn/q N9EESVl3t+9KHtmU/sT1+WE4SNQ1N358Hg1T1McZ1QAVHiuowg0KqP2igiqK+LqRx6xw6Vh6ozMy q1OcJg633TqeC7qRBSKxhDpCAEJb+GmtDQqroCa1AFeNbsEytHZm3poj4gBjWe48nyXz5WgRHdJp uf1LN0NbkUs6LFCTfHSUd9rvnLcaAUDe0cX54uWTwAsvNI3e9BbKfKcMltoTBU3IfDUm/kTLar3x Sm5/GemTr+5/6P3RGb20gr2/NxpeDkHXf6C+wihiCEe35LJq6/RFF7+DjZOej8+SG0EqED1Hf6Dr sAf6UFr2Ve3XyWyOGeCwV+1mTtQqp+UcJmdrALvIVHrzjGZj3Wj1SNYq1xr4Iuq03jzDejATU6iR iIGhi12xPKCreaoqlwg6Lw5YU+uNqF6kvWRekA3O5M29chLwwIobgB1RNgeR4df2o3J1lnsDC3e/ SD8NCo9zqInkkkV/16/5OhkPJrN6Fc3cWJv/FvL+dMi+jmGDZ7PJAFgB6hUek7uB+mbTmq3kPV5V 2DXhqyHOjjU+/N/fvI0Ci+GWT54J1t+l72RYMI6+y0tUsTIdXPIUpELZDQoClRNOr523Z7WM2pUN CnzCE5ptkxlMonRQILbL+CKQ8JzVWvWzl6/grK03uFo+hkqvgkzGHubedtoADQo0AN+Uzmn/aqfN 13SCJ9EjKCiebLKV3EzekyvQqV482cLhTH29ldJ2yqiNrXEe7Uq13NaSNkPbe166KVSHGBVkB90V 53OJMxMjYRtzItba7QzXL8j6bfSuG2O4NIVjkI7jrEWSWKIoShRnM46NJium1Gxi401Vd1/XnWCj k9W134DiUWs2KjVZ+0DWfoNOQDsT9MOVV03R6pVqq3maMbR7JKtXqjsYy2hVy+1KGXQz1evHimj4 8nfNiJtnnXoFnwNRzSeyZnO6gMU7ApF7MwEWXEFr4LnKy2PV8lNZH7lteUMPt69MB6KDBjVdKYSo qKkxwylzOZYCZOVkN5qweg2GwpHEcD7+fTz5gAERxHii6E7O2HrBWbuuXm10P2jxuchCCct9WohP tqKcD5IIFuJJuaqsANYiVE9HllMMjYJvWdH5/L0OjzMcXwWjQnxvQOXYL2p8B2n4AAbXNfURnRHn ESopfIXHGl8xDR/AbIQPT3iG7mnY0I/lejYZT0CHJFfJFGyob7MlnDnhaQ0KPkzuju8M2Qwxj8ph xAequ3ksoV5aRfCpx0oUW4Ke9qSM9qjTMjsEvwOLDXdyueCAMHNLtCKfHd75E/MvkQHOiCf5Vdxn txF9J6QyFmifYxnC2rhQwRfts1qtqr9AvxHze5GeDDEa3Lj5t5K9gvwQ2ji+xwdOOUXNVmPPPH7k FFKuD1P42Cm0QmVTqXf8VsOxngJGLtOs+ODcSJpFRuhi60zjxh0XgQm9DYd3+z7Lu1ewY5ir4oPo KIqrR3ENCmf8Yrfaeq1p5Q7juMXpjgvH0WGgNY1m6AVfavkXAV7mY/y4A2k0YXuv/SLs5q1pNqHP TbFjUtJZAhSA1TkTn1+W5W0u0EkNCmQZHYDvc2FmyqdVIZ/Rt2SIhzmJ0ao9GZ+9QN1Nix0s5PMD bjTw8lD2WgDYzT7MV15u+XdLp2XLWJZRlH9izxvlCbetLtYJ+qRWbnWP6kdNhMn488ImWIo1oIuL cZ6iNoRrkqs3AC9es5ra7rHaWJ3IVnN6dtLB99EFz6RQrlRqZ51aVbfh3gFRC2flaheNCBnFJPbF C96Boc1TdUOBWFYjviiTQFSOAC9sHCcoAN4gjCo/cOTACReSZVWN9sC1zCIQ3ebq8oMIhqLdyQNL IuorbUNQh8b2jrUpj9n3RMxmhXzAZjrgXozD6icnIDZOQBtFu13Gu8A0Fj1d19oAKs3zRqdb7P53 rdXMeCLluNU8B94F0ciXn74jAun8dKeHdhGRyaJIe4hiD//Jb92eFnWdZN0lyMHLrYhxm1kmShF1 m6hmySWJ2U9q1YzvHVFr0Xpr1WDXaHeCe2gO2HN0juTOeBQhzmKsERGP7FXudNCW2GxkfK8Rv2L+ 1tSrqxDY7OIiSfc04CXab/laoXt0Uj72BgGs1mqQkZ/n9R6mtYLOu+Ko11/AeYL7VTwI+lU5+QWv kF91D/KnL/8744pJWbT/iIrCLoWQeQ8yBlT00EUxFRmTO5m6tGBQpHemoFEU7kA96QKNhBMFIF0o HtQVBt60gaITeDjUybzabTZ4u4B9I1VIAOOfNQOuZ9USEcBWE6P/Zw2qCIMNCrdWENdHoFKdy4OD 1+Maj6VIa1yy8Gd1Yj/7cD8ieKt0/USaVcYjK3QBrw0QIKWHx62zoiOELEFzVJa7ty6kgCIl4JUX e+1axTlIETCwk4alCCal4iOxI+BoC9wVnspvS4ADIEAgaKVOW2y0M77uwkXFR6rIIw6V7tulj/3S vCpEfnqCrPTYWj2kC5MgLld+wZ3XW4JOuWKB2ymlwdkQ1DlNrFsiDQr0SzUDOzbSHX8NCmSjrqJ5 kPfnAdVv9GqBTULtHhaxyXZmit1pgvPTKV70dmITgZGBO83uafUkxqNYsVovHzea7U694usHhLZ6 wrqp3SQWvDghlpWL0yvkiz1VWHAL+SxHhdlUEbM5dYm8jjrxKOByipHcVhesLoXkQNQlsq8usIVD aWcRDQqRbki+At5GqwtNs8VIKV3F+nQ6a74hrG8aqQ0Kw+34TwfOQibE10lApyfMhRoOOEnuIkgv 6rXL93c7m0UWonRdGk6FivhnRcO+L3ON3qU7FYyNfdJ8I+QNJ/UB5Gu2tQW/qEg6FO4AbXD0aNb0 DB96ubeMqfjeID5+F7gOW9C/U/Y+tOMUbda/m+FgMEpiXYyh3KCLFkJ3IeA5FoNWS6RPTT/3AC1N KoIYTCENClj2EgNfo0dQKJvjDQosKno2n3ddchEO6UzmoLARVEH1r1cjKN5oFINkvkAXLvRgAjqm 9MYNCuUt3dLc3gz1iWddl6QTFWJy8ZguydfQfl+8Y2TDoc7TSH84jw4eIuK9gQMEXtY1I0iYfSyr tWYiDkiWRqfKeasFJyPNQYC04vZMsTmC7G3aTTjmEMEQk4Pyzv1sdE4AY0EyaNFiLmRQGRLZ1C4I 74hzVK5o4he9SezTOemSz0nRMcnmi6r5yprmi1BbBNX3ZfX9db3fjzV+oGofrKl9wI07k9z5tQNo FAH2Pe5bJ8quh1fXe1OQTTvL8fCPJarn5FYbE24v68cv/UZ4qZBw26QpR6e+6+c7mURE+B9asrj3 ziyF8zNb8i2TNwMlSg+CuY5IUUf5uKR0BtJK5lbWkT486sVwYKwQRPE0BQU+tqXrUjtqiI3kze9d TC4OfZnhRZ5hedESW+LDZPY7hWZnF+vlmMciRIAEOyKRPMrHkaguWHg83ZSFNBHl0YGLZJUAx7qg Y3clMR6lEUNfGc/7s+EUxQAFJMlC3a1VBELcamwpBAIQa1zesPrzISh/qPcBhieGOnQjYrZevLtA plFLXa2PSKC+jT5OR3rqYTtxrLWNuyByjyPTaycGMU/+6MIETAGHtVE5IJfDy0mXiJExu8R3zlbJ b0kx+8nTrCT8lglC8j8YFHh8kZVZRCaUheWh0JBbW3FchcepyD7cGtl+MRXZ6FbIKM6KHmaOnrJu ORiB4hfZLBfkxK1xm2GnIP/wGcgNGVKQjzZF7pyfKpTvZcnv4VQ+zX8riPDkWDk6LnTLVVAX2+jQ eow3E/3LpxEguj9ACCmU+5f9CJRyPpdaS/jUV0N2zs/gVJrFvJXyLj2n0w/mtCQCgiAlsn4DmKkT 626pBJ+YF+jyEtvCNJ6yVlYG4N9SCT4J6inDQKlqb4uTUFLxEyj9S1XX3UCAoqzf3/JP9HF6F6Pk LsohuLQMKV7sgjr5ptyqmmnppSIT2sv4MqR1UdFaD5fCUdt0LTp0dcgiqZYoNuPY6yhhVTholIT/ Lz1T6lUsygIA --ELM922746727-14953-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 29 14:50:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id ED4DD1503D for ; Mon, 29 Mar 1999 14:50:40 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id PAA11137; Mon, 29 Mar 1999 15:50:16 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903292250.PAA11137@panzer.plutotech.com> Subject: Re: Problem with tekram and 3.1-RELEASE In-Reply-To: <199903292232.AAA15190@sister.ludd.luth.se> from Tomas Klockar at "Mar 30, 1999 0:32: 9 am" To: dateck@ludd.luth.se (Tomas Klockar) Date: Mon, 29 Mar 1999 15:50:16 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tomas Klockar wrote... > I tried to help a friend with a Tekram 390F SCSI card. > > I attached the source file which I got from Tekram > > this is what I did. > > cp PM300.GZ /usr/src > cd /usr/src > zcat PM300.GZ | patch -p0 > config TEKRAM > cd ../../compile/TEKRAM > make depend > make > > and this is what i got > > loading kernel > syscons.o: In function `scvidprobe': > syscons.o(.text+0x241): undefined reference to `vid_configure' > syscons.o(.text+0x25e): undefined reference to `vid_allocate' > syscons.o(.text+0x27b): undefined reference to `vid_get_adapter' > syscons.o: In function `sckbdprobe': [ ... ] > The source code from Tekram was supposed to be used with freebsd 3.0 not 3.1 > that I tried it with. > I would epreciate all help i can get. The driver will work with 3.1, other people have reported success with it. However, the console drivers changed somewhat between 3.0 and 3.1. You need to add a few more lines to your kernel config file before it'll compile. The easiest thing to do is to just use the GENERIC config file and add in the following line: controller amd0 Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 29 14:58:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BC8114C16 for ; Mon, 29 Mar 1999 14:58:12 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id PAA11175; Mon, 29 Mar 1999 15:57:44 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199903292257.PAA11175@panzer.plutotech.com> Subject: Re: CAM/SCSI command references? In-Reply-To: <19990328200517.EB895142@friley-185-205.res.iastate.edu> from Chris Csanady at "Mar 28, 1999 2: 5:17 pm" To: cc@137.org (Chris Csanady) Date: Mon, 29 Mar 1999 15:57:44 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris Csanady wrote... > I am looking for online SCSI command references and was wondering > if anyone had any pointers. Also I am interested in the various > vender specific commands relating to CDDA functions. I know very > little about the command formats and codes, so just about anything > will help. Matt has already pointed out the SCSI specs online. If you're looking for information on vendor-specific CDDA functions, the best thing to do is look in the source for tosha, cdd, cdda2wav, etc. > Also, what is the standard API that one should code new software > to in FreeBSD? I imagine cam(3) at the very least--what about > cam_cdbparse(3)? > > In the cam_cdbparse man page, it mentions that some of the commands > are meant to provide an easy migration path, although it does not > specify explicitly which ones. It points to cam_fill_csio() and > scsi_read_write() being desireable, although I have not found these > formally documented anywhere. I think you should probably stay away from the routines in cam_cdbparse(3). They are generally intended to help people migrate from the old libscsi interface. In fact, the man page was largely taken from the old scsi(3) man page. They won't be going away, as far as I can see, but the standard FreeBSD/CAM routines are generally easier to use. There isn't any documentation on the new routines yet. The best thing to do is figure out what SCSI command you're trying to send, and then see if there is a corresponding function declared in scsi_all.h, scsi_sa.h, cam_ccb.h, etc. If there isn't a function, like scsi_start_stop() or scsi_read_write(), you've got two choices: - Write your own CCB/CDB building function. I would advise this if you're going to send the same SCSI CDB more than once. - Use cam_fill_csio() to build the CCB. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 29 15: 4: 3 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33]) by hub.freebsd.org (Postfix) with ESMTP id 8C03B158C9 for ; Mon, 29 Mar 1999 15:03:28 -0800 (PST) (envelope-from dateck@ludd.luth.se) Received: from father.ludd.luth.se (dateck@father.ludd.luth.se [130.240.16.18]) by zed.ludd.luth.se (8.8.5/8.8.5) with ESMTP id BAA16032; Tue, 30 Mar 1999 01:03:08 +0200 From: Tomas Klockar Received: (dateck@localhost) by father.ludd.luth.se (8.6.11/8.6.11) id BAA18635; Tue, 30 Mar 1999 01:03:07 +0200 Message-Id: <199903292303.BAA18635@father.ludd.luth.se> Subject: Re: Problem with tekram and 3.1-RELEASE To: ken@plutotech.com (Kenneth D. Merry) Date: Tue, 30 Mar 1999 01:03:07 +0200 (MET DST) Cc: dateck@ludd.luth.se, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199903292250.PAA11137@panzer.plutotech.com> from "Kenneth D. Merry" at "Mar 29, 99 03:50:16 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Kenneth D. Merry: > Tomas Klockar wrote... > > I tried to help a friend with a Tekram 390F SCSI card. > > > > I attached the source file which I got from Tekram > > > > this is what I did. > > > > cp PM300.GZ /usr/src > > cd /usr/src > > zcat PM300.GZ | patch -p0 > > config TEKRAM > > cd ../../compile/TEKRAM > > make depend > > make > > > > and this is what i got > > > > loading kernel > > syscons.o: In function `scvidprobe': > > syscons.o(.text+0x241): undefined reference to `vid_configure' > > syscons.o(.text+0x25e): undefined reference to `vid_allocate' > > syscons.o(.text+0x27b): undefined reference to `vid_get_adapter' > > syscons.o: In function `sckbdprobe': > > [ ... ] > > > The source code from Tekram was supposed to be used with freebsd 3.0 not 3.1 > > that I tried it with. > > I would epreciate all help i can get. > > The driver will work with 3.1, other people have reported success with it. > However, the console drivers changed somewhat between 3.0 and 3.1. You > need to add a few more lines to your kernel config file before it'll > compile. > > The easiest thing to do is to just use the GENERIC config file and add in > the following line: > > controller amd0 > > Ken > -- > Kenneth Merry > ken@plutotech.com > Thank you, that worked /Tomas -- Tomas Klockar can be found at the following adresses: Kårhusvägen 4:23 | Furuvägen 102 | dateck@ludd.luth.se 977 54 Luleå | 871 52 Härnösand | dateck@solace.mh.se Tel: +46-920-231335 | Tel: +46-611-13393 | d94-tkl@sm.luth.se Mob: +46-70-664 33 26 | Mob: +46-70-374 0 347 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 29 15:57:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from loki.iss.net (loki.iss.net [208.21.0.3]) by hub.freebsd.org (Postfix) with ESMTP id 0A72A15971 for ; Mon, 29 Mar 1999 15:57:17 -0800 (PST) (envelope-from rmooney@iss.net) Received: from arden.iss.net (IDENT:rmooney@arden.iss.net [208.21.0.8]) by loki.iss.net (8.9.3/8.9.3) with SMTP id SAA01496 for ; Mon, 29 Mar 1999 18:55:25 -0500 Date: Mon, 29 Mar 1999 18:56:54 -0500 (EST) From: Robert Mooney To: freebsd-scsi@freebsd.org Subject: 3.1-STABLE + Amanda + HP T4000 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 realize this was a topic of discussion earlier this month -- unfortunately, I wasn't actually on the SCSI list, and the archives don't seem to point to any resolution of the issue. Here's a repost of the question I had sent to freebsd-questions: ---------- Forwarded message ---------- Date: Sun, 28 Mar 1999 23:09:53 -0500 (EST) From: Robert Mooney To: freebsd-questions@freebsd.org Subject: 3.1-STABLE + Amanda + HP T4000 The system is running 3.1-STABLE w/ Amanda 2.4.1p1. While attempting to write a label to a TR4 (travan 4gb native) tape, I received the following error: Mar 28 21:14:45 earthtone /kernel: (sa0:ahc0:0:1:0): SPACE. CDB: 11 1 ff ff ff 0 Mar 28 21:14:45 earthtone /kernel: (sa0:ahc0:0:1:0): ILLEGAL REQUEST asc:2c,0 Mar 28 21:14:45 earthtone /kernel: (sa0:ahc0:0:1:0): Command sequence error Mar 28 21:14:45 earthtone /kernel: (sa0:ahc0:0:1:0): unable to backspace over one of double filemarks at EOD- opting for safety Mar 28 21:14:59 earthtone /kernel: (sa0:ahc0:0:1:0): SPACE. CDB: 11 1 ff ff ff 0 Mar 28 21:14:59 earthtone /kernel: (sa0:ahc0:0:1:0): ILLEGAL REQUEST asc:2c,0 Mar 28 21:14:59 earthtone /kernel: (sa0:ahc0:0:1:0): Command sequence error Mar 28 21:14:59 earthtone /kernel: (sa0:ahc0:0:1:0): unable to backspace over one of double filemarks at EOD- opting for safety Unfortunately, after I rebooted once, further attempts to use amlabel resulted in the command hanging (ie, CTRL-C, CTRL-Z, and kill were of no use). The drive is detected as follows: Mar 28 21:57:15 earthtone /kernel: sa0 at ahc0 bus 0 target 1 lun 0 Mar 28 21:57:15 earthtone /kernel: sa0: Removable Sequential Access SCSI-2 device Mar 28 21:57:15 earthtone /kernel: sa0: 3.300MB/s transfers I've done backups using the QIC-3095 (2gb native) tapes under FreeBSD 2.2.7. Unfortunately, the use of a larger tape and newer OS seems to have gotten me in a bind. The machine is stable as of 03/28. If anyone has had success with the T4000 and TR4 tape, please let me know. Thanks in advance, - Rob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 29 17: 0:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id D70D91531D for ; Mon, 29 Mar 1999 17:00:49 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony [10.0.0.6]) by rover.village.org (8.9.3/8.6.6) with ESMTP id BAA06616 for ; Tue, 30 Mar 1999 01:00:30 GMT Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA05467 for ; Mon, 29 Mar 1999 18:00:30 -0700 (MST) Message-Id: <199903300100.SAA05467@harmony.village.org> To: scsi@freebsd.org Subject: UltraStor 14F Date: Mon, 29 Mar 1999 18:00:30 -0700 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It would appear that you can install and boot the UltraStor 14F as a IDE controller (with the wd driver). This is normally a scsi card, but that is cool that it works at least this much.... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 29 17: 4:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id DDF9815419 for ; Mon, 29 Mar 1999 17:04:27 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony [10.0.0.6]) by rover.village.org (8.9.3/8.6.6) with ESMTP id BAA06640 for ; Tue, 30 Mar 1999 01:04:07 GMT Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA05513 for ; Mon, 29 Mar 1999 18:04:08 -0700 (MST) Message-Id: <199903300104.SAA05513@harmony.village.org> To: freebsd-scsi@FreeBSD.ORG Subject: Re: Travan-20 tape streamer: unit not ready In-reply-to: Your message of "Fri, 26 Mar 1999 13:08:42 PST." <199903262108.NAA19393@mina.sr.hp.com> References: <199903262108.NAA19393@mina.sr.hp.com> Date: Mon, 29 Mar 1999 18:04:08 -0700 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199903262108.NAA19393@mina.sr.hp.com> Darryl Okahata writes: : Err, I've got some old public documents for some old HP DAT drives : (the 1533, at least), but that's about it. : : [ These documents cover hardware switch settings, as well as low-level : SCSI commands. ] That reminds me. I have paper copies of the Archive 150 manual, which covers these two things as well if anybody is interested. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Mar 29 17:32:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from quark.ChrisBowman.com (crbowman.erols.com [209.122.47.155]) by hub.freebsd.org (Postfix) with ESMTP id 3DD6114FE3 for ; Mon, 29 Mar 1999 17:32:23 -0800 (PST) (envelope-from crb@ChrisBowman.com) Received: from fermion (fermion.ChrisBowman.com [10.0.1.2]) by quark.ChrisBowman.com (8.9.2/8.8.8) with SMTP id UAA15851; Mon, 29 Mar 1999 20:43:37 -0500 (EST) (envelope-from crb@ChrisBowman.com) Message-Id: <199903300143.UAA15851@quark.ChrisBowman.com> X-Sender: crb@quark X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Mon, 29 Mar 1999 20:31:46 -0500 To: Tomas Klockar From: "Christopher R. Bowman" Subject: Re: Problem with tekram and 3.1-RELEASE Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <199903292232.AAA15190@sister.ludd.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:32 AM 3/30/99 +0200, Tomas Klockar wrote: >I tried to help a friend with a Tekram 390F SCSI card. > >I attached the source file which I got from Tekram > >this is what I did. > >cp PM300.GZ /usr/src >cd /usr/src >zcat PM300.GZ | patch -p0 >config TEKRAM >cd ../../compile/TEKRAM >make depend >make > >and this is what i got > >[stuff deleted] Um, I actually have a Tekram 390F in my server. It is a Symbios 53c875 based card, and as such works perfectly well under 3.1 with the ncr driver. There should be no need for a driver from Tekram. In fact mine is running the ncr driver under 3.1 now. -------- Christopher R. Bowman crb@ChrisBowman.com http://www.ChrisBowman.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 30 3:37: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.iol.ie (mail2.mail.iol.ie [194.125.2.193]) by hub.freebsd.org (Postfix) with ESMTP id 85B8214F54 for ; Tue, 30 Mar 1999 03:37:03 -0800 (PST) (envelope-from nick@iol.ie) Received: from beckett.earlsfort.iol.ie (beckett.earlsfort.iol.ie [194.125.21.2]) by mail.iol.ie Sendmail (v8.9.3) with ESMTP id MAA27485; Tue, 30 Mar 1999 12:36:39 +0100 (IST) Received: (from nick@localhost) by beckett.earlsfort.iol.ie Sendmail (v8.8.8) id MAA20308; Tue, 30 Mar 1999 12:36:37 +0100 From: Nick Hilliard Message-Id: <199903301136.MAA20308@beckett.earlsfort.iol.ie> Subject: Re: dpt raid-5 performance To: nick@iol.ie (Nick Hilliard) Date: Tue, 30 Mar 1999 12:36:37 +0100 (IST) Cc: grog@lemis.com, tom@sdf.com, nick@iol.ie, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199903211417.OAA28733@beckett.earlsfort.iol.ie> from "Nick Hilliard" at Mar 21, 99 02:17:13 pm X-NCC-RegID: ie.iol Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Does anyone know if a 2044W card creates exactly the same RAID structure on > a disk array as a 3334UW? I have both cards lying around the place at the > moment, and it would trivial to run benchmarks for both systems just by > replacing the card on the machine. I've included some results from Bonnie below. Just for reference, the system is a 200Mhz P5 with 128K RAM running 3.1-RELEASE with softupdates not enabled. The /W card is a DPT-2044W; the /U card is a 3334UW, and each card has 64M standard DRAM. The 3334UW was used to create the RAID-5 array in each instance and the slice size is given in each case. The random seeks column is done with 10 seekers rather than the standard 3. It looks like the 2044W is badly cpu-bound. I guess I won't be buying one of those again. The 3334UW has a 20Mhz 68020, not a 68040 as someone else said. It also looks like it's cpu-bound while doing raid writes. Tom wrote: > Small strip sizes are good for single-user situations (like running > Bonnie), because the IO load will be split over all drives. The results below show that this is not the case. Unfortunately, I didn't bother checking up the DPT performance counters for various reasons. Perhaps some day. > Large strip > sizes are good for multi-user situations, where the extra overhead of the > transactions becomes a problem. The system is actually going to be an FTP server which means lots of cached random reads with very few writes. It's not going to be a hugely busy ftp server -- the ftp daemon limit is probably going to be set at 150 or 200 processes. Nick Hilliard Ireland On-Line System Operations -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 8k/W 256 520 7.1 507 1.6 376 2.2 1273 18.1 1271 4.6 156.2 6.5 16k/W 256 541 7.3 525 1.6 421 2.5 2634 37.8 2695 9.7 180.0 7.5 32k/W 256 560 7.6 533 1.7 450 2.6 3536 50.4 3560 12.9 196.1 7.6 64k/W 256 571 7.8 540 1.7 474 2.8 3740 53.4 3779 13.4 204.3 8.1 128k/W 256 553 7.6 539 1.5 462 2.3 4101 58.6 4119 15.1 206.4 8.3 256k/W 256 558 7.6 534 1.7 464 2.7 4284 61.3 4282 15.8 206.4 8.1 512k/W 256 541 7.5 491 1.7 458 2.3 4293 59.1 4335 16.2 193.6 6.8 1M/W 256 526 7.2 408 1.3 442 2.6 4414 63.3 4450 16.7 210.5 8.1 8k/U 256 2177 29.7 2078 6.4 1533 9.1 6593 94.9 8377 30.6 262.1 10.7 16k/U 256 2122 29.7 2089 6.7 1585 9.7 6707 96.8 8596 32.7 289.2 12.1 32k/U 256 2162 30.1 2122 6.8 1652 10.2 6726 97.3 8521 31.7 307.2 12.5 64k/U 256 2176 30.3 2137 6.8 1674 10.1 6740 97.6 8788 32.0 310.4 12.9 128k/U 256 2156 29.1 2129 6.8 1675 10.5 6968 96.9 9158 34.2 316.1 13.4 256k/U 256 2149 29.9 2103 6.9 1693 10.8 6664 96.8 8832 33.8 326.8 13.9 512k/U 256 2104 29.0 2039 6.6 1670 10.3 6701 97.2 9468 36.5 322.4 13.5 1M/U 256 1827 25.4 1544 5.0 1442 9.2 6658 96.5 10009 38.7 318.6 13.6 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 30 15:14:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from nebraska.utcorp.com (nebraska.utcorp.com [146.145.135.14]) by hub.freebsd.org (Postfix) with ESMTP id 3BFE614C2D for ; Tue, 30 Mar 1999 15:14:23 -0800 (PST) (envelope-from kseel@utcorp.com) Received: from utcorp.com (x-kspc.utcorp.com [146.145.135.17]) by nebraska.utcorp.com (8.8.5/8.8.5) with ESMTP id WAA17032 for ; Tue, 30 Mar 1999 22:52:50 -0500 (EST) Message-ID: <37015B8B.6DDC0429@utcorp.com> Date: Tue, 30 Mar 1999 18:17:31 -0500 From: Kurt Seel X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.8-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: sd device numbering Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there some config file magic to lock an sd dev to a scsi id? i.e. scsi 0 -> sd0 scsi1 -> sd1 scsi2 -> sd2 So that if I pull scsi 1 out, it looks like this : scsi 0 -> sd0 scsi 2 -> sd2 sd1 'disappears' and my fstab remains valid for all the other drives. -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Mar 30 22: 4: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [207.153.65.3]) by hub.freebsd.org (Postfix) with ESMTP id 07AC514E88 for ; Tue, 30 Mar 1999 22:04:01 -0800 (PST) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with SMTP id BAA24884; Wed, 31 Mar 1999 01:03:20 -0500 (EST) Date: Wed, 31 Mar 1999 01:03:20 -0500 (EST) From: "Matthew N. Dodd" To: Kurt Seel Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: sd device numbering In-Reply-To: <37015B8B.6DDC0429@utcorp.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, 30 Mar 1999, Kurt Seel wrote: > Is there some config file magic to lock an sd dev to a scsi id? i.e. > scsi 0 -> sd0 > scsi1 -> sd1 > scsi2 -> sd2 > So that if I pull scsi 1 out, it looks like this : > scsi 0 -> sd0 > scsi 2 -> sd2 > sd1 'disappears' and my fstab remains valid for all the other drives. You can wire your SCSI devices down. Check LINT for details. I'd really love to see something like Solaris has hung off of DEVFS that would automagically present devices in the form of /dev/dsk/busX/targY/lunZ/... But that ends up being too long which leads me to think that assign a 'name' to the device and presenting it under /dev/dsk/{name} would be the way to go. But that would imply both DEVFS and SLICE which doesn't seem all that likely at this point. -- | Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprite/VMS | | winter@jurai.net | This Space For Rent | ix86,sparc,m68k,pmax,vax | | http://www.jurai.net/~winter | Are you k-rad elite enough for my webpage? | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 0: 0:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from surf.iae.nl (surf.IAE.nl [194.151.66.2]) by hub.freebsd.org (Postfix) with ESMTP id 31488150E0 for ; Wed, 31 Mar 1999 00:00:14 -0800 (PST) (envelope-from graaf@iae.nl) Received: from iae.nl (joy.iae.nl [194.151.66.136]) by surf.iae.nl (Postfix) with ESMTP id 7691794F1; Wed, 31 Mar 1999 09:59:47 +0200 (MET DST) Date: Wed, 31 Mar 1999 10:00:44 +0200 (CEST) From: Edwin de Graaf Subject: CAM timeout in dataout phase (3.1-STABLE) To: freebsd-scsi@freebsd.org Cc: admin@iae.nl MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Message-Id: <19990331075950.7691794F1@surf.iae.nl> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On a 3.1-STABLE server with an onboard Adaptec controller we are getting these messages: Adaptec boot: ------------- ahc0: rev 0x00 int a irq 12 on pci0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs DTC RAID controller boot: ------------------------- da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 25500MB (52224000 512 byte sectors: 255H 63S/T 3250C) Timeout error messages: ----------------------- Mar 30 10:24:30 iaehv /kernel: (da1:ahc0:0:1:0): SCB 0x2a - timed out in dataoutphase, SEQADDR == 0x5d Mar 30 10:24:30 iaehv /kernel: (da1:ahc0:0:1:0): BDR message in message buffer Mar 30 10:24:31 iaehv /kernel: (da1:ahc0:0:1:0): SCB 0x2a - timed out in dataoutphase, SEQADDR == 0x5d Mar 30 10:24:31 iaehv /kernel: (da1:ahc0:0:1:0): no longer in timeout, status =34b Mar 30 10:24:31 iaehv /kernel: ahc0: Issued Channel A Bus Reset. 255 SCBs aborted Could anyone suggest a solution, or a way to find out what is going on here? The sources for 3.1-STABLE were compiled about two weeks ago, should we resup? Thanks a lot for your help. Best regards, Edwin de Graaf -- "O Oysters, come and walk with us!" The Walrus did beseech. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 3: 8:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id 7BE11150E4 for ; Wed, 31 Mar 1999 03:08:40 -0800 (PST) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id MAA31061 for ; Wed, 31 Mar 1999 12:08:21 +0100 (BST) Message-ID: <37020224.3FB82DC0@tdx.co.uk> Date: Wed, 31 Mar 1999 12:08:20 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: SYNCHRONIZE CACHE - Illegal Request? OK? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, My recent -current box keeps spitting these out, usually before immanent death / panic's (I think it's been doing this since it was installed)... " syncing disks... 18 16 5 done (da0:ahc0:0:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da0:ahc0:0:0:0): ILLEGAL REQUEST asc:20,0 (da0:ahc0:0:0:0): Invalid command operation code (da1:ahc0:0:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da1:ahc0:0:1:0): ILLEGAL REQUEST asc:20,0 (da1:ahc0:0:1:0): Invalid command operation code " I presume what it's trying to tell me is that the two drives in question (both ageing Quantum's) don't support the SCSI 'sync. cache' command? - And I guess this is 'mostly harmless'? Apart from the obvious 'you just probably lost any pending data in the cache'? The drives in question both ID as: da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 8) da0: 1042MB (2134305 512 byte sectors: 64H 32S/T 1042C) da1: Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 8) da1: 1042MB (2134305 512 byte sectors: 64H 32S/T 1042C) A friend thought these might have been suppressed in recent -current's etc.? - but even my 'really recent' -current system seems to display them... Regards, Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 8:15:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 2B34314BE3 for ; Wed, 31 Mar 1999 08:15:33 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id JAA11461; Wed, 31 Mar 1999 09:05:51 -0700 (MST) Date: Wed, 31 Mar 1999 09:05:51 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903311605.JAA11461@narnia.plutotech.com> To: Edwin de Graaf Cc: scsi@FreeBSD.org Subject: Re: CAM timeout in dataout phase (3.1-STABLE) X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <19990331075950.7691794F1@surf.iae.nl> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <19990331075950.7691794F1@surf.iae.nl> you wrote: > DTC RAID controller boot: > ------------------------- > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled > da1: 25500MB (52224000 512 byte sectors: 255H 63S/T 3250C) Were the number of tags ever reduced? You'll probably have to boot with '-v' to know for sure as Jordan moved the message that indicates when this occurs behind "if (bootverbose)". > Timeout error messages: > ----------------------- > Mar 30 10:24:30 iaehv /kernel: (da1:ahc0:0:1:0): SCB 0x2a - timed out > in dataoutphase, SEQADDR == 0x5d Mar 30 10:24:30 iaehv /kernel: > (da1:ahc0:0:1:0): BDR message in message buffer Mar 30 10:24:31 iaehv > /kernel: (da1:ahc0:0:1:0): SCB 0x2a - timed out in dataoutphase, SEQADDR > == 0x5d Mar 30 10:24:31 iaehv /kernel: (da1:ahc0:0:1:0): no longer in > timeout, status =34b Mar 30 10:24:31 iaehv /kernel: ahc0: Issued Channel > A Bus Reset. 255 SCBs aborted Perhaps the controller is getting overloaded by too many overlapped commands. It could also be that your cabling or termination is inadequate causing a REQ or ACK to be lost during some data transfers. Are you using 'Forced Perfect' terminators? Is your cable < 1.5m in length? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 8:18:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id B142A15C86 for ; Wed, 31 Mar 1999 08:18:24 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id JAA11473; Wed, 31 Mar 1999 09:08:45 -0700 (MST) Date: Wed, 31 Mar 1999 09:08:45 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903311608.JAA11473@narnia.plutotech.com> To: Karl Pielorz Cc: scsi@FreeBSD.org Subject: Re: SYNCHRONIZE CACHE - Illegal Request? OK? X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <37020224.3FB82DC0@tdx.co.uk> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <37020224.3FB82DC0@tdx.co.uk> you wrote: > I presume what it's trying to tell me is that the two drives in question (both > ageing Quantum's) don't support the SCSI 'sync. cache' command? - And I guess > this is 'mostly harmless'? Apart from the obvious 'you just probably lost any > pending data in the cache'? The messages are harmless. If the doesn't support the synchronize cache command, it must not performed defferred writes. > A friend thought these might have been suppressed in recent -current's etc.? - > but even my 'really recent' -current system seems to display them... We tried, but it doesn't seem to work. Perhaps you can instrument the code in sys/cam/scsi/scsi_da.c:dashutdown() to see why our tests do not do the trick. I don't have a device that fails on this command, so I can't test this here. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 10:51:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from server.cirdan.iae.nl (server.cirdan.iae.nl [212.61.28.34]) by hub.freebsd.org (Postfix) with ESMTP id 7D15B14E4B for ; Wed, 31 Mar 1999 10:50:54 -0800 (PST) (envelope-from graaf@cirdan.iae.nl) Received: from cirdan.iae.nl (cirdan.iae.nl [212.61.28.35]) by server.cirdan.iae.nl (Postfix) with ESMTP id 8DEBCD98A; Wed, 31 Mar 1999 21:38:04 +0200 (CEST) Date: Wed, 31 Mar 1999 20:54:53 +0200 (CEST) From: Edwin de Graaf Reply-To: graaf@iae.nl Subject: Re: CAM timeout in dataout phase (3.1-STABLE) To: gibbs@narnia.plutotech.com Cc: admin@iae.nl, scsi@FreeBSD.org In-Reply-To: <199903311605.JAA11461@narnia.plutotech.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Message-Id: <19990331193807.8DEBCD98A@server.cirdan.iae.nl> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Justin, Thanks for your quick response! On 31 Mar, Justin T. Gibbs wrote: > In article <19990331075950.7691794F1@surf.iae.nl> you wrote: >> DTC RAID controller boot: >> ------------------------- >> da1 at ahc0 bus 0 target 1 lun 0 >> da1: Fixed Direct Access SCSI-2 device >> da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled >> da1: 25500MB (52224000 512 byte sectors: 255H 63S/T 3250C) > > Were the number of tags ever reduced? You'll probably have to boot > with '-v' to know for sure as Jordan moved the message that indicates > when this occurs behind "if (bootverbose)". We will run with -v the next time we reboot the system to check this. >> Timeout error messages: >> ----------------------- >> Mar 30 10:24:30 iaehv /kernel: (da1:ahc0:0:1:0): SCB 0x2a - timed out >> in dataoutphase, SEQADDR == 0x5d Mar 30 10:24:30 iaehv /kernel: >> (da1:ahc0:0:1:0): BDR message in message buffer Mar 30 10:24:31 iaehv >> /kernel: (da1:ahc0:0:1:0): SCB 0x2a - timed out in dataoutphase, SEQADDR >> == 0x5d Mar 30 10:24:31 iaehv /kernel: (da1:ahc0:0:1:0): no longer in >> timeout, status =34b Mar 30 10:24:31 iaehv /kernel: ahc0: Issued Channel >> A Bus Reset. 255 SCBs aborted > > Perhaps the controller is getting overloaded by too many overlapped > commands. It could also be that your cabling or termination is > inadequate causing a REQ or ACK to be lost during some data transfers. > Are you using 'Forced Perfect' terminators? Is your cable < 1.5m in > length? There are two SCSI connectors on the motherboard, one wide SCSI and one narrow connector. We have the boot disk on the narrow connector with an active terminator on the cable. The DTC RAID controller is connected to the wide connector; there is also an active terminator on the SCSI cable with the RAID disks. I am not entirely clear if these are two separate SCSI busses, or it it is one bus with wide and narrow devices. I think it is one SCSI bus, and we have disabled termination on the Adaptec controller. The cable length of the two cables combined might be a little over 1.5m Again thanks for your help. Best regards, Edwin de Graaf -- "O Oysters, come and walk with us!" The Walrus did beseech. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 12:18:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id D349A15C77 for ; Wed, 31 Mar 1999 12:18:06 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id NAA17189; Wed, 31 Mar 1999 13:17:22 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903312017.NAA17189@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: graaf@iae.nl Cc: gibbs@plutotech.com, admin@iae.nl, scsi@FreeBSD.org Subject: Re: CAM timeout in dataout phase (3.1-STABLE) In-reply-to: Your message of "Wed, 31 Mar 1999 20:54:53 +0200." <19990331193807.8DEBCD98A@server.cirdan.iae.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Mar 1999 13:08:07 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I am not entirely clear if these are two separate SCSI busses, or it it >is one bus with wide and narrow devices. I think it is one SCSI bus, and >we have disabled termination on the Adaptec controller. The cable length >of the two cables combined might be a little over 1.5m The motherboard has only one bus on it. The termination settings for the controller should be "High Byte Termination Enabled", and "Low Byte Termination Disabled". It may be that your motherboard always terminates the high byte, but perhaps not. Active terminators may not be sufficient for the load you are putting on this system. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 12:32:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from server.cirdan.iae.nl (server.cirdan.iae.nl [212.61.28.34]) by hub.freebsd.org (Postfix) with ESMTP id 4E8FF15CCF for ; Wed, 31 Mar 1999 12:32:06 -0800 (PST) (envelope-from graaf@cirdan.iae.nl) Received: from cirdan.iae.nl (cirdan.iae.nl [212.61.28.35]) by server.cirdan.iae.nl (Postfix) with ESMTP id 179CFD98A; Wed, 31 Mar 1999 23:19:11 +0200 (CEST) Date: Wed, 31 Mar 1999 22:35:57 +0200 (CEST) From: Edwin de Graaf Reply-To: graaf@iae.nl Subject: Re: CAM timeout in dataout phase (3.1-STABLE) To: gibbs@plutotech.com Cc: admin@iae.nl, scsi@FreeBSD.org In-Reply-To: <199903312017.NAA17189@pluto.plutotech.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Message-Id: <19990331211914.179CFD98A@server.cirdan.iae.nl> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Justin, On 31 Mar, Justin T. Gibbs wrote: > The motherboard has only one bus on it. The termination settings for > the controller should be "High Byte Termination Enabled", and "Low > Byte Termination Disabled". It may be that your motherboard always > terminates the high byte, but perhaps not. Active terminators may not > be sufficient for the load you are putting on this system. If active terminators are not sufficient, what would solve the problem? Would it help if we put the boot disk on a separate SCSI controller, thus shortening the total length of the SCSI bus? Or is a different kind of terminator better in this case? Your answers are much appreciated. best regards, Edwin de Graaf -- "O Oysters, come and walk with us!" The Walrus did beseech. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 12:45:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 57ECB14BF9 for ; Wed, 31 Mar 1999 12:45:16 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id NAA18087; Wed, 31 Mar 1999 13:44:53 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903312044.NAA18087@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: graaf@iae.nl Cc: gibbs@plutotech.com, admin@iae.nl, scsi@FreeBSD.org Subject: Re: CAM timeout in dataout phase (3.1-STABLE) In-reply-to: Your message of "Wed, 31 Mar 1999 22:35:57 +0200." <19990331211914.179CFD98A@server.cirdan.iae.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Mar 1999 13:35:38 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Hi Justin, > >On 31 Mar, Justin T. Gibbs wrote: >> The motherboard has only one bus on it. The termination settings for >> the controller should be "High Byte Termination Enabled", and "Low >> Byte Termination Disabled". It may be that your motherboard always >> terminates the high byte, but perhaps not. Active terminators may not >> be sufficient for the load you are putting on this system. > >If active terminators are not sufficient, what would solve the problem? Forced Perfect Terminators. See www.scsi-cables.com for details. >Would it help if we put the boot disk on a separate SCSI controller, >thus shortening the total length of the SCSI bus? Or is a different >kind of terminator better in this case? Your bus length may be too long even if you upgrade your terminators. Moving the boot disk may help things. You could also try reducing the negotiated transfer speed to verify that cabling is your problem. Your configuration will likely work at 16 or 13MHz. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 16:19:53 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from nomis.simon-shapiro.org (nomis.simon-shapiro.org [209.86.126.163]) by hub.freebsd.org (Postfix) with SMTP id C37F814D19 for ; Wed, 31 Mar 1999 16:19:13 -0800 (PST) (envelope-from shimon@simon-shapiro.org) Received: (qmail 47670 invoked by uid 1000); 1 Apr 1999 00:21:58 -0000 From: Simon Shapiro Reply-To: shimon@Simon-Shapiro.ORG Organization: The Simon Shapiro Foundation To: freebsd-scsi@freebsd.org Subject: DPT SmartCache V Status Date: Wed, 31 Mar 1999 19:12:38 -0500 X-Mailer: KMail [version 1.0.17] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <9903311921580C.46299@nomis.simon-shapiro.org> Content-Transfer-Encoding: 8bit X-KMail-Mark: Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am getting about 5 messages a day on this. No kidding! While I thoroughly enjoy reading each and every one of them, here is a summary for all those who want to know. * I had surgery on both my feet, which put me on my kister for few weeks. * Prior to that my wife had a horribly difficult pregnancy. * My 8th child Kaily Alianna shapiro was born healthy and my wife is recovering from most of the damage. * DPT is very eager to have me complete the work. I will get all the support I need from them.BOOTDEV * I am eager to complete these drivers. * I am tentatively scheduled to be in Florida next week to work on these drivers. An Alpha version will be available by EOM April. * DPTMGR (RAID Utilities for DPT controllers) will follow shortly after. * We are not sure yet what is the exact form this code will take. Some complications may force binary-only on certain pieces. At least for a while. * I will continue to support these products and promise to do a better job at respongding and solving problems. * My employer is not involved in any way shape or form in any of this, except for some mildly amused interest and tolerance of my behavior. So, please do NOT call MindSpring for DPT questions, only to sign up, etc. * When something is publishable, it will be posted in http:/simon-shapiro.org, and or at my FTP server at the same place. Hope this helps y'll... -- Sincerely, Simon Shapiro Research Fellow ShapiroS@MindSpring.com MindSpring Enterprises, Inc. 404.815.0770 ext. 2057 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 18:47:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id A6249151A3 for ; Wed, 31 Mar 1999 18:47:20 -0800 (PST) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt8-216-180-15-157.dialup.HiWAAY.net [216.180.15.157]) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id UAA30172 for ; Wed, 31 Mar 1999 20:46:55 -0600 (CST) Received: from nospam.hiwaay.net (nospam.hiwaay.net [127.0.0.1]) by nospam.hiwaay.net (8.9.2/8.9.2) with ESMTP id UAA46365 for ; Wed, 31 Mar 1999 20:46:45 -0600 (CST) (envelope-from dkelly@nospam.hiwaay.net) Message-Id: <199904010246.UAA46365@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: scsi@FreeBSD.ORG Subject: cache and tape drives From: David Kelly Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Mar 1999 20:46:45 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've launched into a study of CAM and the sa driver attempting to learn where the kernel blocks on a write. Studies with kdump indicate it blocks on every write to tape. When attempting to write to 4 tape drives at once, performance suffers. And today the boss said, "We'd like to write 8 tapes at once, how many machines do we need?" Have to admit CAM is over my head as I haven't found my answer. Haven't been sniffing around with a kernel debugger either. Suspect the ccb LINK and FLAG bits control the process blocking. At the moment I no longer have access to the 4-tape machine. The last time I used it (running the Feb 8 3.0-SNAP) a tcopy between identical DDS-3 drives clocked in at a pathetic 300k/sec, previously a dd of the tape to file ran just over 1000k/sec. I learned it was faster to copy to HD, then back to tape, as writing DDS-3 tapes ran at 550k to 700k/sec. Strangely writting DDS-1 tapes always yeilded a consistant 700k/sec, and that's when I was writing 4-up. Don't remember ever writing only one DDS-1 tape at a time. In /usr/include/sys/mtio.h: #define MTCACHE 8 /* enable controller cache */ #define MTNOCACHE 9 /* disable controller cache */ but have found this ioctl's are no-ops. Know everybody has more on their plate than they can handle, that's why I've tried to find a solution myself. Have reached the limits of my abilities so its time to ask for help. "Is CAM generic enough to handle buffered writes?" Considering the example of tagged queuing on HD's its my guess that it is. "Is there a quick way to write to the tape drive until its buffer is full before blocking?" I hope so. Cdrecord apparently goes to great lengths to do this internally for CD-R's. Reproducing such an effort as cdrecord but for tapes, is beyond my motivation. Unless there are mini-errors that I never see, in my application any error reading or writing the tape drive should be considered fatal. Wondered if I could use /dev/pass1 for writing: nospam: [1006] mt -t /dev/pass1 stat mt: /dev/pass1: Operation not permitted nospam: [1007] dd if=/dev/zero bs=10k of=/dev/pass1 count=1000 dd: /dev/pass1: Invalid argument 1+0 records in 0+0 records out 0 bytes transferred in 0.000830 secs (0 bytes/sec) nospam: [1008] Apparently not. Then worried myself wondering how pass devices were mapped to other SCSI devices and didn't pursue the above any further. Pass isn't listed in dmesg, altho "device pass0" is in my kernel config. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 18:59:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 3838114D25; Wed, 31 Mar 1999 18:59:44 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA10046; Thu, 1 Apr 1999 12:29:24 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA90659; Thu, 1 Apr 1999 12:29:23 +0930 (CST) Message-ID: <19990401122922.Q413@lemis.com> Date: Thu, 1 Apr 1999 12:29:22 +0930 From: Greg Lehey To: FreeBSD Hackers , FreeBSD SCSI Mailing List Subject: CCD and Vinum compared with new performance measuring tool Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In the past few weeks, I've been bitching about the fact that bonnie doesn't do what I want in measuring storage device performance. I've now solved the problem: I've written another program. You can pick it up at ftp://ftp.lemis.com/pub/rawio.tar.gz. From the man page: DESCRIPTION rawio tests the speed of the low-level character I/O device special in a concurrent environment. It is intended for comparisons of storage de- vices on a single system, and is not suited for cross-platform perfor- mance testing. By default, rawio spawns eight processes, each of which performs the same test. Four tests are available: Random Read The random read test reads varying length records from the speci- fied device special, starting at random positions within the file. Sequential Read The sequential read test reads constant length records from the specified device special, starting at the beginning of the file. Random Write The random read test writes varying length records to the speci- fied device special, starting at random positions within the file. Sequential Write The sequential read test writes constant length records to the specified device special, starting at the beginning of the file. Here is some sample output measuring vinum volumes and straight disks (remember, these are ancient hand-me-down pre-SCSI-1 CDC drives; only the comparison counts). da2 is the raw disk, ccd0 is a striped ccd, and s128k is a striped vinum volume with the same geometry (128 kB stripes): Test ID K/sec %User %Sys %Total I/Os RR da2 576759 0.0 0.7 0.7 800 RR ccd0 1224133 0.1 2.0 2.1 800 RR s128k 1220979 0.4 2.2 2.6 800 Test ID K/sec %User %Sys %Total I/Os SR da2 899264 0.0 0.4 0.4 800 SR ccd0 1903052 0.0 1.5 1.5 800 SR s128k 1925672 0.1 1.8 1.9 800 Test ID K/sec %User %Sys %Total I/Os RW da2 589874 0.0 0.8 0.8 800 RW ccd0 1380529 0.1 2.2 2.3 800 RW s128k 1370186 0.3 2.6 2.9 800 Test ID K/sec %User %Sys %Total I/Os SW da2 901745 0.0 0.5 0.5 800 SW ccd0 2114599 0.1 1.6 1.7 800 SW s128k 2116235 0.0 2.1 2.1 800 Not surprisingly, the performance figures for vinum are pretty much the same as for ccd; the somewhat higher CPU time is probably due to the debug aids I still have in vinum. Compared to bonnie, the results are pretty reproducible. Comments welcome Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 20:36:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id EAC7D14D2A for ; Wed, 31 Mar 1999 20:36:09 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id VAA43947; Wed, 31 Mar 1999 21:26:33 -0700 (MST) Date: Wed, 31 Mar 1999 21:26:33 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199904010426.VAA43947@narnia.plutotech.com> To: David Kelly Cc: scsi@FreeBSD.org Subject: Re: cache and tape drives X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199904010246.UAA46365@nospam.hiwaay.net> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Have to admit CAM is over my head as I haven't found my answer. Haven't > been sniffing around with a kernel debugger either. Suspect the ccb > LINK and FLAG bits control the process blocking. Not at all. Processes block on writes to all 'raw' devices. The reason for this is simple. To avoid a copy of your data, the kernel blocks your process, wires the data buffer in your process into memory so it cannot be swapped out, and performs the I/O to the device. Only once the I/O has completed can the call to write(2) complete to ensure the proper semantics of the system call (e.g. you can reuse your buffer as soon as write returns). What you are seeing in your application is a classic latency problem. You are transfering data between two high latency devices, so your total throughput will suffer if you are only using a single process: while (more_data) { read from tape [block for a long while...] write to tape [block for a long while...] } The write side likely has much less latency than the read side at least until the write buffer in the device is filled. DDS-3 drives do have a write buffer and the sa driver will make use of it. On the read side, the tape driver must block until the data is available. If the latency of transfering the read data into the write buffer of the target tape device is large enough, you won't be able to stream your reads, and performance will suffer. So how do you solve the problem? For FreeBSD, you'll need to use multiple processes to perform the reads and writes with some kind of fast buffer in the middle. If a doesn't buffer enough data for you, you can always allocate a piece of shared memory between the two processes and make that as large as you like. With this kind of strategy, you should be able to tune the appliation to the point where your streaming read and write speeds are bounded by the speed of the tape drives. In an ideal world, you could use async I/O within a single application, but I haven't experimented enough with AIO under FreeBSD to know if it is robust enough yet for this task. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 21:12:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 3110615277 for ; Wed, 31 Mar 1999 21:12:41 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id WAA44021; Wed, 31 Mar 1999 22:03:06 -0700 (MST) Date: Wed, 31 Mar 1999 22:03:06 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199904010503.WAA44021@narnia.plutotech.com> To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: cache and tape drives X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199904010426.VAA43947@narnia.plutotech.com> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ... > So how do you solve the problem? For FreeBSD, you'll need to use > multiple processes to perform the reads and writes with some kind > of fast buffer in the middle. If a doesn't buffer enough data for ^<== pipe > you, you can always allocate a piece of shared memory between the > two processes and make that as large as you like. With this kind > of strategy, you should be able to tune the appliation to the point > where your streaming read and write speeds are bounded by the speed > of the tape drives. ... -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 21:28:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id EEAF914FBA for ; Wed, 31 Mar 1999 21:28:31 -0800 (PST) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt8-216-180-15-157.dialup.HiWAAY.net [216.180.15.157]) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id XAA28856; Wed, 31 Mar 1999 23:28:09 -0600 (CST) Received: from nospam.hiwaay.net (nospam.hiwaay.net [127.0.0.1]) by nospam.hiwaay.net (8.9.2/8.9.2) with ESMTP id XAA47587; Wed, 31 Mar 1999 23:28:05 -0600 (CST) (envelope-from dkelly@nospam.hiwaay.net) Message-Id: <199904010528.XAA47587@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org From: David Kelly Subject: Re: cache and tape drives In-reply-to: Message from "Justin T. Gibbs" of "Wed, 31 Mar 1999 21:26:33 MST." <199904010426.VAA43947@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Mar 1999 23:28:04 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Justin T. Gibbs" writes: > > Have to admit CAM is over my head as I haven't found my answer. Haven't > > been sniffing around with a kernel debugger either. Suspect the ccb > > LINK and FLAG bits control the process blocking. > > Not at all. Processes block on writes to all 'raw' devices. The That explains something. Scanning my mail archives says Bruce Evans told me that on 3/10. Am suffering from overload of data. > reason for this is simple. To avoid a copy of your data, the kernel > blocks your process, wires the data buffer in your process into memory > so it cannot be swapped out, and performs the I/O to the device. Only > once the I/O has completed can the call to write(2) complete to ensure > the proper semantics of the system call (e.g. you can reuse your buffer > as soon as write returns). > > What you are seeing in your application is a classic latency problem. > You are transfering data between two high latency devices, so your > total throughput will suffer if you are only using a single process: > > while (more_data) { > read from tape [block for a long while...] > write to tape [block for a long while...] > } > > The write side likely has much less latency than the read side at > least until the write buffer in the device is filled. DDS-3 drives > do have a write buffer and the sa driver will make use of it. On > the read side, the tape driver must block until the data is available. > If the latency of transfering the read data into the write buffer > of the target tape device is large enough, you won't be able to > stream your reads, and performance will suffer. Last month when I knocked off 180 tapes in roughly lots of 10 of the same tape my procedure was to create a single file image of the tape on HD, a tar image, then to use "tcopy -s 10240 file.tar /dev/rsa0", but in a shell script where I kicked off one tcopy per tape drive, all tcopys reading the same file. Writing to DDS-1 tapes I saw 700k/sec and steady but for some reason when writing to DDS-3 tapes (same drives) it was only 550k/sec and widely varying. It could have been the tapes as some wrote and verified OK but the drive LED was flashing, complaining about error rates. > So how do you solve the problem? For FreeBSD, you'll need to use > multiple processes to perform the reads and writes with some kind > of fast buffer in the middle. I tried team and dd and didn't see a thing change. Have brought up this subject before when I believed I was simulating my 4 tape drive thruput problems when rc5des was running on my home machine. With rc5des running at its default nice (20), using dd to write 10k blocks from /dev/zero to /dev/rsa0 varies between 150k and 200k/sec on this machine. Without rc5des (but X running) its 360k to 380k. Bruce Evans provided a patch to kern_synch.c. Couldn't tell any change in thruput but there was some change to the "feel" of the system at the keyboard. Was not able to try that patch on the 4 tape machine. Others have suggested bumping the kernel HZ up from 100 to maybe 1000. But from my understanding of things that would simply be a bandaid and no more as a blocked process is supposed to be able to push a running process aside when it becomes unblocked. Or something like that. Shortly I should be getting another system to play with. Again. One with 4 or 8 tape drives. And not have to inaccurately simulate the problem with rc5des. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 23:17:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E34E41516C; Wed, 31 Mar 1999 23:17:38 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA53772; Wed, 31 Mar 1999 23:17:02 -0800 (PST) (envelope-from dillon) Date: Wed, 31 Mar 1999 23:17:02 -0800 (PST) From: Matthew Dillon Message-Id: <199904010717.XAA53772@apollo.backplane.com> To: Greg Lehey Cc: FreeBSD Hackers , FreeBSD SCSI Mailing List Subject: Re: CCD and Vinum compared with new performance measuring tool References: <19990401122922.Q413@lemis.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :In the past few weeks, I've been bitching about the fact that bonnie :doesn't do what I want in measuring storage device performance. I've :now solved the problem: I've written another program. You can pick it :up at ftp://ftp.lemis.com/pub/rawio.tar.gz. From the man page: : :DESCRIPTION : rawio tests the speed of the low-level character I/O device special in a : concurrent environment. It is intended for comparisons of storage de- :.. Just a quick side note: There are known performance problems with the new getnewbuf() in -4.x. These problems have been solved, but not yet committed. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Mar 31 23:20: 3 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 4A4D91516C; Wed, 31 Mar 1999 23:19:56 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id QAA11084; Thu, 1 Apr 1999 16:49:36 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id QAA91354; Thu, 1 Apr 1999 16:49:35 +0930 (CST) Message-ID: <19990401164935.Z413@lemis.com> Date: Thu, 1 Apr 1999 16:49:35 +0930 From: Greg Lehey To: Matthew Dillon Cc: FreeBSD Hackers , FreeBSD SCSI Mailing List Subject: Re: CCD and Vinum compared with new performance measuring tool References: <19990401122922.Q413@lemis.com> <199904010717.XAA53772@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199904010717.XAA53772@apollo.backplane.com>; from Matthew Dillon on Wed, Mar 31, 1999 at 11:17:02PM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wednesday, 31 March 1999 at 23:17:02 -0800, Matthew Dillon wrote: >> >> In the past few weeks, I've been bitching about the fact that bonnie >> doesn't do what I want in measuring storage device performance. I've >> now solved the problem: I've written another program. You can pick it >> up at ftp://ftp.lemis.com/pub/rawio.tar.gz. From the man page: >> >> DESCRIPTION >> rawio tests the speed of the low-level character I/O device special in a >> concurrent environment. It is intended for comparisons of storage de- >> .. > > Just a quick side note: There are known performance problems with the > new getnewbuf() in -4.x. These problems have been solved, but not yet > committed. Thanks for the info. I've noticed that the individual subprocesses tend to run at very different speeds. Does it have anything to do with that? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 1 9:37:33 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by hub.freebsd.org (Postfix) with ESMTP id 20D0B1561C; Thu, 1 Apr 1999 09:36:54 -0800 (PST) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by atlrel2.hp.com (8.9.3/8.8.5tis) with ESMTP id MAA03099; Thu, 1 Apr 1999 12:35:54 -0500 (EST) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA010518097; Thu, 1 Apr 1999 09:34:57 -0800 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id JAA27068; Thu, 1 Apr 1999 09:34:57 -0800 (PST) Message-Id: <199904011734.JAA27068@mina.sr.hp.com> To: Greg Lehey Cc: FreeBSD Hackers , FreeBSD SCSI Mailing List Subject: Re: CCD and Vinum compared with new performance measuring tool Reply-To: Darryl Okahata In-Reply-To: Your message of "Thu, 01 Apr 1999 12:29:22 +0930." <19990401122922.Q413@lemis.com> Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Thu, 01 Apr 1999 09:34:56 -0800 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg Lehey wrote: > In the past few weeks, I've been bitching about the fact that bonnie > doesn't do what I want in measuring storage device performance. I've > now solved the problem: I've written another program. You can pick it > up at ftp://ftp.lemis.com/pub/rawio.tar.gz. From the man page: I hope I'm wrong, but it appears that doing any of the write tests will destroy/corrupt any existing filesystem (and the write tests are enabled if no tests are specified). If so, you may want to make this very clear, as both bonnie and iozone will work file with existing filesystems. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 1 16: 6:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 8BC6E15613; Thu, 1 Apr 1999 16:06:20 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id JAA14549; Fri, 2 Apr 1999 09:36:00 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA93217; Fri, 2 Apr 1999 09:35:57 +0930 (CST) Message-ID: <19990402093557.F413@lemis.com> Date: Fri, 2 Apr 1999 09:35:57 +0930 From: Greg Lehey To: Darryl Okahata Cc: FreeBSD Hackers , FreeBSD SCSI Mailing List Subject: HEADS UP (was: CCD and Vinum compared with new performance measuring tool) References: <19990401122922.Q413@lemis.com> <199904011734.JAA27068@mina.sr.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199904011734.JAA27068@mina.sr.hp.com>; from Darryl Okahata on Thu, Apr 01, 1999 at 09:34:56AM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thursday, 1 April 1999 at 9:34:56 -0800, Darryl Okahata wrote: > Greg Lehey wrote: > >> In the past few weeks, I've been bitching about the fact that bonnie >> doesn't do what I want in measuring storage device performance. I've >> now solved the problem: I've written another program. You can pick it >> up at ftp://ftp.lemis.com/pub/rawio.tar.gz. From the man page: > > I hope I'm wrong, but it appears that doing any of the write tests > will destroy/corrupt any existing filesystem (and the write tests are > enabled if no tests are specified). If so, you may want to make this > very clear, as both bonnie and iozone will work file with existing > filesystems. No, you're right. And yes, I've updated the man page to warn about the overwriting, and I've changed the default to read-only. The new version is available at the same place, ftp://ftp.lemis.com/pub/rawio.tar.gz. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 2 7:48: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pan.ch.intel.com (pan.ch.intel.com [143.182.246.24]) by hub.freebsd.org (Postfix) with ESMTP id 3939314CF5 for ; Fri, 2 Apr 1999 07:47:53 -0800 (PST) (envelope-from jreynold@sedona.ch.intel.com) Received: from sedona.intel.com (sedona.ch.intel.com [143.182.218.21]) by pan.ch.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id IAA20971 for ; Fri, 2 Apr 1999 08:47:34 -0700 (MST) Received: from hip186.ch.intel.com (hip186.ch.intel.com [143.182.225.68]) by sedona.intel.com (8.9.1a/8.9.1/d: sendmail.cf,v 1.7 1999/02/08 16:00:31 steved Exp steved $) with ESMTP id IAA22792 for ; Fri, 2 Apr 1999 08:47:32 -0700 (MST) Received: (from jreynold@localhost) by hip186.ch.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) id KAA25206; Fri, 2 Apr 1999 10:47:31 -0500 (EST) From: John Reynolds~ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14084.59026.344303.181017@hip186.ch.intel.com> Date: Fri, 2 Apr 1999 08:47:30 -0700 (MST) To: freebsd-scsi@freebsd.org Subject: DC-310 (Symbios 53C810) is supported under 3.x X-Mailer: VM 6.70 under Emacs 19.34.1 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is just a quickie letter to -scsi for archive purposes. I had asked this list whether or not people had had direct experience with the Symbios 53C810-based card, DC-310 from Tekram. I didn't get much of a response except from -questions. I ordered it anyway ;-) This note verifies for anybody searching the archives later that the DC-310 is indeed supported no problem. Tekram even lists FreeBSD on the box as supported (but they said only their DC-390U model was supported ... silly people!)!!! So for those questioning if this specific 53C810-based card works, yes! -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds CEG, CCE, Next Generation Flows, HLA | | Intel Corporation MS: CH6-210 Phone: 554-9092 pgr: 868-6512 | | jreynold@sedona.ch.intel.com http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 2 9:32:37 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from watson.fl.curagen.com (watson-e.fl.curagen.com [128.227.25.131]) by hub.freebsd.org (Postfix) with ESMTP id EA53C14BDB for ; Fri, 2 Apr 1999 09:32:35 -0800 (PST) (envelope-from jmunroe@fl.curagen.com) Received: from pc-6 (pc-6.fl.curagen.com [172.16.244.147]) by watson.fl.curagen.com (8.8.8/8.8.8/CGFL-1.0S) with SMTP id MAA16922 for ; Fri, 2 Apr 1999 12:32:14 -0500 (EST) From: "James Munroe" To: Subject: SCSI error code question (No defect spare location available) Date: Fri, 2 Apr 1999 12:32:13 -0500 Message-ID: <002a01be7d2e$bea20790$93f410ac@pc-6.fl.curagen.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does anyone know what the SCSI error code "No defect spare location available field replaceable unit: 3" means? I am running FreeBSD 2.2.5 and I am getting this message occasionally in the kernel logs. Thank you in advance. James To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 2 9:35:46 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 79EC415122 for ; Fri, 2 Apr 1999 09:35:41 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id KAA02701; Fri, 2 Apr 1999 10:35:18 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199904021735.KAA02701@panzer.plutotech.com> Subject: Re: SCSI error code question (No defect spare location available) In-Reply-To: <002a01be7d2e$bea20790$93f410ac@pc-6.fl.curagen.com> from James Munroe at "Apr 2, 1999 12:32:13 pm" To: jmunroe@fl.curagen.com (James Munroe) Date: Fri, 2 Apr 1999 10:35:18 -0700 (MST) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org James Munroe wrote... > Does anyone know what the SCSI error code "No defect spare location > available field replaceable unit: 3" means? I am running FreeBSD 2.2.5 and > I am getting this message occasionally in the kernel logs. Thank you in > advance. It probably means that your hard disk attempted to remap a bad block, but is out of spare sectors to use for remapping. My guess is that your drive is about dead. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 2 9:37: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id EB32714BDB for ; Fri, 2 Apr 1999 09:36:59 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id JAA12765; Fri, 2 Apr 1999 09:36:14 -0800 Date: Fri, 2 Apr 1999 09:36:13 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: James Munroe , freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI error code question (No defect spare location available) In-Reply-To: <199904021735.KAA02701@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > James Munroe wrote... > > Does anyone know what the SCSI error code "No defect spare location > > available field replaceable unit: 3" means? I am running FreeBSD 2.2.5 and > > I am getting this message occasionally in the kernel logs. Thank you in > > advance. > > It probably means that your hard disk attempted to remap a bad block, but > is out of spare sectors to use for remapping. > > My guess is that your drive is about dead. > You *could* reformat with more spares.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 3 0:47: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from relay.nuxi.com (nuxi.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 65C6A14F79; Sat, 3 Apr 1999 00:47:00 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.2/8.9.1) id AAA66064; Sat, 3 Apr 1999 00:44:59 -0800 (PST) (envelope-from obrien) Message-ID: <19990403004459.F65887@nuxi.com> Date: Sat, 3 Apr 1999 00:44:59 -0800 From: "David O'Brien" To: Greg Lehey , FreeBSD Hackers , FreeBSD SCSI Mailing List Subject: Re: CCD and Vinum compared with new performance measuring tool Reply-To: obrien@NUXI.com References: <19990401122922.Q413@lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990401122922.Q413@lemis.com>; from Greg Lehey on Thu, Apr 01, 1999 at 12:29:22PM +0930 X-Operating-System: FreeBSD 3.1-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > now solved the problem: I've written another program. You can pick it > up at ftp://ftp.lemis.com/pub/rawio.tar.gz. From the man page: Port? :-) -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 3 0:50: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 4B54A14F2A; Sat, 3 Apr 1999 00:49:58 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id SAA23230; Sat, 3 Apr 1999 18:18:02 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id SAA02456; Sat, 3 Apr 1999 18:18:01 +0930 (CST) Message-ID: <19990403181800.C2142@lemis.com> Date: Sat, 3 Apr 1999 18:18:00 +0930 From: Greg Lehey To: obrien@NUXI.com, FreeBSD Hackers , FreeBSD SCSI Mailing List Subject: Re: CCD and Vinum compared with new performance measuring tool References: <19990401122922.Q413@lemis.com> <19990403004459.F65887@nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990403004459.F65887@nuxi.com>; from David O'Brien on Sat, Apr 03, 1999 at 12:44:59AM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Saturday, 3 April 1999 at 0:44:59 -0800, David O'Brien wrote: >> now solved the problem: I've written another program. You can pick it >> up at ftp://ftp.lemis.com/pub/rawio.tar.gz. From the man page: > > Port? :-) Once it has stabilised a bit. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 4 11:21:53 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by hub.freebsd.org (Postfix) with ESMTP id CCAE314F39 for ; Sun, 4 Apr 1999 11:21:51 -0700 (PDT) (envelope-from gemorga2@vt.edu) Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id OAA24076 for ; Sun, 4 Apr 1999 14:19:54 -0400 (EDT) Received: from gemorga2.campus.vt.edu (gemorga2.campus.vt.edu [198.82.100.219]) by sable.cc.vt.edu (8.8.8/8.8.8) with SMTP id OAA29166 for ; Sun, 4 Apr 1999 14:19:53 -0400 (EDT) Message-Id: <199904041819.OAA29166@sable.cc.vt.edu> From: "George Morgan" To: freebsd-scsi@freebsd.org Date: Sun, 4 Apr 1999 14:19:54 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: SCSI PCMCIA drive... X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has anyone heard of a SCSI PCMCIA card reader? All the readers I have heard of are proprietary interface. Thanks. George Morgan Virginia Tech Electrical Engineering Class of 2000! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 4 11:49: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id ABF7014CBB for ; Sun, 4 Apr 1999 11:49:04 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id LAA21044; Sun, 4 Apr 1999 11:46:48 -0700 Date: Sun, 4 Apr 1999 11:46:48 -0700 (PWT) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: George Morgan Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI PCMCIA drive... In-Reply-To: <199904041819.OAA29166@sable.cc.vt.edu> 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 Hmm? are you talking about a SCSI device that has PCMCIA readers? There are three that I know of- MPL and Litronics make working ones and Intermart makes a broken one. What do you mean by 'proprietary'? The MPL documentation I have doesn't appear to indicate any 'proprietary' interfaces- just strange and slightly broken ones. (I'm gone for two days, so I can't discuss further until then...) On Sun, 4 Apr 1999, George Morgan wrote: > Has anyone heard of a SCSI PCMCIA card reader? All the readers > I have heard of are proprietary interface. > > Thanks. > > > George Morgan > Virginia Tech > Electrical Engineering > Class of 2000! > > > 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 Mon Apr 5 14: 2:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp.kolej.mff.cuni.cz (smtp.kolej.mff.cuni.cz [195.113.25.225]) by hub.freebsd.org (Postfix) with ESMTP id 6596814D32 for ; Mon, 5 Apr 1999 14:02:08 -0700 (PDT) (envelope-from mdvo3192@mail.kolej.mff.cuni.cz) Received: from mail.kolej.mff.cuni.cz (mail.kolej.mff.cuni.cz [195.113.25.223]) by smtp.kolej.mff.cuni.cz (8.9.2/8.9.0) with ESMTP id XAA88776 for ; Mon, 5 Apr 1999 23:00:11 +0200 (CEST) Received: from localhost (mdvo3192@localhost) by mail.kolej.mff.cuni.cz (8.9.2/8.9.2) with ESMTP id XAA04777 for ; Mon, 5 Apr 1999 23:00:09 +0200 (CEST) Date: Mon, 5 Apr 1999 23:00:09 +0200 (CEST) From: Martin Dvorak To: freebsd-scsi@FreeBSD.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 subscribe freebsd-scsi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 5 14:19:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp.kolej.mff.cuni.cz (smtp.kolej.mff.cuni.cz [195.113.25.225]) by hub.freebsd.org (Postfix) with ESMTP id 3306B15496 for ; Mon, 5 Apr 1999 14:19:51 -0700 (PDT) (envelope-from mdvo3192@mail.kolej.mff.cuni.cz) Received: from mail.kolej.mff.cuni.cz (mail.kolej.mff.cuni.cz [195.113.25.223]) by smtp.kolej.mff.cuni.cz (8.9.2/8.9.0) with ESMTP id XAA90918 for ; Mon, 5 Apr 1999 23:17:53 +0200 (CEST) Received: from localhost (mdvo3192@localhost) by mail.kolej.mff.cuni.cz (8.9.2/8.9.2) with ESMTP id XAA06602 for ; Mon, 5 Apr 1999 23:17:52 +0200 (CEST) Date: Mon, 5 Apr 1999 23:17:52 +0200 (CEST) From: Martin Dvorak To: freebsd-scsi@FreeBSD.ORG Subject: SYM53C876 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 Hi, I am to configure FreeBSD to run on Intel dual PII N440BX motherboard with Symbios SYM53C876 SCSI chipset. I have heard rumors that FreeBSD 3.1-release (which I am to install) should work fine on this motherboard. My problem is I am not sure in kernel configuration. There are too many options on which system stability and speed can depend on. Is there somebody who succesfully configured kernel for this motherboard for the highest stability and speed? Could you send me kernel config file to have something to start with? Thanks very much. Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 6 11:58:53 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from melete.ch.intel.com (melete.ch.intel.com [143.182.246.25]) by hub.freebsd.org (Postfix) with ESMTP id 0803515126; Tue, 6 Apr 1999 11:58:46 -0700 (PDT) (envelope-from jreynold@sedona.ch.intel.com) Received: from sedona.intel.com (sedona.ch.intel.com [143.182.218.21]) by melete.ch.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id LAA22150; Tue, 6 Apr 1999 11:56:47 -0700 (MST) Received: from hip186.ch.intel.com (hip186.ch.intel.com [143.182.225.68]) by sedona.intel.com (8.9.1a/8.9.1/d: sendmail.cf,v 1.7 1999/02/08 16:00:31 steved Exp steved $) with ESMTP id LAA25777; Tue, 6 Apr 1999 11:56:28 -0700 (MST) Received: (from jreynold@localhost) by hip186.ch.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) id OAA25124; Tue, 6 Apr 1999 14:56:29 -0400 (EDT) From: John Reynolds~ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14090.22748.13910.72739@hip186.ch.intel.com> Date: Tue, 6 Apr 1999 11:56:28 -0700 (MST) To: freebsd-scsi@freebsd.org, freebsd-install@freebsd.org Subject: 3.1 Install trouble -- can't see SCSI CD-ROM X-Mailer: VM 6.70 under Emacs 19.34.1 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello gurus, Sorry for the cross-post mail but I figured that since it's probably scsi related and it's definitely install related I was justified ;-) I've been running FreeBSD since 2.0.5 with no hitches on my trusty ol' 486. I recently built up a Pentium II box and am having a bugaboo time getting FreeBSD 3.1 to install on it. Symptom: ------- When I boot from the 3.1 floppies it goes to sysinstall and when I get to the "choose media" screen and pick "CD-ROM" it comes back and says that it can't detect any CD-ROM devices (paraphrase). Observations: ------------- I have already installed NT 4.0 on the machine (for the wife and other "critical" software that I just can't get under FreeBSD) and it seems to find all scsi devices just fine. I've done some crude "stress tests" by "xcopying" an entire CD to the hard drive. It didn't miss a beat. I don't think I've got SCSI termination problems. When the machine boots the BIOS it lists all devices, etc. Machine Hardware: ----------------- Asus P2B-DS motherboard, BIOS rev 1008, 128Mb RAM Adaptec 7890 + AIC3860 Ultra2 chipset. Toshiba XM-6401B 40x CD-ROM, scsi id 3, 50 pin, terminated Yamaha CRW4416S CD-R/CD-RW, scsi id 4, 50 pin, non-terminated Quantum Viking II LVD drive, scsi id 5, hdd0, LVD Quantum Viking II LVD drive, scsi id 6, hdd1, LVD I don't recall the exact stepping or rev of the adaptec chipset. I have NO IDE devices other than the floppy drive. Other Findings: --------------- I can boot the FreeBSD 3.0 floppy and it finds the CD-ROM(s) and all disks. I can boot from the FreeBSD 3.0 CD-ROM #2 and again all scsi stuff is found. When I boot from the FreeBSD 3.1 floppies da0 and da1 *are* found and I have been able to label/partition/newfs them. I've tried using Alt-F1 to switch over to the "debug tty" to see the rest of the probe messages (they buzz away to quickly when the sysinstall screen comes up and I can see them--is there a way to capture this on floppy so I could mail it to these lists???) but really no avail. So, what to do? Is there some sort of mechanism I can perform during this boot where I can get more information for somebody "in the know?" Is this a "known problem?" If so, I couldn't find it in the TROUBLE.TXT or any other place (tried searching the archives but nothing good was found). Any help would GREATLY be appreciated. I REALLY want to get 3.1 on this machine. Thanks, -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds CEG, CCE, Next Generation Flows, HLA | | Intel Corporation MS: CH6-210 Phone: 554-9092 pgr: 868-6512 | | jreynold@sedona.ch.intel.com http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 6 13:38:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id C896814D70 for ; Tue, 6 Apr 1999 13:38:08 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id WAA21705 for freebsd-scsi@freebsd.org; Tue, 6 Apr 1999 22:16:38 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id WAA02539 for freebsd-scsi@freebsd.org; Tue, 6 Apr 1999 22:08:17 +0200 (CEST) From: Wilko Bulte Message-Id: <199904062008.WAA02539@yedi.iaf.nl> Subject: Getting Pioneer CD changer to work To: freebsd-scsi@freebsd.org (FreeBSD SCSI hackers) Date: Tue, 6 Apr 1999 22:08:17 +0200 (CEST) X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I recently obtained a Pioneer 6 CD changer DRM604-X. Currently I'm playing with it to see if I can get it to work on 4.x-current. Sofar it has proven to be a showstopper in that it tends to lock up the ncr (810) adapter during device probe. Yesterday I was more succesful, though as I did not have a CD magazine I used the empty drive. Below are the boot -v messages. Apr 5 16:09:34 p100 /kernel: pass1 at ncr0 bus 0 target 5 lun 0 Apr 5 16:09:34 p100 /kernel: pass1: Removable CD-ROM SCSI-CCS device Apr 5 16:09:34 p100 /kernel: pass1: Serial Number 6 Apr 5 16:09:34 p100 /kernel: pass1: 3.300MB/s transfers Apr 5 16:09:34 p100 /kernel: pass2 at ncr0 bus 0 target 5 lun 1 Apr 5 16:09:35 p100 /kernel: pass2: Removable CD-ROM SCSI-CCS device Apr 5 16:09:35 p100 /kernel: pass2: Serial Number 6 Apr 5 16:09:35 p100 /kernel: pass2: 3.300MB/s transfers Apr 5 16:09:35 p100 /kernel: pass3 at ncr0 bus 0 target 5 lun 2 Apr 5 16:09:35 p100 /kernel: pass3: Removable CD-ROM SCSI-CCS device Apr 5 16:09:35 p100 /kernel: pass3: Serial Number 6 Apr 5 16:09:35 p100 /kernel: pass3: 3.300MB/s transfers Apr 5 16:09:35 p100 /kernel: pass4 at ncr0 bus 0 target 5 lun 3 Apr 5 16:09:35 p100 /kernel: pass4: Removable CD-ROM SCSI-CCS device Apr 5 16:09:35 p100 /kernel: pass4: Serial Number 6 Apr 5 16:09:35 p100 /kernel: pass4: 3.300MB/s transfers Apr 5 16:09:35 p100 /kernel: pass5 at ncr0 bus 0 target 5 lun 4 Apr 5 16:09:35 p100 /kernel: pass5: Removable CD-ROM SCSI-CCS device Apr 5 16:09:35 p100 /kernel: pass5: Serial Number 6 Apr 5 16:09:35 p100 /kernel: pass5: 3.300MB/s transfers Apr 5 16:09:35 p100 /kernel: pass6 at ncr0 bus 0 target 5 lun 5 Apr 5 16:09:35 p100 /kernel: pass6: Removable CD-ROM SCSI-CCS device Apr 5 16:09:35 p100 /kernel: pass6: Serial Number 6 Apr 5 16:09:35 p100 /kernel: pass6: 3.300MB/s transfers Apr 5 16:09:35 p100 /kernel: pass7 at ncr0 bus 0 target 6 lun 0 Apr 5 16:09:35 p100 /kernel: pass7: Removable CD-ROM SCSI-2 device Apr 5 16:09:35 p100 /kernel: pass7: 4.237MB/s transfers (4.237MHz, offset 8) ..... Apr 5 16:09:35 p100 /kernel: changing root device to da0s2a Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): NOT READY asc:b0,0 Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): Vendor Specific ASC Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): NOT READY asc:b0,0 Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): Vendor Specific ASC Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): fatal error, failed to attach to device Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): lost device Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): removing device entry Apr 5 16:09:35 p100 /kernel: (cd1:ncr0:0:5:1): READ CD RECORDED CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 Apr 5 16:09:35 p100 /kernel: (cd1:ncr0:0:5:1): NOT READY asc:b0,0 Apr 5 16:09:35 p100 /kernel: (cd1:ncr0:0:5:1): Vendor Specific ASC Apr 5 16:09:35 p100 /kernel: (cd1:ncr0:0:5:1): READ CD RECORDED CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 Apr 5 16:09:35 p100 /kernel: (cd1:ncr0:0:5:1): NOT READY asc:b0,0 Apr 5 16:09:35 p100 /kernel: (cd1:ncr0:0:5:1): Vendor Specific ASC Apr 5 16:09:36 p100 /kernel: (cd1:ncr0:0:5:1): fatal error, failed to attach to device Apr 5 16:09:36 p100 /kernel: (cd1:ncr0:0:5:1): lost device Apr 5 16:09:36 p100 /kernel: (cd1:ncr0:0 Apr 5 16:09:36 p100 /kernel: :5:1): removing device entry Apr 5 16:09:36 p100 /kernel: da0s1: type 0x1, start 63, end = 12095, size 12033 : OK Apr 5 16:09:36 p100 /kernel: da0s2: type 0xa5, start 12096, end = 4108607, size 4096512 : OK Apr 5 16:09:36 p100 /kernel: (cd2:ncr0:0:5:2): READ CD RECORDED CAPACITY. CDB: 25 40 0 0 0 0 0 0 0 0 Apr 5 16:09:36 p100 /kernel: (cd2:ncr0:0:5:2): NOT READY asc:b0,0 ... [etc, this repeats itself for every LUN] With the magazine in and CDs loaded I get CCB already dequeued messages, timeout nccb blabla, CAM status 0x4b My guess is I need some quirk entries to at least catch the vendor unique ASCs. They probably mean something like "need to load a CD" or something, but I don't have any docs unfortunately. Worse, I got it as-is and I'm not sure if it works correctly. Appreciate insight from people who used these beasts before. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 Tue Apr 6 13:51:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 5161215633; Tue, 6 Apr 1999 13:51:23 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA30560; Tue, 6 Apr 1999 14:48:36 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904062048.OAA30560@panzer.plutotech.com> Subject: Re: 3.1 Install trouble -- can't see SCSI CD-ROM In-Reply-To: <14090.22748.13910.72739@hip186.ch.intel.com> from John Reynolds~ at "Apr 6, 1999 11:56:28 am" To: jreynold@sedona.ch.intel.com (John Reynolds~) Date: Tue, 6 Apr 1999 14:48:36 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG, freebsd-install@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Reynolds~ wrote... > > Hello gurus, > > Sorry for the cross-post mail but I figured that since it's probably scsi > related and it's definitely install related I was justified ;-) > > I've been running FreeBSD since 2.0.5 with no hitches on my trusty ol' > 486. I recently built up a Pentium II box and am having a bugaboo time > getting FreeBSD 3.1 to install on it. > > Symptom: > ------- > > When I boot from the 3.1 floppies it goes to sysinstall and when I get to > the "choose media" screen and pick "CD-ROM" it comes back and says that it > can't detect any CD-ROM devices (paraphrase). > > Observations: > ------------- > > I have already installed NT 4.0 on the machine (for the wife and other > "critical" software that I just can't get under FreeBSD) and it seems to find > all scsi devices just fine. I've done some crude "stress tests" by "xcopying" > an entire CD to the hard drive. It didn't miss a beat. I don't think I've got > SCSI termination problems. When the machine boots the BIOS it lists all > devices, etc. > > Machine Hardware: > ----------------- > > Asus P2B-DS motherboard, BIOS rev 1008, 128Mb RAM > Adaptec 7890 + AIC3860 Ultra2 chipset. > Toshiba XM-6401B 40x CD-ROM, scsi id 3, 50 pin, terminated > Yamaha CRW4416S CD-R/CD-RW, scsi id 4, 50 pin, non-terminated > Quantum Viking II LVD drive, scsi id 5, hdd0, LVD > Quantum Viking II LVD drive, scsi id 6, hdd1, LVD > > I don't recall the exact stepping or rev of the adaptec chipset. I have NO > IDE devices other than the floppy drive. > > Other Findings: > --------------- > > I can boot the FreeBSD 3.0 floppy and it finds the CD-ROM(s) and all disks. > I can boot from the FreeBSD 3.0 CD-ROM #2 and again all scsi stuff is found. > When I boot from the FreeBSD 3.1 floppies da0 and da1 *are* found and I have > been able to label/partition/newfs them. > > I've tried using Alt-F1 to switch over to the "debug tty" to see the rest of > the probe messages (they buzz away to quickly when the sysinstall screen > comes up and I can see them--is there a way to capture this on floppy so I > could mail it to these lists???) but really no avail. > > So, what to do? Is there some sort of mechanism I can perform during this > boot where I can get more information for somebody "in the know?" Is this > a "known problem?" If so, I couldn't find it in the TROUBLE.TXT or any other > place (tried searching the archives but nothing good was found). Any help > would GREATLY be appreciated. I REALLY want to get 3.1 on this machine. Well, there have been problems with machines with 7890s hanging on boot. Justin commited a work-around for the problem on March 22nd/23rd. It might be a good idea to try out one of the snapshots from March 24th or later here: ftp://releng3.FreeBSD.ORG/pub/FreeBSD/snapshots/i386 Either a -current or -stable snapshot will work, although, you'll probably want a stable snapshot. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 6 15: 2:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CA9115537 for ; Tue, 6 Apr 1999 15:02:29 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id QAA31037; Tue, 6 Apr 1999 16:00:24 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904062200.QAA31037@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904062008.WAA02539@yedi.iaf.nl> from Wilko Bulte at "Apr 6, 1999 10: 8:17 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Tue, 6 Apr 1999 16:00:23 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM923436023-30971-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM923436023-30971-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Wilko Bulte wrote... > > I recently obtained a Pioneer 6 CD changer DRM604-X. Currently > I'm playing with it to see if I can get it to work on 4.x-current. > Sofar it has proven to be a showstopper in that it tends to lock > up the ncr (810) adapter during device probe. Yesterday I was > more succesful, though as I did not have a CD magazine I used the > empty drive. > > Below are the boot -v messages. > > Apr 5 16:09:34 p100 /kernel: pass1: 3.300MB/s transfers > Apr 5 16:09:34 p100 /kernel: pass2 at ncr0 bus 0 target 5 lun 1 > Apr 5 16:09:35 p100 /kernel: pass2: Apr 5 16:09:35 p100 /kernel: NEER CD-ROM DRM-600 2401> Removable CD-ROM > SCSI-CCS device [ ... ] > ..... > Apr 5 16:09:35 p100 /kernel: changing root device to da0s2a > Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): READ CD RECORDED CAPACITY. > CDB: 25 0 0 0 0 0 0 0 0 0 > Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): NOT READY asc:b0,0 > Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): Vendor Specific ASC > Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): READ CD RECORDED CAPACITY. > CDB: 25 0 0 0 0 0 0 0 0 0 > Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): NOT READY asc:b0,0 > Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): Vendor Specific ASC > Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): fatal error, failed to > attach to device > Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): lost device > Apr 5 16:09:35 p100 /kernel: (cd0:ncr0:0:5:0): removing device entry [ ... ] > [etc, this repeats itself for every LUN] > > With the magazine in and CDs loaded I get CCB already dequeued messages, > timeout nccb blabla, CAM status 0x4b > > My guess is I need some quirk entries to at least catch the vendor > unique ASCs. They probably mean something like "need to load a CD" > or something, but I don't have any docs unfortunately. Worse, I got it > as-is and I'm not sure if it works correctly. > > Appreciate insight from people who used these beasts before. Well, I've got a couple of ideas. I think there are two things going on here: 1. Your drive responds with an odd ASC when there is no media present. 2. The 20 second timeout for the initial read capacity in the CD driver may be too short for your drive. So, to address the first problem, try the attached diffs. They'll basically make 0x0b an "acceptable" ASC for attachment purposes. To address the second problem, go into cdstart() in sys/cam/scsi/scsi_cd.c and increase the timeout for the read capacity from 20 seconds to say 30 or 40 and see what happens. If putting 0x0b in allows the drive to probe without media present, then that probably means that I need to come up with some generic tie-in to the error recovery code for acceptable errors on probe. I need to make it generic because there are other devices (Joerg's and Matt Dodd's Sony MO drives) that give back weird errors when no media is present. If it turns out that the read capacity timeout is too low, I can probably just bump the default. I would like to get a rough idea of how long it takes your drive to return a read capcity command, so we can avoid making the timeout really long. Ken -- Kenneth Merry ken@plutotech.com --ELM923436023-30971-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=scsi_cd.c.diffs.040699 Content-Description: scsi_cd.c.diffs.040699 Content-Transfer-Encoding: 7bit ==== //depot/cam/sys/cam/scsi/scsi_cd.c#101 - /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_cd.c ==== *** /tmp/tmp.19097.0 Tue Apr 6 15:54:08 1999 --- /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_cd.c Tue Apr 6 15:53:56 1999 *************** *** 1758,1764 **** * attach. */ if ((have_sense) ! && ((asc == 0x3a) || (asc == 0x04)) && (error_code == SSD_CURRENT_ERROR)) snprintf(announce_buf, sizeof(announce_buf), --- 1758,1765 ---- * attach. */ if ((have_sense) ! && ((asc == 0x3a) || (asc == 0x04) || ! (asc == 0x0b)) && (error_code == SSD_CURRENT_ERROR)) snprintf(announce_buf, sizeof(announce_buf), --ELM923436023-30971-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 6 22:42: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from melete.ch.intel.com (melete.ch.intel.com [143.182.246.25]) by hub.freebsd.org (Postfix) with ESMTP id 69AE114CF3; Tue, 6 Apr 1999 22:41:53 -0700 (PDT) (envelope-from jreynold@sedona.ch.intel.com) Received: from sedona.intel.com (sedona.ch.intel.com [143.182.218.21]) by melete.ch.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id WAA11063; Tue, 6 Apr 1999 22:39:48 -0700 (MST) Received: from hip186.ch.intel.com (hip186.ch.intel.com [143.182.225.68]) by sedona.intel.com (8.9.1a/8.9.1/d: sendmail.cf,v 1.7 1999/02/08 16:00:31 steved Exp steved $) with ESMTP id WAA15494; Tue, 6 Apr 1999 22:39:43 -0700 (MST) Received: (from jreynold@localhost) by hip186.ch.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) id BAA26340; Wed, 7 Apr 1999 01:39:43 -0400 (EDT) From: John Reynolds~ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14090.61340.52089.124865@hip186.ch.intel.com> Date: Tue, 6 Apr 1999 22:39:40 -0700 (MST) To: "Kenneth D. Merry" Cc: freebsd-scsi@freebsd.org, freebsd-install@freebsd.org Subject: Re: 3.1 Install trouble -- can't see SCSI CD-ROM In-Reply-To: <199904062048.OAA30560@panzer.plutotech.com> References: <14090.22748.13910.72739@hip186.ch.intel.com> <199904062048.OAA30560@panzer.plutotech.com> X-Mailer: VM 6.70 under Emacs 19.34.1 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ On Tuesday, April 6, Kenneth D. Merry wrote: ] > > Well, there have been problems with machines with 7890s hanging on boot. > Justin commited a work-around for the problem on March 22nd/23rd. > > It might be a good idea to try out one of the snapshots from March 24th or > later here: > > ftp://releng3.FreeBSD.ORG/pub/FreeBSD/snapshots/i386 > > Either a -current or -stable snapshot will work, although, you'll probably > want a stable snapshot. would one be able to get just floppies from that directory and still be able to use the CD-ROM to install the whole system? I realize that the kernel would have to be recompiled after 'supping the same snapshot code. I'm just concerned about installing. I do not have access to a T1 or anything cool. I need to install from CD-ROM (plus I like supporting the effort with my $$$). Lemme know about the above. Thanks for the reply. I'm just about at my wit's end! -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds CEG, CCE, Next Generation Flows, HLA | | Intel Corporation MS: CH6-210 Phone: 554-9092 pgr: 868-6512 | | jreynold@sedona.ch.intel.com http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 1: 4:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from wn1.sci.kun.nl (wn1.sci.kun.nl [131.174.8.1]) by hub.freebsd.org (Postfix) with ESMTP id F0A20155FF for ; Wed, 7 Apr 1999 01:04:52 -0700 (PDT) (envelope-from jvissers@sci.kun.nl) Received: from studs3.sci.kun.nl by wn1.sci.kun.nl via studs3.sci.kun.nl [131.174.124.4] with ESMTP for id KAA12032 (8.8.8/3.23); Wed, 7 Apr 1999 10:02:51 +0200 (MET DST) From: Jos Vissers Received: by studs3.sci.kun.nl via jvissers@localhost for freebsd-scsi@FreeBSD.ORG id KAA05523 (8.8.8/3.1); Wed, 7 Apr 1999 10:02:52 +0200 (MET DST) Message-Id: <199904070802.KAA05523@studs3.sci.kun.nl> Subject: Tekram DC390 To: freebsd-scsi@FreeBSD.ORG Date: Wed, 7 Apr 1999 10:02:51 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I just got a Tekram DC390 because it is cheap and is listed as supported on the back cover of 3.1, and on the back of the box that the controller came in it says that a FreeBSD driver is available. The release notes for 3.1, however, state that this controller was supported by the old scsi driver but has no CAM support YET. Such minor discrepancies can be forgiven of course if they do not appear on every next release cd cover without there actually being support for the card, or perhaps the driver made by Tekram themselves included with the next release. But enough fingerpointing, the Tekram driver seems to work ok. At the moment i only have a cd-writer connected but I can even boot from it, up to the point where the 3.1-release cd kernel doesn't have support for the card ;-) I haven't tried making a bootable cd with support for the card yet but I will soon. If anyone is intersted I can test this card with other devices, i'm currently running 3-stable of 19990405. Jos -- jvissers@sci.kun.nl # Jos Vissers # # Veldsestraat 5 # # 6617 AA Bergharen # # The Netherlands # # (31)-(0)487-531521 # To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 2:55:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 47CD914D12 for ; Wed, 7 Apr 1999 02:55:21 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id SAA23379; Wed, 7 Apr 1999 18:53:21 +0900 (JST) Message-ID: <370B2405.9E9B2EA7@newsguy.com> Date: Wed, 07 Apr 1999 18:23:17 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: 3.1 problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is ncr 53c875 one of the cards not supported any longer on 3.x? If it is supported, any ideas on why a 3.1-RELEASE would not find any hard drives where a 2.2.8 has no problems? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "nothing better than the ability to perform cunning linguistics" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 9: 4:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pan.ch.intel.com (pan.ch.intel.com [143.182.246.24]) by hub.freebsd.org (Postfix) with ESMTP id 314BD15790; Wed, 7 Apr 1999 09:04:05 -0700 (PDT) (envelope-from jreynold@sedona.ch.intel.com) Received: from sedona.intel.com (sedona.ch.intel.com [143.182.218.21]) by pan.ch.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id JAA21031; Wed, 7 Apr 1999 09:01:59 -0700 (MST) Received: from hip186.ch.intel.com (hip186.ch.intel.com [143.182.225.68]) by sedona.intel.com (8.9.1a/8.9.1/d: sendmail.cf,v 1.7 1999/02/08 16:00:31 steved Exp steved $) with ESMTP id JAA13837; Wed, 7 Apr 1999 09:01:55 -0700 (MST) Received: (from jreynold@localhost) by hip186.ch.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) id MAA07923; Wed, 7 Apr 1999 12:01:55 -0400 (EDT) From: John Reynolds~ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14091.33135.748460.555669@hip186.ch.intel.com> Date: Wed, 7 Apr 1999 09:01:51 -0700 (MST) To: "Kenneth D. Merry" Subject: Re: 3.1 Install trouble -- can't see SCSI CD-ROM In-Reply-To: <199904062048.OAA30560@panzer.plutotech.com> References: <14090.22748.13910.72739@hip186.ch.intel.com> <199904062048.OAA30560@panzer.plutotech.com> X-Mailer: VM 6.70 under Emacs 19.34.1 Cc: freebsd-scsi@freebsd.org, freebsd-questions@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ On Tuesday, April 6, Kenneth D. Merry wrote: ] > > [ snip of my tales of fear and loathing regarding CD-ROMs and 3.1 ] > > Well, there have been problems with machines with 7890s hanging on boot. > Justin commited a work-around for the problem on March 22nd/23rd. > > It might be a good idea to try out one of the snapshots from March 24th or > later here: > > ftp://releng3.FreeBSD.ORG/pub/FreeBSD/snapshots/i386 > > Either a -current or -stable snapshot will work, although, you'll probably > want a stable snapshot. [ copying to -questions to see if other individuals have had similar problems with 3.1 and CD-ROM drives ] Thanks for the reply Kenneth! I downloaded the kern and mfsroot floppies for the snapshot of 3.1-stable for 4/6/1999. Made them into disks, popped them into the new machine and BZZZZZZT ... 3.1 still doesn't see the CD-ROM(s) that were connected. I then thought, "maybe it's an adaptec problem" since somebody else told me they had to update the bios on their 2490UW card (I have the onboard 7890 but I figured "what the heck"). So I (temporarily) took the 50-pin bus, unplugged it from the motherboard and plugged it into the other scsi card which will eventually hook up to my scanner (DC-310 from Tekram ... has the 53C810 symbios chip and is found quite easily during boot of 3.1). Plopped the stock 3.1 boot disks into the machine and BZZZT ... 3.1 still would not see the CD-ROM drives connected via ncr0 (these drives were found during POST of the machine, termination is correct, and I was able to see the two CD-ROM drives on this controller in NT when I rebooted ... so I don't think it's hardware). So, what's going on here? Is there some sort of "debug" sysinstall that I can get from somebody that would print more information about what 3.1 is doing/found when it says it can't find any CD-ROM resources? I'd be willing to download, try, report, etc. if it exists. I have not tried a -current snapshot boot disk (I wasn't intending on running current on this machine though). Would the "easiest" thing be to just go ahead and install 3.0 and then try to figure out where 3.1 sources are causing this blip? I tried scouring the archives for problems of this nature related to 3.1 and couldn't find squat. Has anybody else experienced problems with 3.1 and trying to find CD-ROM drives? It doesn't *appear* to be adaptec-related since it couldn't find them even hung off of ncr0 and the DC-310. thanks for all replies, -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds CEG, CCE, Next Generation Flows, HLA | | Intel Corporation MS: CH6-210 Phone: 554-9092 pgr: 868-6512 | | jreynold@sedona.ch.intel.com http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 11: 9:46 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from quark.ChrisBowman.com (crbowman.erols.com [209.122.47.155]) by hub.freebsd.org (Postfix) with ESMTP id 988D415872 for ; Wed, 7 Apr 1999 11:09:39 -0700 (PDT) (envelope-from crb@ChrisBowman.com) Received: from fermion (fermion.ChrisBowman.com [10.0.1.2]) by quark.ChrisBowman.com (8.9.2/8.8.8) with SMTP id OAA44394; Wed, 7 Apr 1999 14:45:45 -0400 (EDT) (envelope-from crb@ChrisBowman.com) Message-Id: <199904071845.OAA44394@quark.ChrisBowman.com> X-Sender: crb@quark X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1 Date: Wed, 07 Apr 1999 14:06:49 -0400 To: "Daniel C. Sobral" From: "Christopher R. Bowman" Subject: Re: 3.1 problem Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <370B2405.9E9B2EA7@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 06:23 PM 4/7/99 +0900, Daniel C. Sobral wrote: >Is ncr 53c875 one of the cards not supported any longer on 3.x? If >it is supported, any ideas on why a 3.1-RELEASE would not find any >hard drives where a 2.2.8 has no problems? Both my 53c875 and my 53c876 (dual channel) cards work fine under 3.1-RELEASE using the ncr driver. -------- Christopher R. Bowman crb@ChrisBowman.com http://www.ChrisBowman.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 11:27:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from carme.eclipse.net.uk (carme.eclipse.net.uk [195.188.32.33]) by hub.freebsd.org (Postfix) with ESMTP id 8B2C814FE6 for ; Wed, 7 Apr 1999 11:27:38 -0700 (PDT) (envelope-from stuart@eclipse.net.uk) Received: from eclipse.net.uk (elara.eclipse.net.uk [195.188.32.31]) by carme.eclipse.net.uk (8.9.3/8.9.3) with ESMTP id TAA52761; Wed, 7 Apr 1999 19:25:21 +0100 (BST) Message-ID: <370BA37F.5ABAF8F7@eclipse.net.uk> Date: Wed, 07 Apr 1999 19:27:11 +0100 From: Stuart Henderson Organization: Eclipse Networking Ltd. X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en-GB MIME-Version: 1.0 To: "Christopher R. Bowman" Cc: "Daniel C. Sobral" , freebsd-scsi@FreeBSD.ORG Subject: Re: 3.1 problem References: <199904071845.OAA44394@quark.ChrisBowman.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>Is ncr 53c875 one of the cards not supported any longer on 3.x? If >>it is supported, any ideas on why a 3.1-RELEASE would not find any >>hard drives where a 2.2.8 has no problems? Is this generic or a custom kernel? Is the 875 listed in dmesg output of the pci bus[1]? If you have built a custom kernel, which SCSI-related devices and options have you used? (nb the scsi device is now called da - it used to be called sd - that bit me the first time I tried moving to v3 and tried to build a new kernel with the config file from v2 - obviously *not* a very good idea - at least now you probably won't even get it built properly with the console changes :) > Both my 53c875 and my 53c876 (dual channel) cards work fine > under 3.1-RELEASE using the ncr driver. I think quite a few people would have noticed if 53c8xx based cards had been broken, they seem to be very popular. Stuart [1] like: Probing for devices on PCI bus 1: ncr0: rev 0x01 int a irq 10 on pci1.4.0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 13: 8: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 265B214CFB for ; Wed, 7 Apr 1999 13:07:47 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id VAA22775; Wed, 7 Apr 1999 21:53:37 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id VAA01873; Wed, 7 Apr 1999 21:57:25 +0200 (CEST) From: Wilko Bulte Message-Id: <199904071957.VAA01873@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904062200.QAA31037@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 6, 1999 4: 0:23 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Wed, 7 Apr 1999 21:57:25 +0200 (CEST) Cc: freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > Wilko Bulte wrote... > > > > I recently obtained a Pioneer 6 CD changer DRM604-X. Currently > > I'm playing with it to see if I can get it to work on 4.x-current. [snip] > > With the magazine in and CDs loaded I get CCB already dequeued messages, > > timeout nccb blabla, CAM status 0x4b Well, I got tired of the bus lockups, as the system disk was on the same bus I could not capture messages easily. So, I dropped in an old Adaptec 1542A (note the A). 4.0 detects the aha ok, and spits out a warning like "1542A, trying to compensate" (or close to that; it sounded as Startrek to me anyway ;-). And locks up, even when no devices are attached to it. Time for more surgery: I freed up a PCI slot and connected the Pioneer cdchanger to a Qlogic 1040 card. This resulted in a much better 'debuggable' system. > > My guess is I need some quirk entries to at least catch the vendor > > unique ASCs. They probably mean something like "need to load a CD" > > or something, but I don't have any docs unfortunately. Worse, I got it > > as-is and I'm not sure if it works correctly. > > > > Appreciate insight from people who used these beasts before. > > Well, I've got a couple of ideas. I think there are two things going on > here: > > 1. Your drive responds with an odd ASC when there is no media present. > 2. The 20 second timeout for the initial read capacity in the CD driver > may be too short for your drive. > > So, to address the first problem, try the attached diffs. They'll > basically make 0x0b an "acceptable" ASC for attachment purposes. I did that and it helps quite a bit: Apr 7 22:30:40 p100 last message repeated 2 times Apr 7 22:30:40 p100 /kernel: (cd0:isp0:0:5:0): READ CD RECORDED CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Apr 7 22:30:40 p100 /kernel: (cd0:isp0:0:5:0): NOT READY asc:3a,0 Apr 7 22:30:40 p100 /kernel: (cd0:isp0:0:5:0): Medium not present Apr 7 22:30:40 p100 /kernel: cd0 at isp0 bus 0 target 5 lun 0 Apr 7 22:30:40 p100 /kernel: cd0: Removable CD-RO M SCSI-CCS device Apr 7 22:30:40 p100 /kernel: cd0: Serial Number 6 Apr 7 22:30:40 p100 /kernel: cd0: 3.300MB/s transfers Apr 7 22:30:40 p100 /kernel: cd0: Attempt to query device size failed: NOT READ Y, Medium not present Apr 7 22:30:51 p100 /kernel: (cd1:isp0:0:5:1): READ CD RECORDED CAPACITY. CDB: 25 20 0 0 0 0 0 0 0 0 Apr 7 22:30:51 p100 /kernel: (cd1:isp0:0:5:1): NOT READY asc:3a,0 Apr 7 22:30:51 p100 /kernel: (cd1:isp0:0:5:1): Medium not present Apr 7 22:30:51 p100 /kernel: cd1 at isp0 bus 0 target 5 lun 1 Apr 7 22:30:52 p100 /kernel: cd1: Removable CD-RO M SCSI-CCS device etc etc. This is with a full 6 cd magazine loaded. > To address the second problem, go into cdstart() in sys/cam/scsi/scsi_cd.c > and increase the timeout for the read capacity from 20 seconds to say 30 or > 40 and see what happens. > > If putting 0x0b in allows the drive to probe without media present, then Yes it will, but only if you change 0b into b0 because that is what the drive reports ;-) You got me scratchin my head with that one 8). Below is what happens without a magazine loaded. Apr 7 22:42:53 p100 /kernel: (cd2:isp0:0:5:2): READ CD RECORDED CAPACITY. CDB: 25 40 0 0 0 0 0 0 0 0 Apr 7 22:42:53 p100 /kernel: (cd2:isp0:0:5:2): NOT READY asc:b0,0 Apr 7 22:42:53 p100 /kernel: (cd2:isp0:0:5:2): Vendor Specific ASC Apr 7 22:42:53 p100 /kernel: cd2 at isp0 bus 0 target 5 lun 2 Apr 7 22:42:53 p100 /kernel: cd2: Removable CD-RO M SCSI-CCS device Apr 7 22:42:53 p100 /kernel: cd2: Serial Number 6 Apr 7 22:42:53 p100 /kernel: cd2: 3.300MB/s transfers Apr 7 22:42:53 p100 /kernel: cd2: Attempt to query device size failed: NOT READ Y, Vendor Specific ASC Apr 7 22:42:53 p100 /kernel: ffs_mountfs: superblock updated for soft updates Apr 7 22:42:53 p100 /kernel: (cd3:isp0:0:5 Apr 7 22:42:53 p100 /kernel: :3): READ CD RECORDED CAPACITY. CDB: 25 60 0 0 0 0 0 0 0 0 > that probably means that I need to come up with some generic tie-in to the > error recovery code for acceptable errors on probe. I need to make it > generic because there are other devices (Joerg's and Matt Dodd's Sony MO > drives) that give back weird errors when no media is present. > > If it turns out that the read capacity timeout is too low, I can probably > just bump the default. I would like to get a rough idea of how long it > takes your drive to return a read capcity command, so we can avoid making > the timeout really long. Now the nasty stuff: my drive has problems *reading*. Initially it whistled like a bird while trying to do so. I assume this is the focussing voice coil of the laser assembly. Cleaning the lens helped, it read (slightly whistling, but much less than before) 2 out of 6 CDs. After a second cleaning operation I made things worse: it now always reports "no medium present" :-( Seems some more hardware surgery seems to be needed. Anybody got a scrap Pioneer DRM604-X that I can get the laser assy from?? Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 13:14: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 88B6A150DA for ; Wed, 7 Apr 1999 13:13:33 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id WAA08136 for freebsd-scsi@FreeBSD.ORG; Wed, 7 Apr 1999 22:11:33 +0200 (CEST) (envelope-from olli) Date: Wed, 7 Apr 1999 22:11:33 +0200 (CEST) From: Oliver Fromme Message-Id: <199904072011.WAA08136@dorifer.heim3.tu-clausthal.de> To: freebsd-scsi@FreeBSD.ORG Subject: Re: 3.1 Install trouble -- can't see SCSI CD-ROM Newsgroups: list.freebsd-scsi Organization: Administration Heim 3 Reply-To: freebsd-scsi@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Reynolds~ wrote in list.freebsd-scsi: > [...] > When I boot from the 3.1 floppies it goes to sysinstall and when I get to > the "choose media" screen and pick "CD-ROM" it comes back and says that it > can't detect any CD-ROM devices (paraphrase). I can confirm that 3.1-RELEASE and 3.1-stable cannot install from a SCSI CD-ROM drive. This is clearly a sysinstall bug. The kernel probes and finds the drives fine, but sysinstall doesn't seem to recognize them. I could reproduce this on several boxes (with very different hardware, but all of them had SCSI CD-ROM drives). IDE CD-ROM drives work fine. There are several workarounds: - Create a (temporary) DOS partition and copy the CD-ROM contents to it, then install from there. - Plug an IDE CD-ROM drive into the box (temporarily) and use it for installation. Sysinstall finds IDE CD-ROM drives without problems. - Put the CD-ROM in another networked PC nearby, and export it via NFS or FTP and install from there. - Copy the "bin" distribution set to floppies and install from them. This will require about 20 floppies, so you probably want to do this only as a last resort. ;-) In either case it's sufficient to install the "bin" files only. Once you can boot the box on its own, you can mount the CD-ROM and install everything else that you need. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 13:39:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ABBF14CE2 for ; Wed, 7 Apr 1999 13:39:49 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA04869; Wed, 7 Apr 1999 14:28:34 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904072028.OAA04869@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904071957.VAA01873@yedi.iaf.nl> from Wilko Bulte at "Apr 7, 1999 9:57:25 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Wed, 7 Apr 1999 14:28:34 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte wrote... > As Kenneth D. Merry wrote ... > > Wilko Bulte wrote... > > > > > > I recently obtained a Pioneer 6 CD changer DRM604-X. Currently > > > I'm playing with it to see if I can get it to work on 4.x-current. > > [snip] > > > > With the magazine in and CDs loaded I get CCB already dequeued messages, > > > timeout nccb blabla, CAM status 0x4b > > Well, I got tired of the bus lockups, as the system disk was on the same > bus I could not capture messages easily. So, I dropped in an old Adaptec > 1542A (note the A). 4.0 detects the aha ok, and spits out a warning > like "1542A, trying to compensate" (or close to that; it sounded as > Startrek to me anyway ;-). And locks up, even when no devices are > attached to it. Time for more surgery: I freed up a PCI slot and > connected the Pioneer cdchanger to a Qlogic 1040 card. > > This resulted in a much better 'debuggable' system. I'm not surprised at all that a 1542A wouldn't work. I think Warner said something about it not working very well. And I'm not surprised that a QLogic 1040 worked better. :) > > > My guess is I need some quirk entries to at least catch the vendor > > > unique ASCs. They probably mean something like "need to load a CD" > > > or something, but I don't have any docs unfortunately. Worse, I got it > > > as-is and I'm not sure if it works correctly. > > > > > > Appreciate insight from people who used these beasts before. > > > > Well, I've got a couple of ideas. I think there are two things going on > > here: > > > > 1. Your drive responds with an odd ASC when there is no media present. > > 2. The 20 second timeout for the initial read capacity in the CD driver > > may be too short for your drive. > > > > So, to address the first problem, try the attached diffs. They'll > > basically make 0x0b an "acceptable" ASC for attachment purposes. > > I did that and it helps quite a bit: > > Apr 7 22:30:40 p100 last message repeated 2 times > Apr 7 22:30:40 p100 /kernel: (cd0:isp0:0:5:0): READ CD RECORDED CAPACITY. > CDB: > 25 0 0 0 0 0 0 0 0 0 > Apr 7 22:30:40 p100 /kernel: (cd0:isp0:0:5:0): NOT READY asc:3a,0 > Apr 7 22:30:40 p100 /kernel: (cd0:isp0:0:5:0): Medium not present > Apr 7 22:30:40 p100 /kernel: cd0 at isp0 bus 0 target 5 lun 0 > Apr 7 22:30:40 p100 /kernel: cd0: Removable > CD-RO > M SCSI-CCS device > Apr 7 22:30:40 p100 /kernel: cd0: Serial Number 6 > Apr 7 22:30:40 p100 /kernel: cd0: 3.300MB/s transfers > Apr 7 22:30:40 p100 /kernel: cd0: Attempt to query device size failed: NOT > READ > Y, Medium not present > Apr 7 22:30:51 p100 /kernel: (cd1:isp0:0:5:1): READ CD RECORDED CAPACITY. > CDB: > 25 20 0 0 0 0 0 0 0 0 > Apr 7 22:30:51 p100 /kernel: (cd1:isp0:0:5:1): NOT READY asc:3a,0 > Apr 7 22:30:51 p100 /kernel: (cd1:isp0:0:5:1): Medium not present > Apr 7 22:30:51 p100 /kernel: cd1 at isp0 bus 0 target 5 lun 1 > Apr 7 22:30:52 p100 /kernel: cd1: Removable > CD-RO > M SCSI-CCS device > > etc etc. This is with a full 6 cd magazine loaded. Well, that is better, but obviously the drive doesn't realize that it actually has media loaded, which is a problem. > > To address the second problem, go into cdstart() in sys/cam/scsi/scsi_cd.c > > and increase the timeout for the read capacity from 20 seconds to say 30 or > > 40 and see what happens. > > > > If putting 0x0b in allows the drive to probe without media present, then > > Yes it will, but only if you change 0b into b0 because that is what the > drive reports ;-) You got me scratchin my head with that one 8). Below is > what happens without a magazine loaded. Ooops! > Apr 7 22:42:53 p100 /kernel: (cd2:isp0:0:5:2): READ CD RECORDED CAPACITY. > CDB: > 25 40 0 0 0 0 0 0 0 0 > Apr 7 22:42:53 p100 /kernel: (cd2:isp0:0:5:2): NOT READY asc:b0,0 > Apr 7 22:42:53 p100 /kernel: (cd2:isp0:0:5:2): Vendor Specific ASC > Apr 7 22:42:53 p100 /kernel: cd2 at isp0 bus 0 target 5 lun 2 > Apr 7 22:42:53 p100 /kernel: cd2: Removable > CD-RO > M SCSI-CCS device > Apr 7 22:42:53 p100 /kernel: cd2: Serial Number 6 > Apr 7 22:42:53 p100 /kernel: cd2: 3.300MB/s transfers > Apr 7 22:42:53 p100 /kernel: cd2: Attempt to query device size failed: NOT > READ > Y, Vendor Specific ASC > Apr 7 22:42:53 p100 /kernel: ffs_mountfs: superblock updated for soft > updates > Apr 7 22:42:53 p100 /kernel: (cd3:isp0:0:5 > Apr 7 22:42:53 p100 /kernel: :3): READ CD RECORDED CAPACITY. CDB: 25 60 0 0 > 0 0 > 0 0 0 0 Well, that looks normal. When you boot without -v, you'll get the normal 1-line error message that you get when there's no media in the drive. > > that probably means that I need to come up with some generic tie-in to the > > error recovery code for acceptable errors on probe. I need to make it > > generic because there are other devices (Joerg's and Matt Dodd's Sony MO > > drives) that give back weird errors when no media is present. > > > > If it turns out that the read capacity timeout is too low, I can probably > > just bump the default. I would like to get a rough idea of how long it > > takes your drive to return a read capcity command, so we can avoid making > > the timeout really long. > > Now the nasty stuff: my drive has problems *reading*. Initially it whistled > like a bird while trying to do so. I assume this is the focussing voice > coil of the laser assembly. Cleaning the lens helped, it read (slightly > whistling, but much less than before) 2 out of 6 CDs. After a second > cleaning operation I made things worse: it now always reports "no medium > present" :-( Seems some more hardware surgery seems to be needed. Bummer. Well, there's not much we can do about that from a software standpoint. But it does explain the medium not present errors above. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 13:40: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 54280158A1; Wed, 7 Apr 1999 13:39:49 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA04808; Wed, 7 Apr 1999 14:17:40 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904072017.OAA04808@panzer.plutotech.com> Subject: Re: 3.1 Install trouble -- can't see SCSI CD-ROM In-Reply-To: <14091.33135.748460.555669@hip186.ch.intel.com> from John Reynolds~ at "Apr 7, 1999 9: 1:51 am" To: jreynold@sedona.ch.intel.com (John Reynolds~) Date: Wed, 7 Apr 1999 14:17:40 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Reynolds~ wrote... > Is there some sort of "debug" sysinstall that I can get from somebody that > would print more information about what 3.1 is doing/found when it says it > can't find any CD-ROM resources? I'd be willing to download, try, report, etc. > if it exists. I have not tried a -current snapshot boot disk (I wasn't > intending on running current on this machine though). > > Would the "easiest" thing be to just go ahead and install 3.0 and then try > to figure out where 3.1 sources are causing this blip? > > I tried scouring the archives for problems of this nature related to 3.1 and > couldn't find squat. Has anybody else experienced problems with 3.1 and > trying to find CD-ROM drives? It doesn't *appear* to be adaptec-related since > it couldn't find them even hung off of ncr0 and the DC-310. I'm not really sure what's going on, but it probably would be easier to debug things if you install 3.0 and then maybe upgrade to 3.1-STABLE via cvsup and buildworld. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 14: 2:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by hub.freebsd.org (Postfix) with ESMTP id A5C2E14DF1 for ; Wed, 7 Apr 1999 14:02:25 -0700 (PDT) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id RAA29483 for ; Wed, 7 Apr 1999 17:00:01 -0400 (EDT) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA202928819; Wed, 7 Apr 1999 14:00:19 -0700 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id OAA02804 for ; Wed, 7 Apr 1999 14:00:19 -0700 (PDT) Message-Id: <199904072100.OAA02804@mina.sr.hp.com> To: freebsd-scsi@FreeBSD.ORG Subject: Re: 3.1 Install trouble -- can't see SCSI CD-ROM Reply-To: Darryl Okahata In-Reply-To: Your message of "Wed, 07 Apr 1999 22:11:33 +0200." <199904072011.WAA08136@dorifer.heim3.tu-clausthal.de> Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Wed, 07 Apr 1999 14:00:16 -0700 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Oliver Fromme wrote: > I can confirm that 3.1-RELEASE and 3.1-stable cannot install > from a SCSI CD-ROM drive. This is clearly a sysinstall bug. I can confirm that 3.1-RELEASE *will* install from a SCSI CDROM drive. I know -- I've done it. Here's part of my dmesg: =============================================================================== ahc0: rev 0x04 int a irq 16 on pci0.12.0 ahc0: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x04 int b irq 16 on pci0.12.1 ahc1: Using left over BIOS settings ahc1: aic7895 Wide Channel B, SCSI Id=7, 16/255 SCBs cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present =============================================================================== You're probably running into some issue with your SCSI controller. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 14:41:37 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (Postfix) with ESMTP id A6CBA14A09; Wed, 7 Apr 1999 14:41:25 -0700 (PDT) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Sisyphos.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id XAA22213; Wed, 7 Apr 1999 23:39:22 +0200 (MET DST) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.6.9) id XAA01677; Wed, 7 Apr 1999 23:36:03 +0200 (CEST) Date: Wed, 7 Apr 1999 23:36:03 +0200 From: Stefan Esser To: Tomas Klockar Cc: freebsd-scsi@freebsd.org, Stefan Esser Subject: Re: Problem with tekram and 3.1-RELEASE Message-ID: <19990407233603.C1574@dialup124.mi.uni-koeln.de> Reply-To: se@freebsd.org References: <199903292232.AAA15190@sister.ludd.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199903292232.AAA15190@sister.ludd.luth.se>; from Tomas Klockar on Tue, Mar 30, 1999 at 12:32:09AM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-03-30 00:32 +0200, Tomas Klockar wrote: > I tried to help a friend with a Tekram 390F SCSI card. > cp PM300.GZ /usr/src > cd /usr/src > zcat PM300.GZ | patch -p0 > config TEKRAM > cd ../../compile/TEKRAM > make depend > make > The source code from Tekram was supposed to be used with freebsd 3.0 not 3.1 > that I tried it with. > I would epreciate all help i can get. What's the problem with the NCR driver and the Tekram card ? I'm using that combination myself ... Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 15:13:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from maui.net (maui.net [207.175.210.2]) by hub.freebsd.org (Postfix) with ESMTP id D774B1507F; Wed, 7 Apr 1999 15:13:35 -0700 (PDT) (envelope-from langfod@kauai.pacificglobal.net) Received: from kauai.pacificglobal.net (Kauai.PacificGlobal.NET [209.84.182.101]) by maui.net (8.8.7/8.8.5) with ESMTP id MAA22273; Wed, 7 Apr 1999 12:11:35 -1000 (HST) Received: (from langfod@localhost) by kauai.pacificglobal.net (8.8.8/8.8.5) id MAA05052; Wed, 7 Apr 1999 12:11:34 -1000 (HST) From: David Langford Message-Id: <199904072211.MAA05052@kauai.pacificglobal.net> Subject: Low cost RAID5? To: questions@freebsd.org Date: Wed, 7 Apr 1999 12:11:34 -1000 (HST) X-blank-line: This space intentionaly left blank. X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Can anyone recomend a good but low cost RAID 5 solution? I am only looking at a three drive solution. SCSI-SCSI would be preferable. I looked at the Mylex CRD-5440 but $2K is a bit high for what I need. Thank you, -David Langford To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 16:23:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 8B3361591C for ; Wed, 7 Apr 1999 16:23:37 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id IAA25620; Thu, 8 Apr 1999 08:21:28 +0900 (JST) Message-ID: <370BE642.8F2E01B7@newsguy.com> Date: Thu, 08 Apr 1999 08:12:02 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Stuart Henderson Cc: "Christopher R. Bowman" , freebsd-scsi@FreeBSD.ORG Subject: Re: 3.1 problem References: <199904071845.OAA44394@quark.ChrisBowman.com> <370BA37F.5ABAF8F7@eclipse.net.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stuart Henderson wrote: > > >>Is ncr 53c875 one of the cards not supported any longer on 3.x? If > >>it is supported, any ideas on why a 3.1-RELEASE would not find any > >>hard drives where a 2.2.8 has no problems? > > Is this generic or a custom kernel? Is the 875 listed in dmesg output of This is installation disk, thus, GENERIC. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "nothing better than the ability to perform cunning linguistics" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 18:37:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id B32E315541 for ; Wed, 7 Apr 1999 18:37:18 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id DAA14359 for freebsd-scsi@freebsd.org; Thu, 8 Apr 1999 03:35:18 +0200 (CEST) (envelope-from olli) Date: Thu, 8 Apr 1999 03:35:18 +0200 (CEST) From: Oliver Fromme Message-Id: <199904080135.DAA14359@dorifer.heim3.tu-clausthal.de> To: freebsd-scsi@freebsd.org Subject: Re: 3.1 Install trouble -- can't see SCSI CD-ROM Newsgroups: list.freebsd-scsi Organization: Administration Heim 3 Reply-To: freebsd-scsi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Darryl Okahata wrote in list.freebsd-scsi: > Oliver Fromme wrote: > > I can confirm that 3.1-RELEASE and 3.1-stable cannot install > > from a SCSI CD-ROM drive. This is clearly a sysinstall bug. > > I can confirm that 3.1-RELEASE *will* install from a SCSI CDROM > drive. I know -- I've done it. Here's part of my dmesg: > [...] > You're probably running into some issue with your SCSI controller. As I wrote in my message, I tried it with several different boxes with very different hardware (and different SCSI host adapters). So that was probably not causing the problem. That's just what I did: Insert kern.flp and CD-ROM #1, boot, insert mfsroot.flp when requested. Kernel will find the CD- ROM drive. Sysinstall doesn't recognize it, unless it's an IDE CD-ROM drive. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 7 21:29:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (Postfix) with ESMTP id E0BB01538A for ; Wed, 7 Apr 1999 21:29:14 -0700 (PDT) (envelope-from fbsd@Ilsa.StevesCafe.com) Received: from Ilsa.StevesCafe.com (localhost.StevesCafe.com [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.8/8.8.5) with ESMTP id WAA10787 for ; Wed, 7 Apr 1999 22:34:17 -0600 (MDT) Message-Id: <199904080434.WAA10787@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: freebsd-scsi@FreeBSD.ORG Subject: Re: 3.1 Install trouble -- can't see SCSI CD-ROM In-reply-to: Your message of "Thu, 08 Apr 1999 03:35:18 +0200." <199904080135.DAA14359@dorifer.heim3.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 07 Apr 1999 22:34:16 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > Darryl Okahata wrote in list.freebsd-scsi: > > Oliver Fromme wrote: > > > I can confirm that 3.1-RELEASE and 3.1-stable cannot install > > > from a SCSI CD-ROM drive. This is clearly a sysinstall bug. > > = > > I can confirm that 3.1-RELEASE *will* install from a SCSI CDROM= > > drive. I know -- I've done it. Here's part of my dmesg: > > [...] > > You're probably running into some issue with your SCSI controll= er. > = > As I wrote in my message, I tried it with several different > boxes with very different hardware (and different SCSI host > adapters). So that was probably not causing the problem. > = > That's just what I did: Insert kern.flp and CD-ROM #1, boot, > insert mfsroot.flp when requested. Kernel will find the CD- > ROM drive. Sysinstall doesn't recognize it, unless it's an > IDE CD-ROM drive. I can also confirm a system install of 3.1R from a SCSI cdrom drive. An asus p2l97-ds, with an older (3-4 years) plextor scsi cdrom drive. -- Steve Passe | powered by = smp@csn.net | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 8 0: 6:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from en26.local.net (froggy.anchorage.ptialaska.net [208.151.119.238]) by hub.freebsd.org (Postfix) with ESMTP id EB1A9158FB for ; Thu, 8 Apr 1999 00:05:55 -0700 (PDT) (envelope-from groggy@iname.com) Received: from en26.local.net (localhost [127.0.0.1]) by en26.local.net (8.8.8/8.8.8) with SMTP id QAA02836 for ; Tue, 6 Apr 1999 16:30:46 -0800 (AKDT) (envelope-from groggy@iname.com) Date: Tue, 6 Apr 1999 16:30:46 -0800 (AKDT) From: Steve Howe X-Sender: abc@en26.local.net To: freebsd-scsi@freebsd.org Subject: scanners 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'm setting up FBSD 2.2.8 for a friend that has a 2940UW. he wants a scanner (either a UMAX 1220S or the new HP with the document feeder). i've been reading the maillists, and it seems many people are having trouble with scanners, CAM, and SANE (whatever that is ;). attached to the 2940UW will be the scanner (25 pin?), an IBM 4.5G (68 pin), HP CD/RW (50 pin), and a Mitsumi CD 32x (50 pin). possibly a Zip Drive (25 pin?) also. 1. are all SCSI scanners compatible? even if they have a document feeder? 2. i remember reading problems about putting 50/25 pin adapters on 68 pin connectors - is this still a problem? the external 2940UW connector will have to drop to 25 pins for the scanner, and probably the zip drive. it is also a concern, since the 68 pin internal connector must be used for the IBM HD, but i need to attach the CD/RW and the CD internally. as you know, you can only use 2 of the 3 connectors on the 2940UW. 3. what additional software do i need to pick up to do this stuff besides the 2.2.8 dist and the kernel sources? i don't see anything about htis stuff in the documentation and i'm new to SCSI stuff. any help would be greatly appreciated - please reply off the list as well, ok? ;) thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 8 3:38:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id E2EA615188 for ; Thu, 8 Apr 1999 03:38:42 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id MAA19234; Thu, 8 Apr 1999 12:36:12 +0200 (CEST) (envelope-from olli) Date: Thu, 8 Apr 1999 12:36:12 +0200 (CEST) From: Oliver Fromme Message-Id: <199904081036.MAA19234@dorifer.heim3.tu-clausthal.de> To: freebsd-scsi@FreeBSD.ORG Cc: groggy@iname.com Subject: Re: scanners Newsgroups: list.freebsd-scsi Organization: Administration Heim 3 Reply-To: freebsd-scsi@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Steve Howe wrote in list.freebsd-scsi: > i'm setting up FBSD 2.2.8 for a friend that has a 2940UW. he wants a > scanner (either a UMAX 1220S or the new HP with the document feeder). > i've been reading the maillists, and it seems many people are having > trouble with scanners, CAM, and SANE (whatever that is ;). SANE ("scanner access now easy") is a bunch of drivers and tools to access scanners under UNIX. It can be used as a plug-in for gimp, for example. I _strongly_ recommend that you put the scanner on a separate SCSI card. UMAX scanners have a broken SCSI interface which _blocks_ the whole bus during scanning. They're not really designed to live with other devices on the same bus. The HP scanners are better (at least we have a HP ScanJet-6100C hanging off a Sun without such problems). Using a separate controller for the scanner will also reduce your cabling problems. For an Ultra-SCSI bus, the maximum cable length is 1.5m (that is, internal plus external cables). At least in theory -- if you have high-quality cables, terminators and wide-to-narrow adapters. > 1. are all SCSI scanners compatible? even if they have a document feeder? I'm not sure if SANE supports the document feeder. You should refer to the SANE documentation. it also contains hints about the various scanners and how "compatible" they are. > 2. i remember reading problems about putting 50/25 pin adapters on 68 pin > connectors - is this still a problem? the external 2940UW connector will > have to drop to 25 pins for the scanner, and probably the zip drive. > > it is also a concern, since the 68 pin internal connector must be used for > the IBM HD, but i need to attach the CD/RW and the CD internally. as you > know, you can only use 2 of the 3 connectors on the 2940UW. Save yourself a lot of trouble and get a separate SCSI adapter for the external devices. It doesn't even have to be an ultra fast one, because scanner and ZIP drive don't require much bandwidth. > 3. what additional software do i need to pick up to do this stuff besides > the 2.2.8 dist and the kernel sources? i don't see anything about htis > stuff in the documentation and i'm new to SCSI stuff. Why 2.2.8? I'd go for a recent 3.1-stable snapshot. When creating the kernel config file, be sure to include all devices that you need for the SCSI stuff. In particular, for the scanner you'll need the "processor target" device (pt0). SANE is in the ports collection (graphics/sane), it contains more docs about how to set it up with your scanner (there are "sane-umax" and "sane-hp" manual pages which you probably want to read). Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 8 13: 7:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 8C98514DC1 for ; Thu, 8 Apr 1999 13:07:16 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id VAA24296 for freebsd-scsi@freebsd.org; Thu, 8 Apr 1999 21:41:57 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id VAA02518 for freebsd-scsi@freebsd.org; Thu, 8 Apr 1999 21:32:56 +0200 (CEST) From: Wilko Bulte Message-Id: <199904081932.VAA02518@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work To: freebsd-scsi@freebsd.org (FreeBSD SCSI hackers) Date: Thu, 8 Apr 1999 21:32:56 +0200 (CEST) X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > Wilko Bulte wrote... > > As Kenneth D. Merry wrote ... > > > Wilko Bulte wrote... > > > > As Kenneth D. Merry wrote ... > > > > > Wilko Bulte wrote... > > > > > > > > > I'm not surprised at all that a 1542A wouldn't work. I think Warner said > > > something about it not working very well. > > > > "Not very well" seems to be an understatement, at least on my box. Ah well, > > it served me well for years but it is showing it's age I suppose. > > You might talk to Warner and see what he has to say about > the 1542A. I might do so when I get the the Pioneer working a bit better. It's probably time to drag out the ol' oscilloscope to see what the signals look like. After figgling a bit more with the "don't touch me, not user adjustable" screws it appears to work reasonable now. Not that I really trust it ;-) > > 0 0 0 0 0 0 0 > > Apr 8 00:30:05 p100 /kernel: (cd5:isp0:0:5:5): ILLEGAL REQUEST asc:20,0 > > Apr 8 00:30:05 p100 /kernel: (cd5:isp0:0:5:5): Invalid command operation > > code > > Apr 8 00:30:05 p100 /kernel: (cd5:isp0:0:5:5): fatal error, failed to > > attach to device > > Apr 8 00:30:05 p100 /kernel: (cd5:isp0:0:5:5): lost device > > Apr 8 00:30:05 p100 /kernel: (cd5:isp0:0:5:5): removing device entry > > > > The 2 last entries are CD discs the drive seems to hate. If I move 'm around > > in the magazine the problems move with them. As these are (literally..) > > scratch CDs I'm gonna get a couple of fresh ones tomorrow. Plenty of > > old but factory fresh marketing promo CDs around ;-) Mind you, I still Which worked. The new CDs are being read and cycled thru load/unload by a shell script as I write this. > FWIW, Justin and I have been talking about making the CD and DA drivers > attach to devices "no matter what", for the most part. (unless they say > something like "logical unit not supported") To be honest I never saw the point in doing a READ CAPACITY etc on a CD drive. If it responds to an inquiry OK, does not produce sense codes like hardware error I'd conclude we have a working drive on our hands. But that might be too simplistic. > > I bumped the timeout to 120000 (ugh) 'cause the drive takes a considerable > > time to 'inventory' the magazine. Especially when errors occur a long > > timeout seems to be needed. > > You shouldn't need to do that unless it really does take 2 minutes to probe > each lun. Once the changer code in the CD driver sees a CDROM device on a > LUN other than 0, it assumes that it is a changer. > > That means that the probing should happen sequentially, not in parallel. > So your timeout should be the time it takes for one LUN to probe, not all > of them. OK. I just went back to the driver. I put the original driver in the tree again and just added the 0xb0 ASC the drive reports during probe when no magazine/cds are loaded. I left all the timeouts alone for now. Will test this later tonight when it has completed a complete magazine test cycle. > You can put a quirk entry in the CD driver to make sure the CD driver sees > even LUN 0 as part of a changer, but I don't think it'll have any noticable > effect on the way things work. It has no problems detecting the 6 LUNs. > > A mount of a plain iso9660 cd produced a new interesting message: > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): READ TOC/PMA/ATIP {MMC > > Proposed}. CDB: 43 60 0 0 0 0 0 0 4 0 > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): ILLEGAL REQUEST asc:20,0 > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): ILLEGAL REQUEST asc:20,0 > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): Invalid command operation > > code > > > > Makes me wonder, especially because the Pioneer firmware claims to be CCS > > only. There is a little dipswitch claiming to select SCSI-2 mode but it > > does not have any obvious effect. I guess this is a pre-SCSI-2 firmware rev > > and it does not have the standard SCSI cmds for optical devices. They were > > introduced in SCSI-2 IIRC. Really a funky piece of hardware ;-) > > Yeah, definitely makes me wonder. I wonder how you get the table of > contents off the thing, since that is the standard CDROM TOC command that > should work on most any CDROM.. 'Most any' appears to be the right term for it ;) I'll experiment a bit more. Just go a solid system lockup by running a 'dd if=/dev/rcd0a' and a 'mount /dev/cd1a ...' at the same time. Only ping still works. Hmm. More testing to do I guess Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 8 13:29:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 051C415217 for ; Thu, 8 Apr 1999 13:28:52 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA11726; Thu, 8 Apr 1999 14:26:42 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904082026.OAA11726@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904081839.UAA01138@yedi.iaf.nl> from Wilko Bulte at "Apr 8, 1999 8:39:55 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Thu, 8 Apr 1999 14:26:42 -0600 (MDT) Cc: freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ CCing this to -scsi since you seem to be sending things separately to me and then the -scsi list ] Wilko Bulte wrote... > As Kenneth D. Merry wrote ... > > Wilko Bulte wrote... > > > As Kenneth D. Merry wrote ... > > > > Wilko Bulte wrote... > > > > > As Kenneth D. Merry wrote ... > > > > > > Wilko Bulte wrote... > > FWIW, Justin and I have been talking about making the CD and DA drivers > > attach to devices "no matter what", for the most part. (unless they say > > something like "logical unit not supported") > > To be honest I never saw the point in doing a READ CAPACITY etc on a CD > drive. If it responds to an inquiry OK, does not produce sense codes > like hardware error I'd conclude we have a working drive on our hands. > But that might be too simplistic. We have to do a read capacity if we're going to mount the CD at all. The read capacity provides two critical pieces of information: the sector/block size of the device, and the size of the device. Both are needed for the disklabel and for mounting filesystems. Now the read capacity may not be necessary on attach, but it must be done before we can open the CD. I think it's generally worthwhile to do on attach as well. > > > I bumped the timeout to 120000 (ugh) 'cause the drive takes a considerable > > > time to 'inventory' the magazine. Especially when errors occur a long > > > timeout seems to be needed. > > > > You shouldn't need to do that unless it really does take 2 minutes to probe > > each lun. Once the changer code in the CD driver sees a CDROM device on a > > LUN other than 0, it assumes that it is a changer. > > > > That means that the probing should happen sequentially, not in parallel. > > So your timeout should be the time it takes for one LUN to probe, not all > > of them. > > OK. I just went back to the driver. I put the original driver in the tree > again and just added the 0xb0 ASC the drive reports during probe when no > magazine/cds are loaded. I left all the timeouts alone for now. > > Will test this later tonight when it has completed a complete magazine > test cycle. > > > You can put a quirk entry in the CD driver to make sure the CD driver sees > > even LUN 0 as part of a changer, but I don't think it'll have any noticable > > effect on the way things work. > > It has no problems detecting the 6 LUNs. The CD driver will detect all 6 LUNs with or without a quirk. The only reason for a quirk entry is that the various LUNs of the changer will not be seen/grouped as a changer until the CD driver sees a LUN greater than 1. Once a group of CD devices is recognized as a changer, I/O to any of those devices goes through the changer scheduler in the CD driver. The changer scheduler schedules I/O to each LUN in a changer, makes sure one LUN can't hog the changer if there is outstanding I/O to another LUN, etc. I don't think it's really necessary to have a quirk entry, though, since all the LUNs will be put in the changer scheduler before any I/O goes to LUN 1 of the device. > > > A mount of a plain iso9660 cd produced a new interesting message: > > > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): READ TOC/PMA/ATIP {MMC > > > Proposed}. CDB: 43 60 0 0 0 0 0 0 4 0 > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): ILLEGAL REQUEST asc:20,0 > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): ILLEGAL REQUEST asc:20,0 > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): Invalid command operation > > > code > > > > > > Makes me wonder, especially because the Pioneer firmware claims to be CCS > > > only. There is a little dipswitch claiming to select SCSI-2 mode but it > > > does not have any obvious effect. I guess this is a pre-SCSI-2 firmware rev > > > and it does not have the standard SCSI cmds for optical devices. They were > > > introduced in SCSI-2 IIRC. Really a funky piece of hardware ;-) > > > > Yeah, definitely makes me wonder. I wonder how you get the table of > > contents off the thing, since that is the standard CDROM TOC command that > > should work on most any CDROM.. > > 'Most any' appears to be the right term for it ;) I'll experiment a bit > more. Just go a solid system lockup by running a 'dd if=/dev/rcd0a' and > a 'mount /dev/cd1a ...' at the same time. Only ping still works. Hmm. > More testing to do I guess Hmm, interesting. What happens if you just try the DD? Can you break into the debugger when the machine locks up? Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 8 15: 7:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 258A314D6B for ; Thu, 8 Apr 1999 15:07:20 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id XAA31707; Thu, 8 Apr 1999 23:58:57 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id XAA04131; Thu, 8 Apr 1999 23:52:57 +0200 (CEST) From: Wilko Bulte Message-Id: <199904082152.XAA04131@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904082026.OAA11726@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 8, 1999 2:26:42 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Thu, 8 Apr 1999 23:52:57 +0200 (CEST) Cc: freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > [ CCing this to -scsi since you seem to be sending things separately to me > and then the -scsi list ] Sorry, that was a mistake which I corrected with a seperate CC: copy to -scsi > Wilko Bulte wrote... > > As Kenneth D. Merry wrote ... > > > Wilko Bulte wrote... > > > > As Kenneth D. Merry wrote ... > > > > > Wilko Bulte wrote... > > > > > > As Kenneth D. Merry wrote ... > > > > > > > Wilko Bulte wrote... > > > FWIW, Justin and I have been talking about making the CD and DA drivers > > > attach to devices "no matter what", for the most part. (unless they say > > > something like "logical unit not supported") > > > > To be honest I never saw the point in doing a READ CAPACITY etc on a CD > > drive. If it responds to an inquiry OK, does not produce sense codes > > like hardware error I'd conclude we have a working drive on our hands. > > But that might be too simplistic. > > We have to do a read capacity if we're going to mount the CD at all. The > read capacity provides two critical pieces of information: the > sector/block size of the device, and the size of the device. Both are > needed for the disklabel and for mounting filesystems. OK, sounds like I need another beer ;-) I confused the READ CAPACITY with the READ TOC (see below) The only thing that could go I think is the warning/error that occurs when no CD is loaded in the drive during probe. > Now the read capacity may not be necessary on attach, but it must be done > before we can open the CD. I think it's generally worthwhile to do on > attach as well. It should not hurt. Maybe a 'silent' one in case of an empty drive? > > > That means that the probing should happen sequentially, not in parallel. > > > So your timeout should be the time it takes for one LUN to probe, not all > > > of them. > > > > OK. I just went back to the driver. I put the original driver in the tree > > again and just added the 0xb0 ASC the drive reports during probe when no > > magazine/cds are loaded. I left all the timeouts alone for now. > > > > Will test this later tonight when it has completed a complete magazine > > test cycle. In the meantime it has proven to work OK with the default timeouts, and only the 0xb0 line in. > > > You can put a quirk entry in the CD driver to make sure the CD driver sees > > > even LUN 0 as part of a changer, but I don't think it'll have any noticable > > > effect on the way things work. > > > > It has no problems detecting the 6 LUNs. > > The CD driver will detect all 6 LUNs with or without a quirk. The only > reason for a quirk entry is that the various LUNs of the changer will not > be seen/grouped as a changer until the CD driver sees a LUN greater than 1. > > Once a group of CD devices is recognized as a changer, I/O to any of those > devices goes through the changer scheduler in the CD driver. The changer > scheduler schedules I/O to each LUN in a changer, makes sure one LUN can't > hog the changer if there is outstanding I/O to another LUN, etc. > > I don't think it's really necessary to have a quirk entry, though, since > all the LUNs will be put in the changer scheduler before any I/O goes to > LUN 1 of the device. That is what I meant. It works with or without the quirk entry. I tried both. Interestingly enough there is a quirk entry for Pioneer already, but my drive has a slightly different inquiry string: { { T_CDROM, SIP_MEDIA_REMOVABLE, "PIONEER", "CD-ROM DRM-604X", "*"}, /* quirks */ CD_Q_CHANGER }, { { T_CDROM, SIP_MEDIA_REMOVABLE, "PIONEER", "CD-ROM DRM-600", "*"}, /* quirks */ CD_Q_CHANGER }, I'm not sure if it is worthwhile to put a quirk in the driver for this drive. Maybe if I can get info on why READ TOCs etc fail.. Just sent mail to Pioneer in Belgium to ask for a SCSI implementation manual for this drive. Lets be optimistic.. > > > > A mount of a plain iso9660 cd produced a new interesting message: > > > > > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): READ TOC/PMA/ATIP {MMC > > > > Proposed}. CDB: 43 60 0 0 0 0 0 0 4 0 > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): ILLEGAL REQUEST asc:20,0 > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): ILLEGAL REQUEST asc:20,0 > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): Invalid command operation > > > > code > > > > > > > > Makes me wonder, especially because the Pioneer firmware claims to be CCS > > > > only. There is a little dipswitch claiming to select SCSI-2 mode but it > > > > does not have any obvious effect. I guess this is a pre-SCSI-2 firmware rev > > > > and it does not have the standard SCSI cmds for optical devices. They were > > > > introduced in SCSI-2 IIRC. Really a funky piece of hardware ;-) > > > > > > Yeah, definitely makes me wonder. I wonder how you get the table of > > > contents off the thing, since that is the standard CDROM TOC command that > > > should work on most any CDROM.. > > > > 'Most any' appears to be the right term for it ;) I'll experiment a bit > > more. Just go a solid system lockup by running a 'dd if=/dev/rcd0a' and > > a 'mount /dev/cd1a ...' at the same time. Only ping still works. Hmm. > > More testing to do I guess > > Hmm, interesting. What happens if you just try the DD? Can you break into > the debugger when the machine locks up? I made a new kernel with the debugger in. I'll have it run overnight to see if it re-occurs. In the meantime there was also a spontaneous reboot. No panic as far as I can see. I'll try to reproduce.. Just the DD seems to work just fine. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 8 16:14:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B8F314D1D for ; Thu, 8 Apr 1999 16:14:08 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id RAA12752; Thu, 8 Apr 1999 17:11:54 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904082311.RAA12752@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904082152.XAA04131@yedi.iaf.nl> from Wilko Bulte at "Apr 8, 1999 11:52:57 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Thu, 8 Apr 1999 17:11:54 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte wrote... > As Kenneth D. Merry wrote ... > > Wilko Bulte wrote... > > > As Kenneth D. Merry wrote ... > > > > Wilko Bulte wrote... > > > > > As Kenneth D. Merry wrote ... > > > > > > Wilko Bulte wrote... > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > Wilko Bulte wrote... > > > > FWIW, Justin and I have been talking about making the CD and DA drivers > > > > attach to devices "no matter what", for the most part. (unless they say > > > > something like "logical unit not supported") > > > > > > To be honest I never saw the point in doing a READ CAPACITY etc on a CD > > > drive. If it responds to an inquiry OK, does not produce sense codes > > > like hardware error I'd conclude we have a working drive on our hands. > > > But that might be too simplistic. > > > > We have to do a read capacity if we're going to mount the CD at all. The > > read capacity provides two critical pieces of information: the > > sector/block size of the device, and the size of the device. Both are > > needed for the disklabel and for mounting filesystems. > > OK, sounds like I need another beer ;-) I confused the READ CAPACITY with > the READ TOC (see below) > > The only thing that could go I think is the warning/error that occurs > when no CD is loaded in the drive during probe. I think it's useful to have a message that tells you that there's no CD present, and why the driver thinks that that's the case. > > Now the read capacity may not be necessary on attach, but it must be done > > before we can open the CD. I think it's generally worthwhile to do on > > attach as well. > > It should not hurt. Maybe a 'silent' one in case of an empty drive? See above. In any case, it's already a stripped-down, one-line informational message. > > > > That means that the probing should happen sequentially, not in parallel. > > > > So your timeout should be the time it takes for one LUN to probe, not all > > > > of them. > > > > > > OK. I just went back to the driver. I put the original driver in the tree > > > again and just added the 0xb0 ASC the drive reports during probe when no > > > magazine/cds are loaded. I left all the timeouts alone for now. > > > > > > Will test this later tonight when it has completed a complete magazine > > > test cycle. > > In the meantime it has proven to work OK with the default timeouts, and > only the 0xb0 line in. Good! > > > > You can put a quirk entry in the CD driver to make sure the CD driver sees > > > > even LUN 0 as part of a changer, but I don't think it'll have any noticable > > > > effect on the way things work. > > > > > > It has no problems detecting the 6 LUNs. > > > > The CD driver will detect all 6 LUNs with or without a quirk. The only > > reason for a quirk entry is that the various LUNs of the changer will not > > be seen/grouped as a changer until the CD driver sees a LUN greater than 1. > > > > Once a group of CD devices is recognized as a changer, I/O to any of those > > devices goes through the changer scheduler in the CD driver. The changer > > scheduler schedules I/O to each LUN in a changer, makes sure one LUN can't > > hog the changer if there is outstanding I/O to another LUN, etc. > > > > I don't think it's really necessary to have a quirk entry, though, since > > all the LUNs will be put in the changer scheduler before any I/O goes to > > LUN 1 of the device. > > That is what I meant. It works with or without the quirk entry. I tried > both. Interestingly enough there is a quirk entry for Pioneer already, but > my drive has a slightly different inquiry string: > > { > { T_CDROM, SIP_MEDIA_REMOVABLE, "PIONEER", "CD-ROM > DRM-604X", > "*"}, /* quirks */ CD_Q_CHANGER > }, > { > { T_CDROM, SIP_MEDIA_REMOVABLE, "PIONEER", "CD-ROM DRM-600", > "*"}, /* quirks */ CD_Q_CHANGER > }, > > I'm not sure if it is worthwhile to put a quirk in the driver for this > drive. Maybe if I can get info on why READ TOCs etc fail.. Just sent > mail to Pioneer in Belgium to ask for a SCSI implementation manual for this > drive. Lets be optimistic.. Hmm, well, my guess is that the 604 is just a newer version of the drive you have. I haven't heard any complaints from any 604 owners about read toc problems, so my guess is that it's a SCSI-2 drive. > > > > > A mount of a plain iso9660 cd produced a new interesting message: > > > > > > > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): READ TOC/PMA/ATIP {MMC > > > > > Proposed}. CDB: 43 60 0 0 0 0 0 0 4 0 > > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): ILLEGAL REQUEST asc:20,0 > > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): ILLEGAL REQUEST asc:20,0 > > > > > Apr 8 00:52:46 p100 /kernel: (cd3:isp0:0:5:3): Invalid command operation > > > > > code > > > > > > > > > > Makes me wonder, especially because the Pioneer firmware claims to be CCS > > > > > only. There is a little dipswitch claiming to select SCSI-2 mode but it > > > > > does not have any obvious effect. I guess this is a pre-SCSI-2 firmware rev > > > > > and it does not have the standard SCSI cmds for optical devices. They were > > > > > introduced in SCSI-2 IIRC. Really a funky piece of hardware ;-) > > > > > > > > Yeah, definitely makes me wonder. I wonder how you get the table of > > > > contents off the thing, since that is the standard CDROM TOC command that > > > > should work on most any CDROM.. > > > > > > 'Most any' appears to be the right term for it ;) I'll experiment a bit > > > more. Just go a solid system lockup by running a 'dd if=/dev/rcd0a' and > > > a 'mount /dev/cd1a ...' at the same time. Only ping still works. Hmm. > > > More testing to do I guess > > > > Hmm, interesting. What happens if you just try the DD? Can you break into > > the debugger when the machine locks up? > > I made a new kernel with the debugger in. I'll have it run overnight to see > if it re-occurs. In the meantime there was also a spontaneous reboot. No > panic as far as I can see. I'll try to reproduce.. Just the DD seems > to work just fine. Hmm, sounds strange indeed. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 8 20:35: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ns.greyzone.com (ns.greyzone.com [167.216.244.129]) by hub.freebsd.org (Postfix) with ESMTP id 6743214FC3 for ; Thu, 8 Apr 1999 20:35:02 -0700 (PDT) (envelope-from daniel@greyzone.com) Received: from daniel (daniel.greyzone.com [167.216.176.102]) by ns.greyzone.com (8.9.3/8.9.3) with SMTP id UAA00428 for ; Thu, 8 Apr 1999 20:33:01 -0700 (PDT) Message-Id: <4.1.19990408202657.00ae3c30@mail.greyzone.com> X-Sender: daniel@mail.greyzone.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 08 Apr 1999 20:27:03 -0700 To: freebsd-scsi@FreeBSD.ORG From: Daniel Duerr Subject: Problems with Adaptec 2940UW & Travan Drive Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I cannot, for the life of me, get a 2940UW (PCI) to work with my Wangtek/Tecmar SCSI TR-4 Travan Tape Drive. Every time I boot I get the following error messages: Mar 31 17:06:00 www1 /kernel: ahc0 rev 1 int a irq 12 on pci0:17:0 Mar 31 17:06:00 www1 /kernel: ahc0: aic7880 Wide Channel, SCSI Id=7, 16 SCBs Mar 31 17:06:00 www1 /kernel: ahc0 waiting for scsi devices to settle Mar 31 17:06:00 www1 /kernel: (ahc0:6:0): "TECMAR TRAVAN NS8 P611" type 1 remova ble SCSI 2 Mar 31 17:06:00 www1 /kernel: st0(ahc0:6:0): Sequential-Access density code 0x45 , Mar 31 17:06:00 www1 /kernel: st0(ahc0:6:0): Target Busy Mar 31 17:06:00 www1 /kernel: Mar 31 17:06:00 www1 /kernel: st0(ahc0:6:0): Target Busy Mar 31 17:06:00 www1 /kernel: Mar 31 17:06:00 www1 /kernel: st0(ahc0:6:0): Target Busy Mar 31 17:06:00 www1 /kernel: drive empty Every time I try to access the drive I get: www1# tar t st0: not ready tar: can't open /dev/rst0 : Device busy and /var/log/messages says: Apr 1 20:53:52 www1 /kernel: st0(ahc0:6:0): NOT READY asc:3a,0 Medium not prese nt There *IS* perfectly functional media present in the drive. In fact, this same drive used to work with FreeBSD 2.2.5 and a Adaptec "aic" 1520 adaptor. I am running this system on a genuine-Intel 233Mhz running FreeBSD 2.2.8 Any ideas would be GREATLY appreciated! Thanks! Daniel Duerr Grey Zone Productions, Inc. Internet Solutions with Customer Control daniel@greyzone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 0:32:38 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id F094A14FD3 for ; Fri, 9 Apr 1999 00:32:34 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id IAA62535 for ; Fri, 9 Apr 1999 08:30:32 +0100 (BST) Message-ID: <370DAC97.2B48323E@tdx.co.uk> Date: Fri, 09 Apr 1999 08:30:31 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: Strange SCSI panic - devstat_end_transaction Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi All, My box did this last night, and I was wondering if anyone could shed any light on it? - Unfortunately the machine was locked solid, and didn't manage to dump... I was newfs'ing a Vinum volume at the time - da2 is dedicated solely to /usr2, and is on a separate controller to all the drives used for Vinum - so I don't think Vinum is related... /usr2 has user home directories on it, a lightly used MySQL database - and the directories for the machines lightly used Apache server (i.e. it was probably being used at the time, but it's never thrashed). The machine is a dual P-Pro200, w/256Mb RAM running on a SuperMicro P6DNF/440FX motherboard. System is running -current as of 22nd March. DA2 is: da2 at ahc0 bus 0 target 5 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da2: 1021MB (2091144 512 byte sectors: 64H 32S/T 1021C) And is running softupdates... The volume got 'mildly' trashed after this - fsck found ~2 errors but does seem to have recovered it without incident. I've quickly checked termination etc. for that controller - and it all appears fine... The contoller (ahc0) is: ahc0: rev 0x01 int a irq 17 on pci0.18.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs Any info / rough ideas would be greatly appreciated... Thanks, -Karl --- devstat_end_transaction: HELP!! busy_count for da2 is < 0 (-1)! panic: vwakeup: neg numoutput mp_lock = 01000001; cpuid = 1; lapic.id = 01000000 boot() called on cpu#1 syncing disks... Fatal trap 12: page fault while in kernel mode mp_lock = 01000002; cpuid = 1; lapic.id = 01000000 fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01b52a0 stack pointer = 0x10:0xff804b2c frame pointer = 0x10:0xff804b30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio <- SMP: XXX trap number = 12 panic: page fault mp_lock = 01000002; cpuid = 1; lapic.id = 01000000 boot() called on cpu#1 devstat_end_transaction: HELP!! busy_count for da2 is < 0 (-1)! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 14:38:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 55FEE15FFF for ; Fri, 9 Apr 1999 14:37:38 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id VAA26695; Fri, 9 Apr 1999 21:48:59 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id VAA15091; Fri, 9 Apr 1999 21:54:44 +0200 (CEST) From: Wilko Bulte Message-Id: <199904091954.VAA15091@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904091714.LAA17078@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 9, 1999 11:14: 6 am" To: ken@plutotech.com (Kenneth D. Merry) Date: Fri, 9 Apr 1999 21:54:43 +0200 (CEST) Cc: freebsd-scsi@freebsd.org X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > Wilko Bulte wrote... > > As Kenneth D. Merry wrote ... > > > Wilko Bulte wrote... > > > > As Kenneth D. Merry wrote ... > > > > > Wilko Bulte wrote... > > > > > > As Kenneth D. Merry wrote ... > > > > > > > Wilko Bulte wrote... > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > Wilko Bulte wrote... > > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > > Wilko Bulte wrote... > > > > > > 'Most any' appears to be the right term for it ;) I'll experiment a bit > > > > > > more. Just go a solid system lockup by running a 'dd if=/dev/rcd0a' and > > > > > > a 'mount /dev/cd1a ...' at the same time. Only ping still works. Hmm. > > > > > > More testing to do I guess > > > > > > > > > > Hmm, interesting. What happens if you just try the DD? Can you break into > > > > > the debugger when the machine locks up? > > > > > > > > I made a new kernel with the debugger in. I'll have it run overnight to see > > > > if it re-occurs. In the meantime there was also a spontaneous reboot. No > > > > panic as far as I can see. I'll try to reproduce.. Just the DD seems > > > > to work just fine. > > > > > > Hmm, sounds strange indeed. > > > > In the meantime I ran the test again. No machine lockup this time. But > > already twice a solid lockup of the drive.. It goes completely comatose, > > not even a SCSI reset from a FreeBSD reboot awakens it. The only thing > > what works is a whack over the head with the powerswitch. This definitely > > is a brilliant piece of firmware I have. I can reproduce a lockup now. But this one looks like a FreeBSD bug to me: - do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k & - do a 'mount -r -t cd9660 /dev/cd2a /mnt' Result: bang! Console lockups, no network logins anymore. I can get into ddb fortunately and can force a dump. But I'm not an expert on gdb -k. A quick try produced: dump 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc015cb43 in boot () (kgdb) bt #0 0xc015cb43 in boot () #1 0xc015cde1 in panic () #2 0xc012ab29 in db_panic () #3 0xc012aac9 in db_command () #4 0xc012ab8e in db_command_loop () #5 0xc012cf0f in db_trap () #6 0xc021e5ce in kdb_trap () #7 0xc022aee4 in trap () #8 0xc021e7f3 in Debugger () #9 0xc0219e60 in scgetc () #10 0xc0214be0 in sckbdevent () #11 0xc02115bb in atkbd_intr () #12 0xc022ee68 in atkbd_isa_intr () #13 0xc0127ad3 in cdrunchangerqueue () #14 0xc0127cbe in cdgetccb () #15 0xc01291f0 in cdprevent () #16 0xc0127633 in cdopen () #17 0xc018bbcb in spec_open () #18 0xc018b9b5 in spec_vnoperate () #19 0xc0201f8d in ufs_vnoperatespec () #20 0xc01860da in vn_open () #21 0xc0182b35 in open () #22 0xc022b71f in syscall () #23 0xc021ef1c in Xint0x80_syscall () #24 0x8048361 in ?? () #25 0x80480e9 in ?? () (kgdb) If you want the dump & kernel to go to an ftp area somewhere plse let me know. It is approx 6Mb in total (gzipped). If you want me to whisper magical words to gdb please tell me which words. ----- Seems I've also found why other people using DRM604X changers might be happier. This is from the xmcd docs: .... "Pioneer DRM-604X units with revisions of the firmware prior to 2403 must be configured to operate in the SCSI-1 mode (DRM-600 emulation, via back panel DIP switches), and xmcd/cda must be configured as if it's operating a DRM-600. Newer DRM-604X units (firmware version 2403 and later) can be set up to run in SCSI-2 mode, and xmcd/cda must be set up accordingly. " .... Guess what: I have firmware 2401. The hunt for something newer is on obviously. A quick look into xmcd's vu_pion.h learned: /* Pioneer vendor-unique commands */ #define OP_VP_EJECT 0xc0 /* Pioneer magazine eject */ #define OP_VP_RDTOC 0xc1 /* Pioneer read TOC */ If I replace the standard READ TOC (0x43) by 0xC1 I get a driver that seems to work just fine. No errors anymore with a mount. Obviously my 'normal' Toshiba CD now complains. So: it seems some type of quirk mechanism is needed. Looking at xmcd again I find a disturbing number of vendor-unique support files for non-SCSI2 drives: ! 0 SCSI-2 standard ! 1 Chinon vendor-unique ! 2 Hitachi vendor-unique ! 3 NEC vendor-unique ! 4 Pioneer vendor-unique ! 5 Sony vendor-unique ! 6 Toshiba vendor-unique ! 7 Panasonic/Matsushita vendor-unique I don't think it is wise to clutter the scsi_cd driver with all this junk. There is more vendor unique stuff around than just the READ TOC (like, surprise surprise, the play audio commands etc) Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 14:39:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 49E4315E8C for ; Fri, 9 Apr 1999 14:37:38 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA22034; Fri, 9 Apr 1999 20:11:56 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id UAA13726; Fri, 9 Apr 1999 20:15:35 +0200 (CEST) From: Wilko Bulte Message-Id: <199904091815.UAA13726@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904091714.LAA17078@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 9, 1999 11:14: 6 am" To: ken@plutotech.com (Kenneth D. Merry) Date: Fri, 9 Apr 1999 20:15:35 +0200 (CEST) Cc: freebsd-scsi@freebsd.org X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > Wilko Bulte wrote... > > As Kenneth D. Merry wrote ... > > > Wilko Bulte wrote... > > > > As Kenneth D. Merry wrote ... > > > > > Wilko Bulte wrote... > > > > > > As Kenneth D. Merry wrote ... > > > > > > > Wilko Bulte wrote... > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > Wilko Bulte wrote... > > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > > Wilko Bulte wrote... ^-- cool > > > > panic as far as I can see. I'll try to reproduce.. Just the DD seems > > > > to work just fine. > > > > > > Hmm, sounds strange indeed. > > > > In the meantime I ran the test again. No machine lockup this time. But > > already twice a solid lockup of the drive.. It goes completely comatose, > > not even a SCSI reset from a FreeBSD reboot awakens it. The only thing > > what works is a whack over the head with the powerswitch. This definitely > > is a brilliant piece of firmware I have. > > > > Console messages: > > > > (cd0:isp0:0:5:0): cddone: got error 0x6 back > > (cd4:isp0:0:5:4): cddone: got error 0x6 back > > (cd3:isp0:0:5:3): cddone: got error 0x6 back > > (cd1:isp0:0:5:1): cddone: got error 0x6 back > > Hmm, looks somewhat familiar. Error 6 is ENXIO. If you boot with -v you > might get more info. You can probably fix it by increasing the minimum > and possibly the maximum changer timeouts. The defaults are 2 seconds and > 10 seconds, respectively. The boot messages are OK, so is the probe. I've diagnosed it as follows: - probes ok - works ok for some time (running my test script) - locks up it's own firmware - kernel throws away the devices associated with the changer, thus cddone 0x6 and 'no such device' errors for 'dd' > Try increasing the minimum to 8 seconds and the maximum to 20: > > options "CHANGER_MIN_BUSY_SECONDS=8" > options "CHANGER_MAX_BUSY_SECONDS=20" > > I had similar problems with Lars Fredriksen's Nakamichi changer that I > borrowed to do the changer functionality in the CD driver. The default > timeouts may be a little too low, but I think they work okay for that sort > of changer at least. In this case it is not the changer. The lockup that happened with me present was during reads by two parallel operating 'dd's like: while : dd sleep 5 dd done So, the drive is seeking quite a bit (you can hear that, and observe it as the case is still off). My guess: the firmware looses track of the parallel I/Os going on. I'm retesting with a single 'dd' in the loop. > If you want to try to reset the SCSI bus without rebooting, you can try > this: > > camcontrol reset 3 > > Where 3 is the bus number. You can find out what bus number your changer > is on from 'camcontrol devlist -v'. Look for scbus# where "#" is the bus > number. Thanks, I'll try that if I get a lockup again. > The BDR functionality in the kernel doesn't work quite right yet, so if you > try something just try the bus reset. > > > Sidetracking a bit: man xpt mentions /dev/xpt. /dev/MAKEDEV does not > > have it though. Is it supposed to be a manual operation with mknod? > > Or is my /dev/MAKEDEV out of date? > > The xpt(4) man pages mentions /dev/xpt0. If your MAKEDEV doesn't have it, > it's out of date: > > {roadwarrior:/usr/home/ken/perforce/cam/etc/etc.i386:26:0} grep xpt MAKEDEV > > sh MAKEDEV pass4 xpt2 # cdev, CAM > xpt*) > name=xpt > units=`expr $i : 'xpt\(.*\)'` > > > That's from -current as of about 3am MDT today. All you need to do is grab > a new copy of MAKEDEV, and then: Right. It proved to be in my -current source tree alright. Apparantly it did not get installed by the 'installworld' for some reason ?? My testbox started off as a 2.2.6 CD install. Ah well, it is there now. camcontrol is happy. If we ever meet, I definitely owe you a couple of beers ;-) Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 14:40: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 19861161C5 for ; Fri, 9 Apr 1999 14:37:38 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id SAA16996; Fri, 9 Apr 1999 18:19:26 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id SAA12288; Fri, 9 Apr 1999 18:15:39 +0200 (CEST) From: Wilko Bulte Message-Id: <199904091615.SAA12288@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904082316.RAA12800@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 8, 1999 5:16:48 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Fri, 9 Apr 1999 18:15:39 +0200 (CEST) Cc: freebsd-scsi@freebsd.org (FreeBSD SCSI hackers) X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > Wilko Bulte wrote... > > As Kenneth D. Merry wrote ... > > OK, so that would mean adding a new quirk type like Q_HAS_WEIRD_TOCCMD or > > something like that. > > > > SCSI revision...: anybody on this list who has such a device other than: > > > > Removable CD-ROM SCSI-CCS device > > [ you didn't CC this to the -scsi list ] Argh. > > It might be interesting to see if older/newer firmware behaves differently. > > Get the distinct feeling this is not the most brilliant firmware west of the > > Chinese Wall... > > > > Apart from the error the CD gets mounted OK BTW. > > Really? How can it, if the READ TOC call doesn't succeed? Maybe it just > defaults to mounting the first track? You tell me ;-) It seems to work though. Apparantly somewhere there is a default assumed that fits well enough to make it work. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 14:40:26 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id F260615E16 for ; Fri, 9 Apr 1999 14:37:38 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id SAA16998; Fri, 9 Apr 1999 18:19:27 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id SAA12343; Fri, 9 Apr 1999 18:24:23 +0200 (CEST) From: Wilko Bulte Message-Id: <199904091624.SAA12343@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904082311.RAA12752@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 8, 1999 5:11:54 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Fri, 9 Apr 1999 18:24:23 +0200 (CEST) Cc: freebsd-scsi@freebsd.org X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > Wilko Bulte wrote... > > As Kenneth D. Merry wrote ... > > > Wilko Bulte wrote... > > > > As Kenneth D. Merry wrote ... > > > > > Wilko Bulte wrote... > > > > > > As Kenneth D. Merry wrote ... > > > > > > > Wilko Bulte wrote... > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > Wilko Bulte wrote... > > That is what I meant. It works with or without the quirk entry. I tried > > both. Interestingly enough there is a quirk entry for Pioneer already, but > > my drive has a slightly different inquiry string: > > > > { > > { T_CDROM, SIP_MEDIA_REMOVABLE, "PIONEER", "CD-ROM > > DRM-604X", > > "*"}, /* quirks */ CD_Q_CHANGER > > }, > > { > > { T_CDROM, SIP_MEDIA_REMOVABLE, "PIONEER", "CD-ROM DRM-600", > > "*"}, /* quirks */ CD_Q_CHANGER > > }, > > > > I'm not sure if it is worthwhile to put a quirk in the driver for this > > drive. Maybe if I can get info on why READ TOCs etc fail.. Just sent > > mail to Pioneer in Belgium to ask for a SCSI implementation manual for this > > drive. Lets be optimistic.. > > Hmm, well, my guess is that the 604 is just a newer version of the drive > you have. I haven't heard any complaints from any 604 owners about read > toc problems, so my guess is that it's a SCSI-2 drive. My guess too. I found a couple of identical changers on a system at work. I asked the 'owner' to find out what firmware revs they have. If it is different/newer or maybe the DMR-604X of the quirk entry above I'll try to borrow it's firmware rom for a quick trip to the prom programmer. > > > > 'Most any' appears to be the right term for it ;) I'll experiment a bit > > > > more. Just go a solid system lockup by running a 'dd if=/dev/rcd0a' and > > > > a 'mount /dev/cd1a ...' at the same time. Only ping still works. Hmm. > > > > More testing to do I guess > > > > > > Hmm, interesting. What happens if you just try the DD? Can you break into > > > the debugger when the machine locks up? > > > > I made a new kernel with the debugger in. I'll have it run overnight to see > > if it re-occurs. In the meantime there was also a spontaneous reboot. No > > panic as far as I can see. I'll try to reproduce.. Just the DD seems > > to work just fine. > > Hmm, sounds strange indeed. In the meantime I ran the test again. No machine lockup this time. But already twice a solid lockup of the drive.. It goes completely comatose, not even a SCSI reset from a FreeBSD reboot awakens it. The only thing what works is a whack over the head with the powerswitch. This definitely is a brilliant piece of firmware I have. Console messages: (cd0:isp0:0:5:0): cddone: got error 0x6 back (cd4:isp0:0:5:4): cddone: got error 0x6 back (cd3:isp0:0:5:3): cddone: got error 0x6 back (cd1:isp0:0:5:1): cddone: got error 0x6 back Sidetracking a bit: man xpt mentions /dev/xpt. /dev/MAKEDEV does not have it though. Is it supposed to be a manual operation with mknod? Or is my /dev/MAKEDEV out of date? Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 15: 8:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B8E615FDF for ; Fri, 9 Apr 1999 14:57:11 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id PAA18063; Fri, 9 Apr 1999 15:54:46 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904092154.PAA18063@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904091815.UAA13726@yedi.iaf.nl> from Wilko Bulte at "Apr 9, 1999 8:15:35 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Fri, 9 Apr 1999 15:54:46 -0600 (MDT) Cc: freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte wrote... > As Kenneth D. Merry wrote ... > > Wilko Bulte wrote... > > > As Kenneth D. Merry wrote ... > > > > Wilko Bulte wrote... > > > > > As Kenneth D. Merry wrote ... > > > > > > Wilko Bulte wrote... > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > Wilko Bulte wrote... > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > Wilko Bulte wrote... > > > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > > > Wilko Bulte wrote... > > > > > panic as far as I can see. I'll try to reproduce.. Just the DD seems > > > > > to work just fine. > > > > > > > > Hmm, sounds strange indeed. > > > > > > In the meantime I ran the test again. No machine lockup this time. But > > > already twice a solid lockup of the drive.. It goes completely comatose, > > > not even a SCSI reset from a FreeBSD reboot awakens it. The only thing > > > what works is a whack over the head with the powerswitch. This definitely > > > is a brilliant piece of firmware I have. > > > > > > Console messages: > > > > > > (cd0:isp0:0:5:0): cddone: got error 0x6 back > > > (cd4:isp0:0:5:4): cddone: got error 0x6 back > > > (cd3:isp0:0:5:3): cddone: got error 0x6 back > > > (cd1:isp0:0:5:1): cddone: got error 0x6 back > > > > Hmm, looks somewhat familiar. Error 6 is ENXIO. If you boot with -v you > > might get more info. You can probably fix it by increasing the minimum > > and possibly the maximum changer timeouts. The defaults are 2 seconds and > > 10 seconds, respectively. > > The boot messages are OK, so is the probe. I've diagnosed it as > follows: > > - probes ok > - works ok for some time (running my test script) > - locks up it's own firmware > - kernel throws away the devices associated with the changer, > thus cddone 0x6 and 'no such device' errors for 'dd' Right, sounds familiar. > > Try increasing the minimum to 8 seconds and the maximum to 20: > > > > options "CHANGER_MIN_BUSY_SECONDS=8" > > options "CHANGER_MAX_BUSY_SECONDS=20" > > > > I had similar problems with Lars Fredriksen's Nakamichi changer that I > > borrowed to do the changer functionality in the CD driver. The default > > timeouts may be a little too low, but I think they work okay for that sort > > of changer at least. > > In this case it is not the changer. The lockup that happened with me > present was during reads by two parallel operating 'dd's like: > > while : > > dd > sleep 5 > dd > done > > So, the drive is seeking quite a bit (you can hear that, and observe it > as the case is still off). My guess: the firmware looses track of the > parallel I/Os going on. I'm retesting with a single 'dd' in the loop. I'm confused here. When you say "dd " above, do you mean that each dd is going to a *separate* CD on the changer, or are you just reading with two different processes from the same CD? (so the changer isn't switching CDs) With the Nakamichi changer I had, I found that if it got pounded too often to switch back and forth (i.e. with I/O going to a number of different LUNs at the same time) it would eventually get confused and stop responding on various LUNs. If you increase the minimum timeout, it'll prevent that from happening. > > The BDR functionality in the kernel doesn't work quite right yet, so if you > > try something just try the bus reset. > > > > > Sidetracking a bit: man xpt mentions /dev/xpt. /dev/MAKEDEV does not > > > have it though. Is it supposed to be a manual operation with mknod? > > > Or is my /dev/MAKEDEV out of date? > > > > The xpt(4) man pages mentions /dev/xpt0. If your MAKEDEV doesn't have it, > > it's out of date: > > > > {roadwarrior:/usr/home/ken/perforce/cam/etc/etc.i386:26:0} grep xpt MAKEDEV > > > > sh MAKEDEV pass4 xpt2 # cdev, CAM > > xpt*) > > name=xpt > > units=`expr $i : 'xpt\(.*\)'` > > > > > > That's from -current as of about 3am MDT today. All you need to do is grab > > a new copy of MAKEDEV, and then: > > Right. It proved to be in my -current source tree alright. Apparantly it > did not get installed by the 'installworld' for some reason ?? My testbox > started off as a 2.2.6 CD install. Ah well, it is there now. camcontrol > is happy. > > If we ever meet, I definitely owe you a couple of beers ;-) Coke (the kind that comes in red cans) would be preferrable. :) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 15:37:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from nac.net (tempest.nac.net [209.123.109.39]) by hub.freebsd.org (Postfix) with SMTP id 2D34214BEE for ; Fri, 9 Apr 1999 15:37:11 -0700 (PDT) (envelope-from alex@nac.net) Received: (qmail 5583 invoked by uid 0); 9 Apr 1999 22:34:50 -0000 Received: from iago.nac.net (alex@209.123.109.26) by tempest.nac.net with SMTP; 9 Apr 1999 22:34:50 -0000 Date: Fri, 9 Apr 1999 18:34:36 -0400 (EDT) From: alex@nac.net To: Wilko Bulte Cc: "Kenneth D. Merry" , freebsd-scsi@freebsd.org Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904091954.VAA15091@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warning: off-topic. Looking at this causes me to shift into migraine mode: On Fri, 9 Apr 1999, Wilko Bulte wrote: > As Kenneth D. Merry wrote ... > > Wilko Bulte wrote... > > > As Kenneth D. Merry wrote ... > > > > Wilko Bulte wrote... > > > > > As Kenneth D. Merry wrote ... > > > > > > Wilko Bulte wrote... > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > Wilko Bulte wrote... > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > Wilko Bulte wrote... > > > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > > > Wilko Bulte wrote... -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex@nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP; we have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 17:37:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by hub.freebsd.org (Postfix) with ESMTP id B93A814BEA for ; Fri, 9 Apr 1999 17:37:22 -0700 (PDT) (envelope-from gemorga2@vt.edu) Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id UAA23454 for ; Fri, 9 Apr 1999 20:35:10 -0400 (EDT) Received: from gemorga2.campus.vt.edu (gemorga2.campus.vt.edu [198.82.100.219]) by sable.cc.vt.edu (8.8.8/8.8.8) with SMTP id UAA32340 for ; Fri, 9 Apr 1999 20:35:09 -0400 (EDT) Message-Id: <199904100035.UAA32340@sable.cc.vt.edu> From: "George Morgan" To: freebsd-scsi@freebsd.org Date: Fri, 9 Apr 1999 20:35:09 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: SCSI PCMCIA/PCCARD Reader... X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Continuing the thread that I started earlier this week... What is the best SCSI PC-CARD reader? I would like to try to avoid the kits that use their own "proprietary???" controller and use one that attaches to my scsi bus.. Is this a good idea? Do these devices cause significant trouble in BSD, Windows, etc??? Thank you for your time. George Morgan Virginia Tech Electrical Engineering Class of 2000! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 17:47:28 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from GW.sim.net.ua (GW.sumy.net [62.244.20.220]) by hub.freebsd.org (Postfix) with ESMTP id DA74714DD5 for ; Fri, 9 Apr 1999 17:46:58 -0700 (PDT) (envelope-from solik@solik.net) Received: from ndesign.com.ua (NDESIGN.sim.net.ua [62.244.20.241]) by GW.sim.net.ua (8.9.3/8.9.3) with ESMTP id DAA05038 for ; Sat, 10 Apr 1999 03:43:59 +0300 (EEST) Received: from solik.net (210-754.sim.net.ua [62.244.19.132] (may be forged)) by ndesign.com.ua (Sendmail 8.who.cares/1) with ESMTP id DAA09027 for ; Sat, 10 Apr 1999 03:42:37 +0300 (EEST) Message-ID: <370E9ED6.2A9E04C9@solik.net> Date: Sat, 10 Apr 1999 03:44:06 +0300 From: Sergey Solyanik Organization: NetDeeper X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: Initio INIC-941 SCSI controller Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! Can anybody help me with INIC-941 driver sources? And some success stories would be very appreciated. Slante! -- SSV3-RIPE Tired of this second-hand fun, http://www.solik.net/ I'm heading for the absolute one. $Id: .signature,v 1.2 1998/10/19 03:09:20 solik Exp $ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 18:48: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 9245515323 for ; Fri, 9 Apr 1999 18:47:59 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id TAA19784; Fri, 9 Apr 1999 19:45:32 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904100145.TAA19784@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904091954.VAA15091@yedi.iaf.nl> from Wilko Bulte at "Apr 9, 1999 9:54:43 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Fri, 9 Apr 1999 19:45:32 -0600 (MDT) Cc: freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte wrote... > As Kenneth D. Merry wrote ... > > Wilko Bulte wrote... > > > As Kenneth D. Merry wrote ... > > > > Wilko Bulte wrote... > > > > > As Kenneth D. Merry wrote ... > > > > > > Wilko Bulte wrote... > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > Wilko Bulte wrote... > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > Wilko Bulte wrote... > > > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > > > Wilko Bulte wrote... > > > > > > > 'Most any' appears to be the right term for it ;) I'll experiment a bit > > > > > > > more. Just go a solid system lockup by running a 'dd if=/dev/rcd0a' and > > > > > > > a 'mount /dev/cd1a ...' at the same time. Only ping still works. Hmm. > > > > > > > More testing to do I guess > > > > > > > > > > > > Hmm, interesting. What happens if you just try the DD? Can you break into > > > > > > the debugger when the machine locks up? > > > > > > > > > > I made a new kernel with the debugger in. I'll have it run overnight to see > > > > > if it re-occurs. In the meantime there was also a spontaneous reboot. No > > > > > panic as far as I can see. I'll try to reproduce.. Just the DD seems > > > > > to work just fine. > > > > > > > > Hmm, sounds strange indeed. > > > > > > In the meantime I ran the test again. No machine lockup this time. But > > > already twice a solid lockup of the drive.. It goes completely comatose, > > > not even a SCSI reset from a FreeBSD reboot awakens it. The only thing > > > what works is a whack over the head with the powerswitch. This definitely > > > is a brilliant piece of firmware I have. > > I can reproduce a lockup now. But this one looks like a FreeBSD bug to me: > > - do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k & > - do a 'mount -r -t cd9660 /dev/cd2a /mnt' Okay, so you're doing I/O to two devices at once. I would still like to see what happens if you increase the minimum timeout. > Result: bang! Console lockups, no network logins anymore. I can get into ddb > fortunately and can force a dump. But I'm not an expert on gdb -k. A quick > try produced: > > dump 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 > 8 7 6 5 4 3 2 1 > --- > #0 0xc015cb43 in boot () > (kgdb) bt > #0 0xc015cb43 in boot () > #1 0xc015cde1 in panic () > #2 0xc012ab29 in db_panic () > #3 0xc012aac9 in db_command () > #4 0xc012ab8e in db_command_loop () > #5 0xc012cf0f in db_trap () > #6 0xc021e5ce in kdb_trap () > #7 0xc022aee4 in trap () > #8 0xc021e7f3 in Debugger () > #9 0xc0219e60 in scgetc () > #10 0xc0214be0 in sckbdevent () > #11 0xc02115bb in atkbd_intr () > #12 0xc022ee68 in atkbd_isa_intr () > #13 0xc0127ad3 in cdrunchangerqueue () > #14 0xc0127cbe in cdgetccb () > #15 0xc01291f0 in cdprevent () > #16 0xc0127633 in cdopen () > #17 0xc018bbcb in spec_open () > #18 0xc018b9b5 in spec_vnoperate () > #19 0xc0201f8d in ufs_vnoperatespec () > #20 0xc01860da in vn_open () > #21 0xc0182b35 in open () > #22 0xc022b71f in syscall () > #23 0xc021ef1c in Xint0x80_syscall () > #24 0x8048361 in ?? () > #25 0x80480e9 in ?? () > (kgdb) > > If you want the dump & kernel to go to an ftp area somewhere plse let > me know. It is approx 6Mb in total (gzipped). > > If you want me to whisper magical words to gdb please tell me > which words. It would be nice if you could give me: - a stack trace using a kernel with debugging symbols - a listing of the location in cdrunchangerqueue() where you broke into the debugger. (just type 'list' in gdb while you're at the stack frame that's in cdrunchangerqueue()) In a way, this smells like some sort of infinite loop in the changer scheduling code. I thought I fixed the infinite loop problem a long time ago, although I suppose I may have missed a case or two. If I can figure out where the loop is happening, I may be able to fix the problem. Once you show me where the thing is looping, I may ask as well for the values of some variables that control the loop. [ ... ] > A quick look into xmcd's vu_pion.h learned: > > /* Pioneer vendor-unique commands */ > #define OP_VP_EJECT 0xc0 /* Pioneer magazine eject */ > #define OP_VP_RDTOC 0xc1 /* Pioneer read TOC */ > > If I replace the standard READ TOC (0x43) by 0xC1 I get a driver that > seems to work just fine. No errors anymore with a mount. Obviously my > 'normal' Toshiba CD now complains. > > So: it seems some type of quirk mechanism is needed. Looking at xmcd > again I find a disturbing number of vendor-unique support files for > non-SCSI2 drives: > > ! 0 SCSI-2 standard > ! 1 Chinon vendor-unique > ! 2 Hitachi vendor-unique > ! 3 NEC vendor-unique > ! 4 Pioneer vendor-unique > ! 5 Sony vendor-unique > ! 6 Toshiba vendor-unique > ! 7 Panasonic/Matsushita vendor-unique > > I don't think it is wise to clutter the scsi_cd driver with all this junk. > There is more vendor unique stuff around than just the READ TOC (like, > surprise surprise, the play audio commands etc) Well, I think it may be possible to put some quirk entries in for various commands, but perhaps we can just restrict it to devices we can test on. Things will be somewhat easier if the CDB format is the same, but the opcodes are different. That's rarely the case, though. The solution to the problem will depend on the scope of the device's vendor-uniqueness. If it's just the READ TOC call that's different, and only the opcode is different from SCSI-2, a quirk entry and an if statement in cdreadtoc() will be sufficient. If this drive has a large number of vendor-unique commands, I'll probably create a scsi_cd_pioneer.c with the vendor-specific commands in it, and then have a table of functions in the softc or something. The function table would be loaded in cdregister() based on a quirk entry. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 19:51:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by hub.freebsd.org (Postfix) with ESMTP id 9A4A514F8B for ; Fri, 9 Apr 1999 19:51:22 -0700 (PDT) (envelope-from gemorga2@vt.edu) Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id WAA01308 for ; Fri, 9 Apr 1999 22:49:09 -0400 (EDT) Received: from gemorga2.campus.vt.edu (gemorga2.campus.vt.edu [198.82.100.219]) by sable.cc.vt.edu (8.8.8/8.8.8) with SMTP id WAA05474 for ; Fri, 9 Apr 1999 22:49:09 -0400 (EDT) Message-Id: <199904100249.WAA05474@sable.cc.vt.edu> From: "George Morgan" To: freebsd-scsi@freebsd.org Date: Fri, 9 Apr 1999 22:49:09 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Advansys PCI SCSI Adapter.. X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a friend with an Advansys (IOMEGA Jaz Jet) PCI narrow scsi controller. Which device is this? (he is building a custom kernel, 3.1R) I searched the mailing list archives but did not find this info. Sorry that this is probably a duplicated question. Thanks George Morgan Virginia Tech Electrical Engineering Class of 2000! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 22: 7:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id C4BAF152F2 for ; Fri, 9 Apr 1999 22:07:40 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id XAA20454; Fri, 9 Apr 1999 23:05:15 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904100505.XAA20454@panzer.plutotech.com> Subject: Re: Advansys PCI SCSI Adapter.. In-Reply-To: <199904100249.WAA05474@sable.cc.vt.edu> from George Morgan at "Apr 9, 1999 10:49: 9 pm" To: gemorga2@vt.edu (George Morgan) Date: Fri, 9 Apr 1999 23:05:15 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org George Morgan wrote... > I have a friend with an Advansys (IOMEGA Jaz Jet) PCI narrow scsi > controller. Which device is this? (he is building a custom kernel, > 3.1R) > > I searched the mailing list archives but did not find this info. Sorry > that this is probably a duplicated question. There are several ways you could figure this out: - Look in the man pages. man -k is your friend: # man -k advansys adv(4) - Advansys ISA/VL/EISA/PCI 8bit SCSI Host adapter driver adw(4) - Advansys PCI 16bit SCSI Host adapter driver - Boot a GENERIC kernel, and see what controller it recognizes. - Look in LINT for the various SCSI drivers. But, the answer to your question is that it most likely needs the adv driver. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 9 22:15:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 795BC151D3 for ; Fri, 9 Apr 1999 22:15:14 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id XAA20520; Fri, 9 Apr 1999 23:12:36 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904100512.XAA20520@panzer.plutotech.com> Subject: Re: Initio INIC-941 SCSI controller In-Reply-To: <370E9ED6.2A9E04C9@solik.net> from Sergey Solyanik at "Apr 10, 1999 3:44: 6 am" To: solik@solik.net (Sergey Solyanik) Date: Fri, 9 Apr 1999 23:12:36 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sergey Solyanik wrote... > Hello! > > Can anybody help me with INIC-941 driver sources? And some success > stories would be very appreciated. Do you mean you're working on a driver, or do you mean that you want a driver? There's no FreeBSD driver for that chip that I know of, for either the old or new SCSI layers. If you're working on a driver for that chip, I'm sure Justin will be glad to answer questions about the interface between the CAM transport layer and SCSI controller drivers. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 10 2: 7:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 4470E14CFA for ; Sat, 10 Apr 1999 02:07:39 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id LAA21812; Sat, 10 Apr 1999 11:02:38 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id AAA16594; Sat, 10 Apr 1999 00:19:07 +0200 (CEST) From: Wilko Bulte Message-Id: <199904092219.AAA16594@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904092154.PAA18063@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 9, 1999 3:54:46 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Sat, 10 Apr 1999 00:19:07 +0200 (CEST) Cc: freebsd-scsi@freebsd.org X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > Wilko Bulte wrote... > > As Kenneth D. Merry wrote ... > > > Wilko Bulte wrote... > > > > As Kenneth D. Merry wrote ... > > > > > Wilko Bulte wrote... > > > > > > As Kenneth D. Merry wrote ... > > > > > > > Wilko Bulte wrote... > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > Wilko Bulte wrote... > > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > > Wilko Bulte wrote... > > > > > > > > > > > > As Kenneth D. Merry wrote ... > > > > > > > > > > > > > Wilko Bulte wrote... .... > > The boot messages are OK, so is the probe. I've diagnosed it as > > follows: > > > > - probes ok > > - works ok for some time (running my test script) > > - locks up it's own firmware > > - kernel throws away the devices associated with the changer, > > thus cddone 0x6 and 'no such device' errors for 'dd' > > Right, sounds familiar. > > > > Try increasing the minimum to 8 seconds and the maximum to 20: > > > > > > options "CHANGER_MIN_BUSY_SECONDS=8" > > > options "CHANGER_MAX_BUSY_SECONDS=20" > > > > > > I had similar problems with Lars Fredriksen's Nakamichi changer that I > > > borrowed to do the changer functionality in the CD driver. The default > > > timeouts may be a little too low, but I think they work okay for that sort > > > of changer at least. > > > > In this case it is not the changer. The lockup that happened with me > > present was during reads by two parallel operating 'dd's like: > > > > while : > > > > dd > > sleep 5 > > dd > > done > > > > So, the drive is seeking quite a bit (you can hear that, and observe it > > as the case is still off). My guess: the firmware looses track of the > > parallel I/Os going on. I'm retesting with a single 'dd' in the loop. > > I'm confused here. When you say "dd " above, do you mean that each dd > is going to a *separate* CD on the changer, or are you just reading with > two different processes from the same CD? (so the changer isn't switching > CDs) The two processes are reading from the same CD, so the changer is not doing anything. The drive's head is seeking a bit and in the end it (sometimes, not always takes the same time) locks up. > With the Nakamichi changer I had, I found that if it got pounded too often > to switch back and forth (i.e. with I/O going to a number of different LUNs > at the same time) it would eventually get confused and stop responding on > various LUNs. Another crappy firmware design apparantly. > If you increase the minimum timeout, it'll prevent that from happening. I can try that later/this weekend. Overnight I plan to have it do single stream reads using tar, then changing to the next cd, than single stream read etc. All in an endless loop. > > Right. It proved to be in my -current source tree alright. Apparantly it > > did not get installed by the 'installworld' for some reason ?? My testbox > > started off as a 2.2.6 CD install. Ah well, it is there now. camcontrol > > is happy. > > > > If we ever meet, I definitely owe you a couple of beers ;-) > > Coke (the kind that comes in red cans) would be preferrable. :) The true coke (in my book). Fine with me. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 Sat Apr 10 2: 9:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ACC.sim.net.ua (ACC.sim.net.ua [62.244.20.221]) by hub.freebsd.org (Postfix) with ESMTP id E4F6F14CFA for ; Sat, 10 Apr 1999 02:09:10 -0700 (PDT) (envelope-from solik@solik.net) Received: from solik.net (NDESIGN.sim.net.ua [62.244.20.241]) by ACC.sim.net.ua (8.9.3/8.8.4) with ESMTP id MAA16079; Sat, 10 Apr 1999 12:06:29 +0300 (EEST) Message-ID: <370F1506.E5338080@solik.net> Date: Sat, 10 Apr 1999 12:08:22 +0300 From: Sergey Solyanik Organization: NetDeeper X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: "Kenneth D. Merry" , freebsd-scsi@FreeBSD.ORG Subject: Re: Initio INIC-941 SCSI controller References: <199904100512.XAA20520@panzer.plutotech.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" wrote: > Do you mean you're working on a driver, or do you mean that you want a > driver? I need a sources for dirver. I have driver, but only in object code. I successfully link it with 2.2.8-RELEASE kernel and it worked ok. But I have a Matsushita CD-R drive, and I can't manage the kernel to detect it as worm device. I've add detection strings into scsiconf.h, but have no success. i think the problem in driver... May be. ;) > There's no FreeBSD driver for that chip that I know of, for either the old > or new SCSI layers. If you want, I can mail it. > If you're working on a driver for that chip, I'm sure Justin will be glad I'm not a great freebsd driver developer, I have a little expirience... May be I'm wrong in thoughts about driver and worm device... Thank you! ps: please, forgive me my bad English. -- SSV3-RIPE Tired of this second-hand fun, http://www.solik.net/ I'm heading for the absolute one. $Id: .signature,v 1.2 1998/10/19 03:09:20 solik Exp $ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 10 10:51:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 15D56150B9 for ; Sat, 10 Apr 1999 10:51:39 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id LAA27237; Sat, 10 Apr 1999 11:47:21 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904101747.LAA27237@panzer.plutotech.com> Subject: Re: Initio INIC-941 SCSI controller In-Reply-To: <370F1506.E5338080@solik.net> from Sergey Solyanik at "Apr 10, 1999 12: 8:22 pm" To: solik@solik.net (Sergey Solyanik) Date: Sat, 10 Apr 1999 11:47:20 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sergey Solyanik wrote... > "Kenneth D. Merry" wrote: > > > Do you mean you're working on a driver, or do you mean that you want a > > driver? > > I need a sources for dirver. I have driver, but only in object code. I > successfully link it with 2.2.8-RELEASE kernel and it worked ok. But I > have a Matsushita CD-R drive, and I can't manage the kernel to detect it > as worm device. I've add detection strings into scsiconf.h, but have no > success. > i think the problem in driver... May be. ;) Well, maybe, but I doubt it. You can't use the worm driver in the old SCSI layer with your CD-R drive. You need to get cdrecord out of the ports/packages tree. > > There's no FreeBSD driver for that chip that I know of, for either the old > > or new SCSI layers. > > If you want, I can mail it. Actually, I found some interesting stuff on the Initio web site. (www.initio.com) I found FreeBSD/NetBSD source for a driver for their cards. Of course that means it'll only work for the old SCSI layer. But, it also means that if you're using 2.2.8, you can recompile the driver yourself. Here it is: http://www.initio.com/source.zip I never knew they had a FreeBSD driver. Of course I only heard of the existence of the company yesterday. As far as the copyright on the driver goes, I'm not sure it would be acceptable for the FreeBSD tree, if the driver were ported to CAM. (someone who knows more about copyright law can look at it and comment) > > If you're working on a driver for that chip, I'm sure Justin will be glad > > I'm not a great freebsd driver developer, I have a little expirience... > May be I'm wrong in thoughts about driver and worm device... I think so. The old worm driver only supported two types of worm devices: HP/Philips and some Plasmon drives. If your drive isn't one of those two types (and it isn't), you'll need to use cdrecord or some other userland CD burning program to talk to the drive. In 3.x, with the new CAM SCSI layer, we've pretty much abandoned the concept of a WORM driver for now. All support for CD-R, CD-RW, etc., burning is provided through cdrecord. The CD driver in 3.x will attach to to any WORM or CD drive, though, so you can use it to read CDs. Writing has to go via cdrecord. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 10 13:38:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id A522A15324 for ; Sat, 10 Apr 1999 13:38:05 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id WAA12797; Sat, 10 Apr 1999 22:32:44 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id WAA03553; Sat, 10 Apr 1999 22:34:41 +0200 (CEST) From: Wilko Bulte Message-Id: <199904102034.WAA03553@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904100145.TAA19784@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 9, 1999 7:45:32 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Sat, 10 Apr 1999 22:34:41 +0200 (CEST) Cc: freebsd-scsi@freebsd.org X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > - do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k & > > - do a 'mount -r -t cd9660 /dev/cd2a /mnt' The above sequence of commands will reproduce the lockup. Doing: - do a 'mount -r -t cd9660 /dev/cd2a /mnt' - do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k & will work and will just drive the changer nuts with swapping discs. I sort of expected that the mount would lock the cd into the drive, changer or not. > > If you want me to whisper magical words to gdb please tell me > > which words. > > It would be nice if you could give me: > > - a stack trace using a kernel with debugging symbols #0 boot (howto=256) at ../../kern/kern_shutdown.c:287 #1 0xc0147ad9 in panic (fmt=0xc02182fc "from debugger") at ../../kern/kern_shutdown.c:448 #2 0xc0128b45 in db_panic (addr=-1071661537, have_addr=0, count=-1, modif=0xc36048ac "") at ../../ddb/db_command.c:432 #3 0xc0128ae5 in db_command (last_cmdp=0xc024eac4, cmd_table=0xc024e924, aux_cmd_tablep=0xc0260988) at ../../ddb/db_command.c:332 #4 0xc0128baa in db_command_loop () at ../../ddb/db_command.c:454 #5 0xc012af2b in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71 #6 0xc01fbbfa in kdb_trap (type=3, code=0, regs=0xc360499c) at ../../i386/i386/db_interface.c:157 #7 0xc02088f8 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1071714996, tf_esi = 134, tf_ebp = -1017099808, tf_isp = -1017099836, tf_ebx = 0, tf_edx = -1071355968, tf_ecx = -1072984320, tf_eax = 38, tf_trapno = 3, tf_err = 0, tf_eip = -1071661537, tf_cs = 8, tf_eflags = 582, tf_esp = -1071355984, tf_ss = -1071367167}) at ../../i386/i386/trap.c:549 #8 0xc01fbe1f in Debugger (msg=0xc0243c01 "manual escape to debugger") at ../../i386/i386/db_interface.c:317 #9 0xc01f74bc in scgetc (kbd=0xc0271ee4, flags=2) at ../../dev/syscons/syscons.c:3714 #10 0xc01f223c in sckbdevent (thiskbd=0xc0271ee4, event=0, arg=0x0) at ../../dev/syscons/syscons.c:816 #11 0xc01eec17 in atkbd_intr (kbd=0xc0271ee4, arg=0x0) at ../../dev/kbd/atkbd.c:561 #12 0xc020a4f0 in atkbd_isa_intr (unit=0) at ../../i386/isa/atkbd_isa.c:84 #13 0xc0125b17 in cdrunchangerqueue (arg=0xc0780c00) at ../../cam/scsi/scsi_cd.c:1225 #14 0xc012720c in cdprevent (periph=0xc0780c00, action=1) at ../../cam/scsi/scsi_cd.c:2517 #15 0xc01256a7 in cdopen (dev=1568, flags=1, fmt=24576, p=0xc336b5a0) at ../../cam/scsi/scsi_cd.c:915 #16 0xc0175e07 in spec_open (ap=0xc3604e2c) at ../../miscfs/specfs/spec_vnops.c:235 #17 0xc0175bf1 in spec_vnoperate (ap=0xc3604e2c) at ../../miscfs/specfs/spec_vnops.c:129 #18 0xc01df5b9 in ufs_vnoperatespec (ap=0xc3604e2c) at ../../ufs/ufs/ufs_vnops.c:2327 #19 0xc017030e in vn_open (ndp=0xc3604f00, fmode=1, cmode=3300) at vnode_if.h:163 #20 0xc016cd69 in open (p=0xc336b5a0, uap=0xc3604f94) at ../../kern/vfs_syscalls.c:972 #21 0xc0209133 in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = -1077944881, tf_ebp = -1077945340, tf_isp = -1017098268, tf_ebx = -1077945100, tf_edx = -1077944891, tf_ecx = 3, tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = 134517904, tf_cs = 31, tf_eflags = 662, tf_esp = -1077946172, tf_ss = 47}) at ../../i386/i386/trap.c:1101 #22 0xc01fc54c in Xint0x80_syscall () #23 0x8048361 in ?? () #24 0x80480e9 in ?? () > - a listing of the location in cdrunchangerqueue() where you broke into > the debugger. (just type 'list' in gdb while you're at the stack frame > that's in cdrunchangerqueue()) Like this? (kgdb) frame 13 #13 0xc0125b17 in cdrunchangerqueue (arg=0xc0780c00) at ../../cam/scsi/scsi_cd.c:1225 1225 } (kgdb) list 1220 * switch time. 1221 */ 1222 changer->flags |= CHANGER_NEED_TIMEOUT; 1223 1224 splx(s); 1225 } 1226 1227 static void 1228 cdchangerschedule(struct cd_softc *softc) 1229 { (kgdb) > In a way, this smells like some sort of infinite loop in the changer > scheduling code. I thought I fixed the infinite loop problem a long time > ago, although I suppose I may have missed a case or two. > > If I can figure out where the loop is happening, I may be able to fix the > problem. Once you show me where the thing is looping, I may ask as well > for the values of some variables that control the loop. OK. > > ! 2 Hitachi vendor-unique > > ! 3 NEC vendor-unique > > ! 4 Pioneer vendor-unique > > ! 5 Sony vendor-unique > > ! 6 Toshiba vendor-unique > > ! 7 Panasonic/Matsushita vendor-unique > > > > I don't think it is wise to clutter the scsi_cd driver with all this junk. > > There is more vendor unique stuff around than just the READ TOC (like, > > surprise surprise, the play audio commands etc) > > Well, I think it may be possible to put some quirk entries in for various > commands, but perhaps we can just restrict it to devices we can test on. > > Things will be somewhat easier if the CDB format is the same, but the > opcodes are different. That's rarely the case, though. xmcd took the approach of different VU support files for the non-standard commands. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 Sat Apr 10 16:30: 3 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (castles542.castles.com [208.214.165.106]) by hub.freebsd.org (Postfix) with ESMTP id D5E5214E39 for ; Sat, 10 Apr 1999 16:30:00 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id QAA00914; Sat, 10 Apr 1999 16:24:04 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199904102324.QAA00914@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Kenneth D. Merry" Cc: solik@solik.net (Sergey Solyanik), freebsd-scsi@FreeBSD.ORG Subject: Re: Initio INIC-941 SCSI controller In-reply-to: Your message of "Fri, 09 Apr 1999 23:12:36 MDT." <199904100512.XAA20520@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Apr 1999 16:24:04 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Sergey Solyanik wrote... > > Hello! > > > > Can anybody help me with INIC-941 driver sources? And some success > > stories would be very appreciated. > > Do you mean you're working on a driver, or do you mean that you want a > driver? > > There's no FreeBSD driver for that chip that I know of, for either the old > or new SCSI layers. I don't know if this has been mentioned yet, but they do actually make the source for their old-SCSI family driver (for FreeBSD) available. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 10 19:19:46 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CE9F153FC for ; Sat, 10 Apr 1999 19:18:58 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id UAA34825; Sat, 10 Apr 1999 20:16:28 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904110216.UAA34825@panzer.plutotech.com> Subject: Re: Strange SCSI panic - devstat_end_transaction In-Reply-To: <370DAC97.2B48323E@tdx.co.uk> from Karl Pielorz at "Apr 9, 1999 8:30:31 am" To: kpielorz@tdx.co.uk (Karl Pielorz) Date: Sat, 10 Apr 1999 20:16:28 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Karl Pielorz wrote... > Hi All, > > My box did this last night, and I was wondering if anyone could shed any light > on it? - Unfortunately the machine was locked solid, and didn't manage to > dump... > > I was newfs'ing a Vinum volume at the time - da2 is dedicated solely to /usr2, > and is on a separate controller to all the drives used for Vinum - so I don't > think Vinum is related... > > /usr2 has user home directories on it, a lightly used MySQL database - and the > directories for the machines lightly used Apache server (i.e. it was probably > being used at the time, but it's never thrashed). > > The machine is a dual P-Pro200, w/256Mb RAM running on a SuperMicro > P6DNF/440FX motherboard. System is running -current as of 22nd March. > > DA2 is: > > da2 at ahc0 bus 0 target 5 lun 0 > da2: Fixed Direct Access SCSI-2 device > da2: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled > da2: 1021MB (2091144 512 byte sectors: 64H 32S/T 1021C) > > And is running softupdates... The volume got 'mildly' trashed after this - > fsck found ~2 errors but does seem to have recovered it without incident. > > I've quickly checked termination etc. for that controller - and it all appears > fine... The contoller (ahc0) is: > > ahc0: rev 0x01 int a irq 17 on pci0.18.0 > ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs > > > Any info / rough ideas would be greatly appreciated... The devstat warning is just a symptom of the problem, and not the real cause of the problem. It basically indicates that one of a couple of things have happened: - a transaction has been completed twice - the buffer queue has been corrupted somehow (Justin said that duplicate buffers might do it) and we ended up getting more transaction completions than transaction starts. The devstat message is informational, and won't cause any system problems, but it does indicate some other problem. > devstat_end_transaction: HELP!! busy_count for da2 is < 0 (-1)! > panic: vwakeup: neg numoutput > mp_lock = 01000001; cpuid = 1; lapic.id = 01000000 > boot() called on cpu#1 I'm not sure what the problem is, and I haven't seen this one recently. Have you ever had the problem before? Can you reproduce it? i.e., if you newfs the Vinum volume again, does it happen again? Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 10 21: 4:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from en26.l1.net (froggy.anchorage.ptialaska.net [208.151.119.238]) by hub.freebsd.org (Postfix) with ESMTP id 810E514BFC; Sat, 10 Apr 1999 21:04:43 -0700 (PDT) (envelope-from groggy@iname.com) Received: from en26.l1.net (localhost [127.0.0.1]) by en26.l1.net (8.8.8/8.8.8) with SMTP id UAA00366; Fri, 9 Apr 1999 20:02:51 -0800 (AKDT) (envelope-from groggy@iname.com) Date: Fri, 9 Apr 1999 20:02:51 -0800 (AKDT) From: Steve Howe X-Sender: abc@en26.l1.net To: freebsd-scsi@freebsd.org Cc: freebsd-questions Subject: board not responding 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 FBSD 2.2.8 any advice on this: vga0 rev1 int a irq 11 on pci0:9:0 ahc0 rev 1 int a irq 10 on pci:0:10:0 ahc0: aic7800 Wide Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "IBM DDRS-34560D DC1B" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4357MB (8925000 512 byte sectors) ahc0: board is not responding (ahc0:1:0): SCB 0x0 - timedout in datain phase, SCSISIGI == 0x44 SEQADDR = 0x129 SCSISEQ = 0x12 SSTAT0 = 0x0 SSTAT1 - 0x2 (ahc0:1:0): abort message in message buffer ahc0: board is not responding cmd fail (ahc0:1:0): SCB 0x1 - timedout while recovery in progress (ahc0:1:0): "unknown unknown ????" type 13 fixed SCSI 0 uk0(ahc0:1:0): Unknown ahc0:board is not responding cmd fail the block above then repeats with SCB 0x2, 0x3, etc. i'm new to SCSI but i am "sure" everything is properly terminated. i moved the 2940UW to different PCI slots, but to no avail. (term) (auto) (term) IBM HD <-> 2940UW <-> Mitsumi CD <-> HP 4020 CD/RW 68 pin 50 pin 50 pin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 10 22: 3:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 1B192153ED; Sat, 10 Apr 1999 22:02:47 -0700 (PDT) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id WAA20266; Sat, 10 Apr 1999 22:00:30 -0700 (PDT) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA196256825; Sat, 10 Apr 1999 22:00:25 -0700 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id WAA06462; Sat, 10 Apr 1999 22:00:24 -0700 (PDT) Message-Id: <199904110500.WAA06462@mina.sr.hp.com> To: Steve Howe Cc: freebsd-scsi@FreeBSD.ORG, freebsd-questions Subject: Re: board not responding Reply-To: Darryl Okahata In-Reply-To: Your message of "Fri, 09 Apr 1999 20:02:51 -0800." Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Sat, 10 Apr 1999 22:00:24 -0700 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Steve Howe wrote: > ahc0 rev 1 int a irq 10 on pci:0:10:0 > ahc0: aic7800 Wide Channel, SCSI Id=7, 16 SCBs > ahc0 waiting for scsi devices to settle > (ahc0:0:0): "IBM DDRS-34560D DC1B" type 0 fixed SCSI 2 > sd0(ahc0:0:0): Direct-Access 4357MB (8925000 512 byte sectors) > ahc0: board is not responding [ ... ] > (term) (auto) (term) > IBM HD <-> 2940UW <-> Mitsumi CD <-> HP 4020 CD/RW > 68 pin 50 pin 50 pin The "IBM DDRS-34560D" is an LVD drive (I've got this exact drive, with the same firmware rev). For this IBM LVD drive, what appears to be the "term" jumper is really the jumper that controls LVD vs SE HVD (single-ended HVD), and "enabling termination" really puts the drive into single-ended mode. You also need an external terminator with this drive (with all LVD drives, actually); there is no built-in termination to enable or disable. As your diagram doesn't show an explicit external terminator with the drive, that might be your problem: no termination. [ In my case, I ordered a "wide SCSI" drive, expecting an SE HVD drive. I received an LVD drive, instead. While this is certainly a "wide SCSI" drive, it was unexpected, as I had to scramble to find some ribbon cable termination. I'm not really complaining, mind you; I'd rather have an LVD drive than a plain SE HVD one, as it'll be much easier for me to upgrade to an LVD controller, should I decide to do so. ] -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 10 23:21:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id C6EE114C0B for ; Sat, 10 Apr 1999 23:21:45 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA31341 for ; Sun, 11 Apr 1999 00:19:30 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA03017 for ; Sun, 11 Apr 1999 00:19:18 -0600 (MDT) Message-Id: <199904110619.AAA03017@harmony.village.org> Subject: Re: Initio INIC-941 SCSI controller To: freebsd-scsi@FreeBSD.ORG In-reply-to: Your message of "Sat, 10 Apr 1999 11:47:20 MDT." <199904101747.LAA27237@panzer.plutotech.com> References: <199904101747.LAA27237@panzer.plutotech.com> Date: Sun, 11 Apr 1999 00:19:18 -0600 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199904101747.LAA27237@panzer.plutotech.com> "Kenneth D. Merry" writes: : I never knew they had a FreeBSD driver. Of course I only heard of the : existence of the company yesterday. As far as the copyright on the driver : goes, I'm not sure it would be acceptable for the FreeBSD tree, if the : driver were ported to CAM. (someone who knows more about copyright law : can look at it and comment) The copyright looks like a fairly standard BSD one and should pose no problems: ** Copyright (c) 1997-98 Initio Corp. All rights reserved. ** ** Redistribution and use in source and binary forms, with or without ** modification, are permitted provided that the following conditions ** are met: ** 1. Redistributions of source code must retain the above copyright ** notice, this list of conditions and the following disclaimer. ** 2. Redistributions in binary form must reproduce the above copyright ** notice, this list of conditions and the following disclaimer in the ** documentation and/or other materials provided with the distribution. ** 3. The name of the author may not be used to endorse or promote products ** derived from this software without specific prior written permission. ** Number 2 is the only thing that I see might be a problem, but many hunks of the kernel have a cluase similar to that. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 11 0:48:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id B2C7714D90 for ; Sun, 11 Apr 1999 00:48:45 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id BAA35839; Sun, 11 Apr 1999 01:46:14 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904110746.BAA35839@panzer.plutotech.com> Subject: Re: Initio INIC-941 SCSI controller In-Reply-To: <199904110619.AAA03017@harmony.village.org> from Warner Losh at "Apr 11, 1999 0:19:18 am" To: imp@harmony.village.org (Warner Losh) Date: Sun, 11 Apr 1999 01:46:14 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote... > In message <199904101747.LAA27237@panzer.plutotech.com> "Kenneth D. Merry" writes: > : I never knew they had a FreeBSD driver. Of course I only heard of the > : existence of the company yesterday. As far as the copyright on the driver > : goes, I'm not sure it would be acceptable for the FreeBSD tree, if the > : driver were ported to CAM. (someone who knows more about copyright law > : can look at it and comment) > > The copyright looks like a fairly standard BSD one and should pose no > problems: > > ** Copyright (c) 1997-98 Initio Corp. All rights reserved. > ** > ** Redistribution and use in source and binary forms, with or without > ** modification, are permitted provided that the following conditions > ** are met: > ** 1. Redistributions of source code must retain the above copyright > ** notice, this list of conditions and the following disclaimer. > ** 2. Redistributions in binary form must reproduce the above copyright > ** notice, this list of conditions and the following disclaimer in the > ** documentation and/or other materials provided with the distribution. > ** 3. The name of the author may not be used to endorse or promote products > ** derived from this software without specific prior written permission. > ** > > > Number 2 is the only thing that I see might be a problem, but many > hunks of the kernel have a cluase similar to that. But that's only one of the files, "I91U.C". Another one, "I91USCSI.C", has the following copyright: /************************************************************************ Copyright (c) 1994-1998 Initio Corp. Initio BSD device driver are copyrighted by Initio Corporation. Your rights of ownership are subject to the limitations and restrictions imposed by the copyright laws. Initio makes no warranty of any kind in regard to this material, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Initio is not liable for any errors contained herein or incidental or consequential damages in connection with furnishing, performance or use of this material. ----------------------------------------------------------------------- And the header file has no copyright. Hmm, look what I found in "I91U.C": #include Ahh, what fun. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 11 0:56:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id 3791F14D98 for ; Sun, 11 Apr 1999 00:56:13 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id IAA21297; Sun, 11 Apr 1999 08:53:50 +0100 (BST) Message-ID: <3710550D.3885BAF4@tdx.co.uk> Date: Sun, 11 Apr 1999 08:53:49 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Strange SCSI panic - devstat_end_transaction References: <199904110216.UAA34825@panzer.plutotech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" wrote: > The devstat warning is just a symptom of the problem, and not the real > cause of the problem. It basically indicates that one of a couple of > things have happened: > > - a transaction has been completed twice > - the buffer queue has been corrupted somehow (Justin said that duplicate > buffers might do it) and we ended up getting more transaction > completions than transaction starts. > > The devstat message is informational, and won't cause any system problems, > but it does indicate some other problem. > > > devstat_end_transaction: HELP!! busy_count for da2 is < 0 (-1)! > > panic: vwakeup: neg numoutput > > mp_lock = 01000001; cpuid = 1; lapic.id = 01000000 > > boot() called on cpu#1 > > I'm not sure what the problem is, and I haven't seen this one recently. > Have you ever had the problem before? No, never... :-( > Can you reproduce it? i.e., if you newfs the Vinum volume again, does it > happen again? No, I've successfully newfs'd the Vinum volume a number of times since... Thanks for the info above!, If it happens again, I'll try again to get a dump, and get back to you... (I guess I'm hoping it doesn't happen again - though it would be nice to figure out what happened :) Regards, Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 11 0:59:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id 171B414D98 for ; Sun, 11 Apr 1999 00:59:29 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id IAA22956; Sun, 11 Apr 1999 08:57:13 +0100 (BST) Message-ID: <371055D7.8BC932F6@tdx.co.uk> Date: Sun, 11 Apr 1999 08:57:11 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Steve Howe Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: board not responding References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Steve Howe wrote: > (ahc0:1:0): SCB 0x1 - timedout while recovery in progress > (ahc0:1:0): "unknown unknown ????" type 13 fixed SCSI 0 > uk0(ahc0:1:0): Unknown > ahc0:board is not responding > cmd fail I've seen the above with a number of 2940's, with different revisions and BIOS versions, it happening in different machines at different times (yes, it is that vague!)... Darryl Okahata has already got back to you with details/suggestions about the drive - go with that first, if it fixes the problem, let me know... (I'm making a collection of details about the 2940 and FreeBSD)... If Darryl's suggestion doesn't work - ditto, let me know - and I'll add your system to the list I'm trying to come up with... :( -Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 11 15:52: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 0AA9616EF7; Sun, 11 Apr 1999 15:47:57 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id RAA16218; Sun, 11 Apr 1999 17:05:04 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id NAA00935; Sun, 11 Apr 1999 13:42:25 +0200 (CEST) From: Wilko Bulte Message-Id: <199904111142.NAA00935@yedi.iaf.nl> Subject: Re: board not responding In-Reply-To: <199904110500.WAA06462@mina.sr.hp.com> from Darryl Okahata at "Apr 10, 1999 10: 0:24 pm" To: darrylo@sr.hp.com Date: Sun, 11 Apr 1999 13:42:25 +0200 (CEST) Cc: groggy@iname.com, freebsd-scsi@freebsd.org, questions@freebsd.org X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Darryl Okahata wrote ... > Steve Howe wrote: > > The "IBM DDRS-34560D" is an LVD drive (I've got this exact drive, > with the same firmware rev). For this IBM LVD drive, what appears to be > the "term" jumper is really the jumper that controls LVD vs SE HVD > (single-ended HVD), and "enabling termination" really puts the drive SE HVD??? As in Single Ended <-> High Voltage Differential ? Most LVD devices can step down to SE. HVD is a completely different thing and is not compatible with LVD or SE. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 11 16:17:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 9011C1506B; Sun, 11 Apr 1999 15:54:26 -0700 (PDT) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id LAA09703; Sun, 11 Apr 1999 11:42:44 -0700 (PDT) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA181336155; Sun, 11 Apr 1999 11:42:35 -0700 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id LAA20273; Sun, 11 Apr 1999 11:42:35 -0700 (PDT) Message-Id: <199904111842.LAA20273@mina.sr.hp.com> To: Wilko Bulte Cc: groggy@iname.com, freebsd-scsi@FreeBSD.ORG, questions@FreeBSD.ORG Subject: Re: board not responding Reply-To: Darryl Okahata In-Reply-To: Your message of "Sun, 11 Apr 1999 13:42:25 +0200." <199904111142.NAA00935@yedi.iaf.nl> Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Sun, 11 Apr 1999 11:42:35 -0700 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte wrote: > As Darryl Okahata wrote ... > > > The "IBM DDRS-34560D" is an LVD drive (I've got this exact drive, > > with the same firmware rev). For this IBM LVD drive, what appears to be > > the "term" jumper is really the jumper that controls LVD vs SE HVD > > (single-ended HVD), and "enabling termination" really puts the drive > > SE HVD??? As in Single Ended <-> High Voltage Differential ? Oh, my. Brain fart. You are, of course, correct. [ That'll teach me to drink and read email. ;-) ] By "SE HVD" (which is wrong), I was referring to plain single-ended SCSI. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 11 16:36:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 1F92714EBB for ; Sun, 11 Apr 1999 16:17:25 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id TAA03639 for ; Sun, 11 Apr 1999 19:15:07 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id TAA41257; Sun, 11 Apr 1999 19:14:26 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 11 Apr 1999 19:14:25 -0400 (EDT) To: freebsd-scsi@freebsd.org Subject: odd performance 'bug' & other questions X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14097.8430.806061.277769@grasshopper.cs.duke.edu> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We're setting up a few large servers, each with 6 9GB seagate medalist pro drives spread across 2 scsi controllers (aic7890 & ncr53c875). We've noticed that if we set up the disks using a simple ccd stripe, after trying various interleaves, the best read bandwidth we can get is only ~35-40MB/sec (using dd if=/dev/rccd0 of=/dev/null bs=64k), which is odd because we'd thought we should be getting at least 55-60MB/sec, as we get about 13.5MB/sec from each drive with the same test. Upon closer examination, we discovered that on some of the drives the performance wanders all over the place -- if you do a dd if=/dev/rX of=/dev/null bs=64k on an individual disk on an otherwise idle system & watch with iostat or systat, you can see the bandwidth jump around quite a bit. I'm thinking that my performance problems might be due to the fact that the reads aren't really sequential, rather the disk arm is moving all over the place to read remapped defective blocks. Using camcontrol to look at the defects list on some of these drives, I see that its HUGE. I've seen one disk with over 1100 entries in the primary defects list. Should I be alarmed at the size of the defects list? Should I complain to my vendor, or is this typical? Also, the ncr controller fails to give me a defects list, I assume this is a bug in the driver? (I'm running -current, dated this Thurs). camcontrol complains: error reading defect list: Input/output error, and I see this on console: (pass3:ncr0:0:0:0): extraneous data discarded. (pass3:ncr0:0:0:0): COMMAND FAILED (9 0) @0xc39a3600. Thanks for your help, ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 11 17:52:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D5FD14CAE for ; Sun, 11 Apr 1999 17:52:07 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id SAA01682; Sun, 11 Apr 1999 18:49:47 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904120049.SAA01682@panzer.plutotech.com> Subject: Re: odd performance 'bug' & other questions In-Reply-To: <14097.8430.806061.277769@grasshopper.cs.duke.edu> from Andrew Gallatin at "Apr 11, 1999 7:14:25 pm" To: gallatin@cs.duke.edu (Andrew Gallatin) Date: Sun, 11 Apr 1999 18:49:47 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrew Gallatin wrote... > > We're setting up a few large servers, each with 6 9GB seagate medalist > pro drives spread across 2 scsi controllers (aic7890 & ncr53c875). > > We've noticed that if we set up the disks using a simple ccd stripe, > after trying various interleaves, the best read bandwidth we can get > is only ~35-40MB/sec (using dd if=/dev/rccd0 of=/dev/null bs=64k), > which is odd because we'd thought we should be getting at least > 55-60MB/sec, as we get about 13.5MB/sec from each drive with the same > test. > > Upon closer examination, we discovered that on some of the drives the > performance wanders all over the place -- if you do a dd if=/dev/rX > of=/dev/null bs=64k on an individual disk on an otherwise idle system > & watch with iostat or systat, you can see the bandwidth jump around > quite a bit. I'm thinking that my performance problems might be due > to the fact that the reads aren't really sequential, rather the disk > arm is moving all over the place to read remapped defective blocks. There are a couple of things going on here that may affect the performance numbers you're seeing: - There was a performance problem in getnewbuf() that was supposedly fixed on April 6th. I haven't tested -current since then, so I don't know for sure whether the problem is really fixed. - The Medalist Pro drives are known to be rather crappy. That's why we've got the number of tags set to 2 in the quirk entry for those drives. > Using camcontrol to look at the defects list on some of these drives, > I see that its HUGE. I've seen one disk with over 1100 entries in the > primary defects list. Should I be alarmed at the size of the defects > list? Should I complain to my vendor, or is this typical? Well, it varies. I've got four disks on a heavily used server: at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 1 lun 0 (pass1,da1) at scbus0 target 3 lun 0 (pass2,da2) at scbus1 target 0 lun 0 (pass3,da3) Here are the defect numbers, in order: Got 464 defects: Got 144 defects: Got 1145 defects: Got 579 defects: I've also got the following disk on my home machine: at scbus1 target 1 lun 0 (pass1,da1) And it has 660 defects in the permanant list, none in the grown defect list. It is a 9G drive, and still gives pretty good performance. (14-16MB/sec) So your numbers are a bit high for a 9G drive, but I'm not sure whether that would be considered excessive. Of course the drives I've got above are higher-end Seagate and IBM disks, not low-end models. And you'd expect the number of defects to be somewhat proportional to the capacity of the drive. Your numbers are closer to the 18G IBM disk above. From the sound of it, your performance numbers sound a lot like the numbers I saw with the performance-impaired version of Matt's getnewbuf() changes. For instance, I've got a machine with 3 2G Seagate Hawks striped together. Normally, I get 5MB/sec per drive, for a total of 15MB/sec. After Matt's changes, I got about 6MB/sec or so, and the CPU was pegged during sequential I/O operations. (this is on a pentium 133) The performance numbers would almost return to normal when doing sequential I/O to/from the raw device. On my Ultrastar 9ZX, which is on a dual P6-200 system, I could only get an average of 12MB/sec (through the filesystem), again with one CPU pegged. The numbers from iostat were all over the place, which was quite unusual. In other words, the first thing I would suspect is some VM system type problem. > Also, the ncr controller fails to give me a defects list, I assume > this is a bug in the driver? (I'm running -current, dated this Thurs). > camcontrol complains: error reading defect list: Input/output error, > and I see this on console: > > (pass3:ncr0:0:0:0): extraneous data discarded. > (pass3:ncr0:0:0:0): COMMAND FAILED (9 0) @0xc39a3600. It could be a driver bug, not sure. What arguments were you using with camcontrol? Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 11 18:54:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 02AB91511A for ; Sun, 11 Apr 1999 18:54:10 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA07803; Mon, 12 Apr 1999 11:21:52 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA66000; Mon, 12 Apr 1999 11:21:50 +0930 (CST) Message-ID: <19990412112149.F2142@lemis.com> Date: Mon, 12 Apr 1999 11:21:49 +0930 From: Greg Lehey To: Andrew Gallatin , freebsd-scsi@FreeBSD.ORG Subject: Re: odd performance 'bug' & other questions References: <14097.8430.806061.277769@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=WlEyl6ow+jlIgNUh X-Mailer: Mutt 0.93.2i In-Reply-To: <14097.8430.806061.277769@grasshopper.cs.duke.edu>; from Andrew Gallatin on Sun, Apr 11, 1999 at 07:14:25PM -0400 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --WlEyl6ow+jlIgNUh Content-Type: text/plain; charset=us-ascii On Sunday, 11 April 1999 at 19:14:25 -0400, Andrew Gallatin wrote: > > We're setting up a few large servers, each with 6 9GB seagate medalist > pro drives spread across 2 scsi controllers (aic7890 & ncr53c875). > > We've noticed that if we set up the disks using a simple ccd stripe, > after trying various interleaves, the best read bandwidth we can get > is only ~35-40MB/sec (using dd if=/dev/rccd0 of=/dev/null bs=64k), > which is odd because we'd thought we should be getting at least > 55-60MB/sec, as we get about 13.5MB/sec from each drive with the same > test. This kind of test is not very useful, and may be counterproductive. What size stripe did you use? I'm attaching a plot of Vinum performance against stripe size with a volume spanning four very slow disks. I briefly tested ccd and got very similar results. These were done with 'rawio' against the character device with 8 concurrent processes. You'll note that sequential I/O performance peaks at about 80 kB stripes, whereas random transfers (which are presumably closer to what you're doing) improve with increasing stripe size. You'll also notice that the performance ratio is approximately the same as you describe, rather less than 3x the single disk, but this is misleading, since I only had four drives in this test. You'll also notice that the performance figures are terrible; that's because they were done on some ancient drives (look at the throughput of the raw drives without Vinum). > Upon closer examination, we discovered that on some of the drives the > performance wanders all over the place -- if you do a dd if=/dev/rX > of=/dev/null bs=64k on an individual disk on an otherwise idle system > & watch with iostat or systat, you can see the bandwidth jump around > quite a bit. I'm thinking that my performance problems might be due > to the fact that the reads aren't really sequential, rather the disk > arm is moving all over the place to read remapped defective blocks. Have you considered rotational latency? Unless you spindle-sync the drives, you can end up with random delays in moving from one drive to the next. If you spindle-sync them, you may or may not incur a whole-rotation delay :-) I've done some tests here, and they show the same effects for single processes. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key --WlEyl6ow+jlIgNUh Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="stripeplot.all.gif" R0lGODdhAAXAA+YAAP///wAAAEBAQP8AAADAAACA/8AA/8D/QMBAAED/gCAgwIAAwABggACA AACAQACAgADAYADAwAD/ACCAIDBggEBAQECAAAAAgIBgAIBgEIBgYIBggAAAwAAA/wBgAEDA gGCgwGDAAGDAoIAAAIAAgGAggGBgYAD//yAgICBAQCBAgGCAIGCAYGCAgICAQICAgKCgoKDQ 4MAgIMBgAIDA4MBgwMCAAMCAYP9AAP9AQIDA//+AYP+AgMCgAMDAwMD/wP8AAP8A//+AoP+A /8DAoP9gYP+AAP+gAIDg4KDg4KD/IMAAAMAAwKAgIKAg/4AgAIAgIIBAAIBAIIBAgIBgwIBg /4CAAKCA/8BggMDAAP+AQP+gQP+gYP+gcP/AIP/AwP//AP//gP//wAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAAAXAAwAH/4AAgoOEhYaHiImKi4yNjo+QkZKTlJWW l5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJysvM zc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAMK HEiwoMGDCBMqXMiwocOHECNKnEixosWLywAFCAIAAAgGAAAAAAQAAggKBgACCA4SFhoeIiYq LjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsLGigYMBgAEDAYIBgAEDAYA BMjKysrKysrKysrKysrKyv/KysrKysrKysrKMgYUBgAEDAYABAwGyMrKysrKysrKysrKysrK ysrKysrKysrKyioCFAAIICgYIBgwGAAQMBgwOAgAGCA4SFhoeIiYqLjI2Oj4CBkpOUlZaXmJ mam5ydnp+QkaKjpKWmp6ipqqusra6voKuwkIIDhIWGh4iJhIGFAYMBgwGAAQMBhwGKCoqKio qKiomBigqKioqCgYoKioeBigqIgYoKg4GKCYGKBoGKBYGKA4GKCoqKioqKiomBigqKioqCgY oKioaBigqJgYoKgoGKCYGKB4GKBIGKA4GKCoqKioqKiomBigqKioqCgYoKioeAhQACCA4CBh oeH/YcDh4aFgwOFhYcDhoWDA4SFAwKFhwOHh4eHh4eHh4eHhYWHA4eHh4eHh4WDA4eHh4SFA wOHh4SFAwOHhIUDA4WFhwOHhYMDhYcChYcDh4eHh4aFhQGEAYcBgAEDAYMBhwOHh4eHh4eHh 4eHhYWHA4eHh4eHh4WAAIIDgIGGh4SEiQEBiYiJAQGJiYUBiIkBA4mFAomFAImFAYmJiYmJi YmIiYkBiYmJi4mFAYmJiYkBiYqJgQGIiYUBiIkBAImJAYmFAImFAYmJiYmJiYmIiYkBiYmJi 4mFAYmJiIkBAYmIiQEBiYmFAYiJAQOJhQKJhQCJhQGJiYmKiRIkSJUIE/ygAEEBwkLDQ8BAx 8TBAUVHRMEBRMTFAUVEwQDExQPEwQJEwQHEwQFFRUfEwoDDAMAAgYDAAIAAxQFFRUVFRUVEx MUBRUVFRUTBAUVHxMEBRETFAUXEwQDExQNEwQLEwQHEwQFFRUVFRUVExMUBRUVFRUTBAUVHR MEBRMTFAUVEwABBAcJCwkDDA0LAwwNBQMMDQECAAEEBwkLDQ8BAxUXGRcTGgsbGxMaCxcTGg sVEwoFExoNEwoHEwoFEwoDGgsbGxsbFxMaCxsbExoLFRMaCxcTCgMTGg0TCgkTCgESCgMaCx sRERMEBQEGBQEAAAIAAQQFAwYHBwMAAQQHCQsP/Q8BAxUXGRcTGgsbGxMaCxcTGgsVEwoFEx oNEwoHEwoFEwoDGgsbGxsbFxMaCxsbExoLFRMaCxcTCgMTGg0TCgkTCgESCgMaCxsbGxsXEx oLGxsTGgsXExoLFRMKBRMaDRMKBxMKBRMKAxoLGxsbGxcTGgsbGxMaCxURFQACCA4CBhoeEh QAAiomEAIuJgACIiQACiYQBiYQAiIiIiIiIiImJhACIiIiIiIiIiIiIiQAAiIiIiIiJhACIi ImJhACIiImEAIuJhACLiYAAiYgDiYQBiYQAiIiIiIiIiIiIiIkAAIiIiIiIiYQAiIiIiYQAi ImJhACKiYQAi4iBgACD/gOAgYaFggKGhYIChIUAAIIDgIGGh4SFiouIi42JAY2NjY0Bj42JA Y6NgQKNiQKNhQONgQKNgQGNAY2NjY2PjYkBjY2NjQGOjYkBj42BAY2JAo2FAI2FAI0BAY0Bj Y2NjI2NAY2NjY2PjYkBjY2NjQGPjYkBjo2BAo2JAo2FA42BAo2BAY0BjY2NjY+NiACCA4CBh oeEhYuJhgKKiomGAomJigKKiYIBiYoDiYYAiYYDiYICioqKioqKiYmKAoqKioqJggKKi4mGA oiJigKLiYIBiYoCiYYBiYYDiYICioqKioqKiYmKAoqKioqJggKKiomGAomJigKKiYIBiYoDi /2GAImGA4mCAoqKioqKi4iFAAYAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5gBmJiYmJiYmJiY mJiYiwGYmJiYmJiYmJiYmJiMAZiYmJiYmJiYmJiYmIsBmJiYhQGYmJiYmJiYmJiYmJiMAZiY mJiYmJiYmJiYmIsBmJiYmJiYmJiYmJiYjAGYmJiYmJiYmJiYmJiLgAIAAQQHCQsNDxETFRcX AxgZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkDGBkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZFwMY GRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZAxgZGRkZGRkZGRkZGRkZGf8ZGRkZGRkZGRkXAxgZ GRkZGQsDGBkZMWLEiBEjRowYMWLEiBEjRowYMWLEiBEjRoACAAEEBwkLDQ8RExUXGRsdHyEj JScpKy0vLwMwMTExMTExMTExMTEZAzAxMTExMTExMTExMRcDMDExCwMwMTExMTExMTExMTEZ AzAxMTExMTExMTExMRcDMDExMTExMTExMTExGQMwMTExMTExMTExMTEXAzAxMQsDMDExMTEx MTExYcKEiRGgAEAAwUHCQsNDxETFRcZGx0fISMlJykrLy8sATExMTExMTExMTExMxgBMTExM TExMTExMTMzFAExMzMIAQADBQcJCw0PERMX/RcZGx0fISMlJykrLS8xMzU3OTs9P0FDRUdJS 01PUVNVV1lbXV9jMgFjOgNjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2MyAWM6A2NjY2NjY2NjY 2NjY2NjY2NjY2NjY2NjYzIBYzoDY2NjY2NjY2NjY2NjY2NjYWLFixSoFaAAAAGAAAABgABBA cJCw0PBwYGDg8PDwsHDAcOBwcGDg8PDwcHDg8PDw8PDw8HAw4PDw8PDw8PDw8PAwABBAcJCw 0PAQMVFxkbHR8REyUnKSstLyEjNTc5Oz0/MTNFR0lLTU9BQ1VXWVdXNgcOBzYHAAdEBy4HOg 1TGgFTSgtbW1tbW1/7W1tbW1tbW1tbW1tbW1tXVzYHBAcGBgcABgYEBwYHAAYGAAYABxwHBg YGBwYABgAGBgcEBwYGAAEABgAGBgQHBgYGBAEGBgQFBwYGBAUHBAUFBQEGAAYGBAEGBgYEAQ YGBgQBBgYABgABBAcJCw0PAQMVGRMGBxcXFxcXExABBAcJCw0PAQMVFxkbHR8REyUnKSstLy EjNTc5Oz0/MTNFR0lLTU9BQ1VXWVlXMAYIBwYHBgQHAAYGBwAGAAYABgAHFgYHBgcABgQHBg AGBgcABgYHAAYGBAcEBwwHDgcGBwIHFgQHAAYGBwoHAAYEBwYOAQcEBwkLDQ8BCxEBBAcP+Q ECAAEEBwkLDQ8BAxUXFxMQAQQHCQsNDwEDFRcZGx0fERMlJykrLS8hIzU3OTs9PzEzRUdJS0 1PQUNVV1lZVzAGCAcGBwYHAAYGBwAGAAYABgQHFAEHBAUBBgAAAAYABgAAAAYABgUBBgAAAA YAAAYAAQQHBwYBBgYGBgYHBgcHBwYFAQcEBQEABgcABgAAAAYAAQQHCQsNDwEDFRkTBgcXFx cXFxMQAQQHCQsNDwEDFRcZGx0fERMlJykrLS8hIzU3OTs9PzEzRUdJS01PQUNVV1lZVzAGCA cGBwYHAAYGBwAGAAYABgYHEAYKBwYHAAYGBwAGCgcGBwQHDAcGD/cGBwYHAgcaBwoHBgcABg YHCg1TGgFTSgtbW1tbW1tbW1tbW1tbW1tbVVq1atWnUCNAAIICg4MDgwOAAwIDgwADAAMAAw MDgIMDA4ADAwKDggODAAMCA4MAAwMCg4MDggOCA4MDgwOCA4MDA4MDg4ODAoODAoOCA4MAAw IDgwAAggOEhYaHiImKhIGLC4uLi4uLgYAAggOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmpucnZ 6fkJGio6SlpqeoqaqrrK2jlAODAwIDgwOCA4MAAwADAwOIA4MDAwODAwMDgwADAgODAAMCA4 MDAgODA4MDgwMDgwMDA4MAAwIDgwMIA4/2A4MDAwODAAMCA4MAAw0OoY0AoKGAAIIDhIWGh4 iJiouMjY6PgIGSk5SVlpeYmZqbnJ2en5CRoqOkpaanqKmqq6ytoqOuDqehrg+hng6urq6urq 6urq6urq6urq6urq6urq6ro44Op6GuD6GeDq6urq6urq6urq6urq6urq6urq6urq6urqWhjg +hng6urq6urq6urq6sqVK1euXLly5cqVK1euXLlyVQhQACCA4CBhoeEhYqLi4mIAIIDgIGGh 4SFiouIiY6PjI2Sk5CRlpeUlZqbmJmen5ydoqOgoaanpKWqq6iprq+srbGZALGdAbGxsbGxs bGxsbGxsbGxsbP9sbGxsbGxsbGZALGdAbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsZkAsZ0Bs bGxsbGxsbGxsbGxsbGxsrFixYn0CRAAAAEAAAABAAAggOEhYaHhIQEBweHh4WEhgSHA4SEBw eHgoSEBIcHh4eHh4eHh4WBhweHh4eHh4eHh4eBgACCA4SFhoeIiYqLjI2Oj4CBkpOUlZaXmJ mam5ydnp+QkaKjpKWmp6ipqquspaSTBI8EkwSABKIEnASdB6GdAKGtDa2tra2tra2tra2tra 2tra2tra2tpaSTBIIEhAMEgAQEAgSDBIAEBAAECASGBIQEAwSEAAQABAMEggSEBAAAj/AEAA QEAgSEBAQCAIQEAgKEhAQCAoSCAoKCgIQCAIQABAAEBAIAhAQCAIQEBAQCAIQEBAAAggOEhY aHiImKhYGLC4uLi4uLgYAAggOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmpucnZ6fkJGio6Slpq eoqaqrrKakkAQEBIMEhAIEgAQDBIAEAAQABAgEhAMEgwSABAIEhAAEAwSABAMEgAQEAgSCBI YEhwSDBIkEgwSABAQCBIMEhASEBIMEhwCEggOEhYaHiIWAgIIDhICBAACCA4SFhoeIiYqLi4 GAAIIDhIWGh4iJiouMjY6PgIGSk5SVlpeYmZqbnJ2en5CRoq/zpKWmp6ipqquspqSQBAQEgw SDBIAEAwSABAAEAAQKBIIAhIICgIQAAAAEAAQAAAAEAAMCgIQAAAAEAAAEAACCA4SDAIQEBA QDBIMDg4SABAAEAAQDA4CEAwCEAwCABIICgICCA4SFhoeIiYqEgYsLi4uLi4uBgACCA4SFho eIiYqLjI2Oj4CBkpOUlZaXmJmam5ydnp+QkaKjpKWmp6ipqquspqSQBAQEgwSDBIAEAwSABA AEAAQLBIAEBQSDBIAEAwSABAUEgwSCBIYEgwSDBIMEiQSABAAEAAQHBIQEhASNAqGdAKGtDa 2tra2tra2tra2tra2tqqVatWrVq1uv8EiAAQQFCQYJBgkACAQJCAAIAAgACAYHAQgGCQAIBg UJBAkIAAgECQgACAYFCQYJBAkECQYJBgkECQgGCQYHBwkACAAIAAgGBwEIBgEIBAkACAABBA cJCw0PAQMVERMWBxcXFxcXExABBAcJCw0PAQMVFxkbHR8REyUnKSstLyEjNTc5Oz0/MTNFR0 lLTU9BQ1VXWV9ZKAkICAQJBgkECQgACAAIBgkACRgIBgkICAYJCAAIBAkIAAgECQgIBAkGCQ YJCAYJCAgGCQgACAQJCAgCCRAIBAkMCQgICAkIBgkICAoPUxoBUUUAAggOAgYaHhIWKi4iJj o+MjZKTkJGX/peUlZqbmJmen5ydoqOgoaanpKWqq6iprKyeBq2trgOtngKurq6urq6urq6ur q6urq6urq6urq6trIYGra2uA62eAq6urq6urq6urq6urq6urq6urq6urq6urq2thgOtngKur q6urq6urq6srV65cuXLlypUrV65cuXLlylUhQAGAAIKDhIWGh4iJiouLAYAAgoOEhYaHiImK i4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CZAbGcAbGxsbGxsbGxsbGx sbGxsbGxsbGxsbGxsZkBsZwBsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxmQGxnAGx/7GxsbGx sbGxsbGxsbGxsbFixYoVixGgAgAAgAIAAIACQADBQcJCQ8OCgoKCw0PCgsPDw8NDw4LDw8PD w8PDw8GAw8PDw8PDw8PDw8MAQADBQcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/QUNFR 0lLTU9RU1VXWVsOCwYLPgsGCyILUAtfGANfPAFdXV1dXV1dXV1dXV1dXV1dXV1dXV9fOgsEC wYKCwQKAggLBgsECgIICgALEgsECwYKCAsECgIKCwYICgALBAsCCAgCAggKAAkAAwUHBAoCC gsGCgoLBgoKCwYICgAJAAMFBwkLDQ8RERcKAxcXFxcXFxf8AQADBQcJCw0PERMVFxkbHR8hI yUnKSstLzEzNTc5Oz0/QUNFR0lLTU9RU1VXW1sMCgALCgsGCAsECgILBAoACgAKAgsOCwYLC AoCCAsECgALBggKAgsECgAKAAoCCw4ICwQKAgsGCwgKAAsGCgkPAAsFBwkLDQ8RCQADBQUKA AEAAwUHCQsNDxETFxcUAQADBQcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/QUNFR0lLT U9RU1VXW1sMCgALCgsGCwQKAgsECgAKAAoCCw4KCgoLBgoKCAoCCwQKAgsECgILBAoACgAKA gsOCQsACQUEAgMECgAIAAIACQAD/wUHCQsNDxERFwoDFxcXFxcXFAEAAwUHCQsNDxETFRcZG x0fISMlJykrLS8xMzU3OTs9P0FDRUdJS01PUVNVV1tbDAoACwoLBgsECgILBAoACgAKAgsMC gILBgsECgILBAoCCwQKAgsECgAKAAoCCw4LCgsKCwQKAgsEC18YA188AV1dXV1dXV1dXV1dX V1dXV1dXV65cufoEqAAQQFCwYLBgsACgQLCgAKAAoACgYHAQoECwQLBAsKAAoGCwAKBAsKAA oGCwAKAAoACgYHAQoGBQsGBQsECwoACgQLCgABBAcJCw0PAQMVGRMGBxcXFxcXExABBAcJCw 0PAQMVFx/5Gx0fERMlJykrLS8hIzU3OTs9PzEzRUdJS01PQUNVV1lbUVsYCwoKBAsGCwQLCg AKAAoGCw4LBgsECwoACgAKBgsECwoACgQLCgoECwYLDgsMCwoKBgsKAAoECwoACgwLUxwPUz wNXV1dXV1dXV1dXV1dXV1ZUrV65cuXLlypUrV4UABQACCA4SFhoeIiYqLi4GAAIIDhIWGh4i JiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wmYGxHIGxMbGxsbGxsbG xsbGxsbGxsbGxsbGxsbGZgbEcgbExsbGxsbGxsbGxsbGxsbGxsbGxsbGxsZmBv/EcgbExsbG xsbGxsbGxsbGxsbGxooVK1asWLFiZQIUAAggOEhYaHiImKi4uBgACCA4SFhoeIiYqLjI2Oj4 CBkpOUlZaXmJmam5ydnp+QkaKjpKWmp6ipqqusra6voKmxkQyxkQGxsbGxsbGxsbGxsbGxsb GxsbGxsbGxubGRDLGRAbGxsbGxsbGxsbGxsbGxsbGxsbG2toMGgwaLBpYGBgIGkQakBoEDsZ EMsZAAggOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmpucnZ6fkJGio6SlpqeoqaqrrK2mowaPBp MGgQaWBq0HoZ0Aoa0Nra2tra2tra2tra2tra2tra2tr/2traajBoIGhgMGgAYGAgaDBoAGBg AGCAaDBoIGhgYCBoAGBgMGhgAGAgaGAAaAAAYGAAYAAIIDgoaDBoAGAAYGAwaGAwaGBgYDBo YGAACCA4SFhoeIiYqFgYsLi4uLi4uBgACCA4SFhoeIiYqLjI2Oj4CBkpOUlZaXmJmam5ydnp +QkaKjpKWmp6ipqqusraCmAAYEBoMGhgIGgAYDBoAGAAYABgcGgwaFBoAGBgIGgAYCBoYABg MGgAYABgAGBwaDBoAGBgIGgwaEBoQGgwaHAIaCA4SFhoeIhYCAggOEgIEAAIIDhIWGh4iJio uLgYAAggOEhYaHiImKi4yNjo//gIGSk5SVlpeYmZqbnJ2en5CRoqOkpaanqKmqq6ytoKYABg QGgwaDBoAGAwaABgAGAAYHBoYGBgMGhgYGAAYDBoAGAwaABgMGgAYABgAGBwaABgAGAAYHBo QGhACGggKAgIIDhIWGh4iJioSBiwuLi4uLi4GAAIIDhIWGh4iJiouMjY6PgIGSk5SVlpeYmZ qbnJ2en5CRoqOkpaanqKmqq6ytoKYABgQGgwaDBoAGAwaABgAGAAYHBoAGAwaDBoAGAwaABg MGgAYDBoAGAAYABgcGgAYABgAGBwaEBoQGjgGhng+hng6urq6urq6urq6urq6urq6sqVK1eu XGUCZP8ACCAoaDBoMGgAYCBoYABgAGAAYDA4CGAgaCBoIGhgAGAwaABgIGhgAGAwaABgAGAA YDA4CGAAYABgAGAwOAhgMAhgIGgAYAAIIDhIWGh4iJioiBiwuLi4uLi4GAAIIDhIWGh4iJio uMjY6PgIGSk5SVlpeYmZqbnJ2en5CRoqOkpaanqKmqq6ytoqaEBoYGAgaDBoIGhgAGAAYDBo cGgwaCBoYABgAGAwaCBoYABgIGhgYCBoMGiAaABgIGhgaGBgQGhgMGhgYODqGOD6GeDq6urq 6urq6urq6urq6sqVK1euXLly5cqVK1eFAAUAAggOEhYaHiImKi4uBgACCA7/EhYaHiImKi4y Njo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CZgbEcgbExsbGxsbGxsbGxsbG xsbGxsbGxsbGxsZmBsRyBsTGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxmYGxHIGxMbGxsbGxsbG xsbGxsbGxsaKFStWrFixYmUCFAAIIDhIWGh4iJiouLgYAAggOEhYaHiImKi4yNjo+AgZKTlJ WWl5iZmpucnZ6fkJGio6SlpqeoqaqrrK2ur6CpsZEMsZEBsbGxsbGxsbGxsbGxsbGxsbGxsb GxsbmxkQyxkQGxsbGxsbGxsbGxsbGxsbGxsbGzt5/3BwcIB5MHiQeMB4cHAQemB4oHhw8HkA CCA4SFhoeIiYqEgYsLi4uLi4uBgACCA4SFhoeIiYqLjI2Oj4CBkpOUlZaXmJmam5ydnp+Qka KjpKWmp6ipqqusqaeDB4cHnQeLB4MHgAeiB58HnQ6hjQChrQ2tra2tra2tra2tra2tra2tra 2tramngweCB4cHAgeDB4gHhwAHAgeHBAeHBwIHggeIB4YHhwcDB4AHgAcABwAAAAcAAAcHBw AABwAHBwAABwcHBwAAAAcHAAAAAAcHBwAAAAAHAACCA4OHgAcHAweHBwMHhwcDB4cABwAAgg OEhYaHiImKhIGLC4uLi4uP+4GAAIIDhIWGh4iJiouMjY6PgIGSk5SVlpeYmZqbnJ2en5CRoq OkpaanqKmqq6ypp4MHhQeABwMHhweCB4cDB4MHgweABwAHCgeHAweDB4AHAgeHAAcDB4AHAw eABwcCB4IHhgeHB4MHiQeHAgeABwMHhQeABwIHhwcAh4IDhIWGh4iFgICCA4SAgQAAggOEhY aHiImKi4uBgACCA4SFhoeIiYqLjI2Oj4CBkpOUlZaXmJmam5ydnp+QkaKjpKWmp6ipqqusqa eHBwcDB4cHBwAHAAcABwcHgweDB4QHhwMHhw0HggCHggKAhwAAAAcABwAAAAcAAwKAhwAAAA cAD/AHAACCA4eDAIcHBwcDB4MDg4eDAoCHggKAgAMHgAcAAAAHAACCA4SFhoeIiYqEgYsLi4 uLi4uBgACCA4SFhoeIiYqLjI2Oj4CBkpOUlZaXmJmam5ydnp+QkaKjpKWmp6ipqqusqaeABw MHgweABwAHAAcHB4MHgweGB4IHgAcNB4AHBQeDB4AHAweABwUHgweCB4YHgweDB4MHiQeFB4 UHgweABwMHjQ6hjQChrQ2tra2tra2tra2tqqVatWrVq1atWqVatEgA4AAA4AAA4AAA4OAA4A DgAOAAEEBwEOBA8OBg8GDwYPAA4EDwgJDwYPAA4IAQ4EDw4ADgQPDgAO/wgBDgYPBA8EDwYP Bg8EDw4GDwgJAQ4IAQ4IAQ4EDw4ADgQPDgABBAcJCw0PERMVCQMWFxcXFxcXAwABBAcJCw0P ERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/QUNFR0lLTU9RU1VXWRMPBg8EDw4ADgQPAA4SDw4A DgQPDg4GDw4OBA8GDxAPDg4GDw4OBg8OAA4EDw4ADgQPDg4EDwYPBg8OBg8ODgYPDgAOBA8O DhAPDA8ODgYPDgAADwAADg4ADgABBAcJCw0PERMVCQMWFxcXFxcXAwABBAcJCw0PERMVFxkb HR8hIyUnKSstLzEzNTc5Oz0/QUNFR0lLTU9RU/9VV1lbRQ9cXU8DXD8DXF1dXV1dXV1dXV1d XV1dXV1dXV1dXV0XD1xdTwNcPwNcXV1dXV1dXV1dXV1dXV1dXV1dXV1dXV1dXQsDXAUDAgII AwoDCgMSAQMAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9P0FDRUdJS01PUVNVV1lb XV9hMwNeAwYDBAMAAgYDAAIGAwACEANiY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2MzA2IFAwAC BgMAAgYDAAIGAw4DYmNjY2NjY2NjY2NjY2NjY2PFihUrVqxYsTIBCgAEEBwkLDQ8REwsDBAM GAwACBgMAAgYDDgEDBD/HCQsFAQEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1Nzk7PT8BA0V HSUtNT1FTVVdZW11fU0FDBAcJCwUBAQQHCQsNDxETCQMGAwYDAAIGAwACBgMOAwABBAcJCw0 PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/AQNFR0lLTU9RU1VXWUdREBAQMBEGERIRGBEQEAI RTBEUERAuEQgRGi9DGgdDCAMGAwACBgMAAgYDDgMaG1tbW1tbW1tbW1tbW1tbW1tbW1tbR1E GES4RGhEWEQYRABFAAQQHCQsHEQwNDQ0JEQwNDQ0NDQ0NDQ0NBQMMDQ0NDQ0NCwMMAwACBgM /wAIGAwACDAUDAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1Nzk7PT8BA0VHSUtNT1FTVVd ZR1EGEQQREBAEEQYREBEQABAEERAIERAQBBEEERARDBEQEAYREAAQABAGEQQREBAEEQAQEAQ REBAQBhEQCBEQEAgREhEGEQAQABAQBhEQBhEQEAARAAAAEBAQAAEEBwkLDQ8RExULAxYXFxc HAQMEBQEAAAIAAQQFAwYFAwYHBwMAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9PwE DRUdJS01PUVNVV1lHUQYRChEAEAYRDhEEERAGEQYRBhEAEAAQFBEQP8YRBhEAEAQREAAQBhE AEAYRABAQBBEEEQwRDhEGERIRBhEAEBAEEQYRCBEIEQYRDgERBAcJCw0PEQsBAQQHCQECAAE EBwkLDQ8RExUXFwMAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9PwEDRUdJS01PUVN VV1lHURAQEAYREBAQABAAEAAQDhEGEQYRCBEQBhEQGhEEAREEBQEQAAAAEAAQAAAAEAAGBQE QAAAAEAAAEAABBAcRBgEQEBAQBhEGBwcRABAAEAAQBgcBEAYBEAYBABEEBQEBBAcJCw0PERM VCQMWFxcXFxcXAwABBAcJCw0PERMVFxkbHT/fISMlJykrLS8xMzU3OTs9PwEDRUdJS01PUVN VV1lHUQAQBhEGEQAQABAAEA4RBhEGEQwRBBEAEBoRABAKEQYRABAGEQAQChEGEQQRDBEGEQY RBhESEQAQABAAEA4RCBEIERolQxoBQ1obW1tbW1tbW1t1apVq1atWrVq1apVq1aDACEAACAA ACAAACAgACAAIAAgAAIIDgIgCCIgDCIMIgwiACAIIhASIgwiACAQAiAIIiAAIAgiIAAgEAIg DCIIIggiDCIMIggiIAwiEBICIAAgACAAIBAOIhAiCCIAIAACCA4SFhoeIiYqIgYsLi4uLi4u BgACCA4SFhoeIiYq/y4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrIOIgwiCCIg ACAIIgAgJCIgACAIIiAgDCIgIAgiDCIgIiAgDCIgIAwiIAAgCCIgACAIIiAgCCIMIgwiIAwi ICAMIiAAIAgiICAkIgAgCCIYIiAgAAIIAiAgDCIgIAACCA4SFhoeIiYqFgYsLi4uLi4uBgAC CA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusrZyIri6tga4fga4 urq6urq6urq6urq6urq6urq6urq6uhYiuLq2Brh+Bri6urq6urq6urq6urq6urq6urq6uv+6 urq6uhYGuH4GuLq6urq6urq6urpy5cqVK1euXLly5cqVK1euXBUCFAAIIDhIWGh4iJiouLgY AAggOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmpucnZ6fkJGio6SlpqeoqaqrrK2ur6CpsZEMsZ EBsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbmxkQyxkQGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxub GRDLGRAbGxsbGxsbGxsbGxsbGxsbK1asWKsAJQgmAAIIDhIWGg4mDCYcCiYcEiYkJCQcHhIm HB4eHh4aJhweHh4eHh4eDgYcHh4eHh4eHh4eHgYAAggOEhYaHiL/JiouMjY6PkJGSk5SVlpe YmZqbnJ2en6COgISCA4SEgACCA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnoWJgwmXCY0 JiwmDCZEJnwqJnxyBnx+PgZ8fn5+fn5+fn5+fn5+fn5+fhICEggOEhIAAggOEgIAEggOEhIA AggOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZiJgwmCCYkJAgmDCYgJiQAJAgmJBAmJCQI JggmICYMJggmJCQIJgAkJAwmJAAkCCYkJAgmJAAkICYAJCQMJiQkDCYkJAwmJAAkeHYGeHpG Bnh6enp6enp6enp6enp6enp6NgIiEBwU/wQEEBwkLDQ8LAQkEBwUBAQQHCQsNDxETFRcZGx0 fISMlJykrLS8xMzU3OTshEwYTChMAEgYTDhMEExIGEwYTBhMAEgASEhMGEwoTABISBBMAEgQ TEgASBhMAEgASABIOExIEEwASBhMKEwASBBMSDgETBAcJCw0PEQsBAQQHCQECAAEEBwkLDQ8 RExUXFwMAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9PysBCQQHAQEEBwkLDQ8REwk BCQQHAQEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1Nzk7FRMSEhIGExISEgASABIAEg4TBhM GEwgTEgYTEhQTP9ISEgYTEhISABIGEwASBhMAEgYTABIAEgASDhMKARMEBQEABhMAEgAAABI AAQQHCQsNDxETFQkDFhcXFxcXFwMAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9PyM JCAgIADtBCQQFAQEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1Nzk7CxMAEgYTBhMAEgASABI OEwYTBhMMEwQTABISEwASBhMGEwASBhMAEgYTABIGEwASABIAEg4TChMKEwYTABIGEzw7Azw 9IwM8PT09PT09PT09PT09PT09OwkICAg8PRUBCQQHAQEEBwkLDQ8RExUXGRsdHyEjJT/nKSs tLzEzNTc5ORMEEwQTBBMSABIAEgASDhMEExIGEwYTBhMAEgQTEBMEEwQTBBMSABIGEwASBBM SABIGEwASABIAEg4TChMKEwQTEgASBBMSOjsBAjo7JwM6Ozs7Ozs7Ozs7Ozs7Ozs7OxkBCQQ JAAEEBwkLDQ8RExUXGQUJCAgIAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1NzkxEwYTBBM SABIEEwASEhMSABIEExISBhMSEgQTBhMOEwYTBBMSABIAEgYTBBMSABIEExISBBMGEw4TDBM SEgYTEgASBBMSABI6OwECOjsnAzo7Ozs7Ozs7Ozs7Ozs7Ozs/+xMBCQQBAQQHCQsNDxETFRc ZFQkICAABBAcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/AQNFVUMGB09DBgdHR0dHR0d HR0dHR0dRSQgICAYHcUkIBgdHR0dHR0dHR0dHR0dHR0dRQwYHT0MGB0dHR0dHR0dHR0dHR0l JCAgIBgd9SQgIBgdHR0dHR0dHR0dHR0dHR01qhCgAEAAwUHCQsNDxETFxcUAQADBQcJCw0PE RMVFxkbHR8hIyUnKSstLzEzNTc5OT00CAoLPz09HAgKCz8/Pz8/Pz8/Pz8/Pz8/Pz8/PT8SA z8/HgM/Pz8/Pz8/Pz8/Pz8/PT0wCgv/Pz09KAgKCz8/Pz8/Pz8/Pz8/Pz8/Pz8/Pz8KAz8/H gM/Pz8/Pz8/Pz8/PT58+fbIEiIAAEEBwkLDQ8BAxUXGRsdGxkYAAEEBwkLDQ8BAxUXGRsdHx ETJScpKy0vISM1Nzk7PT8xM09DNAVDQxQFRUVFRUVFRUVFRUVFQ0kYBAVFSUkoCAQFRUVFRU VFRUVFRUVFRUVFR0MUBUNDFAVFRUVFRUVFRUVFRUVPSQgEBUVDSTgIBAVFRUVFRUVFRUVJRT QUFBARBAcJCw0HBQYVDhUFDhkFBBQUHh8JBQ4fDw8LBQgVDh8PDw8PDw8PCwMODw8PDw8PDw 8PDwMAAQQHD/kLDQ8BAxUXGRsdHxETJScpKy0vISM1Nzk7PT85GAgODz8/MTkYDg8/Pz8/Pz 8/Pz8/OTU2FQ4VKhUWFRYVAhUuHzUOHz0zDg8/Mx4PPz8/Pz8/Pz8/Pz8/Pzs5GA4PPz87OR gODz8/Pz8/Pz8/Pz81NTYVBBUEFBQVBhEFABEEBwUFBBAUBBUEGBUEFBQVBBUIGQUGFQQVBB QUFQAUBBYVBBAUBBUEFBQVBBAUCBkFBhUAFAAUBBYVBBYVBBQUFhUEFBARBAcJCw0PAQMVGx MGBxcXFxcXExABBAcJCw0PAQMVFxkbHR8REyUnKSstLyEjNTc5Oz03ORgODz8/Mz/5KA4PPz 8/Pz8/Pz8/PzE1NhUKFQAUBhUOFQQVBBYVBhUGFQAUABQCFRYVChUAFAQUFQAUBBUEEBQGFQ AUABQAFA4VBhUAFAQUFQYVCBUIFQYVDhEFBBcJCw0PAQsRAQQHCQECAAEEBwkLDQ8BAxUXFx MQAQQHCQsNDwEDFRcZGx0fERMlJykrLS8hIzU3OTs9MzkYDg8/Pzs5KA4PPz8/Pz8/Pz8/Pz 01JBQUFhUEFBQQFAAUABQOFQYVBhUIFQQWFQQUFRQUFBYVBBQUEBQGFQAUBhUAFAYVABQAFA AUDhUAFAAUABQOFQgVCBEFBBUBAQQHCQsNDwEDFRkTBgcf9xcXFxcTEAEEBwkLDQ8BAxUXGR sdHxETJScpKy0vISM1Nzk7PT85CA4PPz8zOTgIDg8/Pz8/Pz8/Pz8/NzUgFAYVBhUAFAAUAB QOFQYVBhUMFQQVABQCFRAUBhUGFQAUBhUAFAYVABQGFQAUABQAFA4VABQAFAAUDhUIFQgVDh 8xMg4PPzETAAEEBwkLDQ8BAxUXGRsdHxETJScpKy0vISM1Nzk7PTs5CA4PPz89OTgODz8/Pz 8/Pz8/Pz8zNSQVBBUEFQQQFAAUABQOFQQVBBYVBhUGFQAUBBUAFRQVBBUEFQQQFAYVABQEFQ QQFAYVABQAFAAUDhUAFAAUABQOH/UIFQQVABQAEQQHCQsNDwEDFRETFgcXFxcXFxMQAQQHCQ sNDwEDFRcZGx0fERMlJykrLS8hIzU3OTs9NzkIDg8/Pz83OQgODz8/Pz8/Pz8/Pz8/NRYVBB UEEBQEFQAUAhUUEBQEFQQUFhUEFBQVBhUOFQYVBBUEEBQAFAYVBBUEEBQEFQQUFBUGFQAVEB QEFQwVBBQYFQQWFQQUEBEEBwkLDQ8BAxUbEwYHFxcXFxcTEAEEBwkLDQ8BAxUXGRsdHxETJS cpKy0vISM1Nzk7PTE4CA4PPz8/PzkIDg8/Pz8/Pz8/Pz8/Pz8/Pz8/NzMeDz8zHg8/Pz8/Pz 8/Pz8/Pz//Pzk+Dz8/Pzc5GA4PPz8/Pz8/Pz8/Pz8/Pz8/PzMzHg8/Mx4PPz8/Pz8/Pz8/Pz 8/OzEyACAkAAwUHCQsNDxETFRcZGx0fISEgCAklJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJ SUlJScnDAElJScnCAElJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSclFAgJJSUlJSUlJSclFAgJJ SUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSZIkFQIUAAggOEhYaHiImKi4uBgACCA4SFho eIiYqLjI2Oj4CBkpOUlZaXmJmam5ydmZSeDp6enpuUlA4Onp6enp6enp6enp6f/p6enp6VkZ 4OkZGeDp6enp6enp6enp6enp6YlIQODp6enp6UlA4Onp6enp6enp6enp6enp6enpORng6RkZ 4Onp6enp6enp6enp6enp6RAgAkAAwUHCQsNDxETFRcZGx0fISMlGAoLJycnJycnJycnJycnJ ycnJycnJycnJycnJycnJScOAycnJSYCAycnJycnJycnJycnJycnJycnJycnJyUlJAoLJycnJ ycnJyUlIAoLJycnJycnJycnJycnJycnJycnJycnJycnJycnJSULAAEAAwUHCQsNDxETFxcUA QADBQcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5OSQL/Ak9PT09Pz0UCT09PT09PT09PT09P T09PT09PxwBPz8gAT09PT09PT09PT09PT09PQQJPT09PT09HAgJPT09PT09PT09PT09PT09P T0/GAE/PyABPT09PT09PT09PT09PT54AERAAAggOEhYaHiImKi4yNjo+QkZKTh4SUFJSUlJS UlJSUlJSUlJSUlJSUlJSUlJSUlJSLgZQUlJGBlBSUlJSUlJSUlJSUlJSUlJSUlJSUlImElBS UlJSUlJSUlISEFBSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUiYGUFJSRgZQUlKiRIkSJUqU KFGiRIkSJUqUKFGiRInSIUAE/wSAAIKDhIWGh4iJiouMjY6PkJGSk40EBJSUlJSUlJSUlJSU lJSUlJSUlJSUlJSUlJSUlIcBlJSUkQGUlJSUlJSUlJSUlJSUlJSUlJSUlJSUhgSUlJSUlJSU lJSUhwSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSGAZSUlJEBgACCg4SFhoeIiYqLjI2O j5CRkpOUlZaXmJmam5ydiQQEnp6enp6enQQEnp6enp6enp6enp6enp6enp6ehAGenpEBnp6e np6enp6enp6enp6WBASenp6enp6egwSenp6enp6enp6enp6enp6enp6DAZ6ekQGenp6enp6e np6env+enjxVAkQACCA4SFhoeIiYqLjI2Oj4CBkpOUlpSEBQWVlZWVlZWVlZWVlZWVlZWVlZ WVlZWVlZCRlQWVnpGFBZWVlZWVlZWVlZWVlZWVlZWVlZOUlAUFlZWVlZWVlZWZlIUFlZWVlZ WVlZWVlZWVlZWVlZWVlZWVlZWfkYUFlZ6RhQWVlZWVmpUqVKlSpVqlSpUqVKlSpVkgSIABBA cJCw0PAQMVFxkbHR8REyUnKSkpGgsrKysrKysrKysrKysrKysrKysrKysrKy0jGgsrLSMaCy srKysrKysrKysrKysrKysrKyMpKgsrKysrKysrKy0pGAoLKysrKysrKysrL/srKysrKysrKy srKysrKSMaCystIxoLKysrKyslKlSpUqVapUqVKlSpUqVXoEiIAAEEBwkLDQ8BAxUXGRsdHx ETJScpIykqCysrKysrKysrKysrKysrKysrKysrKysrJyMaCystIxoLKysrKysrKysrKysrKy srKysrLSkaCysrKysrKysrKSkqCysrKysrKysrKysrKysrKysrKysrKysrJSMaCystIxoLKy srKysrJSpUqVKlWqVKlSpUqVKjUCRAAIIDhIWGh4iJiouMjY6PgIGSk5SVkJQEBgaWlpaWlp aWlpaWlpaWlpaWlpaWlpaWlZGGBpabkYYGlpaWlp/2lpaWlpaWlpaWlpaWnpSGBpaWlpaWlp aWn5SGBpaWlpaWlpaWlpaWlpaWlpaWlpaWlpaUkYYGlpuRhgaWlpaWlpaWnJkiVLlixZsmTJ kqVGgAgAAQQHCQsNDxETFRcZGx0fISMlJykrDQkILC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t BQMsLS0XAywtLS0tLS0tLS0tLS0tLS0tLS0XCQgsLS0tLS0tLS0tKQksLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0BAiwtLRcDLC0tLS0tLS1ZsmTJkiVLlixZsmRJESACQADBQcJCw0PERMVF xkbHR8hIyUnKSkYCS0tLS/9LS0tLS0tLS0tLS0tLS0tLS0tLywBLS8vFAEtLS0tLS0tLS0tL S0tLS0tLS8tEAktLS0tLS0tLS0vLQQICS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0vKAEtLy8UA S0tLS0tLS0tLS5YsWbJkyZIlS5YQASIABBAcJCw0PERMVFxkbHR8hIyUnKSsjCSwtLS0tLS0 tLS0tLS0tLS0tLS0tLS0tJwMsLS0XAywtLS0tLS0tLS0tLS0tLS0tLS0NCQgsLS0tLS0tLS0 tLREJLC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0lAywtLRcDLC0tLS0tLS0tLRkyZIlS5YsWbJk qRD/IAJAAMFBwkLDQ8RExUXGRsdHyEjJScpKSwICS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0vI AEtLy8UAS0tLS0tLS0tLS0tLS0tLS0tLS0ICS0tLS0tLS0tLS0tHAktLS0tLS0tLS0tLS0tL S0tLS0tLS0vLxwBLS8vFAEtLS0tLS0tLS0uWLFmyZMmSJUuWBgEiAAQQHCQsNDxETFRcZGx0 fISMlJykrLQsJLi8vLy8vLy8vLy8vLy8vLy8vLy8vLx0DLi8vEQMuLy8vLy8vLy8vLy8vLy8 vLy8NCS4vLy8vLy8vLy8vDwkILi8vLy8vLy8vLy8vLy8vLy8vLy8vLxk/wy4vLxEDLi8vLy8 vLy8vLy8vHTp0qVLly4RAkRAAAggOEhYaHiImKi4yNjo+AgZKTlJWWmpSHB5eXl5eXl5eXl5 eXl5eXl5eXl5eXm5GHB5eYkYcHl5eXl5eXl5eXl5eXl5eXl5OUhweXl5eXl5eXl5edlIcHl5 eXl5eXl5eXl5eXl5eXl5eXl5eakYcHl5iRhweXl5eXl5eXl5eXl56dKlS5cuCQJEAAggOEhY aHiImKi4yNjo+AgZKTlJWWn5SHB5eXl5eXl5eXl5eXl5eXl5eXl5eXmZGHB5eYkYcHl5eXl5 eXl5eXl5eXl5eXl5CUBweXl5eXl5eXl5eRlJcP95eXl5eXl5eXl5eXl5eXl5eXl5eXmJGHB5 eYkYcHl5eXl5eXl5eXl5eenSpUuXLgEiAAQQHCQsNDxETFRcZGx0fISMlJykrLScJCC4vLy8 vLy8vLy8vLy8vLy8vLy8vLy8NAy4vLxEDLi8vLy8vLy8vLy8vLy8vLy8tCS4vLy8vLy8vLy8 vLQkuLy8vLy8vLy8vLy8vLy8vLy8vLy8vCwMuLy8RAy4vLy8vLy8vLy8vLy8dOnSpUuVABEA AggOEhYaHiImKi4yNjo+QkZKTlJWWl4CEGBiYmJiYmJiYmJiYmJiYmJiYmJiYhoGYGJiFgZg YmJiYmJiYmJiYmJiYmL/YmIOEmBiYmJiYmJiYmJiPhJgYmJiYmJiYmJiYmJiYmJiYmJiYmIW BmBiYhYGYGJiYmJiYmJiYmJiYmJiwoRJECACQADBQcJCw0PERMVFxkbHR8hIyUnKSsvLQgIC TExMTExMTExMTExMTExMTExMTEzMwQBMTMzCAExMTExMTExMTExMTExMTExMAAJMTExMTExM TExMTEoCTExMTExMTExMTExMTExMTExMTExMwQBMTMzCAExMTExMTExMTExMTExMmDBhAkQA CCA4SFhoeIiYqLjI2Oj4CBkpOUlZaXmpSICJiYmJiYmJiYmJiYmJiYmJiYmJiQkQgImJWRiA /4mJiYmJiYmJiYmJiYmJiXlJgImJiYmJiYmJiYmJSYCJiYmJiYmJiYmJiYmJiYmJiYmJiRmA iYlZGICJiYmJiYmJiYmJiYmJiYlpCRABIIDgIGGh4SFiouIiY6PjI2Sk5CRlpeWlIwEmJiYm JiYmJiYmJiYmJiYmJiYm5mUAJiZmYQAmJiYmJiYmJiYmJiYmJiZmJQEmJiYmJiYmJiYmJiYh AQEmJiYmJiYmJiYmJiYmJiYmJiYmZmUAJiZAAGFAQABhQGFAYgAmJiYmJiYmTJgwYcKECRMm TJQAEQACCA4SFhoeIiYqLjI2Oj5CRkpOUlZaXk4SYGJiYmJiYmJiYv9iYmJiYmJiYmJiUgZg YgYEDAYMBggGAAQMBgAEIAZgYmJiYmJiYmJiYmJiYmJiThJgYmJiYmJiYmJiYmImEmBiYmJi YmJiYmJiYmJiYmJiYmJiTgZgXgYABAwGAAIIBgAECAIEAAQIAgQICgoCBAACCA4SFhoeIiYq LjI2Oj5CRkpOUlZaXmJmam5iEnBycnJycnJycnJOEnBycnJycnJycnJycnJycnJyWgZwVgYQ BgQECAYMBgAEDAYcAgYIDhIWCgICCA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam4eEnBycnJy cnJycnJWEnBycnJycnJycnJycnJycnJyFgL/BggOEhYKAgIIDhIWGh4iJhIGDAYMBgAEDAYA BAwGHAYAAggOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpuWhJwcnJycnJycnJyXhJwcnJycnJy cnJycnJycnJyclIGcFYGDAYMBgAEDAYABAwGHAZwcnJycnJycnJycnJych4ScHJycnJycnJy cmYScHJycnJycnJycnJycnJycnJOBnBWAgYAAAAEAAAABAAABAAEAAAABAAEAAIIDgoGAAII DhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqblIScHJycnJycnJycm4SEHBycnJycnJycnJycnJy cnJyRgZwTgIGCAoC/wAMAgAAAAQAAggKBgwODgYAAggOEhYaHiImKi4yNjo+QkZKTlJWWl5i ZmpuThJwcnJycnJycnJycgoScHJycnJycnJycnJycnJycnJCBnByVgZwcnJycnJycnJycnJy chIScHJycnJycnJycnISEnBycnJycnJycnJycnJycnJyPgZwclYGcHJycnJycnJycnLixInT IEAEgACCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmI4EmZmZmZmZmZmZmZmZmZmZmZmZmY8BmZmZ ggGZmZmZmZmZmZmZmZmZmZmTBJmZmZmZmZmZmZmZmZAEmZmZmZmZmZmZmZmZmZmZmZmZmf+O AZmZmYIBmZmZmZmZmZmZmZmZmZmZkgSAAIKDhIWGh4iJiouMjY6PkJGSk5SVlpeYkgSZmZmZ mZmZmZmZmZmZmZmZmZmZjQGZmZmCAZmZmZmZmZmZmZmZmZmZmZEEmZmZmZmZmZmZmZmZlASZ mZmZmZmZmZmZmZmZmZmZmZmZjAGZmZmCAZmZmZmZmZmZmZmZmZmZmZAEgACCg4SFhoeIiYqL jI2Oj5CRkpOUlZaXmJYEmZmZmZmZmZmZmZmZmZmZmZmZmYsBmZmZggGZmZmZmZmZmZmZmZmZ mZmPBJmZmZmZmZmZmZmZmZgEmZmZmZmZmZmZmZmZmZmZmZmZmYr/AZmZmYIBmZmZmZmZmZmZ mZmZmZmZjgSAAIKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmQAEmpqampqampqampqampqampqa kAGampkBmpqampqampqampqampqYBJqampqampqampqampAEmpqampqampqampqampqampqa jwGampkBmpqampqampqampqampqYBJqampqampo0adKkSVMkQASAAIKDhIWGh4iJiouMjY6P kJGSk5SVlpeYmZqbnJ2ekQGfn48Bn5+fn5+fn5+fn5+fjwSfn5+fn4qAA4KDhIWGA4AAgoOE hYaHiImKi4yNjo+QiASRkZGRkZGRkZGR/5GRkZGRkZGRkZGRkZGRkZGRkYUBkZGRkYkBkZGR kZGRkZGRkZGRkZGRkZGRkZGRkYwEkZGRkZGRkZGRgoADgoOEA4AAgoOEhYYAgAOCg4QDgACC g4SFhoeIiYqLjI2Oj44EkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQAZCQkJCNAZCQ kJCQkJCQkJCQkJCQkJCQkJCQkJCQkAAEkJCQkJCQkJCQhIADgoOCgACCg4SFhoeIiIADgoOC gACCg4SFhoeIiYqLjI2Oj4cEkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCPAZCQkJCN AZCQkJCQkJCQkP+QkJCQkJCQkJCQkJCQkJAEkJCQkJCQkJCPgAOCg4AAgoOEhYaHiImKhYAD goOAAIKDhIWGh4iJiouMjY6PggSQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkI4BkJCQ kI0BkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCPBJCQkJCQkJCQi4ADgoKAAIKDhIWGh4iJiouG gAOCgoAAgoOEhYaHiImKi4yNjo0Ej4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4wB j4+Pj4+CAY+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+HBI+Pj4+Pj4+PjoADgoOAAIL/g4SF hoeIiYqLjISAA4KDgACCg4SFhoeIiYqLjI2OiASPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+P j4+Pj4+PiwGPj4+Pj4IBj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4YEj4+Pj4+Pj4+LAwMD A4+Pj4+Pj4QDAwMDj4+Pj4+Pj4UEj4+Pj4+Pj4+Pj4+PHj169OjRo0ePHj169OjRo0ePHj16 pAhQACCA4CBhoeEhYqLi4mIAIIDgIGGh4SFiouIiY6PjI2Sk5CRlpeUlZqbmpiABJycnJ+TA wMAAJyen5MDAwAAnJ+clAScnJycnJycnJycnJycnJ6dmACdn/2UAJycnJycnJycnJycnJyQB JycnJ+PAwMAAJyen5sDAwAAnJyclAScnJycnJycnJycnJycnJ2cmoABAAMFBwkLDQ8RExcXF AEAAwUHCQsNDxETFRcZGx0fISMlJykrLS8xMzU0AAk5OTk7FgYEBTk5OTsOBgQFOTk5JAk5O Tk5OTk5OTk5OTk5OTk7MAE7OygBOTk5OTk5OTk5OTk5ORwJOTk7Ow4GBgQFOTk5OxoGBgQFO Ts5HAk5OTk5OTk5OTk5OTk5OTs5LQAGAAIKDhIWGh4iJiouLAYAAgoOEhYaHiImKi4yNjo+Q kZKTlJWWl5iZmpoEm5ubm4gDAwMDm/+bm5uYAwMDA5ubm48Em5ubm5ubm5ubm5ubm5ubm5uL AZublwGbm5ubm5ubm5ubm5ubmQSbm5ubhgMDA5ubm5ubhQMDA5ubm40Em5ubm5ubm5ubm5ub m5ubm5sUAQoABBAcJCw0PERMVFxcDAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1MQk2Nzc 3CwcGNjc3NzcXBwYGNjc3Fwk2Nzc3Nzc3Nzc3Nzc3Nzc3NxMDNjcvAzY3Nzc3Nzc3Nzc3Nzc xCTY3NzcHBwY2Nzc3NyEHBjY3NxUJNjc3Nzc3Nzc3Nzc3Nzc3NzcRAwABBAcJCw0PERMVFxc DAAEEBwkLDT/PERMVFxkbHR8hIyUnKSstLzEzNS8JNjc3NwUHBjY3Nzc3KQcGBjY3NxEJNjc 3Nzc3Nzc3Nzc3Nzc3NzcPAzY3LwM2Nzc3Nzc3Nzc3Nzc3LQk2Nzc3AQYGNjc3NzczBwYGNjc 3DQk2Nzc3Nzc3Nzc3Nzc3Nzc3Nw0BAwABBAcJCw0PERMVFxcDAAEEBwkLDQ8RExUXGRsdHyE jJScpKy0vMTM1Kwk2Nzc1BwYGNjc3Nzc3BwcGNjc3Cwk2Nzc3Nzc3Nzc3Nzc3Nzc3NwsDNjc vAzY3Nzc3Nzc3Nzc3NzcpCTY3NzEHBgY2Nzc3NzcRBwY2NzcJCTY3Nzc3Nzc3Nzc/9zc3Nzc 3NwkBAwABBAcJCw0PERMVFxcDAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1Jwk2NzcvBwY 2Nzc3NzcbBwY2NzcHCTY3Nzc3Nzc3Nzc3Nzc3Nzc3BwM2Ny8DNjc3Nzc3Nzc3Nzc3NycJNjc 3KQcGBjY3Nzc3NyMHBjY3NwUJNjc3Nzc3Nzc3Nzc3Nzc3NzcFAwABBAcJCw0PERMVFxcDAAE EBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1JQk2NzcnBwY2Nzc3NzctBwYGNjc3CTY3Nzc3Nzc 3Nzc3Nzc3Nzc3AQI2Ny8DNjc3Nzc3Nzc3Nzc3NyMJNjc3P+UHBjY3Nzc3NzcHBjY3Mwk2Nzc 3Nzc3Nzc3Nzc3Nzc3NwECNjcvAQUAAggOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmpCUmwubkZ OTCwubm5ubm5STgwsLmJSbC5ubm5ubm5ubm5ubm5ubm5GbC5eRmwubm5ubm5ubm5ubm5+Uiw ubkZObC5ubm5ubmJODCwuXlJsLm5ubm5ubm5ubm5ubm5uakZsLl5GQAIIDhIWGh4iJiouMjY 6PgIGSk5SVlpeYmZqflIsLm5+TgwsLm5ubm5ubk4MLC5aUmwubm5ubm5ubm5ubm5ubm5mRmw uXkZsLm5ubm5ubm5ubm5uelIsLn/uek4MLC5ubm5ubn5ODCwuVlJsLm5ubm5ubm5ubm5ubm5 uYkZsLl5CRgACCA4SFhoeIiYqLjI2Oj4CBkpOUlZaXmJmanZSLC5uek4sLm5ubm5uTk5MLC5 SUmwubm5ubm5ubm5ubm5ubm5eRmwuXkZsLm5ubm5ubm5ubm5uclIsLm52TgwsLm5ubm5uWk5 MLC5OUmwubm5ubm5ubm5ubm5ubm5aRmwuXkZAAggOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmp yUiwubm5ODCwubm5ubm5qTkwsLkpSbC5ubm5ubm5ubm5ubm5ublZGbC5eRmwubm5ubm5ubm5 ubm5uUiw/7m5qTgwsLm5ubm5ubk5ODCwuRlJsLm5ubm5ubm5ubm5ubm5uUkZsLl5CSgAEEBw kLDQ8BAxUXGRsdHxETJScpKy0vISM1NTkWBzczNxYGBzc3Nzc3Nz83BgYHMTkmBzc3Nzc3Nz c3Nzc3Nzc3NzMmBz8zJgc3Nzc3Nzc3Nzc3NzM5Fgc3MTcWBgc3Nzc3Nzc3NxYHMTkmBzc3Nz c3Nzc3Nzc3Nzc3NTMmBz8xJQACCA4CBhoeEhYqLiImOj4yNkpOQkZaXlJWamZiLB5ubm4cDm 5ubm5ubmpuPAwObmI8Hm5ubm5ubm5ubm5ubm5uZmZMDm5mXA5ubm5ubm5ubm5v/m5iYiwebm puHAwObm5ubm5uZm5MDA5mYjwebm5ubm5ubm5ubm5ubm5mZkwObmJaAAQADBQcJCw0PERMVF xkbHR8hIyUnKSstLzEzNQ4LNzc3CgYHNzc3Nzc3NzcqBgc1NRoLNzc3Nzc3Nzc3Nzc3Nzc1N yIDNzcuAzc3Nzc3Nzc3Nzc3NTUOCzc1NwoGBzc3Nzc3Nzc3MgYHNzUWCzc3Nzc3Nzc3Nzc3N zc3NzceAzc1LgAIAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzUNCTY3NwUHBjY3Nzc3Nzc3 NwUHBjY3FQk2Nzc3Nzc3Nzc3Nzc3Nzc3HQM2Ny8DNjf/Nzc3Nzc3Nzc3NzcLCTY3NwEGBjY3 Nzc3Nzc3Nw0HNjcVCTY3Nzc3Nzc3Nzc3Nzc3NzcbAwABBAcJCw0PERMVFxcDAAEEBwkLDQ8R ExUXGRsdHyEjJScpKy0vMTM1CQk2NzcBBjY3Nzc3Nzc3NxMHBjY3Ewk2Nzc3Nzc3Nzc3Nzc3 Nzc3GQM2Ny8DNjc3Nzc3Nzc3Nzc3NwcJNjc3BwY2Nzc3Nzc3NzcZBwY2NxEJNjc3Nzc3Nzc3 Nzc3Nzc3NxcDNjcvAQoABBAcJCw0PERMVFxkbHR8hIyUnKSstLzEzNQcJNjc1BzY3Nzc3Nzc 3NyEHBjY3Dwk2Nzc3Nzc3Nzc/9zc3Nzc3NxUDNjcvAzY3Nzc3Nzc3Nzc3NzcFCTY3MwcGNjc 3Nzc3Nzc3JwcGNjcNCTY3Nzc3Nzc3Nzc3Nzc3NzcTAzY3LwEFAAIIDhIWGh4iJiouMjY6PgI GSk5SVlpeYmZqQlAsLmJOTCwubm5ubm5ubl5OTCwuUlIsLm5ubm5ubm5ubm5ubm5uZkYsLl5 GbC5ubm5ubm5ubm5ublJsLmJObC5ubm5ubm5ubk5sLlJSLC5ubm5ubm5ubm5ubm5ubmJGLC5 eRkACCA4SFhoeIiYqLjI2Oj4CBkpOUlZaXmJmalJoKmJOTCgqampqampqampyTgwoKlZSKCp qampqf+pqampqampqampeRmgqZkZoKmpqampqampqampqclIoKmJOaCpqampqampqakJOaCp WUigqampqampqampqampqampaRmgqZkJKAAQQHCQsNDwEDFRcZGx0fERMlJykrLS8hIzE5NA U/NyYEBTU1NTU1NTU1NTcmBAU5OQQFNTU1NTU1NTU1NTU1NTU7MyQFMzM0BTU1NTU1NTU1NT U1NzkUBT03JAU1NTU1NTU1NT03JgQFNzkEBTU1NTU1NTU1NTU1NTU1OTMkBTMxOgAEAAwUHC QsNDxETFRcZGx0fISMlJykrLS8zMSwJNTcsBTU1NTU1NTU1NzcwBTU1BAk3/TU1NTU1NTU1N TU1NTU1NygBNzcwATU1NTU1NTU1NTU1NzUQCTc3KgQFNTU1NTU1NTU1NTYCBAU1NAAJNTU1N TU1NTU1NTU1NTU3NyQBNzUyAAgABBAcJCw0PERMVFxkbHR8hIyUnKSstLzEzKwk0NSsHNDU1 NTU1NTU1NTULBzQ1AQg0NTU1NTU1NTU1NTU1NTU1JQM0NTMDNDU1NTU1NTU1NTU1NREJNDUp BzQ1NTU1NTU1NTU1DwcGNDUJNDU1NTU1NTU1NTU1NTU1NSMDNDUzAQUAAggOEhYaHiImKi4y Njo+QkZKTlJWWl5iZlISaGpODgxoampqampqampq/2oqDmhqEmhqampqampqampqampqampC BmhqZgZoampqampqampqampqGhJoak4OaGpqampqampqamo2DmhqEmhqampqampqampqampq amo+BmhqZgIGAAIIDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZKEmhqTg5oampqampqampqaj4O DGhmEmhqampqampqampqampqamo6BmhqZgZoampqampqampqampqFhJoakYODGhqampqampq ampqSg5oYhJoampqampqampqampqampqOgZoamYCCgAEEBwkLDQ8RExUXGRsdHyEjJScpKy0 vMTMjCTQ1Iwc0NTU1NTU1P/U1NTUrBzQxCTQ1NTU1NTU1NTU1NTU1NTUbAzQ1MwM0NTU1NTU 1NTU1NTU1Bwk0NSMHNDU1NTU1NTU1NTUvBwY0Lwk0NTU1NTU1NTU1NTU1NTU1GQM0NTMBAwA BBAcJCw0PERMVFxkbHR8hIyUnKSstLzEzHwk0NSMHNDU1NTU1NTU1NTU1BzQvCTQ1NTU1NTU 1NTU1NTU1NTUXAzQ1MwM0NTU1NTU1NTU1NTU1BQk0NSEHNDU1NTU1NTU1NTU1BQcGNC0JNDU 1NTU1NTU1NTU1NTU1NRUDNDUzAQUAAggOEhYaHiImKi4yNjo+AgZKTlJWWl5iZnpSKCp+Tgw oKn/qampqampqampqVk4oGlJoKmpqampqampqampqampqZkYoKmZGaCpqampqampqampqalJ oKn5OKCpqampqampqampqYk4oFlJoKmpqampqampqampqampqZkYoKmZCSgAEEBwkLDQ8BAx UXGRsdHxETJScpKy0vISM7ORQFPTcUBTU1NTU1NTU1NTU1NxYECTkkBTU1NTU1NTU1NTU1NT U1MTMUBTMzNAU1NTU1NTU1NTU1Mzk0BT03FAU1NTU1NTU1NTU1OzcUCTkkBTU1NTU1NTU1NT U1NTU1PzMEBTMxNQACCA4CBhoeEhYqLiImOj4yNkpOQkZaXlJWbmIoGm/2bjwICmpqampqam pqampubjgCYlgaampqampqampqampqampqZhgKZmZoCmpqampqampqampiYmgaYm44Cmpqam pqampqampqbkwIDmJIGmpqampqampqampqampqZmYYCmZiZAAYAAgoOEhYaHiImKi4yNjo+Q kZKTlJWWl5iZigSamowDmpqampqampqampqalQOakwSampqampqampqampqampqahAGampkB mpqampqampqampqalgSamowDmpqampqampqampqalwMDmpEEmpqampqampqampqampqamoQB mpqZgAIAAQQHCQsNDxETFRcZGx0fISMlJykrLf8vMTMTCTQ1Fwc0NTU1NTU1NTU1NTU1BzQj CTQ1NTU1NTU1NTU1NTU1NTUHAzQ1MwM0NTU1NTU1NTU1NTUrCTQ1FQcGNDU1NTU1NTU1NTU1 NQUHNCMJNDU1NTU1NTU1NTU1NTU1NQUDNDUzAQoABBAcJCw0PERMVFxkbHR8hIyUnKSstLzE zEQk0NRMHNDU1NTU1NTU1NTU1NQsHBjQhCTQ1NTU1NTU1NTU1NTU1NTUBAjQvAwoDAgIGAwo DEgM0NTU1NTU1NTU1NTUpCTQ1Ewc0NTU1NTU1NTU1NTU1EQc0Hwk0NTU1NTU1NTU1NSkSZMm TZoAAAoABBAcJCw0PET/TBwMCCAMKAwACBgMAAhADAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0 vMTMNCTQ1Ewc0NTU1NTU1NTU1NTU1FQc0Hwk0NTU1NTU1NTU1NTU1NTU1AzQrAwACBgMKAwY DAAIGAw4DNDU1NTU1NTU1NTU1Jwk0NREHNDU1NTU1NTU1NTU1NRkHBjQdCTQ1NTU1NTU1KRJ kyZNmjRpygQoABBAcJCw0PAQMZEwYDAgICBAMGAwACBgMOAQMEBwkLBQEBBAcJCw0PAQMVFx kbHR8REyUnKSstLyEtORIDNTcSAzMzMzMzMzMzMzMzMzc3Ag85EgMzMzMzMzMzMzMzMzMzPz /xIwQHCQsFAQEEBwkLDQ8BAxkTBgMGAwACBgMAAgYDDgMAAQQHCQsNDwEDFRcZGx0fERMlJy krLS8hIzk5BAUxNxQFNTU1NTU1NTU1NTUzNyQLORQFNTU1NTU1NTU1NTU1NTEzNA8zJgMGAw ACBgMAAgYDDgMEBTU1NTU1NTU1NTUzOSQFPTcGBAU1NTU1NTU1NTU1NTc3JgQJORQFNTU1NT U5MmTZo0adKkSdMlQAGAAIKDhIWGh4iJhAGDAYMBggEAAYMBAAGIAYAAgoOEhYaHiImKi4yN jo+QkZKTlJWWl5iZgwSamoYDmpqampqampqampqampcDmowEmpqamv+ampqampqampqampYB mpWAAYKCAACDAAAAAAGAAIKCAYODgwGAAIKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmYIEmpqG A5qampqampqampqampqZA5qMBJqampqampqampqampqampUBmpqZAZqampqampqampqamo8E mpqFA5qampqampqampqampqaAAOajASampqampqampqampqampqUAZqamYACAAEEBwkLDQ8R ExUXGRsdHyEjJScpKy0vMTMBCDQ1Cwc0NTU1NTU1NTU1NTU1NQcHNBcJNDU1NTU1NTU1NTU1 NTU1KQM0NTMDNDU1NTU1NTU1NTU1Gwk0NQv/BzQ1NTU1NTU1NTU1NTU1CwcGNBUJNDU1NTU1 NTU1NTU1NTU1JwMAAQQHCQsNDxETFRcXAwABBAcJCw0PERMVFxkbHR8hIyUnKSstLzEzCTIz DQcyMzMzMzMzMzMzMzMzMy0HMhcJMjMzMzMzMzMzMzMzMzMzMxEDMjMzBQMyMzMzMzMzMzMz MzMxCTIzDQcyMzMzMzMzMzMzMzMzMzEHMhcJMjMzMzMzMzMzMzMzMzMzMw8BAwABBAcJCw0P ERMVFxcDAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMS8JMjMNBzIzMzMzMzMzMzMzMzMzMwEG MhcJMjMzMzMzMzMz/zMzMzMzMzMNAzIzMwUDMjMzMzMzMzMzMzMzLwkyMwsHMjMzMzMzMzMz MzMzMzMzBwcyFQkyMzMzMzMzMzMzMzMzMzMzDQEKAAQQHCQsNDxETFRcXAwABBAcJCw0PERM VFxkbHR8hIyUnKSstLzEtCTIzCQcGMjMzMzMzMzMzMzMzMzMzCwcyFQkyMzMzMzMzMzMzMzM zMzMzCwMyMzMFAzIzMzMzMzMzMzMzMy0JMjMHBzIzMzMzMzMzMzMzMzMzMxEHMhUJMjMzMzM zMzMzMzMzMzMzMxECFAAIIDgIGGh4SFiouLiYgAggOAgYaHhIWKi4iJjo+MjZKTkJGWl5f8l ZiVBZubgQGZmZmZmZmZmZmZmZmZmpuLAQGYiQWZmZmZmZmZmZmZmZmZmZuZgQGZmpmBAZmZm ZmZmZmZmZmYmJUFm5uBAZmZmZmZmZmZmZmZmZmZm40AmIkFmZmZmZmZmZmZmZmZmZmamQYAC AAEEBwkLDQ8RExUXFwMAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xKQkyMwUHMjMzMzMzMzMz MzMzMzMzHwcyEQkyMzMzMzMzMzMzMzMzMzMzBQMyMzMFAzIzMzMzMzMzMzMzMycJMjMFBzIz MzMzMzMzMzMzMzMzMyMHMhEJMjMzMzMzMzMzMzMzMzMzMwEACgD/BBAcJCw0PERMVFxcDAAE EBwkLDQ8RExUXGRsdHyEjJScpKy0vMSUJMjMFBzIzMzMzMzMzMzMzMzMzMycHMhEJMjMzMzM zMzMzMzMzMzMzMwMyMzMFAzIzMzMzMzMzMzMzMyUJMjMBBjIzMzMzMzMzMzMzMzMzMysHMhE JMjMzMzMzMzMzMzMzMzMzMQEDAAEEBwkLDQ8RExUXFwMAAQQHCQsNDxETFRcZGx0fISMlJyk rLS8xIwkyMwEGMjMzMzMzMzMzMzMzMzMzLwcyDwkyMzMzMzMzMzMzMzMzMzMxAzIzMwUDMjM zMzMzMzMzMzMzIQkyMwEGMjMzMzMzMzM/8zMzMzMzMzMHMg8JMjMzMzMzMzMzMzMzMzMzLwE DAAEEBwkLDQ8RExUXFwMAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xIQkyMwcyMzMzMzMzMzM zMzMzMzMzBQcyDwkyMzMzMzMzMzMzMzMzMzMtAzIzMwUDMjMzMzMzMzMzMzMzHwkyMwcyMzM zMzMzMzMzMzMzMzMzCQcyDwkyMzMzMzMzMzMzMzMzMzMrAQMAAQQHCQsNDxETFRcXAwABBAc JCw0PERMVFxkbHR8hIyUnKSstLzEfCTIzBzIzMzMzMzMzMzMzMzMzMzMLBwYyDQkyMzMzMzM zMzMzMzMzMzMpP8MyMzMFAzIzMzMzMzMzMzMzMx0JMjMHMjMzMzMzMzMzMzMzMzMzMxEHMgs JMjMzMzMzMzMzMzMzMzMzKQEFAAIIDhIWGh4iJiouLgYAAggOEhYaHiImKi4yNjo+AgZKTlJ WWl5idlIkJk5kJmZmZmZmZmZmZmZmZmZmak4kFlIkJmZmZmZmZmZmZmZmZmZORmQmZkpGJCZ mZmZmZmZmZmZmdlIkIk5kJmZmZmZmZmZmZmZmZmZmck4kFlIkJmZmZmZmZmZmZmZmZmZKQkY AAggOEhYaHiImKi4uBjAyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyEjAyMjICDAACCD/OEhY aHiImKi4yNjo+AgZKTlJWWl5iZmpucmJONAJQNDZ2dnZ2dnZ2dnZ2dn5GNDZORnQ2dnZ2dnZ 2dnZWUnQSTnQ2dnZ2dnZ2dnZ2dnZ2ak40EnQ2dnZ2dnZ2dnZ2dnZ+RjQ2TkZ0NnZ2dnZ2dnZ 2VlJ0Dk50NnZ2dnZ2dnZqVOnTp06MQI0AAggOEhYaHgIQAAIIDhIWGh4iJiouMjY6PgIGSk5 SVlpeYmZqbnZGMDJWRnAycnJycnJycnJySlIwEk5wMnJycnJycnJycnJycnJOcAJQMDJycnJ ycnJycnJycmpGcDJWRnAycnJycnJycnJySlIwDk5wMnJycnJ/8nJycnJycnJySk4wAlAwMnJ ycmJEydOnDhx4sQpE6AAQADBQcJCw0PERMXFxQBGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkbG RAJGRsbFAUAAwUHCQsNDxETFRcZGx0fISMlJykrLS8xMzU1OyYFOgs7Ozs7Ozs7Ozs7Ozs7F gM7OyYDOzs7Ozs7Ozs5OSYJOyYHOzs7Ozs7Ozs7Ozs7OTsoBToLOzs7Ozs7Ozs7Ozs7OxYDO zsmAzs7Ozs7Ozs7OTkmCzsiBzs7Ozs7Ozs7OTp06depkCdAAIIDgIGGh4SEBIIDgIGGh4SFi ouIiY6PjI2Sk5CRlpeUlZqbmZmIAJ/9nZQAnJycnJycnJyfnJgHn5AAnJycnJycnJycnJycn J2fiACcBJycnJycnJycnJycnp2UAJ2dlACcnJycnJycnJ+cmAafkACcnJycnJycnJycnJycn 5+IAJwEnJycnJycnJ06cOHHiVAlQACCA4CBhoeEhYqLi4mIAIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjoyEBIyOj4gAggOAgYaHhIWKi4iJjo+MjZKTkJGWl5SVmpuYm5+YAJ0FnZ2dnZ2dn Z2dnZ2fnYUBn52RAZ2dnZ2dnZ2dn5yNBZ+RAZ2dnZ2dnZ2dnZ2dnZ2fnwCZBZ2dnZ2dnZ2dn Z2dn52FAZ+f/ZEBnZ2dnZ2dnZ2fnI0En5EBnZ2dnZ2dnZ2enTp06deokCNAAIIDgIGGhoSEB IIDgIGGh4SFiouIiY6PjI2Sk5CRlpeUlZqbmZmEAJ2dlACcnJycnJycnJycmAWfkACcnJycn JycnJycnJycn5+TAJgEnJycnJycnJycnJyenZAAnZ2UAJycnJycnJycnJyYBJ+QAJycnJycn JycnJycnJydn5cAmAScnJycnJycnTpw4ceIUCVAAIIDgIGGh4SFiouLiYgAjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyPjIAEjIyPiACCA4CBhoeEhYqLiImOj4yNkpOQkZaXlJWam/+YmZyfi gCaBp6enp6enp6enp6dnZYCnZ2SAp6enp6enp6en5yCBZ+OAp6enp6enp6enp6enp2fmwEAm gaenp6enp6enp6enJ2WAp2dkgKenp6enp6enp6cggWfjgKenp6enp6enpydPnjx54gRoABBA cJCw0JCQABBAcJCw0PAQMVFxkbHR8REyUnKSstLyEjNTcxMggJOzMoCTk5OTk5OTk5OzkoDz cYCTk5OTk5OTk5OTk5OTk5NTcCCTgJOTk5OTk5OTk5OTk9MxgJOzMoCTk5OTk5OTk5OzkoDT cYCTk5OTk5OTk5OTk5OTk5OTcACTgJOTk5OTEydOnDhx4v/EyRGgAEAAwUHCQsNDxETFxcUA RkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRgJGRsbDAUAAwUHCQsNDxETFRcZGx0fISMlJykrL S8xMzU3OTskBTAJPT09PT09PT09PT8/IAE/PyABPT09PT09PT09PAk/GAU9PT09PT09PT09P T09Pz8IBTAJPT09PT09PT09PT0/IAE/PyABPT09PT09PT89OAk/GAU9PT09PT09PT09PT548 eToEaAAQQHCQsNBwkAAQQHCQsNDwEDFRcZGx0fERMlJykrLS8hIzUxMzYHPzMmBzc3Nzc3Nz c3NzE4Bg83Fgc3Nzc3Nzc3Nzc3P/c3Nzc3Nz4JJgc3Nzc3Nzc3Nzc3NzEzNgc/MyYHNzc3Nz c3Nzc3MTgGDTcWBzc3Nzc3Nzc3Nzc3Nzc3NzU3DgkmBzc3PTpk2bNm3atGnTpkuAAgABBAcJ Cw0PERMVFxcDGBkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZEwkYGRkLBwABBAcJCw0PERMVFxkb HR8hIyUnKSstLzEzNTc5OzkHLgk8PT09PT09PT09PT0bAzw9IwM8PT09PT09PT03CTwVBzw9 PT09PT09PT09PT09PR8HLgk8PT09PT09PT09PT0ZAzw9IwM8PT09PT09PT01CTwVBzw9PT09 PT09PT09/z158uQpEqABQADBQcJCQwACQADBQcJCw0PERMVFxkbHR8hIyUnKSstLzEzNyoDN zcuAzc3Nzc3Nzc3NTU2CTcaBzc3Nzc3Nzc3Nzc3Nzc3NzU3FAUuCzc3Nzc3Nzc3Nzc3NTcqA zc3LgM3Nzc3Nzc3Nzc1Mgs3Ggc3Nzc3Nzc3Nzc3Nzc3Nzc3NxQFLgs3Nzc1NmzZt2rRp06ZN kwAFAAIIDhIWGh4iJiouLgYwMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIaEjAyMhIOAAIIDhIW Gh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2eh4OWBJ8fn5+fn5+fn5+fnIGfH4+Bv98fn5+fn5+ fn4+EnwiDnx+fn5+fn5+fn5+fn5+fiYOVBJ8fn5+fn5+fn5+fnIGfH4+Bnx+fn5+fn5+fjoS fCIOfH5+fn5+fn5+fn5+fvr0aRGgAUAAwUHCQkMCQADBQcJCw0PERMVFxkbHR8hIyUnKSstL zEzNyIDNzcuAzc3Nzc3Nzc3NzUuCzcWBzc3Nzc3Nzc3Nzc3Nzc3Nzc3JgUqCzc3Nzc3Nzc3N zc3NTciAzc3LgM3Nzc3Nzc3NzU1Lgs3Fgc3Nzc3Nzc3Nzc3Nzc3Nzc3NyoFKgs3Nzc1NmzZt 2rRp06ZNjwAFAAIIDhIWGh4iJiouLgYwMjIyMjIyMjL/MjIyMjIyMjIyMjIyMjIyEhIwMjIK DgACCA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnpCDlASfH5+fn5+fn5+fn5mBnx+PgZ8 fn5+fn5+fn4yEnweDnx+fn5+fn5+fn5+fn5+fkoOUBJ8fn5+fn5+fn5+fmIGfH4+Bnx+fn5+ fn5+fi4SfB4OfH5+fn5+fn5+fn5+fvr0iRKgAUAAwUHCwkICQADBQcJCw0PERMVFxkbHR8hI yUnKSstLzEzNxoDNzcuAzc3Nzc3Nzc3NTUqCTcWBzc3Nzc3Nzc3Nzc3Nzc3Nzc1NgAFKgs3N zc3Nzc3Nzc3NzU3GgM3Ny4DN/83Nzc3Nzc3NzUmCTcWBzc3Nzc3Nzc3Nzc3Nzc3Nzc3NwQFK gs3NTZs2bdq0adOmTZs2LQIUAAggOEhYaHiImKi4uBjAyMjIyMjIyMjIyMjIyMjIyMjIyMjI yMgIQMDIyDgACCA4SFhoeIiYqLjI2Oj4CBkpOUlZaXmJmam5ydnpqTkwSfD5+fn5+fn5+fn5 WRnw+fkY8Pn5+fn5+fn5mUjwaTjw+fn5+fn5+fn5+fn5+fm5OTBJ8Pn5+fn5+fn5+flJGfD5 +Rjw+fn5+fn5+fmJSPBpOPD5+fn5+fn5+fn5+fnp06dOgAYAAQQHCQsJCQABBAcJCw0PERMV FxkbHf8fISMlJykrLS8xMzUTAzY3LwM2Nzc3Nzc3Nzc3Iwk2Ewc2Nzc3Nzc3Nzc3Nzc3Nzc3 NzcVByYJNjc3Nzc3Nzc3Nzc3NxEDNjcvAzY3Nzc3Nzc3NzchCTYTBzY3Nzc3Nzc3Nzc3Nzc3 Nzc3NxkHJAk2Nzdt2rRp06ZNmzZt2oQIUAAggOAgYaHhIWKi4uJiACMjIyMjIyMjIyMjIyMj IyMjIyMjIyOjIgEj4+IAIIDgIGGh4SFiouIiY6PjI2Sk5CRlpeUlZqbmJmen5yfhgCQBKCgo KCgoKCgoKKhhAChoYwAoKCgoKCgoaCcBKOEAKCgoKCgoKCgoKCgoKCho5YD/JAEoKCgoKCgo KCgoaGEAKGhjACgoKCgoKChoJwHo4AAoKCgoKCgoKCgoKCgoKFCXAA0AAggOEhYOEgACCA4S FhoeIiYqLjI2Oj5CRkpOUlZaXmJmahYGbG5eBmxubm5ubm5ubm46EmwiDmxubm5ubm5ubm5u bm5ubm5ubk4OSBJsbm5ubm5ubm5ubm5uEgZsbl4GbG5ubm5ubm5ubjYSbCIObG5ubm5ubm5u bm5ubm5ubm5uVg5EEmxubtq0adOmTZs2bdq0iRCgAEAAwUHCQsNDxETFxcUARkZGRkZGRkZG RkZGRkZGRkZGRkZGRsZDAkbGxQFAAMFBwkLDQ8RE/8VFxkbHR8hIyUnKSstLzEzNTc5Oz8/F AUkCUFBQUFBQUFBQUFDBAFDQxgBQUFBQUFBQUE0C0MEBUFBQUFBQUFBQUFBQUFDQzgFJAlBQ UFBQUFBQUFBQgABQ0MYAUFBQUFBQUFBNAlDBAVBQUFBQUFBQUFBQUFBQoD4BGgAEEBwkLBwk AAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzUBAjY3LwM2Nzc3Nzc3Nzc3Fwk2Dwc2Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3ByQJNjc3Nzc3Nzc3Nzc3NwM2Ny8DNjc3Nzc3Nzc3NxcJNg8HNjc3Nzc 3Nzc3Nzc3Nzc3Nzc3NwEGP+IJNjc3LRp06ZNmzZt2rRpE6AAQADBQcJCw0PERMXFxQBGRkZG RkZGRkZGRkZGRkZGRkZGRkZGRkICRkbFAUAAwUHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3O Ts9PyoFIAlBQUFBQUFBQUFDPAFDQxgBQUFBQUFBQUEwCUIABUFBQUFBQUFBQUFBQUFBQUMOB SAJQUFBQUFBQUFDQzgBQ0MYAUFBQUFBQUNBLAlCAAVBQUFBQUFBQUFBQUFBQUKAQARoABBAc JCwUJAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMTMvAzQBAAMEBwUBAQQHCQsNDxENAwABBAc JCz/NDxETFRcZGx0fISMlJykrLS8HCTATBzAxMTExMTExMTExMTExMTExMTExMSMHIAkwMTE xMTExMTExMTExMRkDMA0DBAMeAwwDCAMKAxIDMDExMTExMTExMTEdCTATBzAxMTExMTExMTE xMTExMTExMTExMScHIAkwMTEhAkTJkyYMGHChAkTpkWAAgABBAcJCw0PAQIIAxALAwIKAwIG AwACBgMAAhADAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0vBQkwEQcwMTExMTExMTExMTExMTEx MTExMTErByAJMDExMTExMTExMTExMTEVAzALAwgDGAMAAggDAAIEAwYD/wACBgMOAzAxMTEx MTExMTExGwkwEQcwMTExMTExMTExMTExMTExMTExMWG6BGgAEEBwkLAQgAAQQHCQsNDwEDFR cZGx0fERMlJykrLS8hIzkzJAkzAgICDgMWAwQDBAMGAwACBgMOAQMEBwkLBQEBBAcJCw0PAQ MVFxkbHR8REyUnKSstISkeAyceDy8vLy8vLy8vLy8vLy8vLy8vLy8vLScuCR4PLy8vLy8vLy 8vLy8vLyEDBAcJCwUBAQQHCQsNDwEDGRMGAwQDBAMGAwACBgMOAwABBAcJCw0PAQMVFxkbHR 8REyUnKSstLykuAyceDy8vLy8vLy8vLy8vLy8v/y8vLy8vLy8hJg4JHg8vLy8vLy8vLy8vLy 8tIy4PIQMEBQEBBAcJCQMGAQMEBQECAAAAAgACAAAAAgABBAcBAgABBAcJCw0PAQMVFxkbHR 8REyUnKSstLykuASceDy8vLy8vLy8vLy8vLy8vLy8vLy8vLycnDgkeDy8vLy8vLy8vLy8vLy sjLg0jBgMsAwYDAAIGAwACAAMeDy8vLy8vLy8vLy0pLgEnHg8vLy8vLy8vLy8vLy8vLy8vLy 8vLy8rIQ0AAggOAgYSEBIIDgIGGh4SFiouIiY6PjI2Sk5CRlpeUlZmZkgOZgQCRggKAgAAAA QAAAAABAACCAoGDA4OD/YAAggOAgYaHhIWKi4iJjo+MjZKTkJGWlpSXBJeLA5eXl5eXl5eXl 5eXl5eXl5eXl5eXl5aXhgCPB5eXl5eXl5eXl5eXl5SVlwOVhwOVlwOXl5eXl5eXl5eVlJcEl 4sDl5eXl5eXl5eXl5eXl5eXl5eXl5eXlJeKAI8Hl5eXl5eXl5aVLly5dujQJUAAggOAgYaHh IQBggOAgIIDgIGGh4SGiYQAggOAgYaHhIWKi4iJjo+MjZKTkJGWlZSXB5eHA5eXl5eXl5eXl 5eXl5eXl5eXl5eXl5aXigCPB5eXl5eXl5eXl5eXl5aVkwOXlJWLA5eXl5eXl5eXl5SUlwSXi /8Dl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eKAI8Hl5eXl5eXl5eWlS5cuXYoEKAAQQHCQsNDw UDAgICAAEREREXEwABBAcJCw0PAQMVFxkbHR8REyUnKSstJykuASceDy8vLy8vLy8vLy8vLy 8vLy8vLy8vLysnGgkeDy8vLy8vJSENBAcJCw0PAQsRAQQHCQsNDwEDFRcZGx0fHxMQCyMYAw ABJSMQASEhISEhISEhISEhISEhISkgDScQASEhISEhISEhISEhISEhISEhISEhISEhISEhIS EhISEhJyoJEAEhISEhISEhLyENBAcJDQABBAcJCw0PAQsRDQQHAQEP9AcJCw0PAQMVFxkbHR 8TExALIxgDAAElIxABISEhISEhISEhISEhISEvKRAPJxABBAcJCw0PAQMVFxkbHR8REyUnKS stLyEjNTc5Oz0/MTNHKgkSA0NDT0ENBAcJDQABBAcJCw0PAQMVFxENBAcFAQEEBwkLDQ8BAx UXGRsdHxESAAsjGAMAASUjEAEhISEhISEhISEhISEhIS8pEA0nEAEEBwkLDQ8BAxUXGRsdHx ETJScpKy0vISM1Nzk7PT8xNUcsCRIDQ09BPQQHBQEBBAcJCw0PAQMVFxcRHQQHAQEEBwkLDQ 8BAxUXGRsdFRMeDxMSAgIODxsTHg8fHx8fH/8fHx8fHx8fHx8fHxkeDxcQAQQHCQsNDwEDFR cZGx0fERMlJykrLS8hIzU3OTs9PzE5RyoJEgNDQ0E9BAcBAQQHCQsNDwEDFRcZGx0fERMlJy EjKAkpIyMoCSkpKSkpKSkpKSkpJSkYAycYCSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSklJx oJGAkpKSkvIR0EBwUBAQQHCQsNDwEDFRcZGx0fERMlJyklIwoDIxQDCgshIgoLKysrKysrKy srKyMpKgMnGgsrKysrKysrKysrKysrKysrKysrKysrKysrJwoJGgsrKychLQQHCQ0AAQQHCQ sNDwEDFRcZGx0fER/zJScpJSMaASMYAwoLIyoLKysrKysrKysrKyMpKgEnGgsrKysrKysrKy srKysrKysrKysrKysrKysvJwoJGgsrKyUhHQQHBQEBBAcJCw0PAQMVFxkbHR8REyUnKSsjKg EjGAMKCyMqCysrKysrKysrKyshKSoBJxoLKysrKysrKysrKysrKysrKysrKysrKysrIycYCR oLKyspIQ0EBwEBBAcJCw0PAQMVFxkbHR8REyUnKSshIxwPIwgDDAkjLA0tLS0tLS0tLS0tKS kMDycMDS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLScICRwNLSEhLQQFAQEEBwkLDQ8BAxUf9x kbHR8REyUnKSstIxwBIxICAgwLIywNLS0tLS0tLS0tLScpDA8nDA0tLS0tLS0tLS0tLS0tLS 0tLS0tLS0tLSEnGAkcDS0jIR0EBwEBBAcJCw0PAQMVFxkbHR8REyUnKSsnIywNLScjHA0tLS 0tLS0tLS0tJykMDScMDS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJScYCRwNLSEtBAcFAQEEBw kLDQ8BAxUXGRsdHxETJScpKy0nIw4PIwIODSMuDy8vLy8vLy8vLyspHg0nDg8vLy8vLy8vLy 8vLy8vLy8vLy8vLy8vIycYCR4PISEdBAcJDQABBAcJCw0PAQMVH/cZGx0fERMlJykrLScjHg 0jAAIEAw4HIy4PLy8vLy8vLy8vKykeCycODy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8nJxYJHg 8hLQQHBQEBBAcJCw0PAQMVFxkbHR8REyUnKSstLSMuDSMAAgQDDgcjLg8vLy8vLy8vLy8pKR 4LJw4PLy8vLy8vLy8vLy8vLy8vLy8vLy8vLysnFgkeASEtBAcBAQQHCQsNDwEDFRcZGx0fER MlJykrLS8vIwALMwACBAMABTMgATExMTExMTExMTE4AAk3AAExMTExMTExMTExMTExMTExMT ExMTE7NxgJEA0xDQQHBQEBBAcJCw0PAQ/zFRcZGx0fERMlJykrLS8rIxANMwICAgAHMyABMT ExMTExMTExOTAJNwABMTExMTExMTExMTExMTExMTExMTExPzcYCRQBLQQHCQ0AAQQHCQsNDw EDFRcZGx0fERMlJykrLS8rIyABMTszAAExMTExMTExMTE5MAc3AAExMTExMTExMTExMTExMT ExMTExMTEzNyYJHgENBAcJDQABBAcJCw0PAQMVFxkbHR8REyUnKSstLyEhMxILMwQDAgUzIg MzMzMzMzMzMzs5Egc3AgMzMzMzMzMzMzMzMzMzMzMzMzMzMzk3JAEdBAcFAQEEBwkLDQ8BAx UXGRsdHxETJScv+SstLyEnMyIJMwQDAAICAzMiAzMzMzMzMzMzOzkSBTcCAzMzMzMzMzMzMz MzMzMzMzMzMzMzPTcmAQ0EBwEACAABBAcJCw0PAQMVFxkbHR8REyUnKSstLyEhMzIJMwACBA MCAzMiAzMzMzMzMzMzOTkSBTcCAzMzMzMzMzMzMzMzMzMzMzMzMzMzNzEtBAcFAQEEBwcJAA EEBwkLDQ8BAxUXGRsdHxETJScpKy0vIS8zIgkzAAIEAwIDMyIDMzMzMzMzMzM3ORIFNwIDMz MzMzMzMzMzMzMzMzMzMzMzMzMzMR0EBwkNAAEEBwcGBwcBCAABBAcJCw0PAQMVFxkbH/0fER MlJykrLS8hLzMiCzMEAwIFMyIDMzMzMzMzMzM3ORIFNwIDMzMzMzMzMzMzMzMzMzMzMzMzMz 8xLQQHCQ0AAQQHCQsHBwwJCQABBAcJCw0PAQMVFxkbHR8REyUnKSstLyEtMyIDMzUzAgMzMz MzMzMzMzU5EgU3AgMzMzMzMzMzMzMzMzMzMzMzMzMzOzEdBAcJDQABBAcJCw0PBQcABRkAAQ QHCQsNDwEDFRcZGx0fERMlJykrLS8hKzMiBTMCAg8zIgMzMzMzMzMzMzU5EgE2AgMzMzMzMz MzMzMzMzMzMzMzMzMzMS0EBwkLDQ0AAQQHCQsNDwENFwIBGA/wAQQHCQsNDwEDFRcZGx0fER MlJykrLS8hKTMiCTMCAgszIgMzMzMzMzMzMzM5EgU3AgMzMzMzMzMzMzMzMzMzMzMzMzM9MQ 0EBwkNAAEEBwkLDQ8BAxUVFxIJEAEEBwkLDQ8BAxUXGRsdHxETJScpKy0vISkzIg0zAgkzIg MzMzMzMzMzMzM5EgE2AgMzMzMzMzMzMzMzMzMzMzMzMzsxLQQHCQ0AAQQHCQsNDwEDFRcXFx IJEAEEBwkLDQ8BAxUXGRsdHxETJScpKy0vISczIg8zAgIFMyIDMzMzMzMzMzMxORIBNgIDMz MzMzMzMzMzMzMzMzMzMzM/MR0EBw0P8AEEBwkLDQ8BAxUXGRUXFAkaCxsbGxsbGxsbGxsbGx sbGxsbGxsbGxsdEwoLERMSCgsbFRMKCxsbGxsbGxsbGxsbGxsbGxsbFxkaCxcQAQQHCQsNDw EDFRcZGx0fERMlJykrLS8hIzU3OTs9NzEtBAcBAQQHCQsNDwEDFRcZGxsXBAkcDR0dHR0dHR 0dHR0dHR0dHR0dHR0dExMcDR0dHR8TDA0dHR0dHR0dHR0dHR0dHR0dGxkMCRcQAQQHCQsNDw EDFRcZGx0fERMlJykrLS8hIzU3OTs9OTEdBAcFAQEEBwkLDQ8BAxUXGRsZFxIJHA0dHR0dHR 0dHR0dHR0dH/0dHR0dHR0TExwNFRMEAwwNHRESDA0dHR0dHR0dHR0dHR0dHR0dGxkMBxcQAQ QHCQsNDwEDFRcZGx0fERMlJykrLS8hIzU3OTs9NTENBAcJDQABBAcJCw0PAQMVFxkbHR8XAg keDx8fHx8fHx8fHx8fHx8fHx8fHx8REg4NExQDAAIODxkTHg8fHx8fHx8fHx8fHx8fHx8RGA 4HFx4PHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx0RDQQHCQ0AAQQHCQsNDwEDFRcZGx 0fGRcCCRABISEhISEhISEhISEhISEhISEnIxALIxACBAMAASUjEAEhISEhISEhIS/xISEhIS EpIAMnEAEhISEhISEhISEhISEhISEhISEhISEhISEhISEgDQQHBQEBBAcJCw0PAQMVFxkbHR 8RFyIJEAEhISEhISEhISEhISEhISEhISUjEAsjEAIEAwABJSMQASEhISEhISEhISEhISEvKR ADJxABISEhISEhISEhISEhISEhISEhISEhISEhISkhHQQHAQEEBwkLDQ8BAxUXGRsdHxETJx AJEgMjIyMjIyMjIyMjIyMjIyMjISMSCyMUAwIDIyMSAyMjIyMjIyMjIyMjIyMpIgEnEgMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIychHQQHBQEBBAcJCw0P/wEDFRcZGx0fEREnIAkSAyMjIy MjIyMjIyMjIyMjIyMvIwIDIyMjIxIDIyMjIyMjIyMjIyMjISkiAScSAyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjKSENBAcFAQEEBwkLDQ8BAxUXGRsdHxETIScQCRQFJSUlJSUlJSUlJSUlJS UlLSMECSMSBAUjIxQFJSUlJSUlJSUlJSUlJSkEDScEBSUlJSUlJSUlJSUlJSUlJSUlJSUlJS UhHQQHAQEEBwkLDQ8BAxUXGRsdHxETIycgCRQFJSUlJSUlJSUlJSUlJSUlKyMEByMQAgQDBA UtIwQFJSUlJSUlJSUlJSUlISgED/0nBAUlJSUlJSUlJSUlJSUlJSUlJSUlJSUtIQ0EBQEBBA cJCw0PAQMVFxkbHR8REyUtJw4JBgcnJycnJycnJycnJycnJy8jBgUjEAIEAwYHKSMGBycnJy cnJycnJycnLSkGCycGBycnJycnJycnJycnJycnJycnJycvIR0EBwEBBAcJCw0PAQMVFxkbHR 8REyUpJx4JBgcnJycnJycnJycnJycnJy0jBgUjEAIEAwYHKSMGBycnJycnJycnJycnKykGCy cGBycnJycnJycnJycnJycnJycnJycnIR0EBQEBBAcJCw0PAQMVFxkbHR8REyUlJyAJFgcnJy cnJycnJy/3JycnJycrIwYHIxICAgYHKyMGBycnJycnJycnJycnKykGCScGBycnJycnJycnJy cnJycnJycnJyctIQ0EBwEBBAcJCw0PAQMVFxkbHR8REyUnKycACRgJKSkpKSkpKSkpKSkpKS EjGAkpIyMoCSkpKSkpKSkpKSknKRgJJwgJKSkpKSkpKSkpKSkpKSkpKSkpISwMDAwICSkpKS kpKSkpJScACRgJKSkpKSkpKSkpKSkpKS8jCAsjGAknIwgJKSEiVKlChRokSJEiVFgAgAAQQH CQsNBwcAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3KQ0MDAw4OTk5OTk5F/8HDgk4OTk5 OTk5OTk5NwM4AQIIAzgdAzg5OTk5OTk5NQkuBzg5OTk5OTk5OTk5OTk5Bw0MDAw4OTk5OTk5 IQcOCTg5OTk5OTk5OTk1AzgBAggDOB0DODk5ceLEiROnTIAIAAEEBwkLDQcHAAEEBwkLDQ8R ExUXGRsdHyEjJScpKy0vMTM1NxsNDAwMODk5OTk5OSsHDgk4OTk5OTk5OTk5MwM2AQMEBwMA AQQHCQsNDxEPAwABBAcJCw0PERMVFxkbHR8hIyUnKSslCSwBBiwtLS0tLS0tLS0tLS0tLS0t GQENBAcBAQQHCQsNDxETFRcZGx0fISMlJykZBw4JKiv/KysrKysrKysrKysrFQMqEQMqKwsD KisrKysrKysrKysjCSoFByorKysrKysrKysrKysrKysrKwsNDAwMKisrKysrKysrKycHDAkq KysrKysrKysrKysrKxUDKisrHQMqKysrKysrVapUqVIkQASAAIKDhIWGggOAAIKDhIWGh4iJ iouMjY6PkJGSk5SVlpeYmZqbAAYGBgacnJycnJycnIoDhgScnJycnJycnJyclwGcAIABgoOA AIKDhIWGh4iGAYAAgoOEhYaHiImKi4yNjo+QkZKTlJWQBJYAA5aWlpaWlpaWlpaWlpaWlpaW ggYGBgaWlpaWlpaWlpaWkwOG/wSWlpaWlpaWlpaWlpaWkAGWigGCAZaTAZaWlpaWlpaWlpaW hQSWAAOWlpaWlpaWlpaWlpaWlpaWlQYGBpaWlpaWlpYsWbJkSRCgAUAAwUECQADBQcJCw0PE RMVFxkbHR8hIyUnKSstLTICATMQAwYDMx4DMzMzMzMzMzMxKgsuBzMzMzMzMzMzMzMzMzExK AwMDg8zMzMzMzMzMzMsBQ4LMzMzMzMzMzMzMzMyATMQAwYDMx4DMzMzMzMzMzMxKAsuBzMzM zMzMzMzMzMzMzMxIgAwEDQABBAcJCw0PERMVFxkbHR8hIyUnKSsrBw4JLC0tLS0tLS0tLS0t LRsDLP8PAwICAgYDLCUDLC0tLS0tLS0tLS0HCSwBBiwtLS0tLS0tLS0tLS0tLS0ZDQwMLC0t LS0tLS0tLS0fBwwJLC0tLS0tLS0tLS0tLRsDLC0tFwMsLS0tLS1ZsmTJkqVBgAgAAQQHCQsN AQYAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzUVDQwMDDY3Nzc3Nzc3NyUHDAk2Nzc3Nzc3 Nzc3NwECNgcDAgICNiEDNjc3Nzc3Nzc3AQgsBzY3Nzc3Nzc3Nzc3NzcPDQwMDDY3Nzc3Nzc3 Ny8HDAk2Nzc3Nzc3Nzc3NwM2BQMIAQMAAQQHCQsNDxENAwABBAcJCw0PERP/FRcZGx0fISMl JykrGwksBywtLS0tLS0tLS0tLS0tLS0HDQwMLC0tLS0tLS0tLS0tDwcMCSwtLS0tLS0tLS0t LS0VAywPAwgDLCkDLC0tLS0tLS0tLS0BCCwHLC0tLS0tLS0tLS0tLS0tLQEMDAwsLS0tLS0t LS1ZsmRpEaABQADBQQJAAMFBwkLDQ8RExUXGRsdHyEjJScpKy8vJAEzDAMEAzMkATExMTExM TExMzEECywFMTExMTExMTExMTExMzEcDA0xMTExMTExMTEzMxwFDAkxMTExMTExMTExMTMMA zEHAAMFBQUAAwUHCQsNDRMMAQADBQcJCw0PERMVF/8ZGx0fISMlJyspFAssBS0tLS0tLS0tL S0tLS0vLSQMDA0tLS0tLS0tLS0tLS8mBQgJLS0tLS0tLS0tLS0tLxABLS8vFAEtLS0tLS0tL S0tLgsoBS0tLS0tLS0tLS0tLS0vLSAMDA0tLS0tLS0tLS0tLS0vAAUAAQUECQADBQcJCw0PE RMVFxkbHR8hIyUnKSsvLyABMw4CAgADMyQBMTExMTExMTExMAALLAUxMTExMTExMTExMTEzM QwMDAwNMTExMTExMTExMTEzBgUICTExMTExMTExMTExMwgDMwgDCAEzJAExMTExMTExMTEwA gsoBTExMTExMTExMmDBhwv+EiRAgA0EDQADBQcJCw0PERMVFxkbHR8hIyUnKSsvLyYFCAkxM TExMTExMTExMzMEAzMIAwgBMyQBMTExMTExMTExMAssBTExMTExMTExMTExMTEwAAwMDTExM TExMTExMTExMxoFCAkxMTExMTExMTExMTMEAzMIAwgBMyQBMTExMTExMTExMgAgAAQQHCQsN BwABBAcJCw0PERMVFxkbHR8hIyUnKSstLzEzFQ0MDDQ1NTU1NTU1NTU1JQcKCTQ1NTU1NTU1 NTU1BwM0CQMCAgI0IwM0NTU1NTU1NTUNCSgHNDU1NTU1NTU1NTU1LQ0MNDU1NTU1NTU1NTUt Bwj/CTQ1NTU1NTU1NTU1BwM0NTMDAAEEBwkLDQ8RExUXGRsdHyEjJScpKxEJKgcsLS0tLS0t LS0tLS0tLS0BDAwMLC0tLS0tLS0tLS0tLS0HBwgJLC0tLS0tLS0tLS0tLQUDLC0tFwMsLS0t LS0tLS0tJwkoBywtLS0tLS0tLS0tLS0tKw0MDCwtLS0tLS0tLS0tLS0tHQI0AAAAAEAACCA4 SFhoeIiYqLjI2Oj4CBkpOUlZaXm5GICpGIApGYCJiYmJiYmJiWlJUDmAiYmJiYmJiYmJiYmJ +WhggImJiYmJiYmJiYmJiXk4QEiAiYmJiYmJiYmJiWkZgDkIGCA4KAgI/yA4SFhoeIhoGAAI IDhIWGh4iJiouMjY6PgIGSk5SVl5SEA5YGlpaWlpaWlpaWlpaWkpaWBgaWlpaWlpaWlpaWlp aek4QEhgaWlpaWlpaWlpaWlZGWBZGGAYYEkZYGlpaWlpaWlpaRlJQDlgaWlpaWlpaWlpaWlp aRlpYGBpaWlpaWlpaWlpaWlpGQnQAAAAAAEggOAgYaHhIWKi4iJjo+MjZKTkJGWl5WViACYm ZmEAJiYmJiYmJiZmJQHlACYmJiYmJiYmJiYmJuaigQEmJiYmJiYmJiYmJiYm5MAgASYmJiYm JiYmJiYmZQAmJmZhACYmJiYmJiYmJiUB5QAmJv8mJiYmJiYmJiYmZqKBgQEmJiYmTJgwYcKE CRMmTJMADQAAABAAAggOEhYaHiImKi4yNjo+QkZKTlJWWl4eBmBiYhYGYGJiYmJiYmJiUhJM DmBiYmJiYmJiYmJiYmIeGhgYYGJiYmJiYmJiYmJiYl4ODBJgYmJiYmJiYmJiYkoGYCoGYEoG YGJiYmJiYmJiThJQDmBiYmJiYmJiYmJiYmIWGhhgYmLChAkTJkyYMGHChAnTIEADAAAEgACC g4SFhoeIiYqLjI2Oj5CRkpOUlZaXhgGYgwEAgAGCg4AAgoOEhYaHiIYBgACCg4SFhoeIiYqL jI2Oj5CRkpOUlYQEkwP/lpaWlpaWlpaWlpaWlpaHBgYGlpaWlpaWlpaWlpaWlpaWiwODBJaW lpaWlpaWlpaWlpEBlocBhAGWlAGWlpaWlpaWlpaWjgSUA5aWlpaWlpaWlpaWlpaWhAYGBpaW lpaWlpaWlpaWlixZsvQI0AAAAAABIIDgIGGh4SFiouIiY6PjI2Sk5CRlpeUlYQAmJmZhACYm JiYmJiYmpiTB5AAmJiYmJiYmJiYmJualgQEmJiYmJiYmJiYmJiYmZuPAIAEmJiYmJiYmJiYm 5mMAJiZmYQAmJiYmJiYmJmYkweQAJiYmJiYmJiYmJiampYEBJiYmJiYmTJgwYcKECRMmSIAG /wAAAAgAAQQHCQsNDxETFRcZGx0fISMlJykrLS8FAzAVAzAlAzAxMTExMTExMSMJJgcwMTEx MTExMTExMTEpDQwwMTExMTExMTExMTExMScHBgkwMTExMTExMTExMRsDMAsDBgMeAwgDAgII AwoDEgMwMTExMTExMTEhCSYHMDExMTExMTFhwoQJ0yRABgaAAIKDhIWGh4iJiouMjY6PkJGS k5SVlpeYmZqHA4IEm5ubm5ubm5ubm4cBm4MBAAGPAQGDAYMBggEAAYMBAAGIAZubm5ubm5ub kASTA5ubm5ubm5ubm5ubhwYGBpubm5ubm5ubm5ubm5uKA4IEm5ubm/+bm5ubm5uGAZuEAY8B AIABgACCgwABAAGDAQABgwGEgwGAAIKDhIWGh4iJiouMjY6PkJGSk5SVBJMDlZWVlZWVlZWV lZWVlZWJBgaVlZWVlZWVlZWVlZWVlZWVlYgDggSVlZWVlZWVlZWVlZWVggGVhoABgoOCgACC g4SEAYUAAYIBgwEAAYMBhYKAAYKDhIWCgACCg4SFhoeIiYqLjI2Oj5CRkpOUhQSSA5WVlZWV lZWVlZWVlZWViAYGlZWVlZWVlZWVlZWVlZWVlZWLA4IElZWVlZWVlZWVlZWVhoABgoOEhYKA AIKDhIWGh4iJhAGFAYMBgwEAAYMBhwGAAIL/g4SFhoeIiYqLjI2Oj5CRkpOUlASTA5WVlZWV lZWVlZWVlZWVhgYGlZWVlZWVlZWVlZWVlZWVlZWOA4IElZWVlZWVlZWVlZWVlQGVlYcBhAGE AYMBAAGDAYcBlZWVlZWVlZWVlZQEkgOVlZWVlZWVlZWVlZWVlYUGBpWVlZWVKlWqVKlSpUqV KlWqVCkSoAEAAAJAAMFBwkLDQ8RExUXGRsdHyEjJScpKy8mAy8vBgMEAwwCAgMEAgADEgMvL y8vLy8vLS0uCyYHLy8vLy8vLy8vLy0tKAwODy8vLy8vLy8vLy8vLy8vLy8QBAILLy8vLy8vL y8vLy8mAy0sAwABB/0GAQUEAAIAAQABBwYDBwcEAQADBQcJCw0PERMVFxkbHR8hIyUnKSQLJ gcrKysrKysrKysrKyspKAAODysrKysrKysrKysrKysrKyspKwQFBgsrKysrKysrKysrKysmA yspKx4DKysrKysrKysrKSYLIgcrKysrKysrKysrKyspKA4PKysrKysrKysrKysrKyspKlSoV AjQAAEAACCA4SFhoeIiYqLjI2Oj4CBkpOUlZaRkZcHl5iRhweXl5eXl5eXlZSSA5cHl5eXl5 eXl5eXl5CWlgcHl5eXl5eXl5eXl5eXl5eSk5IEhweXl5eXl5eXl5eQkZcHl5iRhweXl5ef95 eXl5WUkQOXB5eXl5eXl5eXl5efloYHB5eXl56dKlS5cuXbp06dKlS5UADQAAEAACCA4SFhoe IiYqLjI2Oj5CRkpOUlZaPgZcXl4iBlxeXl5eXl5eXlISRA5cXl5eXl5eXl5eXl42GhgYXF5e Xl5eXl5eXl5eXl5eXl4CDAgSXF5eXl5eXl5eXl46BlxeXiIGXF5eXl5eXl5eUhJEDlxeXl5e Xl5eXl5eXi4aGFxeXrp06dKlS5cuXbp06dKlS5cKARoAACAABBAcJCw0PERMVFxkbHR8hIyU nKSstGwMuLy8RAy4vLy8vLy8vLycJIgcuLy8vLy8vLy8vLy8VDT/MLi8vLy8vLy8vLy8vLy8 vLy8RBwQJLi8vLy8vLy8vLy8ZAy4vLxEDLi8vLy8vLy8vJwkiBy4vLy8vLy8vLy8vLxENDC4 vLy8dOnSpUuXLl26dOnSpUuXFgEaAAAgAAQQHCQsNDxETFRcZGx0fISMlJykrLRcDLi8vEQM uLy8vLy8vLy8lCSIHLi8vLy8vLy8vLy8vDw0MLi8vLy8vLy8vLy8vLy8vLy8dBwQJLi8vLy8 vLy8vLy8VAy4vLxEDLi8vLy8vLy8vJQkgBy4vLy8vLy8vLy8vLw0NDC4vLy8dOnSpUuXLl26 dOnSpUuXIgEaACAABBAcJCw0PERMVFxk/2x0fISMlJykrLRUDLi8vEQMuLy8vLy8vLy8jCSI HLi8vLy8vLy8vLy8vCQ0MLi8vLy8vLy8vLy8vLy8vLy8pBwAILi8vLy8vLy8vLy8TAy4vLxE DLi8vLy8vLy8vIwkgBy4vLy8vLy8vLy8vLwcNDC4vLy8dOnSpUuXLl26dOnSpUuXLgEaACAA BBAcJCw0PERMVFxkbHR8hIyUnKSstEQMuLy8RAy4vLy8vLy8vLyEJIgcuLy8vLy8vLy8vLy8 BDAwuLy8vLy8vLy8vLy8vLy8vLy8HBwAILi8vLy8vLy8vLy8PAy4vLxEDLi8vLy8vLy8vIQk gBy4vLy8vLy8vP+8vLy8NDC4vLy8dOnSpUuXLl26dOnSpUuXLhkCNABAAAggOEhYaHiImKi4 yNjo+AgZKTlJWWlpGHB5eYkYcHl5eXl5eXl5+UgAOXB5eXl5eXl5eXl5aWlgcHl5eXl5eXl5 eXl5eXl5eXl5mTgAQHB5eXl5eXl5eXl5WRhweXmJGHB5eXl5eXl5eflIADlweXl5eXl5eXl5 eVlpcHl5eXl56dKlS5cuXbp06dKlS5cYARoAIAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0JAy4 vLxEDLi8vLy8vLy8vHQkgBy4vLy8vLy8vLy8vKQ0MLi8vLy8vLy8vLy8vLy8vLy8vHT/HAAg uLy8vLy8vLy8vLwcDLi8vEQMuLy8vLy8vLy8dCSAHLi8vLy8vLy8vLy8lDQwuLy8vLx06dKl S5cuXbp06dKlS5ciARoAIAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0FAy4vLxEDLi8vLy8vLy8 vGwkgBy4vLy8vLy8vLy8vIw0MLi8vLy8vLy8vLy8vLy8vLy8vKQcACC4vLy8vLy8vLy8vAQI uLy8RAy4vLy8vLy8vLxsJIAcuLy8vLy8vLy8vLx8NDC4vLy8vHTp0qVLly5dunTp0qVLly4B GgAgAAQQHCQsNDxETFRcZGx0fISMlJykrLQMsLS0XAywtLS0/7S0tLS0rCSAHLC0tLS0tLS0 tLS0tBw0MLC0tLS0tLS0tLS0tLS0tLS0tLS0HAAgsLS0tLS0tLS0tLRUDLC0tFwMsLS0tLS0 tLS0rCR4HLC0tLS0tLS0tLS0tBw0sLS0tGTJkiVLlixZsmTJkiVLlixZsjQI0AABIIDgIGGh 4SFiouIiY6PjI2Sk5CRlZWWApaXlYoClpaWlpaWlpSUlAeSApaWlpaWlpaWlpaUlgIGBpaWl paWlpaWlpaWlpaWlpaWlpWXhAIGlpaWlpaWlpaWlZWKApaXlYoClpaWlpaWlpSUlweOApaWl paWlpaWlpaWlgYGlpaUlS5YsWbJkyf+SJUuWLFmyZMmSJUSABggAAQQHCQsNDxETFRcZGx0f ISMlJykrJwMsLS0XAywtLS0tLS0tLSkJHgcsLS0tLS0tLS0tLSkNDCwtLS0tLS0tLS0tLS0t LSkBCwQHCQsNDxETFRcBAQQHCQsNDw8HCAABBAcJCw0PERMVFxkbHR8hIyUnKSslAywtLRcD LC0tLS0tLS0tJwkeBywtLS0tLS0tLS0tJw0MLC0tLS0tLS0tLS0tLS0tAQsEBwkLDQsAAQQH CQsNDxETFRcBCwQHCQsNDwsBAAAGCAABBAcJCw0PERMVFxkbHR8hIyUnKSsjAywtLRcDLC0t LS0tLS0tJwn/HAcsLS0tLS0tLS0tLSUNDCwtLS0tLS0tLS0tLS0tGwELBAcJCwABBAcJCw0P ERMVFxkbHR8BAAsEBwkLAAEEBwkLDQ8RExUXGRsdHyEjJScpKxcDLC0tFwMsLS0tLS0tLS0l CR4HLC0tLS0tLS0tLS0jDSwtLS0tLS0tLS0tLS0fAQsEBwkLDQsAAQQHCQsNDxETFRcZGx0f IQEGCAgBCwQHCQsNCwABBAcJCw0PERMVFxkbHR8hIyUnKRUDKisrHQMqKysrKysrKysrDQkc ByorKysrKysrKysrKw0NDCorKysrKysrKysrKyslAQsEBwkLAAEEBwkLDQ8RExUX/xkbHR8h Iw8HCCQPAQsEBwkLAAEEBwkLDQ8RExUXGRsdHyEjJScnAygpKSMDKCkpKSkpKSkpKR8JHgco KSkpKSkpKSkpKSkjDSgpKSkpKSkpKSkpKSkpDQELBAcLAAEEBwkLDQ8RExUXGRsdHyEjJQEG CCYhAQsEBwkLAAEEBwkLDQ8RExUXGRsdHyEjJScRAygpKSMDKCkpKSkpKSkpKR8JHAcoKSkp KSkpKSkpKSkhDQwoKSkpKSkpKSkpKSkpKQEACwQHAQEEBwkLDQ8RExUXGRsdHyEjJRMHCCYn DwELBAcJCwABBAcJCw0PERMVFxkbHR8hIyUhAyYnJycBAv8mJycnJycnJycnJwsJHgcmJycn JycnJycnJycnDw0MJicnJycnJycnJycnJycTAQsEBwUBAQQHCQsNDxETFRcZGx0fISMlIQcI JicjAQsEBwkLAAEEBwkLDQ8RExUXGRsdHyEjJQsDJicnJwECJicnJycnJycnJycLCRwHJicn JycnJycnJycnJw8NJicnJycnJycnJycnJycBCwQHCQsAAQQHCQsNDxETFRcZGx0fISMlJw0H CCgpKQsBCwQHCQsAAQQHCQsNDxETFRcZGx0fISMZAyQlJSULAyQlJSUlJSUlJSUlHwkcByQl JSUlJSUlJSUlJSUlAQwMJCUlJSX/JSUlJSUlJSUlDwELBAcFAQEEBwkLDQ8RExUXGRsdHyEj JScnCSgpKR8BCwQHCQsNCwABBAcJCw0PERMVFxkbHR8hDwMiIyMjEwMiIyMjIyMjIyMjIyMT CRwHIiMjIyMjIyMjIyMjIyMdDSIjIyMjIyMjIyMjIyMjIwELBAcBAQQHCQsNDxETFRcZGx0f ISMlJykRCSorKysZAQsEBwkLDQsAAQQHCQsNDxETFRcZGx0fAQIgISEhGwMgISEhISEhISEh ISEhCQkcByAhISEhISEhISEhISEhIRcNDCAhISEhISEhISEhISEhIREBCwQHBQEBBAcJCw0P ERMVFxkb/x0fISMlJykfCSorKysrGQELBAcBAQQHCQsNDxETFRcZGx0VAx4fHx8fBQMeHx8f Hx8fHx8fHx8fHwUJHAceHx8fHx8fHx8fHx8fHx8fEw0MHh8fHx8fHx8fHx8fHx8fHwUBCwQH BQEBBAcJCw0PERMVFxkbHR8hIyUnKSsHCSwtLS0tLS0tLS0jAywtLRcDLC0tLS0tLS0tGwkc BywtLS0tLS0tLS0tDQ0MLC0tLS0tLS0tLSUBCwQHAQEEBwkLDQ8RExUXGRsdHyEjJScpKxkJ LC0tLS0tLS0tLSEDLC0tFwMsLS0tLS0tLS0bCRwHLC0tLS0tLS0tLS0JDQwsLf8tLS0tLS0t LR8BCwQFAQEEBwkLDQ8RExUXGRsdHyEjJScpKycJLC0tLS0tLS0tLR8DLC0tFwMsLS0tLS0t LS0ZCRwHLC0tLS0tLS0tLS0HDQwsLS0tLS0tLS0tFwELBAcBAQQHCQsNDxETFRcZGx0fISMl JykrLQcJLi8vLy8vLy8vLwkDLi8vEQMuLy8vLy8vLy8HCRwHLi8vLy8vLy8vLx0NLi8vLy8v Ly8vKwELBAUBAQQHCQsNDxETFRcZGx0fISMlJykrLRUJLi8vLy8vLy8vLwcDLi8vEQMuLy8v Ly8vLy8FCRwHLi8vLy8vLy8vLxsNDC4vLy8vLy8vLyH/AQsEBwEBBAcJCw0PERMVFxkbHR8h IyUnKSstIQkuLy8vLy8vLy8vBQMuLy8RAy4vLy8vLy8vLwUJGgcuLy8vLy8vLy8vGw0uLy8v Ly8vLy8bAQsEBQEBBAcJCw0PERMVFxkbHR8hIyUnKSstLwkGLi8vLy8vLy8vLwMuLy8RAy4v Ly8vLy8vLwEIHAcuLy8vLy8vLy8vFw0MLi8vLy8vLy8vEQELBAcBAQQHCQsNDxETFRcZGx0f ISMlJykrLS8NCQYwMTExMTExMTEbAzAxMQsDMDExMTExMTEhCRoHMDExMTExMTExMQEMMDEx MTExMTEpAQsEBQEBBAcJCw0P/xETFRcZGx0fISMlJykrLS8bCQYwMTExMTExMTEZAzAxMQsD MDExMTExMTEfCRwHMDExMTExMTExMQ0wMTExMTExMR8BCwQHAQEEBwkLDQ8RExUXGRsdHyEj JScpKy0vJwkGMDExMTExMTExFwMwMTELAzAxMTExMTExHwkaBzAxMTExMTExMS8NDDAxMTEx MTExFwELBAUBAQQHCQsNDxETFRcZGx0fISMlJykrLS8xBQkGMjMzMzMzMzMzAQIyMzMFAzIz MzMzMzMzDwkaBzIzMzMzMzMzMxsNMjMzMzMzMzEBCwQHAQEEBwkLDQ8RExUXGRsdHyEjJScp Ky0vMf8RCQYyMzMzMzMzMzMDMjMzBQMyMzMzMzMzMw0JGgcyMzMzMzMzMzMZDQwyMzMzMzMz KQELBAUBAQQHCQsNDxETFRcZGx0fISMlJykrLS8xHwkGMjMzMzMzMzMxAzIzMwUDMjMzMzMz MzMNCRoHMjMzMzMzMzMzFw0yMzMzMzMzIQELBAcBAQQHCQsNDxETFRcZGx0fISMlJykrLS8x KwkGMjMzMzMzMzMvAzIzMwUDMjMzMzMzMzMLCRoHMjMzMzMzMzMzFQ0MMjMzMzMzMxsLCgoK MjMzMzMzMzMzMzMzMwcJBjIzMzMzMzMzLQMyMzMFAzIzMzMzMzMzCwkaBzL/MzMzMzMzZcqE CJCBASCA4CBhoeEhYqLiImOj4yNkpORjQUFBweTk5OTk5OTk5OTk5OTk5OSkIsHA5OTk5OTk 5OTk5CRjwOTk5CRAwOTk5OTk5OTk5KQjQePA5OTk5OTk5OTk5ORkocHk5OTk5OTk5GRjQUFB weTk5OTk5OTk5OTk5OTk5OTkI8HAwOTkpEmTJk2aNGnSJEWAAgABBAcJCw0PERMVFxcDGBkZ GRkZGRkZGRkZGRkZGRkJGAcYGRkZGRkZGRkZGRkZGRkZGRkZCQ0MGBkZGRkZGRkZGRkZGRkZ BQsKCgABBAcJCw0PERMVFxkbHR8hIyUnKSstLzEz/yUJCAY0NTU1NTU1NRUDNDUzAzQ1NTU1 NTUrCRoHNDU1NTU1NTUvDTQ1NTU1NTELCgoKNDU1NTU1NTU1NTU1NRUJBjQ1NTU1NTU1EwM0 NTMDNDU1NTU1NSsJGAc0NTU1NTU1NS0NAA0AAQQHCQsNDxETFRcZGx0fISMlDQsKCgomJycn JycnJycnJycnJycnJycXCQYmJycnJycnJycnJw8DJicnJwECJicnJycnJycnJxkJGgcmJycn JycnJycnJycBDCYnJycnJycnJwkLCgoKJicnJycnJycnJycnJycnJycnIQkGAAEEBwkLDQ8R ExUXGRsdHyEjJScpCwMqK/8rHQMqKysrKysrKysbCRgHKisrKysrKysrKycNKisrKysrKysF AQsEBwEBBAcJCw0PERMVFxkbHR8hIyUnKSstLzEzNRkJBjY3Nzc3NzczAzY3LwM2Nzc3Nzc3 GQkaBzY3Nzc3Nzc3Fw0MNjc3Nzc3CwsKCgo2Nzc3Nzc3Nzc3Nzc3JwkGNjc3Nzc3NzEDNjcv AzY3Nzc3NzcZCRgHNjc3Nzc3NzcXDTY3N23atGkQoALBAkAAwUHCQsNDxETFRcZGx0fISMlJ ykrLS8xMTUyCgYHNzc3Nzc1Ny4DNzcuAzc3Nzc3NTUYCxoHNzc3Nzc3NTUWDzc3Nzc3NgoKC gs3/zc3Nzc3Nzc3Nzc3NTUECgoHNzc3Nzc3NyoDNzcuAzc3Nzc3NzUUCxoHNzc3Nzc3NzUQD QANAAMFBwkLDQ8RExUXGRsdHyMjDgoICSUlJSUlJSUlJSUlJSUlJSUlJSUlJRIIBSUlJSUlJ SUlJScnFAElJScnCAElJSUlJSUlJSUlJQYLFAUlJSUlJSUlJSUlJyUQDSUlJSUlJSUnHgoKC AklJSUlJSUlJSUlJSUlJSUlJSUlJSUaACAYAAQQHCQsNDxETFRcZGx0fISMlJyUDKCkpIwMo KSkpKSkpKSknCRgHKCkpKSkpKSkpKSkHDQwoKSkpKSkpHwsKCgooKSkp/ykpKSkpKSkpKSkp KSkpKR8JBigpKSkpKSkpKSkPAygpKSMDKCkpKSkpKSkpJwkWBygpKSkpKSkpKSkpDQJkAAgg OEhYaHiImKi4yNjo+AgZCVBQUCApKSkpKSkpKSkpKSkpKSkpKSkpKSlJSDAwICkpKSkpKSkp KSl5GCApKSlZGCApKSkpKSkpKSkpScA4ICkpKSkpKSkpKSkpWWhgICkpKSkpKSmJWFBQICkp KSkpKSkpKSkpKSkpKSkpKSkpSRIiQAQEA4AAgoOEhYaHiImKi4yNjo+QkZKTjgGUlJSRAZSU lJSUlJSUlJIEiwOUlJSUlJSUlJSUlAYGlJSUlP+UlJSMBQWUlJSUlJSUlJSUlJSUlJSUlJSU lIkEA5SUlJSUlJSUlJSDAZSUlJEBlJSUlJSUlJSUkQSMA5SUlJSUlJSUlJSTgAaAAIKDhIWG h4iJiouMjY6PkI8FBQWRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGEBAMDkZGRkZGRkZGRkZGO AZGRkZGJAZGRkZGRkZGRkZGRigSLA5GRkZGRkZGRkZGRkY4GBpGRkZGRkZGRjQUFBZGRkZGR kZGRkZGRkZGRkZGRkZEiRYoUKRIiQAQEA4AAgoOEhYaHiImKi4yNjo+QkZKTigGUlJSRAZSU lJSUlJSUlJAEjAOUlJT/lJSUlJSUlJEGlJSUlJSUlIcFBQUFlJSUlJSUlJSUlJSUlJSUlJSU lJSUAAQDlJSUlJSUlJSUkwGUlJSRAZSUlJSUlJSUlJAEiwOUlJSUlJSUlJSUkIAMDAABBAcJ Cw0PERMVFxkbHR8hEQsKCgoiIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAQgGBiIjIyMjIyMj IyMjFQMiIyMjEwMiIyMjIyMjIyMjIxMJFgciIyMjIyMjIyMjIyMXDSIjIyMjIyMjDwsKCiIj IyMjIyMjIyMjIyMjIyMjI0WKFClSpEiRDAEiIBgABBAcJCw0PERMVFxkbHR8hIyUnDQMoKSk /4wMoKSkpKSkpKSkfCRYHKCkpKSkpKSkpKR8NKCkpKSkpKQEKCgooKSkpKSkpKSkpKSkpKSk pKSkpKSkhCQYoKSkpKSkpKSkfAygpKSMDKCkpKSkpKSkpHwkUBygpKSkpKSkpKSkdAQ0MAAE EBwkLDQ8RExUXGRsdHyEJCwoiIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjHwkGBiIjIyMjIyM jIyMjDQMiIyMjEwMiIyMjIyMjIyMjIw8JFgciIyMjIyMjIyMjIyMTDSIjIyMjIyMjBwsKCiI jIyMjIyMjIyMjIyMjIyMjIyMjBQpUqRIkSIBAERAMAAIIDhIWGh4iP+YqLjI2Oj4CBkpOSkY QElJGRlASUlJSUlJSUnpSKA4QElJSUlJSUlJSdloQElJSUlJGVlQUEBJSUlJSUlJSUlJSUlJ SUlJSUlJSUmJSDAwQElJSUlJSUlJqRhASUkZGUBJSUlJSUlJSdlIsDhASUlJSUlJSUlJuQjI wAAQQHCQsNDwEDFRcZGx0fHRsaCgoAASEhISEhISEhISEhISEhISEhISEhISEhISEhKSkIBg ABISEhISEhISEhKyMQASEhKyMQASEhISEhISEhISEhKAQHEAEhISEhISEhISEhISctAAEhIS EhISEpKwoKCgABISEhISEhISEhISEhIkSJD/IEGCBAkSJEiQIEGCBEkRIIIBQADBQcJCw0PE RMVFxkbHR8hIyciAycnJSYCAycnJycnJycnJSUGCxYHJycnJycnJycnJSQODycnJyclJyIKC gsnJycnJycnJycnJycnJycnJycnJycnJyUOCgYHJycnJycnJycnHgMnJyUmAgMnJycnJycnJ yUlBAsWBycnJyclJkyZNmjQJkAEggOAgYaHhIWKi4iJjo+NjYkFBASQkJCQkJCQkJCQkJCQk JCQkJCQkJCQkJCQkJCTkIAHBACQkJCQkJCQkJCRkYgAkJCRkYwAkJCQkJCQkJCQk5CPB4gAk JCQkJCQkJCQkJCSk/wEkJCQkJCQkZEEBJCQkJCQkJCQkJCQkJCQkJCQkSJAgQYIECRIkSJAg IQJEMAAIIDhIWGh4iJiouMjY6PgIGSnZGDA5OTkJEDA5OTk5OTk5OTkJQKA4MDk5OTk5OTk5 ORlpYDA5OTk5OclYUFAwOTk5OTk5OTk5OTk5OTk5OTk5OTk5OTk5STAwMDk5OTk5OTk5uRgw OTk5CRAwOTk5OTk5OTk5SaA4MDk5OTk5OWnSpEmRABkAAggOEhYaHiImKi4yNjo+FhYUFEBC QkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCPhIQDEBCQkJCQkJCQkJCFgZAQkICBBQGFP8G FAYkBkBCQkJCQkJCQkJCOhIoDkBCQkJCQkJCQkJCQjoaQEJCQkJCQi4WFBRAQkJCQkJCQkJC ggQJEiRIkCBBggQJEiRIkCBBggQJEiRCgAgGBgABBAcJCw0PERMVFxkbHR8hIyURAyYnFQMC CAMAAgYDAAIGAwACEAMmJycnJycnJyclCRQHJicnJycnJycnJx8NDCYnJycnJxELCiYnJycn JycnJycnJycnJycnJycnJycnJycbCQgGJicnJycnJycnDwMmJxMDAAIGAwYDAAIAAQQDAAIE AQIEBQUBAgABBAcJCw0PERMVFxkbHR8hIyUlCRQHJicnJycnJyf/JycdDSYnJycnJw8LCgom JycnJycnJycnJycnJycnJycnJycnJycnIwkGBiYnJycnJycnJwsDJicXAwYDBgMAAgYDAAIG Aw4BAwQHCQsFAQEEBwkLDQ8RExUXGRsdHyEjJQEIFAcmJycnJycnJycnGw0MJicnJycnCwsK CiYnJycnJycnJycnJycnJycnJycnJycnJycnBQkIBgYmJycnJycnJw0BAwQHCQsFAQEEBwkL DQ8REwkDBgMGAwACBgMAAgYDDgMUFRUVFRUVFRUVFRUVFRUVFRURCRQHFBUVFRUVFRUVFRUV FRUVFRUVFRUFDRQVFRUVFRUVFRUVEQsK/woAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3 OTs9PwsJCAZAQUFBQRsDQCMDBgMGAwACBgMAAgYDDgNAQUFBQTcJFAdAQUFBQUEVDUBBQSsL CkBBQUFBQUFBQUFBQUFBQTUJBgZAQUFBQRcDQCMDCAMAAgYDAAIGAwACEANAQUGBArUJEAEg gOAg4QAggOAgYaHhIWKi4iJjo+MjZKTkpKKBASUlJSXlY0FBASUlJSUlJSUlJSUlJSUlJSUl JSUlJSUlJWUiAcEAJSUlJSUlJaViACXlIWCAoCAAAEAAIICgYMCgYMDg4GAAIIDgIGGh4SFi ouIiY6PjI2Sk5P8jgeLA5OTk5OTk5OTkpKLB5OTk5ORkQUHB5OTk5OTk5OTk5OTk5OTk5OTk 5OTk5OTk5OQkAMHAwOTk5OTk5OQkZMDk5OQkQMDk5OTk5OTk5OQjgeLA5OTk5OTk5OTkZKLB 5OTk5KRkQcHk5OTkpEmTJk2aNGnSpEmTJk2aNGnSpEmTJk2aNKkQIAKCAUAAwUHCQsNDxETF RcZGx0fISMcASUlJycIASUlJSUlJSUlJyUICxQFJSUlJSUlJSUlJSQMDSUlJSUlJwoICSUlJ SUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUkCggFJSUlJSUlJScnBAElJScnCAElJSUn/SUlJ SUnJQoLEAUlJSUmSJEmSJEmSJEAGgACCg4SFhoeIiYqLjI2OhwUFgACCg4SFhoeIiYqLjI2O j5CRkpOUlZaXmJmam5ydnp+eBAQDoKCgoKCDAaCgjQGgoKCgoJkEiQOgoKCgoKCFBqCgoI8F BaCgoKCgoKCgoKCgoKCgoKCSBASgoKCgoIIBoKCNAaCgoKCgmASJA6CgoKCgoIQGBqCgoI0F BQWgoKCgQIECBQoUKFCgQIECBcoSIAICQADBQcJCw0PERMVFxkbHR8jIwwBJSUnJwgBJSUlJ SUlJSUlJQoLEAUlJSUlJSUlJSclHA0lJSUlJyYKCAklJSUlJ/0lJSUlJSUlJSUlJSUlJSUlJ SUlJSUlJyUgCAklJSUlJSUlJxwBJSUnJwgBJSUlJSUlJSUnJQYLEAUlJSUlJSZIkSZL0CJAB IIDgIGGh4SFiouIiY6OjYEEBIIDgIGGh4SFiouIiY6PjI2Sk5CRlpeUlZqbmJmen5ycoJAFB aGhoKGZAaOhiQGhoaGioJEHiQGhoaGhop0FoaKhhQUFBaGhoaGhoaGhoaGhoaGhoKCUBQWho aKhlQGjoYkBoaGhoaCRB4kBoaGhoaKdBaGgoYUFBQWhoaGhoaGioUKFChQoVKlSoTIAICAAB BAcJCw0PERMVFxkbHR8hIQMiIyMjE/8DIiMjIyMjIyMjIxkJEgciIyMjIyMjIyMjIwsNDCIj IyMjIwsKIiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMdCQgiIyMjIyMjIx0DIiMj IxMDIiMjIyMjIyMjIxcJEgciIyNFihQpUqRIkSIVAmQACCA4SFhoeIiYqLjI2LhYUAAIIDhI WGh4iJiouMjY6PgIGSk5SVlpeYmZqbnJ2en5CRoKQEBAICoqKroYICqaGCAqKioqukiQOCAq KioqWmkgKhpaUCAqKioqKioqKioqKioqKip6SUBAICoqKooYICqaGCAqKioqqkiQOCAqKioq SmlgICoKWlD/ICoqKioqKipKlChRokSJEiVqE6ABAgJAAMFBwkLDQ8RExUXGRsdHSMOAyMjI yMSAyMjIyMjIyMjISEWCxIHIyMjIyMjIyMjISEGDyMjIyEjHgoKCyMjIyMjIyMjIyMjIyMjI yMjIyMjIyMjIyMjIyMjIyMhIxwECAoLIyMjIyMjIyMGAyMjIyMSAyMjIyMjIyMjIyEQCQADB wcEBQADBQcJCw0PERMVFxkbHR8hISUmDycnJycnBgoLJycnJycnJycnJycnJycnJycnJycnJ ycnJycnJyUnFgQECAoLJycnJycnJwYDJyclJgIDJycnJycnJyUlEgsSBycnJycnJ/8nJSUgD g8nJyclJwYKCycnJycnJycnJycnJycnJSZMmTZo0adKkSZMmTZo0aZIjQAOCBAQEgACCg4SF hoeIiYqLjI2Oj40BkJCQkI0BkJCQkJCQkJCQkJCDBIgDkJCQkJCQkJCQkJCLBpCQkJCQkAAF BYAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGcAwMDBASioqKdAaKiiQGioqKi oogEiQOioqKiopAGoqKcBQWioqKioqKioqKioqKioqKiopADAwQEBKKiopoBoqKJAaKioqKi iASIA6KioqKijwYGoqKaBQUFoqKiokSJEiVKlChRokSJEv8lShQlQAOCBAQEgACCg4SFhoeI iYqLjI2Oj4UBkJCQkI0BkJCQkJCQkJCQkJAABIkDkJCQkJCQkJCQkJCIBpCQkJCQjgUFgACC g4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKJAwMDBAQEo6OjkQGjo4cBo6Ojo6OC BIgDo6Ojo6OJBqOjlwUFo6Ojo6Ojo6Ojo6Ojo6Ojo6OOAwMDBASjo6OPAaOjhwGjo6OjowAE iQOjo6Ojo4cGBqOjlgUFo6OjRo0aNWrUqFGjRo0aNWrUqEmABgYICAgAAQQHCQsNDxETFRcZ Gx0ZAx4fHx8fBQMeHx8fHx8fHx//Hx8XCRAHHh8fHx8fHx8fHx8fBQ0eHx8fHx8FCwoAAQQH CQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9P0FDRS8HBgYICEZHRxUDRkcPA0ZHR0dHCRAH RkdHR0cPDUZHLQtGR0dHR0dHR0dHR0dHR0dHRzkHBkZHRxUDRkcPA0ZHR0dHCRAHRkdHR0cN DUZHKwsKRkdHR0dHR0dHR0eNGjVq1KhRo0aNGmUIUAAggOAgYaHhIWKi4uJiACMjIyMjIyMj IyMjIyOjIQHiACMjIyMjIyMjIyMjIyMjI4ABIyMjIyMjo2FBASCA4CBhoeEhYqLiImOj4yNk pOQkZaXl/yVmpuYmZ6fnJ2io6ChpqalgwKlpwOnp6akkAeLA6enp6aWBwenpYkHB6enp6enp 6enp6enp6enp6enpKWHAqWnA6enpqSTB4cDp6enppcHp6WJBwenp6enp6enp6enp6enp6enp 6akhYAAggOAgYaHhIWKi4uJiACMjIyMjIyMjIyMjIyNjIQHiACMjIyMjIyMjIyMjIyOjogEj IyMjIyMjYUEBIIDgIGGh4SFiouIiY6PjI2Sk5CRlpeUlZqbmJmen5ydoqOgoaakpYsCpacDp 6elpJMHhwOnp6amlwelpYkHB6enp6enp6enp6enp6enp6enpqWLAqWnA6enpKf8kAeLA6enp KaWBwekpYkHB6enp6enp6enp6enp6enp6enpKSNgACCA4CBhoeEhYqLi4mIAIyMjIyMjIyMj IyMjIyMhweEAIyMjIyMjIyMjIyMjIyOiASMjIyMjI6NgQQEggOAgYaHhIWKi4iJjo+MjZKTk JGWl5SVmpuYmZ6fnJ2io6ChpqaljwKlpwOnp6ekjAeLA6enp6aTB6elhQcHp6enp6enp6enp 6enp6enp6ekpZMCpacDp6enpI8HhwOnp6emkwempYUHB6enp6enp6enp6enp6enp6enpqWQA IIDgIGGh4SFiouLiYgAjIyMjIyMjIyMjIyMjoyAB4gD/IyMjIyMjIyMjIyMjI6OhASMjIyMj 42JBASCA4CBhoeEhYqLiImOj4yNkpOQkZaXlJWam5iZnp+cnaKjoKGmpKWXAqWnA6enpqSPB 4cDp6elppIHB6SlhQcHp6enp6enp6enp6enp6enp6empZcCpacDp6elpIwHiwOnp6Smkwekp YUHB6enp6enp6enp6enp6enp6enpKSZgACCA4CBhoeEhYqLi4mIAIyMjIyMjIyMjIyMjIyMA weEAIyMjIyMjIyMjIyMjIyOhASMjIyMjY2JBASCA4CBhoeEhYqLiImOj4yNkpOQkZaXlJWam 5iZnp+cnaKjoKGmpqWbAqWnA/+np6SkjAeLA6enp6aPB6algQcHp6enp6enp6enp6enp6enp 6ekpZ8CpacDp6ekpI8HhwOnp6emjwekpQEHB6enp6enp6enp6enp6enp6enpqWcAIIDgIGGh 4SFiouLiYgAjIyMjIyMjIyMjIyMjI8HhACMjIyMjIyMjIyMjIyOjoAEjIyMjI+NhASCA4CBh oeEhYqLiImOj4yNkpOQkZaXlJWam5iZnp+cnaKjoKGmpKWjAqWnA6enp6SLB4cDp6empo8Hp aUHB6enp6enp6enp6enp6enp6enpaWjAqWnA6enp6SLB4cDp6ekpo4HBqWlBwenp6enp6enp 6enp6f/p6enp6enpaMCpKaAAQADBQcJCw0PERMVFxkbHR8jIRoLDAUlJSUlJSUlJSUMDSUlJ ycKCAkAAwUHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9P0FDRUdJS09KAU9OA09PTU0UC w4HT09NTRoPT0oKC09PT09PT09PT09PT09PT09PT09OAU9OA09PT00SCw4HT09PTRYNT0oKC 09PT09PT09PT09PT09PT09PT01PBgFNTQAGAAIKDhIWGh4iJiouMjY6PkJGMBIYDkpKSkpKS kpKShQaSkpKSgwWAAIKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6D/oaKjpKWmp4QB qKUBqKioqIQEhwOoqKiohgaoogUFqKioqKioqKioqKioqKioqKioqJkBqKUBqKioqIQEhgOo qKiohgaooQUFqKioqKioqKioqKioqKioqKioqJsBqKWAAgABBAcJCw0PERMVFxkbHR8hIxUJ DgckJSUlJSUlJSUFDQwkJSUlCwoAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9P0FD RUdJS01PEwNQSwNQUVFRBwkMB1BRUVEJDVBBCwpQUVFRUVFRUVFRUVFRUVFRUVFRPwNQSwNQ UVFRBwkMB1BRUVEHDVA/CwpQUVFRUVFRUVFRUVFR/1FRUVFRUUMDUEsBBQACCA4SFhoeIiYq LjI2Oj5CRiYSGA5ISkpKSkpKSkoCGEhKSkYWAAIIDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZq bnJ2en6ChoqOkpaanj4GoJYGoKKiogoSGA6goqKiChqgehYUoKKioqKioqKioqKioqKioqKi opIGoJYGoKKiogIQGA6goqKiAhgYoHYWFKCioqKioqKioqKioqKioqKioqKaBgACCA4SFhoe IiYqLi4GMDIyMjIyMjIyMjIyMhYSGA4wMjIyMjIyMjIyMjIyEhowMjIyMiYWFAACCA4SFhoe IiYqLjI2Oj5CRkpOUlZaXv9iZmpucnZ6foKGio6SlpqeUgaglgagoqKiEhgOoKKiohqgchYU oKKioqKioqKioqKioqKioqKioqIKBqCWBqCioqISGA6goqKeGqBuFhSgoqKioqKioqKioqKi oqKioqKiohIGoJYGAAIIDhIWGh4iJiouMjY6PkJGHhIUDkhKSkpKSkpKOhoYSEpKNhYAAggO EhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeagaglgagoqKeEhgOoKKilhqg bhYUoKKioqKioqKioqKioqKioqKioqIeBqCWBqCiop4SFA6goqKWGqBuFqCioqKioqKioqKi oqL/oqKioqKioiYGoJYGoKKiMgWIABBAcHAAEEBwkLDQ8BAxUXGRsdHxETJy0EBSUpKxoAAQ QHCQsNDwEDFRcZGx0fERMlJykrLS8hIzU3OTs9PzEzRUdJS01PTUMwC1NAAVFdWUoHAAFRWV 1AA1s6AAFRUVFRUVFRUVFRUVFRUVFRUVFZUxALU0ABUV1ZSgcAAVFVXUwAA1swAVFRUVFRUV FRUVFRUVFRUVFRUV1TEAtTQAEEBwkLDQ8BAxUXGRsdHxETKSkKBwQFJSUlJSUlJS0UBSUnKx oAAQQHCQsNDwEDFRcZGx0fERMlJykrLS8hIzU3OTs9PzEzRUdJS01PR0/zQAtTQAFRW1lKBw ABUVNdQANbMAFRUVFRUVFRUVFRUVFRUVFRUVFTUyALU0ABUVlZSgcAAVFTXUABWzoAAVFRUV FRUVFRUVFRUVFRUVFRUVVTIAtTQAFRUVKUAEgACCggOAAIKDhIWGh4iJiouMjY6PkJAGkZGR jAUFgACCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6gBqKUBqKioowSF A6ioqKAGqJYFBaioqKioqKioqKioqKioqKioqKiolgGopQGoqKijBIUDqKionwaolQUFqKio qKioqKioqKioqKioqKioqKiYAailAYAAgoOEhf+Gh4iJiouMjY6PkJGCBIQDkpKSkpKSkpKG BgaSkpKGBQWAAIKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqIYBqaQB qampnwSFA6mpqZoGqZQFqampqampqampqampqampqampqamIAamkAampqZ8EhAOpqamaBqmT BQWpqampqampqampqampqampqampqYkBqaQBgACCg4SFhoeIiYqLjI2Oj5CRBIUDkZGRkZGR kZGMBpGRkYkFgACCg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6iLAamk AampqZ4EhAOpqamZBqn/kgUFqampqampqampqampqampqampqamMAamkAampqZ4EhAOpqamY BqmRBQWpqampqampqampqampqampqampqY4BqaSAAYAAgoOEhYaHiImKi4yNjo+QkASEA5GR kZGRkZGRiwaRkZGHBYAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Slpqeo kAGppAGpqamdBIQDqamplwapkAUFqampqampqampqampqampqampqamRAamkAampqZwEhAOp qamXBqmQBampqampqampqampqampqampqampkwGppAGAAIKDhIWGh4iJiouMjY6PkI8EhAOR /5GRkZGRkZGJBpGRkYUFBYAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Sl pqeolAGppAGpqambBIQDqamplQYGqY8FqampqampqampqampqampqampqamWAamkAampqZsE hAOpqamUBqmPBQWpqampqampqampqampqampqampqZcBqY2AAYIAAAAAAYAAgoIBg4ODAYAA goOEhYaHiImKi4yNjo+QjQSEA5GRkZGRkZGRhwaRkZGEBQWAAIKDhIWGh4iJiouMjY6PkJGS k5SVlpeYmZqbnJ2en6ChoqOkpaanqJkBqYwBgwGCAQABgwEAAYgBqf+pqZoEhAOpqamTBqmO BampqampqampqampqampqampqampmwGpjAGDAQABgwEAAYMBhwGpqamZBIQDqampkwapjQUF qampUqVKlSpVqlSpUqVKlSpVqlSpUnECFAAIIDhIWGh4iJiYGBAQIBgwGAAQMBhwCBggOEhY KAgIIDhIWGh4iJiouMjY6PjISEA4AAkJCQkJCQnZaAAJCWlYAAggOEhYaHiImKi4yNjo+AgZ KTlJWWl5iZmpucnZ6fkJGio6SlpqeorqCBggOEhYKAgIIDhIWGh4iJiIGDAYABAwGAAQMBhw GKCoqKioqKioqKioqKioeEhAOKCoqKioqKj/qKioqKioqAhgoKioqKg4WFAACCA4SFhoeIiY qLjI2Oj4CBkpOUlZaXmJmam5ydnp+QkaKjpKWmp6ivoZkMoYMBgAEDAYABAwGHAYkJqaiklA OJCamhppkMpYkJqampqampqampqampqampqampoaGpDKGDAYIBgAEDAYABCAGJCamnpJQDiQ mpoaaZDKWJCampoqVapUqVKlSpUqVapUqVKlSpVKFKAAQADBQcJCw0PExMSAgADCgMKAxABF RUVFRUVFRUVFRUVFRUMCwgFFRUVFRUVFRUVFRUXFRANFRUVFRcGCAkAAwUHCQsNDxETFRcZG x0fISMlJykrLS8xM/81Nzk7PT9BQ0VHSUtNT1NGAVNKA1NRUSwLCgdTU1EcDg9TFgtTU1NTU 1NTU1NTU1NTU1NTU1NTU0oBU0oDU1FRLAsKB1NRUR4NUxoLU1NTU1NTU1NTU1NTU1NTU1NTU VNOAVNIAQADBQcJCw0PERMVFxkbHR0hEAsKByMjIyMjIyEgAg8jISICCAkAAwUHCQsNDxETF RcZGx0fISMlJykrLS8xMzU3OTs9P0FDRUdJS01PU04BU0oDU1NRKAsKB1NTURoPUxYLU1NTU 1NTU1NTU1NTU1NTU1NTU1NSAVNKA1NRUSgLCgdTU1EaDVMWCgtTU1NTU1NTU1NTU1NTU1P/U 1NTU1FSAgFRSwABAAMFBwkLDQ8RExUXGRsdHyEMCwoHIyMjIyMhISIPIyMgCQADBQcJCw0PE RMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/QUNFR0lLTU9TUwQDV0QBVVVVIAsIBVVXVRANVxIIC VVVVVVVVVVVVVVVVVVVVVVVVVdXMANXRAFVVVUgCwgFVVVVEA9XDggJVVVVVVVVVVVVVVVVV VVVVVVVV1c0A1VFAAYAAgoOEhYaHiImKi4yNjo+QhgSDA5GRkZGRkZGPBpGRjwWAAIKDhIWG h4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmIAar/owGqqqqPBIQDqqqqhwaq hgUFqqqqqqqqqqqqqqqqqqqqqqqqqqqeAaqjAaqqqo8EgwOqqqqGBgaqhgWqqqqqqqqqqqqq qqqqqqqqqqqqqqABqqOAAgABBAcJCw0PERMVFxkbHR8hCQkIByIjIyMjIyMZDSIjHQsKAAEE BwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1Nzk7PT9BQ0VHSUtNT1FTGQNURwNUVVUdCQYHVFVV Cw1UDQtUVVVVVVVVVVVVVVVVVVVVVVVVVUcDVEcDVFVVGwkIB1RVVQkNVA0LVFVVVVVVVVVV VVVVVVVVVVVVVVVJA1RHAwABBAcJCw0P/xETFRcZGx0fIQcJBgciIyMjIyMjFw0iIxsLCgAB BAcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/QUNFR0lLTU9RUyEDVEcDVFVVGQkIB1RV VQcNVAsLVFVVVVVVVVVVVVVVVVVVVVVVVVVPA1RHA1RVVRkJBgdUVVUHDVQLC1RVVVVVVVVV VVVVVVVVVVVVVVVVUQNURwMAAQQHCQsNDxETFRcZGx0fIQEICAciIyMjIyMjEw0iIxkLCgAB BAcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/QUNFR0lLTU9RUykDVEcDVFVVFwkGB1RV VQUNVAkLVFVVVf9VVVVVVVVVVVVVVVVVVVVVVQECVEcDVFVVFQkIB1RVVQEMVAcLClRVVVVV VVVVVVVVVVVVVVVVVVVVVQUDAAEEBwkLDQ8RExUXFwMYGRkZGRkZGRkZGQkJBgcYGRkZGRkZ GRkZDQ0MGBkZEwsAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9P0FDRUdJS01PUVMz A1RHA1RVVRMJCAdUVVMNVAcLClRVVVVVVVVVVVVVVVVVVVVVVVVVVQsDVEcDVFVVEwkGB1RV Uw1UBQsKVFVVVVVVVVVVVVVVVVVVVVVVVVVVDwNURwEFAAIIDhIWGh4iJiouMjY6Pjr/EhAO QEJCQkJCQjIaQEIyFgACCA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6i pnoGqI4GqKqqIhIMDqiqohqoAhQUqKqqqqqqqqqqqqqqqqqqqqqqqqqqKgaojgaoqqoeEhAO qKqeGqgCFKiqqqqqqqqqqqqqqqqqqqqqqqqqqjIGqI4CBgACCA4SFhoeIiYqLjI2Oj42EgwO QEJCQkJCQi4aQEIqFhQAAggOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Slpqe oqaKBqiOBqiqqhoSEA6oqpoaqBaoqqqqqqqqqqqqqqqqqqqq/6qqqqqqPgaojgaoqqoaEgwO qKqaGqgWqKqqqqqqqqqqqqqqqqqqqqqqqqqqQgaojgaoqqoWAkQAAAAAMAAIIDhIWGh4iJio uMjY6PgIYAAJmVhQAAggOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmpucnZ6fkJGio6Slpqeoqa ahqgOhqgqqpaSDA4oKpKamCQWqCqqqqqqqqqqqqqqqqqqqqqqqqqqjoZoDoaoKqqWkgwOKCq OmqgWqCqqqqqqqqqqqqqqqqqqqqqqqqqqkoZoDoaoKqqihAgAgAAgAFAAMFBwkLDQ8RExUXG RkdHg8fHxYICQADBQcJCw0PERMVFxv9Gx0fISMlJykrLS8xMzU3OTs9P0FDRUdJS01PUVNUA 1dEAVVVVQoLBAVVVUYPUAlVVVVVVVVVVVVVVVVVVVVVVVVVV1csA1dEAVVXVQYLBAVVVUQPU ggJVVVVVVVVVVVVVVVVVVVVVVVVVVVXMANXRAFVVVYMAEQAAAAwAAggOEhYaHiImKi4yNjoy Gjw+KhYAAggOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqFgasigas rqoSDA6srn4aoBasrq6urq6urq6urq6urq6urq6urq4aBqyKBqyuqhIMDqyuehqcFhSsrq6u rq6urq6urq7/rq6urq6urq6uHgasigasrqYCIgAAABgABBAcJCw0PERMVFxkbHRcNHh8TCwA BBAcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/AQNFR0lLTU9RU1VTQxYFQ1YXU0lEBxY XfU0OC1YXV1dXV1dXV1dXV1dXV1dXV1dXV1VDFgVDVhdRSUYHFhd7TQwLShYXV1dXV1dXV1d XV1dXV1dXV1dXV1dDFgVDVhdRQVEAAAwAAggOEhYaHiImKi4yNjoqGjw+IhYAAggOEhYaHiI mKi4yNjo+AgZKTlJWWl5iZmpucnZ6fkJGio6SlpqeoqaqtoYsCoasLp6SjA4sLrK/2lgWrC6 urq6urq6urq6urq6urq6urq6uuoYsCoasLp6SiA4sLrKaVBaULC6urq6urq6urq6urq6urq6 urq6uvoYsCoasLpqCogAAABgABBAcJCw0PAQMVFxkbHREdHg8fGwABBAcJCw0PAQMVFxkbHR 8REyUnKSstLyEjNTc5Oz0/MTNFR0lLTU9BQ1VTUyYFU0YHXVlEBwYHV106C0YHV1dXV1dXV1 dXV1dXV1dXV1dXV1VTJgVTRgdbWUYHBgdVXToLRgdXV1dXV1dXV1dXV1dXV1dXV1dXV1MmBV NGB1tRSQAABgABBAcJCw0PAQMVFxkbHR8dDg8fGwABBAcP+QsNDwEDFRcZGx0fERMlJykrLS 8hIzU3OTs9PzEzRUdJS01PQUNVWVMmBVNGB1lZRgcGB1NdOAtKBgdXV1dXV1dXV1dXV1dXV1 dXV1dXW1MmBVNGB1lZRAcGB1NdOAtGB1dXV1dXV1dXV1dXV1dXV1dXV1dfUyYFU0YHV1FBAB AADAACCA4CBhoeEhYqLiImOjY6HB46NhASCA4CBhoeEhYqLiImOj4yNkpOQkZaXlJWam5iZn p+cnaKjoKGmp6SlqqipmwKpowOrqKIHgwOrqpYHBaEHB6urq6urq6urq6urq6urq6urq6upq ZsCqaMDqqijB4MDqqqUBacHq6ur/6urq6urq6urq6urq6urq6urqZsCqaMDqqihABAAAA4AA goOEhYaHiImKi4yNjoMGj4+GBYAAgoOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGi o6SlpqeoqaqcAauiAauroQSDA6urlQajBQWrq6urq6urq6urq6urq6urq6urq6udAauiAaur oQSCA6urlQajBaurq6urq6urq6urq6urq6urq6urq58Bq6IBq6uggAgAAAAGAAEEBwkLDQ8R ExUXGRsdAQweHwsLAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1Nzk7PT9BQ0VHSUtNT1FT VUEDVkUD/1ZXQQkEB1ZXKQ1ECwpWV1dXV1dXV1dXV1dXV1dXV1dXV1dDA1ZFA1ZXPwkGB1ZX Jw1EC1ZXV1dXV1dXV1dXV1dXV1dXV1dXV0cDVkUDVlc/AREAAAwAAggOEhYaHiImKi4yNjoa ODoWFhQAAggOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Slpqeoqaqkgasigas rnoSCA6srk4ahBasrq6urq6urq6urq6urq6urq6urq6aBqyKBqyuehIIDqyuShqEFqyurq6u rq6urq6urq6urq6urq6urp4GrIoGrK52AhIAAAwAAggOEhYaHiImKi4yNjYaOP86EhYUAAII DhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqqIGrIoGrK52EggOrK5G GoAWrK6urq6urq6urq6urq6urq6urq6uqgasigasrnISCA6srkYagBasrq6urq6urq6urq6u rq6urq6urq6uBqyKBqyucgISAAAMAAIIDhIWGh4iJiouMjYuGjg6DhYUAAIIDhIWGh4iJiou MjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq4CBLCGAiIIDhIWGh4iJiouMjY6PkJG Sk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytroaAgL/CA4SFhoeIiYqLjI2OioGPD4+Pj4K Bjw+Pj4+Pj4iEggOPD4+Pj4+Lho8PgIUAAIIDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2 en6ChoqOkpaanqKmqq4SBrCGBrCyYhIIDrCyNhp4FhSwsrKysrKysrKysrKysrKysrKysrJu BrCGBrCyYhIIDrCyMhp4FrCysrKysrKysrKysrKysrKysrKysnYGsIYGsLJeAkQAADAACCA4 SFhoeIiYqLjI2Jho4OgoWAAIIDhIWGh4iJiouMjY6PgIGSk5SVlpeYmZqbnJ2en5CRoqOkpa anqKmqq6ihjAGhrAynpJIDjA/8q6aOBZwMrKysrKysrKysrKysrKysrKysrK+hnAGgp4IDhI WGh4iJiouMjY6PgIGSk5SVlpeYmZqbnJ2en5CRoqOkpaanqKmqq6ytrqaggIIDhIWGh4iJio uMjY6KgY8Pj4+PgoGPD4+Pj4+PhYSCA48Pj4+Pj4eGjw+FhQAAggOEhYaHiImKi4yNjo+AgZ KTlJWWl5iZmpucnZ6fkJGio6Slpqeoqaqrq6GMAaGsDKWkkgOMDKmmjgWcDKysrKysrKysrK ysrKysrKysrKyjoawBoawMpaSSA4wMqKaOBZwMrKysrKysrKysrKysrKysrKysrKShrAGhrA ykoJiP8AAGAAEEBwkLDQ8BAxUXGRsbHQwNFRsAAQQHCQsNDwEDFRcZGx0fERMlJykrLS8hIz U3OTs9PzEzRUdJS01PQUNVV19TGANTSAlZWSQHCAlfXQoLOggJWVlZWVlZWVlZWVlZWVlZWV lZWV1TSANTSAlXWSQHCAlfXQoLOAlZWVlZWVlZWVlZWVlZWVlZWVlZUVNYA1NICVdRIgAgCA AUAAwUHCQsNDxETFRcbGQQNHR4ACQADBQcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/Q UNFR0lLTU9RU1dXJANbQAFZWSQLBAVZWQ4POAlZWVlZWVlZWVlZWVlZWVlb/VlZWVlbVANbQ AFZWSQKAAVZWQ4POAlZWVlZWVlZWVlZWVlZWVlZWVlZW1tUA1sWAgABAAMEAQUGAAEFBQUGA AEAAwUHCQsNDxETFRcZGRwLBAUdHR0dHx0QDR8eCAkAAwUHCQsNDxETFRcZGx0fISMlJykrL S8xMzU3OTs9P0FDRUdJS01PUVNVVywBWxYDCAICAwQCAAMQAVtZIAoABVtZCA84CVlZWVlZW VlZWVlZWVlZWVlZWVlZWVsEA1sSAwoDBAICAwYDDAFZWSALBAVZWQgPOAlZWVlZWVlZWVqxY sWLFihUrVqxYsWLFahCgAEAAwUHCQsNDxETEgICA/wDBgMEAgIDBgEPAAMFBwkJBQADBQcJC w0PERMVFRkUCgIHGxsbGxsZGAIPGRoCCAkAAwUHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3O Ts9P0FDRUdJS01PUVNVVRcAAwUHCQkFAAMFBwkLDQ8RExIDBAICAwQCAgMGAwwBFRUVFRUVF RUXFQQLBAUVFRUVFRUVFRQADRcXDAkAAwUHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9P 0FDRUdJS01PUVNVVzgDWxIDBAICAwQCAgMGAwwBW1kcCgAFW1kGDzQJWVlZWVlZWVlZWVlZW VlZWVlZWVlbWwwDWxIDBAP/BAICAwQCAAMQAVlZHAsEBVlZBA82CAlZWVlasWLFixYoVK1as WLFixYoVK1asWCECFAAIIDhIWGh4iJiYGBAQQBhQGJAYoKioqKioqKioqChIADCgqKioqKio qKhooKhoWAAIIDhIWGh4iJiouMjY6PgIGSk5SVlpeYmZqbnJ2en5CRoqOkpaanqKmqq6ChrA GhrAytpIADDAyipooFnAysrKysrKysrKysrKysrKysrKysrKuhjAGhrAytpIADDAygpgkFlQ wMrKysrKysrKysrKysrKysrKysrKysoYwBoKGAAIIDhIWGh4iJiouMjYmEgAMODo6Ojo6Fho 4Lj/WAAIIDhIWGh4iJiouMjY6PgIGSk5SVlpeYmZqbnJ2en5CRoqOkpaanqKmqq6ShrAGhrA yspIADDAumpgkFnAysrKysrKysrKysrKysrKysrKysrK+hjAGhrAyrpIADDAumqQWVDAysrK ysrKysrKysrKysrKysrKysrKChnAGhoACCA4SFhoeIiYqLjI2IhIADDg6Ojo6OgoaOC4WAAI IDhIWGh4iJiouMjY6PgIGSk5SVlpeYmZqbnJ2en5CRoqOkpaanqKmqq6ihrAGhrAyqpIADDA qmqQWcDKysrKysrKysrKysrKysrKysrKyso6GcAaGsDKqkgAMMCaapBZ/8DKysrKysrKysrK ysrKysrKysrKyspKGcAaGsDKmgiIAGAAEEBwkLDQ8BAxUXGR8dCgkbEAEEBwkLDQ8BAxUXGR sdHxETJScpKy0vISM1Nzk7PT8xM0VHSUtNT0FDVVdXU1gDU0gJU1kQBggBXVALOggJWVlZWV lZWVlZWVlZWVlZWVlZWVldUygDU0gJUVkQBggBXVALOAlZWVlZWVlZWVlZWVlZWVlZWVlZWV FTOANTSAlRURIIIBQADBQcJCw0PERMVFRkODxsUCQADBQcJCw0PERMVFxkbHR8hIyUnKSstL zEzNTc5Oz0/QUNFR0lLTU9RU1VXWwYBW0IDW1v9CAoCBVlMDzILW1tbW1tbW1tbW1tbW1tbW 1tbW1tZWwoBW0IDW1kKCgVZTg8uCgtbW1tbW1tbW1tbW1tbW1tbW1tbW1tbCgFbQgNZWQoAI AAYAAQQHCQsNDxETFRcZCQ0aFQsAAQQHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9P0FD RUdJS01PUVNVV1kPA1pBA1pbCQkGWksNLgtaW1tbW1tbW1tbW1tbW1tbW1tbW1tbEQNaQQNa WwcJAAZaSQ0uC1pbW1tbW1tbW1tbW1tbW1tbW1tbW1sTA1pBA1pbBQERAAwAAggOEhYaHiIm Ki4yDho0KhYAAggOEhb/Gh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6y Kga0gga0tgoSAAy0jhpYFhS0tra2tra2tra2tra2tra2tra2tra2Lga0gga0tgIQAAy0jhpY FrS2tra2tra2tra2tra2tra2tra2trY2BrSCBgACCA4SFhoeIiYqLjI2Egw0NjY2NjYKGjQm FgACCA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusjoGtIIGtLYS AAy0ihpYFrS2tra2tra2tra2tra2tra2tra2trY+BrSCBrS2Egy0ihpUFhS0tra2tra2tra2 /7a2tra2tra2tra2tkIGtIICKggOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6S lpqeoqaqrrK2uhoCAggOEhYaHiImKi4yNjoqBjw+Pj4+CgY8Pj4+PjoSDDw+Pj4+ChoYPBoW AAIIDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6yTga0gga0rhIA DLR+GlgWtLa2tra2tra2tra2tra2tra2tra2tlIGtIIGtK4SDLR+GlgWtLa2tra2tra2tra2 tra2tra2tra2tlYGtIIGtKoSAAAOAAIIDhIWGh4iJiouJhowJhYUAP8CCA4SFhoeIiYqLjI2 Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusloGtIIGtKYSAAy0ehpUFrS2tra2tra2 tra2tra2tra2tra2trZiBrSCBrSmEgAMtHYaVBa0tra2tra2tra2tra2tra2tra2tra2Zga0 gga0ohIAAgwAAggOEhYaHiImKi4iGjAmFgACCA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5y dnp+goaKjpKWmp6ipqqusmoGtIIGtKISDLR2GlAWFLS2tra2tra2tra2tra2tra2tra2trZu BrSCAiYIDhIWGh4iJiouMjY6PkJGSk5SVlr/XmJmam5ydnp+goaKjpKWmp6ipqqusra6GgIC CA4SFhoeIiYqLjI2OioGPD4+Pj4KBjw+Pj4+JhIMPD4+PjYaPBYWAAIIDhIWGh4iJiouMjY6 PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6yega0gga0mhIADLRuGlAWtLa2tra2tra2 tra2tra2tra2tra2tn4GtIIGtJoSDLRyGkwWtLa2tra2tra2tra2tra2tra2tra2toIGtIIG tJYSAAAOAAIIDhIWGh4iJiouGhowGhYUAAIIDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2 en6ChoqOkpaanqKm/6qusoYGtIIGtJISAAy0bhpIFrS2tra2tra2tra2tra2tra2tra2traO BrSCBrSSEgy0bhpIFrS2tra2tra2tra2tra2tra2tra2traSBrSCBrSOEgAADgACCA4SFhoe IiYqLhYaMBoWAAIIDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6y lga0gga0jhIMtGoaRBYUtLa2tra2tra2tra2tra2tra2tra2tpoGtIIGtIoSAAy0ZhpEFrS2 tra2tra2tra2tra2tra2tra2traiBrSCBrSKEgAOAAIIDhIWGh4iJiouEhowFhYAAggOEv8W Gh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ypga0gga0hhIMtGYaRBa0 tra2tra2tra2tra2tra2tra2tra2qga0gga0hhIMtGIaRBa0tra2tra2tra2tra2tra2tra2 tra2rga0gga0ghIMtF4CMjAABBAcJCwEKCgABBAcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc 5Oz0/AQNFR0lLTU9RU1VXWVlDWgFDWgFJRhotTSILGhtbW1tbW1tbW1tbW1tbW1tbW1tbW1t BQhoBQ1o/SQYaLU0iCxobW1tbW1tbW1tbW1tbW1tbW1tbW1tbRX/DGgFDWj1JAAEGAAEEBwk LDQ8RExUXDRYNCwABBAcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/AQNFR0lLTU9RU1V XWVtHQxw/Qxw7SQYcKU0iCxwdXV1dXV1dXV1dXV1dXV1dXV1dXV13Qxw/Qxw5SQYcKU0iCxw dXV1dXV1dXV1dXV1dXV1dXV1dXV15Qxw/Qxw5SQYAAQQHCQsNDxETFRUNFgsLCgABBAcJCw0 PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/AQNFR0lLTU9RU1VXWVtNQxw/Qxw3SQYcJ00gCxw dXV1dXV1dXV1dXV1dXV1dXV1dXV1/Qxw//0McN0kGHCVNIAscHV1dXV1dXV1dXV1dXV1dXV1 dXV1dQUNcP0McNUkGAAEEBwkLDQ8RExUTDRYLCwABBAcJCw0PERMVFxkbHR8hIyUnKSstLzE zNTc5Oz0/AQNFR0lLTU9RU1VXWVtVQxw/QxwzSQYcJU0gCxwdXV1dXV1dXV1dXV1dXV1dXV1 dXV1FQ1w/QxwzSQYcI00gCxwdXV1dXV1dXV1dXV1dXV1dXV1dXV1HQ1w/QxwxSQYAAQQHCQs NDxETFRENFgsLAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1Nzk7PT8BA0VHSUtNT1FTVVd ZW1tDHD9DHDFJP9wjTR4LChwdXV1dXV1dXV1dXV1dXV1dXV1dXV1LQ1w/QxwvSQYcIU0eCxw dXV1dXV1dXV1dXV1dXV1dXV1dXV1PQ1w/QxwtSQYAAQQHCQsNDxETFQ8NFgkLAAEEBwkLDQ8 RExUXGRsdHyEjJScpKy0vMTM1Nzk7PT8BA0VHSUtNT1FTVVdZW2NDHD9DHC1JBhwfTR4LHB1 dXV1dXV1dXV1dXV1dXV1dXV1dXVNDXD9DHCtJBhwfTR4LHB1dXV1dXV1dXV1dXV1dXV1dXV1 dXVVDXD9DHCtJHB9BGQACCA4SEhYUAAIIDhIWGh4iJiouMjY6PgIGSk5SVlpeYmZqbn/ydnp +QkaKjpKWmp6ipqqusraShng+hngSkkw4Opo4Fjg6urq6urq6urq6urq6urq6urq6urq2hrg +hngSkng6mjgWODq6urq6urq6urq6urq6urq6urq6urqGuD6GeA6STDgygjIwAAQQHCQkLAA EEBwkLDQ8BAxUXGRsdHxETJScpKy0vISM1Nzk7PT8xM0VHSUtNT0FDVVdZW1FTPA9TPAVZJg wJXRwLGgwNXV1dXV1dXV1dXV1dXV1dXV1dXV1dVVMMD1M8BVksCV0cCxwNXV1dXV1dXV1dXV 1dXV1dXV1dXV1dWVMMD1M8A1EpBgABBAcJCw0PAQMVFR0GBx/7AAEEBwkLDQ8BAxUXGRsdHx ETJScpKy0vISM1Nzk7PT8xM0VHSUtNT0FDVVdZW1lTPA9TPANZLAddHAscDV1dXV1dXV1dXV 1dXV1dXV1dXV1dXV1TDA9TPAFZJgwFXRwLHA1dXV1dXV1dXV1dXV1dXV1dXV1dXV1fUwwPUz wPWRAHAAEEBwkLDQ8BAxURHAYFGwoAAQQHCQsNDwEDFRcZGx0fERMlJykrLS8hIzU3OTs9Pz EzRUdJS01PQUNVV1lbX1M8D1M8D1kcBV0aCxwNXV1dXV1dXV1dXV1dXV1dXV1dXV1dVVMcD1 M8DVkWDANdGgscDV1dXV1dXV1dXV1f/V1dXV1dXV1dXV1XUxwPUzwLWRAHAAEEBwkLDQ8BAx UdFAUbCgABBAcJCw0PAQMVFxkbHR8REyUnKSstLyEjNTc5Oz0/MTNFR0lLTU9BQ1VXWVtXU0 wPUzwLWRwBXRwICxwNXV1dXV1dXV1dXV1dXV1dXV1dXV1dXVMcD1M8CVkWDA9dCgscDV1dXV 1dXV1dXV1dXV1dXV1dXV1dXV9THA9TPAlRGQABBAcJCw0PAQMRHRQFGwoAAQQHCQsNDwEDFR cZGx0fERMlJykrLS8hIzU3OTs9PzEzRUdJS01PQUNVV1lbX1NMD1M8B1kWDA1dCAscDV1dXV 1dXV1dXV1dX/1dXV1dXV1dXV1VUywPUzwFWRYMDV0ICxwNXV1dXV1dXV1dXV1dXV1dXV1dXV 1dV1MsD1M8BVEZAAEEBwkLDQ8BAx8dBAEaCgABBAcJCw0PAQMVFxkbHR8REyUnKSstLyEjNT c5Oz0/MTNFR0lLTU9BQ1VXWVtXU1wFUxgDCgMCAxwDWRYMC10GCxwNXV1dXV1dXV1dXV1dXV 1dXV1dXV1dXVMsA1MSBgMAAgYDAAIAAxwDWRwLXQYLHA1dXV1dXV1dXV1dXV1dXVlStXrly5 cuXqEqAAQADBQcJCw0PExMQAgADBgMEAgIDBgMMARUVFRUVCggFFRUVFRQPFggJA/wDBQcJC w0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/QUNFR0lLTU9RU1VXWVleAgFfDAMEAwYDBAICA wYBDwADBQcJCQUAAwUHCQsNDRACCgcTExMTEQoNEgAJAAMFBwkLDQ8RExUXGRsdHyEjJScpK y0vMTM1Nzk7PT9BQ0VHSUtNT1FTVVdbWUMAAwUHCQkFAAMFBwkLDQ8RExADBAMGAwQCAgMGA wwBFRUVFxUECRUVFxUQDA8UCQADBQcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/QUNFR 0lLTU9RU1VXWVlfCgFdDwABBQYAAAACAAIAAAACAAEAAwf9BgABAAMFBwkLDQ8TEQ4IBRUVF RUQDRYACQADBQcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/QUNFR0lLTU9RU1VXWVtfC gNfEgMEAgIDBAIAAxIBXQoKBVwCDxYLX19fX19fX19fX19fX19fX19fX19fXV8OA18QAwoDC gMSAV0KCVwADxYKC19fX19fX19fX19fX19dXr169evXq1atXhwAFAAIIDhIWGh4iJiouLgYw MjIyChIMMDIyLhooFgACCA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6i pqqusra6Jga8ega8ChIMvBooFrz/vr6+vr6+vr6+vr6+vr6+vr6+vr6+vioGvHoGvAoSvBoo Fry+vr6+vr6+vr6+vr6+vr6+vr6+vr6+Lga8ega8AhAMAAIIDhIWGh4iJgIYJBYUAAIIDhIW Gh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytroyBrx6BrwCELgaJBa8 vr6+vr6+vr6+vr6+vr6+vr6+vr6+vjoGvHoGvBIMtBokFry+vr6+vr6+vr6+vr6+vr6+vr6+ vr6+Pga8ega4EgywGgAaAAIIDg4WAAIIDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6C hoqOkpaa/56ipqqusra6Qga8ega4ErAaKBa8vr6+vr6+vr6+vr6+vr6+vr6+vr6+vkYGvHoG tBIMrBokFhS8vr6+vr6+vr6+vr6+vr6+vr6+vr6+vkoGvHoGsBIMrBoAAggODhYAAggOEhYa HiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ulIGvHoGsBKsGiQWvL6+ vr6+vr6+vr6+vr6+vr6+vr6+vr5WBrx6BqwSDKgaJBa8vr6+vr6+vr6+vr6+vr6+vr6+vr6+ vloGvHoGqBIMqBogAhYUAAIIDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2ev9+goaKjpKW mp6ipqqusra6Xga8egaoEqgaIBa8vr6+vr6+vr6+vr6+vr6+vr6+vr6+vmYGvHoGpBIMpBog Fry+vr6+vr6+vr6+vr6+vr6+vr6+vr6+aga8egagEgykGiACFgACCA4SFhoeIiYqLjI2Oj5C RkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6bga8egagEqAaGCAWvL6+vr6+vr6+vr6+ vr6+vr6+vr6+vr5yBrx6BpwSDJwaIBYUvL6+vr6+vr6+vr6+vr6+vr6+vr6+vr52Brx6BpgS DJwCGgACCA4KFgACCA4SFhoeIiYqLjI2Oj5CRkpOUlb/Wl5iZmpucnZ6foKGio6Slpqeoqaq rrK2un4GvHoGlBIMnBogFry+vr6+vr6+vr6+vr6+vr6+vr6+vr6+gga8egaUEpwaHBYUvL6+ vr6+vr6+vr6+vr6+vr6+vr6+vr6GBrx6BpASDJgaAAIIDgIUAAIIDhIWGh4iJiouMjY6PkJG Sk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrqOBrx6BowSDJgaHBa8vr6+vr6+vr6+vr6+ vr6+vr6+vr6+vpIGvHoGjBKUGhgYFhS8vr6+vr6+vr6+vr6+vr6+vr6+vr6+vpYGvHoGiBIM kAIaAAIIDgIUAAIIDhIWGh4i/yYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqu sra6nga8egaEEgyQGhwWvL6+vr6+vr6+vr6+vr6+vr6+vr6+vr6iBrx6BoQSkBoYFhS8vr6+ vr6+vr6+vr6+vr6+vr6+vr6+vqYGvHoGgBIMjBoAAggOFgACCA4SFhoeIiYqLjI2Oj5CRkpO UlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6rga8egZ8EgyIGhgYFry+vr6+vr6+vr6+vr6+ vr6+vr6+vr6+sga8egZ8EogaGBYUvL6+vr6+vr6+vr6+vr6+vr6+vr6+vr62Brx6BngSiBoA AggOFv8AAggOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur4G vHoGdBIMhBoYFry+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vgIEvHoGcBIMhBoYFry+vr6+vr6+ vr6+vr6+vr6+vr6+vr6+vgoGvHoGcBKEAhoAAggOFgACCA4SFhoeIiYqLjI2Oj5CRkpOUlZa XmJmam5ydnp+goaKjpKWmp6ipqqusra6vg4GwHYGbBKEGhQWFMDCwsLCwsLCwsLCwsLCwsLC wsLCwsLCcgbAdgZoEoAaGBQWwMLCwsLCwsLCwsLCwsLCwsLCwsLCwsJ6BsD/dgZkEgx8AhoA AggOFgACCA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vh4G wHYGZBJ8GhQWFMDCwsLCwsLCwsLCwsLCwsLCwsLCwsLCggbAdgZgEnwaFBbAwsLCwsLCwsLC wsLCwsLCwsLCwsLCwooGwHYGXBJ8GhQCFgACCA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5y dnp+goaKjpKWmp6ipqqusra6vi4GwHYGWBIMeBoQFhTAwsLCwsLCwsLCwsLCwsLCwsLCwsLC wpIGwHYGWBJ4GhAWwMLCwsLCwsLCwsLCwsLCwsLC/8LCwsLCmgbAdgZUEnQaABoAAAAAFAAC CA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vj4GwHYGUBJ0 GhAWFMDCwsLCwsLCwsLCwsLCwsLCwsLCwsLCogbAdgZMEnQaEBbAwsLCwsLCwsLCwsLCwsLC wsLCwsLCwqoGwHYGTBJwGhACFgACCA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaK jpKWmp6ipqqusra6vk4GwHYGSBJwGgwWFMDCwsLCwsLCwsLCwsLCwsLCwsLCwsLCsgbAdgZE EmwaGAwWwMLCwsLCwsLCwv/CwsLCwsLCwsLCwsLCugbAdgZAEmwaAAIIAhQAAggOEhYaHiIm Ki4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur5eBsB2BjwSbBoQFsDCwsLC wsLCwsLCwsLCwsLCwsLCwsLCwgbAdgY8EmgaEBbAwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsIC BMB2BjgSZBoYAAIIFhQAAggOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Slpqe oqaqrrK2ur5qBsB2BjQSZBoQFsDCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwhIGwHYGMBJkGhAW wML/wsLCwsLCwsLCwsLCwsLCwsLCwsLCwhYGwHYGMBJgGgACCBYUAAIIDhIWGh4iJiouMjY6 PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+egbAdgYsEmAaDBbAwsLCwsLCwsLC wsLCwsLCwsLCwsLCwsIiBsB2BigSXBoYDBbAwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsImBsB2 BiQSXAIaAAAAFBQAAggOEhYaHiImKi4yNjo+QkZKTlJWWl5iZmpucnZ6foKGio6Slpqeoqaq rrK2ur6KBsB2BiASXBoMFsDCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwjIG/8B2BhwSWBoYDBbA wsLCwsLCwsLCwsLCwsLCwsLCwsLCwsI2BsB2BhgSWAIaAAAAFBQAAggOEhYaHiImKi4yNjo+ QkZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur6aBsB2BhQSWBoMFsDCwsLCwsLCwsLC wsLCwsLCwsLCwsLCwkIGwHYGEBJUGhgIFhTAwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsJGBsB2 BhASAAIIDhIWFhoMFgACCA4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6i pqqusra6vq4GwHYGDBJQGgwWwMLCwsLCwsLCwv/CwsLCwsLCwsLCwsLCwlIGwHYGCBJMGhgI FhTAwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsJWBsB2BgAQAAIIDhIWEhoMFgACCA4SFhoeIiYq LjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vr4GwHYGEEwaDBbAwsLCwsLC wsLCwsLCwsLCwsLCwsLCwsJiBsB2EkgaGAgWFMDCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwmYG wHYGRBoMFsDCwoIFCxYsWLBgwYIFCxYsWLBgwYIFCxYsWJsABQACCA4SFhoeIiYqLi4GMBIa CBYUAAIIDhIWGh4iJir/LjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWmp6ipqqusra6vsIS BsRyBjwaCBbExsbGxsbGxsbGxsbGxsbGxsbGxsbGxsYaBsRyBjgaCBbExsbGxsbGxsbGxsbG xsbGxsbGxsbGxsYeBsRyBjAaGAAUFMTGxooVyxSgAEAAwUHCQsNDxETFRcZGx0fISMlJykrL y8sATExMTExMTExMTExMxgBMTExMTExMTExMTMzFAExMzMKARQPBAkxMTExMTExMTEzMygBM TExMTExMTExMTMzFAExMTExMTExMTExMTMYATExMTExMTExMTEzMxQBMTMzCAEUDwQJAAMFB /8JCw0PERMVFxkbHR8hIyUnKSstLxQBMTExMTExMTExMTMzFAExMTExMTExMTExMTMYATExM TExMTExMTEzMxQBMTMzCAEQDA4CCAkxMTExMTExMTEzMywBMTExMTExMTExMTMzFAExMTExM TExMTExMTMYATExMTExMTExMmDBhWgQoABBAcJCw0PAQMVFxcTHg0ECwgJGRkZGRkZGRkZGR kZGRkZGRkZGRkZGRESCAkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZFxMYCRkZGRkZGRkZGRkZGR kZGRkZGRkZGRkZExgJGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRcTGAkf+RkZGRsRCgAEAAwUED gIICQADBQcJCw0PERMVFxkbHR8hIyUnKSstLxwBMTExMTExMTExMTMzFAExMTExMTExMTExM TMYATExMTExMTExMTEzMxQBMTMzCAEIDA4ACTEzMxABMTMIAzMYATMKAy4DJAMiAx4DGAExM zMgATEzCAEzGAMzCAMuAyYDIAMeARsAAQADBQcJCw0PERMVFxsWAxsbGxoDGxsWAxkbBgEbF gEbDgMbBgEbBgMaAxsbGxsbGxYDGxsbGgMZGxYDGxsGAxsSARsOARsKARoCAxoDGxsbGRsaA QQOAgoLGxsbGxkbCgMbGxsaAxsbFgMZGwYD/RsWARsOAxsGARsGAxoDGxsbGRo0WAQoABBAc JCw0PERMPAxQVFQ0DFBUTAxQVBQMUEwMUDwMUCQMUBwMUFRUVFRUVFRMDFBUVFRUFAxQVFQ8 DFBURAxQVBwMUEwMUDQMUCwMUBwMUFRUVFRUVFRMDFBUVFRUFAxQVFQ0DFBUTAxQVBQMUEwM UDwMUCQMUBwMUFRUVFRUVDwEKAAAwKCgABBAcJCw0PAQMVFxkdEwoLGxsTGgsXExoLFRMKBR MaDRMKBxMKBRMKAxoLGxsbGxcTGgsbGxMaCxUTGgsXEwoDExoNEwoJEwoBEgoDGgsbGxsbFx MaCxsbExoLFxMaCx/1EwoFExoNEwoHEwoFEwoDGgsbGxsbFxMaCxsbExoLFREVAAIIDgIGGh 4SFAACKiYQAi4mAAIiJAAKJhAGJhACIiIiIiomFAQABhQGEAIkCAgUEBIiIiIiIiIiIiomEA IiIiIiIiYQAiIiJiYQAiIiJhACLiYQAi4mAAImIA4mEAYmEAIiIiIiIiIiIiIiJAACIiIiIi ImEAIiIiImEAIiJiIWAAIIDgIGGhIUDA4WFhwOHhYMDhYcChYcDh4eHh4eHh4eHh4WFhwOHh 4eHh4eFgwOHh4eGhYMDh4eFhwOHhoWDA4WFhwOGhYMDhIUDAoWHA4eHh4eHh4eHh4eFhYf/A 4eHh4eHh4WDA4eHh4SFAwOHh4SFAwOHhIUDA4WFhwOHhYAAggOAgIWFAYeFgQGFhYWFhYWFh YeFgwGCAYABAwGAAQEDhoEFBASCA4CBhoeEhYqLiImNiQGNjY2NAY+NiQGOjYECjYkCjYUDj YECjYEBjQGNjY2Nj42JAY2NjY0Bjo2JAY+NgQGNiQKNhQCNhQCNAQGNAY2NjY2PjYkBjY2Nj QGPjYkBjo2BAo2JAo2FA42BAo2BAY0BjY2NjY+NiQGNjY2NAY6MioABAAMFBwkLDQ4AARETD AETEwQBERIAARMMAxMIARERERERERIAAgIDBAICAwYDDAkRERET/RERERERERIAARERERERE wgBERETEwgBERETCAETEwwBExMEARMQAxMMAxMIARERERERERERERESAAERERERERMIARERE RMIARETEQsAAQADBQcJCQ4CAw8PCgMPDwYDDw4BDw4DDw8PDw8PDw8PDw8PCgMPDw8PDw8PB gMPDw8NDwYDDw8PDgMPDQ8GAw8PCgMNDwYDDQ4CAQ8OAw8PDw8PDw8PDw8PDwoDDw8PDw8PD wYDDw8PDQ4CAw8PDQ4CAw8NDgIDDw8KAw8PBAEAAwUFCwoDCwsGAwsLCwsLCwsLCwkKAAMGA wQCAgMGAQkHAAMFBwkLDQ8RExUXGRsdH/8hIyUnKSstLzEzNTc5Oz0/QUNFR0lLTU9RU1VXW VtdX2E1AAMFBwkLDQ8RExYDBgMEAgIDBAEAAwUHCQsNDxETFRcZGx0fISMlJykrLS8xMzU3O Ts9P0FDRUdJS01PUVNVV1lbXV9jY0wDCgMEAgIDBAFlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZ WdnGAMMAgIDBAIAAWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWUfAAEFBAACAAEAAQcEAQADB QcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/QUNFR0lLTU9RU1VXWVtdX2FjZWdpa21vc XN1d3l7fX+Bg4f9h4mLjY+Rk5WXmZudn6Gjpaepq62vsbO1t7m7vb/Bw8XHycvNz9HT1dfZ2 93d46ID4+OOAwoD4eOCAwgBAAEHBAEAAwUHCQsNDxETFRcZGx0fISMlJykrLy8SAwoDCgMIA TExMTExMTExMTEzHgMKAwoDCgMIATEzIgABMTExMTExMTExMTEzEgADCAIAATExMTExMTExM TEzMgADCAICAwQCAAExMTExMTExMTEzMyYAAwgCAgMEAgIDBAIAATExMTJgwYcKECRMmRoAC AgAAAAACAAIAAAACAAIAAAACAAIAAAACAAIAAQQHCQsNDxETFQ8DAAIAAQQHCQsNDxH/ExUX GRsdHyEjJScpKy0vJwMAAgYDBgMwMTExMTExMTExMS0DAAIGAwYDAAIGAzAxMTExMTExMTEx IwMAAgYDBgMAAgYDAAIGAzAxMTExMTExMTExFQMAAgYDBgMAAgYDAAIGAwACBgMwMR8DMDEx MTExMTExMTExJQIUAAAAEAAAABAACCA4SFhoeIiYqLjI2Oj4CBkpOUlZaXnJGDAYMBgAEDAY gImJiYmJiYmJiYk5GTAYMBgAEDAYABAwGICJiYmJiYmJiYmJyRgwGDAYABAwGAAQMBgAEDAY gIn5GICJiYmJiYmJiYmJiZkYMBgwGICJiYmJiYmJiYmJiRkw/xgwGAAIEAAAABAACCA4SFho eIiYqLjI2Oj4CBkpOUlZaXl5GDAYMBgAEDAYABAwGICJiYmJiYmJiYmJyRgwGDAYABAwGAAQ MBgAEDAYgIn5GICJiYmJiYmJiYmJiZkYMBgwGICJiYmJiYmJiYmJiRkwGDAYABAwGICJiYmJ iYmJiYmJORkwGDAYAAgQAAAAEAAQAAAAEAAIIDhIWGh4iJiouMjY6PgIGSk5SVlpeRkwGDAY ABAwGAAQMBgAEDAYcHkZGXB5eXl5eXl5eXl5eVkZQBgAEHB5eXl5eXl5eXl5edkYQBgAEDAY ABBweXl5eXl5eXl5eXmJGEAYABAwGP8AEDAYABBweXl5eXl5eXl5eXkJEEAYAAgQAAAAEAAQ AAAAEAAQAAAAEAAQAAggOEhYaHiImKh4CBggKAgIIDhIWGh4iJiouMjY6PgIGSk5SVlpeRkJ GCAoCAAAEAAIIDhIWGh4iJiouMjY6PgIGSk5SVlpeckIGCAoCAAAEAAIICgYAAggOEhYaHiI mKi4yNjo+AgZKTlJWWl5eQgYICgIAAAQAAggKBgwKBgACCA4SFhoeIiYqLjI2Oj4CBkpOUlZ aXkJGCAoCAAAEAAIICgYMCgYMCgYAAggOEhYaHiImKi4yNjo+AgZKTlJWWl5iZmpucnZ6fkJ Gio6Slpqeor/mqq6ytrq+gobKztLW2t7i5uru8vb6/sLHCw8TFxsfIycrLzM3Oz8DB0tPU1d bX2Nna29zd3t/Q0eLj5OXm5+jp6uvs7e7v4OHy8/T19vf4+fr7/P3+//DzCgwIEECxo8iDCh woUMGzp8CDGixIkUK1q8iDGjxo0cO3r8CDKkyJEkS5o8iTKlypUsW7p8CTOmzJk0a9q8iTOn zp08e/r8CTSo0KFEixo9ijSp0qVMfQIKEAQAAAgABBAcJBQMKCwsLCwkDCgsLCwkDBAMKAwI CAgYDAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1Nzk7PT8BA0VHSUtNT1FTVVd/2VtdX2F ZQwYDBAMiI0MGAwoDBgMGAyIjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY1dDCgMCAgIEAwACAgY DAgYDAAICBgMCAhIDAgIGAwIGAQMEBQEABgEBBAcHAwgDBAMEAwYDCAMAAQQHCQsNDxETFRc ZGx0fISMlJykrLS8xMzU3OTs9PwEDRUdJS01PUVNVV1lbXV9hV0MCCAMIAwIEAwYDBgMCBAM AAgYDDgMGAwYDDAMEAwYDEAMIAwACBgMCAgIKAyIjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY1t DBgMIAw4DAAEEAwQBAgAAAwQFAQEEBwUDAggBAggBAgYBP8MEBQEBBAcFAwgDAggDBgMIAwA BBAcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/AQNFR0lLTU9RU1VXWVtdX2FdQwQDCAM OAwYDBgMAAhwDCAMIAwgDGAMIAwACBgMGAwgDIiNjY2NjY2NjY2NjY2NjY2NjY2NjY2NjVUM GAwQDBAMAAg4DBgMCBAMAAhYBAwAAAAIAAAACAAAAAgABBAUDBgcHBwECBgMEAwQDBgMGAwA BBAcJCw0PERMVFxkbHR8hIyUnKSstLzEzNTc5Oz0/AQNFR0lLTU9RU1VXWVtdX2FZQwICCAM CBAMMAwICBAMAAgIGAwICEgMCAjnGAwICBAEDBAUBAAYBAQQHCQECBAMGAwACAgICBgMAAQQ HCQsNDxETFRcZGx0fISMlJykrLS8xMzU3OTs9PwEDRUdJS01PUVNVV1lbXV9hSUNiI2NjY2N jY2NjY2NjY2NjY2NjY2NjY2NjY0tDAAEEBwkLDQ8RExUXGRsdHyEjJScpKy0vMTM1Nzk7PT8 BA0VHSUtNT1FTVVdZW11fYWNlZ2lrbW9xc3V3eXt9f0FDhYeJi42PkZOVl5mbnZ+ho6Wnqau tr7Gztbe5u72/gYPFx8nLzc/R09XX2dvd3+Hj5efp6+3rwwEADs= --WlEyl6ow+jlIgNUh-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 11 22:43:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 55B0815014 for ; Sun, 11 Apr 1999 22:43:18 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id XAA02746; Sun, 11 Apr 1999 23:40:56 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904120540.XAA02746@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904102034.WAA03553@yedi.iaf.nl> from Wilko Bulte at "Apr 10, 1999 10:34:41 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Sun, 11 Apr 1999 23:40:56 -0600 (MDT) Cc: freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte wrote... > > > - do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k & > > > - do a 'mount -r -t cd9660 /dev/cd2a /mnt' > > The above sequence of commands will reproduce the lockup. > Doing: > > - do a 'mount -r -t cd9660 /dev/cd2a /mnt' > - do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k & > > will work and will just drive the changer nuts with swapping discs. Well, it shouldn't swap for long. Once the mount finishes, it'll just keep reading off of cd0. > I sort of expected that the mount would lock the cd into the drive, > changer or not. No, it won't. The idea of the LUN-based changer code in the CD driver is to allow you to do I/O to *all* CDs in the changer, but not all at the same time. The changer will switch the CD that corresponds to the LUN that is getting I/O at the time. One problem that some of these changers have is that if you switch too rapidly back and forth between LUNs, they get confused and kinda lock up. By enforcing a minimum amount of time on each LUN, the CD driver not only avoids lockups, but also increases performance somewhat. > > > If you want me to whisper magical words to gdb please tell me > > > which words. > > > > It would be nice if you could give me: > > > > - a stack trace using a kernel with debugging symbols > > #0 boot (howto=256) at ../../kern/kern_shutdown.c:287 > #1 0xc0147ad9 in panic (fmt=0xc02182fc "from debugger") > at ../../kern/kern_shutdown.c:448 > #2 0xc0128b45 in db_panic (addr=-1071661537, have_addr=0, count=-1, > modif=0xc36048ac "") at ../../ddb/db_command.c:432 > #3 0xc0128ae5 in db_command (last_cmdp=0xc024eac4, cmd_table=0xc024e924, > aux_cmd_tablep=0xc0260988) at ../../ddb/db_command.c:332 > #4 0xc0128baa in db_command_loop () at ../../ddb/db_command.c:454 > #5 0xc012af2b in db_trap (type=3, code=0) at ../../ddb/db_trap.c:71 > #6 0xc01fbbfa in kdb_trap (type=3, code=0, regs=0xc360499c) > at ../../i386/i386/db_interface.c:157 > #7 0xc02088f8 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1071714996, > > tf_esi = 134, tf_ebp = -1017099808, tf_isp = -1017099836, tf_ebx = 0, > tf_edx = -1071355968, tf_ecx = -1072984320, tf_eax = 38, tf_trapno = > 3, > tf_err = 0, tf_eip = -1071661537, tf_cs = 8, tf_eflags = 582, > tf_esp = -1071355984, tf_ss = -1071367167}) at > ../../i386/i386/trap.c:549 > #8 0xc01fbe1f in Debugger (msg=0xc0243c01 "manual escape to debugger") > at ../../i386/i386/db_interface.c:317 > #9 0xc01f74bc in scgetc (kbd=0xc0271ee4, flags=2) > at ../../dev/syscons/syscons.c:3714 > #10 0xc01f223c in sckbdevent (thiskbd=0xc0271ee4, event=0, arg=0x0) > at ../../dev/syscons/syscons.c:816 > #11 0xc01eec17 in atkbd_intr (kbd=0xc0271ee4, arg=0x0) > at ../../dev/kbd/atkbd.c:561 > #12 0xc020a4f0 in atkbd_isa_intr (unit=0) at ../../i386/isa/atkbd_isa.c:84 > #13 0xc0125b17 in cdrunchangerqueue (arg=0xc0780c00) > at ../../cam/scsi/scsi_cd.c:1225 Looks like you're missing a stack frame here, but from your earlier stack trace and from the code I know that the only way to get to cdrunchangerqueue() from cdprevent() is via cdgetccb(). > #14 0xc012720c in cdprevent (periph=0xc0780c00, action=1) > at ../../cam/scsi/scsi_cd.c:2517 > #15 0xc01256a7 in cdopen (dev=1568, flags=1, fmt=24576, p=0xc336b5a0) > at ../../cam/scsi/scsi_cd.c:915 > #16 0xc0175e07 in spec_open (ap=0xc3604e2c) > at ../../miscfs/specfs/spec_vnops.c:235 > #17 0xc0175bf1 in spec_vnoperate (ap=0xc3604e2c) > at ../../miscfs/specfs/spec_vnops.c:129 > #18 0xc01df5b9 in ufs_vnoperatespec (ap=0xc3604e2c) > at ../../ufs/ufs/ufs_vnops.c:2327 > #19 0xc017030e in vn_open (ndp=0xc3604f00, fmode=1, cmode=3300) > at vnode_if.h:163 > #20 0xc016cd69 in open (p=0xc336b5a0, uap=0xc3604f94) > at ../../kern/vfs_syscalls.c:972 > #21 0xc0209133 in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 0, > tf_esi = -1077944881, tf_ebp = -1077945340, tf_isp = -1017098268, > tf_ebx = -1077945100, tf_edx = -1077944891, tf_ecx = 3, tf_eax = 5, > tf_trapno = 12, tf_err = 2, tf_eip = 134517904, tf_cs = 31, > tf_eflags = 662, tf_esp = -1077946172, tf_ss = 47}) > at ../../i386/i386/trap.c:1101 > #22 0xc01fc54c in Xint0x80_syscall () > #23 0x8048361 in ?? () > #24 0x80480e9 in ?? () > > > - a listing of the location in cdrunchangerqueue() where you broke into > > the debugger. (just type 'list' in gdb while you're at the stack frame > > that's in cdrunchangerqueue()) > > Like this? > > (kgdb) frame 13 > #13 0xc0125b17 in cdrunchangerqueue (arg=0xc0780c00) > at ../../cam/scsi/scsi_cd.c:1225 > 1225 } > (kgdb) list > 1220 * switch time. > 1221 */ > 1222 changer->flags |= CHANGER_NEED_TIMEOUT; > 1223 > 1224 splx(s); > 1225 } > 1226 > 1227 static void > 1228 cdchangerschedule(struct cd_softc *softc) > 1229 { > (kgdb) Okay, good. Looks like you probably broke into the debugger while it was going out of the scheduling function. Now, can you print out some values for me: print /x softc->flags print /x changer->flags print /x softc->pinfo.index There's a loop in cdgetccb(), and the process should get put into tsleep() inside that loop at some point. My guess is that that is not happening for some reason. The loop control elements are in the above variables, so maybe that'll tell me something. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 11 23:57:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from en26.l1.net (froggy.anchorage.ptialaska.net [208.151.119.238]) by hub.freebsd.org (Postfix) with ESMTP id 3E1FF15458; Sun, 11 Apr 1999 23:57:41 -0700 (PDT) (envelope-from groggy@iname.com) Received: from en26.l1.net (localhost [127.0.0.1]) by en26.l1.net (8.8.8/8.8.8) with SMTP id XAA01930; Fri, 9 Apr 1999 23:20:48 -0800 (AKDT) (envelope-from groggy@iname.com) Date: Fri, 9 Apr 1999 23:20:48 -0800 (AKDT) From: Steve Howe X-Sender: abc@en26.l1.net Reply-To: Steve Howe To: Darryl Okahata Cc: freebsd-scsi@FreeBSD.ORG, freebsd-questions Subject: Re: board not responding In-Reply-To: <199904110500.WAA06462@mina.sr.hp.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 > > ahc0 rev 1 int a irq 10 on pci:0:10:0 > > ahc0: aic7800 Wide Channel, SCSI Id=7, 16 SCBs > > ahc0 waiting for scsi devices to settle > > (ahc0:0:0): "IBM DDRS-34560D DC1B" type 0 fixed SCSI 2 > > sd0(ahc0:0:0): Direct-Access 4357MB (8925000 512 byte sectors) > > ahc0: board is not responding > > (term) (auto) (term) > > IBM DDRS-34560 HD <-> 2940UW <-> Toshiba 6401B CD <-> HP 4020 CD/RW > > 68 pin 50 pin 50 pin sorry, i had the CD wrong ... i hear what you are saying, but don't know what it means. usually when i hear "single-ended", i think "as opposed to differential". the IBM spec sheets for the drive state: "Enable SCSI terminator SE 50/68 pin" which makes sense, since only the 2944 and 80 pin (AFAIK) adapters are differential units - which i think means that they have two-way communication paths to cut down on interference from electrical "echoes". but anyway - further testing shows the problem to be the Toshiba CDROM (40x). the IBM HD works fine alone, and works fine with the HP CD/RW. the boot floppy boots up. but when i add the Toshiba, with either the IBM or the HP in addition, the SCSI bus dies as shown above. i also notice that the Toshiba causes the Adaptec Bios (2.20) to take forever (3-4 minutes) to finish - when there is no CD in the CDROM. not so with the HP when it is empty. ------------------------------------ and as i write this - whala! i found the problem!!! but i'll send this off in case it helps anyone else; i didn't have too much luck scanning the handbook, faq, maillists, web ... and there are alot of good keywords in here ... it appears that the problem was the Adaptec BIOS speed settings for the CDROM. i had Sync-Negotiation DISABLED for the CDROMs, which gave them a speed of "20.0". when i lower it to 16.7, everything starts working fine! yippie! > The "IBM DDRS-34560D" is an LVD drive (I've got this exact drive, > with the same firmware rev). For this IBM LVD drive, what appears to be > the "term" jumper is really the jumper that controls LVD vs SE HVD > (single-ended HVD), and "enabling termination" really puts the drive > into single-ended mode. You also need an external terminator with this > drive (with all LVD drives, actually); there is no built-in termination > to enable or disable. it only forces SE mode on 80 pin connections - 50/68 is always SE ... with the exception of the 2944 ... STD disclaimer: "i believe" ... > As your diagram doesn't show an explicit external terminator with > the drive, that might be your problem: no termination. > > [ In my case, I ordered a "wide SCSI" drive, expecting an SE HVD drive. > I received an LVD drive, instead. While this is certainly a "wide > SCSI" drive, it was unexpected, as I had to scramble to find some > ribbon cable termination. I'm not really complaining, mind you; I'd > rather have an LVD drive than a plain SE HVD one, as it'll be much > easier for me to upgrade to an LVD controller, should I decide to do > so. ] thanks ;) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 12 6:49:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id A5E5515138 for ; Mon, 12 Apr 1999 06:49:06 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id JAA16042; Mon, 12 Apr 1999 09:46:48 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id JAA43550; Mon, 12 Apr 1999 09:46:05 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 12 Apr 1999 09:46:04 -0400 (EDT) To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: odd performance 'bug' & other questions In-Reply-To: <199904120049.SAA01682@panzer.plutotech.com> References: <14097.8430.806061.277769@grasshopper.cs.duke.edu> <199904120049.SAA01682@panzer.plutotech.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14097.62839.525472.52389@grasshopper.cs.duke.edu> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kenneth D. Merry writes: > > There are a couple of things going on here that may affect the performance > numbers you're seeing: > > - There was a performance problem in getnewbuf() that was supposedly fixed > on April 6th. I haven't tested -current since then, so I don't know for > sure whether the problem is really fixed. I know about this, so I am using dd rather than Bonnie / iozone in order to factor this out. It sure would be nice if Matt's fix surfaced though ;-) > - The Medalist Pro drives are known to be rather crappy. That's why we've > got the number of tags set to 2 in the quirk entry for those drives. Crap, crap, crap. We just bought 84 of these; I wish I could have talked my boss into the barracudas.. > > Using camcontrol to look at the defects list on some of these drives, > > I see that its HUGE. I've seen one disk with over 1100 entries in the > > primary defects list. Should I be alarmed at the size of the defects > > list? Should I complain to my vendor, or is this typical? > > Well, it varies. I've got four disks on a heavily used server: > > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 1 lun 0 (pass1,da1) > at scbus0 target 3 lun 0 (pass2,da2) > at scbus1 target 0 lun 0 (pass3,da3) > > Here are the defect numbers, in order: > > Got 464 defects: > Got 144 defects: > Got 1145 defects: > Got 579 defects: > > I've also got the following disk on my home machine: > > at scbus1 target 1 lun 0 (pass1,da1) > > And it has 660 defects in the permanant list, none in the grown defect > list. It is a 9G drive, and still gives pretty good performance. > (14-16MB/sec) So your numbers are a bit high for a 9G drive, but I'm not > sure whether that would be considered excessive. Of course the drives I've > got above are higher-end Seagate and IBM disks, not low-end models. And > you'd expect the number of defects to be somewhat proportional to the > capacity of the drive. Your numbers are closer to the 18G IBM disk above. OK.. so they're a bit bad, but not necessarily unusual. I haven't paid much attention to defect lists since a 1GB disk was considered large, so I guess I was just a bit surprised to see the size. Thanks for the feedback. <..> > > Also, the ncr controller fails to give me a defects list, I assume > > this is a bug in the driver? (I'm running -current, dated this Thurs). > > camcontrol complains: error reading defect list: Input/output error, > > and I see this on console: > > > > (pass3:ncr0:0:0:0): extraneous data discarded. > > (pass3:ncr0:0:0:0): COMMAND FAILED (9 0) @0xc39a3600. > > It could be a driver bug, not sure. What arguments were you using with > camcontrol? camcontrol defects -n da -u 3 -f phys -P When the unit is one of the drives attached to the on-board adaptec controller, it works as expected. However, if the unit is a drive attached to the ncr crontoller, the command fails as mentioned above. The drives are identical, so that's why I'm assuming there's an ncr bug. Cheers, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 12 7:56:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id D196814CF0 for ; Mon, 12 Apr 1999 07:55:35 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id KAA17621; Mon, 12 Apr 1999 10:53:15 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id KAA43666; Mon, 12 Apr 1999 10:52:33 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 12 Apr 1999 10:52:32 -0400 (EDT) To: Greg Lehey Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: odd performance 'bug' & other questions In-Reply-To: <19990412112149.F2142@lemis.com> References: <14097.8430.806061.277769@grasshopper.cs.duke.edu> <19990412112149.F2142@lemis.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14098.675.979991.329696@grasshopper.cs.duke.edu> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg Lehey writes: > On Sunday, 11 April 1999 at 19:14:25 -0400, Andrew Gallatin wrote: > > > > We're setting up a few large servers, each with 6 9GB seagate medalist > > pro drives spread across 2 scsi controllers (aic7890 & ncr53c875). > > > > We've noticed that if we set up the disks using a simple ccd stripe, > > after trying various interleaves, the best read bandwidth we can get > > is only ~35-40MB/sec (using dd if=/dev/rccd0 of=/dev/null bs=64k), > > which is odd because we'd thought we should be getting at least > > 55-60MB/sec, as we get about 13.5MB/sec from each drive with the same > > test. > > This kind of test is not very useful, and may be counterproductive. > What size stripe did you use? 64kb. 80kb shows the same results. > I'm attaching a plot of Vinum performance against stripe size with a > volume spanning four very slow disks. I briefly tested ccd and got > very similar results. These were done with 'rawio' against the > character device with 8 concurrent processes. You'll note that > sequential I/O performance peaks at about 80 kB stripes, whereas > random transfers (which are presumably closer to what you're doing) I'm (at least trying) to do sequential. I'm just concered that the number of defects might mean these drives really don't do sequential.. > improve with increasing stripe size. You'll also notice that the > performance ratio is approximately the same as you describe, rather > less than 3x the single disk, but this is misleading, since I only had > four drives in this test. > > You'll also notice that the performance figures are terrible; that's > because they were done on some ancient drives (look at the throughput > of the raw drives without Vinum). > > > Upon closer examination, we discovered that on some of the drives the > > performance wanders all over the place -- if you do a dd if=/dev/rX > > of=/dev/null bs=64k on an individual disk on an otherwise idle system > > & watch with iostat or systat, you can see the bandwidth jump around > > quite a bit. I'm thinking that my performance problems might be due > > to the fact that the reads aren't really sequential, rather the disk > > arm is moving all over the place to read remapped defective blocks. > > Have you considered rotational latency? Unless you spindle-sync the > drives, you can end up with random delays in moving from one drive to > the next. If you spindle-sync them, you may or may not incur a > whole-rotation delay :-) I've done some tests here, and they show the > same effects for single processes. This sounds interesting... how do I spindle-sync the drives? Also, how does vinum deal with stripes across multiple controllers? Eg. I have da0:ahc0:0:0:0 da1:ahc0:0:1:0 da2:ahc0:0:2:0 da0:ncr0:0:0:0 da1:ncr0:0:1:0 da2:ncr0:0:2:0 Using ccd, if I stripe them so that each component is atached to alternating controllers (which i think is the right way to do it): ccd0 64 none /dev/da0c /dev/da3c /dev/da1c /dev/da4c /dev/da2c /dev/da5c I see about 40MB/sec total from dd if=/dev/rccd0c of=/dev/null bs=64k, or about 6.5MB/sec per drive. If I stripe them like this: ccd0 64 none /dev/da0c /dev/da1c /dev/da2c /dev/da2c /dev/da4c /dev/da5c I see about 29MB/sec, or about 4.8MB/sec from each drive. If I use vinum, no matter how I organize the sripe section, I always get about 27MB/sec. Cheers, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 12 9: 6:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id DBA331546D for ; Mon, 12 Apr 1999 09:06:23 -0700 (PDT) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) for freebsd-scsi@freebsd.org id 10WjBt-0000pC-00; Mon, 12 Apr 1999 09:04:05 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id JAA14387; Mon, 12 Apr 1999 09:04:01 -0700 Date: Mon, 12 Apr 1999 09:04:01 -0700 (PDT) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Seagate ST15230 wedging To: freebsd-scsi@freebsd.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 Do any of you have any experience with Seagate ST15230 drives? I have one that occasionally wedges when backing up to tape. The wedge spews: sd1(ncr1:1:0): Vendor Specific asc:80,0 Vendor Specific ASC field replaceable unit: 1 I've no idea what that message means, except that I can't access the disk and have to power-cycle to reset it. (Well, actually, it might reset with a simple reboot. But I figure I may as well power-cycle just to be sure.) It's on a system that, for various reasons, is still running FreeBSD 2.2.2, and will be for a little while yet unless I find some urgent reason to upgrade. (Such as someone assuring me that later drivers for the NCR 53c585 fix it.) Thanks, -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 12 9: 7:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DE201546D for ; Mon, 12 Apr 1999 09:07:39 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id KAA05320; Mon, 12 Apr 1999 10:05:10 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904121605.KAA05320@panzer.plutotech.com> Subject: Re: odd performance 'bug' & other questions In-Reply-To: <14097.62839.525472.52389@grasshopper.cs.duke.edu> from Andrew Gallatin at "Apr 12, 1999 9:46: 4 am" To: gallatin@cs.duke.edu (Andrew Gallatin) Date: Mon, 12 Apr 1999 10:05:10 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrew Gallatin wrote... > > Kenneth D. Merry writes: > > > > There are a couple of things going on here that may affect the performance > > numbers you're seeing: > > > > - There was a performance problem in getnewbuf() that was supposedly fixed > > on April 6th. I haven't tested -current since then, so I don't know for > > sure whether the problem is really fixed. > > I know about this, so I am using dd rather than Bonnie / iozone in > order to factor this out. It sure would be nice if Matt's fix > surfaced though ;-) Well, Alan Cox checked in a performance fix for getnewbuf() on April 6th, but like I said, I don't know if the problem has really been fixed since I haven't tested -current since then. > > - The Medalist Pro drives are known to be rather crappy. That's why we've > > got the number of tags set to 2 in the quirk entry for those drives. > > Crap, crap, crap. We just bought 84 of these; I wish I could have > talked my boss into the barracudas.. Yeah, buying crappy disks will often give you headaches. :) I don't think they're too bad for sequential throughput -- 13.5MB/sec isn't bad. But the whole reason you're getting that much performance is because we cranked the number of tags down to 2. It might be worthwhile in the future to buy one or two of the disks you're planning to get a lot of, and then do extensive benchmarks on them. Or at least look in the quirk table or ask around about 'em. :) [ ... ] > > And it has 660 defects in the permanant list, none in the grown defect > > list. It is a 9G drive, and still gives pretty good performance. > > (14-16MB/sec) So your numbers are a bit high for a 9G drive, but I'm not > > sure whether that would be considered excessive. Of course the drives I've > > got above are higher-end Seagate and IBM disks, not low-end models. And > > you'd expect the number of defects to be somewhat proportional to the > > capacity of the drive. Your numbers are closer to the 18G IBM disk above. > > OK.. so they're a bit bad, but not necessarily unusual. I haven't paid much > attention to defect lists since a 1GB disk was considered large, so I guess I was > just a bit surprised to see the size. Yeah, I don't think your trouble is the defect list. You'd be seeing bad performance from single disks if that were the case. I suspect a VM-type problem, although I'm not certain about that. It would be interesting to see if you get the same performance problems under -stable. (FWIW, the CAM code is the same in -stable and -current.) > > > Also, the ncr controller fails to give me a defects list, I assume > > > this is a bug in the driver? (I'm running -current, dated this Thurs). > > > camcontrol complains: error reading defect list: Input/output error, > > > and I see this on console: > > > > > > (pass3:ncr0:0:0:0): extraneous data discarded. > > > (pass3:ncr0:0:0:0): COMMAND FAILED (9 0) @0xc39a3600. > > > > It could be a driver bug, not sure. What arguments were you using with > > camcontrol? > > camcontrol defects -n da -u 3 -f phys -P > > When the unit is one of the drives attached to the on-board adaptec > controller, it works as expected. However, if the unit is a drive > attached to the ncr crontoller, the command fails as mentioned above. > The drives are identical, so that's why I'm assuming there's an ncr bug. Okay, sounds like that may be the case. If I get some time I'll stick an NCR board in my test box and see whether I can read a defect list. Ken -- Kenneth Merry ken@plutotech.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 12 9:13:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from melete.ch.intel.com (melete.ch.intel.com [143.182.246.25]) by hub.freebsd.org (Postfix) with ESMTP id 850761556E; Mon, 12 Apr 1999 09:13:06 -0700 (PDT) (envelope-from jreynold@sedona.ch.intel.com) Received: from sedona.intel.com (sedona.ch.intel.com [143.182.218.21]) by melete.ch.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id JAA04312; Mon, 12 Apr 1999 09:10:47 -0700 (MST) Received: from hip186.ch.intel.com (hip186.ch.intel.com [143.182.225.68]) by sedona.intel.com (8.9.1a/8.9.1/d: sendmail.cf,v 1.7 1999/02/08 16:00:31 steved Exp steved $) with ESMTP id JAA13195; Mon, 12 Apr 1999 09:10:45 -0700 (MST) Received: (from jreynold@localhost) by hip186.ch.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) id MAA27439; Mon, 12 Apr 1999 12:10:45 -0400 (EDT) From: John Reynolds~ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14098.6916.85454.943476@hip186.ch.intel.com> Date: Mon, 12 Apr 1999 09:10:44 -0700 (MST) To: freebsd-scsi@freebsd.org Subject: 3.1-RELEASE -- CD-ROM found! (was Re: 3.1 Install trouble -- can't see SCSI CD-ROM) X-Mailer: VM 6.70 under Emacs 19.34.1 Cc: freebsd-install@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ copying to -install because I feel this is still an "install issue" ] > [ a bunch of people responded ... here are two snippets:] > > > That's just what I did: Insert kern.flp and CD-ROM #1, boot, > > insert mfsroot.flp when requested. Kernel will find the CD- > > ROM drive. Sysinstall doesn't recognize it, unless it's an > > IDE CD-ROM drive. > > I can also confirm a system install of 3.1R from a SCSI cdrom drive. > An asus p2l97-ds, with an older (3-4 years) plextor scsi cdrom drive. Ok, I think I've narrowed down what was going on. Thanks to several people that showed me the Scroll-Lock + PgUp/PgDn trick, I was able to see the rest of the boot messages. The last boot message related to my first CD-ROM was: cd0: Attempt to query device size failed: NOT READY, (there was nothing after the comma) Scratching my head, I rebooted again but this time as soon as it started to boot I inserted the Disk #1 from my FreeBSD 3.1 CD-ROM pack ... it got down to the scsi probe, and viola: cd0: cd present [322265 x 2048 byte records] I then went back into sysinstall, got to the "media" screen, hit CD-ROM and BOOM! Worked! So, now the question exists: "When did this behavior during boot change, is this a bug or feature?" I've installed FreeBSD 2.x.x on my machine from since the days of 2.0.5. I don't remember ever having seen this problem. Granted it was on another machine, but still. Other philosophical things: o If this is a bug, where does it lie? sysinstall? The boot code? o I can accept the fact that one must have a disc in the drive to get things to work (hey, I've done wierder things to install NT!!!--including a Mexican hat dance around the computer.... :) ... if this is "required" then shouldn't the next logical thing be to put this in the error message of sysinstall? i.e. if it doesn't detect a CD-ROM it might suggest that you: a) examine your termination b) use Scroll-Lock + PgUp/PgDn to few the scsi probe messages c) put the disc #1 into the drive during boot Thanks for all that responded. Looks like the Scroll-Lock thing was all I needed to figure out the "duh" problem going on here. The bottom line is if 3.1 sysinstall doesn't find your CD-ROM, try putting a disc in it before the end of the boot sequence. I still wonder whether this is a bug or feature? :-) -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds CEG, CCE, Next Generation Flows, HLA | | Intel Corporation MS: CH6-210 Phone: 554-9092 pgr: 868-6512 | | jreynold@sedona.ch.intel.com http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 12 9:42:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 31AC114D33 for ; Mon, 12 Apr 1999 09:42:17 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id JAA23843; Mon, 12 Apr 1999 09:39:19 -0700 Date: Mon, 12 Apr 1999 09:39:19 -0700 (PWT) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Andrew Gallatin , Doug Rabson Cc: freebsd-scsi@freebsd.org Subject: umm- ISP adapter feedback... 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 One of you, I forgot whom, had the new XP1000 to play with- it had a new rev 'C' ISP1040 in it- I updated the driver to treat it like a ISP1040B and I'd like to know if it's been working okay. Secondly- I upped the queue limits again to 256- that used to give Doug's system agita. Let me know if it breaks again. The limit's going higher later- the 1080/1240 can take up to 1024 entries (I've done the 1080 support and the 1240 support is almost done and is in partial test at a place in England). I've also committed to using the FAST POST feature (commands that complete okay don't get a response updated in the response queue- instead the command handle is posted to mailbox registers and an async event interrupt is posted). Basically, if you see some breakage, let me know sooner rather than later. That goes for all on this list that use these adapters- I *know* that NCR is popular 'coz of price, but the driver sure seems iffy. I've been doing some work on a Solaris NCR driver (to add Ultra2 support) and while that driver is stunningly better than any other of the NCR drivers I've seen, it's *still* a mess. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 12 9:53: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 6FD0314EF4 for ; Mon, 12 Apr 1999 09:53:05 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.1/8.9.1) with ESMTP id MAA20765; Mon, 12 Apr 1999 12:50:42 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id MAA44152; Mon, 12 Apr 1999 12:49:59 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 12 Apr 1999 12:49:58 -0400 (EDT) To: mjacob@feral.com Cc: Doug Rabson , freebsd-scsi@freebsd.org Subject: Re: umm- ISP adapter feedback... In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14098.8921.665186.7704@grasshopper.cs.duke.edu> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob writes: > > > One of you, I forgot whom, had the new XP1000 to play with- it had a new > rev 'C' ISP1040 in it- I updated the driver to treat it like a ISP1040B > and I'd like to know if it's been working okay. That would be me. If you mean rev 1.17 of isp.c, its been working so well that I hadn't noticed that you'd changed anything ;-) > Secondly- I upped the queue limits again to 256- that used to give Doug's > system agita. Let me know if it breaks again. The limit's going higher > later- the 1080/1240 can take up to 1024 entries (I've done the 1080 > support and the 1240 support is almost done and is in partial test at a > place in England). I've also committed to using the FAST POST feature > (commands that complete okay don't get a response updated in the response > queue- instead the command handle is posted to mailbox registers and an > async event interrupt is posted). I'm not sure what rev you did this with, but on a Miata (DPW500au) with: Qlogic ISP Driver, FreeBSD CAM Version 0.99, Core Version 1.7 isp0: rev 0x05 int a irq 3 on pci1.4.0 isp0: using I/O space register mapping isp0: Ultra Mode Capable isp0: Board Revision 1040B, loaded F/W Revision 7.55 isp0: Last F/W revision was 5.54 isp0: invalid NVRAM header I saw pages of these errors on console: isp0: not RESPONSE in RESPONSE Queue (type 0x1) @ idx 34 (next 35) isp0: rqs_flags=2isp0: internal queues full isp0: unknown return 1 isp0: not RESPONSE in RESPONSE Queue (type 0x1) @ idx 35 (next 36) isp0: rqs_flags=2isp0: internal queues full isp0: unknown return 1 isp0: not RESPONSE in RESPONSE Queue (type 0x1) @ idx 36 (next 37) isp0: rqs_flags=2isp0: internal queues full isp0: unknown return 1 I've just built a fresh kernel & put it on that machine & rebooted to see if anything changed, but it hasn't been up terribly long... Cheers, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 12 10: 4: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id EC85115236 for ; Mon, 12 Apr 1999 10:04:03 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id KAA23953; Mon, 12 Apr 1999 10:00:47 -0700 Date: Mon, 12 Apr 1999 10:00:47 -0700 (PWT) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Andrew Gallatin Cc: Doug Rabson , freebsd-scsi@freebsd.org Subject: Re: umm- ISP adapter feedback... In-Reply-To: <14098.8921.665186.7704@grasshopper.cs.duke.edu> 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 > > Matthew Jacob writes: > > > > > > One of you, I forgot whom, had the new XP1000 to play with- it had a new > > rev 'C' ISP1040 in it- I updated the driver to treat it like a ISP1040B > > and I'd like to know if it's been working okay. > > That would be me. If you mean rev 1.17 of isp.c, its been working so > well that I hadn't noticed that you'd changed anything ;-) Well that's a good sign! > > > Secondly- I upped the queue limits again to 256- that used to give Doug's > > system agita. Let me know if it breaks again. The limit's going higher > > later- the 1080/1240 can take up to 1024 entries (I've done the 1080 > > support and the 1240 support is almost done and is in partial test at a > > place in England). I've also committed to using the FAST POST feature > > (commands that complete okay don't get a response updated in the response > > queue- instead the command handle is posted to mailbox registers and an > > async event interrupt is posted). > > I'm not sure what rev you did this with, but on a Miata (DPW500au) > with: > > Qlogic ISP Driver, FreeBSD CAM Version 0.99, Core Version 1.7 > isp0: rev 0x05 int a irq 3 on pci1.4.0 > isp0: using I/O space register mapping > isp0: Ultra Mode Capable > isp0: Board Revision 1040B, loaded F/W Revision 7.55 > isp0: Last F/W revision was 5.54 > isp0: invalid NVRAM header > > I saw pages of these errors on console: > isp0: not RESPONSE in RESPONSE Queue (type 0x1) @ idx 34 (next 35) > isp0: rqs_flags=2isp0: internal queues full > isp0: unknown return 1 > isp0: not RESPONSE in RESPONSE Queue (type 0x1) @ idx 35 (next 36) > isp0: rqs_flags=2isp0: internal queues full > isp0: unknown return 1 > isp0: not RESPONSE in RESPONSE Queue (type 0x1) @ idx 36 (next 37) > isp0: rqs_flags=2isp0: internal queues full > isp0: unknown return 1 Ah! Ah! Ah! Ah! I *just* fixed this with the work I was doing on Geoff's system (the ISP 1240). I'll clean up and commit at least some of the changes today! This was a request getting punted right back out from the request queue to the response queue by the chip w/o even trying to run the command- I have to synthesize a QUEUE FULL condition. This only is happening in the case of cards with unreadable NVRAM where I then set the default queue limit to 128 (and then now run over that). (I can only do so much testing on my own! Thank you!) > > I've just built a fresh kernel & put it on that machine & rebooted to > see if anything changed, but it hasn't been up terribly long... > A quick fix for this is to change the line around 3789 from sdp->isp_max_queue_depth = 128; to sdp->isp_max_queue_depth = MAXISPREQUEST; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 12 10:34:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by hub.freebsd.org (Postfix) with ESMTP id 41F0B1552C; Mon, 12 Apr 1999 10:34:50 -0700 (PDT) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by atlrel2.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id NAA02492; Mon, 12 Apr 1999 13:32:10 -0400 (EDT) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA141948346; Mon, 12 Apr 1999 10:32:26 -0700 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id KAA09157; Mon, 12 Apr 1999 10:32:25 -0700 (PDT) Message-Id: <199904121732.KAA09157@mina.sr.hp.com> To: Steve Howe Cc: freebsd-scsi@FreeBSD.ORG, freebsd-questions Subject: Re: board not responding Reply-To: Darryl Okahata In-Reply-To: Your message of "Fri, 09 Apr 1999 23:20:48 -0800." Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Mon, 12 Apr 1999 10:32:25 -0700 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Steve Howe wrote: > > > ahc0 rev 1 int a irq 10 on pci:0:10:0 > > > ahc0: aic7800 Wide Channel, SCSI Id=7, 16 SCBs > > > ahc0 waiting for scsi devices to settle > > > (ahc0:0:0): "IBM DDRS-34560D DC1B" type 0 fixed SCSI 2 > > > sd0(ahc0:0:0): Direct-Access 4357MB (8925000 512 byte sectors) > > > ahc0: board is not responding > > > > (term) (auto) (term) > > > IBM DDRS-34560 HD <-> 2940UW <-> Toshiba 6401B CD <-> HP 4020 CD/RW > > > 68 pin 50 pin 50 pin > > i hear what you are saying, but don't know what it means. > usually when i hear "single-ended", i think "as opposed to differential". > > the IBM spec sheets for the drive state: > "Enable SCSI terminator SE 50/68 pin" Sorry, I was a bit unclear in my last posting. Here's what I'm trying to say: * The IBM Ultrastar 9ES (which is what you and I have) comes in both single-ended and LVD (Low-Voltage Differential) versions. [ Yes, the IBM drives do come in 68-pin LVD versions. ] * LVD drives can often be used with single-ended controllers. * The "IBM DDRS-34560D DC1B" is an LVD drive. On the drive, look for "LVD" on the little white label. * LVD drives DO NOT HAVE PROVISION FOR ON-DRIVE TERMINATION. LVD drives cannot be used to terminate the SCSI bus. You need an external terminator. * In the case of the IBM DDRS-34560D, the jumper that controls "termination" does not control termination (LVD drives don't have any provision for on-drive termination). Instead, this jumper controls whether or not the drive runs in LVD or plain old single-ended mode. * IBM really does make LVD drives in a 68-pin configuration. See the first page of this PDF file: http://www.storage.ibm.com/techsup/hddtech/ddrs/ddrs.pdf Note the line that says, "SCSI-3 FAST-40 (68 & 80-pin (L)ow (V)oltage (D)ifferential)". * If you still don't believe you have an LVD drive, check out these DejaNews postings: http://www.dejanews.com/[ST_rn=ps]/getdoc.xp?AN=441444978 http://www.dejanews.com/[ST_rn=ps]/getdoc.xp?AN=436967059 http://www.dejanews.com/[ST_rn=ps]/getdoc.xp?AN=436728277 * For more info, Adaptec's web site has some good info on LVD: http://www.adaptec.com/products/solutions/ultra2.html > but when i add the Toshiba, with either the IBM or the HP > in addition, the SCSI bus dies as shown above. ... which is consistent with termination problems (among other possible things). -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 12 11:11:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from shadows.aeon.net (shadows.aeon.net [195.197.32.30]) by hub.freebsd.org (Postfix) with ESMTP id 099151556B for ; Mon, 12 Apr 1999 11:11:11 -0700 (PDT) (envelope-from bsdscsi@shadows.aeon.net) Received: (from bsdscsi@localhost) by shadows.aeon.net (8.9.1/8.8.3) id VAA23104 for freebsd-scsi@freebsd.org; Mon, 12 Apr 1999 21:10:41 +0300 (EEST) From: mika ruohotie Message-Id: <199904121810.VAA23104@shadows.aeon.net> Subject: Re: Boot-time scsi probe problem In-Reply-To: <199903241708.TAA11456@shadows.aeon.net> from mika ruohotie at "Mar 24, 1999 7: 8:50 pm" To: freebsd-scsi@freebsd.org Date: Mon, 12 Apr 1999 21:10:41 +0300 (EEST) Action: hc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > i think it worked. > > i mean, i have a collection of 9 machines running march 14th current > and those gave me problems... (cloned from one disk into each 8 others) whoops. anyone still remember this one? ahc0: rev 0x00 int a irq 14 on pci0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs hangs in the boot time occasionally. i pathed my machine with the committed path and reported the above. now, i today learned some of those 9 machines still hang every now and then. one apparently "too often". now, justin or anyone else, is there any new information about this issue? the board was Asus P2B-DS. :\ last i heard justin said there's a chip-bug. did adaptec ever comment it? the issue is pretty serious to me since there was a pressure on me to linuxise those machines, which i wont do... mickey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 12 11:52: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 9A02714EA2 for ; Mon, 12 Apr 1999 11:51:55 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA21349; Mon, 12 Apr 1999 20:31:01 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id TAA00622; Mon, 12 Apr 1999 19:37:56 +0200 (CEST) From: Wilko Bulte Message-Id: <199904121737.TAA00622@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904120540.XAA02746@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 11, 1999 11:40:56 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Mon, 12 Apr 1999 19:37:56 +0200 (CEST) Cc: freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > Wilko Bulte wrote... > > > > - do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k & > > > > - do a 'mount -r -t cd9660 /dev/cd2a /mnt' > > > > The above sequence of commands will reproduce the lockup. > > Doing: > > > > - do a 'mount -r -t cd9660 /dev/cd2a /mnt' > > - do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k & > > > > will work and will just drive the changer nuts with swapping discs. > > Well, it shouldn't swap for long. Once the mount finishes, it'll just keep > reading off of cd0. OK, I have not really tried a whole lot of this. > > I sort of expected that the mount would lock the cd into the drive, > > changer or not. > > No, it won't. The idea of the LUN-based changer code in the CD driver is > to allow you to do I/O to *all* CDs in the changer, but not all at the same > time. > > The changer will switch the CD that corresponds to the LUN that is getting > I/O at the time. One problem that some of these changers have is that if > you switch too rapidly back and forth between LUNs, they get confused and > kinda lock up. By enforcing a minimum amount of time on each LUN, the CD > driver not only avoids lockups, but also increases performance somewhat. Ah! This clarifies this neatly. Thanks. > > > It would be nice if you could give me: > > > > > > - a stack trace using a kernel with debugging symbols [snip] > Looks like you're missing a stack frame here, but from your earlier stack > trace and from the code I know that the only way to get to > cdrunchangerqueue() from cdprevent() is via cdgetccb(). This is all what gdb gives me. > > Like this? > > > > (kgdb) frame 13 > > #13 0xc0125b17 in cdrunchangerqueue (arg=0xc0780c00) > > at ../../cam/scsi/scsi_cd.c:1225 > > 1225 } > > (kgdb) list > > 1220 * switch time. > > 1221 */ > > 1222 changer->flags |= CHANGER_NEED_TIMEOUT; > > 1223 > > 1224 splx(s); > > 1225 } > > 1226 > > 1227 static void > > 1228 cdchangerschedule(struct cd_softc *softc) > > 1229 { > > (kgdb) > > Okay, good. Looks like you probably broke into the debugger while it was > going out of the scheduling function. Now, can you print out some values > for me: > > print /x softc->flags > print /x changer->flags > print /x softc->pinfo.index Gives: (kgdb) frame 13 #13 0xc0125b17 in cdrunchangerqueue (arg=0xc0780c00) at ../../cam/scsi/scsi_cd.c:1225 1225 } (kgdb) print /x softc->flags Cannot access memory at address 0x80000010. (kgdb) print /x changer->flags $1 = 0x0 (kgdb) print /x softc->pinfo.index Cannot access memory at address 0x80000008. (kgdb) > There's a loop in cdgetccb(), and the process should get put into tsleep() > inside that loop at some point. My guess is that that is not happening for > some reason. The loop control elements are in the above variables, so > maybe that'll tell me something. I'm not sure, the 'cannot access memory' might not be very helpful. I can try to get a couple of other dumps if needed. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 Mon Apr 12 12: 0:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id F31FC1562B for ; Mon, 12 Apr 1999 12:00:38 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id MAA06429; Mon, 12 Apr 1999 12:58:15 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904121858.MAA06429@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904121737.TAA00622@yedi.iaf.nl> from Wilko Bulte at "Apr 12, 1999 7:37:56 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Mon, 12 Apr 1999 12:58:15 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte wrote... > As Kenneth D. Merry wrote ... > > Wilko Bulte wrote... > > > > > - do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k & > > > > > - do a 'mount -r -t cd9660 /dev/cd2a /mnt' > > > > > > The above sequence of commands will reproduce the lockup. > > > Doing: > > > > > > - do a 'mount -r -t cd9660 /dev/cd2a /mnt' > > > - do a 'dd if=/dev/rcd0a of=/dev/null ibs=2k & > > > > > > will work and will just drive the changer nuts with swapping discs. > > > > Well, it shouldn't swap for long. Once the mount finishes, it'll just keep > > reading off of cd0. > > OK, I have not really tried a whole lot of this. > > > > I sort of expected that the mount would lock the cd into the drive, > > > changer or not. > > > > No, it won't. The idea of the LUN-based changer code in the CD driver is > > to allow you to do I/O to *all* CDs in the changer, but not all at the same > > time. > > > > The changer will switch the CD that corresponds to the LUN that is getting > > I/O at the time. One problem that some of these changers have is that if > > you switch too rapidly back and forth between LUNs, they get confused and > > kinda lock up. By enforcing a minimum amount of time on each LUN, the CD > > driver not only avoids lockups, but also increases performance somewhat. > > Ah! This clarifies this neatly. Thanks. Good. The minimum timeout is the guaranteed minimum amount of time that the changer code will spend on a given LUN. The time is calculated starting from the first command *returned* from the given LUN, so the driver doesn't include switch time in the amount of time spent on a LUN. The maximum timeout is the maximum amount of time that will be spent on a given LUN, iff there is I/O pending for another LUN. Otherwise the CD driver will stay on the only LUN that has I/O. > > > Like this? > > > > > > (kgdb) frame 13 > > > #13 0xc0125b17 in cdrunchangerqueue (arg=0xc0780c00) > > > at ../../cam/scsi/scsi_cd.c:1225 > > > 1225 } > > > (kgdb) list > > > 1220 * switch time. > > > 1221 */ > > > 1222 changer->flags |= CHANGER_NEED_TIMEOUT; > > > 1223 > > > 1224 splx(s); > > > 1225 } > > > 1226 > > > 1227 static void > > > 1228 cdchangerschedule(struct cd_softc *softc) > > > 1229 { > > > (kgdb) > > > > Okay, good. Looks like you probably broke into the debugger while it was > > going out of the scheduling function. Now, can you print out some values > > for me: > > > > print /x softc->flags > > print /x changer->flags > > print /x softc->pinfo.index > > Gives: > > (kgdb) frame 13 > #13 0xc0125b17 in cdrunchangerqueue (arg=0xc0780c00) > at ../../cam/scsi/scsi_cd.c:1225 > 1225 } > (kgdb) print /x softc->flags > Cannot access memory at address 0x80000010. > (kgdb) print /x changer->flags > $1 = 0x0 > (kgdb) print /x softc->pinfo.index > Cannot access memory at address 0x80000008. > (kgdb) Hmm, there are a couple of things that could cause this. One could be that you're actually just beyond the stack frame that contained those variables. If you go back up into the stack frame with cdprevent(), can you take a look at: print /x softc->flags print /x softc->changer->flags print /x softc->pinfo.index That might help things somewhat, or maybe not, since the flags will get changed in the routines below that. > > There's a loop in cdgetccb(), and the process should get put into tsleep() > > inside that loop at some point. My guess is that that is not happening for > > some reason. The loop control elements are in the above variables, so > > maybe that'll tell me something. > > I'm not sure, the 'cannot access memory' might not be very helpful. > I can try to get a couple of other dumps if needed. Do you think you might be able to get remote GDB working? You might be able to get better information that way. Ken -- Kenneth Merry ken@plutotech.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 12 13: 7:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 9498914FD5 for ; Mon, 12 Apr 1999 13:07:52 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id VAA24327; Mon, 12 Apr 1999 21:38:26 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id VAA02161; Mon, 12 Apr 1999 21:28:10 +0200 (CEST) From: Wilko Bulte Message-Id: <199904121928.VAA02161@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904121858.MAA06429@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 12, 1999 12:58:15 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Mon, 12 Apr 1999 21:28:10 +0200 (CEST) Cc: freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > > > to allow you to do I/O to *all* CDs in the changer, but not all at the same > > > time. > > > > > > The changer will switch the CD that corresponds to the LUN that is getting > > > I/O at the time. One problem that some of these changers have is that if > > > you switch too rapidly back and forth between LUNs, they get confused and > > > kinda lock up. By enforcing a minimum amount of time on each LUN, the CD > > > driver not only avoids lockups, but also increases performance somewhat. > > > > Ah! This clarifies this neatly. Thanks. > > Good. The minimum timeout is the guaranteed minimum amount of time that > the changer code will spend on a given LUN. The time is calculated > starting from the first command *returned* from the given LUN, so the > driver doesn't include switch time in the amount of time spent on a LUN. > > The maximum timeout is the maximum amount of time that will be spent on a > given LUN, iff there is I/O pending for another LUN. Otherwise the CD > driver will stay on the only LUN that has I/O. [...] > Hmm, there are a couple of things that could cause this. One could be that > you're actually just beyond the stack frame that contained those variables. > > If you go back up into the stack frame with cdprevent(), can you take a > look at: > > print /x softc->flags > print /x softc->changer->flags > print /x softc->pinfo.index > > That might help things somewhat, or maybe not, since the flags will get > changed in the routines below that. A bit more luck now: (kgdb) frame 14 #14 0xc012720c in cdprevent (periph=0xc0780c00, action=1) at ../../cam/scsi/scsi_cd.c:2517 2517 (kgdb) print /x softc->flags $4 = 0xe8 (kgdb) print /x softc->changer->flags $5 = 0x8 (kgdb) print /x softc->pinfo.index $6 = 0xffffffff (kgdb) > > > There's a loop in cdgetccb(), and the process should get put into tsleep() > > > inside that loop at some point. My guess is that that is not happening for > > > some reason. The loop control elements are in the above variables, so > > > maybe that'll tell me something. > > > > I'm not sure, the 'cannot access memory' might not be very helpful. > > I can try to get a couple of other dumps if needed. > > Do you think you might be able to get remote GDB working? You might be > able to get better information that way. I'll give it a try. Soldering iron is heating up to create a cable.. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 Mon Apr 12 13:24:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B2D215087 for ; Mon, 12 Apr 1999 13:24:45 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA07155; Mon, 12 Apr 1999 14:22:23 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904122022.OAA07155@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904121928.VAA02161@yedi.iaf.nl> from Wilko Bulte at "Apr 12, 1999 9:28:10 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Mon, 12 Apr 1999 14:22:22 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte wrote... > As Kenneth D. Merry wrote ... > > Hmm, there are a couple of things that could cause this. One could be that > > you're actually just beyond the stack frame that contained those variables. > > > > If you go back up into the stack frame with cdprevent(), can you take a > > look at: > > > > print /x softc->flags > > print /x softc->changer->flags > > print /x softc->pinfo.index > > > > That might help things somewhat, or maybe not, since the flags will get > > changed in the routines below that. > > A bit more luck now: > > (kgdb) frame 14 > #14 0xc012720c in cdprevent (periph=0xc0780c00, action=1) > at ../../cam/scsi/scsi_cd.c:2517 > 2517 > (kgdb) print /x softc->flags > $4 = 0xe8 Okay, so the active flag is set. > (kgdb) print /x softc->changer->flags > $5 = 0x8 And the need timeout flag is set. > (kgdb) print /x softc->pinfo.index > $6 = 0xffffffff And it isn't queued. Hmm, well, I don't quite understand why it seems to be looping. It shouldn't continue in the loop once the active flag is set. It should get the CCB and keep on going. > > > > There's a loop in cdgetccb(), and the process should get put into tsleep() > > > > inside that loop at some point. My guess is that that is not happening for > > > > some reason. The loop control elements are in the above variables, so > > > > maybe that'll tell me something. > > > > > > I'm not sure, the 'cannot access memory' might not be very helpful. > > > I can try to get a couple of other dumps if needed. > > > > Do you think you might be able to get remote GDB working? You might be > > able to get better information that way. > > I'll give it a try. Soldering iron is heating up to create a cable.. Ahh, doing it the hard way, 'eh? :) In any case, it may help to have a look at those variables with remote gdb. Ken -- Kenneth Merry ken@plutotech.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 12 13:51:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 76FB215593 for ; Mon, 12 Apr 1999 13:51:35 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id WAA26548; Mon, 12 Apr 1999 22:27:40 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id WAA02864; Mon, 12 Apr 1999 22:33:12 +0200 (CEST) From: Wilko Bulte Message-Id: <199904122033.WAA02864@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904121858.MAA06429@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 12, 1999 12:58:15 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Mon, 12 Apr 1999 22:33:12 +0200 (CEST) Cc: freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > That might help things somewhat, or maybe not, since the flags will get > changed in the routines below that. > > > > There's a loop in cdgetccb(), and the process should get put into tsleep() > > > inside that loop at some point. My guess is that that is not happening for > > > some reason. The loop control elements are in the above variables, so > > > maybe that'll tell me something. > > > > I'm not sure, the 'cannot access memory' might not be very helpful. > > I can try to get a couple of other dumps if needed. > > Do you think you might be able to get remote GDB working? You might be > able to get better information that way. Correct me if I'm wrong but I think I just hit a brick wall: - my testbox with the Pioneer changer on it is 4.0-current - my 'production' box is 2.2.8-stable What I need to do a remote kdebug is a gdb running on 2.2.8 (so aout itself) while at the same time smart enough to understand elf (the 4.0-current kernel). Would/should the following work: - export OBJFORMAT=aout on the 4.0 machine - run a local make in /usr/src/gnu/usr.bin/gdb - take the resulting gdb binary to the 2.2.8 machine ? Or is this cutting too many corners? Maybe also link gdb static? Alternative: could I use a 4.0-current *Alpha* box to remotely gdb? I.e. can gdb read other architectures execs/dumps? Probably not I guess.. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 Mon Apr 12 14: 0: 3 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 31CFA150DA for ; Mon, 12 Apr 1999 13:59:57 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA07372; Mon, 12 Apr 1999 14:57:32 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904122057.OAA07372@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904122033.WAA02864@yedi.iaf.nl> from Wilko Bulte at "Apr 12, 1999 10:33:12 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Mon, 12 Apr 1999 14:57:32 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte wrote... > As Kenneth D. Merry wrote ... > > > That might help things somewhat, or maybe not, since the flags will get > > changed in the routines below that. > > > > > > There's a loop in cdgetccb(), and the process should get put into tsleep() > > > > inside that loop at some point. My guess is that that is not happening for > > > > some reason. The loop control elements are in the above variables, so > > > > maybe that'll tell me something. > > > > > > I'm not sure, the 'cannot access memory' might not be very helpful. > > > I can try to get a couple of other dumps if needed. > > > > Do you think you might be able to get remote GDB working? You might be > > able to get better information that way. > > Correct me if I'm wrong but I think I just hit a brick wall: > > - my testbox with the Pioneer changer on it is 4.0-current > - my 'production' box is 2.2.8-stable > > What I need to do a remote kdebug is a gdb running on 2.2.8 (so aout itself) > while at the same time smart enough to understand elf (the 4.0-current > kernel). > > Would/should the following work: > > - export OBJFORMAT=aout on the 4.0 machine > - run a local make in /usr/src/gnu/usr.bin/gdb > - take the resulting gdb binary to the 2.2.8 machine > ? > > Or is this cutting too many corners? Maybe also link gdb static? Yikes. You might be able to get away with it if you run a statically linked ELF gdb from your 4.0 box on your 2.2.8 box. I'm not sure, though. Obviously you'll need the source and binaries on your 2.2.8 box, which I assume you'll compile over NFS from the 4.0 box. That might work, but I'm really no expert on this. All of my machines are ELF now, running either -current or 3.1-stable. > Alternative: could I use a 4.0-current *Alpha* box to remotely gdb? I.e. > can gdb read other architectures execs/dumps? Probably not I guess.. I doubt that'll work. Wouldn't you need an i386 gdb to understand the debugging kernel and talk over the serial port? One other thing that would work is you could send me the changer. :) Of course the postage from there would probably be more than the thing is worth...and then there's customs and all. Ken -- Kenneth Merry ken@plutotech.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 12 15: 9: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 4D18714E33 for ; Mon, 12 Apr 1999 15:08:53 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id XAA31155; Mon, 12 Apr 1999 23:57:26 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id XAA03836; Mon, 12 Apr 1999 23:51:27 +0200 (CEST) From: Wilko Bulte Message-Id: <199904122151.XAA03836@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904122057.OAA07372@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 12, 1999 2:57:32 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Mon, 12 Apr 1999 23:51:27 +0200 (CEST) Cc: freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > Wilko Bulte wrote... > > As Kenneth D. Merry wrote ... > > Correct me if I'm wrong but I think I just hit a brick wall: > > > > - my testbox with the Pioneer changer on it is 4.0-current > > - my 'production' box is 2.2.8-stable > > > > What I need to do a remote kdebug is a gdb running on 2.2.8 (so aout itself) > > while at the same time smart enough to understand elf (the 4.0-current > > kernel). > > > > Would/should the following work: > > > > - export OBJFORMAT=aout on the 4.0 machine > > - run a local make in /usr/src/gnu/usr.bin/gdb > > - take the resulting gdb binary to the 2.2.8 machine > > ? > > > > Or is this cutting too many corners? Maybe also link gdb static? > > Yikes. You might be able to get away with it if you run a statically > linked ELF gdb from your 4.0 box on your 2.2.8 box. I'm not sure, though. Yikes indeed. > Obviously you'll need the source and binaries on your 2.2.8 box, which I > assume you'll compile over NFS from the 4.0 box. That is exactly the config I'm using. > That might work, but I'm really no expert on this. All of my machines are > ELF now, running either -current or 3.1-stable. > > > Alternative: could I use a 4.0-current *Alpha* box to remotely gdb? I.e. > > can gdb read other architectures execs/dumps? Probably not I guess.. > > I doubt that'll work. Wouldn't you need an i386 gdb to understand the > debugging kernel and talk over the serial port? I don't know. It is just a thought. A bit bizarre one maybe :) I decided to bit the bullet: 2.2.8 is going to be 3.1 via an upgrade, probably tomorrow evening. Should give me elf support et al. And a working gdb :) > One other thing that would work is you could send me the changer. :) Of > course the postage from there would probably be more than the thing is > worth...and then there's customs and all. It's not worth it. And given it's sort of fragile nature I don't think it would still work after a transatlantic trip. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 Mon Apr 12 20:29:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rt2.synx.com (tech.boostworks.com [194.167.81.239]) by hub.freebsd.org (Postfix) with ESMTP id B132214CAA for ; Mon, 12 Apr 1999 20:28:12 -0700 (PDT) (envelope-from root@synx.com) Received: from synx.com (rn.synx.com [192.1.1.241]) by rt2.synx.com (8.9.1/8.9.1) with ESMTP id UAA30722 for ; Mon, 12 Apr 1999 20:04:34 +0200 (CEST) Message-Id: <199904121804.UAA30722@rt2.synx.com> Date: Mon, 12 Apr 1999 20:04:31 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@synx.com Subject: Huge SCSI configs To: freebsd-scsi@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am looking for advices about building a fearly huge SCSI config. The config would be : - 4 SCSI chains (2x3950U2W planned) - 12 18.2 GB per chain (48 totals disks) - one Gigabit ethernet link - SMP (Quad-Xeon or Bi-P2) Advices wanted (do/don't). TIA. RN. IhM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 12 20:52:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id BE5A014D53 for ; Mon, 12 Apr 1999 20:52:02 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id VAA09442; Mon, 12 Apr 1999 21:49:40 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904130349.VAA09442@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904122151.XAA03836@yedi.iaf.nl> from Wilko Bulte at "Apr 12, 1999 11:51:27 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Mon, 12 Apr 1999 21:49:40 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM923975380-9424-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --ELM923975380-9424-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Wilko Bulte wrote... > As Kenneth D. Merry wrote ... > > Wilko Bulte wrote... > > > Alternative: could I use a 4.0-current *Alpha* box to remotely gdb? I.e. > > > can gdb read other architectures execs/dumps? Probably not I guess.. > > > > I doubt that'll work. Wouldn't you need an i386 gdb to understand the > > debugging kernel and talk over the serial port? > > I don't know. It is just a thought. A bit bizarre one maybe :) > > I decided to bit the bullet: 2.2.8 is going to be 3.1 via an upgrade, > probably tomorrow evening. Should give me elf support et al. And a > working gdb :) Well, here's something else you can try. Justin and I went through the section of code in question, and it looks like there may be a race condition that could theoretically cause your problem. In any case, try these diffs out. There are two main changes here. The first will let the CD driver attach to anything that claims to be a CD or WORM drive, unless it sends back a "logical unit not supported" error. The second may fix the race condition. I haven't tested these changes out other than to make sure they compile. Let me know how it works. Ken -- Kenneth Merry ken@plutotech.com --ELM923975380-9424-0_ Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: attachment; filename=scsi_cd.c.changer.diffs.041299 Content-Description: scsi_cd.c.changer.diffs.041299 Content-Transfer-Encoding: 7bit ==== //depot/cam/sys/cam/scsi/scsi_cd.c#102 - /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_cd.c ==== *** /tmp/tmp.33532.0 Mon Apr 12 21:42:23 1999 --- /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_cd.c Mon Apr 12 21:41:54 1999 *************** *** 126,132 **** struct cd_softc { cam_pinfo pinfo; cd_state state; ! cd_flags flags; struct buf_queue_head buf_queue; LIST_HEAD(, ccb_hdr) pending_ccbs; struct cd_params params; --- 126,132 ---- struct cd_softc { cam_pinfo pinfo; cd_state state; ! volatile cd_flags flags; struct buf_queue_head buf_queue; LIST_HEAD(, ccb_hdr) pending_ccbs; struct cd_params params; *************** *** 301,307 **** struct cd_softc *cur_device; struct callout_handle short_handle; struct callout_handle long_handle; ! cd_changer_flags flags; STAILQ_ENTRY(cdchanger) changer_links; STAILQ_HEAD(chdevlist, cd_softc) chluns; }; --- 301,307 ---- struct cd_softc *cur_device; struct callout_handle short_handle; struct callout_handle long_handle; ! volatile cd_changer_flags flags; STAILQ_ENTRY(cdchanger) changer_links; STAILQ_HEAD(chdevlist, cd_softc) chluns; }; *************** *** 1103,1109 **** * bootstrap things. */ if (((softc->changer->flags & CHANGER_TIMEOUT_SCHED)==0) ! &&((softc->changer->flags & CHANGER_NEED_TIMEOUT)==0)){ softc->changer->flags |= CHANGER_MANUAL_CALL; cdrunchangerqueue(softc->changer); } --- 1103,1110 ---- * bootstrap things. */ if (((softc->changer->flags & CHANGER_TIMEOUT_SCHED)==0) ! && ((softc->changer->flags & CHANGER_NEED_TIMEOUT)==0) ! && ((softc->changer->flags & CHANGER_SHORT_TMOUT_SCHED)==0)){ softc->changer->flags |= CHANGER_MANUAL_CALL; cdrunchangerqueue(softc->changer); } *************** *** 1341,1347 **** * This should work the first time this device is woken up, * but just in case it doesn't, we use a while loop. */ ! while ((((volatile cd_flags)softc->flags) & CD_FLAG_ACTIVE)==0){ /* * If this changer isn't already queued, queue it up. */ --- 1342,1348 ---- * This should work the first time this device is woken up, * but just in case it doesn't, we use a while loop. */ ! while ((softc->flags & CD_FLAG_ACTIVE) == 0) { /* * If this changer isn't already queued, queue it up. */ *************** *** 1352,1361 **** camq_insert(&softc->changer->devq, (cam_pinfo *)softc); } ! if (((((volatile cd_changer_flags)softc->changer->flags) ! & CHANGER_TIMEOUT_SCHED)==0) ! &&((((volatile cd_changer_flags)softc->changer->flags) ! & CHANGER_NEED_TIMEOUT)==0)){ softc->changer->flags |= CHANGER_MANUAL_CALL; cdrunchangerqueue(softc->changer); } else --- 1353,1362 ---- camq_insert(&softc->changer->devq, (cam_pinfo *)softc); } ! if (((softc->changer->flags & CHANGER_TIMEOUT_SCHED)==0) ! && ((softc->changer->flags & CHANGER_NEED_TIMEOUT)==0) ! && ((softc->changer->flags ! & CHANGER_SHORT_TMOUT_SCHED)==0)) { softc->changer->flags |= CHANGER_MANUAL_CALL; cdrunchangerqueue(softc->changer); } else *************** *** 1739,1756 **** &asc, &ascq); } /* ! * With CDROM devices, we expect 0x3a ! * (Medium not present) errors, since not ! * everyone leaves a CD in the drive. Some ! * broken Philips and HP WORM drives return ! * 0x04,0x00 (logical unit not ready, cause ! * not reportable), so we accept any "not ! * ready" type errors as well. If the error ! * is anything else, though, we shouldn't ! * attach. */ ! if ((have_sense) ! && ((asc == 0x3a) || (asc == 0x04)) && (error_code == SSD_CURRENT_ERROR)) snprintf(announce_buf, sizeof(announce_buf), --- 1740,1751 ---- &asc, &ascq); } /* ! * Attach to anything that claims to be a ! * CDROM or WORM device, as long as it ! * doesn't return a "Logical unit not ! * supported" (0x25) error. */ ! if ((have_sense) && (asc != 0x25) && (error_code == SSD_CURRENT_ERROR)) snprintf(announce_buf, sizeof(announce_buf), --ELM923975380-9424-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 12 21:25: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FBB214E4D for ; Mon, 12 Apr 1999 21:24:57 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id WAA09582; Mon, 12 Apr 1999 22:22:34 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904130422.WAA09582@panzer.plutotech.com> Subject: Re: Huge SCSI configs In-Reply-To: <199904121804.UAA30722@rt2.synx.com> from Remy Nonnenmacher at "Apr 12, 1999 8: 4:31 pm" To: remy@synx.com Date: Mon, 12 Apr 1999 22:22:34 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Remy Nonnenmacher wrote... > I am looking for advices about building a fearly huge SCSI config. > > The config would be : > > - 4 SCSI chains (2x3950U2W planned) That should work okay, as long as you use -current or -stable *after* March 23rd. I've got one in my test box, and it seems to work fine. I haven't pushed it much, though. One thing to be careful about is what sort of slot you put this thing in. If you get a motherboard with only 32-bit slots, you need to make sure that the back end of the PCI slots is thin enough to handle a 64-bit PCI card. There was one machine that I tried to put my 3950 into that it wouldn't fit in, because the back end of the slot was too thick. It worked fine in two other machines, though. > - 12 18.2 GB per chain (48 totals disks) Well, first off, make sure you get IBM or Seagate, and make sure you get one of their high end drives. (not that they're making low-end 18 gig drives yet, AFAIK) I've had direct experience with the 18G Seagate Cheetah II's and IBM Ultrastar 18XP's. They both work fine. My guess is that the IBM Ultrastar 18ZX would work well, too. You should be okay with most any 18G IBM or Seagate disk. But 12 per chain? Assuming these are all Ultra2 LVD, you're still pushing things a bit as far as SCSI bus bandwidth is concerned. For instance, the IBM Ultrastar 18ZX runs at about 23MB/sec on the outer tracks according to IBM's web site. With that sort of performance, you wouldn't be able to get maximum performance out of the disks if had more than 3 on an Ultra 2 chain. You'll also have to start worrying about PCI bus bandwidth and memory bandwidth, depending on what sort of motherboard you get. So, one question I have is this -- are you looking for maximum disk performance, or just a lot of disk space? If you're just looking for a lot of disk space, why not go with 36GB drives? NECX (www.necx.com) is selling IBM Ultrastar 36XP's for $1400. The Ultrastar 18ES is selling for $775. So, it would be cheaper to go with a 36G drive. (FWIW, I know that the 36XP's work just fine, but I haven't seen any 18ES drives yet. I'd imagine they work fine as well.) > - one Gigabit ethernet link Isn't there only one gigabit ethernet driver (Alteon?) at the moment? You should probably ask Bill Paul how it works. You may also want to ask David Greenman about this, since I think he mentioned on -current a while back that he was working on a Gigabit Ethernet driver as well. > - SMP (Quad-Xeon or Bi-P2) Considering the monster you're trying to build, I'd say go for a board that'll get you 64-bit PCI and high memory bandwidth. My guess is that a Quad Xeon board from Intel might do the trick. Ask Mike Smith about these, they had (have??) one at Walnut Creek, I think. From looking at Intel's web page, it looks like you should probably be looking at the AC450NX and the AD450NX servers. You may want to find someone who has one of these, or has tried one out before buying. > Advices wanted (do/don't). I would advise that you thoroughly research things before you buy any hardware. The hardware you're looking at is cutting edge, but there are folks who have "been there, done that" with each item you listed above. If you buy the wrong thing, you can potentially waste a whole lot of money. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 3:14:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from stampede.cs.berkeley.edu (stampede.CS.Berkeley.EDU [128.32.45.124]) by hub.freebsd.org (Postfix) with ESMTP id E4E5314A09 for ; Tue, 13 Apr 1999 03:14:15 -0700 (PDT) (envelope-from asami@cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca1-146.ix.netcom.com [209.109.232.146]) by stampede.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id DAA14420 for ; Tue, 13 Apr 1999 03:12:04 -0700 (PDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.2/8.6.9) id DAA47254; Tue, 13 Apr 1999 03:10:41 -0700 (PDT) Date: Tue, 13 Apr 1999 03:10:41 -0700 (PDT) Message-Id: <199904131010.DAA47254@silvia.hip.berkeley.edu> X-Authentication-Warning: silvia.hip.berkeley.edu: asami set sender to asami@cs.berkeley.edu using -f To: scsi@freebsd.org Subject: timed out while idle? From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Justin, Ken and others, What exactly does "timed out while idle" mean? We're still seeing these stuff from time to time: === Apr 1 18:34:47 m0 /kernel: (da44:ahc2:0:12:0): SCB 0x30 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Apr 1 18:34:47 m0 /kernel: SEQADDR == 0x8 Apr 1 18:34:47 m0 /kernel: SSTAT1 == 0xa Apr 1 18:34:47 m0 /kernel: (da44:ahc2:0:12:0): Queuing a BDR SCB Apr 1 18:34:47 m0 /kernel: (da44:ahc2:0:12:0): Bus Device Reset Message Sent Apr 1 18:34:47 m0 /kernel: (da44:ahc2:0:12:0): no longer in timeout, status = 34b Apr 1 18:34:47 m0 /kernel: ahc2: Bus Device Reset on A:12. 1 SCBs aborted Apr 1 18:58:37 m0 sshd[28252]: log: Connection from 209.111.209.216 port 963 Apr 1 18:58:40 m0 sshd[28252]: log: RSA authentication for asami2 accepted. Apr 1 19:38:30 m0 sshd[1204]: log: Generating new 768 bit RSA key. Apr 1 19:38:30 m0 sshd[1204]: log: RSA key generation complete. Apr 2 13:43:27 m0 /kernel: (da33:ahc2:0:1:0): SCB 0x86 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Apr 2 13:43:27 m0 /kernel: SEQADDR == 0x8 Apr 2 13:43:27 m0 /kernel: SSTAT1 == 0xa Apr 2 13:43:27 m0 /kernel: (da33:ahc2:0:1:0): Queuing a BDR SCB Apr 2 13:43:27 m0 /kernel: (da33:ahc2:0:1:0): Bus Device Reset Message Sent Apr 2 13:43:27 m0 /kernel: (da33:ahc2:0:1:0): no longer in timeout, status = 34b Apr 2 13:43:27 m0 /kernel: ahc2: Bus Device Reset on A:1. 1 SCBs aborted Apr 2 14:58:03 m0 /kernel: (da32:ahc2:0:0:0): SCB 0x75 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Apr 2 14:58:03 m0 /kernel: SEQADDR == 0x8 Apr 2 14:58:03 m0 /kernel: SSTAT1 == 0xa Apr 2 14:58:03 m0 /kernel: (da32:ahc2:0:0:0): Queuing a BDR SCB Apr 2 14:58:03 m0 /kernel: (da32:ahc2:0:0:0): Bus Device Reset Message Sent Apr 2 14:58:03 m0 /kernel: (da32:ahc2:0:0:0): no longer in timeout, status = 34b Apr 2 14:58:03 m0 /kernel: ahc2: Bus Device Reset on A:0. 2 SCBs aborted === Some of these eventually lead to panics or hangs. These are the same IBM disks we asked about a while ago. === da34 at ahc2 bus 0 target 2 lun 0 da34: Fixed Direct Access SCSI2 device da34: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing Enabled da34: 8689MB (17796077 512 byte sectors: 255H 63S/T 1107C) === I traced the message to ahc_timeout() in aic7xxx.c but not being a kernel hacker myself I can't really tell where it's called from. Is this like one of those alarm clocks ("wake me up in 5msecs if nothing happens")? Also, I see 7 phases in case statements: === case P_DATAOUT: printf("in dataout phase"); break; case P_DATAIN: printf("in datain phase"); break; case P_COMMAND: printf("in command phase"); break; case P_MESGOUT: printf("in message out phase"); break; case P_STATUS: printf("in status phase"); break; case P_MESGIN: printf("in message in phase"); break; case P_BUSFREE: printf("while idle, LASTPHASE == 0x%x", bus_state); break; === Is there some place that explans roughly what these correspond to? The ones we see most often are P_BUSFREE, P_COMMAND and P_DATAIN. I see that you refer to Adaptec databooks in aic7xxx.reg but since we don't have those, any web page or other on-line documentation that we can refer to will be great. Thanks! Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 3:52:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 8211515054 for ; Tue, 13 Apr 1999 03:51:41 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from gosset.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 13 Apr 99 11:49:18 +0100 (BST) Date: Tue, 13 Apr 1999 11:49:18 +0100 From: David Malone To: Remy Nonnenmacher Cc: freebsd-scsi@freebsd.org Subject: Re: Huge SCSI configs Message-ID: <19990413114918.A637@gosset.maths.tcd.ie> References: <199904121804.UAA30722@rt2.synx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199904121804.UAA30722@rt2.synx.com>; from Remy Nonnenmacher on Mon, Apr 12, 1999 at 08:04:31PM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Apr 12, 1999 at 08:04:31PM +0200, Remy Nonnenmacher wrote: > - SMP (Quad-Xeon or Bi-P2) We've found that the CPU <-> memory bandwidth of our quad Xeon is only 2/3 that of any of our dual PII 400 or our signle PII 450. Mike Smith ran our benchmark on the quad Xeon they have and got much the same result. I haven't figured out if it is a Xeon thing, or a quad processor thing yet. Naturally the CPU to memory bandwidth may not be a huge issue for you in. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 8:13:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rt2.synx.com (tech.boostworks.com [194.167.81.239]) by hub.freebsd.org (Postfix) with ESMTP id 712BA15653 for ; Tue, 13 Apr 1999 08:05:31 -0700 (PDT) (envelope-from root@synx.com) Received: from synx.com (rn.synx.com [192.1.1.241]) by rt2.synx.com (8.9.1/8.9.1) with ESMTP id QAA35693; Tue, 13 Apr 1999 16:53:46 +0200 (CEST) Message-Id: <199904131453.QAA35693@rt2.synx.com> Date: Tue, 13 Apr 1999 16:53:43 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@synx.com Subject: Re: Huge SCSI configs To: ken@plutotech.com Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <199904130422.WAA09582@panzer.plutotech.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 12 Apr, Kenneth D. Merry wrote: > Remy Nonnenmacher wrote... >> I am looking for advices about building a fearly huge SCSI config. >> >> The config would be : >> >> - 4 SCSI chains (2x3950U2W planned) > > That should work okay, as long as you use -current or -stable *after* March > 23rd. I've got one in my test box, and it seems to work fine. I haven't > pushed it much, though. > OK. Sorry for this late (but ever unanswered question) : what are the known limits in term of SCSI chains, number and size of disks and sizes of filesystems ? Anyone ? > One thing to be careful about is what sort of slot you put this thing in. > If you get a motherboard with only 32-bit slots, you need to make sure that > the back end of the PCI slots is thin enough to handle a 64-bit PCI card. > >..... OK. Still looking for 64 bits PCI MB. >> - 12 18.2 GB per chain (48 totals disks) > > Well, first off, make sure you get IBM or Seagate, and make sure you get > one of their high end drives. (not that they're making low-end 18 gig > drives yet, AFAIK) I've had direct experience with the 18G Seagate > Cheetah II's and IBM Ultrastar 18XP's. They both work fine. My guess is > that the IBM Ultrastar 18ZX would work well, too. > > You should be okay with most any 18G IBM or Seagate disk. > > But 12 per chain? Assuming these are all Ultra2 LVD, you're still pushing > things a bit as far as SCSI bus bandwidth is concerned. For instance, the > IBM Ultrastar 18ZX runs at about 23MB/sec on the outer tracks according to > IBM's web site. > > With that sort of performance, you wouldn't be able to get maximum > performance out of the disks if had more than 3 on an Ultra 2 chain. > Drives would be CCDed or Vinumed by groups of four, one per chain. Each drive divided into three parts, the outer, intermediate and inner cylinders to provide 3 different performance rings. Due to environmental constraints, there are two prefered drives : IBM 18ES or Quantum Atlas4 all two 1 inches. > You'll also have to start worrying about PCI bus bandwidth and memory > bandwidth, depending on what sort of motherboard you get. > > So, one question I have is this -- are you looking for maximum disk > performance, or just a lot of disk space? If you're just looking for a lot > of disk space, why not go with 36GB drives? NECX (www.necx.com) is selling > IBM Ultrastar 36XP's for $1400. The Ultrastar 18ES is selling for $775. > So, it would be cheaper to go with a 36G drive. (FWIW, I know that the > 36XP's work just fine, but I haven't seen any 18ES drives yet. I'd imagine > they work fine as well.) > 36.4 Gigs are all 1.6 inches and won't (probably) fit. 50.1 Gigs are too youngs (bad exp with Seagate on early drives, and probably unaffordable) and would lead to less R/W heads. >> - one Gigabit ethernet link > > Isn't there only one gigabit ethernet driver (Alteon?) at the moment? You > should probably ask Bill Paul how it works. You may also want to ask David > Greenman about this, since I think he mentioned on -current a while back > that he was working on a Gigabit Ethernet driver as well. > Seen it. Packet-engine also provide one. >> - SMP (Quad-Xeon or Bi-P2) > > Considering the monster you're trying to build, I'd say go for a board > that'll get you 64-bit PCI and high memory bandwidth. My guess is that a > Quad Xeon board from Intel might do the trick. Ask Mike Smith about these, > they had (have??) one at Walnut Creek, I think. > Thanks for you reply. It seems pretty clear that PCI bandwidth will be the real problem. I know for sure that it have been a problem on the GigaEth. case and it will be a botleneck point with two (or more) fast SCSI cards running high-end drives. Also, Xeon machines do not appear to be the real killers Intel pretends but SC450NX (or the HP version using 64 bit PCI) machines goes pretty well in my (rackable) constraints. Thanks again. RN. ItM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 9:10:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 35F4C1567C for ; Tue, 13 Apr 1999 09:10:26 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id KAA03222; Tue, 13 Apr 1999 10:07:53 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904131607.KAA03222@panzer.plutotech.com> Subject: Re: Huge SCSI configs In-Reply-To: <199904131453.QAA35693@rt2.synx.com> from Remy Nonnenmacher at "Apr 13, 1999 4:53:43 pm" To: remy@synx.com Date: Tue, 13 Apr 1999 10:07:53 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Remy Nonnenmacher wrote... > On 12 Apr, Kenneth D. Merry wrote: > > Remy Nonnenmacher wrote... > >> I am looking for advices about building a fearly huge SCSI config. > >> > >> The config would be : > >> > >> - 4 SCSI chains (2x3950U2W planned) > > > > That should work okay, as long as you use -current or -stable *after* March > > 23rd. I've got one in my test box, and it seems to work fine. I haven't > > pushed it much, though. > > > > OK. Sorry for this late (but ever unanswered question) : what are the > known limits in term of SCSI chains, number and size of disks and sizes > of filesystems ? Anyone ? Aww, come on, you can easily find out the SCSI stuff anywhere on the web. For Wide SCSI, you can have up to 15 devices on one chain. (SCSI IDs 0 through 15, with 7 reserved for the controller) With Ultra2 LVD, you can have cable lengths of up to 12 meters. There's no inherent limit on disk size, but you may want to talk to Matt Jacob and Matt Dillon about the stability of very large filesystems. > > One thing to be careful about is what sort of slot you put this thing in. > > If you get a motherboard with only 32-bit slots, you need to make sure that > > the back end of the PCI slots is thin enough to handle a 64-bit PCI card. > > > >..... > > OK. Still looking for 64 bits PCI MB. Okay, that'll work. > >> - 12 18.2 GB per chain (48 totals disks) > > > > Well, first off, make sure you get IBM or Seagate, and make sure you get > > one of their high end drives. (not that they're making low-end 18 gig > > drives yet, AFAIK) I've had direct experience with the 18G Seagate > > Cheetah II's and IBM Ultrastar 18XP's. They both work fine. My guess is > > that the IBM Ultrastar 18ZX would work well, too. > > > > You should be okay with most any 18G IBM or Seagate disk. > > > > But 12 per chain? Assuming these are all Ultra2 LVD, you're still pushing > > things a bit as far as SCSI bus bandwidth is concerned. For instance, the > > IBM Ultrastar 18ZX runs at about 23MB/sec on the outer tracks according to > > IBM's web site. > > > > With that sort of performance, you wouldn't be able to get maximum > > performance out of the disks if had more than 3 on an Ultra 2 chain. > > > > Drives would be CCDed or Vinumed by groups of four, one per chain. Each > drive divided into three parts, the outer, intermediate and inner > cylinders to provide 3 different performance rings. Ahh, so you *are* looking for performance. > Due to environmental constraints, there are two prefered drives : IBM > 18ES or Quantum Atlas4 all two 1 inches. Do yourself a favor and don't get the Atlas 4. So you need 1" high drives? > > You'll also have to start worrying about PCI bus bandwidth and memory > > bandwidth, depending on what sort of motherboard you get. > > > > So, one question I have is this -- are you looking for maximum disk > > performance, or just a lot of disk space? If you're just looking for a lot > > of disk space, why not go with 36GB drives? NECX (www.necx.com) is selling > > IBM Ultrastar 36XP's for $1400. The Ultrastar 18ES is selling for $775. > > So, it would be cheaper to go with a 36G drive. (FWIW, I know that the > > 36XP's work just fine, but I haven't seen any 18ES drives yet. I'd imagine > > they work fine as well.) > > > > 36.4 Gigs are all 1.6 inches and won't (probably) fit. 50.1 Gigs are > too youngs (bad exp with Seagate on early drives, and probably > unaffordable) and would lead to less R/W heads. And 50G drives would probably also be 1.6". > >> - SMP (Quad-Xeon or Bi-P2) > > > > Considering the monster you're trying to build, I'd say go for a board > > that'll get you 64-bit PCI and high memory bandwidth. My guess is that a > > Quad Xeon board from Intel might do the trick. Ask Mike Smith about these, > > they had (have??) one at Walnut Creek, I think. > > > > Thanks for you reply. It seems pretty clear that PCI bandwidth will be > the real problem. I know for sure that it have been a problem on the > GigaEth. case and it will be a botleneck point with two (or more) fast > SCSI cards running high-end drives. > > Also, Xeon machines do not appear to be the real killers Intel pretends > but SC450NX (or the HP version using 64 bit PCI) machines goes pretty > well in my (rackable) constraints. I think you'll certainly want 64-bit PCI, and probably multiple PCI busses. I'm not sure whether you can get a 450NX box with two 64-bit PCI busses (the chipset is capable, I don't know whether anyone makes a motherboard with that particular configuration), but that might be a good thing to look for. In any case, with only 4 SCSI busses, I doubt you'll be able to get the full performance out of your disks, but maybe the performance you will get will be enough. Here are some numbers to think about: IBM Ultrastar 18ES Peak performance: 20MB/sec 48 * Ultrastar 18ES: 960MB/sec 4 x Ultra2 LVD Wide SCSI busses: 320MB/sec Gigabit Ethernet theoretical peak: 125MB/sec 64-bit, 33MHz PCI: ~266MB/sec So, you've got a couple of bottlenecks here. The first is that the total disk bandwidth you'll have is about 3 times the amount of SCSI bus bandwidth you'll have available. The second is that your two 3950U2's together would be capable of flooding a 33MHz 64-bit PCI bus. You'll also run into memory bandwidth issues, processor speed issues and various other things. It'll certainly be an interesting experiment. What sort of performance are you trying to get out of this thing anyway? Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 9:25:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id D44F115764 for ; Tue, 13 Apr 1999 09:25:45 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id KAA03308; Tue, 13 Apr 1999 10:23:21 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904131623.KAA03308@panzer.plutotech.com> Subject: Re: timed out while idle? In-Reply-To: <199904131010.DAA47254@silvia.hip.berkeley.edu> from Satoshi Asami at "Apr 13, 1999 3:10:41 am" To: asami@cs.berkeley.edu (Satoshi Asami) Date: Tue, 13 Apr 1999 10:23:21 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Satoshi Asami wrote... > Hi Justin, Ken and others, > > What exactly does "timed out while idle" mean? We're still seeing > these stuff from time to time: > > === > Apr 1 18:34:47 m0 /kernel: (da44:ahc2:0:12:0): SCB 0x30 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 > Apr 1 18:34:47 m0 /kernel: SEQADDR == 0x8 > Apr 1 18:34:47 m0 /kernel: SSTAT1 == 0xa > Apr 1 18:34:47 m0 /kernel: (da44:ahc2:0:12:0): Queuing a BDR SCB > Apr 1 18:34:47 m0 /kernel: (da44:ahc2:0:12:0): Bus Device Reset Message Sent > Apr 1 18:34:47 m0 /kernel: (da44:ahc2:0:12:0): no longer in timeout, status = 34b > Apr 1 18:34:47 m0 /kernel: ahc2: Bus Device Reset on A:12. 1 SCBs aborted The timed out while idle message means that the drive took longer than the timeout (60 seconds) to respond to a read or write request, and nothing was going on on the bus at the time. In other words, your drive went out to lunch, and we hit it with a BDR to get it to come back. > Some of these eventually lead to panics or hangs. > > These are the same IBM disks we asked about a while ago. > > === > da34 at ahc2 bus 0 target 2 lun 0 > da34: Fixed Direct Access SCSI2 device > da34: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing Enabled > da34: 8689MB (17796077 512 byte sectors: 255H 63S/T 1107C) > === > > I traced the message to ahc_timeout() in aic7xxx.c but not being a > kernel hacker myself I can't really tell where it's called from. Is > this like one of those alarm clocks ("wake me up in 5msecs if nothing > happens")? Yep. There's a timeout for each transaction. If the transaction doesn't complete in the specified period of time (60 seconds for disk reads/writes), the timeout fires, a BDR is sent and all transactions that were queued to the disk are requeued. > Also, I see 7 phases in case statements: > > === > case P_DATAOUT: > printf("in dataout phase"); > break; > case P_DATAIN: > printf("in datain phase"); > break; > case P_COMMAND: > printf("in command phase"); > break; > case P_MESGOUT: > printf("in message out phase"); > break; > case P_STATUS: > printf("in status phase"); > break; > case P_MESGIN: > printf("in message in phase"); > break; > case P_BUSFREE: > printf("while idle, LASTPHASE == 0x%x", > bus_state); > break; > === > > Is there some place that explans roughly what these correspond to? > The ones we see most often are P_BUSFREE, P_COMMAND and P_DATAIN. I > see that you refer to Adaptec databooks in aic7xxx.reg but since we > don't have those, any web page or other on-line documentation that we > can refer to will be great. Those are SCSI bus phases. If you're seeing timeouts in datain phase or command phase, that often indicates a termination or cabling problem. Just look at the SCSI specs if you want to find out about the different SCSI bus phases. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 10:25: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rt2.synx.com (tech.boostworks.com [194.167.81.239]) by hub.freebsd.org (Postfix) with ESMTP id 32B7215722 for ; Tue, 13 Apr 1999 10:24:54 -0700 (PDT) (envelope-from root@synx.com) Received: from synx.com (rn.synx.com [192.1.1.241]) by rt2.synx.com (8.9.1/8.9.1) with ESMTP id TAA36868; Tue, 13 Apr 1999 19:22:22 +0200 (CEST) Message-Id: <199904131722.TAA36868@rt2.synx.com> Date: Tue, 13 Apr 1999 19:22:19 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@synx.com Subject: Re: Huge SCSI configs To: ken@plutotech.com Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <199904131607.KAA03222@panzer.plutotech.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13 Apr, Kenneth D. Merry wrote: >> .... >> OK. Sorry for this late (but ever unanswered question) : what are the >> known limits in term of SCSI chains, number and size of disks and sizes >> of filesystems ? Anyone ? > > Aww, come on, you can easily find out the SCSI stuff anywhere on the web. > For Wide SCSI, you can have up to 15 devices on one chain. (SCSI IDs 0 > through 15, with 7 reserved for the controller) With Ultra2 LVD, you can > have cable lengths of up to 12 meters. > Oops, lacked precision "under FreeBSD" !!. (I already proposed building a MAX config (15*2*15*50G) but they had me stop by knocking my head ;). No, seriously, i wouldn't like to find myself running honking into a wall just for not having asked. > There's no inherent limit on disk size, but you may want to talk to Matt > Jacob and Matt Dillon about the stability of very large filesystems. > Fine. I'll do it. >> >> Drives would be CCDed or Vinumed by groups of four, one per chain. Each >> drive divided into three parts, the outer, intermediate and inner >> cylinders to provide 3 different performance rings. > > Ahh, so you *are* looking for performance. > *AND* size... >> Due to environmental constraints, there are two prefered drives : IBM >> 18ES or Quantum Atlas4 all two 1 inches. > > Do yourself a favor and don't get the Atlas 4. So you need 1" high drives? > Yes. 18G is the best tradeoff between perfs/thermal/#heads/stacking. (BTW, I use Quantum and IBM and never got problems. Let me know if you got some with Quantum). > > And 50G drives would probably also be 1.6". > Da. (with ridiculous buffers 1M buffer where everybody is 2 and going 4). > > I think you'll certainly want 64-bit PCI, and probably multiple PCI busses. > I'm not sure whether you can get a 450NX box with two 64-bit PCI busses > (the chipset is capable, I don't know whether anyone makes a motherboard > with that particular configuration), but that might be a good thing to HP. (opened one, last week). > look for. In any case, with only 4 SCSI busses, I doubt you'll be able > to get the full performance out of your disks, but maybe the performance > you will get will be enough. > > Here are some numbers to think about: > > IBM Ultrastar 18ES Peak performance: 20MB/sec > 48 * Ultrastar 18ES: 960MB/sec > 4 x Ultra2 LVD Wide SCSI busses: 320MB/sec > Gigabit Ethernet theoretical peak: 125MB/sec > 64-bit, 33MHz PCI: ~266MB/sec > > So, you've got a couple of bottlenecks here. The first is that the total > disk bandwidth you'll have is about 3 times the amount of SCSI bus > bandwidth you'll have available. > > The second is that your two 3950U2's together would be capable of flooding > a 33MHz 64-bit PCI bus. > > You'll also run into memory bandwidth issues, processor speed issues and > various other things. It'll certainly be an interesting experiment. > > What sort of performance are you trying to get out of this thing anyway? > 100x10Mb/s video stream. In fact, the OS is only there to drive a video super-astro-stuff that is fairly good at pumping data, but is too stupid to even know where video data blocks are. The OS will have the role of driving the process of deciding where to store data to reduce disks movements (aside other little tasks, like driking beers with users). Peak perfs are important here but not really critical as some stream-extensive operations can be driven externally by the video pump. From a pure performance POV, this is not really cutting-edge depending on a good access repartition algo (100x10Mb ~ 125MB/s ~ 31MB/chain) and adding chains is easy. Need only to keep things busy. Using this stuff as real filesystems is only a matter of benchmarking and fun experiments seeking for limits (hence the GigaEthernet). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 10:42: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id E3F4714CE9 for ; Tue, 13 Apr 1999 10:41:57 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id LAA03759; Tue, 13 Apr 1999 11:39:34 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904131739.LAA03759@panzer.plutotech.com> Subject: Re: Huge SCSI configs In-Reply-To: <199904131722.TAA36868@rt2.synx.com> from Remy Nonnenmacher at "Apr 13, 1999 7:22:19 pm" To: remy@synx.com Date: Tue, 13 Apr 1999 11:39:34 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Remy Nonnenmacher wrote... > On 13 Apr, Kenneth D. Merry wrote: > >> .... > >> OK. Sorry for this late (but ever unanswered question) : what are the > >> known limits in term of SCSI chains, number and size of disks and sizes > >> of filesystems ? Anyone ? > > > > Aww, come on, you can easily find out the SCSI stuff anywhere on the web. > > For Wide SCSI, you can have up to 15 devices on one chain. (SCSI IDs 0 > > through 15, with 7 reserved for the controller) With Ultra2 LVD, you can > > have cable lengths of up to 12 meters. > > > > Oops, lacked precision "under FreeBSD" !!. (I already proposed building > a MAX config (15*2*15*50G) but they had me stop by knocking my head ;). > No, seriously, i wouldn't like to find myself running honking into a > wall just for not having asked. Well, it's a good thing to ask! > >> Due to environmental constraints, there are two prefered drives : IBM > >> 18ES or Quantum Atlas4 all two 1 inches. > > > > Do yourself a favor and don't get the Atlas 4. So you need 1" high drives? > > > > Yes. 18G is the best tradeoff between perfs/thermal/#heads/stacking. > (BTW, I use Quantum and IBM and never got problems. Let me know if you > got some with Quantum). Yes, there are certainly problems with Quantum disks. The main problem is that they continually return Queue Full, until we reduce the number of transactions queued to the device to the minimum (2). We get around this problem in the Atlas 2 and 3 by setting the minimum number of transactions to 24. It would probably be better if you just avoid Quantum disks and go for IBM instead. > > And 50G drives would probably also be 1.6". > > > Da. (with ridiculous buffers 1M buffer where everybody is 2 and going > 4). > > > > I think you'll certainly want 64-bit PCI, and probably multiple PCI busses. > > I'm not sure whether you can get a 450NX box with two 64-bit PCI busses > > (the chipset is capable, I don't know whether anyone makes a motherboard > > with that particular configuration), but that might be a good thing to > HP. (opened one, last week). > > look for. In any case, with only 4 SCSI busses, I doubt you'll be able > > to get the full performance out of your disks, but maybe the performance > > you will get will be enough. > > > > Here are some numbers to think about: > > > > IBM Ultrastar 18ES Peak performance: 20MB/sec > > 48 * Ultrastar 18ES: 960MB/sec > > 4 x Ultra2 LVD Wide SCSI busses: 320MB/sec > > Gigabit Ethernet theoretical peak: 125MB/sec > > 64-bit, 33MHz PCI: ~266MB/sec > > > > So, you've got a couple of bottlenecks here. The first is that the total > > disk bandwidth you'll have is about 3 times the amount of SCSI bus > > bandwidth you'll have available. > > > > The second is that your two 3950U2's together would be capable of flooding > > a 33MHz 64-bit PCI bus. > > > > You'll also run into memory bandwidth issues, processor speed issues and > > various other things. It'll certainly be an interesting experiment. > > > > What sort of performance are you trying to get out of this thing anyway? > > > > 100x10Mb/s video stream. In fact, the OS is only there to drive a video > super-astro-stuff that is fairly good at pumping data, but is too stupid > to even know where video data blocks are. The OS will have the role of > driving the process of deciding where to store data to reduce disks > movements (aside other little tasks, like driking beers with users). > > Peak perfs are important here but not really critical as some > stream-extensive operations can be driven externally by the video pump. > > >From a pure performance POV, this is not really cutting-edge depending > on a good access repartition algo (100x10Mb ~ 125MB/s ~ 31MB/chain) and > adding chains is easy. Need only to keep things busy. Ahh, okay. So your performance requirements aren't too bad. You probably won't be able to get 100 10Mb/sec streams of video out of one Gigabit Ethernet interface, though. You'll probably want to divide it over two interfaces. > Using this stuff as real filesystems is only a matter of benchmarking > and fun experiments seeking for limits (hence the GigaEthernet). Certainly sounds interesting. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 10:53:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rt2.synx.com (tech.boostworks.com [194.167.81.239]) by hub.freebsd.org (Postfix) with ESMTP id 5503C157B6 for ; Tue, 13 Apr 1999 10:53:23 -0700 (PDT) (envelope-from root@synx.com) Received: from synx.com (rn.synx.com [192.1.1.241]) by rt2.synx.com (8.9.1/8.9.1) with ESMTP id TAA36976; Tue, 13 Apr 1999 19:50:52 +0200 (CEST) Message-Id: <199904131750.TAA36976@rt2.synx.com> Date: Tue, 13 Apr 1999 19:50:49 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@synx.com Subject: Re: Huge SCSI configs To: ken@plutotech.com Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <199904131739.LAA03759@panzer.plutotech.com> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13 Apr, Kenneth D. Merry wrote: > > Yes, there are certainly problems with Quantum disks. The main problem is > that they continually return Queue Full, until we reduce the number of > transactions queued to the device to the minimum (2). > > We get around this problem in the Atlas 2 and 3 by setting the minimum > number of transactions to 24. It would probably be better if you just > avoid Quantum disks and go for IBM instead. > Hiiirk. good queing is _required_. Okay Okay. Let's IBM....(also a personnal preference). >> >> >From a pure performance POV, this is not really cutting-edge depending >> on a good access repartition algo (100x10Mb ~ 125MB/s ~ 31MB/chain) and >> adding chains is easy. Need only to keep things busy. > > Ahh, okay. So your performance requirements aren't too bad. You probably > won't be able to get 100 10Mb/sec streams of video out of one Gigabit > Ethernet interface, though. You'll probably want to divide it over two > interfaces. > Video stream is took from the SCSI chain. The OS machine is only a one side. The GigaEthernet is only here for the fun.... > > Certainly sounds interesting. > As this machine will sit idling for one or two months, i though that it may be interesting to make it available for FS and drivers writers to stress it.... A low-cost contribution for those interested. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 12:36:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 4A96115180 for ; Tue, 13 Apr 1999 12:36:47 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id OAA08960; Tue, 13 Apr 1999 14:47:12 -0500 (CDT) From: Joe Greco Message-Id: <199904131947.OAA08960@aurora.sol.net> Subject: Re: Huge SCSI configs To: remy@synx.com, ken@plutotech.com, freebsd-scsi@FreeBSD.ORG Date: Tue, 13 Apr 1999 14:47:11 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I am looking for advices about building a fearly huge SCSI config. Yeah, that's fearly all right. :-) > > The config would be : > > > > - 4 SCSI chains (2x3950U2W planned) > > That should work okay, as long as you use -current or -stable *after* March > 23rd. I've got one in my test box, and it seems to work fine. I haven't > pushed it much, though. > > One thing to be careful about is what sort of slot you put this thing in. > If you get a motherboard with only 32-bit slots, you need to make sure that > the back end of the PCI slots is thin enough to handle a 64-bit PCI card. > > There was one machine that I tried to put my 3950 into that it wouldn't fit > in, because the back end of the slot was too thick. It worked fine in two > other machines, though. > > > - 12 18.2 GB per chain (48 totals disks) > > Well, first off, make sure you get IBM or Seagate, and make sure you get > one of their high end drives. (not that they're making low-end 18 gig > drives yet, AFAIK) I've had direct experience with the 18G Seagate > Cheetah II's and IBM Ultrastar 18XP's. They both work fine. My guess is > that the IBM Ultrastar 18ZX would work well, too. > > You should be okay with most any 18G IBM or Seagate disk. > > But 12 per chain? Assuming these are all Ultra2 LVD, you're still pushing > things a bit as far as SCSI bus bandwidth is concerned. For instance, the > IBM Ultrastar 18ZX runs at about 23MB/sec on the outer tracks according to > IBM's web site. > > With that sort of performance, you wouldn't be able to get maximum > performance out of the disks if had more than 3 on an Ultra 2 chain. Another thing to consider is data loss. Can you afford to lose a disk? I've been _very_ lucky with machines running 28-30 disks, simply CCD'd together. I think the drives are old enough that I should expect to have several fall-over-n-die's in the coming year on this one here. If you are more interested in reliability, consider getting a RAID controller. I've been playing with a Mylex DAC960SX myself, really slick unit, which I didn't expect since I've had bad experiences with media translators in the past. The thing just magically works and shows up as a disk to the OS. I don't have to worry about setting up CCD, making all those device nodes, etc. It just appears to be one big disk... da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 138928MB (284524544 512 byte sectors: 255H 63S/T 17710C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4148MB (8496884 512 byte sectors: 255H 63S/T 528C) I'm getting 10MB/s read/write speeds from it. I'd expect faster read speeds, but I think that is a matter of some tuning, and I've optimized it for parallel transactions anyways so maybe that is just fine. Yeah, there we go, on parallel processes I see the speed. tty da1 cpu tin tout KB/t tps MB/s us ni sy in id 0 64 64.00 396 24.75 0 0 2 2 97 0 115 64.00 393 24.57 0 0 2 2 96 0 21 64.00 395 24.69 0 0 2 4 94 0 1340 64.00 394 24.63 1 0 2 2 95 0 21 64.00 397 24.81 0 0 5 1 93 0 400 63.88 393 24.52 0 0 4 3 93 0 21 63.10 395 24.34 0 0 2 2 96 0 356 63.64 397 24.67 1 0 3 1 95 ^^!!!! I have no idea what is eating all that CPU. Heh. The machine in question is an ASUS P2B-DS with onboard SCSI, 512MB RAM, and 2x PII-400. The array is a dozen 18GB Seacrate Barracuda F/W's, two spare and ten participating in a RAID5 with all the parameters on the RAID controller loosened to the max. (Unfortunately, they are loosened in the direction of what I need for a news server, so this might not be an accurate picture of what the thing is actually capable of.) This simplifies server design greatly, because you can simply build a machine with one great SCSI controller and hook up a RAID controller and be done. If you need additional speed, you can always build it as two or four smaller independent arrays, I suppose. Now, obviously, if you need mega speed, this isn't the way to go. However, for some sort of network server, 25MB/s exceeds what you can put out on a 100Mbps Ethernet segment, and is a good percentage of what you could do with gigabit ethernet. Do you really need gigabit ethernet? Or would it be more sensible to do a quad-port 100Mbps ethernet card, a more tried and known technology? (I recommend the Adaptec ANA6944 myself). I'd reconsider what you are trying to accomplish, and then build a machine to fit. If it were me and I needed lots of read speed but could trade off write speed for additional availability, I'd build eight chains of 7 disks each, put two on each of four Mylex controllers, and then only have to worry about how to hook up four fast drive arrays to the PC. I've been satisfied with the performance afforded by the P2B-DS, but I'm not really moving a hundred megabytes of data per second around. A machine with lots of memory bandwidth would be ideal. You might be able to go with fewer Mylexes but I'm not too sure how far one can push them. FW SCSI is limited to 40MB/s, and if I'm doing 25 already, clearly there's a limit. But I think even with the suggested model above, you're probably going to have some Fun trying to deal with moving 100MB/s through most PC architecture machines. I'm waiting for the first person to tell me how you should be able to get 800MB/s++ out of such an array, heh... while the drives might be theoretically capable of it, the SCSI busses and PC just won't be able to deal with it. I'm just waiting for someone to come up with a driver for the new Fore ATM card, the ForeRunnerHE 622. I like the larger packet size I can do with ATM. :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 13:12:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (Postfix) with ESMTP id EEDDD14E0E for ; Tue, 13 Apr 1999 13:12:37 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id QAA03754; Tue, 13 Apr 1999 16:09:43 -0400 (EDT) Date: Tue, 13 Apr 1999 16:09:43 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: "Kenneth D. Merry" Cc: "Jason K. Fritcher" , freebsd-scsi@FreeBSD.ORG Subject: Re: Boot-time scsi probe problem In-Reply-To: <199903160625.XAA23822@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I haven't read the list in a while, but I just started putting 3.1-REL on a new news machine with an ASUS-P2B-LS mobo. It has the internal 7890 and a 2940-U2W card as well. I get the exact same results with about one in five warm boots. Is there any more news on this problem? Some info I haven't seen posted before follows: 7890 bios version: 2.01 2940-U2W bios version: 2.01.0 'boot -v' shows the hang right after trying to talk to the first target after the "waiting for scsi devices to settle" message. Since I wrote it all down, I'll share... (noperiph:ahc0:0:-1:-1): scsi bus reset delivered 0 SCBs aborted (noperiph:ahc1:0:-1:-1): scsi bus reset delivered 0 SCBs aborted ahc1: Selection Timeout on A:3. 1 SCB aborted ahc0: Selection Timeout on A:5. 1 SCB aborted *(this repeats, alternating from one controller to another with a random number appearing each time after the "A:") ahc0: target 0 using 16 bit transfers ahc0: target 0 synchronous at 20.0 MHz, offset=0xf That's it. Each time the target may be different, but it always hangs right after the first "target" message and always on ahc0, which is the built-in 7890. I also didn't see the problem until I compiled my own kernel. After many reboots on the generic kernel I never saw this. thanks, Charles --- Charles Sprickman spork@super-g.com --- "...there's no idea that's so good you can't ruin it with a few well-placed idiots." On Mon, 15 Mar 1999, Kenneth D. Merry wrote: > Jason K. Fritcher wrote... > > > > Hello. I am trying to get FreeBSD 3.1-Stable to boot reliably on a machine I > > have. It was cvsup'ed from Sunday night about 11pm or so. The system was > > originally installed with the 3.1-19990227 snapshot. I can somewhat reliably > > boot from the generic kernel included with the snapshot, but I can not boot > > at all with a kernel compiled from the cvsup. The problems I am having are > > this. When booting with the generic kernel, the system will boot all the way > > through if I power-cycle the machine, or reboot it with the reset boot, > > basically a cold-boot. If I reboot the machine with a warm boot, ie > > Ctrl-Alt-Del, the system will lockup when it tries to probe the scsi bus for > > devices. It will wait the 15 seconds for things to settle, and then it locks > > one the probe starts. I am forced to use the reset button to restart it. > > > > With the new kernel, when the machine gets to the probe, it does not lock > > up, but the probe doesn't work either. It sits there for a few, and then > > starts giving error messages about timeouts. At the end of the message I > > have included the entire boot sequence for reference. > > > > The hardware I have ia an Asus P2B-LS motherboard with onboard AIC-7890 SCSI > > controller + 3860 bridge. For those not familiar with the P2B-LS, the SCSI > > bus is divided into three segments, a U2W, UW, and UN buses. On the U2W bus > > I have a Quantum Viking II 9.1 GB hard drive in LVD mode, on the UW bus is > > nothing but a terminator, and on the UN bus is a Plextor 40x cdrom drive. > > The hard drive is scsi id 0, and the cdrom is scsi id 6. > > > > After looking through the archives for anything similar, I came across > > similar problems which were caused by termination problems. I have checked > > the termination and all seems well. > > > > Any suggestions about what the cause could and possible solutions would be > > much appriciated. I have spent a good 4-5 hours compiling kernels with > > different options, and reading through list archives to try and solve this > > problem. If there is any more information that anyone needs, or have > > questions, please, write me and I will do what I can. > > This sounds and looks like a known problem with the Adaptec 7890 chips. A > number of people have reported this. > > Justin has reproduced the problem (with a lot of help from Tor Egge) and > has a PCI bus trace showing the problem. > > He said that there may be a bug in the 7890 that causes it to hang in > certain circumstances; he has mailed Adaptec asking for information. > > Since he's not in town at the moment, I wouldn't expect any response from > him on this for a few days. > > I suggest that you stick with the kernel that boots for now, if you can. > The hang seems to be timing related in some way, so you might get different > results if you stick your hard disk on the Ultra-Wide bus instead of the > Ultra-2 bus. Hopefully Justin will be able to come up with a fix for it > before too long. > > You also may want to subscribe to the -scsi list, there's a lot less noise > on this list than on many of the other FreeBSD lists. (for now, at least) > > Ken > -- > Kenneth Merry > ken@plutotech.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 13:19:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id BD6D114E8A for ; Tue, 13 Apr 1999 13:19:38 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 88821 invoked by uid 1001); 13 Apr 1999 20:17:17 +0000 (GMT) To: jgreco@ns.sol.net Cc: remy@synx.com, ken@plutotech.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Huge SCSI configs From: sthaug@nethelp.no In-Reply-To: Your message of "Tue, 13 Apr 1999 14:47:11 -0500 (CDT)" References: <199904131947.OAA08960@aurora.sol.net> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 13 Apr 1999 22:17:17 +0200 Message-ID: <88819.924034637@verdi.nethelp.no> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm just waiting for someone to come up with a driver for the new Fore ATM > card, the ForeRunnerHE 622. I like the larger packet size I can do with > ATM. :-) On the other hand, with the Alteon based card you can do jumbo frames too, at a fraction of the cost. (My Netgear GA620 Gigabit Ethernet card bought from the US ended up at almost exactly one tenth of the price of a HE622 from the Fore vendor here in Norway. YMMV) Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 13:20:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id D9C2414CED for ; Tue, 13 Apr 1999 13:20:20 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA04551; Tue, 13 Apr 1999 14:16:57 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904132016.OAA04551@panzer.plutotech.com> Subject: Re: Boot-time scsi probe problem In-Reply-To: from spork at "Apr 13, 1999 4: 9:43 pm" To: spork@super-g.com (spork) Date: Tue, 13 Apr 1999 14:16:57 -0600 (MDT) Cc: jkf@wolfnet.org, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org spork wrote... > I haven't read the list in a while, but I just started putting 3.1-REL on > a new news machine with an ASUS-P2B-LS mobo. It has the internal 7890 and > a 2940-U2W card as well. I get the exact same results with about one in > five warm boots. > > Is there any more news on this problem? Some info I haven't seen posted > before follows: > > 7890 bios version: 2.01 > 2940-U2W bios version: 2.01.0 > > 'boot -v' shows the hang right after trying to talk to the first target > after the "waiting for scsi devices to settle" message. Since I wrote it > all down, I'll share... It's generally a good idea to read the -scsi list. > (noperiph:ahc0:0:-1:-1): scsi bus reset delivered 0 SCBs aborted > (noperiph:ahc1:0:-1:-1): scsi bus reset delivered 0 SCBs aborted > ahc1: Selection Timeout on A:3. 1 SCB aborted > ahc0: Selection Timeout on A:5. 1 SCB aborted > *(this repeats, alternating from one controller to another with a random > number appearing each time after the "A:") > ahc0: target 0 using 16 bit transfers > ahc0: target 0 synchronous at 20.0 MHz, offset=0xf > > That's it. Each time the target may be different, but it always hangs > right after the first "target" message and always on ahc0, which is the > built-in 7890. > > I also didn't see the problem until I compiled my own kernel. After many > reboots on the generic kernel I never saw this. It's a timing issue of some sort. Try a -stable snapshot from *after* March 23rd, and you should be able to boot fairly regularly. The problem hasn't been fixed, but Justin committed a work-around that seems to eliminate it most of the time. I don't think he has heard anything back from Adaptec on the problem yet. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 13:23:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by hub.freebsd.org (Postfix) with ESMTP id 9EFDF1537B; Tue, 13 Apr 1999 13:23:35 -0700 (PDT) (envelope-from se@dialup124.zpr.uni-koeln.de) Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by Sisyphos.MI.Uni-Koeln.DE (8.8.7/8.8.7) with ESMTP id WAA24219; Tue, 13 Apr 1999 22:21:14 +0200 (MET DST) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.6.9) id NAA00473; Tue, 13 Apr 1999 13:52:09 +0200 (CEST) Date: Tue, 13 Apr 1999 13:52:09 +0200 From: Stefan Esser To: patl@phoenix.volant.org Cc: freebsd-scsi@freebsd.org, Stefan Esser Subject: Re: Seagate ST15230 wedging Message-ID: <19990413135209.B309@dialup124.mi.uni-koeln.de> Reply-To: se@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from patl@phoenix.volant.org on Mon, Apr 12, 1999 at 09:04:01AM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1999-04-12 09:04 -0700, patl@phoenix.volant.org wrote: > Do any of you have any experience with Seagate ST15230 drives? > I have one that occasionally wedges when backing up to tape. The > wedge spews: > > sd1(ncr1:1:0): Vendor Specific asc:80,0 Vendor Specific ASC > field replaceable unit: 1 Well, that's a vendor specific return code. You may have to ask your vendor. > I've no idea what that message means, except that I can't access the > disk and have to power-cycle to reset it. (Well, actually, it might > reset with a simple reboot. But I figure I may as well power-cycle > just to be sure.) Are there other error messages from the SCSI sub-system ? Do other SCSI devices continue to work ? > It's on a system that, for various reasons, is still running FreeBSD > 2.2.2, and will be for a little while yet unless I find some urgent > reason to upgrade. (Such as someone assuring me that later drivers > for the NCR 53c585 fix it.) No, sorry, that's not a driver problem, I'm sure. (The SCSI command was executed to the end, and the ASC/ASCQ values obtained through a separate SCSI command, after the drive returned an error status.) But you may try to disable tagged commands, or to lower the synchronous data rate, just to see whether that makes a difference. The problem you report could even be caused by the power supply, which may not be able to deliver sufficient current at 12V (assuming your tape drive motor runs on 12V, as do the mechanical parts of the disk drive). Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 13:34:49 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 6C32114C8E for ; Tue, 13 Apr 1999 13:34:43 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id PAA13072; Tue, 13 Apr 1999 15:45:32 -0500 (CDT) From: Joe Greco Message-Id: <199904132045.PAA13072@aurora.sol.net> Subject: Re: Huge SCSI configs In-Reply-To: <88819.924034637@verdi.nethelp.no> from "sthaug@nethelp.no" at "Apr 13, 1999 10:17:17 pm" To: sthaug@nethelp.no Date: Tue, 13 Apr 1999 15:45:32 -0500 (CDT) Cc: freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I'm just waiting for someone to come up with a driver for the new Fore ATM > > card, the ForeRunnerHE 622. I like the larger packet size I can do with > > ATM. :-) > > On the other hand, with the Alteon based card you can do jumbo frames too, > at a fraction of the cost. (My Netgear GA620 Gigabit Ethernet card bought > from the US ended up at almost exactly one tenth of the price of a HE622 > from the Fore vendor here in Norway. YMMV) My apologies for this non-SCSI discussion, but... This doesn't seem odd. However, 155Mbps ATM is roughly the equal of 100Mbps Ethernet, allows 9180-byte packets, runs over WAN links, and integrates nicely into an existing ATM network. The cost on the server side is important, but it is easy to justify 1x most costs. Getting the benefit on the client side for a reasonable price, well, that's interesting. :-) (Ask Fore for pricing on their UTP 155Mbps ATM cards when purchased along with a workgroup ATM switch...) Not that I'm actually in the market to build a machine with OC-12 speed capability, but if I did, that's why I'd probably consider ATM as a serious choice. Ethernet may win in the long run, just because it is so... commodity. But right now the ATM stuff is out there, works, and switches at the advertised speeds. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 13:40:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 9066114E4A for ; Tue, 13 Apr 1999 13:40:30 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id UAA01696; Mon, 12 Apr 1999 20:58:42 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199904130358.UAA01696@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: remy@synx.com Cc: freebsd-scsi@freebsd.org Subject: Re: Huge SCSI configs In-reply-to: Your message of "Mon, 12 Apr 1999 20:04:31 +0200." <199904121804.UAA30722@rt2.synx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Apr 1999 20:58:42 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I am looking for advices about building a fearly huge SCSI config. > > The config would be : > > - 4 SCSI chains (2x3950U2W planned) > - 12 18.2 GB per chain (48 totals disks) > - one Gigabit ethernet link > - SMP (Quad-Xeon or Bi-P2) > > Advices wanted (do/don't). Depending on how you plan to organise the disks, you might want to look at using some external RAID controllers to cluster the disks (and provide some redundancy in the event of failure). Apart from that, it ought to work OK. SMP may or may not help you, depending on the application. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 15:14:36 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id CE37814CBE; Tue, 13 Apr 1999 15:14:29 -0700 (PDT) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) id 10XBPe-0000dQ-00; Tue, 13 Apr 1999 15:12:10 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id PAA15386; Tue, 13 Apr 1999 15:12:06 -0700 Date: Tue, 13 Apr 1999 15:12:05 -0700 (PDT) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Re: Seagate ST15230 wedging To: se@freebsd.org Cc: freebsd-scsi@freebsd.org, Stefan Esser In-Reply-To: <19990413135209.B309@dialup124.mi.uni-koeln.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13-Apr-99 at 13:21, Stefan Esser (se@mi.uni-koeln.de) wrote: > On 1999-04-12 09:04 -0700, patl@phoenix.volant.org wrote: > > Do any of you have any experience with Seagate ST15230 drives? > > I have one that occasionally wedges when backing up to tape. The > > wedge spews: > > > > sd1(ncr1:1:0): Vendor Specific asc:80,0 Vendor Specific ASC > > field replaceable unit: 1 > > Well, that's a vendor specific return code. > You may have to ask your vendor. The first time this happened, I went grovelling through their Web site; but didn't find anything relevant. I have a cynical expectation that attempts to get the info from a tech support person will be rather frustrating. But it's beginning to look like I'll have to try. But first, another check of their Web site... Ah, it looks like they have quite a lot more available on-line now. But I still can't find anything that looks like 'ASC' or 'Error Code' - are there any other terms they might be using for this? > > I've no idea what that message means, except that I can't access the > > disk and have to power-cycle to reset it. (Well, actually, it might > > reset with a simple reboot. But I figure I may as well power-cycle > > just to be sure.) > > Are there other error messages from the SCSI > sub-system ? Nope. > Do other SCSI devices continue to work ? Yep. The other disk on that controller still responds normally. (The tape and an ancient CD-ROM changer are on a separate controller.) > > It's on a system that, for various reasons, is still running FreeBSD > > 2.2.2, and will be for a little while yet unless I find some urgent > > reason to upgrade. (Such as someone assuring me that later drivers > > for the NCR 53c585 fix it.) > > No, sorry, that's not a driver problem, I'm sure. > (The SCSI command was executed to the end, and the > ASC/ASCQ values obtained through a separate SCSI > command, after the drive returned an error status.) Hmm. I was kind of hoping that maybe the drivers weren't properly handling the error. Which implied the hope that there would be some sort of soft reset that would clear the problem... > But you may try to disable tagged commands, or to > lower the synchronous data rate, just to see whether > that makes a difference. > > The problem you report could even be caused by the > power supply, which may not be able to deliver > sufficient current at 12V (assuming your tape drive > motor runs on 12V, as do the mechanical parts of the > disk drive). The tape drive is an external unit with its own power supply. I don't think it plays an integral part in the problem. But the backup is about the only time that this system experiences extended periods of heavy disk activity. Note that this drive holds the Amanda buffer area for the backups of the partitions on the other drive; so there would be both heavy read and write activity. And it sometimes overlaps with the find in the nightly security script. Note that these wedges don't happen every time. It can be months between them, or only days. I don't believe it has ever happened twice in a row; but if it is related to the (duration of the) load, that may be an effect of Amanda's choice of full or incremental backup. -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 16:20:53 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from stampede.cs.berkeley.edu (stampede.CS.Berkeley.EDU [128.32.45.124]) by hub.freebsd.org (Postfix) with ESMTP id 207A114C85 for ; Tue, 13 Apr 1999 16:20:45 -0700 (PDT) (envelope-from asami@cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca14-50.ix.netcom.com [205.186.215.50]) by stampede.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id QAA15275; Tue, 13 Apr 1999 16:18:46 -0700 (PDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.2/8.6.9) id QAA49274; Tue, 13 Apr 1999 16:18:04 -0700 (PDT) Date: Tue, 13 Apr 1999 16:18:04 -0700 (PDT) Message-Id: <199904132318.QAA49274@silvia.hip.berkeley.edu> X-Authentication-Warning: silvia.hip.berkeley.edu: asami set sender to asami@cs.berkeley.edu using -f To: ken@plutotech.com Cc: scsi@FreeBSD.ORG In-reply-to: <199904131623.KAA03308@panzer.plutotech.com> (ken@plutotech.com) Subject: Re: timed out while idle? From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) References: <199904131623.KAA03308@panzer.plutotech.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * From: "Kenneth D. Merry" * The timed out while idle message means that the drive took longer than the * timeout (60 seconds) to respond to a read or write request, and nothing was * going on on the bus at the time. In other words, your drive went out to * lunch, and we hit it with a BDR to get it to come back. Wow, 60 seconds? That's indeed a pretty good lunch. :) * Yep. There's a timeout for each transaction. If the transaction doesn't * complete in the specified period of time (60 seconds for disk * reads/writes), the timeout fires, a BDR is sent and all transactions that * were queued to the disk are requeued. I see. By the way, can any of these cause panics? Here's an example: === Mar 31 08:46:29 m0 /kernel: (da14:ahc0:0:14:0): SCB 0x31 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Mar 31 08:46:30 m0 /kernel: SEQADDR == 0x8 Mar 31 08:46:30 m0 /kernel: SSTAT1 == 0xa Mar 31 08:46:30 m0 /kernel: (da14:ahc0:0:14:0): Queuing a BDR SCB Mar 31 08:46:30 m0 /kernel: (da14:ahc0:0:14:0): Bus Device Reset Message Sent Mar 31 08:46:30 m0 /kernel: (da14:ahc0:0:14:0): no longer in timeout, status = 34b Mar 31 08:46:30 m0 /kernel: ahc0: Bus Device Reset on A:14. 1 SCBs aborted Mar 31 08:47:33 m0 /kernel: (da10:ahc0:0:10:0): SCB 0x23 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Mar 31 08:47:33 m0 /kernel: SEQADDR == 0x8 Mar 31 08:47:33 m0 /kernel: SSTAT1 == 0xa Mar 31 08:47:33 m0 /kernel: (da10:ahc0:0:10:0): Queuing a BDR SCB Mar 31 08:47:33 m0 /kernel: (da10:ahc0:0:10:0): Bus Device Reset Message Sent Mar 31 08:47:33 m0 /kernel: (da10:ahc0:0:10:0): no longer in timeout, status = 34b Mar 31 08:47:33 m0 /kernel: ahc0: Bus Device Reset on A:10. 1 SCBs aborted Mar 31 09:09:00 m0 /kernel: (da10:ahc0:0:10:0): SCB 0x31 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Mar 31 09:09:01 m0 /kernel: SEQADDR == 0x8 Mar 31 09:09:01 m0 /kernel: SSTAT1 == 0xa Mar 31 09:09:01 m0 /kernel: (da10:ahc0:0:10:0): Queuing a BDR SCB Mar 31 09:09:01 m0 /kernel: (da10:ahc0:0:10:0): Bus Device Reset Message Sent Mar 31 09:09:01 m0 /kernel: (da10:ahc0:0:10:0): no longer in timeout, status = 34b Mar 31 09:09:01 m0 /kernel: ahc0: Bus Device Reset on A:10. 1 SCBs aborted Mar 31 09:33:07 m0 /kernel: (da2:ahc0:0:2:0): SCB 0x31 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 Mar 31 09:33:07 m0 /kernel: SEQADDR == 0x8 Mar 31 09:33:07 m0 /kernel: SSTAT1 == 0xa Mar 31 09:33:07 m0 /kernel: (da2:ahc0:0:2:0): Queuing a BDR SCB Mar 31 09:33:07 m0 /kernel: (da2:ahc0:0:2:0): Bus Device Reset Message Sent Mar 31 09:33:07 m0 /kernel: (da2:ahc0:0:2:0): no longer in timeout, status = 34b Mar 31 09:33:07 m0 /kernel: ahc0: Bus Device Reset on A:2. 1 SCBs aborted === which leads to a panic a few minutes later: === ## gdb -aout -k *.67 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... IdlePTD 2334720 initial pcb at 215ba8 panicstr: integer divide fault panic messages: --- Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x8:0xf011c3c6 stack pointer = 0x10:0xf4f74c84 frame pointer = 0x10:0xf4f74cbc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13423 (md5) interrupt mask = bio trap number = 18 panic: integer divide fault syncing disks... 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 giving up dumping to dev 1, offset 853068 dump 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xf0134b0b in boot () (kgdb) bt #0 0xf0134b0b in boot () #1 0xf0134e27 in panic () #2 0xf01e606d in trap_fatal () #3 0xf01e588a in trap () #4 0xf011c3c6 in ccdbuffer () #5 0xf011c204 in ccdstart () #6 0xf011c184 in ccdstrategy () #7 0xf01625f2 in spec_strategy () #8 0xf0161d29 in spec_vnoperate () #9 0xf01cac65 in ufs_vnoperatespec () #10 0xf01ca63f in ufs_strategy () #11 0xf01cac35 in ufs_vnoperate () #12 0xf0152c6d in cluster_read () #13 0xf01c3765 in ffs_read () #14 0xf015c211 in vn_read () #15 0xf013d3a9 in read () #16 0xf01e629f in syscall () #17 0xf01dc56c in Xint0x80_syscall () #18 0x80481c8 in ?? () #19 0x80480ca in ?? () === Hmm, so it's dying in ccdbuffer. Integer divide fault...divide by zero? I looked in ccdbuffer(), but the only divisions are by cs->sc_ileave or ii->ii_ndisk (we're using simple striping), I don't see how this could possibly cause integer divide faults.... * Those are SCSI bus phases. If you're seeing timeouts in datain phase or * command phase, that often indicates a termination or cabling problem. * * Just look at the SCSI specs if you want to find out about the different * SCSI bus phases. Oh yes, the SCSI specs. That was my other question. ;) There used to be SCSI specs on-line at http://scitexdv.com:8080/SCSI2/ but it doesn't seem to exist anymore. Do you know of some other place? (I did a little search but couldn't find any....) Thanks Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 16:28: 3 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id EBCF6150C4; Tue, 13 Apr 1999 16:27:54 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id RAA05814; Tue, 13 Apr 1999 17:25:34 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904132325.RAA05814@panzer.plutotech.com> Subject: Re: timed out while idle? In-Reply-To: <199904132318.QAA49274@silvia.hip.berkeley.edu> from Satoshi - Ports Wraith - Asami at "Apr 13, 1999 4:18: 4 pm" To: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Date: Tue, 13 Apr 1999 17:25:34 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Satoshi - Ports Wraith - Asami wrote... > * From: "Kenneth D. Merry" > > * The timed out while idle message means that the drive took longer than the > * timeout (60 seconds) to respond to a read or write request, and nothing was > * going on on the bus at the time. In other words, your drive went out to > * lunch, and we hit it with a BDR to get it to come back. > > Wow, 60 seconds? That's indeed a pretty good lunch. :) Yep. > * Yep. There's a timeout for each transaction. If the transaction doesn't > * complete in the specified period of time (60 seconds for disk > * reads/writes), the timeout fires, a BDR is sent and all transactions that > * were queued to the disk are requeued. > > I see. By the way, can any of these cause panics? Here's an example: I don't think the timeouts in and of themselves will cause panics, unless maybe the drive never recovers. > === > Mar 31 08:46:29 m0 /kernel: (da14:ahc0:0:14:0): SCB 0x31 - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 > Mar 31 08:46:30 m0 /kernel: SEQADDR == 0x8 > Mar 31 08:46:30 m0 /kernel: SSTAT1 == 0xa > Mar 31 08:46:30 m0 /kernel: (da14:ahc0:0:14:0): Queuing a BDR SCB > Mar 31 08:46:30 m0 /kernel: (da14:ahc0:0:14:0): Bus Device Reset Message Sent > Mar 31 08:46:30 m0 /kernel: (da14:ahc0:0:14:0): no longer in timeout, status = 34b > Mar 31 08:46:30 m0 /kernel: ahc0: Bus Device Reset on A:14. 1 SCBs aborted [ ... ] > > which leads to a panic a few minutes later: > > === > ## gdb -aout -k *.67 > GDB is free software and you are welcome to distribute copies of it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.16 (i386-unknown-freebsd), > Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... > IdlePTD 2334720 > initial pcb at 215ba8 > panicstr: integer divide fault > panic messages: > --- > Fatal trap 18: integer divide fault while in kernel mode > instruction pointer = 0x8:0xf011c3c6 > stack pointer = 0x10:0xf4f74c84 > frame pointer = 0x10:0xf4f74cbc > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 13423 (md5) > interrupt mask = bio > trap number = 18 > panic: integer divide fault > > syncing disks... 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 giving up > > dumping to dev 1, offset 853068 > dump 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 > --- > #0 0xf0134b0b in boot () > (kgdb) bt > #0 0xf0134b0b in boot () > #1 0xf0134e27 in panic () > #2 0xf01e606d in trap_fatal () > #3 0xf01e588a in trap () > #4 0xf011c3c6 in ccdbuffer () > #5 0xf011c204 in ccdstart () > #6 0xf011c184 in ccdstrategy () > #7 0xf01625f2 in spec_strategy () > #8 0xf0161d29 in spec_vnoperate () > #9 0xf01cac65 in ufs_vnoperatespec () > #10 0xf01ca63f in ufs_strategy () > #11 0xf01cac35 in ufs_vnoperate () > #12 0xf0152c6d in cluster_read () > #13 0xf01c3765 in ffs_read () > #14 0xf015c211 in vn_read () > #15 0xf013d3a9 in read () > #16 0xf01e629f in syscall () > #17 0xf01dc56c in Xint0x80_syscall () > #18 0x80481c8 in ?? () > #19 0x80480ca in ?? () > === > > Hmm, so it's dying in ccdbuffer. Integer divide fault...divide by > zero? I looked in ccdbuffer(), but the only divisions are by > cs->sc_ileave or ii->ii_ndisk (we're using simple striping), I don't > see how this could possibly cause integer divide faults.... I dunno what's going on there. It could be indirectly caused by the timeout, but I really don't know how that could happen. > * Those are SCSI bus phases. If you're seeing timeouts in datain phase or > * command phase, that often indicates a termination or cabling problem. > * > * Just look at the SCSI specs if you want to find out about the different > * SCSI bus phases. > > Oh yes, the SCSI specs. That was my other question. ;) > > There used to be SCSI specs on-line at > > http://scitexdv.com:8080/SCSI2/ > > but it doesn't seem to exist anymore. Do you know of some other > place? (I did a little search but couldn't find any....) Try: http://www.symbios.com/x3t10/ Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 18: 3:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from stampede.cs.berkeley.edu (stampede.CS.Berkeley.EDU [128.32.45.124]) by hub.freebsd.org (Postfix) with ESMTP id 628861507B for ; Tue, 13 Apr 1999 18:03:23 -0700 (PDT) (envelope-from asami@cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca14-50.ix.netcom.com [205.186.215.50]) by stampede.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id SAA15490; Tue, 13 Apr 1999 18:01:06 -0700 (PDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.2/8.6.9) id RAA49792; Tue, 13 Apr 1999 17:59:32 -0700 (PDT) Date: Tue, 13 Apr 1999 17:59:32 -0700 (PDT) Message-Id: <199904140059.RAA49792@silvia.hip.berkeley.edu> X-Authentication-Warning: silvia.hip.berkeley.edu: asami set sender to asami@cs.berkeley.edu using -f To: ken@plutotech.com Cc: scsi@FreeBSD.ORG In-reply-to: <199904132325.RAA05814@panzer.plutotech.com> (ken@plutotech.com) Subject: Re: timed out while idle? From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) References: <199904132325.RAA05814@panzer.plutotech.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * From: "Kenneth D. Merry" * > Wow, 60 seconds? That's indeed a pretty good lunch. :) * * Yep. Do you think it's a bad idea to reduce it to something like 15 seconds? Not that it matters much but the disk reads pretty much stall during that time, and if it's not going to catch any false positives, I'd like them to recover faster. Is there some way to find out if there's something that came back after 15 seconds but before 60? * I don't think the timeouts in and of themselves will cause panics, unless * maybe the drive never recovers. How do I find out if the drive recovered? * I dunno what's going on there. It could be indirectly caused by the * timeout, but I really don't know how that could happen. Next time I'll try to catch it with a debug kernel. * http://www.symbios.com/x3t10/ Great. Thanks! Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 18:25: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 20F3A14E5A; Tue, 13 Apr 1999 18:24:53 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id TAA06901; Tue, 13 Apr 1999 19:22:33 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904140122.TAA06901@panzer.plutotech.com> Subject: Re: timed out while idle? In-Reply-To: <199904140059.RAA49792@silvia.hip.berkeley.edu> from Satoshi - Ports Wraith - Asami at "Apr 13, 1999 5:59:32 pm" To: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Date: Tue, 13 Apr 1999 19:22:33 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Satoshi - Ports Wraith - Asami wrote... > * From: "Kenneth D. Merry" > > * > Wow, 60 seconds? That's indeed a pretty good lunch. :) > * > * Yep. > > Do you think it's a bad idea to reduce it to something like 15 > seconds? Not that it matters much but the disk reads pretty much > stall during that time, and if it's not going to catch any false > positives, I'd like them to recover faster. Is there some way to find > out if there's something that came back after 15 seconds but before > 60? The reason the timeout is as high is it is now is because of some devices (zip drives?) that spin down their media and then spin back up when they get a command. It takes them a little bit to spin up, so that's why the timeout is as long as it is. As far as figuring out whether something came back between 15 and 60 seconds, probably the only way to do that would be to timestamp each CCB as it is sent down to the controller. It can be done, but is it really worth it? > * I don't think the timeouts in and of themselves will cause panics, unless > * maybe the drive never recovers. > > How do I find out if the drive recovered? If it is still responding. In most cases that I've seen a BDR will cause the drive to wake up and start functioning again. > * I dunno what's going on there. It could be indirectly caused by the > * timeout, but I really don't know how that could happen. > > Next time I'll try to catch it with a debug kernel. That'll be more helpful. At least you'll be able to (hopefully) see exactly which line caused the panic. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 18:56:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from stampede.cs.berkeley.edu (stampede.CS.Berkeley.EDU [128.32.45.124]) by hub.freebsd.org (Postfix) with ESMTP id 89C6714C10 for ; Tue, 13 Apr 1999 18:56:41 -0700 (PDT) (envelope-from asami@cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca14-50.ix.netcom.com [205.186.215.50]) by stampede.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id SAA15566; Tue, 13 Apr 1999 18:54:47 -0700 (PDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.2/8.6.9) id SAA53879; Tue, 13 Apr 1999 18:54:04 -0700 (PDT) Date: Tue, 13 Apr 1999 18:54:04 -0700 (PDT) Message-Id: <199904140154.SAA53879@silvia.hip.berkeley.edu> X-Authentication-Warning: silvia.hip.berkeley.edu: asami set sender to asami@cs.berkeley.edu using -f To: ken@plutotech.com Cc: scsi@FreeBSD.ORG In-reply-to: <199904140122.TAA06901@panzer.plutotech.com> (ken@plutotech.com) Subject: Re: timed out while idle? From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) References: <199904140122.TAA06901@panzer.plutotech.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * From: "Kenneth D. Merry" * The reason the timeout is as high is it is now is because of some devices * (zip drives?) that spin down their media and then spin back up when they * get a command. * * It takes them a little bit to spin up, so that's why the timeout is as long * as it is. I see. * As far as figuring out whether something came back between 15 and 60 * seconds, probably the only way to do that would be to timestamp each CCB as * it is sent down to the controller. It can be done, but is it really worth * it? No, I was just curious if I can know if it's safe to shorten in on our site. I guess I can just try and see. * If it is still responding. In most cases that I've seen a BDR will cause * the drive to wake up and start functioning again. Sorry, I meant by analyzing the logs. I guess I don't know what happened if I just see a "timed out while idle" followed by a crash.... Speaking of which (gosh, you should hate this), I have another question. When CAM invalidates a pack, is there some way to get it back short of rebooting? I tried "camcontrol rescan" which does seem to find it (judging from "camcontrol devlist") but I still can't access it ("device not configured"). * That'll be more helpful. At least you'll be able to (hopefully) see exactly * which line caused the panic. Ok. Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 19:33:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 2340814BD2; Tue, 13 Apr 1999 19:33:37 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id UAA07250; Tue, 13 Apr 1999 20:31:18 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904140231.UAA07250@panzer.plutotech.com> Subject: Re: timed out while idle? In-Reply-To: <199904140154.SAA53879@silvia.hip.berkeley.edu> from Satoshi - Ports Wraith - Asami at "Apr 13, 1999 6:54: 4 pm" To: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Date: Tue, 13 Apr 1999 20:31:18 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Satoshi - Ports Wraith - Asami wrote... > * From: "Kenneth D. Merry" > > * The reason the timeout is as high is it is now is because of some devices > * (zip drives?) that spin down their media and then spin back up when they > * get a command. > * > * It takes them a little bit to spin up, so that's why the timeout is as long > * as it is. > > I see. > > * As far as figuring out whether something came back between 15 and 60 > * seconds, probably the only way to do that would be to timestamp each CCB as > * it is sent down to the controller. It can be done, but is it really worth > * it? > > No, I was just curious if I can know if it's safe to shorten in on our > site. I guess I can just try and see. Yeah, I think you can safely do that. You may be able to get away with cranking it down to 10 seconds or so. > * If it is still responding. In most cases that I've seen a BDR will cause > * the drive to wake up and start functioning again. > > Sorry, I meant by analyzing the logs. I guess I don't know what > happened if I just see a "timed out while idle" followed by a > crash.... Right, it's hard to say how the rest of the system will respond. Sometimes, if it happens on your swap drive, you'll see something that goes like "swap_pager: indefinite wait buffer" or something like that. > Speaking of which (gosh, you should hate this), I have another > question. When CAM invalidates a pack, is there some way to get it > back short of rebooting? I tried "camcontrol rescan" which does seem > to find it (judging from "camcontrol devlist") but I still can't > access it ("device not configured"). There's no way to get it back without rebooting. Rescanning won't help you, since that finds devices that have appeared, changed or gone away. Your device hasn't done that, it has stopped responding. It's dead. If you think it should be done otherwise, talk to the author of the da(4) driver. :) (no, it's not me) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 20: 8:18 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from hal-pc.org (hal-pc.org [204.52.135.1]) by hub.freebsd.org (Postfix) with ESMTP id 7BA2814E58 for ; Tue, 13 Apr 1999 20:08:15 -0700 (PDT) (envelope-from jes@hal-pc.org) Received: from jason (206.180.128.42.dial-ip.hal-pc.org [206.180.128.42]) by hal-pc.org (8.9.1/8.9.0) with SMTP id WAA15227; Tue, 13 Apr 1999 22:05:54 -0500 (CDT) Message-ID: <023801be8623$40608fc0$0500a8c0@local.nullifier.dyn.ml.org> From: "Jason" To: Cc: Subject: Tagged queueing problem with Seagate drive Date: Tue, 13 Apr 1999 22:02:35 -0500 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.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a Seagate ST410080N that basically reports itself as a SX410080N and thus the ST410080* quirk entry doesn't catch it. It typically needs a hard reset after locking up after reducing tags 1-3 from 64. The drive is alone on the SCSI bus and properly terminated. I currently don't have any error messages from when the drive locks up, though the typical sense code is 0x151. relevant dmesg bits: . . . ahc0: rev 0x00 int a irq 11 on pci0.18.0 ahc0: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs . . . da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15) da0: 8347MB (17096357 512 byte sectors: 64H 32S/T 8347C) . . . I've put a quick quirk entry for this drive with tags reduced to 32, and so far, haven't had any problems, though I haven't tried any other settings to test performance. - Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 21:17: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id E5CF514E57 for ; Tue, 13 Apr 1999 21:16:57 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id WAA00786; Tue, 13 Apr 1999 22:14:27 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904140414.WAA00786@panzer.plutotech.com> Subject: Re: Tagged queueing problem with Seagate drive In-Reply-To: <023801be8623$40608fc0$0500a8c0@local.nullifier.dyn.ml.org> from Jason at "Apr 13, 1999 10: 2:35 pm" To: jes@hal-pc.org (Jason) Date: Tue, 13 Apr 1999 22:14:26 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jason wrote... > This is a Seagate ST410080N that basically reports itself as a SX410080N and > thus the ST410080* quirk entry doesn't catch it. > > It typically needs a hard reset after locking up after reducing tags 1-3 > from 64. The drive is alone on the SCSI bus and properly terminated. I > currently don't have any error messages from when the drive locks up, though > the typical sense code is 0x151. > > relevant dmesg bits: > . > . > . > ahc0: rev 0x00 int a irq 11 on > pci0.18.0 > ahc0: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs > . > . > . > da0: Fixed Direct Access SCSI-2 device > da0: 10.000MB/s transfers (10.000MHz, offset 15) > da0: 8347MB (17096357 512 byte sectors: 64H 32S/T 8347C) > . > . > . > > I've put a quick quirk entry for this drive with tags reduced to 32, and so > far, haven't had any problems, though I haven't tried any other settings to > test performance. You didn't reduce the number of tags to 32, you disabled tagged queueing altogether. When a drive is capable of tagged queueing and tagged queueing is enabled, you'll see dmesg info like this: da1 at ahc1 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 8705MB (17829870 512 byte sectors: 255H 63S/T 1109C) Your drive probably needs the same quirk entry as the other Elite 9's with the 71xx firmware, which is why it has been working okay with tagged queueing disabled. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 23:48:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from stampede.cs.berkeley.edu (stampede.CS.Berkeley.EDU [128.32.45.124]) by hub.freebsd.org (Postfix) with ESMTP id DE8E514D85 for ; Tue, 13 Apr 1999 23:48:46 -0700 (PDT) (envelope-from asami@cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca14-50.ix.netcom.com [205.186.215.50]) by stampede.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id XAA15856; Tue, 13 Apr 1999 23:46:52 -0700 (PDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.2/8.6.9) id XAA56124; Tue, 13 Apr 1999 23:46:22 -0700 (PDT) Date: Tue, 13 Apr 1999 23:46:22 -0700 (PDT) Message-Id: <199904140646.XAA56124@silvia.hip.berkeley.edu> X-Authentication-Warning: silvia.hip.berkeley.edu: asami set sender to asami@cs.berkeley.edu using -f To: ken@plutotech.com Cc: scsi@FreeBSD.ORG In-reply-to: <199904140231.UAA07250@panzer.plutotech.com> (ken@plutotech.com) Subject: Re: timed out while idle? From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) References: <199904140231.UAA07250@panzer.plutotech.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * From: "Kenneth D. Merry" * Yeah, I think you can safely do that. You may be able to get away with * cranking it down to 10 seconds or so. Ok. DA_DEFAULT_TIMEOUT, right? * Right, it's hard to say how the rest of the system will respond. * Sometimes, if it happens on your swap drive, you'll see something that goes * like "swap_pager: indefinite wait buffer" or something like that. Well, our system disks are IDE at the moment so that won't happen. (Although I've seen that particular message for IDE disk failures.) It's usually just the "timed out" messages follewed by a panic. By the way, looking at aic7xxx.c, in this code snippet: === printf("SCB 0x%x - timed out ", scb->hscb->tag); /* * Take a snapshot of the bus state and print out * some information so we can track down driver bugs. */ bus_state = ahc_inb(ahc, LASTPHASE); switch(bus_state) { case P_DATAOUT: : case P_BUSFREE: printf("while idle, LASTPHASE == 0x%x", bus_state); break; === Since the switch statement is on bus_state, isn't it kinda redundant to print it out again as "LASTPHASE"? (Of course it's ok if that's what you intended, I was just wondering if it's a typo of something else.) * There's no way to get it back without rebooting. Rescanning won't help * you, since that finds devices that have appeared, changed or gone away. * Your device hasn't done that, it has stopped responding. It's dead. If * you think it should be done otherwise, talk to the author of the da(4) * driver. :) (no, it's not me) > * Copyright (c) 1997 Justin T. Gibbs. Oh, ok. ;) Well, all I know is that when pack is invalidated, most of the times it will come back with a reboot of the PC. Since our disks are in external enclosures, this means the SCSI bus reset (possibly several of them) woke them up. I'm wondering if it makes a sense to add an option to camcontrol to revalidate it explicitly when the operator is confident that the disk is back. What do you think, Justin? Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 13 23:52:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 4455A14D85 for ; Tue, 13 Apr 1999 23:52:26 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id IAA19114; Wed, 14 Apr 1999 08:19:09 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id WAA01437; Tue, 13 Apr 1999 22:54:59 +0200 (CEST) From: Wilko Bulte Message-Id: <199904132054.WAA01437@yedi.iaf.nl> Subject: Re: Huge SCSI configs In-Reply-To: <199904131722.TAA36868@rt2.synx.com> from Remy Nonnenmacher at "Apr 13, 1999 7:22:19 pm" To: remy@synx.com Date: Tue, 13 Apr 1999 22:54:59 +0200 (CEST) Cc: ken@plutotech.com, freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Remy Nonnenmacher wrote ... > On 13 Apr, Kenneth D. Merry wrote: > >> .... > >> OK. Sorry for this late (but ever unanswered question) : what are the > >> known limits in term of SCSI chains, number and size of disks and sizes > >> of filesystems ? Anyone ? > > > > Aww, come on, you can easily find out the SCSI stuff anywhere on the web. > > For Wide SCSI, you can have up to 15 devices on one chain. (SCSI IDs 0 > > through 15, with 7 reserved for the controller) With Ultra2 LVD, you can > > have cable lengths of up to 12 meters. > > > > Oops, lacked precision "under FreeBSD" !!. (I already proposed building > a MAX config (15*2*15*50G) but they had me stop by knocking my head ;). > No, seriously, i wouldn't like to find myself running honking into a > wall just for not having asked. > > > There's no inherent limit on disk size, but you may want to talk to Matt > > Jacob and Matt Dillon about the stability of very large filesystems. I once built a 450Gb (or close to that) filesystem on a DEC nee Compaq HSZ80 raidcontroller hooked up to an Adaptec 2944UW. Worked fine, took a while to build on a P90 with 2.2.6 on it. I ran out of disks before I could try CCDing a couple of these together ;-) Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 14 11:23: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rt2.synx.com (tech.boostworks.com [194.167.81.239]) by hub.freebsd.org (Postfix) with ESMTP id 6A36814F78; Wed, 14 Apr 1999 11:21:24 -0700 (PDT) (envelope-from root@synx.com) Received: from synx.com (rn.synx.com [192.1.1.241]) by rt2.synx.com (8.9.1/8.9.1) with ESMTP id UAA42196; Wed, 14 Apr 1999 20:18:35 +0200 (CEST) Message-Id: <199904141818.UAA42196@rt2.synx.com> Date: Wed, 14 Apr 1999 20:18:32 +0200 (CEST) From: Remy Nonnenmacher Reply-To: remy@synx.com Subject: Re: timed out while idle? To: asami@FreeBSD.ORG Cc: ken@plutotech.com, scsi@FreeBSD.ORG In-Reply-To: <199904132318.QAA49274@silvia.hip.berkeley.edu> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13 Apr, Satoshi - Ports Wraith - Asami wrote: > * From: "Kenneth D. Merry" > > * The timed out while idle message means that the drive took longer than the > * timeout (60 seconds) to respond to a read or write request, and nothing was > * going on on the bus at the time. In other words, your drive went out to > * lunch, and we hit it with a BDR to get it to come back. > > Wow, 60 seconds? That's indeed a pretty good lunch. :) > > * Yep. There's a timeout for each transaction. If the transaction doesn't > * complete in the specified period of time (60 seconds for disk > * reads/writes), the timeout fires, a BDR is sent and all transactions that > * were queued to the disk are requeued. > > I see. By the way, can any of these cause panics? Here's an example: > If that can serve: I got _exactly_ the same problem on one machine that was otherwise stable for months. It turned out that updating adpatec BIOS (1.23 and 1.32 to 1.34.2) and disabling auto-termination solved the problem. Unfortunetly, i can't say what of the two actions fixed this for me since i made the two at the same time. RN. IeM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 14 12:22:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id E75E614F01; Wed, 14 Apr 1999 12:22:08 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id NAA02152; Wed, 14 Apr 1999 13:19:43 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904141919.NAA02152@panzer.plutotech.com> Subject: Re: timed out while idle? In-Reply-To: <199904141818.UAA42196@rt2.synx.com> from Remy Nonnenmacher at "Apr 14, 1999 8:18:32 pm" To: remy@synx.com Date: Wed, 14 Apr 1999 13:19:43 -0600 (MDT) Cc: asami@FreeBSD.ORG, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Remy Nonnenmacher wrote... > On 13 Apr, Satoshi - Ports Wraith - Asami wrote: > > * From: "Kenneth D. Merry" > > > > * The timed out while idle message means that the drive took longer than the > > * timeout (60 seconds) to respond to a read or write request, and nothing was > > * going on on the bus at the time. In other words, your drive went out to > > * lunch, and we hit it with a BDR to get it to come back. > > > > Wow, 60 seconds? That's indeed a pretty good lunch. :) > > > > * Yep. There's a timeout for each transaction. If the transaction doesn't > > * complete in the specified period of time (60 seconds for disk > > * reads/writes), the timeout fires, a BDR is sent and all transactions that > > * were queued to the disk are requeued. > > > > I see. By the way, can any of these cause panics? Here's an example: > > > > If that can serve: I got _exactly_ the same problem on one machine that > was otherwise stable for months. It turned out that updating adpatec > BIOS (1.23 and 1.32 to 1.34.2) and disabling auto-termination solved the > problem. Unfortunetly, i can't say what of the two actions fixed this > for me since i made the two at the same time. I would guess the latter. Sometimes, especially for on-board chips, using automatic termination may not work properly. In those cases, it's better to explicitly specify what kind of termination you want. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 14 13:49:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 1EB9C1570C; Wed, 14 Apr 1999 13:49:40 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id OAA13777; Wed, 14 Apr 1999 14:37:53 -0600 (MDT) Date: Wed, 14 Apr 1999 14:37:53 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199904142037.OAA13777@narnia.plutotech.com> To: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) Cc: scsi@FreeBSD.ORG Subject: Re: timed out while idle? X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199904140231.UAA07250@panzer.plutotech.com> <199904140646.XAA56124@silvia.hip.berkeley.edu> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199904140646.XAA56124@silvia.hip.berkeley.edu> you wrote: > * There's no way to get it back without rebooting. Rescanning won't help > * you, since that finds devices that have appeared, changed or gone away. > * Your device hasn't done that, it has stopped responding. It's dead. If > * you think it should be done otherwise, talk to the author of the da(4) > * driver. :) (no, it's not me) > > * Copyright (c) 1997 Justin T. Gibbs. That's not entirely true. The device will come back if it transitions through final close (e.g you umount -f all filesystems referencing it). Further, the code that usually causes the disk pack to be invalidated is in cam_periph.c:cam_periph_error() where a selection timeout causes us to receive an ENXIO error. I believe that invalidating the pack is the correct thing to do since we have no way of determining if the media or device are the same, but that we should be retrying things like selection timeouts in a more sane fashion so that invalidations are a rarity. > Oh, ok. ;) > > Well, all I know is that when pack is invalidated, most of the times > it will come back with a reboot of the PC. Since our disks are in > external enclosures, this means the SCSI bus reset (possibly several > of them) woke them up. Many devices will be slow to acknowledge a selection after they've been bullied about by the recovery code. This is probably what caused the device to be invalidated. > I'm wondering if it makes a sense to add an option to camcontrol to > revalidate it explicitly when the operator is confident that the disk > is back. What do you think, Justin? Its not CAM behavior, its da behavior. It would be a da(4) ioctl. If you'd like to add such and ioctl and a utility to toggle it, be my guest. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 14 16: 7:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from stampede.cs.berkeley.edu (stampede.CS.Berkeley.EDU [128.32.45.124]) by hub.freebsd.org (Postfix) with ESMTP id E36D314D0C for ; Wed, 14 Apr 1999 16:07:23 -0700 (PDT) (envelope-from asami@cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca14-50.ix.netcom.com [205.186.215.50]) by stampede.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id QAA17294; Wed, 14 Apr 1999 16:05:15 -0700 (PDT) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.2/8.6.9) id QAA60472; Wed, 14 Apr 1999 16:01:57 -0700 (PDT) Date: Wed, 14 Apr 1999 16:01:57 -0700 (PDT) Message-Id: <199904142301.QAA60472@silvia.hip.berkeley.edu> X-Authentication-Warning: silvia.hip.berkeley.edu: asami set sender to asami@cs.berkeley.edu using -f To: gibbs@narnia.plutotech.com Cc: scsi@FreeBSD.ORG In-reply-to: <199904142037.OAA13777@narnia.plutotech.com> (gibbs@narnia.plutotech.com) Subject: Re: timed out while idle? From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) References: <199904142037.OAA13777@narnia.plutotech.com> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * From: "Justin T. Gibbs" * That's not entirely true. The device will come back if it transitions * through final close (e.g you umount -f all filesystems referencing * it). Ooh. I'll try that next time. Thanks. * Further, the code that usually causes the disk pack to be * invalidated is in cam_periph.c:cam_periph_error() where a selection * timeout causes us to receive an ENXIO error. I believe that * invalidating the pack is the correct thing to do since we have no * way of determining if the media or device are the same, but that we should * be retrying things like selection timeouts in a more sane fashion so * that invalidations are a rarity. No, I think that's fine. I could have pulled a disk and put in another one. Not doing anything with it until all references to it are closed sounds like a sensible thing to do. Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 14 23: 8: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 29F9B15120; Wed, 14 Apr 1999 23:08:02 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id IAA19216; Thu, 15 Apr 1999 08:01:55 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.2/8.6.12) id AAA00646; Thu, 15 Apr 1999 00:01:15 +0200 (CEST) From: Wilko Bulte Message-Id: <199904142201.AAA00646@yedi.iaf.nl> Subject: Re: timed out while idle? In-Reply-To: <199904142037.OAA13777@narnia.plutotech.com> from "Justin T. Gibbs" at "Apr 14, 1999 2:37:53 pm" To: gibbs@narnia.plutotech.com (Justin T. Gibbs) Date: Thu, 15 Apr 1999 00:01:15 +0200 (CEST) Cc: asami@FreeBSD.ORG, scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Justin T. Gibbs wrote ... > In article <199904140646.XAA56124@silvia.hip.berkeley.edu> you wrote: > > * There's no way to get it back without rebooting. Rescanning won't help > > * you, since that finds devices that have appeared, changed or gone away. > > * Your device hasn't done that, it has stopped responding. It's dead. If > > * you think it should be done otherwise, talk to the author of the da(4) > > * driver. :) (no, it's not me) > > > > * Copyright (c) 1997 Justin T. Gibbs. > > That's not entirely true. The device will come back if it transitions > through final close (e.g you umount -f all filesystems referencing > it). Further, the code that usually causes the disk pack to be > invalidated is in cam_periph.c:cam_periph_error() where a selection > timeout causes us to receive an ENXIO error. I believe that > invalidating the pack is the correct thing to do since we have no > way of determining if the media or device are the same, but that we should > be retrying things like selection timeouts in a more sane fashion so > that invalidations are a rarity. Hmm. Just a random thought. Can't you use the device serial number to determine if it is the same one like before? Anyway, I'd say devices that do disappearing acts are not the ones I would like to have in my machines. YMMV Wilko Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 15 0:13:38 1999 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 73EB314C83 for ; Thu, 15 Apr 1999 00:13:35 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id JAA05930 for scsi@FreeBSD.ORG; Thu, 15 Apr 1999 09:11:14 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id JAA28515; Thu, 15 Apr 1999 09:00:36 +0200 (MET DST) (envelope-from j) Message-ID: <19990415090035.03868@uriah.heep.sax.de> Date: Thu, 15 Apr 1999 09:00:35 +0200 From: J Wunsch To: scsi@FreeBSD.ORG Subject: Re: timed out while idle? Reply-To: Joerg Wunsch References: <199904140231.UAA07250@panzer.plutotech.com> <199904142037.OAA13777@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199904142037.OAA13777@narnia.plutotech.com>; from Justin T. Gibbs on Wed, Apr 14, 1999 at 02:37:53PM -0600 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 As Justin T. Gibbs wrote: > That's not entirely true. The device will come back if it transitions > through final close (e.g you umount -f all filesystems referencing > it). Last time i checked, this didn't work. You couldn't umount -f since umount needed (one way or the other, i didn't investigate) a drive that at least didn't respond with ENXIO all the time, and since the umount never completed, CAM was unable to ever get the drive back again. > Further, the code that usually causes the disk pack to be > invalidated is in cam_periph.c:cam_periph_error() where a selection > timeout causes us to receive an ENXIO error. I believe that > invalidating the pack is the correct thing to do since we have no > way of determining if the media or device are the same, but that we > should be retrying things like selection timeouts in a more sane > fashion so that invalidations are a rarity. I think we've been at this discussion before. IMHO, CAMs action in this case is not what all the people would expect, and it makes CAM (which i believe is excellent by design -- no criticism) rather fragile compared to other operating system. You can't e.g. swap a SCSI chain terminator while the chain is under heavy load, or it would invalidate all the disks on it. Compare this to e.g. a Solaris machine, where you can do this. Don't get me wrong, i understand why you implemented it this way (at least i believe i understand, since i guess that's the behaviour you needed for Plutotech), and i agree that this is one possible view at the world. However, i'd like to see it `tunable' in a way where it tries a lot harder to assume the drive is still alive, since from my experience, 99 % of the SCSI problems are not drives gone south, but SCSI busses being temporarily broken, which is fixable. I'd even argue that this is what most people would expect... Any chance to have the behaviour optional? (The current default behaviour might be very feasible for people running large disk farms, where the wiring is usually well, but it's indeed the disks that wear out.) > Its not CAM behavior, its da behavior. It would be a da(4) ioctl. > If you'd like to add such and ioctl and a utility to toggle it, be > my guest. OK, i'll look into it. ;-) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 15 12: 2: 8 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 1CD4614EBE for ; Thu, 15 Apr 1999 12:01:58 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA24281; Thu, 15 Apr 1999 20:15:09 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.2/8.6.12) id UAA00842; Thu, 15 Apr 1999 20:03:39 +0200 (CEST) From: Wilko Bulte Message-Id: <199904151803.UAA00842@yedi.iaf.nl> Subject: Re: timed out while idle? In-Reply-To: <19990415090035.03868@uriah.heep.sax.de> from J Wunsch at "Apr 15, 1999 9: 0:35 am" To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 15 Apr 1999 20:03:39 +0200 (CEST) Cc: scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As J Wunsch wrote ... > As Justin T. Gibbs wrote: > > > Further, the code that usually causes the disk pack to be > > invalidated is in cam_periph.c:cam_periph_error() where a selection > > timeout causes us to receive an ENXIO error. I believe that > > invalidating the pack is the correct thing to do since we have no > > way of determining if the media or device are the same, but that we > > should be retrying things like selection timeouts in a more sane > > fashion so that invalidations are a rarity. > > I think we've been at this discussion before. IMHO, CAMs action in > this case is not what all the people would expect, and it makes CAM > (which i believe is excellent by design -- no criticism) rather > fragile compared to other operating system. You can't e.g. swap a > SCSI chain terminator while the chain is under heavy load, or it would > invalidate all the disks on it. Compare this to e.g. a Solaris > machine, where you can do this. > > Don't get me wrong, i understand why you implemented it this way (at > least i believe i understand, since i guess that's the behaviour you > needed for Plutotech), and i agree that this is one possible view at > the world. However, i'd like to see it `tunable' in a way where it So a sort of /etc/system with an sd_iotime= or something along these lines? Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 15 12:27:53 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from warped.cswnet.com (warped.cswnet.com [209.136.201.6]) by hub.freebsd.org (Postfix) with SMTP id 6750C15197 for ; Thu, 15 Apr 1999 12:27:42 -0700 (PDT) (envelope-from lambert@warped.cswnet.com) Received: from gronk.csw.net ( [209.136.201.13] ) by warped.cswnet.com (Hethmon Brothers Smtpd) ; Thu, 15 Apr 1999 13:26:08 -0600 Message-Id: <199904151326.0817285.6@warped.cswnet.com> From: lambert@warped.cswnet.com Date: Thu, 15 Apr 1999 13:20:20 -0500 To: freebsd-scsi@freebsd.org Subject: Problems with AIC-7895P SCSI and -STABLE X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.60 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I have a system that won't do large compiles like the kernel. The parts list includes: Gigabyte GA-6BXDS rev 1.7 MotherBoard AIC-7895P on the mobo CH A - bus 0 targ 0 lun 0 - Seagate Barracuda ST34501W CH B - bus 0 targ 1 lun 0 - Seagate Barracuda ST39173LW bus 0 targ 2 lun 0 - Seagate Barracuda ST39173W 256MB ECC RAM (2*128MB sticks) 1 - 400Mhz PII 512K L2 Trident 9875 VGA Intel EtherExpress Pro 10/100+ 3.5" Floppy 1.44MB 104-key Keyboard When compiling the kernel with all parts installed, it will get partway through the compile and hard lock. The keyboard will not respond and a power-cycle is required. If I remove the EtherExpress card the compile completes. So I bought a new card thinking that this one had gone bad. No such luck. I have swapped out the memory. I've swapped the video. I can't swap out the disks but have removed all but the 4.5GB drive with the same results. The only wierd thing in my dmesg output seems to be a warning about using too many ports on the controller even when only one port is in use. So, I turn to you guys. What have I missed? Is there a problem with the "P" model of this SCSI chip? My other machines are using the AIC-7895 without problems. The SCSI BIOS is set to auto-Termination and the last drive on each of the two cables is terminated. dmesg with GENERIC kernel: (I've stripped the unfound driver messages) Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-19990218-STABLE #0: Thu Feb 18 10:56:19 GMT 1999 root@usw3.freebsd.org:/usr/src/sys/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (398.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping=2 Features=0x183fbff> real memory = 268435456 (262144K bytes) avail memory = 257904640 (251860K bytes) Preloaded elf kernel "kernel" at 0xf0340000. Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x03 on pci0.1.0 chip2: rev 0x02 on pci0.7.0 ide_pci0: rev 0x01 on pci0.7.1 chip3: rev 0x02 on pci0.7.3 fxp0: rev 0x05 int a irq 5 on pci0.9.0 fxp0: Ethernet address 00:90:27:0d:4a:5d ahc0: rev 0x04 int a irq 11 on pci0.12.0 ahc0: Illegal cable configuration!!. Only two connectors on the adapter may be used at a time! ahc0: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x04 int b irq 11 on pci0.12.1 ahc1: Using left over BIOS settings ahc1: aic7895 Wide Channel B, SCSI Id=7, 16/255 SCBs Probing for devices on PCI bus 1: vga0: rev 0xf3 int a irq 11 on pci1.0.0 Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode nlpt0: on ppbus 0 nlpt0: Interrupt-driven port ppi0: on ppbus 0 plip0: on ppbus 0 ie0: unknown board_id: f000 ie0 not found at 0x300 vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Waiting 15 seconds for SCSI devices to settle changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.0MB/s transfers (10.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4339MB (8887200 512 byte sectors: 255H 63S/T 553C) da1 at ahc1 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 8683MB (17783240 512 byte sectors: 64H 32S/T 8683C) da2 at ahc1 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 8683MB (17783240 512 byte sectors: 64H 32S/T 8683C) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 15 13:39:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 792FB14D06 for ; Thu, 15 Apr 1999 13:39:43 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id NAA05462 for ; Thu, 15 Apr 1999 13:36:57 -0700 Date: Thu, 15 Apr 1999 13:36:57 -0700 (PWT) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: freebsd-scsi@freebsd.org Subject: Obsolete Data Compression field in Device configuration mode page (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=------------4FE5826A7807529BBBBC2C95 Content-ID: Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --------------4FE5826A7807529BBBBC2C95 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: fyi ---------- Forwarded message ---------- Date: Thu, 15 Apr 1999 15:20:00 -0500 From: David A. Peterson To: t10@Symbios.COM, fc@nsg0.network.com Subject: Obsolete Data Compression field in Device configuration mode page Howdy All, This is a notice regarding the proposed obsoletion of the data compression field in the device configuration mode page. Currently the SSC document contains two methods to deal with data compression: 1. the Data compression mode page 2. the Device configuration mode page At the last combined T10/T11 FC-TAPE/SSC/FCP-2 working group meeting in Harrisburg, PA it was decided to obsolete the Data compression field in the Device configuration mode page in favor of the Data compression mode page. This subject will be voted on at the upcoming T10 meeting in Manchester, New Hampshire. --------------4FE5826A7807529BBBBC2C95 Content-Type: TEXT/X-VCARD; CHARSET=us-ascii; NAME="dap.vcf" Content-ID: Content-Description: Card for David A. Peterson Content-Disposition: ATTACHMENT; FILENAME="dap.vcf" begin:vcard n:Peterson;David tel;fax:612-391-1095 tel;work:612-391-1008 x-mozilla-html:TRUE org:StorageTek - Network Business Group adr:;;;;;; version:2.1 email;internet:dap@network.com title:Principal Engineer x-mozilla-cpt:;-28688 fn:David Peterson end:vcard --------------4FE5826A7807529BBBBC2C95-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 15 14:15:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 731BD14E46 for ; Thu, 15 Apr 1999 14:15:12 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id OAA05703 for ; Thu, 15 Apr 1999 14:12:21 -0700 Date: Thu, 15 Apr 1999 14:12:20 -0700 (PWT) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: freebsd-scsi@freebsd.org Subject: I/O distributed across multiple SCSi busses, same hba... 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 Here's a case of a two-channel Qlogic 1240 (two independent Ultra channels on the same controller card)- I'm doing lmdd's reading from a drive on either bus simultaneously. There's a very wierd distrbution of I/O from bus to bus. Anyone have a quick notion as to why? It's not a controller hw queue resource issue as this is raw access... it might be f/w but I'd kinda doubt it. Is it a VM thingie perhaps? I wouldna think so.... tty da0 da1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 1 26 0.00 0 0.00 0.00 0 0.00 4 0 13 6 77 0 12 8.00 3 9.87 8.00 1262 9.86 2 0 68 20 11 0 12 8.00 5 9.80 8.00 1249 9.76 1 0 71 17 12 0 12 8.00 1255 9.80 8.00 1243 9.71 2 0 67 19 13 0 12 8.00 6 9.89 8.00 1265 9.88 2 0 70 18 10 0 12 8.00 1267 9.90 8.00 1258 9.83 3 0 68 18 11 0 12 8.00 263 9.87 8.00 1253 9.79 2 0 70 19 10 0 12 8.00 1265 9.88 8.00 1230 9.61 3 0 68 16 13 0 12 8.00 64 9.87 8.00 1240 9.69 3 0 65 18 14 0 12 8.00 1259 9.83 8.00 1236 9.66 2 0 66 22 10 0 12 8.00 263 9.87 8.00 1240 9.68 3 0 68 17 11 0 12 8.00 3 9.87 8.00 1239 9.68 2 0 68 19 11 0 12 8.00 1261 9.85 8.00 1239 9.68 2 0 66 21 11 0 12 8.00 1262 9.86 8.00 1239 9.68 2 0 71 17 11 0 12 8.00 7 9.90 8.00 1226 9.58 2 0 67 17 13 0 12 8.00 1261 9.86 8.00 1239 9.68 2 0 71 16 12 0 12 8.00 1259 9.83 8.00 1239 9.68 3 0 69 16 12 0 12 8.00 1251 9.77 8.00 1239 9.68 4 0 66 18 13 0 12 8.00 252 9.78 8.00 1239 9.68 2 0 67 19 13 0 12 8.00 1252 9.78 8.00 1219 9.52 3 0 65 19 13 tty da0 da1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 36 8.00 1252 9.78 8.00 1214 9.48 3 0 65 17 14 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 15 14:34:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id D16D114F13 for ; Thu, 15 Apr 1999 14:34:35 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id PAA04943; Thu, 15 Apr 1999 15:32:09 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904152132.PAA04943@panzer.plutotech.com> Subject: Re: I/O distributed across multiple SCSi busses, same hba... In-Reply-To: from Matthew Jacob at "Apr 15, 1999 2:12:20 pm" To: mjacob@feral.com Date: Thu, 15 Apr 1999 15:32:09 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote... > > Here's a case of a two-channel Qlogic 1240 (two independent Ultra channels > on the same controller card)- I'm doing lmdd's reading from a drive on > either bus simultaneously. There's a very wierd distrbution of I/O from > bus to bus. Anyone have a quick notion as to why? It's not a controller > hw queue resource issue as this is raw access... it might be f/w but I'd > kinda doubt it. Is it a VM thingie perhaps? I wouldna think so.... There's definitely something wrong here. > tty da0 da1 cpu > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > 1 26 0.00 0 0.00 0.00 0 0.00 4 0 13 6 77 > 0 12 8.00 3 9.87 8.00 1262 9.86 2 0 68 20 11 > 0 12 8.00 5 9.80 8.00 1249 9.76 1 0 71 17 12 > 0 12 8.00 1255 9.80 8.00 1243 9.71 2 0 67 19 13 > 0 12 8.00 6 9.89 8.00 1265 9.88 2 0 70 18 10 > 0 12 8.00 1267 9.90 8.00 1258 9.83 3 0 68 18 11 > 0 12 8.00 263 9.87 8.00 1253 9.79 2 0 70 19 10 > 0 12 8.00 1265 9.88 8.00 1230 9.61 3 0 68 16 13 > 0 12 8.00 64 9.87 8.00 1240 9.69 3 0 65 18 14 > 0 12 8.00 1259 9.83 8.00 1236 9.66 2 0 66 22 10 > 0 12 8.00 263 9.87 8.00 1240 9.68 3 0 68 17 11 > 0 12 8.00 3 9.87 8.00 1239 9.68 2 0 68 19 11 > 0 12 8.00 1261 9.85 8.00 1239 9.68 2 0 66 21 11 > 0 12 8.00 1262 9.86 8.00 1239 9.68 2 0 71 17 11 > 0 12 8.00 7 9.90 8.00 1226 9.58 2 0 67 17 13 > 0 12 8.00 1261 9.86 8.00 1239 9.68 2 0 71 16 12 > 0 12 8.00 1259 9.83 8.00 1239 9.68 3 0 69 16 12 > 0 12 8.00 1251 9.77 8.00 1239 9.68 4 0 66 18 13 > 0 12 8.00 252 9.78 8.00 1239 9.68 2 0 67 19 13 > 0 12 8.00 1252 9.78 8.00 1219 9.52 3 0 65 19 13 > tty da0 da1 cpu > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > 0 36 8.00 1252 9.78 8.00 1214 9.48 3 0 65 17 14 This looks like some sort of printf-type bug. I think, in some of the cases, you're only getting a few of the digits. Notice that the megabytes per second is consistent all the way down. The transaction size is as well. But the transactions per second field varies widely. I think it may be that some of the digits aren't getting shown. Like it'll only show the last 1, 2, or 3 digits sometimes. Obviously, (MB/sec * 1024) / KB/t == (or should equal) transfers per second. Here's the relevant code from iostat(8). It's worked fine up until now. I take it this is a -current box with egcs? Alpha or i386? else { total_mb = total_bytes; total_mb /= 1024 * 1024; printf(" %5.2Lf %3.1qu %5.2Lf ", kb_per_transfer, total_transfers, total_mb); } Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 15 14:43: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 49276151D2 for ; Thu, 15 Apr 1999 14:42:58 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id OAA05940; Thu, 15 Apr 1999 14:40:10 -0700 Date: Thu, 15 Apr 1999 14:40:10 -0700 (PWT) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: I/O distributed across multiple SCSi busses, same hba... In-Reply-To: <199904152132.PAA04943@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 0 12 8.00 1259 9.83 8.00 1239 9.68 3 0 69 16 12 > > 0 12 8.00 1251 9.77 8.00 1239 9.68 4 0 66 18 13 > > 0 12 8.00 252 9.78 8.00 1239 9.68 2 0 67 19 13 > > 0 12 8.00 1252 9.78 8.00 1219 9.52 3 0 65 19 13 > > tty da0 da1 cpu > > tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id > > 0 36 8.00 1252 9.78 8.00 1214 9.48 3 0 65 17 14 > Well, bless me, it never occurred to me... > > This looks like some sort of printf-type bug. I think, in some of the > cases, you're only getting a few of the digits. Notice that the megabytes > per second is consistent all the way down. The transaction size is as > well. > > But the transactions per second field varies widely. I think it may be > that some of the digits aren't getting shown. Like it'll only show the > last 1, 2, or 3 digits sometimes. > > Obviously, (MB/sec * 1024) / KB/t == (or should equal) transfers per second. > > Here's the relevant code from iostat(8). It's worked fine up until now. I > take it this is a -current box with egcs? Alpha or i386? > > else { > total_mb = total_bytes; > total_mb /= 1024 * 1024; > > printf(" %5.2Lf %3.1qu %5.2Lf ", > kb_per_transfer, > total_transfers, > total_mb); > } i386, 3.1-stable, with isp from -current. I wouldn't *think* that there's a difference... hold on a second.... D'oh! I'm a surprised idiot. The iostat lines before were being printed on a serial console. I never realized how many characters it could drop...Here's from a pty: isp# iostat da0 da1 5 tty da0 da1 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 14 0.00 0 0.00 0.00 0 0.00 1 0 9 3 88 3 20 0.00 0 0.00 0.00 0 0.00 0 0 0 0 99 1 20 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 4 29 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 3 15 0.00 0 0.00 0.00 0 0.00 0 0 0 1 99 2 14 0.00 0 0.00 0.00 0 0.00 0 0 0 0 99 1 13 7.99 851 6.64 0.00 0 0.00 1 0 15 6 78 5 17 8.00 1309 10.23 0.00 0 0.00 1 0 22 6 70 0 12 8.00 1309 10.23 0.00 0 0.00 1 0 22 7 69 0 13 8.00 1284 10.03 8.00 989 7.72 1 0 61 16 21 0 12 8.00 1280 10.00 8.00 1281 10.01 2 0 75 17 6 0 12 8.00 1278 9.98 8.00 1276 9.97 2 0 76 16 6 0 12 8.00 1279 9.99 8.00 1278 9.99 2 0 74 18 6 0 12 8.00 1276 9.97 8.00 1278 9.99 2 0 76 17 5 0 12 8.00 1278 9.98 8.00 1280 10.00 2 0 72 20 7 0 12 8.00 1277 9.97 8.00 1276 9.97 4 0 72 16 8 0 12 8.00 1277 9.97 8.00 1277 9.98 2 0 78 14 6 0 12 8.00 1275 9.96 8.00 1276 9.97 3 0 74 16 7 (never mind! Sorry for disturbing your naps, folks...) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 15 17: 8:10 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (Postfix) with ESMTP id 2D19114A2F for ; Thu, 15 Apr 1999 17:08:09 -0700 (PDT) (envelope-from asami@vader.cs.berkeley.edu) Received: (from asami@localhost) by vader.cs.berkeley.edu (8.8.7/8.7.3) id RAA01468; Thu, 15 Apr 1999 17:05:47 -0700 (PDT) Date: Thu, 15 Apr 1999 17:05:47 -0700 (PDT) Message-Id: <199904160005.RAA01468@vader.cs.berkeley.edu> To: freebsd-scsi@freebsd.org In-reply-to: <199904142216.QAA03218@panzer.plutotech.com> (ken@plutotech.com) Subject: Re: timed out while idle? From: asami@freebsd.org (Satoshi Asami) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org By the way, I found another case. First, some background. Some of our SCSI strings are double-ended, i.e., have two SCSI adapters on both ends. Due to physical constraints, they don't have external terminators. So they use the SCSI adapters' termination. This setup works pretty well normally, even when one machine is rebooted (Justin, thanks for fixing a problem of unexpected bus resets a few years back). However, if one of the machines is brought down (the "press any key to reboot" prompt), I start seeing timeouts on the other machine. === (da33:ahc2:0:1:0): SCB 0x17 - timed out in datain phase, SCSISIGI == 0x44 SEQADDR == 0x110 SSTAT1 == 0x2 (da33:ahc2:0:1:0): BDR message in message buffer (da33:ahc2:0:1:0): SCB 0x17 - timed out in datain phase, SCSISIGI == 0x54 SEQADDR == 0x110 SSTAT1 == 0x2 (da33:ahc2:0:1:0): no longer in timeout, status = 34b === I'm assuming this is because the termination went away. After I hit return to reboot it, the other machine recovers as if nothing happened. So, my question is: is it possible to keep the termination settings even when the operating system shut down, or is this just the way the adapters are designed? Thanks Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 15 17:12:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sand2.sentex.ca (sand2.sentex.ca [209.167.248.3]) by hub.freebsd.org (Postfix) with ESMTP id 86275151DB; Thu, 15 Apr 1999 17:12:21 -0700 (PDT) (envelope-from mike@sentex.net) Received: from gravel (ospf-wat.sentex.net [209.167.248.81]) by sand2.sentex.ca (8.8.8/8.8.8) with SMTP id UAA24581; Thu, 15 Apr 1999 20:09:58 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <4.1.19990415201543.041e14c0@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 15 Apr 1999 20:19:59 -0400 To: questions@freebsd.org From: Mike Tancsa Subject: ahc0: WARNING no command for scb # Cc: scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, On a 2.2-STABLE machine that is about 90 days old, I saw a whole mess of ahc0: WARNING no command for scb 7 (cmdcmplt) QOUTCNT == 8 ahc0: WARNING no command for scb 7 (cmdcmplt) QOUTCNT == 7 ahc0: WARNING no command for scb 7 (cmdcmplt) QOUTCNT == 6 ahc0: WARNING no command for scb 7 (cmdcmplt) QOUTCNT == 5 ahc0: WARNING no command for scb 7 (cmdcmplt) QOUTCNT == 4 ahc0: WARNING no command for scb 7 (cmdcmplt) QOUTCNT == 3 ahc0: WARNING no command for scb 7 (cmdcmplt) QOUTCNT == 2 ahc0: WARNING no command for scb 7 (cmdcmplt) QOUTCNT == 1 come on my console. Any ideas what they are and what them mean ? Thanks, ---Mike ********************************************************************** Mike Tancsa, Network Admin * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 01.519.651.3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 15 17:52:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 72A3114E2A for ; Thu, 15 Apr 1999 17:52:21 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id SAA01806; Thu, 15 Apr 1999 18:40:24 -0600 (MDT) Date: Thu, 15 Apr 1999 18:40:24 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199904160040.SAA01806@narnia.plutotech.com> To: lambert@warped.cswnet.com Cc: scsi@FreeBSD.org Subject: Re: Problems with AIC-7895P SCSI and -STABLE X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199904151326.0817285.6@warped.cswnet.com> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The only wierd thing in my dmesg output seems to be a warning about using > too many ports on the controller even when only one port is in use. If you send me the dmesg output from a "boot -v", I can probably find out what is going wrong here. I doubt, however, that this is the cause of your hang. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 15 18:10:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id B959915064; Thu, 15 Apr 1999 18:10:42 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id SAA01846; Thu, 15 Apr 1999 18:58:47 -0600 (MDT) Date: Thu, 15 Apr 1999 18:58:47 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199904160058.SAA01846@narnia.plutotech.com> To: asami@FreeBSD.ORG (Satoshi Asami) Cc: scsi@FreeBSD.ORG Subject: Re: timed out while idle? X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <199904160005.RAA01468@vader.cs.berkeley.edu> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199904160005.RAA01468@vader.cs.berkeley.edu> you wrote: > > I'm assuming this is because the termination went away. After I hit > return to reboot it, the other machine recovers as if nothing > happened. The shutdown hook is spamming the termination settings. I should be able to fix this tonight. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 16 1: 1: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from hydrogen.fircrest.net (metriclient-5.uoregon.edu [128.223.172.5]) by hub.freebsd.org (Postfix) with ESMTP id 1431115096 for ; Fri, 16 Apr 1999 01:00:46 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.fircrest.net (8.9.1/8.8.7) id AAA01225; Fri, 16 Apr 1999 00:58:02 -0700 (PDT) Message-ID: <19990416005802.03297@hydrogen.nike.efn.org> Date: Fri, 16 Apr 1999 00:58:02 -0700 From: John-Mark Gurney To: freebsd-scsi@freebsd.org, "Justin T. Gibbs" Subject: adv panics on boot with chinon cd-rom Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=d6Gm4EdcadzBjdND X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii well, I reciently reorganized my scsi devices as I got to new ultra drives... so I had to move devices around... previously the buslogic pci driver wouldn't have any problems with the chinon cd-rom drives, but the advansys pci drive doesn't handle them too well... attached are the output from a 3.1-19990408-STABLE kernel (built w/ CAMDEBUG) with the chinon cd-rom drives on ids 3 & 4... also attached is the output from a working boot on 3.0-RELEASE w/o the chinon drives attached... on the -stable kernel the adv drive actually ends up panicing and rebooting without attaching any devices... on a side note, does anyone know what the upper limit for tags are on the MICROP 4421-07 drives are? this drive likes to go out to lunch if you hit it to hard... yes, I do know about the patch that allows you to set the tags, but I'm pretty sure it's not compatible with 3.0-R, and until I get the cdrom drives up, I'm not going to be upgrading.. -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="31s.output" BIOS basemem: 640K, extmem: 80896K (from 0xe801 call) BIOS extmem (65472K) != RTC extmem (80896K) Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-19990408-STABLE #0: Mon Apr 12 05:18:45 GMT 1999 jmg@hydrogen.fircrest.net:/usr/src/sys/compile/hydrogen Calibrating clock(s) ... TSC clock: 225011611 Hz, i8254 clock: 1193244 Hz Press a key on the console to abort clock calibration Calibrating clock(s) ... TSC clock: 225013100 Hz, i8254 clock: 1193252 Hz Calibrating clock(s) ... TSC clock: 225011516 Hz, i8254 clock: 1193243 Hz Calibrating clock(s) ... TSC clock: 225013076 Hz, i8254 clock: 1193251 Hz Timecounter "i8254" frequency 1193244 Hz CPU: AMD-K6tm w/ multimedia extensions (225.01-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x562 Stepping=2 Features=0x8001bf Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Enable Limit: 80M bytes Write Allocate 15-16M bytes: Enable Hardware Write Allocate Control: Disable real memory = 83886080 (81920K bytes) Physical memory chunk(s): 0x00001000 - 0x0009ffff, 651264 bytes (159 pages) 0x002f1000 - 0x04ffbfff, 80785408 bytes (19723 pages) avail memory = 78270464 (76436K bytes) Found BIOS32 Service Directory header at 0xf00faaa0 Entry = 0xfaf50 (0xf00faf50) Rev = 0 Len = 1 PCI BIOS entry at 0xaf80 DMI header at 0xf00f5a50 Version 2.0 Table at 0xf1000, 29 entries, 661 bytes Other BIOS signatures found: ACPI: 00000000 $PnP: 000fbb50 Preloaded elf kernel "kernel.31s.debug" at 0xf02e0000. pci_open(1): mode 1 addr port (0x0cf8) is 0x80003840 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=15951106) Probing for devices on PCI bus 0: found-> vendor=0x1106, dev=0x1595, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 chip0: rev 0x03 on pci0.0.0 found-> vendor=0x1106, dev=0x0586, revid=0x27 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 chip1: rev 0x27 on pci0.7.0 found-> vendor=0x104b, dev=0x1040, revid=0x00 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=10 map[0]: type 4, range 32, base 00006200, size 2 bt0: rev 0x00 int a irq 10 on pci0.8.0 bt0: BT-946C FW Rev. 4.28D Narrow SCSI Host Adapter, SCSI ID 7, 100 CCBs bt0: Using Strict Round Robin Mailbox Mode found-> vendor=0x1011, dev=0x0014, revid=0x11 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=11 map[0]: type 4, range 32, base 00006300, size 7 map[1]: type 1, range 32, base e0000000, size 7 de0: rev 0x11 int a irq 11 on pci0.9.0 de0: 21041 [10Mb/s] pass 1.1 de0: address 00:80:19:35:21:93 bpf: de0 attached found-> vendor=0x10cd, dev=0x1300, revid=0x02 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=12 map[0]: type 4, range 32, base 00006400, size 6 adv0: rev 0x02 int a irq 12 on pci0.10.0 adv0: AdvanSys Ultra SCSI Host Adapter, SCSI ID 7, queue depth 240 Initializing PnP override table Probing for PnP devices: Trying Read_Port at 203 CSN 1 Vendor ID: CSC4237 [0x3742630e] Serial 0xffffffff Comp ID: @@@0000 [0x00000000] Called nullpnp_probe with tag 0x00000001, type 0x3742630e port 0x0534 0x0388 0x0220 0x0000 irq 5:0 drq 1:3 en 1 port 0x0534 0x0388 0x0220 0x0000 irq 5:0 drq 1:3 en 1 mss_attach 1 at 0x530 irq 5 dma 1:3 flags 0x13 pcm1 (CS423x/Yamaha/AD1816 sn 0xffffffff) at 0x530-0x537 irq 5 drq 1 flags 0x13 on isa Probing for devices on the ISA bus: sc0 on isa sc0: fb0 kbd0 sc0: MDA/Hercules <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa kbd0: atkbd0, generic (3), config:0x10000, flags:0x3f0000 sio0: irq maps: 0x801 0x811 0x801 0x801 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console sio1: irq maps: 0x801 0x809 0x801 0x801 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A dgb0: PC/Xe 64/8K (windowed) dgb0 at 0x320-0x323 maddr 0xd0000 msize 8192 on isa dgb0: 2 ports mss_probe: no address supplied, try default 0x530 device at 0x530 already attached as unit 1 sb_probe: no address supplied, try defaults (0x220,0x240) device at 0x220 already attached as unit 1 pcm0 not found wdc0 not found at 0x1f0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold ppc: parallel port found at 0x3bc ppc0: EPP SPP ppc0 at 0x3bc irq 7 on isa ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode nlpt0: on ppbus 0 nlpt0: Interrupt-driven port vga0 at 0x3b0-0x3bb maddr 0xb0000 msize 32768 on isa fb0: vga0, mda, type:MDA (1), flags:0x70000 fb0: port:0x3b0-0x3bb, crtc:0x3b4, mem:0xb0000 0x8000 fb0: init mode:7, bios mode:7, current mode:7 fb0: window:0xf00b0000 size:32k gran:32k, buf:0x0 size:0k npx0 on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 148411991 bytes/sec bzero() bandwidth = 142227279 bytes/sec apm0 on isa apm: found APM BIOS version 1.2 imasks: bio c0080040, tty c00708ba, net c00708ba de0: enabling 10baseT port BIOS Geometries: 0:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 1:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 2:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 3:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 4:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 5:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 6:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 7:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 0 accounted for Device configuration finished. IP packet filtering initialized, divert enabled, rule-based forwarding disabled, logging disabled bpf: tun0 attached bpf: tun1 attached bpf: sl0 attached bpf: sl1 attached bpf: ppp0 attached bpf: ppp1 attached new masks: bio c0080040, tty c00708ba, net c00708ba bpf: lo0 attached Waiting 2 seconds for SCSI devices to settle bt0: Using Strict Round Robin Mailbox Mode bt: ccb 0xf4825380 - error 4 occured. btstat = 11, sdstat = 0 bt: ccb 0xf4825200 - error 4 occured. btstat = 11, sdstat = 0 bt: ccb 0xf4825340 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xf4825340 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xf4825300 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xf48252c0 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xf4825280 - error 4 occured. btstat = 0, sdstat = 2 (probe5:bt0:0:5:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe5:bt0:0:5:0): ILLEGAL REQUEST asc:24,0 (probe5:bt0:0:5:0): Invalid field in CDB (probbt: ccb 0xf4825240 - error 4 occured. btstat = 0, sdstat = 2 bt: ccb 0xf4825280 - error 4 occured. btstat = 0, sdstat = 2 e3:bt0:0:3:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe3:bt0:0:3:0): ILLEGAL REQUEST asc:24,0 (probe3:bt0:0:3:0): Invalid field in CDB (probe2:bt0:0:2:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe2:bt0:0:2:0): ILLEGAL REQUEST asc:24,0 (probe2:bt0:0:2:0): Invalid field in CDB (probe4:bt0:0:4:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe4:bt0:0:4:0): ILLEGAL REQUEST asc:24,0 (probe4:bt0:0:4:0): Invalid field in CDB sks:c8,1 (probe13:adv0:0:6:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe13:adv0:0:6:0): ILLEGAL REQUEST asc:24,0 (probe13:adv0:0:6:0): Invalid field in CDB sks:cf,2 (probe10:adv0:0:3:0): Timed out (probe10:adv0:0:3:0): Attempting abort (probe10:adv0:0:3:0): Timed out (probe10:adv0:0:3:0): Resetting bus adv0: No longer in timeout panic: adv0: Unhandled Host status error 44 syncing disks... done Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot <-- Rebooting... --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="30r.output" BIOS basemem: 640K, extmem: 80896K (from 0xe801 call) BIOS extmem (65472K) != RTC extmem (80896K) Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-RELEASE #2: Thu Apr 8 23:57:30 PDT 1999 root@:/usr/src/sys/compile/hydrogen Calibrating clock(s) ... TSC clock: 225011182 Hz, i8254 clock: 1193242 Hz Press a key on the console to abort clock calibration Calibrating clock(s) ... TSC clock: 225009405 Hz, i8254 clock: 1193232 Hz Timecounter "i8254" frequency 1193242 Hz cost 3267 ns CPU: AMD-K6tm w/ multimedia extensions (225.01-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x562 Stepping=2 Features=0x8001bf Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative real memory = 83886080 (81920K bytes) Physical memory chunk(s): 0x00001000 - 0x0009ffff, 651264 bytes (159 pages) 0x002b1000 - 0x04ffbfff, 81047552 bytes (19787 pages) avail memory = 78536704 (76696K bytes) Found BIOS32 Service Directory header at 0xf00faaa0 Entry = 0xfaf50 (0xf00faf50) Rev = 0 Len = 1 PCI BIOS entry at 0xaf80 DMI header at 0xf00f5a50 Version 2.0 Table at 0xf1000, 29 entries, 661 bytes Other BIOS signatures found: ACPI: 00000000 $PnP: 000fbb50 pci_open(1): mode 1 addr port (0x0cf8) is 0x80003840 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=15951106) Probing for devices on PCI bus 0: found-> vendor=0x1106, dev=0x1595, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 chip0: rev 0x03 on pci0.0.0 found-> vendor=0x1106, dev=0x0586, revid=0x27 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 chip1: rev 0x27 on pci0.7.0 found-> vendor=0x104b, dev=0x1040, revid=0x00 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=10 map[0]: type 4, range 32, base 00006200, size 2 bt0: rev 0x00 int a irq 10 on pci0.8.0 bt0: BT-946C FW Rev. 4.28D Narrow SCSI Host Adapter, SCSI ID 7, 100 CCBs bt0: Using Strict Round Robin Mailbox Mode found-> vendor=0x1011, dev=0x0014, revid=0x11 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=11 map[0]: type 4, range 32, base 00006300, size 7 map[1]: type 1, range 32, base e0000000, size 7 de0: rev 0x11 int a irq 11 on pci0.9.0 de0: 21041 [10Mb/s] pass 1.1 de0: address 00:80:19:35:21:93 bpf: de0 attached found-> vendor=0x10cd, dev=0x1300, revid=0x02 class=01-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=12 map[0]: type 4, range 32, base 00006400, size 6 adv0: rev 0x02 int a irq 12 on pci0.10.0 adv0: AdvanSys Ultra SCSI Host Adapter, SCSI ID 7, queue depth 240 Initializing PnP override table Probing for PnP devices: Trying Read_Port at 203 CSN 1 Vendor ID: CSC4237 [0x3742630e] Serial 0xffffffff Comp ID: @@@0000 [0x00000000] Called nullpnp_probe with tag 0x00000001, type 0x3742630e port 0x0534 0x0388 0x0220 0x0000 irq 5:0 drq 1:3 en 1 port 0x0534 0x0388 0x0220 0x0000 irq 5:0 drq 1:3 en 1 mss_attach 1 at 0x530 irq 5 dma 1:3 flags 0x13 pcm1 (CS423x/Yamaha sn 0xffffffff) at 0x530-0x537 irq 5 drq 1 flags 0x13 on isa Probing for devices on the ISA bus: video: RTC equip. code:0x3f, DCC code:0x00 video: CRTC:0x3b4, video option:0x00, rows:80, cols:1, font height:0 video: param table EGA/VGA:0, CGA/MDA:0 video: rows_offset:1 video#0: adapter type:MDA (1), flags:0x0, CRTC:0x3b4 video#0: init mode:7, bios mode:7, current mode:7 video#0: window:0xf00b0000 size:32k gran:32k, buf:0xf0000000 size:0k video#0: mode:7, flags:0x0 T 80x25, font:8x14, win:0xb0000 sc0: the current keyboard controller command byte 0047 kbdio: DIAGNOSE status:0055 kbdio: TEST_KBD_PORT status:0000 kbdio: RESET_KBD return code:00fe kbdio: RESET_KBD return code:00fe kbdio: RESET_KBD return code:00fe kbdio: DIAGNOSE status:0055 kbdio: TEST_KBD_PORT status:0000 sc0: failed to reset the keyboard. sc0 at 0x60-0x6f irq 1 on motherboard sc0: MDA/Hercules <16 virtual consoles, flags=0x0> sio0: irq maps: 0x801 0x811 0x801 0x801 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console sio1: irq maps: 0x801 0x809 0x801 0x801 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A dgb0: PC/Xe 64/8K (windowed) dgb0 at 0x320-0x323 maddr 0xd0000 msize 8192 on isa dgb0: 2 ports mss_probe: no address supplied, try default 0x530 device at 0x530 already attached as unit 1 sb_probe: no address supplied, try defaults (0x220,0x240) device at 0x220 already attached as unit 1 pcm0 not found wdc0 not found at 0x1f0 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold ppc: parallel port found at 0x3bc ppc0: EPP SPP ppc0 at 0x3bc irq 7 on isa ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode nlpt0: on ppbus 0 nlpt0: Interrupt-driven port npx0 on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 124766063 bytes/sec bzero() bandwidth = 138869601 bytes/sec apm0 on isa apm: found APM BIOS version 1.2 imasks: bio c0080040, tty c00708ba, net c00708ba de0: enabling 10baseT port BIOS Geometries: 0:03fe7f20 0..1022=1023 cylinders, 0..127=128 heads, 1..32=32 sectors 1:03d27f20 0..978=979 cylinders, 0..127=128 heads, 1..32=32 sectors 2:03d27f20 0..978=979 cylinders, 0..127=128 heads, 1..32=32 sectors 3:03df3f20 0..991=992 cylinders, 0..63=64 heads, 1..32=32 sectors 0 accounted for Device configuration finished. IP packet filtering initialized, divert enabled, rule-based forwarding disabled, logging disabled bpf: tun0 attached bpf: tun1 attached bpf: sl0 attached bpf: sl1 attached bpf: ppp0 attached bpf: ppp1 attached new masks: bio c0080040, tty c00708ba, net c00708ba bpf: lo0 attached Waiting 2 seconds for SCSI devices to settle bt0: Using Strict Round Robin Mailbox Mode (probe3:bt0:0:3:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe3:bt0:0:3:0): ILLEGAL REQUEST asc:24,0 (probe3:bt0:0:3:0): Invalid field in CDB (probe2:bt0:0:2:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe2:bt0:0:2:0): ILLEGAL REQUEST asc:24,0 (probe2:bt0:0:2:0): Invalid field in CDB (probe5:bt0:0:5:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe5:bt0:0:5:0): ILLEGAL REQUEST asc:24,0 (probe5:bt0:0:5:0): Invalid field in CDB (probe4:bt0:0:4:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe4:bt0:0:4:0): ILLEGAL REQUEST asc:24,0 (probe4:bt0:0:4:0): Invalid field in CDB sks:c8,1 pass0 at bt0 bus 0 target 1 lun 0 pass0: Fixed Direct Access SCSI2 device pass0: Serial Number 6054782534 pass0: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled pass1 at bt0 bus 0 target 2 lun 0 pass1: Fixed Direct Access SCSI1 device pass1: 10.0MB/s transfers (10.0MHz, offset 15) pass2 at bt0 bus 0 target 3 lun 0 pass2: Fixed Direct Access SCSI1 device pass2: 10.0MB/s transfers (10.0MHz, offset 15) pass3 at bt0 bus 0 target 4 lun 0 pass3: Fixed Direct Access SCSI1 device pass3: 4.32MB/s transfers (4.32MHz, offset 15) pass4 at bt0 bus 0 target 5 lun 0 pass4: Removable CD-ROM SCSI2 device pass4: 3.300MB/s transfers pass5 at adv0 bus 0 target 0 lun 0 pass5: Fixed Direct Access SCSI2 device pass5: Serial Number pass5: 20.0MB/s transfers (20.0MHz, offset 15) pass6 at adv0 bus 0 target 1 lun 0 pass6: Fixed Direct Access SCSI2 device pass6: Serial Number U8008JK pass6: 20.0MB/s transfers (20.0MHz, offset 15) pass7 at adv0 bus 0 target 2 lun 0 pass7: Fixed Direct Access SCSI2 device pass7: Serial Number U8004BH pass7: 20.0MB/s transfers (20.0MHz, offset 15) da2 at adv0 bus 0 target 0 lun 0 da2: Fixed Direct Access SCSI2 device da2: Serial Number da2: 20.0MB/s transfers (20.0MHz, offset 15) da2: 2068MB (4236661 512 byte sectors: 255H 63S/T 263C) da1 at adv0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI2 device da1: Serial Number U8008JK da1: 20.0MB/s transfers (20.0MHz, offset 15) da1: 4100MB (8398600 512 byte sectors: 255H 63S/T 522C) da4 at adv0 bus 0 target 2 lun 0 da4: Fixed Direct Access SCSI2 device da4: Serial Number U8004BH da4: 20.0MB/s transfers (20.0MHz, offset 15) da4: 4100MB (8398600 512 byte sectors: 255H 63S/T 522C) da3 at bt0 bus 0 target 2 lun 0 da3: Fixed Direct Access SCSI1 device da3: 10.0MB/s transfers (10.0MHz, offset 15) da3: 1959MB (4014054 512 byte sectors: 128H 32S/T 979C) da0 at bt0 bus 0 target 1 lun 0 da0: Fixed Direct Access SCSI2 device da0: Serial Number 6054782534 da0: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled da0: 2047MB (4193360 512 byte sectors: 128H 32S/T 1023C) cd0 at bt0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI2 device cd0: 3.300MB/s transfers cd0: cd present [275057 x 2048 byte records] da5 at bt0 bus 0 target 4 lun 0 da5: Fixed Direct Access SCSI1 device da5: 4.32MB/s transfers (4.32MHz, offset 15) da5: 992MB (2031705 512 byte sectors: 64H 32S/T 992C) da6 at bt0 bus 0 target 3 lun 0 da6: Fixed Direct Access SCSI1 device da6: 10.0MB/s transfers (10.0MHz, offset 15) da6: 1959MB (4014054 512 byte sectors: 128H 32S/T 979C) Considering FFS root f/s. changing root device to da0s1a --d6Gm4EdcadzBjdND-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 16 8: 9:34 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from bsd.braz.ru (ns.braz.ru [194.84.218.50]) by hub.freebsd.org (Postfix) with ESMTP id BA81114D5F for ; Fri, 16 Apr 1999 08:09:16 -0700 (PDT) (envelope-from mvp@braz.ru) Received: from braz.ru (ppp3.braz.ru [194.84.218.243]) by bsd.braz.ru (8.9.3/8.9.3) with ESMTP id AAA94934; Sat, 17 Apr 1999 00:01:28 +0900 (ISS) Message-ID: <37183FC9.E6D237A5@braz.ru> Date: Fri, 16 Apr 1999 08:01:13 -0800 From: Vadim Mikhailov Organization: Bratsk Aluminium Plant X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: Ulf Zimmermann , "Karsten W. Rohrbach" , freebsd-scsi@freebsd.org Subject: AMI MegaRAID driver for FreeBSD Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Karsten W. Rohrbach" wrote: > okay, so i´ll poke them in the ribs, let´s see what happens next :> > excerpt from linux-2.2.1´s drivers/scsi/megaraid.c: > > * Linux MegaRAID device driver > * > * Copyright 1998 American Megatrends Inc. > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License > * as published by the Free Software Foundation; either version > * 2 of the License, or (at your option) any later version. > * > * Version : 0.92 > * > * Description: Linux device driver for AMI MegaRAID controller > > maybe they insist on implementing it themselves? I found by Altavista that "William Simpson" have written driver for AMI MegaRAID under FreeBSD. I wrote message to him, and his answer follows: > Vadim, > I would suggest the RedHat 5.2 install. It is > officially supported by AMI. And works great! > > The FreeBSD driver has not gone through quality > control, it not ready to be released, and > I am no longer involved with that project. > > Best of Luck, Bill Simpson wcs@neosoft.com >> At 02:36 PM 4/15/99 +0900, you wrote: >>Hello, William C. Simpson! >> >> I've found by Altavista that you have written driver >>for AMI MegaRAID under FreeBSD. I have machine with >>that RAID, and I want install FreeBSD on it. >> And my question to you - is it possible to get this >>driver for FreeBSD, or will you commit it to >>FreeBSD CVS tree? >> If you say no, I will install Linux (RedHat 5.2 >>supports MegaRAID), but I want FreeBSD because of >>its stability and perfomance. >> >>Thanks in advance, Vadim Mikhailov. It is so sad... I want to install FreeBSD, not Linux... With best regards, Vadim Mikhailov. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 17 6:25:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from hpcs14.dv.fal.de (hpcs14e.dv.fal.de [134.110.18.14]) by hub.freebsd.org (Postfix) with ESMTP id 37AC715205 for ; Sat, 17 Apr 1999 06:25:24 -0700 (PDT) (envelope-from kraft@hpcs14.dv.fal.de) Received: (from kraft@localhost) by hpcs14.dv.fal.de (8.9.1/8.9.1) id PAA20765; Sat, 17 Apr 1999 15:22:47 +0200 (MET) From: Martin Kraft Message-Id: <199904171322.PAA20765@hpcs14.dv.fal.de> Subject: Re: i/o error with larger QIC To: mjacob@feral.com Date: Sat, 17 Apr 1999 15:22:47 +0200 (MET) Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: from "Matthew Jacob" at Mar 17, 99 12:12:59 pm Reply-To: martin.kraft@fal.de X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org My problem still exists: I can read QIC DC6150 but not DC 6525. I last CVSup'd 3.1-stable on april 10. Matthew Jacob wrote: > > > Matthew Jacob wrote: > > > > > > > sa0: Removable > > > > .. Sequential Access SCSI-CCS device > > > > sa0: 4.32MB/s transfers (4.32MHz, offset 14) > > > > > > > > I can read DC 6150 tapes (written under 2.2.7) without problems. But it > > > > is impossible to read from a DC 6525: > > This is slightly ambiguous. How were the DC6525 tapes written? > > Maybe also try the tar as 'tar tb 2'. su-2.02# tar tb 2 tar: read error on /dev/rsa0 : Input/output error su-2.02# Doesn't help. The tapes where written under 2.2.7 with "tar -cl". I just tried to write a new tape under 3.1 and write and read it: all operations succeeded without error but with blocksize 512: su-2.02# mt status Mode Density Blocksize bpi Compression Current: QIC-320 512 bytes 16000 unsupported ---------available modes--------- 0: QIC-320 512 bytes 16000 unsupported 1: QIC-320 512 bytes 16000 unsupported 2: QIC-320 512 bytes 16000 unsupported : QIC-320 512 bytes 16000 unsupported --------------------------------- Current Driver State: at rst. --------------------------------- File Number: 0 Record Number: 0 su-2.02# So at this moment, I am able to make new backups and restores, which is the most important thing to me. Anyway I think it would be better, if my drive could read the old tapes, because QIC tapes should be exchangeable between different OSs. Many thanks to everyone contributing to these FreeBSD sources! Martin Kraft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 17 10:10:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from praxis.medicusnet.de (praxis.medicusnet.de [194.74.137.21]) by hub.freebsd.org (Postfix) with ESMTP id D42DC14C84 for ; Sat, 17 Apr 1999 10:10:46 -0700 (PDT) (envelope-from maulwurf@subloch.medicusnet.de) Received: from subloch.medicusnet.de (uucp@localhost) by praxis.medicusnet.de (8.8.8/8.8.7) with UUCP id TAA05695 for freebsd-scsi@freebsd.org; Sat, 17 Apr 1999 19:08:22 +0200 Received: by subloch.medicusnet.de (CrossPoint v3.11 R/C2188); 17 Apr 1999 19:09:05 +0200 Date: 17 Apr 1999 19:08:00 +0200 From: maulwurf@subloch.medicusnet.de (Stefan Huerter) To: freebsd-scsi@freebsd.org Cc: martin.kraft@fal.de Message-ID: <7F2jg1SUoRB@subloch.medicusnet.de> In-Reply-To: <199903162302.BAA13911@hpcs14.dv.fal.de> Subject: Re: i/o error with larger QIC X-Mailer: CrossPoint v3.11 R/C2188 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Organization: die wahre Antwort: 42 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Guckux Martin > I can read DC 6150 tapes (written under 2.2.7) without problems. > But it is impossible to read from a DC 6525: > su-2.02# mt status > Mode Density Blocksize bpi Compression > Current: QIC-320 512 bytes 16000 unsupported I have the same problem with the TDC4222 (2.5GB), I asked one of the programmers and he told me, this problem is in work... So you must set the blocksize for workaround, and great yes, it works for me, also why not for you. Try: mt blocksize 0 This should work for you, too. I hope so :-) Bye Stefan --- Hoffnung ist verantwortlich für den Vorwärtstrieb eines Menschen. Wird diese zerstört, wird am Menschen etwas zerstört. Überlebt er dieses und setzt sich damit auseinander, wird er gestärkt wieder erwachen. (Stefan H.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 17 14:41:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from hpcs14.dv.fal.de (hpcs14e.dv.fal.de [134.110.18.14]) by hub.freebsd.org (Postfix) with ESMTP id B470A14D98 for ; Sat, 17 Apr 1999 14:41:19 -0700 (PDT) (envelope-from kraft@hpcs14.dv.fal.de) Received: (from kraft@localhost) by hpcs14.dv.fal.de (8.9.1/8.9.1) id XAA21214; Sat, 17 Apr 1999 23:38:53 +0200 (MET) From: Martin Kraft Message-Id: <199904172138.XAA21214@hpcs14.dv.fal.de> Subject: Re: i/o error with larger QIC To: maulwurf@subloch.medicusnet.de (Stefan Huerter) Date: Sat, 17 Apr 1999 23:38:52 +0200 (MET) Cc: freebsd-scsi@freebsd.org, mjacob@feral.com In-Reply-To: <7F2jg1SUoRB@subloch.medicusnet.de> from "Stefan Huerter" at Apr 17, 99 07:08:00 pm Reply-To: martin.kraft@fal.de X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Matthew and Stefan, thanks for your assistance! Stefan Huerter wrote: > > Try: > mt blocksize 0 > This should work for you, too. I hope so :-) What's that?!?!?! I typed "mt blocksize 0", and -- the first time -- I could tar -t and tar -x a file from my old DC 6525. Great! So far :-( I extracted a small file close to the beginning of the tape. It took just a few seconds (as usual) and the file was on my disk. But after that, the tape didn't rewind and stop, as it did in former time, it now is rewinding forwards and backwards since more than 30 minutes. What a surprise Martin Kraft P.S. 35 minutes. Just another turn. I will kill the tar process, because I don't have a fire extinguisher at home ... Very strange ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 17 14:51:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id CDE8614F2D for ; Sat, 17 Apr 1999 14:51:28 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id OAA13186; Sat, 17 Apr 1999 14:48:52 -0700 Date: Sat, 17 Apr 1999 14:48:52 -0700 (PWT) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: martin.kraft@fal.de Cc: Stefan Huerter , freebsd-scsi@FreeBSD.ORG Subject: Re: i/o error with larger QIC In-Reply-To: <199904172138.XAA21214@hpcs14.dv.fal.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hello Matthew and Stefan, > > thanks for your assistance! > > Stefan Huerter wrote: > > > > Try: > > mt blocksize 0 > > This should work for you, too. I hope so :-) > > What's that?!?!?! > > I typed "mt blocksize 0", and -- the first time -- I could tar -t and > tar -x a file from my old DC 6525. Great! So far :-( > > I extracted a small file close to the beginning of the tape. It took > just a few seconds (as usual) and the file was on my disk. > > But after that, the tape didn't rewind and stop, as it did in former time, > it now is rewinding forwards and backwards since more than 30 minutes. This is what I'm worried about. If you're in *variable* mode, the drive is faking it. QIC is a fixed block format. If you set it to variable mode, I think it tries to guess the block layout, and it sounds like it's having a rough go of it. > > What a surprise > > Martin Kraft > > > P.S. 35 minutes. Just another turn. I will kill the tar process, because > I don't have a fire extinguisher at home ... Very strange ... > Do you remember what blocksize you *wrote* these tapes with? If you do, set the blocksize for the drive fixed at that size and try read with the tar command (setting to the blocksize you used to write the tape). I really wish I had manuals for this drive so I could try and figure what they're trying to do. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 17 15: 5:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from praxis.medicusnet.de (praxis.medicusnet.de [194.74.137.21]) by hub.freebsd.org (Postfix) with ESMTP id 38F0C1540F for ; Sat, 17 Apr 1999 15:05:27 -0700 (PDT) (envelope-from maulwurf@subloch.medicusnet.de) Received: from subloch.medicusnet.de (uucp@localhost) by praxis.medicusnet.de (8.8.8/8.8.7) with UUCP id AAA14528 for freebsd-scsi@freebsd.org; Sun, 18 Apr 1999 00:03:03 +0200 Received: by subloch.medicusnet.de (CrossPoint v3.11 R/C2188); 18 Apr 1999 00:03:33 +0200 Date: 18 Apr 1999 00:03:00 +0200 From: maulwurf@subloch.medicusnet.de (Stefan Huerter) To: freebsd-scsi@freebsd.org Cc: martin.kraft@fal.de Cc: joerg_wunsch@uriah.heep.sax.de Cc: mjacob@feral.com Message-ID: <7F6naWfzoRB@subloch.medicusnet.de> In-Reply-To: <199904172138.XAA21214@hpcs14.dv.fal.de> Subject: Re: i/o error with larger QIC X-Mailer: CrossPoint v3.11 R/C2188 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Organization: die wahre Antwort: 42 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Guckux Martin > thanks for your assistance! no problem, but now I will including another cc: to Joerg, perhaps he can help you. > Stefan Huerter wrote: > > Try: > > mt blocksize 0 > > This should work for you, too. I hope so :-) > What's that?!?!?! > I typed "mt blocksize 0", and -- the first time -- I could tar -t > and tar -x a file from my old DC 6525. Great! So far :-( I have only extracted the whole tape content... > I extracted a small file close to the beginning of the tape. It > took just a few seconds (as usual) and the file was on my disk. > > But after that, the tape didn't rewind and stop, as it did in > former time, it now is rewinding forwards and backwards since more > than 30 minutes. > > What a surprise > > Martin Kraft > > > P.S. 35 minutes. Just another turn. I will kill the tar process, > because I don't have a fire extinguisher at home ... Very strange > ... Joerg, has you any hints? Sorry for setting unasked the CC: Bye Stefan --- Hoffnung ist verantwortlich für den Vorwärtstrieb eines Menschen. Wird diese zerstört, wird am Menschen etwas zerstört. Überlebt er dieses und setzt sich damit auseinander, wird er gestärkt wieder erwachen. (Stefan H.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 17 15:10:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from praxis.medicusnet.de (praxis.medicusnet.de [194.74.137.21]) by hub.freebsd.org (Postfix) with ESMTP id E1F9215351 for ; Sat, 17 Apr 1999 15:10:12 -0700 (PDT) (envelope-from maulwurf@subloch.medicusnet.de) Received: from subloch.medicusnet.de (uucp@localhost) by praxis.medicusnet.de (8.8.8/8.8.7) with UUCP id AAA14655 for freebsd-scsi@freebsd.org; Sun, 18 Apr 1999 00:07:48 +0200 Received: by subloch.medicusnet.de (CrossPoint v3.11 R/C2188); 18 Apr 1999 00:08:36 +0200 Date: 18 Apr 1999 00:08:00 +0200 From: maulwurf@subloch.medicusnet.de (Stefan Huerter) To: freebsd-scsi@freebsd.org Cc: mjacob@feral.com Cc: joerg_wunsch@uriah.heep.sax.de Cc: martin.kraft@fal.de Message-ID: <7F6ncL5zoRB@subloch.medicusnet.de> In-Reply-To: Subject: Re: i/o error with larger QIC X-Mailer: CrossPoint v3.11 R/C2188 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: die wahre Antwort: 42 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Guckux Matthew > > What's that?!?!?! > > > > I typed "mt blocksize 0", and -- the first time -- I could tar -t > > and tar -x a file from my old DC 6525. Great! So far :-( > > > > I extracted a small file close to the beginning of the tape. It > > took just a few seconds (as usual) and the file was on my disk. > > > > But after that, the tape didn't rewind and stop, as it did in > > former time, it now is rewinding forwards and backwards since > > more than 30 minutes. > > This is what I'm worried about. If you're in *variable* mode, the > drive is faking it. QIC is a fixed block format. If you set it to > variable mode, I think it tries to guess the block layout, and it > sounds like it's having a rough go of it. > > > > > What a surprise > > > > Martin Kraft > > > > > > P.S. 35 minutes. Just another turn. I will kill the tar process, > > because I don't have a fire extinguisher at home ... Very strange > > ... > > > > Do you remember what blocksize you *wrote* these tapes with? If you > do, set the blocksize for the drive fixed at that size and try > read with the tar command (setting to the blocksize you used to > write the tape). I really wish I had manuals for this drive so I > could try and figure what they're trying to do. I made a few tests before I get this tip from Joerg, so I tried to use tar with the blocksize of 10240bytes, but this won't work. I get only I/O errors... Bye Stefan --- Hoffnung ist verantwortlich fuer den Vorwaertstrieb eines Menschen. Wird diese zerstoert, wird am Menschen etwas zerstoert. Ueberlebt er dieses und setzt sich damit auseinander, wird er gestaerkt wieder erwachen. (Stefan H.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 17 15:22: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 8C61E15411 for ; Sat, 17 Apr 1999 15:22:04 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id PAA13296; Sat, 17 Apr 1999 15:19:36 -0700 Date: Sat, 17 Apr 1999 15:19:36 -0700 (PWT) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Stefan Huerter Cc: freebsd-scsi@FreeBSD.ORG, joerg_wunsch@uriah.heep.sax.de, martin.kraft@fal.de Subject: Re: i/o error with larger QIC In-Reply-To: <7F6ncL5zoRB@subloch.medicusnet.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > Do you remember what blocksize you *wrote* these tapes with? If you > > do, set the blocksize for the drive fixed at that size and try > > read with the tar command (setting to the blocksize you used to > > write the tape). I really wish I had manuals for this drive so I > > could try and figure what they're trying to do. > > > I made a few tests before I get this tip from Joerg, so I tried to use tar > with the blocksize of 10240bytes, but this won't work. I get only I/O > errors... Well, I guess I'll need to get manuals for these drives to see how they 'support' variable mode then.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 18 4:57:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (Postfix) with ESMTP id 5CF9E14D63 for ; Sun, 18 Apr 1999 04:57:43 -0700 (PDT) (envelope-from dgraef@ibm.net) Received: from slip139-92-13-32.aug.de.ibm.net (slip139-92-13-32.aug.de.ibm.net [139.92.13.32]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id LAA103896 for ; Sun, 18 Apr 1999 11:55:13 GMT Message-Id: <199904181155.LAA103896@out1.ibm.net> From: "detlef graef" To: "freebsd-scsi@freebsd.org" Date: Sun, 18 Apr 99 13:54:36 Reply-To: "detlef graef" X-Mailer: PMMail 1.95a For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Tekram DC390 driver for FreeBSD 3.x Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I've tried to install FreeBSD 3.0 with the new CAMified driver for the Tekram DC390 SCSI adapter. The kernel doesn't wait for the SCSI devices to settle, and then the driver doesn't "see" all devices that are connected to the bus. So I have no access to some devices. The kernel says "waiting 15 sec. for SCSI devises ..." but the kernel doesn't actually wait. The *same* kernel (with support for the 2940 and DC390) waits when a 2940 is installed. Why could this be? The code that makes the kernel to wait is not implemented in the driver. Why are there differences in the behaviour with different controllers? With best regards, D. Graef To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 18 6:21:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 93119151A6 for ; Sun, 18 Apr 1999 06:21:20 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id OAA86580; Sun, 18 Apr 1999 14:23:52 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 18 Apr 1999 14:23:52 +0100 (BST) From: Doug Rabson To: detlef graef Cc: "freebsd-scsi@freebsd.org" Subject: Re: Tekram DC390 driver for FreeBSD 3.x In-Reply-To: <199904181155.LAA103896@out1.ibm.net> 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 Sun, 18 Apr 1999, detlef graef wrote: > Hello, > > I've tried to install FreeBSD 3.0 with the new CAMified driver > for the Tekram DC390 SCSI adapter. > The kernel doesn't wait for the SCSI devices to settle, and then > the driver doesn't "see" all devices that are connected to the bus. > So I have no access to some devices. > > The kernel says "waiting 15 sec. for SCSI devises ..." but the kernel > doesn't actually wait. > > The *same* kernel (with support for the 2940 and DC390) waits when > a 2940 is installed. Why could this be? The code that makes the kernel > to wait is not implemented in the driver. Why are there differences > in the behaviour with different controllers? I have noticed this behaviour with the vpo driver as well. I tried to look into it once but I got lost inside xpt :-). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 18 10:41:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 33CAC14C46 for ; Sun, 18 Apr 1999 10:41:57 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral.com (8.8.7/8.8.7) with ESMTP id KAA15919; Sun, 18 Apr 1999 10:39:18 -0700 Date: Sun, 18 Apr 1999 10:39:17 -0700 (PWT) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: detlef graef Cc: "freebsd-scsi@freebsd.org" Subject: Re: Tekram DC390 driver for FreeBSD 3.x In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I've tried to install FreeBSD 3.0 with the new CAMified driver > > for the Tekram DC390 SCSI adapter. > > The kernel doesn't wait for the SCSI devices to settle, and then > > the driver doesn't "see" all devices that are connected to the bus. > > So I have no access to some devices. > > > > The kernel says "waiting 15 sec. for SCSI devises ..." but the kernel > > doesn't actually wait. Really? It waits for me... So much so that I trimmed the wait down... > > > > The *same* kernel (with support for the 2940 and DC390) waits when > > a 2940 is installed. Why could this be? The code that makes the kernel > > to wait is not implemented in the driver. Why are there differences > > in the behaviour with different controllers? > If the HBA doesn't report a BUS RESET back to CAM via an xpt_async call, the simq won't get frozen for SCSI_DELAY milliseconds. This call occurs both as driven by the driver when a XPT_RESET_BUS gets thrown at it and also when an aynchronous bus reset is detected. Also, if the hba's hba_misc has PIM_NOBUSRESET set, no initial bus reset will be done. Which is the Tekram driver? I don't notice it anywhere.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 18 10:51:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by hub.freebsd.org (Postfix) with ESMTP id D751E14F79 for ; Sun, 18 Apr 1999 10:51:12 -0700 (PDT) (envelope-from dgraef@ibm.net) Received: from slip139-92-13-70.aug.de.ibm.net (slip139-92-13-70.aug.de.ibm.net [139.92.13.70]) by out1.ibm.net (8.8.5/8.6.9) with SMTP id RAA100346; Sun, 18 Apr 1999 17:48:43 GMT Message-Id: <199904181748.RAA100346@out1.ibm.net> From: "detlef graef" To: "mjacob@feral.com" Cc: "freebsd-scsi@FreeBSD.ORG" Date: Sun, 18 Apr 99 19:49:14 Reply-To: "detlef graef" X-Mailer: PMMail 1.95a For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Tekram DC390 driver for FreeBSD 3.x Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, On Sun, 18 Apr 1999 10:39:17 -0700 (PWT), Matthew Jacob wrote: >> > The *same* kernel (with support for the 2940 and DC390) waits when >> > a 2940 is installed. Why could this be? The code that makes the kernel >> > to wait is not implemented in the driver. Why are there differences >> > in the behaviour with different controllers? >> > >If the HBA doesn't report a BUS RESET back to CAM via an xpt_async call, >the simq won't get frozen for SCSI_DELAY milliseconds. This call occurs >both as driven by the driver when a XPT_RESET_BUS gets thrown at it and >also when an aynchronous bus reset is detected. > >Also, if the hba's hba_misc has PIM_NOBUSRESET set, no initial bus reset >will be done. Ok, but this problem I couldn't solve shortly... I'm not a skilled Programmer. >Which is the Tekram driver? I don't notice it anywhere.... You can get it at ftp.tekram.com There is a boot floppy etc. With best regards, D. Graef To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 19 12:35: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by hub.freebsd.org (Postfix) with ESMTP id AB662155CC for ; Mon, 19 Apr 1999 12:34:39 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.56.237]) by smtp01.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA19C5; Mon, 19 Apr 1999 21:26:49 +0200 Received: from daemon.ninth-circle.org (abaddon@daemon [192.168.0.1]) by daemon.ninth-circle.org (8.9.3/8.9.3) with ESMTP id VAA00564; Mon, 19 Apr 1999 21:26:48 +0200 (CEST) (envelope-from asmodai@wxs.nl) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <37183FC9.E6D237A5@braz.ru> Date: Mon, 19 Apr 1999 21:26:47 +0200 (CEST) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: Vadim Mikhailov Subject: RE: AMI MegaRAID driver for FreeBSD Cc: freebsd-scsi@freebsd.org, "Karsten W. Rohrbach" , Ulf Zimmermann Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 16-Apr-99 Vadim Mikhailov wrote: > I found by Altavista that "William Simpson" > have written driver for AMI MegaRAID under FreeBSD. > I wrote message to him, and his answer follows: Funny thing... Guess what is laying on my desk and whom I have been speaking with? =) Correct: one AMI MegaRAID, and been talking to AMI, LSILogic and the two SCSI guru's I know: Kenneth and Justin... How long can you hold off Vadim before ye need this card? I'll try to get it working ASAP time and my noviceness on driverlevel permitting... --- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The FreeBSD Programmer's Documentation Project Network/Security Specialist *BSD: Powered by Knowledge & Know-how To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 19 17: 3:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from bsd.braz.ru (ns.braz.ru [194.84.218.50]) by hub.freebsd.org (Postfix) with ESMTP id 69AAB152D9 for ; Mon, 19 Apr 1999 17:03:11 -0700 (PDT) (envelope-from mvp@braz.ru) Received: from braz.ru (mvp.braz.ru [194.84.218.1]) by bsd.braz.ru (8.9.3/8.9.3) with ESMTP id JAA22953; Tue, 20 Apr 1999 09:00:37 +0900 (ISS) Message-ID: <371BC3AD.E1C49647@braz.ru> Date: Tue, 20 Apr 1999 09:00:45 +0900 From: Vadim Mikhailov X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jeroen Ruigrok/Asmodai Cc: freebsd-scsi@freebsd.org, "Karsten W. Rohrbach" Subject: Re: AMI MegaRAID driver for FreeBSD References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jeroen Ruigrok/Asmodai wrote: > > I found by Altavista that "William Simpson" > > have written driver for AMI MegaRAID under FreeBSD. > > I wrote message to him, and his answer follows: > > How long can you hold off Vadim before ye need this card? I have to install any working unix-like OS to that server in a month. It working under NT now, and I want to drop NT. Because I have 4 years experience with FreeBSD and have negative experience with Linux, of course I want to deal with FreeBSD. > I'll try to get it working ASAP time and my noviceness > on driverlevel permitting... May be I can help you with beta testing? With best regards, Vadim Mikhailov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 19 17:12:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from hawkwind.ncsa.uiuc.edu (hawkwind.ncsa.uiuc.edu [141.142.21.154]) by hub.freebsd.org (Postfix) with ESMTP id 7532A14DCF for ; Mon, 19 Apr 1999 17:12:39 -0700 (PDT) (envelope-from koziol@hawkwind.ncsa.uiuc.edu) Received: (from koziol@localhost) by hawkwind.ncsa.uiuc.edu (8.9.3/8.9.2) id TAA10704 for freebsd-scsi@freebsd.org; Mon, 19 Apr 1999 19:09:20 -0500 (CDT) (envelope-from koziol) Message-Id: <199904200009.TAA10704@hawkwind.ncsa.uiuc.edu> Subject: Re: AMI MegaRAID driver for FreeBSD In-Reply-To: <371BC3AD.E1C49647@braz.ru> from Vadim Mikhailov at "Apr 20, 1999 9: 0:45 am" To: freebsd-scsi@freebsd.org Date: Mon, 19 Apr 1999 19:09:20 -0500 (CDT) From: koziol@ncsa.uiuc.edu Reply-To: koziol@ncsa.uiuc.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Howdy, It turns out that I've also got a system running NT with one of these AMI MegaRAID controllers in it that I'd like to use with FreeBSD. I'll beta test also, if you can get me the code you write. Regards, Quincey Koziol koziol@ncsa.uiuc.edu > Jeroen Ruigrok/Asmodai wrote: > > > > I found by Altavista that "William Simpson" > > > have written driver for AMI MegaRAID under FreeBSD. > > > I wrote message to him, and his answer follows: > > > > How long can you hold off Vadim before ye need this card? > > I have to install any working unix-like OS to that server in a month. > It working under NT now, and I want to drop NT. Because I have 4 years > experience with FreeBSD and have negative experience with Linux, > of course I want to deal with FreeBSD. > > > I'll try to get it working ASAP time and my noviceness > > on driverlevel permitting... > > May be I can help you with beta testing? > > With best regards, Vadim Mikhailov > > > 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 Mon Apr 19 17:47:37 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from blaubaer.kn-bremen.de (blaubaer.kn-bremen.de [194.94.232.249]) by hub.freebsd.org (Postfix) with ESMTP id 7C77014D1A; Mon, 19 Apr 1999 17:47:30 -0700 (PDT) (envelope-from nox@saturn.kn-bremen.de) Received: from saturn.kn-bremen.de (uucp@localhost) by blaubaer.kn-bremen.de (8.9.1/8.9.1) with UUCP id CAA10961; Tue, 20 Apr 1999 02:40:40 +0200 Received: (from nox@localhost) by saturn.kn-bremen.de (8.9.3/8.8.5) id CAA21920; Tue, 20 Apr 1999 02:39:55 +0200 (MET DST) From: Juergen Lock Date: Tue, 20 Apr 1999 02:39:54 +0200 To: freebsd-stable@FreeBSD.ORG Cc: freebsd-scsi@FreeBSD.ORG Subject: hanging `tar xfvR /dev/nrst0' process, can i debug it? Message-ID: <19990420023954.A20589@saturn.kn-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Cc'd to -scsi, subscription is on the way...] bash# tar xfvR /dev/nrst0 tar: rec 0: read error on /dev/nrst0 : Input/output error ^C [other xterm:] bash# ps -xawl|grep tar 0 20103 19849 4 -6 0 940 516 piperd S+ p1 0:00.03 grep tar 0 19838 18532 0 -6 0 436 192 cgticb DE+ p8 0:00.00 (tar) The tape drive is silent, all other targets on the bus can be accessed without problems. I have positioned the tape with a script thats doing camcontrol cmd -u 0 -n sa -t 3000 -c "2b 4 0 v v v v 0 0 0" 0x$c3 0x$c2 0x$c1 0x$c0 (thats the LOCATE command if i remember right, it worked as expected) could that have someting to do with it? Normally i would just reboot but maybe there is something i can check to help isolate the problem? System is 3.1-stable, checked out Apr 10 (cvs-cur.5224), DDB is in the kernel and i can rebuild it with -g (or so i think. :) Awaiting instructions... -- Juergen Lock To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 19 21:29:53 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (nat192.236.mpoweredpc.net [142.177.192.236]) by hub.freebsd.org (Postfix) with ESMTP id 6D8F5155FE for ; Mon, 19 Apr 1999 21:29:50 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id BAA64191 for ; Tue, 20 Apr 1999 01:27:28 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Tue, 20 Apr 1999 01:27:28 -0300 (ADT) From: The Hermit Hacker To: freebsd-scsi@freebsd.org Subject: -STABLE isn't stable - SCSI *and* Ethernet ... 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 Wow...what a mistake this past couple of days have been...the other day, figuring that after ~3months, it might be time to re-sync with -STABLE, figuring that, by its very name, this should be a safe thing to do... ...what a rude awakening I've had :( First off, the xl driver has recently been broken...Bill Paul has so far produced two patches in an attempt to fix them, but...its -STABLE...why should it have broken in the first place? The breakage, which has been reported by one other who tried a similar upgrade, is that after a random period of time, the ethernet's go completely dead and require a reboot to fix :( Bill's latest fix has been reported as "hanging the machine on boot"... 5 minutes ago, I had a new joy: Apr 19 23:34:50 hub /kernel: vm_fault: pager read error, pid 73235 (sendmail) Apr 19 23:34:50 hub /kernel: swap_pager: I/O error - pagein failed; blkno 520, size 4096, error 6 And my /home directory just totally disappeared...I just rebooted back up into my old kernel, and all drives fsck'd fine, and so far, no problems... These are the kinds of things I expect on my home machine, running 4.0-CURRENT...not my production machine running 3.1-STABLE :( Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.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 20 0:40:17 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pelican.sms.fi (pelican.sms.fi [192.58.51.9]) by hub.freebsd.org (Postfix) with ESMTP id 5039014C1B for ; Tue, 20 Apr 1999 00:40:12 -0700 (PDT) (envelope-from pete@sms.fi) Received: from sms.fi (thrush.sms.fi [192.58.51.24]) by pelican.sms.fi (8.9.2/8.9.2) with ESMTP id KAA46850 for ; Tue, 20 Apr 1999 10:37:45 +0300 (EEST) (envelope-from pete@sms.fi) Message-ID: <371C2E30.F7E899DC@sms.fi> Date: Tue, 20 Apr 1999 10:35:12 +0300 From: Petri Helenius X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: tagged queuing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm having problems with a toshiba drive and I'd like to know if there is a way to disable tagged queuing either globally or on target basis on 3.1/4.0 ? Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 20 4:22:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from sand2.sentex.ca (sand2.sentex.ca [209.167.248.3]) by hub.freebsd.org (Postfix) with ESMTP id F257715359 for ; Tue, 20 Apr 1999 04:22:11 -0700 (PDT) (envelope-from mike@sentex.net) Received: from gravel (ospf-wat.sentex.net [209.167.248.81]) by sand2.sentex.ca (8.8.8/8.8.8) with SMTP id HAA05287 for ; Tue, 20 Apr 1999 07:19:44 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <4.1.19990420072456.04ffc960@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 20 Apr 1999 07:29:26 -0400 To: freebsd-scsi@FreeBSD.ORG From: Mike Tancsa Subject: Re: -STABLE isn't stable - SCSI *and* Ethernet ... In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:27 AM 4/20/99 , The Hermit Hacker wrote: > > >Wow...what a mistake this past couple of days have been...the other day, >figuring that after ~3months, it might be time to re-sync with -STABLE, >figuring that, by its very name, this should be a safe thing to do... Did you do an upgrade, or a fresh install ? I have a couple of machines in production that are on the STABLE branch and so far so good. But they use the a 2940U2W and the fxp cards. Apart from the very dangerous DOS still there they have been humming along (knock on wood). But since they are for internal use only (i.e. the general customer population do not have access to them) I am not too worried. What SCSI controller are you using ? ---Mike ********************************************************************** Mike Tancsa, Network Admin * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 01.519.651.3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 20 4:24:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from kobra.efd.lth.se (kobra.efd.lth.se [130.235.34.36]) by hub.freebsd.org (Postfix) with ESMTP id 0AF981510C for ; Tue, 20 Apr 1999 04:24:49 -0700 (PDT) (envelope-from f98bs@efd.lth.se) Received: from efd.lth.se (f98bs@val-1.efd.lth.se [130.235.35.143]) by kobra.efd.lth.se (8.8.8/8.8.8) with ESMTP id NAA06164 for ; Tue, 20 Apr 1999 13:22:22 +0200 (MET DST) Message-Id: <199904201122.NAA06164@kobra.efd.lth.se> To: freebsd-scsi@freebsd.org Subject: AHA-1520B and CAM? Date: Tue, 20 Apr 1999 13:22:22 +0200 From: Bjorn Smedman MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is anybody working on porting the old aic driver to the CAM subsystem? If so, what timescale are we talking here? Next week? Next year? I would really like to use FreeBSD/CAM with my Adaptec AHA-1520B for burning CD-R's, but as it is now I'm stuck with Linux or getting a new controller to replace a perfectly sufficient one. -- Björn Smedman, f98bs@efd.lth.se "The most incomprehensible thing about the world is that it is comprehensible." - Albert Einstein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 20 4:38:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id B55CE14BE6 for ; Tue, 20 Apr 1999 04:38:10 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elpc36.jrc.it (elpc36.jrc.it [139.191.71.36]) by mrelay.jrc.it (LMC5692) with SMTP id NAA29010 for ; Tue, 20 Apr 1999 13:39:33 +0200 (MET DST) Date: Tue, 20 Apr 1999 13:35:43 +0200 (CEST) From: Nick Hibma X-Sender: n_hibma@elpc36.jrc.it Reply-To: Nick Hibma To: freebsd-scsi@FreeBSD.ORG Subject: Re: AHA-1520B and CAM? In-Reply-To: <199904201122.NAA06164@kobra.efd.lth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org While on the topic of CAM, how manym bits are missing from CAM for the disconnection of a SIM? The vpo driver has been adapted to support USB Zip drives and issues a=20 =09xpt_bus_deregister() to do this. This function is however not implemented: cam_xpt.c: file 1/1 line 4027 byte 106112/157518 pct 67% int32_t xpt_bus_deregister(path_id) u_int8_t path_id; { /* XXX */ return (CAM_SUCCESS); } Cheers, Nick On Tue, 20 Apr 1999, Bjorn Smedman wrote: > Is anybody working on porting the old aic driver to the CAM subsystem? > If so, what timescale are we talking here? Next week? Next year? >=20 > I would really like to use FreeBSD/CAM with my Adaptec AHA-1520B for bur= ning > CD-R's, but as it is now I'm stuck with Linux or getting a new controlle= r to > replace a perfectly sufficient one. >=20 > -- > Bj=F6rn Smedman, f98bs@efd.lth.se > "The most incomprehensible thing about the world is that it is comprehen= sible." > - Albert Einstei= n >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 20 7:43:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 5793D14F63 for ; Tue, 20 Apr 1999 07:43:24 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id IAA01839; Tue, 20 Apr 1999 08:31:11 -0600 (MDT) Date: Tue, 20 Apr 1999 08:31:11 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199904201431.IAA01839@narnia.plutotech.com> To: Petri Helenius Cc: scsi@FreeBSD.org Subject: Re: tagged queuing X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <371C2E30.F7E899DC@sms.fi> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <371C2E30.F7E899DC@sms.fi> you wrote: > > I'm having problems with a toshiba drive and I'd like to know if there > is a way > to disable tagged queuing either globally or on target basis on 3.1/4.0 > ? > > Pete See the 'quirk' entries in /usr/src/sys/cam/cam_xpt.c. Search for 'broken'. 8-) -- 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 20 7:46:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 98F0C14F63 for ; Tue, 20 Apr 1999 07:46:57 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id IAA01848; Tue, 20 Apr 1999 08:34:37 -0600 (MDT) Date: Tue, 20 Apr 1999 08:34:37 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199904201434.IAA01848@narnia.plutotech.com> To: The Hermit Hacker Cc: scsi@FreeBSD.org Subject: Re: -STABLE isn't stable - SCSI *and* Ethernet ... X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 5 minutes ago, I had a new joy: > > Apr 19 23:34:50 hub /kernel: vm_fault: pager read error, pid 73235 > (sendmail) > Apr 19 23:34:50 hub /kernel: swap_pager: I/O error - pagein failed; blkno > 520, size 4096, error 6 If you'd like some help instead of just griping, it would be useful to know: 1) What your hardware configuration is. 2) What other messages were displayed on the console before the single message you recounted. 3) What kind of activity your system sees at ~23:30 that might have helped to instigate the problem so a developer has an idea of how to reproduce your problem. -- 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 20 8:35:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gate.lustig.com (gate.lustig.com [205.246.2.242]) by hub.freebsd.org (Postfix) with SMTP id B952614FD4 for ; Tue, 20 Apr 1999 08:35:41 -0700 (PDT) (envelope-from barry@lustig.com) Received: (qmail 19433 invoked from network); 20 Apr 1999 15:33:17 -0000 Received: from devious.lustig.com (205.246.2.244) by gate.lustig.com with SMTP; 20 Apr 1999 15:33:17 -0000 Received: (qmail 2119 invoked by uid 1001); 20 Apr 1999 15:33:15 -0000 Message-ID: <19990420153315.2118.qmail@devious.lustig.com> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 4.2mach v148) X-Nextstep-Mailer: Mail 4.2mach (Enhance 2.2p1) Received: by NeXT.Mailer (1.148.RR) From: Barry Lustig Date: Tue, 20 Apr 1999 11:33:14 -0400 To: stable@freebsd.org, scsi@freebsd.org Subject: SCSI Failure during Amanda Backup (Unexpected busfree) Reply-To: barry@Lustig.COM X-Organizations: Barry Lustig & Associates, Inc. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org First the problem: Starting on 4/3, my amanda backups have started failing. At the point of failure the following appears on the console: (sa0:ahc0:0:5:0): SCB 0x4 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 (sa0:ahc0:0:5:0): Queuing a BDR SCB (sa0:ahc0:0:5:0): Bus Device Reset Message Sent (sa0:ahc0:0:5:0): no longer in timeout, status = 34b ahc0: Bus Device Reset on A:5. 1 SCBs aborted Unexpected busfree. LASTPHASE == 0x0 SEQADDR == 0x5d My system consists of an Asus P2B-DS motherboard: ahc0: rev 0x00 int a irq 19 on pci0.6.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs sa0 at ahc0 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 15) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) cd0 at ahc0 bus 0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 16) cd0: cd present [101210 x 2048 byte records] Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1a 127023 23582 93280 20% / /dev/da0s1h 1688711 861751 691864 55% /usr /dev/da0s1g 508143 448475 34261 93% /usr/obj /dev/da0s1f 1016303 706570 228429 76% /usr/ports /dev/da0s1e 254063 126773 106965 54% /var /dev/da1s1e 17369075 10515107 5464442 66% /d1 Remote machine: /dev/sd0a 998204 729067 239190 75% / I am using all 3 SCSI connectors on the motherboard. The 50 pin connector connects only the CDROM, which is properly terminated. The 68pin Ultra connector goes to the back of the machine where the DLT connects to it via a cable. It also, is properly terminated. The 2 disk drives are internal and are connected to the Ultra2 connector with the Adaptec Ultra2 cable (with terminator on the end). I've upgraded the firmware in the DLT to the latest available on the Quantum ftp site. Amanda backs up the remote machine and all partitions other than da1s1e to /d1/dumps and then dumps that to tape. This part of the backup works fine. The problem occurs when amanda is backing up da1s1e directly to tape, sometime during the dump it fails. I've seen anywhere from 3 to 7 GB dumped sucessfully before the failure. This same setup had been running without problems for months. Any ideas as to what is happening? I am running 3.1 Stable cvsupped on 4/17. Thanks, barry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 20 12:10:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id B443414FB4; Tue, 20 Apr 1999 12:08:59 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA30978; Tue, 20 Apr 1999 20:38:06 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.6.12) id UAA00793; Tue, 20 Apr 1999 20:18:34 +0200 (CEST) From: Wilko Bulte Message-Id: <199904201818.UAA00793@yedi.iaf.nl> Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) In-Reply-To: <19990420153315.2118.qmail@devious.lustig.com> from Barry Lustig at "Apr 20, 1999 11:33:14 am" To: barry@lustig.com Date: Tue, 20 Apr 1999 20:18:34 +0200 (CEST) Cc: stable@FreeBSD.ORG, scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Barry Lustig wrote ... > First the problem: Starting on 4/3, my amanda backups have started > failing. At the point of failure the following appears on the console: > > (sa0:ahc0:0:5:0): SCB 0x4 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > (sa0:ahc0:0:5:0): Queuing a BDR SCB > (sa0:ahc0:0:5:0): Bus Device Reset Message Sent > (sa0:ahc0:0:5:0): no longer in timeout, status = 34b > ahc0: Bus Device Reset on A:5. 1 SCBs aborted > Unexpected busfree. LASTPHASE == 0x0 > SEQADDR == 0x5d > > My system consists of an Asus P2B-DS motherboard: > > ahc0: > rev 0x00 int a irq 19 on pci0.6.0 > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs > > sa0 at ahc0 bus 0 target 5 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 10.000MB/s transfers (10.000MHz, offset 15) > da1 at ahc0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-3 device > da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), > Tagged Queueing Enabled > da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) > changing root device to da0s1a > da0 at ahc0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > cd0 at ahc0 bus 0 target 6 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 10.000MB/s transfers (10.000MHz, offset 16) > cd0: cd present [101210 x 2048 byte records] > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1a 127023 23582 93280 20% / > /dev/da0s1h 1688711 861751 691864 55% /usr > /dev/da0s1g 508143 448475 34261 93% /usr/obj > /dev/da0s1f 1016303 706570 228429 76% /usr/ports > /dev/da0s1e 254063 126773 106965 54% /var > /dev/da1s1e 17369075 10515107 5464442 66% /d1 > > Remote machine: > /dev/sd0a 998204 729067 239190 75% / > > > I am using all 3 SCSI connectors on the motherboard. The 50 pin connector Wrong. This is one SCSI bus as far as I can see. SCSI buses are linear things, not star shaped. And they have only 2 terminators, each on every end of the bus. So: T=terminator D=scsi device H= hostadapter T-------D--------H--------D-------T is OK T-------D--------H--------D-------T | D | T is definitely wrong. To add to that using external and internal (flat) cables is generally not recommended, especially not on Ultra (or faster) buses. Configure things correctly and try again. BTW I recommend putting the DLT on it's own bus. It likes that (for speed). Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 Tue Apr 20 12:20:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id EB8D914CEA; Tue, 20 Apr 1999 12:20:16 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.8.8/8.8.8) with ESMTP id MAA29154; Tue, 20 Apr 1999 12:17:41 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Date: Tue, 20 Apr 1999 12:17:41 -0700 (PDT) From: Doug White To: Mike Tancsa Cc: questions@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahc0: WARNING no command for scb # In-Reply-To: <4.1.19990415201543.041e14c0@granite.sentex.ca> 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 Thu, 15 Apr 1999, Mike Tancsa wrote: > > Hi, > On a 2.2-STABLE machine that is about 90 days old, I saw a whole mess of > > ahc0: WARNING no command for scb 7 (cmdcmplt) > QOUTCNT == 8 > ahc0: WARNING no command for scb 7 (cmdcmplt) > QOUTCNT == 7 > ahc0: WARNING no command for scb 7 (cmdcmplt) > QOUTCNT == 6 > ahc0: WARNING no command for scb 7 (cmdcmplt) > QOUTCNT == 5 > ahc0: WARNING no command for scb 7 (cmdcmplt) > QOUTCNT == 4 > ahc0: WARNING no command for scb 7 (cmdcmplt) > QOUTCNT == 3 > ahc0: WARNING no command for scb 7 (cmdcmplt) > QOUTCNT == 2 > ahc0: WARNING no command for scb 7 (cmdcmplt) > QOUTCNT == 1 A bunch of commads were dropped, it appears. maybe a disk was having a problem? Doug White Internet: dwhite@resnet.uoregon.edu | FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite | 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 Tue Apr 20 12:21:26 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (nat192.236.mpoweredpc.net [142.177.192.236]) by hub.freebsd.org (Postfix) with ESMTP id 6FDB21512A for ; Tue, 20 Apr 1999 12:21:22 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA73997; Tue, 20 Apr 1999 16:18:55 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Tue, 20 Apr 1999 16:18:54 -0300 (ADT) From: The Hermit Hacker To: Mike Tancsa Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: -STABLE isn't stable - SCSI *and* Ethernet ... In-Reply-To: <4.1.19990420072456.04ffc960@granite.sentex.ca> 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 The following two cards are in the machine...haven't had any problems with that machineuntil I upgraded to 3.1-STABLE from a 3.0-STABLE machine of around January... ahc0: rev 0x01 int a irq 15 on pci0.9.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x01 int a irq 12 on pci0.10.0 ahc1: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs On Tue, 20 Apr 1999, Mike Tancsa wrote: > At 12:27 AM 4/20/99 , The Hermit Hacker wrote: > > > > > >Wow...what a mistake this past couple of days have been...the other day, > >figuring that after ~3months, it might be time to re-sync with -STABLE, > >figuring that, by its very name, this should be a safe thing to do... > > Did you do an upgrade, or a fresh install ? I have a couple of machines in > production that are on the STABLE branch and so far so good. But they use > the a 2940U2W and the fxp cards. Apart from the very dangerous DOS still > there they have been humming along (knock on wood). But since they are for > internal use only (i.e. the general customer population do not have access > to them) I am not too worried. What SCSI controller are you using ? > > ---Mike > ********************************************************************** > Mike Tancsa, Network Admin * mike@sentex.net > Sentex Communications Corp, * http://www.sentex.net/mike > Cambridge, Ontario * 01.519.651.3400 > Canada * > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.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 20 12:27:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (Postfix) with ESMTP id 17F7E15627; Tue, 20 Apr 1999 12:27:35 -0700 (PDT) (envelope-from mike@sentex.net) Received: from simoeon (simeon.sentex.ca [209.112.4.47]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id PAA01914; Tue, 20 Apr 1999 15:25:03 -0400 (EDT) Message-Id: <3.0.5.32.19990420152424.00aa0af0@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 20 Apr 1999 15:24:24 -0400 To: Doug White From: Mike Tancsa Subject: Re: ahc0: WARNING no command for scb # Cc: questions@FreeBSD.ORG, scsi@FreeBSD.ORG In-Reply-To: References: <4.1.19990415201543.041e14c0@granite.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:17 PM 4/20/99 -0700, Doug White wrote: >On Thu, 15 Apr 1999, Mike Tancsa wrote: > >> >> Hi, >> On a 2.2-STABLE machine that is about 90 days old, I saw a whole mess of >> QOUTCNT == 5 >> ahc0: WARNING no command for scb 7 (cmdcmplt) >> QOUTCNT == 4 >> ahc0: WARNING no command for scb 7 (cmdcmplt) >> QOUTCNT == 3 >> ahc0: WARNING no command for scb 7 (cmdcmplt) >> QOUTCNT == 2 >> ahc0: WARNING no command for scb 7 (cmdcmplt) >> QOUTCNT == 1 > >A bunch of commads were dropped, it appears. maybe a disk was having a >problem? But what kind of problem ? I am wondering if this is a firmware issue, a bad sector issue, or a software issue ? ---Mike ------------------------------------------------------------------------ Mike Tancsa, tel 01.519.651.3400 Network Administrator, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 20 12:30: 3 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (nat192.236.mpoweredpc.net [142.177.192.236]) by hub.freebsd.org (Postfix) with ESMTP id 36CA315437 for ; Tue, 20 Apr 1999 12:29:55 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA74218; Tue, 20 Apr 1999 16:27:23 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Tue, 20 Apr 1999 16:27:22 -0300 (ADT) From: The Hermit Hacker To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: -STABLE isn't stable - SCSI *and* Ethernet ... In-Reply-To: <199904201434.IAA01848@narnia.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Apr 1999, Justin T. Gibbs wrote: > > 5 minutes ago, I had a new joy: > > > > Apr 19 23:34:50 hub /kernel: vm_fault: pager read error, pid 73235 > > (sendmail) > > Apr 19 23:34:50 hub /kernel: swap_pager: I/O error - pagein failed; blkno > > 520, size 4096, error 6 > > If you'd like some help instead of just griping, it would be useful > to know: > > 1) What your hardware configuration is. ahc0: rev 0x01 int a irq 15 on pci0.9.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x01 int a irq 12 on pci0.10.0 ahc1: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs hub> grep "^da[0-9]:" /var/run/dmesg.boot | sort | grep Fixed da0: Fixed Direct Access SCSI-2 device da1: Fixed Direct Access SCSI-3 device da2: Fixed Direct Access SCSI-3 device da3: Fixed Direct Access SCSI-2 device da4: Fixed Direct Access SCSI-2 device da5: Fixed Direct Access SCSI-2 device da6: Fixed Direct Access SCSI-2 device da7: Fixed Direct Access SCSI-2 device da8: Fixed Direct Access SCSI-2 device da9: Fixed Direct Access SCSI-2 device > 2) What other messages were displayed on the console before the single > message you recounted. Sorry Justin, but I didn't figure you guys wanted ~160 klines of error messages, so only sent the one :( Apr 19 23:12:02 hub /kernel: Unexpected busfree. LASTPHASE == 0x80 Apr 19 23:12:03 hub /kernel: SEQADDR == 0x153 Apr 19 23:12:03 hub /kernel: (da3:ahc0:0:5:0): Invalidating pack Apr 19 23:12:03 hub /kernel: (da3:ahc0:0:5:0): Invalidating pack > 3) What kind of activity your system sees at ~23:30 that might have > helped to instigate the problem so a developer has an idea of how > to reproduce your problem. Nothing unusual at that time...news is on a didfferent control, but its expire processes don't start up for another half hour, at midnight...other hen that, quiet. da3 itslef hasn't had a problem since I first put that system up almost a year ago now....and, wit the old January kernel back in place, hasn't shown one either :( Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.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 20 12:30:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 294A314BD5 for ; Tue, 20 Apr 1999 12:30:35 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 21148 invoked by uid 1001); 20 Apr 1999 19:28:07 +0000 (GMT) To: wilko@yedi.iaf.nl Cc: barry@lustig.com, stable@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) From: sthaug@nethelp.no In-Reply-To: Your message of "Tue, 20 Apr 1999 20:18:34 +0200 (CEST)" References: <199904201818.UAA00793@yedi.iaf.nl> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 20 Apr 1999 21:28:07 +0200 Message-ID: <21146.924636487@verdi.nethelp.no> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I am using all 3 SCSI connectors on the motherboard. The 50 pin connector > > Wrong. This is one SCSI bus as far as I can see. SCSI buses are linear > things, not star shaped. And they have only 2 terminators, each on every > end of the bus. What you may be missing here is that the ASUS P2B-DS has the Adaptec AIC 3860 bridge (as an option), which gives you an electrically isolated single-ended bus. So in this case, it should be possible to use all three connectors. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 20 12:35:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 41FAC14EEE for ; Tue, 20 Apr 1999 12:35:44 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id NAA03268; Tue, 20 Apr 1999 13:33:01 -0600 (MDT) (envelope-from gibbs@plutotech.com) Message-Id: <199904201933.NAA03268@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: The Hermit Hacker Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: -STABLE isn't stable - SCSI *and* Ethernet ... In-reply-to: Your message of "Tue, 20 Apr 1999 16:27:22 -0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Apr 1999 13:23:23 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Sorry Justin, but I didn't figure you guys wanted ~160 klines of error >messages, so only sent the one :( What you sent this time doesn't look like 160k lines of error messages either, but it is certainly quite useful. >Apr 19 23:12:02 hub /kernel: Unexpected busfree. LASTPHASE == 0x80 >Apr 19 23:12:03 hub /kernel: SEQADDR == 0x153 >Apr 19 23:12:03 hub /kernel: (da3:ahc0:0:5:0): Invalidating pack >Apr 19 23:12:03 hub /kernel: (da3:ahc0:0:5:0): Invalidating pack One of your drives went away for a while. This is probably caused by a sudden peak in activity that caused your drives to draw more power than your supplies can offer. da9 should also be upgraded to L915 if you want it to be reliable. -- 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 20 13: 8: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 6F5FD15798; Tue, 20 Apr 1999 13:07:59 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id WAA02438; Tue, 20 Apr 1999 22:00:05 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.6.12) id VAA04015; Tue, 20 Apr 1999 21:42:40 +0200 (CEST) From: Wilko Bulte Message-Id: <199904201942.VAA04015@yedi.iaf.nl> Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) In-Reply-To: <21146.924636487@verdi.nethelp.no> from "sthaug@nethelp.no" at "Apr 20, 1999 9:28: 7 pm" To: sthaug@nethelp.no Date: Tue, 20 Apr 1999 21:42:40 +0200 (CEST) Cc: barry@lustig.com, stable@freebsd.org, scsi@freebsd.org X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As sthaug@nethelp.no wrote ... > > > I am using all 3 SCSI connectors on the motherboard. The 50 pin connector > > > > Wrong. This is one SCSI bus as far as I can see. SCSI buses are linear > > things, not star shaped. And they have only 2 terminators, each on every > > end of the bus. > > What you may be missing here is that the ASUS P2B-DS has the Adaptec > AIC 3860 bridge (as an option), which gives you an electrically isolated > single-ended bus. So in this case, it should be possible to use all three > connectors. Right, that definitely makes a difference. I don't know all the Asus boards ;-) For troubleshooting I still like to suggest to go back to as simple a SCSI config as possible. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 Tue Apr 20 13:27: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (nat192.236.mpoweredpc.net [142.177.192.236]) by hub.freebsd.org (Postfix) with ESMTP id B26FF15817 for ; Tue, 20 Apr 1999 13:27:02 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA75023; Tue, 20 Apr 1999 17:24:41 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Tue, 20 Apr 1999 17:24:41 -0300 (ADT) From: The Hermit Hacker To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: -STABLE isn't stable - SCSI *and* Ethernet ... In-Reply-To: <199904201933.NAA03268@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Apr 1999, Justin T. Gibbs wrote: > >Sorry Justin, but I didn't figure you guys wanted ~160 klines of error > >messages, so only sent the one :( > > What you sent this time doesn't look like 160k lines of error messages > either, but it is certainly quite useful. > > >Apr 19 23:12:02 hub /kernel: Unexpected busfree. LASTPHASE == 0x80 > >Apr 19 23:12:03 hub /kernel: SEQADDR == 0x153 > >Apr 19 23:12:03 hub /kernel: (da3:ahc0:0:5:0): Invalidating pack > >Apr 19 23:12:03 hub /kernel: (da3:ahc0:0:5:0): Invalidating pack > > One of your drives went away for a while. This is probably caused by > a sudden peak in activity that caused your drives to draw more power > than your supplies can offer. da9 should also be upgraded to L915 if > you want it to be reliable. Okay, but why does it only do this under 3.1-STABLE? In the past 4 months, I've never seen that error, now, with upgrading to 3.1-STABLE, it suddenly happens? If this had been happening consistently over the past 4 months, regardless of OS, no sweat...I can believe a hardware issue, but it only started *after* upgrading to 3.1-STABLE :( Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.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 20 13:34:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 4EF38154E8 for ; Tue, 20 Apr 1999 13:34:42 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id OAA04763; Tue, 20 Apr 1999 14:32:12 -0600 (MDT) (envelope-from gibbs@plutotech.com) Message-Id: <199904202032.OAA04763@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: The Hermit Hacker Cc: "Justin T. Gibbs" , scsi@FreeBSD.org Subject: Re: -STABLE isn't stable - SCSI *and* Ethernet ... In-reply-to: Your message of "Tue, 20 Apr 1999 17:24:41 -0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Apr 1999 14:22:35 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> One of your drives went away for a while. This is probably caused by >> a sudden peak in activity that caused your drives to draw more power >> than your supplies can offer. da9 should also be upgraded to L915 if >> you want it to be reliable. > >Okay, but why does it only do this under 3.1-STABLE? In the past 4 >months, I've never seen that error, now, with upgrading to 3.1-STABLE, it >suddenly happens? If this had been happening consistently over the past 4 >months, regardless of OS, no sweat...I can believe a hardware issue, but >it only started *after* upgrading to 3.1-STABLE :( upgrading from what to 3.1-stable? 3.0R? If so, there have been several changes that affect performance of the system and allow for higher loads to be dished out to disks. Perhaps your system was teetering on the edge of failure before, and the new code is just enough faster to make the problem surface. -- 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 20 13:41:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from thelab.hub.org (nat192.236.mpoweredpc.net [142.177.192.236]) by hub.freebsd.org (Postfix) with ESMTP id 0673515792 for ; Tue, 20 Apr 1999 13:41:07 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id RAA75205; Tue, 20 Apr 1999 17:38:50 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Tue, 20 Apr 1999 17:38:50 -0300 (ADT) From: The Hermit Hacker To: "Justin T. Gibbs" Cc: scsi@FreeBSD.org Subject: Re: -STABLE isn't stable - SCSI *and* Ethernet ... In-Reply-To: <199904202032.OAA04763@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Apr 1999, Justin T. Gibbs wrote: > >> One of your drives went away for a while. This is probably caused by > >> a sudden peak in activity that caused your drives to draw more power > >> than your supplies can offer. da9 should also be upgraded to L915 if > >> you want it to be reliable. > > > >Okay, but why does it only do this under 3.1-STABLE? In the past 4 > >months, I've never seen that error, now, with upgrading to 3.1-STABLE, it > >suddenly happens? If this had been happening consistently over the past 4 > >months, regardless of OS, no sweat...I can believe a hardware issue, but > >it only started *after* upgrading to 3.1-STABLE :( > > upgrading from what to 3.1-stable? 3.0R? If so, there have been several > changes that affect performance of the system and allow for higher loads > to be dished out to disks. Perhaps your system was teetering on the > edge of failure before, and the new code is just enough faster to make > the problem surface. From 3.0-STABLE to 3.1-STABLE ... Will look at power supply issues... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.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 20 14:23:37 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at [128.130.111.12]) by hub.freebsd.org (Postfix) with ESMTP id 5B38C15886; Tue, 20 Apr 1999 14:22:56 -0700 (PDT) (envelope-from pfeifer@dbai.tuwien.ac.at) Received: from markab (markab [128.130.111.33]) by vexpert.dbai.tuwien.ac.at (8.9.1/8.9.1) with ESMTP id XAA08468; Tue, 20 Apr 1999 23:20:19 +0200 (MET DST) Date: Tue, 20 Apr 1999 23:20:17 +0200 (MET DST) From: Gerald Pfeifer To: Barry Lustig Cc: stable@freebsd.org, scsi@freebsd.org Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) In-Reply-To: <19990420153315.2118.qmail@devious.lustig.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, 20 Apr 1999, Barry Lustig wrote: > My system consists of an Asus P2B-DS motherboard: > [...] > I am using all 3 SCSI connectors on the motherboard. As far as I remember Adaptec's docs, you can only use 2 of these 3 connectors at any time, can't you? Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 20 14:38:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gate.lustig.com (gate.lustig.com [205.246.2.242]) by hub.freebsd.org (Postfix) with SMTP id 062DC14EE8 for ; Tue, 20 Apr 1999 14:38:42 -0700 (PDT) (envelope-from barry@lustig.com) Received: (qmail 21496 invoked from network); 20 Apr 1999 21:29:37 -0000 Received: from devious.lustig.com (205.246.2.244) by gate.lustig.com with SMTP; 20 Apr 1999 21:29:37 -0000 Received: (qmail 3068 invoked by uid 1001); 20 Apr 1999 21:29:35 -0000 Message-ID: <19990420212935.3067.qmail@devious.lustig.com> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 4.2mach v148) In-Reply-To: <199904201942.VAA04015@yedi.iaf.nl> X-Nextstep-Mailer: Mail 4.2mach (Enhance 2.2p1) Received: by NeXT.Mailer (1.148.RR) From: Barry Lustig Date: Tue, 20 Apr 1999 17:29:34 -0400 To: Wilko Bulte Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) Cc: sthaug@nethelp.no, stable@freebsd.org, scsi@freebsd.org Reply-To: barry@Lustig.COM References: <199904201942.VAA04015@yedi.iaf.nl> X-Organizations: Barry Lustig & Associates, Inc. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What is odd is that it used to work. The errors only started on 4/3. Were there any CAM changes around that time that might have this effect? barry On Tue, 20 Apr 1999, Wilko Bulte wrote: > As sthaug@nethelp.no wrote ... > I am using all 3 SCSI connectors on the motherboard. The 50 pin connector > > Wrong. This is one SCSI bus as far as I can see. SCSI buses are linear > things, not star shaped. And they have only 2 terminators, each on every > end of the bus. > > What you may be missing here is that the ASUS P2B-DS has the Adaptec > AIC 3860 bridge (as an option), which gives you an electrically isolated > single-ended bus. So in this case, it should be possible to use all three > connectors. > > Right, that definitely makes a difference. I don't know all the Asus > boards ;-) > > For troubleshooting I still like to suggest to go back to as simple > a SCSI config as possible. > > Groeten / Cheers, > Wilko > _ ______________________________________________________________________ | > / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : > Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdxP6327; Tue Apr 20 15:03:21 1999 X-Mailer: exmh version 2.0.2 2/24/98 Reply-To: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.1-RELEASE X-Sender: cschuber To: barry@lustig.com Cc: stable@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) In-reply-to: Your message of "Tue, 20 Apr 1999 11:33:14 EDT." <19990420153315.2118.qmail@devious.lustig.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Apr 1999 15:03:21 -0700 From: Cy Schubert Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19990420153315.2118.qmail@devious.lustig.com>, Barry Lustig writes: > First the problem: Starting on 4/3, my amanda backups have started > failing. At the point of failure the following appears on the console: > I am using all 3 SCSI connectors on the motherboard. The 50 pin connector > connects only the CDROM, which is properly terminated. The 68pin Ultra > connector goes to the back of the machine where the DLT connects to it via a > > cable. It also, is properly terminated. The 2 disk drives are internal and > > are connected to the Ultra2 connector with the Adaptec Ultra2 cable (with > terminator on the end). This controller has a single bus. The manual (actually a pamphlet) for my brand new 2940U/UW states that you can connect devices to any two of the three connectors. This makes sense because you can only have two ends to the bus. Using three cables you'd have three ends. I'm surprised it works as well as you describe. I would have expected filesystem corruption. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 20 17:27: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id D731A14EA8 for ; Tue, 20 Apr 1999 17:26:59 -0700 (PDT) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) for freebsd-scsi@freebsd.org id 10Zkoa-0007AH-00; Tue, 20 Apr 1999 17:24:32 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id RAA28742; Tue, 20 Apr 1999 17:24:28 -0700 Date: Tue, 20 Apr 1999 17:24:28 -0700 (PDT) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Differential host adapter choice To: freebsd-scsi@freebsd.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 Some time in the next few weeks, I should be receiving a tape library with a Differential SCSI interface; so I'm in the market for a matching host adapter. I confess, I haven't been keeping track, which (differential) controllers are best supported under FreeBSD 3.1 and up? Is it still the NCR/Symbios series? Which have the best performance? Which should be avoided? What brand-names use which chipsets? Thanks, -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 20 17:36:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0FE6B1506A for ; Tue, 20 Apr 1999 17:36:42 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id RAA25921; Tue, 20 Apr 1999 17:34:02 -0700 Date: Tue, 20 Apr 1999 17:34:01 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: patl@phoenix.volant.org Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Differential host adapter choice In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Differential is a electrical level... not really a programming constraint, per se. The NCR/Symbios Differential Adaptec 2944 Differential Qlogic 1040 Differential have all been known to work, to a point. I'm biased against the NCR cards, but they're definitely the cost leaders. I use differential Qlogic cards all the time. I've also used the 2944 with some mixed results. All 3 of these brands use their own chipsets. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 20 20: 7:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id BEA9C15254; Tue, 20 Apr 1999 20:07:44 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id EAA20906; Wed, 21 Apr 1999 04:54:28 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.6.12) id AAA07016; Wed, 21 Apr 1999 00:20:53 +0200 (CEST) From: Wilko Bulte Message-Id: <199904202220.AAA07016@yedi.iaf.nl> Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) In-Reply-To: <19990420212935.3067.qmail@devious.lustig.com> from Barry Lustig at "Apr 20, 1999 5:29:34 pm" To: barry@lustig.com Date: Wed, 21 Apr 1999 00:20:53 +0200 (CEST) Cc: sthaug@nethelp.no, stable@FreeBSD.ORG, scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Barry Lustig wrote ... > What is odd is that it used to work. The errors only started on 4/3. Were > there any CAM changes around that time that might have this effect? > > barry No that I know, Ken or Justin might be able to give you better info. But anything that (for example) makes things go faster on the bus could trigger problems. This is what debugging SCSI problems makes so interesting :/ That is also the reason for my suggestion to play around a bit with the SCSI config. > On Tue, 20 Apr 1999, Wilko Bulte wrote: > > As sthaug@nethelp.no wrote ... > > I am using all 3 SCSI connectors on the motherboard. The 50 pin connector > > > > Wrong. This is one SCSI bus as far as I can see. SCSI buses are linear > > things, not star shaped. And they have only 2 terminators, each on every > > end of the bus. > > > > What you may be missing here is that the ASUS P2B-DS has the Adaptec > > AIC 3860 bridge (as an option), which gives you an electrically isolated > > single-ended bus. So in this case, it should be possible to use all three > > connectors. > > > > Right, that definitely makes a difference. I don't know all the Asus > > boards ;-) > > > > For troubleshooting I still like to suggest to go back to as simple > > a SCSI config as possible. > > > > Groeten / Cheers, > > Wilko Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 21 8:16:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gate.lustig.com (gate.lustig.com [205.246.2.242]) by hub.freebsd.org (Postfix) with SMTP id E9B8C1532E for ; Wed, 21 Apr 1999 08:16:38 -0700 (PDT) (envelope-from barry@lustig.com) Received: (qmail 508 invoked from network); 21 Apr 1999 15:14:11 -0000 Received: from devious.lustig.com (205.246.2.244) by gate.lustig.com with SMTP; 21 Apr 1999 15:14:11 -0000 Received: (qmail 4680 invoked by uid 1001); 21 Apr 1999 15:14:15 -0000 Message-ID: <19990421151414.4679.qmail@devious.lustig.com> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 4.2mach v148) In-Reply-To: <199904202220.AAA07016@yedi.iaf.nl> X-Nextstep-Mailer: Mail 4.2mach (Enhance 2.2p1) Received: by NeXT.Mailer (1.148.RR) From: Barry Lustig Date: Wed, 21 Apr 1999 11:14:13 -0400 To: Wilko Bulte Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) Cc: sthaug@nethelp.no, stable@FreeBSD.ORG, scsi@FreeBSD.ORG Reply-To: barry@Lustig.COM References: <199904202220.AAA07016@yedi.iaf.nl> X-Organizations: Barry Lustig & Associates, Inc. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've gone ahead and added a second SCSI bus to system, just for the DLT. I'll see if that clears up the problem. barry On Wed, 21 Apr 1999, Wilko Bulte wrote: > As Barry Lustig wrote ... > What is odd is that it used to work. The errors only started on 4/3. Were > there any CAM changes around that time that might have this effect? > > barry > > No that I know, Ken or Justin might be able to give you better info. > > But anything that (for example) makes things go faster on the bus > could trigger problems. This is what debugging SCSI problems makes > so interesting :/ > > That is also the reason for my suggestion to play around a bit with the > SCSI config. > > On Tue, 20 Apr 1999, Wilko Bulte wrote: > As sthaug@nethelp.no wrote ... > I am using all 3 SCSI connectors on the motherboard. The 50 pin connector > > Wrong. This is one SCSI bus as far as I can see. SCSI buses are linear > things, not star shaped. And they have only 2 terminators, each on every > end of the bus. > > What you may be missing here is that the ASUS P2B-DS has the Adaptec > AIC 3860 bridge (as an option), which gives you an electrically isolated > single-ended bus. So in this case, it should be possible to use all three > connectors. > > Right, that definitely makes a difference. I don't know all the Asus > boards ;-) > > For troubleshooting I still like to suggest to go back to as simple > a SCSI config as possible. > > Groeten / Cheers, > Wilko > > Groeten / Cheers, > Wilko > _ ______________________________________________________________________ | > / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : > ; Wed, 21 Apr 1999 09:33:07 -0700 (PDT) (envelope-from girgen@partitur.se) Received: from partitur.se (banjo.partitur.se [193.219.246.233]) by bastuba.partitur.se (8.8.8/8.8.8) with ESMTP id SAA15948; Wed, 21 Apr 1999 18:30:39 +0200 (CEST) (envelope-from girgen@partitur.se) Message-ID: <371DFD2F.B0ED8377@partitur.se> Date: Wed, 21 Apr 1999 18:30:39 +0200 From: Palle Girgensohn Organization: Partitur X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.1-STABLE i386) X-Accept-Language: sv,en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: seagate python taper? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! Seagate Python DDS-3. On FreeBSD 3.1 with 1542-CP? Is it OK. I read a message from a year ago that stated: > Just for your information! Don't use any combination of Seagate Python DAT > drives, Adaptec 2940 SCSI controller and FreeBSD or Linux! http://www.freebsd.org/cgi/getmsg.cgi?fetch=39897+0+/usr/local/www/db/text/1998/freebsd-scsi/19980222.freebsd-scsi On the other hand, others seem to have no problem, and this taper will run on a fresh 3.1 stable (last build this weekend). I do use a 2940-UW, but probably not for the disks and will use 1542-CP for the taper. Will this be OK? Thanks for replies. Also, if it's OK, and you're using it with Amanda, do you have tape length and other nice parameters for amanda? They would make me happy ;-) Regards, Palle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 21 10:52:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gate.lustig.com (gate.lustig.com [205.246.2.242]) by hub.freebsd.org (Postfix) with SMTP id A1C2915824 for ; Wed, 21 Apr 1999 10:51:42 -0700 (PDT) (envelope-from barry@lustig.com) Received: (qmail 1341 invoked from network); 21 Apr 1999 17:49:17 -0000 Received: from devious.lustig.com (205.246.2.244) by gate.lustig.com with SMTP; 21 Apr 1999 17:49:17 -0000 Received: (qmail 5047 invoked by uid 1001); 21 Apr 1999 17:49:22 -0000 Message-ID: <19990421174922.5046.qmail@devious.lustig.com> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 4.2mach v148) In-Reply-To: <199904202220.AAA07016@yedi.iaf.nl> X-Nextstep-Mailer: Mail 4.2mach (Enhance 2.2p1) Received: by NeXT.Mailer (1.148.RR) From: Barry Lustig Date: Wed, 21 Apr 1999 13:49:21 -0400 To: Wilko Bulte Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) Cc: sthaug@nethelp.no, stable@FreeBSD.ORG, scsi@FreeBSD.ORG Reply-To: barry@Lustig.COM References: <199904202220.AAA07016@yedi.iaf.nl> X-Organizations: Barry Lustig & Associates, Inc. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The good news is that adding a second SCSI controller (Adaptec 2940UW) to my system, and connecting only the DLT 4000 to that controller, seems to have cleared up the problem. The bad news is, that there is some sort of strange interaction between the Ultra2 drives on the Ultra2 part of the Adaptec aic7890/91, and a DLT4000 (with the most recent Quantum firmware) on the Ultra part of the controller. Any pointers on how to help debug this further? barry On Wed, 21 Apr 1999, Wilko Bulte wrote: > As Barry Lustig wrote ... > What is odd is that it used to work. The errors only started on 4/3. Were > there any CAM changes around that time that might have this effect? > > barry > > No that I know, Ken or Justin might be able to give you better info. > > But anything that (for example) makes things go faster on the bus > could trigger problems. This is what debugging SCSI problems makes > so interesting :/ > > That is also the reason for my suggestion to play around a bit with the > SCSI config. > > On Tue, 20 Apr 1999, Wilko Bulte wrote: > As sthaug@nethelp.no wrote ... > I am using all 3 SCSI connectors on the motherboard. The 50 pin connector > > Wrong. This is one SCSI bus as far as I can see. SCSI buses are linear > things, not star shaped. And they have only 2 terminators, each on every > end of the bus. > > What you may be missing here is that the ASUS P2B-DS has the Adaptec > AIC 3860 bridge (as an option), which gives you an electrically isolated > single-ended bus. So in this case, it should be possible to use all three > connectors. > > Right, that definitely makes a difference. I don't know all the Asus > boards ;-) > > For troubleshooting I still like to suggest to go back to as simple > a SCSI config as possible. > > Groeten / Cheers, > Wilko > > Groeten / Cheers, > Wilko > _ ______________________________________________________________________ | > / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : > Message-Id: <199904211736.TAA00642@yedi.iaf.nl> Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) In-Reply-To: <19990421151414.4679.qmail@devious.lustig.com> from Barry Lustig at "Apr 21, 1999 11:14:13 am" To: barry@lustig.com Date: Wed, 21 Apr 1999 19:36:00 +0200 (CEST) Cc: sthaug@nethelp.no, stable@FreeBSD.ORG, scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Barry Lustig wrote ... > I've gone ahead and added a second SCSI bus to system, just for the DLT. > I'll see if that clears up the problem. Well, just keep us posted on progress. I do have a DLT4000 drive here, but no such Asus board. Best of luck, Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 21 11:11:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Samizdat.uucom.com (samizdat.uucom.com [198.202.217.54]) by hub.freebsd.org (Postfix) with ESMTP id 2D46515838 for ; Wed, 21 Apr 1999 11:10:05 -0700 (PDT) (envelope-from cshenton@uucom.com) Received: (from cshenton@localhost) by Samizdat.uucom.com (8.9.3/8.9.3) id OAA16197; Wed, 21 Apr 1999 14:07:27 -0400 (EDT) To: Palle Girgensohn Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: seagate python taper? References: <371DFD2F.B0ED8377@partitur.se> From: Chris Shenton Date: 21 Apr 1999 14:07:27 -0400 In-Reply-To: Palle Girgensohn's message of "Wed, 21 Apr 1999 18:30:39 +0200" Message-ID: Lines: 48 X-Mailer: Gnus v5.6.45/Emacs 20.3 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 21 Apr 1999 18:30:39 +0200, Palle Girgensohn said: Palle> Hi! Seagate Python DDS-3. On FreeBSD 3.1 with 1542-CP? Is it Palle> OK. I read a message from a year ago that stated: >> Just for your information! Don't use any combination of Seagate >> Python DAT drives, Adaptec 2940 SCSI controller and FreeBSD or >> Linux! Palle> http://www.freebsd.org/cgi/getmsg.cgi?fetch=39897+0+/usr/local/www/db/text/1998/freebsd-scsi/19980222.freebsd-scsi Palle> On the other hand, others seem to have no problem, and this Palle> taper will run on a fresh 3.1 stable (last build this Palle> weekend). I do use a 2940-UW, but probably not for the disks Palle> and will use 1542-CP for the taper. Will this be OK? I'm using a 2940 with a Python 4xDDS2 drive on 3.1-STABLE: ahc0: rev 0x03 int a irq 9 on pci0.8.0 ahc0: aic7870 Single Channel A, SCSI Id=7, 16/255 SCBs sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 15) ch0 at ahc0 bus 0 target 4 lun 1 ch0: Removable Changer SCSI-2 device ch0: 5.000MB/s transfers (5.000MHz, offset 15) ch0: 4 slots, 1 drive, 1 picker, 0 portals Palle> tape length and other nice parameters for amanda? They would Palle> make me happy ;-) Again, I'm using DDS2 so my Amanda info wouldnb't help with tape size. I did find that the chg-chip script didn't quite work -- I had to comment out a print statement that confused Amanda when it returned: *** chg-chio.ORIG Wed Feb 24 11:48:14 1999 --- chg-chio Sat Mar 20 16:21:44 1999 *************** *** 347,353 **** $currentTape = 1; } - print STDERR "$currentTape $max_slot 1\n"; print "$currentTape $max_slot 1\n"; exit 0; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 21 11:13: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id 6CA73157EF; Wed, 21 Apr 1999 11:11:56 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.8.8/8.8.8) with ESMTP id LAA04633; Wed, 21 Apr 1999 11:09:25 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Date: Wed, 21 Apr 1999 11:09:24 -0700 (PDT) From: Doug White To: Mike Tancsa Cc: questions@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahc0: WARNING no command for scb # In-Reply-To: <3.0.5.32.19990420152424.00aa0af0@staff.sentex.ca> 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, 20 Apr 1999, Mike Tancsa wrote: > >> On a 2.2-STABLE machine that is about 90 days old, I saw a whole mess of > >> QOUTCNT == 5 > >> ahc0: WARNING no command for scb 7 (cmdcmplt) > >> QOUTCNT == 4 > >> ahc0: WARNING no command for scb 7 (cmdcmplt) > >> QOUTCNT == 3 > >> ahc0: WARNING no command for scb 7 (cmdcmplt) > >> QOUTCNT == 2 > >> ahc0: WARNING no command for scb 7 (cmdcmplt) > >> QOUTCNT == 1 > > > >A bunch of commads were dropped, it appears. maybe a disk was having a > >problem? > > But what kind of problem ? I am wondering if this is a firmware issue, a > bad sector issue, or a software issue ? I can't tell from that informatio. All the error says is that some SCSI commands were lost. I suspect a device reset of somesort. If you get these on a regular basis, be worried; otherwise, I'd call it a fluke. Doug White Internet: dwhite@resnet.uoregon.edu | FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite | www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 21 11:20:55 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 101811587C for ; Wed, 21 Apr 1999 11:19:59 -0700 (PDT) (envelope-from dkelly@mail.HiWAAY.net) Received: (from dkelly@localhost) by mail.HiWAAY.net (8.9.1a/8.9.0) id NAA11540; Wed, 21 Apr 1999 13:17:30 -0500 (CDT) Date: Wed, 21 Apr 1999 13:17:30 -0500 (CDT) From: David Kelly Message-Id: <199904211817.NAA11540@mail.HiWAAY.net> To: freebsd-scsi@FreeBSD.ORG, girgen@partitur.se Subject: Re: seagate python taper? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Palle Girgensohn writes: > Seagate Python DDS-3. On FreeBSD 3.1 with 1542-CP? Is it OK. I read a > message from a year ago that stated: > > > Just for your information! Don't use any combination of Seagate Python DAT > > drives, Adaptec 2940 SCSI controller and FreeBSD or Linux! > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=39897+0+/usr/local/www/db/text/1998/freebsd-scsi/19980222.freebsd-scsi I followed the above to Deja-news and didn't find much more than discussion of audio over DAT and SGI's special firmware. I have an Archive/Conner/Seagate Python DDS-2 drive attached to an Adaptec 2940 (an old one, not even Ultra, just Fast). Works fine. Also have a DDS-1 Python connected to a newer 2940. Also works fine (only tried under 2.2.8 and older): ahc0 rev 1 int a irq 11 on pci0:15:0 ahc0: aic7860 Single Channel, SCSI Id=7, 3 SCBs (ahc0:6:0): "ARCHIVE Python 25601-XXX 2.75" type 1 removable SCSI 2 Searched Seagates site and found: http://www.seagate.com:80/support/tape/tapeinfo/w4m_diff.shtml which says: The Python DAT drives are fully DDS, DDS-DC, DDS-2, SCSI 1, and SCSI-2 compliant. Suggesting you either have a Python, or you have a DDS-3 drive, not both. The Seagate DDS-3 drives are known as Scorpion. I have run about 200 tapes thru 4 Scorpion-24 DDS-3 drives attached to (2) Asus SC875 controllers in (1) FreeBSD 3.0 (Feb 8 SNAP). What problems I have had are not directly related to the tape drives. Reading tape to HD, I see about 1MB/sec (uncompressed tape). Writing 10k blocksize runs about 700k/sec, even when writting to all 4 tape drives at once. (I do this a lot). Using tcopy to read from one drive, write to another pokes along at 300k/sec. Since installing this system there have been numerous changes to -CURRENT's scheduler but I am no longer in a position to update the above system. Seagate DDS drives with hardware compression ship from the factory with compression as the default setting. Suggest if you wish to be compatible with anyone else's system that you turn off the compression jumper. You can always enable compression with mt(1) if you need it. If the other system has compression too then compression will be compatible, but not everybody has hardware compression. -- David Kelly N4HHE, dkelly@hiwaay.net (hm) ====================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 21 11:40: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 0AC8815064; Wed, 21 Apr 1999 11:38:11 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA00088; Wed, 21 Apr 1999 20:26:38 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.6.12) id UAA02024; Wed, 21 Apr 1999 20:04:06 +0200 (CEST) From: Wilko Bulte Message-Id: <199904211804.UAA02024@yedi.iaf.nl> Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) In-Reply-To: <19990421174922.5046.qmail@devious.lustig.com> from Barry Lustig at "Apr 21, 1999 1:49:21 pm" To: barry@lustig.com Date: Wed, 21 Apr 1999 20:04:05 +0200 (CEST) Cc: sthaug@nethelp.no, stable@FreeBSD.ORG, scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Barry Lustig wrote ... > The good news is that adding a second SCSI controller (Adaptec 2940UW) to >my system, and connecting only the DLT 4000 to that controller, seems to have > cleared up the problem. The bad news is, that there is some sort of strange Good. > interaction between the Ultra2 drives on the Ultra2 part of the Adaptec > aic7890/91, and a DLT4000 (with the most recent Quantum firmware) on the > Ultra part of the controller. Any pointers on how to help debug this > further? Hmmmm. Are the drives new to your config, i.e. when Amanda ran OK with the DLT on it's original location were the same drives also present? Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ http://www.freebsd.org _____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 21 11:42:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gate.lustig.com (gate.lustig.com [205.246.2.242]) by hub.freebsd.org (Postfix) with SMTP id 964D615848 for ; Wed, 21 Apr 1999 11:41:45 -0700 (PDT) (envelope-from barry@lustig.com) Received: (qmail 1643 invoked from network); 21 Apr 1999 18:39:19 -0000 Received: from devious.lustig.com (205.246.2.244) by gate.lustig.com with SMTP; 21 Apr 1999 18:39:19 -0000 Received: (qmail 5186 invoked by uid 1001); 21 Apr 1999 18:39:25 -0000 Message-ID: <19990421183925.5185.qmail@devious.lustig.com> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 4.2mach v148) In-Reply-To: <199904211804.UAA02024@yedi.iaf.nl> X-Nextstep-Mailer: Mail 4.2mach (Enhance 2.2p1) Received: by NeXT.Mailer (1.148.RR) From: Barry Lustig Date: Wed, 21 Apr 1999 14:39:25 -0400 To: Wilko Bulte Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) Cc: sthaug@nethelp.no, stable@FreeBSD.ORG, scsi@FreeBSD.ORG Reply-To: barry@Lustig.COM References: <199904211804.UAA02024@yedi.iaf.nl> X-Organizations: Barry Lustig & Associates, Inc. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org No. These same drives and DLT have been running on the system for the past 6 months. First under 2.2.8, and then I upgraded to 3.1-stable. They have been in the same place on the SCSI chain the entire time. The only thing that has been changing is that da1s1e has been filling up. It has grown from 4-5GB to almost 9GB used. barry On Wed, 21 Apr 1999, Wilko Bulte wrote: > ... > Hmmmm. Are the drives new to your config, i.e. when Amanda ran OK > with the DLT on it's original location were the same drives also present? > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 21 16:13:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id B657E14E23 for ; Wed, 21 Apr 1999 16:13:30 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id IAA02112; Thu, 22 Apr 1999 08:41:01 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA84834; Thu, 22 Apr 1999 08:41:01 +0930 (CST) Date: Thu, 22 Apr 1999 08:41:00 +091800 From: Greg Lehey To: Palle Girgensohn Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: seagate python taper? Message-ID: <19990422084100.F54567@freebie.lemis.com> References: <371DFD2F.B0ED8377@partitur.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <371DFD2F.B0ED8377@partitur.se>; from Palle Girgensohn on Wed, Apr 21, 1999 at 06:30:39PM +0200 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wednesday, 21 April 1999 at 18:30:39 +0200, Palle Girgensohn wrote: > Hi! > > Seagate Python DDS-3. On FreeBSD 3.1 with 1542-CP? Is it OK. I read a > message from a year ago that stated: > >> Just for your information! Don't use any combination of Seagate Python DAT >> drives, Adaptec 2940 SCSI controller and FreeBSD or Linux! > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=39897+0+/usr/local/www/db/text/1998/freebsd-scsi/19980222.freebsd-scsi As others have observed, don't believe everything you read. I'm another who's been using this combination for years with no problems attributable to the configuration. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 21 16:44:58 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by hub.freebsd.org (Postfix) with ESMTP id A3447158DD for ; Wed, 21 Apr 1999 16:44:36 -0700 (PDT) (envelope-from girgen@partitur.se) Received: from d1o62.telia.com (root@d1o62.telia.com [195.198.198.241]) by mailf.telia.com (8.8.8/8.8.8) with ESMTP id BAA23161; Thu, 22 Apr 1999 01:42:02 +0200 (CEST) Received: from stordatan.telia.com (t6o62p44.telia.com [195.198.199.104]) by d1o62.telia.com (8.8.5/8.8.5) with ESMTP id BAA17890; Thu, 22 Apr 1999 01:42:00 +0200 (CEST) Received: from partitur.se (localhost [127.0.0.1]) by stordatan.telia.com (8.9.2/8.9.1) with ESMTP id BAA00381; Thu, 22 Apr 1999 01:41:29 +0200 (CEST) (envelope-from girgen@partitur.se) Message-ID: <371E6229.A660B766@partitur.se> Date: Thu, 22 Apr 1999 01:41:29 +0200 From: Palle Girgensohn Organization: Partitur X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.1-STABLE i386) X-Accept-Language: sv,en MIME-Version: 1.0 To: David Kelly Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: seagate SCORPION taper? Was: python References: <199904211817.NAA11540@mail.HiWAAY.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! As David Kelly proposes, I have mixed up the names of these machines. I am planning to get a Seagate *Scorpion* DDS-3, not a python. Sorry for confusion! But the Scorpions, they seem to be doing fine with FreeBSD? Glad to hear. I'm planning on returning a Hornet NS 20 (Travan5) since I can't get it to work properly... It can't mount the tapes on FreeBSD... Has anybody had any luck with such a machine? /Palle David Kelly wrote: > > Palle Girgensohn writes: > > Seagate Python DDS-3. On FreeBSD 3.1 with 1542-CP? Is it OK. I read a > > message from a year ago that stated: > > > > > Just for your information! Don't use any combination of Seagate Python DAT > > > drives, Adaptec 2940 SCSI controller and FreeBSD or Linux! > > > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=39897+0+/usr/local/www/db/text/1998/freebsd-scsi/19980222.freebsd-scsi > > I followed the above to Deja-news and didn't find much more than > discussion of audio over DAT and SGI's special firmware. > > I have an Archive/Conner/Seagate Python DDS-2 drive attached to an > Adaptec 2940 (an old one, not even Ultra, just Fast). Works fine. > > Also have a DDS-1 Python connected to a newer 2940. Also works fine > (only tried under 2.2.8 and older): > > ahc0 rev 1 int a irq 11 on pci0:15:0 > ahc0: aic7860 Single Channel, SCSI Id=7, 3 SCBs > (ahc0:6:0): "ARCHIVE Python 25601-XXX 2.75" type 1 removable SCSI 2 > > Searched Seagates site and found: > http://www.seagate.com:80/support/tape/tapeinfo/w4m_diff.shtml which > says: > > The Python DAT drives are fully DDS, DDS-DC, DDS-2, SCSI 1, > and SCSI-2 compliant. > > Suggesting you either have a Python, or you have a DDS-3 drive, not > both. The Seagate DDS-3 drives are known as Scorpion. > > I have run about 200 tapes thru 4 Scorpion-24 DDS-3 drives attached > to (2) Asus SC875 controllers in (1) FreeBSD 3.0 (Feb 8 SNAP). > What problems I have had are not directly related to the tape drives. > Reading tape to HD, I see about 1MB/sec (uncompressed tape). Writing > 10k blocksize runs about 700k/sec, even when writting to all 4 > tape drives at once. (I do this a lot). > > Using tcopy to read from one drive, write to another pokes along > at 300k/sec. Since installing this system there have been numerous > changes to -CURRENT's scheduler but I am no longer in a position > to update the above system. > > Seagate DDS drives with hardware compression ship from the factory > with compression as the default setting. Suggest if you wish to > be compatible with anyone else's system that you turn off the > compression jumper. You can always enable compression with mt(1) > if you need it. If the other system has compression too then > compression will be compatible, but not everybody has hardware > compression. > > -- > David Kelly N4HHE, dkelly@hiwaay.net (hm) > ====================================================================== > The human mind ordinarily operates at only ten percent of its > capacity -- the rest is overhead for the operating system. > > 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 21 17:11:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by hub.freebsd.org (Postfix) with ESMTP id A853C1587B for ; Wed, 21 Apr 1999 17:11:07 -0700 (PDT) (envelope-from girgen@partitur.se) Received: from d1o62.telia.com (root@d1o62.telia.com [195.198.198.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id CAA14383 for ; Thu, 22 Apr 1999 02:08:38 +0200 (CEST) Received: from stordatan.telia.com (t6o62p44.telia.com [195.198.199.104]) by d1o62.telia.com (8.8.5/8.8.5) with ESMTP id CAA23148 for ; Thu, 22 Apr 1999 02:08:32 +0200 (CEST) Received: from partitur.se (localhost [127.0.0.1]) by stordatan.telia.com (8.9.2/8.9.1) with ESMTP id CAA00555 for ; Thu, 22 Apr 1999 02:07:57 +0200 (CEST) (envelope-from girgen@partitur.se) Message-ID: <371E685D.FB8D4FCD@partitur.se> Date: Thu, 22 Apr 1999 02:07:57 +0200 From: Palle Girgensohn Organization: Partitur X-Mailer: Mozilla 4.51 [en] (X11; I; FreeBSD 3.1-STABLE i386) X-Accept-Language: sv,en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: Hornet NS 20 (Travan-5), any hope? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! I've been away for a while and found a long discussion from end of march about the Travan-5 taper that I started. I missed half of discussion when it happened. I recently had some time to try a few modifications to samount, but this not really my area of expertise. Did anybody get something like the Hornet NS 20 to work with FreeBSD, or is it doomed? /Palle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 21 19:20:24 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id CBA5A15549 for ; Wed, 21 Apr 1999 19:19:57 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt8-216-180-15-203.dialup.HiWAAY.net [216.180.15.203]) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id VAA09997; Wed, 21 Apr 1999 21:17:26 -0500 (CDT) Received: from nospam.hiwaay.net (nospam.hiwaay.net [127.0.0.1]) by nospam.hiwaay.net (8.9.2/8.9.2) with ESMTP id VAA19940; Wed, 21 Apr 1999 21:17:24 -0500 (CDT) (envelope-from dkelly@nospam.hiwaay.net) Message-Id: <199904220217.VAA19940@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Palle Girgensohn Cc: freebsd-scsi@FreeBSD.ORG From: David Kelly Subject: Re: seagate SCORPION taper? Was: python In-reply-to: Message from Palle Girgensohn of "Thu, 22 Apr 1999 01:41:29 +0200." <371E6229.A660B766@partitur.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Apr 1999 21:17:24 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Palle Girgensohn writes: > Hi! > > As David Kelly proposes, I have mixed up the names of these machines. I > am planning to get a Seagate *Scorpion* DDS-3, not a python. Sorry for > confusion! > > But the Scorpions, they seem to be doing fine with FreeBSD? Glad to > hear. Yup. Am going to try mounting 8 on the next FreeBSD machine I build. Just can't write lots of tapes fast enough. :-) Actually the thought is to get a couple of 7 or 9 bay SCSI boxes, put one CD-R, one 18G narrow HD, and 4 tapes in each. Then each box on its own SCSI card and bus. Don't know yet if we'll fill one box with 4mm, the other with 8mm, or split them up. Can always change our mind later. The sad thing is I've pretty much resigned myself to a narrow 18G HD as I can't get wide tape or CD-R and can't see buying 5 wide to narrow adapters (well, maybe at only $12 each). Or a wide to narrow terminator and breaking the SCSI cable. I don't think I have a bandwidth problem, so I fall back to a narrow HD. Then again, have been talking and talking and talking about this with the bosses for months. And nothing has been happening. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 21 20: 7:50 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 8B01814F22; Wed, 21 Apr 1999 20:07:40 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id EAA22482; Thu, 22 Apr 1999 04:54:00 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.6.12) id AAA06274; Thu, 22 Apr 1999 00:51:03 +0200 (CEST) From: Wilko Bulte Message-Id: <199904212251.AAA06274@yedi.iaf.nl> Subject: Re: SCSI Failure during Amanda Backup (Unexpected busfree) In-Reply-To: <19990421183925.5185.qmail@devious.lustig.com> from Barry Lustig at "Apr 21, 1999 2:39:25 pm" To: barry@lustig.com Date: Thu, 22 Apr 1999 00:51:03 +0200 (CEST) Cc: sthaug@nethelp.no, stable@FreeBSD.ORG, scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Barry Lustig wrote ... > No. These same drives and DLT have been running on the system for the past > 6 months. First under 2.2.8, and then I upgraded to 3.1-stable. They have > been in the same place on the SCSI chain the entire time. The only thing > that has been changing is that da1s1e has been filling up. It has grown from > 4-5GB to almost 9GB used. Which should not matter I'd say. I can only speak for my own config, which also has a DLT4000 (OK, DEC TZ88) on an ncr875. 2 disks are on another ncr875. The disks are a IBM 4.5Gb USCSI and an older Seagate Barracuda 4.3Gb FSCSI disk. DLT worked fine with 2.2.8-stable which I ran until 1.5 weeks ago. Now on 3.1-stable it works just as well as before. What does this tell us? Hmm. I'll give it some thought but I guess it is something in the Adaptec driver interacting badly with the SCSI devices you have. Iff this is true it will probably hard for other people to help if they don't have exactly the same h/w config. Groeten / Cheers, Wilko _ ______________________________________________________________________ | / o / / _ Arnhem, The Netherlands |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl _______________________ Powered by FreeBSD ___ 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 22 8:16:18 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id BAC7514E35 for ; Thu, 22 Apr 1999 08:16:14 -0700 (PDT) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id BAA10078; Fri, 23 Apr 1999 01:13:00 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (4.1) id xma010073; Fri, 23 Apr 99 01:12:53 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id BAA29614; Fri, 23 Apr 1999 01:12:53 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id BAA10268; Fri, 23 Apr 1999 01:12:52 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id BAA10969; Fri, 23 Apr 1999 01:12:52 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199904221512.BAA10969@nymph.detir.qld.gov.au> To: maulwurf@subloch.medicusnet.de (Stefan Huerter) Cc: freebsd-scsi@freebsd.org, syssgm@detir.qld.gov.au Subject: Re: i/o error with larger QIC References: <7F6ncL5zoRB@subloch.medicusnet.de> In-Reply-To: <7F6ncL5zoRB@subloch.medicusnet.de> from Stefan Huerter at "18 Apr 1999 00:08:00 +0200" Date: Fri, 23 Apr 1999 01:12:52 +1000 From: Stephen McKay Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 18th April 1999, Stefan Huerter wrote: >> Do you remember what blocksize you *wrote* these tapes with? If you >> do, set the blocksize for the drive fixed at that size and try >> read with the tar command (setting to the blocksize you used to >> write the tape). I really wish I had manuals for this drive so I >> could try and figure what they're trying to do. > >I made a few tests before I get this tip from Joerg, so I tried to use tar >with the blocksize of 10240bytes, but this won't work. I get only I/O >errors... "10240bytes"? Do you mean 1024 bytes? If 'mt blocksize 0' doesn't work, then using 'mt blocksize 1024' should work. The normal block size for these tapes is 1024 bytes. It's really silly to use anything else for QIC525. But the current tape driver doesn't know that... yet. Stephen. PS My magic method of getting my TDC4200 to write over old tapes is to set the blocksize to 1024, then use 'mt density 0'. Works a treat! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 22 9:58: 8 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 64BF714ECC for ; Thu, 22 Apr 1999 09:58:05 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA00479; Thu, 22 Apr 1999 09:54:57 -0700 Date: Thu, 22 Apr 1999 09:54:56 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Stephen McKay Cc: Stefan Huerter , freebsd-scsi@FreeBSD.ORG Subject: Re: i/o error with larger QIC In-Reply-To: <199904221512.BAA10969@nymph.detir.qld.gov.au> 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 > > >> Do you remember what blocksize you *wrote* these tapes with? If you > >> do, set the blocksize for the drive fixed at that size and try > >> read with the tar command (setting to the blocksize you used to > >> write the tape). I really wish I had manuals for this drive so I > >> could try and figure what they're trying to do. > > > >I made a few tests before I get this tip from Joerg, so I tried to use tar > >with the blocksize of 10240bytes, but this won't work. I get only I/O > >errors... > > "10240bytes"? No, I mean 10240- but now that I've understood that variable emulation really *is* being done by newer QIC drives the attempts to set to fixed mode is pointless (personally, I think that this emulated variable mode is a grotesque design botch if (Reads in Variable mode of N-Kbytes) don't match (Reads in Fixed mode with blocksize at N-Kbytes), which is the impression I'm gathering from what people have said...). > > Do you mean 1024 bytes? If 'mt blocksize 0' doesn't work, then using > 'mt blocksize 1024' should work. The normal block size for these tapes > is 1024 bytes. It's really silly to use anything else for QIC525. But > the current tape driver doesn't know that... yet. Yes. I have a TANDBERG SLR-5 on order. I'm tired of screwing around with this. It arrives the middle of next week. Then I'll sit down and try and handle QIC drives more sensibly. What I may end up having to do is that it may be impossible to automatically correctly infer QIC behaviours without some hint from the user- and I don't want to get into a constant quirk game, so what would be people feel about a 'mt datamodel' type of command? Frankly, the big worry spot in a lot of this has been the toe stubbing around trying to do 2FM at EOT. Some drives support it, some drives don't. A lot of *early* QIC drives don't, but I'll have to admit that my QIC knowledge isn't what it should be- I really didn't keep up with QIC because most of the drives I've seen over the last 10 years have been DAT && Exabyte and other high end drives. Now that I'm getting a new high end QIC drive and I've already gotten an newer HP Travan-like drive (the T20) perhaps I might be able to produce something a little more sane for those of you out there that use these units. At any rate, if we could just accept a 1FM at EOT model with 2FM @EOT as the exception (solely for drives that cannot report early warning (1/2" reel drives) a *lot* of the problems would go away. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 22 11:55:16 1999 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 53DBF14D82 for ; Thu, 22 Apr 1999 11:53:40 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id UAA23685 for freebsd-scsi@FreeBSD.ORG; Thu, 22 Apr 1999 20:51:11 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id UAA14571; Thu, 22 Apr 1999 20:30:35 +0200 (MET DST) (envelope-from j) Message-ID: <19990422203034.22930@uriah.heep.sax.de> Date: Thu, 22 Apr 1999 20:30:34 +0200 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: i/o error with larger QIC Reply-To: Joerg Wunsch References: <7F6ncL5zoRB@subloch.medicusnet.de> <199904221512.BAA10969@nymph.detir.qld.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199904221512.BAA10969@nymph.detir.qld.gov.au>; from Stephen McKay on Fri, Apr 23, 1999 at 01:12:52AM +1000 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 As Stephen McKay wrote: > Do you mean 1024 bytes? If 'mt blocksize 0' doesn't work, then using > 'mt blocksize 1024' should work. The normal block size for these tapes > is 1024 bytes. It's really silly to use anything else for QIC525. Huh? Every QIC-525 tape i've seen so far seems to have used variable- length recording. Sure, the underlying tape has to impose a blocksize (of 1024 bytes), but that doesn't mean logical blocks could not be of variable size. I have to look at my girlfriend's TDC3820 again (with FreeBSD pre-3.0, and the old SCSI system), but i'm almost sure this used to be the case. According to the Tandberg manual, even QIC-150 is able to perform variable-length recording, but this always wastes one 512-byte block for recording the logical block length, whereas QIC >= 320 seems to record the logical block length somewhere outside the physical blocks, so no space wasted as long as you write in multiples of 1024 bytes (which probably everybody does anyway: tar uses 10 KB, dump 10 or 32 KB, depending on the tape length). Just to verify this, i dug up an old QIC-525 cartridge, and put it into the TDC4222 drive under a fairly-current system. Running `tar t' succeeded immediately since the driver had already been forced into variable mode (which i'm currently doing from rc.local to work around the driver problems). Looking at the tape's contents, it looks like the cartridge has once been written on a Linux/AXP machine, so it seems the interoperability in `variable' mode is fine. Hmm, hmm, i notice the `tar: Blocksize = 1 records' on top, so this probably means the tape has been written in 512-byte records? At least, i notice a very poor performance. Yup, this really seems to have been written using 512-byte variable- length recording. Interestingly enough, using 512-byte fixed-length mode seems to much improve performance when reading. This triggered me to make a few experiments with dump (all done on a TDC4222 with a QIC-525 cartridge). Speeds are excluding the tape rewind time (which is varying unpredictably due to the serpentine recording). write read speed using blocksize blocksz speed f/512 f/1024 v/10K v/32K ** v/32K 179K/s + + * 188K/s v/10K 179K/s + + 190K/s (190K/s) v/1024 104K/s + 137K/s (81K/s) (81K/s) f/1024 179K/s ** ++ 133K/s 83K/s 82K/s f/512 179K/s 87K/s 121K/s 191K/s 192K/s () Values in parenthesis are modi that are possible but not much useful, since they return short blocks. + IO error ++ IO error plus ``Invalid request. Fixed block device requests must be a multiple of 1 bytes'' (apparently some bug there) * not useful, since only partial blocks would be retrieved, so the remaining data in each block were lost; IMHO this should rather yield an IO error instead (which it did in previous FreeBSD versions) ** blocksize currently needs to be manually adjusted back to 1024 after each tape operation, since the driver resets it to 512 To summarize: ------------- Variable-length logical blocks seem to work best, ever. Fixed-legnth blocks (either 512 or 1024 bytes) have problems with read speed. This seems to be a driver problem, in particular since the read speed using variable-length read operations is better. Given that the best possible values are at best en par with the variable- length recording values, i don't see why anybody would use fixed- length mode. The driver seems to have bugs, see ++ and ** above. Btw., `mt stat' reports compression 0x3 everywhere, although i know that only QIC-2GB and above support compression at all. Maybe this is part of the problem? Slow speeds above are accompanied by the tape going in `start-stop' mode. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 22 12: 4:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 56A0914D37 for ; Thu, 22 Apr 1999 12:04:01 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA01045; Thu, 22 Apr 1999 12:01:13 -0700 Date: Thu, 22 Apr 1999 12:01:12 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: i/o error with larger QIC In-Reply-To: <19990422203034.22930@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > write read speed using blocksize > blocksz speed f/512 f/1024 v/10K v/32K > ** > > v/32K 179K/s + + * 188K/s > v/10K 179K/s + + 190K/s (190K/s) > v/1024 104K/s + 137K/s (81K/s) (81K/s) > f/1024 179K/s ** ++ 133K/s 83K/s 82K/s > f/512 179K/s 87K/s 121K/s 191K/s 192K/s > > () Values in parenthesis are modi that are possible but not much > useful, since they return short blocks. > > + IO error > > ++ IO error plus ``Invalid request. Fixed block device requests must > be a multiple of 1 bytes'' (apparently some bug there) D'oh! That's a wierd one! > > * not useful, since only partial blocks would be retrieved, so > the remaining data in each block were lost; IMHO this should rather > yield an IO error instead (which it did in previous FreeBSD versions) > > ** blocksize currently needs to be manually adjusted back to 1024 > after each tape operation, since the driver resets it to 512 That's a bug to fix, yes. > > To summarize: > ------------- > > Variable-length logical blocks seem to work best, ever. You see- this is why this all has come to be a mess. *My* out of date experience with QIC had led me to believe that Variable && QIC was just not a good idea. I'm still not convinced of this (see other mail about what may be a design flaw)- but this is why I'm actually getting a QIC drive so I can assess, for myself (not out of manuals), what's going on. > Fixed-legnth blocks (either 512 or 1024 bytes) have problems with read > speed. This seems to be a driver problem, in particular since the > read speed using variable-length read operations is better. Given > that the best possible values are at best en par with the variable- > length recording values, i don't see why anybody would use fixed- > length mode. > > The driver seems to have bugs, see ++ and ** above. Btw., `mt stat' > reports compression 0x3 everywhere, although i know that only QIC-2GB > and above support compression at all. Maybe this is part of the > problem? > > Slow speeds above are accompanied by the tape going in `start-stop' > mode. > A more complete assessment than this will be performed soon. I don't think fixed mode is that great either, but I'm not convinced that variable mode with QIC drives is so fanatastic either. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 22 15:43:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from aloha.cc.columbia.edu (aloha.cc.columbia.edu [128.59.59.134]) by hub.freebsd.org (Postfix) with ESMTP id 27BC715996 for ; Thu, 22 Apr 1999 15:42:58 -0700 (PDT) (envelope-from jmr50@columbia.edu) Received: from vincent2 (vincent2.furn.rhno.columbia.edu [128.59.129.227]) by aloha.cc.columbia.edu (8.8.5/8.8.5) with SMTP id SAA04853 for ; Thu, 22 Apr 1999 18:40:27 -0400 (EDT) Message-ID: <00c101be8d11$b4de98c0$e3813b80@furn.rhno.columbia.edu> From: "Jacob M. Rosenberg" To: Subject: Buslogic/Mylex Flashpoint drivers? Date: Thu, 22 Apr 1999 18:44:39 -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.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there anyone working on support for buslogic/mylex Flashpoint scsi host adapters? - Jacob Rosenberg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 22 15:45: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from misha.cisco.com (misha.cisco.com [171.69.206.50]) by hub.freebsd.org (Postfix) with ESMTP id 62BE415454 for ; Thu, 22 Apr 1999 15:44:42 -0700 (PDT) (envelope-from mi@misha.cisco.com) Received: (from mi@localhost) by misha.cisco.com (8.9.2/8.9.1) id SAA96017; Thu, 22 Apr 1999 18:41:37 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin Message-Id: <199904222241.SAA96017@misha.cisco.com> Subject: Re: writing slower with SoftUpdates In-Reply-To: <19990422172744.A51036@dan.emsphone.com> from Dan Nelson at "Apr 22, 1999 05:27:44 pm" To: dnelson@emsphone.com (Dan Nelson) Date: Thu, 22 Apr 1999 18:41:37 -0400 (EDT) Cc: freebsd-scsi@freebsd.org Reply-To: mi@aldan.algebra.com X-Mailer: ELM [version 2.4ME+ PL52 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dan Nelson once wrote (regarding iozone reporting ~10% slower results with SoftUpdates, compared to without -- sync mount): > > WCE was ON on both drives: > > > > Checking SCSI drives for write-cache: > > at scbus0 target 8 lun 0 (pass0,da0) > > at scbus0 target 9 lun 0 (pass1,da1) > > I disabled WCE on both and re-ran the iozone tests. No noticable > > changes from the previous numbers... What really bothers me, is the > > fact that reading speed speed is consistently only 13-14Mb/s on one > > disk, while it is 17-18 (same as writing) on the other. Can it be, > > that one of the partitions I'm trying this on is /tmp (the other is > > /var/tmp)? There are no files in either one of them and they are of > > the same size and offset on two identical disks. > The different mountpoint shouldn't make any difference. I guess you > could dump the bad-block table for both drives, and see if your slower > disk has more relocated blocks than the faster one. "camcontrol > defects -u 0 -f block" will dump the blocklist. (pass0:ahc0:0:8:0): READ DEFECT DATA(10). CDB: 37 0 0 0 0 0 0 fd e8 0 (pass0:ahc0:0:8:0): RECOVERED ERROR asc:1c,0 (pass0:ahc0:0:8:0): Defect list not found field replaceable unit: 18 sks:ca,2 > If you still can't find the problem, try asking in the freebsd-scsi > mailinglist. CC-ed there. The machine is 350MHz PentumII with 128Mb of 100MHz RAM. The disks are LVD being the only targets on the LVD outlet of Adaptec 2940U2W. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 23 1:15:53 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id 0E5F414CE2 for ; Fri, 23 Apr 1999 01:15:46 -0700 (PDT) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id SAA29866; Fri, 23 Apr 1999 18:12:54 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (4.1) id xma029860; Fri, 23 Apr 99 18:12:37 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id SAA15055; Fri, 23 Apr 1999 18:12:36 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id SAA21044; Fri, 23 Apr 1999 18:12:36 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id SAA00532; Fri, 23 Apr 1999 18:12:35 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199904230812.SAA00532@nymph.detir.qld.gov.au> To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG, syssgm@detir.qld.gov.au Subject: Re: i/o error with larger QIC References: In-Reply-To: from Matthew Jacob at "Thu, 22 Apr 1999 09:54:56 -0700" Date: Fri, 23 Apr 1999 18:12:35 +1000 From: Stephen McKay Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thursday, 22nd April 1999, Matthew Jacob wrote: >At any rate, if we could just >accept a 1FM at EOT model with 2FM @EOT as the exception (solely for >drives that cannot report early warning (1/2" reel drives) a *lot* of the >problems would go away. That sounds fine to me. What broke? I'm having a little time off, and have a TDC4200 (QIC), Archive Viper 525 (QIC), Exabyte 8200, and a Kennedy 6250bpi 1/2" reel to reel rack mount job, but I don't know if it works yet. ;-) Oh, and I've got a couple other QIC drives of unknown health in the cupboard. I could do a bit of testing after I get my hardware put back together. I've got a lot of upgrading and rebuilding scheduled. I might even throw out some of the stuff that no longer works! :-) Stephen. PS Anybody interested in getting FreeBSD working on old Mips hardware? Say a Mips 3260? Should be about as fast as a 486... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 23 1:49:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id 9957E14BCC for ; Fri, 23 Apr 1999 01:49:38 -0700 (PDT) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id SAA01289; Fri, 23 Apr 1999 18:46:55 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (4.1) id xma001271; Fri, 23 Apr 99 18:46:40 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id SAA16106 for ; Fri, 23 Apr 1999 18:46:40 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id SAA21773 for ; Fri, 23 Apr 1999 18:46:39 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id SAA01231; Fri, 23 Apr 1999 18:46:38 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199904230846.SAA01231@nymph.detir.qld.gov.au> To: freebsd-scsi@freebsd.org Cc: syssgm@detir.qld.gov.au Subject: Re: i/o error with larger QIC References: <19990422203034.22930@uriah.heep.sax.de> In-Reply-To: <19990422203034.22930@uriah.heep.sax.de> from J Wunsch at "Thu, 22 Apr 1999 20:30:34 +0200" Date: Fri, 23 Apr 1999 18:46:38 +1000 From: Stephen McKay Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thursday, 22nd April 1999, J Wunsch wrote: >As Stephen McKay wrote: > >> Do you mean 1024 bytes? If 'mt blocksize 0' doesn't work, then using >> 'mt blocksize 1024' should work. The normal block size for these tapes >> is 1024 bytes. It's really silly to use anything else for QIC525. > >Huh? Every QIC-525 tape i've seen so far seems to have used variable- >length recording. Sure, the underlying tape has to impose a blocksize >(of 1024 bytes), but that doesn't mean logical blocks could not be of >variable size. Interesting. I've used fixed 1024 byte blocks all the time to avoid the hassles of pretend variable length blocks. >Just to verify this, i dug up an old QIC-525 cartridge, and put it >into the TDC4222 drive under a fairly-current system. Running `tar t' >succeeded immediately since the driver had already been forced into >variable mode (which i'm currently doing from rc.local to work around >the driver problems). Looking at the tape's contents, it looks like >the cartridge has once been written on a Linux/AXP machine, so it >seems the interoperability in `variable' mode is fine. Hmm, hmm, i >notice the `tar: Blocksize = 1 records' on top, so this probably means >the tape has been written in 512-byte records? At least, i notice a >very poor performance. You are seeing a "feature" of the Tandberg, as far as I can tell. It will read fixed block tapes in variable mode, but very slowly. It is slow because every read() is satisfied by only 512 or 1024 bytes. If you were using fixed block mode, then each read() would return 10K or more (I use 32Kb for everything). Try using (say): dd if=/dev/rsa0 of=foo bs=32k count=10 and you will see 10 partial reads in variable mode, totalling 5K or 10K, and 10 full reads in fixed block mode, totalling 320K. [Interesting table removed] >Variable-length logical blocks seem to work best, ever. > >Fixed-legnth blocks (either 512 or 1024 bytes) have problems with read >speed. This seems to be a driver problem, in particular since the >read speed using variable-length read operations is better. Given >that the best possible values are at best en par with the variable- >length recording values, i don't see why anybody would use fixed- >length mode. But what block size did the application use when the tape was in fixed block mode? This is important, and affects the throughput. Eg, I use: $ mt blocksize 1024 $ tar cbf 64 /dev/nrsa0 foo bar bletch to use fixed block mode, but 32Kb transfers. I have no trouble keeping the tape streaming. So I don't see why anybody would use variable mode on these devices. :-) >The driver seems to have bugs, see ++ and ** above. Btw., `mt stat' >reports compression 0x3 everywhere, although i know that only QIC-2GB >and above support compression at all. Maybe this is part of the >problem? Yes, there are some bugs and misfeatures. I can test fixes, or if people are very patient, I can attempt to produce fixes. Stephen. PS Jörg, I know you don't like to be in the cc: list of responses, but since I turn my list mail into news, keeping me in the cc: list means I won't miss anything! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 23 7:53: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D980E151BC for ; Fri, 23 Apr 1999 07:53:01 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id HAA04354; Fri, 23 Apr 1999 07:50:21 -0700 Date: Fri, 23 Apr 1999 07:50:20 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Stephen McKay Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: i/o error with larger QIC In-Reply-To: <199904230812.SAA00532@nymph.detir.qld.gov.au> 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 > > >At any rate, if we could just > >accept a 1FM at EOT model with 2FM @EOT as the exception (solely for > >drives that cannot report early warning (1/2" reel drives) a *lot* of the > >problems would go away. > > That sounds fine to me. What broke? I'm having a little time off, and Well, QIC usage was broken by me. And then a 'feature' where I would try and eject the tape if a wfm failed was added by me. Both are (still slowly) in process of being fixed. > have a TDC4200 (QIC), Archive Viper 525 (QIC), Exabyte 8200, and a Kennedy > 6250bpi 1/2" reel to reel rack mount job, but I don't know if it works yet. ;-) > Oh, and I've got a couple other QIC drives of unknown health in the cupboard. > I could do a bit of testing after I get my hardware put back together. I've > got a lot of upgrading and rebuilding scheduled. I might even throw out > some of the stuff that no longer works! :-) I'll take you up on the Kennedy and QIC testing! > > Stephen. > > PS Anybody interested in getting FreeBSD working on old Mips hardware? > Say a Mips 3260? Should be about as fast as a 486... I think warner losh is working on MIPS now.... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 23 18:10:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from com-os2.ms.mff.cuni.cz (com-os2.ms.mff.cuni.cz [195.113.19.215]) by hub.freebsd.org (Postfix) with ESMTP id 54F8D14E42 for ; Fri, 23 Apr 1999 18:09:57 -0700 (PDT) (envelope-from galambos@com-os2.ms.mff.cuni.cz) Received: from localhost (galambos@localhost) by com-os2.ms.mff.cuni.cz (8.9.1/8.9.1) with ESMTP id DAA04497 for ; Sat, 24 Apr 1999 03:08:44 +0200 (CEST) (envelope-from galambos@com-os2.ms.mff.cuni.cz) Date: Sat, 24 Apr 1999 03:08:44 +0200 (CEST) From: Leo Galambos To: freebsd-scsi@freebsd.org Subject: INITIO IOI-9100UW (SCSI PCI) 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 have got $SUBJ (www.ioiscsi.com) with src-code of drivers on a floppy disk, but I cannot compile it, because /usr/src/sys doesn't contain scsi subdir with scsiconf.h. How can I get the subdir for 3.1-RELEASE? I've tried cvs-ing and/or extracting 3.1-RELEASE/src/* files --- without success. BTW: Have you removed the directory from devel tree? Please, e-mail me at galambos@com-os2.ms.mff.cuni.cz, I am not a subscriber. Thank you. Leo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 24 18:46:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 988BB14D53 for ; Sat, 24 Apr 1999 18:46:30 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id TAA48692; Sat, 24 Apr 1999 19:46:17 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904250146.TAA48692@panzer.plutotech.com> Subject: Re: writing slower with SoftUpdates In-Reply-To: <199904222241.SAA96017@misha.cisco.com> from Mikhail Teterin at "Apr 22, 1999 6:41:37 pm" To: mi@aldan.algebra.com Date: Sat, 24 Apr 1999 19:46:17 -0600 (MDT) Cc: dnelson@emsphone.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mikhail Teterin wrote... > Dan Nelson once wrote (regarding iozone reporting ~10% slower results > with SoftUpdates, compared to without -- sync mount): > > > > WCE was ON on both drives: > > > > > > Checking SCSI drives for write-cache: > > > at scbus0 target 8 lun 0 (pass0,da0) > > > at scbus0 target 9 lun 0 (pass1,da1) > > > > I disabled WCE on both and re-ran the iozone tests. No noticable > > > changes from the previous numbers... What really bothers me, is the > > > fact that reading speed speed is consistently only 13-14Mb/s on one > > > disk, while it is 17-18 (same as writing) on the other. Can it be, > > > that one of the partitions I'm trying this on is /tmp (the other is > > > /var/tmp)? There are no files in either one of them and they are of > > > the same size and offset on two identical disks. > > > The different mountpoint shouldn't make any difference. I guess you > > could dump the bad-block table for both drives, and see if your slower > > disk has more relocated blocks than the faster one. "camcontrol > > defects -u 0 -f block" will dump the blocklist. > > (pass0:ahc0:0:8:0): READ DEFECT DATA(10). CDB: 37 0 0 0 0 0 0 fd e8 0 > (pass0:ahc0:0:8:0): RECOVERED ERROR asc:1c,0 > (pass0:ahc0:0:8:0): Defect list not found field replaceable unit: 18 sks:ca,2 Seagate drives generally don't support the block defect list format, and the error they spit out to tell you that isn't exactly intuitive. Try the physical sector format: camcontrol defects -u 0 -f phys -G To get the permanant defect list: camcontrol defects -u 0 -f phys -G To get both: camcontrol defects -u 0 -f phys -PG > > If you still can't find the problem, try asking in the freebsd-scsi > > mailinglist. > > CC-ed there. The machine is 350MHz PentumII with 128Mb of 100MHz RAM. > The disks are LVD being the only targets on the LVD outlet of Adaptec > 2940U2W. If I read your comments above correctly, it appears that you've already tried enabling/disabling write caching. That can certainly have an effect on things. One other thing to look at is where you are on the disk. I/O performance will be better on the outer diameter tracks. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 24 18:47:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 5285914D53 for ; Sat, 24 Apr 1999 18:47:55 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id TAA48710; Sat, 24 Apr 1999 19:47:52 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904250147.TAA48710@panzer.plutotech.com> Subject: Re: Buslogic/Mylex Flashpoint drivers? In-Reply-To: <00c101be8d11$b4de98c0$e3813b80@furn.rhno.columbia.edu> from "Jacob M. Rosenberg" at "Apr 22, 1999 6:44:39 pm" To: jmr50@columbia.edu (Jacob M. Rosenberg) Date: Sat, 24 Apr 1999 19:47:52 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jacob M. Rosenberg wrote... > Is there anyone working on support for buslogic/mylex Flashpoint scsi host > adapters? Yes, Justin Gibbs is working on a driver. I don't know how far he has gotten on it. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 24 18:49:29 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id BA9D014D53 for ; Sat, 24 Apr 1999 18:49:27 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id TAA48722; Sat, 24 Apr 1999 19:49:22 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904250149.TAA48722@panzer.plutotech.com> Subject: Re: INITIO IOI-9100UW (SCSI PCI) In-Reply-To: from Leo Galambos at "Apr 24, 1999 3: 8:44 am" To: galambos@com-os2.ms.mff.cuni.cz (Leo Galambos) Date: Sat, 24 Apr 1999 19:49:22 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Leo Galambos wrote... > I have got $SUBJ (www.ioiscsi.com) with src-code of drivers on a floppy > disk, but I cannot compile it, because /usr/src/sys doesn't contain scsi > subdir with scsiconf.h. > > How can I get the subdir for 3.1-RELEASE? I've tried cvs-ing and/or > extracting 3.1-RELEASE/src/* files --- without success. > > BTW: Have you removed the directory from devel tree? > > Please, e-mail me at galambos@com-os2.ms.mff.cuni.cz, I am not a > subscriber. FreeBSD, starting with the 3.x releases, has a new SCSI layer. The Initio driver won't work with 3.0 or any release after that unless it is rewritten. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 24 20: 5:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from onion.ish.org (onion.ish.org [210.145.219.202]) by hub.freebsd.org (Postfix) with ESMTP id 6F97014CAA for ; Sat, 24 Apr 1999 20:05:39 -0700 (PDT) (envelope-from ishizuka@ish.org) Received: from localhost (ishizuka@localhost [127.0.0.1]) by onion.ish.org (8.9.3/3.7Wpl1-08/27/98) with ESMTP id MAA30836 for ; Sun, 25 Apr 1999 12:05:38 +0900 (JST) To: freebsd-scsi@freebsd.org Subject: Re: Tekram DC390 driver for FreeBSD 3.x In-Reply-To: <199904181748.RAA100346@out1.ibm.net> References: <199904181748.RAA100346@out1.ibm.net> X-Mailer: Mew version 1.94b23 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint20: 276D 697A C2CB 1580 C683 8F18 DA98 1A4A 50D2 C4CB X-PGP-Fingerprint16: C6 DE 46 24 D7 9F 22 EB 79 E2 90 AB 1B 9A 35 2E X-PGP-Public-Key: http://www.ish.org/pgp-public-key.txt X-URL: http://www.ish.org/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990425120538A.ishizuka@onion.ish.org> Date: Sun, 25 Apr 1999 12:05:38 +0900 From: Masachika ISHIZUKA X-Dispatcher: imput version 990405(IM114) Lines: 76 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi. I have installed 3.1-RELEASE with DC-390, yesterday. It works fine. Installation process is as follows. (This process is shown in freebsd-users-jp 40399 (FreeBSD mailling list in Japan) on Tue, 30 Mar 1999 by yamanaka-san.) (1) Get boot300.zip, kern300.zip and pm300.gz from ftp://ftp.tekram.com/scsi/freebsd/ (2) Create boot floppiy and kern floppy asfollows. # unzip boot300.zip # fdformat fd0 # dd if=boot300.flp of=/dev/rfd0 # unzip kern300.zip # fdformat fd0 # dd if=kern300.flp of=/dev/rfd0 (3) Install 3.1R with boot300 floppy. (4) Before reboot when installation finished, copy kern300 as follows. Insert kern300 floppy. # mount /dev/fd0 /mnt # cp /mnt/kernel / (5) Reboot with single user mode. (6) Modify /etc/fstab not to use procfs temporary. # vi /etc/fstab comment out procfs's line. (7) Go multi user mode. #exit (8) install pm300 patch. Prepare pm300.gz (created by unzip pm300.zip) on /tmp # cd / # gzip -cd /tmp/pm300.gz | patch -p0 (9) add and device-driver's line to files.i386 # cd /usr/src/sys/i386/conf # echo 'pci/tek390.c optional amd device-driver' >> files.i386 (10) Make your kernel with amd driver. # cp GENERIC tekram # vi tekram You must add 'controller amd0' and 'pseudo-driver vn'. # config tekram # cd ../../compile/tekram # make depend # make # make -DFORCE install (11) Install boot loader. # disklabel -B da0 (12) Restore procfs's line on /etc/fstab. (13) Reboot (14) Update /stand with mfsroot.flp Create and insert mfsroot floppy. # mount -r /dev/fd0 /mnt # cp /mnt/mfsroot.gz /tmp # umount /mnt # cd /tmp # gzip -d mfsroot.gz # vnconfig -ce /dev/vn0c /mfsroot # mount -r /dev/vn0c /mnt # rm -rf /stand # mkdir /stand # cd /mnt # tar cf - * | (cd /stand; tar xvf -) # cd / # umount /mnt # vnconfig -u /dev/vn0c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 24 21:59:52 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from kot.ne.mediaone.net (kot.ne.mediaone.net [24.218.12.203]) by hub.freebsd.org (Postfix) with ESMTP id 5A8C214E11 for ; Sat, 24 Apr 1999 21:59:49 -0700 (PDT) (envelope-from mi@kot.ne.mediaone.net) Received: (from mi@localhost) by kot.ne.mediaone.net (8.9.1a/8.9.1) id AAA03413; Sun, 25 Apr 1999 00:58:35 -0400 (EDT) From: Mikhail Teterin Message-Id: <199904250458.AAA03413@kot.ne.mediaone.net> Subject: Re: writing slower with SoftUpdates In-Reply-To: <199904250146.TAA48692@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 24, 1999 07:46:17 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Sun, 25 Apr 1999 00:58:34 -0400 (EDT) Cc: dnelson@emsphone.com, freebsd-scsi@FreeBSD.ORG X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" > > WCE was ON on both drives: => > > => > > Checking SCSI drives for write-cache: => > > at scbus0 target 8 lun 0 (pass0,da0) => > > at scbus0 target 9 lun 0 (pass1,da1) => > > I disabled WCE on both and re-ran the iozone tests. No noticable => > > changes from the previous numbers... What really bothers me, is the => > > fact that reading speed speed is consistently only 13-14Mb/s on one => > > disk, while it is 17-18 (same as writing) on the other. =Try the physical sector format: = camcontrol defects -u 0 -f phys -G Got 0 defects. camcontrol defects -u 1 -f phys -G Got 0 defects. =To get both: camcontrol defects -u 0 -f phys -PG | wc -l Got 868 defects: 868 camcontrol defects -u 1 -f phys -PG | wc -l Got 141 defects: 141 Khmm, the second disk is indeed faster for writing and a LOT faster for reading. Does this number of defects justify an exhange request -- we just bought both disks? Why do SoftUpdates slow things down on both disks, anyway? With and without WCE -- the numbers don't change noticeably... => The machine is 350MHz PentumII with 128Mb of 100MHz RAM. The disks => are LVD being the only targets on the LVD outlet of Adaptec 2940U2W. =One other thing to look at is where you are on the disk. I/O =performance will be better on the outer diameter tracks. I know, but the partitions are identical: mi@labservn:~ (95) mount | grep /tmp /dev/da0s1e on /tmp (local, soft-updates, writes: sync 4 async 8014) /dev/da1s1e on /var/tmp (local, soft-updates, writes: sync 23 async 4801) mi@labservn:~ (96) ( disklabel da0 ; disklabel da1 ) | grep ' e:' e: 1048576 655360 4.2BSD 0 0 0 # (Cyl. 963*- 2505*) e: 1048576 655360 4.2BSD 0 0 0 # (Cyl. 963*- 2505*) Thanks a lot for your help! -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 24 23:37: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 31D1314D9B for ; Sat, 24 Apr 1999 23:37:04 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id AAA49618; Sun, 25 Apr 1999 00:36:51 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904250636.AAA49618@panzer.plutotech.com> Subject: Re: writing slower with SoftUpdates In-Reply-To: <199904250458.AAA03413@kot.ne.mediaone.net> from Mikhail Teterin at "Apr 25, 1999 0:58:34 am" To: mi@kot.ne.mediaone.net (Mikhail Teterin) Date: Sun, 25 Apr 1999 00:36:51 -0600 (MDT) Cc: dnelson@emsphone.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mikhail Teterin wrote... > Kenneth D. Merry once stated: > > => > > WCE was ON on both drives: > => > > > => > > Checking SCSI drives for write-cache: > => > > at scbus0 target 8 lun 0 (pass0,da0) > => > > at scbus0 target 9 lun 0 (pass1,da1) > > => > > I disabled WCE on both and re-ran the iozone tests. No noticable > => > > changes from the previous numbers... What really bothers me, is the > => > > fact that reading speed speed is consistently only 13-14Mb/s on one > => > > disk, while it is 17-18 (same as writing) on the other. > > =Try the physical sector format: > > = camcontrol defects -u 0 -f phys -G > Got 0 defects. > camcontrol defects -u 1 -f phys -G > Got 0 defects. > > =To get both: > > camcontrol defects -u 0 -f phys -PG | wc -l > Got 868 defects: > 868 > camcontrol defects -u 1 -f phys -PG | wc -l > Got 141 defects: > 141 > > Khmm, the second disk is indeed faster for writing and a LOT faster > for reading. Does this number of defects justify an exhange request > -- we just bought both disks? I don't think it's too far out of line for a 9 gig disk, but I suppose that could be one possible explanation for the speed difference. What happens when you read off the raw device, instead of from the filesystem? It might be nice to elminate some of the VM system from the equation. Also, is this on -current or -stable or what? > Why do SoftUpdates slow things down on both disks, anyway? With > and without WCE -- the numbers don't change noticeably... Well, perhaps there's some sort of VM problem that's causing the soft updates slowness? I really don't know what's going on. I've seen instances where having both softupdates and write caching enabled would cause variable performance on disks. But that variable performance would usually go away if I disabled one or the other. In this case, you've tried disabling write caching and it doesn't affect the results. So, that seems to point to maybe some sort of VM-type problem. Is iozone eating a lot of CPU time when you run benchmarks? > => The machine is 350MHz PentumII with 128Mb of 100MHz RAM. The disks > => are LVD being the only targets on the LVD outlet of Adaptec 2940U2W. > > =One other thing to look at is where you are on the disk. I/O > =performance will be better on the outer diameter tracks. > > I know, but the partitions are identical: > > mi@labservn:~ (95) mount | grep /tmp > /dev/da0s1e on /tmp (local, soft-updates, writes: sync 4 async 8014) > /dev/da1s1e on /var/tmp (local, soft-updates, writes: sync 23 async 4801) > mi@labservn:~ (96) ( disklabel da0 ; disklabel da1 ) | grep ' e:' > e: 1048576 655360 4.2BSD 0 0 0 # (Cyl. 963*- 2505*) > e: 1048576 655360 4.2BSD 0 0 0 # (Cyl. 963*- 2505*) Hmm, I suppose that pretty much rules out that possibility. I doubt that you'd see too much difference even if you were writing at the beginning of one 512MB partition and at the end of the other on a 9G disk. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 25 5:51:24 1999 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 693ED14D53 for ; Sun, 25 Apr 1999 05:50:22 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id OAA20321; Sun, 25 Apr 1999 14:50:19 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id OAA27793; Sun, 25 Apr 1999 14:42:38 +0200 (MET DST) (envelope-from j) Message-ID: <19990425144238.12611@uriah.heep.sax.de> Date: Sun, 25 Apr 1999 14:42:38 +0200 From: J Wunsch To: FreeBSD SCSI list Cc: Stephen McKay Subject: Re: i/o error with larger QIC Reply-To: Joerg Wunsch References: <199904221512.BAA10969@nymph.detir.qld.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Matthew Jacob on Thu, Apr 22, 1999 at 09:54:56AM -0700 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 As Matthew Jacob wrote: > Frankly, the big worry spot in a lot of this has been the toe > stubbing around trying to do 2FM at EOT. Some drives support it, > some drives don't. Well, they should all support 2 FMs, but most of the QIC drives cannot overwrite the last FM subsequently (the new Tandbergs only after enabling it on some mode page), so you'd end up with 2 FMs between files in the middle of the tape, which i've always found to be plain annoying. What would break if we dropped this (except for half-inch tapes)? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 25 6:20:22 1999 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 4D17814D16 for ; Sun, 25 Apr 1999 06:20:18 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id PAA20632; Sun, 25 Apr 1999 15:20:18 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id PAA28003; Sun, 25 Apr 1999 15:06:48 +0200 (MET DST) (envelope-from j) Message-ID: <19990425150647.52666@uriah.heep.sax.de> Date: Sun, 25 Apr 1999 15:06:47 +0200 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Cc: Stephen McKay Subject: Re: i/o error with larger QIC Reply-To: Joerg Wunsch References: <19990422203034.22930@uriah.heep.sax.de> <199904230846.SAA01231@nymph.detir.qld.gov.au> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88 In-Reply-To: <199904230846.SAA01231@nymph.detir.qld.gov.au>; from Stephen McKay on Fri, Apr 23, 1999 at 06:46:38PM +1000 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 As Stephen McKay wrote: > >Huh? Every QIC-525 tape i've seen so far seems to have used variable- > >length recording. Sure, the underlying tape has to impose a blocksize > >(of 1024 bytes), but that doesn't mean logical blocks could not be of > >variable size. > > Interesting. I've used fixed 1024 byte blocks all the time to avoid > the hassles of pretend variable length blocks. But well, why are we using `pretend' variable length blocks on the other tape drives then? Everything except half-inch pretends the variable-length recording (with more or less restrictions). Just to verify this assumption, i've fetched the Exabyte 8mm SCSI reference, and they're basically doing about the same as QIC >= 320. They use the same 1 KB physical blocks (with some more ECC data due to the nature of the helical-scan recording -- 400 bytes per each 1024 data bytes on 8 mm, as opposed to 2 physical 1024-byte blocks per each 14 physical data blocks on QIC). So, whenever you use those drives in variable-length mode (and i'm sure this applies to DDS and DLT as well), the drive actually splits the data to fit into physical blocks. The emulation may be better or worse, depending on the actual implementation, but who cares? The main differences i'm seeing between EXB 8mm and QIC >= 320 are: . The two more modern 8mm formats (8200c and 8500) can start logical blocks at arbitrary positions within a physical block, so they don't have to pad blocks. The old 8200 format is similar to the QIC way, logical blocks could span multiple physical blocks, but the remainder of the last physical block up to the next block boundary is padded. (There's one exception to this, i. e. two 512-byte logical blocks can share one 1024-byte physical QIC block. Thus, 512-byte fixed- length recording doesn't waste space on QIC.) . QIC only accepts three possible block size settings: 0 (variable), 512, 1024. 8 mm accepts everything up to 240 KB. I don't know how other tape systems behave here, but i haven't seen anybody who would use odd fixed-length blocksizes either, so it's probably rather a mood point. > You are seeing a "feature" of the Tandberg, as far as I can tell. It > will read fixed block tapes in variable mode, but very slowly. It is I'm not sure whether this is a feature of the Tandberg only, but i don't care right now. You're probably right, this returns short blocks. OTOH, my test series defeats your idea :), under some situations the data rate went up to the full QIC-525 speed again even for this combination. > But what block size did the application use when the tape was in fixed > block mode? This is important, and affects the throughput. Eg, I use: In my case, it was dump's default of 10 KB. From my experience, bumping it over 10 KB doesn't affect the overall throughput much, and beyond 32 KB, you'll hardly notice any improvement at all. So i figure this wasn't the key point in my measurements. > $ mt blocksize 1024 > $ tar cbf 64 /dev/nrsa0 foo bar bletch > > to use fixed block mode, but 32Kb transfers. I have no trouble keeping > the tape streaming. So I don't see why anybody would use variable > mode on these devices. :-) Because it's obsolete. :) Nobody uses it on the other tape drives either (even though all of them, of course, implement it). I have no problems with the speed in variable-length mode either, as long as the application is using a large enough block size. Speedwise, it makes no difference whether you pass the 32 KB in one transfer to the tape drive, and then have the tape considering it as a single logical block, or as 32 logical blocks (that are incidentally same length as the physical blocks then) of 1 KB each. OTOH, with variable-length mode, you can always get some data out of any tape, regardless how it has been written (provided your application uses a large enough blocksize at all to hold the blocks -- dump and GNUtar seem to work OK). Again, if fixed-length recording were that good, why don't the other tape drives use it? I think the only reason for using fixed-length recording on QIC (>= 320) is history... (Of course, with QIC-120/150, this differs a lot. The variable-length emulation there imposes so much restrictions that it's practically useless, and despite of it apparently being a QIC standard, i wouldn't be so sure whether all the QIC drives would really grok such tapes at all.) > PS Jörg, I know you don't like to be in the cc: list of responses, but > since I turn my list mail into news, keeping me in the cc: list means > I won't miss anything! OK, it's only that my mailer can special-case replies to mailing lists, so _not_ keeping people in the Cc list is somewhat simpler for me. But i can honor your wish, no problem. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 25 6:32:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from kot.ne.mediaone.net (kot.ne.mediaone.net [24.218.12.203]) by hub.freebsd.org (Postfix) with ESMTP id 4F589151D0 for ; Sun, 25 Apr 1999 06:32:45 -0700 (PDT) (envelope-from mi@kot.ne.mediaone.net) Received: (from mi@localhost) by kot.ne.mediaone.net (8.9.1a/8.9.1) id JAA04525; Sun, 25 Apr 1999 09:31:55 -0400 (EDT) From: Mikhail Teterin Message-Id: <199904251331.JAA04525@kot.ne.mediaone.net> Subject: Re: writing slower with SoftUpdates In-Reply-To: <199904250636.AAA49618@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 25, 1999 00:36:51 am" To: ken@plutotech.com (Kenneth D. Merry) Date: Sun, 25 Apr 1999 09:31:54 -0400 (EDT) Cc: dnelson@emsphone.com, freebsd-scsi@FreeBSD.ORG X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" at scbus0 target 8 lun 0 (pass0,da0) mi: at scbus0 target 9 lun 0 (pass1,da1) mi: I disabled WCE on both and re-ran the iozone tests. No noticable mi: changes from the previous numbers... What really bothers me, is the mi: fact that reading speed speed is consistently only 13-14Mb/s on one mi: disk, while it is 17-18 (same as writing) on the other. => = camcontrol defects -u 0 -f phys -G => Got 0 defects. => camcontrol defects -u 1 -f phys -G => Got 0 defects. => camcontrol defects -u 0 -f phys -PG | wc -l => Got 868 defects: => 868 => camcontrol defects -u 1 -f phys -PG | wc -l => Got 141 defects: => 141 => => Khmm, the second disk is indeed faster for writing and a LOT faster => for reading. Does this number of defects justify an exhange request => -- we just bought both disks? =I don't think it's too far out of line for a 9 gig disk, but I suppose that =could be one possible explanation for the speed difference. The difference (for reading) is 13-14Mb vs 17-18Mb per second -- kind of huge for seemingly identical drives. =What happens when you read off the raw device, instead of from the =filesystem? It might be nice to elminate some of the VM system from the =equation. Also, is this on -current or -stable or what? This is on a very recent -stable... I'm going to update it to the very latest and retry... => Why do SoftUpdates slow things down on both disks, anyway? With => and without WCE -- the numbers don't change noticeably... =Well, perhaps there's some sort of VM problem that's causing the soft =updates slowness? I really don't know what's going on. The two 256Mb paging areas I have, are also on the identical locations on the disks, but they are not even touched having 128Mb of RAM... =So, that seems to point to maybe some sort of VM-type problem. Is iozone =eating a lot of CPU time when you run benchmarks? Not at all... => => The machine is 350MHz PentumII with 128Mb of 100MHz RAM. The disks => => are LVD being the only targets on the LVD outlet of Adaptec 2940U2W. => =One other thing to look at is where you are on the disk. I/O => =performance will be better on the outer diameter tracks. => => I know, but the partitions are identical: => => mi@labservn:~ (95) mount | grep /tmp => /dev/da0s1e on /tmp (local, soft-updates, writes: sync 4 async 8014) => /dev/da1s1e on /var/tmp (local, soft-updates, writes: sync 23 async 4801) => mi@labservn:~ (96) ( disklabel da0 ; disklabel da1 ) | grep ' e:' => e: 1048576 655360 4.2BSD 0 0 0 # (Cyl. 963*- 2505*) => e: 1048576 655360 4.2BSD 0 0 0 # (Cyl. 963*- 2505*) Thanks! -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 25 15:44:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id B4E2914E85 for ; Sun, 25 Apr 1999 15:44:07 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id PAA12873; Sun, 25 Apr 1999 15:43:46 -0700 Date: Sun, 25 Apr 1999 15:43:46 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Joerg Wunsch Cc: FreeBSD SCSI list , Stephen McKay Subject: Re: i/o error with larger QIC In-Reply-To: <19990425144238.12611@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 25 Apr 1999, J Wunsch wrote: > As Matthew Jacob wrote: > > > Frankly, the big worry spot in a lot of this has been the toe > > stubbing around trying to do 2FM at EOT. Some drives support it, > > some drives don't. > > Well, they should all support 2 FMs, but most of the QIC drives cannot > overwrite the last FM subsequently (the new Tandbergs only after > enabling it on some mode page), so you'd end up with 2 FMs between > files in the middle of the tape, which i've always found to be plain > annoying. > > What would break if we dropped this (except for half-inch tapes)? tcopy, but that could be fixed. Basically anything that assumed two sequential filemarks is EOT (rather than basing it on information content). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 25 16:22:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 4FC0914C59 for ; Sun, 25 Apr 1999 16:22:10 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt8-216-180-15-254.dialup.HiWAAY.net [216.180.15.254]) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id SAA21593 for ; Sun, 25 Apr 1999 18:22:08 -0500 (CDT) Received: from nospam.hiwaay.net (nospam.hiwaay.net [127.0.0.1]) by nospam.hiwaay.net (8.9.2/8.9.2) with ESMTP id SAA38889 for ; Sun, 25 Apr 1999 18:03:50 -0500 (CDT) (envelope-from dkelly@nospam.hiwaay.net) Message-Id: <199904252303.SAA38889@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-scsi@FreeBSD.ORG From: David Kelly Subject: Blocksizes (was Re: i/o error with larger QIC) In-reply-to: Message from J Wunsch of "Sun, 25 Apr 1999 15:06:47 +0200." <19990425150647.52666@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 25 Apr 1999 18:03:50 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org J Wunsch writes: > = > . QIC only accepts three possible block size settings: 0 (variable), > 512, 1024. 8 mm accepts everything up to 240 KB. I don't know how > other tape systems behave here, but i haven't seen anybody who would > use odd fixed-length blocksizes either, so it's probably rather a > mood point. For sane normal Unix blocksize isn't a life and death matter. OTOH I've worked the past several years in a "data center" where tapes and other media was deposited and checked into the "library." Often we had no idea what was on the tape or how it was written. But if somebody requested a copy it was my job to figure out how to dupe it if the technician's cookbook approach failed. Most tapes were 8mm. Most tapes were in tar format. Most tapes were not blocked at 10k. A lot of tapes were apparently written on a VAX directly from FORTRAN. In this case the first block was 80 bytes. The next couple of blocks would be of random size, then a repeating pattern of blocksizes would emerge. Often (3) EOF's were used to mark a single intended EOF. Solaris provides a "Berkeley" tape device which eats these 3 EOF's. Otherwise the Solaris tcopy falsely stops early. I ported FreeBSD's tcopy to Irix and had one special version where I was hacking on the EOD detection. Got bit in the difference between Irix 6.2 and 6.3 here. Recently saw a tape with 488 tape files. Each with 3 EOF's. Took 8 or = 12 hours to tcopy as apparently an Exabyte 8505 takes a long time to = write an EOF. Given a choice I'll always choose Irix over Solaris. Especially when hosting a system for lusers. But the most annoying thing about Irix is that it defaults to 256k and 126k (or is it 128k?) blocksizes for 4mm and 8mm respectively. Not too awful as /var/sysgen/master.d/scsi lets you select the default. The bad thing is unless told otherwise the SCSI tape device driver will write a new tape with whatever blocksize was last seen. Can you say, "tar 2G of data with 512 byte blocksize?" Or = 31k? Or how about the luser who was writting 1024k blocksize because = the system would do it and he thought it would be faster? One contract ends, I get moved to another with similar duties but a chance to start with a clean sheet. So far we only have one system and its running FreeBSD with (4) Seagate Scorpion DDS-3 drives attached. Its serving well as I have more control of our incoming data now. OTOH the hardware wish list includes an SGI O2 simply the injest data the FreeBSD system can't grok. One day I'll experiment with the kernel parameter which limits max blocksize (have "HOWTO" archived) but probably won't get around to it until I'm under the gun. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 25 16:32: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 6D00A14EFF for ; Sun, 25 Apr 1999 16:31:57 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt8-216-180-15-254.dialup.HiWAAY.net [216.180.15.254]) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id SAA25484 for ; Sun, 25 Apr 1999 18:31:56 -0500 (CDT) Received: from nospam.hiwaay.net (nospam.hiwaay.net [127.0.0.1]) by nospam.hiwaay.net (8.9.2/8.9.2) with ESMTP id SAA39140 for ; Sun, 25 Apr 1999 18:31:54 -0500 (CDT) (envelope-from dkelly@nospam.hiwaay.net) Message-Id: <199904252331.SAA39140@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: FreeBSD SCSI list From: David Kelly Subject: Re: i/o error with larger QIC In-reply-to: Message from Matthew Jacob of "Sun, 25 Apr 1999 15:43:46 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 Apr 1999 18:31:54 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob writes: > On Sun, 25 Apr 1999, J Wunsch wrote: > > > > What would break if we dropped this (except for half-inch tapes)? > > > tcopy, but that could be fixed. Basically anything that assumed two > sequential filemarks is EOT (rather than basing it on information > content). That reminds me, I have some tcopy changes I need to send-pr tomorrow when I can get to the machine where my diffs are. Basically two simple things: counters are u_long and don't count correctly past 4G. The other is when target or destination is a file and you are doing "copy-verify" the tape ioctl() won't rewind a file. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 25 17:38: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id E3CA114D87; Sun, 25 Apr 1999 17:37:59 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id TAA24060; Sun, 25 Apr 1999 19:55:32 -0500 (EST) Date: Sun, 25 Apr 1999 19:55:30 -0500 (EST) From: Alfred Perlstein To: W Gerald Hicks Cc: Sean Leach , wghicks@wghicks.bellsouth.net, questions@freebsd.org, scsi@freebsd.org Subject: Firewire support, was: Re: FreeBSD for Alpha In-Reply-To: <199904252011.QAA22503@bellsouth.net> 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 Sun, 25 Apr 1999, W Gerald Hicks wrote: > I'd be willing to pay for the FireWire hardware for a PC (is there any?) > if someone knowledgable with it would like to work on FreeBSD support. > > What sort of peripheral devices are available now for FW and are open > enough to permit third-party OS use? I'm not affiliated with the FreeBSD project in any real sense, I'm cc'ing the mailing lists to see if anyone is interested. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 26 4:13:33 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 066D7150B0 for ; Mon, 26 Apr 1999 04:13:28 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id MAA63370 for scsi@freebsd.org; Mon, 26 Apr 1999 12:13:27 +0100 (BST) (envelope-from joe) Date: Mon, 26 Apr 1999 12:13:27 +0100 From: Josef Karthauser To: scsi@freebsd.org Subject: Scsi bus problems - can someone tell me what went wrong? Message-ID: <19990426121327.G34926@pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, One of our machines spasm'd last night. Can someone shed some light on what happened please? FreeBSD 3.1-STABLE (BLUECAT) #8: Tue Mar 9 16:28:23 GMT 1999 Thanks in advance, Joe ----- Forwarded message from Charlie Root ----- bluecat kernel log messages: > ddr 0xa0000 msize 131072 on isa > swap_pager: indefinite wait buffer: device: 0x20401, blkno: 85808, size: 4096 > (da0:ahc0:0:0:0): SCB 0x50 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xa > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > swap_pager: indefinite wait buffer: device: 0x20401, blkno: 85808, size: 4096 > swap_pager: indefinite wait buffer: device: 0x20401, blkno: 85808, size: 4096 > swap_pager: indefinite wait buffer: device: 0x20401, blkno: 85808, size: 4096 > (da0:ahc0:0:0:0): SCB 0xe0 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > swap_pager: indefinite wait buffer: device: 0x20401, blkno: 85808, size: 4096 > swap_pager: indefinite wait buffer: device: 0x20401, blkno: 85808, size: 4096 > swap_pager: indefinite wait buffer: device: 0x20401, blkno: 85808, size: 4096 > (da0:ahc0:0:0:0): SCB 0xd0 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xa > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0x57 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0x17 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xb > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0xfb - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xc > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0x26 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0xf7 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0xcf - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0xc6 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xc > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0x19 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0x3c - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0xdf - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xc > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0x37 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xa > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0x1 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0x18 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0x4a - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0x35 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xc > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0xed - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0x9 > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0x22 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xb > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0x2b - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xa > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0xc5 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xb > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 > (da0:ahc0:0:0:0): SCB 0xd6 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xc > (da0:ahc0:0:0:0): Queuing a BDR SCB > (da0:ahc0:0:0:0): Bus Device Reset Message Sent > (da0:ahc0:0:0:0): no longer in timeout, status = 353 > Unexpected busfree. LASTPHASE == 0xa0 > SEQADDR == 0x152 ----- End forwarded message ----- -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Apr 26 7:30:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 7E38C151A9 for ; Mon, 26 Apr 1999 07:30:18 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id IAA15128; Mon, 26 Apr 1999 08:20:31 -0600 (MDT) Date: Mon, 26 Apr 1999 08:20:31 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199904261420.IAA15128@narnia.plutotech.com> To: Josef Karthauser Cc: scsi@FreeBSD.org Subject: Re: Scsi bus problems - can someone tell me what went wrong? X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <19990426121327.G34926@pavilion.net> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <19990426121327.G34926@pavilion.net> you wrote: > Hi, > > One of our machines spasm'd last night. Can someone shed some light on what > happened please? > > FreeBSD 3.1-STABLE (BLUECAT) #8: Tue Mar 9 16:28:23 GMT 1999 You need a newer -stable. A bug in the error recovery code was fixed in early April. I don't know why your device timed out. Perhaps knowing what kind of devices are in the system would help. -- 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 27 13:25:27 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from blaubaer.kn-bremen.de (blaubaer.kn-bremen.de [194.94.232.249]) by hub.freebsd.org (Postfix) with ESMTP id 2DDEF1566E; Tue, 27 Apr 1999 13:25:11 -0700 (PDT) (envelope-from nox@saturn.kn-bremen.de) Received: from saturn.kn-bremen.de (uucp@localhost) by blaubaer.kn-bremen.de (8.9.1/8.9.1) with UUCP id WAA16703; Tue, 27 Apr 1999 22:19:00 +0200 Received: (from nox@localhost) by saturn.kn-bremen.de (8.9.3/8.8.5) id VAA02370; Tue, 27 Apr 1999 21:28:15 +0200 (MET DST) From: Juergen Lock Date: Tue, 27 Apr 1999 21:28:15 +0200 To: freebsd-stable@FreeBSD.ORG Cc: freebsd-scsi@FreeBSD.ORG Subject: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) Message-ID: <19990427212815.A674@saturn.kn-bremen.de> References: <19990420023954.A20589@saturn.kn-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990420023954.A20589@saturn.kn-bremen.de>; from nox on Tue, Apr 20, 1999 at 02:39:54AM +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Apr 20, 1999 at 02:39:54AM +0200, nox wrote: > [Cc'd to -scsi, subscription is on the way...] > > bash# tar xfvR /dev/nrst0 > tar: rec 0: read error on /dev/nrst0 : Input/output error > > ^C > > [other xterm:] > bash# ps -xawl|grep tar > 0 20103 19849 4 -6 0 940 516 piperd S+ p1 0:00.03 grep tar > 0 19838 18532 0 -6 0 436 192 cgticb DE+ p8 0:00.00 (tar) > > The tape drive is silent, all other targets on the bus can be > accessed without problems. I have positioned the tape with a script > thats doing > > camcontrol cmd -u 0 -n sa -t 3000 -c "2b 4 0 v v v v 0 0 0" 0x$c3 0x$c2 0x$c1 0x$c0 Well... after having discovered mt rdhpos/sethpos :), and mounted the drive into a new external case (the old ones PSU died), i now have some more data: 1. exactly the same happens when i use mt sethpos instead of the camcontrol script: the 1st tar returns `tar: rec 0: Blocksize = 12 records', (ok so maybe the position i gave is a few blocks off), the next goes hanging like mentioned above. And if i then look at the console there is this: Apr 27 19:00:22 saturn /kernel: (sa0:ncr0:0:5:0): WRITE FILEMARKS. CDB: 10 0 0 0 0 0 Apr 27 19:00:22 saturn /kernel: (sa0:ncr0:0:5:0): DATA PROTECT asc:27,0 Apr 27 19:00:22 saturn /kernel: (sa0:ncr0:0:5:0): Write protected Apr 27 19:00:45 saturn /kernel: (sa0:ncr0:0:5:0): WRITE FILEMARKS. CDB: 10 0 0 0 0 0 Apr 27 19:00:45 saturn /kernel: (sa0:ncr0:0:5:0): DATA PROTECT asc:27,0 Apr 27 19:00:45 saturn /kernel: (sa0:ncr0:0:5:0): Write protected Apr 27 19:02:49 saturn /kernel: (sa0:ncr0:0:5:0): WRITE FILEMARKS. CDB: 10 0 0 0 0 0 Apr 27 19:02:49 saturn /kernel: (sa0:ncr0:0:5:0): ILLEGAL REQUEST asc:2c,0 Apr 27 19:02:49 saturn /kernel: (sa0:ncr0:0:5:0): Command sequence error Apr 27 19:02:51 saturn /kernel: (sa0:ncr0:0:5:0): WRITE FILEMARKS. CDB: 10 0 0 0 0 0 Apr 27 19:02:51 saturn /kernel: (sa0:ncr0:0:5:0): ILLEGAL REQUEST asc:2c,0 Apr 27 19:02:51 saturn /kernel: (sa0:ncr0:0:5:0): Command sequence error Huh!?? Why on earth is it trying to write filemarks?? Good that the tape was write protected... 2. reading the tape from beginning (repeated tar tfvR /dev/nrst0 until the wanted position is reached) works ok i.e. i then can read past the failing spot without problems. (except that doing it this way takes looong...) so i presume something in the internal state of the nrst (sa) driver is causing the problem... (the tape drive is most likely innocent, see below.) 3. mt bl(ocksize) doesn't work. regardless what blocksize i give i get: Apr 27 16:00:47 saturn /kernel: (sa0:ncr0:0:5:0): MODE SELECT(06). CDB: 15 0 0 0 c 0 Apr 27 16:00:47 saturn /kernel: (sa0:ncr0:0:5:0): ILLEGAL REQUEST asc:26,0 Apr 27 16:00:47 saturn /kernel: (sa0:ncr0:0:5:0): Invalid field in parameter list sks:8f,4 (should the requested blocksize appear in the CDB? it is always 15 0 0 0 c 0...) the default blocksize is OK (tape is streaming) so this doesn't worry me too much, but i thought i'll mention it anyway. (on a related note, i cant get camcontrol defects to work on any of my 4 disk drives, i only get this: Apr 27 15:55:48 saturn /kernel: (probe0:ncr0:0:0:0): COMMAND FAILED (6 ff) @0xf07a1400. dmesg below.) 4. on one reboot i got this: Apr 27 15:55:48 saturn /kernel: Waiting 5 seconds for SCSI devices to settle Apr 27 15:55:48 saturn /kernel: ncr0: restart (scsi reset). Apr 27 15:55:48 saturn /kernel: (probe6:ncr0:0:6:0): COMMAND FAILED (6 ff) @0xf07bc000. Apr 27 15:55:48 saturn /kernel: (probe5:ncr0:0:5:0): COMMAND FA Apr 27 15:55:48 saturn /kernel: ILED (6 ff) @0xf07bc600. Apr 27 15:55:48 saturn /kernel: (probe4:ncr0:0:4:0): COMMAND FAILED (6 ff) @0xf07bcc00. Apr 27 15:55:48 saturn /kernel: (probe3:ncr0:0:3:0): COMMAND FAILED (6 ff) @0xf07bb200. Apr 27 15:55:48 saturn /kernel: (probe2:ncr0:0:2:0): COMMAND FAILED (6 ff) @0xf07bb800. Apr 27 15:55:48 saturn /kernel: (probe1:ncr0:0:1:0): COMMAND FAILED (6 ff) @0xf07bbe00. Apr 27 15:55:48 saturn /kernel: (probe0:ncr0:0:0:0): COMMAND FAILED (6 ff) @0xf07a1400. Apr 27 15:55:48 saturn /kernel: (probe4:ncr0:0:4:0): INQUIRY. CDB: 12 1 80 0 ff 0 Apr 27 15:55:48 saturn /kernel: (probe4:ncr0:0:4:0): ILLEGAL REQUEST asc:24,0 Apr 27 15:55:48 saturn /kernel: (probe4:ncr0:0:4:0): Invalid field in CDB Apr 27 15:55:48 saturn /kernel: (probe5:ncr0:0:5:0): INQUIRY. CDB: 12 1 80 0 ff 0 Apr 27 15:55:48 saturn /kernel: (probe5:ncr0:0:5:0): ILLEGAL REQUEST asc:24,0 Apr 27 15:55:48 saturn /kernel: (probe5:ncr0:0:5:0): Invalid field in CDB sks:c8,1 and then it goes on listing the SCSI devices as usual. should i worry? 5. back to the tape, booting a 2.2.8-stable kernel: the tape is not streaming and regardless what blocksize i set it to it stays that way (always start/stop behavior). i did not try my positioning script. 6. booting a 2.1-stable kernel: everything works! the tape is streaming, i can position it (using my old version of the script thats doing scsi -f), and then i can read from there on without problems. well, there is one minor nit: i first have to read a few blocks off /dev/nrst0 or else it will rewind before starting to read after the positioning command... Here is the latest dmesg (boot -v, 3.1-stable): Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-STABLE #29: Tue Apr 27 00:18:14 MET DST 1999 nox@saturn:/www/w/usr/home5/cvs/src31/src/sys/compile/SP3G.3I Calibrating clock(s) ... i8254 clock: 1228973 Hz 1228973 Hz differs from default of 1193182 Hz by more than 1% Timecounter "i8254" frequency 1193182 Hz CPU: i486 DX4 (486-class CPU) Origin = "GenuineIntel" Id = 0x480 Stepping=0 Features=0x3 real memory = 33554432 (32768K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x002d6000 - 0x01febfff, 30498816 bytes (7446 pages) avail memory = 29859840 (29160K bytes) Found BIOS32 Service Directory header at 0xf00fc310 Entry = 0xfc740 (0xf00fc740) Rev = 0 Len = 1 PCI BIOS entry at 0xc770 Other BIOS signatures found: ACPI: 00000000 $PnP: 00000000 Preloaded elf kernel "kernel" at 0xf02c5000. VESA: information block 56 45 53 41 02 01 3a 4f 00 c0 00 00 00 00 57 4f 00 c0 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 20 mode(s) found Math emulator present pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 pci_open(1a): mode1res=0x00000000 (0x80000000) pci_open(1b): mode1res=0x00000000 (0xff000001) pci_open(2): mode 2 enable port (0x0cf8) is 0x00 pci_open(2a): mode2res=0x0e (0x0e) pci_open(2a): now trying mechanism 2 pci_cfgcheck: device 0 [class=000000] 1 [class=000000] 2 [class=000000] 3 4 5 6 [class=030000] [hdr=00] is there (id=88115333) Probing for devices on PCI bus 0: found-> vendor=0x8086, dev=0x0483, revid=0x04 class=00-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 chip0: rev 0x04 on pci0.0.0 CPU: 486DX, bus=33MHz, CPU->Memory posting ON Warning: NO DRAM parity! Cache: 256KB writeback, cache clocks=2-1-1-1 DRAM: page mode code fetch, read and write, memory clocks=X-2-2-2 CPU->PCI: posting ON, burst mode ON PCI->Memory: posting OFF found-> vendor=0x1000, dev=0x0001, revid=0x01 class=00-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=9 map[0]: type 4, range 32, base 0000e800, size 8 map[1]: type 1, range 32, base fbfef000, size 8 ncr0: rev 0x01 int a irq 9 on pci0.1.0 ncr0: minsync=25, maxsync=206, maxoffs=8, 16 dwords burst, normal dma fifo ncr0: single-ended, open drain IRQ driver found-> vendor=0x8086, dev=0x0484, revid=0x03 class=00-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 chip1: rev 0x03 on pci0.2.0 Bus Modes: Bus Park, Bus Lock, Coprocessor errors enabled Keyboard controller: 60h,62h,64h,66h RTC: 70h-77h found-> vendor=0x5333, dev=0x8811, revid=0x00 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=0 map[0]: type 1, range 32, base fb000000, size 23 vga0: rev 0x00 int a irq 0 on pci0.6.0 Probing for devices on the ISA bus: atkbd: the current kbd controller command byte 0045 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa sc0 on isa sc0: fb0 kbd0 sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa kbd0: atkbd0, AT 101/102 (2), config:0x10000, flags:0x3d0000 psm0: disabled, not probed. sio0: irq maps: 0x9 0x19 0x9 0x9 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: disabled, not probed. pca0 on motherboard pca0: PC speaker audio driver fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S wd0: ATA INQUIRE valid = 0007, dmamword = 0407, apio = 0003, udma = 0007 ppc: parallel port found at 0x378 PC873xx FER=0x4f FAR=0x10 PTR=0x8 FCR=0x0 PCR=0x0 PMC=0x0 TUP=0x0 SID=0x1a PNP0=0xff PNP1=0xff LPTBA=0xff PC873xx irq 7 at 0x378 PC873xx irq set to 0 PC873xx unlocked, NIBBLE ppc0 at 0x378 irq 7 flags 0x20 on isa ppc0: PC87332 chipset (NIBBLE-only) in COMPATIBLE mode nlpt0: on ppbus 0 ppi0: on ppbus 0 isic0 at 0xd80 irq 12 flags 0x3 on isa isic0: Teles S0/16.3 isic0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) (Addr=0x960) isic0: HSCX 82525 or 21525 Version 2.1 (AddrA=0x160, AddrB=0x560) vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa fb0: vga0, vga, type:VGA (5), flags:0x700ff fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xf00b8000 size:32k gran:32k, buf:0x0 size:0k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VESA: v1.2, 2048k memory, flags:0x0, mode table:0xf00c4f57 (c0004f57) VESA: ELSA WINNER 1000TRIO npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. imasks: bio c0084040, tty c003001a, net c0061080 BIOS Geometries: 0:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 1:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 2:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 3:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 4:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 5:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 6:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 7:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 0 accounted for Device configuration finished. IP packet filtering initialized, divert disabled, rule-based forwarding disabled, unlimited logging bpf: tun0 attached bpf: lo0 attached i4b: ISDN call control device attached i4bisppp: 4 ISDN SyncPPP device(s) attached bpf: isp0 attached bpf: isp1 attached bpf: isp2 attached bpf: isp3 attached i4bctl: ISDN system control port attached i4bipr: 4 IP over raw HDLC ISDN device(s) attached (VJ header compression) bpf: ipr0 attached bpf: ipr1 attached bpf: ipr2 attached bpf: ipr3 attached i4btel: 2 ISDN telephony interface device(s) attached i4brbch: 4 raw B channel access device(s) attached i4btrc: 4 ISDN trace device(s) attached Linux-ELF exec handler installed Waiting 5 seconds for SCSI devices to settle ncr0: restart (scsi reset). (probe4:ncr0:0:4:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe4:ncr0:0:4:0): ILLEGAL REQUEST asc:24,0 (probe4:ncr0:0:4:0): Invalid field in CDB (probe5:ncr0:0:5:0): INQUIRY. CDB: 12 1 80 0 ff 0 (probe5:ncr0:0:5:0): ILLEGAL REQUEST asc:24,0 (probe5:ncr0:0:5:0): Invalid field in CDB sks:c8,1 sa0 at ncr0 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 4.901MB/s transfers (4.901MHz, offset 8) pass0 at ncr0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number 1C176285 pass0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled pass1 at ncr0 bus 0 target 1 lun 0 pass1: Fixed Direct Access SCSI-2 device pass1: Serial Number EF90YAE pass1: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled pass2 at ncr0 bus 0 target 2 lun 0 pass2: Fixed Direct Access SCSI-2 device pass2: Serial Number 5U2R4677 pass2: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled pass3 at ncr0 bus 0 target 3 lun 0 pass3: Fixed Direct Access SCSI-2 device pass3: Serial Number 1C071239 pass3: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled pass4 at ncr0 bus 0 target 4 lun 0 pass4: Removable CD-ROM SCSI-2 device pass4: 3.300MB/s transfers pass5 at ncr0 bus 0 target 5 lun 0 pass5: Removable Sequential Access SCSI-2 device pass5: 4.901MB/s transfers (4.901MHz, offset 8) da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: Serial Number EF90YAE da1: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da1: 2048MB (4194304 512 byte sectors: 255H 63S/T 261C) da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number 1C176285 da0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da0: 1034MB (2118144 512 byte sectors: 255H 63S/T 131C) da3 at ncr0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-2 device da3: Serial Number 1C071239 da3: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da3: 1034MB (2118144 512 byte sectors: 255H 63S/T 131C) cd0 at ncr0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 3.300MB/s transfers cd0: cd present [323944 x 2048 byte records] da2 at ncr0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: Serial Number 5U2R4677 da2: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da2: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) Considering MFS root f/s. No MFS image available as root f/s. Considering FFS root f/s. changing root device to da2s1a da2s1: type 0xa5, start 63, end = 4224527, size 4224465 : OK Start pid=2 Start pid=3 Start pid=4 wd0s1: type 0x6, start 63, end = 2056319, size 2056257 : OK wd0s2: type 0xa5, start 2056320, end = 12594959, size 10538640 : OK da3s1: type 0xa5, start 63, end = 2104514, size 2104452 : OK da1s1: type 0xa5, start 261954, end = 4191263, size 3929310 : OK da1s4: type 0x6, start 63, end = 261953, size 261891 : OK da0s1: type 0x5, start 261954, end = 523907, size 261954 : OK da0s3: type 0xa5, start 523908, end = 2118143, size 1594236 : OK da0s4: type 0x6, start 63, end = 261953, size 261891 : OK da3s1: type 0xa5, start 63, end = 2104514, size 2104452 : OK da0s1: type 0x5, start 261954, end = 523907, size 261954 : OK da0s3: type 0xa5, start 523908, end = 2118143, size 1594236 : OK da0s4: type 0x6, start 63, end = 261953, size 261891 : OK da0s1: type 0x5, start 261954, end = 523907, size 261954 : OK da0s3: type 0xa5, start 523908, end = 2118143, size 1594236 : OK da0s4: type 0x6, start 63, end = 261953, size 261891 : OK da3s1: type 0xa5, start 63, end = 2104514, size 2104452 : OK da1s1: type 0xa5, start 261954, end = 4191263, size 3929310 : OK da1s4: type 0x6, start 63, end = 261953, size 261891 : OK da0s1: type 0x5, start 261954, end = 523907, size 261954 : OK da0s3: type 0xa5, start 523908, end = 2118143, size 1594236 : OK da0s4: type 0x6, start 63, end = 261953, size 261891 : OK splash: image decoder found: green_saver Regards, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 27 16: 9:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (Postfix) with ESMTP id 1E7AC15687 for ; Tue, 27 Apr 1999 16:09:16 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id TAA01696; Tue, 27 Apr 1999 19:08:40 -0400 (EDT) Date: Tue, 27 Apr 1999 19:08:40 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: "Kenneth D. Merry" Cc: jkf@wolfnet.org, freebsd-scsi@FreeBSD.ORG Subject: Re: Boot-time scsi probe problem In-Reply-To: <199904132016.OAA04551@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 13 Apr 1999, Kenneth D. Merry wrote: [stuff about the onboard 7890 locking on boot on an ASUS P2B-LS snipped] > > It's a timing issue of some sort. > > Try a -stable snapshot from *after* March 23rd, and you should be able to > boot fairly regularly. The problem hasn't been fixed, but Justin committed > a work-around that seems to eliminate it most of the time. > > I don't think he has heard anything back from Adaptec on the problem yet. Is there any more news on this issue? This machine's not in production yet, so I still have time to fiddle about. I still see the problem now and then (always at the worst time). As a reminder, I see this much more on this machine that has the 7890 onboard in addition to a 2940U2W. Never seen it on other machines using the 7890 yet... Thanks, Charles > Ken > -- > Kenneth Merry > ken@plutotech.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 27 16:19:27 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 46E9814C88 for ; Tue, 27 Apr 1999 16:19:24 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id RAA65980; Tue, 27 Apr 1999 17:19:17 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904272319.RAA65980@panzer.plutotech.com> Subject: Re: Boot-time scsi probe problem In-Reply-To: from spork at "Apr 27, 1999 7: 8:40 pm" To: spork@super-g.com (spork) Date: Tue, 27 Apr 1999 17:19:17 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org spork wrote... > > On Tue, 13 Apr 1999, Kenneth D. Merry wrote: > > [stuff about the onboard 7890 locking on boot on an ASUS P2B-LS snipped] > > > > It's a timing issue of some sort. > > > > Try a -stable snapshot from *after* March 23rd, and you should be able to > > boot fairly regularly. The problem hasn't been fixed, but Justin committed > > a work-around that seems to eliminate it most of the time. > > > > I don't think he has heard anything back from Adaptec on the problem yet. > > Is there any more news on this issue? This machine's not in production > yet, so I still have time to fiddle about. I still see the problem now > and then (always at the worst time). As a reminder, I see this much more > on this machine that has the 7890 onboard in addition to a 2940U2W. Never > seen it on other machines using the 7890 yet... I haven't heard anything about it. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 27 23:33:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from slip1.raccoon.com (slip1.raccoon.com [165.90.135.16]) by hub.freebsd.org (Postfix) with ESMTP id DAA5A15625 for ; Tue, 27 Apr 1999 23:33:41 -0700 (PDT) (envelope-from johnl@raccoon.com) Received: from raccoon.com (dsl-ip145.networkiowa.com [165.90.140.145]) by slip1.raccoon.com (8.8.7/8.8.7) with ESMTP id BAA00677 for ; Wed, 28 Apr 1999 01:29:23 -0500 Message-ID: <3727FA0C.E3780714@raccoon.com> Date: Thu, 29 Apr 1999 01:19:56 -0500 From: John Lengeling X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: Problems with HP T20 SCSI Travan under FreeBSD 3.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have an HP T20 SCSI Travan tape driver under FreeBSD 3.1 connected to an Adaptec 2940UW controller. Kernel sees the 2940 and the HP T20 drive. I created the device using MAKEDEV sa0. When I insert the cartridge, the drive scans back and forth a bit like a QIC drive. Looks like some other error was returned from the probe. When I try to do anything with the drive like tar (tar -cvf /dev/rsa0) or mt status, I get: LOAD UNLOAD CDB 1B 0 0 0 10 MEDIUM ERROR asc:15,2 Positioning Error detected by read of medium. What is up? Will the T20 work under FreeBSD 3.1? I have included my boot -v output. Is it specific to the HP T20, or will or will Exabyte 8200/8500s or HP 4MM drives work under 3.1? 10b7, dev=0x9058, revid=0x00 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=10 map[0]: type 4, range 32, base 0000ec00, size 7 map[1]: type 1, range 32, base febfef80, size 7 xl0: <3Com 3c905B-COMBO Fast Etherlink XL> rev 0x00 int a irq 10 on pci0.19.0 xl0: Ethernet address: 00:50:04:66:84:22 xl0: media options word: 3a xl0: probing for a PHY xl0: checking address: 0 xl0: checking address: 1 xl0: checking address: 2 xl0: checking address: 3 xl0: checking address: 4 xl0: checking address: 5 xl0: checking address: 6 xl0: checking address: 7 xl0: checking address: 8 xl0: checking address: 9 xl0: checking address: 10 xl0: checking address: 11 xl0: checking address: 12 xl0: checking address: 13 xl0: checking address: 14 xl0: checking address: 15 xl0: checking address: 16 xl0: checking address: 17 xl0: checking address: 18 xl0: checking address: 19 xl0: checking address: 20 xl0: checking address: 21 xl0: checking address: 22 xl0: checking address: 23 xl0: checking address: 24 xl0: found PHY at address 24, vendor id: 0 device id: 0 xl0: PHY type: xl0: found 10baseT xl0: found AUI xl0: found BNC xl0: found 100baseTX xl0: autoneg complete, link status good (half-duplex, 10Mbps) bpf: xl0 attached Probing for devices on PCI bus 1: found-> vendor=0x1002, dev=0x4742, revid=0x5c class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[0]: type 1, range 32, base fd000000, size 24 map[1]: type 4, range 32, base 0000d800, size 8 map[2]: type 1, range 32, base feaff000, size 12 vga0: rev 0x5c on pci1.0.0 Initializing PnP override table Probing for PnP devices: Trying Read_Port at 203 CSN 1 Vendor ID: CSC4236 [0x3642630e] Serial 0xffffffff Comp ID: @@@0000 [0x00000000] Called nullpnp_probe with tag 0x00000001, type 0x3642630e port 0x0000 0x0000 0x0000 0x0000 irq 0:0 drq 4:4 en 0 This is a CS4236, but LDN 0 is disabled Probing for devices on the ISA bus: atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa sc0 on isa sc0: fb0 kbd0 sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa kbd0: atkbd0, AT 101/102 (2), config:0x10000, flags:0x3d0000 psm0: current command byte:0065 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 00 00 64 psm: status 00 03 64 psm: status 00 03 64 psm: status 10 00 64 psm: data 08 00 00 psm: data 08 00 00 psm: status 00 02 64 psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0, 2 buttons psm0: config:00000000, flags:00000000, packet size:3 psm0: syncmask:c0, syncbits:00 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 not found at 0x2f8 sio2: disabled, not probed. sio3: disabled, not probed. mss_probe: no address supplied, try default 0x530 mss_detect error, busy still set (0xff) sb_probe: no address supplied, try defaults (0x220,0x240) pcm0 not found fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 4121MB (8440992 sectors), 8374 cyls, 16 heads, 63 S/T, 512 B/S wd0: ATA INQUIRE valid = 0007, dmamword = 0007, apio = 0003, udma = 0407 wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (wd2): wd2: 8063MB (16514064 sectors), 16383 cyls, 16 heads, 63 S/T, 512 B/S wd2: ATA INQUIRE valid = 0007, dmamword = 0007, apio = 0003, udma = 0407 wdc1: unit 1 (atapi): , removable, accel, dma, iordis acd0: drive speed 5512KB/sec, 256KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 16 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked ppc: parallel port found at 0x378 ppc0: EPP SPP ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode nlpt0: on ppbus 0 nlpt0: Interrupt-driven port ppi0: on ppbus 0 plip: irq 7 plip0: on ppbus 0 bpf: lp0 attached vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3b0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xf00b8000 size:32k gran:32k, buf:0x0 size:0k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. imasks: bio c008c040, tty c0071492, net c0071492 BIOS Geometries: 0:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 1:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 2:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 3:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 4:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 5:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 6:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 7:00000000 0..0=1 cylinders, 0..0=1 heads, 1..0=0 sectors 0 accounted for Device configuration finished. bpf: tun0 attached bpf: sl0 attached bpf: ppp0 attached new masks: bio c008c040, tty c0071492, net c0071492 bpf: lo0 attached Waiting 15 seconds for SCSI devices to settle (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. ahc0: Selection Timeout on A:0. 1 SCBs aborted ahc0: Selection Timeout on A:1. 1 SCBs aborted ahc0: Selection Timeout on A:2. 1 SCBs aborted ahc0: Selection Timeout on A:3. 1 SCBs aborted ahc0: Selection Timeout on A:5. 1 SCBs aborted ahc0: Selection Timeout on A:6. 1 SCBs aborted ahc0: Selection Timeout on A:8. 1 SCBs aborted ahc0: Selection Timeout on A:9. 1 SCBs aborted ahc0: Selection Timeout on A:10. 1 SCBs aborted ahc0: Selection Timeout on A:11. 1 SCBs aborted ahc0: Selection Timeout on A:12. 1 SCBs aborted ahc0: Selection Timeout on A:13. 1 SCBs aborted ahc0: Selection Timeout on A:14. 1 SCBs aborted ahc0: Selection Timeout on A:15. 1 SCBs aborted (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 sa0 at ahc0 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 3.300MB/s transfers pass0 at ahc0 bus 0 target 4 lun 0 pass0: Removable Sequential Access SCSI-2 device pass0: 3.300MB/s transfers Considering MFS root f/s. No MFS image available as root f/s. Considering FFS root f/s. changing root device to wd0s1a wd0s1: type 0xa5, start 63, end = 8434124, size 8434062 : OK wd2s1: type 0xa5, start 63, end = 16514063, size 16514001 : OK wd2s1: type 0xa5, start 63, end = 16514063, size 16514001 : OK Linux-ELF exec handler installed splash: image decoder found: logo_saver (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 (sa0:ahc0:0:4:0): MEDIUM ERROR asc:15,2 (sa0:ahc0:0:4:0): Positioning error detected by read of medium (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 (sa0:ahc0:0:4:0): MEDIUM ERROR asc:15,2 (sa0:ahc0:0:4:0): Positioning error detected by read of medium (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 (sa0:ahc0:0:4:0): MEDIUM ERROR asc:15,2 (sa0:ahc0:0:4:0): Positioning error detected by read of medium JohnL To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 0:21: 6 1999 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 A43D315508 for ; Wed, 28 Apr 1999 00:20:59 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id JAA22470 for freebsd-scsi@FreeBSD.ORG; Wed, 28 Apr 1999 09:20:58 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id JAA37612; Wed, 28 Apr 1999 09:16:24 +0200 (MET DST) (envelope-from j) Message-ID: <19990428091622.29861@uriah.heep.sax.de> Date: Wed, 28 Apr 1999 09:16:22 +0200 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) Reply-To: Joerg Wunsch References: <19990420023954.A20589@saturn.kn-bremen.de> <19990427212815.A674@saturn.kn-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <19990427212815.A674@saturn.kn-bremen.de>; from Juergen Lock on Tue, Apr 27, 1999 at 09:28:15PM +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 As Juergen Lock wrote: > Huh!?? Why on earth is it trying to write filemarks?? Good that the > tape was write protected... Ouch! It seems `mt rdhpos' and/or `mt rdspos' trashed my backup tape as well... Both reported 0 (correctly, the tape was at BOT), but any attempt to `mt fsr' afterwards yielded a blank check. :-( -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 8:24:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id EA87B1547E for ; Wed, 28 Apr 1999 08:24:18 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id IAA24810; Wed, 28 Apr 1999 08:23:52 -0700 Date: Wed, 28 Apr 1999 08:23:51 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Lengeling Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Problems with HP T20 SCSI Travan under FreeBSD 3.1 In-Reply-To: <3727FA0C.E3780714@raccoon.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 For once I actually *have* such a device. > (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 > (sa0:ahc0:0:4:0): MEDIUM ERROR asc:15,2 > (sa0:ahc0:0:4:0): Positioning error detected by read of medium This error sounds like you haven't got the right kind of media. The drive is very picky. I really have only used C4435 (HP tested/certified 20GB TR-5 cartridge). I ordered some TR-4s by mistake. No can do. Other than that, add: { { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP", "T20*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512 }, and that seems to work so far for me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 8:40:12 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 67731150E9 for ; Wed, 28 Apr 1999 08:40:06 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id IAA24907; Wed, 28 Apr 1999 08:39:34 -0700 Date: Wed, 28 Apr 1999 08:39:34 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Joerg Wunsch , Juergen Lock Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) In-Reply-To: <19990428091622.29861@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > As Juergen Lock wrote: > > > Huh!?? Why on earth is it trying to write filemarks?? Good that the > > tape was write protected... > > Ouch! It seems `mt rdhpos' and/or `mt rdspos' trashed my backup tape > as well... Both reported 0 (correctly, the tape was at BOT), but any > attempt to `mt fsr' afterwards yielded a blank check. > > :-( > Sorry- I really hadn't parsed the previous message. These are *amazingly* broken drives then. The SCSI specification says that a write of *zero* filemarks is to flush any pending writes. You have to do this when you do a read hardware position in order to avoid an ambiguity in the spec as to the true position as affected by data in the tape drive buffer. This is not an abstruse edge case in the SCSI spec. This is common sense as well. I believe that the writers of QIC f/w should be sent to Redmond for the rest of their miserable lives. The only other time filemarks are written is when you explicitly do them via the ioctl or at saclose time when SA_FLAG_TAPE_WRITTEN was set (which is only set after a block I/O write of data). There's a limited amount we can do to get around completely broken hardware. I'm sorry you've got broken h/w here if it's doing this when it receives a zero count. This hardware should be thrown out. Or don't try use the read h/w position. This may sound offensive, but there it is. Or buy a Siemens system where they're just as lackadaisical with specs and tend to lose sales to real engineering. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 8:55:30 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from relay1.mail.uk.psi.net (relay1.mail.uk.psi.net [154.32.105.6]) by hub.freebsd.org (Postfix) with ESMTP id 6BC0015768 for ; Wed, 28 Apr 1999 08:55:21 -0700 (PDT) (envelope-from amobbs@allstor-sw.co.uk) Received: from mail.plasmon.co.uk ([193.115.5.217]) by relay1.mail.uk.psi.net with smtp (Exim 2.02 #3) id 10cWg4-0005TK-00 for freebsd-scsi@FreeBSD.ORG; Wed, 28 Apr 1999 16:55:13 +0100 Received: by mail.plasmon.co.uk(Lotus SMTP MTA v4.6.2 (693.3 8-11-1998)) id 80256761.00572DA9 ; Wed, 28 Apr 1999 16:52:13 +0100 X-Lotus-FromDomain: PLASNOTES From: amobbs@allstor-sw.co.uk To: freebsd-scsi@FreeBSD.ORG Message-ID: <80256761.00572CBF.00@mail.plasmon.co.uk> Date: Wed, 28 Apr 1999 16:52:10 +0100 Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev /nrst0' process, can i debug it?) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >These are *amazingly* broken drives then. The SCSI specification says that >a write of *zero* filemarks is to flush any pending writes. You have to do >this when you do a read hardware position in order to avoid an ambiguity >in the spec as to the true position as affected by data in the tape drive >buffer. Doesn't Read Position (34h) give all the info you need, i.e. Physical pos., logical pos. and number of blocks in buffer? I agree that flushing is safer, but surely one could avoid it if necessary. Andrew. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 8:58: 3 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 51945154CF for ; Wed, 28 Apr 1999 08:57:57 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id IAA25039; Wed, 28 Apr 1999 08:57:07 -0700 Date: Wed, 28 Apr 1999 08:57:06 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Joerg Wunsch , Juergen Lock Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > These are *amazingly* broken drives then. The SCSI specification says that > a write of *zero* filemarks is to flush any pending writes. You have to do > this when you do a read hardware position in order to avoid an ambiguity > in the spec as to the true position as affected by data in the tape drive > buffer. This is not an abstruse edge case in the SCSI spec. This is common > sense as well. I believe that the writers of QIC f/w should be sent to > Redmond for the rest of their miserable lives. > That said, try this patch: *** scsi_sa.c.prev Wed Apr 28 08:54:12 1999 --- scsi_sa.c Wed Apr 28 08:56:43 1999 *************** *** 2723,2735 **** { struct scsi_tape_position_data loc; union ccb *ccb; ! struct sa_softc *softc; ! int error; /* ! * First flush any pending writes... */ ! error = sawritefilemarks(periph, 0, 0); /* * The latter case is for 'write protected' tapes --- 2723,2738 ---- { struct scsi_tape_position_data loc; union ccb *ccb; ! struct sa_softc *softc = (struct sa_softc *)periph->softc; ! int error = 0; /* ! * First flush any pending writes (if any had occurred). ! * Amazingly stupid drives sometimes take a zero count ! * and say "Duh! Zero must mean One!". */ ! if (softc->flags & SA_FLAG_TAPE_WRITTEN) ! error = sawritefilemarks(periph, 0, 0); /* * The latter case is for 'write protected' tapes *************** *** 2739,2745 **** if (error != 0 && error != EACCES) return (error); - softc = (struct sa_softc *)periph->softc; ccb = cam_periph_getccb(periph, 1); scsi_read_position(&ccb->csio, 1, sadone, MSG_SIMPLE_Q_TAG, --- 2742,2747 ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 9:12:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 17E8B14E94 for ; Wed, 28 Apr 1999 09:12:47 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA25129; Wed, 28 Apr 1999 09:12:31 -0700 Date: Wed, 28 Apr 1999 09:12:30 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: amobbs@allstor-sw.co.uk Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev /nrst0' process, can i debug it?) In-Reply-To: <80256761.00572CBF.00@mail.plasmon.co.uk> 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 > > > > > >These are *amazingly* broken drives then. The SCSI specification says that > >a write of *zero* filemarks is to flush any pending writes. You have to do > >this when you do a read hardware position in order to avoid an ambiguity > >in the spec as to the true position as affected by data in the tape drive > >buffer. > > Doesn't Read Position (34h) give all the info you need, i.e. Physical pos., > logical pos. and number of blocks in buffer? I agree that flushing is > safer, but surely one could avoid it if necessary. > Now *that's* an area I would mistrust the f/w on- yes, you get number of blocks in the buffer (you use a flag in the cdb to select SCSI logical vs. hardware, and there's *nothing* that says that any device has to support either. STK drives puke on SCSI logical block reporting. DLT's puke on hardware block reporting). I think the patch I sent is probably the right approach. It's always a tradeoff- features vs. supporting really broken h/w. It really ticks me that this is broken. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 12:22: 0 1999 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 9D21E14F92 for ; Wed, 28 Apr 1999 12:21:53 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id VAA05548 for freebsd-scsi@FreeBSD.ORG; Wed, 28 Apr 1999 21:21:52 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id VAA00807; Wed, 28 Apr 1999 21:08:36 +0200 (MET DST) (envelope-from j) Message-ID: <19990428210836.47084@uriah.heep.sax.de> Date: Wed, 28 Apr 1999 21:08:36 +0200 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) Reply-To: Joerg Wunsch References: <19990428091622.29861@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Matthew Jacob on Wed, Apr 28, 1999 at 08:39:34AM -0700 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 As Matthew Jacob wrote: > These are *amazingly* broken drives then. The SCSI specification > says that a write of *zero* filemarks is to flush any pending > writes. Well, but it doesn't say nothing must be written. ;-) The SCSI spec's a little thin in describing what needs to be done upon receipt of a WRITE FILEMARKS with a zero count, and what must not be done. However, i agree that's a bug in the Tandberg since it violates the Tandberg SCSI reference as well which indeed claims nothing would be written. However, trying to issue a WRITE FILEMARKS on a tape that has never been written so far is IMHO an mistake, and the SCSI specs don't seem to forbid that the drive refuses the command at all iff the medium is write-protected. So if at all, this `flush buffers' should IMHO only be done after the tape has actually been written to (which is already being tracked inside the driver). However(2), while i was at it, i traced the CAM CCBs, and i couldn't think of any scenario where a still-buffered write operation could get into your way at all. Whatever you're doing, either the application that holds the tape open for writing hasn't finished yet, in which case any further attempt to open the tape will be denied, or said application already caused a real filemark to be written (which by SCSI definition causes any buffered data to be written out before the WRITE FILEMARKS (with a count of >= 1) returns). So what's the scenario where you think you really need another WRITE FILEMARKS with a count of 0? > I believe that the writers of QIC f/w should be sent to > Redmond for the rest of their miserable lives. Nah, c'mon, it's just one bug in the firmware. By your terms, you could easily throw away almost any SCSI hardware since they often suffer more serious firmware bugs... -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 12:46:54 1999 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 E9F0614EDE for ; Wed, 28 Apr 1999 12:46:49 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id VAA06129 for freebsd-scsi@FreeBSD.ORG; Wed, 28 Apr 1999 21:46:48 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id VAA00474; Wed, 28 Apr 1999 21:46:10 +0200 (MET DST) (envelope-from j) Message-ID: <19990428214609.07248@uriah.heep.sax.de> Date: Wed, 28 Apr 1999 21:46:09 +0200 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) Reply-To: Joerg Wunsch References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Matthew Jacob on Wed, Apr 28, 1999 at 08:57:06AM -0700 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 As Matthew Jacob wrote: > That said, try this patch: This works, except > *************** > *** 2739,2745 **** > if (error != 0 && error != EACCES) > return (error); > > - softc = (struct sa_softc *)periph->softc; > ccb = cam_periph_getccb(periph, 1); > > scsi_read_position(&ccb->csio, 1, sadone, MSG_SIMPLE_Q_TAG, > --- 2742,2747 ---- > ...this hunk failed to patch (and manually patching it this way yielded a `softc might be used unitiniatilized' warning, so i figure your source was a little different). Well, there are still some superfluous WRITE FILEMARKS, nevertheless. I played a little with `mt rdhpos' and `mt sethpos', and it seems the `set' operations make the driver think anything had been written, so it's also issuing the WRITE FILEMARKS command. This doesn't seem to write any filemarks, indeed, as long as it happens after BOT, _but_ issuing an `mt sethpos 1' _at_ BOT still erases the tape then... Is there any reason why the driver sets the SA_FLAG_TAPE_WRITTEN flag for just the `mt set*pos' operation? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 12:57:38 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from blaubaer.kn-bremen.de (blaubaer.kn-bremen.de [194.94.232.249]) by hub.freebsd.org (Postfix) with ESMTP id 9364B154A4 for ; Wed, 28 Apr 1999 12:57:33 -0700 (PDT) (envelope-from nox@saturn.kn-bremen.de) Received: from saturn.kn-bremen.de (uucp@localhost) by blaubaer.kn-bremen.de (8.9.1/8.9.1) with UUCP id VAA23766; Wed, 28 Apr 1999 21:50:30 +0200 Received: (from nox@localhost) by saturn.kn-bremen.de (8.9.3/8.8.5) id VAA01204; Wed, 28 Apr 1999 21:51:37 +0200 (MET DST) From: Juergen Lock Date: Wed, 28 Apr 1999 21:51:37 +0200 To: Matthew Jacob Cc: Joerg Wunsch , freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) Message-ID: <19990428215136.A943@saturn.kn-bremen.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Matthew Jacob on Wed, Apr 28, 1999 at 08:57:06AM -0700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Apr 28, 1999 at 08:57:06AM -0700, Matthew Jacob wrote: > > > > These are *amazingly* broken drives then. The SCSI specification says that > > a write of *zero* filemarks is to flush any pending writes. You have to do > > this when you do a read hardware position in order to avoid an ambiguity > > in the spec as to the true position as affected by data in the tape drive > > buffer. This is not an abstruse edge case in the SCSI spec. This is common > > sense as well. I believe that the writers of QIC f/w should be sent to > > Redmond for the rest of their miserable lives. :) > > That said, try this patch: > [snip] Thanx, this fixes rdhpos. sethpos still does the sawritefilemarks() unconditionally... And do you have any idea as to the other problems, why mt bl(ocksize) stopped working and why the reading process after sethpos gets Input/output error and then hangs at cgticb? Inquiring minds, etc... Regards, -- Juergen Lock (remove dot foo from address to reply) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 13:44:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D392514E36 for ; Wed, 28 Apr 1999 13:44:17 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id NAA26442; Wed, 28 Apr 1999 13:43:59 -0700 Date: Wed, 28 Apr 1999 13:43:58 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) In-Reply-To: <19990428210836.47084@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > WRITE FILEMARKS (with a count of >= 1) returns). So what's the > scenario where you think you really need another WRITE FILEMARKS with > a count of 0? At < 10MB/s tape transport speed you'll have data in the tape buffers for geologic time after you've finished the WRITE command (remember- you're in buffered mode) and want to read position. > > > I believe that the writers of QIC f/w should be sent to > > Redmond for the rest of their miserable lives. > > Nah, c'mon, it's just one bug in the firmware. By your terms, you > could easily throw away almost any SCSI hardware since they often > suffer more serious firmware bugs... > #&%*(#%*#%*&!!!! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 13:51: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3591D14E36 for ; Wed, 28 Apr 1999 13:51:00 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id NAA26467; Wed, 28 Apr 1999 13:49:40 -0700 Date: Wed, 28 Apr 1999 13:49:38 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) In-Reply-To: <19990428214609.07248@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > ...this hunk failed to patch (and manually patching it this way > yielded a `softc might be used unitiniatilized' warning, so i figure > your source was a little different). Yes, I'm off of -current. > > Well, there are still some superfluous WRITE FILEMARKS, nevertheless. > I played a little with `mt rdhpos' and `mt sethpos', and it seems the > `set' operations make the driver think anything had been written, so > it's also issuing the WRITE FILEMARKS command. This doesn't seem to > write any filemarks, indeed, as long as it happens after BOT, _but_ > issuing an `mt sethpos 1' _at_ BOT still erases the tape then... Is > there any reason why the driver sets the SA_FLAG_TAPE_WRITTEN flag for > just the `mt set*pos' operation? Oh- sorry- the same bloody patch applies to sasetpos too- this is what I get for doing this on the fly while working on 50 other projects (and answering this email through a clogged 144Kb DSL line because there's half a dozen dweebs getting the linux networker client from my site....).. static int sardpos(struct cam_periph *periph, int hard, u_int32_t *blkptr) { struct scsi_tape_position_data loc; union ccb *ccb; struct sa_softc *softc = (struct sa_softc *)periph->softc; int error = 0; /* * First flush any pending writes (if any had occurred). * Amazingly stupid drives sometimes take a zero count * and say "Duh! Zero must mean One!". */ if (softc->flags & SA_FLAG_TAPE_WRITTEN) error = sawritefilemarks(periph, 0, 0); /* * The latter case is for 'write protected' tapes * which are too stupid to recognize a zero count * for writing filemarks as a no-op. */ if (error != 0 && error != EACCES) return (error); ccb = cam_periph_getccb(periph, 1); scsi_read_position(&ccb->csio, 1, sadone, MSG_SIMPLE_Q_TAG, hard, &loc, SSD_FULL_SIZE, 5000); softc->dsreg = MTIO_DSREG_RBSY; error = cam_periph_runccb(ccb, saerror, 0, 0, &softc->device_stats); softc->dsreg = MTIO_DSREG_REST; if ((ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) cam_release_devq(ccb->ccb_h.path, 0, 0, 0, 0); if (error == 0) { if (loc.flags & SA_RPOS_UNCERTAIN) { error = EINVAL; /* nothing is certain */ } else { *blkptr = scsi_4btoul(loc.firstblk); } } xpt_release_ccb(ccb); return (error); } static int sasetpos(struct cam_periph *periph, int hard, u_int32_t *blkptr) { union ccb *ccb; struct sa_softc *softc = (struct sa_softc *)periph->softc; int error = 0; /* * First flush any pending writes (if any had occurred). * Amazingly stupid drives sometimes take a zero count * and say "Duh! Zero must mean One!". */ if (softc->flags & SA_FLAG_TAPE_WRITTEN) error = sawritefilemarks(periph, 0, 0); /* * The latter case is for 'write protected' tapes * which are too stupid to recognize a zero count * for writing filemarks as a no-op. */ if (error != 0 && error != EACCES) return (error); softc = (struct sa_softc *)periph->softc; ccb = cam_periph_getccb(periph, 1); scsi_set_position(&ccb->csio, 1, sadone, MSG_SIMPLE_Q_TAG, hard, *blkptr, SSD_FULL_SIZE, 60 * 60 * 1000); softc->dsreg = MTIO_DSREG_POS; error = cam_periph_runccb(ccb, saerror, 0, 0, &softc->device_stats); softc->dsreg = MTIO_DSREG_REST; if ((ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) cam_release_devq(ccb->ccb_h.path, 0, 0, 0, 0); xpt_release_ccb(ccb); /* * Note relative file && block number position now unknown (if * these things ever start being maintained in this driver). * * Do this for any kind of error (to be safe). */ softc->fileno = softc->blkno = (daddr_t) -1; return (error); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 13:51:51 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 1FDC814E36 for ; Wed, 28 Apr 1999 13:51:47 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id NAA26476; Wed, 28 Apr 1999 13:50:50 -0700 Date: Wed, 28 Apr 1999 13:50:49 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Juergen Lock Cc: Joerg Wunsch , freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) In-Reply-To: <19990428215136.A943@saturn.kn-bremen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Thanx, this fixes rdhpos. sethpos still does the sawritefilemarks() > unconditionally... see other > And do you have any idea as to the other problems, > why mt bl(ocksize) stopped working and why the reading process after > sethpos gets Input/output error and then hangs at cgticb? No, not yet. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 14:14:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by hub.freebsd.org (Postfix) with ESMTP id 80CC0151D1 for ; Wed, 28 Apr 1999 14:14:31 -0700 (PDT) (envelope-from gemorga2@vt.edu) Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id RAA14557 for ; Wed, 28 Apr 1999 17:14:29 -0400 (EDT) Received: from gemorga2.campus.vt.edu (gemorga2.campus.vt.edu [198.82.100.219]) by sable.cc.vt.edu (8.8.8/8.8.8) with SMTP id RAA09401 for ; Wed, 28 Apr 1999 17:14:28 -0400 (EDT) Message-Id: <199904282114.RAA09401@sable.cc.vt.edu> From: "George Morgan" To: freebsd-scsi@freebsd.org Date: Wed, 28 Apr 1999 17:14:29 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: A good compliant tape drive... X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org So does anyone make a tape drive with good compliant firmware???? That works all the time with 3.1??? With all the discussion about different tape drives from vendors that I thought were pretty good (like Tandberg) I now wonder if such a beast exists? Thanks. George Morgan Virginia Tech Electrical Engineering Class of 2000! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 20:17:40 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from slip1.raccoon.com (slip1.raccoon.com [165.90.135.16]) by hub.freebsd.org (Postfix) with ESMTP id 6B7A014C9C for ; Wed, 28 Apr 1999 20:17:38 -0700 (PDT) (envelope-from johnl@raccoon.com) Received: from raccoon.com (dsl-ip145.networkiowa.com [165.90.140.145]) by slip1.raccoon.com (8.8.7/8.8.7) with ESMTP id WAA20282; Wed, 28 Apr 1999 22:13:24 -0500 Message-ID: <3727C9F5.16A4D856@raccoon.com> Date: Wed, 28 Apr 1999 21:54:45 -0500 From: John Lengeling X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Problems with HP T20 SCSI Travan under FreeBSD 3.1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote: > > For once I actually *have* such a device. > > > (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 > > (sa0:ahc0:0:4:0): MEDIUM ERROR asc:15,2 > > (sa0:ahc0:0:4:0): Positioning error detected by read of medium > > This error sounds like you haven't got the right kind of media. The > drive is very picky. > > I really have only used C4435 (HP tested/certified 20GB TR-5 cartridge). > I ordered some TR-4s by mistake. No can do. I am using brand new C4435 20GB TR-5 tapes. The drive worked when it was in a RedHat 4.2 machine. I tried two brand new tapes. Both failed with the same error. > > Other than that, add: > > { > { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP", > "T20*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512 > }, > > and that seems to work so far for me. I will try this tomorrow and let you know. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 23:24:39 1999 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 1EF3B14E00 for ; Wed, 28 Apr 1999 23:24:33 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA15510 for freebsd-scsi@FreeBSD.ORG; Thu, 29 Apr 1999 08:24:32 +0200 (CEST) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.3/8.9.1) id IAA03062; Thu, 29 Apr 1999 08:20:07 +0200 (MET DST) (envelope-from j) Message-ID: <19990429082006.15161@uriah.heep.sax.de> Date: Thu, 29 Apr 1999 08:20:06 +0200 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) Reply-To: Joerg Wunsch References: <19990428210836.47084@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Matthew Jacob on Wed, Apr 28, 1999 at 01:43:58PM -0700 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 As Matthew Jacob wrote: > > So what's the > > scenario where you think you really need another WRITE FILEMARKS with > > a count of 0? > > At < 10MB/s tape transport speed you'll have data in the tape buffers for > geologic time after you've finished the WRITE command (remember- you're in > buffered mode) and want to read position. Well, but you didn't read the remainder of my article, did you? The thing is, before you can get at issuing an ioctl(MTIOCRD*POS), unless you're doing this inside the application that's currently writing (none of the existing apps would do so), the application writing data has to close the tape device first. Closing the tape device after a write operation always results in writing at least one filemark (withouth the `Imm' bit set in the CCB), so this by definition flushes the write buffer. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 28 23:41: 1 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 66B5C14CA2 for ; Wed, 28 Apr 1999 23:40:54 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id XAA28388; Wed, 28 Apr 1999 23:40:34 -0700 Date: Wed, 28 Apr 1999 23:40:33 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Joerg Wunsch Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev/nrst0' process, can i debug it?) In-Reply-To: <19990429082006.15161@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > As Matthew Jacob wrote: > > > > So what's the > > > scenario where you think you really need another WRITE FILEMARKS with > > > a count of 0? > > > > At < 10MB/s tape transport speed you'll have data in the tape buffers for > > geologic time after you've finished the WRITE command (remember- you're in > > buffered mode) and want to read position. > > Well, but you didn't read the remainder of my article, did you? I thought I had. I apologize if I hadn't. I was likely reading it over a very slow dsl line. > > The thing is, before you can get at issuing an ioctl(MTIOCRD*POS), > unless you're doing this inside the application that's currently > writing (none of the existing apps would do so), the application > writing data has to close the tape device first. Closing the tape > device after a write operation always results in writing at least one > filemark (withouth the `Imm' bit set in the CCB), so this by > definition flushes the write buffer. > Yes, but saying none of the current applications do the behaviour of write write rdhpos write is not correct behaviour. The expected and usual behaviour of this feature is to use it within an application- not via the mt(1) command. The expected usage would be likely be to read position and then write a record- and flushing a previous write is a good thing. It isn't just a case of flushing to make it easier for getting reported position. There have been proposed, I seem to recall, specific changes to the Solaris tape driver to handle DDI_SUSPEND events for the E10K class of machines- you get a DDI_SUSPEND, so you throw a 'Flush' at the drive so that the data that you've lied about being committed to media is actually committed to media. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 29 11:46:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id F30A814BCE for ; Thu, 29 Apr 1999 11:46:41 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA30806; Thu, 29 Apr 1999 11:46:08 -0700 Date: Thu, 29 Apr 1999 11:46:07 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Lengeling Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Problems with HP T20 SCSI Travan under FreeBSD 3.1 In-Reply-To: <3727C9F5.16A4D856@raccoon.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 > > Matthew Jacob wrote: > > > > For once I actually *have* such a device. > > > > > (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 > > > (sa0:ahc0:0:4:0): MEDIUM ERROR asc:15,2 > > > (sa0:ahc0:0:4:0): Positioning error detected by read of medium > > > > This error sounds like you haven't got the right kind of media. The > > drive is very picky. > > > > I really have only used C4435 (HP tested/certified 20GB TR-5 cartridge). > > I ordered some TR-4s by mistake. No can do. > > I am using brand new C4435 20GB TR-5 tapes. The drive worked when it > was in a RedHat 4.2 machine. I tried two brand new tapes. Both failed > with the same error. > > > > > Other than that, add: > > > > { > > { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP", > > "T20*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512 > > }, > > > > and that seems to work so far for me. > > I will try this tomorrow and let you know. > Work for you? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 29 12:50:25 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (Postfix) with ESMTP id E35CE15602 for ; Thu, 29 Apr 1999 12:50:12 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id PAA03814 for ; Thu, 29 Apr 1999 15:50:11 -0400 (EDT) Date: Thu, 29 Apr 1999 15:50:10 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: freebsd-scsi@freebsd.org Subject: device assignment 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 Hi, I have two scsi controllers, a built-in 7890 and a 2940-U2W. When I installed, bios drive "0" and da0 were at ID 0 of the 7890 controller, so the boot process and the root filesystem were both on the potentially buggy 7890. To see if I could fix the problem by booting from the 2940-U2W, I swapped the drives from one controller to the other and told the BIOS that the 7890 should *not* be the boot device. ahc0 is the 7890 and ahc1 is the 2940 card. So it does now boot from that drive, but when it goes to mount root, it wants to mount the first device on ahc0, which is another drive. What determines the device mappings here? Can I fix this or must I reinstall? Why does the built-in controller always get ahc0 instead of ahc1? Help. Charles --- Charles Sprickman spork@super-g.com --- "...there's no idea that's so good you can't ruin it with a few well-placed idiots." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 29 13: 1:44 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id CB48215917 for ; Thu, 29 Apr 1999 13:01:11 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA78007; Thu, 29 Apr 1999 14:01:07 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199904292001.OAA78007@panzer.plutotech.com> Subject: Re: device assignment In-Reply-To: from spork at "Apr 29, 1999 3:50:10 pm" To: spork@super-g.com (spork) Date: Thu, 29 Apr 1999 14:01:07 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org spork wrote... > Hi, > > I have two scsi controllers, a built-in 7890 and a 2940-U2W. When I > installed, bios drive "0" and da0 were at ID 0 of the 7890 controller, so > the boot process and the root filesystem were both on the potentially > buggy 7890. Both of those controllers have 7890's on board... > To see if I could fix the problem by booting from the 2940-U2W, I swapped > the drives from one controller to the other and told the BIOS that the > 7890 should *not* be the boot device. ahc0 is the 7890 and ahc1 is the > 2940 card. > > So it does now boot from that drive, but when it goes to mount root, it > wants to mount the first device on ahc0, which is another drive. > > What determines the device mappings here? Can I fix this or must I > reinstall? Why does the built-in controller always get ahc0 instead of > ahc1? FreeBSD's device assignment is generally determined by probe order. PCI devices are probed in ascending order, regardless of what order the BIOS probes things in. (Note that the probe order is a bit different now in -current for machines with more than one PCI bus. Doug Rabson said that he's planning on writing code that will at least allow the old probing behavior.) You need to do the following in the loader to get things to work, assuming that the drive you want to boot off of is "da1": set root_disk_unit=1 Then in your fstab, make sure that your root filesystem, etc., reference da1, not da0. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 2 12:32:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from hpcs14.dv.fal.de (hpcs14e.dv.fal.de [134.110.18.14]) by hub.freebsd.org (Postfix) with ESMTP id DC83C14EA5 for ; Sun, 2 May 1999 12:32:48 -0700 (PDT) (envelope-from kraft@hpcs14.dv.fal.de) Received: (from kraft@localhost) by hpcs14.dv.fal.de (8.9.1/8.9.1) id VAA21296; Sun, 2 May 1999 21:32:38 +0200 (MET) From: Martin Kraft Message-Id: <199905021932.VAA21296@hpcs14.dv.fal.de> Subject: Re: i/o error with larger QIC To: mjacob@feral.com Date: Sun, 2 May 1999 21:32:37 +0200 (MET) Cc: freebsd-scsi@freebsd.org In-Reply-To: from "Matthew Jacob" at Apr 17, 99 02:48:52 pm Reply-To: martin.kraft@fal.de X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry for the delay! Matthew Jacob wrote: > > > Hello Matthew and Stefan, > > > > thanks for your assistance! > > > > Stefan Huerter wrote: > > > > > > Try: > > > mt blocksize 0 > > > This should work for you, too. I hope so :-) > > > > What's that?!?!?! > > > > I typed "mt blocksize 0", and -- the first time -- I could tar -t and > > tar -x a file from my old DC 6525. Great! So far :-( > > > > I extracted a small file close to the beginning of the tape. It took > > just a few seconds (as usual) and the file was on my disk. > > > > But after that, the tape didn't rewind and stop, as it did in former time, > > it now is rewinding forwards and backwards since more than 30 minutes. > > This is what I'm worried about. If you're in *variable* mode, the drive is > faking it. QIC is a fixed block format. If you set it to variable mode, > I think it tries to guess the block layout, and it sounds like it's having > a rough go of it. > > > > > What a surprise > > > > Martin Kraft > > > > > > P.S. 35 minutes. Just another turn. I will kill the tar process, because > > I don't have a fire extinguisher at home ... Very strange ... > > > > Do you remember what blocksize you *wrote* these tapes with? If you do, > set the blocksize for the drive fixed at that size and try read with the > tar command (setting to the blocksize you used to write the tape). I > really wish I had manuals for this drive so I could try and figure what > they're trying to do. I don't know; I just used "tar -c" under 2.2.7. I try 10240: su-2.02# tar -t tar: read error on /dev/rsa0 : Input/output error su-2.02# mt blocksize 10240 su-2.02# tar -t ./ bin/ bin/cat bin/chio bin/chmod bin/cp bin/csh bin/date bin/dd bin/df bin/domainname bin/echo bin/expr bin/hostname bin/kill bin/ln ^C su-2.02# pwd /root su-2.02# mkdir mist su-2.02# cd mist su-2.02# tar -x bin/* But without succes: the drive is now rewinding forward and backward every thre seconds and no extracted file appears on the disk. I am not able to break the process with kill or even kill -9. Seems to be an autonomous operatione of the drive. I would like to add another fact to my previous description. Even with 150 MB tapes written under 2.2.7, after correctly extracting the desired files, the drive goes to wind the tape forward and backward infintitely. Martin Kraft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 2 16:46: 5 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from caern.limax.com (we-24-130-40-67.we.mediaone.net [24.130.40.67]) by hub.freebsd.org (Postfix) with ESMTP id 987D614DD2 for ; Sun, 2 May 1999 16:46:03 -0700 (PDT) (envelope-from obrien@leonardo.net) Received: from mobrien.ni.net (localhost [127.0.0.1]) by caern.limax.com (8.9.2/8.9.2) with ESMTP id QAA00436 for ; Sun, 2 May 1999 16:47:26 -0700 (PDT) (envelope-from obrien@leonardo.net) Message-Id: <199905022347.QAA00436@caern.limax.com> To: freebsd-scsi@freebsd.org Subject: A report on Quantum VP32210 Date: Sun, 02 May 1999 16:47:25 -0700 From: "Mike O'Brien" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a 2-gig Quantum drive that reports itself to 3.1-RELEASE as: da0: Fixed Direct Access SCSI-2 device da0: 10.0MB/s transfers (10.0MHz, offset 15) da0: 2103MB (4308352 512 byte sectors: 64H 32S/T 2103C) Left to its own devices, it gradually ticks down the "tagged openings". Then, occasionally, it does this number: Apr 24 21:14:02 caern /kernel: (da0:ahc0:0:0:0): SCB 0x24 - timed out while idle , LASTPHASE == 0x1, SEQADDR == 0x9 Apr 24 21:15:02 caern /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Apr 24 21:16:02 caern /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Apr 24 21:16:02 caern /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Apr 24 21:16:02 caern /kernel: Unexpected busfree. LASTPHASE == 0xa0 Apr 24 21:16:02 caern /kernel: SEQADDR == 0x151 Apr 24 21:16:02 caern /kernel: (da0:ahc0:0:0:0): SCB 0x2 - timed out while idle, LASTPHASE == 0x1, SEQADDR == 0xa Apr 24 21:16:02 caern /kernel: (da0:ahc0:0:0:0): Queuing a BDR SCB Apr 24 21:16:02 caern /kernel: (da0:ahc0:0:0:0): Bus Device Reset Message Sent Apr 24 21:16:02 caern /kernel: (da0:ahc0:0:0:0): no longer in timeout, status = 353 Apr 24 21:16:02 caern /kernel: Unexpected busfree. LASTPHASE == 0xa0 Apr 24 21:16:02 caern /kernel: SEQADDR == 0x151 This was diagnosed as "bad firmware." Ok, I went over to the Quantum website and downloaded the program QSHR_LDR and the latest firmware for a VP32210. The drive would not scan. QSHR_LDR found my 1-Gb Quantum Fireball just fine, but on the VP32210 it reported: Info: Unexpected Call to GetMsg_Out() with MsgID 0x1d Eight of these, all identical. An attempt to load the new firmware just hung. I retreated in disarray. I added an entry to the "quirk" table turning off tagged queuing to the drive. The problem went away. Just thought you all might like to know that this drive might have a problem. Mike O'Brien To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun May 2 18:26:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from slip1.raccoon.com (slip1.raccoon.com [165.90.135.16]) by hub.freebsd.org (Postfix) with ESMTP id 44847156A6 for ; Sun, 2 May 1999 18:26:51 -0700 (PDT) (envelope-from johnl@raccoon.com) Received: from raccoon.com (dsl-ip145.networkiowa.com [165.90.140.145]) by slip1.raccoon.com (8.8.7/8.8.7) with ESMTP id UAA30755; Sun, 2 May 1999 20:21:57 -0500 Message-ID: <32CA027A.F19D2561@raccoon.com> Date: Wed, 01 Jan 1997 00:21:46 -0600 From: John Lengeling X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Problems with HP T20 SCSI Travan under FreeBSD 3.1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I added the change to the quirk table and it still didn't work. I am going to verify that the drive works under NT next. Any you have this exact tape drive working correctly under 3.1-RELEASE? johnl Matthew Jacob wrote: > > > > > Matthew Jacob wrote: > > > > > > For once I actually *have* such a device. > > > > > > > (sa0:ahc0:0:4:0): LOAD UNLOAD. CDB: 1b 0 0 0 1 0 > > > > (sa0:ahc0:0:4:0): MEDIUM ERROR asc:15,2 > > > > (sa0:ahc0:0:4:0): Positioning error detected by read of medium > > > > > > This error sounds like you haven't got the right kind of media. The > > > drive is very picky. > > > > > > I really have only used C4435 (HP tested/certified 20GB TR-5 cartridge). > > > I ordered some TR-4s by mistake. No can do. > > > > I am using brand new C4435 20GB TR-5 tapes. The drive worked when it > > was in a RedHat 4.2 machine. I tried two brand new tapes. Both failed > > with the same error. > > > > > > > > Other than that, add: > > > > > > { > > > { T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "HP", > > > "T20*", "*"}, SA_QUIRK_FIXED|SA_QUIRK_1FM, 512 > > > }, > > > > > > and that seems to work so far for me. > > > > I will try this tomorrow and let you know. > > > > Work for you? > > 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 Mon May 3 19:37:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 763891577F for ; Mon, 3 May 1999 19:37:51 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id TAA10248; Mon, 3 May 1999 19:37:45 -0700 Date: Mon, 3 May 1999 19:37:44 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Lengeling Cc: freebsd-scsi@freebsd.org Subject: Re: Problems with HP T20 SCSI Travan under FreeBSD 3.1 In-Reply-To: <372E15B3.CB551A3@raccoon.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 (sharing this with the group)... The top of the FreeBSD-3.1 tree works with my T20 but poorly- that is, it writes tapes fine, but attempts to append fail if you use fsf to locate the end of media- this is because the writing of two filemarks (which it assumes it can do- while it has determined it has to be in fixed mode in samount it can't know that two filemarks aren't accepted), you get this (by now well known and embarrassing) nonsense: (sa0:ahc0:0:1:0): Write append position error (sa0:ahc0:0:1:0): WRITE(06). CDB: a 1 0 0 a 0 (sa0:ahc0:0:1:0): Deferred Error: MEDIUM ERROR info:2800 asc:50,1 (sa0:ahc0:0:1:0): Write append position error (sa0:ahc0:0:1:0): WRITE(06). CDB: a 1 0 0 a 0 (sa0:ahc0:0:1:0): Deferred Error: MEDIUM ERROR info:2800 asc:50,1 (sa0:ahc0:0:1:0): Write append position error (sa0:ahc0:0:1:0): WRITE(06). CDB: a 1 0 0 a 0 (sa0:ahc0:0:1:0): Deferred Error: MEDIUM ERROR info:2800 asc:50,1 (sa0:ahc0:0:1:0): Write append position error (sa0:ahc0:0:1:0): WRITE FILEMARKS. CDB: 10 0 0 0 2 0 (sa0:ahc0:0:1:0): MEDIUM ERROR info:1800 asc:50,1 (sa0:ahc0:0:1:0): Write append position error (sa0:ahc0:0:1:0): failure at writing filemarks - opting for safety whereupon it rewinds. Very stupid. If you use 'mt eod' to append, that works much better- but still seems iffy. Taking a snapshot of my current -current scsi_sa.[ch] with one minor tweak (for an ioctl I haven't pulled back yet) seems to work much better. I've tried a multi-tape file tar- and it seems to work for me w/o too much testing- feel free to snag the scsi_sa.c/scsi_sa.h from ftp://ftp.feral.com/pub/freebsd and try it on your drive. I should note that tcopy *hangs* in trying to evaluate these tapes- I have to track down what's happening here about this- this may be some interactions with blocks past an error not getting biodone'd correctly. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue May 4 22:31: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (Postfix) with ESMTP id 80BBC15B7F for ; Tue, 4 May 1999 22:31:05 -0700 (PDT) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.8/8.8.5) with SMTP id BAA13327; Wed, 5 May 1999 01:30:32 -0400 (EDT) Date: Wed, 5 May 1999 01:30:32 -0400 (EDT) From: spork X-Sender: spork@super-g.inch.com To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: device assignment In-Reply-To: <199904292001.OAA78007@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry for the late reply... I was trying to see if the 7890 problem varied if I booted off the card rather than the builtin chipset. No difference... still hangs. Thanks, Charles On Thu, 29 Apr 1999, Kenneth D. Merry wrote: > FreeBSD's device assignment is generally determined by probe order. PCI > devices are probed in ascending order, regardless of what order the BIOS > probes things in. (Note that the probe order is a bit different now in > -current for machines with more than one PCI bus. Doug Rabson said that > he's planning on writing code that will at least allow the old probing > behavior.) > > You need to do the following in the loader to get things to work, assuming > that the drive you want to boot off of is "da1": > > set root_disk_unit=1 > > Then in your fstab, make sure that your root filesystem, etc., reference > da1, not da0. > > Ken > -- > Kenneth Merry > ken@plutotech.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue May 4 22:34:39 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EB0C15ABD for ; Tue, 4 May 1999 22:34:17 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id XAA36038; Tue, 4 May 1999 23:34:14 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199905050534.XAA36038@panzer.plutotech.com> Subject: Re: device assignment In-Reply-To: from spork at "May 5, 1999 1:30:32 am" To: spork@super-g.com (spork) Date: Tue, 4 May 1999 23:34:14 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org spork wrote... > Sorry for the late reply... I was trying to see if the 7890 problem > varied if I booted off the card rather than the builtin chipset. > > No difference... still hangs. I wouldn't expect any change in behavior, since they're both 7890's. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed May 5 18:21:34 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rmx09.globecomm.net (rmx09.iname.net [165.251.8.95]) by hub.freebsd.org (Postfix) with ESMTP id 5592214F3F for ; Wed, 5 May 1999 18:21:28 -0700 (PDT) (envelope-from lordportico@iname.com) Received: from weba2.iname.net by rmx09.globecomm.net (8.9.1/8.8.0) with ESMTP id VAA11677 ; Wed, 5 May 1999 21:21:27 -0400 (EDT) From: lordportico@iname.com Received: (from root@localhost) by weba2.iname.net (8.9.1a/8.9.2.Alpha2) id VAA25182; Wed, 5 May 1999 21:21:27 -0400 (EDT) MIME-Version: 1.0 Message-Id: <9905052121271G.23779@weba2.iname.net> Date: Wed, 5 May 1999 21:21:27 -0400 (EDT) Content-Type: Text/Plain Content-Transfer-Encoding: 7bit To: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (also posted to comp.unix.bsd.freebsd.misc newsgroup and the freebsd-stable mailing list) hi all... I keep getting these error messages: (not together, but the "have seen data phase' error always is after either a data-in or data-out error) blacktabby /kernel: (da0:ahc0:0:8:0): data overrun detected in Data-Out phase. Tag == 0x3a blacktabby /kernel: (da0:ahc0:0:8:0) have seen Data Phase, Length=1024. NumSgs=1 blacktabby /kernel: (da0:ahc0:0:8:0): data overrun detected in Data-In phase. Tag == 0x7. this results in serious filesystem corruption, because it doesn't finish writing whatever file it is currently working on (as far as i can tell) scsi id 8 is my primary hd (the ibm 4gig listed below) my hardware: FIC PA-2013mb (bios 1.33), p200mmx cpu, 64mb PC100 SDRAM, Adaptec 2940uw (bios 1.34.3), IBM 4gig uw-scsi hd, Old Micropolis 1.6gig scsi hd, NEC Multispin 8x cdrom drive. I wiped FreeBSD for a bit, and installed win98 on the 4gig hd, and it seemed to work fine, so i think freebsd is the problem. I'm running freebsd 3.1-stable, last make world about 2pm pacific time on 05-04-1999. dmesg output: (without the data-in error) Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-STABLE #0: Tue May 4 17:49:34 PDT 1999 root@blacktabby.dyndns.org:/usr/src/sys/compile/TERU Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P55C (200.46-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping=3 Features=0x8001bf real memory = 67043328 (65472K bytes) avail memory = 62087168 (60632K bytes) Preloaded elf kernel "kernel" at 0xc02eb000. Probing for devices on PCI bus 0: chip0: rev 0x04 on pci0.0.0 chip1: rev 0x00 on pci0.1.0 chip2: rev 0x47 on pci0.7.0 ide_pci0: rev 0x06 on pci0.7.1 chip3: rev 0x10 on pci0.7.3 vga0: rev 0x01 int a irq 10 on pci0.8.0 ahc0: rev 0x01 int a irq 11 on pci0.9.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs fxp0: rev 0x08 int a irq 5 on pci0.10.0 fxp0: Ethernet address 00:90:27:44:ba:67 Probing for devices on PCI bus 1: Probing for PnP devices: CSN 1 Vendor ID: CTL009e [0x9e008c0e] Serial 0x0924c1de Comp ID: PNPb02f [0x2fb0d041] Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <8 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model GlidePoint, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A ppc0 at 0x378 irq 7 on isa ppc0: Winbond chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 plip0: on ppbus 0 lpt0: on ppbus 0 lpt0: Interrupt-driven port fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface apm0 on isa apm: found APM BIOS version 1.2 sb_reset_dsp failed sb0 not found at 0x220 sb_reset_dsp failed sbxvi0 not found sbmidi0 not found at 0x330 opl0 not found at 0x388 awe0 at 0x620 on isa AWE32: not detected Intel Pentium detected, installing workaround for F00F bug Waiting 10 seconds for SCSI devices to settle changing root device to da0s1a da1 at ahc0 bus 0 target 3 lun 0 da1: Fixed Direct Access SCSI-CCS device da1: 3.300MB/s transfers da1: 1635MB (3349512 512 byte sectors: 255H 63S/T 208C) cd0 at ahc0 bus 0 target 4 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 da0 at ahc0 bus 0 target 8 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) cd9660: RockRidge Extension (da0:ahc0:0:8:0): data overrun detected in Data-Out phase. Tag == 0x3. (da0:ahc0:0:8:0): Have seen Data Phase. Length = 1024. NumSGs = 1. any help would be greatly appreciated... thanks Ace --------------------------------------------------- Get free personalized email at http://www.iname.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed May 5 18:25:34 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from rmx09.globecomm.net (rmx09.iname.net [165.251.8.95]) by hub.freebsd.org (Postfix) with ESMTP id 6F6C414F0A for ; Wed, 5 May 1999 18:25:32 -0700 (PDT) (envelope-from lordportico@iname.com) Received: from weba7.iname.net by rmx09.globecomm.net (8.9.1/8.8.0) with ESMTP id VAA12508 ; Wed, 5 May 1999 21:25:32 -0400 (EDT) From: lordportico@iname.com Received: (from root@localhost) by weba7.iname.net (8.9.1a/8.9.2.Alpha2) id VAA15525; Wed, 5 May 1999 21:25:31 -0400 (EDT) MIME-Version: 1.0 Message-Id: <990505212531F4.29556@weba7.iname.net> Date: Wed, 5 May 1999 21:25:31 -0400 (EDT) Content-Type: Text/Plain Content-Transfer-Encoding: 7bit To: freebsd-scsi@freebsd.org Subject: 3.1-stable/filesystem corruption Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sorry iname removed the subject from the mail i just sent... (regarding the "data Overrun detected in data-out phase" error messages, etc.) thanks Ace --------------------------------------------------- Get free personalized email at http://www.iname.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 6 8: 0:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 8488814CBF for ; Thu, 6 May 1999 08:00:16 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 11068 invoked by uid 1001); 6 May 1999 15:00:14 +0000 (GMT) To: freebsd-scsi@freebsd.org Subject: How easily can Seagate ST15150N have their firmware upgraded? From: sthaug@nethelp.no X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 06 May 1999 17:00:13 +0200 Message-ID: <11066.926002813@verdi.nethelp.no> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warning: This question is unrelated to FreeBSD. We have a number of disks which identify themselves as DEC RZ29B, various firmware levels (0007, 0009, 0014, 0016). It seems that these disks are really Seagate ST15150N (Barracuda 4 GB, 1.6"). We would like to upgrade the firmware on these disks to "normal" Seagate firmware - this is because we want to use the disks in a NetApp F330 box which has specific needs with respect to firmware revisions. My question is: How can I do this upgrade myself? I've seen plenty of references on this list to upgrading firmware on Quantum disks, but can't remember seeing anything on upgrading Seagate firmware. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 6 11: 9:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 1773014DDC for ; Thu, 6 May 1999 11:09:20 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id TAA00641; Thu, 6 May 1999 19:45:42 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.6.12) id TAA00958; Thu, 6 May 1999 19:38:34 GMT From: Wilko Bulte Message-Id: <199905061938.TAA00958@yedi.iaf.nl> Subject: Re: How easily can Seagate ST15150N have their firmware upgraded? In-Reply-To: <11066.926002813@verdi.nethelp.no> from "sthaug@nethelp.no" at "May 6, 1999 5: 0:13 pm" To: sthaug@nethelp.no Date: Thu, 6 May 1999 19:38:34 +0000 (GMT) Cc: freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As sthaug@nethelp.no wrote ... > We have a number of disks which identify themselves as DEC RZ29B, various > firmware levels (0007, 0009, 0014, 0016). It seems that these disks are > really Seagate ST15150N (Barracuda 4 GB, 1.6"). We would like to upgrade Yes, they are ST15150N alright. RZ29B-VW also exists and is the wide scsi variant. There is one sitting next to my keyboard as I type this (a RZ29B narrow one; was replaced by an 18Gb yesterday) > the firmware on these disks to "normal" Seagate firmware - this is because > we want to use the disks in a NetApp F330 box which has specific needs > with respect to firmware revisions. Hmm. Rev 14 and 16 are OK for RZ29B. 07 had some issues when used behind Storageworks array controller. 09 I've never seen. Is the NetApp really that picky? rev 16 is the latest and greatest so... > My question is: How can I do this upgrade myself? I've seen plenty of > references on this list to upgrading firmware on Quantum disks, but can't > remember seeing anything on upgrading Seagate firmware. RZ29B firmware is flashable allright. IRRC I've done it with some Windoze tool called SCSI Toolset. I have never tried going from DEC f/w to stock Seagate f/w though. See no reason why that should not work. I could ask our disk specialist if you want me to. Groeten / Cheers, Wilko (in paid life in Storageworks engineering) | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 6 11:14: 2 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from lfes.languageforce.com (mail.languageforce.com [206.111.39.135]) by hub.freebsd.org (Postfix) with ESMTP id 6C8A715A8B for ; Thu, 6 May 1999 11:13:57 -0700 (PDT) (envelope-from Response@languageforce.com) Received: from dennis (206.111.39.132 [206.111.39.132]) by lfes.languageforce.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id JM7JHDKV; Thu, 6 May 1999 11:18:07 -0700 From: Response@languageforce.com To: Date: Thu, 06 May 1999 11:16:16 -0800 Subject: Breakthrough in Portuguese Translation Software Reply-To: Response@languageforce.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Priority: 3 Message-Id: <19990506181358.6C8A715A8B@hub.freebsd.org> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Portuguese UTStarGate What the World Has been Waiting For ! Communicate in Portuguese, on Web Sites, E-Mail, and documents as easily as English! Full Bi-Directional Translation English to Portuguese is as easy and complete as Portuguese to English. Complete Grammar support Even complex sentences are translated properly, insuring you the best in global communication! Transparent Web Page Translation Web pages transform from Portuguese to English before your eyes, with all formatting and graphics preserved! Multi-Lingual Voice Chat The included IBM ViaVoice Dictation System allows you to dictate in English, directly into a Portuguese Chat Room, then they see the Portuguese text !! When they type in Portuguese, you hear the response in English! Document & E-mail Translation Simply type English into your E-mail, Word Processing, Spreadsheet, or any other document that needs to be translated. With a push of a button, you will have the Portuguese! This is truly the world's most advanced package! Special Introductory CD-ROM Offer ! ONLY $189 ! CALL NOW ! 888-837-8887 TOLL FREE ! FREE BONUS PACK ! (While they last) * FREE Voice Dictation Headset (a $39 Value) * FREE IBM ViaVoice Module * FREE E-Mail for Life * FREE Web Page Hosting * FREE Global Instant Messaging * FREE UTStarGate World Net TV * FREE UTStarGate Jukebox W/ MP3 * FREE UTStargate World Radio Player * Full Internet Explorer 5 Functionality * Interchangable 'Skins' to customize your browser * Powered by Universal Translator Level II Special Introductory CD-ROM Offer ! ONLY $189 ! CALL NOW ! 888-837-8887 TOLL FREE ! ---------------------------------------------------------------------- Message Sent Using Aureate Group Mail Free Edition http://www.group-mail.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 6 13: 1: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 96AC415A07 for ; Thu, 6 May 1999 13:00:38 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id NAA05126; Thu, 6 May 1999 13:50:46 -0600 (MDT) Date: Thu, 6 May 1999 13:50:46 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199905061950.NAA05126@narnia.plutotech.com> To: lordportico@iname.com Cc: scsi@FreeBSD.org Subject: Re: none X-Newsgroups: pluto.freebsd.scsi In-Reply-To: <9905052121271G.23779@weba2.iname.net> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <9905052121271G.23779@weba2.iname.net> you wrote: > > I keep getting these error messages: > (not together, but the "have seen data phase' error always is after either a data-in or data-out error) > > blacktabby /kernel: (da0:ahc0:0:8:0): data overrun detected in Data-Out phase. Tag == 0x3a > > blacktabby /kernel: (da0:ahc0:0:8:0) have seen Data Phase, Length=1024. NumSgs=1 > > blacktabby /kernel: (da0:ahc0:0:8:0): data overrun detected in Data-In phase. Tag == 0x7. My guess would be that your cabling is inadequate. Check your termination, shorten your cables, and if that fails, lower the syncrate to your IBM drive. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 6 13:21: 6 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B45D1517B; Thu, 6 May 1999 13:20:55 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id OAA46687; Thu, 6 May 1999 14:20:54 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199905062020.OAA46687@panzer.plutotech.com> Subject: HEADS UP: CAM changes To: current@FreeBSD.ORG Date: Thu, 6 May 1999 14:20:54 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have just committed a number of CAM changes that will require recompilation of any userland programs you have that access the CAM passthrough driver. So things like cdrecord, xmcd, etc., should be recompiled. The best way to update your system is via make world. NOTE: I would really like to hear from NCR owners about these changes. Justin and I made a small negotiation change in the NCR driver that should mean that people with 875's and the like should get Ultra speeds without putting options in their kernel. To summarize, these changes: - add new 'tags' and 'negotiate' commands to camcontrol. The tags command allows setting and viewing the number of tagged openings, and the negotiate command allows viewing and setting negotiation parameters for devices. - add code to make the transport layer's sink devices invisible to camcontrol devlist by default. (they reappear with -v) - The CD and DA drivers now attach regardless of what errors they get back from a read capacity. (with one exception -- "logical unit not supported") - Fixed a negotiation bug in the NCR driver. Note that the ahc, adv, and ncr drivers are the only drivers that fully support the 'camcontrol negotiate' command at this point. Other drivers, like the adw driver, may let you turn sync negotiation on and off but won't let you set the sync rate. In the case of the adw boards, I think it's a hardware limitation. Other drivers, like the bt driver, don't support the XPT_SET_TRAN_SETTINGS CCB at all, so you can't set any negotiation parameters. The 'tags' command should work on any device, because tagged queueing is handled by the transport layer, and not individual peripheral drivers. I plan on checking all of this code into -stable as well, hopefully later on today. Many thanks to Justin for helping with these changes and reviewing everything. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 6 15:40:49 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 7E54C14CCB for ; Thu, 6 May 1999 15:40:36 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id AAA17840 for scsi@FreeBSD.ORG; Fri, 7 May 1999 00:40:34 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id BE7438849; Fri, 7 May 1999 00:37:04 +0200 (CEST) (envelope-from roberto) Date: Fri, 7 May 1999 00:37:04 +0200 From: Ollivier Robert To: scsi@FreeBSD.ORG Subject: Re: HEADS UP: CAM changes Message-ID: <19990507003704.A50446@keltia.freenix.fr> Mail-Followup-To: scsi@FreeBSD.ORG References: <199905062020.OAA46687@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <199905062020.OAA46687@panzer.plutotech.com>; from Kenneth D. Merry on Thu, May 06, 1999 at 02:20:54PM -0600 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5244 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Kenneth D. Merry: > NOTE: I would really like to hear from NCR owners about these changes. > Justin and I made a small negotiation change in the NCR driver that should > mean that people with 875's and the like should get Ultra speeds without > putting options in their kernel. For the record, I get Ultra speed w/o any problems on my 875 even without these changes. YMMV of course. FreeBSD 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 roberto@keltia.freenix.fr:/src/src/sys/compile/KELTIA_T Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 200465492 Hz CPU: AMD-K6tm w/ multimedia extensions (200.47-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x562 Stepping=2 Features=0x8001bf real memory = 134217728 (131072K bytes) avail memory = 127381504 (124396K bytes) Preloaded elf kernel "kernel" at 0xc0322000. Preloaded elf module "nfs.ko" at 0xc032209c. Preloaded elf module "vesa.ko" at 0xc0322138. Preloaded elf module "linux.ko" at 0xc03221d4. Preloaded elf module "green_saver.ko" at 0xc0322274. Preloaded elf module "procfs.ko" at 0xc0322318. Preloaded elf module "if_ppp.ko" at 0xc03223b8. Preloaded elf module "if_tun.ko" at 0xc0322458. VESA: v2.0, 2048k memory, flags:0x1, mode table:0xc02ec222 (1000022) VESA: Matrox Graphics Inc. Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x01 on pci0.7.0 vga0: rev 0x01 int a irq 15 on pci0.10.0 ncr0: rev 0x03 int a irq 9 on pci0.11.0 ncr1: rev 0x12 int a irq 11 on pci0.12.0 [...] da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da2 at ncr0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da2: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 6 15:46: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 58BAD14CCB for ; Thu, 6 May 1999 15:45:53 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id QAA47672; Thu, 6 May 1999 16:45:41 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199905062245.QAA47672@panzer.plutotech.com> Subject: Re: HEADS UP: CAM changes In-Reply-To: <19990507003704.A50446@keltia.freenix.fr> from Ollivier Robert at "May 7, 1999 0:37: 4 am" To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Thu, 6 May 1999 16:45:41 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ollivier Robert wrote... > According to Kenneth D. Merry: > > NOTE: I would really like to hear from NCR owners about these changes. > > Justin and I made a small negotiation change in the NCR driver that should > > mean that people with 875's and the like should get Ultra speeds without > > putting options in their kernel. > > For the record, I get Ultra speed w/o any problems on my 875 even without > these changes. YMMV of course. Is the BIOS enabled on your 875 board? Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 6 20:58:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from project.m2.ntu.edu.tw (project.m2.ntu.edu.tw [140.112.213.32]) by hub.freebsd.org (Postfix) with ESMTP id DB47B15061 for ; Thu, 6 May 1999 20:57:00 -0700 (PDT) (envelope-from tyl@project.m2.ntu.edu.tw) Received: from localhost (tyl@localhost) by project.m2.ntu.edu.tw (8.9.1/8.9.1) with ESMTP id LAA12607 for ; Fri, 7 May 1999 11:55:37 +0800 (CST) (envelope-from tyl@project.m2.ntu.edu.tw) Date: Fri, 7 May 1999 11:55:37 +0800 (CST) From: tyl To: freebsd-scsi@FreeBSD.org Subject: AHA 2940 U/UW waiting fail? 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 like to install FreeBSD 4.0-19990503 FreeBSD detect my SCSI card normally But when it waiting SCSI devices for 15 seconds It fails, nothing responding, and the system is halt I have installed 4.0-19990408, and work perfectly and I reuse the booting disk (kern.flp & mfsroot.flp) It still works, and detect all the devices. And the Windows 95 on the computer still works perfect ... What happens? Is there any changes for new version FreeBSD? Thanks for your help first !! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 6 21:35:15 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from munin.odin-corporation.com (fredriks-2.pr.mcs.net [205.164.50.242]) by hub.freebsd.org (Postfix) with ESMTP id 03082152D8 for ; Thu, 6 May 1999 21:35:06 -0700 (PDT) (envelope-from lars@odin-corporation.com) Received: from odin-corporation.com (localhost [127.0.0.1]) by munin.odin-corporation.com (8.9.3/8.9.1) with ESMTP id XAA41518; Thu, 6 May 1999 23:34:52 -0500 (CDT) (envelope-from lars@odin-corporation.com) Message-ID: <37326D6B.FCFBA135@odin-corporation.com> Date: Thu, 06 May 1999 23:34:52 -0500 From: Lars Fredriksen Organization: Odin Corporation X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: no, en MIME-Version: 1.0 To: tyl Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: AHA 2940 U/UW waiting fail? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org tyl wrote: > I like to install FreeBSD 4.0-19990503 > FreeBSD detect my SCSI card normally > But when it waiting SCSI devices for 15 seconds > It fails, nothing responding, and the system is halt > > I have installed 4.0-19990408, and work perfectly > and I reuse the booting disk (kern.flp & mfsroot.flp) > It still works, and detect all the devices. > > And the Windows 95 on the computer still works perfect ... > > What happens? Is there any changes for new version FreeBSD? > Thanks for your help first !! > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message Hi, Are you running SMP? If so, the UP kernel works just fine (at least for me). I don't know quite what is going on with the SMP configuration though. It appears that the interrups aren't getting setup up right; at least the driver behaves as though it never got a response back from the board. Lars To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu May 6 23: 0: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 021A214CE0 for ; Thu, 6 May 1999 22:59:37 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id HAA05261 for scsi@FreeBSD.ORG; Fri, 7 May 1999 07:59:35 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 426E98849; Fri, 7 May 1999 07:29:52 +0200 (CEST) (envelope-from roberto) Date: Fri, 7 May 1999 07:29:52 +0200 From: Ollivier Robert To: scsi@FreeBSD.ORG Subject: Re: HEADS UP: CAM changes Message-ID: <19990507072952.A52714@keltia.freenix.fr> Mail-Followup-To: scsi@FreeBSD.ORG References: <19990507003704.A50446@keltia.freenix.fr> <199905062245.QAA47672@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <199905062245.QAA47672@panzer.plutotech.com>; from Kenneth D. Merry on Thu, May 06, 1999 at 04:45:41PM -0600 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5244 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Kenneth D. Merry: > Is the BIOS enabled on your 875 board? Yes, I'm booting on it. I don't use the NCR BIOS on the motherboard (ASUS T2P4) because it is an older one. I have 4.08 on my 875. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #2: Fri Apr 16 22:37:03 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 1:41:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id A64C615D5D for ; Fri, 7 May 1999 01:41:49 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 26199 invoked by uid 1001); 7 May 1999 08:41:48 +0000 (GMT) To: roberto@keltia.freenix.fr Cc: scsi@FreeBSD.ORG Subject: Re: HEADS UP: CAM changes From: sthaug@nethelp.no In-Reply-To: Your message of "Fri, 7 May 1999 00:37:04 +0200" References: <19990507003704.A50446@keltia.freenix.fr> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 07 May 1999 10:41:47 +0200 Message-ID: <26197.926066507@verdi.nethelp.no> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > NOTE: I would really like to hear from NCR owners about these changes. > > Justin and I made a small negotiation change in the NCR driver that should > > mean that people with 875's and the like should get Ultra speeds without > > putting options in their kernel. > > For the record, I get Ultra speed w/o any problems on my 875 even without > these changes. YMMV of course. Same here, running a kernel somewhere between 3.0 and 3.1, and (now) 3.1-STABLE. Never had a problem with Ultra speeds for the 875. Steinar Haug, Nethelp consulting, sthaug@nethelp.no ---------------------------------------------------------------------- Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-STABLE #0: Sat Apr 3 10:11:35 CEST 1999 sthaug@verdi.nethelp.no:/d/freebsd/stable/src/sys/compile/VERDI_ELF Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 166193834 Hz CPU: Pentium/P55C (166.19-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping=3 Features=0x8001bf real memory = 134217728 (131072K bytes) avail memory = 127574016 (124584K bytes) Preloaded elf kernel "kernel" at 0xf02d8000. Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x01 on pci0.7.0 ide_pci0: rev 0x00 on pci0.7.1 fxp0: rev 0x02 int a irq 12 on pci0.9.0 fxp0: Ethernet address 00:a0:c9:44:a8:90 ncr0: rev 0x03 int a irq 10 on pci0.10.0 vga0: rev 0x01 int a irq 11 on pci0.11.0 Probing for PnP devices: CSN 1 Vendor ID: CTL009e [0x9e008c0e] Serial 0x026f274d Comp ID: PNPb02f [0x2fb0d041] pcm1 (SB16pnp sn 0x026f274d) at 0x220-0x22f irq 5 drq 1 flags 0x15 on isa Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 not found sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A pcm0 not probed due to drq conflict with pcm1 at 1 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 wd0: 16124MB (33022080 sectors), 32760 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): , removable, intr, dma, iordis acd0: drive speed 4134KB/sec, 256KB cache acd0: supported read types: CD-R, CD-RW, CD-DA, packet track acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm audio disc loaded, unlocked ppc0 at 0x378 irq 7 on isa ppc0: W83877F chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppb0: IEEE1284 device found /NIBBLE/PS2/ECP Probing for PnP devices on ppbus0: ppbus0: PRINTER PCL 6 Emulation, PostScript Level 2 Emulation, NPAP, PJL nlpt0: on ppbus 0 nlpt0: Interrupt-driven port ppi0: on ppbus 0 plip0: on ppbus 0 vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface Intel Pentium detected, installing workaround for F00F bug Waiting 3 seconds for SCSI devices to settle sa0 at ncr0 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 8) changing root device to da0s1a da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 3:49:35 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from project.m2.ntu.edu.tw (project.m2.ntu.edu.tw [140.112.213.32]) by hub.freebsd.org (Postfix) with ESMTP id 4DDEF14D92 for ; Fri, 7 May 1999 03:49:28 -0700 (PDT) (envelope-from tyl@project.m2.ntu.edu.tw) Received: from localhost (tyl@localhost) by project.m2.ntu.edu.tw (8.9.1/8.9.1) with ESMTP id SAA12912; Fri, 7 May 1999 18:48:44 +0800 (CST) (envelope-from tyl@project.m2.ntu.edu.tw) Date: Fri, 7 May 1999 18:48:43 +0800 (CST) From: tyl To: Lars Fredriksen Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: AHA 2940 U/UW waiting fail? In-Reply-To: <37326D6B.FCFBA135@odin-corporation.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 Thu, 6 May 1999, Lars Fredriksen wrote: > Are you running SMP? If so, the UP kernel works just fine (at least for > me). I don't know quite what is going on with the SMP configuration > though. It appears that the interrups aren't getting setup up right; at > least the driver behaves as though it never got a response back from the > board. Thanks for your help first !! My computer is not running SMP, It is just a plain P-II 233 :) But almost one year ago, I really meet the similar problem like you say. At that time, I do something with APIC configuration... and then the machine run very well. I have disconnected all the HDs and CDROMs, but FreeBSD still halt at the "waiting 15 seconds". It seems the problem is on the card? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 8:15:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from munin.odin-corporation.com (fredriks-2.pr.mcs.net [205.164.50.242]) by hub.freebsd.org (Postfix) with ESMTP id A2E76150D9 for ; Fri, 7 May 1999 08:15:11 -0700 (PDT) (envelope-from lars@odin-corporation.com) Received: from odin-corporation.com (localhost [127.0.0.1]) by munin.odin-corporation.com (8.9.3/8.9.1) with ESMTP id KAA89743; Fri, 7 May 1999 10:15:06 -0500 (CDT) (envelope-from lars@odin-corporation.com) Message-ID: <3733037A.C2C64778@odin-corporation.com> Date: Fri, 07 May 1999 10:15:06 -0500 From: Lars Fredriksen Organization: Odin Corporation X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: no, en MIME-Version: 1.0 To: tyl Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: AHA 2940 U/UW waiting fail? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org tyl wrote: > On Thu, 6 May 1999, Lars Fredriksen wrote: > > > Are you running SMP? If so, the UP kernel works just fine (at least for > > me). I don't know quite what is going on with the SMP configuration > > though. It appears that the interrups aren't getting setup up right; at > > least the driver behaves as though it never got a response back from the > > board. > > Thanks for your help first !! My computer is not running SMP, It is just a > plain P-II 233 :) But almost one year ago, I really meet the similar > problem like you say. At that time, I do something with APIC > configuration... and then the machine run very well. > > I have disconnected all the HDs and CDROMs, but FreeBSD still halt at the > "waiting 15 seconds". It seems the problem is on the card? No, I don't think it is a problem with the card per se. However, it might be an issue with how we configure interrupts. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message Hm, it is interssting that you see the problem on UP when I don't. What does your mptable output look like? Lars To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 8:25:27 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (Postfix) with ESMTP id 9A83314CE0 for ; Fri, 7 May 1999 08:25:18 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id KAA00427 for freebsd-scsi@freebsd.org; Fri, 7 May 1999 10:25:18 -0500 (CDT) Message-ID: <19990507102517.A416@Denninger.Net> Date: Fri, 7 May 1999 10:25:17 -0500 From: Karl Denninger To: freebsd-scsi@freebsd.org Subject: Question - Onstream SCSI Streamer Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers will be LARTed and the remains fed to my cat Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has anyone looked at this tape drive yet? It shows up on a probe as a sequential access SCSI device, but fails to work (at all) - complaints about bad CCBs start as soon as you attempt to actually use it. Running -CURRENT. Boot extract is: sa0 at ahc1 bus 0 target 4 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 7) And the bad CCB messages are: (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 (sa0:ahc1:0:4:0): Invalid field in CDB (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 (sa0:ahc1:0:4:0): Invalid field in CDB (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 (sa0:ahc1:0:4:0): Invalid field in CDB (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 (sa0:ahc1:0:4:0): Invalid field in CDB (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 (sa0:ahc1:0:4:0): Invalid field in CDB (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 (sa0:ahc1:0:4:0): Invalid field in CDB (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 (sa0:ahc1:0:4:0): Invalid field in CDB (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 (sa0:ahc1:0:4:0): Invalid field in CDB -- -- Karl Denninger (karl@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 8:28:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id AC3D4150BB for ; Fri, 7 May 1999 08:28:05 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id IAA28868; Fri, 7 May 1999 08:27:47 -0700 Date: Fri, 7 May 1999 08:27:46 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Karl Denninger Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer In-Reply-To: <19990507102517.A416@Denninger.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It cannot work yet with FreeBSD. The problems are many because in order to support it a special device model has to be constructed (immediate rewinds, software filemarks). This is not schedule to occur for a while yet. On Fri, 7 May 1999, Karl Denninger wrote: > Has anyone looked at this tape drive yet? > > It shows up on a probe as a sequential access SCSI device, but fails to > work (at all) - complaints about bad CCBs start as soon as you attempt > to actually use it. > > Running -CURRENT. > > Boot extract is: > > sa0 at ahc1 bus 0 target 4 lun 0 > sa0: Removable Sequential Access SCSI-2 device > sa0: 5.000MB/s transfers (5.000MHz, offset 7) > > And the bad CCB messages are: > > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > (sa0:ahc1:0:4:0): Invalid field in CDB > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > (sa0:ahc1:0:4:0): Invalid field in CDB > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > (sa0:ahc1:0:4:0): Invalid field in CDB > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > (sa0:ahc1:0:4:0): Invalid field in CDB > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > (sa0:ahc1:0:4:0): Invalid field in CDB > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > (sa0:ahc1:0:4:0): Invalid field in CDB > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > (sa0:ahc1:0:4:0): Invalid field in CDB > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > (sa0:ahc1:0:4:0): Invalid field in CDB > > -- > -- > Karl Denninger (karl@denninger.net) Web: fathers.denninger.net > I ain't even *authorized* to speak for anyone other than myself, so give > up now on trying to associate my words with any particular organization. > > > > 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 Fri May 7 8:32:19 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (Postfix) with ESMTP id A292515109 for ; Fri, 7 May 1999 08:32:14 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id KAA00461; Fri, 7 May 1999 10:31:51 -0500 (CDT) Message-ID: <19990507103151.A431@Denninger.Net> Date: Fri, 7 May 1999 10:31:51 -0500 From: Karl Denninger To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer References: <19990507102517.A416@Denninger.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Matthew Jacob on Fri, May 07, 1999 at 08:27:46AM -0700 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers will be LARTed and the remains fed to my cat Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmmm.... immediate rewinds? You mean implied rewinds on close, and no way to override them? That would limit you to one dump per tape, no? I'm willing to take a look at this (since I have one) provided I can wrangle enough information to actually do so. -- -- Karl Denninger (karl@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. On Fri, May 07, 1999 at 08:27:46AM -0700, Matthew Jacob wrote: > > > It cannot work yet with FreeBSD. The problems are many because in order to > support it a special device model has to be constructed (immediate > rewinds, software filemarks). This is not schedule to occur for a while > yet. > > > On Fri, 7 May 1999, Karl Denninger wrote: > > > Has anyone looked at this tape drive yet? > > > > It shows up on a probe as a sequential access SCSI device, but fails to > > work (at all) - complaints about bad CCBs start as soon as you attempt > > to actually use it. > > > > Running -CURRENT. > > > > Boot extract is: > > > > sa0 at ahc1 bus 0 target 4 lun 0 > > sa0: Removable Sequential Access SCSI-2 device > > sa0: 5.000MB/s transfers (5.000MHz, offset 7) > > > > And the bad CCB messages are: > > > > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > > (sa0:ahc1:0:4:0): Invalid field in CDB > > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > > (sa0:ahc1:0:4:0): Invalid field in CDB > > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > > (sa0:ahc1:0:4:0): Invalid field in CDB > > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > > (sa0:ahc1:0:4:0): Invalid field in CDB > > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > > (sa0:ahc1:0:4:0): Invalid field in CDB > > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > > (sa0:ahc1:0:4:0): Invalid field in CDB > > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > > (sa0:ahc1:0:4:0): Invalid field in CDB > > (sa0:ahc1:0:4:0): REWIND. CDB: 1 0 0 0 0 0 > > (sa0:ahc1:0:4:0): ILLEGAL REQUEST asc:24,0 > > (sa0:ahc1:0:4:0): Invalid field in CDB > > > > -- > > -- > > Karl Denninger (karl@denninger.net) Web: fathers.denninger.net > > I ain't even *authorized* to speak for anyone other than myself, so give > > up now on trying to associate my words with any particular organization. > > > > > > > > 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 Fri May 7 8:33:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E28C5150BB for ; Fri, 7 May 1999 08:33:52 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id IAA28917; Fri, 7 May 1999 08:33:42 -0700 Date: Fri, 7 May 1999 08:33:41 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Karl Denninger Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer In-Reply-To: <19990507103151.A431@Denninger.Net> 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 Fri, 7 May 1999, Karl Denninger wrote: > Hmmm.... immediate rewinds? You mean implied rewinds on close, and no way > to override them? That would limit you to one dump per tape, no? No, the 'immediate bit' in a rewind. > > I'm willing to take a look at this (since I have one) provided I can wrangle > enough information to actually do so. > I'm waiting for that information myself. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 8:43:31 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (Postfix) with ESMTP id 3C47C152B2 for ; Fri, 7 May 1999 08:43:27 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id KAA00488; Fri, 7 May 1999 10:38:14 -0500 (CDT) Message-ID: <19990507103814.B431@Denninger.Net> Date: Fri, 7 May 1999 10:38:14 -0500 From: Karl Denninger To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer References: <19990507103151.A431@Denninger.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Matthew Jacob on Fri, May 07, 1999 at 08:33:41AM -0700 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers will be LARTed and the remains fed to my cat Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, May 07, 1999 at 08:33:41AM -0700, Matthew Jacob wrote: > On Fri, 7 May 1999, Karl Denninger wrote: > > > Hmmm.... immediate rewinds? You mean implied rewinds on close, and no way > > to override them? That would limit you to one dump per tape, no? > > No, the 'immediate bit' in a rewind. Ah. Ok. That would, I think, be relatively quick to take care of, no? Software filemarks (the drive doesn't know how to write them?!) could be a bigger problem. > > I'm willing to take a look at this (since I have one) provided I can wrangle > > enough information to actually do so. > > > > I'm waiting for that information myself. Hmmm... that sounds like an indefinite timeframe. Does anyone have hacks to get even partial functionality? I'm flat-out of reasonable options with the DATs that I've been using (you know, the old "data grows" problem) and I've got the fun problem of either finding a solution to this via the ADR drives or returning it and going with DLT (about 4x the price). -- -- Karl Denninger (karl@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 9: 0:22 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 848B714A09 for ; Fri, 7 May 1999 09:00:17 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA00542; Fri, 7 May 1999 09:00:06 -0700 Date: Fri, 7 May 1999 09:00:06 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Karl Denninger Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer In-Reply-To: <19990507103814.B431@Denninger.Net> 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 Fri, May 07, 1999 at 08:33:41AM -0700, Matthew Jacob wrote: > > On Fri, 7 May 1999, Karl Denninger wrote: > > > > > Hmmm.... immediate rewinds? You mean implied rewinds on close, and no way > > > to override them? That would limit you to one dump per tape, no? > > > > No, the 'immediate bit' in a rewind. > > Ah. Ok. > > That would, I think, be relatively quick to take care of, no? Yes. > > Software filemarks (the drive doesn't know how to write them?!) could be a > bigger problem. Yes. Onstream has said that they want to specify more carefully what the soft filemarks will look like. > > > > I'm willing to take a look at this (since I have one) provided I can wrangle > > > enough information to actually do so. > > > > > > > I'm waiting for that information myself. > > Hmmm... that sounds like an indefinite timeframe. No- they've said they'd get that information and unit to me RSN. I believe they're doing the manual this month. I expect to get a unit and a manual by the end of June at the latest. It'll take a couple weeks of work I suspect- there's more than just the rewind, etc..But no promises. > > Does anyone have hacks to get even partial functionality? I'm flat-out of > reasonable options with the DATs that I've been using (you know, the old > "data grows" problem) and I've got the fun problem of either finding a > solution to this via the ADR drives or returning it and going with DLT > (about 4x the price). Oddly enough I've found the HP T20 Travan-5 a reasonable price performer- but if you're saying a DDS3 isn't doing it for you, that's not an option. What's the limiting factor? Cost? At 12GB nominal per tape for a DDS-3 you'll need 4-5 to match each Onstream cartridge- so you get a bigger jukebox. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 9: 6: 9 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (Postfix) with ESMTP id 9D85D151C4 for ; Fri, 7 May 1999 09:06:02 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id LAA00673; Fri, 7 May 1999 11:05:58 -0500 (CDT) Message-ID: <19990507110558.A614@Denninger.Net> Date: Fri, 7 May 1999 11:05:58 -0500 From: Karl Denninger To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer References: <19990507103814.B431@Denninger.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Matthew Jacob on Fri, May 07, 1999 at 09:00:06AM -0700 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers will be LARTed and the remains fed to my cat Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, May 07, 1999 at 09:00:06AM -0700, Matthew Jacob wrote: > > On Fri, May 07, 1999 at 08:33:41AM -0700, Matthew Jacob wrote: > > > On Fri, 7 May 1999, Karl Denninger wrote: > > > > > > > Hmmm.... immediate rewinds? You mean implied rewinds on close, and no way > > > > to override them? That would limit you to one dump per tape, no? > > > > > > No, the 'immediate bit' in a rewind. > > > > Ah. Ok. > > > > That would, I think, be relatively quick to take care of, no? > > Yes. Given that I could write either one dump per tape, or with dump (which knows what its reading and writing, therefore doesn't really "need" filemarks, right?) it would work - no? How difficult would it be to fix just that part of things, and would it get the desired result (usability with dump only)? > > Software filemarks (the drive doesn't know how to write them?!) could be a > > bigger problem. > > Yes. Onstream has said that they want to specify more carefully what the > soft filemarks will look like. Grrr... > > > > I'm willing to take a look at this (since I have one) provided I can wrangle > > > > enough information to actually do so. > > > > > > > > > > I'm waiting for that information myself. > > > > Hmmm... that sounds like an indefinite timeframe. > > No- they've said they'd get that information and unit to me RSN. I believe > they're doing the manual this month. I expect to get a unit and a manual > by the end of June at the latest. It'll take a couple weeks of work I > suspect- there's more than just the rewind, etc..But no promises. Well that's quite the pickle for me... > > Does anyone have hacks to get even partial functionality? I'm flat-out of > > reasonable options with the DATs that I've been using (you know, the old > > "data grows" problem) and I've got the fun problem of either finding a > > solution to this via the ADR drives or returning it and going with DLT > > (about 4x the price). > > Oddly enough I've found the HP T20 Travan-5 a reasonable price performer- > but if you're saying a DDS3 isn't doing it for you, that's not an option. > What's the limiting factor? Cost? At 12GB nominal per tape for a DDS-3 > you'll need 4-5 to match each Onstream cartridge- so you get a bigger > jukebox. Running dumps to a juke doesn't work if a single filesystem doesn't fit on a tape. Unfortunately I am in the position of having a lot of already compressed files on big disks and filesystems. The result is that a single filesystem dump doesn't fit on one tape. Therefore, I can't run anything on automatic. This is a serious problem from a standpoint of actually getting the dumps done. 60 days is not a good timeframe for me; I'll live if I have to, and probably will keep the drive in that instance, but even partial functionality would serve since my needs are only for dump(8) to work. -- -- Karl Denninger (karl@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 9:17:32 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 0CA4F150C8 for ; Fri, 7 May 1999 09:17:28 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA00745; Fri, 7 May 1999 09:17:22 -0700 Date: Fri, 7 May 1999 09:17:22 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Karl Denninger Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer In-Reply-To: <19990507110558.A614@Denninger.Net> 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 > > > > Yes. > > Given that I could write either one dump per tape, or with dump (which > knows what its reading and writing, therefore doesn't really "need" > filemarks, right?) it would work - no? > > How difficult would it be to fix just that part of things, and would it get > the desired result (usability with dump only)? Possibly easy if you just cut for this device only. I mean, it's just software. But I certainly wouldn't go this route. > > > > Software filemarks (the drive doesn't know how to write them?!) could be a > > > bigger problem. > > > > Yes. Onstream has said that they want to specify more carefully what the > > soft filemarks will look like. > > Grrr... No, this is a good thing. This means that if they improve (they'd *better*!) their h/w so that filemarks etc. are done in h/w there has to be a compatibility with tapes written with 'soft' marks- so a known format should be decided on. > > > > > > I'm willing to take a look at this (since I have one) provided I can wrangle > > > > > enough information to actually do so. > > > > > > > > > > > > > I'm waiting for that information myself. > > > > > > Hmmm... that sounds like an indefinite timeframe. > > > > No- they've said they'd get that information and unit to me RSN. I believe > > they're doing the manual this month. I expect to get a unit and a manual > > by the end of June at the latest. It'll take a couple weeks of work I > > suspect- there's more than just the rewind, etc..But no promises. > > Well that's quite the pickle for me... Sorry. > > > > Does anyone have hacks to get even partial functionality? I'm flat-out of > > > reasonable options with the DATs that I've been using (you know, the old > > > "data grows" problem) and I've got the fun problem of either finding a > > > solution to this via the ADR drives or returning it and going with DLT > > > (about 4x the price). > > > > Oddly enough I've found the HP T20 Travan-5 a reasonable price performer- > > but if you're saying a DDS3 isn't doing it for you, that's not an option. > > What's the limiting factor? Cost? At 12GB nominal per tape for a DDS-3 > > you'll need 4-5 to match each Onstream cartridge- so you get a bigger > > jukebox. > > Running dumps to a juke doesn't work if a single filesystem doesn't fit > on a tape. Unfortunately I am in the position of having a lot of already > compressed files on big disks and filesystems. > > The result is that a single filesystem dump doesn't fit on one tape. > Therefore, I can't run anything on automatic. This is a serious problem > from a standpoint of actually getting the dumps done. > > 60 days is not a good timeframe for me; I'll live if I have to, and probably > will keep the drive in that instance, but even partial functionality would > serve since my needs are only for dump(8) to work. Why don't you go to multivolume dumps or use a different backup application? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 9:40:53 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 11702152AE for ; Fri, 7 May 1999 09:40:49 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id KAA52644; Fri, 7 May 1999 10:40:37 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199905071640.KAA52644@panzer.plutotech.com> Subject: Re: HEADS UP: CAM changes In-Reply-To: <26197.926066507@verdi.nethelp.no> from "sthaug@nethelp.no" at "May 7, 1999 10:41:47 am" To: sthaug@nethelp.no Date: Fri, 7 May 1999 10:40:37 -0600 (MDT) Cc: roberto@keltia.freenix.fr, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sthaug@nethelp.no wrote... > > > NOTE: I would really like to hear from NCR owners about these changes. > > > Justin and I made a small negotiation change in the NCR driver that should > > > mean that people with 875's and the like should get Ultra speeds without > > > putting options in their kernel. > > > > For the record, I get Ultra speed w/o any problems on my 875 even without > > these changes. YMMV of course. > > Same here, running a kernel somewhere between 3.0 and 3.1, and (now) > 3.1-STABLE. Never had a problem with Ultra speeds for the 875. Good, glad to hear it. I probably should have explained what we changed in the NCR driver. Some of the NCR/Symbios boards have clock doublers or clock quadruplers. The change only affects those boards. Boards with clock doublers or quadruplers are: 875 with a revision of 2 or greater, 875j, 885, 895, and 896. And it only seems to make a difference when the BIOS is enabled on the card. You've got a rev 3 875. I assume the BIOS is enabled for your card? > ncr0: rev 0x03 int a irq 10 on pci0.10.0 Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 9:42:57 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 5888315470 for ; Fri, 7 May 1999 09:42:54 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id KAA52659; Fri, 7 May 1999 10:42:48 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199905071642.KAA52659@panzer.plutotech.com> Subject: Re: HEADS UP: CAM changes In-Reply-To: <19990507072952.A52714@keltia.freenix.fr> from Ollivier Robert at "May 7, 1999 7:29:52 am" To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Fri, 7 May 1999 10:42:48 -0600 (MDT) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ollivier Robert wrote... > According to Kenneth D. Merry: > > Is the BIOS enabled on your 875 board? > > Yes, I'm booting on it. I don't use the NCR BIOS on the motherboard (ASUS > T2P4) because it is an older one. I have 4.08 on my 875. Ahh, well that's why it works with the older code as well. The BIOS was disabled on the Diamond Fireport 40 I tested on, so that's why I ran into the problem. The NCR driver wasn't assuming the board was capable of Ultra speeds when the BIOS wasn't enabled. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 10:17:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id D845514D6D for ; Fri, 7 May 1999 10:17:17 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 34645 invoked by uid 1001); 7 May 1999 17:17:16 +0000 (GMT) To: ken@plutotech.com Cc: scsi@FreeBSD.ORG Subject: Re: HEADS UP: CAM changes From: sthaug@nethelp.no In-Reply-To: Your message of "Fri, 7 May 1999 10:40:37 -0600 (MDT)" References: <199905071640.KAA52644@panzer.plutotech.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 07 May 1999 19:17:16 +0200 Message-ID: <34643.926097436@verdi.nethelp.no> Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Some of the NCR/Symbios boards have clock doublers or clock quadruplers. > The change only affects those boards. Boards with clock doublers or > quadruplers are: 875 with a revision of 2 or greater, 875j, 885, 895, and > 896. > > And it only seems to make a difference when the BIOS is enabled on the > card. You've got a rev 3 875. I assume the BIOS is enabled for your > card? Yup. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 10:37:48 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 21447153CD for ; Fri, 7 May 1999 10:37:26 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id TAA01106; Fri, 7 May 1999 19:32:17 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.6.12) id TAA48310; Fri, 7 May 1999 19:20:43 +0200 (CEST) From: Wilko Bulte Message-Id: <199905071720.TAA48310@yedi.iaf.nl> Subject: Re: HEADS UP: CAM changes In-Reply-To: <26197.926066507@verdi.nethelp.no> from "sthaug@nethelp.no" at "May 7, 1999 10:41:47 am" To: sthaug@nethelp.no Date: Fri, 7 May 1999 19:20:43 +0200 (CEST) Cc: roberto@keltia.freenix.fr, scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As sthaug@nethelp.no wrote ... > > > NOTE: I would really like to hear from NCR owners about these changes. > > > Justin and I made a small negotiation change in the NCR driver that should > > > mean that people with 875's and the like should get Ultra speeds without > > > putting options in their kernel. > > > > For the record, I get Ultra speed w/o any problems on my 875 even without > > these changes. YMMV of course. > > Same here, running a kernel somewhere between 3.0 and 3.1, and (now) > 3.1-STABLE. Never had a problem with Ultra speeds for the 875. In case anybody wants another "same here". BIOS is enabled: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-STABLE #0: Mon May 3 21:09:59 CEST 1999 root@yedi.iaf.nl:/usr/freebsd-3.1-stable/src/sys/compile/YEDI Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 261958822 Hz CPU: AMD-K6tm w/ multimedia extensions (261.96-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x562 Stepping=2 Features=0x8001bf real memory = 100663296 (98304K bytes) avail memory = 94875648 (92652K bytes) Preloaded elf kernel "kernel" at 0xf02c7000. Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x01 on pci0.7.0 xl0: <3Com 3c905-TX Fast Etherlink XL> rev 0x00 int a irq 14 on pci0.9.0 xl0: Ethernet address: 00:60:08:09:b8:f1 xl0: autoneg not complete, no carrier (forcing half-duplex, 10Mbps) vga0: rev 0x00 int a irq 14 on pci0.10.0 ncr0: rev 0x04 int a irq 9 on pci0.11.0 ncr1: rev 0x02 int a irq 11 on pci0.12.0 Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2 at 0x1a0-0x1a7 flags 0x501 on isa sio2: type 16550A (multiport) sio3 at 0x1a8-0x1af flags 0x501 on isa sio3: type 16550A (multiport) sio4 at 0x1b0-0x1b7 flags 0x501 on isa sio4: type 16550A (multiport) sio5 at 0x1b8-0x1bf irq 5 flags 0x501 on isa sio5: type 16550A (multiport master) fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in isic0 at 0xd80 irq 15 flags 0x3 on isa isic0: Teles S0/16.3 isic0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) (Addr=0x960) isic0: HSCX 82525 or 21525 Version 2.1 (AddrA=0x160, AddrB=0x560) vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa npx0 on motherboard npx0: INT 16 interface IP packet filtering initialized, divert enabled, rule-based forwarding disabled, unlimited logging i4b: ISDN call control device attached i4bisppp: 2 ISDN SyncPPP device(s) attached i4bctl: ISDN system control port attached i4btrc: 2 ISDN trace device(s) attached Waiting 3 seconds for SCSI devices to settle changing root device to da0s2a da0 at ncr0 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: 17365MB (35565080 512 byte sectors: 255H 63S/T 2213C) cd0 at ncr0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: cd present [1289220 x 512 byte records] ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates Groeten / Cheers, | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 11:15:11 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 3CB3F14E3C for ; Fri, 7 May 1999 11:15:08 -0700 (PDT) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id LAA03157; Fri, 7 May 1999 11:14:09 -0700 (PDT) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA162110839; Fri, 7 May 1999 11:13:59 -0700 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id LAA14488; Fri, 7 May 1999 11:13:58 -0700 (PDT) Message-Id: <199905071813.LAA14488@mina.sr.hp.com> To: Karl Denninger Cc: mjacob@feral.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer Reply-To: Darryl Okahata In-Reply-To: Your message of "Fri, 07 May 1999 10:38:14 CDT." <19990507103814.B431@Denninger.Net> Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 May 1999 11:13:58 -0700 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Karl Denninger wrote: > Does anyone have hacks to get even partial functionality? I'm flat-out of > reasonable options with the DATs that I've been using (you know, the old > "data grows" problem) and I've got the fun problem of either finding a > solution to this via the ADR drives or returning it and going with DLT > (about 4x the price). I, too, have the OnStream drive, and it's best to think of it as a "low-cost drive with a proprietary interface". Even though it has a SCSI connector, it's not a tape drive in the traditional (SCSI) sense. It'll take special drivers to talk to this puppy. If you're feeling brave and lucky, OnStream is selling "new" internal Quantum DLT-2000XT's for $649 (15GB capacity, uncompressed ). Note that these are "brand new" obsolete drives. You'd better read the fine print (especially on warranty, shipping, and "defective products"), but check out: http://www.onsale.com/category/Mass_Storage.htm Search for "DLT-2000XT", near the bottom of the page. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 11:23:20 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 7203E14E46 for ; Fri, 7 May 1999 11:23:14 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA01552; Fri, 7 May 1999 11:19:43 -0700 Date: Fri, 7 May 1999 11:19:43 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Darryl Okahata Cc: Karl Denninger , freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer In-Reply-To: <199905071813.LAA14488@mina.sr.hp.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 > I, too, have the OnStream drive, and it's best to think of it as a > "low-cost drive with a proprietary interface". Even though it has a > SCSI connector, it's not a tape drive in the traditional (SCSI) sense. > It'll take special drivers to talk to this puppy. > > If you're feeling brave and lucky, OnStream is selling "new" > internal Quantum DLT-2000XT's for $649 (15GB capacity, uncompressed ). > Note that these are "brand new" obsolete drives. You'd better read the > fine print (especially on warranty, shipping, and "defective products"), > but check out: I would not recommend the XT given the media incompatibilities they've been known to have. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 11:29:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (Postfix) with ESMTP id AAFEB14DD4 for ; Fri, 7 May 1999 11:29:30 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id NAA00292; Fri, 7 May 1999 13:26:55 -0500 (CDT) Message-ID: <19990507132655.A266@Denninger.Net> Date: Fri, 7 May 1999 13:26:55 -0500 From: Karl Denninger To: Darryl Okahata Cc: mjacob@feral.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer References: <19990507103814.B431@Denninger.Net> <199905071813.LAA14488@mina.sr.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199905071813.LAA14488@mina.sr.hp.com>; from Darryl Okahata on Fri, May 07, 1999 at 11:13:58AM -0700 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers will be LARTed and the remains fed to my cat Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, May 07, 1999 at 11:13:58AM -0700, Darryl Okahata wrote: > Karl Denninger wrote: > > > Does anyone have hacks to get even partial functionality? I'm flat-out of > > reasonable options with the DATs that I've been using (you know, the old > > "data grows" problem) and I've got the fun problem of either finding a > > solution to this via the ADR drives or returning it and going with DLT > > (about 4x the price). > > I, too, have the OnStream drive, and it's best to think of it as a > "low-cost drive with a proprietary interface". Even though it has a > SCSI connector, it's not a tape drive in the traditional (SCSI) sense. > It'll take special drivers to talk to this puppy. Well, not THAT special. It *IS* an SCSI sequential access device. > If you're feeling brave and lucky, OnStream is selling "new" > internal Quantum DLT-2000XT's for $649 (15GB capacity, uncompressed ). > Note that these are "brand new" obsolete drives. You'd better read the > fine print (especially on warranty, shipping, and "defective products"), > but check out: > > http://www.onsale.com/category/Mass_Storage.htm > > Search for "DLT-2000XT", near the bottom of the page. The 2000XTs aren't that old :-) A year or so ago I bought two for my old ISP - they're very nice units and work well. They also work properly with FreeBSD - I know this factually, because I know precisely where two of them are being used on a FreeBSD machine on a daily basis :-) However, the media is fscking expensive and hard to get. The IIIXTs (required for 15G storage; the other tapes which work only yield 10GB) are getting extremely expensive and difficult to find. If I'm going to buy a DLT these days it will be a 4000 series. -- -- Karl Denninger (karl@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 11:31:43 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id EEB06153F2 for ; Fri, 7 May 1999 11:31:40 -0700 (PDT) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id LAA10502; Fri, 7 May 1999 11:31:35 -0700 (PDT) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA170831891; Fri, 7 May 1999 11:31:31 -0700 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id LAA14714; Fri, 7 May 1999 11:31:30 -0700 (PDT) Message-Id: <199905071831.LAA14714@mina.sr.hp.com> To: mjacob@feral.com Cc: Karl Denninger , freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer Reply-To: Darryl Okahata In-Reply-To: Your message of "Fri, 07 May 1999 11:19:43 PDT." Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 May 1999 11:31:29 -0700 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I would not recommend the XT given the media incompatibilities they've > been known to have. That's good to know, thanks. I was toying with the idea of getting one. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 11:33:56 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (Postfix) with ESMTP id 621DF153EB for ; Fri, 7 May 1999 11:33:52 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id NAA00305; Fri, 7 May 1999 13:31:18 -0500 (CDT) Message-ID: <19990507133118.B266@Denninger.Net> Date: Fri, 7 May 1999 13:31:18 -0500 From: Karl Denninger To: mjacob@feral.com, Darryl Okahata Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer References: <199905071813.LAA14488@mina.sr.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Matthew Jacob on Fri, May 07, 1999 at 11:19:43AM -0700 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers will be LARTed and the remains fed to my cat Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, May 07, 1999 at 11:19:43AM -0700, Matthew Jacob wrote: > > I, too, have the OnStream drive, and it's best to think of it as a > > "low-cost drive with a proprietary interface". Even though it has a > > SCSI connector, it's not a tape drive in the traditional (SCSI) sense. > > It'll take special drivers to talk to this puppy. > > > > If you're feeling brave and lucky, OnStream is selling "new" > > internal Quantum DLT-2000XT's for $649 (15GB capacity, uncompressed ). > > Note that these are "brand new" obsolete drives. You'd better read the > > fine print (especially on warranty, shipping, and "defective products"), > > but check out: > > I would not recommend the XT given the media incompatibilities they've > been known to have. The XTs are fine - but they cannot read or write tapes written on a DLT 4000 or 7000. They can read and write 10GB (2000) and 15GB (DLTIII-XT) media, along with older DLT formats. The big problem with the 2000XTs is the cost and availability of the tapes. To get full capacity you need the XT length tapes (15GB) which are NOT second-sourced. As such you're going to get positively raped on the media cost since there is no competition (no Fuji tapes, for example). I had two of these at MCS - they were rock-solid and reliable. However, unless you can reliably source media they're going to be trouble down the road. -- -- Karl Denninger (karl@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 11:36: 4 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 58AC914E46 for ; Fri, 7 May 1999 11:36:00 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA01670; Fri, 7 May 1999 11:32:16 -0700 Date: Fri, 7 May 1999 11:32:15 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Karl Denninger Cc: Darryl Okahata , freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer In-Reply-To: <19990507133118.B266@Denninger.Net> 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 > > > "low-cost drive with a proprietary interface". Even though it has a > > > SCSI connector, it's not a tape drive in the traditional (SCSI) sense. > > > It'll take special drivers to talk to this puppy. > > > > > > If you're feeling brave and lucky, OnStream is selling "new" > > > internal Quantum DLT-2000XT's for $649 (15GB capacity, uncompressed ). > > > Note that these are "brand new" obsolete drives. You'd better read the > > > fine print (especially on warranty, shipping, and "defective products"), > > > but check out: > > > > I would not recommend the XT given the media incompatibilities they've > > been known to have. > > The XTs are fine - but they cannot read or write tapes written on a > DLT 4000 or 7000. > > They can read and write 10GB (2000) and 15GB (DLTIII-XT) media, along with > older DLT formats. > > The big problem with the 2000XTs is the cost and availability of the tapes. > To get full capacity you need the XT length tapes (15GB) which are NOT > second-sourced. As such you're going to get positively raped on the > media cost since there is no competition (no Fuji tapes, for example). > > I had two of these at MCS - they were rock-solid and reliable. However, > unless you can reliably source media they're going to be trouble down the > road. I had several at Legato. By mistake an XT tape placed into a 2000 destroyed it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 11:41:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (Postfix) with ESMTP id 6A26B153DC for ; Fri, 7 May 1999 11:41:41 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id NAA00336; Fri, 7 May 1999 13:39:00 -0500 (CDT) Message-ID: <19990507133900.A317@Denninger.Net> Date: Fri, 7 May 1999 13:39:00 -0500 From: Karl Denninger To: mjacob@feral.com Cc: Darryl Okahata , freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer References: <19990507133118.B266@Denninger.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Matthew Jacob on Fri, May 07, 1999 at 11:32:15AM -0700 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers will be LARTed and the remains fed to my cat Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, May 07, 1999 at 11:32:15AM -0700, Matthew Jacob wrote: > > > > > "low-cost drive with a proprietary interface". Even though it has a > > > > SCSI connector, it's not a tape drive in the traditional (SCSI) sense. > > > > It'll take special drivers to talk to this puppy. > > > > > > > > If you're feeling brave and lucky, OnStream is selling "new" > > > > internal Quantum DLT-2000XT's for $649 (15GB capacity, uncompressed ). > > > > Note that these are "brand new" obsolete drives. You'd better read the > > > > fine print (especially on warranty, shipping, and "defective products"), > > > > but check out: > > > > > > I would not recommend the XT given the media incompatibilities they've > > > been known to have. > > > > The XTs are fine - but they cannot read or write tapes written on a > > DLT 4000 or 7000. > > > > They can read and write 10GB (2000) and 15GB (DLTIII-XT) media, along with > > older DLT formats. > > > > The big problem with the 2000XTs is the cost and availability of the tapes. > > To get full capacity you need the XT length tapes (15GB) which are NOT > > second-sourced. As such you're going to get positively raped on the > > media cost since there is no competition (no Fuji tapes, for example). > > > > I had two of these at MCS - they were rock-solid and reliable. However, > > unless you can reliably source media they're going to be trouble down the > > road. > > I had several at Legato. By mistake an XT tape placed into a 2000 > destroyed it. Well, yes. The XT tapes are both thinner and longer than the regular 2000-series DLT tapes, and the 2000-series drives CANNOT handle the thinner and longer media. DLT in general is *forward* compatible, but not *backward* compatible. This is also true of most other "similar" media types (ie: put a 120mm DDS-II tape in an older DDS drive and it will get "eaten" as well, as the proper running tension is MUCH lower on the 120mm media) I have NOT tried putting a 2000-XT tape in a DLT-4000 unit, and have absolutely no idea if that is safe or not. If its not then the drive is a dead end, which could be bad. One of the items that makes these new "Onstream" drives so attractive is the price. $500 for the drive is damn good, and with media about $1/Gb its quite competitive. The 50G version of the same drive, due out sometime this second quarter can handle an "extra length" cartridge - but is also backward compatible for both read an write. The Onstreams are also about as fast as a DLT 4000 (but not as fast as the DLT 7000) in terms of raw I/O bitrate, and their media is less expensive. I wouldn't be surprised if they end up being a dominant device in the low and midrange server marketplace. On a cost/performance basis nothing else on the market comes close. -- -- Karl Denninger (karl@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 11:48:38 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.226]) by hub.freebsd.org (Postfix) with ESMTP id 2BB6D14BC9 for ; Fri, 7 May 1999 11:48:35 -0700 (PDT) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel3.hp.com (8.8.6 (PHNE_17135)/8.8.5tis) with ESMTP id LAA17952; Fri, 7 May 1999 11:48:29 -0700 (PDT) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA175952908; Fri, 7 May 1999 11:48:28 -0700 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id LAA15026; Fri, 7 May 1999 11:48:27 -0700 (PDT) Message-Id: <199905071848.LAA15026@mina.sr.hp.com> To: Karl Denninger Cc: mjacob@feral.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer Reply-To: Darryl Okahata In-Reply-To: Your message of "Fri, 07 May 1999 13:39:00 CDT." <19990507133900.A317@Denninger.Net> Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Fri, 07 May 1999 11:48:27 -0700 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Karl Denninger wrote: > The Onstreams are also about as fast as a DLT 4000 (but not as fast as the > DLT 7000) in terms of raw I/O bitrate, and their media is less expensive. Under Windows 98, I see an average of 50-60MB/minute with the OnStream drive. The drive has peaked higher, but the average for me is 50-60MB/min. Not bad, but not great, either. This is with *no* compression, BTW. The PC is a 400MHz Celeron using an NCR 815 SCSI adapter. -- Darryl Okahata darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 12:19:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (Postfix) with ESMTP id DF3FC14F54 for ; Fri, 7 May 1999 12:19:37 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id OAA00521; Fri, 7 May 1999 14:16:56 -0500 (CDT) Message-ID: <19990507141656.A517@Denninger.Net> Date: Fri, 7 May 1999 14:16:56 -0500 From: Karl Denninger To: Darryl Okahata Cc: mjacob@feral.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer References: <19990507133900.A317@Denninger.Net> <199905071848.LAA15026@mina.sr.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199905071848.LAA15026@mina.sr.hp.com>; from Darryl Okahata on Fri, May 07, 1999 at 11:48:27AM -0700 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers will be LARTed and the remains fed to my cat Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, May 07, 1999 at 11:48:27AM -0700, Darryl Okahata wrote: > Karl Denninger wrote: > > > The Onstreams are also about as fast as a DLT 4000 (but not as fast as the > > DLT 7000) in terms of raw I/O bitrate, and their media is less expensive. > > Under Windows 98, I see an average of 50-60MB/minute with the > OnStream drive. The drive has peaked higher, but the average for me is > 50-60MB/min. Not bad, but not great, either. > > This is with *no* compression, BTW. The PC is a 400MHz Celeron > using an NCR 815 SCSI adapter. You're probably filesystem limited. Winblows, well, blows. :-) -- -- Karl Denninger (karl@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 13:53:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 504F6155C6 for ; Fri, 7 May 1999 13:53:15 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id WAA09123; Fri, 7 May 1999 22:18:21 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.6.12) id VAA83160; Fri, 7 May 1999 21:08:19 +0200 (CEST) From: Wilko Bulte Message-Id: <199905071908.VAA83160@yedi.iaf.nl> Subject: Re: Question - Onstream SCSI Streamer In-Reply-To: <19990507133900.A317@Denninger.Net> from Karl Denninger at "May 7, 1999 1:39: 0 pm" To: karl@Denninger.Net (Karl Denninger) Date: Fri, 7 May 1999 21:08:19 +0200 (CEST) Cc: mjacob@feral.com, darrylo@sr.hp.com, freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Karl Denninger wrote ... > On Fri, May 07, 1999 at 11:32:15AM -0700, Matthew Jacob wrote: > > > > > If you're feeling brave and lucky, OnStream is selling "new" > > > > > internal Quantum DLT-2000XT's for $649 (15GB capacity, uncompressed ). > > > > > Note that these are "brand new" obsolete drives. You'd better read the > > > > > fine print (especially on warranty, shipping, and "defective products"), > > > > > but check out: > > > > > > > > I would not recommend the XT given the media incompatibilities they've > > > > been known to have. > > > > > > The XTs are fine - but they cannot read or write tapes written on a > > > DLT 4000 or 7000. They can read DLT4000 written tapes iff these are on CompactapeIII or CompacTapeIIIxt tapes. They can't write/read the Compactape IV tapes, these are only for DLT[47]000 drives. > > > second-sourced. As such you're going to get positively raped on the > > > media cost since there is no competition (no Fuji tapes, for example). > > > > > > I had two of these at MCS - they were rock-solid and reliable. However, > > > unless you can reliably source media they're going to be trouble down the > > > road. > > > > I had several at Legato. By mistake an XT tape placed into a 2000 > > destroyed it. The tape I guess, not the drive. > Well, yes. The XT tapes are both thinner and longer than the regular > 2000-series DLT tapes, and the 2000-series drives CANNOT handle the > thinner and longer media. > > DLT in general is *forward* compatible, but not *backward* compatible. Not true, the TZ87 and older drives (yes, the DEC ones, before they sold the tape & disk stuff to Quantum) can even read/write TK50 media aka Compactape II. A whopping 90Mb / cartridge. The DLT2000 is equivalent to a TZ87N (note the N) and can't do TK50 tapes. TZ87 drives are second hand several hunderd $ more expensive than TZ87N. The heads of the TZ87 are speced / tested to much narrower tolerances to be able to do TK50. Some people are really willing to pay top $ to get the genuine TZ87 ;-) > I have NOT tried putting a 2000-XT tape in a DLT-4000 unit, and have > absolutely no idea if that is safe or not. If its not then the drive > is a dead end, which could be bad. Works like a charm and is OK. My TZ88 aka DLT4000 is fed with a diet of Compactape III and IIIxt tapes. > One of the items that makes these new "Onstream" drives so attractive is > the price. $500 for the drive is damn good, and with media about $1/Gb > its quite competitive. The 50G version of the same drive, due out sometime > this second quarter can handle an "extra length" cartridge - but is also > backward compatible for both read an write. > > The Onstreams are also about as fast as a DLT 4000 (but not as fast as the > DLT 7000) in terms of raw I/O bitrate, and their media is less expensive. Ever tried to keep a DLT7000 streaming? Better fix the 64kbyte physio bottleneck before trying. Groeten / Cheers, | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 15: 6: 7 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id B882F153FB for ; Fri, 7 May 1999 15:05:50 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id XAA13188; Fri, 7 May 1999 23:38:29 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.6.12) id XAA32584; Fri, 7 May 1999 23:29:45 +0200 (CEST) From: Wilko Bulte Message-Id: <199905072129.XAA32584@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199904130349.VAA09442@panzer.plutotech.com> from "Kenneth D. Merry" at "Apr 12, 1999 9:49:40 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Fri, 7 May 1999 23:29:45 +0200 (CEST) Cc: freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Like I promised here is the status update for the Pioneer DRM-604X changer. Today I finally got hold of the new (well, newer) firmware roms. I'm running it on a -current of a couple of days ago. It is now at: /kernel: cd4: Removable CD-ROM SCSI-CCS device (when set to non-SCSI2 mode via the dipswitch on the back) or /kernel: cd3: Removable CD-ROM SCSI-2 device (when set to SCSI-2 mode). The problem: May 7 20:53:10 p100 /kernel: (cd3:isp0:0:5:2): READ TOC/PMA/ATIP {MMC Proposed} . CDB: 43 40 0 0 0 0 0 0 4 0 May 7 20:53:10 p100 /kernel: (cd3:isp0:0:5:2): ILLEGAL REQUEST asc:20,0 May 7 20:53:10 p100 /kernel: (cd3:isp0:0:5:2): Invalid command operation code can with this firmware rev be fixed by switching to SCSI-2 mode. The driver is now happy because the READ TOC cmd is no longer VU but adheres to the SCSI2 standard. I can still get the system to lock up with the default CHANGER_MIN_BUSY_SECONDS and CHANGER_MAX_BUSY_SECONDS. A kernel built with # Pioneer cdloader options CHANGER_MIN_BUSY_SECONDS=5 options CHANGER_MAX_BUSY_SECONDS=15 works fine, no lockups. Apparantly the defaults are too low for the Pioneer. All of the above was tested on a Qlogic 1040 board (isp driver). The only mystery left is that I can't get it to work using the ncr driver on a ncr810 board: May 7 23:35:07 p100 savecore: no core dump May 7 23:35:28 p100 /kernel: ncr1: timeout nccb=0xc0789200 (skip) May 7 23:35:28 p100 /kernel: (cd1:ncr1:0:5:0): got CAM status 0x4b May 7 23:35:28 p100 /kernel: (cd1:ncr1:0:5:0): fatal error, failed to attach to device May 7 23:35:28 p100 /kernel: (cd1:ncr1:0:5:0): lost device May 7 23:35:28 p100 /kernel: (cd1:ncr1:0:5:0): removing device entry May 7 23:35:50 p100 /kernel: ncr1: timeout nccb=0xc0788e00 (skip) May 7 23:36:12 p100 /kernel: ncr1: timeout nccb=0xc0788e00 (skip) May 7 23:36:12 p100 /kernel: (cd2:ncr1:0:5:1): got CAM status 0x4b May 7 23:36:12 p100 /kernel: (cd2:ncr1:0:5:1): fatal error, failed to attach to device etc. If anybody has a clue why the ncr is so much more obnoxious... Groeten / Cheers, | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 15:25:14 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id F311014C48 for ; Fri, 7 May 1999 15:25:08 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id PAA02531; Fri, 7 May 1999 15:18:40 -0700 Date: Fri, 7 May 1999 15:18:40 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: Karl Denninger , darrylo@sr.hp.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer In-Reply-To: <199905071908.VAA83160@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > second-sourced. As such you're going to get positively raped on the > > > > media cost since there is no competition (no Fuji tapes, for example). > > > > > > > > I had two of these at MCS - they were rock-solid and reliable. However, > > > > unless you can reliably source media they're going to be trouble down the > > > > road. > > > > > > I had several at Legato. By mistake an XT tape placed into a 2000 > > > destroyed it. > > The tape I guess, not the drive. The drive. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 16:13:27 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from melete.ch.intel.com (melete.ch.intel.com [143.182.246.25]) by hub.freebsd.org (Postfix) with ESMTP id 027471501E for ; Fri, 7 May 1999 16:13:23 -0700 (PDT) (envelope-from jreynold@sedona.ch.intel.com) Received: from sedona.intel.com (sedona.ch.intel.com [143.182.218.21]) by melete.ch.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id QAA18301 for ; Fri, 7 May 1999 16:13:22 -0700 (MST) Received: from hip186.ch.intel.com (hip186.ch.intel.com [143.182.225.68]) by sedona.intel.com (8.9.1a/8.9.1/d: sendmail.cf,v 1.8 1999/04/16 15:25:49 steved Exp steved $) with ESMTP id QAA26794 for ; Fri, 7 May 1999 16:13:19 -0700 (MST) X-Envelope-To: X-Envelope-From: jreynold@sedona.ch.intel.com Received: (from jreynold@localhost) by hip186.ch.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) id TAA26726; Fri, 7 May 1999 19:13:19 -0400 (EDT) From: John Reynolds~ MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14131.29582.685730.629057@hip186.ch.intel.com> Date: Fri, 7 May 1999 16:13:18 -0700 (MST) To: freebsd-scsi@freebsd.org Subject: FYI: P2B-DS BIOS update to 1008B available X-Mailer: VM 6.70 under Emacs 19.34.1 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ resend to -scsi since the BIOS update does apply to SCSI bios for 7890 ] hello all, I'm sending this out as an FYI for folks who might not have seen it. Asus has a new BIOS update for practically all of their motherboards with the AIC7890 chipset. This BIOS update updates the onboard Adaptec SCSI bios to version v2.11. I know I've seen traffic here and elsewhere about this chipset and also the 2940U2W cards--some solutions people with the add-on cards had were to update the bios to the latest one (v2.11). Well, now us folks with the embedded stuff can update it as well. ftp://ftp.asus.com/pub/BIOS/bxds108b.zip (P2B-DS--other flavors exist too). Go get it. -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds CEG, CCE, Next Generation Flows, HLA | | Intel Corporation MS: CH6-210 Phone: 480-554-9092 pgr: 868-6512 | | jreynold@sedona.ch.intel.com http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri May 7 22:19:49 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (Postfix) with ESMTP id BAE931532F for ; Fri, 7 May 1999 22:19:45 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.3/8.8.2) id AAA00616; Sat, 8 May 1999 00:19:36 -0500 (CDT) Message-ID: <19990508001936.A597@Denninger.Net> Date: Sat, 8 May 1999 00:19:36 -0500 From: Karl Denninger To: mjacob@feral.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer References: <19990507110558.A614@Denninger.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Matthew Jacob on Fri, May 07, 1999 at 09:17:22AM -0700 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers will be LARTed and the remains fed to my cat Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, May 07, 1999 at 09:17:22AM -0700, Matthew Jacob wrote: > > > > > > > Yes. > > > > Given that I could write either one dump per tape, or with dump (which > > knows what its reading and writing, therefore doesn't really "need" > > filemarks, right?) it would work - no? > > > > How difficult would it be to fix just that part of things, and would it get > > the desired result (usability with dump only)? > > Possibly easy if you just cut for this device only. I mean, it's just > software. But I certainly wouldn't go this route. Well, I added a quirk entry for the OnStream (and support for "rewind immediate" in general) to the SA driver. All that did for me is discover that the Onstream also refuses to respond to an inquiry for block limits (!) I'm going to try a few other things here before giving up on this quest and waiting for someone to get real documentation, but I'm not encouraged by what I'm seeing so far. Given that this thing CLAIMS (in the description that I have) to be an SCSI-II device, the block limit read *has to* be legal. But it fails, which means that I may be looking at some other ugliness. Why do I feel like I'm staring down a black hole on this thing? :-) > > > Yes. Onstream has said that they want to specify more carefully what the > > > soft filemarks will look like. > > > > Grrr... > > No, this is a good thing. This means that if they improve (they'd > *better*!) their h/w so that filemarks etc. are done in h/w there has to > be a compatibility with tapes written with 'soft' marks- so a known format > should be decided on. Well, yes, ok, that makes sense. :-) > > > > > I'm waiting for that information myself. > > > > > > > > Hmmm... that sounds like an indefinite timeframe. > > > > > > No- they've said they'd get that information and unit to me RSN. I believe > > > they're doing the manual this month. I expect to get a unit and a manual > > > by the end of June at the latest. It'll take a couple weeks of work I > > > suspect- there's more than just the rewind, etc..But no promises. > > > > Well that's quite the pickle for me... > > Sorry. > > > > > > > Does anyone have hacks to get even partial functionality? I'm flat-out of > > > > reasonable options with the DATs that I've been using (you know, the old > > > > "data grows" problem) and I've got the fun problem of either finding a > > > > solution to this via the ADR drives or returning it and going with DLT > > > > (about 4x the price). > > > > > > Oddly enough I've found the HP T20 Travan-5 a reasonable price performer- > > > but if you're saying a DDS3 isn't doing it for you, that's not an option. > > > What's the limiting factor? Cost? At 12GB nominal per tape for a DDS-3 > > > you'll need 4-5 to match each Onstream cartridge- so you get a bigger > > > jukebox. > > > > Running dumps to a juke doesn't work if a single filesystem doesn't fit > > on a tape. Unfortunately I am in the position of having a lot of already > > compressed files on big disks and filesystems. > > > > The result is that a single filesystem dump doesn't fit on one tape. > > Therefore, I can't run anything on automatic. This is a serious problem > > from a standpoint of actually getting the dumps done. > > > > 60 days is not a good timeframe for me; I'll live if I have to, and probably > > will keep the drive in that instance, but even partial functionality would > > serve since my needs are only for dump(8) to work. > > Why don't you go to multivolume dumps or use a different backup application? I can do that, but not automatically. I'll live with DAT for now if I have to, but I won't like it. I'm going to continue to play with this a bit more - and that's exactly what it is, since I have no actual documentation on what this drive will and won't handle, and as such I pretty much have to screw around until I find out the hard way :-) -- -- Karl Denninger (karl@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat May 8 0:39:41 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 19343154B6 for ; Sat, 8 May 1999 00:39:38 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id BAA57620; Sat, 8 May 1999 01:39:34 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199905080739.BAA57620@panzer.plutotech.com> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199905072129.XAA32584@yedi.iaf.nl> from Wilko Bulte at "May 7, 1999 11:29:45 pm" To: wilko@yedi.iaf.nl (Wilko Bulte) Date: Sat, 8 May 1999 01:39:34 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wilko Bulte wrote... > Like I promised here is the status update for the Pioneer DRM-604X changer. > Today I finally got hold of the new (well, newer) firmware roms. I'm running > it on a -current of a couple of days ago. > > It is now at: > > /kernel: cd4: Removable CD-ROM SCSI-CCS device > (when set to non-SCSI2 mode via the dipswitch on the back) > > or > > /kernel: cd3: Removable CD-ROM SCSI-2 device > (when set to SCSI-2 mode). > > The problem: > > May 7 20:53:10 p100 /kernel: (cd3:isp0:0:5:2): READ TOC/PMA/ATIP {MMC > Proposed} > . CDB: 43 40 0 0 0 0 0 0 4 0 > May 7 20:53:10 p100 /kernel: (cd3:isp0:0:5:2): ILLEGAL REQUEST asc:20,0 > May 7 20:53:10 p100 /kernel: (cd3:isp0:0:5:2): Invalid command operation > code > > can with this firmware rev be fixed by switching to SCSI-2 mode. The > driver is now happy because the READ TOC cmd is no longer VU but adheres to > the SCSI2 standard. Cool! > I can still get the system to lock up with the default CHANGER_MIN_BUSY_SECONDS > and CHANGER_MAX_BUSY_SECONDS. > > A kernel built with > > # Pioneer cdloader > options CHANGER_MIN_BUSY_SECONDS=5 > options CHANGER_MAX_BUSY_SECONDS=15 > > works fine, no lockups. Apparantly the defaults are too low for the Pioneer. That's not terribly surprising. The defaults are okay for Nakamichi changers. Perhaps they should be changed... > All of the above was tested on a Qlogic 1040 board (isp driver). > > The only mystery left is that I can't get it to work using the ncr > driver on a ncr810 board: > > May 7 23:35:07 p100 savecore: no core dump > May 7 23:35:28 p100 /kernel: ncr1: timeout nccb=0xc0789200 (skip) > May 7 23:35:28 p100 /kernel: (cd1:ncr1:0:5:0): got CAM status 0x4b > May 7 23:35:28 p100 /kernel: (cd1:ncr1:0:5:0): fatal error, failed to > attach to device > May 7 23:35:28 p100 /kernel: (cd1:ncr1:0:5:0): lost device > May 7 23:35:28 p100 /kernel: (cd1:ncr1:0:5:0): removing device entry > May 7 23:35:50 p100 /kernel: ncr1: timeout nccb=0xc0788e00 (skip) > May 7 23:36:12 p100 /kernel: ncr1: timeout nccb=0xc0788e00 (skip) > May 7 23:36:12 p100 /kernel: (cd2:ncr1:0:5:1): got CAM status 0x4b > May 7 23:36:12 p100 /kernel: (cd2:ncr1:0:5:1): fatal error, failed to > attach to device > > etc. If anybody has a clue why the ncr is so much more obnoxious... Hmm, it looks like the initial read capacity is timing out. You can try increasing the timeout for the read capacity in the probe case of cdstart() and see if that fixes the problem. I'm not sure, though, why the timeouts work okay for the QLogic board and not for the NCR. That's rather perplexing. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat May 8 2:30:21 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 4B68215615 for ; Sat, 8 May 1999 02:30:18 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: (from uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id LAA04044; Sat, 8 May 1999 11:00:29 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.6.12) id AAA34134; Sat, 8 May 1999 00:44:11 +0200 (CEST) From: Wilko Bulte Message-Id: <199905072244.AAA34134@yedi.iaf.nl> Subject: Re: Question - Onstream SCSI Streamer In-Reply-To: from Matthew Jacob at "May 7, 1999 3:18:40 pm" To: mjacob@feral.com Date: Sat, 8 May 1999 00:44:10 +0200 (CEST) Cc: karl@Denninger.Net, darrylo@sr.hp.com, freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Matthew Jacob wrote ... > > > > > > second-sourced. As such you're going to get positively raped on the > > > > > media cost since there is no competition (no Fuji tapes, for example). > > > > > > > > > > I had two of these at MCS - they were rock-solid and reliable. However, > > > > > unless you can reliably source media they're going to be trouble down the > > > > > road. > > > > > > > > I had several at Legato. By mistake an XT tape placed into a 2000 > > > > destroyed it. > > > > The tape I guess, not the drive. > > The drive. Yikes. What got broken? Leader pickup? Head? Groeten / Cheers, | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat May 8 9:19:16 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id B8EB415B2A for ; Sat, 8 May 1999 09:19:05 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id RAA18364; Sat, 8 May 1999 17:48:15 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id RAA47601; Sat, 8 May 1999 17:34:56 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199905081534.RAA47601@yedi.iaf.nl> Subject: Re: Getting Pioneer CD changer to work In-Reply-To: <199905080739.BAA57620@panzer.plutotech.com> from "Kenneth D. Merry" at "May 8, 1999 1:39:34 am" To: ken@plutotech.com (Kenneth D. Merry) Date: Sat, 8 May 1999 17:34:56 +0200 (CEST) Cc: freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Kenneth D. Merry wrote ... > Wilko Bulte wrote... > > I can still get the system to lock up with the default CHANGER_MIN_BUSY_SECONDS > > and CHANGER_MAX_BUSY_SECONDS. > > > > A kernel built with > > > > # Pioneer cdloader > > options CHANGER_MIN_BUSY_SECONDS=5 > > options CHANGER_MAX_BUSY_SECONDS=15 > > > > works fine, no lockups. Apparantly the defaults are too low for the Pioneer. > > That's not terribly surprising. The defaults are okay for Nakamichi > changers. Perhaps they should be changed... I think the current defaults are pretty low, but then again, I have this Pioneer beast ;-) ;-) > > All of the above was tested on a Qlogic 1040 board (isp driver). > > > > The only mystery left is that I can't get it to work using the ncr > > driver on a ncr810 board: > > > > May 7 23:35:07 p100 savecore: no core dump > > May 7 23:35:28 p100 /kernel: ncr1: timeout nccb=0xc0789200 (skip) > > May 7 23:35:28 p100 /kernel: (cd1:ncr1:0:5:0): got CAM status 0x4b > > May 7 23:35:28 p100 /kernel: (cd1:ncr1:0:5:0): fatal error, failed to > > attach to device > > May 7 23:35:28 p100 /kernel: (cd1:ncr1:0:5:0): lost device > > May 7 23:35:28 p100 /kernel: (cd1:ncr1:0:5:0): removing device entry > > May 7 23:35:50 p100 /kernel: ncr1: timeout nccb=0xc0788e00 (skip) > > May 7 23:36:12 p100 /kernel: ncr1: timeout nccb=0xc0788e00 (skip) > > May 7 23:36:12 p100 /kernel: (cd2:ncr1:0:5:1): got CAM status 0x4b > > May 7 23:36:12 p100 /kernel: (cd2:ncr1:0:5:1): fatal error, failed to > > attach to device > > > > etc. If anybody has a clue why the ncr is so much more obnoxious... > > Hmm, it looks like the initial read capacity is timing out. You can try > increasing the timeout for the read capacity in the probe case of > cdstart() and see if that fixes the problem. > > I'm not sure, though, why the timeouts work okay for the QLogic board and > not for the NCR. That's rather perplexing. Well, it was not clear to me, thats for sure. I'll play around with it next week. First there is this DLT4500 to fix (the hardware that is) Groeten / Cheers, | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat May 8 11: 8:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id C032E14BF7 for ; Sat, 8 May 1999 11:08:21 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA05789; Sat, 8 May 1999 11:04:38 -0700 Date: Sat, 8 May 1999 11:04:38 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Wilko Bulte Cc: karl@Denninger.Net, darrylo@sr.hp.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Question - Onstream SCSI Streamer In-Reply-To: <199905072244.AAA34134@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > The drive. > > Yikes. What got broken? Leader pickup? Head? Leader pickup is easy- that happens regularly. You pop the drive upon and put the leader pickup back on the spring. The heads probably. It never was able to read any tapes afterwards, period. We looked blank when we told ATL (the drives were in a large ATL jukebox ~500 slots, 3 DLT2000) that it wasn't working. Shame on us. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat May 8 12:34:23 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 57FF215320 for ; Sat, 8 May 1999 12:34:19 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from quarm.feral.com (quarm [192.67.166.252]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA06170; Sat, 8 May 1999 12:34:12 -0700 Date: Sat, 8 May 1999 12:34:13 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: amobbs@allstor-sw.co.uk Cc: freebsd-scsi@FreeBSD.ORG Subject: followup on old email- Read Position In-Reply-To: <80256761.00572CBF.00@mail.plasmon.co.uk> 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 (following up on older email- fishwrap probably) > > > > >These are *amazingly* broken drives then. The SCSI specification says that > >a write of *zero* filemarks is to flush any pending writes. You have to do > >this when you do a read hardware position in order to avoid an ambiguity > >in the spec as to the true position as affected by data in the tape drive > >buffer. > > Doesn't Read Position (34h) give all the info you need, i.e. Physical pos., > logical pos. and number of blocks in buffer? I agree that flushing is > safer, but surely one could avoid it if necessary. I looked into this again. The specification for SCSI-2 states: The first block location field indicates the block address associated with the current logical position. The value shall indicate the block address of the next data block to be transferred between the initiator and the the target if a READ or a WRITE command is issued. This is fine, you might think, to simply ignore any blocks in the drive's buffer that haven't been written yet. My hand furtively reaches out to remove the flush command- but hesitates. The problem here is that a hardware block position cannot possibly known until *after* all pending writes have been put on media. If there is a media error for some media types, the next hardware block is (re)used for data that wasn't successfully written to the previous block- and they have different addresses. So this leads me to think that perhaps flushing need only be done if you want to read device specific (HARDWARE) block position- you don't have to flush if you read logical block position (SCSI logical block). But again, I hesitate because I just simply have a hard time believing that drives will get this right too. However, flushing prior to *setting* position is too much. So I think that what we'll end up with is: If and only if writing and a read position is desired, do the flush. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message