aaccli core dumps ... looking for solution...

[Scott Long]

If the aaccli died while it had the controller open, then the refcount
in the driver will remain non-zero and you won't be able to open it
again until you reboot (it's a long-standing bug that I'll hopefully
fix someday).  However, rebuild, scrub, clear, and verify tasks are
designed to survive reboots.  The adapter will merely pick up where it
left off a few seconds after the reboot.  This will not affect your
data integrity any more than it is now.
The pause/resume functions are rather dangerous in general and I
would not recommend using them without good reason.  aaccli is very
much a 'no seatbelts' application.

Scott

Josh Brooks wrote:
> Hello,
> 
> I had some mirrors that had members marked offline, and before I buy new
> disks and replace them i wanted to try (at least once) to verify them and
> rejoin them and see how long they last.
> 
> So, I started aaccli and ran:
> 
> disk verify /repair=TRUE (2,1,0)
> 
> and then ran:
> 
> disk verify /repair=TRUE (3,2,0)
> 
> so i was running two verifys concurrently - I checked it by running `task
> list` a few times, and they were both proceeding just fine.  So I went to
> bed.
> 
> I wake up this morning, and the machine is fine, but I can no longer use
> aaccli.  When I run it, it starts, I get the prompt, and I can run things
> like `controller list`, but when I try to `open aac0` i get:
> 
> CLI > open aac0
> Executing: open "aac0"
> 
> AAC0>
> Floating exception (core dumped)r:  , State:DNE 100.0%
> 
> 
> So ... it looks like the ANSI screen drawing screws up a little, as it
> prints the core dump message on top of the status: done message ...
> 
> -------
> 
> So, I am wondering what to do ... I cannot check the state of my disks
> without being able to open the controller ... but I also cannot reboot
> this machine right now (since, presumably that would just make this
> problem go away).
> 
> Any suggestions ?  I was thinking of running one of these commands:
> 
>     controller rescan - Rescans the SCSI buses, and updates all underlying
> structures.
>     controller reset_scsi_bus - Resets the specified SCSI bus.
>     controller resume_io - Does rescan operation and then resumes IO after
> pause_io.
> 
> But I am afraid to run them on this live, running system - can anyone tell
> me if any of these commands, in general, are safe to run as an attempt to
> "slap the controller and make it behave" ?
> 
> Any comments appreciated...
> 
> _______________________________________________
> freebsd-scsi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"