1997-02-09 20:29:15 +00:00
|
|
|
.\" Copyright (c) 1997
|
|
|
|
|
.\" John-Mark Gurney. All rights reserved.
|
|
|
|
|
.\"
|
|
|
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
|
|
|
.\" modification, are permitted provided that the following conditions
|
|
|
|
|
.\" are met:
|
|
|
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
|
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
|
|
|
.\" 3. Neither the name of the author nor the names of any co-contributors
|
|
|
|
|
.\" may be used to endorse or promote products derived from this software
|
|
|
|
|
.\" without specific prior written permission.
|
|
|
|
|
.\"
|
|
|
|
|
.\" THIS SOFTWARE IS PROVIDED BY John-Mark Gurney AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
.\" SUCH DAMAGE.
|
|
|
|
|
.\"
|
1999-08-28 00:22:10 +00:00
|
|
|
.\" $FreeBSD$
|
1997-02-09 20:29:15 +00:00
|
|
|
.\"
|
Move dynamic sysctl(8) variable creation for the cd(4) and da(4) drivers
out of cdregister() and daregister(), which are run from interrupt context.
The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.
The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread. For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.
The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand. So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread. (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)
scsi_cd.c: Remove sysctl variable creation code from cdregister(), and
move it to a new function, cdsysctlinit(). Queue
cdsysctlinit() to the taskqueue_thread taskqueue once we
have fully registered the cd(4) driver instance.
scsi_da.c: Remove sysctl variable creation code from daregister(), and
move it to move it to a new function, dasysctlinit().
Queue dasysctlinit() to the taskqueue_thread taskqueue once
we have fully registered the da(4) instance.
taskqueue.h: Declare the new taskqueue_thread taskqueue, update some
comments.
subr_taskqueue.c:
Create the new kernel thread taskqueue. This taskqueue
runs outside of Giant, so any functions queued to it would
need to explicitly acquire/release Giant if they need it.
cd.4: Update the cd(4) man page to talk about the minimum command
size sysctl/loader tunable. Also note that the changer
variables are available as loader tunables as well.
da.4: Update the da(4) man page to cover the retry_count,
default_timeout and minimum_cmd_size sysctl variables/loader
tunables. Remove references to /dev/r???, they aren't used
any longer.
cd.9: Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
quirk.
taskqueue.9: Update the taskqueue(9) man page to describe the new thread
task queue, and the taskqueue_swi_giant queue.
MFC after: 3 days
2003-09-03 04:46:28 +00:00
|
|
|
.Dd September 2, 2003
|
1997-02-23 18:00:03 +00:00
|
|
|
.Dt CD 9
|
2001-07-10 15:31:11 +00:00
|
|
|
.Os
|
1997-02-09 20:29:15 +00:00
|
|
|
.Sh NAME
|
|
|
|
|
.Nm cd
|
1998-10-12 04:09:49 +00:00
|
|
|
.Nd CDROM driver for the CAM SCSI subsystem
|
1997-02-09 20:29:15 +00:00
|
|
|
.Sh DESCRIPTION
|
1997-02-09 21:08:52 +00:00
|
|
|
The
|
|
|
|
|
.Nm
|
2001-08-10 17:35:21 +00:00
|
|
|
device driver provides a read only interface for CDROM drives
|
|
|
|
|
.Tn ( SCSI
|
1998-10-12 04:09:49 +00:00
|
|
|
type 5)
|
2001-08-10 17:35:21 +00:00
|
|
|
and WORM drives
|
|
|
|
|
.Tn ( SCSI
|
1998-10-12 04:09:49 +00:00
|
|
|
type 4)
|
|
|
|
|
that support CDROM type commands.
|
2003-10-23 02:33:03 +00:00
|
|
|
Some drives don't behave as the driver expects.
|
2003-10-23 05:34:13 +00:00
|
|
|
See the
|
|
|
|
|
.Sx QUIRKS
|
|
|
|
|
section for information on possible flags.
|
1997-02-09 20:29:15 +00:00
|
|
|
.Sh QUIRKS
|
|
|
|
|
Each
|
|
|
|
|
.Tn CD-ROM
|
|
|
|
|
device can have different interpretations of the
|
|
|
|
|
.Tn SCSI
|
2003-10-23 02:33:03 +00:00
|
|
|
spec.
|
|
|
|
|
This can lead to drives requiring special handling in the driver.
|
|
|
|
|
The following is a list of quirks that the driver recognize.
|
1997-02-09 20:29:15 +00:00
|
|
|
.Bl -tag -width CD_Q_BCD_TRACKS
|
|
|
|
|
.It Dv CD_Q_NO_TOUCH
|
|
|
|
|
This flag tell the driver not to probe the drive at attach time to see if
|
2003-10-23 02:33:03 +00:00
|
|
|
there is a disk in the drive and find out what size it is.
|
|
|
|
|
This flag is currently unimplemented in the CAM
|
2000-11-20 18:41:33 +00:00
|
|
|
.Nm
|
1998-10-12 04:09:49 +00:00
|
|
|
driver.
|
1997-02-09 20:29:15 +00:00
|
|
|
.It Dv CD_Q_BCD_TRACKS
|
|
|
|
|
This flag is for broken drives that return the track numbers in packed BCD
|
2003-10-23 02:33:03 +00:00
|
|
|
instead of straight decimal.
|
|
|
|
|
If the drive seems to skip tracks
|
2001-08-07 15:48:51 +00:00
|
|
|
(tracks 10-15 are skipped)
|
1997-02-09 20:29:15 +00:00
|
|
|
then you have a drive that is in need of this flag.
|
1998-10-12 04:09:49 +00:00
|
|
|
.It Dv CD_Q_NO_CHANGER
|
|
|
|
|
This flag tells the driver that the device in question is not a changer.
|
|
|
|
|
This is only necessary for a CDROM device with multiple luns that are not a
|
|
|
|
|
part of a changer.
|
|
|
|
|
.It Dv CD_Q_CHANGER
|
|
|
|
|
This flag tells the driver that the given device is a multi-lun changer.
|
|
|
|
|
In general, the driver will figure this out automatically when it sees a
|
2003-10-23 02:33:03 +00:00
|
|
|
LUN greater than 0.
|
|
|
|
|
Setting this flag only has the effect of telling the
|
1998-10-12 04:09:49 +00:00
|
|
|
driver to run the initial read capacity command for LUN 0 of the changer
|
|
|
|
|
through the changer scheduling code.
|
Move dynamic sysctl(8) variable creation for the cd(4) and da(4) drivers
out of cdregister() and daregister(), which are run from interrupt context.
The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.
The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread. For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.
The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand. So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread. (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)
scsi_cd.c: Remove sysctl variable creation code from cdregister(), and
move it to a new function, cdsysctlinit(). Queue
cdsysctlinit() to the taskqueue_thread taskqueue once we
have fully registered the cd(4) driver instance.
scsi_da.c: Remove sysctl variable creation code from daregister(), and
move it to move it to a new function, dasysctlinit().
Queue dasysctlinit() to the taskqueue_thread taskqueue once
we have fully registered the da(4) instance.
taskqueue.h: Declare the new taskqueue_thread taskqueue, update some
comments.
subr_taskqueue.c:
Create the new kernel thread taskqueue. This taskqueue
runs outside of Giant, so any functions queued to it would
need to explicitly acquire/release Giant if they need it.
cd.4: Update the cd(4) man page to talk about the minimum command
size sysctl/loader tunable. Also note that the changer
variables are available as loader tunables as well.
da.4: Update the da(4) man page to cover the retry_count,
default_timeout and minimum_cmd_size sysctl variables/loader
tunables. Remove references to /dev/r???, they aren't used
any longer.
cd.9: Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
quirk.
taskqueue.9: Update the taskqueue(9) man page to describe the new thread
task queue, and the taskqueue_swi_giant queue.
MFC after: 3 days
2003-09-03 04:46:28 +00:00
|
|
|
.It Dv CD_Q_10_BYTE_ONLY
|
|
|
|
|
This flag tells the driver that the given device only accepts 10 byte MODE
|
2003-10-23 02:33:03 +00:00
|
|
|
SENSE/MODE SELECT commands.
|
|
|
|
|
In general these types of quirks should not be
|
Move dynamic sysctl(8) variable creation for the cd(4) and da(4) drivers
out of cdregister() and daregister(), which are run from interrupt context.
The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.
The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread. For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.
The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand. So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread. (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)
scsi_cd.c: Remove sysctl variable creation code from cdregister(), and
move it to a new function, cdsysctlinit(). Queue
cdsysctlinit() to the taskqueue_thread taskqueue once we
have fully registered the cd(4) driver instance.
scsi_da.c: Remove sysctl variable creation code from daregister(), and
move it to move it to a new function, dasysctlinit().
Queue dasysctlinit() to the taskqueue_thread taskqueue once
we have fully registered the da(4) instance.
taskqueue.h: Declare the new taskqueue_thread taskqueue, update some
comments.
subr_taskqueue.c:
Create the new kernel thread taskqueue. This taskqueue
runs outside of Giant, so any functions queued to it would
need to explicitly acquire/release Giant if they need it.
cd.4: Update the cd(4) man page to talk about the minimum command
size sysctl/loader tunable. Also note that the changer
variables are available as loader tunables as well.
da.4: Update the da(4) man page to cover the retry_count,
default_timeout and minimum_cmd_size sysctl variables/loader
tunables. Remove references to /dev/r???, they aren't used
any longer.
cd.9: Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
quirk.
taskqueue.9: Update the taskqueue(9) man page to describe the new thread
task queue, and the taskqueue_swi_giant queue.
MFC after: 3 days
2003-09-03 04:46:28 +00:00
|
|
|
added to the
|
|
|
|
|
.Xr cd 4
|
2003-10-23 02:33:03 +00:00
|
|
|
driver.
|
|
|
|
|
The reason is that the driver does several things to attempt to
|
|
|
|
|
determine whether the drive in question needs 10 byte commands.
|
|
|
|
|
First, it
|
Move dynamic sysctl(8) variable creation for the cd(4) and da(4) drivers
out of cdregister() and daregister(), which are run from interrupt context.
The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.
The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread. For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.
The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand. So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread. (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)
scsi_cd.c: Remove sysctl variable creation code from cdregister(), and
move it to a new function, cdsysctlinit(). Queue
cdsysctlinit() to the taskqueue_thread taskqueue once we
have fully registered the cd(4) driver instance.
scsi_da.c: Remove sysctl variable creation code from daregister(), and
move it to move it to a new function, dasysctlinit().
Queue dasysctlinit() to the taskqueue_thread taskqueue once
we have fully registered the da(4) instance.
taskqueue.h: Declare the new taskqueue_thread taskqueue, update some
comments.
subr_taskqueue.c:
Create the new kernel thread taskqueue. This taskqueue
runs outside of Giant, so any functions queued to it would
need to explicitly acquire/release Giant if they need it.
cd.4: Update the cd(4) man page to talk about the minimum command
size sysctl/loader tunable. Also note that the changer
variables are available as loader tunables as well.
da.4: Update the da(4) man page to cover the retry_count,
default_timeout and minimum_cmd_size sysctl variables/loader
tunables. Remove references to /dev/r???, they aren't used
any longer.
cd.9: Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
quirk.
taskqueue.9: Update the taskqueue(9) man page to describe the new thread
task queue, and the taskqueue_swi_giant queue.
MFC after: 3 days
2003-09-03 04:46:28 +00:00
|
|
|
issues a CAM Path Inquiry command to determine whether the protocol that
|
|
|
|
|
the drive speaks typically only allows 10 byte commands. (ATAPI and USB
|
|
|
|
|
are two prominent examples of protocols where you generally only want to
|
|
|
|
|
send 10 byte commands.) Then, if it gets an ILLEGAL REQUEST error back
|
|
|
|
|
from a 6 byte MODE SENSE or MODE SELECT command, it attempts to send the 10
|
2003-10-23 02:33:03 +00:00
|
|
|
byte version of the command instead.
|
|
|
|
|
The only reason you would need a
|
Move dynamic sysctl(8) variable creation for the cd(4) and da(4) drivers
out of cdregister() and daregister(), which are run from interrupt context.
The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.
The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread. For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.
The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand. So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread. (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)
scsi_cd.c: Remove sysctl variable creation code from cdregister(), and
move it to a new function, cdsysctlinit(). Queue
cdsysctlinit() to the taskqueue_thread taskqueue once we
have fully registered the cd(4) driver instance.
scsi_da.c: Remove sysctl variable creation code from daregister(), and
move it to move it to a new function, dasysctlinit().
Queue dasysctlinit() to the taskqueue_thread taskqueue once
we have fully registered the da(4) instance.
taskqueue.h: Declare the new taskqueue_thread taskqueue, update some
comments.
subr_taskqueue.c:
Create the new kernel thread taskqueue. This taskqueue
runs outside of Giant, so any functions queued to it would
need to explicitly acquire/release Giant if they need it.
cd.4: Update the cd(4) man page to talk about the minimum command
size sysctl/loader tunable. Also note that the changer
variables are available as loader tunables as well.
da.4: Update the da(4) man page to cover the retry_count,
default_timeout and minimum_cmd_size sysctl variables/loader
tunables. Remove references to /dev/r???, they aren't used
any longer.
cd.9: Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
quirk.
taskqueue.9: Update the taskqueue(9) man page to describe the new thread
task queue, and the taskqueue_swi_giant queue.
MFC after: 3 days
2003-09-03 04:46:28 +00:00
|
|
|
quirk is if your drive uses a protocol (e.g.
|
|
|
|
|
.Tn SCSI )
|
|
|
|
|
that typically doesn't have a problem with 6 byte commands.
|
1997-02-09 20:29:15 +00:00
|
|
|
.El
|
|
|
|
|
.Sh FILES
|
1998-10-12 04:09:49 +00:00
|
|
|
.Bl -tag -width /sys/cam/scsi/scsi_cd.c -compact
|
|
|
|
|
.It Pa /sys/cam/scsi/scsi_cd.c
|
|
|
|
|
is the driver source file.
|
1997-02-09 20:29:15 +00:00
|
|
|
.El
|
|
|
|
|
.Sh SEE ALSO
|
|
|
|
|
.Xr cd 4 ,
|
1998-10-16 00:26:28 +00:00
|
|
|
.Xr scsi 4
|
1997-02-09 20:29:15 +00:00
|
|
|
.Sh HISTORY
|
|
|
|
|
The
|
|
|
|
|
.Nm
|
|
|
|
|
manual page first appeared in
|
1997-02-17 15:22:20 +00:00
|
|
|
.Fx 2.2 .
|
1998-03-12 07:31:21 +00:00
|
|
|
.Sh AUTHORS
|
2000-11-22 09:35:58 +00:00
|
|
|
.An -nosplit
|
1997-02-09 20:29:15 +00:00
|
|
|
This
|
1998-03-12 07:31:21 +00:00
|
|
|
manual page was written by
|
|
|
|
|
.An John-Mark Gurney Aq gurney_j@efn.org .
|
1998-10-12 04:09:49 +00:00
|
|
|
It was updated for CAM and
|
|
|
|
|
.Fx 3.0
|
|
|
|
|
by
|
1999-08-15 10:48:36 +00:00
|
|
|
.An Kenneth Merry Aq ken@FreeBSD.org .
|
