LinuxLists.cc - linux-next: Tree for July 18

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Sat, Jul 19, 2008 at 9:28 AM, Mariusz Kozlowski
<[email protected]> wrote:
> Hello,
>
> I get this on my x86_32 laptop.
>
> ------------[ cut here ]------------
> WARNING: at /home/mako/linux/lkt/sources/linux-next/kernel/lockdep.c:2068 trace_hardirqs_on_caller+0xdc/0x128()
> Modules linked in:
> Pid: 0, comm: swapper Not tainted 2.6.26-next-20080718 #1
> [<c011d5ca>] warn_on_slowpath+0x4e/0x68
> [<c0132600>] ? init_srcu_struct+0x17/0x3b
> [<c011de86>] ? release_console_sem+0x1c2/0x1e8
> [<c0139818>] ? trace_hardirqs_off+0xb/0xd
> [<c02b95cb>] ? _spin_unlock_irqrestore+0x39/0x60
> [<c011de9a>] ? release_console_sem+0x1d6/0x1e8
> [<c01326be>] ? up+0x23/0x30
> [<c011de86>] ? release_console_sem+0x1c2/0x1e8
> [<c01326be>] ? up+0x23/0x30
> [<c011de86>] ? release_console_sem+0x1c2/0x1e8
> [<c013b83b>] ? __lock_acquire+0x365/0x1151
> [<c013b048>] trace_hardirqs_on_caller+0xdc/0x128
> [<c013b09f>] trace_hardirqs_on+0xb/0xd
> [<c016a40b>] __slab_alloc+0x329/0x61e
> [<c011665f>] ? kmemcheck_memset+0x24/0xe5
> [<c016a7a0>] kmem_cache_alloc+0xa0/0xb6
> [<c01dedb4>] ? kobject_init+0x3b/0xdd
> [<c01dedb4>] ? kobject_init+0x3b/0xdd
> [<c01dedb4>] kobject_init+0x3b/0xdd
> [<c025997f>] firmware_map_add_entry+0x2a/0x4b
> [<c03b8e0c>] firmware_map_add_early+0x32/0x56
> [<c03a3faf>] e820_reserve_resources+0x10a/0x14e
> [<c03a1965>] setup_arch+0x375/0x540
> [<c0136e81>] ? clockevents_register_notifier+0x28/0x2d
> [<c011e477>] ? printk+0x1b/0x1d
> [<c03a09df>] start_kernel+0x67/0x278
> [<c03a0304>] i386_start_kernel+0x64/0x70
> =======================
> ---[ end trace 4eaa2a86a8e2da22 ]---
>

What I don't get here is how SLUB can be used this early in the boot
process. Notice that this is still miles away from the

SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1

line, which comes much later. And that kobject_init() _is_ calling
kzalloc() via verify_dynamic_kobject_allocation(). Isn't this an
error?

(Unfortunately, my "git log" doesn't turn up any recent changes for
any of the affected code paths here.)

Vegard

--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036

2008-07-19 12:56:56

by Pekka Enberg

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Sat, 2008-07-19 at 11:55 +0200, Vegard Nossum wrote:
> On Sat, Jul 19, 2008 at 9:28 AM, Mariusz Kozlowski
> <[email protected]> wrote:
> > Hello,
> >
> > I get this on my x86_32 laptop.
> >
> > ------------[ cut here ]------------
> > WARNING: at /home/mako/linux/lkt/sources/linux-next/kernel/lockdep.c:2068 trace_hardirqs_on_caller+0xdc/0x128()
> > Modules linked in:
> > Pid: 0, comm: swapper Not tainted 2.6.26-next-20080718 #1
> > [<c011d5ca>] warn_on_slowpath+0x4e/0x68
> > [<c0132600>] ? init_srcu_struct+0x17/0x3b
> > [<c011de86>] ? release_console_sem+0x1c2/0x1e8
> > [<c0139818>] ? trace_hardirqs_off+0xb/0xd
> > [<c02b95cb>] ? _spin_unlock_irqrestore+0x39/0x60
> > [<c011de9a>] ? release_console_sem+0x1d6/0x1e8
> > [<c01326be>] ? up+0x23/0x30
> > [<c011de86>] ? release_console_sem+0x1c2/0x1e8
> > [<c01326be>] ? up+0x23/0x30
> > [<c011de86>] ? release_console_sem+0x1c2/0x1e8
> > [<c013b83b>] ? __lock_acquire+0x365/0x1151
> > [<c013b048>] trace_hardirqs_on_caller+0xdc/0x128
> > [<c013b09f>] trace_hardirqs_on+0xb/0xd
> > [<c016a40b>] __slab_alloc+0x329/0x61e
> > [<c011665f>] ? kmemcheck_memset+0x24/0xe5
> > [<c016a7a0>] kmem_cache_alloc+0xa0/0xb6
> > [<c01dedb4>] ? kobject_init+0x3b/0xdd
> > [<c01dedb4>] ? kobject_init+0x3b/0xdd
> > [<c01dedb4>] kobject_init+0x3b/0xdd
> > [<c025997f>] firmware_map_add_entry+0x2a/0x4b
> > [<c03b8e0c>] firmware_map_add_early+0x32/0x56
> > [<c03a3faf>] e820_reserve_resources+0x10a/0x14e
> > [<c03a1965>] setup_arch+0x375/0x540
> > [<c0136e81>] ? clockevents_register_notifier+0x28/0x2d
> > [<c011e477>] ? printk+0x1b/0x1d
> > [<c03a09df>] start_kernel+0x67/0x278
> > [<c03a0304>] i386_start_kernel+0x64/0x70
> > =======================
> > ---[ end trace 4eaa2a86a8e2da22 ]---
> >
>
> What I don't get here is how SLUB can be used this early in the boot
> process. Notice that this is still miles away from the
>
> SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>
> line, which comes much later. And that kobject_init() _is_ calling
> kzalloc() via verify_dynamic_kobject_allocation(). Isn't this an
> error?
>
> (Unfortunately, my "git log" doesn't turn up any recent changes for
> any of the affected code paths here.)

Indeed, looks like a bug in kobject_init(). You need to wait for
kmem_cache_init() to be run before using kzalloc().

Pekka

2008-07-19 12:59:33

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Sat, Jul 19, 2008 at 11:55 AM, Vegard Nossum <[email protected]> wrote:
> What I don't get here is how SLUB can be used this early in the boot
> process. Notice that this is still miles away from the
>
> SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>
> line, which comes much later. And that kobject_init() _is_ calling
> kzalloc() via verify_dynamic_kobject_allocation(). Isn't this an
> error?
>
> (Unfortunately, my "git log" doesn't turn up any recent changes for
> any of the affected code paths here.)

Ehe... and this is the reason why: The code was added by this patch:

commit 0e3638d1e04040121af00195f7e4628078246489
Author: Dave Hansen <[email protected]>
Date: Thu Mar 16 17:30:16 2006 -0800

warn when statically-allocated kobjects are used

..which only exists in -next. Is that just a truly ancient patch, or
did somebody forget to adjust their clock?

(Stephen: Maybe this has been answered before, but what's the best way
to figure out where it came from?)

Vegard

--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036

2008-07-19 13:23:19

by Stephen Rothwell

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

Hi Vegard,

On Sat, 19 Jul 2008 14:59:12 +0200 "Vegard Nossum" <[email protected]> wrote:
>
> Ehe... and this is the reason why: The code was added by this patch:
>
> commit 0e3638d1e04040121af00195f7e4628078246489
> Author: Dave Hansen <[email protected]>
> Date: Thu Mar 16 17:30:16 2006 -0800
>
> warn when statically-allocated kobjects are used
>
> ..which only exists in -next. Is that just a truly ancient patch, or
> did somebody forget to adjust their clock?
>
> (Stephen: Maybe this has been answered before, but what's the best way
> to figure out where it came from?)

The easiest way is to ask me to look in my source tree (since I have the
heads of all the branches I merge - at least until the next day and gitk
then makes it easy ...).

In this case, that commit comes from the driver-core tree.

--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/

Attachments:

(No filename) (933.00 B)
(No filename) (197.00 B)
Download all attachments

2008-07-19 15:36:17

by Bartlomiej Zolnierkiewicz

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18 (very early crash on x86_32)

Hi,

Since around next-20080709 linux-next has been crashing very early in
the boot on my x86_32 laptop (the problem is also reproducible under
qemu, config & screenshot attached). Now that merging has paused for
a moment I took a closer look into the issue.

First I bisected it down to commit 99c2fcc5306153c8ae56542b3e80dddaf77baa45
("Merge branch 'quilt/driver-core'") and then with a little patchwork I
identified the source as a commit 0e3638d1e04040121af00195f7e4628078246489
("warn when statically-allocated kobjects are used").

With commit 0e3638d1e04040121af00195f7e4628078246489 reverted and fixup
from Al for vfs-next/net-next conflict (http://lkml.org/lkml/2008/7/18/591)
next-20080718 works fine for me.

BTW ide tree's conflicts against Linus' tree should be fixed now.

Thanks,
Bart

Attachments:

(No filename) (802.00 B)
bug.png (22.34 kB)
bug.config (55.90 kB)
Download all attachments

2008-07-19 22:20:58

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Sat, Jul 19, 2008 at 02:59:12PM +0200, Vegard Nossum wrote:
> On Sat, Jul 19, 2008 at 11:55 AM, Vegard Nossum <[email protected]> wrote:
> > What I don't get here is how SLUB can be used this early in the boot
> > process. Notice that this is still miles away from the
> >
> > SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> >
> > line, which comes much later. And that kobject_init() _is_ calling
> > kzalloc() via verify_dynamic_kobject_allocation(). Isn't this an
> > error?
> >
> > (Unfortunately, my "git log" doesn't turn up any recent changes for
> > any of the affected code paths here.)
>
> Ehe... and this is the reason why: The code was added by this patch:
>
> commit 0e3638d1e04040121af00195f7e4628078246489
> Author: Dave Hansen <[email protected]>
> Date: Thu Mar 16 17:30:16 2006 -0800
>
> warn when statically-allocated kobjects are used
>
> ..which only exists in -next. Is that just a truly ancient patch, or
> did somebody forget to adjust their clock?

It is truely a very old patch, that only lives in my tree, and currently
isn't planned to go to Linus any year soon.

But it has a very long history of living in the -mm tree, and finding
real bugs, it's just not "safe" enough to go to Linus's tree. Unless
you think it is?

thanks,

greg k-h

2008-07-19 22:27:37

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Sun, Jul 20, 2008 at 12:17 AM, Greg KH <[email protected]> wrote:
> On Sat, Jul 19, 2008 at 02:59:12PM +0200, Vegard Nossum wrote:
>> On Sat, Jul 19, 2008 at 11:55 AM, Vegard Nossum <[email protected]> wrote:
>> > What I don't get here is how SLUB can be used this early in the boot
>> > process. Notice that this is still miles away from the
>> >
>> > SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
>> >
>> > line, which comes much later. And that kobject_init() _is_ calling
>> > kzalloc() via verify_dynamic_kobject_allocation(). Isn't this an
>> > error?
>> >
>> > (Unfortunately, my "git log" doesn't turn up any recent changes for
>> > any of the affected code paths here.)
>>
>> Ehe... and this is the reason why: The code was added by this patch:
>>
>> commit 0e3638d1e04040121af00195f7e4628078246489
>> Author: Dave Hansen <[email protected]>
>> Date: Thu Mar 16 17:30:16 2006 -0800
>>
>> warn when statically-allocated kobjects are used
>>
>> ..which only exists in -next. Is that just a truly ancient patch, or
>> did somebody forget to adjust their clock?
>
> It is truely a very old patch, that only lives in my tree, and currently
> isn't planned to go to Linus any year soon.
>
> But it has a very long history of living in the -mm tree, and finding
> real bugs, it's just not "safe" enough to go to Linus's tree. Unless
> you think it is?

Hm. In this case, the patch is not even reporting a problem, it is in
fact in error itself.

The problem is that it calls kzalloc() before the slab caches have
been set up. (Yes, it's a wonder that nothing crashed.) I can only
suggest the addendum

if (!slab_is_available())
return;

Vegard

--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036

2008-07-19 22:44:37

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Sun, Jul 20, 2008 at 12:27:26AM +0200, Vegard Nossum wrote:
> On Sun, Jul 20, 2008 at 12:17 AM, Greg KH <[email protected]> wrote:
> > On Sat, Jul 19, 2008 at 02:59:12PM +0200, Vegard Nossum wrote:
> >> On Sat, Jul 19, 2008 at 11:55 AM, Vegard Nossum <[email protected]> wrote:
> >> > What I don't get here is how SLUB can be used this early in the boot
> >> > process. Notice that this is still miles away from the
> >> >
> >> > SLUB: Genslabs=12, HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> >> >
> >> > line, which comes much later. And that kobject_init() _is_ calling
> >> > kzalloc() via verify_dynamic_kobject_allocation(). Isn't this an
> >> > error?
> >> >
> >> > (Unfortunately, my "git log" doesn't turn up any recent changes for
> >> > any of the affected code paths here.)
> >>
> >> Ehe... and this is the reason why: The code was added by this patch:
> >>
> >> commit 0e3638d1e04040121af00195f7e4628078246489
> >> Author: Dave Hansen <[email protected]>
> >> Date: Thu Mar 16 17:30:16 2006 -0800
> >>
> >> warn when statically-allocated kobjects are used
> >>
> >> ..which only exists in -next. Is that just a truly ancient patch, or
> >> did somebody forget to adjust their clock?
> >
> > It is truely a very old patch, that only lives in my tree, and currently
> > isn't planned to go to Linus any year soon.
> >
> > But it has a very long history of living in the -mm tree, and finding
> > real bugs, it's just not "safe" enough to go to Linus's tree. Unless
> > you think it is?
>
> Hm. In this case, the patch is not even reporting a problem, it is in
> fact in error itself.
>
> The problem is that it calls kzalloc() before the slab caches have
> been set up. (Yes, it's a wonder that nothing crashed.) I can only
> suggest the addendum
>
> if (!slab_is_available())
> return;

That's odd, what changed to cause this to become a problem? Is a
kobject somehow now being created too early in the boot process than it
was in the past? This code hasn't changed in a very long time, so I'm
loath to blame this code, odds are the root cause is somewhere else...

thanks,

greg k-h

2008-07-19 22:44:53

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Sun, Jul 20, 2008 at 12:27 AM, Vegard Nossum <[email protected]> wrote:
>>> commit 0e3638d1e04040121af00195f7e4628078246489
>>> Author: Dave Hansen <[email protected]>
>>> Date: Thu Mar 16 17:30:16 2006 -0800
>>>
>>> warn when statically-allocated kobjects are used
>>>
>>> ..which only exists in -next. Is that just a truly ancient patch, or
>>> did somebody forget to adjust their clock?
>>
>> It is truely a very old patch, that only lives in my tree, and currently
>> isn't planned to go to Linus any year soon.
>>
>> But it has a very long history of living in the -mm tree, and finding
>> real bugs, it's just not "safe" enough to go to Linus's tree. Unless
>> you think it is?
>
> Hm. In this case, the patch is not even reporting a problem, it is in
> fact in error itself.
>
> The problem is that it calls kzalloc() before the slab caches have
> been set up. (Yes, it's a wonder that nothing crashed.) I can only
> suggest the addendum
>
> if (!slab_is_available())
> return;

Well, of course, it's also possible that the e820 code shouldn't be
initializing kobjects this early in the first place.

firmware_map_add_early() is using bootmem for the allocation. So yes,
I guess it should possible to use kobjects here. That said, this code
is in fact fairly recent:

commit 69ac9cd629ca96e59f34eb4ccd12d00b2c8276a7
Author: Bernhard Walle <[email protected]>
Date: Fri Jun 27 13:12:54 2008 +0200

sysfs: add /sys/firmware/memmap

I'll add the Cc. I still have a feeling that the kobject patch should
expect to run even when slab is not available.

Vegard

--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036

2008-07-19 23:02:10

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Sun, Jul 20, 2008 at 12:44:38AM +0200, Vegard Nossum wrote:
> On Sun, Jul 20, 2008 at 12:27 AM, Vegard Nossum <[email protected]> wrote:
> >>> commit 0e3638d1e04040121af00195f7e4628078246489
> >>> Author: Dave Hansen <[email protected]>
> >>> Date: Thu Mar 16 17:30:16 2006 -0800
> >>>
> >>> warn when statically-allocated kobjects are used
> >>>
> >>> ..which only exists in -next. Is that just a truly ancient patch, or
> >>> did somebody forget to adjust their clock?
> >>
> >> It is truely a very old patch, that only lives in my tree, and currently
> >> isn't planned to go to Linus any year soon.
> >>
> >> But it has a very long history of living in the -mm tree, and finding
> >> real bugs, it's just not "safe" enough to go to Linus's tree. Unless
> >> you think it is?
> >
> > Hm. In this case, the patch is not even reporting a problem, it is in
> > fact in error itself.
> >
> > The problem is that it calls kzalloc() before the slab caches have
> > been set up. (Yes, it's a wonder that nothing crashed.) I can only
> > suggest the addendum
> >
> > if (!slab_is_available())
> > return;
>
> Well, of course, it's also possible that the e820 code shouldn't be
> initializing kobjects this early in the first place.

That's probably the case, the kobject code isn't able to handle this
kind of thing (sysfs included).

> firmware_map_add_early() is using bootmem for the allocation. So yes,
> I guess it should possible to use kobjects here. That said, this code
> is in fact fairly recent:
>
> commit 69ac9cd629ca96e59f34eb4ccd12d00b2c8276a7
> Author: Bernhard Walle <[email protected]>
> Date: Fri Jun 27 13:12:54 2008 +0200
>
> sysfs: add /sys/firmware/memmap
>
> I'll add the Cc. I still have a feeling that the kobject patch should
> expect to run even when slab is not available.

I never has been expected to do so in the past, so odds are, lots of
things might break :(

thanks,

greg k-h

2008-07-19 23:11:47

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Sun, Jul 20, 2008 at 12:58 AM, Greg KH <[email protected]> wrote:
>> firmware_map_add_early() is using bootmem for the allocation. So yes,
>> I guess it should possible to use kobjects here. That said, this code
>> is in fact fairly recent:
>>
>> commit 69ac9cd629ca96e59f34eb4ccd12d00b2c8276a7
>> Author: Bernhard Walle <[email protected]>
>> Date: Fri Jun 27 13:12:54 2008 +0200
>>
>> sysfs: add /sys/firmware/memmap
>>
>> I'll add the Cc. I still have a feeling that the kobject patch should
>> expect to run even when slab is not available.
>
> I never has been expected to do so in the past, so odds are, lots of
> things might break :(

Yeah. Maybe you should withdraw your ack? :-D

Signed-off-by: Bernhard Walle <[email protected]>
Acked-by: Greg KH <[email protected]>
Acked-by: Vivek Goyal <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Ingo Molnar <[email protected]>

I'm sorry for having been a bit rash earlier -- it's the combination
of the patches that produce the failure; they both seem okay on their
own. On the other hand, this is what -next is for, isn't it?

Maybe the firmware memmap code can simply run a little later in the
boot sequence?

Vegard

--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036

2008-07-19 23:23:53

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Sun, Jul 20, 2008 at 01:11:36AM +0200, Vegard Nossum wrote:
> On Sun, Jul 20, 2008 at 12:58 AM, Greg KH <[email protected]> wrote:
> >> firmware_map_add_early() is using bootmem for the allocation. So yes,
> >> I guess it should possible to use kobjects here. That said, this code
> >> is in fact fairly recent:
> >>
> >> commit 69ac9cd629ca96e59f34eb4ccd12d00b2c8276a7
> >> Author: Bernhard Walle <[email protected]>
> >> Date: Fri Jun 27 13:12:54 2008 +0200
> >>
> >> sysfs: add /sys/firmware/memmap
> >>
> >> I'll add the Cc. I still have a feeling that the kobject patch should
> >> expect to run even when slab is not available.
> >
> > I never has been expected to do so in the past, so odds are, lots of
> > things might break :(
>
> Yeah. Maybe you should withdraw your ack? :-D
>
> Signed-off-by: Bernhard Walle <[email protected]>
> Acked-by: Greg KH <[email protected]>
> Acked-by: Vivek Goyal <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Signed-off-by: Ingo Molnar <[email protected]>

Heh, I didn't realize that this ran so early in the boot process, the
code logically looks correct :)

> I'm sorry for having been a bit rash earlier -- it's the combination
> of the patches that produce the failure; they both seem okay on their
> own. On the other hand, this is what -next is for, isn't it?

Yup.

> Maybe the firmware memmap code can simply run a little later in the
> boot sequence?

Possibly. I wonder why this is only a problem on your machine and not
on anything that Ingo tested?

thanks,

greg k-h

2008-07-20 00:18:26

by Rafael J. Wysocki

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: sky2 WOL broken

On Friday, 18 of July 2008, Stephen Rothwell wrote:
> Hi all,
>
> Changes since next-20080717:
>
> Restored tree: ttydev.
>
> Temporarily dropped tree: acpi (confusion about its source).
>
> Most of the differences were conflicts moving from tree to tree as some
> of the trees are now merged into Linus' tree. Most have been inflicted
> on the driver-core and usb trees. I have not notified these separately.
>
> Because of the moving of conflicts around it is difficult to tell when
> they are going away (though I assume some are).
>
> The driver-core tree gained a conflict against Linus' tree.
>
> The usb tree inherited a build fix patch from the pci tree.
>
> The x86 tree gained a trivial conflict against Linus' tree but it was in
> a commit that is still being reverted.
>
> The ocsf2 tree gained several conflicts against Linus' tree because what
> was sent to Linus was not the same as what is in linuxt-next.
>
> The vfs tree gained conflicts against Linus' tree, the sparc tree and the
> mips tree.
>
> The semaphore-removal tree gained conflicts against Linus' tree that
> required the reversion of two commits.
>
> The ttydev tree had two patches that didn't apply and gained conflicts
> against the wireless tree and the usb tree (4). It also required a build
> fix patch.
>
> Lots of conflicts have gone from the x86 and ubifs trees.
>
> I have also applied the following patches for known problems:
>
> sparc64: sysdev API change fallout
> sparc32: smp_call_function API change fallout (this has already
> been fixed in the upstream sparc tree and comes from an incomplete merge
> on my part).
>
> This tree fails to build for ARCH=sparc (i.e. 32bit) with a 64bit gcc
> v3.4.5 - it tries to use the 64bit header files. This may be an artifact
> of one of my merge fixups, but I don't actually think so.
>
> ----------------------------------------------------------------------------

commit db99b98885e717454feef1c6868b27d3f23c2e7c
Author: Stephen Hemminger <[email protected]>
Date: Wed May 14 17:04:16 2008 -0700

sky2: put PHY in sleep when down

and

commit a068c0adf2fe28b324bca87f85d27af7f993cdaf
Author: Stephen Hemminger <[email protected]>
Date: Wed May 14 17:04:17 2008 -0700

sky2: pci power savings

break Wake-on-LAN on my test box using sky2. More specifically, with these
two commits applied the box hangs solid during hibernation/power off
while executing the sky2 callbacks.

The adapter is reported as 88E8056 (Asus M3A32-MVP Deluxe mainboard).

Thanks,
Rafael

2008-07-20 09:01:21

by Dave Hansen

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Sun, 2008-07-20 at 01:11 +0200, Vegard Nossum wrote:
> Maybe the firmware memmap code can simply run a little later in the
> boot sequence?

Heh, I'm catching up on this thread...

It is possible that it could run later. But, I do know that there are
at least a couple of these tables (on various arches) that we toss out
of memory or become unavailable later in boot.

I do this this:

sysfs: add /sys/firmware/memmap

is really being done at the wrong level. I don't, for instance, see
*any* reference to memory hotplug in these patches. That's because
they're done against firmware structures, and memory hotplug doesn't
update firmware structures on the two architectures that I can remember
(ppc64 and x86).

In other words, kexec using this probably won't work on a memory hotplug
machine.

Secondly, why don't we just modify the
existing /sys/devices/system/memory things to properly export what exec
needs? They're already cross-platform *and* they're updated with memory
hotplug events.

-- Dave

2008-07-20 09:36:51

by Thomas Meyer

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

Am Sonntag, den 20.07.2008, 02:01 -0700 schrieb Dave Hansen:
> On Sun, 2008-07-20 at 01:11 +0200, Vegard Nossum wrote:
> > Maybe the firmware memmap code can simply run a little later in the
> > boot sequence?
>
> Heh, I'm catching up on this thread...
>

On that thread?

http://lkml.org/lkml/2008/7/15/108

2008-07-20 12:48:58

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

* "Vegard Nossum" <[email protected]> [2008-07-20 00:44]:
>
> On Sun, Jul 20, 2008 at 12:27 AM, Vegard Nossum <[email protected]> wrote:
> >>> commit 0e3638d1e04040121af00195f7e4628078246489
> >>> Author: Dave Hansen <[email protected]>
> >>> Date: Thu Mar 16 17:30:16 2006 -0800
> >>>
> >>> warn when statically-allocated kobjects are used
> >>>
> >>> ..which only exists in -next. Is that just a truly ancient patch, or
> >>> did somebody forget to adjust their clock?
> >>
> >> It is truely a very old patch, that only lives in my tree, and currently
> >> isn't planned to go to Linus any year soon.
> >>
> >> But it has a very long history of living in the -mm tree, and finding
> >> real bugs, it's just not "safe" enough to go to Linus's tree. Unless
> >> you think it is?
> >
> > Hm. In this case, the patch is not even reporting a problem, it is in
> > fact in error itself.
> >
> > The problem is that it calls kzalloc() before the slab caches have
> > been set up. (Yes, it's a wonder that nothing crashed.) I can only
> > suggest the addendum
> >
> > if (!slab_is_available())
> > return;
>
> Well, of course, it's also possible that the e820 code shouldn't be
> initializing kobjects this early in the first place.
>
> firmware_map_add_early() is using bootmem for the allocation. So yes,
> I guess it should possible to use kobjects here. That said, this code
> is in fact fairly recent:
>
> commit 69ac9cd629ca96e59f34eb4ccd12d00b2c8276a7
> Author: Bernhard Walle <[email protected]>
> Date: Fri Jun 27 13:12:54 2008 +0200
>
> sysfs: add /sys/firmware/memmap
>
> I'll add the Cc. I still have a feeling that the kobject patch should
> expect to run even when slab is not available.

I already posted a fix for that problem, see
http://article.gmane.org/gmane.linux.kernel.kexec/1882.

Which people should I CC to get that fix into linux-next?

Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

2008-07-20 12:51:47

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

* Greg KH <[email protected]> [2008-07-19 16:20]:
>
> > Maybe the firmware memmap code can simply run a little later in the
> > boot sequence?
>
> Possibly. I wonder why this is only a problem on your machine and not
> on anything that Ingo tested?

It also was on my machine when I tested it on linux-next. That's why I
made the patch as described in

http://article.gmane.org/gmane.linux.kernel.kexec/1882.

However, it was not in tip tree. It seems to be the combination of
patches, but I don't know why and I didn't have the time to find it
out, the fix was much easier.

Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

2008-07-20 13:03:55

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

* Dave Hansen <[email protected]> [2008-07-20 02:01]:
>
> It is possible that it could run later. But, I do know that there are
> at least a couple of these tables (on various arches) that we toss out
> of memory or become unavailable later in boot.
>
> I do this this:
>
> sysfs: add /sys/firmware/memmap
>
> is really being done at the wrong level.

I posted that patches multiple times. They were reviewed by the kdump
maintainer and by the kexec maintainer. Why didn't you mention it
*there* that this is the wrong way?

> I don't, for instance, see
> *any* reference to memory hotplug in these patches.

Right. The idea was to add memory hotplugging later. I decided to
create the patch series, get some review, and then fix the rest of the
systems that use memory hot-plugging. So, do you see a problem (in
theory) to add memory and remove memory in that sysfs interface? Of
course the code must be extended to handle modifications in the linked
list afterwards. Yes, I should have made that extension just after the
patch went into tip. Unfortunately, I didn't have time so far.

> Secondly, why don't we just modify the existing /sys/devices/system/memory

Because I didn't know that interface. And because I don't see that
interface on my two systems that I just checked. i386 and x86-64. What
do I have to do to enable that interface?

Does that interface export the *used* memory or just export the memory
that is available? Because exactly that was the reason why I made that
modification -- because kexec needs to know the *available* memory even
if that memory is disabled via 'memmap' or 'mem' command line
parameters.

Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

2008-07-20 15:45:21

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

* Bernhard Walle <[email protected]> [2008-07-20 15:03]:
>
> Because I didn't know that interface. And because I don't see that
> interface on my two systems that I just checked. i386 and x86-64. What
> do I have to do to enable that interface?

That interface depends on CONFIG_MEMORY_HOTPLUG. But given to that
dependency list,

128 config MEMORY_HOTPLUG
129 bool "Allow for memory hot-add"
130 depends on SPARSEMEM || X86_64_ACPI_NUMA
131 depends on HOTPLUG && !HIBERNATION && ARCH_ENABLE_MEMORY_HOTPLUG
132 depends on (IA64 || X86 || PPC64 || SUPERH || S390)

that interface is off on *many* systems (i386, x86_64), so we can't rely
on that interface in kexec. I think on POWER it's much more common than
on PC architectures.

Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

2008-07-21 13:19:37

by Vivek Goyal

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Sun, Jul 20, 2008 at 02:01:02AM -0700, Dave Hansen wrote:
> On Sun, 2008-07-20 at 01:11 +0200, Vegard Nossum wrote:
> > Maybe the firmware memmap code can simply run a little later in the
> > boot sequence?
>
> Heh, I'm catching up on this thread...
>
> It is possible that it could run later. But, I do know that there are
> at least a couple of these tables (on various arches) that we toss out
> of memory or become unavailable later in boot.
>
> I do this this:
>
> sysfs: add /sys/firmware/memmap
>
> is really being done at the wrong level. I don't, for instance, see
> *any* reference to memory hotplug in these patches. That's because
> they're done against firmware structures, and memory hotplug doesn't
> update firmware structures on the two architectures that I can remember
> (ppc64 and x86).
>
> In other words, kexec using this probably won't work on a memory hotplug
> machine.

If memory is just being added and not being removed then kexec will
continue to work. Just that newly added memory will not be visible to
second kernel. (Unless we start modifying /sys/firmware/memmap upon
memory hotplug event).

Is /proc/iomem updated upon memory hotplug event. All these years, kexec
has been using that interace.

>
> Secondly, why don't we just modify the
> existing /sys/devices/system/memory things to properly export what exec
> needs? They're already cross-platform *and* they're updated with memory
> hotplug events.

As bernhard mentioned that above interface has got long dependeny list
and will not work for kexec until and unless we get rid of those
dependencies.

What does /sys/devices/system/memory represent? All the physical memory
present in the system or all the physical memory being used by kernel
(for example, memory limited by command line options mem=).

If it represents all the physical memory present in the system then it
might make sense to not create another interface but to use this one for
kexec. (But we shall have to get rid of long list of dependencies so that
it can gel wil more universal appeal of kexec).

Do you think that we can decouple /sys/devices/system/memory interface with
CONFIG_MEMORY_HOTPLUG?

Thanks
Vivek

2008-07-21 13:25:20

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

* Vivek Goyal [2008-07-21 09:17]:
>
> Is /proc/iomem updated upon memory hotplug event.

Yes. I just checked that (yesterday).

I think it would make sense to extend /sys/firmware/memmap on
hot-plugging. Just because on reboot, the firmware will see that
memory, too, and report it. However, we need a way to discriminate the
originally firmware-provided memory map with later added memory. I'm
not sure how that can be done, I have to think about it.

Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

2008-07-21 13:42:29

by Vivek Goyal

[permalink] [raw]

Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on_caller

On Mon, Jul 21, 2008 at 03:25:39PM +0200, Bernhard Walle wrote:
> * Vivek Goyal [2008-07-21 09:17]:
> >
> > Is /proc/iomem updated upon memory hotplug event.
>
> Yes. I just checked that (yesterday).
>
> I think it would make sense to extend /sys/firmware/memmap on
> hot-plugging. Just because on reboot, the firmware will see that
> memory, too, and report it. However, we need a way to discriminate the
> originally firmware-provided memory map with later added memory. I'm
> not sure how that can be done, I have to think about it.

Probably use another type of RAM identifier (System RAM (hotplug)).

But the point is, if /sys/devices/system/memory also represents all
the physical memory present in the system then it might be not be
justified to create another similar interface. (Until and unless there
is something unique about /sys/firmware/memmap).

Thanks
Vivek

2008-07-21 15:00:19