Date: Tue, 1 May 2001 12:46:08 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Tomi Vainio - Sun Finland - <Tomi.Vainio@Sun.COM> Cc: freebsd-current@FreeBSD.ORG Subject: Re: camcontrol stop / restart broken Message-ID: <20010501124608.A55572@panzer.kdm.org> In-Reply-To: <15085.44361.206744.404170@ultrahot.Finland.Sun.COM>; from Tomi.Vainio@Sun.COM on Mon, Apr 30, 2001 at 09:22:01PM %2B0300 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> <15085.44361.206744.404170@ultrahot.Finland.Sun.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 30, 2001 at 21:22:01 +0300, Tomi Vainio - Sun Finland - wrote: > Kenneth D. Merry writes: > > > > 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. > > > Thanks, I'll test this soon. > > > I'd still like to know when these messages are cropping up. > > > I scanned messages files and it seems to start ~2 hours after I have tried > to spin up the disk first time. > > Apr 28 23:01:40 cat /boot/kernel/kernel: (da1:ahc0:0:2:0): Invalidating pack > Apr 28 23:08:10 cat /boot/kernel/kernel: (da1:ahc0:0:2:0): Invalidating pack > Apr 29 00:49:42 cat /boot/kernel/kernel: (noperiph:ahc0:0:2:0): xpt_scan_lun: can't allocate CCB, can't continue > > Apr 29 14:40:00 cat /boot/kernel/kernel: (da1:ahc0:0:2:0): Invalidating pack > Apr 29 14:44:31 cat /boot/kernel/kernel: (da1:ahc0:0:2:0): Invalidating pack > Apr 29 16:34:04 cat /boot/kernel/kernel: (noperiph:ahc0:0:2:0): xpt_scan_lun: can't allocate path, can't continue > Hmm. Well, I definitely haven't seen this before. The only thing I can figure is that we got into some sort of infinite rescan loop. I don't know how spinning up the disk (or trying to) would trigger a rescan. If it happens again, could you try to drop into the debugger and get a stack trace? If the stack trace doesn't show anything, perhaps setting a breakpoint in xpt_scan_lun would work. (You may want to have remote gdb setup for that.) Ken -- Kenneth Merry ken@kdm.org 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?20010501124608.A55572>