[broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Michal Piotrowski]

Hi Greg,

This looks like a sysfs bug
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/00003.jpg

l *kernel_param_sysfs_setup+0x75
0xc13c0894 is in kernel_param_sysfs_setup (kernel/params.c:570).
565             mk->mod = THIS_MODULE;
566             kobj_set_kset_s(mk, module_subsys);
567             kobject_set_name(&mk->kobj, name);
568             kobject_init(&mk->kobj);
569             ret = kobject_add(&mk->kobj);
570             BUG_ON(ret < 0);
571             param_sysfs_setup(mk, kparam, num_params, name_skip);
572             kobject_uevent(&mk->kobj, KOBJ_ADD);
573     }
574

http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/mm-config

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Greg KH]

On Fri, Jul 20, 2007 at 06:32:21PM +0200, Michal Piotrowski wrote:
>  Hi Greg,
> 
>  This looks like a sysfs bug
>  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/00003.jpg
> 
>  l *kernel_param_sysfs_setup+0x75
>  0xc13c0894 is in kernel_param_sysfs_setup (kernel/params.c:570).
>  565             mk->mod = THIS_MODULE;
>  566             kobj_set_kset_s(mk, module_subsys);
>  567             kobject_set_name(&mk->kobj, name);
>  568             kobject_init(&mk->kobj);
>  569             ret = kobject_add(&mk->kobj);
>  570             BUG_ON(ret < 0);
>  571             param_sysfs_setup(mk, kparam, num_params, name_skip);
>  572             kobject_uevent(&mk->kobj, KOBJ_ADD);
>  573     }
>  574
> 
>  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/mm-config

What kernel version is this happening on?  The -mm tree?  Can you try
Linus's tree instead?

It looks like there was some needed information right before the first
stack dump, showing exactly what kobject was trying to be added that was
already present.  Odds are this is a kernel parameter with the same name
as a duplicate one within the same module, but the trick is going to be
trying to figure out what module is causing this.

So it's not a sysfs bug, but rather a driver issue that this is
catching.

Does that make sense?

greg k-h

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Andrew Morton]

On Fri, 20 Jul 2007 15:50:47 -0700
Greg KH <gregkh@suse.de> wrote:

> On Fri, Jul 20, 2007 at 06:32:21PM +0200, Michal Piotrowski wrote:
> >  Hi Greg,
> > 
> >  This looks like a sysfs bug
> >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/00003.jpg
> > 
> >  l *kernel_param_sysfs_setup+0x75
> >  0xc13c0894 is in kernel_param_sysfs_setup (kernel/params.c:570).
> >  565             mk->mod = THIS_MODULE;
> >  566             kobj_set_kset_s(mk, module_subsys);
> >  567             kobject_set_name(&mk->kobj, name);
> >  568             kobject_init(&mk->kobj);
> >  569             ret = kobject_add(&mk->kobj);
> >  570             BUG_ON(ret < 0);
> >  571             param_sysfs_setup(mk, kparam, num_params, name_skip);
> >  572             kobject_uevent(&mk->kobj, KOBJ_ADD);
> >  573     }
> >  574
> > 
> >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/mm-config
> 
> What kernel version is this happening on?  The -mm tree?  Can you try
> Linus's tree instead?
> 
> It looks like there was some needed information right before the first
> stack dump, showing exactly what kobject was trying to be added that was
> already present.  Odds are this is a kernel parameter with the same name
> as a duplicate one within the same module, but the trick is going to be
> trying to figure out what module is causing this.
> 
> So it's not a sysfs bug, but rather a driver issue that this is
> catching.

In that case a BUG was way too harsh treatment, and in fact directly
contributed to our inability to debug the bug!

Can we wind that back a bit?  Add some useful printks and then recover
in some fashion?

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Greg KH]

On Fri, Jul 20, 2007 at 03:59:12PM -0700, Andrew Morton wrote:
> On Fri, 20 Jul 2007 15:50:47 -0700
> Greg KH <gregkh@suse.de> wrote:
> 
> > On Fri, Jul 20, 2007 at 06:32:21PM +0200, Michal Piotrowski wrote:
> > >  Hi Greg,
> > > 
> > >  This looks like a sysfs bug
> > >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/00003.jpg
> > > 
> > >  l *kernel_param_sysfs_setup+0x75
> > >  0xc13c0894 is in kernel_param_sysfs_setup (kernel/params.c:570).
> > >  565             mk->mod = THIS_MODULE;
> > >  566             kobj_set_kset_s(mk, module_subsys);
> > >  567             kobject_set_name(&mk->kobj, name);
> > >  568             kobject_init(&mk->kobj);
> > >  569             ret = kobject_add(&mk->kobj);
> > >  570             BUG_ON(ret < 0);
> > >  571             param_sysfs_setup(mk, kparam, num_params, name_skip);
> > >  572             kobject_uevent(&mk->kobj, KOBJ_ADD);
> > >  573     }
> > >  574
> > > 
> > >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/mm-config
> > 
> > What kernel version is this happening on?  The -mm tree?  Can you try
> > Linus's tree instead?
> > 
> > It looks like there was some needed information right before the first
> > stack dump, showing exactly what kobject was trying to be added that was
> > already present.  Odds are this is a kernel parameter with the same name
> > as a duplicate one within the same module, but the trick is going to be
> > trying to figure out what module is causing this.
> > 
> > So it's not a sysfs bug, but rather a driver issue that this is
> > catching.
> 
> In that case a BUG was way too harsh treatment, and in fact directly
> contributed to our inability to debug the bug!
> 
> Can we wind that back a bit?  Add some useful printks and then recover
> in some fashion?

Sure, I don't mind doing that at all.

Hm, it looks like Randy added this back in September last year with:
	commit d8c7649e99e4b081b624aefe1e77caa30b53cb18
	Author: Randy Dunlap <rdunlap@xenotime.net>
	Date:   Fri Sep 29 01:58:55 2006 -0700

	    [PATCH] kernel/params: driver layer error checking

	    Check driver layer return values in kernel/params.c

	    Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
	    Signed-off-by: Andrew Morton <akpm@osdl.org>
	    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

(wow, I love git and the signed-off-tree for things like this, it's
trivial to find this information out.)

So I'm guessing he was trying to catch something specific here.

Randy, any objection to changing that BUG_ON to a printk warning instead
telling the user exactly what needs to be fixed and that the system is
now going to be unstable when any module is unloaded?

thanks,

greg k-h

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Randy Dunlap]

On Fri, 20 Jul 2007 16:10:52 -0700 Greg KH wrote:

> On Fri, Jul 20, 2007 at 03:59:12PM -0700, Andrew Morton wrote:
> > On Fri, 20 Jul 2007 15:50:47 -0700
> > Greg KH <gregkh@suse.de> wrote:
> > 
> > > On Fri, Jul 20, 2007 at 06:32:21PM +0200, Michal Piotrowski wrote:
> > > >  Hi Greg,
> > > > 
> > > >  This looks like a sysfs bug
> > > >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/00003.jpg
> > > > 
> > > >  l *kernel_param_sysfs_setup+0x75
> > > >  0xc13c0894 is in kernel_param_sysfs_setup (kernel/params.c:570).
> > > >  565             mk->mod = THIS_MODULE;
> > > >  566             kobj_set_kset_s(mk, module_subsys);
> > > >  567             kobject_set_name(&mk->kobj, name);
> > > >  568             kobject_init(&mk->kobj);
> > > >  569             ret = kobject_add(&mk->kobj);
> > > >  570             BUG_ON(ret < 0);
> > > >  571             param_sysfs_setup(mk, kparam, num_params, name_skip);
> > > >  572             kobject_uevent(&mk->kobj, KOBJ_ADD);
> > > >  573     }
> > > >  574
> > > > 
> > > >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/mm-config
> > > 
> > > What kernel version is this happening on?  The -mm tree?  Can you try
> > > Linus's tree instead?
> > > 
> > > It looks like there was some needed information right before the first
> > > stack dump, showing exactly what kobject was trying to be added that was
> > > already present.  Odds are this is a kernel parameter with the same name
> > > as a duplicate one within the same module, but the trick is going to be
> > > trying to figure out what module is causing this.
> > > 
> > > So it's not a sysfs bug, but rather a driver issue that this is
> > > catching.
> > 
> > In that case a BUG was way too harsh treatment, and in fact directly
> > contributed to our inability to debug the bug!
> > 
> > Can we wind that back a bit?  Add some useful printks and then recover
> > in some fashion?
> 
> Sure, I don't mind doing that at all.
> 
> Hm, it looks like Randy added this back in September last year with:
> 	commit d8c7649e99e4b081b624aefe1e77caa30b53cb18
> 	Author: Randy Dunlap <rdunlap@xenotime.net>
> 	Date:   Fri Sep 29 01:58:55 2006 -0700
> 
> 	    [PATCH] kernel/params: driver layer error checking
> 
> 	    Check driver layer return values in kernel/params.c
> 
> 	    Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> 	    Signed-off-by: Andrew Morton <akpm@osdl.org>
> 	    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
> 
> (wow, I love git and the signed-off-tree for things like this, it's
> trivial to find this information out.)
> 
> So I'm guessing he was trying to catch something specific here.
> 
> Randy, any objection to changing that BUG_ON to a printk warning instead
> telling the user exactly what needs to be fixed and that the system is
> now going to be unstable when any module is unloaded?

Of course not (no objection).

I added a BUG_ON() ?  Shame on me.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Satyam Sharma]

On 7/21/07, Greg KH <gregkh@suse.de> wrote:
> On Fri, Jul 20, 2007 at 03:59:12PM -0700, Andrew Morton wrote:
> > On Fri, 20 Jul 2007 15:50:47 -0700
> > Greg KH <gregkh@suse.de> wrote:
> >
> > > On Fri, Jul 20, 2007 at 06:32:21PM +0200, Michal Piotrowski wrote:
> > > >  Hi Greg,
> > > >
> > > >  This looks like a sysfs bug
> > > >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/
> > > >  broken-out-2007-07-20-00-22/00003.jpg
> > > >
> > > >  l *kernel_param_sysfs_setup+0x75
> > > >  0xc13c0894 is in kernel_param_sysfs_setup (kernel/params.c:570).
> > > >  565             mk->mod = THIS_MODULE;
> > > >  566             kobj_set_kset_s(mk, module_subsys);
> > > >  567             kobject_set_name(&mk->kobj, name);
> > > >  568             kobject_init(&mk->kobj);
> > > >  569             ret = kobject_add(&mk->kobj);
> > > >  570             BUG_ON(ret < 0);
> > > >  571             param_sysfs_setup(mk, kparam, num_params, name_skip);
> > > >  572             kobject_uevent(&mk->kobj, KOBJ_ADD);
> > > >  573     }
> > > >  574
> > > >
> > > >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/mm-config
> > >
> > > What kernel version is this happening on?  The -mm tree?  Can you try
> > > Linus's tree instead?
> > >
> > > It looks like there was some needed information right before the first
> > > stack dump, showing exactly what kobject was trying to be added that was
> > > already present.  Odds are this is a kernel parameter with the same name
> > > as a duplicate one within the same module,

I don't think that's an -EEXIST.

I think what we have here is kobject_add() exiting with -EINVAL.
(kobject attempted to be registered with no name!)

[ The first trace on that screen shows: kobject_shadow_add+0x5b/0x189.
That's the WARN_ON(1) at lib/kobject.c:176. If it was a EEXIST case,
we would've seen an offset in kobject_shadow_add closer to 0x189,
because the dump_stack() for EEXIST is barely 4 instructions before
we return from that function. ]

> > > but the trick is going to be
> > > trying to figure out what module is causing this.

So I'd guess we want to search for a module that's passing a kobject *
to kobject_add() such that !kobj->k_name is true.

> > > So it's not a sysfs bug, but rather a driver issue that this is
> > > catching.
> >
> > In that case a BUG was way too harsh treatment, and in fact directly
> > contributed to our inability to debug the bug!
> >
> > Can we wind that back a bit?  Add some useful printks and then recover
> > in some fashion?
> [...]
> So I'm guessing he was trying to catch something specific here.

Considering that:

(1) This isn't a bug that should bring down the kernel that hard, and,
(2) kobject_shadow_add() seems to be dumping enough stacks and
printing printk's on errors already,

I'd suggest to just get rid of the BUG_ON() in kernel_param_sysfs_setup()


Satyam

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Satyam Sharma]

Oh, which means ...


On 7/21/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> On 7/21/07, Greg KH <gregkh@suse.de> wrote:
> > On Fri, Jul 20, 2007 at 03:59:12PM -0700, Andrew Morton wrote:
> > > On Fri, 20 Jul 2007 15:50:47 -0700
> > > Greg KH <gregkh@suse.de> wrote:
> > >
> > > > On Fri, Jul 20, 2007 at 06:32:21PM +0200, Michal Piotrowski wrote:
> > > > >  Hi Greg,
> > > > >
> > > > >  This looks like a sysfs bug
> > > > >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/
> > > > >  broken-out-2007-07-20-00-22/00003.jpg
> > > > >
> > > > >  l *kernel_param_sysfs_setup+0x75
> > > > >  0xc13c0894 is in kernel_param_sysfs_setup (kernel/params.c:570).
> > > > >  565             mk->mod = THIS_MODULE;
> > > > >  566             kobj_set_kset_s(mk, module_subsys);

> > > > >  567             kobject_set_name(&mk->kobj, name);

Shouldn't the return of kobject_set_name() be checked here?

[ Looking at code, and realizing that kobject_set_name() manages to
succeed even when given a null string! ]

> > > > >  568             kobject_init(&mk->kobj);
> > > > >  569             ret = kobject_add(&mk->kobj);
> > > > >  570             BUG_ON(ret < 0);
> > > > >  571             param_sysfs_setup(mk, kparam, num_params, name_skip);
> > > > >  572             kobject_uevent(&mk->kobj, KOBJ_ADD);
> > > > >  573     }
> > > > >  574
> > > > >
> > > > >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/
> > > > >  broken-out-2007-07-20-00-22/mm-config
> > > >
> > > > What kernel version is this happening on?  The -mm tree?  Can you try
> > > > Linus's tree instead?
> > > >
> > > > It looks like there was some needed information right before the first
> > > > stack dump, showing exactly what kobject was trying to be added that was
> > > > already present.  Odds are this is a kernel parameter with the same name
> > > > as a duplicate one within the same module,
>
> I don't think that's an -EEXIST.
>
> I think what we have here is kobject_add() exiting with -EINVAL.
> (kobject attempted to be registered with no name!)
>
> [ The first trace on that screen shows: kobject_shadow_add+0x5b/0x189.
> That's the WARN_ON(1) at lib/kobject.c:176. If it was a EEXIST case,
> we would've seen an offset in kobject_shadow_add closer to 0x189,
> because the dump_stack() for EEXIST is barely 4 instructions before
> we return from that function. ]
>
> > > > but the trick is going to be
> > > > trying to figure out what module is causing this.
>
> So I'd guess we want to search for a module that's passing a kobject *
> to kobject_add() such that !kobj->k_name is true.

Oh, that's kernel_param_sysfs_setup itself. So we actually need to
search for a built-in module in Michal's config that ... has an ... empty
"" modname !? Shouldn't that turn up pretty quickly in a grep?

How do I do that, btw?

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Michal Piotrowski]

On 21/07/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> Oh, which means ...
>
>
> On 7/21/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> > On 7/21/07, Greg KH <gregkh@suse.de> wrote:
> > > On Fri, Jul 20, 2007 at 03:59:12PM -0700, Andrew Morton wrote:
> > > > On Fri, 20 Jul 2007 15:50:47 -0700
> > > > Greg KH <gregkh@suse.de> wrote:
> > > >
> > > > > On Fri, Jul 20, 2007 at 06:32:21PM +0200, Michal Piotrowski wrote:
> > > > > >  Hi Greg,
> > > > > >
> > > > > >  This looks like a sysfs bug
> > > > > >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/
> > > > > >  broken-out-2007-07-20-00-22/00003.jpg
> > > > > >
> > > > > >  l *kernel_param_sysfs_setup+0x75
> > > > > >  0xc13c0894 is in kernel_param_sysfs_setup (kernel/params.c:570).
> > > > > >  565             mk->mod = THIS_MODULE;
> > > > > >  566             kobj_set_kset_s(mk, module_subsys);
>
> > > > > >  567             kobject_set_name(&mk->kobj, name);
>
> Shouldn't the return of kobject_set_name() be checked here?
>
> [ Looking at code, and realizing that kobject_set_name() manages to
> succeed even when given a null string! ]
>
> > > > > >  568             kobject_init(&mk->kobj);
> > > > > >  569             ret = kobject_add(&mk->kobj);
> > > > > >  570             BUG_ON(ret < 0);
> > > > > >  571             param_sysfs_setup(mk, kparam, num_params, name_skip);
> > > > > >  572             kobject_uevent(&mk->kobj, KOBJ_ADD);
> > > > > >  573     }
> > > > > >  574
> > > > > >
> > > > > >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/
> > > > > >  broken-out-2007-07-20-00-22/mm-config
> > > > >
> > > > > What kernel version is this happening on?  The -mm tree?  Can you try
> > > > > Linus's tree instead?
> > > > >
> > > > > It looks like there was some needed information right before the first
> > > > > stack dump, showing exactly what kobject was trying to be added that was
> > > > > already present.  Odds are this is a kernel parameter with the same name
> > > > > as a duplicate one within the same module,
> >
> > I don't think that's an -EEXIST.
> >
> > I think what we have here is kobject_add() exiting with -EINVAL.
> > (kobject attempted to be registered with no name!)
> >
> > [ The first trace on that screen shows: kobject_shadow_add+0x5b/0x189.
> > That's the WARN_ON(1) at lib/kobject.c:176. If it was a EEXIST case,
> > we would've seen an offset in kobject_shadow_add closer to 0x189,
> > because the dump_stack() for EEXIST is barely 4 instructions before
> > we return from that function. ]
> >
> > > > > but the trick is going to be
> > > > > trying to figure out what module is causing this.
> >
> > So I'd guess we want to search for a module that's passing a kobject *
> > to kobject_add() such that !kobj->k_name is true.
>
> Oh, that's kernel_param_sysfs_setup itself. So we actually need to
> search for a built-in module in Michal's config that ... has an ... empty
> "" modname !?

I'll try to figure out this

> Shouldn't that turn up pretty quickly in a grep?
>
> How do I do that, btw?
>

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Greg KH]

On Sat, Jul 21, 2007 at 02:28:52AM +0200, Michal Piotrowski wrote:
>  On 21/07/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> > Oh, which means ...
> >
> >
> > On 7/21/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> > > On 7/21/07, Greg KH <gregkh@suse.de> wrote:
> > > > On Fri, Jul 20, 2007 at 03:59:12PM -0700, Andrew Morton wrote:
> > > > > On Fri, 20 Jul 2007 15:50:47 -0700
> > > > > Greg KH <gregkh@suse.de> wrote:
> > > > >
> > > > > > On Fri, Jul 20, 2007 at 06:32:21PM +0200, Michal Piotrowski wrote:
> > > > > > >  Hi Greg,
> > > > > > >
> > > > > > >  This looks like a sysfs bug
> > > > > > >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/
> > > > > > >  broken-out-2007-07-20-00-22/00003.jpg
> > > > > > >
> > > > > > >  l *kernel_param_sysfs_setup+0x75
> > > > > > >  0xc13c0894 is in kernel_param_sysfs_setup (kernel/params.c:570).
> > > > > > >  565             mk->mod = THIS_MODULE;
> > > > > > >  566             kobj_set_kset_s(mk, module_subsys);
> >
> > > > > > >  567             kobject_set_name(&mk->kobj, name);
> >
> > Shouldn't the return of kobject_set_name() be checked here?
> >
> > [ Looking at code, and realizing that kobject_set_name() manages to
> > succeed even when given a null string! ]
> >
> > > > > > >  568             kobject_init(&mk->kobj);
> > > > > > >  569             ret = kobject_add(&mk->kobj);
> > > > > > >  570             BUG_ON(ret < 0);
> > > > > > >  571             param_sysfs_setup(mk, kparam, num_params, 
> > name_skip);
> > > > > > >  572             kobject_uevent(&mk->kobj, KOBJ_ADD);
> > > > > > >  573     }
> > > > > > >  574
> > > > > > >
> > > > > > >  http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/
> > > > > > >  broken-out-2007-07-20-00-22/mm-config
> > > > > >
> > > > > > What kernel version is this happening on?  The -mm tree?  Can you 
> > try
> > > > > > Linus's tree instead?
> > > > > >
> > > > > > It looks like there was some needed information right before the 
> > first
> > > > > > stack dump, showing exactly what kobject was trying to be added 
> > that was
> > > > > > already present.  Odds are this is a kernel parameter with the same 
> > name
> > > > > > as a duplicate one within the same module,
> > >
> > > I don't think that's an -EEXIST.
> > >
> > > I think what we have here is kobject_add() exiting with -EINVAL.
> > > (kobject attempted to be registered with no name!)
> > >
> > > [ The first trace on that screen shows: kobject_shadow_add+0x5b/0x189.
> > > That's the WARN_ON(1) at lib/kobject.c:176. If it was a EEXIST case,
> > > we would've seen an offset in kobject_shadow_add closer to 0x189,
> > > because the dump_stack() for EEXIST is barely 4 instructions before
> > > we return from that function. ]
> > >
> > > > > > but the trick is going to be
> > > > > > trying to figure out what module is causing this.
> > >
> > > So I'd guess we want to search for a module that's passing a kobject *
> > > to kobject_add() such that !kobj->k_name is true.
> >
> > Oh, that's kernel_param_sysfs_setup itself. So we actually need to
> > search for a built-in module in Michal's config that ... has an ... empty
> > "" modname !?
> 
>  I'll try to figure out this

Try the patch below to help you boot and figure out what went wrong.

Post the kernel log results and I'll try to help you out.

thanks,

greg k-h

---
 kernel/params.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/kernel/params.c
+++ b/kernel/params.c
@@ -567,7 +567,11 @@ static void __init kernel_param_sysfs_se
 	kobject_set_name(&mk->kobj, name);
 	kobject_init(&mk->kobj);
 	ret = kobject_add(&mk->kobj);
-	BUG_ON(ret < 0);
+	if (ret) {
+		printk(KERN_ERR "module '%s' failed to be added to sysfs, "
+			"the system will be unstable now.\n", name);
+		return;
+	}
 	param_sysfs_setup(mk, kparam, num_params, name_skip);
 	kobject_uevent(&mk->kobj, KOBJ_ADD);
 }

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Andrew Morton]

On Fri, 20 Jul 2007 18:02:57 -0700 Greg KH <gregkh@suse.de> wrote:

> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -567,7 +567,11 @@ static void __init kernel_param_sysfs_se
>  	kobject_set_name(&mk->kobj, name);
>  	kobject_init(&mk->kobj);
>  	ret = kobject_add(&mk->kobj);
> -	BUG_ON(ret < 0);
> +	if (ret) {
> +		printk(KERN_ERR "module '%s' failed to be added to sysfs, "
> +			"the system will be unstable now.\n", name);
> +		return;
> +	}

It would be nice to print the value of `ret' too.

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Greg KH]

On Fri, Jul 20, 2007 at 06:37:33PM -0700, Andrew Morton wrote:
> On Fri, 20 Jul 2007 18:02:57 -0700 Greg KH <gregkh@suse.de> wrote:
> 
> > --- a/kernel/params.c
> > +++ b/kernel/params.c
> > @@ -567,7 +567,11 @@ static void __init kernel_param_sysfs_se
> >  	kobject_set_name(&mk->kobj, name);
> >  	kobject_init(&mk->kobj);
> >  	ret = kobject_add(&mk->kobj);
> > -	BUG_ON(ret < 0);
> > +	if (ret) {
> > +		printk(KERN_ERR "module '%s' failed to be added to sysfs, "
> > +			"the system will be unstable now.\n", name);
> > +		return;
> > +	}
> 
> It would be nice to print the value of `ret' too.

Ok, how about this version:

---
 kernel/params.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/kernel/params.c
+++ b/kernel/params.c
@@ -567,7 +567,12 @@ static void __init kernel_param_sysfs_se
 	kobject_set_name(&mk->kobj, name);
 	kobject_init(&mk->kobj);
 	ret = kobject_add(&mk->kobj);
-	BUG_ON(ret < 0);
+	if (ret) {
+		printk(KERN_ERR "Module '%s' failed to be added to sysfs, "
+		      "error number %d\n", name, ret);
+		printk(KERN_ERR	"The system will be unstable now.\n");
+		return;
+	}
 	param_sysfs_setup(mk, kparam, num_params, name_skip);
 	kobject_uevent(&mk->kobj, KOBJ_ADD);
 }

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Satyam Sharma]

[ Considering this has sufficiently excited me, I became the second person
to illegitimately download 2.6.22-mm1 and am presently building Michal's
config. The strange thing is that I couldn't get 22-mm1 to even build with
the posted .config -- so had to deselect XFS, ATA, unionfs.

Hopefully this bug should be 100% reproducible at boot time anyway.
Don't care much for XFS and unionfs, but hoping deselecting ATA from
the config doesn't change the variables much in this equation. ]


On 7/21/07, Greg KH <gregkh@suse.de> wrote:
> On Fri, Jul 20, 2007 at 06:37:33PM -0700, Andrew Morton wrote:
> > On Fri, 20 Jul 2007 18:02:57 -0700 Greg KH <gregkh@suse.de> wrote:
> >
> > > --- a/kernel/params.c
> > > +++ b/kernel/params.c
> > > @@ -567,7 +567,11 @@ static void __init kernel_param_sysfs_se
> > >     kobject_set_name(&mk->kobj, name);
> > >     kobject_init(&mk->kobj);
> > >     ret = kobject_add(&mk->kobj);
> > > -   BUG_ON(ret < 0);
> > > +   if (ret) {
> > > +           printk(KERN_ERR "module '%s' failed to be added to sysfs, "
> > > +                   "the system will be unstable now.\n", name);
> > > +           return;
> > > +   }
> >
> > It would be nice to print the value of `ret' too.


What I'm surprised about is that %eax doesn't seem to contain the
return value `ret' of kobject_add(). It's 1, which is funny, given:

ret = kobject_add(&mk->kobj);
BUG_ON(ret < 0);

One wouldn't expect BUG() -- or the corresponding exception handler --
to clobber registers, that would be a sad day.


> Ok, how about this version:
>
> ---
>  kernel/params.c |    7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -567,7 +567,12 @@ static void __init kernel_param_sysfs_se
>         kobject_set_name(&mk->kobj, name);
>         kobject_init(&mk->kobj);
>         ret = kobject_add(&mk->kobj);
> -       BUG_ON(ret < 0);
> +       if (ret) {
> +               printk(KERN_ERR "Module '%s' failed to be added to sysfs, "
> +                     "error number %d\n", name, ret);
> +               printk(KERN_ERR "The system will be unstable now.\n");
> +               return;
> +       }
>         param_sysfs_setup(mk, kparam, num_params, name_skip);
>         kobject_uevent(&mk->kobj, KOBJ_ADD);
>  }


I'm building with this:

if (ret) {
        printk("~~~~~ .%s.%d.%s. ~~~~~\n", name, ret, kparam->name);
        return;
}

To also print out the evil kparam->name that caused us to crash.
When ret == EINVAL, name would be "", so not so helpful alone.

Also enabling netconsole, though I'm sure there's zero chances
of NET / ethXXX / netconsole being up _this_ early in the boot ...

Will keep you guys posted :-)

Satyam

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Satyam Sharma]

On 7/21/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> Hopefully this bug should be 100% reproducible at boot time anyway.
> Don't care much for XFS and unionfs, but hoping deselecting ATA from
> the config doesn't change the variables much in this equation. ]


Gargh! My system obviously cannot boot without libata. Guess it's
time to go through git log and see how to fix that build breakage
myself ...

Michal, how did you even manage to build / boot this kernel!


> On 7/21/07, Greg KH <gregkh@suse.de> wrote:
> > On Fri, Jul 20, 2007 at 06:37:33PM -0700, Andrew Morton wrote:
> > > On Fri, 20 Jul 2007 18:02:57 -0700 Greg KH <gregkh@suse.de> wrote:
> > >
> > > > --- a/kernel/params.c
> > > > +++ b/kernel/params.c
> > > > @@ -567,7 +567,11 @@ static void __init kernel_param_sysfs_se
> > > >     kobject_set_name(&mk->kobj, name);
> > > >     kobject_init(&mk->kobj);
> > > >     ret = kobject_add(&mk->kobj);
> > > > -   BUG_ON(ret < 0);
> > > > +   if (ret) {
> > > > +           printk(KERN_ERR "module '%s' failed to be added to sysfs, "
> > > > +                   "the system will be unstable now.\n", name);
> > > > +           return;
> > > > +   }
> > >
> > > It would be nice to print the value of `ret' too.
>
>
> What I'm surprised about is that %eax doesn't seem to contain the
> return value `ret' of kobject_add(). It's 1, which is funny, given:
>
> ret = kobject_add(&mk->kobj);
> BUG_ON(ret < 0);
>
> One wouldn't expect BUG() -- or the corresponding exception handler --
> to clobber registers, that would be a sad day.


But I cracked this one alright. His .config has CONFIG_PROFILE_LIKELY=y
which replaces unlikely() / likely() with do_check_likely() and forces
gcc to clobber %eax with the condition itself, which in our case was
(ret < 0) == TRUE, and thus, the "1" value we saw in %eax in the
register dumps.

We should probably document somewhere that CONFIG_PROFILE_LIKELY
is not good for debugging.

Hmmm ... thinking out aloud here, but probably I don't need to fix that
libata breakage at all. I'll just put the BUG_ON(ret < 0) back in the
code, deselect PROFILE_LIKELY, and this time we _will_ have the
return of kobject_add() in %eax ...


That'll at least clear up the EEXIST vs EINVAL mystery, that'll be a
good data point, yes.

Anyway, I guess I must stop my running commentary -- will only post
after this is cleared up now :-)

Satyam

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Satyam Sharma]

Ok, this worked:

> His .config has CONFIG_PROFILE_LIKELY=y
> which replaces unlikely() / likely() with do_check_likely() and forces
> gcc to clobber %eax with the condition itself, which in our case was
> (ret < 0) == TRUE, and thus, the "1" value we saw in %eax in the
> register dumps.

The usage of unlikely() in BUG_ON and CONFIG_PROFILE_LIKELY=y
meant %eax that held `ret' from kobject_add() was being lost.

With that turned off:

0xc136071b      call   0xc1103744 <kobject_add>
[ ret i.e. %eax = kobject_add() ]
0xc1360720      test   %eax,%eax
[ %eax = %eax && %eax = %eax ]
[ probably gcc thinks this is an efficient < 0 check on i386 :-) ]
0xc1360722      jns    0xc1360728
[ if false jump down below, else: ]
0xc1360724      ud2a
[ invalid opcode exception. /* from BUG */ ]
0xc1360726      jmp    0xc1360726
[ for (;;) ; /* from BUG */ ]

> We should probably document somewhere that CONFIG_PROFILE_LIKELY
> is not good for debugging.
>
> Hmmm ... thinking out aloud here, but probably I don't need to fix that
> libata breakage at all. I'll just put the BUG_ON(ret < 0) back in the
> code, deselect PROFILE_LIKELY, and this time we _will_ have the
> return of kobject_add() in %eax ...

So %eax retained its value. I reproduced Michal's oops (without having
to select CONFIG_ATA, because param_sysfs_init() is called way
earlier than searching for root block device during boot -- which is what
my system didn't like without ATA), and yes, I saw:

%eax == ffffffea == -22 == -EINVAL.

But:

When I replace the BUG_ON() with Greg's (or my modified) patch,
the kernel ignores that error as we wanted, but _still_ crashes before
finding the root block device (because ATA is not in kernel and my
system seems to require it). Unfortunately, lots of dmesg output
has scrolled up by then, and our "printk" is lost. Because of no
CONFIG_ATA, nothing gets written to disk either. I don't have a
serial cable around, netconsole not up yet at that point.

Ugh, I'm running out of ideas.

Satyam

[BUG] Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Satyam Sharma]

On 7/21/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> [...]
> %eax == ffffffea == -22 == -EINVAL.
>
> But:
>
> When I replace the BUG_ON() with Greg's (or my modified) patch,
> the kernel ignores that error as we wanted, but _still_ crashes before
> finding the root block device (because ATA is not in kernel and my
> system seems to require it). Unfortunately, lots of dmesg output
> has scrolled up by then, and our "printk" is lost. Because of no
> CONFIG_ATA, nothing gets written to disk either.


The following hack worked:

if (ret) {
        printk("~~~~~ .%s.%d.%s. ~~~~~\n", name, ret, kparam->name);
        for (;;)
                cpu_relax();
}

So I just hung my testbox at the point the info I wanted was printed out :-)

I hand-copied the following from the screen:


*****

The kobject at, or inside cpu_devices+0x10/0xe0 is not dynamically
allocated.
The kobject at, or inside cpu_devices+0x10/0xe0 is not dynamically
allocated. (printed twice)
WARNING: at lib/kobject.c:220 kobject_shadow_add()
...
show_trace
dump_stack
...
kobject_shadow_add+0x65/0x1b6
kobject_add
kernel_param_sysfs_setup
param_sysfs_init
...
...

~~~~~ ..-22.mtrr.show. ~~~~~

*****


Something wrong with "cpu_devices" and "mtrr.show" in 22-mm1 me thinks.
Wonder if latest -git is already fixed? Spent 4 hours on this, at least :-p


BTW "kobject at, or inside cpu_devices+0x10/0xe0 is not dynamically
allocated" sounds like something that could, and should, have been
caught at build time ...


Satyam

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Michal Piotrowski]

Satyam Sharma pisze:
> On 7/21/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
>> Hopefully this bug should be 100% reproducible at boot time anyway.
>> Don't care much for XFS and unionfs, but hoping deselecting ATA from
>> the config doesn't change the variables much in this equation. ]
> 
> 
> Gargh! My system obviously cannot boot without libata. Guess it's
> time to go through git log and see how to fix that build breakage
> myself ...
> 
> Michal, how did you even manage to build / boot this kernel!

I commented origin.patch and mm.patch in series file, reverted xfs patches,
fixed libata build, deselected unionfs.

Here is a patch for libata

--- linux-work3-clean/drivers/ata/libata-core.c	2007-07-20 16:53:26.000000000 +0200
+++ linux-work3/drivers/ata/libata-core.c	2007-07-20 17:26:30.000000000 +0200
@@ -2036,7 +2036,7 @@ int ata_dev_configure(struct ata_device 
 		dev->max_sectors = min_t(unsigned int, ATA_MAX_SECTORS_128,
 					 dev->max_sectors);
 
-	if (ata_device_blacklisted(dev) & ATA_HORKAGE_ALPM) {
+	if (ata_dev_blacklisted(dev) & ATA_HORKAGE_ALPM) {
 		dev->horkage |= ATA_HORKAGE_ALPM;
 
 		/* reset link pm_policy for this port to no pm */

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Michal Piotrowski]

On 21/07/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> Ok, this worked:
>
> > His .config has CONFIG_PROFILE_LIKELY=y
> > which replaces unlikely() / likely() with do_check_likely() and forces
> > gcc to clobber %eax with the condition itself, which in our case was
> > (ret < 0) == TRUE, and thus, the "1" value we saw in %eax in the
> > register dumps.
>
> The usage of unlikely() in BUG_ON and CONFIG_PROFILE_LIKELY=y
> meant %eax that held `ret' from kobject_add() was being lost.
>
> With that turned off:
>
> 0xc136071b      call   0xc1103744 <kobject_add>
> [ ret i.e. %eax = kobject_add() ]
> 0xc1360720      test   %eax,%eax
> [ %eax = %eax && %eax = %eax ]
> [ probably gcc thinks this is an efficient < 0 check on i386 :-) ]
> 0xc1360722      jns    0xc1360728
> [ if false jump down below, else: ]
> 0xc1360724      ud2a
> [ invalid opcode exception. /* from BUG */ ]
> 0xc1360726      jmp    0xc1360726
> [ for (;;) ; /* from BUG */ ]
>
> > We should probably document somewhere that CONFIG_PROFILE_LIKELY
> > is not good for debugging.
> >
> > Hmmm ... thinking out aloud here, but probably I don't need to fix that
> > libata breakage at all. I'll just put the BUG_ON(ret < 0) back in the
> > code, deselect PROFILE_LIKELY, and this time we _will_ have the
> > return of kobject_add() in %eax ...
>
> So %eax retained its value. I reproduced Michal's oops (without having
> to select CONFIG_ATA, because param_sysfs_init() is called way
> earlier than searching for root block device during boot -- which is what
> my system didn't like without ATA), and yes, I saw:
>
> %eax == ffffffea == -22 == -EINVAL.
>
> But:
>
> When I replace the BUG_ON() with Greg's (or my modified) patch,
> the kernel ignores that error as we wanted, but _still_ crashes before
> finding the root block device (because ATA is not in kernel and my
> system seems to require it). Unfortunately, lots of dmesg output
> has scrolled up by then, and our "printk" is lost. Because of no
> CONFIG_ATA, nothing gets written to disk either. I don't have a
> serial cable around, netconsole not up yet at that point.

Neither serial nor net console doesn't work, system hangs very early.

>
> Ugh, I'm running out of ideas.
>
> Satyam
>

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Satyam Sharma]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

On 7/21/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> Satyam Sharma pisze:
> > [...]
> > Gargh! My system obviously cannot boot without libata. Guess it's
> > time to go through git log and see how to fix that build breakage
> > myself ...
> >
> > Michal, how did you even manage to build / boot this kernel!
>
> I commented origin.patch and mm.patch in series file, reverted xfs patches,
> fixed libata build, deselected unionfs.
>
> Here is a patch for libata
>
> --- linux-work3-clean/drivers/ata/libata-core.c 2007-07-20 16:53:26.000000000 +0200
> +++ linux-work3/drivers/ata/libata-core.c       2007-07-20 17:26:30.000000000 +0200
> @@ -2036,7 +2036,7 @@ int ata_dev_configure(struct ata_device
>                 dev->max_sectors = min_t(unsigned int, ATA_MAX_SECTORS_128,
>                                          dev->max_sectors);
>
> -       if (ata_device_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> +       if (ata_dev_blacklisted(dev) & ATA_HORKAGE_ALPM) {
>                 dev->horkage |= ATA_HORKAGE_ALPM;
>
>                 /* reset link pm_policy for this port to no pm */


And to think I went through all those hoops just to avoid *this* ... :-(
Anyway, please apply the attached patch and let's verify if we're both
actually bit by the same bug. A screenshot of my case is available at:

http://www.cse.iitk.ac.in/users/ssatyam/mtrr.show-bug.jpg

[ excuse the quality, it's not a digicam, but a cellphone-cam ]

Satyam

[-- Attachment #2: test.patch --]
[-- Type: text/x-patch, Size: 527 bytes --]

diff --git a/kernel/params.c b/kernel/params.c
index effbaae..5656ccf 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -567,7 +567,11 @@ static void __init kernel_param_sysfs_setup(const char *name,
 	kobject_set_name(&mk->kobj, name);
 	kobject_init(&mk->kobj);
 	ret = kobject_add(&mk->kobj);
-	BUG_ON(ret < 0);
+	if (ret) {
+		printf("~~~~~ .%s.%d.%s. ~~~~~\n", name, ret, kparam->name);
+		for (;;)
+			cpu_relax();
+	}
 	param_sysfs_setup(mk, kparam, num_params, name_skip);
 	kobject_uevent(&mk->kobj, KOBJ_ADD);
 }

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Michal Piotrowski]

On 21/07/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> On 7/21/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > Satyam Sharma pisze:
> > > [...]
> > > Gargh! My system obviously cannot boot without libata. Guess it's
> > > time to go through git log and see how to fix that build breakage
> > > myself ...
> > >
> > > Michal, how did you even manage to build / boot this kernel!
> >
> > I commented origin.patch and mm.patch in series file, reverted xfs patches,
> > fixed libata build, deselected unionfs.
> >
> > Here is a patch for libata
> >
> > --- linux-work3-clean/drivers/ata/libata-core.c 2007-07-20 16:53:26.000000000 +0200
> > +++ linux-work3/drivers/ata/libata-core.c       2007-07-20 17:26:30.000000000 +0200
> > @@ -2036,7 +2036,7 @@ int ata_dev_configure(struct ata_device
> >                 dev->max_sectors = min_t(unsigned int, ATA_MAX_SECTORS_128,
> >                                          dev->max_sectors);
> >
> > -       if (ata_device_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> > +       if (ata_dev_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> >                 dev->horkage |= ATA_HORKAGE_ALPM;
> >
> >                 /* reset link pm_policy for this port to no pm */
>
>
> And to think I went through all those hoops just to avoid *this* ... :-(
> Anyway, please apply the attached patch and let's verify if we're both
> actually bit by the same bug.

kernel/params.c: In function 'kernel_param_sysfs_setup':
kernel/params.c:571: error: implicit declaration of function 'printf'
make[1]: *** [kernel/params.o] Error 1
make: *** [kernel] Error 2

fixed :)

> A screenshot of my case is available at:
>
> http://www.cse.iitk.ac.in/users/ssatyam/mtrr.show-bug.jpg
>
> [ excuse the quality, it's not a digicam, but a cellphone-cam ]
>
> Satyam
>
>

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Michal Piotrowski]

Hi Andi,

On 21/07/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> On 7/21/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > Satyam Sharma pisze:
> > > [...]
> > > Gargh! My system obviously cannot boot without libata. Guess it's
> > > time to go through git log and see how to fix that build breakage
> > > myself ...
> > >
> > > Michal, how did you even manage to build / boot this kernel!
> >
> > I commented origin.patch and mm.patch in series file, reverted xfs patches,
> > fixed libata build, deselected unionfs.
> >
> > Here is a patch for libata
> >
> > --- linux-work3-clean/drivers/ata/libata-core.c 2007-07-20 16:53:26.000000000 +0200
> > +++ linux-work3/drivers/ata/libata-core.c       2007-07-20 17:26:30.000000000 +0200
> > @@ -2036,7 +2036,7 @@ int ata_dev_configure(struct ata_device
> >                 dev->max_sectors = min_t(unsigned int, ATA_MAX_SECTORS_128,
> >                                          dev->max_sectors);
> >
> > -       if (ata_device_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> > +       if (ata_dev_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> >                 dev->horkage |= ATA_HORKAGE_ALPM;
> >
> >                 /* reset link pm_policy for this port to no pm */
>
>
> And to think I went through all those hoops just to avoid *this* ... :-(
> Anyway, please apply the attached patch and let's verify if we're both
> actually bit by the same bug. A screenshot of my case is available at:
>
> http://www.cse.iitk.ac.in/users/ssatyam/mtrr.show-bug.jpg

Yep, the same bug here.

My hunt file shows me this

GOOD
x86_64-mm-i386-string-out-of-line.patch
BAD

Andi?

>
> [ excuse the quality, it's not a digicam, but a cellphone-cam ]
>
> Satyam
>
>

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Andi Kleen]

On Saturday 21 July 2007 18:00:52 Michal Piotrowski wrote:
> Hi Andi,
> 
> On 21/07/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> > On 7/21/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > Satyam Sharma pisze:
> > > > [...]
> > > > Gargh! My system obviously cannot boot without libata. Guess it's
> > > > time to go through git log and see how to fix that build breakage
> > > > myself ...
> > > >
> > > > Michal, how did you even manage to build / boot this kernel!
> > >
> > > I commented origin.patch and mm.patch in series file, reverted xfs patches,
> > > fixed libata build, deselected unionfs.
> > >
> > > Here is a patch for libata
> > >
> > > --- linux-work3-clean/drivers/ata/libata-core.c 2007-07-20 16:53:26.000000000 +0200
> > > +++ linux-work3/drivers/ata/libata-core.c       2007-07-20 17:26:30.000000000 +0200
> > > @@ -2036,7 +2036,7 @@ int ata_dev_configure(struct ata_device
> > >                 dev->max_sectors = min_t(unsigned int, ATA_MAX_SECTORS_128,
> > >                                          dev->max_sectors);
> > >
> > > -       if (ata_device_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> > > +       if (ata_dev_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> > >                 dev->horkage |= ATA_HORKAGE_ALPM;
> > >
> > >                 /* reset link pm_policy for this port to no pm */
> >
> >
> > And to think I went through all those hoops just to avoid *this* ... :-(
> > Anyway, please apply the attached patch and let's verify if we're both
> > actually bit by the same bug. A screenshot of my case is available at:
> >
> > http://www.cse.iitk.ac.in/users/ssatyam/mtrr.show-bug.jpg
> 
> Yep, the same bug here.
> 
> My hunt file shows me this
> 
> GOOD
> x86_64-mm-i386-string-out-of-line.patch
> BAD
> 
> Andi?


Does it still happen with the i386-string-out-of-line version from
firstfloor.org:/pub/ak/x86_64/quilt/patches/ ? 

I fixed some issues there.

-Andi

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Michal Piotrowski]

On 21/07/07, Andi Kleen <ak@suse.de> wrote:
> On Saturday 21 July 2007 18:00:52 Michal Piotrowski wrote:
> > Hi Andi,
> >
> > On 21/07/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> > > On 7/21/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > > Satyam Sharma pisze:
> > > > > [...]
> > > > > Gargh! My system obviously cannot boot without libata. Guess it's
> > > > > time to go through git log and see how to fix that build breakage
> > > > > myself ...
> > > > >
> > > > > Michal, how did you even manage to build / boot this kernel!
> > > >
> > > > I commented origin.patch and mm.patch in series file, reverted xfs patches,
> > > > fixed libata build, deselected unionfs.
> > > >
> > > > Here is a patch for libata
> > > >
> > > > --- linux-work3-clean/drivers/ata/libata-core.c 2007-07-20 16:53:26.000000000 +0200
> > > > +++ linux-work3/drivers/ata/libata-core.c       2007-07-20 17:26:30.000000000 +0200
> > > > @@ -2036,7 +2036,7 @@ int ata_dev_configure(struct ata_device
> > > >                 dev->max_sectors = min_t(unsigned int, ATA_MAX_SECTORS_128,
> > > >                                          dev->max_sectors);
> > > >
> > > > -       if (ata_device_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> > > > +       if (ata_dev_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> > > >                 dev->horkage |= ATA_HORKAGE_ALPM;
> > > >
> > > >                 /* reset link pm_policy for this port to no pm */
> > >
> > >
> > > And to think I went through all those hoops just to avoid *this* ... :-(
> > > Anyway, please apply the attached patch and let's verify if we're both
> > > actually bit by the same bug. A screenshot of my case is available at:
> > >
> > > http://www.cse.iitk.ac.in/users/ssatyam/mtrr.show-bug.jpg
> >
> > Yep, the same bug here.
> >
> > My hunt file shows me this
> >
> > GOOD
> > x86_64-mm-i386-string-out-of-line.patch
> > BAD
> >
> > Andi?
>
>
> Does it still happen with the i386-string-out-of-line version from
> firstfloor.org:/pub/ak/x86_64/quilt/patches/ ?

404

>
> I fixed some issues there.
>
> -Andi
>
>

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Michal Piotrowski]

On 21/07/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> On 21/07/07, Andi Kleen <ak@suse.de> wrote:
> > On Saturday 21 July 2007 18:00:52 Michal Piotrowski wrote:
> > > Hi Andi,
> > >
> > > On 21/07/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> > > > On 7/21/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > > > Satyam Sharma pisze:
> > > > > > [...]
> > > > > > Gargh! My system obviously cannot boot without libata. Guess it's
> > > > > > time to go through git log and see how to fix that build breakage
> > > > > > myself ...
> > > > > >
> > > > > > Michal, how did you even manage to build / boot this kernel!
> > > > >
> > > > > I commented origin.patch and mm.patch in series file, reverted xfs patches,
> > > > > fixed libata build, deselected unionfs.
> > > > >
> > > > > Here is a patch for libata
> > > > >
> > > > > --- linux-work3-clean/drivers/ata/libata-core.c 2007-07-20 16:53:26.000000000 +0200
> > > > > +++ linux-work3/drivers/ata/libata-core.c       2007-07-20 17:26:30.000000000 +0200
> > > > > @@ -2036,7 +2036,7 @@ int ata_dev_configure(struct ata_device
> > > > >                 dev->max_sectors = min_t(unsigned int, ATA_MAX_SECTORS_128,
> > > > >                                          dev->max_sectors);
> > > > >
> > > > > -       if (ata_device_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> > > > > +       if (ata_dev_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> > > > >                 dev->horkage |= ATA_HORKAGE_ALPM;
> > > > >
> > > > >                 /* reset link pm_policy for this port to no pm */
> > > >
> > > >
> > > > And to think I went through all those hoops just to avoid *this* ... :-(
> > > > Anyway, please apply the attached patch and let's verify if we're both
> > > > actually bit by the same bug. A screenshot of my case is available at:
> > > >
> > > > http://www.cse.iitk.ac.in/users/ssatyam/mtrr.show-bug.jpg
> > >
> > > Yep, the same bug here.
> > >
> > > My hunt file shows me this
> > >
> > > GOOD
> > > x86_64-mm-i386-string-out-of-line.patch
> > > BAD
> > >
> > > Andi?
> >
> >
> > Does it still happen with the i386-string-out-of-line version from
> > firstfloor.org:/pub/ak/x86_64/quilt/patches/ ?
>
> 404

ftp :)

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Michal Piotrowski]

On 21/07/07, Andi Kleen <ak@suse.de> wrote:
> On Saturday 21 July 2007 18:00:52 Michal Piotrowski wrote:
> > Hi Andi,
> >
> > On 21/07/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> > > On 7/21/07, Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > > Satyam Sharma pisze:
> > > > > [...]
> > > > > Gargh! My system obviously cannot boot without libata. Guess it's
> > > > > time to go through git log and see how to fix that build breakage
> > > > > myself ...
> > > > >
> > > > > Michal, how did you even manage to build / boot this kernel!
> > > >
> > > > I commented origin.patch and mm.patch in series file, reverted xfs patches,
> > > > fixed libata build, deselected unionfs.
> > > >
> > > > Here is a patch for libata
> > > >
> > > > --- linux-work3-clean/drivers/ata/libata-core.c 2007-07-20 16:53:26.000000000 +0200
> > > > +++ linux-work3/drivers/ata/libata-core.c       2007-07-20 17:26:30.000000000 +0200
> > > > @@ -2036,7 +2036,7 @@ int ata_dev_configure(struct ata_device
> > > >                 dev->max_sectors = min_t(unsigned int, ATA_MAX_SECTORS_128,
> > > >                                          dev->max_sectors);
> > > >
> > > > -       if (ata_device_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> > > > +       if (ata_dev_blacklisted(dev) & ATA_HORKAGE_ALPM) {
> > > >                 dev->horkage |= ATA_HORKAGE_ALPM;
> > > >
> > > >                 /* reset link pm_policy for this port to no pm */
> > >
> > >
> > > And to think I went through all those hoops just to avoid *this* ... :-(
> > > Anyway, please apply the attached patch and let's verify if we're both
> > > actually bit by the same bug. A screenshot of my case is available at:
> > >
> > > http://www.cse.iitk.ac.in/users/ssatyam/mtrr.show-bug.jpg
> >
> > Yep, the same bug here.
> >
> > My hunt file shows me this
> >
> > GOOD
> > x86_64-mm-i386-string-out-of-line.patch
> > BAD
> >
> > Andi?
>
>
> Does it still happen with the i386-string-out-of-line version from
> firstfloor.org:/pub/ak/x86_64/quilt/patches/ ?
>
> I fixed some issues there.

I confirm that the bug is fixed.

Yet another one:
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/00004.jpg
it looks very weird ;)

Why "Linux 2/6/22-git14 #14 SMP..." banner is displayed 5 times?

Andrew, is this a known issue?

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Andi Kleen]

On Saturday 21 July 2007 20:11, Michal Piotrowski wrote:

> I confirm that the bug is fixed.

Some string functions were optimized away. When I discovered it 
I was astonished the kernel booted at all. Anyways, it could explain
a number of weird effects.

-Andi

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Andrew Morton]

On Sat, 21 Jul 2007 20:11:16 +0200 "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:

> Yet another one:
> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/00004.jpg
> it looks very weird ;)
> 
> Why "Linux 2/6/22-git14 #14 SMP..." banner is displayed 5 times?

Was that with the fixed x86_64-mm-i386-string-out-of-line.patch?

> Andrew, is this a known issue?

Nope.  But I haven't compiled all that stuff in over a week, let
alone tried to boot it.  I assumed everyone went by the announce
emails rather than autofishing in the upload directory ;)

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Michal Piotrowski]

Andrew Morton pisze:
> On Sat, 21 Jul 2007 20:11:16 +0200 "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote:
> 
>> Yet another one:
>> http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-07-20-00-22/00004.jpg
>> it looks very weird ;)
>>
>> Why "Linux 2/6/22-git14 #14 SMP..." banner is displayed 5 times?
> 
> Was that with the fixed x86_64-mm-i386-string-out-of-line.patch?

Yes
+
modified series applied on top of 2.6.22-git14

--- series      2007-07-20 09:21:49.000000000 +0200
+++ linux-work2/series  2007-07-21 18:54:43.000000000 +0200
@@ -1,4 +1,4 @@
-origin.patch
+#origin.patch
 slow-down-printk-during-boot.patch
 slow-down-printk-during-boot-fix-2.patch
 xen-disable-vdso-nosegneg-on-native-boot.patch
@@ -131,6 +131,7 @@ libata-send-event-when-an-received.patch
 ata-ahci-alpm-store-interrupt-value.patch
 ata-ahci-alpm-expose-power-management-policy-option-to-users.patch
 ata-ahci-alpm-enable-link-power-management-for-ata-drivers.patch
+ata-ahci-alpm-enable-link-power-management-for-ata-drivers-fix.patch
 ata-ahci-alpm-enable-aggressive-link-power-management-for-ahci-controllers.patch
 #
 # experimental:
@@ -362,7 +363,8 @@ x86_64-mm-define-and-use-local_distance-
 x86_64-mm-acpi-various-cleanups.patch
 x86_64-mm-fam10-string.patch
 x86_64-mm-gcc43-memcpy.patch
-x86_64-mm-i386-string-out-of-line.patch
+#x86_64-mm-i386-string-out-of-line.patch
+i386-string-out-of-line
 x86_64-mm-gcc-hot-cold.patch
 x86_64-mm-vdso.patch
 x86_64-mm-tsc-unstable.patch
@@ -532,8 +534,8 @@ i386-remove-unnecessary-code.patch
 git-newsetup.patch
 #
 #
-git-xfs.patch
-git-xfs-fixup.patch
+#git-xfs.patch
+#git-xfs-fixup.patch
 #git-cryptodev.patch
 #git-cryptodev-fixup.patch
 #git-xtensa.patch
@@ -542,7 +544,7 @@ xtensa-enable-arbitary-tty-speed-setting
 #pci-device-ensure-sysdata-initialised-v2.patch
 git-kgdb.patch
 git-kgdb-fixup-2.patch
-mm.patch
+#mm.patch
 #
 pci-x-pci-express-read-control-interfaces-myrinet.patch
 pci-x-pci-express-read-control-interfaces-mthca.patch

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: [broken-out-2007-07-20-00-22] kernel bug at kernel/params:570

[Satyam Sharma]

Hi,

On 7/21/07, Andi Kleen <ak@suse.de> wrote:
> On Saturday 21 July 2007 20:11, Michal Piotrowski wrote:
>
> > I confirm that the bug is fixed.
>
> Some string functions were optimized away. When I discovered it
> I was astonished the kernel booted at all. Anyways, it could explain
> a number of weird effects.

Yup, and I still am astonished myself. Reading just the C sources,
there was no way param_sysfs_builtin() could've allowed an empty
string to pass into kernel_param_sysfs_setup() ... which makes me
want to see the fix for this even more, but I can't find it on your ftp
directory any more :-(

Care to resend?

Satyam