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
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message