Iomaga Jaz drives.
From: Steve Logue <stevel@mail.cdsnet.net>
To: freebsd-current@freebsd.org, freebsd-scsi@freebsd.org
Subject: Jaz Drives / Tagged Command Queuing
FreeBSD Lists,
Due to my own problems as the owner of a Jaz drive, I have gotten word
from Iomega that confirms the state of Tagged Command Queuing as the
underlying problem. There is an error in all Jaz, and Jaz2 drives prior
to BIOS level J.86 that has not shipped yet. Read the following, and
make the appropriate corrections to your system present, and future:
> Steve,
>
> I got a very fast response from the hardware engineer (Jaz and Jaz 2
> designer). The problem is this - The Jaz drive does not support
> command queing, and revisions older than J.86 do not report it correctly.
> For example, when your SCSI adapter says "I'm going to use command
> queing" to the Jaz drive, the drive answers "OK, lets go", even though its
> not supported. The J.86 drives will now answer "Sorry, command
> queing is not supported". Iomega does not have any current plans to
> support command queing.
>
> Thank's for your report, I will continue to forward it to the hardware
> engineers.
-STEVEl
--
---------------------------------------------------------------------
Steve Logue http://home.cdsnet.net/~stevel
Systems Integration nettek LLC
---------------------------------------------------------------------
Submitted by: Steve Logue <stevel@mail.cdsnet.net>
Fix the SCIOCGETDEVINFO code so that it compiles, and while I'm at it,
add support for human-readable device names so that I don't have
to call devname(3) on the scd->dev to get it.
to look up information about that device. Right now, all it does
is give back the dev_t for the device, if known, since that's all
I needed, but hopefully the SCSI mavens will come up with a more generally
useful structure.
This introduce an xxxFS_BOOT for each of the rootable filesystems.
(Presently not required, but encouraged to allow a smooth move of option *FS
to opt_dontuse.h later.)
LFS is temporarily disabled, and will be re-enabled tomorrow.
the "READ_CAPACITY" command, rather than the physical blocksize
reported in the physical geometry code-page.
Also don't print out worrying bogus messages when probing a
device that has no media. There's no point in printing out
something that is unknowable. It just confuses things.
Move the check for valid blocksize out of 'open()' to the subroutine
that actually finds this out, thus probe/attach can also report and
act on the problem.
under -current. The actual preparation of the next track will now be
deferred until just before the first write operation. Otherwise,
opening the device with write intent will cause the execution of
commands that are illegal in `limited command set mode' (i.e., after
the write channel has been opened).
While i was at it, cleaned up the worm_open() function a bit.
Removed the volume overflow pre-check in worm_strategy(). It was
time-consuming, and rather useless in many cases anyway (with the size
being reported for just the entire volume only), so we can as well let
the actual SCSI command fail instead, where it'll properly be reported
as EIO.
Partially submitted by & discussed with: jmz
unknown drive. Such a drive will be configured by worm(4)
nevertheless (albeit with a warning), but cannot be opened except of
the SCSI control device (so scsi(8) or cdrecord will continue to
work).
break for the usual sector size. dscheck() adjusts b_bcount to
handle EOF, so we must scale it and not preserve it. i/o beyond
the end of partitions has been broken since rev.1.96.
Not fixed in: od driver
much grieve to owners of IBM drives when used in conjunction with
tagged command queuing, and didn't serve any purpose at all (since
experiments have proven that it simply didn't work).
Instead, call scsi_start_unit() once in sd_attach(), so in case the
drive has been configured to `remote start', it will spin up there.
(If it has spun down later, it must have been because of administrator
action (scsi(8)) anyway.)
While i was at it, bump the timeout for scsi_start_unit() to 30
seconds. 10 seconds were way too few for most drives.
PR: 4486
Submitted by: tegge@idi.ntnu.no (Tor Egge)
Implement a function is_adapter_memory() in order to determine what
should nto be dumped at all. Currently, only populated with the ``ISA
memory hole''. Adapter regions of other busses should be added.
