lkml.org 
[lkml]   [1997]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: aic7xxx driver.
    Date
    From
    --------
    > > 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. *
    *****************************************************************************



    \
     
     \ /
      Last update: 2005-03-22 13:39    [W:4.387 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site