Re: aic7xxx driver.

Doug Ledford (dledford@dialnet.net)
Sun, 06 Jul 1997 05:57:07 -0500


--------
> > Much experimentation and some corrupted filesystems later it seemed
> > that the aic7xxx driver was causing a problem which seemed to be
> > related to CPU speed - eg. with the motherboard clock set at 60 MHz
> > and the CPU internal at 150 MHz all was well, with the motherboard
> > at 60MHz and the CPU internal at 180MHz there were problems.
> >
> > In the spirit of an experiment I changed all the outb() calls
> > to outb_p() and all the inb() to inb_p for the whole of aic7xxx.c.
> >
> > Since then there have been no problems at all when running the CPU
> > at 210 MHz (417 BogoMIPS)
>
> H. Peter Anvin and Felix von Leitner had trouble running their K6s at the
> rated speed as well. Their problems went away after replacing the chip
> with another K6. It's conceivable that inb() and outb() compile to
> instructions that yours doesn't run properly at the higher speed.

Or it's entirely possible that the early K6 systems could be munging bus
operations at these high speeds due to differences in the K6 and Pentium
CPUs. Especially when you consider that one of the reason for switching
from a programmed I/O model to a DMA model for the SCSI control blocks in
the aic7xxx driver (28 bytes per block, used to control what the sequencer
does on any given command) was the fact the PentPro 200 machines could
sometimes cause the aic7xxx based cards to flake out under fast PI/O
operations. The K6 could be merely better at bringing out the same problem
with the Adaptec cards. However, I do seem to recall that the real symptom
of this is NMI interrupts generated when accessing the card too quickly
using programmed I/O, so the real question is, does the machine give any of
the NMI messages ("Huh? Dazed and confused, trying to continue" or something
to that effect) before it spews chunks? If it does, then I guess it
shouldn't have tried to continue ;)

As for the shotgun approach of changing all of the I/Os. Yeah, that was
probably overkill. Most likely what we are seeing here is similar to the
PPro 200 chips in that the various back-to-back PI/O operations are being
executed fast enough on the CPU as to cause problems on the bus for the
aic7xxx chipset. One possible solution would be to only slow down back to
back I/O ops and see if it goes away. Another good test would be to see if
it is indeed a CPU problem as Trevor pointed out. If this bug goes away
with another CPU, then it's also possible that early runs of the K6 CPU have
some bus timing problems. Also, you don't mention the kernel version you
are using, but if it's any kernel from the 2.0.x series, then it still has
the older aic7xxx driver based on the PI/O model instead of the SCB DMA
model. The new version of the driver is currently slated for inclusion in
2.0.31, but you can grab the latest from ftp.pcnet.com:/users/eichen/linux-??
???-2.0.26.tar.gz (the same driver is used in both the 2.0 and 2.1 kernel
series currently, although that should change once some of the mid-level
code gets re-done in 2.1). Since this version of the driver has
significantly fewer back to back PI/O operations, it should at least work
better given your circumstance.

To be quite honest though, I would try the new CPU first. The reason I say
this is that you had problems with the CPU at 180MHz, and the mem bus at 60
MHz, which means that the PCI bus was at 30MHz, and 30MHz on the PCI bus
shouldn't upset the Adaptec chipsets even if the CPU is really fast unless
there is some kind of timing problem. We never saw the problem with PPro
180 chips, just the 200s, so it would seem to indicate that the problem
didn't show up until you got to the full 33MHz PCI bus plus a really fast
CPU.

-- 
*****************************************************************************
* Doug Ledford                      *   Unix, Novell, Dos, Windows 3.x,     *
* dledford@dialnet.net    873-DIAL  *     WfW, Windows 95 & NT Technician   *
*   PPP access $14.95/month         *****************************************
*   Springfield, MO and surrounding * Usenet news, e-mail and shell account.*
*   communities.  Sign-up online at * Web page creation and hosting, other  *
*   873-9000 V.34                   * services available, call for info.    *
*****************************************************************************