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

Kenneth Merry

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

Reply via email to