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

From: Vegard Nossum
Date: Sat Jul 19 2008 - 19:11:48 EST

On Sun, Jul 20, 2008 at 12:58 AM, Greg KH <gregkh@xxxxxxx> 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 <bwalle@xxxxxxx>
>> 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 <bwalle@xxxxxxx>
Acked-by: Greg KH <gregkh@xxxxxxx>
Acked-by: Vivek Goyal <vgoyal@xxxxxxxxxx>
Cc: kexec@xxxxxxxxxxxxxxxxxxx
Cc: yhlu.kernel@xxxxxxxxx
Signed-off-by: Ingo Molnar <mingo@xxxxxxx>

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?


"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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at