From: Adrian Bunk <bunk@stusta.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>,
Rene Herman <rene.herman@keyaccess.nl>,
Ingo Molnar <mingo@elte.hu>,
Linux Kernel <linux-kernel@vger.kernel.org>,
hpa@zytor.com, torvalds@linux-foundation.org,
akpm@linux-foundation.org, Pavel Machek <pavel@suse.cz>
Subject: Re: 2.6.26, PAT and AMD family 6
Date: Thu, 8 May 2008 01:09:42 +0300 [thread overview]
Message-ID: <20080507220942.GD14951@cs181133002.pp.htv.fi> (raw)
In-Reply-To: <alpine.LFD.1.10.0805072341210.3318@apollo.tec.linutronix.de>
On Wed, May 07, 2008 at 11:54:19PM +0200, Thomas Gleixner wrote:
> On Thu, 8 May 2008, Adrian Bunk wrote:
> > On Wed, May 07, 2008 at 10:52:36PM +0200, Thomas Gleixner wrote:
>...
> > > Also there is no downside on these older systems. They are fine with
> > > MTRRs and have been for years. We can revisit that once PAT support
> > > has stabilized.
> >
> > My comment was about:
> > "please try attach patch to see if duron support PAT."
>
> I know.
>
> > That information is for sure available.
>
> So you know where it is and you can confirm that it works fine ?
>
> Pointers please.
Rene testing the patch Yinghai Lu sent would can reveal reliably whether
it works fine for all Duron steppings?
> > > This feature and detection code is hard to clean up and definitely out
> > > of the scope of this patch.
> >
> > Did you even look at the commit we are discussing?
> >
> > It ***adds*** exactly the same code at three different places.
>
> Yes, I did. And it adds it for a fscking good reason.
>
> 1) two times in common.c due to the existing detection logic mess
> 2) once in the 64 bit version
>
> Again, this code is inherited and fragile mess, which can not be
> changed at will.
Please explain why having this code twice in arch/x86/kernel/cpu/common.c
should be safer than doing the logical thing of putting it into an own
function:
void clear_set_pat(struct cpuinfo_x86 *c)
{
clear_cpu_cap(c, X86_FEATURE_PAT);
switch (c->x86_vendor) {
case X86_VENDOR_AMD:
if (c->x86 >= 0xf && c->x86 <= 0x11)
set_cpu_cap(c, X86_FEATURE_PAT);
break;
case X86_VENDOR_INTEL:
if (c->x86 == 0xF || (c->x86 == 6 && c->x86_model >= 15))
set_cpu_cap(c, X86_FEATURE_PAT);
break;
}
}
> > >...
> > > > And this patch (by the author of the code himself) is the first time
> > > > where it breaks.
> > >
> > > Very interesting analysis. What broke ? This CPU was never in the set
> > > of supported ones at all.
> >
> > The patch in the email I answered to was broken since the author did
>
> "the author" has a name.
>
> > fall into his own trap by patching only one copy of his duplicated code.
>
> That's not a real good reason to yell at him.
>
> Yinghai wanted to help out and check with the reporter whether this CPU
> works with PAT or not.
>
> Yinghai made a mistake.
>
> You come along and ride a crusade against him for that. Very helpful.
I'm actually on a crusade against:
- the many empty or unusable commit descriptions that recently came
through the x86 tree
- the fact that Yinghai Lu ignored Pavel's valid commit to not do
copy&paste programming
> Thanks,
>
> tglx
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next prev parent reply other threads:[~2008-05-07 22:12 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-07 1:48 Rene Herman
2008-05-07 2:39 ` Yinghai Lu
2008-05-07 12:46 ` Undocumented and duplicated code Adrian Bunk
2008-05-07 13:14 ` Rene Herman
2008-05-07 20:52 ` 2.6.26, PAT and AMD family 6 Thomas Gleixner
2008-05-07 20:59 ` Pavel Machek
2008-05-07 21:10 ` Rene Herman
2008-05-07 21:41 ` Thomas Gleixner
2008-05-07 21:46 ` Adrian Bunk
2008-05-07 22:08 ` Thomas Gleixner
2008-05-07 22:29 ` Pavel Machek
2008-05-07 22:04 ` Rene Herman
2008-05-07 22:23 ` Rene Herman
2008-05-07 22:31 ` Yinghai Lu
2008-05-07 22:57 ` H. Peter Anvin
2008-05-08 0:02 ` Rene Herman
2008-05-08 0:03 ` H. Peter Anvin
2008-05-08 0:10 ` Rene Herman
2008-05-08 0:19 ` Linus Torvalds
2008-05-08 0:28 ` Rene Herman
2008-05-08 1:57 ` [PATCH] x86: introduce a new Linux defined feature flag for PAT support Rene Herman
2008-05-08 1:58 ` Linus Torvalds
2008-05-08 2:11 ` H. Peter Anvin
2008-05-08 2:17 ` Rene Herman
2008-05-08 2:24 ` Linus Torvalds
2008-05-08 2:28 ` H. Peter Anvin
2008-05-08 12:49 ` Thomas Gleixner
2008-05-08 13:08 ` Ingo Molnar
2008-05-08 16:44 ` H. Peter Anvin
2008-05-08 13:11 ` Adrian Bunk
2008-05-08 13:33 ` Thomas Gleixner
2008-05-08 14:44 ` Rene Herman
2008-05-08 14:53 ` Thomas Gleixner
2008-05-08 16:48 ` H. Peter Anvin
2008-05-08 16:53 ` Rene Herman
2008-05-08 2:04 ` [PATCH] x86: enable PAT support on AMD Duron model 7 Rene Herman
2008-05-08 2:08 ` Arjan van de Ven
2008-05-08 2:12 ` Rene Herman
2008-05-08 10:19 ` [PATCH] x86: introduce a new Linux defined feature flag for PAT support Andi Kleen
2008-05-08 12:40 ` Rene Herman
2008-05-08 13:39 ` Andi Kleen
2008-05-08 15:32 ` Alan Cox
2008-05-08 16:51 ` H. Peter Anvin
2008-05-08 0:21 ` 2.6.26, PAT and AMD family 6 Thomas Gleixner
2008-05-08 0:30 ` Rene Herman
2008-05-08 0:15 ` Linus Torvalds
2008-05-08 0:31 ` H. Peter Anvin
2008-05-08 10:14 ` Andi Kleen
2008-05-08 16:43 ` H. Peter Anvin
2008-05-07 21:23 ` Adrian Bunk
2008-05-07 21:54 ` Thomas Gleixner
2008-05-07 22:09 ` Adrian Bunk [this message]
2008-05-07 22:14 ` Pavel Machek
2008-05-07 22:22 ` Yinghai Lu
2008-05-07 22:37 ` Pavel Machek
2008-05-07 22:40 ` Yinghai Lu
2008-05-07 23:02 ` Pavel Machek
2008-05-07 23:02 ` Thomas Gleixner
2008-05-07 23:10 ` Pavel Machek
2008-05-07 23:46 ` Thomas Gleixner
2008-05-07 22:23 ` Yinghai Lu
2008-05-07 22:39 ` Pavel Machek
2008-05-07 22:45 ` Yinghai Lu
2008-05-07 23:06 ` Pavel Machek
2008-05-07 23:01 ` H. Peter Anvin
2008-05-07 22:26 ` Yinghai Lu
2008-05-07 22:30 ` Rene Herman
2008-05-07 22:58 ` Thomas Gleixner
2008-05-07 13:00 ` Rene Herman
2008-05-07 13:42 ` Arjan van de Ven
2008-05-07 14:09 ` Rene Herman
2008-05-07 14:24 ` Arjan van de Ven
2008-05-07 19:08 ` Rene Herman
2008-05-07 22:17 ` Arjan van de Ven
2008-05-07 19:39 ` Daniel Hazelton
2008-05-07 20:06 ` Rene Herman
2008-05-07 20:16 ` Yinghai Lu
2008-05-07 20:18 ` Yinghai Lu
2008-05-08 4:06 ` H. Peter Anvin
2008-05-07 20:44 matthieu castet
2008-05-07 20:46 ` matthieu castet
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=20080507220942.GD14951@cs181133002.pp.htv.fi \
--to=bunk@stusta.de \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pavel@suse.cz \
--cc=rene.herman@keyaccess.nl \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=yhlu.kernel@gmail.com \
/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
all inboxes | Powered by JetHome®