Messages in this thread | | | Date | Wed, 9 Aug 2006 15:21:22 +0200 | From | "Michal Piotrowski" <> | Subject | Re: mm snapshot broken-out-2006-08-08-00-59.tar.gz uploaded |
| |
Hi,
On 09/08/06, Ravikiran G Thirumalai <kiran@scalex86.org> wrote: > On Tue, Aug 08, 2006 at 04:42:10PM -0700, Andrew Morton wrote: > > On Wed, 9 Aug 2006 00:11:38 +0200 > > "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote: > > > > ah-hah, thanks. The oopsing statement was added by > > slab-fix-lockdep-warnings.patch. > > > > I guess we can fix this by whacking another #ifdef CONFIG_NUMA in there but > > I don't think that's how we want to address this. > > > > We've been moving towards making the NUMA slab code work OK in a non-NUMA > > build by setting the NUMA-specific fields to NULL and simply blowing a few > > cycles at runtime to avoid many tens of ifdefs (it's that bad). > > > > Here, we should have had either l3==NULL or l3->alien==NULL, but that has > > been violated, hence the crash. > > Kiran, could you take a look please? The 0x01020304 is interesting... > > Eeesh, because on SMP, alloc_alien_cache returns 0x01020304 instead of > NULL, And it returns 0x01020304 because CPU_UP_PREPARE fails if > alloc_alien_cache returns NULL. NUMA and non NUMA slab should be able to > work even without alien caches, currently that doesn't seem to be the case. > We are working on that. In the meanwhile, the following patch should > fix the oops due to locdep annotation. > > Thanks, > Kiran > > Fix oops due to alien cache locdep annotation on non NUMA configurations. > A plain alien != NULL won't work as l3->alien is initialized with > 0x01020304ul
Bug fixed, thanks.
Regards, Michal
-- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/) - 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/
| |