lkml.org 
[lkml]   [2010]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [stable] [113/197] x86, cacheinfo: Calculate L3 indices
From: Jiri Kosina <jkosina@suse.cz>
Date: Thu, May 13, 2010 at 01:26:15AM -0400

> On Wed, 12 May 2010, H. Peter Anvin wrote:
>
> > >>> So if K8_NB has failed initializing for some reason, we never go near
> > >>> the pci devs and the node_to_k8_nb_misc() calls since we effectively
> > >>> disable the L3 functionality.
> > >>>
> > >>> Thus the NULL pointer checks you remove in the patch below are
> > >>> superfluous, I agree, and I have already removed those in my tree along
> > >>> with the other improvements/fixes I'm working on right now.
> > >>
> > >> So, was there ever a patch applied that fixed the bug that Jiri found in
> > >> the stable kernels with this original patch that I could apply?
> > >>
> > >
> > > Sounds like this patch in -tip should be promoted to mainline/stable...
> > > could the AMD people please confirm?
> > >
> >
> > Specifically, "waiting to hit mainline" is not an option since they are
> > currently queued for .35, but we need a minimal fix in .34 -- this is
> > the "stable backport". If this "stable backport" is simply a subset of
> > the patch series then let me know which ones should be moved to urgent
> > and sent to Linus immediately. I obviously don't have access to a setup
> > which can replicate this particular problem.
>
> One is already there -- 0e152cd7c16832bd5cadee0c2e41d9959bc9b6f9. This
> particular one solely was enough to fix the problem I have been hitting.
>
> Plus there is f2b20e41407fccfcf ("x86, cacheinfo: Turn off L3 cache
> index disable feature in virtualized environments") in -tip tree, which
> fixes a crash of similar nature I have been seeing on bare metal, but for
> virtualized environments.
> This one might be considered for .34/stable still.

Correct, so 0e152cd7c16832bd5cadee0c2e41d9959bc9b6f9 is in mainline and
makes sure we cache the k8 northbridges before using them in other code
and f2b20e41407fccfcf is an early-exit kludge in case we're running
as a guest and we get no northbirdge PCI devices exported from the
hypervisor.

And Peter you're right, "waiting for mainline" is not an excuse here,
the last one (f2b20e41407fccfcf) should've been sent to Linus right
away. However, he said -rc7 is gonna be the last one so I'm hoping
there's still time to get it in.

Thanks.

--
Regards/Gruss,
Boris.

--
Advanced Micro Devices, Inc.
Operating Systems Research Center



\
 
 \ /
  Last update: 2010-05-13 09:03    [W:0.140 / U:2.280 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site