[lkml]   [2002]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: Via KT133 pci corruption: stock 2.4.18pre2 oopses as well
> Nice, yet one more variable to the equation ;). And I thought 
> I could rule out kernel bugs by reproducing this on
> supposedly stable kernel (the 2.2.20 I used had all sort of
> patches in it; ide, e2compr and raid to name the largest ones.)
> This could be a sync_page_buffers() bug, but what puzzles me
> is that I can reproduce the oopses on 2.2 as well (although
> they can of course be different oopses).
> Also, I'm seeing ide and network corruption that would very
> much point to pci transfer corruption. Of course, it can be
> that the oopses are not caused by that.

>From what I've read, it looks like there can be issues with the VIA
KT133 PCI implementation, possibly applying to other VIA chipsets too.

Master memory reads can talk 45 cycles rather than 16 (the max defined
in the PCI spec) - this sounds like it could be due to either a) bad
motherboard design with signal problems, or b) BIOS chipset
configuration (try setting 'PCI master read caching' to on?). This is
since problems have been reported with different make motherboards using
the same chipset, and those being the only two factors differing.

Of course, this may well not help if it is geniunely a bug in the
kernel, but may solve the PCI corruption (if any).

Also, if it is a chipset issue, updating the BIOS can help at times,
with the vendor incorporating work-arounds for known chipset problems
(eg the well-publicised IDE corruption issue).

Daniel J Blueman

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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