Re: Promise IDE controller crashes 2.4.22

From: Wes Janzen (superchkn_at_sbcglobal.net)
Date: 11/29/03

  • Next message: Sven Luther: "Re: Disk Geometries reported incorrectly on 2.6.0-testX" 
    Date:	Sat, 29 Nov 2003 03:12:56 -0600
To: John Goerzen <jgoerzen@complete.org>

    John Goerzen wrote:

    >On Fri, Nov 28, 2003 at 01:36:57PM -0600, Wes Janzen wrote:
    >
    >
    >>I'd suspect some sort of PCI problem, especially since you're running a
    >>
    >>
    >
    >Do you happen to have a URL where I can read up on PCI problems with
    >K6s?
    >
    Well, I know of the assorted problems with the KT133 & newer from VIA
    and SoundBlaster Live sound cards. I think changing the latency greatly
    reduced the problems but didn't eradicate it completely, IIRC. You can
    search on Google for "via soundblaster live" to get some more information.

    I know when I posted to the list due to problems with the onboard IDE on
    my board, several people responded that they had problems with their VIA
    boards randomly corrupting data during PCI busmaster transfers. That
    problem doesn't seem to afflict my board. Most of those were on newer
    boards (KT/KX133) but some involved the MVP3 which both of us are
    running. I compared notes with someone with the same motherboard
    revision who didn't have the problems I have, so perhaps some silicon or
    boards were defective in a way that was never detected by VIA or the
    board manufacturer respectively.

    Anyway, if VIA had problems with the later chipset I wouldn't be at all
    surprised if an older version suffered from similar defects.

    > Are the problems unique to Linux?
    >
    These problems are not unique to Linux. Windows configures PCI devices
    differently though and that could have an effect.

    > Note that it's a K6-3, so it's
    >not really first generation PCI.
    >
    >
    Well, it was a first-generation chipset in many regards ;-) Seriously
    though, especially back then VIA was several notches below Intel when it
    came to product quality. The K6 in any form was a bargain chip and the
    chipsets for it were targetting that market; I doubt they went through
    any qualification program remotely resembling those of Intel. In other
    words, it may not be first generation for VIA but it wasn't top quality
    either.

    I'm not bashing VIA, that's just the reality of it. My system was flaky
    until I replaced the onboard IDE with the Promise cards. It became
    solid when I replaced the 3dfx Banshee with an ATI 9000 Pro. Still I
    don't expect to get the kind of performance out of the cards as I would
    if they were in a comparable PII system. For example, I seriously doubt
    the 3COM diagnostics complain about PCI bus performance on an Intel system.

    > ...
    >
    >Can you translate UDMA-2 into something like UDMA/133? I'm having
    >trouble mapping the two in my head (I'm not terribly familiar with IDE
    >internals)
    >
    >
    >
    UDMA-2 = UDMA/33

    It's not really important, I'm just pointing out that if the drive
    stopped responding due to a communication problem between the drive and
    card, the drive would be reset and the system would become responsive
    even if it paused for several seconds.

    I should also clarify that the drive communicated fine with the VIA IDE
    in UDMA-2, just not with the Promise controllers. I have to back the
    drive down to UDMA-1 before writing data or it will reset and fallback
    to PIO.

    > ...
    >
    >The other thing is that the drives hooked to the on-board IDE channels
    >work fine. I don't know if that is important; but I figured I'd mention
    >it.
    >
    >
    >
    It may not stress the PCI bus as much, it was designed specifically for
    the chipset, and it's attached to the PCI bus in a significantly
    different manner. It's just that the fact that using PIO transfers
    implies a large reduction in the PCI bandwidth utilized by the card.
    That and my experience with card to drive communication failure only
    leaves some other cause. Depending on the type of transfer, it's likely
    that the PCI bus is being completely saturated when bursting write data
    to the drive's cache or even a sustained write. So going from a high
    PCI load to a lower PCI load solves the problem.

    It's possible that the driver is doing something wrong, but I'm using a
    similar hardware configuration and not experiencing the problem. Many
    more people are using the driver and card with a different board, also
    apparently without problems. So, add the history of VIA and PCI
    problems and a PCI communication failure looks like a prime candidate.
    You'd be wise to run an extensive memory test though to eliminate that
    cause. Other possible suspects would be the power supply or a hot cpu.

    >>You might try putting the card in another slot too. My cards are
    >>
    >>
    >
    >Hmm, I could give that a try.
    >
    >
    Could be a BIOS setting causing the problem too, but I don't know enough
    about the PCI bus to know which settings you'd want to adjust ;-) If it
    was me, I'd try the PCI settings first though since my machine is so
    full of cards and cables.

    Perhaps someone else can speak up and let us know if another misbehaving
    PCI device could be causing this problem? For example when the drive is
    hogging the bus during a DMA transfer maybe another card could interrupt
    it and lock up the PCI bus; is it possible and if so, likely? Maybe
    it's not the bandwidth but a long transfer that's the problem...? I'd
    rather not try to dig up the PCI specs to answer this question (mainly
    because I don't have the time).

    Good luck,
    Wes

    >Thanks,
    >John
    >
    >

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Sven Luther: "Re: Disk Geometries reported incorrectly on 2.6.0-testX"

    Relevant Pages