On Sun, Apr 29, 2001 at 14:47:47 +0300, Tomi Vainio - Sun Finland - wrote:
> Kenneth D. Merry writes:
> >
> > Can you do the following:
> >
> > camcontrol stop da1
> > camcontrol tur da1 -v
> > [ then you can start it back up with camcontrol start ]
> >
> > What I want to see here is the sense information coming back from the drive
> > when it is spun down.
> >
> > The new error recovery code should be doing the same thing as the old error
> > recovery code -- sending a start unit. For some reason it isn't doing the
> > right thing, though.
> >
> cat:~(10)# camcontrol stop da1
> Unit stopped successfully
> cat:~(11)# camcontrol tur da1 -v
> Unit is not ready
> (pass1:ahc0:0:2:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> (pass1:ahc0:0:2:0): CAM Status: SCSI Status Error
> (pass1:ahc0:0:2:0): SCSI Status: Check Condition
> (pass1:ahc0:0:2:0): NOT READY asc:4,2
> (pass1:ahc0:0:2:0): Logical unit not ready, initializing cmd. required field
>replaceable unit: 2
> cat:~(12)# mount /f
> mount: /dev/da1s1e: Input/output error
> cat:~(13)# camcontrol tur da1 -v
> Unit is not ready
> (pass1:ahc0:0:2:0): TEST UNIT READY. CDB: 0 0 0 0 0 0
> (pass1:ahc0:0:2:0): CAM Status: SCSI Status Error
> (pass1:ahc0:0:2:0): SCSI Status: Check Condition
> (pass1:ahc0:0:2:0): NOT READY asc:4,2
> (pass1:ahc0:0:2:0): Logical unit not ready, initializing cmd. required field
>replaceable unit: 2
That's the normal error message, so I'm not sure what's going on here.
This will probably have to wait 'till tomorrow when I can get on a -current
test box. There's definitely something odd going on.
> cat:~(15)# camcontrol start da1
> Unit started successfully
> cat:~(16)# mount /f
> mount: /dev/da1s1e: Input/output error
At this point the pack has probably already been invalidated, so it won't
let you mount the drive.
> cat:~(17)# camcontrol devlist
> <IBM DDRS-34560 S97B> at scbus0 target 0 lun 0 (pass0,da0)
> <SEAGATE ST32550W 0420> at scbus1 target 2 lun 0 (probe0,pass1,da1)
>
>
>
> Also messages file is full of these:
>
> Apr 29 00:55:42 cat /boot/kernel/kernel: (noperiph:ahc0:0:2:0): xpt_scan_lun: can't
>allocate path, can't continue
> Apr 29 00:55:43 cat last message repeated 26 times
> Apr 29 00:57:43 cat last message repeated 359 times
> Apr 29 01:07:43 cat last message repeated 1793 times
> Apr 29 01:17:43 cat last message repeated 1794 times
> Apr 29 01:27:43 cat last message repeated 1793 times
> Apr 29 01:34:13 cat last message repeated 1122 times
> Apr 29 01:34:13 cat /boot/kernel/kernel: (noperiph:ahc0:0:2:0): xpt_scan_lun: can't
>allocate path, can't continue
> Apr 29 01:34:13 cat last message repeated 43 times
> Apr 29 01:36:02 cat last message repeated 322 times
That's not good; it means malloc is failing. Did this happen right after
boot, or after a 'camcontrol rescan' or what?
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
