Date: Wed, 01 May 1996 23:18:38 -0700 From: "Justin T. Gibbs" <gibbs@freefall.freebsd.org> To: "Kenneth D. Merry" <ken@area238.residence.gatech.edu> Cc: stable@FreeBSD.org Subject: Re: stable / Adaptec 2842 question.. Message-ID: <199605020618.XAA27590@freefall.freebsd.org> In-Reply-To: Your message of "Wed, 01 May 1996 23:18:29 EDT." <199605020318.XAA15544@area238.residence.gatech.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I upgraded to the most recent version of the Adaptec driver on >Monday (4/29/96). Things are much more stable now. (Thanks Justin!) >Before the upgrade, I couldn't get through a full cvs update i.e.: >cd /usr/src >cvs update -rRELENG_2_1_0 >(btw - is the -r necessary?) > > It would bomb every time trying to update sys/i386/isa/sound. I'm >not sure whether it was just a certain series of conditions that would make >it barf there, or if it's a bad spot on the disk, or what, but every time >the cvs update would get there, the machine would hang, then crash. When I >did get a crash dump, it would crash inside the adaptec driver, I think >inside ahc_timeout() or something. > Now, when I do the same cvs update operation, the machine doesn't >crash when it gets to /usr/src/sys/i386/isa/sound. :) It just resets the >SCSI bus!? All of the pending disk operations continue, though, after the >bus reset. (I haven't tried any stuff with my DAT drive at the same time, >though, so I don't know if tape operations would get hosed.) Is the bus >reset supposed to happen? Here are the kernel messages I get: The bus reset is part of the timeout recovery code that I think I finially have working reliably. What shouldn't happen is the initial timeout and I'm still investigating what could be causing this. The Linux driver seems to be having a much worse time of it lately with timeouts happening, but I think this is related to those same problems. It has something to do with how we initialze the termination settings on the card I think. When I find out for sure, you'll see commit mail. > I have options AHC_TAGENABLE in my kernel config file, do I need >anything to do with the SCB paging? Does it increase performance? Would >it prevent the SCSI bus resets? Are the SCSI bus resets a normal thing? Since you only have 4 SCBs, SCB paging should increase performance, but you may want to wait another week since Satoshi has already made the current version of the code fail using his 6 disk CCD array, and I haven't gotten word back on the patch I sent him to correct the problem. > I suppose this *could* be a termination problem, or some other >cabling problem, but I find it hard to believe that I could pound the disk >pretty hard with things like bonnie and iozone, and do 3 compiles at a time >without a glitch, if there is a hardware problem. I have the Atlas drive >on an internal ribbon cable, the cdrom and DAT drives are external. It could also be a race condition I've added to the driver recently. I don't know yet. > Anyway, this isn't a huge problem or anything. Things are *very* >stable here. I can run 3 compiles, Netscape, and various other things at >the same time, no blips, no glitches. (I could do more with more ram.) >Strangely enough, though, heavy cvs stuff tends to cause these resets. But at least the driver recovers now... >Thanks, > >Ken >-- >Kenneth Merry >ken@area238.residence.gatech.edu >Disclaimer: I don't speak for GTRI, GT, or Elvis. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605020618.XAA27590>