From owner-freebsd-scsi Sun Sep 27 01:05:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA27718 for freebsd-scsi-outgoing; Sun, 27 Sep 1998 01:05:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from localhost.localdomain (ppp-101-46.villette.club-internet.fr [194.158.101.46]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA27703; Sun, 27 Sep 1998 01:05:44 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (groudier@localhost) by localhost.localdomain (8.8.4/8.8.4) with SMTP id JAA00544; Sun, 27 Sep 1998 09:12:29 +0200 X-Authentication-Warning: localhost.localdomain: groudier owned process doing -bs Date: Sun, 27 Sep 1998 09:12:29 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Howard Lew cc: Dan Busarow , freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: NCR 53c875 SCSI Problems 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 On Sat, 26 Sep 1998, Howard Lew wrote: > On Sat, 26 Sep 1998, Howard Lew wrote: > > > On Sat, 26 Sep 1998, Dan Busarow wrote: > > > > > On Sat, 26 Sep 1998, Howard Lew wrote: > > > > Somehow, the Seagate Hawk drive is having or causing the command failure > > > > problem -- something that never occurred with the 810 when using freebsd. > > > > > > Try going into the SCSI setup on boot up and set the transfer speed > > > to 20MB so it doesn't try wide negotiation. > > I tried setting the speed to 20MB and keeping it at 8 bit, but regardless > > of what I do the FreeBSD bootup probe still says it is wide scsi and that > > 16 bit is enabled. Right after that it starts all the command failed > > messages. I flashed upgraded the bios and it didn't help. The FreeBSD ncr driver does not read the user-setup from NVRAM and it is not possible to tell it about the BUS width at boot time. So, the WIDE negotiation has every chance to occur with great success and, as a result, will break any further data transfer between the controller and the device. > > Is there a way to force the driver to use narrow mode? I know this hard > > disk can do wide scsi, but I am using the 50 pin connector right now. Is > > narrow the default? So if I comment out the code in the setwide in ncr.c > > should that do the trick? You will get the desired effect by just masking the FE_WIDE bit in the 'features' bitmap which is the main result of the chip probe code. Look into ncr_attach(), the patch should be trivial and very short. > I did some more checking around and found out that Debian Linux also works > fine with the Seagate Hawk/Diamond Fireport 40 combination. But FreeBSD, The Linux driver reads the user-setup from the controller NVRAM and apply user desired controller and devices settings. It is also possible to send it boot parameters. The 2nd method is only usefull for controllers that donnot have NVRAM. At the time I have back-ported the Ultra1/2 SCSI support to the FreeBSD ncr driver, the NVRAM code was available in the Linux ncr53c8xx driver, but this code hasn't been candidate to the back-port, since SteFan was working on a different implementation for FreeBSD. > NetBSD, and OpenBSD all suffer from the same problem of being locked on > "wide bus" when I am using the narrow connector. Same problem as FreeBSD. Regards, Gerard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 27 04:15:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA17882 for freebsd-scsi-outgoing; Sun, 27 Sep 1998 04:15:37 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from magnet.geophysik.tu-freiberg.de (magnet.geophysik.tu-freiberg.de [139.20.128.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA17755; Sun, 27 Sep 1998 04:14:30 -0700 (PDT) (envelope-from freebsd@magnet.geophysik.tu-freiberg.de) Received: (from freebsd@localhost) by magnet.geophysik.tu-freiberg.de (8.9.1/8.7.3) id NAA09487; Sun, 27 Sep 1998 13:14:06 +0200 (CEST) From: Holm Tiffe Message-Id: <199809271114.NAA09487@magnet.geophysik.tu-freiberg.de> Subject: AHA 2742T+CAM+SMP problems 2nd. try #3 To: freebsd-scsi@FreeBSD.ORG Date: Sun, 27 Sep 1998 13:14:06 +0200 (CEST) Cc: freebsd-smp@FreeBSD.ORG Reply-To: freebsd@magnet.geophysik.tu-freiberg.de X-Mailer: ELM [version 2.4ME+ PL26 (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 Hi, I've again upgraded my kernel sources (cvs-cur.4680) and the panic from the previous version is gone now (since cam_xpt.c v.1.14) My AHA2742T is'nt working on SMP, we before. Today I have build a kernel with a COMCONSOLE to get a verbose logging from the boot process. (Remember: there is no longer an overclocked CPU) Here comes the log from kernel -hv: [ preserving 0x33148 bytes of kernel symbol table ] BIOS basemem (639K) != RTC basemem (640K), setting to BIOS value 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-BETA #8: Sun Sep 27 12:40:48 MET DST 1998 holm@unicorn.pppnet.tu-freiberg.de:/usr/src/sys/compile/UNICORNS Calibrating clock(s) ... TSC clock: 99998394 Hz, i8254 clock: 1193169 Hz Press a key on the console to abort clock calibration Calibrating clock(s) ... TSC clock: 99999113 Hz, i8254 clock: 1193175 Hz Calibrating clock(s) ... TSC clock: 99999575 Hz, i8254 clock: 1193181 Hz Calibrating clock(s) ... TSC clock: 99999086 Hz, i8254 clock: 1205108 Hz Timecounter "i8254" frequency 1193169 Hz cost 3800 ns CPU: Pentium/P54C (586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x3bf real memory = 67108864 (65536K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x00299000 - 0x03ffdfff, 64376832 bytes (15717 pages) avail memory = 62603264 (61136K bytes) Programming 16 pins in IOAPIC #0 EISA INTCONTROL = 00000e00 SMP: CPU0 apic_initialize(): lint0: 0x00000700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 Found BIOS32 Service Directory header at 0xf00fb1c0 Entry = 0xfb5f0 (0xf00fb5f0) Rev = 0 Len = 1 PCI BIOS entry at 0xb620 Other BIOS signatures found: ACPI: 00000000 $PnP: 00000000 SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000010 SVR: 0x000001ff eisa0: Probing for devices on the EISA bus ahc0: at 0x1c00-0x1cff irq 11 on eisa0 slot 1 ahc0: Using Level Sensitive Interrupts ahc0: aic7770 <= Rev C, Twin Channel, A SCSI Id=7, B SCSI Id=7, 4/255 SCBs ahc0: Resetting Channel B ahc0: Resetting Channel A ahc0: Downloading Sequencer Program... 419 instructions downloaded pci_open(1): mode 1 addr port (0x0cf8) is 0x00000000 pci_open(1a): mode1res=0x00000000 (0x80000000) pci_open(1b): mode1res=0x80000000 (0xff000001) pci_cfgcheck: device 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 -- nothing found 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=060000] [hdr=00] is there (id=04a38086) Probing for devices on PCI bus 0: found-> vendor=0x8086, dev=0x04a3, revid=0x11 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 chip0: rev 0x11 on pci0.0.0 CPU: Pentium, 100MHz, CPU->Memory posting ON, read around write Warning: Cache parity disabled! Warning: DRAM parity mask! Cache: 512KB writeback, cache clocks=3-2-2-2/4-2-2-2 Cache flags: byte-control powersaver DRAM: page mode memory clocks=X-3-3-3 (50ns) CPU->PCI: posting ON, burst mode ON, PCI clocks=2-1-1-1 PCI->Memory: posting ON Refresh: RAS#Only found-> vendor=0x8086, dev=0x0482, revid=0x04 class=00-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 chip1: rev 0x04 on pci0.2.0 found-> vendor=0x102b, dev=0x051b, revid=0x00 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=9 map[0]: type 3, range 32, base fb000000, size 24 map[1]: type 1, range 32, base fafec000, size 14 map[2]: type 1, range 32, base fa000000, size 23 vga0: rev 0x00 int a irq 9 on pci0.5.0 found-> vendor=0x1011, dev=0x0002, revid=0x23 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=10 map[0]: type 4, range 32, base 0000e800, size 7 map[1]: type 1, range 32, base f9fff000, size 7 de0: rev 0x23 int a irq 10 on pci0.6.0 de0: Cogent 21040 [10Mb/s] pass 2.3 de0: address 00:00:92:90:09:8d bpf: de0 attached Probing for devices on the ISA bus: video: RTC equip. code:0x4f, DCC code:0xf9 video: CRTC:0x3d4, video option:0x60, rows:80, cols:25, font height:16 video: param table EGA/VGA:0xf00c04d0, CGA/MDA:0 video: rows_offset:1 video#0: adapter type:VGA (5), flags:0x7f, CRTC:0x3d4 video#0: init mode:24, bios mode:3, current mode:24 video#0: window:0xf00b8000 size:32k gran:32k, buf:0xf0000000 size:32k video#0: mode:0, flags:0x1 T 40x25, font:8x8, win:0xb8000 video#0: mode:1, flags:0x1 T 40x25, font:8x8, win:0xb8000 video#0: mode:2, flags:0x1 T 80x25, font:8x8, win:0xb8000 video#0: mode:3, flags:0x1 T 80x25, font:8x8, win:0xb8000 video#0: mode:19, flags:0x1 T 40x25, font:8x14, win:0xb8000 video#0: mode:20, flags:0x1 T 40x25, font:8x14, win:0xb8000 video#0: mode:21, flags:0x1 T 80x25, font:8x14, win:0xb8000 video#0: mode:22, flags:0x1 T 80x25, font:8x14, win:0xb8000 video#0: mode:23, flags:0x1 T 40x25, font:8x16, win:0xb8000 video#0: mode:25, flags:0x0 T 80x25, font:8x16, win:0xb0000 video#0: mode:24, flags:0x1 T 80x25, font:8x16, win:0xb8000 video#0: mode:7, flags:0x0 T 80x25, font:8x14, win:0xb0000 video#0: mode:112, flags:0x1 T 80x43, font:8x8, win:0xb8000 video#0: mode:113, flags:0x1 T 80x43, font:8x8, win:0xb8000 video#0: mode:33, flags:0x0 T 80x30, font:8x16, win:0xb0000 video#0: mode:32, flags:0x1 T 80x30, font:8x16, win:0xb8000 video#0: mode:31, flags:0x0 T 80x50, font:8x8, win:0xb0000 video#0: mode:30, flags:0x1 T 80x50, font:8x8, win:0xb8000 video#0: mode:35, flags:0x0 T 80x60, font:8x8, win:0xb0000 video#0: mode:34, flags:0x1 T 80x60, font:8x8, win:0xb8000 video#0: mode:4, flags:0x3 G 320x200x2, 1 plane(s), font:8x8, win:0xb8000 video#0: mode:5, flags:0x3 G 320x200x2, 1 plane(s), font:8x8, win:0xb8000 video#0: mode:6, flags:0x3 G 640x200x1, 1 plane(s), font:8x8, win:0xb8000 video#0: mode:13, flags:0x3 G 320x200x4, 4 plane(s), font:8x8, win:0xa0000 video#0: mode:14, flags:0x3 G 640x200x4, 4 plane(s), font:8x8, win:0xa0000 video#0: mode:15, flags:0x2 G 640x350x4, 4 plane(s), font:8x14, win:0xa0000 video#0: mode:17, flags:0x2 G 640x350x4, 4 plane(s), font:8x14, win:0xa0000 video#0: mode:16, flags:0x3 G 640x350x2, 2 plane(s), font:8x14, win:0xa0000 video#0: mode:18, flags:0x3 G 640x350x4, 4 plane(s), font:8x14, win:0xa0000 video#0: mode:26, flags:0x3 G 640x480x4, 4 plane(s), font:8x16, win:0xa0000 video#0: mode:27, flags:0x3 G 640x480x4, 4 plane(s), font:8x16, win:0xa0000 video#0: mode:28, flags:0x3 G 320x200x8, 1 plane(s), font:8x8, win:0xa0000 video#0: mode:37, flags:0x3 G 320x240x8, 1 plane(s), font:8x8, win:0xa0000 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 sc0: the current keyboard controller command byte 0047 kbdio: DIAGNOSE status:0055 kbdio: TEST_KBD_PORT status:0000 kbdio: RESET_KBD return code:00fa kbdio: RESET_KBD status:00aa sc0: keyboard device ID: ab41 sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0: irq maps: 0x401 0x411 0x401 0x401 sio0 at 0x3f8-0x3ff irq 4 flags 0x30 on isa sio0: type 16450, console sio1: irq maps: 0x401 0x409 0x401 0x401 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16450 dgb0: PC/Xe 64K dgb0 at 0x300-0x303 maddr 0xd0000 msize 65536 on isa dgb0: 8 ports lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached psm0: current command byte:0047 kbdio: TEST_AUX_PORT status:0000 kbdio: RESET_AUX return code:00fa kbdio: RESET_AUX status:00aa kbdio: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 90 03 14 psm: status 90 03 14 psm: status 90 03 14 psm: status 00 00 0a psm: data 08 00 00 psm: data 08 00 00 psm: status 00 02 64 psm0 at 0x60-0x64 irq 12 on motherboard psm0: model Generic PS/2 mouse, device ID 0, 3 buttons psm0: config:00000000, flags:00000000, packet size:3 psm0: syncmask:c0, syncbits:00 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fd0: 1.44MB 3.5in fd1: 1.2MB 5.25in npx0 on motherboard npx0: INT 16 interface i586_bzero() bandwidth = 668002672 bytes/sec bzero() bandwidth = 337040781 bytes/sec imasks: bio c8000040, tty c700149a, net c700149a de0: enabling AUI/BNC port SMP: enabled INTs: 1, 3, 4, 6, 7, 10, 11, 12, apic_imen: 0x00ffe325 BIOS Geometries: 0:00ca3f20 0..202=203 cylinders, 0..63=64 heads, 1..32=32 sectors 1:0104fe3f 0..260=261 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Intel Pentium F00F detected, installing workaround APIC_IO: routing 8254 via pin 2 bpf: tun0 attached bpf: sl0 attached bpf: ppp0 attached new masks: bio c8000040, tty c700149a, net c700149a bpf: lo0 attached (noperiph:ahc0:0:X:X): SCSI bus reset delivered. 0 SCBs aborted. (noperiph:ahc0:1:X:X): SCSI bus reset delivered. 0 SCBs aborted. SMP: AP CPU #1 Launched! SMP: CPU1 apic_initialize(): lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff ahc0: Selection Timeout on A:1. 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 B:0. 1 SCBs aborted ahc0: Selection Timeout on B:1. 1 SCBs aborted It is impossible that the AHA2742 generates no interrupts, because the panic message from the previous post came from within _ahc_intr(). The file /usr/src/sys/i386/eisa/ahc_eisa.c contains the following lines: /* * See if we have a Rev E or higher aic7770. Anything below a * Rev E will have a R/O autoflush disable configuration bit. */ { char *id_string; u_int8_t sblkctl; u_int8_t sblkctl_orig; sblkctl_orig = ahc_inb(ahc, SBLKCTL); sblkctl = sblkctl_orig ^ AUTOFLUSHDIS; ahc_outb(ahc, SBLKCTL, sblkctl); sblkctl = ahc_inb(ahc, SBLKCTL); if (sblkctl != sblkctl_orig) { id_string = "aic7770 >= Rev E, "; /* * Ensure autoflush is enabled */ sblkctl &= ~AUTOFLUSHDIS; ahc_outb(ahc, SBLKCTL, sblkctl); } else id_string = "aic7770 <= Rev C, "; printf("%s: %s", ahc_name(ahc), id_string); } .. could this be relatet to my problem ? Please give me a hint, where I should look to get this debugged. I'll try to get this working alone, because no one seems to be very interrested on my problem, but I need urgently a hint... Holm -- ******************************************************************************* * Holm Tiffe holm@geophysik.tu-freiberg.de * * Freiberger Strasse 24 * * 09600 Kleinschirma, Germany Microsoft is not the Answer - * * Tel.: 49 3731 74233 Microsoft is the Question, * * UUCP: 49 3731 73719 unicorn!holm and the Answer is no ! * ******************************************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 27 06:21:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA00108 for freebsd-scsi-outgoing; Sun, 27 Sep 1998 06:21:50 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA00102 for ; Sun, 27 Sep 1998 06:21:49 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id HAA11614; Sun, 27 Sep 1998 07:14:48 -0600 (MDT) Date: Sun, 27 Sep 1998 07:14:48 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809271314.HAA11614@narnia.plutotech.com> To: freebsd@magnet.geophysik.tu-freiberg.de cc: scsi@FreeBSD.ORG Subject: Re: AHA 2742T+CAM+SMP problems 2nd. try #3 Newsgroups: pluto.freebsd.scsi In-Reply-To: <199809271114.NAA09487@magnet.geophysik.tu-freiberg.de> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199809271114.NAA09487@magnet.geophysik.tu-freiberg.de> you wrote: > Hi, > > I've again upgraded my kernel sources (cvs-cur.4680) > and the panic from the previous version is gone now > (since cam_xpt.c v.1.14) Can you move this to the SMP list then? This is not a CAM problem. > (noperiph:ahc0:0:X:X): SCSI bus reset delivered. 0 SCBs aborted. > (noperiph:ahc0:1:X:X): SCSI bus reset delivered. 0 SCBs aborted. > SMP: AP CPU #1 Launched! > SMP: CPU1 apic_initialize(): > lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff > ahc0: Selection Timeout on A:1. 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 B:0. 1 SCBs aborted > ahc0: Selection Timeout on B:1. 1 SCBs aborted > > It is impossible that the AHA2742 generates no interrupts, > because the panic message from the previous post came from > within _ahc_intr(). Okay, let me rephrase that. The 2742 is able to generate interrupts until a little time after the second CPU is launched. The panic you saw yesturday actually occured well before the second CPU was launched. > /* > * See if we have a Rev E or higher aic7770. Anything below a > * Rev E will have a R/O autoflush disable configuration bit. > */ This has nothing to do with interrupt delivery. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 27 12:45:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03689 for freebsd-scsi-outgoing; Sun, 27 Sep 1998 12:45:49 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from midten.fast.no (midten.fast.no [195.139.251.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03625; Sun, 27 Sep 1998 12:45:18 -0700 (PDT) (envelope-from tegge@fast.no) Received: from fast.no (IDENT:tegge@midten.fast.no [195.139.251.11]) by midten.fast.no (8.9.1/8.9.1) with ESMTP id VAA01789; Sun, 27 Sep 1998 21:42:18 +0200 (CEST) Message-Id: <199809271942.VAA01789@midten.fast.no> To: freebsd@magnet.geophysik.tu-freiberg.de Cc: freebsd-scsi@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: AHA 2742T+CAM+SMP problems 2nd. try #3 From: Tor.Egge@fast.no In-Reply-To: Your message of "Sun, 27 Sep 1998 13:14:06 +0200 (CEST)" References: <199809271114.NAA09487@magnet.geophysik.tu-freiberg.de> X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 27 Sep 1998 21:42:18 +0200 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > EISA INTCONTROL = 00000e00 Interrupts 10, 11 and 12 are level sensitive. > ahc0: at 0x1c00-0x1cff irq 11 on eisa0 slot 1 > ahc0: Using Level Sensitive Interrupts The scsi card generates an active low/level interrupt 11. With an MP table that says I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# INT conforms conforms 0 11 2 11 this means that int pin 11 on the IOAPIC is currently programmed as active high/edge trigger. It should probably be programmed as active high/level trigger. I assume you have the MP spec document. If you configure your scsi card to use edge interrupts, you'll probably avoid this problem. Index: mpapic.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/mpapic.c,v retrieving revision 1.32 diff -u -r1.32 mpapic.c --- mpapic.c 1998/09/06 22:41:40 1.32 +++ mpapic.c 1998/09/27 18:39:04 @@ -303,12 +303,7 @@ printf("EISA INTCONTROL = %08x\n", intcontrol); } - /* - * EISA IRQ's are identical to ISA irq's, regardless of - * whether they are edge or level since they go through - * the level/polarity converter gadget. - */ - level = 0; + level = ((intcontrol >> eirq) & 1); if (level) *flags |= IOART_TRGRLVL; @@ -378,7 +373,8 @@ * level/polarity converter gadget. */ if (level == 1) /* XXX Always false */ - pol = 0; /* if level, active low */ + /* level => active high on IO APIC (low on EISA bus) */ + pol = 1; /* if level, active high */ else pol = 1; /* if edge, high edge */ - Tor Egge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Sep 27 15:44:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03074 for freebsd-scsi-outgoing; Sun, 27 Sep 1998 15:44:14 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA02898; Sun, 27 Sep 1998 15:43:33 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id GAA00386; Mon, 28 Sep 1998 06:37:55 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199809272237.GAA00386@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Tor.Egge@fast.no cc: freebsd@magnet.geophysik.tu-freiberg.de, freebsd-scsi@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: AHA 2742T+CAM+SMP problems 2nd. try #3 In-reply-to: Your message of "Sun, 27 Sep 1998 21:42:18 +0200." <199809271942.VAA01789@midten.fast.no> Date: Mon, 28 Sep 1998 06:37:55 +0800 From: Peter Wemm Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tor.Egge@fast.no wrote: > > EISA INTCONTROL = 00000e00 > > Interrupts 10, 11 and 12 are level sensitive. 9, 10 and 11 actually.. (9 is pci video card, 10 is pci ethernet card, 11 is scsi controller). This is interesting. When we were first putting this together we came to the conclusion that the output of the edle/level control system was fed to both the normal PIC and the IO apic. After looking at my system (intcontrol = 0x220), it's reporting irq 5 and 9 as level (video and network again), and the Adaptec is (now that I think about it) on edge trigger mode. ahc0: at 0x1c00-0x1cff irq 11 on eisa0 slot 1 ahc0: Using Edge Triggered Interrupts The documentation doesn't say anything about the routing of interrupts on EISA systems. Also, it's interesting to note that the MPtable is *wrong* on both his and my systems. (and it's in ROM) > > ahc0: at 0x1c00-0x1cff irq 11 on eisa0 slo t 1 > > ahc0: Using Level Sensitive Interrupts > > The scsi card generates an active low/level interrupt 11. And that's the difference between his and my systems. > With an MP table that says > > I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# > INT conforms conforms 0 11 2 11 > > > this means that int pin 11 on the IOAPIC is currently programmed as > active high/edge trigger. And the mptable is wrong on all of these systems. > It should probably be programmed as active high/level trigger. I assume > you have the MP spec document. It doesn't help. I seem to recall that there was another problem too.. If my memory serves, I think PCI was level active low, but EISA was level active high - or maybe the other way around.. Presumably the ELCR device knows about this or has some other compensation to make it work. > If you configure your scsi card to use edge interrupts, you'll probably > avoid this problem. Yes. > Index: mpapic.c > =================================================================== > RCS file: /home/ncvs/src/sys/i386/i386/mpapic.c,v > retrieving revision 1.32 > diff -u -r1.32 mpapic.c > --- mpapic.c 1998/09/06 22:41:40 1.32 > +++ mpapic.c 1998/09/27 18:39:04 > @@ -303,12 +303,7 @@ > printf("EISA INTCONTROL = %08x\n", intcontrol); > } > > - /* > - * EISA IRQ's are identical to ISA irq's, regardless of > - * whether they are edge or level since they go through > - * the level/polarity converter gadget. > - */ > - level = 0; > + level = ((intcontrol >> eirq) & 1); > > if (level) > *flags |= IOART_TRGRLVL; > @@ -378,7 +373,8 @@ > * level/polarity converter gadget. */ > > if (level == 1) /* XXX Always false */ > - pol = 0; /* if level, active low */ > + /* level => active high on IO APIC (low on EISA bus) */ > + pol = 1; /* if level, active high */ > else > pol = 1; /* if edge, high edge */ This should probably work too. We had something like this in the SMP cvs tree before the merge, but it got backed out. It was probably some other problem or lack of information, I don't remember the details, but at the time my 2742 worked under edge trigger best. This is a very grey area in the MPspec. > - Tor Egge Cheers, -Peter -- Peter Wemm Netplex Consulting "No coffee, No workee!" :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 00:35:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA19618 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 00:35:33 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from coventry.ac.uk (mercury.coventry.ac.uk [193.61.107.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA19613 for ; Mon, 28 Sep 1998 00:35:31 -0700 (PDT) (envelope-from justin@mascarpone.coventry.ac.uk) Received: from mascarpone.coventry.ac.uk (mascarpone.coventry.ac.uk [194.66.38.77]) by coventry.ac.uk (8.8.7/8.6.11) with SMTP id IAA12164 for <@mercury.coventry.ac.uk:scsi@freebsd.org>; Mon, 28 Sep 1998 08:35:20 +0100 (BST) Received: (from justin@localhost) by mascarpone.coventry.ac.uk (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA01788; Mon, 28 Sep 1998 08:34:51 +0100 Message-Id: <199809280734.IAA01788@mascarpone.coventry.ac.uk> Date: Mon, 28 Sep 98 08:34 +0100 From: Justin Murdock Subject: Slide Writers To: scsi@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Af v1.98.4 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Is there any support for SCSI slidewriters? In particular the one attatched to the mac just across the room SCSIProbe 4.3 reports Type: Printer Vendor: AGFA-MTX Product:SlideWriter Version:2.03 Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 02:31:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA06874 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 02:31:26 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail.cs.tu-berlin.de (mail.cs.tu-berlin.de [130.149.17.13]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA06258; Mon, 28 Sep 1998 02:25:51 -0700 (PDT) (envelope-from wosch@cs.tu-berlin.de) Received: from caramba.cs.tu-berlin.de (wosch@caramba.cs.tu-berlin.de [130.149.17.12]) by mail.cs.tu-berlin.de (8.9.1/8.9.1) with ESMTP id LAA15022; Mon, 28 Sep 1998 11:19:53 +0200 (MET DST) Received: (from wosch@localhost) by caramba.cs.tu-berlin.de (8.9.1/8.9.0) id LAA01296; Mon, 28 Sep 1998 11:19:49 +0200 (MET DST) Message-ID: <19980928111947.A552@caramba.cs.tu-berlin.de> Date: Mon, 28 Sep 1998 11:19:47 +0200 From: Wolfram Schneider To: cameron.humphries@sge.net, wosch@FreeBSD.ORG Cc: scsi@FreeBSD.ORG Subject: Re: broken link References: <4a25668d.0026fbc9.00@sge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <4a25668d.0026fbc9.00@sge.net>; from cameron.humphries@sge.net on Mon, Sep 28, 1998 at 05:08:27PM +1000 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1998-09-28 17:08:27 +1000, cameron.humphries@sge.net wrote: > http://www.freebsd.org/FAQ/FAQ75.html#75 has a broken link. The link is > ftp://ftp.freebsd.org/pub/FreeBSD/cam which doesn't exist. > > Would you have a pointer to the proper location of these patches?? CAM is now imported into FreeBSD 3.0-current. See ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/sys/cam or http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/ -- Wolfram Schneider http://freebsd.org/~w/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 05:49:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA03781 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 05:49:49 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA03754 for ; Mon, 28 Sep 1998 05:49:34 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from bergelmir.ifi.uio.no (2602@bergelmir.ifi.uio.no [129.240.65.172]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id OAA09708 for ; Mon, 28 Sep 1998 14:49:17 +0200 (MET DST) Received: (from dag-erli@localhost) by bergelmir.ifi.uio.no ; Mon, 28 Sep 1998 14:49:17 +0200 (MET DST) Mime-Version: 1.0 To: scsi@FreeBSD.ORG Subject: mt fsf 1 times out Organization: University of Oslo, Department of Informatics X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-other-addresses: 'finger dag-erli@ifi.uio.no' for a list X-disclaimer-1: The views expressed in this article are mine alone, and do X-disclaimer-2: not necessarily coincide with those of any organisation or X-disclaimer-3: company with which I am or have been affiliated. X-Stop-Spam: http://www.cauce.org/ From: dag-erli@ifi.uio.no (Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 28 Sep 1998 14:49:17 +0200 Message-ID: Lines: 60 X-Mailer: Gnus v5.5/Emacs 19.34 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id FAA03774 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I had a CAM+softupdates crash yesterday (no panic message, no core dump, no nothing; I suspect the kernel dropped into the debugger, which doesn't work too well if X is running. When I rebooted, I found my /usr totally hosed (looks like the root directory entry had been blown away) and fsck failed miserably ("no space in lost+found, sorry"), so I thought what the heck, I have a week-old level 0 dump and there's nothing in /usr except the "usual" (bin, sbin, libexec, share, and X) since I have /usr/local, /usr/src and /usr/obj on separate file systems, and my ports tree is in /usr/local (which allows me to mount /usr ro - unfortunately, it wasn't ro when the crash happened for some reason I can't remember). So I newfs'ed /usr, copied back what I needed (make, mtree, a couple of libs) from /usr/obj/elf/usr/src/tmp/usr/*, recreated the /usr hierarchy with 'mtree -eU' and ran make install. So far so good. But now I want to restore my X tree (/usr/X11R6) from tape. The problem is that there are several dumps on the tape, and I can't seek to the right one. Here's what the tape looks like (from memory): 1) level 0 dump of / 2) level 0 dump of /home <--- this is a biggie 3) level 0 dump of /usr <--- this is the one I want 4) level 0 dump of /var 5) level 0 dump of /home/cvs 6) level 0 dump of /home/ncvs The reason why /home is so big is that I have two complete FreeBSD distributions laid out under /home/ftp (for network installs). I agree it's kinda dumb to dump it to tape when I have them on CD-ROM, but I just stuffed in the tape and ran the script (which extracts the list of file systems to dump from /etc/fstab, which is the reason for the boneheaded layout - /home should have been last) The problem is that 'mt fsf 2' from the beginning of the tape (or 'mt fsf 1' after 'mt rewind; mt fsf 1' to seek past /) takes more than an hour, and I get a timeout after precisely one hour (give or take five seconds). What I get is the usual "timed out while idle", followed by a "Power on, reset, or bus device reset occurred", followed by the tape rewinding (much faster than it can wind forward)... This seems consistent with the code (saspace() in sys/cam/scsi/scsi_sa.c calls scsi_space with a timeout of 60*60*1000 ms) I thought of winding the tape forward "manually" bit by bit (by doing 'mt fsr xxx') but I can't seem to find the right count. If I rewind the tape and do 'mt fsr 1000' followed by 'mt fsf 1', I get to /home as expected. I have a log of the dump, so I know the size of each section, but how many blocks are in a record? What count should I use to wind the tape forward ~2100000 blocks? (of course I intended to do it in several smaller steps so that none of the individual steps took more than an hour). Of course, I can hack my kernel to use a longer timeout, but I'd like to know the answer to those questions all the same... OBTW, I browsed through some of the CAM code while researching this and I have to hand it to you guys, it's such *beautiful* code... :) DES -- Dag-Erling Smørgrav - dag-erli@ifi.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 09:09:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA02155 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 09:09:10 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA02141 for ; Mon, 28 Sep 1998 09:09:05 -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 KAA12061; Mon, 28 Sep 1998 10:08:45 -0600 (MDT) Message-Id: <199809281608.KAA12061@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: scsi From: Steve Passe To: "Justin T. Gibbs" cc: scsi@FreeBSD.ORG Subject: p2b scsi termination Mime-Version: 1.0 Content-Type: text/plain Date: Mon, 28 Sep 1998 10:08:45 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin, I have been running an asus p2b-ds with -current for a week now, VERY nice board! Am totally confused about the scsi term issue. Kevin @ atipa said you worked out some of the details on this. 1: the manual states: "The 68-pin WIDE SCSI connectoris always terminated and will only work as an end device" is that really true? 2: I want to put a wide device on the 68-pin wide (not u2w) bus, and several narrow devices on the 50-pin bus. The BIOS doesn't have the usual choice of "low off/hi on", only "off/on". If I turn the SE term off, will it implicitly leave the 'high' side on? Or is this even possible? The adaptec datasheet for the aha2940u2w board claims that all connectors can be used simultaniously, so I think it should work... 3: Am I correct in believing that the uw bus and narrow bus are effectively ONE SCSI bus, with the hi 8-bits left off one half? (u2w TERM ON) (SE TERM OFF, implicit hi-byte ON?) |u2w conn| |uw conn|====-----|narrow conn| ---------- --------- ------------- || || | ||={da0} ||={da3} |-{st0} || || | ||={da1} || |-{cd0} || || | ||={da2} || |-{da5(zip)} || || | ||={TERM} ||={TERM} |-{TERM} 4: Kevin postulated that the BIOS actually enables/disables AUTOMATIC TERMination, so that it should always be left on, and the hardware will determine whats where, is that possible? This worrys me as I have had "automatic TERMination" fail to work properly on other MBs in the past, requiring a manual setting to function properly. tia, -- 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 Mon Sep 28 09:25:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA05240 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 09:25:28 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA05226 for ; Mon, 28 Sep 1998 09:25:24 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id KAA02664; Mon, 28 Sep 1998 10:25:10 -0600 (MDT) Message-Id: <199809281625.KAA02664@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Steve Passe cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: p2b scsi termination In-reply-to: Your message of "Mon, 28 Sep 1998 10:08:45 MDT." <199809281608.KAA12061@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Sep 1998 10:18:39 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Justin, > >I have been running an asus p2b-ds with -current for a week now, VERY >nice board! Am totally confused about the scsi term issue. Kevin @ atipa >said you worked out some of the details on this. I have a P2B-S here, and the last time I looked at this, it seemed that: 1) The termination settings I can set in the aic7xxx driver have no effect. All termination control is provided by some PLD that is controlled by the MB BIOS. 2) The MB allows you to toggle the termination on the low 8bits of the SE bus, but the high byte termination is always on (perhaps there is a jumper for it??) 3) The MB does not have automatic termination support. Since the P2B series uses an aic3860, the LVD and SE busses are electrically two separate busses. This is why you can use all three connectors simultaneously. > 1: the manual states: "The 68-pin WIDE SCSI connectoris always terminated > and will only work as an end device" > is that really true? yes. > 2: I want to put a wide device on the 68-pin wide (not u2w) bus, and > several narrow devices on the 50-pin bus. The BIOS doesn't have > the usual choice of "low off/hi on", only "off/on". If I turn the > SE term off, will it implicitly leave the 'high' side on? Or is this > even possible? The adaptec datasheet for the aha2940u2w board claims > that all connectors can be used simultaniously, so I think it should > work... You just need to turn off the low byte termination in the MB BIOS. > 3: Am I correct in believing that the uw bus and narrow bus are > effectively ONE SCSI bus, with the hi 8-bits left off one half? Yup. > 4: Kevin postulated that the BIOS actually enables/disables AUTOMATIC > TERMination, so that it should always be left on, and the hardware > will determine whats where, is that possible? This worrys me as > I have had "automatic TERMination" fail to work properly on other > MBs in the past, requiring a manual setting to function properly. The BIOS directly controls the terminators. There is no cable detection logic on this MB. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 09:45:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09170 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 09:45:51 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA09153 for ; Mon, 28 Sep 1998 09:45:40 -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 KAA12178; Mon, 28 Sep 1998 10:45:22 -0600 (MDT) Message-Id: <199809281645.KAA12178@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: "Justin T. Gibbs" cc: Steve Passe , scsi@FreeBSD.ORG Subject: Re: p2b scsi termination In-reply-to: Your message of "Mon, 28 Sep 1998 10:18:39 MDT." <199809281625.KAA02664@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Sep 1998 10:45:22 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin, > > 1: the manual states: "The 68-pin WIDE SCSI connectoris always terminated > > and will only work as an end device" > > is that really true? > > yes. > > ... > > > 3: Am I correct in believing that the uw bus and narrow bus are > > effectively ONE SCSI bus, with the hi 8-bits left off one half? > > Yup. perhaps I havn't had enough coffe yet this morning, but these 2 statements seem to conflict. IF the WIDE SCSI MUST be an end device then my statement about devices on both the WIDE and NARROW busses wouldn't work. Are they trying to say that "the HIGH byte of the WIDE bus is always terminated" and thus you couldn't put the MB connector in the middle of a WIDE cable (assumming you didn't use the NARROW cable at all)? -- 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 Mon Sep 28 09:46:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09344 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 09:46:20 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA09243 for ; Mon, 28 Sep 1998 09:46:09 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id KAA15157; Mon, 28 Sep 1998 10:39:12 -0600 (MDT) Date: Mon, 28 Sep 1998 10:39:12 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809281639.KAA15157@narnia.plutotech.com> To: Justin Murdock cc: scsi@FreeBSD.ORG Subject: Re: Slide Writers Newsgroups: pluto.freebsd.scsi In-Reply-To: <199809280734.IAA01788@mascarpone.coventry.ac.uk> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <199809280734.IAA01788@mascarpone.coventry.ac.uk> you wrote: > Is there any support for SCSI slidewriters? > > In particular the one attatched to the mac just across the room It looks like it supports the standard SCSI printer interface. You'd need to write a peripheral driver for this, but that shouldn't be too hard. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 09:53:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA10686 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 09:53:01 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA10676 for ; Mon, 28 Sep 1998 09:52:58 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id KAA15183; Mon, 28 Sep 1998 10:46:13 -0600 (MDT) Date: Mon, 28 Sep 1998 10:46:13 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809281646.KAA15183@narnia.plutotech.com> To: dag-erli@ifi.uio.no (Dag-Erling C. Sm?rgrav ) cc: scsi@FreeBSD.ORG Subject: Re: mt fsf 1 times out Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > The problem is that 'mt fsf 2' from the beginning of the tape (or 'mt > fsf 1' after 'mt rewind; mt fsf 1' to seek past /) takes more than an > hour, and I get a timeout after precisely one hour (give or take five > seconds). What I get is the usual "timed out while idle", followed by > a "Power on, reset, or bus device reset occurred", followed by the > tape rewinding (much faster than it can wind forward)... This seems > consistent with the code (saspace() in sys/cam/scsi/scsi_sa.c calls > scsi_space with a timeout of 60*60*1000 ms) I would suggest simply uping the timeout in the kernel and using mt normally. The timeout in general is a known problem. The plan is to run tape operations expected to take a while with no timeout, add support for the XPT_ABORT_CCB CAM function code, handle signals in the sa ioctl routine, and send an abort if the user ^C's mt. mt will also be modified to take an optional timeout (which would then be passed into the ioctl) so that scripts running without human supervision can handle error conditions. I do not know if I will be able to get all of the CAM hooks for this completed before 3.0R, but I will try. The ch driver would benefit from this interface too. > OBTW, I browsed through some of the CAM code while researching this > and I have to hand it to you guys, it's such *beautiful* code... :) Thanks! -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 09:55:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA11118 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 09:55:47 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA11095 for ; Mon, 28 Sep 1998 09:55: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.8.7/8.8.5) with ESMTP id KAA04923; Mon, 28 Sep 1998 10:55:27 -0600 (MDT) Message-Id: <199809281655.KAA04923@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Steve Passe cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: p2b scsi termination In-reply-to: Your message of "Mon, 28 Sep 1998 10:45:22 MDT." <199809281645.KAA12178@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Sep 1998 10:48:55 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Justin, > >> > 1: the manual states: "The 68-pin WIDE SCSI connectoris always terminated >> > and will only work as an end device" >> > is that really true? >> >> yes. >> >> ... >> >> > 3: Am I correct in believing that the uw bus and narrow bus are >> > effectively ONE SCSI bus, with the hi 8-bits left off one half? >> >> Yup. > >perhaps I havn't had enough coffe yet this morning, but these 2 statements >seem to conflict. IF the WIDE SCSI MUST be an end device then my statement >about devices on both the WIDE and NARROW busses wouldn't work. It must be the end of the wide chain. You cannot have the adapter port in the middle of a wide cable as it will always terminate the high byte of the bus. It may also terminate the low byte depending on the settings in the BIOS. >Are they >trying to say that "the HIGH byte of the WIDE bus is always terminated" >and thus you couldn't put the MB connector in the middle of a WIDE cable >(assumming you didn't use the NARROW cable at all)? Exactly. >-- >Steve Passe | powered by >smp@csn.net | Symmetric MultiProcessor FreeBSD -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 15:39:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA11907 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 15:39:20 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from vision.vc3.com (vision.vc3.com [209.12.161.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA11877 for ; Mon, 28 Sep 1998 15:39:08 -0700 (PDT) (envelope-from tatemj@vision.vc3.com) Received: from localhost (tatemj@localhost) by vision.vc3.com (8.8.7/8.8.5) with SMTP id SAA24711 for ; Mon, 28 Sep 1998 18:38:49 -0400 Date: Mon, 28 Sep 1998 18:38:49 -0400 (EDT) From: Jason Tatem To: freebsd-scsi@FreeBSD.ORG Subject: CAM Failure? 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 got an Adaptec 2940UW and a variety of Seagate UW drives in my system. Been running -current with periodic updating to it for about 6-8 months now without problems. When I CVsup'd the other night, world compiled fine, and when I modified my kernel config file to include the proper device names and such for CAM, everything went fine there...kernel compiled nice and clean. When I rebooted, it found the card itself, but none of hte 4 drives attatched to it. Boot my old kernel, everytihng detects fine. Build a kernel using the latest GENERIC kernel config, and still l no drives found. Download the 0927 boot.flp, and it too finds no drives on thechain. They all properly identify the card, but none of them can find the drives attatched to it. Any ideas? I'm still running aout, if that has anything to do with the situation (tho' since the bootdisk also failed, I don't really see how) --Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 21:24:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA05529 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 21:24:29 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA05523 for ; Mon, 28 Sep 1998 21:24:25 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id WAA16692; Mon, 28 Sep 1998 22:17:40 -0600 (MDT) Date: Mon, 28 Sep 1998 22:17:40 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809290417.WAA16692@narnia.plutotech.com> To: Jason Tatem cc: scsi@FreeBSD.ORG Subject: Re: CAM Failure? Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: [ Can't find drives ... ] No error messages? Can you try booting with -v and noting any SCSI related (aic7xxx related) messages? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 21:25:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA05654 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 21:25:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nagual.pp.ru (ache.relcom.ru [193.125.20.108]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA05633; Mon, 28 Sep 1998 21:25:11 -0700 (PDT) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.9.1/8.9.1) id IAA00338; Tue, 29 Sep 1998 08:24:54 +0400 (MSD) (envelope-from ache) Message-ID: <19980929082453.A328@nagual.pp.ru> Date: Tue, 29 Sep 1998 08:24:53 +0400 From: "Andrey A. Chernov" To: current@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: ahc & CAM: strange diagnostic Mail-Followup-To: current@freebsd.org, scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i Organization: Biomechanoid Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I often (f.e. on 'sync' command) get this diagnostic after CAM updates: (da0:ahc0:0:0:0): tagged openings now 64 what it means? How to handle it? My config info: ahc0: rev 0x00 int a irq 15 on pci0.8.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI2 device da1: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled da1: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ MTH/SH/HE S-- W-- N+ PEC>+ D A a++ C G>+ QH+(++) 666+>++ Y To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 22:01:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA10345 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 22:01:08 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA10329 for ; Mon, 28 Sep 1998 22:00:57 -0700 (PDT) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.8.8) with ESMTP id VAA17592; Mon, 28 Sep 1998 21:59:52 -0700 (PDT) (envelope-from jkh@time.cdrom.com) To: "Andrey A. Chernov" cc: scsi@FreeBSD.ORG Subject: Re: ahc & CAM: strange diagnostic In-reply-to: Your message of "Tue, 29 Sep 1998 08:24:53 +0400." <19980929082453.A328@nagual.pp.ru> Date: Mon, 28 Sep 1998 21:59:51 -0700 Message-ID: <17588.907045191@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Killed bogus cross-post; just in -scsi where it belongs now] > I often (f.e. on 'sync' command) get this diagnostic after CAM updates: > > (da0:ahc0:0:0:0): tagged openings now 64 It means that it's decided your drive isn't capable of taking so many tags. It's a normal side-effect of CAM's ability to "throttle back" as necessary since the abilities of many drives often don't match what they claim to be able to do. > what it means? How to handle it? Relax and ignore it. :) Maybe it should be made part of bootverbose now since I have seen several messages about this from users needlessly freaking out about the message. I happen to like the message since it tells me which drives to perhaps avoid in the future if it drops to a really low number, but I can see how it would make other people scream and run to the tech support lines. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 22:20:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA13754 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 22:20:51 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA13668 for ; Mon, 28 Sep 1998 22:20:21 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id XAA16803; Mon, 28 Sep 1998 23:13:32 -0600 (MDT) Date: Mon, 28 Sep 1998 23:13:32 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809290513.XAA16803@narnia.plutotech.com> To: "Andrey A. Chernov" cc: scsi@FreeBSD.ORG Subject: Re: ahc & CAM: strange diagnostic Newsgroups: pluto.freebsd.scsi In-Reply-To: <19980929082453.A328@nagual.pp.ru> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article <19980929082453.A328@nagual.pp.ru> you wrote: > I often (f.e. on 'sync' command) get this diagnostic after CAM updates: > > (da0:ahc0:0:0:0): tagged openings now 64 > > what it means? How to handle it? It means that the system determined that your drive can only handle 64 concurrent transactions at a time. The system properly handled the situation by reducing the number of transactions it will send to the device at a time. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Sep 28 22:20:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA13757 for freebsd-scsi-outgoing; Mon, 28 Sep 1998 22:20:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA13692; Mon, 28 Sep 1998 22:20:28 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id XAA20433; Mon, 28 Sep 1998 23:20:08 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199809290520.XAA20433@panzer.plutotech.com> Subject: Re: ahc & CAM: strange diagnostic In-Reply-To: <19980929082453.A328@nagual.pp.ru> from "Andrey A. Chernov" at "Sep 29, 98 08:24:53 am" To: ache@nagual.pp.ru (Andrey A. Chernov) Date: Mon, 28 Sep 1998 23:20:08 -0600 (MDT) Cc: current@FreeBSD.ORG, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (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 Andrey A. Chernov wrote... > I often (f.e. on 'sync' command) get this diagnostic after CAM updates: > > (da0:ahc0:0:0:0): tagged openings now 64 > > what it means? How to handle it? That means your drive probably has space for 64 transactions at a time. Congratulations, you've got a decent drive. :) You don't do anything about it. It's merely informational. If it goes down to zero, though, that would indicate a buggy drive. (one that continually sends queue full, or doesn't handle tagged queueing well, or something like that) 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 Sep 29 07:15:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA28489 for freebsd-scsi-outgoing; Tue, 29 Sep 1998 07:15:08 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA28434; Tue, 29 Sep 1998 07:14:33 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from yggdrasil.ifi.uio.no (2602@yggdrasil.ifi.uio.no [129.240.64.182]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id QAA02735; Tue, 29 Sep 1998 16:11:41 +0200 (MET DST) Received: (from dag-erli@localhost) by yggdrasil.ifi.uio.no ; Tue, 29 Sep 1998 16:11:40 +0200 (MET DST) Mime-Version: 1.0 To: "Andrey A. Chernov" Cc: current@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahc & CAM: strange diagnostic References: <19980929082453.A328@nagual.pp.ru> Organization: University of Oslo, Department of Informatics X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-other-addresses: 'finger dag-erli@ifi.uio.no' for a list X-disclaimer-1: The views expressed in this article are mine alone, and do X-disclaimer-2: not necessarily coincide with those of any organisation or X-disclaimer-3: company with which I am or have been affiliated. X-Stop-Spam: http://www.cauce.org/ From: dag-erli@ifi.uio.no (Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 29 Sep 1998 16:11:39 +0200 In-Reply-To: "Andrey A. Chernov"'s message of "Tue, 29 Sep 1998 08:24:53 +0400" Message-ID: Lines: 11 X-Mailer: Gnus v5.6.44/Emacs 20.3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id HAA28451 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Andrey A. Chernov" writes: > (da0:ahc0:0:0:0): tagged openings now 64 > [...] > da0: Fixed Direct Access SCSI2 device OK, that's it. I'm definitely dumping Quantum and Seagate and going for IBM instead. DES -- Dag-Erling Smørgrav - dag-erli@ifi.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Sep 29 17:10:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11930 for freebsd-scsi-outgoing; Tue, 29 Sep 1998 17:10:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from vision.vc3.com (vision.vc3.com [209.12.161.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA11924 for ; Tue, 29 Sep 1998 17:10:20 -0700 (PDT) (envelope-from tatemj@vision.vc3.com) Received: from localhost (tatemj@localhost) by vision.vc3.com (8.8.7/8.8.5) with SMTP id UAA07122; Tue, 29 Sep 1998 20:09:59 -0400 Date: Tue, 29 Sep 1998 20:09:59 -0400 (EDT) From: Jason Tatem To: "Justin T. Gibbs" cc: scsi@FreeBSD.ORG Subject: Re: CAM Failure? In-Reply-To: <199809290417.WAA16692@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 Well crap...looks like i'm just a friggin' idiot....nobody told me that the drives get listed at the very end of the boot process now....when my system stops unexpectedly for a few moments, i get worried....i kept rebooting before it picked up the friggin' drives! Consider this a big "Never mind" --Jason ----------------------------------------------------------------- Jason Tatem "What you want is irrelevant. VC3, Inc. What you have chosen is at hand!" tatemj@vc3.com --Spock, Star Trek VI ----------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Sep 29 19:32:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04107 for freebsd-scsi-outgoing; Tue, 29 Sep 1998 19:32:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA04095; Tue, 29 Sep 1998 19:32:05 -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 EAA12157; Wed, 30 Sep 1998 04:31:50 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (VMailer, from userid 101) id 2CA121430; Wed, 30 Sep 1998 01:14:32 +0200 (CEST) Date: Wed, 30 Sep 1998 01:14:32 +0200 From: Ollivier Robert To: current@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahc & CAM: strange diagnostic Message-ID: <19980930011432.B15508@keltia.freenix.fr> Mail-Followup-To: current@FreeBSD.ORG, scsi@FreeBSD.ORG References: <19980929082453.A328@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.94.4i In-Reply-To: =?iso-8859-1?Q?=3Cxzp90j31010=2Efsf=40yggdrasil=2Eifi=2Euio=2Eno=3E=3B_f?= =?iso-8859-1?Q?rom_Dag-Erling_C=2E_Sm=F8rgrav__on_Tue=2C_Sep_29=2C_1998_?= =?iso-8859-1?Q?at_04:11:39PM_+0200?= X-Operating-System: FreeBSD 3.0-BETA/ELF ctm#4660 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Dag-Erling C. Smørgrav : > OK, that's it. I'm definitely dumping Quantum and Seagate and going > for IBM instead. To be honest with Quantum, my brand new Viking II is blazingly fast compared to my trusty DCAS and supports the same # of transactions (64). My 4 GB DCAS runs at 9 MB/s max whereas the Viking is doing 13 MB/s. I haven't tried the new 7200 rpm DDRS IBM drives but I guess they're good too. 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-BETA #0: Sun Sep 27 14:53:13 CEST 1998 roberto@tara.freenix.org:/src/src/sys/compile/TARA [...] da0 at ahc0 bus 0 target 6 lun 0 da0: Fixed Direct Access SCSI2 device da0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) 203 [1:09] roberto@tara:~> dmesg | grep "tagged openings" (da0:ahc0:0:6:0): tagged openings now 63 -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-BETA #0: Sat Sep 19 23:38:25 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 03:13:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA06618 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 03:13:31 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from onizuka.vmunix.org (onizuka.vmunix.org [194.97.84.67]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA06594 for ; Wed, 30 Sep 1998 03:13:24 -0700 (PDT) (envelope-from torstenb@vmunix.org) Received: by onizuka.vmunix.org via sendmail with stdio id for ; Wed, 30 Sep 1998 12:13:04 +0200 (CEST) Message-Id: Subject: Command Linking To: scsi@FreeBSD.ORG Date: Wed, 30 Sep 1998 12:13:04 +0200 (CEST) Reply-To: torstenb@vmunix.org From: torstenb@FreeBSD.ORG (Torsten Blum) X-Mailer: ELM [version 2.4ME+ PL40 (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 Hi, I started writing a firmware-upgrade utility for the Tandberg MLR1 and MLR3 drives when I saw that Tandberg made their Programmers Manual to the public (http://www.tdata.no/support/doc_manuals.html). Well, I can read the firmware from the drive and write it to a file. The problem starts when I start to write the new firmware. Due to the physio problem I have to upload the firmware in 64k parts with the WRITE BUFFER command. After each WRITE BUFFER the drive sends a MSG_LINK_CMD_COMPLETE (0x0a) and the scsi system can't handle it: ahc1:A:5: Warning - unknown message received from target (0xa). SEQ_FLAGS == 0xd2. Rejecting Unexpected busfree. LASTPHASE == 0xa0 SEQADDR == 0x99 Tandberg's SCSI Interface Specifications for the MLR1 contains the following description: 3.2.1.4 Command Linking Normally the Drive goes to the BUS FREE phase after a successful command completion. The Drive transfers the GOOD status byte and the COMMAND COMPLETED messages before entering the BUS FREE phase. If the initiator wants the Drive to go directly to a new COMMAND phase after successful command completion, the initiator has to link the commands. The Drive than transfers an INTERMEDIATE status byte followed by a LINKED COMMAND COMPLETE (or LINKED COMMAND COMPLETE W/FLAG) message byte before entering the COMMAND phase. The Drive expects immediately the transfer of a new command. [...] Just adding "cmp A,MSG_LINK_CMD_COMPLETE je mesgin_done;" to p_mesgin: in aic7xxx.seq doesnt help because (according to the Tandberg SCSI Cmd Specs) the command phase sequencing needs to me modified. Any help is appreciated -tb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 06:06:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA27394 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 06:06:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA27323; Wed, 30 Sep 1998 06:06:08 -0700 (PDT) (envelope-from dag-erli@ifi.uio.no) Received: from grjottunagard.ifi.uio.no (2602@grjottunagard.ifi.uio.no [129.240.64.131]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id PAA17615; Wed, 30 Sep 1998 15:05:50 +0200 (MET DST) Received: (from dag-erli@localhost) by grjottunagard.ifi.uio.no ; Wed, 30 Sep 1998 15:05:49 +0200 (MET DST) Mime-Version: 1.0 To: Ollivier Robert Cc: current@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahc & CAM: strange diagnostic References: <19980929082453.A328@nagual.pp.ru> <19980930011432.B15508@keltia.freenix.fr> Organization: University of Oslo, Department of Informatics X-url: http://www.stud.ifi.uio.no/~dag-erli/ X-other-addresses: 'finger dag-erli@ifi.uio.no' for a list X-disclaimer-1: The views expressed in this article are mine alone, and do X-disclaimer-2: not necessarily coincide with those of any organisation or X-disclaimer-3: company with which I am or have been affiliated. X-Stop-Spam: http://www.cauce.org/ From: dag-erli@ifi.uio.no (Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?= ) Date: 30 Sep 1998 15:05:49 +0200 In-Reply-To: Ollivier Robert's message of "Wed, 30 Sep 1998 01:14:32 +0200" Message-ID: Lines: 22 X-Mailer: Gnus v5.6.44/Emacs 20.3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id GAA27382 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ollivier Robert writes: > According to Dag-Erling C. Smørgrav : > > OK, that's it. I'm definitely dumping Quantum and Seagate and going > > for IBM instead. > To be honest with Quantum, my brand new Viking II is blazingly fast > compared to my trusty DCAS and supports the same # of transactions (64). My > 4 GB DCAS runs at 9 MB/s max whereas the Viking is doing 13 MB/s. You're not comparing equivalent models... IBM's closest match for the Viking II is the newer DDRS. I haven't tested one, but the specs are very close (7.5 ms nominal average seek, 512 kB cache, 7200 rpm) Surprisingly enough, in Norway the Quantum Viking II is approx. $50 cheaper than the IBM UltraStar 9ES aka DDRS-39130W. I say surprisingly because IBM drives are usually cheaper. One more argument in favor of IBM disks is that they reputedly run cooler and quieter than Quantum or Seagate disks. DES -- Dag-Erling Smørgrav - dag-erli@ifi.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 08:20:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA18011 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 08:20:24 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from opus.cts.cwu.edu (opus.cts.cwu.edu [198.104.92.71]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA18001 for ; Wed, 30 Sep 1998 08:20:19 -0700 (PDT) (envelope-from skynyrd@opus.cts.cwu.edu) Received: from localhost (skynyrd@localhost) by opus.cts.cwu.edu (8.9.1/8.9.1) with ESMTP id IAA24834; Wed, 30 Sep 1998 08:19:51 -0700 (PDT) Date: Wed, 30 Sep 1998 08:19:51 -0700 (PDT) From: Chris Timmons To: "Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?=" cc: scsi@FreeBSD.ORG Subject: IBM's cool disks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I really have to agree here. I couldn't believe the difference between IBM DDRS-34560W and the ultra-wide 'cudas and atlas-I,II's that I have. I would be skeptical of the awesome viking-II's until they've been around a while and their firmware is proven reliable. My personal history with Quantum has been firmware hell. -c On 30 Sep 1998, Dag-Erling C. [iso-8859-1] Smørgrav wrote: > One more argument in favor of IBM disks is that they reputedly run > cooler and quieter than Quantum or Seagate disks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 08:43:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA20743 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 08:43:16 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA20729 for ; Wed, 30 Sep 1998 08:43:14 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id JAA24139; Wed, 30 Sep 1998 09:36:14 -0600 (MDT) Date: Wed, 30 Sep 1998 09:36:14 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809301536.JAA24139@narnia.plutotech.com> To: torstenb@vmunix.org cc: scsi@FreeBSD.ORG Subject: Re: Command Linking Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > Well, I can read the firmware from the drive and write it to a file. The > problem starts when I start to write the new firmware. Due to the physio > problem I have to upload the firmware in 64k parts with the WRITE BUFFER > command. After each WRITE BUFFER the drive sends a MSG_LINK_CMD_COMPLETE > (0x0a) and the scsi system can't handle it: Do you have to load the firmware using a series of linked commands instead of unlinked commands? I had no intention of supporting this feature in the aic7xxx driver and it would probably require some additional tweaking to the SCSI transport layer to make it work. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 10:56:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA13314 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 10:56:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA13261 for ; Wed, 30 Sep 1998 10:56:06 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id LAA24440; Wed, 30 Sep 1998 11:49:12 -0600 (MDT) Date: Wed, 30 Sep 1998 11:49:12 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809301749.LAA24440@narnia.plutotech.com> To: Karl Denninger cc: scsi@FreeBSD.ORG Subject: Re: Long IDE probes? User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > SCSI devices similarly are probed by the adapter BIOS. Again, there is no > reason for the long wait that I can fathom. Then you don't fathom SCSI. When the system comes up, it resets the SCSI bus to ensure that all previously negotiated transfer negotiations have been nullified. Some devices take longer than others to respond after a bus reset. If you are dealing with modern disks, you only need to wait ~100ms. If you are dealing with tape drives, some cdrom drives, or older devices, you must wait longer or risk "not seeing" the device. The bus settle delay is easily configurable so that people with nice devices can shorten it, but the default delay in GENERIC is there for a very good reason. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 10:59:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA14227 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 10:59:20 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA14220 for ; Wed, 30 Sep 1998 10:59:18 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.1/8.8.2) id MAA04363; Wed, 30 Sep 1998 12:58:58 -0500 (CDT) Message-ID: <19980930125858.B4304@Denninger.Net> Date: Wed, 30 Sep 1998 12:58:58 -0500 From: Karl Denninger To: "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Re: Long IDE probes? References: <199809301749.LAA24440@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199809301749.LAA24440@narnia.plutotech.com>; from Justin T. Gibbs on Wed, Sep 30, 1998 at 11:49:12AM -0600 Organization: Karl's Sushi and Packet Smashers Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 30, 1998 at 11:49:12AM -0600, Justin T. Gibbs wrote: > > SCSI devices similarly are probed by the adapter BIOS. Again, there is no > > reason for the long wait that I can fathom. > > Then you don't fathom SCSI. When the system comes up, it resets the > SCSI bus to ensure that all previously negotiated transfer negotiations > have been nullified. Some devices take longer than others to respond > after a bus reset. If you are dealing with modern disks, you only need > to wait ~100ms. If you are dealing with tape drives, some cdrom drives, > or older devices, you must wait longer or risk "not seeing" the device. > The bus settle delay is easily configurable so that people with nice > devices can shorten it, but the default delay in GENERIC is there for > a very good reason. > > -- > Justin The default was recently increased (read: made longer) - like doubled. I *KNOW* that things like Exabytes "go away" for short periods of time after a bus reset. But we're talking about *defaults* here, and modern disks and tape drives, while they may kvetch internally for a while before they'll generally be useful, but virtually all will respond to an inquiry within 3-5 seconds - maximum. -- -- Karl Denninger (karl@denninger.net) http://www.mcs.net/~karl 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 Wed Sep 30 11:19:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17953 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 11:19:54 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA17948 for ; Wed, 30 Sep 1998 11:19:52 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id MAA14837; Wed, 30 Sep 1998 12:19:34 -0600 (MDT) Message-Id: <199809301819.MAA14837@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Karl Denninger cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: Long IDE probes? In-reply-to: Your message of "Wed, 30 Sep 1998 12:58:58 CDT." <19980930125858.B4304@Denninger.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Sep 1998 12:13:04 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >The default was recently increased (read: made longer) - like doubled. The delay in the generic kernel has always been 15 seconds. The default with no delay specified has always been 2 seconds. CAM effectively reduces this delay over the old SCSI code as all bus delays during the initial prove phase occur in parallel. >I *KNOW* that things like Exabytes "go away" for short periods of time >after a bus reset. But we're talking about *defaults* here, and modern >disks and tape drives, while they may kvetch internally for a while before >they'll generally be useful, but virtually all will respond to an inquiry >within 3-5 seconds - maximum. Not everyone who uses FreeBSD has "modern devices". Not everyone who uses FreeBSD knows that their devices will only work with a longish delay. Are you saying that we should lose the ability to install on these machines simply because you, a user that knows how to modify this behavior, finds the default behavior annoying? -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 11:29:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA20672 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 11:29:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA20659 for ; Wed, 30 Sep 1998 11:29:51 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.1/8.8.2) id NAA04521; Wed, 30 Sep 1998 13:29:34 -0500 (CDT) Message-ID: <19980930132933.B4481@Denninger.Net> Date: Wed, 30 Sep 1998 13:29:33 -0500 From: Karl Denninger To: "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Re: Long IDE probes? References: <19980930125858.B4304@Denninger.Net> <199809301819.MAA14837@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199809301819.MAA14837@pluto.plutotech.com>; from Justin T. Gibbs on Wed, Sep 30, 1998 at 12:13:04PM -0600 Organization: Karl's Sushi and Packet Smashers Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 30, 1998 at 12:13:04PM -0600, Justin T. Gibbs wrote: > >The default was recently increased (read: made longer) - like doubled. > > The delay in the generic kernel has always been 15 seconds. The default > with no delay specified has always been 2 seconds. CAM effectively reduces > this delay over the old SCSI code as all bus delays during the initial > prove phase occur in parallel. > > >I *KNOW* that things like Exabytes "go away" for short periods of time > >after a bus reset. But we're talking about *defaults* here, and modern > >disks and tape drives, while they may kvetch internally for a while before > >they'll generally be useful, but virtually all will respond to an inquiry > >within 3-5 seconds - maximum. > > Not everyone who uses FreeBSD has "modern devices". Not everyone > who uses FreeBSD knows that their devices will only work with a longish > delay. Are you saying that we should lose the ability to install on > these machines simply because you, a user that knows how to modify this > behavior, finds the default behavior annoying? > > -- > Justin Justin, quit being a pompous ass and lose the attitude. Its uncalled for. You and I both know damn well that to install you need ONLY, WORST CASE: 1. A floppy that works (to boot from) 2. A CDROM 3. A disk Some folks need only a floppy, disk, and network card - they load off the network. Kvetching about how someone's 1980's scanner or ancient tape drive won't come up under GENERIC on initial boot is both pointless and inappropriate, given that you *know* these facts to be true, and that for every one of those people there are a dozen others who can't boot without manual override of GENERIC's defaults due to ISA bus conflicts. Don't give me crap about how "the defaults must accomodate everyone". They don't RIGHT NOW and FreeBSD has NEVER had that as a criteria for driver probe behavior. I have loaded FreeBSD on a dozen machines over the last two years in which the default network card settings in GENERIC - over which I wanted to load the system - were in conflict with other found devices and as such I had to MANUALLY go into the config screen and reset them. There are a half-dozen machines in MCSNet's computer room that have ISA cards in them that simply WILL NOT run GENERIC without manual intervention - not because the devices aren't there, but because the ONLY possible combination of IRQs and shared RAM addresses aren't the pre-ordained set of ones which are in GENERIC's idea of where devices have to be in order to show up. If you want to make a point about ancient hardware, then explain why in the heck was CAM integrated without ALL the legacy SCSI devices being supported? Don't get me wrong - I'm not bitching about the CAM integration - that was the right choice. It was just as much right as the current settings for bus settling time and probe delays in the IDE code are wrong. -- -- Karl Denninger (karl@denninger.net) http://www.mcs.net/~karl 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 Wed Sep 30 11:51:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA24478 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 11:51:17 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA24460 for ; Wed, 30 Sep 1998 11:51:04 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id MAA16318; Wed, 30 Sep 1998 12:50:44 -0600 (MDT) Message-Id: <199809301850.MAA16318@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Karl Denninger cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: Long IDE probes? In-reply-to: Your message of "Wed, 30 Sep 1998 13:29:33 CDT." <19980930132933.B4481@Denninger.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Sep 1998 12:44:13 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Not everyone who uses FreeBSD has "modern devices". Not everyone >> who uses FreeBSD knows that their devices will only work with a longish >> delay. Are you saying that we should lose the ability to install on >> these machines simply because you, a user that knows how to modify this >> behavior, finds the default behavior annoying? >> >> -- >> Justin > >Justin, quit being a pompous ass and lose the attitude. Its uncalled for. Ahemmm. >You and I both know damn well that to install you need ONLY, WORST CASE: > 1. A floppy that works (to boot from) > 2. A CDROM > 3. A disk You can also install off of tape, a CD-R that can look like a CDROM, an Optical disk, etc. etc. Sysinstal has allowed for this for some time. >Kvetching about how someone's 1980's scanner or ancient tape drive won't >come up under GENERIC on initial boot is both pointless and inappropriate, >given that you *know* these facts to be true I'm talking about old CDROM drives, CD-Rs and OD disks as well as tapes. Not everyone performs CDROM or network installs. Documentation exists for tape installs and for people that have unconnected machines at home, it should remain an option. >, and that for every one of >those people there are a dozen others who can't boot without manual >override of GENERIC's defaults due to ISA bus conflicts. When did this become the topic of our discussion? I would also clasify this as buggy behavior since many of these devices can be probed safely without user intervention. I would also argue that this kind of failure is both better documented in the install notes and more likely to be expected by the user than a failure caused by the SCSI or IDE settle delay. >They don't RIGHT NOW and FreeBSD has NEVER had that as a criteria for >driver probe behavior. Does this mean that we shouldn't have that criteria? This is the criteria I used for all of the ISA probes for the new CAM drivers. >If you want to make a point about ancient hardware, then explain why in the >heck was CAM integrated without ALL the legacy SCSI devices being supported? But all legacy SCSI devices are being supported by CAM (at least that is the intention barring bugs). We don't support legacy SCSI controllers due to lack of time and documentation. In other words, the 3.0R documentation will clearly state that we only support cards X, Y, and Z. It will also say that disks, cdroms, scanners, tapes, and worm devices are supported. The user will understand if their wd7000 controller isn't found during install because the documentation does say that it is supported, but they will be perplexed if their CDROM drive is not found when attached to a supported controller. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 12:11:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA29484 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 12:11:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA29477 for ; Wed, 30 Sep 1998 12:11:15 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.1/8.8.2) id OAA04683; Wed, 30 Sep 1998 14:10:56 -0500 (CDT) Message-ID: <19980930141056.A4656@Denninger.Net> Date: Wed, 30 Sep 1998 14:10:56 -0500 From: Karl Denninger To: "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Re: Long IDE probes? References: <19980930132933.B4481@Denninger.Net> <199809301850.MAA16318@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199809301850.MAA16318@pluto.plutotech.com>; from Justin T. Gibbs on Wed, Sep 30, 1998 at 12:44:13PM -0600 Organization: Karl's Sushi and Packet Smashers Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 30, 1998 at 12:44:13PM -0600, Justin T. Gibbs wrote: > >You and I both know damn well that to install you need ONLY, WORST CASE: > > 1. A floppy that works (to boot from) > > 2. A CDROM > > 3. A disk > > You can also install off of tape, a CD-R that can look like a CDROM, > an Optical disk, etc. etc. Sysinstal has allowed for this for some > time. Uh, Justin, you have to get the bits on the media ;-) The point I'm making here is that anything reasonably current in the SCSI world will respond to an INQUIRY - at least - within specs. If it doesn't then its broken. We should endeavor to fix that, yes, but at what price? Where is the line drawn? That's the issue here - we make everyone wait for 2% of users. Why not put this thing in the kernel config screen, and default it to the SCSI standard values. If someone needs to tune it (we can document that) then tune it. But for the rest of us, its a LOT faster. The same holds true for IDE. Follow the specs and give people a workaround if possible from the boot screens. The kernel startup for the boot floppy already recommends that you go through the config screens, so this is not an impossible goal by any stretch. > >Kvetching about how someone's 1980's scanner or ancient tape drive won't > >come up under GENERIC on initial boot is both pointless and inappropriate, > >given that you *know* these facts to be true > > I'm talking about old CDROM drives, CD-Rs and OD disks as well as tapes. There are very few of those which are (1) in service, (2) don't respond to INQUIRY within specs after a RESET, and (3) are actually needed to *boot and load*. For those which are, a parameter in the kernel config screen will allow installation to proceed. > Not everyone performs CDROM or network installs. Documentation exists > for tape installs and for people that have unconnected machines at home, > it should remain an option. An option, yes. But not the default. > >They don't RIGHT NOW and FreeBSD has NEVER had that as a criteria for > >driver probe behavior. > > Does this mean that we shouldn't have that criteria? This is the > criteria I used for all of the ISA probes for the new CAM drivers. You can't possibly get there from here, since there are dozens of permutations and you can't know what is and isn't possible in a given machine with a given set of boards. > >If you want to make a point about ancient hardware, then explain why in the > >heck was CAM integrated without ALL the legacy SCSI devices being supported? > > But all legacy SCSI devices are being supported by CAM (at least that is > the intention barring bugs). Fine. Make it an option. > The user will understand if their wd7000 controller > isn't found during install because the documentation does say that it is > supported, but they will be perplexed if their CDROM drive is not found > when attached to a supported controller. > > -- > Justin Again, document that devices which are non-complient may need a longer timeout, and put that parameter in the kernel config screen. Don't penalize the rest of the users on every boot (many of who have NO IDEA how to build kernels and fix this) because 2% of the users have hardware which is non-complient with the SCSI (or IDE) standards. For a server this is no big deal. For a user with a laptop or other machine which is booted when used and turned off when not this is a BIG deal; "time to be up and running from a cold power-on" is an issue. -- -- Karl Denninger (karl@denninger.net) http://www.mcs.net/~karl 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 Wed Sep 30 12:32:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03270 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 12:32:43 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from onizuka.vmunix.org (onizuka.vmunix.org [194.97.84.67]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03236 for ; Wed, 30 Sep 1998 12:32:30 -0700 (PDT) (envelope-from torstenb@vmunix.org) Received: by onizuka.vmunix.org via sendmail with stdio id for ; Wed, 30 Sep 1998 21:32:03 +0200 (CEST) Message-Id: From: torstenb@vmunix.org (Torsten Blum) Subject: Re: Command Linking In-Reply-To: <199809301536.JAA24139@narnia.plutotech.com> from "Justin T. Gibbs" at "Sep 30, 98 09:36:14 am" To: gibbs@narnia.plutotech.com (Justin T. Gibbs) Date: Wed, 30 Sep 1998 21:32:03 +0200 (CEST) Cc: scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (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 Justin T. Gibbs wrote: > > Well, I can read the firmware from the drive and write it to a file. The > > problem starts when I start to write the new firmware. Due to the physio > > problem I have to upload the firmware in 64k parts with the WRITE BUFFER > > command. After each WRITE BUFFER the drive sends a MSG_LINK_CMD_COMPLETE > > (0x0a) and the scsi system can't handle it: > > Do you have to load the firmware using a series of linked commands > instead of unlinked commands? Yes, the alternative is one write buffer for the whole firmware image, which doesnt work due to the 64k physio limitation. > I had no intention of supporting this feature in the aic7xxx driver Hm, why ? -tb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 12:58:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA09744 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 12:58:15 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA09632 for ; Wed, 30 Sep 1998 12:58:05 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id NAA21005; Wed, 30 Sep 1998 13:57:44 -0600 (MDT) Message-Id: <199809301957.NAA21005@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Karl Denninger cc: "Justin T. Gibbs" , scsi@FreeBSD.ORG Subject: Re: Long IDE probes? In-reply-to: Your message of "Wed, 30 Sep 1998 14:10:56 CDT." <19980930141056.A4656@Denninger.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Sep 1998 13:51:13 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >On Wed, Sep 30, 1998 at 12:44:13PM -0600, Justin T. Gibbs wrote: >> >You and I both know damn well that to install you need ONLY, WORST CASE: >> > 1. A floppy that works (to boot from) >> > 2. A CDROM >> > 3. A disk >> >> You can also install off of tape, a CD-R that can look like a CDROM, >> an Optical disk, etc. etc. Sysinstal has allowed for this for some >> time. > >Uh, Justin, you have to get the bits on the media ;-) Not necessarily under FreeBSD. I once installed FreeBSD using a floppy set generated on an HP-UX machine. >The point I'm making here is that anything reasonably current in the SCSI >world will respond to an INQUIRY - at least - within specs. If it doesn't >then its broken. We should endeavor to fix that, yes, but at what price? > >Where is the line drawn? That's the issue here - we make everyone wait for >2% of users. My main concern is about system installation and tech support load. The defaults on the installation media should be extremely conservative. >Why not put this thing in the kernel config screen, and >default it to the SCSI standard values. If someone needs to tune it (we >can document that) then tune it. But for the rest of us, its a LOT faster. 1) The technology to put it in the kernel config screen is not quite there yet. This is another item for the generic "fix FreeBSD's configuration system" task that comes post 3.0R. 2) Even if you had it in the configuration screen I would still argue, from a tech support load and usability standpoint, that the default should be conservative. 3) Post install, there should be a series of options to "better tune your system". This allows you to educate the user and give them the option of experimenting with different system tweaks, while falling back to the previous settings if a failure occurs. >Follow the specs and give people a workaround if possible from the boot >screens. The kernel startup for the boot floppy already recommends that >you go through the config screens, so this is not an impossible goal by >any stretch. Wrong. Joe new user looks at the configuration screen, decides that it's too complicated, and goes with the defaults. The system doesn't see his SCSI devices. Why? He doesn't know. Maybe this FreeBSD thing is simply broken. Linux worked okay. So did NT. Hmmm. [ sound of CDROM going into trash bin ]. >> >Kvetching about how someone's 1980's scanner or ancient tape drive won't >> >come up under GENERIC on initial boot is both pointless and inappropriate, >> >given that you *know* these facts to be true >> >> I'm talking about old CDROM drives, CD-Rs and OD disks as well as tapes. > >There are very few of those which are (1) in service, Perhaps in your environment. >(2) don't respond to INQUIRY within specs after a RESET, and I am constantly amazed at the number of devices that come on the market every year that don't follow the spec. >(3) are actually needed to *boot and load*. >From a tech support standpoint, having a usable system after installation is also important. >For those which are, a parameter in the kernel config screen will allow >installation to proceed. Assuming they know that this is the parameter to change. >> Not everyone performs CDROM or network installs. Documentation exists >> for tape installs and for people that have unconnected machines at home, >> it should remain an option. > >An option, yes. But not the default. It is a supported installation method. There is no optional or default about it. >> >They don't RIGHT NOW and FreeBSD has NEVER had that as a criteria for >> >driver probe behavior. >> >> Does this mean that we shouldn't have that criteria? This is the >> criteria I used for all of the ISA probes for the new CAM drivers. > >You can't possibly get there from here, since there are dozens of >permutations and you can't know what is and isn't possible in a given >machine with a given set of boards. Win95/98 can do it on 99% of all machines. That satisfies my definition of possible. >> But all legacy SCSI devices are being supported by CAM (at least that is >> the intention barring bugs). > >Fine. Make it an option. It is a kernel option. >Again, document that devices which are non-complient may need a longer >timeout, and put that parameter in the kernel config screen. > >Don't penalize the rest of the users on every boot (many of who have NO IDEA >how to build kernels and fix this) because 2% of the users have hardware >which is non-complient with the SCSI (or IDE) standards. If we provide an option via user config to limit the SCSI delay (won't happen for 3.0R) then the people who are annoyed by the delay can experiment with lower settings without rebuilding their kernel. If you say that most users that can't build a kernel will not be able to find this option, then you've made my point about novice installs for me. Installation must be conservative as 50% of the people that install for the first time will not read the documentation until after they've completed the install, if ever. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 13:03:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA10891 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 13:03:08 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA10871 for ; Wed, 30 Sep 1998 13:03:02 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id OAA22127; Wed, 30 Sep 1998 14:02:41 -0600 (MDT) Message-Id: <199809302002.OAA22127@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: torstenb@vmunix.org (Torsten Blum) cc: gibbs@plutotech.com (Justin T. Gibbs), scsi@FreeBSD.ORG Subject: Re: Command Linking In-reply-to: Your message of "Wed, 30 Sep 1998 21:32:03 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Sep 1998 13:56:10 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Do you have to load the firmware using a series of linked commands >> instead of unlinked commands? > >Yes, the alternative is one write buffer for the whole firmware image, >which doesnt work due to the 64k physio limitation. We need to make that limitation go away. >> I had no intention of supporting this feature in the aic7xxx driver > >Hm, why ? Because very few, mostly older, devices support it. It doesn't provide any performance benefit if you have a modern controller and device (i.e. any that controller FreeBSD supports and a tape drive with a minimal write buffer). It can also unfairly lock out other devices from using the SCSI bus for long periods of time. None of our peripheral drivers make use of this feature. Adding support into the firmware of the aic7xxx driver is a space issue, but probably possible. Does the drive support loading firmware from tape? > -tb -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 13:11:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12997 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 13:11:09 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Genesis.Denninger.Net (kdhome-2.pr.mcs.net [205.164.6.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12969 for ; Wed, 30 Sep 1998 13:10:57 -0700 (PDT) (envelope-from karl@Genesis.Denninger.Net) Received: (from karl@localhost) by Genesis.Denninger.Net (8.9.1/8.8.2) id PAA04889; Wed, 30 Sep 1998 15:10:39 -0500 (CDT) Message-ID: <19980930151039.A4848@Denninger.Net> Date: Wed, 30 Sep 1998 15:10:39 -0500 From: Karl Denninger To: "Justin T. Gibbs" Cc: scsi@FreeBSD.ORG Subject: Re: Long IDE probes? References: <19980930141056.A4656@Denninger.Net> <199809301957.NAA21005@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199809301957.NAA21005@pluto.plutotech.com>; from Justin T. Gibbs on Wed, Sep 30, 1998 at 01:51:13PM -0600 Organization: Karl's Sushi and Packet Smashers Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 30, 1998 at 01:51:13PM -0600, Justin T. Gibbs wrote: > > >The point I'm making here is that anything reasonably current in the SCSI > >world will respond to an INQUIRY - at least - within specs. If it doesn't > >then its broken. We should endeavor to fix that, yes, but at what price? > > > >Where is the line drawn? That's the issue here - we make everyone wait for > >2% of users. > > My main concern is about system installation and tech support load. The > defaults on the installation media should be extremely conservative. My main concern is that people consider things like this (boot time) to be critical for other than server machines. I personally don't care - First, I leave my FreeBSD machine at home up all the time - its a server (screw NT, I reformatted my last NT Server system and replaced it with FreeBSD + Samba - 3x the I/O speed, all the features, and by God, no more blue screens of death!) However, I'm not the majority (how many people have a network in their home and a laptop in the bedroom for night-time surfing, along with an office with a couple of systems there too!) If I were a novice and loading this on a portable machine, I'd go back to Windows. Why? Because that minute-long extra delay sucks, and I won't want to wait for it on the plane. Nor (in the case of IDE in particular) will I know how to get rid of it. > >Why not put this thing in the kernel config screen, and > >default it to the SCSI standard values. If someone needs to tune it (we > >can document that) then tune it. But for the rest of us, its a LOT faster. > > 1) The technology to put it in the kernel config screen is not quite there > yet. This is another item for the generic "fix FreeBSD's configuration > system" task that comes post 3.0R. Well, ok. > 2) Even if you had it in the configuration screen I would still argue, > from a tech support load and usability standpoint, that the default > should be conservative. No. The default should be to the specs. Put something in the startup screen that says "if you have problems with SCSI devices not showing up, select THIS and then please read the FAQ" and selecting ups the timeout to 15 seconds. > 3) Post install, there should be a series of options to "better tune your > system". This allows you to educate the user and give them the option > of experimenting with different system tweaks, while falling back to the > previous settings if a failure occurs. Yes. > Wrong. Joe new user looks at the configuration screen, decides that it's > too complicated, and goes with the defaults. The system doesn't see his > SCSI devices. Why? He doesn't know. Maybe this FreeBSD thing is simply > broken. Linux worked okay. So did NT. Hmmm. [ sound of CDROM going > into trash bin ]. Not if Joe New User has a screen starting him in the face that says "If your disk and CDROM don't show up, hit " > >(2) don't respond to INQUIRY within specs after a RESET, and > > I am constantly amazed at the number of devices that come on the > market every year that don't follow the spec. On this issue? C'mon Justin - I know of one really major example - old Exabyte 8200s. > >(3) are actually needed to *boot and load*. > > >From a tech support standpoint, having a usable system after installation > is also important. Yep. Which is why the "SELECT HERE" option is the right one. > It is a supported installation method. There is no optional or default > about it. Non-complient devices are "supported"? They may work, but "supported"?! > >You can't possibly get there from here, since there are dozens of > >permutations and you can't know what is and isn't possible in a given > >machine with a given set of boards. > > Win95/98 can do it on 99% of all machines. That satisfies my definition > of possible. But its not there today Justin. FreeBSD may some day get there. It may also not get there. Right now its massively not there for anyone who has ISA bus cards in their machine. PCI makes it easy, really. But if you have ISA cards in the system the story changes quite a bit. > >Fine. Make it an option. > > It is a kernel option. The default is wrong. > >Don't penalize the rest of the users on every boot (many of who have NO IDEA > >how to build kernels and fix this) because 2% of the users have hardware > >which is non-complient with the SCSI (or IDE) standards. > > If we provide an option via user config to limit the SCSI delay (won't > happen for 3.0R) then the people who are annoyed by the delay can > experiment with lower settings without rebuilding their kernel. If you say > that most users that can't build a kernel will not be able to find this > option, then you've made my point about novice installs for me. No. Most novices can read. Most novices have no idea how to use "vi" to edit the config file and rebuild a kernel. > Installation must be conservative as 50% of the people that install for the > first time will not read the documentation until after they've completed > the install, if ever. Installation should provide options for people who may have non-complient devices. The rest of the user population, who must be assumed to be just as incapable of kernel building and such, should not be penalized to cover the 1% cases. Unless, of course, the intent is to make FreeBSD only a "hackers" OS. -- -- Karl Denninger (karl@denninger.net) http://www.mcs.net/~karl 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 Wed Sep 30 14:36:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA02326 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 14:36:46 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA02270 for ; Wed, 30 Sep 1998 14:36:33 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA19353 (5.67b/IDA-1.5); Wed, 30 Sep 1998 23:28:23 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id VAA02620; Wed, 30 Sep 1998 21:36:06 +0200 (CEST) From: Wilko Bulte Message-Id: <199809301936.VAA02620@yedi.iaf.nl> Subject: Re: Long IDE probes? In-Reply-To: <199809301850.MAA16318@pluto.plutotech.com> from "Justin T. Gibbs" at "Sep 30, 98 12:44:13 pm" To: gibbs@plutotech.com (Justin T. Gibbs) Date: Wed, 30 Sep 1998 21:36:06 +0200 (CEST) Cc: karl@denninger.net, gibbs@plutotech.com, 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+ PL38 (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... > >> Not everyone who uses FreeBSD has "modern devices". Not everyone > >> who uses FreeBSD knows that their devices will only work with a longish > >> delay. Are you saying that we should lose the ability to install on > >> these machines simply because you, a user that knows how to modify this > >> behavior, finds the default behavior annoying? > >> > >> -- > >> Justin > > > >Justin, quit being a pompous ass and lose the attitude. Its uncalled for. > > Ahemmm. > > >You and I both know damn well that to install you need ONLY, WORST CASE: > > 1. A floppy that works (to boot from) > > 2. A CDROM > > 3. A disk > > You can also install off of tape, a CD-R that can look like a CDROM, > an Optical disk, etc. etc. Sysinstal has allowed for this for some > time. I for one once tried an install on a 5.25" MO drive. Works. But needs reasonably high timeouts. > >Kvetching about how someone's 1980's scanner or ancient tape drive won't > >come up under GENERIC on initial boot is both pointless and inappropriate, > >given that you *know* these facts to be true > > I'm talking about old CDROM drives, CD-Rs and OD disks as well as tapes. > Not everyone performs CDROM or network installs. Documentation exists > for tape installs and for people that have unconnected machines at home, > it should remain an option. Things that are not broken should be left alone. There is no reason whatsoever to assume people have PII-1Ghz, 12000 rpm 18Gb disks etc. Justin is absolutely right in having a conservative GENERIC kernel. If people are too lazy to build a custom kernel that is their fault. And theirs alone. > >If you want to make a point about ancient hardware, then explain why in the > >heck was CAM integrated without ALL the legacy SCSI devices being supported? Why this bitching attitude? If you feel CAM is not complete by all means write extensions to it. > But all legacy SCSI devices are being supported by CAM (at least that is > the intention barring bugs). We don't support legacy SCSI controllers > due to lack of time and documentation. In other words, the 3.0R > documentation will clearly state that we only support cards X, Y, and Z. > It will also say that disks, cdroms, scanners, tapes, and worm devices > are supported. The user will understand if their wd7000 controller > isn't found during install because the documentation does say that it is > supported, but they will be perplexed if their CDROM drive is not found > when attached to a supported controller. Right... Principle of least surprise etc. > > Justin Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 15:27:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA11019 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 15:27:23 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA10985; Wed, 30 Sep 1998 15:27:04 -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.1/8.8.8) with ESMTP id PAA03681; Wed, 30 Sep 1998 15:31:08 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199809302231.PAA03681@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: dag-erli@ifi.uio.no (Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?= ) cc: Ollivier Robert , current@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahc & CAM: strange diagnostic In-reply-to: Your message of "30 Sep 1998 15:05:49 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 30 Sep 1998 15:31:08 -0700 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id PAA10991 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > One more argument in favor of IBM disks is that they reputedly run > cooler and quieter than Quantum or Seagate disks. I can't speak for the 7200 and 10000rpm IBM disks, as I have never been able to source them when I've been considering them. I can say that IBM go to considerable lengths to make their cooling data available (see the product pages for their drives), and they do appear to be comparable if not somewhat better than the competition. OTOH, we have been running a 9GB Seagate Cheetah in Freefall holding the CVS repository, and despite being far and away the busiest disk in the system it has kept its cool quite well. -- \\ 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 Wed Sep 30 15:57:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA17192 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 15:57:20 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA17161 for ; Wed, 30 Sep 1998 15:57:06 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id QAA02415; Wed, 30 Sep 1998 16:56:19 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199809302256.QAA02415@panzer.plutotech.com> Subject: Re: ahc & CAM: strange diagnostic In-Reply-To: <199809302231.PAA03681@dingo.cdrom.com> from Mike Smith at "Sep 30, 98 03:31:08 pm" To: mike@smith.net.au (Mike Smith) Date: Wed, 30 Sep 1998 16:56:19 -0600 (MDT) Cc: dag-erli@ifi.uio.no, roberto@keltia.freenix.fr, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (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 [ trimmed -current off the CC list ] Mike Smith wrote... > > One more argument in favor of IBM disks is that they reputedly run > > cooler and quieter than Quantum or Seagate disks. > > I can't speak for the 7200 and 10000rpm IBM disks, as I have never been > able to source them when I've been considering them. I can say that > IBM go to considerable lengths to make their cooling data available > (see the product pages for their drives), and they do appear to be > comparable if not somewhat better than the competition. Yeah, they've got nice drives. I've got an Ultrastar 9ZX (10000RPM) at home, ant it's quite nice. Some of the newer IBM drives have onboard temperature sensors, and will supposedly start failing commands if they get too hot. (with a sense code that indicates the problem) My disk hasn't gotten that hot yet, though. > OTOH, we have been running a 9GB Seagate Cheetah in Freefall holding > the CVS repository, and despite being far and away the busiest disk in > the system it has kept its cool quite well. That's because it's a second generation Cheetah. The second generation Cheetahs run a good bit cooler, I think. They're also faster than the 10,000 RPM IBM disks. (the first generation Cheetahs were slower than the IBM disks) 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 Sep 30 17:10:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA02747 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 17:10:06 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Gatekeeper.Alameda.net (gatekeeper.Alameda.net [207.90.181.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA02656; Wed, 30 Sep 1998 17:09:44 -0700 (PDT) (envelope-from ulf@Gatekeeper.Alameda.net) Received: by Gatekeeper.Alameda.net (8.8.8/8.8.6) id RAA07816; Wed, 30 Sep 1998 17:08:53 -0700 (PDT) Message-ID: <19980930170853.A26485@Alameda.net> Date: Wed, 30 Sep 1998 17:08:53 -0700 From: Ulf Zimmermann To: Mike Smith , =?iso-8859-1?Q?Dag-Erling_C=2E_Sm=F8rgrav_?= Cc: Ollivier Robert , current@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahc & CAM: strange diagnostic Reply-To: ulf@Alameda.net References: <199809302231.PAA03681@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199809302231.PAA03681@dingo.cdrom.com>; from Mike Smith on Wed, Sep 30, 1998 at 03:31:08PM -0700 Organization: Alameda Networks, Inc. X-Operating-System: FreeBSD 2.2.6-STABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 30, 1998 at 03:31:08PM -0700, Mike Smith wrote: > > One more argument in favor of IBM disks is that they reputedly run > > cooler and quieter than Quantum or Seagate disks. > > I can't speak for the 7200 and 10000rpm IBM disks, as I have never been > able to source them when I've been considering them. I can say that > IBM go to considerable lengths to make their cooling data available > (see the product pages for their drives), and they do appear to be > comparable if not somewhat better than the competition. > > OTOH, we have been running a 9GB Seagate Cheetah in Freefall holding > the CVS repository, and despite being far and away the busiest disk in > the system it has kept its cool quite well. I just replaced a Barracuda 9GB disk with an IBM 18G and the drive is very much cooler. I will put some IBM 10K 9G in later tonight. > > -- > \\ 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-current" in the body of the message -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-769-2936 Alameda Networks, Inc. | http://www.Alameda.net | Fax#: 510-521-5073 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 19:22:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA20959 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 19:22:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA20928 for ; Wed, 30 Sep 1998 19:22:37 -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 UAA22072; Wed, 30 Sep 1998 20:21:38 -0600 (MDT) Message-Id: <199810010221.UAA22072@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0.2 2/24/98 From: Steve Passe To: "Kenneth D. Merry" cc: mike@smith.net.au (Mike Smith), dag-erli@ifi.uio.no, roberto@keltia.freenix.fr, scsi@FreeBSD.ORG Subject: Re: ahc & CAM: strange diagnostic In-reply-to: Your message of "Wed, 30 Sep 1998 16:56:19 MDT." <199809302256.QAA02415@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Sep 1998 20:21:38 -0600 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, > [ trimmed -current off the CC list ] > > Mike Smith wrote... > > > One more argument in favor of IBM disks is that they reputedly run > > > cooler and quieter than Quantum or Seagate disks. > > ... > > OTOH, we have been running a 9GB Seagate Cheetah in Freefall holding > > the CVS repository, and despite being far and away the busiest disk in > > the system it has kept its cool quite well. > > That's because it's a second generation Cheetah. The second generation > Cheetahs run a good bit cooler, I think. They're also faster than the > 10,000 RPM IBM disks. (the first generation Cheetahs were slower than the > IBM disks) I just purchased 3 cheetah 10000rpm LVD drives and am quite pleased, they run MUCH cooler than the older ones. After an afternoon of buildworlds they were barely warm to the touch! -- 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 Wed Sep 30 21:31:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07969 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 21:31:08 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA07964; Wed, 30 Sep 1998 21:31:06 -0700 (PDT) (envelope-from jeff-ml@mountin.net) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id XAA21604; Wed, 30 Sep 1998 23:30:34 -0500 (CDT) Received: from harkol-125.isdn.mke.execpc.com(169.207.64.253) by peak.mountin.net via smap (V1.3) id sma021602; Wed Sep 30 23:30:23 1998 Message-Id: <3.0.3.32.19980930232853.00712a74@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 30 Sep 1998 23:28:53 -0500 To: ulf@Alameda.net, Mike Smith , "Dag-Erling C. =?iso-8859-1?Q?Sm=F8rgrav?=" From: "Jeffrey J. Mountin" Subject: Re: ahc & CAM: strange diagnostic Cc: Ollivier Robert , current@FreeBSD.ORG, scsi@FreeBSD.ORG In-Reply-To: <19980930170853.A26485@Alameda.net> References: <199809302231.PAA03681@dingo.cdrom.com> <199809302231.PAA03681@dingo.cdrom.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 05:08 PM 9/30/98 -0700, Ulf Zimmermann wrote: >On Wed, Sep 30, 1998 at 03:31:08PM -0700, Mike Smith wrote: >> > One more argument in favor of IBM disks is that they reputedly run >> > cooler and quieter than Quantum or Seagate disks. >> >> I can't speak for the 7200 and 10000rpm IBM disks, as I have never been >> able to source them when I've been considering them. I can say that >> IBM go to considerable lengths to make their cooling data available >> (see the product pages for their drives), and they do appear to be >> comparable if not somewhat better than the competition. >> >> OTOH, we have been running a 9GB Seagate Cheetah in Freefall holding >> the CVS repository, and despite being far and away the busiest disk in >> the system it has kept its cool quite well. > >I just replaced a Barracuda 9GB disk with an IBM 18G and the drive >is very much cooler. I will put some IBM 10K 9G in later tonight. Cooler is good, but what about long term reliability? UIUC either had a string of bad drives or perhaps the quality has improved with IBM. Noisy drives bother me and get me thinking about thermodynamics. Jeff Mountin - Unix Systems TCP/IP networking jeff@mountin.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 23:27:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA25722 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 23:27:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from www2.shoppersnet.com (shoppersnet.com [204.156.152.112]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA25711; Wed, 30 Sep 1998 23:27:34 -0700 (PDT) (envelope-from digital@www2.shoppersnet.com) Received: from localhost (digital@localhost) by www2.shoppersnet.com (8.8.8/8.8.8) with SMTP id XAA12127; Wed, 30 Sep 1998 23:28:54 -0700 (PDT) (envelope-from digital@www2.shoppersnet.com) Date: Wed, 30 Sep 1998 23:28:54 -0700 (PDT) From: Howard Lew To: Gerard Roudier cc: Dan Busarow , freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: NCR 53c875 SCSI Problems 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 On Sun, 27 Sep 1998, Gerard Roudier wrote: > > On Sat, 26 Sep 1998, Howard Lew wrote: > > > On Sat, 26 Sep 1998, Howard Lew wrote: > > > > > On Sat, 26 Sep 1998, Dan Busarow wrote: > > > > > > > On Sat, 26 Sep 1998, Howard Lew wrote: > > > > > Somehow, the Seagate Hawk drive is having or causing the command failure > > > > > problem -- something that never occurred with the 810 when using freebsd. > > > > > > > > Try going into the SCSI setup on boot up and set the transfer speed > > > > to 20MB so it doesn't try wide negotiation. > > > > I tried setting the speed to 20MB and keeping it at 8 bit, but regardless > > > of what I do the FreeBSD bootup probe still says it is wide scsi and that > > > 16 bit is enabled. Right after that it starts all the command failed > > > messages. I flashed upgraded the bios and it didn't help. > > The FreeBSD ncr driver does not read the user-setup from NVRAM and it is > not possible to tell it about the BUS width at boot time. So, the WIDE > negotiation has every chance to occur with great success and, as a result, > will break any further data transfer between the controller and the > device. > Yes. This appears to be the problem. Because the driver doesn't seem to be able to correctly identify the bus width, I think it would be a better idea to read the NVRAM values if they are available. Otherwise, those of us (anyone really) using a SCSI hard drive that supports a WIDE bus but is running it on a NARROW bus connector on a NCR/Symbios 53c875 card may run into this same problem. Unfortunately, it is not a simple problem to fix unless you already have a FreeBSD system that is bootable off of another drive. If this is the case, the fix is trivial by modifying ncr.c But imagine a user trying to install FreeBSD and boot from boot.flp and failing each time when the controller isn't able to talk to the hard drive after switching to the WIDE bus. I think this is a serious enough problem to require a fix... > > > Is there a way to force the driver to use narrow mode? I know this hard > > > disk can do wide scsi, but I am using the 50 pin connector right now. Is > > > narrow the default? So if I comment out the code in the setwide in ncr.c > > > should that do the trick? > > You will get the desired effect by just masking the FE_WIDE bit in the > 'features' bitmap which is the main result of the chip probe code. > Look into ncr_attach(), the patch should be trivial and very short. > Thanks for the good tip. > > I did some more checking around and found out that Debian Linux also works > > fine with the Seagate Hawk/Diamond Fireport 40 combination. But FreeBSD, > > The Linux driver reads the user-setup from the controller NVRAM and apply > user desired controller and devices settings. It is also possible to send > it boot parameters. The 2nd method is only usefull for controllers that > donnot have NVRAM. > > At the time I have back-ported the Ultra1/2 SCSI support to the FreeBSD > ncr driver, the NVRAM code was available in the Linux ncr53c8xx driver, > but this code hasn't been candidate to the back-port, since SteFan was > working on a different implementation for FreeBSD. > hmmm... Stefan? If you are listenining, any ideas to a real fix? > > NetBSD, and OpenBSD all suffer from the same problem of being locked on > > "wide bus" when I am using the narrow connector. > > Same problem as FreeBSD. > > Regards, > Gerard. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Sep 30 23:39:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA27502 for freebsd-scsi-outgoing; Wed, 30 Sep 1998 23:39:41 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from www2.shoppersnet.com (shoppersnet.com [204.156.152.112]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA27484; Wed, 30 Sep 1998 23:39:38 -0700 (PDT) (envelope-from digital@www2.shoppersnet.com) Received: from localhost (digital@localhost) by www2.shoppersnet.com (8.8.8/8.8.8) with SMTP id XAA12214; Wed, 30 Sep 1998 23:40:42 -0700 (PDT) (envelope-from digital@www2.shoppersnet.com) Date: Wed, 30 Sep 1998 23:40:42 -0700 (PDT) From: Howard Lew To: Thomas Keusch cc: freebsd-scsi@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: NCR 53c875 SCSI Problems In-Reply-To: <19980928053655.19907@visionaire.ping.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 Mon, 28 Sep 1998, Thomas Keusch wrote: > On Sep 26, Howard Lew wrote > > > Somehow, the Seagate Hawk drive is having or causing the command failure > > problem -- something that never occurred with the 810 when using freebsd. > > > > Does anyone know what kind of command it is failing on? Is it trying to > > query the drive speed or something? > > I have a very similar/the same problem with a SymbiosLogic 8750SP Ultra-SCSI > controller and two IBM DCAS 4.1 Gb HDDs. > > I did not find a solution yet, but it seems that the problem on my box is > related to FreeBSD trying to find out the size of the disks. This produces > basically the same error as yours, but quits scanning with an "could not get > size" error for each disk after a while. Yes, this is exactly the same problem I am having. I guess if I wait a very long time, it might get past the boot probe after failing to detect the affected drives, but generally the boot probe shouldn't take 1 hour or more to do. > > I took of the entire bus from the controller, so that the controller was the > only SCSI device in the system. FreeBSD doesn't choke on the controller > itself, it's the disks. Yes, it is the disks -- not the controller. There is an easy fix if you already have a working FreeBSD system that is booting off another drive. As long as you are not using the WIDE bus, you can force everything to 8 bit mode. I found that changing the SCSI_NCR_MAX_WIDE to 0 does the trick. Of course, this forces 8 bit mode and disables the WIDE bus, so you should not have any devices on the WIDE bus. As it is, this is not a real fix because you need a working system to make the changes in ncr.c and then recompile the system. So if a new user wants to install FreeBSD on his hard disk, this quick fix will not work as they won't be able to get through the installation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 1 00:22:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA03665 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 00:22:17 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from bsd.synx.com (rt.synx.com [194.167.81.239]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA03559; Thu, 1 Oct 1998 00:22:04 -0700 (PDT) (envelope-from root@synx.com) Received: from synx.com (rn [192.1.1.241]) by bsd.synx.com (8.6.12/8.6.12) with ESMTP id IAA11866; Thu, 1 Oct 1998 08:19:33 +0100 Message-Id: <199810010719.IAA11866@bsd.synx.com> Date: Thu, 1 Oct 1998 09:19:26 +0200 (CEST) From: Remy NONNENMACHER Reply-To: remy@synx.com Subject: Re: ahc & CAM: strange diagnostic To: ulf@Alameda.net cc: mike@smith.net.au, dag-erli@ifi.uio.no, roberto@keltia.freenix.fr, current@FreeBSD.ORG, scsi@FreeBSD.ORG In-Reply-To: <19980930170853.A26485@Alameda.net> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 30 Sep, Ulf Zimmermann wrote: > On Wed, Sep 30, 1998 at 03:31:08PM -0700, Mike Smith wrote: >> > One more argument in favor of IBM disks is that they reputedly run >> > cooler and quieter than Quantum or Seagate disks. >> >> I can't speak for the 7200 and 10000rpm IBM disks, as I have never been >> able to source them when I've been considering them. I can say that >> IBM go to considerable lengths to make their cooling data available >> (see the product pages for their drives), and they do appear to be >> comparable if not somewhat better than the competition. >> >> OTOH, we have been running a 9GB Seagate Cheetah in Freefall holding >> the CVS repository, and despite being far and away the busiest disk in >> the system it has kept its cool quite well. > > I just replaced a Barracuda 9GB disk with an IBM 18G and the drive > is very much cooler. I will put some IBM 10K 9G in later tonight. > I've 6 of them along with 2 Atlas and the 9G 10K IBM are really going hot (in all meaning of the word :)). An interesting thing is that they feature a temp. probe that can be read through status pages. Environmental 21 deg.C give a 35/37 deg.C internal temp. >> >> -- >> \\ 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-current" 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 Thu Oct 1 03:12:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA23662 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 03:12:54 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from magnet.geophysik.tu-freiberg.de ([139.20.128.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA23656 for ; Thu, 1 Oct 1998 03:12:45 -0700 (PDT) (envelope-from freebsd@magnet.geophysik.tu-freiberg.de) Received: (from freebsd@localhost) by magnet.geophysik.tu-freiberg.de (8.9.1/8.7.3) id MAA01377 for freebsd-scsi@freebsd.org; Thu, 1 Oct 1998 12:11:25 +0200 (CEST) From: Holm Tiffe Message-Id: <199810011011.MAA01377@magnet.geophysik.tu-freiberg.de> Subject: Minor glitch with AHA2742 and CAM (bus nubering) To: freebsd-scsi@FreeBSD.ORG Date: Thu, 1 Oct 1998 12:11:25 +0200 (CEST) Reply-To: freebsd@magnet.geophysik.tu-freiberg.de X-Mailer: ELM [version 2.4ME+ PL26 (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 Hi, on my old 486/EISA I have an -current (elf) running with an AHA2742T twin bus adapter. Because of the brain damadget architecture from this controller (Bus A has an external and an internal connector, bus B has only an internal connector) I've changed the Bus numbering in the EISA Setup, so that channel B is the primary bus and channel A the secondary. This configuration is running fine, but the now primary channel B is detected as bus #1 and the secondary channel A as bus #0. This makes no problems so far. But when I connect an external SCSI disk later whitout hardwiring the devices in the kernel the kernel is booting fine (using da0 in the bootloader) but when it try's to mount the root disk it panics, because there is no / filesystem on the now new disk from the second channel A that is now da0! Could we please change this bus numbering behavior so that the in the EISA Setup defined "primary" SCSI bus get's the bus #0 even when it is channel B ? Thanks in advance, Holm -- ******************************************************************************* * Holm Tiffe holm@geophysik.tu-freiberg.de * * Freiberger Strasse 24 * * 09600 Kleinschirma, Germany Microsoft is not the Answer - * * Tel.: 49 3731 74233 Microsoft is the Question, * * UUCP: 49 3731 73719 unicorn!holm and the Answer is no ! * ******************************************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 1 05:02:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA06657 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 05:02:45 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nomis.simon-shapiro.org (nomis.simon-shapiro.org [209.86.126.163]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id FAA06645 for ; Thu, 1 Oct 1998 05:02:39 -0700 (PDT) (envelope-from shimon@simon-shapiro.org) Received: (qmail 4354 invoked by uid 1000); 1 Oct 1998 13:05:34 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 01 Oct 1998 09:05:34 -0400 (EDT) X-Face: (&r=uR0&yvh>h^ZL4"-TH61PD}/|Y'~58Z# Gz&BK'&uLAf:2wLb~L7YcWfau{;N(#LR2)\i.l8'ZqVhv~$rNx$]Om6Sv36S'\~5m/U'"i/L)&t$R0&?,)tm0l5xZ!\hZU^yMyCdt!KTcQ376cCkQ^Q_n.GH;Dd-q+ O51^+.K-1Kq?WsP9;cw-Ki+b.iY-5@3!YB5{I$h;E][Xlg*sPO61^5=:5k)JdGet,M|$"lq!1!j_>? $0Yc? Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: freebsd-scsi@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: DPT_RESET - Do We Still Need It? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Please post back ONLY on FreeBSD-SCSI! Some time ago (pre-CAM) there was a need to disable the DPT driver feature which causes the controller to flush caches and shutdown during kernel shutdown. The problem manifested itself by shutting the kernel down (including calls to all registered at_shutdown functions), then proceeding to do massive I/O to the (already shutdown) disk subsystem. This was during kernel panics that resulted in kernel dumps. The ``feature'' I added to the DPT driver was to actually ignore the shutdown command and just introduce a delay instead. The Question: Do we still need the added feature, or does the kernel/CAM now shuts down as should have been (No I/O after closure)? Sincerely Yours, Shimon@Simon-Shapiro.ORG 770.265.7340 Simon Shapiro Unwritten code has no bugs and executes at twice the speed of mouth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 1 05:44:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA11476 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 05:44:05 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA11333; Thu, 1 Oct 1998 05:43:42 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.8.8/8.8.8) id NAA26588; Thu, 1 Oct 1998 13:43:22 +0100 (BST) (envelope-from joe) Message-ID: <19981001134322.E16056@pavilion.net> Date: Thu, 1 Oct 1998 13:43:22 +0100 From: Josef Karthauser To: freebsd-scsi@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: chio.c (bug?) Mail-Followup-To: freebsd-scsi@Freebsd.org, freebsd-hackers@freebsd.org References: <19980929114402.9912.qmail@modgud.nordicdms.com> <86g1d9ab83.fsf@samizdat.uucom.com> <19980930192132.D11002@pavilion.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19980930192132.D11002@pavilion.net>; from Josef Karthauser on Wed, Sep 30, 1998 at 07:21:32PM +0100 X-NCC-RegID: uk.pavilion Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I'm doing some work with chio and amanda under CAM and I've discovered what appears to be a bug :) chio.c: --- chio.c 1998/09/15 07:48:51 1.7 +++ chio.c 1998/10/01 12:36:19 @@ -405,6 +405,8 @@ if (data.cp_nportals) (void) printf(", %d portal%s", data.cp_nportals, (data.cp_nportals > 1) ? "s" : ""); + printf("\n%s: current picker: %d\n", changer_name, data.cp_curpicker); + return (0); Oops I think. Can someone either put the offending line back in, or expain why it shouldn't be there. Thanks :) Joe -- Josef Karthauser Technical Manager FreeBSD: The power to serve (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 Thu Oct 1 06:10:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA14922 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 06:10:44 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA14888; Thu, 1 Oct 1998 06:10:33 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.8.8/8.8.8) id OAA01342; Thu, 1 Oct 1998 14:10:15 +0100 (BST) (envelope-from joe) Message-ID: <19981001141015.G16056@pavilion.net> Date: Thu, 1 Oct 1998 14:10:15 +0100 From: Josef Karthauser To: freebsd-scsi@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: re: chio.c (bug?) Mail-Followup-To: freebsd-scsi@Freebsd.org, freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Mailer: Mutt 0.93.2i In-Reply-To: <19980930192132.D11002@pavilion.net>; from Josef Karthauser on Wed, Sep 30, 1998 at 07:21:32PM +0100 X-NCC-RegID: uk.pavilion Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry, I was a bit quick off the mark. I believe that the patch below reinstates the functionality documented in the man page: params Report the number of slots, drives, pickers, and portals in the changer, and which picker unit the changer is currently config- ured to use. ----------------Patch below---------------------- --- chio.c Thu Oct 1 14:02:29 1998 +++ /home/joe/chio.c Thu Oct 1 14:04:20 1998 @@ -382,7 +382,6 @@ do_params(char *cname, int argc, char **argv) { struct changer_params data; - int picker; /* No arguments to this command. */ @@ -406,12 +405,6 @@ if (data.cp_nportals) (void) printf(", %d portal%s", data.cp_nportals, (data.cp_nportals > 1) ? "s" : ""); - - - /* Get current picker from changer and display it. */ - if (ioctl(changer_fd, CHIOGPICKER, &picker)) - err(1, "%s: CHIOGPICKER", changer_name); - printf("\n%s: current picker: %d\n", changer_name, picker); return (0); -- Josef Karthauser Technical Manager FreeBSD: The power to serve (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] ----- End forwarded message ----- -- Josef Karthauser Technical Manager FreeBSD: The power to serve (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 Thu Oct 1 07:45:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29175 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 07:45:32 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail.intercom.com ([207.51.55.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA29167 for ; Thu, 1 Oct 1998 07:45:28 -0700 (PDT) (envelope-from jason@intercom.com) Received: from intercom.com (I.am@shagalicious.com [206.98.165.250]) by mail.intercom.com (8.9.0/8.9.0) with ESMTP id KAA24489; Thu, 1 Oct 1998 10:45:07 -0400 (EDT) Message-ID: <361395B8.C050D07A@intercom.com> Date: Thu, 01 Oct 1998 10:46:16 -0400 From: "Jason J. Horton" X-Sender: "Jason J. Horton" <@mail.intercom.com> X-Mailer: Mozilla 4.5b2 [en]C-NECCK (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: remy@synx.com, scsi@FreeBSD.ORG Subject: Re: ahc & CAM: strange diagnostic References: <199810010719.IAA11866@bsd.synx.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org How are drive temperatures accessed? obviously that would be useful for system monitoring(SNMP or otherwise) -J Remy NONNENMACHER wrote: > > On 30 Sep, Ulf Zimmermann wrote: > > On Wed, Sep 30, 1998 at 03:31:08PM -0700, Mike Smith wrote: > >> > One more argument in favor of IBM disks is that they reputedly run > >> > cooler and quieter than Quantum or Seagate disks. > >> > >> I can't speak for the 7200 and 10000rpm IBM disks, as I have never been > >> able to source them when I've been considering them. I can say that > >> IBM go to considerable lengths to make their cooling data available > >> (see the product pages for their drives), and they do appear to be > >> comparable if not somewhat better than the competition. > >> > >> OTOH, we have been running a 9GB Seagate Cheetah in Freefall holding > >> the CVS repository, and despite being far and away the busiest disk in > >> the system it has kept its cool quite well. > > > > I just replaced a Barracuda 9GB disk with an IBM 18G and the drive > > is very much cooler. I will put some IBM 10K 9G in later tonight. > > > > I've 6 of them along with 2 Atlas and the 9G 10K IBM are really going > hot (in all meaning of the word :)). An interesting thing is that they > feature a temp. probe that can be read through status pages. > Environmental 21 deg.C give a 35/37 deg.C internal temp. > > >> > >> -- > >> \\ 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-current" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" 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 Thu Oct 1 08:01:51 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA01207 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 08:01:51 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA01184; Thu, 1 Oct 1998 08:01:48 -0700 (PDT) (envelope-from dkelly@n4hhe.ampr.org) Received: from nospam.hiwaay.net (tnt4-181.HiWAAY.net [208.166.127.181]) by mail.HiWAAY.net (8.9.0/8.9.0) with ESMTP id KAA23800; Thu, 1 Oct 1998 10:01:29 -0500 (CDT) Received: from n4hhe.ampr.org (localhost.ampr.org [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.8) with ESMTP id KAA27273; Thu, 1 Oct 1998 10:01:27 -0500 (CDT) (envelope-from dkelly@n4hhe.ampr.org) Message-Id: <199810011501.KAA27273@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: remy@synx.com cc: current@FreeBSD.ORG, scsi@FreeBSD.ORG From: David Kelly Subject: Re: ahc & CAM: strange diagnostic In-reply-to: Message from Remy NONNENMACHER of "Thu, 01 Oct 1998 09:19:26 +0200." <199810010719.IAA11866@bsd.synx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Oct 1998 10:01:27 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Remy NONNENMACHER writes: > > I just replaced a Barracuda 9GB disk with an IBM 18G and the drive > > is very much cooler. I will put some IBM 10K 9G in later tonight. > > > > I've 6 of them along with 2 Atlas and the 9G 10K IBM are really going > hot (in all meaning of the word :)). An interesting thing is that they > feature a temp. probe that can be read through status pages. > Environmental 21 deg.C give a 35/37 deg.C internal temp. Any details as to how we too might be able to play with the temperature status probe you mention? My 7.2k 9G IBM drive might support it too. I have a digital indoor/outdoor thermometer mounted on my case. Probe is taped to the HD. Its running 38C now, 11C over the external temperature of the PC's case. Was using a max/min model but decided it was needed worse elsewhere. -- 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 Thu Oct 1 08:58:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA12270 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 08:58:18 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA12248 for ; Thu, 1 Oct 1998 08:58:10 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id JAA27451; Thu, 1 Oct 1998 09:51:23 -0600 (MDT) Date: Thu, 1 Oct 1998 09:51:23 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199810011551.JAA27451@narnia.plutotech.com> To: shimon@simon-shapiro.org cc: scsi@FreeBSD.ORG Subject: Re: DPT_RESET - Do We Still Need It? Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > The problem manifested itself by shutting the kernel down (including calls > to all registered at_shutdown functions), then proceeding to do massive I/O > to the (already shutdown) disk subsystem. This was during kernel panics > that resulted in kernel dumps. I corrected this by adding the SHUTDOWN_FINAL at_shutdown state. This hook class is called only after a system dump, if any, is performed. I needed this for the adaptec originally, but the CAM dpt driver uses it now too. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 1 09:21:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA15629 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 09:21:47 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nomis.simon-shapiro.org (nomis.simon-shapiro.org [209.86.126.163]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA15614 for ; Thu, 1 Oct 1998 09:21:42 -0700 (PDT) (envelope-from shimon@simon-shapiro.org) Received: (qmail 15755 invoked by uid 1000); 1 Oct 1998 17:24:36 -0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) In-Reply-To: <199810011551.JAA27451@narnia.plutotech.com> Date: Thu, 01 Oct 1998 13:24:36 -0400 (EDT) X-Face: (&r=uR0&yvh>h^ZL4"-TH61PD}/|Y'~58Z# Gz&BK'&uLAf:2wLb~L7YcWfau{;N(#LR2)\i.l8'ZqVhv~$rNx$]Om6Sv36S'\~5m/U'"i/L)&t$R0&?,)tm0l5xZ!\hZU^yMyCdt!KTcQ376cCkQ^Q_n.GH;Dd-q+ O51^+.K-1Kq?WsP9;cw-Ki+b.iY-5@3!YB5{I$h;E][Xlg*sPO61^5=:5k)JdGet,M|$"lq!1!j_>? $0Yc? Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: freebsd-scsi@FreeBSD.ORG Subject: Re: DPT_RESET - Do We Still Need It? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Justin T. Gibbs, On 01-Oct-98 you wrote: > In article you wrote: > > The problem manifested itself by shutting the kernel down (including > > calls > > to all registered at_shutdown functions), then proceeding to do massive > > I/O > > to the (already shutdown) disk subsystem. This was during kernel > > panics > > that resulted in kernel dumps. > > I corrected this by adding the SHUTDOWN_FINAL at_shutdown state. This > hook class is called only after a system dump, if any, is performed. > I needed this for the adaptec originally, but the CAM dpt driver uses it > now too. Great! I do not have to bother with this ugly hack, then. There will be a minor patch posted soon (I need to see that it works), that takes care of some (most, all?) of the lost IRQs. I am currently stressing the driver and the kernel around it and will post results soon. > > -- > Justin Sincerely Yours, Shimon@Simon-Shapiro.ORG 770.265.7340 Simon Shapiro Unwritten code has no bugs and executes at twice the speed of mouth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 1 09:24:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA16033 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 09:24:07 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nomis.simon-shapiro.org (nomis.simon-shapiro.org [209.86.126.163]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA15943 for ; Thu, 1 Oct 1998 09:24:00 -0700 (PDT) (envelope-from shimon@simon-shapiro.org) Received: (qmail 15768 invoked by uid 1000); 1 Oct 1998 17:26:58 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 01 Oct 1998 13:26:58 -0400 (EDT) X-Face: (&r=uR0&yvh>h^ZL4"-TH61PD}/|Y'~58Z# Gz&BK'&uLAf:2wLb~L7YcWfau{;N(#LR2)\i.l8'ZqVhv~$rNx$]Om6Sv36S'\~5m/U'"i/L)&t$R0&?,)tm0l5xZ!\hZU^yMyCdt!KTcQ376cCkQ^Q_n.GH;Dd-q+ O51^+.K-1Kq?WsP9;cw-Ki+b.iY-5@3!YB5{I$h;E][Xlg*sPO61^5=:5k)JdGet,M|$"lq!1!j_>? $0Yc? Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: freebsd-scsi@FreeBSD.ORG Subject: 5th Generation DPT Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just a note to those who asked: Work is progressing well on the 5th Generation DPT controllers. This will include the FCAL versions soon. Details on the avaiability are still sketchy, but it will be available, for FreeBSD 3.0, and for free. Of this I am certain. Sincerely Yours, Shimon@Simon-Shapiro.ORG 770.265.7340 Simon Shapiro Unwritten code has no bugs and executes at twice the speed of mouth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 1 09:48:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA19476 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 09:48:27 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA19397; Thu, 1 Oct 1998 09:48:12 -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 JAA20379; Thu, 1 Oct 1998 09:47:45 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Date: Thu, 1 Oct 1998 09:47:44 -0700 (PDT) From: Doug White To: David Kelly cc: remy@synx.com, current@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahc & CAM: strange diagnostic In-Reply-To: <199810011501.KAA27273@nospam.hiwaay.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 Thu, 1 Oct 1998, David Kelly wrote: > Remy NONNENMACHER writes: > > > I just replaced a Barracuda 9GB disk with an IBM 18G and the drive > > > is very much cooler. I will put some IBM 10K 9G in later tonight. > > > > > > > I've 6 of them along with 2 Atlas and the 9G 10K IBM are really going > > hot (in all meaning of the word :)). An interesting thing is that they > > feature a temp. probe that can be read through status pages. > > Environmental 21 deg.C give a 35/37 deg.C internal temp. > > Any details as to how we too might be able to play with the temperature > status probe you mention? My 7.2k 9G IBM drive might support it too. It's on mode page 0, somewhere :) Someone needs to grab the software interface so we can add the variable names to mode_pages. That or a secret-ring-decoder for the bytes returned by 'camcontrol modepage -m 0'. My UltraStor 9ES 4Gig UltraWide (DDRS-34560W)[1] doesn't appear to support it, according to the IBM specs. A link to the feature's technote (Drive-TIP) shows up for the 18XL (10krpm, 9 & 18GB sizes). They even show the chip location on the back side of the hard disk controller board. (out of view of course) > I have a digital indoor/outdoor thermometer mounted on my case. Probe > is taped to the HD. Its running 38C now, 11C over the external > temperature of the PC's case. We really need to figure out how to read the BIOS hardware moitor port on ATX MB's. IT'd be a great thing to stick on the MtraixOrbital LCD displays :) Doug White Internet: dwhite@resnet.uoregon.edu | FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite | www.freebsd.org [1] Kudos to Toshiba for replacing the Crapopolis with such a nice drive. :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Oct 1 13:00:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA22311 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 13:00:59 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA22290 for ; Thu, 1 Oct 1998 13:00:51 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id OAA08745; Thu, 1 Oct 1998 14:00:22 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810012000.OAA08745@panzer.plutotech.com> Subject: Re: ahc & CAM: strange diagnostic In-Reply-To: from Doug White at "Oct 1, 98 09:47:44 am" To: dwhite@resnet.uoregon.edu (Doug White) Date: Thu, 1 Oct 1998 14:00:22 -0600 (MDT) Cc: dkelly@hiwaay.net, remy@synx.com, scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (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 [ -current trimmed off the CC list ] Doug White wrote... > On Thu, 1 Oct 1998, David Kelly wrote: > > > Remy NONNENMACHER writes: > > > > I just replaced a Barracuda 9GB disk with an IBM 18G and the drive > > > > is very much cooler. I will put some IBM 10K 9G in later tonight. > > > > > > > > > > I've 6 of them along with 2 Atlas and the 9G 10K IBM are really going > > > hot (in all meaning of the word :)). An interesting thing is that they > > > feature a temp. probe that can be read through status pages. > > > Environmental 21 deg.C give a 35/37 deg.C internal temp. > > > > Any details as to how we too might be able to play with the temperature > > status probe you mention? My 7.2k 9G IBM drive might support it too. > > It's on mode page 0, somewhere :) Someone needs to grab the software > interface so we can add the variable names to mode_pages. That or a > secret-ring-decoder for the bytes returned by 'camcontrol modepage -m 0'. I've got the databook for 18XP and the 9LP, and the only parameter in mode page 0 that's related to temperature is the thing that lets you specify the temperature threshold. It is byte 9 of modepage 0. The description in the manual says: "Byte 9 specifies the threshold value in Celsius for the thermal sensor warning message. The termpature threshold can be adjusted in the range: 6C through 65C. A value of 0 selects the default threshold which depends on which electronics card is installed in the drive. All other values above or below the adjustable range select the range limit to which they are closest. "Note: The casting temperature may be different than that reported by the sensor due to the sensor being located on the electronics card rather than the casting." It looks like you can set the temperature threshold value, but you can't read it. (which fits the output of byte 9 of modepage 0 on my 9ZX -- it's 0) I looked around in the log page descriptions and in all the mode page descriptions, and I couldn't find a place that specified the current temperature of the drive. > My UltraStor 9ES 4Gig UltraWide (DDRS-34560W)[1] doesn't appear to support > it, according to the IBM specs. A link to the feature's technote > (Drive-TIP) shows up for the 18XL (10krpm, 9 & 18GB sizes). They even > show the chip location on the back side of the hard disk controller board. > (out of view of course) The 18XL is a 7200 RPM drive. The 9ZX is their only 10000 RPM drive. I'm kinda annoyed that IBM doesn't put their drive manuals on the web. Quantum provides SCSI specs for their products on the web, which is very handy. So, Remy, you wanna tell us which log or mode page you're looking at? 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 Oct 1 13:15:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA24602 for freebsd-scsi-outgoing; Thu, 1 Oct 1998 13:15:23 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA24596 for ; Thu, 1 Oct 1998 13:15:21 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id OAA08859; Thu, 1 Oct 1998 14:14:49 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810012014.OAA08859@panzer.plutotech.com> Subject: Re: chio.c (bug?) In-Reply-To: <19981001141015.G16056@pavilion.net> from Josef Karthauser at "Oct 1, 98 02:10:15 pm" To: joe@pavilion.net (Josef Karthauser) Date: Thu, 1 Oct 1998 14:14:49 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (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 [ -hackers trimmed off the CC list, please just post to -scsi for stuff like this ] Josef Karthauser wrote... > Sorry, I was a bit quick off the mark. I believe that the patch below > reinstates the functionality documented in the man page: > > params Report the number of slots, drives, pickers, and portals in the > changer, and which picker unit the changer is currently config- > ured to use. You're quite right, it's broken. It looks like it got messed up when Hans put in volume tag support. I'll try to commit the patch later on tonight. 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 Oct 2 02:52:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA25497 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 02:52:55 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA25486; Fri, 2 Oct 1998 02:52:54 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id CAA10467; Fri, 2 Oct 1998 02:52:37 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id CAA04737; Fri, 2 Oct 1998 02:52:35 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id CAA15297; Fri, 2 Oct 1998 02:52:34 -0700 (PDT) Date: Fri, 2 Oct 1998 02:52:34 -0700 (PDT) From: Don Lewis Message-Id: <199810020952.CAA15297@salsa.gv.tsc.tdk.com> To: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: filesystem safety and SCSI disk write caching Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was doing some torture testing of softupdates, CAM, and fsck by hitting the reset button on a running system and noticed that fsck would sometimes encounter inconsistencies in the filesystem that should not be happening, such as directory entries that pointed to unallocated inodes. I tracked the problem down to write caching being enabled on the machine's SCSI disk. After using camcontrol to disable write caching, this problem went away. It would be nice if folks in this situation would get a warning that their filesystems could get trashed because the disk has write caching enabled. I think the best situation would be to issue this warning at filesystem mount time (though folks who use async mounts shouldn't get an extra warning about write caching, their filesystems may get trashed anyway). This would require a communications channel between the filesystem and CAM. Another possibility would be to just issue a brief warning when the device is probed at boot time. Even a warning in the documentation would be helpful, at least for those who bothered to read it. BTW, with softupdates, and tagged command queuing enabled in CAM, there is not much of a performance hit from turning off write caching. I saw "make buildworld" increase from about 2 hours to 2 hours 5 minutes, and "make -j6 buildworld" increase from about 1 hour 30 minutes to 1 hour 35 minutes. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 2 06:26:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA24750 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 06:26:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA24732; Fri, 2 Oct 1998 06:26:39 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA12369 (5.67b/IDA-1.5); Fri, 2 Oct 1998 14:59:34 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id OAA29167; Fri, 2 Oct 1998 14:06:50 +0200 (CEST) From: Wilko Bulte Message-Id: <199810021206.OAA29167@yedi.iaf.nl> Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <199810020952.CAA15297@salsa.gv.tsc.tdk.com> from Don Lewis at "Oct 2, 98 02:52:34 am" To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Fri, 2 Oct 1998 14:06:50 +0200 (CEST) Cc: freebsd-fs@FreeBSD.ORG, 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+ PL38 (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 Don Lewis wrote... > > I was doing some torture testing of softupdates, CAM, and fsck by > hitting the reset button on a running system and noticed that fsck > would sometimes encounter inconsistencies in the filesystem that > should not be happening, such as directory entries that pointed to > unallocated inodes. I tracked the problem down to write caching > being enabled on the machine's SCSI disk. After using camcontrol to > disable write caching, this problem went away. Yuck. Write caching on disks is evil. I've discussed this kind of thing at great length with the disk gurus at work. There is consensus: write caching is not to be trusted, there are even firmware incarnations out there that get confused by a SCSI bus reset and loose track of what they have cached. Admittedly this is junk firmware, but it seems to happen. This is the kind of stuff that makes the Oracle-s of this world extremely nervous ;-) > It would be nice if folks in this situation would get a warning that > their filesystems could get trashed because the disk has write caching > enabled. I think the best situation would be to issue this warning at > filesystem mount time (though folks who use async mounts shouldn't get > an extra warning about write caching, their filesystems may get trashed > anyway). This would require a communications channel between the > filesystem and CAM. Another possibility would be to just issue a > brief warning when the device is probed at boot time. Even a warning > in the documentation would be helpful, at least for those who bothered > to read it. You'd have to dig into the modepages of the drives. Makes for a somewhat kludgy interface in the SCSI subsystem all the way up to 'mount'. I'd rather put it into the device probe section for the da devices. > BTW, with softupdates, and tagged command queuing enabled in CAM, there > is not much of a performance hit from turning off write caching. I > saw "make buildworld" increase from about 2 hours to 2 hours 5 minutes, > and "make -j6 buildworld" increase from about 1 hour 30 minutes to > 1 hour 35 minutes. Negligible difference in my book. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 2 09:46:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA27212 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 09:46:46 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA27200; Fri, 2 Oct 1998 09:46:40 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id KAA21621; Fri, 2 Oct 1998 10:46:20 -0600 (MDT) Message-Id: <199810021646.KAA21621@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Don Lewis cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Fri, 02 Oct 1998 02:52:34 PDT." <199810020952.CAA15297@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Oct 1998 10:39:50 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >I was doing some torture testing of softupdates, CAM, and fsck by >hitting the reset button on a running system and noticed that fsck >would sometimes encounter inconsistencies in the filesystem that >should not be happening, such as directory entries that pointed to >unallocated inodes. I tracked the problem down to write caching >being enabled on the machine's SCSI disk. After using camcontrol to >disable write caching, this problem went away. This is a non-conclusive result. By disabling the cache, you have effectively reduced the concurrent transaction count which may mask bugs elsewhere in the system. So long as you do not lose power to your SCSI disk (which the reset button should not cause to occur), the cache should have no impact on the results of your test. >BTW, with softupdates, and tagged command queuing enabled in CAM, there >is not much of a performance hit from turning off write caching. I >saw "make buildworld" increase from about 2 hours to 2 hours 5 minutes, >and "make -j6 buildworld" increase from about 1 hour 30 minutes to >1 hour 35 minutes. In this particular benchmark, perhaps not, but make buildworld is not indicative of most I/O loads. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 2 12:00:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA18187 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 12:00:37 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA18175; Fri, 2 Oct 1998 12:00:33 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA02176; Fri, 2 Oct 1998 11:59:40 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdTh2170; Fri Oct 2 18:59:30 1998 Date: Fri, 2 Oct 1998 11:59:26 -0700 (PDT) From: Julian Elischer To: Don Lewis cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <199810020952.CAA15297@salsa.gv.tsc.tdk.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 you are correct. write caching can screw soft updates if there is any major re-ordering of the data written. With tags it doesn't matter if they are re-ordered, as long as they are not acknowledged until they are on the platter. As you noted, softupdates itself does reduce the value of drive write caching, and in fact I'm glad that your numbers agree with my expectations. julian On Fri, 2 Oct 1998, Don Lewis wrote: > > I was doing some torture testing of softupdates, CAM, and fsck by > hitting the reset button on a running system and noticed that fsck > would sometimes encounter inconsistencies in the filesystem that > should not be happening, such as directory entries that pointed to > unallocated inodes. I tracked the problem down to write caching > being enabled on the machine's SCSI disk. After using camcontrol to > disable write caching, this problem went away. > > It would be nice if folks in this situation would get a warning that > their filesystems could get trashed because the disk has write caching > enabled. I think the best situation would be to issue this warning at > filesystem mount time (though folks who use async mounts shouldn't get > an extra warning about write caching, their filesystems may get trashed > anyway). This would require a communications channel between the > filesystem and CAM. Another possibility would be to just issue a > brief warning when the device is probed at boot time. Even a warning > in the documentation would be helpful, at least for those who bothered > to read it. > > BTW, with softupdates, and tagged command queuing enabled in CAM, there > is not much of a performance hit from turning off write caching. I > saw "make buildworld" increase from about 2 hours to 2 hours 5 minutes, > and "make -j6 buildworld" increase from about 1 hour 30 minutes to > 1 hour 35 minutes. > > > 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 Oct 2 12:30:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA21749 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 12:30:30 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA21737; Fri, 2 Oct 1998 12:30:21 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id NAA11650; Fri, 2 Oct 1998 13:29:57 -0600 (MDT) Message-Id: <199810021929.NAA11650@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Wilko Bulte cc: Don.Lewis@tsc.tdk.com (Don Lewis), freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Fri, 02 Oct 1998 14:06:50 +0200." <199810021206.OAA29167@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Oct 1998 13:23:27 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Yuck. Write caching on disks is evil. I've discussed this kind of >thing at great length with the disk gurus at work. There is consensus: >write caching is not to be trusted, there are even firmware incarnations >out there that get confused by a SCSI bus reset and loose track of what >they have cached. Admittedly this is junk firmware, but it seems to >happen. Your statement doesn't seem to be "write caching is inherently evil", but "there are many drives with bogus firmware where write caching is evil". There is a big difference. If you have a sane device and a UPS, write caching is not evil at all. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 2 12:53:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA25026 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 12:53:37 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA25020; Fri, 2 Oct 1998 12:53:34 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id NAA12817; Fri, 2 Oct 1998 13:53:13 -0600 (MDT) Message-Id: <199810021953.NAA12817@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Julian Elischer cc: Don Lewis , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Fri, 02 Oct 1998 11:59:26 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Oct 1998 13:46:43 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >write caching can screw soft updates if there is any >major re-ordering of the data written. Only if you lose power or have a buggy device. Go read the SCSI spec on write caching. >With tags it doesn't matter if they are re-ordered, as long >as they are not acknowledged until they are on the platter. Tagged transactions may "complete" in a non-FIFO order. "Complete" either means data transfered into the cache or data safely on the media depending on whether the cache is enabled. Re-ordered writes are allowed, but, only such that it maintains read/write coherency. This is with the restrictive ordering semantics that drives usually ship with by default. You can turn on "re-order at will" through a mode page. Waiting for Terry's long winded response to this thread, Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 2 13:14:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA27819 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 13:14:35 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA27790; Fri, 2 Oct 1998 13:14:29 -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 WAA21117; Fri, 2 Oct 1998 22:14:07 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (VMailer, from userid 101) id 2CF841458; Fri, 2 Oct 1998 22:03:53 +0200 (CEST) Date: Fri, 2 Oct 1998 22:03:53 +0200 From: Ollivier Robert To: current@FreeBSD.ORG, "FreeBSD SCSI Users' list" Subject: Re: ahc & CAM: strange diagnostic Message-ID: <19981002220353.A17421@keltia.freenix.fr> Reply-To: "FreeBSD SCSI Users' list" Mail-Followup-To: current@FreeBSD.ORG, FreeBSD SCSI Users' list References: <19980929082453.A328@nagual.pp.ru> <19980930011432.B15508@keltia.freenix.fr> <19980930154002.A14288@matti.ee> <19980930235134.B24498@keltia.freenix.fr> <19981002153211.A13506@matti.ee> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.4i In-Reply-To: <19981002153211.A13506@matti.ee>; from Vallo Kallaste on Fri, Oct 02, 1998 at 03:32:11PM +0300 X-Operating-System: FreeBSD 3.0-BETA/ELF ctm#4660 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ cross-post to "scsi" and FU2 "scsi" ] According to Vallo Kallaste: > The string PCI-4.11.00 was before updating PCI-4.03.xx , I can't remember > exactly. I can restore the old version if there are need for that. Hmmm, mine is 4.08.00 and I have the 4.09.00 upgrade. Time to check on ASUS and/or Symbios for a new upgrade (although having no problem makes me vary of updating it). > ncr0: rev 0x03 int a irq 9 on pci0.9.0 > da0 at ncr0 bus 0 target 5 lun 0 > da0: Fixed Direct Access SCSI2 device > da0: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled > da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) Funny. My IBM drives report an offset of 15 with the ASUS and my new VikingII reports 8 on the built-in 7880 UW board... [ASUS SC-875] da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) [Adaptec 7880/UW] da0 at ahc0 bus 0 target 6 lun 0 da0: Fixed Direct Access SCSI2 device da0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) What is the exact meaning of "offset" ? And what is the difference between the 4.5WSE and the 4.5WLS model of VikingII (I don't have the complete manual) ? -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-BETA #0: Sat Sep 19 23:38:25 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 2 15:04:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA12731 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 15:04:18 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA12595; Fri, 2 Oct 1998 15:04:01 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA12256; Fri, 2 Oct 1998 15:03:42 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpd012230; Fri Oct 2 15:03:41 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA21941; Fri, 2 Oct 1998 15:03:35 -0700 (MST) From: Terry Lambert Message-Id: <199810022203.PAA21941@usr08.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: gibbs@plutotech.com (Justin T. Gibbs) Date: Fri, 2 Oct 1998 22:03:35 +0000 (GMT) Cc: julian@whistle.com, Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810021953.NAA12817@pluto.plutotech.com> from "Justin T. Gibbs" at Oct 2, 98 01:46:43 pm X-Mailer: ELM [version 2.4 PL25] 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 > >write caching can screw soft updates if there is any > >major re-ordering of the data written. > > Only if you lose power or have a buggy device. Go read the SCSI spec on > write caching. > > >With tags it doesn't matter if they are re-ordered, as long > >as they are not acknowledged until they are on the platter. > > Tagged transactions may "complete" in a non-FIFO order. "Complete" either > means data transfered into the cache or data safely on the media depending > on whether the cache is enabled. Re-ordered writes are allowed, but, only > such that it maintains read/write coherency. This is with the restrictive > ordering semantics that drives usually ship with by default. You can turn > on "re-order at will" through a mode page. > > Waiting for Terry's long winded response to this thread, I told you so. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 2 15:05:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA12994 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 15:05:46 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA12983; Fri, 2 Oct 1998 15:05:43 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id PAA12488; Fri, 2 Oct 1998 15:58:55 -0600 (MDT) Date: Fri, 2 Oct 1998 15:58:55 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199810022158.PAA12488@narnia.plutotech.com> To: "FreeBSD SCSI Users' list" cc: scsi@FreeBSD.ORG Subject: Re: ahc & CAM: strange diagnostic Newsgroups: pluto.freebsd.scsi In-Reply-To: <19980929082453.A328@nagual.pp.ru> <19980930011432.B15508@keltia.freenix.fr> <19980930154002.A14288@matti.ee> <19980930235134.B24498@keltia.freenix.fr> <19981002153211.A13506@matti.ee> <19981002220353.A17421@keltia.freenix.fr> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-BETA (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> ncr0: rev 0x03 int a irq 9 on pci0.9.0 >> da0 at ncr0 bus 0 target 5 lun 0 >> da0: Fixed Direct Access SCSI2 device >> da0: 40.0MB/s transfers (20.0MHz, offset 16, 16bit), Tagged Queueing Enabled >> da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) > > Funny. My IBM drives report an offset of 15 with the ASUS and my new > VikingII reports 8 on the built-in 7880 UW board... The aic7880 can only handle a sync offset of 15 bytes in narrow mode and 8 bytes in wide mode. This is a restriction of the chip, not the drive. > What is the exact meaning of "offset" ? In synchronous SCSI, the devices of a connection negotiate the clock rate at which data transations occur as well as the size of the sliding data "window" of unacknowledged transactions. The offset is the SCSI term for the window size. So, if a device says it has an offset of 8, it has said that it has buffer space to recieve 8, unacknowledged transactions. This provides some slack for transmission and processing latencies. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 2 15:07:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA13389 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 15:07:29 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA13369; Fri, 2 Oct 1998 15:07:19 -0700 (PDT) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id QAA02024; Fri, 2 Oct 1998 16:06:56 -0600 (MDT) Message-Id: <199810022206.QAA02024@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), julian@whistle.com, Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Fri, 02 Oct 1998 22:03:35 -0000." <199810022203.PAA21941@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Oct 1998 16:00:26 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I told you so. You told me some things that were in-correct and some things that I already knew. Par for the course. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 2 16:38:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA23772 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 16:38:40 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA23755 for ; Fri, 2 Oct 1998 16:38:28 -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 BAA00561 for freebsd-scsi@FreeBSD.ORG; Sat, 3 Oct 1998 01:38:05 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (VMailer, from userid 101) id 05DCA1515; Sat, 3 Oct 1998 01:15:19 +0200 (CEST) Date: Sat, 3 Oct 1998 01:15:19 +0200 From: Ollivier Robert To: "FreeBSD SCSI Users' list" Subject: Weird CAM problem on SC-875 Message-ID: <19981003011519.A433@keltia.freenix.fr> Mail-Followup-To: FreeBSD SCSI Users' list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.4i X-Operating-System: FreeBSD 3.0-BETA/ELF ctm#4695 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've a weird problem... I have two systems at the same CTM cvs-cur level#4695, compiled at the same time (sources a few hours old). One (keltia) is a K6/200 with one SC-875 and one SC-200. The second one (tara) is an Intel Providence with one PPro/200 and one built-in 7880 adapter. camcontrol is working fine on the latter system, showing and modifying the mode pages. camcontrol is spewing the messages below on the first system... -=-=-=- 201 [1:07] root@keltia:~# camcontrol modepage -u 0 -m 8 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory 202 [1:07] root@keltia:~# ll /dev/pass* /dev/xp* crw------- 1 root operator 31, 0 Sep 19 23:45 /dev/pass0 crw------- 1 root operator 31, 1 Sep 19 23:45 /dev/pass1 crw------- 1 root operator 31, 2 Sep 19 23:45 /dev/pass2 crw------- 1 root operator 31, 3 Sep 19 23:45 /dev/pass3 crw------- 1 root operator 31, 4 Sep 19 23:45 /dev/pass4 crw------- 1 root operator 31, 5 Sep 19 23:45 /dev/pass5 crw------- 1 root operator 31, 6 Sep 19 23:45 /dev/pass6 crw------- 1 root operator 31, 7 Sep 19 23:45 /dev/pass7 crw------- 1 root operator 104, 0 Oct 3 00:57 /dev/xpt0 -=-=-=- -=-=-=- 201 [1:08] root@tara:~# camcontrol modepage -u 0 -m 8 IC: 0 ABPF: 0 CAP: 0 DISC: 0 SIZE: 0 WCE: 0 MF: 0 RCD: 0 Demand Retention Priority: 0 Write Retention Priority: 0 Disable Pre-fetch Transfer Length: 65535 Minimum Pre-fetch: 0 Maximum Pre-fetch: 65535 Maximum Pre-fetch Ceiling: 65535 202 [1:08] root@tara:~# ll /dev/pass* /dev/xp* crw------- 1 root operator 31, 0 Sep 26 23:46 /dev/pass0 crw------- 1 root operator 31, 1 Sep 26 23:46 /dev/pass1 crw------- 1 root operator 31, 2 Sep 26 23:46 /dev/pass2 crw------- 1 root operator 31, 3 Sep 26 23:46 /dev/pass3 crw------- 1 root operator 104, 0 Sep 26 23:46 /dev/xpt0 crw------- 1 root operator 104, 1 Sep 26 23:46 /dev/xpt1 -=-=-=- Any ideas ? More info ? dmesg from keltia -=-=-=- ncr0: rev 0x03 int a irq 9 on pci0.11.0 ncr1: rev 0x12 int a irq 11 on pci0.12.0 ... sa1 at ncr0 bus 0 target 4 lun 0 sa1: Removable Sequential Access SCSI2 device sa1: 3.300MB/s transfers sa0 at ncr1 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI2 device sa0: 5.0MB/s transfers (5.0MHz, offset 8) da12 at ncr1 bus 0 target 2 lun 0 da12: Fixed Direct Access SCSI2 device da12: 10.0MB/s transfers (10.0MHz, offset 8), Tagged Queueing Enabled da12: 1030MB (2110812 512 byte sectors: 255H 63S/T 131C) cd1 at ncr1 bus 0 target 3 lun 0 cd1: Removable CD-ROM SCSI2 device cd1: 10.0MB/s transfers (10.0MHz, offset 8) cd1: Attempt to query device size failed: NOT READY, Medium not present da1 at ncr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI2 device da1: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: 40.0MB/s transfers (20.0MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) da2 at ncr0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI2 device da2: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da2: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) -=-=-=- dmesg from tara -=-=-=- ahc0: rev 0x00 int a irq 11 on pci0.9.0 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs da0 at ahc0 bus 0 target 6 lun 0 da0: Fixed Direct Access SCSI2 device da0: 40.0MB/s transfers (20.0MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) -=-=-=- -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-BETA #1: Sat Oct 3 00:56:28 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 2 17:37:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA00598 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 17:37:49 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA00593 for ; Fri, 2 Oct 1998 17:37:48 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id SAA16848; Fri, 2 Oct 1998 18:37:23 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810030037.SAA16848@panzer.plutotech.com> Subject: Re: Weird CAM problem on SC-875 In-Reply-To: <19981003011519.A433@keltia.freenix.fr> from Ollivier Robert at "Oct 3, 98 01:15:19 am" To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Fri, 2 Oct 1998 18:37:23 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (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... > I've a weird problem... I have two systems at the same CTM cvs-cur > level#4695, compiled at the same time (sources a few hours old). > > One (keltia) is a K6/200 with one SC-875 and one SC-200. The second one > (tara) is an Intel Providence with one PPro/200 and one built-in 7880 > adapter. > > camcontrol is working fine on the latter system, showing and modifying the > mode pages. > > camcontrol is spewing the messages below on the first system... > > -=-=-=- > 201 [1:07] root@keltia:~# camcontrol modepage -u 0 -m 8 > camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed > cam_lookup_pass: No such file or directory > > 202 [1:07] root@keltia:~# ll /dev/pass* /dev/xp* > crw------- 1 root operator 31, 0 Sep 19 23:45 /dev/pass0 > crw------- 1 root operator 31, 1 Sep 19 23:45 /dev/pass1 > crw------- 1 root operator 31, 2 Sep 19 23:45 /dev/pass2 > crw------- 1 root operator 31, 3 Sep 19 23:45 /dev/pass3 > crw------- 1 root operator 31, 4 Sep 19 23:45 /dev/pass4 > crw------- 1 root operator 31, 5 Sep 19 23:45 /dev/pass5 > crw------- 1 root operator 31, 6 Sep 19 23:45 /dev/pass6 > crw------- 1 root operator 31, 7 Sep 19 23:45 /dev/pass7 > crw------- 1 root operator 104, 0 Oct 3 00:57 /dev/xpt0 > -=-=-=- Do you have the passthrough driver configured in the kernel on keltia? Perhaps I should put a "dummy light" in the transport layer to detect this... 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 Oct 2 18:09:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA05154 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 18:09:17 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA05128; Fri, 2 Oct 1998 18:09:14 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id SAA02504; Fri, 2 Oct 1998 18:08:56 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd002479; Fri Oct 2 18:08:54 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA02581; Fri, 2 Oct 1998 18:08:48 -0700 (MST) From: Terry Lambert Message-Id: <199810030108.SAA02581@usr06.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: gibbs@plutotech.com (Justin T. Gibbs) Date: Sat, 3 Oct 1998 01:08:48 +0000 (GMT) Cc: tlambert@primenet.com, gibbs@plutotech.com, julian@whistle.com, Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810022206.QAA02024@pluto.plutotech.com> from "Justin T. Gibbs" at Oct 2, 98 04:00:26 pm X-Mailer: ELM [version 2.4 PL25] 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 told you so. > > You told me some things that were in-correct and some things that > I already knew. Par for the course. Feel free to make his setup work with SCSI write caching enabled. When you do, I will eat crow. Right now, the crow is in your court. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Oct 2 18:25:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA07487 for freebsd-scsi-outgoing; Fri, 2 Oct 1998 18:25:41 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA07479; Fri, 2 Oct 1998 18:25:22 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id LAA18635; Sat, 3 Oct 1998 11:24:50 +1000 Date: Sat, 3 Oct 1998 11:24:50 +1000 From: Bruce Evans Message-Id: <199810030124.LAA18635@godzilla.zeta.org.au> To: Don.Lewis@tsc.tdk.com, gibbs@plutotech.com Subject: Re: filesystem safety and SCSI disk write caching Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>BTW, with softupdates, and tagged command queuing enabled in CAM, there >>is not much of a performance hit from turning off write caching. I >>saw "make buildworld" increase from about 2 hours to 2 hours 5 minutes, >>and "make -j6 buildworld" increase from about 1 hour 30 minutes to >>1 hour 35 minutes. > >In this particular benchmark, perhaps not, but make buildworld is not >indicative of most I/O loads. I think it can be interpreted as showing that the performance hit is very large. `make world' is mostly cpu-bound, and most of it's i/o's are reads (60% here). I guess it spends less than 5 minutes of its time writing (27000 block output operations here). An increase of 5 minutes is very large. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 3 00:36:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA11347 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 00:36:23 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA11340; Sat, 3 Oct 1998 00:36:20 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA00139 (5.67b/IDA-1.5); Sat, 3 Oct 1998 09:35:00 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id AAA04758; Sat, 3 Oct 1998 00:54:44 +0200 (CEST) From: Wilko Bulte Message-Id: <199810022254.AAA04758@yedi.iaf.nl> Subject: Re: filesystem safety and SCSI disk write caching In-Reply-To: <199810021929.NAA11650@pluto.plutotech.com> from "Justin T. Gibbs" at "Oct 2, 98 01:23:27 pm" To: gibbs@plutotech.com (Justin T. Gibbs) Date: Sat, 3 Oct 1998 00:54:44 +0200 (CEST) Cc: Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, 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+ PL38 (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... > >Yuck. Write caching on disks is evil. I've discussed this kind of > >thing at great length with the disk gurus at work. There is consensus: > >write caching is not to be trusted, there are even firmware incarnations > >out there that get confused by a SCSI bus reset and loose track of what > >they have cached. Admittedly this is junk firmware, but it seems to > >happen. > > Your statement doesn't seem to be "write caching is inherently evil", > but "there are many drives with bogus firmware where write caching is > evil". There is a big difference. If you have a sane device and a True, there is a big difference alright. But the problem is that is not easy for an average user to find out how well behaved a disk's fw actuall is. > UPS, write caching is not evil at all. Right. I for one opt for security over a (small ?) performance gain. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW : http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 3 00:56:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA13692 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 00:56:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from bsd.synx.com (rt.synx.com [194.167.81.239]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA13679 for ; Sat, 3 Oct 1998 00:56:09 -0700 (PDT) (envelope-from root@synx.com) Received: from synx.com (rn [192.1.1.241]) by bsd.synx.com (8.6.12/8.6.12) with ESMTP id IAA07052; Sat, 3 Oct 1998 08:55:24 +0100 Message-Id: <199810030755.IAA07052@bsd.synx.com> Date: Sat, 3 Oct 1998 09:55:13 +0200 (CEST) From: Remy NONNENMACHER Reply-To: remy@synx.com Subject: Re: ahc & CAM: strange diagnostic - DGVS Disks temp. To: jason@intercom.com cc: scsi@FreeBSD.ORG In-Reply-To: <361395B8.C050D07A@intercom.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 1 Oct, Jason J. Horton wrote: > How are drive temperatures accessed? obviously that would be useful > for system monitoring(SNMP or otherwise) > Here is the scsi command I use : scsi -f /dev/rsd7c -c '4D 0 76 0 0 0 0 0 20 0' -i 32 's9 i1' It is found as log sense page 36H. Works on SCSI revision 6.0. may not work for older (4 of my 6 disks doesn't have a 36H page). (Temp is Deg. C). RN. IeM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 3 03:28:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA21996 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 03:28:22 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA21991 for ; Sat, 3 Oct 1998 03:28:20 -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 MAA02901 for freebsd-scsi@FreeBSD.ORG; Sat, 3 Oct 1998 12:28:00 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (VMailer, from userid 101) id 8B9ED1515; Sat, 3 Oct 1998 11:36:36 +0200 (CEST) Date: Sat, 3 Oct 1998 11:36:36 +0200 From: Ollivier Robert To: freebsd-scsi@FreeBSD.ORG Subject: Re: Weird CAM problem on SC-875 Message-ID: <19981003113636.A2657@keltia.freenix.fr> Mail-Followup-To: freebsd-scsi@FreeBSD.ORG References: <19981003011519.A433@keltia.freenix.fr> <199810030037.SAA16848@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.4i In-Reply-To: <199810030037.SAA16848@panzer.plutotech.com>; from Kenneth D. Merry on Fri, Oct 02, 1998 at 06:37:23PM -0600 X-Operating-System: FreeBSD 3.0-BETA/ELF ctm#4695 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Kenneth D. Merry: > Do you have the passthrough driver configured in the kernel on keltia? Oh boy, my face is red. I was so sure I had it that I didn't check for it :-( Sorry. *-<:) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-BETA #1: Sat Oct 3 00:56:28 CEST 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 3 07:35:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA13520 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 07:35:31 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail.kersur.net (mail.kersur.net [199.79.199.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA13512 for ; Sat, 3 Oct 1998 07:35:29 -0700 (PDT) (envelope-from dswartz@druber.com) Received: from manticore (manticore.druber.com [207.180.95.108]) by mail.kersur.net (8.8.8/8.8.8) with SMTP id KAA05332 for ; Sat, 3 Oct 1998 10:36:12 -0400 (EDT) Message-Id: <3.0.5.32.19981003103509.0094e6f0@mail.kersur.net> X-Sender: druber@mail.kersur.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sat, 03 Oct 1998 10:35:09 -0400 To: freebsd-scsi@FreeBSD.ORG From: Dan Swartzendruber Subject: dumping with CAM kernel? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I had sent email awhile back to the -stable list about a panic I ran into on 2.2.7-STABLE, using quotas. I couldn't provide a trace, because the system didn't seem to be taking a dump. I was managing the system remotely, so I couldn't see what was happening. Yesterday, I got to run the repro testcase while looking at the console. When the system panicked, it did in fact try to take a dump. However, the ahc driver coughed up a few furballs about SCB's and aborted. I have done this 3 times and gotten somewhat different messages each time. I don't have more precise info, since I haven't yet gotten remote console access working for that machine. This is a 2.2.7-STABLE system with the most recent CAM patches. The system has onboard 7880 driving several UW drives, and onboard 7860 driving the CDROM (this is a Dell server). It's hard to believe it's a configurating/wiring/termination issue, since the machine works flawlessly under normal conditions. Any ideas? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 3 09:57:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA24804 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 09:57:16 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA24799 for ; Sat, 3 Oct 1998 09:57:13 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id KAA13245; Sat, 3 Oct 1998 10:56:51 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199810031656.KAA13245@panzer.plutotech.com> Subject: Re: dumping with CAM kernel? In-Reply-To: <3.0.5.32.19981003103509.0094e6f0@mail.kersur.net> from Dan Swartzendruber at "Oct 3, 98 10:35:09 am" To: dswartz@druber.com (Dan Swartzendruber) Date: Sat, 3 Oct 1998 10:56:51 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (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 Swartzendruber wrote... > > I had sent email awhile back to the -stable list about a panic I ran into > on 2.2.7-STABLE, using quotas. I couldn't provide a trace, because the > system didn't seem to be taking a dump. I was managing the system > remotely, so I couldn't see what was happening. Yesterday, I got to run > the repro testcase > while looking at the console. When the system panicked, it did in fact try > to take a dump. However, the ahc driver coughed up a few furballs about > SCB's and aborted. I have done this 3 times and gotten somewhat different > messages each time. I don't have more precise info, since I haven't yet > gotten remote console access working for that machine. This is a 2.2.7-STABLE > system with the most recent CAM patches. The system has onboard 7880 driving > several UW drives, and onboard 7860 driving the CDROM (this is a Dell server). > It's hard to believe it's a configurating/wiring/termination issue, since the > machine works flawlessly under normal conditions. Any ideas? Dumps were broken for a while in CAM because (I think) of the order some of the shutdown hooks were called. Basically, the shutdown hook that Justin uses to reset the Adaptec board to a "known" state was getting called before the dump routine in the da driver gets called. So when we tried to run the dump routine, everything just blew up. (no sequencer running on the card, all the registers are set wrong, etc. etc.) Justin finally figured out and fixed the problem around the time we put CAM into -current. We haven't released another -stable snapshot yet. That'll probably happen after 3.0 goes out. I'm not sure what kind of environment you've got it in, but if you can, you might want to put a serial console on it and enable DDB. Then you can capture a stack trace of the problem at least. If that's not possible, I guess you'll probably have to wait until we get another -stable snapshot out. That problem bugged me for a good while, because I had a bad RAM setup in my home machine (too much capacitance load), and couldn't see the panic messages to figure out whether it was a parity problem or something else. I finally setup a serial console, and I was able to see what the problem was. (Or rather see that it wasn't a parity error...) 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 Oct 3 10:12:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA26569 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 10:12:04 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from mail.kersur.net (mail.kersur.net [199.79.199.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA26540 for ; Sat, 3 Oct 1998 10:11:58 -0700 (PDT) (envelope-from dswartz@druber.com) Received: from manticore (manticore.druber.com [207.180.95.108]) by mail.kersur.net (8.8.8/8.8.8) with SMTP id NAA09336; Sat, 3 Oct 1998 13:12:38 -0400 (EDT) Message-Id: <3.0.5.32.19981003131135.0094fab0@mail.kersur.net> X-Sender: druber@mail.kersur.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sat, 03 Oct 1998 13:11:35 -0400 To: "Kenneth D. Merry" From: Dan Swartzendruber Subject: Re: dumping with CAM kernel? Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810031656.KAA13245@panzer.plutotech.com> References: <3.0.5.32.19981003103509.0094e6f0@mail.kersur.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:56 AM 10/3/98 -0600, Kenneth D. Merry wrote: >Dan Swartzendruber wrote... > >Dumps were broken for a while in CAM because (I think) of the order some >of the shutdown hooks were called. Basically, the shutdown hook that >Justin uses to reset the Adaptec board to a "known" state was getting >called before the dump routine in the da driver gets called. So when we >tried to run the dump routine, everything just blew up. (no sequencer >running on the card, all the registers are set wrong, etc. etc.) > >Justin finally figured out and fixed the problem around the time we put >CAM into -current. We haven't released another -stable snapshot yet. >That'll probably happen after 3.0 goes out. Thanks, I finally got a dump on a non-CAM system here at home, but it's nice to know I wasn't hallucinating. >I'm not sure what kind of environment you've got it in, but if you can, you >might want to put a serial console on it and enable DDB. Then you can capture >a stack trace of the problem at least. If that's not possible, I guess >you'll probably have to wait until we get another -stable snapshot out. Actually, I'm in the process of setting of a remote monitoring system for a bunch of the servers. Each one will have serial0 connected to a terminal server port. Each server's /boot.config will say '-P' to probe for the (nonexistent) keyboard. I'm finishing up (RSN) the daemon that runs on a workstation and monitors all of the console ports. The idea is to let an admin telnet to a specific port on the workstation and pull up a console session for that server (complete with the last N lines of console output, etc...) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 3 12:02:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA13423 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 12:02:56 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from localhost.localdomain (ppp-112-61.villette.club-internet.fr [194.158.112.61]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA13352; Sat, 3 Oct 1998 12:02:40 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (groudier@localhost) by localhost.localdomain (8.8.4/8.8.4) with SMTP id UAA01820; Sat, 3 Oct 1998 20:09:31 +0200 X-Authentication-Warning: localhost.localdomain: groudier owned process doing -bs Date: Sat, 3 Oct 1998 20:09:26 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Howard Lew cc: Dan Busarow , freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: NCR 53c875 SCSI Problems 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 On Wed, 30 Sep 1998, Howard Lew wrote: > On Sun, 27 Sep 1998, Gerard Roudier wrote: > > > The FreeBSD ncr driver does not read the user-setup from NVRAM and it is > > not possible to tell it about the BUS width at boot time. So, the WIDE > > negotiation has every chance to occur with great success and, as a result, > > will break any further data transfer between the controller and the > > device. > > > > Yes. This appears to be the problem. > > Because the driver doesn't seem to be able to correctly identify the bus > width, I think it would be a better idea to read the NVRAM values if they Wide and Narrow devices can share the same SCSI bus. This has been the result of T10 standards being careful about compatibility issues. But from device (a controller is a device) point of view, a Wide device is always connected to a Wide bus and a Narrow device is always connected to a Narrow bus. One of the tricks is that a Wide device can be driven using only the Narrow subset of signals of a real (or imaginary) Wide bus. > are available. Otherwise, those of us (anyone really) using a SCSI hard > drive that supports a WIDE bus but is running it on a NARROW bus connector My opinion is that connecting a Wide controller to a Wide device using a Narrow SCSI connector is beyond SCSI specifications. The NVRAM when present and read by the driver may help accomodate this configuration, but with controllers that haven't NVRAM, we are stuck when it is not possible to tell the driver about. > on a NCR/Symbios 53c875 card may run into this same problem. > > Unfortunately, it is not a simple problem to fix unless you already have a > FreeBSD system that is bootable off of another drive. If this is the > case, the fix is trivial by modifying ncr.c Using a working system to apply a work-around in order to be able to boot a broken system is quite usual. ;-) Modifying ncr.c, as I suggested, is just a hack for personnal convenience that has the effect to definitely narrow all 53C8XX controllers at driver level. It is not an acceptable fix at all. > But imagine a user trying to install FreeBSD and boot from boot.flp and > failing each time when the controller isn't able to talk to the hard drive > after switching to the WIDE bus. I think this is a serious enough problem > to require a fix... If you want to be nice with such users, then you must use a default driver setup that would neither negotiate Wide, nor accept Wide negotiation until some user intervention. I am not sure such a proposal will be accepted. A boot command option that would tell the driver that it must only drive devices (or part of devices) in Narrow mode (until it is told different) is probably the only acceptable solution. I donnot know if this is possible with FreeBSD. Regards, Gerard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 3 15:39:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA10926 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 15:39:58 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from www2.shoppersnet.com (shoppersnet.com [204.156.152.112]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA10901; Sat, 3 Oct 1998 15:39:50 -0700 (PDT) (envelope-from digital@www2.shoppersnet.com) Received: from localhost (digital@localhost) by www2.shoppersnet.com (8.8.8/8.8.8) with SMTP id PAA12103; Sat, 3 Oct 1998 15:41:25 -0700 (PDT) (envelope-from digital@www2.shoppersnet.com) Date: Sat, 3 Oct 1998 15:41:25 -0700 (PDT) From: Howard Lew To: Gerard Roudier cc: Dan Busarow , freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: NCR 53c875 SCSI Problems 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 On Sat, 3 Oct 1998, Gerard Roudier wrote: > > On Wed, 30 Sep 1998, Howard Lew wrote: > > > On Sun, 27 Sep 1998, Gerard Roudier wrote: > > > > > The FreeBSD ncr driver does not read the user-setup from NVRAM and it is > > > not possible to tell it about the BUS width at boot time. So, the WIDE > > > negotiation has every chance to occur with great success and, as a result, > > > will break any further data transfer between the controller and the > > > device. > > > > > > > Yes. This appears to be the problem. > > > > Because the driver doesn't seem to be able to correctly identify the bus > > width, I think it would be a better idea to read the NVRAM values if they > > Wide and Narrow devices can share the same SCSI bus. This has been the > result of T10 standards being careful about compatibility issues. But > from device (a controller is a device) point of view, a Wide device is > always connected to a Wide bus and a Narrow device is always connected to > a Narrow bus. One of the tricks is that a Wide device can be driven using > only the Narrow subset of signals of a real (or imaginary) Wide bus. > Actually this drive has a SCA connector so that it can be connected either to a Wide or Narrow bus. In other words, the bus type depends on whether I choose an 80to50 or 80to68 pin adapter. Thus, it should be okay to use either the Wide or Narrow bus. But if the drive of course had a 68 pin wide connector and I used a 68 to 50 pin adapter, I might reason that the conversion may be causing the bus detection problem. However, this is not the case. > > are available. Otherwise, those of us (anyone really) using a SCSI hard > > drive that supports a WIDE bus but is running it on a NARROW bus connector > > My opinion is that connecting a Wide controller to a Wide device using a > Narrow SCSI connector is beyond SCSI specifications. The NVRAM when > present and read by the driver may help accomodate this configuration, but > with controllers that haven't NVRAM, we are stuck when it is not possible > to tell the driver about. I guess the driver could be "smart" in that after making an assumption that it has correctly identified a device on the "Wide" bus that it try at least once to communicate with the drive. If that attempt fails, the driver should assume that the mode was incorrect and try the "Narrow" bus. Such a method would offer the best compatibility. In other words, the problem is that the driver "guesses" wrong and just goes on its merry way without checking its guess. > > > on a NCR/Symbios 53c875 card may run into this same problem. > > > > Unfortunately, it is not a simple problem to fix unless you already have a > > FreeBSD system that is bootable off of another drive. If this is the > > case, the fix is trivial by modifying ncr.c > > Using a working system to apply a work-around in order to be able to boot > a broken system is quite usual. ;-) Yes, agreed. But those without a working system to do that will be out of luck. > Modifying ncr.c, as I suggested, is just a hack for personnal convenience > that has the effect to definitely narrow all 53C8XX controllers at driver > level. It is not an acceptable fix at all. > yes, agreed. > > But imagine a user trying to install FreeBSD and boot from boot.flp and > > failing each time when the controller isn't able to talk to the hard drive > > after switching to the WIDE bus. I think this is a serious enough problem > > to require a fix... > > If you want to be nice with such users, then you must use a default driver > setup that would neither negotiate Wide, nor accept Wide negotiation > until some user intervention. I am not sure such a proposal will be > accepted. > A boot command option that would tell the driver that it must only drive > devices (or part of devices) in Narrow mode (until it is told different) > is probably the only acceptable solution. I donnot know if this is > possible with FreeBSD. > I think the easiest solution would be to assume Wide and try communicating with the drive. After assuming Wide, check the assumption -- if have problems communicating with the drive, assume narrow. If narrow fails, report error. This way, those users using a Wide bus won't be stuck with the Narrow bus and those users using drives on the Narrow bus will have their drives running in the proper bus mode -- in other words, everyone should be happy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 3 18:26:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA03855 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 18:26:55 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03811; Sat, 3 Oct 1998 18:26:40 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id SAA06542; Sat, 3 Oct 1998 18:26:19 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd006510; Sat Oct 3 18:26:10 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id SAA16639; Sat, 3 Oct 1998 18:26:03 -0700 (MST) From: Terry Lambert Message-Id: <199810040126.SAA16639@usr06.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: bde@zeta.org.au (Bruce Evans) Date: Sun, 4 Oct 1998 01:26:03 +0000 (GMT) Cc: Don.Lewis@tsc.tdk.com, gibbs@plutotech.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199810030124.LAA18635@godzilla.zeta.org.au> from "Bruce Evans" at Oct 3, 98 11:24:50 am X-Mailer: ELM [version 2.4 PL25] 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 > >>BTW, with softupdates, and tagged command queuing enabled in CAM, there > >>is not much of a performance hit from turning off write caching. I > >>saw "make buildworld" increase from about 2 hours to 2 hours 5 minutes, > >>and "make -j6 buildworld" increase from about 1 hour 30 minutes to > >>1 hour 35 minutes. > > > >In this particular benchmark, perhaps not, but make buildworld is not > >indicative of most I/O loads. > > I think it can be interpreted as showing that the performance hit is > very large. `make world' is mostly cpu-bound, and most of it's i/o's > are reads (60% here). I guess it spends less than 5 minutes of its time > writing (27000 block output operations here). An increase of 5 minutes > is very large. This is without "noatime". Every inode read, is written, and every directory inode is written multiple times, and all object files and executables, as well as some generated sources, are written. If you read the Ganger/Patt paper, you will see that soft updates is within 5% of memory speed for most uses. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 3 18:37:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA06065 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 18:37:58 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA06048; Sat, 3 Oct 1998 18:37:50 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id LAA14507; Sun, 4 Oct 1998 11:37:22 +1000 Date: Sun, 4 Oct 1998 11:37:22 +1000 From: Bruce Evans Message-Id: <199810040137.LAA14507@godzilla.zeta.org.au> To: bde@zeta.org.au, tlambert@primenet.com Subject: Re: filesystem safety and SCSI disk write caching Cc: Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, gibbs@plutotech.com Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> I think it can be interpreted as showing that the performance hit is >> very large. `make world' is mostly cpu-bound, and most of it's i/o's >> are reads (60% here). I guess it spends less than 5 minutes of its time >> writing (27000 block output operations here). An increase of 5 minutes >> is very large. > >This is without "noatime". Actually, 27000 is with "noatime" on all file systems, and with "async" on all file systems that were written to by my `make world' (/tmp, /var/tmp, MAKEOBJDIRPREFIX = /c/obj and DESTDIR = /c/root). >Every inode read, is written, and every >directory inode is written multiple times, and all object files and >executables, as well as some generated sources, are written. Yes, the default configuration may be much slower than mine. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 3 19:17:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA12598 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 19:17:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA12494; Sat, 3 Oct 1998 19:16:55 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id TAA15523; Sat, 3 Oct 1998 19:16:30 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd015497; Sat Oct 3 19:16:20 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id TAA19402; Sat, 3 Oct 1998 19:16:15 -0700 (MST) From: Terry Lambert Message-Id: <199810040216.TAA19402@usr06.primenet.com> Subject: Re: filesystem safety and SCSI disk write caching To: bde@zeta.org.au (Bruce Evans) Date: Sun, 4 Oct 1998 02:16:15 +0000 (GMT) Cc: bde@zeta.org.au, tlambert@primenet.com, Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, gibbs@plutotech.com In-Reply-To: <199810040137.LAA14507@godzilla.zeta.org.au> from "Bruce Evans" at Oct 4, 98 11:37:22 am X-Mailer: ELM [version 2.4 PL25] 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 can be interpreted as showing that the performance hit is > >> very large. `make world' is mostly cpu-bound, and most of it's i/o's > >> are reads (60% here). I guess it spends less than 5 minutes of its time > >> writing (27000 block output operations here). An increase of 5 minutes > >> is very large. > > > >This is without "noatime". > > Actually, 27000 is with "noatime" on all file systems, and with "async" > on all file systems that were written to by my `make world' (/tmp, /var/tmp, > MAKEOBJDIRPREFIX = /c/obj and DESTDIR = /c/root). Even better. We are talking an increase of one hour, 30, to one hour, 35 in trade for soft update without atime and without SCSI write caching enabled. This is from 90 to 95 minutes, or 95/90 = 1.0555. This is a difference of 5.6% to go from zero reliability to 100% reliability, barring hardware failure. In my book, this is overhead *well spent*. I can post (once again) the results of a Novell study on server usage patterns. The 30,000 foot view for a typical server breaks down to: 75% reads 15% writes 8% directory search operations 2% other Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Oct 3 23:00:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA16412 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 23:00:33 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from dingo.cdrom.com (castles144.castles.com [208.214.165.144]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA16397; Sat, 3 Oct 1998 23:00:23 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id XAA02017; Sat, 3 Oct 1998 23:05:00 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810040605.XAA02017@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Bruce Evans cc: tlambert@primenet.com, Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, gibbs@plutotech.com Subject: Re: filesystem safety and SCSI disk write caching In-reply-to: Your message of "Sun, 04 Oct 1998 11:37:22 +1000." <199810040137.LAA14507@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Oct 1998 23:04:58 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> I think it can be interpreted as showing that the performance hit is > >> very large. `make world' is mostly cpu-bound, and most of it's i/o's > >> are reads (60% here). I guess it spends less than 5 minutes of its time > >> writing (27000 block output operations here). An increase of 5 minutes > >> is very large. > > > >This is without "noatime". > > Actually, 27000 is with "noatime" on all file systems, and with "async" > on all file systems that were written to by my `make world' (/tmp, /var/tmp, > MAKEOBJDIRPREFIX = /c/obj and DESTDIR = /c/root). > > >Every inode read, is written, and every > >directory inode is written multiple times, and all object files and > >executables, as well as some generated sources, are written. > > Yes, the default configuration may be much slower than mine. I can definitely back your basic point ('make world' is CPU bound) up. On a 4-way Xeon system with slow disks we were still able to get down around 40 minutes. -- \\ 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 Oct 3 23:16:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA18285 for freebsd-scsi-outgoing; Sat, 3 Oct 1998 23:16:57 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA18279; Sat, 3 Oct 1998 23:16:54 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id QAA26536; Sun, 4 Oct 1998 16:16:24 +1000 Date: Sun, 4 Oct 1998 16:16:24 +1000 From: Bruce Evans Message-Id: <199810040616.QAA26536@godzilla.zeta.org.au> To: bde@zeta.org.au, mike@smith.net.au Subject: Re: filesystem safety and SCSI disk write caching Cc: Don.Lewis@tsc.tdk.com, freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG, gibbs@plutotech.com, tlambert@primenet.com Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Yes, the default configuration may be much slower than mine. > >I can definitely back your basic point ('make world' is CPU bound) up. >On a 4-way Xeon system with slow disks we were still able to get down >around 40 minutes. Er, that shows that it is i/o bound on systems with so much CPU. I got it down to 75 minutes on 1-way K6-233 with 1 IDE disk before it was bloated by perl5 and transition to elf. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message