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

> 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.

Kenneth Merry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to