Date: Thu, 8 May 2003 09:50:39 -0700 (PDT) From: Josh Brooks <user@mail.econolodgetulsa.com> To: Scott Long <scott_long@btc.adaptec.com> Cc: freebsd-scsi@freebsd.org Subject: Re: aaccli core dumps ... looking for solution... Message-ID: <20030508094945.I5537-100000@mail.econolodgetulsa.com> In-Reply-To: <3EB95680.8060009@btc.adaptec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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! > 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?20030508094945.I5537-100000>