Date: Fri, 09 May 2003 00:33:59 -0600 From: Scott Long <scott_long@btc.adaptec.com> To: Josh Brooks <user@mail.econolodgetulsa.com> Cc: freebsd-scsi@freebsd.org Subject: Re: aaccli core dumps ... looking for solution... Message-ID: <3EBB4BD7.5070806@btc.adaptec.com> In-Reply-To: <20030508094945.I5537-100000@mail.econolodgetulsa.com> References: <20030508094945.I5537-100000@mail.econolodgetulsa.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Josh Brooks wrote: > >>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 > > > Is it bad to verify two disks simultaneously on the same controller like I > did ? I am just looking for an explanation as to why aaccli died out... > > thanks! > The controller can handle the operation just fine, but there is likely a bug in aaccli. 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@freebsd.org mailing list >>>http://lists.freebsd.org/mailman/listinfo/freebsd-scsi >>>To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" >> >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EBB4BD7.5070806>