At 19:45 Uhr +0200 21.09.1999, Matthew Jacob wrote:
>[ I'm late coming to this discussion as it was forwarded to me offlist

Not much has happened so far. Make yourself comfortable.  =8)

>>Date: Mon, 20 Sep 1999 21:16:30 +0200
>>To: tech-kern
>>From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
>>Subject: scsipi/st.c issues
>>
>>I am in the middle of suggesting the st(4) driver to cooperate with
>>Tandberg TDC 4222 and SLR 5 drives.

[...]

>>there is some global flag missing for dealing with QIC-like EOM handling
>
>The global flag is ST_2FM_AT_EOD.

The existing quirks entries use only ST_Q_* constants. It wasn't obvious to
me that/where other constants are checked for.

>>(one filemark) in "quirkdata.quirks". Currently, a drive slips through the
>>cracks in st_decide_mode() when it gets probed as running in "default
>>mode", i.e. st->density == 0.
>
>There is no quirk flag at present in NetBSD to turn off the 2FM@EOD behaviour.
>It's still based solely on density as found in st_decide_mode (which is
>often bogus until some media access occurs).

It is always bogus when the "default" density 0 is assumed.

>In my opinion, the QIC
>manufacturers have been so bad in their emulation of variable mode that
>it's just downright wrongheaded to try and use it. Selecting 512 bytes
>fiexed for < QIC-525 and 1024 fixed for the above seems reasonable.

Where do you see problems with variable blocksize? Do they change for
pre-QIC 525 drives and newer ones? From the Tandberg handbooks I get the
impression that only the place of blocking/deblocking is changed: In fixed
block mode, the initiator has to do the work, whereas in variable block
mode the drive does the work.
>
>>Furthermore, you get two filemarks at EOM which prohibits
>>tarring/dumping several files onto one tape - appending to a tape gives a
>>flood of errors. This was broken around 1.3, it worked for me with a 1.2G
>>kernel.
>
>Is there a PR open on this?

Not from me. I sent note to current-users ("restore(8)/tape quirk in 1.4?")
when I first ran into problems. Didn't get far, though. It took me quite a
while to find documentation about how tape drives and especially QIC drives
work, and figure out where the problem might be. I've hacked st.c to handle
the QIC & two-filemarks issue correctly and should be able to come up with
a patch soon.

>>What "page 0" is "quirkdata.page_0_size" referring to? The "vital product
>>data" page length? And how would I determine the correct length for a given
>>drive?
>
>This is for drives that need a precise mode length, I believe. It doesn't
>appear to be used anywhere.

Leaving this field 0, I get something like

 Check Condition on CDB: 0x08 00 00 20 00 00
 SENSE KEY:  No Additional Sense
                Incorrect Length Indicator Set
 ASC/ASCQ:  No Additional Sense Information

for the SLR5 (I have the exact wording at work). Is this related?

>The comments ahead of st_mode_sense are
>bogus- it's not an INQUIRY that's being sent but a Group 0 Mode Sense
>(w/o a page code). The purpose of this is to get the current density,
>the current block size, and whether the tape is write-protected.

Is this information supposed to be propagated to userland? Why do I see

[hauke@elmo] ~ # mt status
SCSI tape drive, residual=0
ds=3<Mounted>
er=0
blocksize: 0 (0, 0, 0, 0)
density: 0 (0, 0, 0, 0)
[hauke@elmo] ~ #

even after adding the relevant density constants? They show up in the syslog...

>The other issues are "need quirk data to force
>1FM@EOM"

ISTR that the FreeBSD CAM sa driver code uses this. Comparing st.c and the
CAM driver code makes a strong case for moving to CAM.  =8>

>and "Document this stuff".

Thanks for picking up the ball,

	hauke



--
"It's never straight up and down"     (DEVO)