Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [PATCH] x86 NUMA panic compile error | Date | Mon, 15 May 2006 20:13:53 +0200 |
| |
On Monday 15 May 2006 20:08, Andrew Morton wrote: > Ingo Molnar <mingo@elte.hu> wrote: > > > > > > * Andy Whitcroft <apw@shadowen.org> wrote: > > > > > if (use_cyclone == 0) { > > > /* Make sure user sees something */ > > > - static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else." > > > + static const char s[] __initdata = "Not an IBM x440/NUMAQ. Don't use i386 CONFIG_NUMA anywhere else."; > > > early_printk(s); > > > panic(s); > > > } > > > > i still strongly oppose the original Andi hack... numerous reasons were > > given not to apply it (it's nice to simulate/trigger rarer features on > > mainstream hardware too, and this ability to boot NUMA on my flat x86 > > testbox found at least one other NUMA bug already). Furthermore, the > > crash i reported was fixed by the NUMA patchset. > > I'll be darned. I never knew it was even possible to run x86 numa kernels > on non-numa boxen. I'd have tested about 1000000 of Christoph Lameter's > patches if someone had told me. Yes, it's useful.
If you want to use it for that I would suggest to port the numa emulation code at least - two or four nodes tends to find more problems than a single node.
But testing on a 64bit box - even with numa emulation - would be much better because on 32bit ZONE_NORMAL often is node 0 only and you won't get much numaness for kernel objects.
> > > Andrew, please drop: > > > > x86_64-mm-i386-numa-summit-check.patch > > bang.
Ok.
> > > (which has nothing to do with x86_64 anyway) > > True. > > I guess the concern here is that we don't want people building these > frankenkernels and then sending us bug reports against them.
Well it will still increase the bug numbers you care so much about.
Another reason I don't like it is that it's ugly and reimplements parts of ACPI on its own for no reason.
If people use it regularly for debugging maybe it won't bit rot as quickly as it used to be, but there is a big difference between theory and practice so we'll see.
> So it is perhaps reasonable to do this panic, but only if !CONFIG_EMBEDDED? > (It really is time to start renaming CONFIG_EMBEDDED to CONFIG_DONT_DO_THIS > or something).
Fine.
-Andi - 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/
| |