Following some patches to slightly adapt the PAT code.
patch 1 - enable PAT for all AMD CPUs that have the PAT feature flag set
patch 2 - fix up paranoia check in pat_init and fix the logic to
enable/disable PAT (IMHO the current code enables PAT on all
Transmeta and Centaur CPUs even if no PAT feature flag is set)
(I admit I should have changed the sequence of patches 1 and 2.)
patch 3 - fix some checkpatch errors
patch 4 - variable renaming
patch 5 - slightly changing the code that is doing the intersection of
pat_type and mtrr_type to be more readable (from my point of view)
Patches are against x86/pat (as of version v2.6.26-rc3-6-g46dd98a).
Please apply (at least patches 1 and 2).
Patches 3-5 are more a cleanup kind of thing.
Thanks.
Andreas
* Andreas Herrmann <[email protected]> wrote:
> Following some patches to slightly adapt the PAT code.
>
> patch 1 - enable PAT for all AMD CPUs that have the PAT feature flag set
> patch 2 - fix up paranoia check in pat_init and fix the logic to
> enable/disable PAT (IMHO the current code enables PAT on all
> Transmeta and Centaur CPUs even if no PAT feature flag is set)
> (I admit I should have changed the sequence of patches 1 and 2.)
> patch 3 - fix some checkpatch errors
> patch 4 - variable renaming
applied to tip/x86/pat, thanks Andreas. (i presume you'll send a
followup patch for the suggestions that came up in the discussion)
> patch 5 - slightly changing the code that is doing the intersection of
> pat_type and mtrr_type to be more readable (from my point of view)
>
> Patches are against x86/pat (as of version v2.6.26-rc3-6-g46dd98a).
#5 makes sense too, but it didnt apply cleanly:
Applying patch
patches/pat-x86-pat-make-pat-x-mtrr-type-more-readable.patch
patching file arch/x86/mm/pat.c
Hunk #1 FAILED at 185.
1 out of 1 hunk FAILED -- rejects in file arch/x86/mm/pat.c
(it didnt apply neither against tip/x86/pat or tip/master, nor against
linus/master. I guess it's some mixup somewhere.)
Ingo
On Thu, Jun 12, 2008 at 10:10:29AM +0200, Ingo Molnar wrote:
>
> * Andreas Herrmann <[email protected]> wrote:
>
> > Following some patches to slightly adapt the PAT code.
> >
> > patch 1 - enable PAT for all AMD CPUs that have the PAT feature flag set
> > patch 2 - fix up paranoia check in pat_init and fix the logic to
> > enable/disable PAT (IMHO the current code enables PAT on all
> > Transmeta and Centaur CPUs even if no PAT feature flag is set)
> > (I admit I should have changed the sequence of patches 1 and 2.)
> > patch 3 - fix some checkpatch errors
> > patch 4 - variable renaming
>
> applied to tip/x86/pat, thanks Andreas. (i presume you'll send a
> followup patch for the suggestions that came up in the discussion)
Yes, I'll do.
> > patch 5 - slightly changing the code that is doing the intersection of
> > pat_type and mtrr_type to be more readable (from my point of view)
> >
> > Patches are against x86/pat (as of version v2.6.26-rc3-6-g46dd98a).
>
> #5 makes sense too, but it didnt apply cleanly:
That's odd. I've double checked it by doing a fresh
$ git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
$ git remote update
$ git checkout tip/x86/pat
and applying patches 1-5 in sequence without problems.
(Patches were taken from emails that arrived via my linux-kernel
subscription.) Probably your tip/x86/pat is not at
v2.6.26-rc3-6-g46dd98a?
When trying to apply the patches to tip/master I get rejects for
patches 3 and 5.
Hence I think creating my patches against a feature branch was not a
good idea.
> Applying patch
> patches/pat-x86-pat-make-pat-x-mtrr-type-more-readable.patch
> patching file arch/x86/mm/pat.c
> Hunk #1 FAILED at 185.
> 1 out of 1 hunk FAILED -- rejects in file arch/x86/mm/pat.c
>
> (it didnt apply neither against tip/x86/pat or tip/master, nor against
> linus/master. I guess it's some mixup somewhere.)
Ok, it's commit 282c454cd3a7041f59a37112bb2f82263bc38f6c which was not
contained in the tip/x86/pat branch. This means I have to adapt patch 5.
Finally a dumb question. What patches do you prefer?
Patches against feature branches (say tip/x86/foo), against tip/master
or against tip/auto-latest as described in your tip.git-Readme?
Thanks,
Andreas
* Andreas Herrmann <[email protected]> wrote:
> > > patch 5 - slightly changing the code that is doing the intersection of
> > > pat_type and mtrr_type to be more readable (from my point of view)
> > >
> > > Patches are against x86/pat (as of version
> > > v2.6.26-rc3-6-g46dd98a).
> >
> > #5 makes sense too, but it didnt apply cleanly:
>
> That's odd. I've double checked it by doing a fresh
>
> $ git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
> $ git remote update
> $ git checkout tip/x86/pat
>
> and applying patches 1-5 in sequence without problems.
> (Patches were taken from emails that arrived via my linux-kernel
> subscription.) Probably your tip/x86/pat is not at
> v2.6.26-rc3-6-g46dd98a?
it was there - but some other commit from upstream interfered.
> When trying to apply the patches to tip/master I get rejects for
> patches 3 and 5.
>
> Hence I think creating my patches against a feature branch was not a
> good idea.
it was a good idea - as that the final destination where the PAT patches
end up.
current tip/x86/pat head is:
tip/x86/pat 499f8f8: x86: rename pat_wc_enabled to pat_enabled
> > 1 out of 1 hunk FAILED -- rejects in file arch/x86/mm/pat.c
> >
> > (it didnt apply neither against tip/x86/pat or tip/master, nor against
> > linus/master. I guess it's some mixup somewhere.)
>
> Ok, it's commit 282c454cd3a7041f59a37112bb2f82263bc38f6c which was not
> contained in the tip/x86/pat branch. This means I have to adapt patch
> 5.
indeed. I cherry-picked this commit meanwhile into x86/pat.
> Finally a dumb question. What patches do you prefer? Patches against
> feature branches (say tip/x86/foo), against tip/master or against
> tip/auto-latest as described in your tip.git-Readme?
either is fine - but if you make specific topic updates it's best to do
them against the topic branch and we'll integrate them all together. If
in doubt, using tip/master doesnt hurt.
usually i do this: i update x86/pat, then i switch to 'master' and check
whether it all merges cleanly via 'git-merge x86/pat'.
when you switch to a topic branch, you might also want to update to the
latest linus tree via 'git-merge linus/master', to pick up all other
fixes as well. The topic branches always merge cleanly to linus-latest.
(we automate that - the x86/pat topic branch is not stale as its -rc3
base would suggest, there simply was no need to merge it to Linus-latest
up to now)
Ingo