Re: kmalloc zero size changes break i386

[Andi Kleen <ak@suse.de>]

On Thursday 19 July 2007 16:08:34 Pekka Enberg wrote:
> Hi Andi,
> 
> On 7/19/07, Andi Kleen <ak@suse.de> wrote:
> > qemu testing and booting test machines with i386 kernels wasn't very successfull
> > with recent git kernels. I got either BUGs because of failing sysfs initialization
> > or oopses in kmalloc, but no user land.
> >
> > I bisected it down to this commit.
> >
> > To reproduce: try to boot a 386 defconfig kernel, compiled with gcc 4.1, in qemu
> 
> [snip]
> 
> > 6cb8f91320d3e720351c21741da795fed580b21b is first bad commit
> > commit 6cb8f91320d3e720351c21741da795fed580b21b
> > Author: Christoph Lameter <clameter@sgi.com>
> > Date:   Tue Jul 17 04:03:22 2007 -0700
> >
> >     Slab allocators: consistent ZERO_SIZE_PTR support and NULL result semantics
> 
> I have i386 defconfig kernel + qemu + busybox userland image + GCC
> 4.1.2 booting ok here. Did you manage to capture the oops? 

The sysfs crashes are all over; the first I saw is the BUG_ON() in
kernel_param_sysfs_setup(); but it was changing during the bisect
and in other similar sysfs BUG_ON()s too.

During one bisect state I also had a crash in kmalloc itself. I right
now don't have it anymore; do you want me to restart the bisect go
recreate it?

x86-64 kernels BTW work just fine; just something seems to be broken
with i386.

Unfortunately newsetup seems to have broken argument passing to qemu
so it's a bit difficult to get more out of it.

> Is the 
> userland image available somewhere?

Userland is not reached yet. You can just use a dummy dd if=/dev/zero of=.... bs=1M count=1
file. 

-Andi