>I kept having troubles with the aic7xxx driver in stock 2.0.30.
>One machine kept getting frequent kernel stack corruption messages.
>I needn't tell you how stable the machine was.
I noticed this problem at one time. Recompiling the kernel and not using
UMSDOS seemed to fix the problem. Hadn't noticed this recently.
Certainly taking the maintainer's advice is a good idea.
Another detail...I didn't get the message until accessing the drive on
the EIDE controller. I associated this with a nasty bug in UMSDOS
because removing UMSDOS fixed things up.
Recursive things like rm -rf on the UMSDOS partition really blew the
system's mind. After that initial kernel stack corruption everything
went to hell. copys failing etc.
My machine:
Vintage Dell P 90 (circa 1995...FDIV bug fixed). With buggy RZ-1000 EIDE
(hmmm). 32 megs of ram. EIDE drives are a 1.08 gig WD and a EZ 135.
SCSI controller runs a NEC 4x CDROM, 2 SCSI 1.08 gig drives...one NEC
and one Seagate. The SCSI NEC drive is my primary Linux drive...with a
single 1.08 gig partition for linux and a swap partition on my other
SCSI drive (that's now... may have had the swap on EIDE drive
before...don't recall).
My system does not typically have long uptimes but I do on pretty
frequent occasion beat the crap out my system by running multiple
compile sessions, numerous xterms, an emacs or too and other various
bloated X programs (xv in true color for instance).
NOTE NOTE NOTE this caused corruption on my EIDE drive...non critical
areas fortunately. I haven't seen this problem in a LONG time.
Some controller info from /proc for others who might be watching:
Adaptec AIC7xxx driver version: 4.0/3.2/4.0
Compile Options:
AIC7XXX_RESET_DELAY : 15
AIC7XXX_TWIN_SUPPORT : Enabled
AIC7XXX_TAGGED_QUEUEING: Disabled
AIC7XXX_PAGE_ENABLE : Disabled
AIC7XXX_PROC_STATS : Disabled
Adapter Configuration:
SCSI Adapter: AHA-2940
(AIC-787x chipset)
Host Bus: Single
Base IO: 0xfc00
IRQ: 11
SCBs: Used 2, HW 16, Page 16
Interrupts: 8017
Serial EEPROM: True
Extended Translation: Disabled
SCSI Bus Reset: Enabled
Ultra SCSI: Disabled
Target Disconnect: Enabled
I'm too lazy to reboot to get my Adaptec BIOS version but my guess is 1.1x.
I'd be glad to get the exact number if there is any interest. Maybe
someone should take a look at umsdos. I dunno.
I haven't done any major kernel hacking since 1.2.13 or so. Hacked my
entire 1.2.13 kernel so that it was completely modularized minus IDE.
PS/2 mouse, SCSI cdrom subsystem and all. Even developed several useful
proc files (to me) including a /proc/mount with a hacked mount/umount
binary that used it. (I got stuck on /proc/mount entry for /.)
Hmmm...seems to me I also had built some infrastructure
in the proc code so that I could add and delete modules to add and delete
proc files at will. Mostly personal enhancement...the code was riddled
with bugs. The PS/2 code was sufficently stable that I uploaded it to
sunsite.unc.edu at one point. Noticed a memory leak when I loaded and
unloaded the module and fixed that....Those were the days. The patch of my
stuff against stock 1.2.13 was nearly a megabyte. I was working
an a IPC based communication system between init and the kernel to
share some intimate information but then 2.0 came out. :)
Glenn
>Dan Eischen, deischen@iworks.InterWorks.org, the author of the
>aic7xxx driver, also recommends not to use stock 2.0.30 aic7xxx
>driver. He instead pointed me to his "July27" driver,
>available from ftp://ftp.pcnet.com/users/eischen/Linux/July27/
>(mail me if you want it in unified diff format)
>I installed this driver release, and the problems are gone ever since,
>the machine is running stable again. It also cured random hard locks
>on a friend's machine (dg2fef@afthd.th-darmstadt.de) when serving
>with Samba. On two other machines (btw. all having an Adaptec
>2940) it also performed very well.
I couldn't test exotic SCSI hardware, I only used it with
SCSI disks (removable and fixed), CDROM drives and a CD Writer.
I'd like the July27 driver to be part of 2.0.31...
Tom