2.6.10rc3+cset == oops (fs).

2.6.10rc3+cset == oops (fs).

[Paweł Sikora]

Hi,

I've just tried to boot the 2.6.10rc3+cset20041210_0507.

[handcopy of the ooops]

dereferencing null pointer
eip at: radix_tree_tag_clear

trace:
(...)
test_clear_page_dirty
truncate_complete_page
truncate_inode_pages_range
truncate_inode_pages
generic_delete_inode
sys_unlink
initrd_load
prepare_namespace
(...)


/dev/hda1 on / type ext3 (rw)
/dev/hda2 on /usr type ext3 (rw)
/dev/hda5 on /tmp type ext3 (rw)
/dev/hda6 on /var type ext3 (rw)
/dev/hda7 on /home type ext3 (rw)
/dev/hda8 on /home/users/pluto/multimedia type ext3 (rw)
/dev/hdd1 on /home/users/pluto/rpm type ext3 (rw)
none on /proc type proc (rw,gid=17)
none on /dev/pts type devpts (rw,gid=5,mode=620)
none on /dev/shm type tmpfs (rw)
sysfs on /sys type sysfs (rw)
selinuxfs on /selinux type selinuxfs (rw)

-- 
/* Copyright (C) 2003, SCO, Inc. This is valuable Intellectual Property. */

                           #define say(x) lie(x)

Re: 2.6.10rc3+cset == oops (fs).

[Andrew Morton]

Pawe__ Sikora <pluto@pld-linux.org> wrote:
>
> I've just tried to boot the 2.6.10rc3+cset20041210_0507.
> 
> [handcopy of the ooops]
> 
> dereferencing null pointer
> eip at: radix_tree_tag_clear
> 
> trace:
> (...)
> test_clear_page_dirty
> truncate_complete_page
> truncate_inode_pages_range
> truncate_inode_pages
> generic_delete_inode
> sys_unlink
> initrd_load
> prepare_namespace
> (...)

I can't think of any recent changes whish could cause something like this. 
Is this reproducible?  If so, could you please work out which kernel
version and bk snapshot introduced the bug?  Thanks.

Re: 2.6.10rc3+cset == oops (fs).

[Paweł Sikora]

On Saturday 11 of December 2004 00:25, Andrew Morton wrote:
> Pawe__ Sikora <pluto@pld-linux.org> wrote:
> > I've just tried to boot the 2.6.10rc3+cset20041210_0507.
> >
> > [handcopy of the ooops]
> >
> > dereferencing null pointer
> > eip at: radix_tree_tag_clear

 407:lib/radix-tree.c **** 
 408:lib/radix-tree.c ****   if (*pathp->slot == NULL)     <=== ooopses here
 409:lib/radix-tree.c ****    goto out;
 410:lib/radix-tree.c **** 

 1341                .loc 1 408 0
 1342 0605 8B45A4     movl -92(%ebp), %eax # <variable>.slot, D.9023
 1343 0608 8B00       movl (%eax), %eax #* D.9023,
 1344 060a 85C0       testl %eax, %eax #
 1345 060c 744F       je .L132 #,

> > trace:
> > (...)
> > test_clear_page_dirty
> > truncate_complete_page
> > truncate_inode_pages_range
> > truncate_inode_pages
> > generic_delete_inode
> > sys_unlink
> > initrd_load
> > prepare_namespace
> > (...)
>
> I can't think of any recent changes whish could cause something like this.
> Is this reproducible?  If so, could you please work out which kernel
> version and bk snapshot introduced the bug?  Thanks.

2.6.10rc1+cset20041025_0606 works fine (I'm using it now).
2.6.10rc3+cset20041210_0507 oopses.

I'll do more test later...

-- 
/* Copyright (C) 2003, SCO, Inc. This is valuable Intellectual Property. */

                           #define say(x) lie(x)

Re: 2.6.10rc3+cset == oops (fs).

[Paweł Sikora]

On Saturday 11 of December 2004 00:51, Paweł Sikora wrote:
> On Saturday 11 of December 2004 00:25, Andrew Morton wrote:
> > Pawe__ Sikora <pluto@pld-linux.org> wrote:
> > > I've just tried to boot the 2.6.10rc3+cset20041210_0507.
> > >
> > > [handcopy of the ooops]
> > >
> > > dereferencing null pointer
> > > eip at: radix_tree_tag_clear
>
>  407:lib/radix-tree.c ****
>  408:lib/radix-tree.c ****   if (*pathp->slot == NULL)     <=== ooopses
> here 409:lib/radix-tree.c ****    goto out;
>  410:lib/radix-tree.c ****
>

after deep analysis i conclude that this bug is related to the gcc4.
with gcc343 kernel doesn't oops during boot time.
now i'm working on reduced testcase...

-- 
/* Copyright (C) 2003, SCO, Inc. This is valuable Intellectual Property. */

                           #define say(x) lie(x)