lkml.org 
[lkml]   [2003]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Promise IDE controller crashes 2.4.22


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/

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