I'm going to give it until tonight before I really give up on this, but
right now the only real explination I have is that the KT133A chipset is
buggy, but not constistantly buggy, and that there's not a whole lot that
can be done about it.
Robert might turn something up with his MMX2 programs, from what David
Hollister said yesterday, it sounds like he may be on to something, I'm
no developer, my C consists of being able to use "printf("Hello
World!\n");", and I know absilutely no asm, so I can't contribute
anything on that front.
There's really four options that I can see if the burnMMX2 programs don't
turn anything up:
1. If it says KT133A, activate code that disables the relevant
optimizations.
2. Spend a lot of time getting detailed, exact information from users
about what exactly their board is reporting and wether or not they have
problems, so that detailed information can be used to determine wether or
not to shut off instructions as in #1. This is obviously the cleaner
solution, but it's a lot of effort for a single buggy chipset. We'd need
at least 150-200 reports to have semi-reliable data for something like
this, and it may turn out that there's nothing that can be isolated well
enough to justify this.
3. Do nothing, and advise users in the help to select i686 or K6-2/3 if
they have problems with K7/Athlon optimizations.
4. Add a config option that only shows up if someone selects K7/Athlon,
something to the effect of "Disable buggy optimizations for KT133A
chipset." And have it selected by default, and advise users in help about
what the problem is, and that they can try turning this off, but that it
may not work if they do.
Personaly I'd prefer option #4. #2 would be even better, but again,
that'll take a lot of time for a single chipset. I've only gotten 25 or
so reports, and the only thing they did was give me 3 or 4 theories that
all turned out to be fairly wrong.
BIOS versions are still a candidate, as some people ARE reporting that
they make a difference. If users having problems want something to try,
try Award V2.8 BIOS if avalible for your board. Gerbrand van der Zouw
reports stability with it and Kurt's patch, I don't know if he's tried it
without the patch, and I don't know what the patch does.
If burnMMX2 and variants turn something up, this is obviously all moot,
and hopefully something could be done to actually FIX the problem instead
of putting a band-aid(TM) over it.
Does anyone have any contacts at VIA that might actually be interested in
getting this fixed?
-
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/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:40 EST