The machine can not recognize this PD drive
as neither PD drive nor CD-ROM Drive.
So I can not use CD-ROMs and PDs from FreeBSD.
PR: 7423
Reviewed by: phk
Submitted by: Takura Koyama <takura@popweb.ne.jp>
to [u]intptr_t instead of to [u_]long.
Don't cast pointers to integers just to do ordinary pointer arithmetic
on them, especially when the casts use gcc's feature of casting lvalues.
interupt level events. This needs a lot of cleanup, but has been working
here for a month or two.. originally needed for CAM integration
but that hasn't happenned yet. The probing state machines for each
handler should be replaced by a more generic state-service. It's
still quite messy in there..
There is only cdevsw (which should be renamed in a later edit to deventry
or something). cdevsw contains the union of what were in both bdevsw an
cdevsw entries. The bdevsw[] table stiff exists and is a second pointer
to the cdevsw entry of the device. it's major is in d_bmaj rather than
d_maj. some cleanup still to happen (e.g. dsopen now gets two pointers
to the same cdevsw struct instead of one to a bdevsw and one to a cdevsw).
rawread()/rawwrite() went away as part of this though it's not strictly
the same patch, just that it involves all the same lines in the drivers.
cdroms no longer have write() entries (they did have rawwrite (?)).
tapes no longer have support for bdev operations.
Reviewed by: Eivind Eklund and Mike Smith
Changes suggested by eivind.
FreeBSD/alpha. The most significant item is to change the command
argument to ioctl functions from int to u_long. This change brings us
inline with various other BSD versions. Driver writers may like to
use (__FreeBSD_version == 300003) to detect this change.
The prototype FreeBSD/alpha machdep will follow in a couple of days
time.
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).
