On Sat, Jan 26, 2002 at 10:38:54PM -0700, Scott Long wrote:
> Besides this somewhat empirical evidence, is there any other reason
> that you suspect the aac controller? Can you post the relevant dmesg
> lines that describe this controller? We make pretty heavy use of
> our aac controller here, with very good results. I'd like to help
> narrow this down, since data corruption is not a typical failure
> mode of these controllers or the aac driver.
The relevant dmesg lines were in the message; I've reproduced them below.
I had no reason to suspect the controller before Matt Dillon mentioned
it during and after our debugging session.
I'm still waiting on diagnostic testing on the machine in question. I've
had no problems that I can directly trace to the controller.
> > ahc0: <Adaptec aic7899 Ultra160 SCSI adapter> port 0xd800-0xd8ff mem
>0xf7ffe000-0xf7ffefff irq 10 at device 4.1 on pci2
> > aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/255 SCBs
> > aac0: <Dell PERC 3/Si> mem 0xf0000000-0xf3ffffff irq 2 at device 2.1 on pci1
> > aac0: i960RX 100MHz, 54MB cache memory, no battery support
> > aac0: Kernel 2.1-3, Build 2951, S/N 4c20d0
> > aacd0: <RAID 0/1> on aac0
> > aacd0: 139997MB (286714368 sectors)
> > Mounting root from ufs:/dev/aacd0s1a
Doug Swarin, Programmer
doug (at) texas dot net
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message