Re: 2.6.33 dies on modprobe
From: AmÃrico Wang
Date: Wed Mar 03 2010 - 03:58:29 EST
On Mon, Mar 1, 2010 at 5:07 PM, M G Berberich
> Am Montag, den 01. MÃrz schrieb AmÃrico Wang:
>> On Mon, Mar 1, 2010 at 6:12 AM, M G Berberich
>> <berberic@xxxxxxxxxxxxxxxxx> wrote:
>> > I tried to build a 2.6.33 kernel but on boot it dies on modprobe
>> > (kernel-Oops). This might be the result of faulty config, but I'm
>> > totaly clueless what's the fault.
>> > The kernel starts up fine and mounts the root-filesystem, but then
>> > dies on the first modprobe executed. I can boot it with init=/bin/bash
>> > and get a working bash (until I do modprobe on any module).
>> > System is a Gigabyte M55S-S3 rev 2.0 (nForce 550) with an AMD Athlon64
>> > X2 5000+ and amd64-kernel architecture. kernel-sources are from
>> > kernel.org.
>> It seems something is wrong with forcedeth code or PCI code.
>> Adding some Cc's.
> I don't think it's forcedeth. forcedeth just happens to be the first
> module that get's loaded in startup. It crashes with any other module
> too (I tried ohci_hcd).
Ok, below is my patch, I am not sure it could fix the BUG for you,
but it could fix the WARNING. But perhaps they are related.
Please give it a try.
It looks really odd that we do class_put() in non-failure path of
class_register(), shouldn't it be in class_unregister()?
In fact we have this problem long time ago, since commit 7c71448b,
but a recent change (commit 18d19c964) uncovers this.
Signed-off-by: WANG Cong <xiyou.wangcong@xxxxxxxxx>
Cc: Greg Kroah-Hartman <gregkh@xxxxxxx>
diff --git a/drivers/base/class.c b/drivers/base/class.c
index 6e2c3b0..ccf312d 100644
@@ -192,7 +192,6 @@ int __class_register(struct class *cls, struct lock_class_key *key)
error = add_class_attrs(class_get(cls));
@@ -200,6 +199,7 @@ EXPORT_SYMBOL_GPL(__class_register);
void class_unregister(struct class *cls)
pr_debug("device class '%s': unregistering\n", cls->name);