Date: Sun, 6 May 2001 11:19:53 +0200 (MET DST) From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-current@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: camcontrol stop / restart broken Message-ID: <200105060919.f469JrT07865@uriah.heep.sax.de> References: <15083.9059.887489.356984@ultrahot.Finland.Sun.COM> <20010428224047.A37268@panzer.kdm.org> <15083.65379.523173.371122@ultrahot.Finland.Sun.COM> <20010430101214.A46826@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[F'up changed to freebsd-scsi] "Kenneth D. Merry" <ken@kdm.org> 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. Issuing a "camcontrol command daX -c '1b 0 0 0 1 0'" works. 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. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105060919.f469JrT07865>