From owner-freebsd-scsi Mon Jun 15 11:16:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA28841 for freebsd-scsi-outgoing; Mon, 15 Jun 1998 11:16:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hscmg02.hou.ucarb.com (hscmg02.hou.ucarb.com [144.68.4.25]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA28818 for ; Mon, 15 Jun 1998 11:16:44 -0700 (PDT) (envelope-from NguyenHM@ucarb.com) Received: by hscmg02.hou.ucarb.com with Internet Mail Service (5.0.1458.49) id ; Mon, 15 Jun 1998 13:21:06 -0500 Message-ID: <332F90115D96D0119CD500805FEA976B016945DA@HSCMS01> From: "Nguyen HM (Mike)" To: freebsd-scsi@FreeBSD.ORG Subject: PowerDomain 2940UW Date: Mon, 15 Jun 1998 13:18:24 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, This is a kind of off-the-wall question, but it is scsi and FreeBSD related, so I thought I'd give it a shot. I have a PowerDomain 2940UW, which is the Macintosh version of the 2940UW. This means that it has Mac firmware. Seeing as how I no longer have a Mac (though I want one of those new iMacs pretty bad), I would like to use it in my FreeBSD box. My question is, if I have a copy of the latest (1.25) firmware for Intel platforms, will I get a working card if I flash the PowerDomain 2940UW? Has anyone tried this? I asked Adaptec twice, the first time the guy was very non-committal, the second guy implied that it would work. Has anyone tried this? Does anyone have any information about the PCI architecture, etc., which might clue me in as to whether it would work or not? I'd like some feedback before I render a $200 card useless (not that it kinda isn't already useless now). Thanks, Mike. // Mike Nguyen // Unix Systems Analyst and Geek // Union Carbide Corporation * (281) 212-8073 // nguyenhm@ucarb.com * mikenguyen@sprintmail.com (personal) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 15 12:24:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA10257 for freebsd-scsi-outgoing; Mon, 15 Jun 1998 12:24:06 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA10176 for ; Mon, 15 Jun 1998 12:23:57 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id TAA02121; Mon, 15 Jun 1998 19:23:30 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA29793; Mon, 15 Jun 1998 21:23:30 +0200 (MET DST) Message-ID: <19980615212329.44637@follo.net> Date: Mon, 15 Jun 1998 21:23:29 +0200 From: Eivind Eklund To: "Nguyen HM (Mike)" , freebsd-scsi@FreeBSD.ORG Subject: Re: PowerDomain 2940UW References: <332F90115D96D0119CD500805FEA976B016945DA@HSCMS01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <332F90115D96D0119CD500805FEA976B016945DA@HSCMS01>; from Nguyen HM (Mike) on Mon, Jun 15, 1998 at 01:18:24PM -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jun 15, 1998 at 01:18:24PM -0500, Nguyen HM (Mike) wrote: > Hi, > > This is a kind of off-the-wall question, but it is scsi and FreeBSD > related, so I thought I'd give it a shot. > > I have a PowerDomain 2940UW, which is the Macintosh version of the > 2940UW. This means that it has Mac firmware. Seeing as how I no longer > have a Mac (though I want one of those new iMacs pretty bad), I would > like to use it in my FreeBSD box. > > My question is, if I have a copy of the latest (1.25) firmware for Intel > platforms, will I get a working card if I flash the PowerDomain 2940UW? > Has anyone tried this? I asked Adaptec twice, the first time the guy was > very non-committal, the second guy implied that it would work. Has > anyone tried this? Does anyone have any information about the PCI > architecture, etc., which might clue me in as to whether it would work > or not? >From the FreeBSD end, I guess it would work. FreeBSD doesn't use the firmware, only the hardware. How it would work for the BIOS I have no idea - I'd guess it would work, but that is a guess from a person that isn't very qualified in the area :-) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 15 13:45:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA23933 for freebsd-scsi-outgoing; Mon, 15 Jun 1998 13:45:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from fledge.watson.org (shafeeq@COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA23921 for ; Mon, 15 Jun 1998 13:45:14 -0700 (PDT) (envelope-from shafeeq@cyrus.watson.org) Received: from localhost (shafeeq@localhost) by fledge.watson.org (8.8.8/8.8.8) with SMTP id QAA07056 for ; Mon, 15 Jun 1998 16:45:14 -0400 (EDT) X-Authentication-Warning: fledge.watson.org: shafeeq owned process doing -bs Date: Mon, 15 Jun 1998 16:45:14 -0400 (EDT) From: Shafeeq Sinnamohideen X-Sender: shafeeq@fledge.watson.org To: freebsd-scsi@FreeBSD.ORG Subject: disappearing cdrom w/ Bt948+CAM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org So, I decided to try out CAM on my SMP machine with a Bt-948. The problem is that during the bus probe, it fails to discover the NEC CDR-500 at id 6, along with the attached error messages. If I understand correctly, the messages are the result of trying to probe LUNs of device 0? The messages from the scsi probe section of a CAM & non CAM kernel are below, & I'd be glad to provide any other information that would help. Thanks, Shafeeq messages from CAM kernel : Jun 9 23:03:02 luthien /kernel.CAM: bt0: Using Strict Round Robin Mailbox Mode Jun 9 23:03:02 luthien /kernel.CAM: SMP: AP CPU #1 Launched! Jun 9 23:03:02 luthien /kernel.CAM: SMP: CPU1 apic_initialize(): Jun 9 23:03:02 luthien /kernel.CAM: lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff Jun 9 23:03:02 luthien /kernel.CAM: (probe0:bt0:0:0:1): INQUIRY. CDB: 12 20 0 0 24 0 Jun 9 23:03:02 luthien /kernel.CAM: (probe0:bt0:0:0:1): error code 67 Jun 9 23:03:02 luthien /kernel.CAM: (probe0:bt0:0:0:2): INQUIRY. CDB: 12 40 0 0 24 0 Jun 9 23:03:02 luthien /kernel.CAM: (probe0:bt0:0:0:2): error code 48 Jun 9 23:03:02 luthien /kernel.CAM: (probe0:bt0:0:0:3): INQUIRY. CDB: 12 60 0 0 24 0 Jun 9 23:03:03 luthien /kernel.CAM: (probe0:bt0:0:0:3): error code 77 Jun 9 23:03:03 luthien /kernel.CAM: (probe4:bt0:0:0:4): INQUIRY. CDB: 12 80 0 0 Jun 9 23:03:03 luthien /kernel.CAM: 24 0 Jun 9 23:03:03 luthien /kernel.CAM: (probe4:bt0:0:0:4): error code 67 Jun 9 23:03:03 luthien /kernel.CAM: (probe4:bt0:0:0:5): INQUIRY. CDB: 12 a0 0 0 24 0 Jun 9 23:03:03 luthien /kernel.CAM: (probe4:bt0:0:0:5): error code 67 Jun 9 23:03:03 luthien /kernel.CAM: (probe4:bt0:0:0:6): INQUIRY. CDB: 12 c0 0 0 24 0 Jun 9 23:03:03 luthien /kernel.CAM: (probe4:bt0:0:0:6): error code 67 Jun 9 23:03:03 luthien /kernel.CAM: (probe2:bt0:0:0:7): INQUIRY. CDB: 12 e0 0 0 24 0 Jun 9 23:03:03 luthien /kernel.CAM: (probe2:bt0:0:0:7): error code 67 Jun 9 23:03:04 luthien /kernel.CAM: pass0 at bt0 bus 0 target 0 lun 0 Jun 9 23:03:04 luthien /kernel.CAM: pass0: Fixed Direct Access SCSI2 device Jun 9 23:03:04 luthien /kernel.CAM: pass0: 10.0MB/s transfers (10.0MHz, offset 15) Jun 9 23:03:04 luthien /kernel.CAM: pass1 at bt0 bus 0 target 1 lun 0 Jun 9 23:03:04 luthien /kernel.CAM: pass1: Fixed Direct Access SCSI2 device Jun 9 23:03:04 luthien /kernel.CAM: pass1: 5.0MB/s transfers (5.0MHz, offset 12) Jun 9 23:03:04 luthien /kernel.CAM: pass2 at bt0 bus 0 target 2 lun 0 Jun 9 23:03:04 luthien /kernel.CAM: pass2: Fixed Direct Access SCSI2 device Jun 9 23:03:04 luthien /kernel.CAM: pass2: 10.0MB/s transfers (10.0MHz, offset 8) Jun 9 23:03:04 luthien /kernel.CAM: pass3 at bt0 bus 0 target 3 lun 0 Jun 9 23:03:04 luthien /kernel.CAM: pass3: Fixed Direct Access SCSI2 device Jun 9 23:03:04 luthien /kernel.CAM: pass3: Serial Number 0000A00000 Jun 9 23:03:05 luthien /kernel.CAM: pass3: 10.0MB/s transfers (10.0MHz, offset 8), Tagged Queueing Enabled Jun 9 23:03:05 luthien /kernel.CAM: pass4 at bt0 bus 0 target 4 lun 0 Jun 9 23:03:05 luthien /kernel.CAM: pass4: Fixed Direct Access SCSI2 device Jun 9 23:03:05 luthien /kernel.CAM: pass4: 1 Jun 9 23:03:05 luthien /kernel.CAM: 0.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled Jun 9 23:03:05 luthien /kernel.CAM: pass5 at bt0 bus 0 target 5 lun 0 Jun 9 23:03:05 luthien /kernel.CAM: pass5: Removable CD-ROM SCSI2 device Jun 9 23:03:05 luthien /kernel.CAM: pass5: 6.756MB/s transfers (6.756MHz, offset 15) Jun 9 23:03:05 luthien /kernel.CAM: da0 at bt0 bus 0 target 0 lun 0 Jun 9 23:03:05 luthien /kernel.CAM: da0: Fixed Direct Access SCSI2 device Jun 9 23:03:05 luthien /kernel.CAM: da0: 10.0MB/s transfers (10.0MHz, offset 15) Jun 9 23:03:06 luthien /kernel.CAM: da0: 257MB (528354 512 byte sectors: 64H 32S/T 257C) Jun 9 23:03:06 luthien /kernel.CAM: da2 at bt0 bus 0 target 2 lun 0 Jun 9 23:03:06 luthien /kernel.CAM: da2: Fixed Direct Access SCSI2 device Jun 9 23:03:06 luthien /kernel.CAM: da2: 10.0MB/s transfers (10.0MHz, offset 8) Jun 9 23:03:06 luthien /kernel.CAM: da2: 516MB (1057616 512 byte sectors: 64H 32S/T 516C) Jun 9 23:03:06 luthien /kernel.CAM: da3 at bt0 bus 0 target 3 lun 0 Jun 9 23:03:06 luthien /kernel.CAM: da3: Fixed Direct Access SCSI2 device Jun 9 23:03:06 luthien /kernel.CAM: da3: Serial Number 0000A00000 Jun 9 23:03:06 luthien /kernel.CAM: da3: 10.0MB/s transfers (10.0MHz, offset 8), Tagged Queueing Enabled Jun 9 23:03:06 luthien /kernel.CAM: da3: 1001MB (2051000 512 byte sectors: 64H 32S/T 1001C) Jun 9 23:03:06 luthien /kernel.CAM: da4 at bt0 bus 0 target 4 lun 0 Jun 9 23:03:06 luthien /kernel.CAM: da4: Fixed Direct Access SCSI2 device Jun 9 23:03:07 luthien /kernel.CAM: da4: 10.0MB/s transfers (10.0MHz, offset 15), Tagged Queueing Enabled Jun 9 23:03:07 luthien /kernel.CAM: da4: 859MB (17595 Jun 9 23:03:07 luthien /kernel.CAM: 32 512 byte sectors: 64H 32S/T 859C) Jun 9 23:03:07 luthien /kernel.CAM: Considering FFS root f/s. Jun 9 23:03:07 luthien /kernel.CAM: changing root device to da0s1a Jun 9 23:03:07 luthien /kernel.CAM: da0s1: type 0xa5, start 32, end = 526335, size 526304 : OK Jun 9 23:03:07 luthien /kernel.CAM: da1 at bt0 bus 0 target 1 lun 0 Jun 9 23:03:07 luthien /kernel.CAM: da1: Fixed Direct Access SCSI2 device Jun 9 23:03:07 luthien /kernel.CAM: da1: 5.0MB/s transfers (5.0MHz, offset 12) Jun 9 23:03:07 luthien /kernel.CAM: da1: 305MB (625356 512 byte sectors: 64H 32S/T 305C) Jun 9 23:03:07 luthien /kernel.CAM: cd0 at bt0 bus 0 target 5 lun 0 Jun 9 23:03:07 luthien /kernel.CAM: cd0: Removable CD-ROM SCSI2 device Jun 9 23:03:08 luthien /kernel.CAM: cd0: 6.756MB/s transfers (6.756MHz, offset 15) Jun 9 23:03:08 luthien /kernel.CAM: cd0: cd present [331886 x 2048 byte records] Jun 9 23:03:08 luthien /kernel.CAM: da2s1: type 0xa5, start 63, end = 1044224, size 1044162 : OK Jun 9 23:03:08 luthien /kernel.CAM: da1s1: type 0xa5, start 32, end = 624639, size 624608 : OK Jun 9 23:03:08 luthien /kernel.CAM: da3s1: type 0xa5, start 32, end = 2050047, size 2050016 : OK Jun 9 23:03:08 luthien /kernel.CAM: da4s1: type 0xa5, start 63, end = 1751084, size 1751022 : OK Jun 9 23:03:08 luthien /kernel.CAM: da2s1: type 0xa5, start 63, end = 1044224, size 1044162 : OK Jun 9 23:03:08 luthien /kernel.CAM: da1s1: type 0xa5, start 32, end = 624639, size 624608 : OK Jun 9 23:03:08 luthien /kernel.CAM: da3s1: type 0xa5, start 32, end = 2050047, size 2050016 : OK Jun 9 23:03:08 luthien /kernel.CAM: da4s1: type 0xa5, start 63, end ------------------------------------------------------------------------------ This is is the scsi probe section of the same machine booting with a non-cam kernel. Note the presence of cd1 on scsi id 6 : ------------------------------------------------------------------------------ Jun 8 11:26:38 luthien /kernel: bt0: rev 0x08 int a irq 17 on pci0.19.0 Jun 8 11:26:38 luthien /kernel: bt0: Bt948 / 0-(32bit) bus Jun 8 11:26:38 luthien /kernel: bt0: reading board settings, busmastering, int=15 Jun 8 11:26:39 luthien /kernel: bt0: version 5.06I, fast sync, parity, 32 mbxs, 32 ccbs Jun 8 11:26:39 luthien /kernel: bt0: targ 0 sync rate=10.00MB/s(100ns), offset=15 Jun 8 11:26:39 luthien /kernel: bt0: targ 1 sync rate= 5.00MB/s(200ns), offset=12 Jun 8 11:26:39 luthien /kernel: bt0: targ 2 sync rate=10.00MB/s(100ns), offset=08 Jun 8 11:26:39 luthien /kernel: bt0: targ 3 sync rate=10.00MB/s(100ns), offset=08 Jun 8 11:26:39 luthien /kernel: bt0: targ 4 sync rate=10.00MB/s(100ns), offset=15 Jun 8 11:26:39 luthien /kernel: bt0: targ 5 sync rate= 6.66MB/s(150ns), offset=15 Jun 8 11:26:39 luthien /kernel: bt0: targ 6 sync rate= 5.00MB/s(200ns), offset=12 Jun 8 11:26:39 luthien /kernel: bt0: Using Strict Round robin scheme Jun 8 11:26:39 luthien /kernel: bt0: waiting for scsi devices to settle Jun 8 11:26:39 luthien /kernel: scbus0 at bt0 bus 0 Jun 8 11:26:39 luthien /kernel: sd0 at scbus0 target 0 lun 0 Jun 8 11:26:40 luthien /kernel: sd0: type 0 fixed SCSI 2 Jun 8 11:26:40 luthien /kernel: sd0: Direct-Access 257MB (528354 512 byte sectors) Jun 8 11:26:40 luthien /kernel: sd1 at scbus0 target 1 lun 0 Jun 8 11:26:40 luthien /kernel: sd1: type 0 fixed SCSI 2 Jun 8 11:26:40 luthien /kernel: sd1: Direct-Access Jun 8 11:26:40 luthien /kernel: sd1: ILLEGAL REQUEST asc:24,0 Invalid field in CDB Jun 8 11:26:40 luthien /kernel: sd1 could not mode sense (4). Using ficticious geometry Jun 8 11:26:40 luthien /kernel: 305MB (625356 512 byte sectors) Jun 8 11:26:40 luthien /kernel: sd2 at scbus0 target 2 lun 0 Jun 8 11:26:40 luthien /kernel: sd2: type 0 fixed SCSI 2 Jun 8 11:26:40 luthien /kernel: sd2: Direct-Access 516MB (1057616 512 byte sectors) Jun 8 11:26:40 luthien /kernel: sd3 at scbus0 target 3 lun 0 Jun 8 11:26:41 luthien /kernel: sd3: type 0 fixed SCSI 2 Jun 8 11:26:41 luthien /kernel: sd3: Direct-Access 1001MB (2051000 512 byte sectors) Jun 8 11:26:41 luthien /kernel: sd4 at scbus0 target 4 lun 0 Jun 8 11:26:41 luthien /kernel: sd4: type 0 fixed SCSI 2 Jun 8 11:26:41 luthien /kernel: sd4: Direct-Access 859MB (1759532 512 byte sectors) Jun 8 11:26:41 luthien /kernel: cd0 at scbus0 target 5 lun 0 Jun 8 11:26:41 luthien /kernel: cd0: type 5 removable SCSI 2 Jun 8 11:26:41 luthien /kernel: cd0: CD-ROM cd present [331886 x 2048 byte records] Jun 8 11:26:41 luthien /kernel: cd1 at scbus0 target 6 lun 0 Jun 8 11:26:41 luthien /kernel: cd1: type 5 removable SCSI 2 Jun 8 11:26:41 luthien /kernel: cd1: CD-ROM cd present [314225 x 2048 byte records] Jun 8 11:26:41 luthien /kernel: Probing for devices on the ISA bus: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 15 15:07:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA07643 for freebsd-scsi-outgoing; Mon, 15 Jun 1998 15:07:21 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA07633 for ; Mon, 15 Jun 1998 15:07:19 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id QAA12427; Mon, 15 Jun 1998 16:02:16 -0600 (MDT) Date: Mon, 15 Jun 1998 16:02:16 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199806152202.QAA12427@narnia.plutotech.com> To: Shafeeq Sinnamohideen cc: scsi@FreeBSD.ORG Subject: Re: disappearing cdrom w/ Bt948+CAM Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > So, I decided to try out CAM on my SMP machine with a Bt-948. > The problem is that during the bus probe, it fails to discover the NEC > CDR-500 at id 6, along with the attached error messages. If I understand > correctly, the messages are the result of trying to probe LUNs of device > 0? The messages from the scsi probe section of a CAM & non CAM kernel are > below, & I'd be glad to provide any other information that would help. > > Thanks, > Shafeeq I wonder if the bt driver believes that the card is at ID 6?? Your dmesg output left out this information from the CAM boot. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Mon Jun 15 15:14:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA08674 for freebsd-scsi-outgoing; Mon, 15 Jun 1998 15:14:17 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA08619 for ; Mon, 15 Jun 1998 15:13:49 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id QAA26718; Mon, 15 Jun 1998 16:13:40 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806152213.QAA26718@panzer.plutotech.com> Subject: Re: disappearing cdrom w/ Bt948+CAM In-Reply-To: from Shafeeq Sinnamohideen at "Jun 15, 98 04:45:14 pm" To: shafeeq@cyrus.watson.org (Shafeeq Sinnamohideen) Date: Mon, 15 Jun 1998 16:13:40 -0600 (MDT) Cc: freebsd-scsi@freebsd.org, gibbs@pluto.plutotech.com X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org Precedence: bulk X-Loop: FreeBSD.org Shafeeq Sinnamohideen wrote... > So, I decided to try out CAM on my SMP machine with a Bt-948. > The problem is that during the bus probe, it fails to discover the NEC > CDR-500 at id 6, along with the attached error messages. If I understand > correctly, the messages are the result of trying to probe LUNs of device > 0? The messages from the scsi probe section of a CAM & non CAM kernel are > below, & I'd be glad to provide any other information that would help. > messages from CAM kernel : > > Jun 9 23:03:02 luthien /kernel.CAM: bt0: Using Strict Round Robin Mailbox Mode > Jun 9 23:03:02 luthien /kernel.CAM: SMP: AP CPU #1 Launched! > Jun 9 23:03:02 luthien /kernel.CAM: SMP: CPU1 apic_initialize(): > Jun 9 23:03:02 luthien /kernel.CAM: lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff > Jun 9 23:03:02 luthien /kernel.CAM: (probe0:bt0:0:0:1): INQUIRY. CDB: 12 20 0 0 24 0 > Jun 9 23:03:02 luthien /kernel.CAM: (probe0:bt0:0:0:1): error code 67 [ CONNER hard drive returning bogus error codes when it's probed on luns greater than 0 ] > Jun 9 23:03:04 luthien /kernel.CAM: pass0 at bt0 bus 0 target 0 lun 0 > Jun 9 23:03:04 luthien /kernel.CAM: pass0: Fixed Direct Access SCSI2 device > Jun 9 23:03:04 luthien /kernel.CAM: pass0: 10.0MB/s transfers (10.0MHz, offset 15) I would suggest adding a quirk entry to xpt_quirk_table in sys/cam/cam_xpt.c like this: { /* Barfs on luns > 0 */ { T_DIRECT, SIP_MEDIA_FIXED, "CONNER", "CFA270S", "*" }, CAM_QUIRK_NOLUNS, /*mintags*/2, /*maxtags*/64 }, Put that entry just before the last quirk entry in the table and see if it helps any. Let me know if that fixes your problem, we can put it in the quirk table by default if it does. As for why your second CDROM drive isn't getting recognized, I don't really have any quick answers for you. One thing to keep in mind is that the drive isn't even making it through the probe sequence. If it were, the passthrough driver at least would attach. I have a similar drive on one of my machines (running CAM): cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI2 device cd0: 3.300MB/s transfers ) cd0: cd present [314535 x 2048 byte records] Although it is on an Adaptec controller, not a BusLogic controller. The probe sequence is generally: standard inquiry [ If we have a tagged queueing device, get the control mode page to determine whether or not tagged queueing is disabled or not ] serial number test unit ready (for negotiation) One thing you might be able to do is put some printfs in probedone() to see whether various commands are succeeding or failing, and possibly get a better handle on the problem. I would suggest initially just putting a scsi_sense_print() in the PROBE_INQUIRY case of probedone(), like this: [ .... ] } else if ((done_ccb->ccb_h.status & CAM_SIM_QFRZN) != 0) { /* Don't wedge the queue */ xpt_release_devq(done_ccb->ccb_h.path->device, /*run_queue*/TRUE); } /* XXX this is new XXX */ if ((done_ccb->ccb_h.target_id == 6) && (done_ccb->ccb_h.target_lun == 0)) { printf("got an error back while probing the CDROM\n"); scsi_sense_print(&done_ccb->csio); } /* XXX end of new code */ /* * If we get to this point, we got an error status back * from the inquiry and the error status doesn't require [ .... ] You'll add that little snippet of code in around line 3422 of cam_xpt.c. Anyway, see if that reveals anything. Justin may have some ideas, since he wrote the BusLogic driver. Don't expect to hear from him until next week, though. (we'll both be at Usenix this week) One other thing....I assume you're running the latest CAM snapshot? (May 20th) If not, you need to upgrade, since there were some significant bugs in earlier versions of the CAM BusLogic driver. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 16 01:31:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA23494 for freebsd-scsi-outgoing; Tue, 16 Jun 1998 01:31:41 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from Guard.PolyNet.Lviv.UA (Guard.PolyNet.Lviv.UA [194.44.138.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA23476 for ; Tue, 16 Jun 1998 01:31:28 -0700 (PDT) (envelope-from ts@polynet.lviv.ua) From: ts@polynet.lviv.ua Received: (qmail 13805 invoked by alias); 16 Jun 1998 08:31:14 -0000 Received: (qmail 13800 invoked from network); 16 Jun 1998 08:31:14 -0000 Received: from postoffice.polynet.lviv.ua (194.44.138.1) by guard.polynet.lviv.ua with SMTP; 16 Jun 1998 08:31:14 -0000 Received: (qmail 28334 invoked by uid 1000); 16 Jun 1998 08:31:12 -0000 Date: 16 Jun 1998 11:31:12 +0300 Date: Tue, 16 Jun 1998 11:31:11 +0300 (EEST) X-Sender: ts@NetSurfer.LP.Lviv.UA To: freebsd-scsi@FreeBSD.ORG Subject: Fujitsu SCSI MO 640M - disklabel and newfs problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi I have Fujitsu SCSI-2 MO 640M drive and a disk for it. The OS sees the drive but I have a problem using a disk (was OK with Win). Can anyone tell me what parameters I can use to disklabel it? Strange, is this device/disk unpopular to freebsd people, cos I can not find it in disktab? Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 16 03:14:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA09933 for freebsd-scsi-outgoing; Tue, 16 Jun 1998 03:14:10 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nanguo.chalmers.com.au (gateway.chalmers.com.au [203.1.96.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA09868 for ; Tue, 16 Jun 1998 03:13:54 -0700 (PDT) (envelope-from robert@chalmers.com.au) Received: from chalmers.com.au (carbon.chalmers.com.au [203.1.96.26]) by nanguo.chalmers.com.au (8.8.8/8.8.8) with ESMTP id UAA18966; Tue, 16 Jun 1998 20:10:49 +1000 (EST) Message-ID: <35864725.37A32CCC@chalmers.com.au> Date: Tue, 16 Jun 1998 20:21:25 +1000 From: Robert Chalmers Reply-To: robert@chalmers.com.au Organization: chalmers.com.au X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: ts@polynet.lviv.ua CC: freebsd-scsi@FreeBSD.ORG Subject: Re: Fujitsu SCSI MO 640M - disklabel and newfs problem References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, This may be of help. I just went through this myself recently. Note please that the disk I used was a different one to yours, but the principleis the same. ======== start here ========= This is the process I used to set up a dedicated, non-boot second SCSI disk. I used an Adaptec 1542 controller. I received some good advice from Malte Lance regarding the formula to use initially to calculate disk size in sectors. I also discovered that someone else had mentioned that having an #nt value greater than 64 on i386 systems could cause incorrect results. This may be so, however Malte's formula works, and actually returns the correct number of sectors. Even though the final process chenges them to the correct ones. Malte swears by fdisk, but I prefer not to use it for various reasons. The business of setting up a SCSI drive this way can seem complex, but if taken a step at a time goes ok usually. If you have a new SCSI drive, there is no need to format it. However, there is some inforamtion you need to discover, the most important of which is the total number of cylinders on the disk. Scsiformat is the only way I know of discovering this. You should note here that this first comamnd is non-destructive. On a new drive it should be all you need. Use the scsiformat command to discover your number of cylinders. This has a -p, and an ordinary 'd' followed bye the drive id. sd1 for your second disk. Don't mess with the primary disk, which would be sd0. All the man commands use sd0 as examples, so don't type them by mistake. You will nuke your operating system! So, Command line: scsiformat -p d sd1 Returns; (in my case) ---------------- COMPAQ C2490A 3184 Mode data length: 35 Medium type: 0 Device Specific Parameter: 0 Block descriptor length: 8 Density code: 0 Number of blocks: 0 Reserved: 0 Block length: 512 PS: 0 Reserved: 0 Page code: 4 Page length: 22 Number of Cylinders: 2630 <------------ this is what you want. Number of Heads: 18 Starting Cylinder-Write Precompensation: 0 Starting Cylinder-Reduced Write Current: 0 Drive Step Rate: 0 Landing Zone Cylinder: 0 Reserved: 0 RPL: 0 Rotational Offset: 0 Reserved: 0 Medium Rotation Rate: 6400 Reserved: 0 Reserved: 0 -------------------------------- You should redirect this output to the printer. Keep it for future reference. If you have a second hand disk, or the above command would not return the correct information, or any information, you may have to actually do a low-level format of the drive. This wont hurt, but can take ...... ages ...... When it starts, you get a warning that formatting will take place in three (3) seconds ahhhhhh. Dont worry, unless you used the wrong disk id. Make sure you get sd1 right, not sd0!!!! Commandline: scsiformat -w sd1 Starts in 3 seconds.... (takes about 15 minutes for a 2.1Gb drive) Write down your total number of cylinders number, or re-issue the scsiformat -p -d sd1 command and print it out. -------------------------------- Next step is to set up your disktab entry. Set up /etc/disktab entry: entry for a 2.1Gb Compaq SCSI Calculate true size in sectors with this formula; sectors/track * tracks/cylinder * cylinders Malte suggests #ns=32 #nt=64 and your total cylinder number gleaned from the scsiformat -p d sd1 command. In my case, the formula gives: 32 * 64 * 2630 = 5386240 -------------------------------- My disktab entry looks like this; c2490a|Compaq C2490A SCSI:\ :ty=winchester:dt=SCSI:ns#32:nt#64:nc#2630:\ :pa#2055000:oa#0:ta=4.2BSD:\ :pb#336640:ob#2055000:tb=swap:\ :pc#5386240:oc#0:\ :pd#1497300:od#2391640:td=4.2BSD:\ :pe#1497300:oe#3888940:te=4.2BSD: This actually states the partiton sizes, and the offsets. That is, where each partiton starts. Look at the last entry. It starts at sector 3888940, and is 1497300 in size. adds up to 5386240, the total size. You cant go past that of course. ------------------------------ Having checked your work, run this little script: it prevents you typing in the wrong scsi disk number!!! I called it tabmake.sh, and set it 755. disklabel -w -r /dev/rsd1c c2490a sd1s1 echo "Done" This SHOULD run with out error and produce the word "Done" If you get errors - go back and check your numbers in disktab! Then, disklabel sd1 should produce your equivelant of this. I notice also that the RPM is different to thatin the scsiformat command line return. Which gives 6400 Also, once you have used disktab, your cant do it this way again, unless you go back to step 1, and format the drive to remove the partition information. Ok, to check you work, do a disklabel sd1 You will notice that the numbers have changed from those in the disktab entry. Don't worry. Its a 'best fit' effort by the system to round things off on boundaries. You can actually modify this with the disklabel editing facility, and write it back to disk. Be careful though. # /dev/rsd1c: type: SCSI disk: c2490a label: sd1s1 flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 2006 sectors/unit: 4110000 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 5 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2055000 0 4.2BSD 0 0 0 # (Cyl. 0 - 1003*) b: 336640 2055000 swap # (Cyl. 1003*- 1167*) c: 4110000 0 unused 0 0 # (Cyl. 0 - 2006*) d: 1497300 2391640 4.2BSD 0 0 0 # (Cyl. 1167*- 1898*) e: 1497300 2612700 4.2BSD 0 0 0 # (Cyl. 1275*- 2006*) Ok, thats about it. Its an interesting experiment. You get to see whats going on, and learn how to write a disktab entry into the bargin. Bob =========== end here ============= ts@polynet.lviv.ua wrote: > > Hi > I have Fujitsu SCSI-2 MO 640M drive and a disk for it. > The OS sees the drive but I have a problem using a disk (was OK with Win). > Can anyone tell me what parameters I can use to disklabel it? > Strange, is this device/disk unpopular to freebsd people, cos I can not > find it in disktab? > Thanks. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message -- Support Whirled Peas. Business in China? China House robert@chalmers.com.au ph:61 7 49440357 fx:61 7 49578425 China House Uses Webposition to ensure Top Spot in Searches http://www.chalmers.com.au/ChinaHouse/Business/webposition To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 16 11:50:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA00401 for freebsd-scsi-outgoing; Tue, 16 Jun 1998 11:50:38 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from po6.andrew.cmu.edu (PO6.ANDREW.CMU.EDU [128.2.10.106]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA00384 for ; Tue, 16 Jun 1998 11:50:33 -0700 (PDT) (envelope-from yunching+@andrew.cmu.edu) Received: (from postman@localhost) by po6.andrew.cmu.edu (8.8.5/8.8.2) id OAA05996; Tue, 16 Jun 1998 14:47:00 -0400 (EDT) Received: via switchmail; Tue, 16 Jun 1998 14:46:58 -0400 (EDT) Received: from unix10.andrew.cmu.edu via qmail ID ; Tue, 16 Jun 1998 14:45:47 -0400 (EDT) Received: from unix10.andrew.cmu.edu via qmail ID ; Tue, 16 Jun 1998 14:45:47 -0400 (EDT) Received: from mms.4.60.Jun.27.1996.03.02.53.sun4.51.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.unix10.andrew.cmu.edu.sun4m.54 via MS.5.6.unix10.andrew.cmu.edu.sun4_51; Tue, 16 Jun 1998 14:45:47 -0400 (EDT) Message-ID: Date: Tue, 16 Jun 1998 14:45:47 -0400 (EDT) From: Yun-Ching Lee To: freebsd-scsi@FreeBSD.ORG, ts@polynet.lviv.ua Subject: Re: Fujitsu SCSI MO 640M - disklabel and newfs problem In-Reply-To: References: Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Excerpts from internet.computing.freebsd.scsi: 16-Jun-98 Fujitsu SCSI MO 640M - disk.. by ts@polynet.lviv.ua > I have Fujitsu SCSI-2 MO 640M drive and a disk for it. > The OS sees the drive but I have a problem using a disk (was OK with Win). What kind of cartridge are you trying to use? Which version of FreeBSD are you running? If you are using 640MB cartridge with 2K sectorsize, you will need to patch the kernel if it's not 3.0-CURRENT. I patched my 2.2 and on kernel with mo2048-kit.tar.gz from ftp://ftp.freebsd.org/pub/FreeBSD/incoming , but it's not there any more. I have this patch somewhere on my computer, unfortunately, it's in some paper box somewhere. 540MB and below cartridges should work just fine without any kernel patches. > Can anyone tell me what parameters I can use to disklabel it? > Strange, is this device/disk unpopular to freebsd people, cos I can not > find it in disktab? I have one that works great for me. Try to search the mailing list archive; there has been a thread on this subject around August of last year. I remember there were few posts with disklabels, which worked just fine with me. -- Yun-Ching (Allen) Lee ycl+@cmu.edu "There is no such thing as a good influence... All influence is immoral." -- Lord Henry Wotton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 16 13:01:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA11547 for freebsd-scsi-outgoing; Tue, 16 Jun 1998 13:01:16 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA11537 for ; Tue, 16 Jun 1998 13:01:05 -0700 (PDT) (envelope-from reilly@zeta.org.au) Received: from zeta.org.au (d83.syd2.zeta.org.au [203.26.11.83]) by godzilla.zeta.org.au (8.8.7/8.8.7) with ESMTP id GAA28456 for ; Wed, 17 Jun 1998 06:01:00 +1000 Received: (qmail 7543 invoked by uid 1000); 16 Jun 1998 13:20:09 -0000 Message-ID: <19980616232009.29194@gurney.reilly.home> Date: Tue, 16 Jun 1998 23:20:09 +1000 From: Andrew Reilly To: ts@polynet.lviv.ua Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Fujitsu SCSI MO 640M - disklabel and newfs problem References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67e In-Reply-To: ; from ts@polynet.lviv.ua on Tue, Jun 16, 1998 at 11:31:11AM +0300 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jun 16, 1998 at 11:31:11AM +0300, ts@polynet.lviv.ua wrote: > I have Fujitsu SCSI-2 MO 640M drive and a disk for it. > The OS sees the drive but I have a problem using a disk (was OK with Win). > Can anyone tell me what parameters I can use to disklabel it? > Strange, is this device/disk unpopular to freebsd people, cos I can not > find it in disktab? > Thanks. Unless someone else pipes up to the contrary, it's my experience that you cannot do this (talk to 640M disks) under FreeBSD at all, at the moment. I have one (a M2513A), and FreeBSD 2.2.6+(May 11). I believe that 3.0-current can't do much better. The problem is that the 640M disks have sectors that are 2k bytes long, rather than the usual 512. FreeBSD does all file system and device calculations in terms of a global block size, which is 512 bytes. I believe that there are moves afoot to rectify this situation. Perhaps as part of the DEVFS change? In the mean-time, your best bet is to buy some of the 540M media: they have 512-byte sectors. I haven't tried them myself yet, but I know that the 230M disks work. It's all a bit disappointing, really. -- Andrew "The steady state of disks is full." -- Ken Thompson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 16 14:58:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA02506 for freebsd-scsi-outgoing; Tue, 16 Jun 1998 14:58:14 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from tor-dev1.nbc.netcom.ca (tor-dev1.nbc.netcom.ca [207.181.89.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA02485 for ; Tue, 16 Jun 1998 14:58:07 -0700 (PDT) (envelope-from dacole@netcom.ca) Received: from localhost (dacole@localhost) by tor-dev1.nbc.netcom.ca (8.8.8/8.8.8) with SMTP id RAA10054 for ; Tue, 16 Jun 1998 17:57:45 -0400 (EDT) X-Authentication-Warning: tor-dev1.nbc.netcom.ca: dacole owned process doing -bs Date: Tue, 16 Jun 1998 17:57:45 -0400 (EDT) From: Dave Cole X-Sender: dacole@tor-dev1.nbc.netcom.ca To: scsi@FreeBSD.ORG Subject: cam + freebsd-current? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been wanting to try out CAM with a few tape drives and libraries here, but I can't seem to compile -current with the latest CAM snapshot (from 980520). I have been getting this error for a few weeks now: awk: cmd. line:2: fatal: cannot open file `/bin/../sys/param.h' for reading (No such file or directory)*** Error code 2 I thought I saw someone mention recently that they had CAM working with a very recent -current, though I can't find that email now. Was it just my imagination? ---------------------------------------------------------------- Dave Cole (DC1110) | dacole@netcom.ca Systems Administrator |* dacole@rik.net * | office/~dacole/ Netcom Canada |* www.rik.net/~dacole/ * 905 King Street West, Toronto, M6K 3G9 | phone - 416.341.5801 Toronto, Ontario, Canada, Earth, Sol | fax - 416.341.5725 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 16 17:49:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA02709 for freebsd-scsi-outgoing; Tue, 16 Jun 1998 17:49:55 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nlanr.net (oceana.sdsc.edu [132.249.40.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA02704 for ; Tue, 16 Jun 1998 17:49:53 -0700 (PDT) (envelope-from jambi@nlanr.net) Received: from localhost (jambi@localhost) by nlanr.net (8.8.6/8.8.6) with SMTP id RAA08746; Tue, 16 Jun 1998 17:49:51 -0700 (PDT) Date: Tue, 16 Jun 1998 17:49:49 -0700 (PDT) From: Jambi To: Yun-Ching Lee cc: freebsd-scsi@FreeBSD.ORG, ts@polynet.lviv.ua Subject: USENIX anyone? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey all, I was wondering if anyone is @usenix new orleans? I'd like to meet the CAM developers to talk about disk preformance and pushing the disk/driver to a higher level. Plz respond in private. _______________________________________________ Jambi Ganbar | (619) 8220938 | jambi@nlanr.net San Diego SuperComputer Center ________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 16 18:58:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA12270 for freebsd-scsi-outgoing; Tue, 16 Jun 1998 18:58:35 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA12265 for ; Tue, 16 Jun 1998 18:58:32 -0700 (PDT) (envelope-from dan@math.berkeley.edu) Received: (from dan@localhost) by math.berkeley.edu (8.8.7/8.8.7) id SAA20496; Tue, 16 Jun 1998 18:58:31 -0700 (PDT) Date: Tue, 16 Jun 1998 18:58:31 -0700 (PDT) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199806170158.SAA20496@math.berkeley.edu> To: freebsd-scsi@FreeBSD.ORG Subject: the scsi pass through ioctl Cc: dan@math.berkeley.edu Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 1) Can someone explain the timeout member of the scsireq struct used for the SCIOCCOMMAND (scsi command pass through) ioctl()? I would guess it sets the time period after which an incomplete scsi command will be cancelled without returning scsi status and that the SCCMD_TIMEOUT code will be returned in the retsts member of the scsireq struct. Can someone confirm this? Can someone tell me in what units the timeout is specified? Seconds? Milliseconds? Days? Endless Summers? 2) A long time ago someone said in a FreeBSD mailing list that you could trash your disk contents by attempting scsi pass through commands while the disk was also doing normal file system I/O. Does anyone recall why this might have been the case and know if it might still be the case? I can think of reasons why I might want to do "harmless" scsi commands on an active disk. Dan Strick dan@math.berkeley.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Jun 16 19:24:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA17117 for freebsd-scsi-outgoing; Tue, 16 Jun 1998 19:24:19 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from enigami.com (enigami.com [208.140.182.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA17027 for ; Tue, 16 Jun 1998 19:24:02 -0700 (PDT) (envelope-from ckempf@enigami.com) Received: from singularity.enigami.com (singularity.enigami.com [208.140.182.42]) by enigami.com (8.9.0/8.9.0) with ESMTP id WAA20001 for ; Tue, 16 Jun 1998 22:23:26 -0400 (EDT) Received: (from ckempf@localhost) by singularity.enigami.com (8.9.0/8.9.0) id WAA13291; Tue, 16 Jun 1998 22:22:37 -0400 (EDT) To: freebsd-scsi@FreeBSD.ORG Subject: Re: cam + freebsd-current? References: From: Cory Kempf In-Reply-To: Dave Cole's message of "Tue, 16 Jun 1998 17:57:45 -0400 (EDT)" X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Date: 16 Jun 1998 22:22:37 -0400 Message-ID: Lines: 27 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org (oops! accidently sent the first copy to -current...) Dave Cole writes: > I've been wanting to try out CAM with a few tape drives and libraries > here, but I can't seem to compile -current with the latest CAM > snapshot (from 980520). > > awk: cmd. line:2: fatal: cannot open file `/bin/../sys/param.h' for > reading (No such file or directory)*** Error code 2 I am running -current+cam, based on the May 29th sources. To compile, I had to copy param.h from /sys/sys/param.h to /sys/param.h, if memory serves. I might have had to do another, similar sort of copy as well. +C -- Thinking of purchasing RAM from the Chip Merchant? Please read this first: Cory Kempf Macintosh / Unix Consulting & Software Development ckempf@enigami.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 17 02:56:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA14140 for freebsd-scsi-outgoing; Wed, 17 Jun 1998 02:56:27 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [208.220.66.37]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA14130 for ; Wed, 17 Jun 1998 02:56:21 -0700 (PDT) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id FAA15033; Wed, 17 Jun 1998 05:31:19 -0400 (EDT) From: Peter Dufault Message-Id: <199806170931.FAA15033@hda.hda.com> Subject: Re: the scsi pass through ioctl In-Reply-To: <199806170158.SAA20496@math.berkeley.edu> from Dan Strick at "Jun 16, 98 06:58:31 pm" To: dan@math.berkeley.edu (Dan Strick) Date: Wed, 17 Jun 1998 05:31:18 -0400 (EDT) Cc: freebsd-scsi@FreeBSD.ORG, dan@math.berkeley.edu 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 Precedence: bulk X-Loop: FreeBSD.org > 1) Can someone explain the timeout member of the scsireq struct > used for the SCIOCCOMMAND (scsi command pass through) ioctl()? > > I would guess it sets the time period after which an incomplete > scsi command will be cancelled without returning scsi status > and that the SCCMD_TIMEOUT code will be returned in the > retsts member of the scsireq struct. > > Can someone confirm this? > Can someone tell me in what units the timeout is specified? > Seconds? Milliseconds? Days? Endless Summers? Yes - milliseconds. > > 2) A long time ago someone said in a FreeBSD mailing list that you > could trash your disk contents by attempting scsi pass through > commands while the disk was also doing normal file system I/O. > > Does anyone recall why this might have been the case and know > if it might still be the case? I can think of reasons why I > might want to do "harmless" scsi commands on an active disk. I don't know of any reason and I did test it on active disks. Harmless scsi commands should be fine. Any part of the system not heavily used and not regression tested is likely to have problems and should be used cautiously at first. Formatting disks, I/O bypassing the buffer cache, and so on must be avoided... Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 17 05:56:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA16040 for freebsd-scsi-outgoing; Wed, 17 Jun 1998 05:56:17 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA15919; Wed, 17 Jun 1998 05:55:10 -0700 (PDT) (envelope-from jmb) From: "Jonathan M. Bresler" Message-Id: <199806171255.FAA15919@hub.freebsd.org> Subject: Re: USENIX anyone? In-Reply-To: from Jambi at "Jun 16, 98 05:49:49 pm" To: jambi@nlanr.net (Jambi) Date: Wed, 17 Jun 1998 05:55:09 -0700 (PDT) Cc: ycl+@CMU.EDU, freebsd-scsi@FreeBSD.ORG, ts@polynet.lviv.ua X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jambi wrote: > Hey all, > I was wondering if anyone is @usenix new orleans? I'd like to meet the > CAM developers to talk about disk preformance and pushing the disk/driver > to a higher level. Plz respond in private. we there are a number of people here: jordan hubbard, david greenman, john polstra, justin gibbs, satoshi asami, guido van rooij, poul-henning kamp, gary palmer, mike smith, mark murray, david o'obrien, and a host of other people. jmb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Jun 17 07:28:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA00596 for freebsd-scsi-outgoing; Wed, 17 Jun 1998 07:28:31 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (root@gw100.feral.com [192.67.166.129]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA00586 for ; Wed, 17 Jun 1998 07:28:29 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral-gw (mjacob@gw100.feral.com [192.67.166.129]) by feral.com (8.8.6/8.8.6) with SMTP id HAA06860; Wed, 17 Jun 1998 07:28:15 -0700 Message-ID: <3587D27F.71FA5B69@feral.com> Date: Wed, 17 Jun 1998 07:28:15 -0700 From: Matthew Jacob Organization: Feral Software X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: Peter Dufault CC: Dan Strick , freebsd-scsi@FreeBSD.ORG Subject: Re: the scsi pass through ioctl References: <199806170931.FAA15033@hda.hda.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Peter Dufault wrote: > > I don't know of any reason and I did test it on active disks. > Harmless scsi commands should be fine. Any part of the system not > heavily used and not regression tested is likely to have problems > and should be used cautiously at first. Formatting disks, I/O > bypassing the buffer cache, and so on must be avoided... Even a TEST UNIT READY may put a device over it's tag limit. Some devices and host adapter drivers may not cope with this well, but, yes, this should mostly be okay. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 18 01:02:49 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA11717 for freebsd-scsi-outgoing; Thu, 18 Jun 1998 01:02:49 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from top.worldcontrol.com (surf10.cruzers.com [205.215.232.10]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA11500 for ; Thu, 18 Jun 1998 01:01:28 -0700 (PDT) (envelope-from brian@worldcontrol.com) From: brian@worldcontrol.com Received: (qmail 404 invoked by uid 100); 18 Jun 1998 08:01:38 -0000 Message-ID: <19980618010133.A381@top.worldcontrol.com> Date: Thu, 18 Jun 1998 01:01:33 -0700 To: freebsd-multimedia@FreeBSD.ORG Cc: freebsd-scsi@FreeBSD.ORG Subject: reading m2f2 CD sectors? Mail-Followup-To: freebsd-multimedia@freebsd.org, freebsd-scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've determined that cdrecord 1.6 will write (even if I have to hack the code) what I want with regard to Mode 2 Form 2 CDROM sectors. However, I was wondering where things are these days with reading Mode 2 Form 2 sectors? In the old days, Amancio and I used some "hack" he came up with (apologies Amancio) to read M2F2 from Plextor drives. I presume (read "I'm hoping") that something more formal has developed since those days. I need to be able to read the M2F2 sectors without relying on any TOC or track info. Just raw sectors. Could some kind soul point me in the right direction. I'm also into CAM these days, so maybe someone knows of a CAM way to read M2F2. If not, running the older SCSI layer is an option. I cross-posted this to freebsd-scsi, however, I'm not subscribed there, so freebsd-scsi readers please post back to freebsd-multimedia. Thanks, -- Brian Litzinger To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 18 03:54:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA07104 for freebsd-scsi-outgoing; Thu, 18 Jun 1998 03:54:03 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from tata.research.rockwell.cz (tata.research.rockwell.cz [193.85.154.66]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id DAA07013 for ; Thu, 18 Jun 1998 03:53:49 -0700 (PDT) (envelope-from mira@rockwell.cz) Received: from rockwell.cz (aja.research.rockwell.cz [193.85.154.75]) by tata.research.rockwell.cz (8.6.9/8.6.5) with ESMTP id NAA17781 for ; Thu, 18 Jun 1998 13:03:16 +0200 Message-ID: <3588F450.4AA54C81@rockwell.cz> Date: Thu, 18 Jun 1998 13:04:48 +0200 From: Miroslav Kes Organization: Rockwell Automation Ltd., Research Center Prague X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: freebsd-scsi@FreeBSD.ORG Subject: 2.2.6 RELASE & CAM boot.flp: Unable to create a new /etc/fstab file! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi. I'm trying to install 2.2.6 with CAM on my box which is 266MHz Pentium II Microstar ATX AHA 2940U2W with ST-39173LW and ST-32272W disks Nakamichi 16x/5 CD changer Since the time I subscribed to the freebsd-scsi list I haven't seen anybody reporting successfull use of the U2W drive & discs (I hoped I would be the first :-)) Now I'm getting the "Unable to create a new /etc/fstab file! Manual intervention will be required." error message from the installation utility. Here is the whole story. Concerning installation of the 2.2.6-RELEASE I found the response from John Polstra wrote: > Ok, so I didn't read the mailing lists before I sent my question about > the AIC-7890. Now can anyone tell me where I can get a 2.2.6 boot > floppy image that has the CAM support in it so I can install the O/S.... > :-) http://www.freebsd.org/~abial/cam-boot/ - -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth I downloaded the boot.flp and kernel.flp. First I realized the boot.flp contains 3.0 kernel. I'm not sure if it's OK if I want to install the 2.2.6 but I tried to follow instructions I found on that URL. First problem I encoutered was that the installation utility reported it couldn't see the CDROM so I tried NFS installation.but the network card (3COM Fast Etherlink XL PCI 10/100) was not found either. So I replaced the CD changer with single CD-ROM drive which was found OK. After partitioning discs in this way: da0s1a / 60MB da0s1b swap 130MB da0s1e /var 100MB da0s1f /usr 1867MB da1s1e /smbshare 8683MB I got error message: "Unable to create a new /etc/fstab file! Manual intervention will be required." When I looked at the VTY shell I saw: ... cpio: /mnt/stand/sh linked to /mnt/stand/-sh /mnt/stand/-sh find: etc: no such file or directory 0 blocks DEBUG: Scaning disk da0 for root filesystem DEBUG: Scaning disk da1 for root filesystem DEBUG: Scaning disk da0 for swap filesystem DEBUG: Scaning disk da0 for swap filesystem What's going wrong? How the "Manual intervention" should look like. Any idea ? Thanks Mira -- ----------------------------------------------------------- | Miroslav Kes | |---------------------------------------------------------| | Rockwell Automation Ltd. | tel.: (+420) 2 2425 6913 | | Research Center Prague | fax: (+420) 2 250467 | | Americka 22 | e-mail: mira@rockwell.cz | | 120 00 Praha 2 - Vinohrady | | | Czech Republic | | ----------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 18 10:00:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA07004 for freebsd-scsi-outgoing; Thu, 18 Jun 1998 10:00:28 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from enigami.com (enigami.com [208.140.182.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA06884 for ; Thu, 18 Jun 1998 10:00:16 -0700 (PDT) (envelope-from ckempf@enigami.com) Received: from singularity.enigami.com (singularity.enigami.com [208.140.182.42]) by enigami.com (8.9.0/8.9.0) with ESMTP id MAA24926 for ; Thu, 18 Jun 1998 12:59:46 -0400 (EDT) Received: (from ckempf@localhost) by singularity.enigami.com (8.9.0/8.9.0) id MAA17913; Thu, 18 Jun 1998 12:58:48 -0400 (EDT) Date: Thu, 18 Jun 1998 12:58:48 -0400 (EDT) Message-Id: <199806181658.MAA17913@singularity.enigami.com> From: Cory Kempf To: freebsd-scsi@FreeBSD.ORG Subject: Rolling CAM in, what is still needed? Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What is still needed before the CAM stuff can become part of the main body of code? At least w.r.t. -current? Thanks, +C To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 18 13:45:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA09936 for freebsd-scsi-outgoing; Thu, 18 Jun 1998 13:45:44 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA09923 for ; Thu, 18 Jun 1998 13:45:40 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id OAA08675; Thu, 18 Jun 1998 14:45:23 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806182045.OAA08675@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806181658.MAA17913@singularity.enigami.com> from Cory Kempf at "Jun 18, 98 12:58:48 pm" To: ckempf@enigami.com (Cory Kempf) Date: Thu, 18 Jun 1998 14:45:23 -0600 (MDT) Cc: freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Cory Kempf wrote... > What is still needed before the CAM stuff can become part of the main > body of code? At least w.r.t. -current? More hardware support, including: - Adaptec 1542 (Brian Beattie is working on this) - Adaptec 1742 (Justin said he started on this) - Adaptec AIC-6260 and 6360 - DPT support (Simon is working on this) - Better NCR support (810's don't work too well, I think) - Ultrastor? (Warner may be working on this) I started work on a WORM driver, but it's temporarily on hold until we get some answers back from Plextor on why negotiation is broken on the 4/12 Max. (i.e. that's the drive I got to do the worm driver, but I can't continue until we get a fix from them. If someone sends me another worm drive, the driver will probably get done faster since Plextor hasn't been too responsive to Justin's problem report.) Most of the pieces are there. The next snapshot will have mode page editing support, like the old SCSI code (in fact I just ported the code from the old SCSI layer). It will also have arbitrary SCSI cdb execution support, like the old SCSI layer. There are still a few bugs to be worked out in that code, and a few features to add, but it's pretty much all there now. So, the bottom line is that things are getting closer, but hardware drivers are our weak point right now. One other area that could use some work/help is userland application porting. So far, we have: - xmcd (ported by me) - cdrecord (Mike Smith) - tosha (Russell Cattelan, patch is in my inbox) We don't yet have: - SANE - cdd There may be other applications that send SCSI commands directly to drives, I can't think of any off the top of my head. If there are any more, someone let me know. If anyone wants to do SANE or cdd or some other application, I'm more than willing to help out. (although I don't have a scanner) Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 18 14:08:36 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14390 for freebsd-scsi-outgoing; Thu, 18 Jun 1998 14:08:36 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from itsdsv1.enc.edu (fw1.enc.edu [207.95.42.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14361 for ; Thu, 18 Jun 1998 14:08:32 -0700 (PDT) (envelope-from owensc@enc.edu) Received: from itsdsv2.enc.edu (itsdsv2.enc.edu [10.1.1.9]) by itsdsv1.enc.edu (8.7.5/8.7.3) with SMTP id RAA02387 for ; Thu, 18 Jun 1998 17:07:32 -0400 (EDT) Date: Thu, 18 Jun 1998 17:07:32 -0400 (EDT) From: Charles Owens To: freebsd-scsi@FreeBSD.ORG Subject: Sony AIT tape drive support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Howdy, Has anyone here played with one of these drives with FreeBSD? These drives, of course, have an extended SCSI command set that allows access to the on-tape memory chip for the storing of index information, etc. My understanding is that when used with a plain, vanilla SCSI tape driver the AIT unit behaves just like a regular 8-millimeter drive (just with higher capacity and better throughput perhaps). Access to the other AIT nifty features (fast access times, no need to rewind prior to tape removal, etc.) requires a driver that utilizes this extended SCSI command set. Am I right here? Any further comments? Has anyone been thinking about adding support the extra AIT functionality to the standard SCSI driver (or pehaps making a separate AIT driver)? I should have one of these drives (installed in a nifty 28-tape library!) to play with in a few weeks. I'll be fine without support for the extra features since I mostly just care about the high storage capacity. Pleace cc: any replys to me directly since I'm not on the -scsi list. Thanks, --- ------------------------------------------------------------------------- Charles N. Owens Email: owensc@enc.edu http://www.enc.edu/~owensc Network & Systems Administrator Information Technology Services "Outside of a dog, a book is a man's Eastern Nazarene College best friend. Inside of a dog it's too dark to read." - Groucho Marx ------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 18 14:09:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA14774 for freebsd-scsi-outgoing; Thu, 18 Jun 1998 14:09:59 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from scifair.acadiau.ca (scifair.acadiau.ca [131.162.160.32]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA14727 for ; Thu, 18 Jun 1998 14:09:50 -0700 (PDT) (envelope-from miker@scifair.acadiau.ca) Received: from localhost (miker@localhost) by scifair.acadiau.ca (8.8.5/8.8.5) with SMTP id SAA00805; Thu, 18 Jun 1998 18:09:40 -0300 (ADT) Date: Thu, 18 Jun 1998 18:09:39 -0300 (ADT) From: Michael Richards To: Miroslav Kes cc: freebsd-scsi@FreeBSD.ORG Subject: Re: 2.2.6 RELASE & CAM boot.flp: Unable to create a new /etc/fstab file! In-Reply-To: <3588F450.4AA54C81@rockwell.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 18 Jun 1998, Miroslav Kes wrote: I am having the identical problem. I did fiddle and get it to go a little further. I am installing 3.0-current on: Dual P II-300 196 MB RAM Adaptec 2940U2W Quantum 6.4G SCSI drive Jaz Drive I am actually installing onto a Jaz disk. I changed the boot rom from 0 (the quantum drive with NT on it) to 4 (the blank Jaz disk) The install stopped at the /etc/fstab point on the first try. I did some fiddling, ie tried the fixit floppy, into a shell, and looked around. The directories where there. The install, when in debug mode says that /etc does not exist. I rebooted the next day and tried the same procedure. Instead of re-partitioning and formatting, I didn't make any changes in the partitioner, and set the mount points again in the labeller. The install went further this time. It crapped out when it tried to mount my DOS partition on the SCSI 6.4 drive. In fooling with the Emergency Holographic Doctor (Er, Shell), I noticed that programs like mount, mkdir and such live on the fixit floppy. I tried copying those to /usr/bin, but it didn't seem to make a difference. I am stuck. Don't know if my creating a /usr/bin will hurt anything either. -Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 18 15:06:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24190 for freebsd-scsi-outgoing; Thu, 18 Jun 1998 15:06:01 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from tor-dev1.nbc.netcom.ca (tor-dev1.nbc.netcom.ca [207.181.89.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA24173 for ; Thu, 18 Jun 1998 15:05:56 -0700 (PDT) (envelope-from dacole@netcom.ca) Received: from localhost (dacole@localhost) by tor-dev1.nbc.netcom.ca (8.8.8/8.8.8) with SMTP id SAA16551 for ; Thu, 18 Jun 1998 18:05:31 -0400 (EDT) X-Authentication-Warning: tor-dev1.nbc.netcom.ca: dacole owned process doing -bs Date: Thu, 18 Jun 1998 18:05:31 -0400 (EDT) From: Dave Cole X-Sender: dacole@tor-dev1.nbc.netcom.ca cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806182045.OAA08675@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 18 Jun 1998, Kenneth D. Merry wrote: -Cory Kempf wrote... -> What is still needed before the CAM stuff can become part of the main -> body of code? At least w.r.t. -current? - - More hardware support, including: - - - Adaptec 1542 (Brian Beattie is working on this) - - Adaptec 1742 (Justin said he started on this) - - Adaptec AIC-6260 and 6360 While we are here, anyone heard of an Adaptec AHA-1535A? It seems to be based upon an AIC-7970Q. This is an ISA narrow scsi card with the typical internal 50 pin connector and an external 'SCSI-2' 50 pin connector. Noone here is terribly sure where this card came from. Probably an OEM card that shipped with one of our cd burners. A coworker tried using this card with fbsd-2.2.5 but found it seemingly unsupported. I haven't tried it yet since I can't find any reference to it anywhere within any version of FreeBSD. - - Better NCR support (810's don't work too well, I think) Is this currently true? I haven't heard too much on this. ---------------------------------------------------------------- Dave Cole (DC1110) | dacole@netcom.ca Systems Administrator |* dacole@rik.net * | office/~dacole/ Netcom Canada |* www.rik.net/~dacole/ * 905 King Street West, Toronto, M6K 3G9 | phone - 416.341.5801 Toronto, Ontario, Canada, Earth, Sol | fax - 416.341.5725 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 18 17:03:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11978 for freebsd-scsi-outgoing; Thu, 18 Jun 1998 17:03:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from roma.coe.ufrj.br (jonny@roma.coe.ufrj.br [146.164.53.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA11970 for ; Thu, 18 Jun 1998 17:03:02 -0700 (PDT) (envelope-from jonny@jonny.eng.br) Received: (from jonny@localhost) by roma.coe.ufrj.br (8.8.8/8.8.8) id VAA15043; Thu, 18 Jun 1998 21:02:45 -0300 (EST) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199806190002.VAA15043@roma.coe.ufrj.br> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806182045.OAA08675@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 18, 98 02:45:23 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Thu, 18 Jun 1998 21:02:45 -0300 (EST) Cc: ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org #define quoting(Kenneth D. Merry) // One other area that could use some work/help is userland // application porting. So far, we have: Isn't it possible to do a compatibility layer in CAM ? Changes in API are always a PITA. Jonny -- Joao Carlos Mendes Luis M.Sc. Student jonny@jonny.eng.br Universidade Federal do Rio de Janeiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 18 20:36:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA11116 for freebsd-scsi-outgoing; Thu, 18 Jun 1998 20:36:43 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA11080 for ; Thu, 18 Jun 1998 20:36:29 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA17382 (5.67b/IDA-1.5); Fri, 19 Jun 1998 04:55:21 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.8/8.6.12) id AAA05790; Fri, 19 Jun 1998 00:48:11 +0200 (CEST) From: Wilko Bulte Message-Id: <199806182248.AAA05790@yedi.iaf.nl> Subject: Re: Sony AIT tape drive support In-Reply-To: from Charles Owens at "Jun 18, 98 05:07:32 pm" To: owensc@enc.edu (Charles Owens) Date: Fri, 19 Jun 1998 00:48:11 +0200 (CEST) Cc: freebsd-scsi@FreeBSD.ORG X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As Charles Owens wrote... > Has anyone here played with one of these drives with FreeBSD? These Not yet, but I could borrow one from my boss and try it. Digital ^H^H^H^H^H Compaq resells them under the Storageworks brand. > My understanding is that when used with a plain, vanilla SCSI tape driver > the AIT unit behaves just like a regular 8-millimeter drive (just with > higher capacity and better throughput perhaps). Access to the other AIT > nifty features (fast access times, no need to rewind prior to tape > removal, etc.) requires a driver that utilizes this extended SCSI command > set. > > Am I right here? Any further comments? Has anyone been thinking about I think so. The current Digital operating systems don't make use (yet?) of the chip in the cassette. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl |/|/ / / /( (_) Arnhem, The Netherlands WWW: http://www.tcja.nl ______________________________________________ Powered by FreeBSD __________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 18 20:54:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA14292 for freebsd-scsi-outgoing; Thu, 18 Jun 1998 20:54:39 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA14248 for ; Thu, 18 Jun 1998 20:54:22 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id VAA10250; Thu, 18 Jun 1998 21:54:01 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806190354.VAA10250@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806190002.VAA15043@roma.coe.ufrj.br> from Joao Carlos Mendes Luis at "Jun 18, 98 09:02:45 pm" To: jonny@jonny.eng.br (Joao Carlos Mendes Luis) Date: Thu, 18 Jun 1998 21:54:01 -0600 (MDT) Cc: ken@plutotech.com, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Joao Carlos Mendes Luis wrote... > #define quoting(Kenneth D. Merry) > // One other area that could use some work/help is userland > // application porting. So far, we have: > > Isn't it possible to do a compatibility layer in CAM ? Changes in > API are always a PITA. Yeah, in fact I even had a SCIOCCOMMAND implementation for the passthrough driver early on. I would much rather, however, move applications over to the new API. It isn't that hard to use. I know that changes in API can be a PITA, I had to port a very large application from the old scsireq/SCIOCCOMMAND system to the new passthrough driver. We can't keep old API's around forever for no particular reason, so I'd rather go ahead and port things. In any case, most of the major consumers of the old SCSI passthrough facilities have been ported. cdd and SANE have not, but my guess is that there aren't many more than that. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 18 21:01:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA15288 for freebsd-scsi-outgoing; Thu, 18 Jun 1998 21:01:31 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from roma.coe.ufrj.br (jonny@roma.coe.ufrj.br [146.164.53.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA15278 for ; Thu, 18 Jun 1998 21:01:25 -0700 (PDT) (envelope-from jonny@jonny.eng.br) Received: (from jonny@localhost) by roma.coe.ufrj.br (8.8.8/8.8.8) id BAA25325; Fri, 19 Jun 1998 01:00:55 -0300 (EST) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199806190400.BAA25325@roma.coe.ufrj.br> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806190354.VAA10250@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 18, 98 09:54:01 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Fri, 19 Jun 1998 01:00:54 -0300 (EST) Cc: jonny@jonny.eng.br, ken@plutotech.com, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org #define quoting(Kenneth D. Merry) // Joao Carlos Mendes Luis wrote... // > #define quoting(Kenneth D. Merry) // > // One other area that could use some work/help is userland // > // application porting. So far, we have: // > // > Isn't it possible to do a compatibility layer in CAM ? Changes in // > API are always a PITA. // // Yeah, in fact I even had a SCIOCCOMMAND implementation for the // passthrough driver early on. I would much rather, however, move // applications over to the new API. It isn't that hard to use. // // I know that changes in API can be a PITA, I had to port a very // large application from the old scsireq/SCIOCCOMMAND system to the new // passthrough driver. We can't keep old API's around forever for no // particular reason, so I'd rather go ahead and port things. Sorry for my ignorance, but is this interface FreeBSD only ? If it's somewhat generic (say, *BSD), I'd prefer to have both, and have immediate portability for "future" applications. Is there a big advantage on the new scheme ? At least, while CAM is in transition mode, being available only as patches, the compatibilty API would make easy to choose cam or not-cam during boot time (for those interfaces available in both modes, of course). I hope that's what you said above. As always, JMHO, and not being an involved programmer, my vote is not much here. :) Jonny -- Joao Carlos Mendes Luis M.Sc. Student jonny@jonny.eng.br Universidade Federal do Rio de Janeiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Jun 18 21:14:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA17859 for freebsd-scsi-outgoing; Thu, 18 Jun 1998 21:14:42 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA17842 for ; Thu, 18 Jun 1998 21:14:36 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id WAA10410; Thu, 18 Jun 1998 22:14:26 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806190414.WAA10410@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806190400.BAA25325@roma.coe.ufrj.br> from Joao Carlos Mendes Luis at "Jun 19, 98 01:00:54 am" To: jonny@jonny.eng.br (Joao Carlos Mendes Luis) Date: Thu, 18 Jun 1998 22:14:25 -0600 (MDT) Cc: ken@plutotech.com, jonny@jonny.eng.br, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Joao Carlos Mendes Luis wrote... > #define quoting(Kenneth D. Merry) > // I know that changes in API can be a PITA, I had to port a very > // large application from the old scsireq/SCIOCCOMMAND system to the new > // passthrough driver. We can't keep old API's around forever for no > // particular reason, so I'd rather go ahead and port things. > > Sorry for my ignorance, but is this interface FreeBSD only ? Nope, it's also used in NetBSD and OpenBSD, I think. > If it's somewhat generic (say, *BSD), I'd prefer to have both, > and have immediate portability for "future" applications. > Is there a big advantage on the new scheme ? Yeah, it doesn't involve needless translation, and you can send more than just SCSI commands with it. You can send any type of CCB using the standard passthrough ioctl. > At least, while CAM is in transition mode, being available only > as patches, the compatibilty API would make easy to choose cam > or not-cam during boot time (for those interfaces available in > both modes, of course). I hope that's what you said above. Yeah, you could do it that way I suppose. But there's more than just random SCSI utilities that will break if you run a CAM userland with a regular -current kernel. The device statistics code is completely different in CAM, and all the dk* stuff doesn't exist anymore. i.e. systat, iostat, vmstat and rpc.rstatd compiled under CAM won't work right with a regular -current kernel, and vice versa. > As always, JMHO, and not being an involved programmer, my vote > is not much here. :) I'm not terribly inclined to do it myself, at the moment I don't think it's really worth the effort. If someone else thinks it's important to have scsireq support, and wants to go through the trouble to do it, I may be able to fish out my (probably now broken) code to implement the SCIOCCOMMAND in the passthrough driver. You'll still have to point the applications to /dev/rpassn, though. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 19 07:59:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26360 for freebsd-scsi-outgoing; Fri, 19 Jun 1998 07:59:25 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA26329 for ; Fri, 19 Jun 1998 07:59:10 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id HAA21572; Fri, 19 Jun 1998 07:49:24 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd021569; Fri Jun 19 14:49:15 1998 Date: Fri, 19 Jun 1998 07:49:12 -0700 (PDT) From: Julian Elischer To: "Kenneth D. Merry" cc: Joao Carlos Mendes Luis , ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806190414.WAA10410@panzer.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org surely both old and new interfaces can co-exist.. this is really quite important for netBSD binary compatibility.. Juat mention in the man pages that the old one is less prefered and slower (is it?) Surely the old interface is pretty generic.. (userland scsi that is) On Thu, 18 Jun 1998, Kenneth D. Merry wrote: > Joao Carlos Mendes Luis wrote... > > #define quoting(Kenneth D. Merry) > > // I know that changes in API can be a PITA, I had to port a very > > // large application from the old scsireq/SCIOCCOMMAND system to the new > > // passthrough driver. We can't keep old API's around forever for no > > // particular reason, so I'd rather go ahead and port things. > > > > Sorry for my ignorance, but is this interface FreeBSD only ? > > Nope, it's also used in NetBSD and OpenBSD, I think. > > > If it's somewhat generic (say, *BSD), I'd prefer to have both, > > and have immediate portability for "future" applications. > > Is there a big advantage on the new scheme ? > > Yeah, it doesn't involve needless translation, and you can send > more than just SCSI commands with it. You can send any type of CCB using > the standard passthrough ioctl. > > > At least, while CAM is in transition mode, being available only > > as patches, the compatibilty API would make easy to choose cam > > or not-cam during boot time (for those interfaces available in > > both modes, of course). I hope that's what you said above. > > Yeah, you could do it that way I suppose. But there's more than > just random SCSI utilities that will break if you run a CAM userland with a > regular -current kernel. The device statistics code is completely > different in CAM, and all the dk* stuff doesn't exist anymore. i.e. > systat, iostat, vmstat and rpc.rstatd compiled under CAM won't work right > with a regular -current kernel, and vice versa. > > > As always, JMHO, and not being an involved programmer, my vote > > is not much here. :) > > I'm not terribly inclined to do it myself, at the moment I don't > think it's really worth the effort. If someone else thinks it's important > to have scsireq support, and wants to go through the trouble to do it, I > may be able to fish out my (probably now broken) code to implement the > SCIOCCOMMAND in the passthrough driver. You'll still have to point the > applications to /dev/rpassn, though. > > > Ken > -- > Kenneth Merry > ken@plutotech.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 19 09:28:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA15391 for freebsd-scsi-outgoing; Fri, 19 Jun 1998 09:28:40 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from feral.com (root@gw100.feral.com [192.67.166.129]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA15286 for ; Fri, 19 Jun 1998 09:28:21 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral-gw (mjacob@gw100.feral.com [192.67.166.129]) by feral.com (8.8.6/8.8.6) with SMTP id JAA12918; Fri, 19 Jun 1998 09:23:55 -0700 Message-ID: <358A909B.1DF72290@feral.com> Date: Fri, 19 Jun 1998 09:23:55 -0700 From: Matthew Jacob Organization: Feral Software X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: Julian Elischer CC: "Kenneth D. Merry" , Joao Carlos Mendes Luis , ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Julian Elischer wrote: > > surely both old and new interfaces can co-exist.. > this is really quite important for netBSD binary compatibility.. > Juat mention in the man pages that the old one is less prefered and slower > (is it?) The term usually used is "deprecated interfaces". And usual deprecation rules are to stop documenting a departing interface at one release, but leave it in place, and the next remove it entirely. > > Surely the old interface is pretty generic.. > > (userland scsi that is) Yes, but how many of these are there that Ken hasn't done yet? If it's really a consensus on everyone's part to have the OLD interfaces around, Ken, I'll help integrate that. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 19 10:31:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA27055 for freebsd-scsi-outgoing; Fri, 19 Jun 1998 10:31:59 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA26926 for ; Fri, 19 Jun 1998 10:31:19 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id LAA12458; Fri, 19 Jun 1998 11:30:01 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806191730.LAA12458@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <358A909B.1DF72290@feral.com> from Matthew Jacob at "Jun 19, 98 09:23:55 am" To: mjacob@feral.com (Matthew Jacob) Date: Fri, 19 Jun 1998 11:30:01 -0600 (MDT) Cc: julian@whistle.com, ken@plutotech.com, jonny@jonny.eng.br, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Jacob wrote... > Julian Elischer wrote: > > > > Surely the old interface is pretty generic.. > > > > (userland scsi that is) > > Yes, but how many of these are there that Ken hasn't done yet? Right, that's what I'm interested in. I talked to Julian this morning (in person, actually!) and that's the question I had. So I'll say it so everyone can see: - How many more programs use this (scsireq) interface? - Are people going to yell and scream loudly if it goes away when CAM is integrated into the tree?? I have already ported the largest application I know of that used the old scsireq interface. (I did it last fall, it's a big part of Pluto's products.) As far as generally available applications, I ported xmcd, Mike Smith ported cdrecord and Russell Cattelan has ported tosha. That leaves SANE and cdd. What other applications are out there, either publically available or in use privately? > If it's really a consensus on everyone's part to have the OLD > interfaces around, Ken, I'll help integrate that. Yeah, if there is enough need for it, I think we can do something, at least for one release or so. There are several issues here: - the old SCIOCCOMMAND ioctl can be emulated in the current passthrough driver, I did it at one time last year. - the problem is that with the old SCSI code, to send SCSI commands directly to a device, you opened the device itself (/dev/rcd0a or whatever) and did the SCIOCCOMMAND ioctl on that device. CAM does things differently, primarily because users may want to send commands to device, even though the device's open() routine may fail. For instance, you can't open a CD device if there is no media inserted. But the user may want to send an INQUIRY command to the drive, whether or not there's a CD in the drive. So, to solve this, you have two choices: (that I can think of offhand) - have a special control minor number for each device, and have the open call ignore failures in read capacity, test unit ready, etc. - have a separate passthrough driver that doesn't have to have any commands succeed to attach or open. For CAM, we chose the latter. Anyway, I've gotta go, so I'll just say that in order to have devices respond to the SCIOCCOMMAND ioctl in the same way, we'd have to wire code to handle that ioctl into each device driver's ioctl routine. (probably in cam_periph_ioctl()) I'd rather not kludge any of this up, though, unless someone can make a compelling case that it needs to be done. [ p.s. I won't be able to answer email again until tomorrow night. ] Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 19 10:51:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA01364 for freebsd-scsi-outgoing; Fri, 19 Jun 1998 10:51:17 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from roma.coe.ufrj.br (jonny@roma.coe.ufrj.br [146.164.53.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA01200 for ; Fri, 19 Jun 1998 10:50:17 -0700 (PDT) (envelope-from jonny@jonny.eng.br) Received: (from jonny@localhost) by roma.coe.ufrj.br (8.8.8/8.8.8) id OAA02683; Fri, 19 Jun 1998 14:42:45 -0300 (EST) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199806191742.OAA02683@roma.coe.ufrj.br> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806191730.LAA12458@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 19, 98 11:30:01 am" To: ken@plutotech.com (Kenneth D. Merry) Date: Fri, 19 Jun 1998 14:42:45 -0300 (EST) Cc: mjacob@feral.com, julian@whistle.com, ken@plutotech.com, jonny@jonny.eng.br, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org #define quoting(Kenneth D. Merry) // - the problem is that with the old SCSI code, to send SCSI commands // directly to a device, you opened the device itself (/dev/rcd0a or // whatever) and did the SCIOCCOMMAND ioctl on that device. CAM does // things differently, primarily because users may want to send // commands to device, even though the device's open() routine may // fail. For instance, you can't open a CD device if there is no // media inserted. But the user may want to send an INQUIRY command // to the drive, whether or not there's a CD in the drive. So, to // solve this, you have two choices: (that I can think of offhand) // - have a special control minor number for each device, and // have the open call ignore failures in read capacity, test // unit ready, etc. // - have a separate passthrough driver that doesn't have to // have any commands succeed to attach or open. Isn't this what /dev/xxx.ctl does ? // For CAM, we chose the latter. Anyway, I've gotta go, so I'll // just say that in order to have devices respond to the // SCIOCCOMMAND ioctl in the same way, we'd have to wire code to // handle that ioctl into each device driver's ioctl routine. // (probably in cam_periph_ioctl()) // // I'd rather not kludge any of this up, though, unless someone can // make a compelling case that it needs to be done. Maybe it's not a big problem, considering the ports collection. :) For me, the most important is to have the rules clearly defined. Being said that, both options are good enough. Jonny -- Joao Carlos Mendes Luis M.Sc. Student jonny@jonny.eng.br Universidade Federal do Rio de Janeiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 19 12:56:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA22772 for freebsd-scsi-outgoing; Fri, 19 Jun 1998 12:56:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nomis.simon-shapiro.org ([209.86.126.163]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA22417 for ; Fri, 19 Jun 1998 12:55:01 -0700 (PDT) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 2328 invoked by uid 1000); 19 Jun 1998 19:48:37 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 19 Jun 1998 15:48:37 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Chris Parry , freebsd-questions@FreeBSD.ORG, freebsd-SCSI@FreeBSD.ORG Subject: RE: DPT support binaries - How to Setup Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris, I hope you do not mind me forwarding this to FreBSD questions... On 19-Jun-98 Chris Parry wrote: >> Since I moved, my web server has been down. DPT drivers for FreeBSD are >> integral part of FreeBSD now. If you want to see the contents of my ftp >> server use ftp://simon-shapiro.org/crash >> >> There is no dptmgr for FreeBSD yet. In the works. > > Excellent. Would you know how people are currently setting up RAID on > DPT's in FreeBSD? I'm assuming something like having a dos partition, > and > doing the config there, and then just mounting the volume as sd0? I have been asked this question many times, and have also seen much misinformation in this regard, so here is a brief review. The DPT controller creates and manages RAID array in a manner totally transparent to the (ANY) operating system. Say, you have 45 disk drives, and you attach them to one DPT controller (I have several ``customers'' who do that; You need a DPT PM3334UDW, and seven disk shelves, and a very large UPS). Then you boot DOS from a floppy, take the DPT install floppy number one (comes with the controller), put it in the floppy drive and type ``dptmgr/fw0'' and press the return key. After a short while, a windows-like application starts. You do not need windows, DOS or anything installed on the machine. Just boot dos 6.22 or later (I use IBM PC-DOS 7.0) from the floppy drive. We will go to the review in a minute, but here are the the steps to create a very complex RAID subsystem, for ANY operating system, FreeBSD included. For brevity, I will use the notation cXbYtZ to define disk drives. The DPT controllers (PM3334 series can have up to three SCSI busses attached to the same controller. BTW, the correct name for a SCSI controller is HBA, as in Host Bus Adapter. Let's say we have two controllers. The first controller has 1 disk connected to the first channel, and the disk is setup (via its jumpers) to be target 1. The second controller has one disk connected to the third channel, and is setup to be target ID 15. In this example, I will call the first disk c0b0t1. The second disk I will call c1tb2t15. OK? Now, back to our monster system. Step by step: * Hook up everything. If you are not using DPT, nor DEC StorageWorks disk shelves, make SURE you bought the MOST expensive cables you can find. Ultra SCSI runs 16 bit bus at 20MHz, using electrical signals similar to ISA/PCI busses. You do not expect your PC cards to work over 30 feet of sloppy, cheap cable. Right? Do not expect SCSI to be any different. If you need long cables, or more than 5-6 drives per very short cable, get differential controllers, and good shelves. Half the people that contact me with ``DPT problems'' have cheap cables and/or disk shelves. the other half is using some Quantum Atlas drives that have old/bad/wrong firmware. About 1 in a hundred actually has a deficiency in the driver, or the firmware. this is not bragging. These are facts. I am happy to help each and every one, but your system is yours, not mine, and you need to set it up correctly. * As indicated above, boot DOS, install DPT floppy 1, and start the dptmgr with the option fw0. I will tell you later why. * If this is the very first time these disk drives are connected to the DPT controller, DPTMGR will invite you to choose an O/S. Say, Linux, or Other. Do NOT say BSDi. This is important. * In this example, We will assume a pair of DPT PM3334UDW (Ultra-wide, differential, with 3 busses) HBAs. 84 4GB drives that are all identical, We will assume that the drives are installed in DPT shelves, 7 drives per shelf. Each channel in each controller has 2 shelves attached to it; 2 shelves contain 14 drives, for a total of 6 shelves per controller, or 42 drives per controller. The shelves have to be configured for the starting TARGET ID of the shelf. One shelf has targets 0-6, the second shelf has targets 8-15. The DPT HBA has target ID 7 on all three busses. * We want to arrange the drives in this manner: 1 RAID-1 array to be used for booting the system, most installed file systems, etc. This will give us full redundancy, and yet be able to READ faster than a single disk, and WRITE almost as fast. 4GB will be enough, so this will consume exactly two drives. 1 RAID-0 array to be used for swap, /tmp, /var/tmp, /usr/obj, etc. RAID-0 is very fast, but if any disk in the array fails, the whole array will lose its data. For the indicated use, this is acceptable to us (Remember, this is just an example). We do not need an awful lot of space, but we need the speed of at least 15MB/Sec, so we will use 6 drives here. 1 Huge RAID-0 array to contain news articles. Again, we do not care if we loose the article. This array needs to be big and as fast as possible. We will use 33 disk drives here. 1 Huge RAID-5 array to contain our E-mail. We need reliability and capacity, so we will use 33 drives here. In reality, RAID-5 arrays are not so effective at this size, but this is just an exadurated example. 1 Very large RAID-5 array to contain our CVS tree. Since reliability and performance are important, we will use 8 drives here. If you add up the drives, you will see that we have two drives unassigned here. Hold on... * Before we go on to configure/create any RAID arrays, here is a bit of madness; The order in which the BIOS finds adaptors (controllers) on the PCI bus, and the order in which the SAME BIOS boots, and/or FreeBSD scans the PCI bus, can be reversed on some motherboards. What that means is that when we refer to c0bYtZ, in the context of DPTMGR, it actually may be C1bYtZ as far as Unix is concerned. In ALL my systems things are reversed: What the DPT calls HBA0, is actually HBA 1 for Unix. * Make sure the DPT sees all your devices, without errors. If you use DPT disk shelves, and see a cabling error, unplug, correct, and use the File->Read system configuration to force the DPTMGR to re-scan the busses. No need to reboot. * The next step is to define the role of each drive in the system. Drives can be themselves, part of RAID array, or Hot Spares. Drives that are Hot Spares or part of a RAID array, are invisible TO THE O/S. Again; There is no way for the O/S to see a drive that is part of a RAID array, or a hot spare. * In defining RAID arrays, DPTMGR asks you for a stripe size. Unless you have a specific reason to override the default stripe size, leave it alone. Chances are the DPT people who write the firmware know their hardware, SCSI and RAID theory better than you do. * Using the DPTMGR utility, we create a RAID-1 array using c1b0t0 and c1b1t0. Use the File->Set system Parameters to save the configuration and have the DPT start building the array. When you are done defining the array, it's icons will have black flags. When it builds, the array icon will be blue, and the drives' will be white. * While the array builds, double click on it, click on the Name button, and type in an appropriate name, for Example ``Mad_Boot-1'' to remind yourself this is the Mad system, the Boot ``disk'' (more on that later), and it is a RAID-1. Choose File->Set system Parameters to save the new name. * Double click on c1b2t0 and click on Make hot Spare. This will make this drive invisible to ?Unix, but will allow the DPT to automatically replace any defective drive with the hot spare. We will talk about that some more later. * Start creating a RAID-0 array. Add devices to this array in this order: c1b0t1, c1b1t1, c1b2t1, c1b0t2, c1b1t2, c1b2t2, c1b0t3, c1b1t3, c1b2t3... The idea is to specify the drives, alternating between busses. This gives the DPT the opportunity to load0share the busses. Performance gains are impressive. When you are done, File->Set system Parameters. Do not forget to change the array name to ``Mad-News-0'' * Do the same with the last arrays on c0. Remember to designate a hot spare, to alternate the drives as you Add them to an array, to File->Set system Parameters. * The theory says that you could now shut your systems down, and install Unix on it. Not so fast: While the arrays are building, they are NOT available to you. Current firmware (7M0) will show the arrays to the O/S with size of zero or one sector. FreeBSD will crash (panic) in response to that. Leave the system alone until it is all done. Handling failures on arrays that are already built is totally different. See below. * If you follow my example, when you re-boot the system, BIOS, DOS, Windows, Linux, FreeBSD, they will only see FIVE disk drives. What happened to the other 79 drives?!!! Listen Carefully: Every RAID array appears to the O/S as ONE DISK DRIVE. Hot spares are TOTALLY INVISIBLE to the O/S Since we defined 5 RAID arrays and two hot spares (one per HBA. Hot Spares cannot cross HBA lines), all the system gets to see is FIVE DRIVES. If you look at the drive model, it will show the array Name you chose when setting up. The revision level for the ``drive'' is DPTxYz, where xYz is the firmware version. Currently, there is no way to get to the underlying drives in FreeBSD. Operation: Once the arrays completed building (the blue flags will be gone, and if you double click on the array icon, its Status files will say ``optimal''. Go Install whatever O/S, using whatever method you choose. Please beware that some versions of FreeBSD barf on disks with capacity of 20GB or larger. So it may barf on filesystems this huge. This seems to be an ``attribute'' of sysinstall, not the standard fdisk, disklabel, and newfs. you may choose to only install and configure the boot disk, as this one appears to the O/S as a simple, 4GB disk (if you used 4GB drives to define it). Failures: What does the DPT do in case of disk failure? First, the FreeBSD O/S, the DPT driver in the O/S, have no clue about the discussion below, except as explicitly indicated. General: If you use DPT shelves, a failed drive (unless it is totally dead) will turn its fault light on. The disk canister has a Fault light, that the DPT can turn on and off. In addition, the DPT controller will beep. The beeping pattern actually will tell you which disk on which bus has failed. If you use DPT (or DEC) shelves, simply pull out the bad drive and plug in a new drive. RAID-0: If any disk in a RAID-0 array fails, the whole array is flagged by the DPT as ``Dead''. Any I/O to the array will immediately fail. If you boot DOS/DPTMGR, the array will have black flag on it. Your only option is to delete the array, and create a new one. Any data on the array will be lost. horrible? Not necessarily. If you use RAID-0 arrays for data you can live without, you will be fine. With drives touting 800,000 hours MTBF, an 8 disks RAID-0 array will have MTBF of about 5 years. RAID-1/5: If a drive fails, the RAID array will go into degraded mode (Yellow flag in dptmgr). If you have a Hot Spare connected to the DPT, it will automatically make the hot spare a new member of the degraded array and start rebuilding the array onto the drive (that was the Hot Spare). If you replace the dead drive with a good one, the newly inserted drive will be recognized by the DPT and be made a new Hot Spare. The new hot Spare will not be available until the building array has completed its re-build. Important: The degraded array is available for I/O while in degraded or constructing mode. This has been verified more than once, and actually works. However: * RAID-5 in degraded mode is very slow. * Array rebuild in RAID-5 is done by reading all the good drives, computing the missing data, and writing it to the new/replacement drive. This is not exactly fast. It is downright SLOW. * RAID-1 arrays build by copying the entire good disk onto the replacement disk. This sucks all the bandwidth off the SCSI bus. * If there is another error while the arrays are in degraded/rebuild mode, you are hosed. there is not redundant data and you may lose your data. If possible and/or practical, do not WRITE to a degraded array. Back it up instead. Common Failure: I cannot overstate the commonality of this failure scenario: One uses cheap shelves (disk cabinets), cheap cables, marginal drives and the following happens: A certain drive hangs, or goes on the fritz, or the SCSI bus stalls. the DPT makes a valiant effort to reset the bus, but at least one drive is out cold. the DPT raises the alarm, and drafts a HotSpare into service. It then starts rebuilding the array. Since building the array is very I/O intensive, another drive goes on the fritz. Now the array is DEAD as far as the DPT is concerned. At this point the operator notices the problem, shuts the system down, reboots into the DPTMGR and comes out saying ``Nothing is WRONG!'' The operator sees red flags on the drives, if lucky, runs the DPT OPTIMAL.EXE utility (NOT available from me!), runs DOS based diagnostics, and start his/her news server again. Within minutes/hours/days, the whole scenario repeats. What happened? Under DOS (dptmgr is no exception), I/O is poled or sedately slow. Failures are rare and recovery almost certain. Under FreeBSD, a new server can peak at well over 1,000 disk I/Os per second. This is when marginal systems break. This is the most frustrating scenario for me; * The problem is NOT an O/S problem (FreeBSD simply pushes as much I/O into the driver as it can. It knows not a RAID array; The RAID array is simply a disk. * It is not a driver problem; the driver does not know a RAID array form a cucumber; It simply receives SCSI commands and passes them along. It never looks inside to even see what command is passing through. * the DPT firmware is not at fault either; It simply pushes commands to the drives according th the ANSI spec. So, who is at fault? Typically, the user who buys a $3,000.00 disk controller, attaching it to $20,000 worth of disk drives, using a $5.000 cable. In some cases, the user elects to buy the cheapest drive the can find, so as to reduce the $20,000 cost in disks to maybe $15,000. Some of these drives simply cannot do I/O correctly, or cannot do it correctly and quickly. Sometimes the problem is a combination of marginal interconnect and marginal drives. What to Do? If you have a mission critical data storage that you want to be reliable and fast: * Get a DPT controller * Get the ECC memory form DPT (Yes, bitch them out on the price, and say that Simon said the price is absurdly high). * Get the disk shelves from DPT (Or get DEC StorageWorks) * Get the DISKS from DPT. Make sure they supply you with the ECC ready disks). you will pay about $100.00/per drive extra, but will get the carrier for free, so the total cost is just about the same. * Get the cables from DPT, DEC, or Amphenol. * SCSI Cables are precision instruments. Keep the hammer away form them. * Use only the version of Firmware I recommend for the DPT. It is currently 7Li, not the newer 7M0. I have done the above, and on that day, my I/O errors disappeared. I run a total of over 60 disk drives on DPTs. Some in very stressed environments. Most in mission critical environments. Any failure we have to date is a direct result of violating these rules. What is the ECC option? The ECC option comprises of special ECC SIMMs for the DPT cache, proper cabling, and proper disk shelves (cabinets, enclosures). Using this option, the DPT guarantees that the data recorded to a device, or read from a device goes through a complete ECC data path. any small errors in the data are transparently corrected. Large errors are detected and alarmed. How does it work? * When data arrives from the host into the controller, it is put into the cache memory, and a 16 byte ECC is computed on every 512 byte ``sector''. * The disk drive is formatted to 528 bytes/sector, instead of the normal 512. Please note that not every disk can do that. sometimes it is simply a matter of having the proper firmware on the disk. sometimes the disk has to be different. * When the DPT writes the sector to disk, it writes the entire 528 bytes to disk. when it READs the sector, it reads the entire 528 bytes, performs the ECC check/correction, and puts the data in the cache memory. All disk drives have either CRC or ECC. What's the big deal? disk drives uses ECC (or some such) to make sure that what came into their possession was recored correctly on the disk, or that the recorded data is read correctly. The disk drive still has no clue if the data it receives from the initiator (HBA) is correct. When a disk sends data to the HBA, it does not know what arrives at the host. Yes, SCSI bus support parity. But parity cannot correct errors, and will totally miss even number of missing bits. Yes, that happens easily with bad cables. So, what is it good for? Aside from peace of mind, there is one important use for this: Hot Plug drives. Let me explain: The SCSI bus (ribbon cable genre, not FCAL) was never designed to sustain hot insertion. IF you add/remove device on the bus, you will invariably glitch it. These glitches will find themselves doing one of two things: a. Corrupt some handshake signal. this is typically easily detected by the devices and corrected via re-try. b. Corrupt some data which is in transfer. This is the more common case. If the corruption went undetected, something will go wrong much later and will typically be blamed on software. The ECC option goes hand in hand with the cabinet/disk-canister. The cabinet/canister combination makes sure that the minimal disruption appears on the bus by using special circuitry. the ECC option complements it by making sure that the entire data path, from the CPU to the disk and back is monitored for quality, and in most cases automatically repaired. What other wonders does a DPT controller perform? If you expect it to actually write code for you, sorry. It does not. But, if you use the correct enclosure, it will tell you about P/S failures, fan failures, overheating, and internal failures. A near-future release of the driver will even allow you to get these alarms into user space. You can then write a shell/perl/whatever script/program to take some action when a failure occurs in your disk system. What Performance can I expect out of a DPT system? It depends. Caching systems are slower in sequential access than individual disks. Things like Bonnie will not show what the DPT can really do. RAID-1 is slightly slower than a single disk in WRITE and can be slightly faster in READ operations. RAID-5 is considerably slower in WRITE and slightly faster in READ. RAID-0 is fast but very fragile. The main difference is in the disk subsystem reaction to increasing load and its handling of failures. A single disk is a single point of failure. A DPT, correctly configured will present ``perfect./non-stop'' disks to the O/S. In terms of load handling, the DPT controller has the lowest load per operation in a FreeBSD system. In terms of interrupts per operation, number of disks per PCI slot, size of file systems, number of CPU cycles per logical operation, and handling of heavy disk loads, it is probably the best option available to FreeBSD today. In terms of RAW I/O, doing random read/write to large disk partitions, these are the numbers: RAID-0: Approximately 1,930 disk operations per second. About 18-21 MB/Sec. RAID-1: About 6.5 MB/Sec WRITE, About 8-14 MB/Sec READ, the wide range stems form increasing cache hit ratio. RAID-5: About 5.5 MB/Sec write, 8.5 MB/.Sec READ. These are optimal numbers, derived from large arrays, and a PM3334UDW with 64MB of ECC cache. To achieve these numbers you have to have at least 500 processes reading and writing continuedly to random areas on the disk. This translates to Load Average of 150-980, depending on the array type, etc. >From daily use, I'dd say that until your disk I/O reached 300 I/O ops/sed, you will not feel the load at all. I home the above answers some of the most common questions about the DPT controller, and its interaction with FreeBSD. If you have some more, then let me know. Simon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 19 13:58:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA03788 for freebsd-scsi-outgoing; Fri, 19 Jun 1998 13:58:56 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from tor-dev1.nbc.netcom.ca (tor-dev1.nbc.netcom.ca [207.181.89.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA03758 for ; Fri, 19 Jun 1998 13:58:40 -0700 (PDT) (envelope-from dacole@netcom.ca) Received: from localhost (dacole@localhost) by tor-dev1.nbc.netcom.ca (8.8.8/8.8.8) with SMTP id QAA18891 for ; Fri, 19 Jun 1998 16:58:16 -0400 (EDT) X-Authentication-Warning: tor-dev1.nbc.netcom.ca: dacole owned process doing -bs Date: Fri, 19 Jun 1998 16:58:15 -0400 (EDT) From: Dave Cole X-Sender: dacole@tor-dev1.nbc.netcom.ca To: scsi@FreeBSD.ORG Subject: status of dump/st0/EIO/EOM/variable block sizes issue? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I was just doing a few '(ufs)dump's from both remote solaris machines and local freebsd volumes to compressing exabyte 2.5GB and 20GB drives, and in both cases, the dumps aborted with something along the theme of 'Input/Output error, restart dump? (yes/no)'. This is pretty spectacularily depressing. Even more depressing is when I can send the same jobs to a Solaris (2.6 at least) box and get a pleasing 'Insert next volume #1' prompt. I understand the issue with incomplete blocks lying about the EOM on variable block devices like compressing tape drives is somewhat troubling, but how is Solaris doing it so well? Though, in complete honesty, I've never had to try to restore from a multi-volume variable block sized dump done to a solaris hosted tape drive. *shrug* Is it as nightmarish as most other solaris issues? ---------------------------------------------------------------- Dave Cole (DC1110) | dacole@netcom.ca Systems Administrator |* dacole@rik.net * | office/~dacole/ Netcom Canada |* www.rik.net/~dacole/ * 905 King Street West, Toronto, M6K 3G9 | phone - 416.341.5801 Toronto, Ontario, Canada, Earth, Sol | fax - 416.341.5725 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 19 16:16:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA27946 for freebsd-scsi-outgoing; Fri, 19 Jun 1998 16:16:13 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA27936 for ; Fri, 19 Jun 1998 16:16:09 -0700 (PDT) (envelope-from darrylo@sr.hp.com) Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com (8.8.6/8.8.5tis) with ESMTP id QAA12699; Fri, 19 Jun 1998 16:15:58 -0700 (PDT) Received: from mina.sr.hp.com by srmail.sr.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA173348157; Fri, 19 Jun 1998 16:15:57 -0700 Received: from localhost (darrylo@mina.sr.hp.com [15.4.42.247]) by mina.sr.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.7.3 TIS 5.0) id QAA05817; Fri, 19 Jun 1998 16:15:56 -0700 (PDT) Message-Id: <199806192315.QAA05817@mina.sr.hp.com> To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? Reply-To: darrylo@sr.hp.com In-Reply-To: Your message of "Fri, 19 Jun 1998 11:30:01 PDT." <199806191730.LAA12458@panzer.plutotech.com> Mime-Version: 1.0 (generated by tm-edit 1.1.1.1) Content-Type: text/plain; charset=US-ASCII Date: Fri, 19 Jun 1998 16:15:56 -0700 From: Darryl Okahata Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Kenneth D. Merry" wrote: > - How many more programs use this (scsireq) interface? Does /sbin/scsi work (or has it been ported)? If so, great. I've got some perl scripts that fdisk/disklabel/newfs arbitrary disks, and they rely upon scsi(8). -- Darryl Okahata Internet: darrylo@sr.hp.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Hewlett-Packard, or of the little green men that have been following him all day. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 19 17:47:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA11333 for freebsd-scsi-outgoing; Fri, 19 Jun 1998 17:47:58 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from tempest.nac.net (tempest.nac.net [209.123.20.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA11314 for ; Fri, 19 Jun 1998 17:47:56 -0700 (PDT) (envelope-from alex@nac.net) From: alex@nac.net Received: (qmail 21464 invoked from network); 19 Jun 1998 20:42:29 -0400 Received: from iago.nac.net (alex@209.123.20.5) by tempest.nac.net with SMTP; 19 Jun 1998 20:42:29 -0400 Date: Fri, 19 Jun 1998 20:47:40 -0400 (EDT) To: Simon Shapiro cc: Chris Parry , freebsd-questions@FreeBSD.ORG, freebsd-SCSI@FreeBSD.ORG Subject: RE: DPT support binaries - How to Setup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Just some notes... > The DPT controller creates and manages RAID array in a manner totally > transparent to the (ANY) operating system. Say, you have 45 disk drives, ANY operating system that has a drive for the SCSI card. Like, remember the FreeBSD didn't have a driver for it until recently. > 1 RAID-0 array to be used for swap, /tmp, /var/tmp, /usr/obj, etc. > RAID-0 is very fast, but if any disk in the array fails, the whole > array will lose its data. For the indicated use, this is acceptable > to us (Remember, this is just an example). > We do not need an awful lot of space, but we need the speed of at > least 15MB/Sec, so we will use 6 drives here. Is this bright? Couldn't this panic the system in an event of a failure? > 1 Huge RAID-0 array to contain news articles. Again, we do not care if > we loose the article. This array needs to be big and as fast as > possible. We will use 33 disk drives here. Also, I think this is a bad idea; at least make three 11-drive arrays (RAID-0 is ok, but this way if you lose *1* disk, you don't lose the ENTIRE spool, only a third -- and, you lose no storage space). With news servers like breeze, this is very easy. > 1 Huge RAID-5 array to contain our E-mail. We need reliability and > capacity, so we will use 33 drives here. In reality, RAID-5 arrays > are not so effective at this size, but this is just an exadurated > example. You are putting news and mail on the same machine? > What does the DPT do in case of disk failure? Usually kernel panic on bootup, but thats irrelevant. > Typically, the user who buys a $3,000.00 disk controller, attaching it to The most expensive 3334/UDW is like $1800. > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex@nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP! We have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 19 18:01:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA13345 for freebsd-scsi-outgoing; Fri, 19 Jun 1998 18:01:52 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA13325; Fri, 19 Jun 1998 18:01:49 -0700 (PDT) (envelope-from laotzu@juniper.net) Received: from leaf.juniper.net (leaf.juniper.net [208.197.169.211]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id SAA18949; Fri, 19 Jun 1998 18:01:20 -0700 (PDT) Received: from localhost (laotzu@localhost) by leaf.juniper.net (8.8.8/8.7.3) with SMTP id SAA07789; Fri, 19 Jun 1998 18:01:20 -0700 (PDT) Date: Fri, 19 Jun 1998 18:01:20 -0700 (PDT) From: Chris Parry To: alex@nac.net cc: Simon Shapiro , freebsd-questions@FreeBSD.ORG, freebsd-SCSI@FreeBSD.ORG Subject: RE: DPT support binaries - How to Setup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alex, thanks for the notes, I have my own opinions there, but they aren't really relavent for this. My assumption is I need to have a DOS bootable partition somewhere with the storage management software on it (or perhaps I could get away with doing it from floppy), then setup my RAID-1 device, which will then simply appear as /dev/sd0 from the FreeBSD side of things. Is this correct? Thanks for the help, -chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Jun 19 18:47:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19864 for freebsd-scsi-outgoing; Fri, 19 Jun 1998 18:47:14 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19858 for ; Fri, 19 Jun 1998 18:47:12 -0700 (PDT) (envelope-from dan@math.berkeley.edu) Received: (from dan@localhost) by math.berkeley.edu (8.8.7/8.8.7) id SAA01444; Fri, 19 Jun 1998 18:47:10 -0700 (PDT) Date: Fri, 19 Jun 1998 18:47:10 -0700 (PDT) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199806200147.SAA01444@math.berkeley.edu> To: ken@plutotech.com Subject: Re: Rolling CAM in, what is still needed? Cc: dan@math.berkeley.edu, freebsd-scsi@FreeBSD.ORG Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Right, that's what I'm interested in. I talked to Julian this > morning (in person, actually!) and that's the question I had. So I'll say > it so everyone can see: > > - How many more programs use this (scsireq) interface? I recently ported a rather useful general scsi device utility program to FreeBSD. It slices, dices, and knows a great deal about mode parameter pages. > - Are people going to yell and scream loudly if it goes away when CAM > is integrated into the tree?? Not if we have a reasonable alternative. It would be nice if both interfaces worked side-by-side for a while to facilitate migration. It would also be nice if the new scsi passthrough ioctl() was documented. I had a little difficulty with SCIOCCOMMAND. > - the problem is that with the old SCSI code, to send SCSI commands > directly to a device, you opened the device itself (/dev/rcd0a or > whatever) and did the SCIOCCOMMAND ioctl on that device. CAM does > things differently, primarily because users may want to send > commands to device, even though the device's open() routine may > fail. For instance, you can't open a CD device if there is no > media inserted. But the user may want to send an INQUIRY command > to the drive, whether or not there's a CD in the drive. So, to > solve this, you have two choices: (that I can think of offhand) > - have a special control minor number for each device, and > have the open call ignore failures in read capacity, test > unit ready, etc. > - have a separate passthrough driver that doesn't have to > have any commands succeed to attach or open. A special control device is important if the regular device is exclusive-open or touching it may affect the status of the device (example: tape) but I don't think a control device should be used to solve the open-failure problem. A second approach might be to add a special open() flag to the fcntl.h repertoire. Sun uses O_NDELAY for this purpose. I don't much like this either. It seems like an unnecessary complication to me. I think the open-failure problem is best solved by not creating it in the first place. This is a totally artificial problem. Let the drivers allow the open() even if the device it not ready. The system calls that should fail if the device is not ready are read() and write(). Why should open() fail? What existing application programs are broken by this approach? We might define a special file for the controller itself. It could be used for non-device-specific operations (e.g. bus or controller reset) or truly general SCSI passthrough (you specify the bus-id and the lun). (As mentioned above, tape may be a special case. Tape drivers might make read/write operations wait when there is tape motion such as rewind or load in progress. A special control device might be useful to allow status requests and such when the drive is already busy.) Dan Strick dan@math.berkeley.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 20 09:17:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA05116 for freebsd-scsi-outgoing; Sat, 20 Jun 1998 09:17:04 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from base486.home.org (imdave@imdave.pr.mcs.net [205.164.3.77]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA05108 for ; Sat, 20 Jun 1998 09:17:01 -0700 (PDT) (envelope-from imdave@mcs.net) Received: (from imdave@localhost) by base486.home.org (8.8.8/8.8.8) id LAA10605; Sat, 20 Jun 1998 11:15:20 -0500 (CDT) Date: Sat, 20 Jun 1998 11:15:20 -0500 (CDT) From: Dave Bodenstab Message-Id: <199806201615.LAA10605@base486.home.org> To: freebsd-scsi@FreeBSD.ORG Subject: Re: Micropolis 4345WS (Toshiba "Equium" 6200M) Cc: darrylo@sr.hp.com, mike@smith.net.au, skynyrd@opus.cts.cwu.edu Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org For the benefit of anyone else with the Toshiba Equium 6200M and/or the Micropolis 4345WS drives... I could not install FreeBSD with the original firmware revision of the Micropolis drives (zC19) -- I got ``SCB timeout'' etc. Thanks to Chris Timmons who sent me the X502_4.exe (which updates the firmware to X502), the drives are now working. I installed the 5/20 SMP snapshot without a hitch. Folks had previously mentioned: http://www.addit.de/SUPPORT/micr-eproms.htm as a source for Micropolis FW upgrades, but the site was apparently down for 2-3 weeks. I just checked today, and the site is back up. It lists X504_4.exe as the current fw for the 4345xx drives (but the comment still says X502 and the link is still to ``X502_4.exe''.) Probably the ``X504'' is a typo. So... the site is back up and the fw upgrade is available for anyone who needs it. Dave Bodenstab imdave@mcs.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 20 10:14:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA11790 for freebsd-scsi-outgoing; Sat, 20 Jun 1998 10:14:17 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA11763; Sat, 20 Jun 1998 10:14:09 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0ynQhc-0006vY-00; Sat, 20 Jun 1998 09:41:20 -0700 Date: Sat, 20 Jun 1998 09:41:18 -0700 (PDT) From: Tom To: alex@nac.net cc: Simon Shapiro , Chris Parry , freebsd-questions@FreeBSD.ORG, freebsd-SCSI@FreeBSD.ORG Subject: RE: DPT support binaries - How to Setup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 19 Jun 1998 alex@nac.net wrote: > > What does the DPT do in case of disk failure? > > Usually kernel panic on bootup, but thats irrelevant. Of course, thats just you. I don't see this at all, and I've tried the fail/rebuild procedure many times. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 20 16:16:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA23420 for freebsd-scsi-outgoing; Sat, 20 Jun 1998 16:16:26 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nomis.simon-shapiro.org ([209.86.126.163]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA23385 for ; Sat, 20 Jun 1998 16:16:17 -0700 (PDT) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 15140 invoked by uid 1000); 20 Jun 1998 23:16:58 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 20 Jun 1998 19:16:57 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: alex@nac.net Subject: RE: DPT support binaries - How to Setup Cc: freebsd-SCSI@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, Chris Parry Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 20-Jun-98 alex@nac.net wrote: > > > Just some notes... > > >> The DPT controller creates and manages RAID array in a manner totally >> transparent to the (ANY) operating system. Say, you have 45 disk >> drives, > > ANY operating system that has a drive for the SCSI card. Like, remember > the FreeBSD didn't have a driver for it until recently. Recently as in last 18 months :-) The point is that if you install Doze, NiceTry, Unixware, SCSO, whatever, the RAID array is the very same, compatible, interoprable, and just simply there, regardless of the O/S. >> 1 RAID-0 array to be used for swap, /tmp, /var/tmp, /usr/obj, etc. >> RAID-0 is very fast, but if any disk in the array fails, the >> whole >> array will lose its data. For the indicated use, this is >> acceptable >> to us (Remember, this is just an example). >> We do not need an awful lot of space, but we need the speed of at >> least 15MB/Sec, so we will use 6 drives here. > > Is this bright? Couldn't this panic the system in an event of a failure? No. It should not. I use most my on-line systems this way for many years. In any case, a fatal disk failure will crash your Unix system. There really is no real increased exposure here. Besides, this was an example. In reality one must choose the engineering solution desired based on acceptable risks and compromise between benefits/costs/risks. My point is that the DPT technology (and other, comparable technologies) give you the choice, Speed, performance, safety, capacity, etc. >> 1 Huge RAID-0 array to contain news articles. Again, we do not >> care if >> we loose the article. This array needs to be big and as fast as >> possible. We will use 33 disk drives here. > > Also, I think this is a bad idea; at least make three 11-drive arrays > (RAID-0 is ok, but this way if you lose *1* disk, you don't lose the > ENTIRE spool, only a third -- and, you lose no storage space). With news > servers like breeze, this is very easy. You have missed my point :-) This is an absurd example, set out to demonstrate that it is practical and operational, and that the O/S does not see disks, but RAID arrays, and that 84 disks appear as five, with the O/S having no clue what happened. Besides, for performance this arrangement is mostly silly anyway. >> 1 Huge RAID-5 array to contain our E-mail. We need reliability and >> capacity, so we will use 33 drives here. In reality, RAID-5 >> arrays >> are not so effective at this size, but this is just an exadurated >> example. > > You are putting news and mail on the same machine? Sure, why not? I also put a FreeBSD mirror and a build environment to cut CDs from. Remember, this is a SILLY ands ABSURD example. >> What does the DPT do in case of disk failure? > > Usually kernel panic on bootup, but thats irrelevant. Absolutely not true. The DPT card has nothing to do with the panics you quote. Go read the code, and trace the panics. I have. There is only one, identifyable combination of failures, which involves the USER doing something against the clear instructions, that can cause the kernel to panic in case of a RAID failure. In this context, we might as well all pack and go home: You can always do something destruvtive and then complain. When in the army, we did not feel sorry for those who shot themselves in the foot. We tended medical services, but a purply heart you do not get for doing something wrong, or careless. >> Typically, the user who buys a $3,000.00 disk controller, attaching it >> to > > The most expensive 3334/UDW is like $1800. True. But with 64MB of ECC RAM, differential option, etc, it can retail for more than $3,000. Besides, I think you see my point. Simon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 20 16:19:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA23918 for freebsd-scsi-outgoing; Sat, 20 Jun 1998 16:19:14 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from nomis.simon-shapiro.org ([209.86.126.163]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA23909 for ; Sat, 20 Jun 1998 16:19:11 -0700 (PDT) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 15171 invoked by uid 1000); 20 Jun 1998 23:19:53 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sat, 20 Jun 1998 19:19:53 -0400 (EDT) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Chris Parry Subject: RE: DPT support binaries - How to Setup Cc: freebsd-SCSI@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, alex@nac.net Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 20-Jun-98 Chris Parry wrote: > > Alex, thanks for the notes, I have my own opinions there, but they aren't > really relavent for this. My assumption is I need to have a DOS bootable > partition somewhere with the storage management software on it (or > perhaps > I could get away with doing it from floppy), then setup my RAID-1 device, > which will then simply appear as /dev/sd0 from the FreeBSD side of > things. > > Is this correct? Yup. I typically have slice (DOS partition) 1 as a small (64MB or less) DOS partition. I have customers who do not want to pay the DOS royalties, nor do they want to violate federal copyright laws by installing DOS on a disk, when it will practically never be used. These people choose to do the work from floppy. I use IBM PC-DOS, so as to minimize the payment to M$. Simon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 20 20:06:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA20640 for freebsd-scsi-outgoing; Sat, 20 Jun 1998 20:06:20 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA20634 for ; Sat, 20 Jun 1998 20:06:15 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id VAA20485; Sat, 20 Jun 1998 21:05:37 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806210305.VAA20485@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806191742.OAA02683@roma.coe.ufrj.br> from Joao Carlos Mendes Luis at "Jun 19, 98 02:42:45 pm" To: jonny@jonny.eng.br (Joao Carlos Mendes Luis) Date: Sat, 20 Jun 1998 21:05:37 -0600 (MDT) Cc: ken@plutotech.com, mjacob@feral.com, julian@whistle.com, jonny@jonny.eng.br, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Joao Carlos Mendes Luis wrote... > #define quoting(Kenneth D. Merry) > // - the problem is that with the old SCSI code, to send SCSI commands > // directly to a device, you opened the device itself (/dev/rcd0a or > // whatever) and did the SCIOCCOMMAND ioctl on that device. CAM does > // things differently, primarily because users may want to send > // commands to device, even though the device's open() routine may > // fail. For instance, you can't open a CD device if there is no > // media inserted. But the user may want to send an INQUIRY command > // to the drive, whether or not there's a CD in the drive. So, to > // solve this, you have two choices: (that I can think of offhand) > // - have a special control minor number for each device, and > // have the open call ignore failures in read capacity, test > // unit ready, etc. > // - have a separate passthrough driver that doesn't have to > // have any commands succeed to attach or open. > > Isn't this what /dev/xxx.ctl does ? My guess is that that is what it was supposed to do in theory, but in practice, I don't think it does. I looked at the open routines in the current cd, sd and st drivers, and none of them check to see if it was the control device that was opened. So if no media is in the drive, the open will fail. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 20 20:09:06 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA20937 for freebsd-scsi-outgoing; Sat, 20 Jun 1998 20:09:06 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA20912 for ; Sat, 20 Jun 1998 20:09:03 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id VAA20507; Sat, 20 Jun 1998 21:07:42 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806210307.VAA20507@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806192315.QAA05817@mina.sr.hp.com> from Darryl Okahata at "Jun 19, 98 04:15:56 pm" To: darrylo@sr.hp.com Date: Sat, 20 Jun 1998 21:07:42 -0600 (MDT) Cc: ken@plutotech.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Darryl Okahata wrote... > "Kenneth D. Merry" wrote: > > > - How many more programs use this (scsireq) interface? > > Does /sbin/scsi work (or has it been ported)? If so, great. I've > got some perl scripts that fdisk/disklabel/newfs arbitrary disks, and > they rely upon scsi(8). Well, scsi(8) has not been ported, it has been replaced by camcontrol. camcontrol should be able to do everything that scsi(8) did, and more. The version of camcontrol in the current snapshot (May 20th) doesn't have mode page or arbitrary cdb support, but the version in the next snapshot will. The code is already done, and there's just one more bug I need to work out. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 20 20:19:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA22007 for freebsd-scsi-outgoing; Sat, 20 Jun 1998 20:19:53 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from panzer.plutotech.com (ken@panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA22000 for ; Sat, 20 Jun 1998 20:19:49 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.8.8/8.8.5) id VAA20588; Sat, 20 Jun 1998 21:19:39 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199806210319.VAA20588@panzer.plutotech.com> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806200147.SAA01444@math.berkeley.edu> from Dan Strick at "Jun 19, 98 06:47:10 pm" To: dan@math.berkeley.edu (Dan Strick) Date: Sat, 20 Jun 1998 21:19:38 -0600 (MDT) Cc: ken@plutotech.com, dan@math.berkeley.edu, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dan Strick wrote... > > Right, that's what I'm interested in. I talked to Julian this > > morning (in person, actually!) and that's the question I had. So I'll say > > it so everyone can see: > > > > - How many more programs use this (scsireq) interface? > > I recently ported a rather useful general scsi device utility program to > FreeBSD. It slices, dices, and knows a great deal about mode parameter > pages. What's the name of the program? Is there a URL? I'd like to have a look at it, see what it does and see how difficult it would be to port it. Does it do things that camcontrol doesn't? > > - Are people going to yell and scream loudly if it goes away when CAM > > is integrated into the tree?? > > Not if we have a reasonable alternative. It would be nice if both > interfaces worked side-by-side for a while to facilitate migration. > It would also be nice if the new scsi passthrough ioctl() was documented. > I had a little difficulty with SCIOCCOMMAND. I certainly agree that the current interface needs to be documented. I think the current libcam is a good alternative to the old libscsi library. You should be able to do all of the same things, including using the old command string format to do cdbs. (that's with the latest version of the library, which isn't "out" in a snapshot yet) Before I (or someone else) go hacking through things to add in support for the old passthrough interface, I really would like to know the scope of the porting problem. You're the first person (other than Julian and Poul-Henning, who said something vague about some internal program at TFS) that's mentioned any program other than the ones I know about that needs to be ported. We can provide backwards compatibility, but if it goes away in say FreeBSD 3.1 or 4.0, people may still scream, since they never noticed that the interface was "deprecated." > > - the problem is that with the old SCSI code, to send SCSI commands > > directly to a device, you opened the device itself (/dev/rcd0a or > > whatever) and did the SCIOCCOMMAND ioctl on that device. CAM does > > things differently, primarily because users may want to send > > commands to device, even though the device's open() routine may > > fail. For instance, you can't open a CD device if there is no > > media inserted. But the user may want to send an INQUIRY command > > to the drive, whether or not there's a CD in the drive. So, to > > solve this, you have two choices: (that I can think of offhand) > > - have a special control minor number for each device, and > > have the open call ignore failures in read capacity, test > > unit ready, etc. > > - have a separate passthrough driver that doesn't have to > > have any commands succeed to attach or open. > > A special control device is important if the regular device is > exclusive-open or touching it may affect the status of the device > (example: tape) but I don't think a control device should be used > to solve the open-failure problem. Right. > A second approach might be to add a special open() flag to the fcntl.h > repertoire. Sun uses O_NDELAY for this purpose. I don't much like > this either. It seems like an unnecessary complication to me. You might as well open the control device, the code would be similar. > I think the open-failure problem is best solved by not creating it in the > first place. This is a totally artificial problem. Let the drivers allow > the open() even if the device it not ready. The system calls that should > fail if the device is not ready are read() and write(). Why should > open() fail? What existing application programs are broken by this > approach? I'm not sure what applications would be broken. The current passthrough driver approach fixes the open() problem already. It doesn't depend on the device returning *any* commands successfully to complete. That was a major reason for doing a separate passthrough driver with different open() requirements than the "normal" peripheral drivers. > We might define a special file for the controller itself. > It could be used for non-device-specific operations (e.g. bus or controller > reset) or truly general SCSI passthrough (you specify the bus-id and the lun). Well, actually, we have something like that already in CAM. There's the transport layer device (/dev/[r]xpt[n]). That's how you send bus rescans, and a few other commands. It also provides mapping from device type / unit number to the correct passthrough driver. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Jun 20 22:04:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA03830 for freebsd-scsi-outgoing; Sat, 20 Jun 1998 22:04:37 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from tempest.nac.net (tempest.nac.net [209.123.20.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA03810 for ; Sat, 20 Jun 1998 22:04:33 -0700 (PDT) (envelope-from alex@nac.net) From: alex@nac.net Received: (qmail 28312 invoked from network); 21 Jun 1998 01:03:05 -0400 Received: from iago.nac.net (alex@209.123.20.5) by tempest.nac.net with SMTP; 21 Jun 1998 01:03:05 -0400 Date: Sun, 21 Jun 1998 01:04:13 -0400 (EDT) To: Tom cc: Simon Shapiro , Chris Parry , freebsd-questions@FreeBSD.ORG, freebsd-SCSI@FreeBSD.ORG Subject: RE: DPT support binaries - How to Setup In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Search the archives; there are about 10 instances of this in the past 2 months. It is when the array is in degraded mode, and you try to boot. > > > What does the DPT do in case of disk failure? > > > > Usually kernel panic on bootup, but thats irrelevant. > > Of course, thats just you. I don't see this at all, and I've tried > the fail/rebuild procedure many times. > > Tom > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex@nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP! We have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message