From owner-freebsd-scsi Sun Jul 14 00:43:12 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA28180 for freebsd-scsi-outgoing; Sun, 14 Jul 1996 00:43:12 -0700 (PDT) Received: from ref.tfs.com ([206.245.251.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA28172 for ; Sun, 14 Jul 1996 00:43:09 -0700 (PDT) Received: (from julian@localhost) by ref.tfs.com (8.7.5/8.7.3) id AAA13984; Sun, 14 Jul 1996 00:41:19 -0700 (PDT) Message-Id: <199607140741.AAA13984@ref.tfs.com> Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 To: jbh@labyrinth.net.au (John Hartley) Date: Sun, 14 Jul 1996 00:41:18 -0700 (PDT) From: "JULIAN Elischer" Cc: freebsd-scsi@freebsd.org In-Reply-To: <199607140517.PAA17083@minotaur.labyrinth.net.au> from "John Hartley" at Jul 14, 96 03:17:33 pm X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > > > J"org > I added the "rouge" code as suggested and .... er that's rogue.. as in villain, and the list of known villains is the gallery. struct rogue gallery[]; sort of a joke you understand.. > The tape returns... > /kernel: st0(ahc0:2:0): command: 1a,0,0,0,18,0-[24 bytes] > /kernel: ------------------------------ > /kernel: 000: 2f 25 10 08 15 00 00 00 00 00 02 00 90 0e 00 00 > /kernel: 016: 14 14 00 00 e0 00 38 00 > /kernel: ------------------------------ and then the driver sets... > /kernel: st0(ahc0:2:0): command: 15,0,0,0,18,0-[24 bytes] > /kernel: ------------------------------ > /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 90 0e 00 00 > /kernel: 016: 14 14 00 00 e0 00 38 00 > /kernel: ------------------------------ my guess from memory is that the first two bytes different are ok, but what is the change from 02 to 04? scsi/scsi_tape.h should hold the answer to THAT question.. > > Thanks again, I am going to get a copy of the SCSI specs so that I might > be of more use in diagnosing the problem. used to be on ftp.ncr.com but were moved.. they did leave a pointer however.. > Regards. > > John Hartley jbh@labyrinth.net.au > Graphica Software Pty. Ltd. > > From owner-freebsd-scsi Sun Jul 14 01:22:25 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA03285 for freebsd-scsi-outgoing; Sun, 14 Jul 1996 01:22:25 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA03268; Sun, 14 Jul 1996 01:22:16 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA23594; Sun, 14 Jul 1996 10:22:07 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA20631; Sun, 14 Jul 1996 10:22:06 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id KAA15641; Sun, 14 Jul 1996 10:04:15 +0200 (MET DST) From: J Wunsch Message-Id: <199607140804.KAA15641@uriah.heep.sax.de> Subject: Re: Jaz drive questions To: freebsd-scsi@freebsd.org Date: Sun, 14 Jul 1996 10:04:15 +0200 (MET DST) Cc: Stephen.Couchman@imagenet.on.ca, freebsd-questions@freebsd.org, n_melhor@Telebit.COM Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607132245.IAA03964@godzilla.zeta.org.au> from Bruce Evans at "Jul 14, 96 08:45:47 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Bruce Evans wrote: > > sd1(ahc0:2:0): ILLEGAL REQUEST asc:24,0 Invalid field in > > CDB sd1 could not mode sense (4). Using ficticious > > geometry 1021MB (2091050 512 byte sectors) > > This means that FreeBSD _did_ recognize the drive. Iomega apparently > didn't bother to implement the SCSI mode sense command, so the driver > can't determine anything about the number of heads or sectors/track > on the disk (if any). That's not true. Of course, they did implement a MODE SENSE command (it's optional per the SCSI specs, but certainly implemented in any disk drive). It's possible that they didn't implement mode page 4 ("Rigid disk drive geometry page"), or that FreeBSD has some other incorrect setting when performing the MODE SENSE. You will only be sure after turning on debugging, and comparing step by step with IOmega's SCSI specs. The claimed number of sectors looks highly suspicious: it's IMHO 10 x too large. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sun Jul 14 03:04:34 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA18723 for freebsd-scsi-outgoing; Sun, 14 Jul 1996 03:04:34 -0700 (PDT) Received: from ref.tfs.com ([206.245.251.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA18692; Sun, 14 Jul 1996 03:04:28 -0700 (PDT) Received: (from julian@localhost) by ref.tfs.com (8.7.5/8.7.3) id DAA14806; Sun, 14 Jul 1996 03:04:02 -0700 (PDT) Message-Id: <199607141004.DAA14806@ref.tfs.com> Subject: Re: Jaz drive questions To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 14 Jul 1996 03:04:02 -0700 (PDT) From: "JULIAN Elischer" Cc: freebsd-scsi@freebsd.org, Stephen.Couchman@imagenet.on.ca, freebsd-questions@freebsd.org, n_melhor@Telebit.COM In-Reply-To: <199607140804.KAA15641@uriah.heep.sax.de> from "J Wunsch" at Jul 14, 96 10:04:15 am X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > As Bruce Evans wrote: > > > > sd1(ahc0:2:0): ILLEGAL REQUEST asc:24,0 Invalid field in > > > CDB sd1 could not mode sense (4). Using ficticious > > > geometry 1021MB (2091050 512 byte sectors) > > > > This means that FreeBSD _did_ recognize the drive. Iomega apparently > > didn't bother to implement the SCSI mode sense command, so the driver > > can't determine anything about the number of heads or sectors/track > > on the disk (if any). > > That's not true. Of course, they did implement a MODE SENSE command > (it's optional per the SCSI specs, but certainly implemented in any > disk drive). It's possible that they didn't implement mode page 4 > ("Rigid disk drive geometry page"), or that FreeBSD has some other > incorrect setting when performing the MODE SENSE. You will only be > sure after turning on debugging, and comparing step by step with > IOmega's SCSI specs. the geometry is in fact unimportant.. the ficticious one should work just fine.. > > The claimed number of sectors looks highly suspicious: it's IMHO > 10 x too large. > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) > From owner-freebsd-scsi Sun Jul 14 03:47:47 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA27690 for freebsd-scsi-outgoing; Sun, 14 Jul 1996 03:47:47 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA27679 for ; Sun, 14 Jul 1996 03:47:41 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id MAA26029; Sun, 14 Jul 1996 12:45:10 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id MAA22072; Sun, 14 Jul 1996 12:45:05 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id MAA00518; Sun, 14 Jul 1996 12:40:37 +0200 (MET DST) From: J Wunsch Message-Id: <199607141040.MAA00518@uriah.heep.sax.de> Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 To: freebsd-scsi@freebsd.org Date: Sun, 14 Jul 1996 12:40:37 +0200 (MET DST) Cc: jbh@labyrinth.net.au (John Hartley) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607140517.PAA17083@minotaur.labyrinth.net.au> from John Hartley at "Jul 14, 96 03:17:33 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As John Hartley wrote: > >+ {"Tandberg tdc4100", "TANDBERG", " TDC 4100", "????", > >+ ST_Q_NEEDS_PAGE_0|ST_Q_SNS_HLP, ^^^^^^^^^^^^^^^^^^ Take this out again. :) It hurts when i do so... We are now violating the specs by setting the PS bit in a MODE SELECT command: ``When using the MODE SENSE command, a parameters savable (PS) bit of one indicates that the mode page can be saved by the target in a non-volatile, vendor-specific location. A PS bit of zero indicates that the supported parameters cannot be saved. When using the MODE SELECT command, the PS bit is reserved.'' > Jul 14 14:51:19 qwiff /kernel: st0(ahc0:2:0): command: 1a,0,0,0,18,0-[24 bytes] > Jul 14 14:51:19 qwiff /kernel: ------------------------------ > Jul 14 14:51:19 qwiff /kernel: 000: 2f 25 10 08 15 00 00 00 00 00 02 00 90 ^^ That's better than what it used to be before! It now properly reports density 0x15 on the first attempt. > Jul 14 14:51:20 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,18,0-[24 bytes] > Jul 14 14:51:20 qwiff /kernel: ------------------------------ > Jul 14 14:51:20 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 90 ^^ But my advise was partially botched. The code still tries to select density 0 in your drive, but now without doing the block mode decision inside the driver (so it apparently takes it from the rogue table). I wonder why this happened. When comparing with the SCSIDEBUG output from my TDC4222, it looks like this device requires a valid density and doesn't grok density 0 (which means ``default density'' -- one would assume it should always accept this). I wonder whether we should always use the following kludge: Index: sys/scsi/st.c =================================================================== RCS file: /home/ncvs/src/sys/scsi/st.c,v retrieving revision 1.36.4.1 diff -u -u -r1.36.4.1 st.c --- st.c 1995/07/22 04:25:10 1.36.4.1 +++ st.c 1996/07/14 10:25:07 @@ -1530,7 +1530,9 @@ scsi_cmd.length = dat_len; dat.header.blk_desc_len = sizeof(struct blk_desc); dat.header.dev_spec |= SMH_DSP_BUFF_MODE_ON; - dat.blk_desc.density = st->density; + dat.blk_desc.density = + st->density? st->density: + 0x7f /* use previous density */; if (st->flags & ST_FIXEDBLOCKS) { scsi_uto3b(st->blksiz, dat.blk_desc.blklen); } It forces the density set to the ``use previous density'' value per the SCSI specs in case the current value is 0. (If i read the specs correctly, the latter is a ``Can't happen'' condition since a tape device is not supposed to ever return density 0. The Tandberg does, however.) Could you try both? First, remove the bogus ST_Q_NEEDS_PAGE_0. If this works, try disabling the quirk record entirely, and see whether the above patch would also solve the problem. If the latter works for you, i think it is safe to commit it as a general failsafe option. Here's the quirk record patch again in a slightly different version: Index: sys/scsi/st.c =================================================================== RCS file: /home/ncvs/src/sys/scsi/st.c,v retrieving revision 1.36.4.1 diff -u -u -r1.36.4.1 st.c --- st.c 1995/07/22 04:25:10 1.36.4.1 +++ st.c 1996/07/14 10:36:50 @@ -113,6 +113,15 @@ {0, 0, QIC_120} /* minor 12,13,14,15 */ } }, + {"Tandberg tdc4100", "TANDBERG", " TDC 4100", "????", + ST_Q_NEEDS_PAGE_0|ST_Q_SNS_HLP, + { + {0, 0, 0}, /* minor 0,1,2,3 */ + {0, ST_Q_FORCE_VAR_MODE, QIC_525}, /* minor 4,5,6,7 */ + {0, ST_Q_FORCE_VAR_MODE, 0x15}, /* minor 8,9,10,11 */ + {512, ST_Q_FORCE_FIXED_MODE, QIC_150} /* minor 12,13,14,15 */ + } + }, {"Rev 5 of the Archive 2525", "ARCHIVE ", "VIPER 2525 25462", "-005", 0, { It's now supposed to force subdevice 1 (/dev/rst0.1) into QIC-525 variable length, subdevice 2 into QIC-1GB variable length, and subdevice 3 into QIC-150 512-byte records. Failing any form of usable autodetection (subdevice 0), this is supposed to supply safe defaults. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sun Jul 14 04:22:48 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA07826 for freebsd-scsi-outgoing; Sun, 14 Jul 1996 04:22:48 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA07787 for ; Sun, 14 Jul 1996 04:22:42 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id NAA26695; Sun, 14 Jul 1996 13:20:45 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA22251; Sun, 14 Jul 1996 13:20:44 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id MAA00412; Sun, 14 Jul 1996 12:52:37 +0200 (MET DST) From: J Wunsch Message-Id: <199607141052.MAA00412@uriah.heep.sax.de> Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 To: freebsd-scsi@freebsd.org Date: Sun, 14 Jul 1996 12:52:37 +0200 (MET DST) Cc: jbh@labyrinth.net.au Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607140741.AAA13984@ref.tfs.com> from JULIAN Elischer at "Jul 14, 96 00:41:18 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As JULIAN Elischer wrote: > The tape returns... > > /kernel: 000: 2f 25 10 08 15 00 00 00 00 00 02 00 90 0e 00 00 > and then the driver sets... > > /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 90 0e 00 00 > my guess from memory is that the first two bytes different are ok, > but what is the change from 02 to 04? It's bumping the blocksize from 512 bytes to 1024. Both is bogus, since the cartridge is a 1 Gig which is variable-length. The change from 0x15 to 0x00 is also bogus. See my other reply. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sun Jul 14 07:45:01 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA22588 for freebsd-scsi-outgoing; Sun, 14 Jul 1996 07:45:01 -0700 (PDT) Received: from ref.tfs.com ([206.245.251.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA22567; Sun, 14 Jul 1996 07:44:58 -0700 (PDT) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by ref.tfs.com (8.7.5/8.7.3) with SMTP id HAA15997; Sun, 14 Jul 1996 07:36:04 -0700 (PDT) Received: from allegro.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0ufS8d-000Qc7C; Sun, 14 Jul 96 16:27 MET DST From: grog@lemis.de (Greg Lehey) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Received: (grog@localhost) by allegro.lemis.de (8.6.9/8.6.9) id QAA22112; Sun, 14 Jul 1996 16:23:13 +0200 Message-Id: <199607141423.QAA22112@allegro.lemis.de> Subject: Re: 8 * 0xFF bytes at intermittent multiples of 0x1000 To: jhs@freebsd.org Date: Sun, 14 Jul 1996 16:23:13 +0200 (MET DST) Cc: scsi@freebsd.org In-Reply-To: <199606121518.RAA06093@vector.jhs.no_domain> from "Julian H. Stacey" at Jun 12, 96 05:18:52 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In early June 1996, Julian H. Stacey wrote: > > To scsi@freebsd.org > Cc Adaptec 1542A SCSI Adapter People, Julian Elischer. > > [ I last posted to +1542A owners + bugs@ , > but scsi@ now seems more appropriate than bugs@. > I & some other 1542A people are most probably not on scsi@ list, > so please be careful if trimming CC line. > ] > > I (Julian Stacey ) did a load more hardware changes & tests, > including swapping my Adaptec 1542A for a 1542B, & swapping sd0 & sd1, > & eventually deduced it was not my 1542A that was mis-behaving, > (returning 8 * 0xFF bytes at intermittent multiples of 0x1000), > but was one of 2 HP 97548S SCSI 1 633MB disks. > > Either the disk is faulty, or maybe the scsi code might not be > allowing for some strange sequence, or some such. > > __HOWEVER__ > We can't dismiss it as an isolated equipment fault, as > - tomppa@fidata.fi detects similar data corruptions, > - scott@relay.forest.com seems to be having similar problems, > but with a 1542B, > - perhaps other people are suffering similar corruption > without realising it. > > Partial Conclusion: > 1542A people can `relax', to the extent that 1542B seems to be > able to trigger the fault too (I don't have a1542C or 2940 etc) I've just run into this same problem, but I can't confirm your findings. I'm putting together a machine out of old junk parts. Currently it has a 486/66 with 16 MB and two full-height 5\(14" drives: (aha0:0:0): "CDC 94161-9 6226" type 0 fixed SCSI 1 sd0(aha0:0:0): Direct-Access 148MB (304605 512 byte sectors) (aha0:1:0): "CDC 94171-9 5836" type 0 fixed SCSI 1 sd1(aha0:1:0): Direct-Access 308MB (631017 512 byte sectors) Although these drives both claim to be CDC, the second one has a Seagate label on it. I installed 2.1-RELEASE on the machine from CD-ROM, and immediately after booting lots of programs SIGSEGVed. I compared them with the original and found almost exactly the same symptoms you describe: here's the result of comparing /usr/bin at a later time: /usr/bin/cu bin/cu differ: char 40961, line 131 /usr/bin/uucp bin/uucp differ: char 32769, line 97 /usr/bin/uupick bin/uupick differ: char 32769, line 102 /usr/bin/uustat bin/uustat differ: char 32769, line 111 /usr/bin/as bin/as differ: char 81921, line 185 /usr/bin/awk bin/awk differ: char 32769, line 83 /usr/bin/bc bin/bc differ: char 32769, line 134 /usr/bin/cvs bin/cvs differ: char 212993, line 725 /usr/bin/gdb bin/gdb differ: char 475137, line 5209 /usr/bin/grep bin/grep differ: char 32771, line 107 /usr/bin/egrep bin/egrep differ: char 32771, line 107 /usr/bin/fgrep bin/fgrep differ: char 32771, line 107 (many more) It's interesting to note how many come immediately after the first 32 KB. In the cases I looked at, a number of bytes had been replaced by 0xff; the total size of the executable didn't change. In most other cases, too, the corruption was at or immediately after the beginning of a memory page. Another point: I've only seen this corruption on the second disk. Considering that they're almost identical, that's interesting. I don't know how to explain it, except that maybe it's a coincidence. The big difference from your experience is that I replaced the 1542A with a 1542B, and the problems completely disappeared. Let's look at the other responders: >> Date: Tue, 11 Jun 1996 16:56:50 -0400 >> From: Scott Kelly >> To: jhs@freebsd.org >> Subject: Adaptec 1542A Users (from 12 Apr 1996) >> >> >> I seem to be having similar problems, but with a 1542B... Do you know if there >> has been a driver update since April? Are you sure that these are the exact problems? What other hardware are you running? > For reference, I'll append parts of my last mail: >> Tomi Vainio >> Has confirmed he sees the same Adaptec 1542A SCSI adapter bug that I do. >> >> > I connected sd1 to my 1542A and here are results: >> > >> > 1. No problems if testblock is only one that generates disk activity. >> > 2. I launched couple find processes to sd0 and at same time I >> > run testblock. Testblock failed only 1/10 of test runs. >> > 3. I copied files with cp to sd1 when running testblock on >> > sd1. Testblock failed on every time. Yes, I had a vague feeling that it was related to the amount of disk activity. >> So it looks like a generic bug in FreeBSD code: >> With a 1542A (& not a 1542B, which seems OK), >> In simultaneous multiple task write mode to sd1 (or 2 or 3 or 4), >> At random multiples of 0x1000 bytes, >> The first 8 bytes of a block get forced to 0xFF. >> (Of course it may well be that FreeBSD code is not `in error' but merely >> doesnt allow for some wart in the 1542A, that's fixed in the 1542B, >> but whatever, we need a fix). > > As above in this mail, I think I'm wrong there, it's not 1542A sepcific, > I get it with 2 different 1542B's as well Do you have 1542Bs with which you don't get it? When I get a bit of time, I intend to install BSD/OS on the same configuration and see if it has the same problems. Greg From owner-freebsd-scsi Sun Jul 14 13:29:43 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA13721 for freebsd-scsi-outgoing; Sun, 14 Jul 1996 13:29:43 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA13700; Sun, 14 Jul 1996 13:29:37 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA05013; Mon, 15 Jul 1996 06:14:07 +1000 Date: Mon, 15 Jul 1996 06:14:07 +1000 From: Bruce Evans Message-Id: <199607142014.GAA05013@godzilla.zeta.org.au> To: joerg_wunsch@uriah.heep.sax.de, julian@ref.tfs.com Subject: Re: Jaz drive questions Cc: Stephen.Couchman@imagenet.on.ca, freebsd-questions@FreeBSD.org, freebsd-scsi@FreeBSD.org, n_melhor@Telebit.COM Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> > > sd1(ahc0:2:0): ILLEGAL REQUEST asc:24,0 Invalid field in >> > > CDB sd1 could not mode sense (4). Using ficticious >> > > geometry 1021MB (2091050 512 byte sectors) >> > >> > This means that FreeBSD _did_ recognize the drive. Iomega apparently >> > didn't bother to implement the SCSI mode sense command, so the driver ^mode page 4 of the >> > can't determine anything about the number of heads or sectors/track >> > on the disk (if any). >> ... >the geometry is in fact unimportant.. It's important for booting. >the ficticious one should work just fine.. Only insofar as it is not much used, or happens to match the geometry used in the MBR. If there is no MBR and you use the (64 heads) * (32 sectors) geometry then booting will only be possible provided: 1) The SCSI BIOS supports this geometry either as a default or by interpreting the MBR. It probably does. 2) The boot cylinder is < 1024. Each cylinder is 1M in the 64x32 geometry, so there is no problem for drives smaller than 1024MB. The drive under discussion is slightly smaller so there is no problem for it. A geometry of (255 heads) * (63 sectors) should be used for drives in the 1GB-8GB range if the SCSI BIOS supports it. >> The claimed number of sectors looks highly suspicious: it's IMHO >> 10 x too large. It's normal for a 1GB drive. Bruce From owner-freebsd-scsi Mon Jul 15 00:27:33 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA10009 for freebsd-scsi-outgoing; Mon, 15 Jul 1996 00:27:33 -0700 (PDT) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA09999 for ; Mon, 15 Jul 1996 00:27:31 -0700 (PDT) Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.7.5/jtpda-5.2) with ESMTP id JAA05764 for ; Mon, 15 Jul 1996 09:27:25 +0200 (METDST) Received: from cezanne.prism.uvsq.fr (cezanne.prism.uvsq.fr [193.51.25.64]) by guillotin.prism.uvsq.fr (8.7.5/jtpda-5.2) with ESMTP id JAA27519 for ; Mon, 15 Jul 1996 09:27:18 +0200 (MET DST) From: Nicolas.Souchu@prism.uvsq.fr (Nicolas SOUCHU) Received: from (son@localhost) by cezanne.prism.uvsq.fr (8.7.5/jtpda-5.2) id QAA03718 ; Sat, 13 Jul 1996 16:35:51 +0200 (METDST) Date: Sat, 13 Jul 1996 16:35:51 +0200 (METDST) Message-Id: <199607131435.QAA03718@cezanne.prism.uvsq.fr> To: "Nathan Melhorn" CC: freebsd-scsi@freebsd.org Subject: ZIP IOMEGA driver (was Jaz drive questions) In-Reply-To: <9606128372.AA837205829@smtpgate.chelmsford.telebit.com> References: <9606128372.AA837205829@smtpgate.chelmsford.telebit.com> Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I just installed an IOMega parallel port Zip drive into my kernel. It's not > part of FreeBSD, I just found the PPA-3 driver on someone's web page > (Nicolas.Souchu@prism.uvsq.fr) -- who can't actively support it at this > time. I don't want to worry about ziptools, yet. But ppa3.c release 0.20 is now available as I promised it in my last mail. (http://www.prism.uvsq.fr/~son/ppa3.c) Now the system is not frozen when you use your ZIP drive. A timeout is scheduled for each scsi request, releasing then some CPU time. Thanks to Justin T. Gibbs precious help... ... > I don't know about your other problems, since I'm new to FreeBSD and still > fooling around with the ZipDrive. Currently the probe at boot time takes 2 > minutes! I also haven't yet tried formatting it as a Unix disk. Have you tried to disable the SCSI_DELAY in your MACHINE configuration file to get faster startup ? nicolas Nicolas.Souchu@prism.uvsq.fr From owner-freebsd-scsi Mon Jul 15 05:53:28 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA04656 for freebsd-scsi-outgoing; Mon, 15 Jul 1996 05:53:28 -0700 (PDT) Received: from mailbox.neosoft.com (mailbox.neosoft.com [206.109.1.16]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA04649 for ; Mon, 15 Jul 1996 05:53:24 -0700 (PDT) Received: from bonkers.taronga.com (root@bonkers.neosoft.com [206.109.2.48]) by mailbox.neosoft.com (8.7.5/8.7.3) with SMTP id HAA29535 for ; Mon, 15 Jul 1996 07:53:21 -0500 (CDT) Received: (from peter@localhost) by bonkers.taronga.com (8.6.11/8.6.9) id HAA13974; Mon, 15 Jul 1996 07:51:06 -0500 Date: Mon, 15 Jul 1996 07:51:06 -0500 From: peter@taronga.com (Peter da Silva) Message-Id: <199607151251.HAA13974@bonkers.taronga.com> To: scsi@freebsd.org Subject: Re: Jaz drive questions Newsgroups: taronga.freebsd.scsi In-Reply-To: <199607140804.KAA15641@uriah.heep.sax.de> References: <199607132245.IAA03964@godzilla.zeta.org.au> Organization: none Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199607140804.KAA15641@uriah.heep.sax.de>, J Wunsch wrote: >The claimed number of sectors looks highly suspicious: it's IMHO >10 x too large. You confusing the JAZ and the ZIP? The ZIP is 100MB, the JAZ is 1GB. From owner-freebsd-scsi Mon Jul 15 08:52:29 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA18904 for freebsd-scsi-outgoing; Mon, 15 Jul 1996 08:52:29 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA18890 for ; Mon, 15 Jul 1996 08:52:12 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id RAA23240 for ; Mon, 15 Jul 1996 17:50:44 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id RAA05756 for scsi@FreeBSD.ORG; Mon, 15 Jul 1996 17:50:44 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id RAA17107 for scsi@FreeBSD.ORG; Mon, 15 Jul 1996 17:30:56 +0200 (MET DST) From: J Wunsch Message-Id: <199607151530.RAA17107@uriah.heep.sax.de> Subject: Re: Jaz drive questions To: scsi@FreeBSD.ORG Date: Mon, 15 Jul 1996 17:30:56 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607151251.HAA13974@bonkers.taronga.com> from Peter da Silva at "Jul 15, 96 07:51:06 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Peter da Silva wrote: > >The claimed number of sectors looks highly suspicious: it's IMHO > >10 x too large. > > You confusing the JAZ and the ZIP? The ZIP is 100MB, the JAZ is 1GB. Yes, i was. Bruce already corrected me. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Tue Jul 16 01:13:20 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA22363 for freebsd-scsi-outgoing; Tue, 16 Jul 1996 01:13:20 -0700 (PDT) Received: from minotaur.labyrinth.net.au (minotaur.labyrinth.net.au [203.9.148.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA22286 for ; Tue, 16 Jul 1996 01:12:25 -0700 (PDT) Received: (from mail@localhost) by minotaur.labyrinth.net.au (8.7.2/8.7.2) id QAA13198 for ; Tue, 16 Jul 1996 16:41:25 +1000 (EST) Date: Tue, 16 Jul 1996 16:41:25 +1000 (EST) Message-Id: <199607160641.QAA13198@minotaur.labyrinth.net.au> X-Authentication-Warning: minotaur.labyrinth.net.au: mail set sender to using -f Received: from portal-as13.labyrinth.net.au(203.9.148.23) by minotaur.labyrinth.net.au via smap (V1.3) id sma013193; Tue Jul 16 16:41:18 1996 X-Sender: jbh@labyrinth.net.au (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-scsi@freebsd.org From: John Hartley Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 12:40 14/07/96 +0200, you wrote: Here is more SCSI debug output following another session of testing with the Tandberg tape drive. >As John Hartley wrote: > >> >+ {"Tandberg tdc4100", "TANDBERG", " TDC 4100", "????", >> >+ ST_Q_NEEDS_PAGE_0|ST_Q_SNS_HLP, > ^^^^^^^^^^^^^^^^^^ > >Take this out again. :) It hurts when i do so... We are now >violating the specs by setting the PS bit in a MODE SELECT command: > Tryed this as follows: >>> mt fsr <<< Jul 16 16:56:45 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 >>> mt rewind <<< Jul 16 16:57:26 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 >>> mt status <<< ditto >>> Output <<< Present Mode: Density = 0x00 Blocksize = 1024 bytes ---------available modes--------- Mode 0: Density = 0x00 Blocksize variable Mode 1: Density = QIC-320 Blocksize variable Mode 2: Density = QIC-150 Blocksize variable Mode 3: Density = QIC-120 Blocksize variable >>> tar tv (with debug on) <<< Jul 16 17:49:06 qwiff /kernel: st0(ahc0:2:0): stclose: Closing device Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:49:23 qwiff /kernel: xs(0xf0859980): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf08599d8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:49:23 qwiff /kernel: : get_xs Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:49:23 qwiff /kernel: xs(0xf0859980): flg(0x20)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf08599d8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:49:23 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): mounting Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:49:24 qwiff /kernel: xs(0xf0859980): flg(0x20)sc_link(0xf0859780)retr(0x4)timo(0x493e0)cmd(0xf08599d8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1b,0,0,0,1,0-[0 bytes] Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): command: 1b,0,0,0,1,0-[0 bytes] Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:49:24 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:49:25 qwiff /kernel: xs(0xf0859980): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf08599d8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:49:25 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:49:26 qwiff /kernel: xs(0xf0aaff80): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0aaffd8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 16 17:49:26 qwiff /kernel: ------------------------------ Jul 16 17:49:26 qwiff /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 Jul 16 17:49:26 qwiff /kernel: ------------------------------ Jul 16 17:49:26 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:49:26 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:49:26 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 16 17:49:26 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:49:26 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:49:26 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:49:26 qwiff /kernel: st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 16 17:49:26 qwiff /kernel: ------------------------------ Jul 16 17:49:26 qwiff /kernel: 000: 2f 25 10 08 15 00 00 00 00 00 02 00 Jul 16 17:49:26 qwiff /kernel: ------------------------------ Jul 16 17:49:26 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:49:26 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:49:26 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:49:26 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:49:27 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): density code 0x15, 512-byte blocks, write-enabled, st0(ahc0:2:0): buffered Jul 16 17:49:27 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 16 17:49:27 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:49:27 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:49:27 qwiff /kernel: xs(0xf0859980): flg(0x820)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf08599d8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 16 17:49:27 qwiff /kernel: ------------------------------ Jul 16 17:49:27 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 Jul 16 17:49:27 qwiff /kernel: ------------------------------ Jul 16 17:49:27 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:49:27 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 16 17:49:27 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 16 17:49:27 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:49:27 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:49:27 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:49:27 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 16 17:49:28 qwiff /kernel: ------------------------------ Jul 16 17:49:28 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 Jul 16 17:49:28 qwiff /kernel: ------------------------------ Jul 16 17:49:28 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:49:28 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x1 Jul 16 17:49:28 qwiff /kernel: code70 valid0 seg0 key5 ili0 eom0 fmark0 Jul 16 17:49:28 qwiff /kernel: info: 0 0 0 0 followed by 10 extra bytes Jul 16 17:49:28 qwiff /kernel: extra: 0 8 0 0 24 0 2 0 0 0 Jul 16 17:49:28 qwiff /kernel: st0(ahc0:2:0): calling private err_handler() Jul 16 17:49:28 qwiff /kernel: st0(ahc0:2:0): private err_handler() returned -1 Jul 16 17:49:28 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 16 17:49:28 qwiff /kernel: st0(ahc0:2:0): scsi_interpret_sense (no bp) returned 22 Jul 16 17:49:28 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:49:28 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:49:28 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): Open complete Jul 16 17:49:29 qwiff /kernel: st0(ahc0:2:0): stopen: dev=0xe00 (unit 0) result 0 Jul 16 17:49:29 qwiff /kernel: st0(ahc0:2:0): Jul 16 17:49:29 qwiff /kernel: ststrategy st0(ahc0:2:0): 10240 bytes @ blk0 Jul 16 17:49:29 qwiff /kernel: st0(ahc0:2:0): ststart st0: oops not queued >>> mt status <<<< ditto >>> Output <<<< Present Mode: Density = 0x00 Blocksize = 1024 bytes ---------available modes--------- Mode 0: Density = 0x00 Blocksize variable Mode 1: Density = QIC-320 Blocksize variable Mode 2: Density = QIC-150 Blocksize variable Mode 3: Density = QIC-120 Blocksize variable > >I wonder whether we should always use the following kludge: > >@@ -1530,7 +1530,9 @@ > scsi_cmd.length = dat_len; > dat.header.blk_desc_len = sizeof(struct blk_desc); > dat.header.dev_spec |= SMH_DSP_BUFF_MODE_ON; >- dat.blk_desc.density = st->density; >+ dat.blk_desc.density = >+ st->density? st->density: >+ 0x7f /* use previous density */; > if (st->flags & ST_FIXEDBLOCKS) { > scsi_uto3b(st->blksiz, dat.blk_desc.blklen); > } > > > I didn't try this as the previous test failed!! Instead I put in the alternative rogue lines. >+ {"Tandberg tdc4100", "TANDBERG", " TDC 4100", "????", >+ ST_Q_NEEDS_PAGE_0|ST_Q_SNS_HLP, >+ { >+ {0, 0, 0}, /* minor 0,1,2,3 */ >+ {0, ST_Q_FORCE_VAR_MODE, QIC_525}, /* minor 4,5,6,7 */ >+ {0, ST_Q_FORCE_VAR_MODE, 0x15}, /* minor 8,9,10,11 */ >+ {512, ST_Q_FORCE_FIXED_MODE, QIC_150} /* minor 12,13,14,15 */ >+ } >+ }, Put this in without the ST_Q_NEED_PAGE_0 flag (as per previous test). mt fsr mt rewind mt status (all produced ussual error) >>> Output <<< Present Mode: Density = 0x00 Blocksize = 1024 bytes ---------available modes--------- Mode 0: Density = 0x00 Blocksize variable Mode 1: Density = QIC-320 Blocksize variable Mode 2: Density = ECMA TC17 Blocksize variable Mode 3: Density = QIC-150 Blocksize = 512 bytes >>> tar tvf /dev/rst0.0 <<<< Jul 16 17:07:56 qwiff /kernel: st0(ahc0:2:0): stclose: Closing device Jul 16 17:08:35 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 16 17:08:35 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:08:35 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:08:36 qwiff /kernel: xs(0xf0aaff80): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:08:36 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:08:36 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 16 17:08:36 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:08:36 qwiff /kernel: : get_xs Jul 16 17:08:36 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:08:36 qwiff /kernel: xs(0xf0aaff80): flg(0x20)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:08:36 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:08:36 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 16 17:08:36 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:08:36 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:08:36 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:08:36 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:08:36 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:08:37 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:08:37 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:08:37 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:08:37 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): mounting Jul 16 17:08:37 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 16 17:08:37 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:08:37 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:08:37 qwiff /kernel: xs(0xf0aaff80): flg(0x20)sc_link(0xf0859780)retr(0x4)timo(0x493e0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1b,0,0,0,1,0-[0 bytes] Jul 16 17:08:37 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:08:37 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 16 17:08:37 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:08:37 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:08:37 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): command: 1b,0,0,0,1,0-[0 bytes] Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:08:38 qwiff /kernel: xs(0xf0aaff80): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:08:38 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:08:39 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:08:39 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:08:39 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:08:39 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:08:39 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:08:39 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 16 17:08:39 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:08:39 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:08:39 qwiff /kernel: xs(0xf0aaff80): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0aaffd8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 16 17:08:39 qwiff /kernel: ------------------------------ Jul 16 17:08:39 qwiff /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 Jul 16 17:08:39 qwiff /kernel: ------------------------------ Jul 16 17:08:39 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:08:40 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:08:40 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 16 17:08:40 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:08:40 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:08:40 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:08:40 qwiff /kernel: st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 16 17:08:40 qwiff /kernel: ------------------------------ Jul 16 17:08:40 qwiff /kernel: 000: 2f 25 10 08 15 00 00 00 00 00 02 00 Jul 16 17:08:40 qwiff /kernel: ------------------------------ Jul 16 17:08:40 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:08:40 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:08:40 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:08:40 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:08:40 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): density code 0x15, 512-byte blocks, write-enabled, st0(ahc0:2:0): buffered Jul 16 17:08:41 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 16 17:08:41 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:08:41 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:08:41 qwiff /kernel: xs(0xf0aaff80): flg(0x820)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0aaffd8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 16 17:08:41 qwiff /kernel: ------------------------------ Jul 16 17:08:41 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 Jul 16 17:08:41 qwiff /kernel: ------------------------------ Jul 16 17:08:41 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:08:41 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:08:41 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 16 17:08:41 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:08:41 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:08:41 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:08:41 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 16 17:08:41 qwiff /kernel: ------------------------------ Jul 16 17:08:42 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 Jul 16 17:08:42 qwiff /kernel: ------------------------------ Jul 16 17:08:42 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:08:42 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x1 Jul 16 17:08:42 qwiff /kernel: code70 valid0 seg0 key5 ili0 eom0 fmark0 Jul 16 17:08:42 qwiff /kernel: info: 0 0 0 0 followed by 10 extra bytes Jul 16 17:08:42 qwiff /kernel: extra: 0 8 0 0 24 0 2 0 0 0 Jul 16 17:08:42 qwiff /kernel: st0(ahc0:2:0): calling private err_handler() Jul 16 17:08:42 qwiff /kernel: st0(ahc0:2:0): private err_handler() returned -1 Jul 16 17:08:42 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 16 17:08:42 qwiff /kernel: st0(ahc0:2:0): scsi_interpret_sense (no bp) returned 22 Jul 16 17:08:42 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:08:42 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:08:42 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): Open complete Jul 16 17:08:42 qwiff /kernel: st0(ahc0:2:0): stopen: dev=0xe00 (unit 0) result 0 Jul 16 17:08:43 qwiff /kernel: st0(ahc0:2:0): Jul 16 17:08:43 qwiff /kernel: ststrategy st0(ahc0:2:0): 10240 bytes @ blk0 Jul 16 17:08:43 qwiff /kernel: st0(ahc0:2:0): ststart st0: oops not queued >>> tar tvf /dev/rst0.1 <<< Jul 16 17:08:43 qwiff /kernel: st0(ahc0:2:0): stclose: Closing device Jul 16 17:09:07 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 16 17:09:07 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:09:07 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:09:07 qwiff /kernel: xs(0xf0aaff80): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:09:07 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:09:07 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 16 17:09:07 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:09:07 qwiff /kernel: : get_xs Jul 16 17:09:07 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:09:07 qwiff /kernel: xs(0xf0aaff80): flg(0x20)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:09:07 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:09:07 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 16 17:09:07 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): mounting Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:09:08 qwiff /kernel: xs(0xf0859980): flg(0x20)sc_link(0xf0859780)retr(0x4)timo(0x493e0)cmd(0xf08599d8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1b,0,0,0,1,0-[0 bytes] Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:09:08 qwiff /kernel: st0(ahc0:2:0): command: 1b,0,0,0,1,0-[0 bytes] Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:09:09 qwiff /kernel: xs(0xf0859980): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf08599d8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:09:09 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:09:10 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 16 17:09:10 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:09:10 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:09:10 qwiff /kernel: xs(0xf0859980): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf08599d8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 16 17:09:10 qwiff /kernel: ------------------------------ Jul 16 17:09:10 qwiff /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 Jul 16 17:09:10 qwiff /kernel: ------------------------------ Jul 16 17:09:10 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:09:10 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:09:10 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 16 17:09:10 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:09:10 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:09:10 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:09:10 qwiff /kernel: st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 16 17:09:10 qwiff /kernel: ------------------------------ Jul 16 17:09:10 qwiff /kernel: 000: 2f 25 10 08 15 00 00 00 00 00 02 00 Jul 16 17:09:10 qwiff /kernel: ------------------------------ Jul 16 17:09:10 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): density code 0x15, 512-byte blocks, write-enabled, st0(ahc0:2:0): buffered Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:09:11 qwiff /kernel: xs(0xf0859980): flg(0x820)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf08599d8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 16 17:09:11 qwiff /kernel: ------------------------------ Jul 16 17:09:11 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 Jul 16 17:09:11 qwiff /kernel: ------------------------------ Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:09:11 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:09:12 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 16 17:09:12 qwiff /kernel: ------------------------------ Jul 16 17:09:12 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 Jul 16 17:09:12 qwiff /kernel: ------------------------------ Jul 16 17:09:12 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:09:12 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x1 Jul 16 17:09:12 qwiff /kernel: code70 valid0 seg0 key5 ili0 eom0 fmark0 Jul 16 17:09:12 qwiff /kernel: info: 0 0 0 0 followed by 10 extra bytes Jul 16 17:09:12 qwiff /kernel: extra: 0 8 0 0 24 0 2 0 0 0 Jul 16 17:09:12 qwiff /kernel: st0(ahc0:2:0): calling private err_handler() Jul 16 17:09:12 qwiff /kernel: st0(ahc0:2:0): private err_handler() returned -1 Jul 16 17:09:12 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 16 17:09:12 qwiff /kernel: st0(ahc0:2:0): scsi_interpret_sense (no bp) returned 22 Jul 16 17:09:12 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:09:12 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:09:12 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): Open complete Jul 16 17:09:12 qwiff /kernel: st0(ahc0:2:0): stopen: dev=0xe04 (unit 0) result 0 Jul 16 17:09:12 qwiff /kernel: st0(ahc0:2:0): Jul 16 17:09:13 qwiff /kernel: ststrategy st0(ahc0:2:0): 10240 bytes @ blk0 Jul 16 17:09:13 qwiff /kernel: st0(ahc0:2:0): ststart st0: oops not queued >>> tar tvf /dev/rst0.2 <<<< Jul 16 17:09:13 qwiff /kernel: st0(ahc0:2:0): stclose: Closing device Jul 16 17:09:33 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 16 17:09:33 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:09:33 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:09:33 qwiff /kernel: xs(0xf0aaff80): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:09:33 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:09:34 qwiff /kernel: : get_xs Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:09:34 qwiff /kernel: xs(0xf0aaff80): flg(0x20)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:09:34 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): mounting Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:09:35 qwiff /kernel: xs(0xf0aaff80): flg(0x20)sc_link(0xf0859780)retr(0x4)timo(0x493e0)cmd(0xf0aaffd8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1b,0,0,0,1,0-[0 bytes] Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): command: 1b,0,0,0,1,0-[0 bytes] Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:09:35 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:09:35 qwiff /kernel: xs(0xf0859980): flg(0x60)sc_link(0xf0859780)retr(0x2)timo(0x186a0)cmd(0xf08599d8)len(0x6)dat a(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): command: 0,0,0,0,0,0-[0 bytes] Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): scsi_cmd Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:09:36 qwiff /kernel: xs(0xf0859980): flg(0x420)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf08599d8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 16 17:09:36 qwiff /kernel: ------------------------------ Jul 16 17:09:36 qwiff /kernel: 000: 00 00 00 00 00 00 00 00 00 00 00 00 Jul 16 17:09:36 qwiff /kernel: ------------------------------ Jul 16 17:09:36 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0a59000) Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): command: 1a,0,0,0,c,0-[12 bytes] Jul 16 17:09:37 qwiff /kernel: ------------------------------ Jul 16 17:09:37 qwiff /kernel: 000: 2f 25 10 08 15 00 00 00 00 00 02 00 Jul 16 17:09:37 qwiff /kernel: ------------------------------ Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x0 Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): density code 0x15, 512-byte blocks, write-enabled, st0(ahc0:2:0): buffered Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): scsi_cmd Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): get_xs Jul 16 17:09:37 qwiff /kernel: st0(ahc0:2:0): returning Jul 16 17:09:37 qwiff /kernel: xs(0xf0aaff80): flg(0x820)sc_link(0xf0859780)retr(0x4)timo(0x1388)cmd(0xf0aaffd8)len(0x6)dat a(0xf2772000)len(0xc)res(0x0)err(0x0)bp(0x0)st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 16 17:09:38 qwiff /kernel: ------------------------------ Jul 16 17:09:38 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 Jul 16 17:09:38 qwiff /kernel: ------------------------------ Jul 16 17:09:38 qwiff /kernel: st0(ahc0:2:0): ahc_scsi_cmd Jul 16 17:09:38 qwiff /kernel: st0(ahc0:2:0): start scb(0xf0ab0000) Jul 16 17:09:38 qwiff /kernel: st0(ahc0:2:0): 12 @0xf2772000:- 0x4b000(0xc) Jul 16 17:09:38 qwiff /kernel: st0(ahc0:2:0): cmd_sent Jul 16 17:09:38 qwiff /kernel: st0(ahc0:2:0): ahc_done Jul 16 17:09:38 qwiff /kernel: st0(ahc0:2:0): scsi_done Jul 16 17:09:38 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] Jul 16 17:09:38 qwiff /kernel: ------------------------------ Jul 16 17:09:38 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 Jul 16 17:09:38 qwiff /kernel: ------------------------------ Jul 16 17:09:38 qwiff /kernel: st0(ahc0:2:0): back in cmd() Jul 16 17:09:38 qwiff /kernel: st0(ahc0:2:0): sc_err1,err = 0x1 Jul 16 17:09:38 qwiff /kernel: code70 valid0 seg0 key5 ili0 eom0 fmark0 Jul 16 17:09:38 qwiff /kernel: info: 0 0 0 0 followed by 10 extra bytes Jul 16 17:09:38 qwiff /kernel: extra: 0 8 0 0 24 0 2 0 0 0 Jul 16 17:09:39 qwiff /kernel: st0(ahc0:2:0): calling private err_handler() Jul 16 17:09:39 qwiff /kernel: st0(ahc0:2:0): private err_handler() returned -1 Jul 16 17:09:39 qwiff /kernel: st0(ahc0:2:0): ILLEGAL REQUEST csi:0,8,0,0 asc:24,0 Invalid field in CDB field replaceable unit: 2 Jul 16 17:09:39 qwiff /kernel: st0(ahc0:2:0): scsi_interpret_sense (no bp) returned 22 Jul 16 17:09:39 qwiff /kernel: st0(ahc0:2:0): free_xs Jul 16 17:09:39 qwiff /kernel: st0(ahc0:2:0): calling private start() Jul 16 17:09:39 qwiff /kernel: st0(ahc0:2:0): ststart st0(ahc0:2:0): Open complete Jul 16 17:09:39 qwiff /kernel: st0(ahc0:2:0): stopen: dev=0xe08 (unit 0) result 0 Jul 16 17:09:39 qwiff /kernel: st0(ahc0:2:0): Jul 16 17:09:39 qwiff /kernel: ststrategy st0(ahc0:2:0): 10240 bytes @ blk0 Jul 16 17:09:39 qwiff /kernel: st0(ahc0:2:0): ststart st0: oops not queued >>> mt status <<< >>> Output <<< Present Mode: Density = 0x00 Blocksize = 1024 bytes ---------available modes--------- Mode 0: Density = 0x00 Blocksize variable Mode 1: Density = QIC-320 Blocksize variable Mode 2: Density = ECMA TC17 Blocksize variable Mode 3: Density = QIC-150 Blocksize = 512 bytes !!!!!! That is the end of the latest block of testing. I guess the question is is what is it that the FreeBSD drivers are doing that is different from the dos ASPI and Windows NT tape driver??? Could it be possible that they are not doing a "mode set" before reading or writing data to the tape and so are not being caught by the "sensisitvity" of the hardware??? Not being a SCSI person this is pure speculation... Thanks to anyone/everyone who has taken time to look at all these logs. Regards. John Hartley. From owner-freebsd-scsi Tue Jul 16 11:20:33 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA19881 for freebsd-scsi-outgoing; Tue, 16 Jul 1996 11:20:33 -0700 (PDT) Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA19863; Tue, 16 Jul 1996 11:20:29 -0700 (PDT) Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id OAA16599; Tue, 16 Jul 1996 14:19:34 -0400 Received: from centime.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id OAA05745; Tue, 16 Jul 1996 14:20:37 -0400 Received: by centime.cascade (5.x/SMI-SVR4) id AA12434; Tue, 16 Jul 1996 14:20:34 -0400 Date: Tue, 16 Jul 1996 14:20:34 -0400 From: conta@alpo.casc.com (Alex Conta) Message-Id: <9607161820.AA12434@centime.cascade> To: freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org Subject: Adaptec 2940 PCI-SCSI on Compaq ProLinea 5100 Cc: conta@alpo.casc.com X-Sun-Charset: US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk SCSI hardware/freebsd problem: 1. I have an Adaptec 2940 PCI-SCSI-2 adapter that works just fine under FreeBSD 2.1 on a DEC Starion 960 PC (SCSI-2 hard disk drive + cd-rom). The same adapter works fine on a Compaq ProLinea 5100 (SCSI hard disk and cd-rom) under Windows 3.1, but it does not work when I try to install FreeBSD from a CD-ROM distribution. The installation fails because the adapter is not recognized. Booting with "-c" and setting manually the IRQ, Port Address, and other parameters didn't help. Known problem? Known solution? 2. Any plans to add support for the AMD SCSI adapter that is embedded with Compaq DexPro 6200 XL? Alex From owner-freebsd-scsi Tue Jul 16 11:53:43 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA22917 for freebsd-scsi-outgoing; Tue, 16 Jul 1996 11:53:43 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA22911; Tue, 16 Jul 1996 11:53:40 -0700 (PDT) Message-Id: <199607161853.LAA22911@freefall.freebsd.org> To: conta@alpo.casc.com (Alex Conta) cc: freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Adaptec 2940 PCI-SCSI on Compaq ProLinea 5100 In-reply-to: Your message of "Tue, 16 Jul 1996 14:20:34 EDT." <9607161820.AA12434@centime.cascade> Date: Tue, 16 Jul 1996 11:53:40 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >SCSI hardware/freebsd problem: > >1. > >I have an Adaptec 2940 PCI-SCSI-2 adapter that works just fine under FreeBSD >2.1 on a DEC Starion 960 PC (SCSI-2 hard disk drive + cd-rom). > >The same adapter works fine on a Compaq ProLinea 5100 (SCSI hard disk and >cd-rom) under Windows 3.1, but it does not work when I try to install FreeBSD >from a CD-ROM distribution. > >The installation fails because the adapter is not recognized. Booting with >"-c" and setting manually the IRQ, Port Address, and other parameters didn't >help. The 2940 shouldn't show up in Userconfig anymore. It is not an ISA device. >Known problem? Known solution? This is the first I've heard of this kind of problem. Perhaps our PCI code is having problems with this board. >Alex > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Tue Jul 16 12:20:37 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA27453 for freebsd-scsi-outgoing; Tue, 16 Jul 1996 12:20:37 -0700 (PDT) Received: from Sisyphos (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA27428; Tue, 16 Jul 1996 12:20:31 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-47.slip.Uni-Koeln.DE) by Sisyphos with SMTP id AA22308 (5.67b/IDA-1.5); Tue, 16 Jul 1996 21:20:17 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.5/8.6.9) id VAA00899; Tue, 16 Jul 1996 21:20:08 +0200 (MET DST) Date: Tue, 16 Jul 1996 21:20:08 +0200 (MET DST) Message-Id: <199607161920.VAA00899@x14.mi.uni-koeln.de> From: Stefan Esser To: conta@alpo.casc.com (Alex Conta) Cc: freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org Subject: Adaptec 2940 PCI-SCSI on Compaq ProLinea 5100 In-Reply-To: <9607161820.AA12434@centime.cascade> References: <9607161820.AA12434@centime.cascade> Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Alex Conta writes: > > SCSI hardware/freebsd problem: > > 1. > > I have an Adaptec 2940 PCI-SCSI-2 adapter that works just fine under FreeBSD > 2.1 on a DEC Starion 960 PC (SCSI-2 hard disk drive + cd-rom). > > The same adapter works fine on a Compaq ProLinea 5100 (SCSI hard disk and > cd-rom) under Windows 3.1, but it does not work when I try to install FreeBSD > from a CD-ROM distribution. > > The installation fails because the adapter is not recognized. Booting with > "-c" and setting manually the IRQ, Port Address, and other parameters didn't > help. Please enter "-v" at the "Boot: " prompt and send me all numbers from the lines starting with pcibus_setup or pcibus_check. If it reports success in the pcibus_check line, then I need any information about devices found on the PCI bus. > Known problem? Known solution? Compaq caused lots of problems because of their knowingly ignoring the PCI specs. I once got a reply that it wouldn't matter, since the BIOS and their drivers worked around the problems introduced this way. But what they didn't care about was, that the required workaround might break support for other systems. They don't bother, since they know their drivers are only used with their machines. But we hardly want to have a special FreeBSD version just for Compaq machines ... :) > 2. > > Any plans to add support for the AMD SCSI adapter that is embedded with > Compaq DexPro 6200 XL? There was a message from Tekram recently, who seem to offer a SCSI board based on the same chip and who seemed to be interested in having it supported under FreeBSD. I sent them a reply, but did not hear from them thereafter ... Many people have asked for support of the AMD SCSI chip. But since it is far less powerful than the NCR 53c810, which is available for some $70, nobody bothered to actually write a driver for it ... I understand that it might be good enough to connect an external CDROM or tape ... (It is a bus-master controller, but requires the CPU to handle disconnect and that means that there are multiple interrupts per transfer required and also that SCSI latencies are being introduced which limit the SCSI throughput. The NCR 53c810 as well as the Adaptec 2940 series offers a small CPU as part of the host adapter.) Reagrds, STefan From owner-freebsd-scsi Tue Jul 16 12:23:19 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA27833 for freebsd-scsi-outgoing; Tue, 16 Jul 1996 12:23:19 -0700 (PDT) Received: from Sisyphos (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA27787; Tue, 16 Jul 1996 12:23:10 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-47.slip.Uni-Koeln.DE) by Sisyphos with SMTP id AA22315 (5.67b/IDA-1.5); Tue, 16 Jul 1996 21:22:52 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.5/8.6.9) id VAA00902; Tue, 16 Jul 1996 21:22:39 +0200 (MET DST) Date: Tue, 16 Jul 1996 21:22:39 +0200 (MET DST) Message-Id: <199607161922.VAA00902@x14.mi.uni-koeln.de> From: Stefan Esser To: "Justin T. Gibbs" Cc: conta@alpo.casc.com (Alex Conta), freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Adaptec 2940 PCI-SCSI on Compaq ProLinea 5100 In-Reply-To: <199607161853.LAA22911@freefall.freebsd.org> References: <9607161820.AA12434@centime.cascade> <199607161853.LAA22911@freefall.freebsd.org> Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Justin T. Gibbs writes: > The 2940 shouldn't show up in Userconfig anymore. It is not an ISA device. > > >Known problem? Known solution? > > This is the first I've heard of this kind of problem. Perhaps our PCI > code is having problems with this board. No, it most probably is another problem with a PCI chip set in a Compaq machine ... :( Regards, STefan From owner-freebsd-scsi Tue Jul 16 15:07:11 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA29354 for freebsd-scsi-outgoing; Tue, 16 Jul 1996 15:07:11 -0700 (PDT) Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA29332; Tue, 16 Jul 1996 15:07:03 -0700 (PDT) Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id RAA17702; Tue, 16 Jul 1996 17:55:27 -0400 Received: from centime.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id RAA13338; Tue, 16 Jul 1996 17:56:32 -0400 Received: by centime.cascade (5.x/SMI-SVR4) id AA12557; Tue, 16 Jul 1996 17:56:29 -0400 Date: Tue, 16 Jul 1996 17:56:29 -0400 From: conta@alpo.casc.com (Alex Conta) Message-Id: <9607162156.AA12557@centime.cascade> To: conta@alpo.casc.com, se@ZPR.Uni-Koeln.DE Subject: Re: Adaptec 2940 PCI-SCSI on Compaq ProLinea 5100 Cc: freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org X-Sun-Charset: US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Please enter "-v" at the "Boot: " prompt > and send me all numbers from the lines > starting with pcibus_setup or pcibus_check. > > If it reports success in the pcibus_check > line, then I need any information about > devices found on the PCI bus. Stefan, and Justin, Thanks much for the quick answers. Sorry for not giving this info earlier. With 'boot': On the DEC PC there is a successful, and laborious PCI probe - there are several lines displayed with info about the SCSI adapter, the SCSI CD-ROM, and Hard Disk Drive found, as well as the other PCI cards. On Compaq the PCI probe is apparently very short, and with no comments or lines displayed on the screen. With 'boot -v': on Compaq after the lines: npx0 on motherboard npx0: INT 16 interface the following 5 lines are displayed (only with 'boot -v'): pcibus_setup(1): mode1res=0x80000000c (0x80000000), mode2res = 0x0c (0x0e) rootfs is 1000 kbyte compiled in MFS BIOS geometries: 0:01953f20 0..405=406 cylinders, 0..63=64 heads, 1..32=32 sectors 0 accounted for followed by: /stand/sysinstall running as init > > Compaq caused lots of problems because of > their knowingly ignoring the PCI specs. > I once got a reply that it wouldn't matter, > since the BIOS and their drivers worked > around the problems introduced this way. > > But what they didn't care about was, that > the required workaround might break support > for other systems. They don't bother, since > they know their drivers are only used with > their machines. But we hardly want to have > a special FreeBSD version just for Compaq > machines ... :) The PCI-SCSI adapter works with Windows 3.1 and the Adaptec Windows 3.1 drivers - "EASY-SCSI 4.0" - that I installed from an Adaptec distribution diskette, which are perhaps tunned to the Compaq PCI behavior. Some additional info: on the DEC PC, the PCI-SCSI adapter has the following: IRQ = 9 Port addr = 7000-70ff (length 0xff) Mem Addr = c8000-c8fff (length 0xfff) = f1ef0000 - f1ef0fff (length 0xfff) on Compaq, it has the following: IRQ = 11 Port addr = 1000-10ff (length 0xff) Mem Addr = c8000-cffff (length 0x7fff) - note length difference = 41000000 - 41000fff (length 0xfff) On Compaq the PCI Master is bu default Enabled (BIOS parameter). Changing it didn't have any effect on the FreeBSD behavior. On Compaq an additional PCI device is a Cirrus VGA compatible controller that has: mem addr: 40000000-40ffffff dependencies: 3b0-3bb, 3c0-3df, a0000-bffff, c0000-c7fff I hope this helps to diagnose the problem. > > > 2. > > > > Any plans to add support for the AMD SCSI adapter that is embedded with > > Compaq DexPro 6200 XL? > > There was a message from Tekram recently, who ... > The NCR 53c810 as well as the Adaptec 2940 series > offers a small CPU as part of the host adapter.) > It seems that the AMD based SCSI adapter which comes integrated with the DEXPRO 6200 XL, a high end Compaq desktop, helps Compaq to lower the costs. > Reagrds, STefan > Thanks, Alex From owner-freebsd-scsi Tue Jul 16 15:11:24 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA29685 for freebsd-scsi-outgoing; Tue, 16 Jul 1996 15:11:24 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA29669; Tue, 16 Jul 1996 15:11:16 -0700 (PDT) Received: from orion.webspan.net (root@orion.webspan.net [206.154.70.41]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id PAA21814 ; Tue, 16 Jul 1996 15:11:15 -0700 Received: from localhost (gpalmer@localhost [127.0.0.1]) by orion.webspan.net (8.7.5/8.6.12) with SMTP id SAA03009; Tue, 16 Jul 1996 18:09:47 -0400 (EDT) X-Authentication-Warning: orion.webspan.net: Host gpalmer@localhost [127.0.0.1] didn't use HELO protocol To: conta@alpo.casc.com (Alex Conta) cc: freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org From: "Gary Palmer" Subject: Re: Adaptec 2940 PCI-SCSI on Compaq ProLinea 5100 In-reply-to: Your message of "Tue, 16 Jul 1996 14:20:34 EDT." <9607161820.AA12434@centime.cascade> Date: Tue, 16 Jul 1996 18:09:47 -0400 Message-ID: <3006.837554987@orion.webspan.net> Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Alex Conta wrote in message ID <9607161820.AA12434@centime.cascade>: > I have an Adaptec 2940 PCI-SCSI-2 adapter that works just fine under FreeBSD > 2.1 on a DEC Starion 960 PC (SCSI-2 hard disk drive + cd-rom). > The same adapter works fine on a Compaq ProLinea 5100 (SCSI hard disk and > cd-rom) under Windows 3.1, but it does not work when I try to install FreeBSD > from a CD-ROM distribution. > The installation fails because the adapter is not recognized. Booting with > "-c" and setting manually the IRQ, Port Address, and other parameters didn't > help. > Known problem? Known solution? My money is on the Compaq having one of the ``interesting'' Compaq PCI implimentations which causes our code nightmares. You may want to try 2.1.5 to see if it has the Compaq fixes in it, if not then -current does. (BTW: the ahc driver doesn't appear to the `-c' boot config. as it's a PCI device and all necessary information is auto-detected, but *ONLY* if the PCI bus is detected) > 2. > Any plans to add support for the AMD SCSI adapter that is embedded with > Compaq DexPro 6200 XL? Not that I am aware of. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-scsi Tue Jul 16 15:19:30 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA00889 for freebsd-scsi-outgoing; Tue, 16 Jul 1996 15:19:30 -0700 (PDT) Received: from hda.com (ip17-max1-fitch.zipnet.net [199.232.245.17]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA00877 for ; Tue, 16 Jul 1996 15:19:24 -0700 (PDT) Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id SAA08864; Tue, 16 Jul 1996 18:15:18 -0400 From: Peter Dufault Message-Id: <199607162215.SAA08864@hda.com> Subject: Re: Conner going bad. To: joerg_wunsch@uriah.heep.sax.de Date: Tue, 16 Jul 1996 18:15:16 -0400 (EDT) Cc: freebsd-scsi@FreeBSD.ORG In-Reply-To: <199607122033.WAA20241@uriah.heep.sax.de> from "J Wunsch" at Jul 12, 96 10:33:22 pm Reply-to: hdalog@zipnet.net X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > As John-Mark Gurney wrote: > > > > It's a bad sector. Do you have automatic bad sector remapping enabled? > > > if you enable it do you need to reformat the drive? > > No, you don't. Keep in mind that the data is lost - the drive can't recover it. How much of a problem that is depends on your luck. -- Peter Dufault Real-Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-scsi Tue Jul 16 15:22:35 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA01285 for freebsd-scsi-outgoing; Tue, 16 Jul 1996 15:22:35 -0700 (PDT) Received: from orion.webspan.net (orion.webspan.net [206.154.70.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA01030; Tue, 16 Jul 1996 15:20:10 -0700 (PDT) Received: from localhost (gpalmer@localhost [127.0.0.1]) by orion.webspan.net (8.7.5/8.6.12) with SMTP id SAA03485; Tue, 16 Jul 1996 18:17:45 -0400 (EDT) X-Authentication-Warning: orion.webspan.net: Host gpalmer@localhost [127.0.0.1] didn't use HELO protocol To: Stefan Esser cc: conta@alpo.casc.com (Alex Conta), freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org From: "Gary Palmer" Subject: Re: Adaptec 2940 PCI-SCSI on Compaq ProLinea 5100 In-reply-to: Your message of "Tue, 16 Jul 1996 21:20:08 +0200." <199607161920.VAA00899@x14.mi.uni-koeln.de> Date: Tue, 16 Jul 1996 18:17:45 -0400 Message-ID: <3481.837555465@orion.webspan.net> Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stefan Esser wrote in message ID <199607161920.VAA00899@x14.mi.uni-koeln.de>: > Compaq caused lots of problems because of > their knowingly ignoring the PCI specs. > I once got a reply that it wouldn't matter, > since the BIOS and their drivers worked > around the problems introduced this way. > But what they didn't care about was, that > the required workaround might break support > for other systems. They don't bother, since > they know their drivers are only used with > their machines. But we hardly want to have > a special FreeBSD version just for Compaq > machines ... :) Which is (IMNSHO) is *EXTREMELY* shortshighted of ANY company ... how many ``high end'' OS's rely on the crappy PC bios for I/O? I'm not meaning the M$ stuff, I'm meaning the true UN*X stuff (e.g. Solaris, SCO, FreeBSD. Sorry, maybe I shouldn't have said UN*X :-) ). It basically means that Compaq hardware is limited to running M$ stuff, which is cutting out other people from the game ... has Compaq been bought out by M$, perhaps? :) Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-scsi Tue Jul 16 16:26:37 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA11161 for freebsd-scsi-outgoing; Tue, 16 Jul 1996 16:26:37 -0700 (PDT) Received: from mole.mole.org (marmot.mole.org [204.216.57.191]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA11125; Tue, 16 Jul 1996 16:26:31 -0700 (PDT) Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id XAA28224; Tue, 16 Jul 1996 23:20:12 GMT Received: from meerkat.mole.org(206.197.192.110) by mole.mole.org via smap (V1.3) id sma028222; Tue Jul 16 23:20:12 1996 Received: (from mrm@localhost) by meerkat.mole.org (8.6.11/8.6.9) id QAA21999; Tue, 16 Jul 1996 16:20:11 -0700 Date: Tue, 16 Jul 1996 16:20:11 -0700 From: "M.R.Murphy" Message-Id: <199607162320.QAA21999@meerkat.mole.org> To: gpalmer@FreeBSD.org, se@ZPR.Uni-Koeln.DE Subject: Re: Adaptec 2940 PCI-SCSI on Compaq ProLinea 5100 Cc: conta@alpo.casc.com, freebsd-hardware@FreeBSD.org, freebsd-scsi@FreeBSD.org Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Which is (IMNSHO) is *EXTREMELY* shortshighted of ANY company ... how > many ``high end'' OS's rely on the crappy PC bios for I/O? I'm not > meaning the M$ stuff, I'm meaning the true UN*X stuff (e.g. Solaris, > SCO, FreeBSD. Sorry, maybe I shouldn't have said UN*X :-) ). It > basically means that Compaq hardware is limited to running M$ stuff, > which is cutting out other people from the game ... has Compaq been > bought out by M$, perhaps? :) > (money spent on non-M$ stuff) + (money spent on M$ stuff) --------------------------------------------------------- = 1 (money spent on M$ stuff) More's the pity, but the money talks. That makes it not necessarily shortsighted from a business standpoint :-( The good of it is that there's a driving force for less expensive, more powerful hardware to run M$ (and it's required), and other OS's get to ride the coattails. -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good From owner-freebsd-scsi Tue Jul 16 18:20:04 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA29108 for freebsd-scsi-outgoing; Tue, 16 Jul 1996 18:20:04 -0700 (PDT) Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA29020; Tue, 16 Jul 1996 18:19:59 -0700 (PDT) Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id VAA17988; Tue, 16 Jul 1996 21:19:01 -0400 Received: from centime.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id VAA15504; Tue, 16 Jul 1996 21:20:03 -0400 Received: by centime.cascade (5.x/SMI-SVR4) id AA12607; Tue, 16 Jul 1996 21:20:00 -0400 Date: Tue, 16 Jul 1996 21:20:00 -0400 From: conta@alpo.casc.com (Alex Conta) Message-Id: <9607170120.AA12607@centime.cascade> To: gpalmer@freebsd.org, se@zpr.uni-koeln.de Subject: More on Adaptec 2940 PCI-SCSI on Compaq ProLinea 5100 Cc: freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org, conta@alpo.casc.com X-Sun-Charset: US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Gary wrote: .. > My money is on the Compaq having one of the ``interesting'' Compaq PCI > implimentations which causes our code nightmares. You may want to try > 2.1.5 to see if it has the Compaq fixes in it, if not then -current > does. > > (BTW: the ahc driver doesn't appear to the `-c' boot config. as it's a > PCI device and all necessary information is auto-detected, but *ONLY* > if the PCI bus is detected) > config in "line mode" allows entering commands for it. By the way, the manual - Installing and Running FreeBSD - is in contradiction: at page 7 ahc0 is 294x, and ahc1 is 274x, while at page 165 ahc0 is 274x, and ahc1 is 2940/3940. And then again at page 181, 27dx is ahb0, while 174x is ahc0, and ahc1. At any rate, I learn more about this, as I go along. Some more information related to the PCI problem: I installed the Adaptec PIC-SCSI card into a Compaq DexPro 6200 XL, as a second SCSI adapter, I disabled the embeded SCSI (AMD), and the FreeBSD installation went well so far - I didn't boot yet. What I think is relevant is that 'boot -v' listed this time the following: pcibus_setup(1): mode1res=0x80000000c (0x80000000), mode2res = 0xff (0x0e) as opposed to when it failed: pcibus_setup(1): mode1res=0x80000000c (0x80000000), mode2res = 0x0c (0x0e) It seems that the value 0 of bit 1 causes the failure. 2. > > > Any plans to add support for the AMD SCSI adapter that is embedded with > > Compaq DexPro 6200 XL? > > Not that I am aware of. > Apparently the Compaq's PCI Ethernet (AMD) is recognized but no driver exists. So it looks like a further mismatch between Compaq and FreeBSD. Alex From owner-freebsd-scsi Wed Jul 17 04:20:13 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA01252 for freebsd-scsi-outgoing; Wed, 17 Jul 1996 04:20:13 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA01234 for ; Wed, 17 Jul 1996 04:20:04 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id NAA06722; Wed, 17 Jul 1996 13:12:20 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id NAA02035; Wed, 17 Jul 1996 13:12:20 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id NAA03732; Wed, 17 Jul 1996 13:06:32 +0200 (MET DST) From: J Wunsch Message-Id: <199607171106.NAA03732@uriah.heep.sax.de> Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 To: freebsd-scsi@freebsd.org Date: Wed, 17 Jul 1996 13:06:32 +0200 (MET DST) Cc: jbh@labyrinth.net.au (John Hartley) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607160641.QAA13198@minotaur.labyrinth.net.au> from John Hartley at "Jul 16, 96 04:41:25 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As John Hartley wrote: > >>> Output <<< > > Present Mode: Density = 0x00 Blocksize = 1024 bytes > ---------available modes--------- > Mode 0: Density = 0x00 Blocksize variable > Mode 1: Density = QIC-320 Blocksize variable > Mode 2: Density = QIC-150 Blocksize variable > Mode 3: Density = QIC-120 Blocksize variable Ick. This is weird (and it cannot work this way). Neither this blocksize nor this density will be accepted by the drive. As long as you're getting this, all other attempts are in vaine. However, this looks as if the `rogue' code wouldn't work as expected. (Sorry, i cannot reproduce this, this code has been taken out meanwhile. The entire rogue handling has been moved out to scsiconf.c, that's what is #ifdef NEW_SCSICONF for you.) Something like mt -f /dev/st0ctl.0 blocksize 0 mt -f /dev/st0ctl.0 density 0x15 is the least that must work. Try experimenting with this. > >I wonder whether we should always use the following kludge: > > > >@@ -1530,7 +1530,9 @@ > > scsi_cmd.length = dat_len; > > dat.header.blk_desc_len = sizeof(struct blk_desc); > > dat.header.dev_spec |= SMH_DSP_BUFF_MODE_ON; > >- dat.blk_desc.density = st->density; > >+ dat.blk_desc.density = > >+ st->density? st->density: > >+ 0x7f /* use previous density */; > > if (st->flags & ST_FIXEDBLOCKS) { > > scsi_uto3b(st->blksiz, dat.blk_desc.blklen); > > } > > > > > > > > I didn't try this as the previous test failed!! Hmm, no, if you kill the rogue entry, the above _should_ work nevertheless. (As long as the rogue entry is there, it seems the kernel uses 1024 byte blocksize, but i remember that this wasn't the case before for your drive.) > I guess the question is is what is it that the FreeBSD drivers are doing > that is different from the dos ASPI and Windows NT tape driver??? The BSD driver should perhaps by default not even try to MODE SELECT the drive. That's what it is constantly getting wrong in your case. Look here: > Jul 16 17:09:38 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] > Jul 16 17:09:38 qwiff /kernel: ------------------------------ > Jul 16 17:09:38 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 > Jul 16 17:09:38 qwiff /kernel: ------------------------------ That's the interesting line. It should actually look: > Jul 16 17:09:38 qwiff /kernel: 000: 00 00 10 08 15 00 00 00 00 00 00 00 ^^ ^^ -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Wed Jul 17 12:29:03 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA11760 for freebsd-scsi-outgoing; Wed, 17 Jul 1996 12:29:03 -0700 (PDT) Received: from linux4nn.gn.iaf.nl (root@linux4nn.gn.iaf.nl [193.67.144.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA11754; Wed, 17 Jul 1996 12:28:59 -0700 (PDT) Received: from uni4nn.iaf.nl (root@uni4nn.iaf.nl [193.67.144.33]) by linux4nn.gn.iaf.nl (8.6.9/8.6.9) with SMTP id VAA08165; Wed, 17 Jul 1996 21:30:07 +0200 Received: by uni4nn.iaf.nl with UUCP id AA09544 (5.67b/IDA-1.5); Wed, 17 Jul 1996 21:29:41 +0200 Received: by iafnl.es.iaf.nl with UUCP id AA05601 (5.67b/IDA-1.5); Wed, 17 Jul 1996 20:57:58 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.6.12/8.6.6) id TAA00615; Wed, 17 Jul 1996 19:08:17 +0200 From: Wilko Bulte Message-Id: <199607171708.TAA00615@yedi.iaf.nl> X-Organisation: Private FreeBSD site - Arnhem - The Netherlands Subject: Re: Adaptec 2940 PCI-SCSI on Compaq ProLinea 5100 To: gpalmer@FreeBSD.ORG (Gary Palmer) Date: Wed, 17 Jul 1996 19:08:17 +0200 (MET DST) Cc: se@zpr.uni-koeln.de, conta@alpo.casc.com, freebsd-scsi@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG In-Reply-To: <3481.837555465@orion.webspan.net> from "Gary Palmer" at Jul 16, 96 06:17:45 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Gary Palmer wrote... > > But what they didn't care about was, that > > the required workaround might break support > > for other systems. They don't bother, since > > they know their drivers are only used with > > their machines. But we hardly want to have > > a special FreeBSD version just for Compaq > > machines ... :) > > Which is (IMNSHO) is *EXTREMELY* shortshighted of ANY company ... how > many ``high end'' OS's rely on the crappy PC bios for I/O? I'm not > meaning the M$ stuff, I'm meaning the true UN*X stuff (e.g. Solaris, People get filty rich by just doing mainstream (read: M$ stuff). Why bother with niche markets? It's sad, true... > SCO, FreeBSD. Sorry, maybe I shouldn't have said UN*X :-) ). It > basically means that Compaq hardware is limited to running M$ stuff, > which is cutting out other people from the game ... has Compaq been > bought out by M$, perhaps? :) > > Gary Wilko 'The Devils Attorney' _ ____________________________________________________________________ | / o / / _ Wilko Bulte email: wilko@yedi.iaf.nl |/|/ / / /( (_) Private FreeBSD site - Arnhem - The Netherlands -------------------------------------------------------------------------- From owner-freebsd-scsi Wed Jul 17 20:14:12 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA12795 for freebsd-scsi-outgoing; Wed, 17 Jul 1996 20:14:12 -0700 (PDT) Received: from minotaur.labyrinth.net.au (minotaur.labyrinth.net.au [203.9.148.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA12781 for ; Wed, 17 Jul 1996 20:13:55 -0700 (PDT) Received: (from mail@localhost) by minotaur.labyrinth.net.au (8.7.2/8.7.2) id NAA07553 for ; Thu, 18 Jul 1996 13:13:47 +1000 (EST) Date: Thu, 18 Jul 1996 13:13:47 +1000 (EST) Message-Id: <199607180313.NAA07553@minotaur.labyrinth.net.au> X-Authentication-Warning: minotaur.labyrinth.net.au: mail set sender to using -f Received: from portal-as3.labyrinth.net.au(203.9.148.13) by minotaur.labyrinth.net.au via smap (V1.3) id sma007544; Thu Jul 18 13:13:42 1996 X-Sender: jbh@labyrinth.net.au (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-scsi@freebsd.org From: John Hartley Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 13:06 17/07/96 +0200, you wrote: > >Ick. This is weird (and it cannot work this way). Neither this >blocksize nor this density will be accepted by the drive. As long as >you're getting this, all other attempts are in vaine. > >However, this looks as if the `rogue' code wouldn't work as expected. >(Sorry, i cannot reproduce this, this code has been taken out >meanwhile. The entire rogue handling has been moved out to >scsiconf.c, that's what is #ifdef NEW_SCSICONF for you.) > >Something like > > mt -f /dev/st0ctl.0 blocksize 0 > mt -f /dev/st0ctl.0 density 0x15 Tried lots of these but no luck. Also I think that this is kind of dangerous. What is I change the type of tape I put into the drive? Surely dealing with what media I put into the drive should be a function of the tape drive and not the controlling software... > >is the least that must work. Try experimenting with this. > >> >I wonder whether we should always use the following kludge: >> > >> >@@ -1530,7 +1530,9 @@ >> > scsi_cmd.length = dat_len; >> > dat.header.blk_desc_len = sizeof(struct blk_desc); >> > dat.header.dev_spec |= SMH_DSP_BUFF_MODE_ON; >> >- dat.blk_desc.density = st->density; >> >+ dat.blk_desc.density = >> >+ st->density? st->density: >> >+ 0x7f /* use previous density */; >> > if (st->flags & ST_FIXEDBLOCKS) { >> > scsi_uto3b(st->blksiz, dat.blk_desc.blklen); >> > } >> > >> > >> > >> >> I didn't try this as the previous test failed!! > >Hmm, no, if you kill the rogue entry, the above _should_ work >nevertheless. (As long as the rogue entry is there, it seems the >kernel uses 1024 byte blocksize, but i remember that this wasn't the >case before for your drive.) > I tried this code but still got the problems..... >> I guess the question is is what is it that the FreeBSD drivers are doing >> that is different from the dos ASPI and Windows NT tape driver??? > >The BSD driver should perhaps by default not even try to MODE SELECT >the drive. That's what it is constantly getting wrong in your case. >Look here: > >> Jul 16 17:09:38 qwiff /kernel: st0(ahc0:2:0): command: 15,0,0,0,c,0-[12 bytes] >> Jul 16 17:09:38 qwiff /kernel: ------------------------------ >> Jul 16 17:09:38 qwiff /kernel: 000: 00 00 10 08 00 00 00 00 00 00 04 00 >> Jul 16 17:09:38 qwiff /kernel: ------------------------------ > >That's the interesting line. It should actually look: > >> Jul 16 17:09:38 qwiff /kernel: 000: 00 00 10 08 15 00 00 00 00 00 00 00 > ^^ ^^ In a desperate attempt to get the drive up and running I #defined out the entire st_mode_select section of code, as this seemed to be where all the errors were coming from. Also I considered that mechanism as very fragile in that it allowed no leeway in how the driver "talked" to the tape drive. I guess my idea about it was, I ask the tape to read/write a stream of data, I don't care or want to know how it choices to do this. It a smart fellow it will work something out.... ;-) The following is the modified code!!!! errval st_mode_select(unit, flags, page, pagelen) u_int32 unit, flags; struct tape_pages *page; u_int32 pagelen; { #define MAJOR_HACK_JBH #ifdef MAJOR_HACK_JBH return(0); #else u_int32 dat_len; struct scsi_mode_select scsi_cmd; struct { struct scsi_mode_header header; struct blk_desc blk_desc; struct tape_pages page; } dat; struct scsi_link *sc_link = SCSI_LINK(&st_switch, unit); struct scsi_data *st = sc_link->sd; /* * Check if we need to use a default page.. * Gee, hope we saved one before now........ */ if ((st->quirks & ST_Q_NEEDS_PAGE_0) && (!page)) { pagelen = PAGE_0_SENSE_DATA_SIZE; page = (struct tape_pages *) st->saved_page0; } /* * Now work out the total dat size etc. */ dat_len = sizeof(struct scsi_mode_header) + sizeof(struct blk_desc) + (page ? pagelen : 0); /* * Set up for a mode select */ bzero(&dat, dat_len); bzero(&scsi_cmd, sizeof(scsi_cmd)); scsi_cmd.op_code = MODE_SELECT; scsi_cmd.length = dat_len; dat.header.blk_desc_len = sizeof(struct blk_desc); dat.header.dev_spec |= SMH_DSP_BUFF_MODE_ON; #ifdef ST_TEST_NONE dat.blk_desc.density = st->density; #else /* Test case */ dat.blk_desc.density = st->density ? st->density : 0x7f /* use previous density */; #endif if (st->flags & ST_FIXEDBLOCKS) { scsi_uto3b(st->blksiz, dat.blk_desc.blklen); } if (page) { bcopy(page, &dat.page, pagelen); /* the Tandberg tapes need the block size to */ /* be set on each mode sense/select. */ } /* * do the command */ return (scsi_scsi_cmd(sc_link, (struct scsi_generic *) &scsi_cmd, sizeof(scsi_cmd), (u_char *) &dat, dat_len, ST_RETRIES, 5000, NULL, flags | SCSI_DATA_OUT)); #endif } Result..... Success at last....!!!! The tape now writes and reads... I then popped out the 1.2 GB cartridge and put in an old QIC-150 (150 MB) cartridge, with some tar file on it. It read the tape no problems. Obviously the drive was being very dumb in its negotiation, but very smart in its area of strength (reading and writing). I not sure what you think of this HACK, but it does work... Thanks a lot for all your help (J"org). As you say never trust an operating system you don't have sources for... Cheers. John Hartley. From owner-freebsd-scsi Thu Jul 18 01:26:56 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA04386 for freebsd-scsi-outgoing; Thu, 18 Jul 1996 01:26:56 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA04225 for ; Thu, 18 Jul 1996 01:24:27 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA12485; Thu, 18 Jul 1996 10:21:41 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA18529; Thu, 18 Jul 1996 10:21:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id KAA04086; Thu, 18 Jul 1996 10:20:44 +0200 (MET DST) From: J Wunsch Message-Id: <199607180820.KAA04086@uriah.heep.sax.de> Subject: Re: tandberg scsi tape + FreeBSD 2.1/2.0.5 To: freebsd-scsi@freebsd.org Date: Thu, 18 Jul 1996 10:20:43 +0200 (MET DST) Cc: jbh@labyrinth.net.au (John Hartley) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607180313.NAA07553@minotaur.labyrinth.net.au> from John Hartley at "Jul 18, 96 01:13:47 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As John Hartley wrote: > In a desperate attempt to get the drive up and running I #defined out the > entire st_mode_select section of code, as this seemed to be where all the > errors were coming from. Also I considered that mechanism as very > fragile in that it allowed no leeway in how the driver "talked" to the > tape drive. > I guess my idea about it was, I ask the tape to read/write a stream of data, > I don't care or want to know how it choices to do this. It a smart fellow > it will work something out.... ;-) I also wonder why the code is generally attempting to MODE SELECT the drive (and i've been asked by somebody who's been hacking SCSI on an old SVR4 why he never needed a ``rogues gallery'' while we do). Julian? What's the reasoning behind this??? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Thu Jul 18 10:18:11 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03564 for freebsd-scsi-outgoing; Thu, 18 Jul 1996 10:18:11 -0700 (PDT) Received: from rzcomm1.rz.tu-bs.de (rzcomm1.rz.tu-bs.de [134.169.9.107]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA03559 for ; Thu, 18 Jul 1996 10:18:08 -0700 (PDT) Received: from rzrtr1.rz.tu-bs.de by rzcomm1.rz.tu-bs.de with SMTP (1.38.193.4/16.2) id AA02938; Thu, 18 Jul 1996 19:14:01 +0200 Received: by rzrtr1.rz.tu-bs.de (AIX 4.1/UCB 5.64/4.03) id AA79038; Thu, 18 Jul 1996 19:17:49 +0200 From: y0002257@ws.rz.tu-bs.de (Sven Brandenburg) Message-Id: <9607181717.AA79038@rzrtr1.rz.tu-bs.de> Subject: turning off scsi disks To: freebsd-scsi@freebsd.org Date: Thu, 18 Jul 1996 19:17:48 +0200 (MET_DST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, daemon folks! I hope this isn't FAQ or already in progress - but I wonder whether it is possible to turn off a scsi harddisk automatically after a certain time of no operation - recent ide drives can handle this. I know, *SOME* older scsi drives knew a vendor specific command which performed the same - but I tried this with my (newer) harddisks and it didn4t work :-( My question is: Can someone help me to find out the *RIGHT* scsi commands for my disks or is there some code in the scsi/filesystem stuff that I missed? I suppose turning off a scsi harddisk with the scsi(8) command and START/STOPUNIT crashes the whole system rather than reducing noise ;-) My configuration P100, NCR825 with ST31230N and Q Fireball on narrow cable running 2.1R. If it helps tell me to be more specific. ANY suggestions are welcome. Fare You Well! ---- I will not trust you, I, Nor longer stay in your company. Your hands than mine are quicker for a fray: My legs are longer though, to run away. William Shakespeare, A Midsummer Night`s Dream, 1596 From owner-freebsd-scsi Thu Jul 18 12:21:04 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA10504 for freebsd-scsi-outgoing; Thu, 18 Jul 1996 12:21:04 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA10499 for ; Thu, 18 Jul 1996 12:21:00 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA05495 for ; Thu, 18 Jul 1996 21:20:58 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA27040 for freebsd-scsi@freebsd.org; Thu, 18 Jul 1996 21:20:57 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id VAA06840 for freebsd-scsi@freebsd.org; Thu, 18 Jul 1996 21:03:45 +0200 (MET DST) From: J Wunsch Message-Id: <199607181903.VAA06840@uriah.heep.sax.de> Subject: CD driver To: freebsd-scsi@freebsd.org Date: Thu, 18 Jul 1996 21:03:45 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all, i'm currently playing with some improvements to the (SCSI) CD driver. I've got the first prototype of multi-track support already running, and have been playing a little with CD-DA. (Sheesh, i should really get a soundcard, i guess. :) Alas, it seems that each vendor picked a different method to allow digital reading of CD-DA tracks. The SCSI-2 specs made the IMHO big mistake to forbid reading these data with a regular READ command. (The drive _must_ return BLANK CHECK / Illegal mode for this track when attempting to read CD-DA data.) So now, some of the vendors apparently enable it by using a vendor-specific `density code' in the MODE SELECT block descriptor (0x82, applicable to at least the Toshiba 3401 and higher), followed by a regular read. Other drives seem to use a specific command (0xd8) that is similar to READ(12) but reads audio data (reported for Plextor, my Toshiba 3401 can also do this, but, the Toshiba 3501 rejects it). I didn't find anything specific in the CD-R writer specs for my Plasmon, so i assume it can read them regularly (perhaps requires a MODE SELECT with a block size of 2352 before, i have to test this). The big question now is how to place the hooks in the CD driver that allow for the various methods, and how to assign/enable the hooks. They must be applicable to each device separately, since it's certainly possible that someone has two or more different drives. I thought of using LKM's for it, but think this will be difficult for multiple different drives. While we are at it, does anybody know of other methods to enable CD-DA? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Thu Jul 18 12:36:31 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA11259 for freebsd-scsi-outgoing; Thu, 18 Jul 1996 12:36:31 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA11254; Thu, 18 Jul 1996 12:36:29 -0700 (PDT) Message-Id: <199607181936.MAA11254@freefall.freebsd.org> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: freebsd-scsi@FreeBSD.ORG Subject: Re: CD driver In-reply-to: Your message of "Thu, 18 Jul 1996 21:03:45 +0200." <199607181903.VAA06840@uriah.heep.sax.de> Date: Thu, 18 Jul 1996 12:36:29 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just FYI, I have ~50,000 lines of context diffs for the SCSI system (and drivers) at present. I hope to check in tomorrow, but the changes will definitely affect your work. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Thu Jul 18 12:51:42 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA12098 for freebsd-scsi-outgoing; Thu, 18 Jul 1996 12:51:42 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA12089 for ; Thu, 18 Jul 1996 12:51:39 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id VAA06341; Thu, 18 Jul 1996 21:51:08 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id VAA27545; Thu, 18 Jul 1996 21:51:07 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id VAA07196; Thu, 18 Jul 1996 21:43:27 +0200 (MET DST) From: J Wunsch Message-Id: <199607181943.VAA07196@uriah.heep.sax.de> Subject: Re: turning off scsi disks To: freebsd-scsi@freebsd.org Date: Thu, 18 Jul 1996 21:43:27 +0200 (MET DST) Cc: y0002257@ws.rz.tu-bs.de (Sven Brandenburg) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9607181717.AA79038@rzrtr1.rz.tu-bs.de> from Sven Brandenburg at "Jul 18, 96 07:17:48 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Sven Brandenburg wrote: > I suppose turning off a scsi harddisk with the scsi(8) command and > START/STOPUNIT crashes the whole system rather than reducing noise > ;-) You can turn it off while it's not opened. The hooks for turning it on are already in place (they need to go a couple of lines above in order to work correctly). I'm actually doing this with my MO drive in the `od' driver, to avoid heat generation and laser and mechanics abration while it's not being mounted. Making it spin down while being idle would require additional timers in the driver, but should not be undoable. However, the hook to turn it on must be moved into the sdstart routine then (perhaps activated by some additonal flag in the sd_data structure that is being set by the timeout handler when spinning it down). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Thu Jul 18 15:15:46 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA23155 for freebsd-scsi-outgoing; Thu, 18 Jul 1996 15:15:46 -0700 (PDT) Received: from linux4nn.gn.iaf.nl (root@linux4nn.gn.iaf.nl [193.67.144.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA23146 for ; Thu, 18 Jul 1996 15:15:42 -0700 (PDT) Received: from uni4nn.iaf.nl (root@uni4nn.iaf.nl [193.67.144.33]) by linux4nn.gn.iaf.nl (8.6.9/8.6.9) with SMTP id AAA12503; Fri, 19 Jul 1996 00:17:01 +0200 Received: by uni4nn.iaf.nl with UUCP id AA09303 (5.67b/IDA-1.5); Fri, 19 Jul 1996 00:16:31 +0200 Received: by iafnl.es.iaf.nl with UUCP id AA22786 (5.67b/IDA-1.5); Thu, 18 Jul 1996 23:36:25 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.6.12/8.6.6) id XAA02887; Thu, 18 Jul 1996 23:04:03 +0200 From: Wilko Bulte Message-Id: <199607182104.XAA02887@yedi.iaf.nl> X-Organisation: Private FreeBSD site - Arnhem - The Netherlands Subject: Re: turning off scsi disks To: y0002257@ws.rz.tu-bs.de (Sven Brandenburg) Date: Thu, 18 Jul 1996 23:04:02 +0200 (MET DST) Cc: freebsd-scsi@freebsd.org In-Reply-To: <9607181717.AA79038@rzrtr1.rz.tu-bs.de> from "Sven Brandenburg" at Jul 18, 96 07:17:48 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Sven Brandenburg wrote... > I hope this isn't FAQ or already in progress - > but I wonder whether it is possible to turn off a scsi harddisk > automatically after a certain time of no operation - recent ide drives can > handle this. > > I know, *SOME* older scsi drives knew a vendor specific command which performed > the same - but I tried this with my (newer) harddisks and it didn4t work :-( > > My question is: > Can someone help me to find out the *RIGHT* scsi commands for my disks > or START/STOP unit should do it. > I suppose turning off a scsi harddisk with the scsi(8) command and START/STOPUNIT > crashes the whole system rather than reducing noise ;-) You better be a bit careful with this. The very nice MTBF figures we see these days are definitely not spec'ed by a system turning the drive on/off every couple of minutes. At least not if the drive was not designed for this. E.g. laptop drives even have 'parking ramps' to lay their heads to rest ;-) Wilko _ ____________________________________________________________________ | / o / / _ Wilko Bulte email: wilko@yedi.iaf.nl |/|/ / / /( (_) Private FreeBSD site - Arnhem - The Netherlands -------------------------------------------------------------------------- From owner-freebsd-scsi Thu Jul 18 17:12:46 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA01923 for freebsd-scsi-outgoing; Thu, 18 Jul 1996 17:12:46 -0700 (PDT) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA01918 for ; Thu, 18 Jul 1996 17:12:42 -0700 (PDT) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA14305; Fri, 19 Jul 96 02:17:21 +0100 Date: Fri, 19 Jul 96 02:17:21 +0100 Message-Id: <9607190117.AA14305@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-scsi@freebsd.org In-Reply-To: <199607181903.VAA06840@uriah.heep.sax.de> (message from J Wunsch on Thu, 18 Jul 1996 21:03:45 +0200 (MET DST)) Subject: Re: CD driver X-Mailer: Emacs Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> J Wunsch writes: > Hi all, > i'm currently playing with some improvements to the (SCSI) CD driver. > I've got the first prototype of multi-track support already running, > and have been playing a little with CD-DA. (Sheesh, i should really > get a soundcard, i guess. :) Oh you will need to fix the sound drivers too :-) I don't know if there is a mainboard/soundcard/driver-version able to play 16bit/44.1KHz sound. I had some success 1 year ago with a pas16, but I am sure you will have problems with -current and a GUS max :-( > Alas, it seems that each vendor picked a different method to allow > digital reading of CD-DA tracks. The SCSI-2 specs made the IMHO big > mistake to forbid reading these data with a regular READ command. > (The drive _must_ return BLANK CHECK / Illegal mode for this track > when attempting to read CD-DA data.) So now, some of the vendors > apparently enable it by using a vendor-specific `density code' in the > MODE SELECT block descriptor (0x82, applicable to at least the Toshiba > 3401 and higher), followed by a regular read. Other drives seem to > use a specific command (0xd8) that is similar to READ(12) but reads > audio data (reported for Plextor, my Toshiba 3401 can also do this, > but, the Toshiba 3501 rejects it). I didn't find anything specific in > the CD-R writer specs for my Plasmon, so i assume it can read them > regularly (perhaps requires a MODE SELECT with a block size of 2352 > before, i have to test this). > The big question now is how to place the hooks in the CD driver that > allow for the various methods, and how to assign/enable the hooks. > They must be applicable to each device separately, since it's > certainly possible that someone has two or more different drives. I > thought of using LKM's for it, but think this will be difficult for > multiple different drives. And it may happen that some drives forbid totally CD-DA. I think you need to select the method according to the drive identification and then to have a manufacturer/model -> method table somewhere. > While we are at it, does anybody know of other methods to enable > CD-DA? I have (had? - I have not tested it for a long time) CD-DA working with my sony drives, using the 0xd9 scsi command. I implemented it with an additional ioctl. > -- > cheers, J"org > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-scsi Fri Jul 19 00:21:12 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA11255 for freebsd-scsi-outgoing; Fri, 19 Jul 1996 00:21:12 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA11242 for ; Fri, 19 Jul 1996 00:20:51 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA26835 for ; Fri, 19 Jul 1996 09:20:41 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA06431 for freebsd-scsi@freebsd.org; Fri, 19 Jul 1996 09:20:40 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id IAA03008 for freebsd-scsi@freebsd.org; Fri, 19 Jul 1996 08:56:55 +0200 (MET DST) From: J Wunsch Message-Id: <199607190656.IAA03008@uriah.heep.sax.de> Subject: Re: CD driver To: freebsd-scsi@freebsd.org Date: Fri, 19 Jul 1996 08:56:55 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9607190117.AA14305@cabri.obs-besancon.fr> from Jean-Marc Zucconi at "Jul 19, 96 02:17:21 am" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Jean-Marc Zucconi wrote: > > and have been playing a little with CD-DA. (Sheesh, i should really > > get a soundcard, i guess. :) > > Oh you will need to fix the sound drivers too :-) I don't know if > there is a mainboard/soundcard/driver-version able to play > 16bit/44.1KHz sound. Hmm, i'm rather interested in hearing anything at all. Right now, i've been using pcaudio... sounds terrible, of course. :) > And it may happen that some drives forbid totally CD-DA. I think you Yes, of course. Early SCSI drives are too eager in following the specs. I'm not sure whether the SCSI specificators had copy protection in mind, or whether they deemed it not useful to process the sounds digitally, but i believe it required a certain pressure from the industry before the vendors implemented this feature. (I remember that our old Indys came with a Toshiba 3401 and used this feature, while the 3301 cannot do it.) > need to select the method according to the drive identification and > then to have a manufacturer/model -> method table somewhere. But this will require kernel hacking to add a clone drive of a different vendor which behaves identical to something that's already known. One rogue's table (for the tape drives) is already one too much... when it comes to maintain it. Now, if you think of Toshiba cycling their model numbers four times a year: ick! Perhaps a vendor-based selection would already suffice? (Yep, it will fail for a Toshiba 3301, but there's not a big problem since the owner of such an old drive cannot get it to read CD-DA in any way, so it's only slightly more broken than special-casing this ``too old'' case.) > > While we are at it, does anybody know of other methods to enable > > CD-DA? > > I have (had? - I have not tested it for a long time) CD-DA working > with my sony drives, using the 0xd9 scsi command. I implemented it > with an additional ioctl. 0xd9? Sheesh. Yet another one... What is it? The same parameter list as 0xa8 (READ(12))? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Fri Jul 19 06:39:38 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA26257 for freebsd-scsi-outgoing; Fri, 19 Jul 1996 06:39:38 -0700 (PDT) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA26251 for ; Fri, 19 Jul 1996 06:39:35 -0700 (PDT) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA18664; Fri, 19 Jul 96 15:36:09 +0100 Date: Fri, 19 Jul 96 15:36:09 +0100 Message-Id: <9607191436.AA18664@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-scsi@freebsd.org In-Reply-To: <199607190656.IAA03008@uriah.heep.sax.de> (message from J Wunsch on Fri, 19 Jul 1996 08:56:55 +0200 (MET DST)) Subject: Re: CD driver X-Mailer: Emacs Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> J Wunsch writes: > 0xd9? Sheesh. Yet another one... What is it? The same parameter > list as 0xa8 (READ(12))? Here is how I do it: #define READ_DIGITAL_AUDIO 0xd9 /* cdrom read digital audio */ struct scsi_read_digitalaudio { u_char op_code; u_char :5; u_char lun:3; u_char unused1; u_char start_m; u_char start_s; u_char start_f; u_char unused2; u_char end_m; u_char end_s; u_char end_f; u_char subcode; u_char control; }; /* * Read Digital Audio */ #ifdef CD_DA static errval cd_read_digital_audio (u_int32_t unit, int start_m, int start_s, int start_f, int end_m, int end_s,int end_f, u_char *data, int len) { struct scsi_read_digitalaudio scsi_cmd; bzero((struct scsi_generic *)&scsi_cmd,sizeof(scsi_cmd)); scsi_cmd.op_code = READ_DIGITAL_AUDIO; scsi_cmd.start_m = start_m; scsi_cmd.start_s = start_s; scsi_cmd.start_f = start_f; scsi_cmd.end_m = end_m; scsi_cmd.end_s = end_s; scsi_cmd.end_f = end_f; return scsi_scsi_cmd(SCSI_LINK(&cd_switch, unit), (struct scsi_generic *)&scsi_cmd, sizeof(struct scsi_read_digitalaudio), data, len, CDRETRIES, 20000, NULL, SCSI_DATA_IN); } #endif /* CD_DA */ Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-scsi Fri Jul 19 07:26:21 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA28243 for freebsd-scsi-outgoing; Fri, 19 Jul 1996 07:26:21 -0700 (PDT) Received: from rzcomm1.rz.tu-bs.de (rzcomm1.rz.tu-bs.de [134.169.9.107]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA28228 for ; Fri, 19 Jul 1996 07:26:04 -0700 (PDT) Received: from rzrtr1.rz.tu-bs.de by rzcomm1.rz.tu-bs.de with SMTP (1.38.193.4/16.2) id AA08872; Fri, 19 Jul 1996 16:22:02 +0200 Received: by rzrtr1.rz.tu-bs.de (AIX 4.1/UCB 5.64/4.03) id AA78962; Fri, 19 Jul 1996 16:25:40 +0200 From: y0002257@ws.rz.tu-bs.de (Sven Brandenburg) Message-Id: <9607191425.AA78962@rzrtr1.rz.tu-bs.de> Subject: Re: turning off scsi disks To: freebsd-scsi@FreeBSD.org Date: Fri, 19 Jul 1996 16:25:39 +0200 (MET_DST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Above all thanks for your answers, Wilko Bulte writes: > You better be a bit careful with this. The very nice MTBF figures we > see these days are definitely not spec'ed by a system turning the > drive on/off every couple of minutes. At least not if the drive > was not designed for this. Well, apart from the fact that repeated spindown of your disks doesnīt really *increase* the MTBF I would like to have the possibility of doing so! My problem is not having the harddisks run while working - They do not have to spin down every minute - I want to turn them off when there`s no load what so ever. Therefore the time before a disk receives its STOP unit should be well over five (maybe ten) minutes without disk activity - so these occasions are presumably very rare when working. (Which then shouldnīt decrease MTBF that much.) I would be entirely happy to let the disks do this on their own - without the need to hack the sources. There are older disks who implemented such a feature but unfortunately I donīt know whether my disks have such nice thing nor how to activate it - all I know is that it works for an old 40Meg Quantum disk - There was a short front end running on the Amiga which allowed to set the spin off time and to make a decision whether to put this information permanently onto the disk or just until reboot. When saved permanently the harddisk would turn off after that given time - even after switching the scsi host and system. I want to have exactly this! J. Wunsch wrote: > Making it spin down while being idle would require additional timers > in the driver, but should not be undoable. However, the hook to turn > it on must be moved into the sdstart routine then (perhaps activated > by some additonal flag in the sd_data structure that is being set by > the timeout handler when spinning it down). When do we start working on it ;-) As you may have noticed I am new to FreeBSD (not to computers, though) and canīt imagine how much work this could be (shame on me - Iīve never taken a look on the related sources.. I will do right now..) BUT: Am am willing to learn! :-) Thank you very much for your time. ---- I will not trust you, I, Nor longer stay in your company. Your hands than mine are quicker for a fray: My legs are longer though, to run away. William Shakespeare, A Midsummer Night`s Dream, 1596 From owner-freebsd-scsi Fri Jul 19 09:56:04 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA07721 for freebsd-scsi-outgoing; Fri, 19 Jul 1996 09:56:04 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA07692 for ; Fri, 19 Jul 1996 09:55:58 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id SAA20949; Fri, 19 Jul 1996 18:54:32 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA14308; Fri, 19 Jul 1996 18:54:31 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id SAA01264; Fri, 19 Jul 1996 18:45:41 +0200 (MET DST) From: J Wunsch Message-Id: <199607191645.SAA01264@uriah.heep.sax.de> Subject: Re: turning off scsi disks To: freebsd-scsi@freebsd.org Date: Fri, 19 Jul 1996 18:45:41 +0200 (MET DST) Cc: y0002257@ws.rz.tu-bs.de (Sven Brandenburg) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9607191425.AA78962@rzrtr1.rz.tu-bs.de> from Sven Brandenburg at "Jul 19, 96 04:25:39 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Sven Brandenburg wrote: > > Making it spin down while being idle would require additional timers > > in the driver, but should not be undoable. [...] > When do we start working on it ;-) You've got the source. You can start today if you want. :) > As you may have noticed I am new to FreeBSD (not to computers, though) > and canīt imagine how much work this could be (shame on me - Iīve never > taken a look on the related sources.. I will do right now..) /sys/scsi/sd.c is the driver file. Watch out the usage of the function scsi_start_unit(). In FreeBSD-current, there is even a man page now for timeout(9) explaining the kernel timer handling. This should be almost all you need for playing. You can also have a look at /sys/scsi/od.c, remember, my od does already spin down at close() time. (It's a compile-time option, to be moved out into an ioctl some day.) You can perhaps start with a fixed timeout first, but should consider an ioctl to adjust it later. This will most likely require some utility like sdcontrol(8) then. You should also read the chapter about kernel debugging in the handbook. Single-stepping some functions, or tweaking some kernel variable comes extremely handy sometimes. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Fri Jul 19 09:56:50 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA07780 for freebsd-scsi-outgoing; Fri, 19 Jul 1996 09:56:50 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA07770 for ; Fri, 19 Jul 1996 09:56:45 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id SAA20954; Fri, 19 Jul 1996 18:54:34 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id SAA14312; Fri, 19 Jul 1996 18:54:33 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id SAA01276; Fri, 19 Jul 1996 18:48:19 +0200 (MET DST) From: J Wunsch Message-Id: <199607191648.SAA01276@uriah.heep.sax.de> Subject: Re: CD driver To: freebsd-scsi@freebsd.org Date: Fri, 19 Jul 1996 18:48:18 +0200 (MET DST) Cc: jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9607191436.AA18664@cabri.obs-besancon.fr> from Jean-Marc Zucconi at "Jul 19, 96 03:36:09 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Jean-Marc Zucconi wrote: > > 0xd9? Sheesh. Yet another one... What is it? The same parameter > > list as 0xa8 (READ(12))? > > Here is how I do it: > #define READ_DIGITAL_AUDIO 0xd9 /* cdrom read digital audio */ > > struct scsi_read_digitalaudio > { > u_char op_code; > u_char :5; > u_char lun:3; > u_char unused1; > u_char start_m; > u_char start_s; > u_char start_f; > u_char unused2; > u_char end_m; > u_char end_s; > u_char end_f; > u_char subcode; > u_char control; > }; Ah, so this looks like a READ AUDIO MSF command. 0xd8 is a READ AUDIO LBA (with the exact same parameter list as 0xa8 -- READ(12)). Can you perchance test whether your drive would also grok the 0xd8 one? (Btw., what's the `subcode' field for?) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Fri Jul 19 15:14:03 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA22864 for freebsd-scsi-outgoing; Fri, 19 Jul 1996 15:14:03 -0700 (PDT) Received: from orthanc.jrw.org (jr@cronus.pacificorp.com [131.219.211.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA22859 for ; Fri, 19 Jul 1996 15:14:00 -0700 (PDT) Received: (from jr@localhost) by orthanc.jrw.org (8.7.3/8.6.9) id QAA00607 for freebsd-scsi@freebsd.org; Fri, 19 Jul 1996 16:14:21 -0600 (MDT) From: "J.R. Westmoreland" Message-Id: <199607192214.QAA00607@orthanc.jrw.org> Subject: Multi-session CD support To: freebsd-scsi@freebsd.org Date: Fri, 19 Jul 1996 16:14:19 -0600 (MDT) Reply-To: jr@jrw.org X-Phone: (801) 546-3254 X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there currently any support for the multi-session CD yet? If so, what release? If not, has anyone done anything yet? -- J.R. Westmoreland E-mail: jr@jrw.org Callsign: N7MFF Phone: work: (801) 220-4784 fax: (801) 220-4412 home: (801) 546-3254 Address: J.R. Westmoreland 1456 E. Hilda Dr. Fruit Heights, UT 84037 From owner-freebsd-scsi Fri Jul 19 16:21:12 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA25465 for freebsd-scsi-outgoing; Fri, 19 Jul 1996 16:21:12 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA25451 for ; Fri, 19 Jul 1996 16:21:08 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id BAA29675; Sat, 20 Jul 1996 01:20:46 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id BAA20246; Sat, 20 Jul 1996 01:20:45 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id AAA01507; Sat, 20 Jul 1996 00:53:37 +0200 (MET DST) From: J Wunsch Message-Id: <199607192253.AAA01507@uriah.heep.sax.de> Subject: Re: Multi-session CD support To: freebsd-scsi@freebsd.org Date: Sat, 20 Jul 1996 00:53:36 +0200 (MET DST) Cc: jr@jrw.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199607192214.QAA00607@orthanc.jrw.org> from "J.R. Westmoreland" at "Jul 19, 96 04:14:19 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As J.R. Westmoreland wrote: > Is there currently any support for the multi-session CD yet? > If so, what release? If not, has anyone done anything yet? You're getting too fast. :) You've just been asking me in a personal mail about this... Multi-track, yes. The session is irrelevant, i think (who cares from which session the tracks are, as long as you can access all of them?). I can dump you over my current working source for 2.2-current if you want. It is subject to radical changes, it's basically just there to get a feeling for the problems. But it basically `works'. (The diff is currently 420 lines / 11 KB.) 73 de -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Fri Jul 19 18:17:14 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA01352 for freebsd-scsi-outgoing; Fri, 19 Jul 1996 18:17:14 -0700 (PDT) Received: from mail.vcnet.com (ns1.vcnet.com [205.228.248.15]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA01347 for ; Fri, 19 Jul 1996 18:17:11 -0700 (PDT) Received: from [205.228.248.22] by mail.vcnet.com (post.office MTA v1.9.3b ID# 0-13499) with ESMTP id AAA5747 for ; Fri, 19 Jul 1996 18:16:48 -0700 X-Sender: jon@mail.vcnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Header: VCNet 805-383-3500 Date: Fri, 19 Jul 1996 18:17:19 -0700 To: freebsd-scsi@freebsd.org From: jon@vcnet.com (Jon Rust) Subject: 2940 and large drives Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk First try: Installing freebsd over my old linux disks (2gig conner and 4 gig seagate). The fdisk/diaklabeler part of the install process complains that the geometry on the drives is hosed. So I hit the G key, and let FreeBSD pick the geometry. It hoses up my drives completely, and I have to do a low level format before the drives are useful again. The install script aborts when it tries to make a new fs on the hosed-up drives. Second try: Ignored the message this time about bad geometry (after doing a low level format on the drives). The install completes okay. Upon reboot I get a message about "there is a drive larger than 1 gig with a 64 head/ 32 sector partitioning which is not compatable with the 255 head/ 63 sector translation setting on this card. Data could be corrupted. Hit any key to .....". After hitting any key, the system comes up okay, but this obviously is bad, as evidenced by my daily crashes where the computer reboots itself! Third try: I turn OFF the option in the Adaptec for "extended BIOS for DOS-drives larger than 1 gig" figuring maybe that option is ONLY for DOS drives. I don't get the error messages any more, but it's only been running for a few hours. Could that be the fix? Can anyone help me understand what's happening here? Linux never gave me these problems (using a 1540cf) with the same drives. Also, what's the recommended process for adding scsi drives (formatting them, partitioning them and making the new fs's)? The man page for fdisk is pretty tough to follow, and disklabel's is even worse. Pointers to FAQs with this info would be great as FreeBSD's site is missing this part. Thanks, Jon <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Jon Rust VCNet For info, call us or email to 805.383.3500 info@vcnet.com PGP Fingerprint = 58 55 6C 46 4C 2B 7E 65 BB 35 AB 02 E1 27 73 7B "African swallows maybe, but not a European swallow. That's my point." <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> From owner-freebsd-scsi Sat Jul 20 00:21:05 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA21709 for freebsd-scsi-outgoing; Sat, 20 Jul 1996 00:21:05 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA21697 for ; Sat, 20 Jul 1996 00:21:02 -0700 (PDT) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id JAA12077; Sat, 20 Jul 1996 09:20:56 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id JAA25695; Sat, 20 Jul 1996 09:20:55 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA03287; Sat, 20 Jul 1996 09:16:06 +0200 (MET DST) From: J Wunsch Message-Id: <199607200716.JAA03287@uriah.heep.sax.de> Subject: Re: 2940 and large drives To: freebsd-scsi@freebsd.org Date: Sat, 20 Jul 1996 09:16:06 +0200 (MET DST) Cc: jon@vcnet.com (Jon Rust) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from Jon Rust at "Jul 19, 96 06:17:19 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (This should have gone to freebsd-questions@freebsd.org.) As Jon Rust wrote: > the geometry. It hoses up my drives completely, and I have to do a low > level format before the drives are useful again. The install script aborts > when it tries to make a new fs on the hosed-up drives. Uh-oh, i hope you didn't _actually_ low-level format the drive. Low-level formatting a SCSI drive is something you only need if you have to reorganize the bad sector replacement table. All other cases are perfectly covered by either simply reinstalling and ignoring the pre-existing data, or at least by wiping out the first few blocks with zeros. > Ignored the message this time about bad geometry (after doing a low level > format on the drives). The install completes okay. Upon reboot I get a > message about "there is a drive larger than 1 gig with a 64 head/ 32 sector > partitioning which is not compatable with the 255 head/ 63 sector > translation setting on this card. Data could be corrupted. Hit any key to > .....". FreeBSD won't corrupt any data in this case, but might have problems to boot at all. Your system booted, so this was not a problem. > After hitting any key, the system comes up okay, but this obviously > is bad, as evidenced by my daily crashes where the computer reboots itself! Yeah, and herein lies the problem. You forgot to tell us how it crashes and what exactly happens. How should we know _why_ your machine crashed if your only sentence about it is ``daily crashes where the computer reboots itself''? > I turn OFF the option in the Adaptec for "extended BIOS for DOS-drives > larger than 1 gig" figuring maybe that option is ONLY for DOS drives. I It is only intended for stupid systems and always a good idea to turn it off. Infact, the BIOS is only used for booting in Linux or FreeBSD, and entirely ignored once the system comes up. The translation is only in effect while booting, since the BIOS doesn't provide a better abstraction of a disk than sectors, heads, and cylinders (without an unreasonably degraded number of bits available for each of them). Either SCSI as Unices provide the block number abstraction (also called LBA addressing), so no further translation happens other than adding an offset for the start of the slice and/or partition. > Also, what's the recommended process for adding scsi drives (formatting > them, partitioning them and making the new fs's)? The man page for fdisk is > pretty tough to follow, and disklabel's is even worse. I've often repeated my procedure in Usenet, but it's probably inadequate for you since it is a little ignorant about possible but non-existant (for me) foreign operating systems. (For one, i totally ignore fdisk, and go strictly on with labelling the disk.) /stand/sysinstall should be up to the task now, but wasn't that good for post-install maintenance back in 2.1. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sat Jul 20 05:25:54 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA07683 for freebsd-scsi-outgoing; Sat, 20 Jul 1996 05:25:54 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA07650 for ; Sat, 20 Jul 1996 05:25:48 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id WAA30953; Sat, 20 Jul 1996 22:18:26 +1000 Date: Sat, 20 Jul 1996 22:18:26 +1000 From: Bruce Evans Message-Id: <199607201218.WAA30953@godzilla.zeta.org.au> To: freebsd-scsi@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: 2940 and large drives Cc: jon@vcnet.com Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> I turn OFF the option in the Adaptec for "extended BIOS for DOS-drives >> larger than 1 gig" figuring maybe that option is ONLY for DOS drives. I >It is only intended for stupid systems and always a good idea to turn >it off. Infact, the BIOS is only used for booting in Linux or on? You want the option that gives a geometry of 63 sectors/track and 255 heads/cylinders as easily as possible, preferably be default, at least for disks larger than 1GB. >FreeBSD, and entirely ignored once the system comes up. The >translation is only in effect while booting, since the BIOS doesn't >provide a better abstraction of a disk than sectors, heads, and >cylinders (without an unreasonably degraded number of bits available >for each of them). Either SCSI as Unices provide the block number >abstraction (also called LBA addressing), so no further translation >happens other than adding an offset for the start of the slice and/or >partition. A geometry of 63/255 allows booting from anywhere on disks of size up to about 8GB. If you don't use it, then booting from large disks may be complicated (booting from cylinders >= 1024 is impossible). Bruce From owner-freebsd-scsi Sat Jul 20 10:21:21 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA27080 for freebsd-scsi-outgoing; Sat, 20 Jul 1996 10:21:21 -0700 (PDT) Received: from mail.vcnet.com (ns1.vcnet.com [205.228.248.15]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA27069 for ; Sat, 20 Jul 1996 10:21:19 -0700 (PDT) Received: from [205.228.248.22] by mail.vcnet.com (post.office MTA v1.9.3b ID# 0-13499) with ESMTP id AAA16894 for ; Sat, 20 Jul 1996 10:20:56 -0700 X-Sender: jon@mail.vcnet.com Message-Id: In-Reply-To: <199607200716.JAA03287@uriah.heep.sax.de> References: from Jon Rust at "Jul 19, 96 06:17:19 pm" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Header: VCNet 805-383-3500 Date: Sat, 20 Jul 1996 10:21:24 -0700 To: freebsd-scsi@freebsd.org From: jon@vcnet.com (Jon Rust) Subject: Re: 2940 and large drives Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Ignored the message this time about bad geometry (after doing a low level >> format on the drives). The install completes okay. Upon reboot I get a >> message about "there is a drive larger than 1 gig with a 64 head/ 32 sector >> partitioning which is not compatable with the 255 head/ 63 sector >> translation setting on this card. Data could be corrupted. Hit any key to >> .....". > >FreeBSD won't corrupt any data in this case, but might have problems >to boot at all. Your system booted, so this was not a problem. > >> After hitting any key, the system comes up okay, but this obviously >> is bad, as evidenced by my daily crashes where the computer reboots itself! > >Yeah, and herein lies the problem. You forgot to tell us how it >crashes and what exactly happens. How should we know _why_ your >machine crashed if your only sentence about it is ``daily crashes >where the computer reboots itself''? > Well since it crashed in the middle of the night, AND rebooted itself with NO syslog entries, how am I supposed to tell? I came in in the morning, and the machines sitting on the BIOS screen (you know, where it checks the memory, tells you what kind of IDE drive you got, and the scsi card announces its presence) complaining about head/sector translations waiting for me to hit any key. The information above is all I had. Since turning off the "enable DOS partitions > 1g" option in the card, all is well... or at least it hasn't crashed in about 24 hours. A new record! Thanks to those who helped... though no one's suggested a straightforward way to partition up new drives. Linux has cfdisk, but I guess I'm not in Kansas anymore, Toto. jon <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Jon Rust VCNet For info, call us or email to 805.383.3500 info@vcnet.com PGP Fingerprint = 58 55 6C 46 4C 2B 7E 65 BB 35 AB 02 E1 27 73 7B "African swallows maybe, but not a European swallow. That's my point." <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> From owner-freebsd-scsi Sat Jul 20 11:47:02 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA05150 for freebsd-scsi-outgoing; Sat, 20 Jul 1996 11:47:02 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA05138; Sat, 20 Jul 1996 11:47:00 -0700 (PDT) Message-Id: <199607201847.LAA05138@freefall.freebsd.org> To: jon@vcnet.com (Jon Rust) cc: freebsd-scsi@freebsd.org Subject: Re: 2940 and large drives In-reply-to: Your message of "Sat, 20 Jul 1996 10:21:24 PDT." Date: Sat, 20 Jul 1996 11:47:00 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Well since it crashed in the middle of the night, AND rebooted itself with >NO syslog entries, how am I supposed to tell? I came in in the morning, and >the machines sitting on the BIOS screen (you know, where it checks the >memory, tells you what kind of IDE drive you got, and the scsi card >announces its presence) complaining about head/sector translations waiting >for me to hit any key. The information above is all I had. Put DDB into your kernel so that the machine won't auto reboot on a panic. It will also allow you to recover a stack trace of where the problem occured. Sometimes a panic condition is so severe, you don't get a syslog entry... >Since turning off the "enable DOS partitions > 1g" option in the card, all >is well... or at least it hasn't crashed in about 24 hours. A new record! Are you accessing a DOS partition at all? >Thanks to those who helped... though no one's suggested a straightforward >way to partition up new drives. Linux has cfdisk, but I guess I'm not in >Kansas anymore, Toto. You have to know what the right geometry to use is since, unlike Linux, the individual device drivers don't export information about the BIOS goemetry. I'll be the first to admit that the FreeBSD fdisk is not as easy to use as it could be. >jon > ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> >Jon Rust >VCNet For info, call us or email to >805.383.3500 info@vcnet.com > PGP Fingerprint = 58 55 6C 46 4C 2B 7E 65 BB 35 AB 02 E1 27 73 7B >"African swallows maybe, but not a European swallow. That's my point." ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> > > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sat Jul 20 14:27:05 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA17728 for freebsd-scsi-outgoing; Sat, 20 Jul 1996 14:27:05 -0700 (PDT) Received: from cabri.obs-besancon.fr (cabri.obs-besancon.fr [193.52.184.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA17720 for ; Sat, 20 Jul 1996 14:26:57 -0700 (PDT) Received: by cabri.obs-besancon.fr (5.57/Ultrix3.0-C) id AA29242; Sat, 20 Jul 96 23:31:44 +0100 Date: Sat, 20 Jul 96 23:31:44 +0100 Message-Id: <9607202231.AA29242@cabri.obs-besancon.fr> From: Jean-Marc Zucconi To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-scsi@freebsd.org In-Reply-To: <199607191648.SAA01276@uriah.heep.sax.de> (message from J Wunsch on Fri, 19 Jul 1996 18:48:18 +0200 (MET DST)) Subject: Re: CD driver X-Mailer: Emacs Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> J Wunsch writes: > Ah, so this looks like a READ AUDIO MSF command. 0xd8 is a READ AUDIO > LBA (with the exact same parameter list as 0xa8 -- READ(12)). Can you > perchance test whether your drive would also grok the 0xd8 one? I just did a test using the d8 command, and it seems to work (the drive led flashed and I did not get any error :-)) > (Btw., what's the `subcode' field for?) My documentation is very short. I got it from some FAQ a long time ago, and I losed the original text. Now I only have a printed sheet of paper with the following indications: special sub code selector 0 == normal 2352, other values are 01, 02, 03 I think this is also documented elsewhere because I added some manuscript notes: 1 -> audio data + 10 bytes Q-subcode+6 null bytes = 2368b; 2 ->audio data + all subcode data = 2448 bytes; 3-> all subcode data (P-W) only = 96 bytes > -- > cheers, J"org > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) Jean-Marc _____________________________________________________________________________ Jean-Marc Zucconi Observatoire de Besancon F 25010 Besancon cedex PGP Key: finger jmz@cabri.obs-besancon.fr ============================================================================= From owner-freebsd-scsi Sat Jul 20 19:29:57 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA04040 for freebsd-scsi-outgoing; Sat, 20 Jul 1996 19:29:57 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA04024 for ; Sat, 20 Jul 1996 19:29:52 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id MAA20673; Sun, 21 Jul 1996 12:29:32 +1000 Date: Sun, 21 Jul 1996 12:29:32 +1000 From: Bruce Evans Message-Id: <199607210229.MAA20673@godzilla.zeta.org.au> To: gibbs@freefall.freebsd.org, jon@vcnet.com Subject: Re: 2940 and large drives Cc: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>Thanks to those who helped... though no one's suggested a straightforward >>way to partition up new drives. Linux has cfdisk, but I guess I'm not in >>Kansas anymore, Toto. Linux fdisk should continue to work. This leaves the simpler problem of labeling the FreeBSD slice. >You have to know what the right geometry to use is since, unlike Linux, >the individual device drivers don't export information about the BIOS >goemetry. I'll be the first to admit that the FreeBSD fdisk is not as >easy to use as it could be. Individual device drivers don't export it because they don't know it. Bruce From owner-freebsd-scsi Sat Jul 20 20:48:25 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA09482 for freebsd-scsi-outgoing; Sat, 20 Jul 1996 20:48:25 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA09477; Sat, 20 Jul 1996 20:48:22 -0700 (PDT) Message-Id: <199607210348.UAA09477@freefall.freebsd.org> To: Bruce Evans cc: jon@vcnet.com, freebsd-scsi@freebsd.org Subject: Re: 2940 and large drives In-reply-to: Your message of "Sun, 21 Jul 1996 12:29:32 +1000." <199607210229.MAA20673@godzilla.zeta.org.au> Date: Sat, 20 Jul 1996 20:48:21 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Individual device drivers don't export it because they don't know it. Actually, I think that most of them can be made to know (this is easy to do for at least the aic7xxx cards), but I'd rather see us doing some sort of "drive tagging" during boot and determining the BIOS geometry to drive mapping generically. Who's working on the three stage boot project these days???? >Bruce -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================