Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Petr Vandrovec]

On 19 Sep 01 at 17:31, Liakakis Kostas wrote:
> 
> It seems to fix the stability problem. We don;t know why, but
> experimetation shows that those _with_ the problem are relieved. This is
> fine! We are happy with it.
> 
> We write to a register marked as "don't write" by Via. This is potentialy 
> dangerous in ways we don't know yet.

Just small question - you are saying that your KT133A works fine with
0x89... Two questions then - Do you have more than 256MB in your box?
And second one: Do you have one, two, or three memory modules installed
on the board? 

If your answer is <=256MB, one module, no surprise then, as AFAIK nobody 
with such config suffers from the problem. But checking also number of 
memory modules looks more like black magic that anything else. 
Hopefully VIA will answer...
                                            Thanks,
                                                Petr Vandrovec
                                                vandrove@vc.cvut.cz
                                                

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Liakakis Kostas]

On Wed, 19 Sep 2001, Petr Vandrovec wrote:

> 
> Just small question - you are saying that your KT133A works fine with
> 0x89... Two questions then - Do you have more than 256MB in your box?

Right.

> And second one: Do you have one, two, or three memory modules installed
> on the board? 

3 x 256MB double sided, unbuffered and -guess what- no-name.

> If your answer is <=256MB, one module, no surprise then, as AFAIK nobody 
> with such config suffers from the problem. But checking also number of 
> memory modules looks more like black magic that anything else. 
> Hopefully VIA will answer...

/me hopes too.

-K.

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Gergely Tamas]

Hi!

 > If your answer is <=256MB, one module, no surprise then, as AFAIK nobody
 > with such config suffers from the problem. But checking also number of
 > memory modules looks more like black magic that anything else.
 > Hopefully VIA will answer...

Not exactly. I can report about two different machines - my home one, and
one here at workplace - which hit this bug. Linux even does not start on
them with 3R. Both of them have got 256 Mb, one module. This fix helps for
both of them.

Gergely

ps: ABIT KT7A, Duron 750MHz, 256Mb (one module)

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Luigi Genoni]

3R was not working for me too, 3C is well working, actually.

Luigi
On Wed, 19 Sep 2001, Gergely Tamas wrote:

> Hi!
>
>  > If your answer is <=256MB, one module, no surprise then, as AFAIK nobody
>  > with such config suffers from the problem. But checking also number of
>  > memory modules looks more like black magic that anything else.
>  > Hopefully VIA will answer...
>
> Not exactly. I can report about two different machines - my home one, and
> one here at workplace - which hit this bug. Linux even does not start on
> them with 3R. Both of them have got 256 Mb, one module. This fix helps for
> both of them.
>
> Gergely
>
> ps: ABIT KT7A, Duron 750MHz, 256Mb (one module)
>
> -
> 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/
>

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Luigi Genoni]

On Wed, 19 Sep 2001, Petr Vandrovec wrote:

> On 19 Sep 01 at 17:31, Liakakis Kostas wrote:
> >
> > It seems to fix the stability problem. We don;t know why, but
> > experimetation shows that those _with_ the problem are relieved. This is
> > fine! We are happy with it.
> >
> > We write to a register marked as "don't write" by Via. This is potentialy
> > dangerous in ways we don't know yet.
>
> Just small question - you are saying that your KT133A works fine with
> 0x89... Two questions then - Do you have more than 256MB in your box?
> And second one: Do you have one, two, or three memory modules installed
> on the board?
>
> If your answer is <=256MB, one module, no surprise then, as AFAIK nobody
> with such config suffers from the problem. But checking also number of
> memory modules looks more like black magic that anything else.
> Hopefully VIA will answer...
Just to add a curiosity. Abit KT7A MBs do not accept all 256 MB modules.
with some of them they do see just 128 MB, and anyway systems are stable,
but of course systems managers get unhappy.
This should be because of modules density...

OK, this was OT but maybe some of you had this experience.

Luigi

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[john slee]

On Thu, Sep 20, 2001 at 01:07:29AM +0200, Luigi Genoni wrote:
> Just to add a curiosity. Abit KT7A MBs do not accept all 256 MB modules.
> with some of them they do see just 128 MB, and anyway systems are stable,
> but of course systems managers get unhappy.
> This should be because of modules density...

bx chipsets have a limitation of 128mb per bank for non-registered dimms
afaik.  ie. 256mb dimms that are two-bank will work as expected, and
256mb dimms that are one-bank will be seen as 128mb.  generally two-bank
256mb dimms have chips on both sides of the module, whereas one-bank
jobbies have it on one side...  found this out the expensive way :-(

of course this isnt relevant to abit kt7 boards but it does sound very
similar.

j.

-- 
R N G G   "Well, there it goes again... And we just sit 
 I G G G   here without opposable thumbs." -- gary larson

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Gábor Lénárt]

BTW ...
When I switched to Duron with a new (well, it was my friend's) motherboard
(according to lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)),
I can't boot Linux anymore since it stucked around partiotion checking (sorry
I don't remember, but I can check on the next week). It was kernel 2.2.19.
2.4.x works without any problem, the last kernel I've checked (and using now)
is 2.4.9. Is it the same problem?


On Wed, Sep 19, 2001 at 04:59:09PM +0000, Petr Vandrovec wrote:
> On 19 Sep 01 at 17:31, Liakakis Kostas wrote:
> > 
> > It seems to fix the stability problem. We don;t know why, but
> > experimetation shows that those _with_ the problem are relieved. This is
> > fine! We are happy with it.
> > 
> > We write to a register marked as "don't write" by Via. This is potentialy 
> > dangerous in ways we don't know yet.
> 
> Just small question - you are saying that your KT133A works fine with
> 0x89... Two questions then - Do you have more than 256MB in your box?
> And second one: Do you have one, two, or three memory modules installed
> on the board? 
> 
> If your answer is <=256MB, one module, no surprise then, as AFAIK nobody 
> with such config suffers from the problem. But checking also number of 
> memory modules looks more like black magic that anything else. 
> Hopefully VIA will answer...
>                                             Thanks,
>                                                 Petr Vandrovec
>                                                 vandrove@vc.cvut.cz
>                                                 
> -
> 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/

-- 
 --[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]---------[ lgb@lgb.hu ]--
 U have 8 bit comp or chip of them and it's unused or to be sold? Call me!
 -------[ +36 30 2270823 ]------> LGB <-----[ Linux/UNIX/8bit 4ever ]-----

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Petr Vandrovec]

On 19 Sep 01 at 11:43, Dan Hollis wrote:
> On Wed, 19 Sep 2001, Linus Torvalds wrote:
> > It is _probably_ an undocumented performance thing, and clearing that
> > bit may slow something down. But it might also change some behaviour,
> > and knowing _what_ the behaviour is might be very useful for figuring
> > out what it is that triggers the problem.
> 
> AFAIK noone has even tested it yet to see what it does to performance! Eg
> it might slow down memory access so that athlon-optimized memcopy is now
> slower than non-athlon-optimized memcopy. And if it turns out to be the
> case, we might as well just use the non-athlon-optimized memcopy instead
> of twiddling undocumented northbridge bits...

No, we cannot. On boxes which do not work with athlon optimized kernels
any user can execute athlon's fast_page_copy from userspace, causing
corruption on completely unrelated pages, eventually leading to
kernel crash... So you cannot allow untrusted users on such machine.
                                                Best regards,
                                                    Petr Vandrovec
                                                    vandrove@vc.cvut.cz
                                                    

Re: [PATCH] Athlon bug stomper. Pls apply.

[Liakakis Kostas]

Please consider making it a configurable option. 

My Asus A7V133 runs perfectly well with 55.7=1 and so does at least
another mobo brand that was reported here. If it can work out of the box,
leave it that way. Since this register is undocumented the patch below is
a hack. Sure it works on people hitting the problem but it is still a
hack. As such I don't want to use it if I don't have to.

-K.


On Tue, 18 Sep 2001, VDA wrote:

> Hi Linus, Alan,
> 
> Since we don't have any negative feedback on Athlon bug
> stomper, I think patch could be applied to
> arch/i386/kernel/pci-pc.c in mainline kernel.
> Diffed against 4.2.9.
[patch snipped]

Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[VDA]

Wednesday, September 19, 2001, 12:39:07 AM,
Liakakis Kostas <kostas@skiathos.physics.auth.gr> wrote:

LK> Please consider making it a configurable option. 

LK> My Asus A7V133 runs perfectly well with 55.7=1 and so does at least
LK> another mobo brand that was reported here. If it can work out of the box,
LK> leave it that way. Since this register is undocumented the patch below is
LK> a hack. Sure it works on people hitting the problem but it is still a
LK> hack. As such I don't want to use it if I don't have to.

Look into pci-pc.c amd quirks.c: do you want to make all those
config options too?

Also, do you want people to spend days finding out why their
once stable system with their brand new, faster processor
started to oops, finally giving up and posting about this to lkml?
-- 
Best regards, VDA
mailto:VDA@port.imtp.ilyichevsk.odessa.ua
http://port.imtp.ilyichevsk.odessa.ua/vda/

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Liakakis Kostas]

I am just opposing to be forced to use a fix when a fix isn't really
needed on my setup.


On Wed, 19 Sep 2001, VDA wrote:

> Look into pci-pc.c amd quirks.c: do you want to make all those
> config options too?

I will, and if I find something done not needed I might complain again.

> Also, do you want people to spend days finding out why their
> once stable system with their brand new, faster processor
> started to oops, finally giving up and posting about this to lkml?

I dont suppose it will take more than an hour for somebody to notice that
under the "Optimized for K7" option there is another called "Enable 55.7=0
fix for K7 that oops all over the place"

Please calm down. I never suggested your fix is wrong. It was a long
awaited one indeed. I only suggested that it be applied wherever it needs
to be, not blindly whenever a KT133/A setup is seen.

If you don't agree with my view, just say why, don't go arround mocking me
about it.

-K.

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Thomas Langås]

Liakakis Kostas:
> Please calm down. I never suggested your fix is wrong. It was a long
> awaited one indeed. I only suggested that it be applied wherever it needs
> to be, not blindly whenever a KT133/A setup is seen.

If this should be an optional fix, it should be default enabled, and then
all those who don't want to use the fix, should disable it. But I guess, as
long as it's an option, someone is _bound_ to come naging with their
problems...

-- 
Thomas

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Liakakis Kostas]

Think again.

It seems to fix the stability problem. We don;t know why, but
experimetation shows that those _with_ the problem are relieved. This is
fine! We are happy with it.

We write to a register marked as "don't write" by Via. This is potentialy 
dangerous in ways we don't know yet.


> If this should be an optional fix, it should be default enabled, and then
> all those who don't want to use the fix, should disable it. But I guess, as
> long as it's an option, someone is _bound_ to come naging with their
> problems...

How can you know you need it if it is enabled by default. I see many more
ppl just not being bothered enough to check. 

And then, would you prefer having somebody naging about, say, his
northbirdge melting down after 10mins with K7 optimizations enabled?

-K.

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Jan Niehusmann]

On Wed, Sep 19, 2001 at 05:31:36PM +0300, Liakakis Kostas wrote:
> It seems to fix the stability problem. We don;t know why, but
> experimetation shows that those _with_ the problem are relieved. This is
> fine! We are happy with it.
> 
> We write to a register marked as "don't write" by Via. This is potentialy 
> dangerous in ways we don't know yet.

Additionally, look at who tested the 'fix' up to now: Probably only
people who had a problem before. And for all of them, the problem got
fixed. But do we know what happens if we use this 'fix' on a computer
that is not broken? No. Perhaps it breaks when we apply the 'fix'?

OTOH, I think there are only two ways to find out: Either we put the
'fix' into a mainline kernel (linux -pre kernel or -ac kernel should
be enough) as a default and look if somebody starts complaining, or
we convince VIA to tell us what the register in question really does.

Jan

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Liakakis Kostas]

On Wed, 19 Sep 2001, Jan Niehusmann wrote:

> OTOH, I think there are only two ways to find out: Either we put the
> 'fix' into a mainline kernel (linux -pre kernel or -ac kernel should
> be enough) as a default and look if somebody starts complaining, or
> we convince VIA to tell us what the register in question really does.

*nod*

Alan said he could squeeze some info out of VIA. Any news yet?

-K.

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Alan Cox]

> On Wed, 19 Sep 2001, Jan Niehusmann wrote:
> 
> > OTOH, I think there are only two ways to find out: Either we put the
> > 'fix' into a mainline kernel (linux -pre kernel or -ac kernel should
> > be enough) as a default and look if somebody starts complaining, or
> > we convince VIA to tell us what the register in question really does.
> 
> *nod*
> 
> Alan said he could squeeze some info out of VIA. Any news yet?

I've been busy working on other things, and being ill. I've not yet pursued
it with them

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Linus Torvalds]

In article <20010919165503.A16359@gondor.com>,
Jan Niehusmann  <jan@gondor.com> wrote:
>
>Additionally, look at who tested the 'fix' up to now: Probably only
>people who had a problem before. And for all of them, the problem got
>fixed. But do we know what happens if we use this 'fix' on a computer
>that is not broken? No. Perhaps it breaks when we apply the 'fix'?

This is my personal main worry.

The problem with things like these is that people for whom the old code
works fine don't tend to be interested in "fixes" floating around on the
net - whether it is for Athlon chipset problems or for driver bugs or
anything else.

Which means that the "statistical sampling" is very skewed by
self-selection, and anybody who knows anything about statistics knows
that sample selection is _very_ important.

Right now, for example, I'm leaning towards applying the patch, but
quite frankly I'm still not certain.  Getting _some_ kind of information
out of VIA would be really good - even just an ACK from somebody who is
under NDA and can say just "yes, it's safe to clear bit 7 of reg 0x55". 

It is _probably_ an undocumented performance thing, and clearing that
bit may slow something down. But it might also change some behaviour,
and knowing _what_ the behaviour is might be very useful for figuring
out what it is that triggers the problem.

			Linus

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[safemode]

It works fine on the KX133 chipset that is on the Abit KA7 motherboard.  So, 
i for one have not applied the patch. 


On Wednesday 19 September 2001 12:00, Linus Torvalds wrote:
> In article <20010919165503.A16359@gondor.com>,
>
> Jan Niehusmann  <jan@gondor.com> wrote:
> >Additionally, look at who tested the 'fix' up to now: Probably only
> >people who had a problem before. And for all of them, the problem got
> >fixed. But do we know what happens if we use this 'fix' on a computer
> >that is not broken? No. Perhaps it breaks when we apply the 'fix'?
>
> This is my personal main worry.
>
> The problem with things like these is that people for whom the old code
> works fine don't tend to be interested in "fixes" floating around on the
> net - whether it is for Athlon chipset problems or for driver bugs or
> anything else.
>
> Which means that the "statistical sampling" is very skewed by
> self-selection, and anybody who knows anything about statistics knows
> that sample selection is _very_ important.
the only way it'll get a good sampling is to put it in the kernel 
I suggest not adding this to the "athlon" cpu selection code.  Rather make it 
a sub-option like many other drivers have.  That way people can select 
whether they need it or not until we are sure it's totally safe for everyone 
to use it by Via saying so or something.   Just a suggestion, other drivers 
do the same thing, so why not the cpu selection screen for workarounds. 


>
> Right now, for example, I'm leaning towards applying the patch, but
> quite frankly I'm still not certain.  Getting _some_ kind of information
> out of VIA would be really good - even just an ACK from somebody who is
> under NDA and can say just "yes, it's safe to clear bit 7 of reg 0x55".
>

> It is _probably_ an undocumented performance thing, and clearing that
> bit may slow something down. But it might also change some behaviour,
> and knowing _what_ the behaviour is might be very useful for figuring
> out what it is that triggers the problem.
>
> 			Linus
> -
> 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/

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Nicholas Knight]

On Wednesday 19 September 2001 10:15 am, safemode wrote:
> It works fine on the KX133 chipset that is on the Abit KA7 motherboard.
>  So, i for one have not applied the patch.

That would be because the bug is specific to the KT133A chipset...

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Marek Mentel]

On Wed, 19 Sep 2001 16:41:45 -0700, Nicholas Knight wrote:

>On Wednesday 19 September 2001 10:15 am, safemode wrote:
>> It works fine on the KX133 chipset that is on the Abit KA7 motherboard.
>>  So, i for one have not applied the patch.
>
>That would be because the bug is specific to the KT133A chipset...

 and KT133E -   which is KT133  made  in 0.18 technology AFAIR
--------------------------------------------------------
 Marek Mentel  mmark@koala.ichpw.zabrze.pl  2:484/3.8          
 INSTITUTE FOR CHEMICAL PROCESSING OF COAL , Zabrze , POLAND
 NOTE: my opinions are strictly my own and not those of my employer

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Dan Hollis]

On Wed, 19 Sep 2001, Linus Torvalds wrote:
> It is _probably_ an undocumented performance thing, and clearing that
> bit may slow something down. But it might also change some behaviour,
> and knowing _what_ the behaviour is might be very useful for figuring
> out what it is that triggers the problem.

AFAIK noone has even tested it yet to see what it does to performance! Eg
it might slow down memory access so that athlon-optimized memcopy is now
slower than non-athlon-optimized memcopy. And if it turns out to be the
case, we might as well just use the non-athlon-optimized memcopy instead
of twiddling undocumented northbridge bits...

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Roberto Jung Drebes]

On Wed, 19 Sep 2001, Dan Hollis wrote:

> AFAIK noone has even tested it yet to see what it does to performance! Eg
> it might slow down memory access so that athlon-optimized memcopy is now
> slower than non-athlon-optimized memcopy. And if it turns out to be the
> case, we might as well just use the non-athlon-optimized memcopy instead
> of twiddling undocumented northbridge bits...

How can I test it? Can someone point me to a simple program to do it? Then
I could run it over the non-optimized, the optimized in the good bios and
the optimized in the bad bios plus patch to test it.

Altough my system shows the bug, I am not sure if we should add the patch
as the default option right now. Actually, we don´t have a clue if the
only thing this bit is doing is solving the bug or if it is going to be
responsible for an unknown and unnoticed bug that will show up later. Why
rush things up? Can´t we wait a word from VIA and then decide what to
do? What could be done is to put this patch somewhere other than the list
where we can point people that come to lkml with this problem to.

--
Roberto Jung Drebes <drebes@inf.ufrgs.br>
Porto Alegre, RS - Brasil
http://www.inf.ufrgs.br/~drebes/

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Pavel Machek]

Hi!

> > It is _probably_ an undocumented performance thing, and clearing that
> > bit may slow something down. But it might also change some behaviour,
> > and knowing _what_ the behaviour is might be very useful for figuring
> > out what it is that triggers the problem.
> 
> AFAIK noone has even tested it yet to see what it does to performance! Eg
> it might slow down memory access so that athlon-optimized memcopy is now
> slower than non-athlon-optimized memcopy. And if it turns out to be the
> case, we might as well just use the non-athlon-optimized memcopy instead
> of twiddling undocumented northbridge bits...

And if someone does optimized copy in userspace, whole machine is dead?

Do you really wnt me to post bugtraq?

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Nicholas Knight]

On Wednesday 19 September 2001 09:00 am, Linus Torvalds wrote:
> In article <20010919165503.A16359@gondor.com>,

>
> Right now, for example, I'm leaning towards applying the patch, but
> quite frankly I'm still not certain.  Getting _some_ kind of
> information out of VIA would be really good - even just an ACK from
> somebody who is under NDA and can say just "yes, it's safe to clear bit
> 7 of reg 0x55".
>

Is there an way someone could find out what Windows, possibly with VIA's 
4-in-1 drivers, do with this bit? And for that matter, what the test 
program that tests it regardless of kernel optimizations does in Windows, 
if it can be ported?

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Liakakis Kostas]

On Wed, 19 Sep 2001, Nicholas Knight wrote:

> Is there an way someone could find out what Windows, possibly with VIA's 
> 4-in-1 drivers, do with this bit? And for that matter, what the test 
> program that tests it regardless of kernel optimizations does in Windows, 
> if it can be ported?

Win2k, Via4132. They leave it alone ax 0x89. Asus A7V133, Athlon TB 1.4-C

-K.

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Luigi Genoni]

On Wed, 19 Sep 2001, Jan Niehusmann wrote:

> On Wed, Sep 19, 2001 at 05:31:36PM +0300, Liakakis Kostas wrote:
> > It seems to fix the stability problem. We don;t know why, but
> > experimetation shows that those _with_ the problem are relieved. This is
> > fine! We are happy with it.
> >
> > We write to a register marked as "don't write" by Via. This is potentialy
> > dangerous in ways we don't know yet.
>
> Additionally, look at who tested the 'fix' up to now: Probably only
> people who had a problem before. And for all of them, the problem got
> fixed. But do we know what happens if we use this 'fix' on a computer
> that is not broken? No. Perhaps it breaks when we apply the 'fix'?
No, it won't break.  I tried this patch on an Athlon 1300 Mhz 200 FSB,
that has worked with athlon optimizzed kernels without any problems, and
it still works. I did this just for curiosity, and i was
avoiding to post a long series of it works for me too, since I have just
abit MBs, and before the patch was out I just putted a working bios on
every MB.  Anyway I tried the patch on working Athlon.

And let's try to get VIA to tell us what is going on....

bests
Luigi

Re: Re[2]: [PATCH] Athlon bug stomper. Pls apply.

[Tom Diehl]

On Wed, 19 Sep 2001, Liakakis Kostas wrote:

>
> I am just opposing to be forced to use a fix when a fix isn't really
> needed on my setup.

If it causes no performance hit I do not see the problem. Since I have
not seen all of this thread I have to ask what is/are the downsides to
blindly enabling this? What are the real concerns? If the concern is
just to keep your machine "factory fresh" do you have anything that says
this is not just a screw up on the bios writers part? Look at all of the
known and documented BIOS bugs there are.

> On Wed, 19 Sep 2001, VDA wrote:
>
> > Look into pci-pc.c amd quirks.c: do you want to make all those
> > config options too?
>
> I will, and if I find something done not needed I might complain again.

You are free to modify things to your preferences. I think the real point
is to fix it for the largest possible audience. Making it a compile option
IMO serves no real benefit and has some potential rather large downsides.
People like to fiddle. If someone turns it off and does not know what they
are doing the next thing you know is they are complaining here about something
that they should not be playing with anyway.

> > Also, do you want people to spend days finding out why their
> > once stable system with their brand new, faster processor
> > started to oops, finally giving up and posting about this to lkml?
>
> I don't suppose it will take more than an hour for somebody to notice that
> under the "Optimized for K7" option there is another called "Enable 55.7=0
> fix for K7 that oops all over the place"

Depends on the skill set that person possesses. some people will find it
some will not. Murphy definitely will be at work here.

Enjoy,

-- 
......Tom		BLAME: The Secret To Success is Knowing who
tdiehl@rogueind.com	to Blame for Your Failures.