On Thu, 22 Mar 2007 07:23:06 -0500,
Larry Finger <[EMAIL PROTECTED]> wrote:
> Cornelia Huck wrote:
> > On Wed, 21 Mar 2007 23:39:17 -0800,
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> >> On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote:
> >>
> >>> With the latest -mm, I'm now getting this:
> >>>
> >>> Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
> >>> 2200BG Network Connection
> >>> Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
> >>> value (0)
> >>> Mar 21 15:06:52 cinder kernel: ipw2200: ipw2200-bss.fw
> >>> request_firmware failed:
> >>> Reason -2
> >>> Mar 21 15:06:52 cinder kernel: ipw2200: Unable to load firmware: -2
> >>> Mar 21 15:06:52 cinder kernel: ipw2200: failed to register network
> >>> device
> >> The firmware loading bug is caused by
> >> driver-core-handles-kobject_uevent-failure-while-device_add.patch
> >
> > Hm, this patch looks sane. It might be a good idea to enable
> > CONFIG_DEBUG_KOBJECT and find out why kobject_uevent() actually fails
> > in this case...
>
> Attached is the appropriate portion of /var/log/messages with Kobject
> debugging enabled.
> Mar 22 07:01:42 larrylap2 kernel: kobject 0000:01:00.0: registering. parent:
> firmware, set: devices
> Mar 22 07:01:42 larrylap2 kernel: kobject_uevent_env
> Mar 22 07:01:42 larrylap2 kernel: fill_kobj_path: path =
> '/class/firmware/0000:01:00.0'
> Mar 22 07:01:42 larrylap2 kernel: fill_kobj_path: path =
> '/devices/pci0000:00/0000:00:02.0/0000:01:00.0'
> Mar 22 07:01:42 larrylap2 kernel: kobject_uevent_env
> Mar 22 07:01:42 larrylap2 ntpd[3434]: frequency initialized -31.513 PPM from
> /var/lib/ntp/drift/ntp.drift
> Mar 22 07:01:43 larrylap2 kernel: fill_kobj_path: path =
> '/class/firmware/0000:01:00.0'
> Mar 22 07:01:43 larrylap2 kernel: fill_kobj_path: path =
> '/devices/pci0000:00/0000:00:02.0/0000:01:00.0'
> Mar 22 07:01:43 larrylap2 kernel: firmware_loading_store: unexpected value (0)
> Mar 22 07:01:43 larrylap2 kernel: kobject_uevent_env
> Mar 22 07:01:43 larrylap2 kernel: fill_kobj_path: path =
> '/class/firmware/0000:01:00.0'
> Mar 22 07:01:43 larrylap2 kernel: fill_kobj_path: path =
> '/devices/pci0000:00/0000:00:02.0/0000:01:00.0'
> Mar 22 07:01:43 larrylap2 kernel: kobject 0000:01:00.0: cleaning up
(Repeating several times)
This would indicate that dev_uevent had been called. But how could
kobject_uevent then return an error without moaning about an uevent()
error code? Maybe the following debug patch could shed some light on
this (all moaning is prefixed with kobject_uevent_env, so it should be
easy to spot)...
---
lib/kobject_uevent.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
--- linux-2.6.orig/lib/kobject_uevent.c
+++ linux-2.6/lib/kobject_uevent.c
@@ -85,11 +85,11 @@ int kobject_uevent_env(struct kobject *k
int retval = 0;
int j;
- pr_debug("%s\n", __FUNCTION__);
+ pr_debug("%s: %s\n", __FUNCTION__, kobject_name(kobj));
action_string = action_to_string(action);
if (!action_string) {
- pr_debug("kobject attempted to send uevent without
action_string!\n");
+ pr_debug("%s: kobject attempted to send uevent without
action_string!\n", __FUNCTION__);
return -EINVAL;
}
@@ -101,7 +101,7 @@ int kobject_uevent_env(struct kobject *k
} while (!top_kobj->kset && top_kobj->parent);
}
if (!top_kobj->kset) {
- pr_debug("kobject attempted to send uevent without kset!\n");
+ pr_debug("%s: kobject attempted to send uevent without
kset!\n", __FUNCTION__);
return -EINVAL;
}
@@ -111,7 +111,7 @@ int kobject_uevent_env(struct kobject *k
/* skip the event, if the filter returns zero. */
if (uevent_ops && uevent_ops->filter)
if (!uevent_ops->filter(kset, kobj)) {
- pr_debug("kobject filter function caused the event to
drop!\n");
+ pr_debug("%s: kobject filter function caused the event
to drop!\n", __FUNCTION__);
return 0;
}
@@ -121,18 +121,20 @@ int kobject_uevent_env(struct kobject *k
else
subsystem = kobject_name(&kset->kobj);
if (!subsystem) {
- pr_debug("unset subsytem caused the event to drop!\n");
+ pr_debug("%s: unset subsytem caused the event to drop!\n",
__FUNCTION__);
return 0;
}
/* environment index */
envp = kzalloc(NUM_ENVP * sizeof (char *), GFP_KERNEL);
- if (!envp)
+ if (!envp) {
+ pr_debug("%s: couldn't alloc envp\n", __FUNCTION__);
return -ENOMEM;
-
+ }
/* environment values */
buffer = kmalloc(BUFFER_SIZE, GFP_KERNEL);
if (!buffer) {
+ pr_debug("%s: couldn't alloc buffer\n", __FUNCTION__);
retval = -ENOMEM;
goto exit;
}
@@ -140,6 +142,7 @@ int kobject_uevent_env(struct kobject *k
/* complete object path */
devpath = kobject_get_path(kobj, GFP_KERNEL);
if (!devpath) {
+ pr_debug("%s: couldn't get kobject path\n", __FUNCTION__);
retval = -ENOENT;
goto exit;
}
@@ -221,6 +224,7 @@ exit:
kfree(devpath);
kfree(buffer);
kfree(envp);
+ pr_debug("%s: returning %d\n", __FUNCTION__, retval);
return retval;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
