Re: BUG?: VIA IDE transfer-rate problem

[Erik Slagter <erik@slagter.name>]

[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

On Thu, 2006-01-19 at 08:21 +0100, Helmut Toplitzer wrote:
> Ok. I found another possible reason, did I?
> 
> I read in several forums that HLT in KT333 chipsets
> of VIA is not enough to get the processor in powersafe
> and to disconnect from the FSB. You need to issuse
> the STPGNT command which also needs first
> to set some registers (because it degrades overall performance and
> so it's normaly disabled by BIOS).
> http://www.planet3dnow.de/vbulletin/archive/index.php/t-80854.html
> (German)
> 
> It's called "Disconnect Enable when STPGNT Detected". And may cause
> other problems like sound distortion etc. because of high fluctuation
> in power current.

This is actually a common AMD Athlon problem. When STOPGRNT is not
enable, hlt does next to nothing. Some boards/bios'es set this bit by
itself, some don't, and some even crash when it's enabled (very bad,
imho).

Also my experience is that some PCI devices tend to stop working when
STOPGRNT is enabled, notably my Promise SX 150 tx2plus, that completely
freaks whenever it misses one single interrupt, which may very well
happen when the processor/board are in C1/C2 (apparently).

See also my other message on this matter:

On Tue, 2006-01-03 at 18:58 +0000, Alan Cox wrote:

> There is a known old bug with error handling in some cases on promise
> chips. The core kernel code tries to clean up any remaining data after
> an error (to handle chip prefetch/postwrite FIFOs) if DRQ_STAT is
> asserted. Its a nice trick, saves on resets and slow recovery but
isn't
> compatible with some promise controllers.
> 
> The -mm tree has a partial but incomplete fix to this implemented, the
> base kernel does not have this fixed.
> 
> Its been known for some time so perhaps the ide maintainers have
patches
> waiting for 2.6.16 now its opened ?

Is this patch supposed to fix this problem:

Promise SATAII150 TX2plus using libata_promise, when it misses one
single interrupt (or maybe it's not even missed but only delayed), it
goes crazy, kernel log is full with disk failures, and the disk is
kicked out of the md(1) array grmbl.

This happens when amd76x_pm is used, even with the irq watcher in the
utter most conservative setting.

Any clue otherwise?


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2771 bytes --]