On Sun, May 06, 2001 at 11:19:53 +0200, J Wunsch wrote:
> [F'up changed to freebsd-scsi]
>
> "Kenneth D. Merry" <[EMAIL PROTECTED]> wrote:
>
> > This should be fixed as of rev 1.22 of scsi_all.c. There was an errant
> > search and replace that caused the 'start' bit in the start/stop unit to
> > always be set to 0 (stop). So automatic spinups wouldn't work, and
> > 'camcontrol start' wouldn't work.
>
> I've got:
>
> uriah # cvs stat /sys/cam/scsi/scsi_all.c
> ===================================================================
> File: scsi_all.c Status: Up-to-date
>
> Working revision: 1.24 Result of merge
> Repository revision: 1.24 /home/ncvs/src/sys/cam/scsi/scsi_all.c,v
> Sticky Tag: (none)
> Sticky Date: (none)
> Sticky Options: (none)
>
> ....and still have the problem that the "camcontrol start" doesn't
> work. It returns immediately to the caller, claiming a "unit started
> successfully", while the drive hasn't started at all.
camcontrol uses scsi_start_stop() to build the start unit CDB.
scsi_start_stop() is in libcam, which compiles a number of kernel files in
userland. (including scsi_all.c) So you need to rebuild world to fix
camcontrol.
> Issuing a "camcontrol command daX -c '1b 0 0 0 1 0'" works.
That bypasses the CDB builder function (scsi_start_stop()), so I would
expect it to work.
> I didn't try whether the kernel-implied startup on disk access would
> work, though, since it would IMHO risk a hanging kernel and controller
> timeout.
That should work now.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
