Messages in this thread | | | Subject | Re: aic7xxx driver. | Date | Sun, 06 Jul 1997 05:57:07 -0500 | From | Doug Ledford <> |
| |
-------- > > 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. * *****************************************************************************
| |