> Eyal Lebedinsky wrote:
> FWIW, I'm shaking down a T'bird VIA VT8363 (no "A") Northbridge &
> VT82C686A (Southbridge). No HPT.
>
> I had terrible read errors on /dev/hda single UDMA66 (1 in 5 md5sums on
> an unmounted 1.5 GB partition was different) until I slowed the SDRAM
> down from the PC133 (it really is) down to PC100. CPU always 8.5*100.
> At least UDMA is still working, even if my RAM is decidedly slower.
Just for information, before christmas I took delivery of Asus A7V's using
same KT133 chipset using PC133 RAM, things seemed to install well, but I
found severe intermittent problems. I could cause kernel crashes and/or
lock ups related to heavy IDE and/or SCSI I/O activity. It cost me about a
man month in testing, and trouble shooting eliminating all probable and
possible causes. I eventually found that the system would run stably when
set to PC100, and I think the BIOS had changed to these defaults, without me
noticing. This confused things, as then I could not reliably reproduce the
problem. The RAM passed extensive testing with memtest86 at PC133.
The supplier ended up offering a swap to slightly slower PIIIs and Intel
chipset based boards. At the time, the KT133 chipset only seemed to have
favourable reviews, and the A7V was praised for speed and stability,
everywhere I could find.
Now months later LKML discusses all kinds of Via Chip Set problems, though
it's not clear from what I read that the KT133 is actually problematic.
It's so hard to get clear info on this, due to all possible errors and
mistakes that can be made, by a problem reporter. I was using 2.2 kernels,
so I don't think any of this is due to kernel-2.4 introducing new problems.
It may have been reported earlier on LKML, but I don't always get time to
browse the mail archives, and the list has far too much traffic, for me to
follow directly.
Perhaps there's a better info source for H/W testing, and problem reporting?
Magazines, and hardware review websites, just aren't doing the job, I
believe it is difficult for them to write -ve reviews, and they're often
using beta drivers etc. When vendors were ignoring security bug-traq
helped a lot.
What we really need is some kind of GPL thrash test program suite, on the
lines of BurnCPU and memtest, that really exposes flaws like APIC CRC
problems, UDMA bugs etc. May be then passing hardware configurations could
be certifed as Linux quality, rather than Windows quality, as reviewers seem
to willing to accept problems as being Win driver related, and they expect
to reboot anyway. The emphasis should be on correctness, and finding and
localising the cause of errors, though I suspect some kind of benchmarking
element, would make it sexy enough to be run by reviewers and testers at
hardware companies, to churn out numbers and charts.
So how many programs exist already, for hardware acceptance testing? How do
we show problems are not kernel related?
How long are we going to put up with wasting time and money on faulty
products?
Ranting!
Rob
--
=- To unsubscribe, email [EMAIL PROTECTED] with the -=
=- body of "unsubscribe linux-abit". -=
