Apparently I didn't make my plans to make dev_t and devsw[] go away
under DEVFS quite clear enough to Peter Dufault as he stitched the SCSI
system together using them when he redid the configuration side of things.
This made is rather an effort to remove all vestiges of dev_t and
devsw[] entries from sd.c in DEVFS/SLICE mode.
is broken. It omits the SCSI_DATA_IN flag in the SCSI READ ELEMENT
STATUS command, which makes the 'chio status' command fail.
PR: 6528
Reviewed by: phk
Submitted by: Hans Huebner <hans@artcom.de>
This code will be turned on with the TWO options
DEVFS and SLICE. (see LINT)
Two labels PRE_DEVFS_SLICE and POST_DEVFS_SLICE will deliniate these changes.
/dev will be automatically mounted by init (thanks phk)
on bootup. See /sys/dev/slice/slice.4 for more info.
All code should act the same without these options enabled.
Mike Smith, Poul Henning Kamp, Soeren, and a few dozen others
This code does not support the following:
bad144 handling.
Persistance. (My head is still hurting from the last time we discussed this)
ATAPI flopies are not handled by the SLICE code yet.
When this code is running, all major numbers are arbitrary and COULD
be dynamically assigned. (this is not done, for POLA only)
Minor numbers for disk slices ARE arbitray and dynamically assigned.
data targets. At least st0 works for me again....
Also, scsi_scsi_cmd() looks like it's been exiting without a biodone() on
an attached buffer in a number of error cases, leading to locked buffers.
Defer the WRITE SESSION command until the first write command, so that
it works like the prepare track command, allowing the device to be
closed after the command.
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.
