From: "Daniel J Blueman" <daniel.blueman@btinternet.com>
To: "'Ville Herva'" <vherva@niksula.hut.fi>,
"'Andrew Morton'" <akpm@zip.com.au>
Cc: <linux-kernel@vger.kernel.org>,
"'Jani Forssell'" <jani.forssell@viasys.com>
Subject: RE: Via KT133 pci corruption: stock 2.4.18pre2 oopses as well
Date: Wed, 9 Jan 2002 23:33:28 -0000 [thread overview]
Message-ID: <001001c19966$0af99fd0$0100a8c0@icarus> (raw)
In-Reply-To: <20020109235722.L1200@niksula.cs.hut.fi>
> 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.
[snip]
>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).
Dan
___________________
Daniel J Blueman
next prev parent reply other threads:[~2002-01-09 23:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-08 19:58 2.2.21pre2 oops Ville Herva
2002-01-08 20:16 ` Alan Cox
2002-01-08 20:13 ` Ville Herva
2002-01-09 12:45 ` Ville Herva
2002-01-09 15:26 ` Via KT133 pci corruption: stock 2.4.18pre2 oopses as well Ville Herva
2002-01-09 21:00 ` Andrew Morton
2002-01-09 21:57 ` Ville Herva
2002-01-09 23:30 ` Martin Josefsson
2002-01-10 0:19 ` Daniel J Blueman
2002-01-10 0:41 ` Martin Josefsson
2002-01-10 1:04 ` Daniel J Blueman
2002-01-10 5:34 ` Ville Herva
2002-01-10 12:01 ` Henrique de Moraes Holschuh
2002-01-10 12:56 ` Martin Josefsson
2002-01-10 13:37 ` Ville Herva
2002-01-09 23:33 ` Daniel J Blueman [this message]
2002-01-10 6:34 ` Ville Herva
2002-01-10 6:40 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001001c19966$0af99fd0$0100a8c0@icarus' \
--to=daniel.blueman@btinternet.com \
--cc=akpm@zip.com.au \
--cc=jani.forssell@viasys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vherva@niksula.hut.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox