From owner-freebsd-scsi Sun Jan 26 01:50:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA29642 for freebsd-scsi-outgoing; Sun, 26 Jan 1997 01:50:35 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA29636 for ; Sun, 26 Jan 1997 01:50:31 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA16387 for freebsd-scsi@FreeBSD.org; Sun, 26 Jan 1997 10:50:30 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id KAA27870; Sun, 26 Jan 1997 10:27:05 +0100 (MET) Message-ID: Date: Sun, 26 Jan 1997 10:27:05 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.org (FreeBSD SCSI list) Subject: Re: Tape Backup Drive Not working. References: <10798.199701260129@pitcairn.cogsci.ed.ac.uk> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <10798.199701260129@pitcairn.cogsci.ed.ac.uk>; from Richard Tobin on Jan 26, 1997 01:29:03 +0000 Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Richard Tobin wrote: > > Hmm. I wonder if there's any reason to _not_ set the PF bit by > > default? > > Well, as you say, all SCSI-2 devices should be happy with it. So we only need to know which drives wouldn't grok it. Since people usually tend to not respond to surveys of this kind, it's probably the only `solution' to bring in the change, and see who would complain. The Archive Viper 150 is already in the quirks, i would probably better add an entry for the Wangtek 5150ES in advance (and also one for the older 5099?). Does anybody have experiences with the Wangtek 5525ES? Does it claim to be SCSI-2 or SCSI-1? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sun Jan 26 03:41:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA02995 for freebsd-scsi-outgoing; Sun, 26 Jan 1997 03:41:22 -0800 (PST) Received: from vector.jhs.no_domain (slip139-92-4-228.mu.de.ibm.net [139.92.4.228]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA02973 for ; Sun, 26 Jan 1997 03:41:10 -0800 (PST) Received: (from jhs@localhost) by vector.jhs.no_domain (8.7.5/8.6.9) id CAA05695; Sun, 26 Jan 1997 02:50:05 +0100 (MET) Date: Sun, 26 Jan 1997 02:50:05 +0100 (MET) Message-Id: <199701260150.CAA05695@vector.jhs.no_domain> To: scsi@freebsd.org Subject: sea0 boot From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Organization: Vector Systems Ltd. X-Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Tel: +49.89.268616 X-Fax: +49.89.2608126 X-ISDN: +49.89.26023276 X-Web: http://www.freebsd.org/~jhs/ Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anyone out there booting succesfully off a sea0 device ? I can't seem to, & `man sea' implies an IDE cohabiting, which probably is normally used for booting. ( which isn't the case here (I pulled the IDE card & drive, 'cos it's got a MesDog FS I don't want to zap just yet). I'm wondering if sea0 is perhaps tested for running but untested for booting ? I've tested my scsi disk on another system, & it boots multi user so all is OK in terms of content, but on the sea0 card, it stops at the first bar of the spinner after "text=0xda000" BTW when I try a manual boot with fd(0,a)/kernel (a currrent kernel) it hangs just after "text=0xcf000 " I have 2 cards here (not in simultaneously): a Qtronix TDC-8850 TDC-885 a Future Domain TMC885 & when i try the 2.1.6 flops with a kernel -c, it resets shortly after the spinner. I have a 100M BSD disk, no fdisk pollution :-) PS please leave me on CC line, as I've only just despatched a subscribe scsi to majordomo Thanks Julian --- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-scsi Sun Jan 26 03:48:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA03202 for freebsd-scsi-outgoing; Sun, 26 Jan 1997 03:48:58 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA03197 for ; Sun, 26 Jan 1997 03:48:54 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id MAA17430 for scsi@freebsd.org; Sun, 26 Jan 1997 12:31:32 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.8.4/8.8.2) id MAA04164; Sun, 26 Jan 1997 12:04:46 +0100 (MET) Message-ID: Date: Sun, 26 Jan 1997 12:04:46 +0100 From: andreas@klemm.gtn.com (Andreas Klemm) To: scsi@freebsd.org Subject: fbsd-current: data overrun of 510 bytes detected. Forcing a retry. X-Mailer: Mutt 0.55-PL15 Mime-Version: 1.0 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk When running bonnie on my 3rd SCSI disk I get the following messages after a couple of seconds: sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. It doesn't hang the system and the messages stop if I stop bonnie. I have on scsi controller (2940) with Firmware 1.16 if I remember right. This is my kernel config file: machine "i386" cpu "I586_CPU" ident BISDN maxusers 64 options INET #Internet communications protocols options FFS #Fast filesystem options PROCFS #Process filesystem options "COMPAT_43" options SCSI_DELAY=8 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow ordinary users to take the # console - this is useful for X. options "MAXCONS=4" # Number of virtual SCO compat consoles options IPFIREWALL #firewall options IPFIREWALL_VERBOSE #print information about options "IPFIREWALL_VERBOSE_LIMIT=100" #limit verbosity options TELES_HAS_MEMCPYB # bisdn 0.97 options SYSVSHM,SYSVSEM,SYSVMSG # System V shared memory options "IBCS2" # COFF binary compatibility options COMPAT_LINUX # Linux Binary compatibility options SHOW_BUSYBUFS # busy buffers on shutdown ? options AHC_TAGENABLE options AHC_SCBPAGING_ENABLE options AHC_ALLOW_MEMIO options SCSI_REPORT_GEOMETRY options DDB options KTRACE #kernel tracing options MFS #Memory File System config kernel root on sd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 # my hardwired scsi devices, they have always the same SCSI ID ! controller ahc0 controller scbus0 at ahc0 disk sd0 at scbus0 target 0 disk sd1 at scbus0 target 1 disk sd2 at scbus0 target 2 tape st0 at scbus0 target 4 device cd0 at scbus0 target 6 # syscons is the default console driver, resembling an SCO console device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr device lpt0 at isa? port? tty irq 7 vector lptintr device ed0 at isa? port 0x300 net irq 10 iomem 0xcc000 vector edintr # Joystick device joy0 at isa? port "IO_GAME" pseudo-device loop pseudo-device ether pseudo-device log pseudo-device tun 1 pseudo-device pty 16 pseudo-device bpfilter 4 #Berkeley packet filter pseudo-device snp 3 #Snoop device - to look at pty/vty/etc.. pseudo-device gzip pseudo-device vn #Vnode driver (turns a file into a device) pseudo-device speaker # SB = SoundBlaster; PAS = ProAudioSpectrum; GUS = Gravis UltraSound # Controls all sound devices controller snd0 # SoundBlaster DSP driver - for SB, SB Pro, SB16, PAS(emulating SB) device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr # SoundBlaster 16 DSP driver - for SB16 - requires sb0 device device sbxvi0 at isa? drq 5 # SoundBlaster 16 MIDI - for SB16 - requires sb0 device device sbmidi0 at isa? port 0x330 # Yamaha OPL-2/OPL-3 FM - for SB, SB Pro, SB16, PAS device opl0 at isa? port 0x388 #--------------------------------------------------------------------------- # # ISDN - parts of an example config file for bisdn # ------------------------------------------------ # # last edit-date: [Sun May 26 10:35:22 1996] # #--------------------------------------------------------------------------- options IPI_VJ # Van Jacobsen header compression support #options "IPI_DIPA=3" # send ip accounting packets every 3 seconds # Teles S0/16.3 ###################################################### IRQ 9 ## controller tel0 at isa? port 0xd80 net irq 9 vector telintr pseudo-device disdn pseudo-device isdn pseudo-device ipi 4 pseudo-device itel 2 pseudo-device ispy 1 This is the output of dmesg: CALIBRATION not specified - using old calibration method CPU: Pentium (99.47-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 67108864 (65536K bytes) avail memory = 63664128 (62172K bytes) pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x8000005c pcibus_setup(1a): mode1res=0x80000000 (0x80000000) pcibus_check: device 0 is there (id=122d8086) Probing for devices on PCI bus 0: configuration mode 1 allows 32 devices. chip0 rev 2 on pci0:0:0 CPU Inactivity timer: clocks Peer Concurrency: enabled CPU-to-PCI Write Bursting: enabled PCI Streaming: enabled Bus Concurrency: enabled Cache: 256K dual-bank pipelined-burst secondary; L1 enabled DRAM: no memory hole, 66 MHz refresh Read burst timing: x-2-2-2/x-3-3-3 Write burst timing: x-3-3-3 RAS-CAS delay: 3 clocks chip1 rev 2 on pci0:7:0 I/O Recovery Timing: 8-bit 3.5 clocks, 16-bit 3.5 clocks Extended BIOS: disabled Lower BIOS: enabled Coprocessor IRQ13: enabled Mouse IRQ12: disabled Interrupt Routing: A: IRQ11, B: disabled, C: IRQ12, D: disabled MB0: disabled, MB1: disabled chip2 rev 2 on pci0:7:1 mapreg[20] type=1 addr=0000e800 size=0010. Primary IDE: disabled Secondary IDE: disabled vga0 rev 0 int a irq 12 on pci0:10:0 mapreg[10] type=0 addr=f8000000 size=2000000. ahc0 rev 3 int a irq 11 on pci0:12:0 mapreg[10] type=1 addr=0000e400 size=0100. mapreg[14] type=0 addr=f7800000 size=1000. reg20: virtual=0xf6ba9000 physical=0xf7800000 size=0x1000 ahc0: Reading SEEPROM...done. low byte termination disabled, high byte termination enabled ahc0: aic7870 Single Channel, SCSI Id=7, 16/255 SCBs ahc0: Reseting Channel A ahc0: Downloading Sequencer Program...Done ahc0: Probing channel A Choosing drivers for scbus configured at 0 ahc0 waiting for scsi devices to settle scbus0 at ahc0 bus 0 ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahc0: target 0 Tagged Queuing Device sd is configured at 0 sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 2063MB (4226725 512 byte sectors)sd0 at scbus0 target 0 lun 0: with 6703 cyls, 5 heads, and an average 126 sectors/track ahc0: target 1 synchronous at 10.0MHz, offset = 0xf ahc0: target 1 Tagged Queuing Device sd is configured at 1 sd1 at scbus0 target 1 lun 0 sd1: type 0 fixed SCSI 2 sd1: Direct-Access 2063MB (4226725 512 byte sectors)sd1 at scbus0 target 1 lun 0: with 6703 cyls, 5 heads, and an average 126 sectors/track ahc0: target 2 synchronous at 10.0MHz, offset = 0xf ahc0: target 2 Tagged Queuing Device sd is configured at 2 sd2 at scbus0 target 2 lun 0 sd2: type 0 fixed SCSI 2 sd2: Direct-Access 2063MB (4226725 512 byte sectors)sd2 at scbus0 target 2 lun 0: with 6703 cyls, 5 heads, and an average 126 sectors/track ahc0: target 4 synchronous at 4.4MHz, offset = 0x8 st is configured at 0 st0 at scbus0 target 4 lun 0 st0: type 1 removable SCSI 2 st0: Sequential-Access density code 0x0, 512-byte blocks, write-enabled ahc0: target 6 synchronous at 4.0MHz, offset = 0xf cd is configured at 0 cd0 at scbus0 target 6 lun 0 cd0: type 5 removable SCSI 2 cd0: CD-ROM cd present [253041 x 2048 byte records] pci0: uses 33558528 bytes of memory from f7800000 upto f9ffffff. pci0: uses 272 bytes of I/O space from e400 upto e80f. Probing for devices on the ISA bus: sc0: the current keyboard controller command byte 0047 kbdio: new command byte:0064 (set_controller...) kbdio: RESET_KBD return code:00fa kbdio: RESET_KBD status:00aa kbdio: new command byte:0047 (set_controller...) sc0 at 0x60-0x6f irq 1 on motherboard kbdio: new command byte:0046 (set_controller...) kbdio: new command byte:0047 (set_controller...) sc0: VGA color <4 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 10 maddr 0xcc000 msize 16384 on isa ed0: address 00:00:c0:25:fd:2d, type WD8013EPC (16 bit) bpf: ed0 attached sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface bpf: lp0 attached fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in tel0 at 0xd80 irq 9 on isa bpf: ipi0 attached bpf: ipi1 attached bpf: ipi2 attached bpf: ipi3 attached tel0: card type Teles S0/16.3 npx0 on motherboard npx0: INT 16 interface joy0 at 0x201 on isa joy0: joystick sb0 at 0x220 irq 5 drq 1 on isa sb0: sbxvi0 at 0x0 drq 5 on isa sbxvi0: sbmidi0 at 0x330 on isa opl0 at 0x388 on isa opl0: imasks: bio c0000840, tty c003009a, net c0020600 BIOS Geometries: 0:0106fe3f 0..262=263 cylinders, 0..254=255 heads, 1..63=63 sectors 1:0106fe3f 0..262=263 cylinders, 0..254=255 heads, 1..63=63 sectors 2:0106fe3f 0..262=263 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for Device configuration finished. Considering FFS root f/s. configure() finished. bpf: tun0 attached bpf: lo0 attached IP packet filtering initialized, divert disabled, logging limited to 100 packets/entry sd0s1: type 0x6, start 63, end = 1028159, size 1028097 : OK sd0s2: type 0x5, start 1028160, end = 2056319, size 1028160 : OK sd0s3: type 0xa5, start 2056320, end = 4225094, size 2168775 : OK sd0s5: type 0x6, start 1028223, end = 2056319, size 1028097 : OK sd1s1: type 0xa5, start 63, end = 4225094, size 4225032 : OK sd2s1: type 0xa5, start 63, end = 4225094, size 4225032 : OK sd2s1: type 0xa5, start 63, end = 4225094, size 4225032 : OK -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-scsi Sun Jan 26 10:30:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA17890 for freebsd-scsi-outgoing; Sun, 26 Jan 1997 10:30:09 -0800 (PST) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA17884 for ; Sun, 26 Jan 1997 10:30:08 -0800 (PST) Received: from narnia (localhost [127.0.0.1]) by narnia.plutotech.com (8.8.4/8.7.3) with ESMTP id KAA16660; Sun, 26 Jan 1997 10:30:02 -0800 (PST) Message-Id: <199701261830.KAA16660@narnia.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: andreas@klemm.gtn.com (Andreas Klemm) cc: scsi@freebsd.org Subject: Re: fbsd-current: data overrun of 510 bytes detected. Forcing a retry. In-reply-to: Your message of "Sun, 26 Jan 1997 12:04:46 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Jan 1997 10:30:02 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I can reproduce this here and will look into it later today. >When running bonnie on my 3rd SCSI disk I get the following messages >after a couple of seconds: > >sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a r >etry. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sun Jan 26 11:08:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA19277 for freebsd-scsi-outgoing; Sun, 26 Jan 1997 11:08:10 -0800 (PST) Received: from gate.fidata.fi (gate.fidata.fi [193.64.102.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA19270 for ; Sun, 26 Jan 1997 11:08:05 -0800 (PST) Received: from zeta.fidata.fi (zeta.fidata.fi [193.64.102.5]) by gate.fidata.fi (8.8.3/8.8.0) with ESMTP id VAA24869; Sun, 26 Jan 1997 21:07:56 +0200 (EET) Received: (from tomppa@localhost) by zeta.fidata.fi (8.8.5/8.8.0) id VAA25206; Sun, 26 Jan 1997 21:07:55 +0200 (EET) Date: Sun, 26 Jan 1997 21:07:55 +0200 (EET) From: Tomi Vainio Message-Id: <199701261907.VAA25206@zeta.fidata.fi> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) CC: freebsd-scsi@freebsd.org Subject: Re: Tape Backup Drive Not working. In-Reply-To: References: <10798.199701260129@pitcairn.cogsci.ed.ac.uk> Reply-To: tomppa@fidata.fi Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J. Wunsch writes: > for the older 5099?). Does anybody have experiences with the Wangtek > 5525ES? Does it claim to be SCSI-2 or SCSI-1? > (bt0:2:0): "WANGTEK 5525ES SCSI 70Z" type 1 removable SCSI 2 st0(bt0:2:0): Sequential-Access density code 0x0, drive empty I have used this one since FreeBSD 2.0 and it has always worked without any problems. Tomppa -- Tomi Vainio, Fimeko-Data Oy Phone: +358 (0)9 4582421 Mail: tomppa@iki.fi tomppa@fidata.fi Telefax: +358 (0)9 4582425 From owner-freebsd-scsi Sun Jan 26 12:16:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA21585 for freebsd-scsi-outgoing; Sun, 26 Jan 1997 12:16:50 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA21573 for ; Sun, 26 Jan 1997 12:16:47 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id VAA20134; Sun, 26 Jan 1997 21:02:22 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.8.4/8.8.2) id UAA07243; Sun, 26 Jan 1997 20:58:43 +0100 (MET) Message-ID: Date: Sun, 26 Jan 1997 20:58:43 +0100 From: andreas@klemm.gtn.com (Andreas Klemm) To: gibbs@narnia.plutotech.com (Justin T. Gibbs) Cc: scsi@freebsd.org Subject: Re: fbsd-current: data overrun of 510 bytes detected. Forcing a retry. References: <199701261830.KAA16660@narnia.plutotech.com> X-Mailer: Mutt 0.55-PL15 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <199701261830.KAA16660@narnia.plutotech.com>; from "Justin T. Gibbs" on Jan 26, 1997 10:30:02 -0800 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Justin ! Justin T. Gibbs writes: > I can reproduce this here and will look into it later today. Ok, thanks. > >When running bonnie on my 3rd SCSI disk I get the following messages > >after a couple of seconds: > > > >sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. =20 Another thing. Backups using dump still fail when using AHC_TAGENABLE. I started with the following kernel options: options AHC_TAGENABLE options AHC_SCBPAGING_ENABLE options AHC_ALLOW_MEMIO This freezes the SCSI bus when dump starts writing to the=20 QIC tape (5 GB Tandberg). After that I only tried=20 options AHC_SCBPAGING_ENABLE options AHC_ALLOW_MEMIO This resulted in these error messages, which didn't freeze the system. Jan 26 13:16:22 klemm /kernel: st0 at scbus0 target 4 lun 0: timed out whil= e idle, LASTPHASE =3D=3D 0x1, SCSISIGI =3D=3D 0x0 Jan 26 13:16:22 klemm /kernel: SEQADDR =3D=3D 0xc =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00= =00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00=00Jan 26 13:16:22 klemm /k= ernel: SEQADDR =3D=3D 0xc Jan 26 13:16:22 klemm /kernel: ahc0: Issued Channel A Bus Reset. 1 SCBs abo= rted Jan 26 13:16:22 klemm /kernel: sd0 at scbus0 target 0 lun 0: UNIT ATTENTION= asc:29,0 Jan 26 13:16:22 klemm /kernel: sd0 at scbus0 target 0 lun 0: Power on, res= et, or bus device reset occurred Jan 26 13:16:23 klemm /kernel: , retries:4 Jan 26 13:16:23 klemm /kernel: st0 at scbus0 target 4 lun 0: UNIT ATTENTION= asc:29,0 Jan 26 13:16:23 klemm /kernel: st0 at scbus0 target 4 lun 0: Power on, res= et, or bus device reset occurred Jan 26 13:16:23 klemm /kernel: st0: oops not queued Jan 26 13:16:23 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:23 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:23 klemm /kernel: , retries:3 Jan 26 13:16:23 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:23 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:23 klemm /kernel: , retries:2 Jan 26 13:16:23 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:23 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:23 klemm /kernel: , retries:1 Jan 26 13:16:23 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:23 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:23 klemm /kernel: , FAILURE Jan 26 13:16:23 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:23 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:23 klemm /kernel: , retries:4 Jan 26 13:16:23 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:23 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:24 klemm /kernel: , retries:3 Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:24 klemm /kernel: , retries:2 Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:24 klemm /kernel: , retries:1 Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:24 klemm /kernel: , FAILURE Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:24 klemm /kernel: , retries:4 Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:24 klemm /kernel: , retries:3 Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:24 klemm /kernel: , retries:2 Jan 26 13:16:24 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:25 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:25 klemm /kernel: , retries:1 Jan 26 13:16:25 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:25 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:25 klemm /kernel: , FAILURE Jan 26 13:16:25 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:25 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:25 klemm /kernel: , retries:4 Jan 26 13:16:25 klemm /kernel: sd0 at scbus0 target 0 lun 0: NOT READY asc:= 4,1 Jan 26 13:16:25 klemm /kernel: sd0 at scbus0 target 0 lun 0: Logical unit = is in process of becoming ready Jan 26 13:16:25 klemm /kernel: , retries:3 Jan 26 13:17:39 klemm /kernel: sd2 at scbus0 target 2 lun 0: UNIT ATTENTION= asc:29,0 Jan 26 13:17:39 klemm /kernel: sd2 at scbus0 target 2 lun 0: Power on, res= et, or bus device reset occurred Jan 26 13:17:39 klemm /kernel: , retries:4 Jan 26 13:18:02 klemm /kernel: st0 at scbus0 target 4 lun 0: timed out whil= e idle, LASTPHASE =3D=3D 0x1, SCSISIGI =3D=3D 0x0 Jan 26 13:18:02 klemm /kernel: SEQADDR =3D=3D 0x10 Jan 26 13:18:04 klemm /kernel: st0 at scbus0 target 4 lun 0: timed out whil= e idle, LASTPHASE =3D=3D 0x1, SCSISIGI =3D=3D 0x0 Jan 26 13:18:04 klemm /kernel: SEQADDR =3D=3D 0xd Jan 26 13:18:04 klemm /kernel: ahc0: Issued Channel A Bus Reset. 1 SCBs abo= rted Jan 26 13:18:05 klemm /kernel: sd0 at scbus0 target 0 lun 0: UNIT ATTENTION= asc:29,0 Jan 26 13:18:05 klemm /kernel: sd0 at scbus0 target 0 lun 0: Power on, res= et, or bus device reset occurred Jan 26 13:18:05 klemm /kernel: , retries:4 Jan 26 13:18:05 klemm /kernel: sd2 at scbus0 target 2 lun 0: UNIT ATTENTION= asc:29,0 Jan 26 13:18:05 klemm /kernel: sd2 at scbus0 target 2 lun 0: Power on, res= et, or bus device reset occurred Jan 26 13:18:05 klemm /kernel: , retries:4 Jan 26 13:20:01 klemm /kernel: sd1 at scbus0 target 1 lun 0: UNIT ATTENTION= asc:29,0 Jan 26 13:20:01 klemm /kernel: sd1 at scbus0 target 1 lun 0: Power on, res= et, or bus device reset occurred Jan 26 13:20:01 klemm /kernel: , retries:4 Jan 26 13:30:10 klemm reboot: rebooted by root using only this option doesn't make trouble. options AHC_ALLOW_MEMIO Andreas /// From owner-freebsd-scsi Sun Jan 26 12:21:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA21866 for freebsd-scsi-outgoing; Sun, 26 Jan 1997 12:21:15 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA21852 for ; Sun, 26 Jan 1997 12:20:53 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA06605 for freebsd-scsi@freebsd.org; Sun, 26 Jan 1997 21:20:38 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id UAA07131; Sun, 26 Jan 1997 20:56:24 +0100 (MET) Message-ID: Date: Sun, 26 Jan 1997 20:56:24 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@freebsd.org Subject: Re: Tape Backup Drive Not working. References: <10798.199701260129@pitcairn.cogsci.ed.ac.uk> <199701261907.VAA25206@zeta.fidata.fi> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701261907.VAA25206@zeta.fidata.fi>; from Tomi Vainio on Jan 26, 1997 21:07:55 +0200 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Tomi Vainio wrote: (Thanks for the feedback!) > > for the older 5099?). Does anybody have experiences with the Wangtek > > 5525ES? Does it claim to be SCSI-2 or SCSI-1? > > > (bt0:2:0): "WANGTEK 5525ES SCSI 70Z" type 1 removable SCSI 2 > st0(bt0:2:0): Sequential-Access density code 0x0, drive empty Hmm, i assume that's already one of the newer drives? > I have used this one since FreeBSD 2.0 and it has always worked > without any problems. Of course, but that wasn't my question. The question was whether it would continue to work with the PF bit set. Since your drive claims SCSI-2 conformance, it must work then. Anybody around with older drives? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sun Jan 26 14:39:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA29122 for freebsd-scsi-outgoing; Sun, 26 Jan 1997 14:39:48 -0800 (PST) Received: from vector.jhs.no_domain (slip139-92-4-214.mu.de.ibm.net [139.92.4.214]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA29101 for ; Sun, 26 Jan 1997 14:39:34 -0800 (PST) Received: (from jhs@localhost) by vector.jhs.no_domain (8.7.5/8.6.9) id XAA22180; Sun, 26 Jan 1997 23:39:28 +0100 (MET) Date: Sun, 26 Jan 1997 23:39:28 +0100 (MET) Message-Id: <199701262239.XAA22180@vector.jhs.no_domain> To: freebsd-scsi@freebsd.org Subject: sea driver tmc 885 From: "Julian H. Stacey" Reply-To: "Julian H. Stacey" X-Organization: Vector Systems Ltd. X-Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Tel: +49.89.268616 X-Fax: +49.89.2608126 X-ISDN: +49.89.26023276 X-Web: http://www.freebsd.org/~jhs/ Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I asked about 6 hours ago a question about the sea driver, please ignore the question, I was confused by too many simultaneous hardware errors, (my sea card now boots my system) Sorry for the noise ! PS sorry I can't set the subject line to match, but I kept no copy, & I haven't been subscribed to scsi@ yet (not enough elapsed time since majordomo got my subscribe). Julian --- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/ From owner-freebsd-scsi Sun Jan 26 15:20:20 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA01175 for freebsd-scsi-outgoing; Sun, 26 Jan 1997 15:20:20 -0800 (PST) Received: from gate.fidata.fi (gate.fidata.fi [193.64.102.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA01170 for ; Sun, 26 Jan 1997 15:20:17 -0800 (PST) Received: from zeta.fidata.fi (zeta.fidata.fi [193.64.102.5]) by gate.fidata.fi (8.8.3/8.8.0) with ESMTP id BAA29951; Mon, 27 Jan 1997 01:19:32 +0200 (EET) Received: (from tomppa@localhost) by zeta.fidata.fi (8.8.5/8.8.0) id BAA26263; Mon, 27 Jan 1997 01:19:31 +0200 (EET) Date: Mon, 27 Jan 1997 01:19:31 +0200 (EET) From: Tomi Vainio Message-Id: <199701262319.BAA26263@zeta.fidata.fi> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) CC: freebsd-scsi@freebsd.org Subject: Re: Tape Backup Drive Not working. In-Reply-To: References: <10798.199701260129@pitcairn.cogsci.ed.ac.uk> <199701261907.VAA25206@zeta.fidata.fi> Reply-To: tomppa@fidata.fi Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J. Wunsch writes: > > (bt0:2:0): "WANGTEK 5525ES SCSI 70Z" type 1 removable SCSI 2 > > st0(bt0:2:0): Sequential-Access density code 0x0, drive empty > > Hmm, i assume that's already one of the newer drives? > I believe mine has newer one assy. Older drives should have jumper (W2) that sets SCSI-1/SCSI-2 mode and I also have software for this but it never worked with my drive. Tomppa -- Tomi Vainio, Fimeko-Data Oy Phone: +358 (0)9 4582421 Mail: tomppa@iki.fi tomppa@fidata.fi Telefax: +358 (0)9 4582425 From owner-freebsd-scsi Sun Jan 26 15:28:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA01631 for freebsd-scsi-outgoing; Sun, 26 Jan 1997 15:28:08 -0800 (PST) Received: from ami.tom.computerworks.net (AMI.RES.CMU.EDU [128.2.95.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA01624 for ; Sun, 26 Jan 1997 15:28:05 -0800 (PST) Received: from bonkers.taronga.com by ami.tom.computerworks.net with smtp (Smail3.1.29.1 #1) id m0vodyU-0021e4C; Sun, 26 Jan 97 18:26 EST Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id RAA26119; Sun, 26 Jan 1997 17:20:46 -0600 Date: Sun, 26 Jan 1997 17:20:46 -0600 From: peter@taronga.com (Peter da Silva) Message-Id: <199701262320.RAA26119@bonkers.taronga.com> To: j@uriah.heep.sax.de Subject: Re: Tape Backup Drive Not working. Newsgroups: taronga.freebsd.scsi In-Reply-To: References: <10798.199701260129@pitcairn.cogsci.ed.ac.uk> <199701261907.VAA25206@zeta.fidata.fi>,<199701261907.VAA25206@zeta.fidata.fi> Organization: none Cc: scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article , J Wunsch wrote: >Anybody around with older drives? Exabyte 8200 (SCSI-1 with some SCSI-2 stuff), and Emulex MT-02 SCSI-QIC-02 adapter (SCSI-0 ?). From owner-freebsd-scsi Sun Jan 26 16:54:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA08214 for freebsd-scsi-outgoing; Sun, 26 Jan 1997 16:54:14 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA08208 for ; Sun, 26 Jan 1997 16:54:11 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA14099 for scsi@freebsd.org; Mon, 27 Jan 1997 01:54:09 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id BAA08457; Mon, 27 Jan 1997 01:43:59 +0100 (MET) Message-ID: Date: Mon, 27 Jan 1997 01:43:59 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@freebsd.org Subject: Re: Tape Backup Drive Not working. References: <10798.199701260129@pitcairn.cogsci.ed.ac.uk> <199701261907.VAA25206@zeta.fidata.fi>,<199701261907.VAA25206@zeta.fidata.fi> <199701262320.RAA26119@bonkers.taronga.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701262320.RAA26119@bonkers.taronga.com>; from Peter da Silva on Jan 26, 1997 17:20:46 -0600 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Peter da Silva wrote: > >Anybody around with older drives? > > Exabyte 8200 (SCSI-1 with some SCSI-2 stuff), and Emulex MT-02 SCSI-QIC-02 > adapter (SCSI-0 ?). Can you test the PF bit patch there? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Mon Jan 27 02:25:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA29653 for freebsd-scsi-outgoing; Mon, 27 Jan 1997 02:25:15 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id CAA29638; Mon, 27 Jan 1997 02:24:53 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-15.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA28781 (5.67b/IDA-1.5); Mon, 27 Jan 1997 11:24:36 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id LAA08059; Mon, 27 Jan 1997 11:24:01 +0100 (CET) Message-Id: Date: Mon, 27 Jan 1997 11:22:40 +0100 From: se@freebsd.org (Stefan Esser) To: jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) Cc: se@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: 2 NCR controllers, problem. References: <9701242338.AA08766@cabri.obs-besancon.fr> X-Mailer: Mutt 0.58-PL15 Mime-Version: 1.0 In-Reply-To: <9701242338.AA08766@cabri.obs-besancon.fr>; from Jean-Marc Zucconi on Jan 25, 1997 00:38:13 +0100 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jan 25, jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) wrote: > >>>>> Stefan Esser writes: > In fact this is not a problem because that this is the second > controller. I tried to boot after having removed the 1st NCR and the > bios does not recognize the DAT (the machine does not boot however > because the drive has no OS on it). > Of course this does not explain why a 1542 see the DAT (they both use > the same scsi attach routine?) nor why I can make the DAT to appear > when I use scsi(8) You may need to extend the probe wait time: options SCSI_DELAY=30 Regards, STefan From owner-freebsd-scsi Mon Jan 27 11:23:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA23536 for freebsd-scsi-outgoing; Mon, 27 Jan 1997 11:23:25 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA23530 for ; Mon, 27 Jan 1997 11:23:21 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-12.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA06635 (5.67b/IDA-1.5 for ); Mon, 27 Jan 1997 20:23:13 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id UAA09471; Mon, 27 Jan 1997 20:23:18 +0100 (CET) Message-Id: Date: Mon, 27 Jan 1997 20:23:18 +0100 From: se@freebsd.org (Stefan Esser) To: andreas@klemm.gtn.com (Andreas Klemm) Cc: scsi@freebsd.org Subject: Re: fbsd-current: data overrun of 510 bytes detected. Forcing a retry. References: X-Mailer: Mutt 0.58-PL15 Mime-Version: 1.0 In-Reply-To: ; from Andreas Klemm on Jan 26, 1997 12:04:46 +0100 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jan 26, andreas@klemm.gtn.com (Andreas Klemm) wrote: > When running bonnie on my 3rd SCSI disk I get the following messages > after a couple of seconds: > > sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. Sorry, can't answer your questions, but I just wanted to mention, that I do NOT FULLY agree to the recent changes to the SCSI probe messages. And the above clearly shows, which part I do not like :) I really would appreciate, if the old format was retained at least for error messages: - there will be many problem reports with no mention given of the SCSI controller involved - there are now some 30 characters of lead in, and this causes the message to be folded over several lines ... > I have on scsi controller (2940) with Firmware 1.16 if I remember > right. This is my kernel config file: Well, Andreas does it correctly and mentions the controller type. But he has been in this business long enough to know that it might matter and isn't just a "normal" user ... :) Regards, STefan From owner-freebsd-scsi Mon Jan 27 16:58:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA00842 for freebsd-scsi-outgoing; Mon, 27 Jan 1997 16:58:02 -0800 (PST) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA00744; Mon, 27 Jan 1997 16:57:13 -0800 (PST) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA01641; Tue, 28 Jan 97 01:00:50 +0100 Date: Tue, 28 Jan 97 01:00:50 +0100 Message-Id: <9701280000.AA01641@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: se@freebsd.org Cc: se@freebsd.org, freebsd-scsi@freebsd.org In-Reply-To: Subject: Re: 2 NCR controllers, problem. X-Mailer: Emacs Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> Stefan Esser writes: > On Jan 25, jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) wrote: >> >>>>> Stefan Esser writes: >> In fact this is not a problem because that this is the second >> controller. I tried to boot after having removed the 1st NCR and the >> bios does not recognize the DAT (the machine does not boot however >> because the drive has no OS on it). >> Of course this does not explain why a 1542 see the DAT (they both use >> the same scsi attach routine?) nor why I can make the DAT to appear >> when I use scsi(8) > You may need to extend the probe wait time: > options SCSI_DELAY=30 30 is very long! Setting SCSI_DELAY=8 already works :-) Thanks for the tip, Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-scsi Tue Jan 28 07:08:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA18237 for freebsd-scsi-outgoing; Tue, 28 Jan 1997 07:08:42 -0800 (PST) Received: from shell.monmouth.com (pechter@shell.monmouth.com [205.164.220.9]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA18219; Tue, 28 Jan 1997 07:08:38 -0800 (PST) Received: (from pechter@localhost) by shell.monmouth.com (8.8.4/8.7.3) id KAA29318; Tue, 28 Jan 1997 10:08:20 -0500 (EST) From: Bill/Carolyn Pechter Message-Id: <199701281508.KAA29318@shell.monmouth.com> Subject: CD Rom and LUNs To: freebsd-scsi@freebsd.org Date: Tue, 28 Jan 1997 10:08:19 -0500 (EST) Cc: freebsd-questions@freebsd.org 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 X-Loop: FreeBSD.org Precedence: bulk Looks like my $6.50 SCSI Chinon CDROM drive (a great price... I may get one drive for each FreeBSD revision) has the problem of being recognized on all LUNs. It's a Chinon "CDS- 435 M62" single speed SCSI cdrom. Is there a flag or option to have it not try to configure as CD0->CD7. My other CDROM gets configured as CD8. I'm considering hardwiring down the SCSI bus in the config file... Any other suggestions... I haven't looked at the code yet... I'm wondering if this is just a FAQ item? Bill ------------------------------------------------------------------------------- Bill Pechter/Carolyn Pechter | 17 Meredith Drive, Tinton Falls, NJ 07724, 908-389-3592 | pechter@shell.monmouth.com This message brought to you by the letters VAX and the numbers 11 and 780. From owner-freebsd-scsi Tue Jan 28 10:33:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA00343 for freebsd-scsi-outgoing; Tue, 28 Jan 1997 10:33:28 -0800 (PST) Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA00322; Tue, 28 Jan 1997 10:33:13 -0800 (PST) Received: from x14.mi.uni-koeln.de (annexr3-2.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA22870 (5.67b/IDA-1.5); Tue, 28 Jan 1997 19:32:37 +0100 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.4/8.6.9) id TAA03346; Tue, 28 Jan 1997 19:32:06 +0100 (CET) Message-Id: Date: Tue, 28 Jan 1997 19:30:46 +0100 From: se@freebsd.org (Stefan Esser) To: jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) Cc: se@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: 2 NCR controllers, problem. References: <9701280000.AA01641@cabri.obs-besancon.fr> X-Mailer: Mutt 0.58-PL15 Mime-Version: 1.0 In-Reply-To: <9701280000.AA01641@cabri.obs-besancon.fr>; from Jean-Marc Zucconi on Jan 28, 1997 01:00:50 +0100 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Jan 28, jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) wrote: > > You may need to extend the probe wait time: > > > options SCSI_DELAY=30 > > 30 is very long! Setting SCSI_DELAY=8 already works :-) Well, I really thought about suggesting to find out the lowest value working reliably, but I was just to tired from working too long, that day, and supposed you would find out yourself, and in fact you did :) I seem to remember, that 30 seconds is the maximum time allowed for selftest of a SCSI device, before it must be able to reply to an INQUIRY command ... Regards, STefan From owner-freebsd-scsi Tue Jan 28 10:58:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA02222 for freebsd-scsi-outgoing; Tue, 28 Jan 1997 10:58:39 -0800 (PST) Received: from relay.nuxi.com (nuxi.ucdavis.edu [128.120.37.176]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA02199; Tue, 28 Jan 1997 10:58:29 -0800 (PST) Received: from dragon.nuxi.com (reqd-064.ucdavis.edu [128.120.251.184]) by relay.nuxi.com (8.7.6/8.6.12) with ESMTP id KAA17697; Tue, 28 Jan 1997 10:58:33 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.8.4/8.7.3) id KAA06190; Tue, 28 Jan 1997 10:58:24 -0800 (PST) Message-ID: Date: Tue, 28 Jan 1997 10:58:24 -0800 From: obrien@dragon.cs.ucdavis.edu (David O'Brien) To: pechter@shell.monmouth.com (Bill/Carolyn Pechter) Cc: freebsd-scsi@freebsd.org, freebsd-questions@freebsd.org Subject: Re: CD Rom and LUNs References: <199701281508.KAA29318@shell.monmouth.com> X-Mailer: Mutt 0.57-PL4 Mime-Version: 1.0 Reply-To: deobrien@ucdavis.edu Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 In-Reply-To: <199701281508.KAA29318@shell.monmouth.com>; from Bill/Carolyn Pechter on Jan 28, 1997 10:08:19 -0500 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bill/Carolyn Pechter writes: > Looks like my $6.50 SCSI Chinon CDROM drive (a great price... I may get Where in the world can you get this price??? Sounds really good for boxes that only need a CDROM for installs. > one drive for each FreeBSD revision) has the problem of being recognized > on all LUNs. It's a Chinon "CDS- 435 M62" single speed SCSI cdrom. What version of FBSD are you running? My Teac did the same thing. The kernel was changed from 2.2-961014-SNAP to 2.2-ALPHA so that it won't look for multiple LUNs on CDROMs unless it is told to. Too many cheap scsi CDROMs answered to all LUNs. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) From owner-freebsd-scsi Tue Jan 28 15:50:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA19912 for freebsd-scsi-outgoing; Tue, 28 Jan 1997 15:50:54 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA19891 for ; Tue, 28 Jan 1997 15:50:49 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA15952; Wed, 29 Jan 1997 00:50:46 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id AAA17387; Wed, 29 Jan 1997 00:50:20 +0100 (MET) Message-ID: Date: Wed, 29 Jan 1997 00:50:20 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.org (FreeBSD SCSI list) Cc: pechter@shell.monmouth.com (Bill/Carolyn Pechter) Subject: Re: CD Rom and LUNs References: <199701281508.KAA29318@shell.monmouth.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from David O'Brien on Jan 28, 1997 10:58:24 -0800 Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As David O'Brien wrote: > > one drive for each FreeBSD revision) has the problem of being recognized > > on all LUNs. It's a Chinon "CDS- 435 M62" single speed SCSI cdrom. > > What version of FBSD are you running? My Teac did the same thing. The > kernel was changed from 2.2-961014-SNAP to 2.2-ALPHA so that it won't > look for multiple LUNs on CDROMs unless it is told to. Too many cheap > scsi CDROMs answered to all LUNs. Here's the change. Alas, it's a little more complex than i wish, so chances are good that patching will fail. Index: /sys/scsi/scsiconf.c =================================================================== RCS file: /home/cvs/src/sys/scsi/scsiconf.c,v retrieving revision 1.69 retrieving revision 1.74 diff -u -u -r1.69 -r1.74 --- scsiconf.c 1996/11/30 07:39:37 1.69 +++ scsiconf.c 1997/01/14 06:54:16 1.74 @@ -248,10 +248,9 @@ static struct scsidevs knowndevs[] = { -/* od's must be probed before sd's since some of them identify as T_DIRECT */ #if NOD > 0 { - T_OPTICAL, T_OPTICAL, T_REMOV, "MATSHITA", "PD-1 LF-1000", "*", + T_OPTICAL, T_OPTICAL, T_REMOV, "MATSHITA", "PD-1 LF-100*", "*", "od", SC_MORE_LUS }, { @@ -259,7 +258,11 @@ "od", SC_MORE_LUS }, { - T_OPTICAL, T_OPTICAL, T_REMOV, "*", "*", "*", + T_DIRECT, T_OPTICAL, T_REMOV, "MOST", "RMD-5200-S", "*", + "od", SC_ONE_LU + }, + { + T_DIRECT, T_OPTICAL, T_REMOV, "RICOH", "RO-*", "*", "od", SC_ONE_LU }, #endif /* NOD */ @@ -268,10 +271,6 @@ T_DIRECT, T_DIRECT, T_FIXED, "EMULEX", "MD21*" , "*", "sd", SC_MORE_LUS }, - { - T_DIRECT, T_DIRECT, T_FIXED, "*", "*", "*", - "sd", SC_ONE_LU - }, #endif /* NSD */ #if NST > 0 { @@ -306,17 +305,7 @@ T_SEQUENTIAL, T_SEQUENTIAL, T_REMOV, "Quantum", "DLT*", "*", "st", SC_MORE_LUS, 0 }, - { - T_SEQUENTIAL, T_SEQUENTIAL, T_REMOV, "*", "*", "*", - "st", SC_ONE_LU, 0, mode_unktape - }, #endif /* NST */ -#if NCH > 0 - { - T_CHANGER, T_CHANGER, T_REMOV, "*", "*", "*", - "ch", SC_ONE_LU - }, -#endif /* NCH */ #if NCD > 0 #ifndef UKTEST /* make cdroms unrecognised to test the uk driver */ /* @@ -388,6 +377,44 @@ T_READONLY, T_WORM, T_REMOV, "PLASMON", "RF41*", "*", "worm", SC_ONE_LU }, +#endif /* NWORM */ + + /* + * Wildcard entries. Keep them down here below all device + * specific entries, so the above ones can override the type + * driver if necessary. + */ +#if NOD > 0 + { + T_OPTICAL, T_OPTICAL, T_REMOV, "*", "*", "*", + "od", SC_ONE_LU + }, +#endif /* NOD */ +#if NSD > 0 + { + T_DIRECT, T_DIRECT, T_FIXED, "*", "*", "*", + "sd", SC_ONE_LU + }, +#endif /* NSD */ +#if NST > 0 + { + T_SEQUENTIAL, T_SEQUENTIAL, T_REMOV, "*", "*", "*", + "st", SC_ONE_LU, 0, mode_unktape + }, +#endif /* NST */ +#if NCH > 0 + { + T_CHANGER, T_CHANGER, T_REMOV, "*", "*", "*", + "ch", SC_ONE_LU + }, +#endif /* NCH */ +#if NCD > 0 && !defined(UKTEST) + { + T_READONLY, T_READONLY, T_REMOV, "*", "*", "*", + "cd", SC_ONE_LU + }, +#endif /* NCD */ +#if NWORM > 0 { T_WORM, T_WORM, T_REMOV, "*", "*", "*", "worm", SC_ONE_LU -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Tue Jan 28 21:32:49 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA10156 for freebsd-scsi-outgoing; Tue, 28 Jan 1997 21:32:49 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA10142 for ; Tue, 28 Jan 1997 21:32:44 -0800 (PST) Received: (qmail 9332 invoked by uid 1000); 29 Jan 1997 01:05:19 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 28 Jan 1997 15:25:25 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: freebsd-scsi@freebsd.org Subject: NewComer Questions... Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am learning slowly, and just discovered this mailing list. In way of introduction, I am working on a high speed database engine for embedded telephony applications. We need to develop the following functionality: 1. Multi-initiator support 2. DLM 3. Non-stop operation 4. Very large (hundreds of Gigabytes) databases 5. Very fast (400 I/O's per second sustained) databases. Because O/S source is very criticsl for such effort, the ``free'' ones area natural choice. After 2 years or more of Linux usage. I decided (at least for now) to not use it. FreeBSD seems very attractive. My questions to this forum are: 1. Minor device designation for systems with up to 20 disk controllers (PCI), FCAL interfaces (with over 100 targets per bus. controllers with multiple busses, etc. 2. Naming conventions for /dev entries for such beasts. 3. Moving all SCSI devices to a /dev/{r}dsk... 4. Any documents about SCSI HBA driver entry points 5. Anyone interested in helping out Thanx in advance, Simon From owner-freebsd-scsi Tue Jan 28 23:38:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA16182 for freebsd-scsi-outgoing; Tue, 28 Jan 1997 23:38:05 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA16177 for ; Tue, 28 Jan 1997 23:38:01 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id XAA11525; Tue, 28 Jan 1997 23:33:13 -0800 (PST) Message-ID: <32EEFCD5.794BDF32@whistle.com> Date: Tue, 28 Jan 1997 23:31:33 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Simon Shapiro CC: freebsd-scsi@freebsd.org Subject: Re: NewComer Questions... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: > > I am learning slowly, and just discovered this mailing list. > > In way of introduction, I am working on a high speed database > engine for embedded telephony applications. > > We need to develop the following functionality: > > 1. Multi-initiator support I assume you mean in SCSI? we ahve some basic support for that but it requires a SCSI host adapter that supports it.. it hasn't been exercised in years. (I wrote it iwith Peter Dufault but it's a rarely used feature. Or are you alking about several machines sharing a single bus?) > 2. DLM Daringly Lowfat Milk? > 3. Non-stop operation hmm this is a tricky one.. what's your definition of non-stop? > 4. Very large (hundreds of Gigabytes) databases not un heard of.. we have several people into teh > 100MB range.. it does scale, though I have some ideas of some little NITS that will require hitting on the head.. i.e. nomenclomature things not really technical limits. > 5. Very fast (400 I/O's per second sustained) databases. we can get about 100 per disk so with 4 disks :) > > Because O/S source is very criticsl for such effort, the > ``free'' ones area natural choice. > > After 2 years or more of Linux usage. I decided (at least > for now) to not use it. FreeBSD seems very attractive. That's why we use it.. > > My questions to this forum are: > > 1. Minor device designation for systems with up to 20 disk > controllers (PCI), FCAL interfaces (with over 100 targets > per bus. controllers with multiple busses, etc. your nomenclature is confusing me.. FCAL? there are boards with 3 bosses an d2 bisses that are supported. W can support PCI bridges to get more slots > > 2. Naming conventions for /dev entries for such beasts. /dev/{r}sd[0-9][0-9] there is a limit at the moment to about 32 drives per machine (I think) but it's a rather artificial limit and could be removed relativly easily. > > 3. Moving all SCSI devices to a /dev/{r}dsk... not sure what you mean by this..... if you don't like the names there is always mknod:) (so that ca't be what you mean.. it's too easy) > > 4. Any documents about SCSI HBA driver entry points ah there's the rub.. I guess I'm going to have to write that one day.. 6 years isn't too long is it? (since I wrote the code) > > 5. Anyone interested in helping out sure.. but it depends on what you want to do and how much work you are willing to do yourself :) I'm extremely busy these days.. but I can offer advice. justin gibbs might also have good input for you as he's been the person doing the most work recently. > > Thanx in advance, > > Simon From owner-freebsd-scsi Wed Jan 29 04:22:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA26699 for freebsd-scsi-outgoing; Wed, 29 Jan 1997 04:22:10 -0800 (PST) Received: from hda.hda.com (ip65-max1-fitch.ziplink.net [199.232.245.65]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id EAA26694 for ; Wed, 29 Jan 1997 04:22:06 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id HAA08774; Wed, 29 Jan 1997 07:16:57 -0500 From: Peter Dufault Message-Id: <199701291216.HAA08774@hda.hda.com> Subject: Re: NewComer Questions... In-Reply-To: <32EEFCD5.794BDF32@whistle.com> from Julian Elischer at "Jan 28, 97 11:31:33 pm" To: julian@whistle.com (Julian Elischer) Date: Wed, 29 Jan 1997 07:16:56 -0500 (EST) Cc: Shimon@i-Connect.Net, freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > We need to develop the following functionality: > > > > 1. Multi-initiator support > I assume you mean in SCSI? > we ahve some basic support for that but it requires a SCSI host > adapter that supports it.. it hasn't been exercised in years. > (I wrote it iwith Peter Dufault but it's a rarely used feature. > Or are you alking about several machines sharing a single bus?) Only the aha1542b supports it. It breaks on earlier and later versions even on the aha adapter. The only way to resurrect this will be to put it into the NCR and AHC where we have solid support for the firmware. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-scsi Wed Jan 29 12:23:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA19161 for freebsd-scsi-outgoing; Wed, 29 Jan 1997 12:23:45 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA19155 for ; Wed, 29 Jan 1997 12:23:42 -0800 (PST) Received: (qmail 7293 invoked by uid 1000); 29 Jan 1997 21:23:02 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 29 Jan 1997 12:55:07 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: freebsd-scsi@freebsd.org Subject: XXXminpys question Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk When/how is the minphys entry point in an HBA driver called? All we see in the bt and ahc drivers is a comparison between a buf and a constant. In the driver we are writing now, mulltiple controllers, all run with the same driver, can EACH have their own minphys. Actually, like others, it is limited by the scatter-gather DMA engine. The cheapest HBA can have 16 segments in the DBA S/G. The largest can have 8192 currently. May grow larger. What we need, in addition to the clarification above is these answers: a. Does minphys get called for each I/O request, with that I/O's own buf? b. Does minphys get called, at initialization time, once per HBA? c. Does minphys get called only once for ``the driver''? If A is true, we can (nasty) extract the HBA from the device data in buf. If B is true, we need some indication in calling minphys as to which HBA. Ic C is true, we have a problem. In that case, can we manipilate the buf structure when the SCSI command is called in and do only partial I/O by manipulating the b_count and b_resid fields? This is sort of a stalling stump for us so soon response will be appreciated... Thanx! Simon From owner-freebsd-scsi Wed Jan 29 13:52:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA24382 for freebsd-scsi-outgoing; Wed, 29 Jan 1997 13:52:12 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA24374 for ; Wed, 29 Jan 1997 13:52:06 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id WAA05383; Wed, 29 Jan 1997 22:50:10 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id WAA21535; Wed, 29 Jan 1997 22:29:00 +0100 (MET) Message-ID: Date: Wed, 29 Jan 1997 22:29:00 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: Shimon@i-Connect.Net (Simon Shapiro) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: XXXminpys question References: X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Simon Shapiro on Jan 29, 1997 12:55:07 -0800 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Simon Shapiro wrote: > When/how is the minphys entry point in an HBA driver called? I think all that minphys stuff is currently defunct. The magic is in physio(9), and it seems as if it was intended to be called once per each buf: for(i=0;iuio_iovcnt;i++) { while( uio->uio_iov[i].iov_len) { bp->b_bcount = uio->uio_iov[i].iov_len; bp->b_flags = B_BUSY | B_PHYS | B_CALL | bufflags; bp->b_iodone = physwakeup; bp->b_data = uio->uio_iov[i].iov_base; bp->b_bcount = minp( bp); if( minp != minphys) bp->b_bcount = minphys( bp); However, this also makes it very apparent that it can't work: if the provided (by the caller to physio) `minp' is different from teh default minphys(), then the default minphys() will be called in addition to minp, effectively limiting all transfers to 64 KB by now. Of course, rawread(9) and rawwrite(9) don't ever call it with something else than minphys(9) anway. The default minphys(9) uses the constant MAXPHYS as a high watermark. The SCSI minphys routines seem to be called _in addition_ to the physio(9) minphys handling, to make the mess complete (once per call to scsi_strategy(), in sys/scsi/scsi_driver.c). All this needs a redesign. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Wed Jan 29 14:21:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA25739 for freebsd-scsi-outgoing; Wed, 29 Jan 1997 14:21:25 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id OAA25732 for ; Wed, 29 Jan 1997 14:21:20 -0800 (PST) Received: (qmail 9128 invoked by uid 1000); 29 Jan 1997 23:20:40 -0000 Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 29 Jan 1997 13:50:27 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: freebsd-scsi@freebsd.org Subject: SCSI Driver Open/Close Routines Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi there... We observe that in scsi/scsiconf.h the scsi_adapter definition for the (entry points) open /close do not take any arguments, unless the bus is PC98. In the case of PC98, open takes a scsi_link as an argument, but still no argument for close. What we need is two things: 1. We need to be able to open the individual controller, and close it. We need to maintain control over the exact state of each controller, Is it open, closed, etc. This control extends to IF and when a SCSI bus or device are reset and other such details. Part of this need is to be able to communicate with the controller via several methods. Things we need to do are RAID setup, firmware configuration, SNMP and others. The mechanism we see today in FreeBSD does not seem to allow it in the scsi_adapter entry points. Can someone help us understand it? 2. We need to be able to precisely control the access to every device on any SCSI bus on any HBA. This includes allowing/barring access, putting devices in R/O or R/W mode, resetting and blocking resets. The entry points in scsi_device allow that. We also understand from having scsi_device defined for an adapter that the adapter can appear as a device. Question: What will this device be in /dev? Major, minor, naming convention, etc. ..but; For both scsi_adapter and scsi_device, in the drivers code we saw, there is a single, scalar declaration of scsi_adapter and scsi_device. We would like to be able to turn these into arrays (logically). So each HBA is its own scsi_adapter and each HBA is its own scsi_device, with the associated /dev/ entries, as above. thanx for any (polite :-) reply... Simon From owner-freebsd-scsi Wed Jan 29 15:31:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA29472 for freebsd-scsi-outgoing; Wed, 29 Jan 1997 15:31:12 -0800 (PST) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA29467 for ; Wed, 29 Jan 1997 15:31:09 -0800 (PST) Received: from narnia (localhost [127.0.0.1]) by narnia.plutotech.com (8.8.4/8.7.3) with ESMTP id PAA02312; Wed, 29 Jan 1997 15:31:09 -0800 (PST) Message-Id: <199701292331.PAA02312@narnia.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Simon Shapiro cc: freebsd-scsi@freebsd.org Subject: Re: SCSI Driver Open/Close Routines In-reply-to: Your message of "Wed, 29 Jan 1997 13:50:27 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 1997 15:31:09 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >What we need is two things: Simon. You're not the only person concerned with these types of issues. Pluto ended up performing some serious hackery to the FreeBSD SCSI system in order to get the kind of functionality you require. Unfortunatly, there was a large "time to ship" vs. quality tradeoff on the approach. For this reason, I'm starting to architect a CAM based SCSI system for FreeBSD. I believe that it will handle most of your needs and if not, could be easily extended. I invite you to go read the SCSI CAM documents which are availible at ftp.symbios.com and see if a CAM like architecture will suit your needs. I expect to have a minimal CAM system (SCSI disks only) availible in about 1.5 months. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Wed Jan 29 15:53:03 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA00715 for freebsd-scsi-outgoing; Wed, 29 Jan 1997 15:53:03 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA00710 for ; Wed, 29 Jan 1997 15:53:00 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id PAA27486; Wed, 29 Jan 1997 15:50:27 -0800 (PST) Message-ID: <32EFE1E2.ABD322C@whistle.com> Date: Wed, 29 Jan 1997 15:48:50 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Simon Shapiro CC: freebsd-scsi@FreeBSD.ORG Subject: Re: XXXminpys question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: > > When/how is the minphys entry point in an HBA driver called? the adapter has a minphys that cuts down any transfer it couldn't do. It's adapter dependent of course. devices that can't handle their transfer being done in two parts should notice that this has happenned and abort the operation. (e.g. some tape drives). the adapter minphys is called from the genereic scsi minphys() scsi_minphys() in scsi_driver.c which is called by the device specific driver ( e.g sd.c) in the strategy() function. > All we see in the bt and ahc drivers is a comparison between a buf and a > constant. and a truncation of the transfer.. the higher level code will notice on return that not all the data was transfered an dwill re-try for the rest. > > In the driver we are writing now, mulltiple controllers, all run with the > same driver, can EACH have their own minphys.? Yes, you can put any code you wish in there. it could be a comparison with a field in the device's local structure.. > Actually, like others, it is > limited by the scatter-gather DMA engine. The cheapest HBA can have 16 > segments in the DBA S/G. The largest can have 8192 currently. May grow > larger. 16, yuk.. even the aha had 17, the reason for th extra one is to allow a guaranteed ability to transfer 64K, as the first and lat pages migh tbe only partial in the casae of a non-alligned transfer.. the bt has LOTS and the aha has 17. note however htat the present limit inside the kernel is for 64K trnasfers so you will not get a request for > than that. This should be fixed but is not yet.. > > What we need, in addition to the clarification above is these answers: > > a. Does minphys get called for each I/O request, with that I/O's own buf? YES. that's how it can truncate the transfer to break it up to multiple transfers. > b. Does minphys get called, at initialization time, once per HBA? NO > c. Does minphys get called only once for ``the driver''? NO > If A is true, we can (nasty) extract the HBA from the device data in buf. you mean "can we"? no and yes.. you could trivially extract it from bp->b_driver2 where the generic scsi code stores it. It is not ALWAYS htere however. It would be a trivial change for scsi_minphys() which has that information to make sure it is always set before calling the HBA minphys. The information is in the scsi_link structure. bp->b_driver2 is used to hold a pointer for this some times and scsi_minphys has a pointer to this. bp->b_driver2 = sc->link; would be all that is needed to add to scsi_minphys. > If B is true, we need some indication in calling minphys as to which HBA. it's not true. > Ic C is true, we have a problem. In that case, can we manipilate the buf it's not true > structure when the SCSI command is called in and do only partial I/O by > manipulating the b_count and b_resid fields? that's what the system already does > > This is sort of a stalling stump for us so soon response will be > appreciated... > > Thanx! > > Simon julian From owner-freebsd-scsi Wed Jan 29 16:03:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA01321 for freebsd-scsi-outgoing; Wed, 29 Jan 1997 16:03:42 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA01314 for ; Wed, 29 Jan 1997 16:03:38 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id PAA27711; Wed, 29 Jan 1997 15:59:19 -0800 (PST) Message-ID: <32EFE3F5.237C228A@whistle.com> Date: Wed, 29 Jan 1997 15:57:41 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Joerg Wunsch CC: Simon Shapiro , freebsd-scsi@freebsd.org Subject: Re: XXXminpys question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > The SCSI minphys routines seem to be called _in addition_ to the > physio(9) minphys handling, to make the mess complete (once per call > to scsi_strategy(), in sys/scsi/scsi_driver.c). exactly.. the adapter or device might have more restrictions than hte rest of the kernel, so they need a say. > > All this needs a redesign. > definitly.. From owner-freebsd-scsi Wed Jan 29 16:43:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA04235 for freebsd-scsi-outgoing; Wed, 29 Jan 1997 16:43:00 -0800 (PST) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA04227 for ; Wed, 29 Jan 1997 16:42:56 -0800 (PST) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.8.4/8.8.4) with SMTP id QAA28762; Wed, 29 Jan 1997 16:39:37 -0800 (PST) Message-ID: <32EFED68.2F1CF0FB@whistle.com> Date: Wed, 29 Jan 1997 16:38:00 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Simon Shapiro CC: freebsd-scsi@freebsd.org Subject: Re: SCSI Driver Open/Close Routines References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Simon Shapiro wrote: > > Hi there... > > We observe that in scsi/scsiconf.h the scsi_adapter definition for the > (entry points) open /close do not take any arguments, unless the bus is > PC98. > > In the case of PC98, open takes a scsi_link as an argument, but still no > argument for close. > > What we need is two things: > > 1. We need to be able to open the individual controller, and close it. > We need to maintain control over the exact state of each controller, > Is it open, closed, etc. Adapters are neither open or closed. they just "are". An adapter takes asynchronous commands fro higher level device drivers but keeps almost no state itself 9except as to how many more simultanious operations it can support (known as "opennings") > This control extends to IF and when a SCSI > bus or device are reset and other such details. Part of this need is > to be able to communicate with the controller via several methods. what do you need totalk to the adapter for fro raid setup? does the adapter do the raid itself? > Things we need to do are RAID setup, firmware configuration, SNMP and > others. The mechanism we see today in FreeBSD does not seem to allow > it in the scsi_adapter entry points. Can someone help us understand it? My sugestion is to attach a scsi device to the ADAPTER's scsi sddress in the devices array. this device could use a differnt 'adapter entrypoint structure, to call differnt routines . > > 2. We need to be able to precisely control the access to every device on > any SCSI bus on any HBA. This includes allowing/barring access, putting > devices in R/O or R/W mode, resetting and blocking resets. The entry > points in scsi_device allow that. We also understand from having > scsi_device defined for an adapter that the adapter can appear as a > device. Question: What will this device be in /dev? Major, minor, > naming convention, etc. whatever you define it to be you haven't written the driver for it yet :) we just provided the hooks.. you supply the driver.. the major is just an nteger to indentify your driver.. it's assigned to you.. teh minor is passed to the driver.. you can define it to be used in any way you want.. usually some bits are reserved to specify a unit number. Other uses include: using some bits to define operating mode, or using some bits to indicate debug features.. that's totally up to you.. we just pass it straight to you.. > > ..but; For both scsi_adapter and scsi_device, in the drivers code we saw, > there is a single, scalar declaration of scsi_adapter and scsi_device. > We would like to be able to turn these into arrays (logically). So each > HBA is its own scsi_adapter and each HBA is its own scsi_device, with the > associated /dev/ entries, as above. each adapter driver has an array of entry points for both adapter-side and device-side(never used yet, you might be the first) functions to call. However this is only referenced via the scsi_link structure associated with the calling device. There is nothing to say that you might not have MORE THAN ONE set of entry points, and that the differnt devices (each device has it's own scsi-link) might not point to difernt entry points to get diferent behaviour. How you set thes up is a different question.. There is also a separate scsibus_data[] structure allocated for each BUS and there could be several busses per adapter. basically each of the following has it's own information: the adapter type: the driver has an array of entrypoints and things that are invariant. the specific adapter: keeps track of things that change (e.g. opennings) the scsi bus: keeps track of what's attached where the device type: has a structure of entrypoints etc. each device instance: has information about where it's attached (invariant) and dynamic info. the scsi_link structure links all these different pieces together, (hence it's name). none of these items access the other directly. they ALWAYS go via the scsi_link. If you change a scsi_link, you change reality.. julian From owner-freebsd-scsi Thu Jan 30 01:21:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA00130 for freebsd-scsi-outgoing; Thu, 30 Jan 1997 01:21:25 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA00119 for ; Thu, 30 Jan 1997 01:21:17 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA14508 for freebsd-scsi@freebsd.org; Thu, 30 Jan 1997 10:21:09 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id KAA27336; Thu, 30 Jan 1997 10:20:14 +0100 (MET) Message-ID: Date: Thu, 30 Jan 1997 10:20:14 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@freebsd.org Subject: Re: XXXminpys question References: <32EFE3F5.237C228A@whistle.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <32EFE3F5.237C228A@whistle.com>; from Julian Elischer on Jan 29, 1997 15:57:41 -0800 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Julian Elischer wrote: > > The SCSI minphys routines seem to be called _in addition_ to the > > physio(9) minphys handling, to make the mess complete (once per call > > to scsi_strategy(), in sys/scsi/scsi_driver.c). > > exactly.. > the adapter or device might have more restrictions than > hte rest of the kernel, so they need a say. The adapters _are_ the reason for a minphys, so there should only be one at all. We should probably add it to the cdevsw entries. It can default to minphys (64 KB). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Thu Jan 30 03:15:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA05375 for freebsd-scsi-outgoing; Thu, 30 Jan 1997 03:15:31 -0800 (PST) Received: from hda.hda.com (ip30-max1-fitch.ziplink.net [199.232.245.30]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA05367 for ; Thu, 30 Jan 1997 03:15:27 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id GAA10436; Thu, 30 Jan 1997 06:10:02 -0500 From: Peter Dufault Message-Id: <199701301110.GAA10436@hda.hda.com> Subject: Re: XXXminpys question In-Reply-To: from J Wunsch at "Jan 30, 97 10:20:14 am" To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 30 Jan 1997 06:10:02 -0500 (EST) Cc: freebsd-scsi@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > As Julian Elischer wrote: > > > > The SCSI minphys routines seem to be called _in addition_ to the > > > physio(9) minphys handling, to make the mess complete (once per call > > > to scsi_strategy(), in sys/scsi/scsi_driver.c). > > > > exactly.. > > the adapter or device might have more restrictions than > > hte rest of the kernel, so they need a say. > > The adapters _are_ the reason for a minphys, so there should only be > one at all. We should probably add it to the cdevsw entries. It can > default to minphys (64 KB). You still want an overall system minphys to prevent a rogue driver / rogue dd from crashing the system. It is the maximum amount you're willing to guarantee to lock down for a raw transfer. The physio loop is correct - if you vectored through a "scsiwrite" instead of a "rawwrite" it could work with the current setup without the redundant minphys in the scsi code. I've always assumed that minphys was supposed to be in the cdevsw but the way it is in FreeBSD is the way it is in 4.4. This is for raw transfers - I'm not sure where "minphysing" is / should be done for block transfers in the case of the clustering of transfers. Finally, I think this hooks in with what Julian was asking the other day about scatter/gather lists hooked off the bufs (but I'm vague about this part). You call minphys before locking down the transfer, and so minphys will have to generate the scatter/gather list to figure out a real minphys, and then I guess the kernel must redo some of the work for the locking down. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-scsi Thu Jan 30 03:21:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA05635 for freebsd-scsi-outgoing; Thu, 30 Jan 1997 03:21:36 -0800 (PST) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA05630; Thu, 30 Jan 1997 03:21:33 -0800 (PST) Received: by sovcom.kiae.su id AA22440 (5.65.kiae-1 ); Thu, 30 Jan 1997 14:04:32 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Thu, 30 Jan 97 14:04:31 +0300 Received: from localhost (nagual.ru [127.0.0.1]) by nagual.ru (8.8.5/8.8.5) with SMTP id OAA00253; Thu, 30 Jan 1997 14:03:21 +0300 (MSK) Date: Thu, 30 Jan 1997 14:03:21 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: FreeBSD-current , FreeBSD-SCSI List Subject: Adaptec errors with latest SCSI updates Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I start to get following errors after recent SCSI code updates: ahc0: WARNING no command for scb 0 (cmdcmplt) QOUTCNT == 4 ahc0: WARNING no command for scb 0 (cmdcmplt) QOUTCNT == 1 My configuration: ahc0: at 0x1c00-0x1cff irq 11 on eisa0 slot 1 ahc0: aic7770 >= Rev E, Single Channel, SCSI Id=7, 4 SCBs scbus0 at ahc0 bus 0 ahc0: target 0 Tagged Queuing Device sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 1013MB (2074880 512 byte sectors) ahc0: target 1 Tagged Queuing Device sd1 at scbus0 target 1 lun 0 sd1: type 0 fixed SCSI 2 sd1: Direct-Access 2063MB (4226725 512 byte sectors) -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-scsi Thu Jan 30 14:46:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA06975 for freebsd-scsi-outgoing; Thu, 30 Jan 1997 14:46:56 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA06947 for ; Thu, 30 Jan 1997 14:46:47 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id PAA09359; Thu, 30 Jan 1997 15:45:50 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701291216.HAA08774@hda.hda.com> Date: Thu, 30 Jan 1997 14:15:26 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Peter Dufault Subject: Re: NewComer Questions... Cc: freebsd-scsi@freebsd.org, (Julian Elischer) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Peter Dufault; On 29-Jan-97 you wrote: > > > We need to develop the following functionality: > > > > > > 1. Multi-initiator support > > I assume you mean in SCSI? > > we ahve some basic support for that but it requires a SCSI host > > adapter that supports it.. it hasn't been exercised in years. > > (I wrote it iwith Peter Dufault but it's a rarely used feature. > > Or are you alking about several machines sharing a single bus?) > > Only the aha1542b supports it. It breaks on earlier and later > versions even on the aha adapter. The only way to resurrect > this will be to put it into the NCR and AHC where we have > solid support for the firmware. True for only a while longer. We are writing a DPT driver for FreeBSD. Once this is done (a week or two), you will have an alternative. We are going to use this controller for this project for many reasons. [ So that this thread does not turn into a commercial for DPT (they are not paying me), nor a flaming war of ``my controller is better than your controller'' (had enough of those in the Linux camp), I will invite those who are curious to contact me off this list. ] I realize this is a tricky/complex issue. As I am new to FreeBSD, I initiated this thread to discover what is there, how, why, etc. Thanx for all your input. It is very valuable... Simon From owner-freebsd-scsi Thu Jan 30 14:47:54 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA07173 for freebsd-scsi-outgoing; Thu, 30 Jan 1997 14:47:54 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA07146 for ; Thu, 30 Jan 1997 14:47:48 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id PAA09357; Thu, 30 Jan 1997 15:45:49 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <32EEFCD5.794BDF32@whistle.com> Date: Thu, 30 Jan 1997 12:44:23 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Julian Elischer Subject: Re: NewComer Questions... Cc: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Julian Elischer; On 29-Jan-97 you wrote: > Simon Shapiro wrote: > > > > I am learning slowly, and just discovered this mailing list. > > > > In way of introduction, I am working on a high speed database > > engine for embedded telephony applications. > > > > We need to develop the following functionality: > > > > 1. Multi-initiator support > I assume you mean in SCSI? > we ahve some basic support for that but it requires a SCSI host > adapter that supports it.. it hasn't been exercised in years. > (I wrote it iwith Peter Dufault but it's a rarely used feature. > Or are you alking about several machines sharing a single bus?) Yes. Multiple machines sharing the same SCSI bus. We have the HBA to do that and are porting the basic driver now. I am just wondering about what is there already and what is not. > > 2. DLM > Daringly Lowfat Milk? You almost got it right... :-) But to be more precise, it stands for Distributed Lock Manager. A creature that is used in concert with multi-initiator SCSI busses and is responsible for providing the coordination necessary for such a mayhem. this arrangement is useful in two places: Large, complex databases, where more than one host (CPU, system) wants access to the same physical database and in HRA (High Reiliability and Availability) systems where one system failure still leaves a path to the database through another. > > 3. Non-stop operation > hmm this is a tricky one.. > what's your definition of non-stop? A failure of any single component does not stop the system from providing the same services as before the failure. If you picture a RAID-{1,5} box conected to two hosts, you get the SCSI part of ``non-stop''; If a disk fails, the RAID array continues to run. The RAID box actually knows how to put a hot spare into service, so performance is restored in short order. If a host fails (without putting a short on the SCSI cable), the other host can continue and access the same storage, etc. > > 4. Very large (hundreds of Gigabytes) databases > not un heard of.. we have several people into teh > 100MB range.. > it does scale, though I have some ideas of some little NITS that> will require hitting on the head.. i.e. nomenclomature thi ngs > not really technical limits. Good. I need to talk about the nomeclature soon... I also need to learn the minor to dev mapping, etc. > > 5. Very fast (400 I/O's per second sustained) databases. > we can get about 100 per disk so with 4 disks :) Yes, you are on target. On a wide/fast SCSI you can expect about 130-140 T/s, with a bus total of about 430 T/s. this was confirmed on SPARC-20 with Slowlaris 2.5.1, on Linux with a DPT PCI HBA, and on FreeBSD with AHA2940W. this hosds true for transfers of up to about 4K in length. After that, funny things happen. Slowlaris HANGS the process if you do O_SYNC writes and reads concurrently on records of 8K and larger. The DPT controller holds linear degradation to 32K transfers and then peaks up again at 64K transfers. the AHA on FreeBSD exhibits similar behaviour, slower peaking and about 1/5th the throughput, etc. We are very anxious to see what the DPT will do on FreeBSD. I have some unique questions in this area, but am curious as to how interested is this forum in these things... > > Because O/S source is very criticsl for such effort, the > > ``free'' ones area natural choice. > > > > After 2 years or more of Linux usage. I decided (at least > > for now) to not use it. FreeBSD seems very attractive. > That's why we use it.. Endorsement? > > 1. Minor device designation for systems with up to 20 disk > > controllers (PCI), FCAL interfaces (with over 100 targets > > per bus. controllers with multiple busses, etc. > your nomenclature is confusing me.. > FCAL? Sorry. I hate these abbreviations... PCI we all know. (Plug and Pray on Intel Invented Local Bus...). FCAL is Fiber Channel Arbitrated Loop. A nifty trick, where all the SCSI devices sit on a loop of a fiber channel. Something like this: HOST-A -------- Disk-1 ------- Disk-2 -------- Disk-n -----+ | | +---------------------------------------------------------+ Now, the way I remember it, data normally flows clockwise in this daisy chain. In case of failure, it can flow backwards to reach ``the other side'' of the failure. Advantages are numerous: * All traffic is actually network traffic. The SCSI bus setup, arbitration, etc. is all gone. Typically, a single loop will support more than 1,400 T/s, vs. 400 on a normal SCSI cable. * Transfer rates are much faster, on the order of several hundreds of MB/Sec. * Inherently reliable, with redundency built in. * The ``SCSI bus'' can support (I think) 255 devices per loop. * Cabling advantages; Very long runs (several hundred meters), immunity from EMI/RFI, etc. Now I may be a bit off in some of these details, but the thing is real. Costs are not abnormally high either (about $50/drive extra) This does present the question of how do we name target ID 159 on Bus 79. Does it not? And what will its minor number be? > there are boards with 3 bosses an d2 bisses that are supported. > W can support PCI bridges to get more slots Yes. this is exactly where I am going with it. The Adaptec 3940 is really 2 controllers, not two busses. It appeas that FreeBSD config is OK in this regard, but I can find no documentation. When the DPT driver is done, I will be glad to contribute it to FreeBSD... > > 2. Naming conventions for /dev entries for such beasts. > /dev/{r}sd[0-9][0-9] > there is a limit at the moment to about 32 drives per machine > (I think) but it's a rather artificial limit > and could be removed relativly easily. Good. How is this limit imposed? I need to know. We can have sd0-sdf. What we need is either sd00-sdff or (better?) c[0-f]b[0-f]d[00-ff]s[0-400][a-h]. This gives you exactly 32 bits minors which I noticed FreeBSD to use already. > > 3. Moving all SCSI devices to a /dev/{r}dsk... > not sure what you mean by this..... > if you don't like the names there is always mknod:) > (so that ca't be what you mean.. it's too easy) This is exactly what I mean. Not all questions are difficult. On a large system, the number of sd* and rds* entries in /dev can be a bit overwhelming. What I propose is considering moving them to their own directory, like SunOS, etc. have done. I realize I could do that on ``my own system''. > > 4. Any documents about SCSI HBA driver entry points > ah there's the rub.. > I guess I'm going to have to write that one day.. > 6 years isn't too long is it? (since I wrote the code) :-) We are discovering these slowly. What we do not want to miss is the full intention of the original architect. We are comparing and analyzing the bt and the aic7xxx drivers, but that only tells me what these writers understood and thought appropriate for their hardware, not what the system actually CAN do. for example, for MI work, we need open/close and init/start on the HBA, as well as the devices attached. We discovered these entry points in scsiconf.h, but no driver uses them. We then notice (as I posted before), that the standard open/close pass no arguments, but the PC98 passes something to the open. Devices have a nicer open, but when does it get called? When will the open to the ADAPTER be called? When the initializing routines are running, are interrupts enabled? Is the VM totally functional? Can one sleep in the initializing? This is the class of questions we have. If we can gain good understanding here, i may be able to initiate the documentation of the SCSI subsystem as part of this project. ... Thanx so much for your help... Simon From owner-freebsd-scsi Thu Jan 30 15:04:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA08439 for freebsd-scsi-outgoing; Thu, 30 Jan 1997 15:04:02 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA08410 for ; Thu, 30 Jan 1997 15:03:55 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id AAA07149 for freebsd-scsi@freebsd.org; Fri, 31 Jan 1997 00:03:53 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id WAA28849; Thu, 30 Jan 1997 22:56:20 +0100 (MET) Message-ID: Date: Thu, 30 Jan 1997 22:56:20 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@freebsd.org Subject: Re: XXXminpys question References: <199701301110.GAA10436@hda.hda.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701301110.GAA10436@hda.hda.com>; from Peter Dufault on Jan 30, 1997 06:10:02 -0500 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Peter Dufault wrote: > > The adapters _are_ the reason for a minphys, so there should only be > > one at all. We should probably add it to the cdevsw entries. It can > > default to minphys (64 KB). > > You still want an overall system minphys to prevent a rogue driver / rogue > dd from crashing the system. It is the maximum amount you're willing to > guarantee to lock down for a raw transfer. I remember that David Greenman once said that the main reason for the existing minphys was the limitation of the SCSI adapters. Maybe there should be another minphys, but more something like 1 MB or larger then. The existing 64 KB limitation is something seriously small. Think of SGI's (stupid) habit of writing 256 KB blocked tapes, or of something like a WRITE BUFFER command to download firmware where the device will only accept the entire buffer at once (supposedly since it tries to compute a checksum on the fly). I think my Tandberg tape belongs to this group. It's annoying to boot a DOS floppy just for a SCSI firmware upgrade only. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Thu Jan 30 18:22:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA22332 for freebsd-scsi-outgoing; Thu, 30 Jan 1997 18:22:05 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA22324 for ; Thu, 30 Jan 1997 18:22:01 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.4/8.6.9) id VAA06077; Thu, 30 Jan 1997 21:21:50 -0500 (EST) From: "John S. Dyson" Message-Id: <199701310221.VAA06077@dyson.iquest.net> Subject: Re: XXXminpys question To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 30 Jan 1997 21:21:50 -0500 (EST) Cc: freebsd-scsi@freebsd.org In-Reply-To: from "J Wunsch" at Jan 30, 97 10:56:20 pm Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Peter Dufault wrote: > > > > The adapters _are_ the reason for a minphys, so there should only be > > > one at all. We should probably add it to the cdevsw entries. It can > > > default to minphys (64 KB). > > > > You still want an overall system minphys to prevent a rogue driver / rogue > > dd from crashing the system. It is the maximum amount you're willing to > > guarantee to lock down for a raw transfer. > > I remember that David Greenman once said that the main reason for the > existing minphys was the limitation of the SCSI adapters. > > Maybe there should be another minphys, but more something like 1 MB or > larger then. The existing 64 KB limitation is something seriously > small. > It will require some restructuring of the pbuf (physical I/O buffer) code, but isn't that bad to do. It has been in my queue for a while. If the driver-savvy people can work out a way to query the driver for the maximum I/O size, I can/will implement the upper level changes. John Dyson From owner-freebsd-scsi Thu Jan 30 19:38:31 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA27430 for freebsd-scsi-outgoing; Thu, 30 Jan 1997 19:38:31 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA27424 for ; Thu, 30 Jan 1997 19:38:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id TAA27509; Thu, 30 Jan 1997 19:37:49 -0800 (PST) Message-Id: <199701310337.TAA27509@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Simon Shapiro cc: Julian Elischer , freebsd-scsi@freebsd.org Subject: Re: NewComer Questions... In-reply-to: Your message of "Thu, 30 Jan 1997 12:44:23 PST." From: David Greenman Reply-To: dg@root.com Date: Thu, 30 Jan 1997 19:37:49 -0800 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> > 2. Naming conventions for /dev entries for such beasts. >> /dev/{r}sd[0-9][0-9] >> there is a limit at the moment to about 32 drives per machine >> (I think) but it's a rather artificial limit >> and could be removed relativly easily. > >Good. How is this limit imposed? I need to know. >We can have sd0-sdf. What we need is either sd00-sdff or (better?) >c[0-f]b[0-f]d[00-ff]s[0-400][a-h]. This gives you exactly 32 bits >minors which I noticed FreeBSD to use already. The "-current" limit is 512 disk devices...sd0 through sd511. I plan to bring this change into the 2.2 branch perhaps as early as tonight. >When the initializing routines are running, are interrupts enabled? That's a difficult question. It depends on which version of FreeBSD and what type of device (PCI/ISA) it is. Bruce might know the answer more specifically. >Is the VM totally functional? Yes, the VM system is initialized prior to any device probes/attaches. > Can one sleep in the initializing? No, but you can DELAY(). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-scsi Thu Jan 30 19:40:07 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA27606 for freebsd-scsi-outgoing; Thu, 30 Jan 1997 19:40:07 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA27580 for ; Thu, 30 Jan 1997 19:40:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id TAA27523; Thu, 30 Jan 1997 19:39:22 -0800 (PST) Message-Id: <199701310339.TAA27523@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-scsi@freebsd.org Subject: Re: XXXminpys question In-reply-to: Your message of "Thu, 30 Jan 1997 22:56:20 +0100." From: David Greenman Reply-To: dg@root.com Date: Thu, 30 Jan 1997 19:39:22 -0800 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I remember that David Greenman once said that the main reason for the >existing minphys was the limitation of the SCSI adapters. Right, it has to do with the number of scatter-gather entries that the controller can have per-DMA. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-scsi Thu Jan 30 20:20:06 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA29538 for freebsd-scsi-outgoing; Thu, 30 Jan 1997 20:20:06 -0800 (PST) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA29470 for ; Thu, 30 Jan 1997 20:19:58 -0800 (PST) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.4) id XAA26137; Thu, 30 Jan 1997 23:19:47 -0500 (EST) Date: Thu, 30 Jan 1997 23:19:47 -0500 (EST) From: Charles Henrich Message-Id: <199701310419.XAA26137@crh.cl.msu.edu> To: dg@root.com, freebsd-scsi@freebsd.org Subject: Re: NewComer Questions... Newsgroups: lists.freebsd.scsi References: <5crr1o$118t@msunews.cl.msu.edu> X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In lists.freebsd.scsi you write: > The "-current" limit is 512 disk devices...sd0 through sd511. I plan to >bring this change into the 2.2 branch perhaps as early as tonight. Yea! You are da man! -Crh -- Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-scsi Thu Jan 30 23:21:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA09241 for freebsd-scsi-outgoing; Thu, 30 Jan 1997 23:21:05 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA09220; Thu, 30 Jan 1997 23:20:58 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id IAA22782; Fri, 31 Jan 1997 08:01:37 +0100 (MET) Received: (from andreas@localhost) by klemm.gtn.com (8.8.5/8.8.2) id HAA01540; Fri, 31 Jan 1997 07:50:54 +0100 (MET) Message-ID: <19970131075054.MU36921@klemm.gtn.com> Date: Fri, 31 Jan 1997 07:50:54 +0100 From: andreas@klemm.gtn.com (Andreas Klemm) To: ache@nagual.ru (???????????????) Cc: current@FreeBSD.ORG (FreeBSD-current), scsi@FreeBSD.ORG (FreeBSD-SCSI List) Subject: Re: Adaptec errors with latest SCSI updates References: X-Mailer: Mutt 0.59-PL19 Mime-Version: 1.0 In-Reply-To: ; from "???????????????" on Jan 30, 1997 14:03:21 +0300 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I still get the following errors when running bonnie -s 100 on a fresh filesystem on a separate harddisk (3rd one). AHC 2940 ROM V1.16 10MB/sec. +-------------------+ +---------------------------+ | internal | | external SCSI box | | (T)HD1 --- HD2 ---<>-- 1 m cable --<>- CD-ROM -- TDC-4222 -- HD3 --T | | | | +-------------------+ +---------------------------+ active terminator of High density external IBM DORS SCSI HD ->Centronix Centronix style scsi cable active Terminator But I don't think the errors come from cabling, since this cabling I use for months now and I don't get the errors when disabling the the additional kernel options as reported in an earlier mail. This afternoon I will test, if backup using dump is possible, when having AHC_TAGENABLE set in the kernel ... Up to now it still isn't possible. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. sd2 at scbus0 target 2 lun 0: data overrun of 510 bytes detected. Forcing a retry. Copyright (c) 1992-1996 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #0: Fri Jan 31 07:28:45 MET 1997 root@klemm.gtn.com:/usr/sys.bisdn/compile/BISDN Calibrating clock(s) relative to mc146818A clock ... i586 clock: 99468527 Hz, i8254 clock: 1193122 Hz CPU: Pentium (99.47-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x525 Stepping=5 Features=0x1bf real memory = 67108864 (65536K bytes) avail memory = 63664128 (62172K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0:0 chip1 rev 2 on pci0:7:0 chip2 rev 2 on pci0:7:1 vga0 rev 0 int a irq 12 on pci0:10:0 ahc0 rev 3 int a irq 11 on pci0:12:0 ahc0: aic7870 Single Channel, SCSI Id=7, 16/255 SCBs ahc0 waiting for scsi devices to settle scbus0 at ahc0 bus 0 ahc0: target 0 Tagged Queuing Device sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 2063MB (4226725 512 byte sectors)sd0 at scbus0 target 0 lun 0: with 6703 cyls, 5 heads, and an average 126 sectors/track ahc0: target 1 Tagged Queuing Device sd1 at scbus0 target 1 lun 0 sd1: type 0 fixed SCSI 2 sd1: Direct-Access 2063MB (4226725 512 byte sectors)sd1 at scbus0 target 1 lun 0: with 6703 cyls, 5 heads, and an average 126 sectors/track ahc0: target 2 Tagged Queuing Device sd2 at scbus0 target 2 lun 0 sd2: type 0 fixed SCSI 2 sd2: Direct-Access 2063MB (4226725 512 byte sectors)sd2 at scbus0 target 2 lun 0: with 6703 cyls, 5 heads, and an average 126 sectors/track st0 at scbus0 target 4 lun 0 st0: type 1 removable SCSI 2 st0: Sequential-Access density code 0x0, 512-byte blocks, write-enabled cd0 at scbus0 target 6 lun 0 cd0: type 5 removable SCSI 2 cd0: CD-ROM can't get the size Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <4 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 10 maddr 0xcc000 msize 16384 on isa ed0: address 00:00:c0:25:fd:2d, type WD8013EPC (16 bit) sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in tel0 at 0xd80 irq 9 on isa tel0: card type Teles S0/16.3 npx0 on motherboard npx0: INT 16 interface joy0 at 0x201 on isa joy0: joystick sb0 at 0x220 irq 5 drq 1 on isa sb0: sbxvi0 at 0x0 drq 5 on isa sbxvi0: sbmidi0 at 0x330 on isa opl0 at 0x388 on isa opl0: IP packet filtering initialized, divert disabled, logging limited to 100 packets/entry -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-scsi Thu Jan 30 23:35:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id XAA09857 for freebsd-scsi-outgoing; Thu, 30 Jan 1997 23:35:26 -0800 (PST) Received: from freebee.tu-graz.ac.at (root@freebee.tu-graz.ac.at [129.27.193.128]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id XAA09725; Thu, 30 Jan 1997 23:33:06 -0800 (PST) Received: from dwarf.tu-graz.ac.at (dialup1.tu-graz.ac.at [129.27.250.2]) by freebee.tu-graz.ac.at (8.6.11/8.6.9) with ESMTP id IAA02182; Fri, 31 Jan 1997 08:30:42 +0100 Received: (from rmike@localhost) by dwarf.tu-graz.ac.at (8.7.5/8.7.3) id JAA00313; Thu, 30 Jan 1997 09:00:52 +0100 (MET) Date: Thu, 30 Jan 1997 09:00:52 +0100 (MET) From: Michael Ranner Reply-To: rmike@sbox.tu-graz.ac.at To: freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org Subject: AHA2920 Driver Message-ID: Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there currently a work in progress for the AHA2920 SCSI adapter. I'm got the Linux fdomain.c source and now I try to write a driver for FreeBSD 2.1.5 based on it. Is there somebody, I can contact, if I have problems? /\/\ichael Ranner - rmike@sbox.tu-graz.ac.at _o_ http://www.sbox.tu-graz.ac.at/home/rmike/ / \ ___|o o o|___ AdamsCII / \ /--(_)-(_)-(_)--\ From owner-freebsd-scsi Fri Jan 31 01:22:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA14020 for freebsd-scsi-outgoing; Fri, 31 Jan 1997 01:22:59 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA14015 for ; Fri, 31 Jan 1997 01:22:56 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA15722 for freebsd-scsi@freebsd.org; Fri, 31 Jan 1997 10:22:48 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id KAA02290; Fri, 31 Jan 1997 10:18:44 +0100 (MET) Message-ID: Date: Fri, 31 Jan 1997 10:18:44 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@freebsd.org Subject: Re: XXXminpys question References: <199701310221.VAA06077@dyson.iquest.net> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701310221.VAA06077@dyson.iquest.net>; from John S. Dyson on Jan 30, 1997 21:21:50 -0500 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As John S. Dyson wrote: > It will require some restructuring of the pbuf (physical I/O buffer) > code, but isn't that bad to do. It has been in my queue for a while. > If the driver-savvy people can work out a way to query the driver for > the maximum I/O size, I can/will implement the upper level changes. The adapter minphys stuff is already available internal. It's only a matter of including it into the [bc]devsw structure. SCSI devices probably need to put sc_minphys() there (or however it's called) which has to decide further. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Fri Jan 31 02:59:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA17173 for freebsd-scsi-outgoing; Fri, 31 Jan 1997 02:59:24 -0800 (PST) Received: from hda.hda.com (ip28-max1-fitch.ziplink.net [199.232.245.28]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id CAA17168 for ; Fri, 31 Jan 1997 02:59:21 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id FAA12508; Fri, 31 Jan 1997 05:54:04 -0500 From: Peter Dufault Message-Id: <199701311054.FAA12508@hda.hda.com> Subject: Re: NewComer Questions... In-Reply-To: from Simon Shapiro at "Jan 30, 97 12:44:23 pm" To: Shimon@i-Connect.Net (Simon Shapiro) Date: Fri, 31 Jan 1997 05:54:03 -0500 (EST) Cc: julian@whistle.com, freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > 1. Multi-initiator support > > I assume you mean in SCSI? > > we ahve some basic support for that but it requires a SCSI host > > adapter that supports it.. it hasn't been exercised in years. > > (I wrote it iwith Peter Dufault but it's a rarely used feature. > > Or are you alking about several machines sharing a single bus?) > > Yes. Multiple machines sharing the same SCSI bus. We have the HBA > to do that and are porting the basic driver now. I am just > wondering about what is there already and what is not. Julian meant target mode and not multiple initiator, i.e., using processor send/receive commands to talk between two processors over the SCSI bus. That only works on the AHA1542B due to firmware issues, though on that it worked fine a few years ago. I haven't used it much since then. I use a shared SCSI bus between two systems for debugging (again, with 1542s; build using a fast system that stays up and reboot the slow system) as you plan on doing and that works fine as long as you stay on your toes and don't do anything stupid with multiply mounted file systems. Are you using the SCSI disk block range reservation in your DLM? I thought about doing that but decided it was too likely to uncover bugs in drive firmware and never even tried it. It would certainly improve safety if it worked. > > > > 2. DLM > > Daringly Lowfat Milk? > > You almost got it right... :-) But to be more precise, it stands > for Distributed Lock Manager. A creature that is used in concert > with multi-initiator SCSI busses and is responsible for providing > the coordination necessary for such a mayhem. this arrangement is > useful in two places: Large, complex databases, where more than > one host (CPU, system) wants access to the same physical database > and in HRA (High Reiliability and Availability) systems where one > system failure still leaves a path to the database through another. I assume you do this over ethernet and not processor send/receive? (...) > > > > 2. Naming conventions for /dev entries for such beasts. > > /dev/{r}sd[0-9][0-9] > > there is a limit at the moment to about 32 drives per machine > > (I think) but it's a rather artificial limit > > and could be removed relativly easily. > > Good. How is this limit imposed? I need to know. The field for units in the minor number is only 5 bits. The dkunit stuff has a lower limit I think, but that affects only disk statistics. (...) > When the initializing routines are running, are interrupts enabled? > Is the VM totally functional? Can one sleep in the initializing? No interrupts, no sleeping. The kernel memory is there and you can malloc etc, but I'm not sure what you mean about VM totally functional. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-scsi Fri Jan 31 03:00:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA17272 for freebsd-scsi-outgoing; Fri, 31 Jan 1997 03:00:40 -0800 (PST) Received: from hda.hda.com (ip28-max1-fitch.ziplink.net [199.232.245.28]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA17267 for ; Fri, 31 Jan 1997 03:00:38 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id FAA12519; Fri, 31 Jan 1997 05:55:30 -0500 From: Peter Dufault Message-Id: <199701311055.FAA12519@hda.hda.com> Subject: Re: NewComer Questions... In-Reply-To: <199701310337.TAA27509@root.com> from David Greenman at "Jan 30, 97 07:37:49 pm" To: dg@root.com Date: Fri, 31 Jan 1997 05:55:30 -0500 (EST) Cc: freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > The "-current" limit is 512 disk devices...sd0 through sd511. I plan to > bring this change into the 2.2 branch perhaps as early as tonight. Oops. I better get with the program. Peter -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-scsi Fri Jan 31 03:27:17 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA18287 for freebsd-scsi-outgoing; Fri, 31 Jan 1997 03:27:17 -0800 (PST) Received: from hda.hda.com (ip28-max1-fitch.ziplink.net [199.232.245.28]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA18279 for ; Fri, 31 Jan 1997 03:26:56 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id GAA12564; Fri, 31 Jan 1997 06:20:36 -0500 From: Peter Dufault Message-Id: <199701311120.GAA12564@hda.hda.com> Subject: Re: XXXminpys question In-Reply-To: <199701310339.TAA27523@root.com> from David Greenman at "Jan 30, 97 07:39:22 pm" To: dg@root.com Date: Fri, 31 Jan 1997 06:20:35 -0500 (EST) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >I remember that David Greenman once said that the main reason for the > >existing minphys was the limitation of the SCSI adapters. > > Right, it has to do with the number of scatter-gather entries that the > controller can have per-DMA. Given that the memory isn't locked down yet and may not be mapped to physical memory, and that the maximum size of the scatter-gather list is dependent on the fragmentation of the physical memory, this problem is a bit thornier than at first glance. Is there a problem with considering minphys to be a guarantee to do the I/O so that a side effect of minphys is to lock down the pages and build the scatter-gather list using some published entry points? Then you can do system minphys to limit to the system max, driver minphys which pokes in its resources, locks down, and builds the scatter-gather and other parts of the pending transaction, then continue on through the physio lockdown which will either trivially succeed or figure out that it was already done, and finally do the I/O. Peter -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 From owner-freebsd-scsi Fri Jan 31 04:32:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id EAA20605 for freebsd-scsi-outgoing; Fri, 31 Jan 1997 04:32:32 -0800 (PST) Received: from relay.nuxi.com (nuxi.ucdavis.edu [128.120.37.176]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA20597; Fri, 31 Jan 1997 04:32:25 -0800 (PST) Received: from dragon.nuxi.com (reqf-050.ucdavis.edu [128.120.253.170]) by relay.nuxi.com (8.8.4/8.6.12) with ESMTP id EAA25988; Fri, 31 Jan 1997 04:32:23 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.8.4/8.7.3) id EAA03688; Fri, 31 Jan 1997 04:32:19 -0800 (PST) Message-ID: <19970131043219.SC38625@dragon.nuxi.com> Date: Fri, 31 Jan 1997 04:32:19 -0800 From: obrien@NUXI.com (David O'Brien) To: gibbs@freebsd.org Cc: scsi@freebsd.org Subject: probles w/latest 2940U code X-Mailer: Mutt 0.59-PL19 Mime-Version: 1.0 Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Justin, I'm having trouble with the 1/29 files. The previous commits worked pretty good (a few anomolies, but the best so far). With the 1/29 versions, I get some kernel panics: ============================================================================ 2.2-BETA kernel with 1/29/97 updates: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ swap_pager: I/O error - pagein failed; blkno 57792, szie 20480, error 5 vm_fault: page input (probably hardware) error, PID 13075 failure sd0(ahc0:0:0) ABORTED COMMAND asc:4e0 overlapped commands attempted, retries 4 Panic: ahc0: Timed-out command times out again syncing disks.... Fatal trap 12: page fault while in kernel mode fault virtual addr = 0x10 fault code = supervisor read, page not present code seg = base 0x0, limit 0xfffff, type 0x1b = DPL0, pres 1, def32 1, gram 1 proc flags = interupt enabled, resume, IOPL = 0 current proc = idle interupt mask = bio ============================================================================ I'm also having a problem in that my usual probing is: ahc0 rev 0 int a irq 11 on pci0:18 ahc0: aic7880 Single Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "TANDEM 4265-1 1011" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4303MB (8813870 512 byte sectors) sd0(ahc0:0:0): with 4392 cyls, 16 heads, and an average 125 sectors/track (ahc0:6:0): "TEAC CD-ROM CD-56S 1.0D" type 5 removable SCSI 2 cd0(ahc0:6:0): CD-ROM cd present [320495 x 2048 byte records] However, when I put an Archive Viper 150 tape drive in the chain, my cdrom drive is mis-probed: ahc0 rev 0 int a irq 11 on pci0:18 ahc0: aic7880 Single Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "TANDEM 4265-1 1011" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 4303MB (8813870 512 byte sectors) sd0(ahc0:0:0): with 4392 cyls, 16 heads, and an average 125 sectors/track ahc0:A:3: refuses syncronous negotiation. Using asyncronous transfers (ahc0:3:0): "ARCHIVE VIPER 150 21531 -004" type 1 removable SCSI 1 st0(ahc0:3:0): Sequential-Access density code 0x0, 512-byte blocks, write-enabled (ahc0:4:0): "EXABYTE EXB-85058SQANXR1 07J0" type 1 removable SCSI 2 st1(ahc0:4:0): Sequential-Access density code 0x0, drive empty (ahc0:6:0): parity error during Data-In phase. (ahc0:6:0): parity error during Data-In phase. (ahc0:6:0): "unknown unknown ????" type 13 fixed SCSI 0 uk0(ahc0:6:0): Unknown (ahc0:6:1): parity error during Data-In phase. (ahc0:6:1): parity error during Data-In phase. (ahc0:6:1): "unknown unknown ????" type 13 fixed SCSI 0 uk1(ahc0:6:1): Unknown ..snip.. The BIOS display of the AHA-2940U on boot up shows correct vendor strings for all four SCSI devices. Note that previous to 2.2-Beta, my cdrom drive answered for all 8 LUNs. With the Archive tape drive, and the 1/29 files, I will get a panic every time, with the previous set of commits, I get the kernel probes shown. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) From owner-freebsd-scsi Fri Jan 31 09:58:25 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA03759 for freebsd-scsi-outgoing; Fri, 31 Jan 1997 09:58:25 -0800 (PST) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA03735 for ; Fri, 31 Jan 1997 09:57:52 -0800 (PST) Received: from narnia (localhost [127.0.0.1]) by narnia.plutotech.com (8.8.4/8.7.3) with ESMTP id JAA03123; Fri, 31 Jan 1997 09:57:29 -0800 (PST) Message-Id: <199701311757.JAA03123@narnia.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: obrien@NUXI.com (David O'Brien) cc: scsi@freebsd.org Subject: Re: probles w/latest 2940U code In-reply-to: Your message of "Fri, 31 Jan 1997 04:32:19 PST." <19970131043219.SC38625@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 Jan 1997 09:57:29 -0800 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Hi Justin, > >I'm having trouble with the 1/29 files. The previous commits worked >pretty good (a few anomolies, but the best so far). With the 1/29 >versions, I get some kernel panics: > >============================================================================ >2.2-BETA kernel with 1/29/97 updates: >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >swap_pager: I/O error - pagein failed; blkno 57792, szie 20480, error 5 >vm_fault: page input (probably hardware) error, PID 13075 failure >sd0(ahc0:0:0) ABORTED COMMAND asc:4e0 overlapped commands attempted, retries 4 >Panic: ahc0: Timed-out command times out again >syncing disks.... I fixed this one (along with 4 or so other error recovery bugs) last night. This was after a recovery attempt for a timeout correct? Dumb mistake on my part. I'm doing some more testing today and will update the driver again tonight. >I'm also having a problem in that my usual probing is: > >(ahc0:6:0): parity error during Data-In phase. >(ahc0:6:0): parity error during Data-In phase. >(ahc0:6:0): "unknown unknown ????" type 13 fixed SCSI 0 >uk0(ahc0:6:0): Unknown >(ahc0:6:1): parity error during Data-In phase. >(ahc0:6:1): parity error during Data-In phase. >(ahc0:6:1): "unknown unknown ????" type 13 fixed SCSI 0 >uk1(ahc0:6:1): Unknown >..snip.. > >The BIOS display of the AHA-2940U on boot up shows correct vendor strings >for all four SCSI devices. Note that previous to 2.2-Beta, my cdrom >drive answered for all 8 LUNs. With the Archive tape drive, and the 1/29 >files, I will get a panic every time, with the previous set of commits, >I get the kernel probes shown. > The BIOS may have parity disabled during its initial bus scan. Can you try this again with the parity disabled in SCSI-Select (I believe that the driver honors that, but I'll have to check)? Did this work okay in previous versions of the driver? >-- David (obrien@NUXI.com -or- obrien@FreeBSD.org) -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Fri Jan 31 12:33:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA10527 for freebsd-scsi-outgoing; Fri, 31 Jan 1997 12:33:15 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA10493; Fri, 31 Jan 1997 12:32:55 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id NAA15005; Fri, 31 Jan 1997 13:32:14 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701310221.VAA06077@dyson.iquest.net> Date: Fri, 31 Jan 1997 11:24:09 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: dyson@FreeBSD.ORG Subject: Re: XXXminpys question Cc: freebsd-scsi@FreeBSD.ORG, joerg_wunsch@uriah.heep.sax.de, "John S. Dyson" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi John S. Dyson; On 31-Jan-97 you wrote: > > As Peter Dufault wrote: > > > > > > The adapters _are_ the reason for a minphys, so there should only be > > > > one at all. We should probably add it to the cdevsw entries. It can > > > > default to minphys (64 KB). > > > > > > You still want an overall system minphys to prevent a rogue driver / rogue > > > dd from crashing the system. It is the maximum amount you're willing to > > > guarantee to lock down for a raw transfer. > > > > I remember that David Greenman once said that the main reason for the > > existing minphys was the limitation of the SCSI adapters. > > > > Maybe there should be another minphys, but more something like 1 MB or > > larger then. The existing 64 KB limitation is something seriously > > small. > > > It will require some restructuring of the pbuf (physical I/O buffer) > code, but isn't that bad to do. It has been in my queue for a while. > If the driver-savvy people can work out a way to query the driver for > the maximum I/O size, I can/will implement the upper level changes. > > John Dyson Is this not the purpose of the xxx_minphys entry point to the driver? Simon From owner-freebsd-scsi Fri Jan 31 12:33:34 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA10567 for freebsd-scsi-outgoing; Fri, 31 Jan 1997 12:33:34 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA10550 for ; Fri, 31 Jan 1997 12:33:30 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id NAA15034; Fri, 31 Jan 1997 13:32:16 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701310337.TAA27509@root.com> Date: Fri, 31 Jan 1997 12:35:48 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: dg@root.com Subject: Re: NewComer Questions... Cc: freebsd-scsi@freebsd.org, Julian Elischer , David Greenman Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi David Greenman; On 31-Jan-97 you wrote: > The "-current" limit is 512 disk devices...sd0 through sd511. I plan to > bring this change into the 2.2 branch perhaps as early as tonight. I will switch over to -current once I gather the courage :-) The project needs to deliver in about 120 days. Should I target all work at 2.2, or 3.0. Cannot do it for -current. Right? > >When the initializing routines are running, are interrupts enabled? > > That's a difficult question. It depends on which version of FreeBSD and > what type of device (PCI/ISA) it is. Bruce might know the answer more > specifically. PCI, Version is at least 2.2-BETA. Maybe even 3.0? See above. > >Is the VM totally functional? > > Yes, the VM system is initialized prior to any device probes/attaches. > > > Can one sleep in the initializing? > > No, but you can DELAY(). Good. Thanx. FreeBSD appears to be a better O/S than most! Simon From owner-freebsd-scsi Fri Jan 31 12:33:44 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA10614 for freebsd-scsi-outgoing; Fri, 31 Jan 1997 12:33:44 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA10592 for ; Fri, 31 Jan 1997 12:33:38 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id NAA15042; Fri, 31 Jan 1997 13:32:16 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199701311054.FAA12508@hda.hda.com> Date: Fri, 31 Jan 1997 13:07:17 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: Peter Dufault Subject: Re: NewComer Questions... Cc: freebsd-scsi@freebsd.org, julian@whistle.com Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Peter Dufault; On 31-Jan-97 you wrote: ... Some good news delted... > I use a shared SCSI bus between two systems for debugging (again, > with 1542s; build using a fast system that stays up and reboot the > slow system) as you plan on doing and that works fine as long as > you stay on your toes and don't do anything stupid with multiply > mounted file systems. All the work will be done on raw devices, or r/o file systems. > Are you using the SCSI disk block range reservation in your DLM? I > thought about doing that but decided it was too likely to uncover > bugs in drive firmware and never even tried it. Thisd is an interesting idea. much like you, I put it in the category of synchronized spindles, RAID-3 and such; It is in the brochre, probably in the specs., maybe even in the firmware. Do I want to debug it? Probably not :-) Te DLM is implemented very generically and handles ALL the sharing issues. All that is expected of the SCSI system is to tolerate each other's initiator. The ``disk'' access will be done through something like ccd that will virtualize the disks and will be the one with the ``saring awareness''. We want the SCSI part to be as plain as possible. We want the code compartmentalized as much as possible. This enhances the amount/depth of the code that will be pumped back into the public domain. My employer pays for all of this... ... > I assume you do this over ethernet and not processor send/receive? Of course. Maybe even RS-232. Don't jump... :-)) ... > The field for units in the minor number is only 5 bits. The > dkunit stuff has a lower limit I think, but that affects only > disk statistics. We may need to visit these. Later. > No interrupts, no sleeping. The kernel memory is there and you can > malloc etc, but I'm not sure what you mean about VM totally functional. Exactly that. you can use virtual addresses, malloc is alive, etc. Interesting you say no interrupts because some SCSI adapters use splbio there... Simon From owner-freebsd-scsi Fri Jan 31 12:36:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA10850 for freebsd-scsi-outgoing; Fri, 31 Jan 1997 12:36:14 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA10838 for ; Fri, 31 Jan 1997 12:36:07 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id NAA15004; Fri, 31 Jan 1997 13:32:14 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 31 Jan 1997 12:06:08 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: John-Mark Gurney Subject: Re: amd.map file format documentation Cc: current@freebsd.org, "Justin T. Gibbs" , John-Mark Gurney Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi John-Mark Gurney; On 31-Jan-97 you wrote: ... > also... there is a good postscript document that is in the source tree > (src/usr.sbin/amdref.ps) and that goes into it deeply.. but it currently > isn't installed (kinda large at 464k)... No it is not there. It is in /usr/src/usr.sbin/amd/doc/amdref.ps :-) Simon From owner-freebsd-scsi Fri Jan 31 20:03:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA02588 for freebsd-scsi-outgoing; Fri, 31 Jan 1997 20:03:46 -0800 (PST) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA02579; Fri, 31 Jan 1997 20:03:37 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.4/8.6.9) id XAA02913; Fri, 31 Jan 1997 23:03:27 -0500 (EST) From: "John S. Dyson" Message-Id: <199702010403.XAA02913@dyson.iquest.net> Subject: Re: XXXminpys question To: Shimon@i-Connect.Net (Simon Shapiro) Date: Fri, 31 Jan 1997 23:03:27 +73900 (EST) Cc: dyson@freebsd.org, freebsd-scsi@freebsd.org, joerg_wunsch@uriah.heep.sax.de, toor@dyson.iquest.net In-Reply-To: from "Simon Shapiro" at Jan 31, 97 11:24:09 am X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > Hi John S. Dyson; On 31-Jan-97 you wrote: > > It will require some restructuring of the pbuf (physical I/O buffer) > > code, but isn't that bad to do. It has been in my queue for a while. > > If the driver-savvy people can work out a way to query the driver for > > the maximum I/O size, I can/will implement the upper level changes. > > > > John Dyson > > Is this not the purpose of the xxx_minphys entry point to the driver? > > Simon > Yes, except is that indeed the *right* way to do it? I am suggesting that we review that choice first. John From owner-freebsd-scsi Sat Feb 1 00:11:09 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id AAA10052 for freebsd-scsi-outgoing; Sat, 1 Feb 1997 00:11:09 -0800 (PST) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA10047; Sat, 1 Feb 1997 00:11:06 -0800 (PST) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id AAA15729; Sat, 1 Feb 1997 00:11:05 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id AAA21337; Sat, 1 Feb 1997 00:11:04 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.4/8.8.4) id AAA28411; Sat, 1 Feb 1997 00:11:02 -0800 (PST) Date: Sat, 1 Feb 1997 00:11:02 -0800 (PST) From: Don Lewis Message-Id: <199702010811.AAA28411@salsa.gv.tsc.tdk.com> To: freebsd-fs@freebsd.org, freebsd-scsi@freebsd.org Subject: SCSI disk MEDIUM ERROR with a few twists Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I was recently bitten by a disk that developed a bad sector and am somewhat disturbed about a few things. First the vital statistics: FreeBSD 2.1.6 Adaptec 2940UW Seagate ST31051N (Hawk) AWRE and ARRE are both enabled This machine is our news server. The disk in question holds /, /usr, and the partition where the history file lives. The latter partition is the one that developed the problem. Unknown to me, the problem cropped up a couple weeks ago, which brings us to the first problem: /etc/daily doesn't report this but these lists probably aren't the right place to report that. This problem was logged, all the way to the point where FAILURE was reported once on January 16. It occurred a bunch of times on January 18. Things were quiet until January 28, when I noticed that the machine wasn't feeding any news. I had a bunch of rlogin sessions open to the machine from the machine in my office, and when I tried to run any commands it responded with a message indicating some sort of I/O error. When I checked the machine's console, it was complaining about sd0 being not-ready. It decided to try to reboot when I typed on the keyboard, but hung because the disk wasn't ready. I power cycled the machine, and it started to boot but fsck decided that the one partition was hosed. I ran fsck manually, and things looked pretty grim. Fsck complained about bad blocks, and the kernal complained about MEDIUM ERRORs (but I didn't think to write down the block numbers). Some of the messages from fsck made it pretty obvious that a number of inodes had been overwritten with total garbage (preposterous file sizes, block numbers way out of range), and the block numbers in either the inode or an indirect block for the newsgroups file had been overwritten with similar trash as well. I ran fsck a few times answering "yes" until things were clean. The second problem is: During this final failure, something overwrite some number of good blocks with garbage data. It could be the filesystem, the SCSI driver, or the drive firmware. I then dump'ed everything on the disk in preparation for replacing it because I thought it was toast. During the process of dumping the news partition, I got a kernel complaint about a MEDIUM ERROR, but dump didn't complain. I also saved this partition using tar, and I got a MEDIUM ERROR when it was copying the history.pag file, but tar didn't complain. This brings us to the third problem: It appears that these errors aren't reported to userland I don't know whether the SCSI code isn't reporting this to the filesystem, or the filesystem isn't reporting this to userland code, but dump didn't seem to see a problem, tar didn't seem to see a problem. Also innd didn't seem to see a problem even though it appears to do the proper checking. It just seemed to accept duplicate articles on occasion, which I ended up reporting to inn-bugs. I guess I'll have to retract that bug report. I looked at the SCSI code in -current, and it's error handing seemed to be similar, so I hope y'all are interested. Before replacing the drive, I decided to run the Adaptec disk verification. It found a grand total of one bad sector and remapped it. The only remaining damage was that fsck had deleted my newsgroups file and history.pag had one formerly bad sector. Since the disk didn't appear to be hopeless, I replaced the newsgroups file and rebuilt history.pag, and things have been working flawlessly ever since. --- Truck From owner-freebsd-scsi Sat Feb 1 05:51:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA21457 for freebsd-scsi-outgoing; Sat, 1 Feb 1997 05:51:11 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA21440; Sat, 1 Feb 1997 05:51:03 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id OAA05267; Sat, 1 Feb 1997 14:50:44 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id OAA17384; Sat, 1 Feb 1997 14:29:17 +0100 (MET) Message-ID: Date: Sat, 1 Feb 1997 14:29:17 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: Don.Lewis@tsc.tdk.com (Don Lewis) Cc: freebsd-fs@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: SCSI disk MEDIUM ERROR with a few twists References: <199702010811.AAA28411@salsa.gv.tsc.tdk.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702010811.AAA28411@salsa.gv.tsc.tdk.com>; from Don Lewis on Feb 1, 1997 00:11:02 -0800 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Don Lewis wrote: (It would be fine if you could structure your report better. It's very hard to browse through, all the paragraphs were filled up with words where it's hard to figure out the essence of your problem.) > /etc/daily doesn't report this (and others don't report this) Of course. That's because buffered writes cannot report media errors to their caller. The caller has already got an OK indication about the write operation, when the device driver finally notices the write error. All the driver can do at this point is syslogging the problem. You ought to check your syslog regularly. The easiest way is to drop it onto all your logged in terminals :) (seriously, i do). > It could be the filesystem, the SCSI driver, or the drive firmware. It could be the drive itself. What MEDIUM ERRORs are these? You forgot to quote the most important thing, the driver message. > I don't know whether the SCSI code isn't reporting this to the filesystem, > or the filesystem isn't reporting this to userland code, but dump didn't > seem to see a problem, tar didn't seem to see a problem. It's interesting to know that dump didn't see the problem, since dump operates on the raw device, where error reporting is possible. Are you sure they were _unrecovered_ medium errors, i.e. the kernel didn't successfully retry them? Again, please *quote* the error messages, instead of assuming we know them. > Before replacing the drive, I decided to run the Adaptec disk verification. > It found a grand total of one bad sector and remapped it. The only > remaining damage was that fsck had deleted my newsgroups file and > history.pag had one formerly bad sector. Since the disk didn't appear > to be hopeless, I replaced the newsgroups file and rebuilt history.pag, > and things have been working flawlessly ever since. I wouldn't use that disk for serious work again. It's certainly good for storing news articles, but no longer reliable enough for storing your history database there. Also, go through SCSI reformatting it. This will cause the drive to recreate the bad sector table as necessary. You can even do this without using the adapter BIOS, there's always /sbin/scsiformat for this. I've once recovered another Seacrate drive that suffered from medium errors, and am using this until now (more than one year after those problems). However, i resorted it to a scratch drive for release testing etc., and do no longer use it for mission-critical work. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sat Feb 1 06:25:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA23902 for freebsd-scsi-outgoing; Sat, 1 Feb 1997 06:25:15 -0800 (PST) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA23897; Sat, 1 Feb 1997 06:25:13 -0800 (PST) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id GAA18114; Sat, 1 Feb 1997 06:25:02 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id GAA29183; Sat, 1 Feb 1997 06:25:00 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.4/8.8.4) id GAA28908; Sat, 1 Feb 1997 06:24:59 -0800 (PST) From: Don Lewis Message-Id: <199702011424.GAA28908@salsa.gv.tsc.tdk.com> Date: Sat, 1 Feb 1997 06:24:59 -0800 In-Reply-To: j@uriah.heep.sax.de (J Wunsch) "Re: SCSI disk MEDIUM ERROR with a few twists" (Feb 1, 2:29pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), Don.Lewis@tsc.tdk.com (Don Lewis) Subject: Re: SCSI disk MEDIUM ERROR with a few twists Cc: freebsd-fs@freebsd.org, freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Feb 1, 2:29pm, J Wunsch wrote: } Subject: Re: SCSI disk MEDIUM ERROR with a few twists } As Don Lewis wrote: } } > /etc/daily doesn't report this } } (and others don't report this) } } Of course. That's because buffered writes cannot report media errors } to their caller. The caller has already got an OK indication about } the write operation, when the device driver finally notices the write } error. All the driver can do at this point is syslogging the problem. Yes, but this is the "unrecovered read error" so often mentioned in the freebsd-scsi mail archive. Also, tar and dump were definitely reading it. INN was probably doing both. } You ought to check your syslog regularly. The easiest way is to drop } it onto all your logged in terminals :) (seriously, i do). A syslog scanner is on my list of things to do. } > It could be the filesystem, the SCSI driver, or the drive firmware. } } It could be the drive itself. The MEDIUM ERROR itself and the falling offline a week or so later are definitely the fault of the drive. That the error wasn't reported to userland lies somewhere between the driver and userland, inclusive. } What MEDIUM ERRORs are these? You forgot to quote the most important } thing, the driver message. Ok, here it is: Jan 18 04:30:33 news /kernel: sd0(ahc0:0:0): MEDIUM ERROR info:14683a asc:11,0 Unrecovered read error field replaceable unit: ea sks:80,11 Jan 18 04:30:34 news /kernel: , retries:4 Jan 18 04:30:35 news /kernel: sd0(ahc0:0:0): MEDIUM ERROR info:14683a asc:11,0 Unrecovered read error field replaceable unit: ea sks:80,11 Jan 18 04:30:35 news /kernel: , retries:3 Jan 18 04:30:36 news /kernel: sd0(ahc0:0:0): MEDIUM ERROR info:14683a asc:11,0 Unrecovered read error field replaceable unit: ea sks:80,11 Jan 18 04:30:38 news /kernel: , retries:2 Jan 18 04:30:42 news /kernel: sd0(ahc0:0:0): MEDIUM ERROR info:14683a asc:11,0 Unrecovered read error field replaceable unit: ea sks:80,11 Jan 18 04:30:42 news /kernel: , retries:1 Jan 18 04:30:43 news /kernel: sd0(ahc0:0:0): MEDIUM ERROR info:14683a asc:11,0 Unrecovered read error field replaceable unit: ea sks:80,11 Jan 18 04:30:44 news /kernel: , FAILURE Always the same info:#. } > I don't know whether the SCSI code isn't reporting this to the filesystem, } > or the filesystem isn't reporting this to userland code, but dump didn't } > seem to see a problem, tar didn't seem to see a problem. } } It's interesting to know that dump didn't see the problem, since dump } operates on the raw device, where error reporting is possible. Are } you sure they were _unrecovered_ medium errors, i.e. the kernel didn't } successfully retry them? Again, please *quote* the error messages, } instead of assuming we know them. Actually I'm not sure if it was recovered or not when I ran dump. I was running in single user at the time, so it was not logged. It was the same basic message, but I don't remember if it got all the way to FAILURE. I didn't decide that I should report this until I had seen how badly the filesystem *appeared* to have been munched by what turned out to be one bad sector. By that time, the sector had been remapped and I could no longer reproduce the problem. I also can't quote messages from it's death throes before it wedged, because this disk also contains /var and nothing was syslogged until after I got the machine running multi-user again. I *think* the message was: "Logical unit is in process of becoming ready", but if so it was lying. } > Before replacing the drive, I decided to run the Adaptec disk verification. } > It found a grand total of one bad sector and remapped it. The only } > remaining damage was that fsck had deleted my newsgroups file and } > history.pag had one formerly bad sector. Since the disk didn't appear } > to be hopeless, I replaced the newsgroups file and rebuilt history.pag, } > and things have been working flawlessly ever since. } } I wouldn't use that disk for serious work again. It's certainly good } for storing news articles, but no longer reliable enough for storing } your history database there. If it was more than one sector it would already be gone, but in this case I'm going to leave it running and keep a very close eye on it. It gave me at least two weeks warning last time. If it gets sick again, then I can at least file a more complete report ;-) Are there any experiments you want me to try? } Also, go through SCSI reformatting it. This will cause the drive to } recreate the bad sector table as necessary. You can even do this } without using the adapter BIOS, there's always /sbin/scsiformat for } this. The painful part is that this is the root disk, and I'm pretty sure the 2.1.x fixit disk doesn't contain scsiformat. Doesn't remapping the sector add the original to the drive's grown defect list? --- Truck From owner-freebsd-scsi Sat Feb 1 07:20:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA26321 for freebsd-scsi-outgoing; Sat, 1 Feb 1997 07:20:55 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id HAA26311 for ; Sat, 1 Feb 1997 07:20:48 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id QAA07013; Sat, 1 Feb 1997 16:20:42 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id QAA06590; Sat, 1 Feb 1997 16:03:46 +0100 (MET) Message-ID: Date: Sat, 1 Feb 1997 16:03:46 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: Don.Lewis@tsc.tdk.com (Don Lewis) Cc: freebsd-scsi@freebsd.org Subject: Re: SCSI disk MEDIUM ERROR with a few twists References: <199702011424.GAA28908@salsa.gv.tsc.tdk.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702011424.GAA28908@salsa.gv.tsc.tdk.com>; from Don Lewis on Feb 1, 1997 06:24:59 -0800 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Don Lewis wrote: > } It could be the drive itself. > > The MEDIUM ERROR itself and the falling offline a week or so later > are definitely the fault of the drive. That the error wasn't reported > to userland lies somewhere between the driver and userland, inclusive. See my other mail. For buffered (filesystem) writes, it's no surprise. Reads should, however, always report it. > Jan 18 04:30:33 news /kernel: sd0(ahc0:0:0): MEDIUM ERROR info:14683a asc:11,0 Unrecovered read error field replaceable unit: ea sks:80,11 > Always the same info:#. Which means: always the same block # (in hex). > I also can't quote messages from it's death throes before it wedged, > because this disk also contains /var and nothing was syslogged until > after I got the machine running multi-user again. I *think* the message > was: "Logical unit is in process of becoming ready", but if so it was > lying. Btw., you should no longer see this error message now. This case is retried forever, until it either turns into a `real' error, or eventually succeeds. > It gave me at least two weeks warning last time. If it gets sick again, > then I can at least file a more complete report ;-) Are there any > experiments you want me to try? Well, you could see why the read error isn't reported to userland then. :-) > } Also, go through SCSI reformatting it. This will cause the drive to > } recreate the bad sector table as necessary. You can even do this > } without using the adapter BIOS, there's always /sbin/scsiformat for > } this. > > The painful part is that this is the root disk, and I'm pretty sure the > 2.1.x fixit disk doesn't contain scsiformat. scsiformat is simple: scsi -s 7200 -f /dev/rsdX.ctl -c "4 0 0 0 0 0" (Put it into background if you prefer, once started, you can't break it with ^Z.) > Doesn't remapping the sector > add the original to the drive's grown defect list? Yes, but reformatting does IMHO often a more complete check, so if an adjacent sector is flakey, it will more likely be put there as well. We need a remapping tool as well. Anybody here who ever dealt with defect list management? Since we do already know the block number (from the info field in the syslog message), it should be easy to add it to the defect list. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sat Feb 1 07:37:21 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA26957 for freebsd-scsi-outgoing; Sat, 1 Feb 1997 07:37:21 -0800 (PST) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA26952 for ; Sat, 1 Feb 1997 07:37:19 -0800 (PST) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id HAA18417; Sat, 1 Feb 1997 07:37:12 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id HAA01119; Sat, 1 Feb 1997 07:37:11 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.4/8.8.4) id HAA28985; Sat, 1 Feb 1997 07:37:09 -0800 (PST) From: Don Lewis Message-Id: <199702011537.HAA28985@salsa.gv.tsc.tdk.com> Date: Sat, 1 Feb 1997 07:37:09 -0800 In-Reply-To: j@uriah.heep.sax.de (J Wunsch) "Re: SCSI disk MEDIUM ERROR with a few twists" (Feb 1, 4:03pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), Don.Lewis@tsc.tdk.com (Don Lewis) Subject: Re: SCSI disk MEDIUM ERROR with a few twists Cc: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Feb 1, 4:03pm, J Wunsch wrote: } Subject: Re: SCSI disk MEDIUM ERROR with a few twists } As Don Lewis wrote: } > I also can't quote messages from it's death throes before it wedged, } > because this disk also contains /var and nothing was syslogged until } > after I got the machine running multi-user again. I *think* the message } > was: "Logical unit is in process of becoming ready", but if so it was } > lying. } } Btw., you should no longer see this error message now. This case is } retried forever, until it either turns into a `real' error, or } eventually succeeds. Actually, this was kind of wierd too. When I checked the console, it was covered with this message. I tapped a few keys on the keyboard and I got a "press any key to reboot" message. There was no sign of a panic. That's when it tried to reboot and hung in the SCSI BIOS waiting for the drive ... } > It gave me at least two weeks warning last time. If it gets sick again, } > then I can at least file a more complete report ;-) Are there any } > experiments you want me to try? } } Well, you could see why the read error isn't reported to userland } then. :-) If I don't get caught in a maze of twisty little passages ;-) Yeah, I can try tar again, and dd the raw partition to /dev/null. That should narrow it down a bit. } scsiformat is simple: } } scsi -s 7200 -f /dev/rsdX.ctl -c "4 0 0 0 0 0" } } (Put it into background if you prefer, once started, you can't break } it with ^Z.) Since it's the root disk, I won't be doing much else. } > Doesn't remapping the sector } > add the original to the drive's grown defect list? } } Yes, but reformatting does IMHO often a more complete check, so if an } adjacent sector is flakey, it will more likely be put there as well. I've got another question. I read in the archives why this sector wouldn't be automagically remapped by the drive on a read failure even though automagic remapping is turned on. But wouldn't the drive remember that the sector was bad and remap it the next time it was written (assuming it hadn't been powered off in between)? I'd be willing to bet that this sector had been written at least once between the failures that were logged. } We need a remapping tool as well. Anybody here who ever dealt with } defect list management? Since we do already know the block number } (from the info field in the syslog message), it should be easy to add } it to the defect list. I was reading the SCSI spec and thinking about writing something that would at dump out the current defect list, but then my brain started hurting too much :-( --- Truck From owner-freebsd-scsi Sat Feb 1 09:51:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA01738 for freebsd-scsi-outgoing; Sat, 1 Feb 1997 09:51:08 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA01732 for ; Sat, 1 Feb 1997 09:51:03 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA10508; Sat, 1 Feb 1997 18:50:57 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id SAA29256; Sat, 1 Feb 1997 18:31:31 +0100 (MET) Message-ID: Date: Sat, 1 Feb 1997 18:31:31 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: Don.Lewis@tsc.tdk.com (Don Lewis) Cc: freebsd-scsi@freebsd.org Subject: Re: SCSI disk MEDIUM ERROR with a few twists References: <199702011537.HAA28985@salsa.gv.tsc.tdk.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702011537.HAA28985@salsa.gv.tsc.tdk.com>; from Don Lewis on Feb 1, 1997 07:37:09 -0800 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Don Lewis wrote: > } We need a remapping tool as well. Anybody here who ever dealt with > } defect list management? Since we do already know the block number > } (from the info field in the syslog message), it should be easy to add > } it to the defect list. > > I was reading the SCSI spec and thinking about writing something that > would at dump out the current defect list, but then my brain started > hurting too much :-( Metoo. This defect list stuff is even worse to understand (from just reading the specs only) than mode pages. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sat Feb 1 10:14:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA02866 for freebsd-scsi-outgoing; Sat, 1 Feb 1997 10:14:45 -0800 (PST) Received: from hda.hda.com (ip16-max1-fitch.ziplink.net [199.232.245.16]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA02858 for ; Sat, 1 Feb 1997 10:14:39 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id NAA16376; Sat, 1 Feb 1997 13:08:56 -0500 From: Peter Dufault Message-Id: <199702011808.NAA16376@hda.hda.com> Subject: Re: SCSI disk MEDIUM ERROR with a few twists In-Reply-To: <199702011537.HAA28985@salsa.gv.tsc.tdk.com> from Don Lewis at "Feb 1, 97 07:37:09 am" To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Sat, 1 Feb 1997 13:08:55 -0500 (EST) Cc: joerg_wunsch@uriah.heep.sax.de, Don.Lewis@tsc.tdk.com, freebsd-scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > As Don Lewis wrote: > > > } We need a remapping tool as well. Anybody here who ever dealt with > > } defect list management? Since we do already know the block number > > } (from the info field in the syslog message), it should be easy to add > > } it to the defect list. > > > > I was reading the SCSI spec and thinking about writing something that > > would at dump out the current defect list, but then my brain started > > hurting too much :-( > > Metoo. This defect list stuff is even worse to understand (from just > reading the specs only) than mode pages. The remapping tool is easy: write anything to the block. Here is an sector slipper I wrote in C once, however, it may fail also if it can't recover the data - I don't have time to check the spec right now. I also put together a defect list dumper for Satoshi when he was having some problems, so I'm putting that here too. Caveat emptor. # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # slipsec.c # dump-defects.c # defect # echo x - slipsec.c sed 's/^X//' >slipsec.c << 'END-of-slipsec.c' X/* slipsec: Slip a sector using "reallocate block". X */ X#include X#include X#include X#include X X#include X Xint main(int argc, char *argv[]) X{ X scsireq_t *scsireq; X X int qualifier, type, rmb, modifier, iso, ecma, ansi; X char vendor_id[17], product_id[17], revision[5]; X int lba, len; X int i; X int fid; X u_char *inq_buf = malloc(96), *lbas; X u_long block = 0; X int n; X X if (argc < 3) X { X fprintf(stderr, "Usage: %s device sector1 ... sectorn\n", argv[0]); X exit(-1); X } X X fid = scsi_open(argv[1], O_RDWR); X if (fid == -1) X { X perror(argv[1]); X exit(errno); X } X X scsireq = scsireq_build(scsireq_new(), X 96, inq_buf, SCCMD_READ, X "12 0 0 0 v 0", 96); X X if (scsireq_enter(fid, scsireq) == -1) X { X scsi_debug(stderr, -1, scsireq); X exit(errno); X } X X scsireq_decode(scsireq, "b3 b5 b1 b7 b2 b3 b3 s8 z16 z16 z4", X &qualifier, &type, &rmb, &modifier, &iso, &ecma, &ansi, X vendor_id, product_id, revision); X X printf("%s %s %s\n", vendor_id, product_id, revision); X if (type != 0) X { X printf("This is not a direct access device.\n"); X exit(0); X } X X switch(ansi) X { X case 0: X printf("WARNING: This device might not comply to any standard.\n"); X break; X X case 1: X printf("This is a SCSI-1 device.\n"); X break; X X case 2: X printf("This is a SCSI-2 device.\n"); X break; X } X X /* How many blocks? X */ X if (scsireq_enter(fid, scsireq_build(scsireq, X 8, inq_buf, SCCMD_READ, X "25 0 0 0 0 0 0 0 0 0")) == -1) /* Read capacity */ X { X scsi_debug(stderr, -1, scsireq); X exit(errno); X } X X scsireq_decode(scsireq, "i4 i4", &lba, &len); X X printf("The device has %d %d byte blocks.\n", lba, len); X fflush(stdout); X X /* Verify all blocks seem reasonable first: X */ X for (i = 2; i < argc; i++) X { X if ((block = strtoul(argv[i], 0, 0)) > lba) X { X fprintf(stderr, X "Block at %ld outside of maximum %d.\n", block, lba); X exit(-1); X } X } X X n = i - 2; X len = 4 + 4 * n; X if ( (lbas = malloc(len)) == 0 ) X { X perror("malloc"); X exit(errno); X } X X (void)scsireq_build(scsireq, X len, lbas, SCCMD_WRITE, X "07 0 0 0 0 0"); X X scsireq_encode(scsireq, "0 0 v:i2 ", 4 * n); X X for (i = 0; i < n; i++) X scsireq_encode(scsireq, "sv v:i4 ", 4 + 4 * i, strtoul(argv[i + 2], 0, 0)); X X if (scsireq_enter(fid, scsireq) == -1) X { X perror("scsireq_enter"); X exit(errno); X } X X /* Did we get sense? X */ X if (scsireq->senselen_used) X { X int valid, code, key, info, asc, ascq; X X scsireq_buff_decode(scsireq->sense, scsireq->senselen_used, X "b1 b7 *i1 *b4 b4 i4 s12 i1 i1", &valid, &code, X &key, &info, &asc, &ascq); X X printf("Block %lx: valid %d code %02x sense key %02x info %x asc %02x ascq %02x\n", X block, valid, code, key, info, asc, ascq); X fflush(stdout); X } X X exit(0); X} END-of-slipsec.c echo x - dump-defects.c sed 's/^X//' >dump-defects.c << 'END-of-dump-defects.c' X#include X#include Xint main(int ac, char *av[]) X{ X struct header { X u_char stuff[2]; X u_char length[2]; X } h; X X struct physical_sector { X u_char cyl[3]; X u_char head; X u_char sec[4]; X } p; X X if (fread(&h, sizeof(h), 1, stdin) == 1) X while (fread(&p, sizeof(p), 1, stdin) == 1) X printf("%d %d %d\n", (p.cyl[0] << 16) | (p.cyl[1] << 8) | p.cyl[2], X p.head, X (p.sec[0] << 24) | (p.sec[1] << 16) | (p.sec[2] << 8) | p.sec[3]); X} END-of-dump-defects.c echo x - defect sed 's/^X//' >defect << 'END-of-defect' X#!/bin/sh Xusage() X{ X echo "usage: defect raw-device-name" 1>&2 X exit 2 X} X X# Get the grown defect length: X Xif [ $# -ne 1 ] ; then X usage Xfi X XCTL=$1 XBASE=$CTL X X# X# Select what you want to read. PList include the primary defect list X# from the factory. GList is grown defects only. X# X XGList=1 XPList=0 X Xif [ "x$CTL" = "x" ] ; then X usage Xfi X Xif expr "$CTL" : 'sd[0-9][0-9]*$' > /dev/null ; then X # generic disk name given, convert to control device name X CTL="/dev/r${CTL}.ctl" Xfi X Xlength=`scsi -f ${CTL} \ X-c "{ Op code} 37 0 0:3 v:1 v:1 5:3 0 0 0 0 4:i2 0" $PList $GList \ X-i 4 "{ stuff } *i2 { Defect list length } i2"` X Xecho "There are" `expr $length / 8` defects X X# Adjust for the header: Xlength=`expr $length + 4` X X# Read the defects and store to disk X Xscsi -f ${CTL} \ X-c "{ Op code} 37 0 0:3 v:1 v:1 5:3 0 0 0 0 v:i2 0" $PList $GList $length \ X-i $length - > /tmp/defects.$BASE X Xecho "Defects in /tmp/defects.$BASE" X X# They are in the physical sector format. The format (assume packing) is: X# struct physical_sector { X# u_short cylinder; X# u_char head; X# u_long sector; X# }; X# X# Note that they are bigendian! You'll have to use ntohl or something. X# END-of-defect exit From owner-freebsd-scsi Sat Feb 1 11:51:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA06379 for freebsd-scsi-outgoing; Sat, 1 Feb 1997 11:51:42 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA06374 for ; Sat, 1 Feb 1997 11:51:39 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id UAA14866; Sat, 1 Feb 1997 20:51:37 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id UAA29862; Sat, 1 Feb 1997 20:31:30 +0100 (MET) Message-ID: Date: Sat, 1 Feb 1997 20:31:30 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-scsi@FreeBSD.org (FreeBSD SCSI list) Cc: Don.Lewis@tsc.tdk.com (Don Lewis) Subject: Re: SCSI disk MEDIUM ERROR with a few twists References: <199702011537.HAA28985@salsa.gv.tsc.tdk.com> <199702011808.NAA16376@hda.hda.com> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199702011808.NAA16376@hda.hda.com>; from Peter Dufault on Feb 1, 1997 13:08:55 -0500 Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk As Peter Dufault wrote: > I also put together a defect list dumper for Satoshi when he was > having some problems, so I'm putting that here too. Neat! I've combined both, since this is really easier to handle in Perl. Maybe we should put this up under tools/? #!/usr/bin/perl sub usage { die "usage: defect raw-device-name [Glist|Plist]\n"; } # # Main # &usage if $#ARGV < 0 || $#ARGV > 1; $ENV{'PATH'} = "/bin:/usr/bin:/sbin:/usr/sbin"; $dev = $ARGV[0]; # generic device name given? if ($dev =~ /^[so]d\d+$/) { $dev = "/dev/r${dev}.ctl"; } # # Select what you want to read. PList include the primary defect list # from the factory. GList is grown defects only. # if ($#ARGV > 0) { if ($ARGV[1] =~ /^[Gg]/) { $glist = 1; $plist = 0; } elsif ($ARGV[1] =~ /^[Pp]/) { $glist = 0; $plist = 1; } else { &usage; } } else { $glist = 1; $plist = 0; } open(PIPE, "scsi -f $dev " . "-c '{ Op code} 37 0 0:3 v:1 v:1 5:3 0 0 0 0 4:i2 0' $plist $glist " . "-i 4 '{ stuff } *i2 { Defect list length } i2' |") || die "Cannot pipe from scsi(8)\n"; chop($amnt = ); close(PIPE); if ($amnt == 0) { print "There are no defects (in this list).\n"; exit 0; } print "There are " . $amnt / 8 . " defects in this list.\n"; $amnt += 4; open(PIPE, "scsi -f $dev " . "-c '{ Op code} 37 0 0:3 v:1 v:1 5:3 0 0 0 0 v:i2 0' $plist $glist " . "$amnt -i $amnt - |") || die "Cannot pipe from scsi(8)\n"; read(PIPE, $buf, 4); # defect list header print "cylinder head sector\n"; while(read(PIPE, $buf, 8)) { ($cylhi, $cyllo, $head, $sec) = unpack("CnCN", $buf); printf "%8u %4u %6u\n", $cylhi*65536+$cyllo, $head, $sec; } close(PIPE); -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sat Feb 1 15:26:10 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA13800 for freebsd-scsi-outgoing; Sat, 1 Feb 1997 15:26:10 -0800 (PST) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA13793 for ; Sat, 1 Feb 1997 15:26:04 -0800 (PST) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.4) id SAA11001; Sat, 1 Feb 1997 18:26:03 -0500 (EST) Date: Sat, 1 Feb 1997 18:26:03 -0500 (EST) From: Charles Henrich Message-Id: <199702012326.SAA11001@crh.cl.msu.edu> To: j@uriah.heep.sax.de, freebsd-scsi@freebsd.org Subject: Re: SCSI disk MEDIUM ERROR with a few twists Newsgroups: lists.freebsd.scsi References: <5d07hr$l9m@msunews.cl.msu.edu> X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In lists.freebsd.scsi you write: >As Peter Dufault wrote: >> I also put together a defect list dumper for Satoshi when he was >> having some problems, so I'm putting that here too. >Neat! >I've combined both, since this is really easier to handle in Perl. >Maybe we should put this up under tools/? This stuff is coolness! Might I suggest strongly that on sysstems where we have devices with sd0() online that we run this daily and diff the results as we do with master.passwd ? This gives system administrators early warnings on failing disks if they start to see the glist grow and grow day after day.. -Crh -- Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-scsi Sat Feb 1 16:01:02 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA16440 for freebsd-scsi-outgoing; Sat, 1 Feb 1997 16:01:02 -0800 (PST) Received: from aries.bb.cc.wa.us (root@[208.8.136.11]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA16425 for ; Sat, 1 Feb 1997 16:00:58 -0800 (PST) Received: from localhost (chris@localhost) by aries.bb.cc.wa.us (8.8.3/8.6.9) with SMTP id QAA18295; Sat, 1 Feb 1997 16:00:21 -0800 (PST) Date: Sat, 1 Feb 1997 16:00:21 -0800 (PST) From: Chris Coleman To: Richard Tobin cc: Joerg Wunsch , FreeBSD SCSI list Subject: Re: Tape Backup Drive Not working. In-Reply-To: <199701251540.PAA16318@deacon.cogsci.ed.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 25 Jan 1997, Richard Tobin wrote: > > > "Conner CTT8000-S 1.17" Type 1 removable SCSI2 > > > st0(ahc:0:3:0):Sequential-Access Density Code 0x45, Drive Empty > > > Never heard of such a beast. The density code is far beyond those > > mentioned in the SCSI-2 specs. I assume this is something only > > compatible to itself? > > Looks like Conner's version of the HP T4000s, which is actually a QIC > standard (3095). I posted fairly trivial patches for the HP a few > months ago. > > Essentially all that was required was setting the PF bit in mode > select, but there's no reason to suppose that Conner's SCSI > implementation will have the same quirks as HP's. It's still not working. I tried the patch that was sent to me, but it didn't seem to make a diffrence. I am still getting the same errors. I think is might have somthing to do with this actually being a HP Travin? drive. This was suggested to me by someone, I don't fully understand it. I am still under warranty, so I am thinking of sending it back and getting a new Tape Drive. I have the Adaptec 2910 scsi card for it. Tell me whether i should send this back also. I need to know which Tape Drives are fully supported in 2.1.6-RELEASE. Ill get one of them. > > Incidentally, I would interested if anyone else is successfully using > the T4000s, since I having trouble reading tapes which is most likely > a hardware problem, but I'm not certain. > > -- Richard > Thanks. Christopher J. Coleman (chris@aries.bb.cc.wa.us) Computer Support Technician I (509)-766-8873 Big Bend Community College Internet Instructor FreeBSD Book Project: http://www.bb.cc.wa.us/~chris/book.html Death is life's way of telling you you're fired. From owner-freebsd-scsi Sat Feb 1 16:15:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA18478 for freebsd-scsi-outgoing; Sat, 1 Feb 1997 16:15:57 -0800 (PST) Received: from sendero.i-connect.net ([206.190.144.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA18471 for ; Sat, 1 Feb 1997 16:15:50 -0800 (PST) Received: (from shimon@localhost) by sendero.i-connect.net (8.8.5/8.8.4) id RAA10286 for freebsd-scsi@freebsd.org; Sat, 1 Feb 1997 17:15:35 -0800 (PST) Message-ID: X-Mailer: XFMail 1.1-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Sat, 01 Feb 1997 16:59:14 -0800 (PST) Organization: iConnect Corp. From: Simon Shapiro To: freebsd-scsi@freebsd.org Subject: Jazz Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone know how to convince a Jaz pack that has been marked Read-Only as usable (read-write)? Contacting Iomega has not been useful. The ``documentation'' that comes with the drive can make you laugh or cry, mood dependant. Thanx, Simon From owner-freebsd-scsi Sat Feb 1 16:45:14 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA19748 for freebsd-scsi-outgoing; Sat, 1 Feb 1997 16:45:14 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id QAA19743 for ; Sat, 1 Feb 1997 16:45:10 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA07330; Sun, 2 Feb 1997 01:45:05 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.5/8.6.9) id BAA15671; Sun, 2 Feb 1997 01:34:39 +0100 (MET) Message-ID: Date: Sun, 2 Feb 1997 01:34:37 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: chris@bb.cc.wa.us (Chris Coleman) Cc: freebsd-scsi@freebsd.org (FreeBSD SCSI list) Subject: Re: Tape Backup Drive Not working. References: <199701251540.PAA16318@deacon.cogsci.ed.ac.uk> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: ; from Chris Coleman on Feb 1, 1997 16:00:21 -0800 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Chris Coleman wrote: > I am still under warranty, so I am thinking of sending it back and getting > a new Tape Drive. I have the Adaptec 2910 scsi card for it. Tell me > whether i should send this back also. The 2910 card is a Future Domain controller, without a BIOS. Nothing much to worry about, certainly a < $50 piece. Unsupported in FreeBSD by now, though somebody wrote in Usenet (or on this list?) that he's going to start porting a driver. Whether you could use the drive with FreeBSD depends on whether you could squeeze some documentation out of HP that explains the SCSI handling. Sure, we are interested to see the drive supported (i've heard this name quite often lately, they appear to be cheap), but i'm afraid you'll run out of patience until it finally flies. > I need to know which Tape Drives > are fully supported in 2.1.6-RELEASE. Ill get one of them. Almost all. Avoid the el-cheapos, they often have firmware quirks that make the life harder, see your example. Exabyte is the patch-of-the-week firmware company. HP DATs used to be usable, but lately, they often die a very early death. Many people basically distrust all the helical scan tape drives (including me). I'm happy with my Tandberg drive, QIC-2.5GB (plus hardware compression for the 2 and 2.5 GB media). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)