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. ;-)