RE: [patch 2.6.12-rc3] modifications in firmware_class.c to support nohotplug
From: Abhay_Salunke
Date: Fri Jun 10 2005 - 14:46:57 EST
> > > > -----Original Message-----
> > > > From: Greg KH [mailto:greg@xxxxxxxxx]
> > > > Sent: Wednesday, June 08, 2005 11:10 AM
> > > > To: Salunke, Abhay
> > > > Cc: dtor_core@xxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> > > akpm@xxxxxxxx;
> > > > Domsch, Matt; ranty@xxxxxxxxxx
> > > > Subject: Re: [patch 2.6.12-rc3] modifications in
firmware_class.c to
> > > > support nohotplug
> > > >
> > > > On Wed, Jun 08, 2005 at 11:04:09AM -0500, Abhay_Salunke@xxxxxxxx
> > > wrote:
> > > > > > I think it would be better if you just have request_firmware
and
> > > > > > request_firmware_nowait accept timeout parameter that would
> > > override
> > > > > > default timeout in firmware_class. 0 would mean use default,
> > > > > > MAX_SCHED_TIMEOUT - wait indefinitely.
> > > > >
> > > > > But we still need to avoid hotplug being invoked as we need it
be
> a
> > > > > manual process.
> > > >
> > > > No, hotplug can happen just fine (it happens loads of times
today
> for
> > > > things that people don't care about.)
> > > >
> > > If hotplug happens the complete function is called which makes the
> > > request_firmware return with a failure.
> >
> > If this was true, then the current code would not work at all.
> >
>
> What Abhay is trying to say is that default firmware.agent when it
> does not find requested firmware file writes -1 (abort) to "loading"
> attribute causing firmware_request to fail.
>
> I think it should be fixed in firmware.agent though, not in kernel -
> the agent shoudl just recognoze that sometimes not having firmware
> file is ok.
>
I tired to do the following
1. echo 0 > /sys/class/firmware/timeout
2. modify the firmware.agent by commenting echo -1 when file is not
present as below.
if [ -f "$FIRMWARE_DIR/$FIRMWARE" ]; then
echo 1 > $SYSFS/$DEVPATH/loading
cp "$FIRMWARE_DIR/$FIRMWARE" $SYSFS/$DEVPATH/data
echo 0 > $SYSFS/$DEVPATH/loading
else
# echo -1 > $SYSFS/$DEVPATH/loading
Fi
3. load the dell_rbu driver : see dell_rbu code snipped below
device_initialize(&rbu_device);
strncpy(rbu_device.bus_id,"dell_rbu", BUS_ID_SIZE);
rc = request_firmware_nowait(THIS_MODULE,
"dell_rbu", &rbu_device,
&context,
callbackfn);
if(rc) {
printk(KERN_ERR
"dcdrbu_init:"
" request_firmware_nowait failed %d\n", rc);
}
But this created a kernel Oops message as follows. Also note that
uncomment the line in firmware.agents fixed the Oops message.
Jun 10 19:29:39 localhost kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
Jun 10 19:29:39 localhost kernel: printing eip:
Jun 10 19:29:39 localhost kernel: c0188b71
Jun 10 19:29:39 localhost kernel: *pde = 1fabe001
Jun 10 19:29:39 localhost kernel: Oops: 0000 [#2]
Jun 10 19:29:39 localhost kernel: SMP
Jun 10 19:29:39 localhost kernel: Modules linked in: dell_rbu(U) smbfs
parport_pc lp parport autofs4 sunrpc ipt_REJECT ipt_state ip_conntrack
iptable_filter ip_tables button battery ac md5 ipv6 ohci_hcd tg3 floppy
sg dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod mptscsih mptbase sd_mod
scsi_mod
Jun 10 19:29:39 localhost kernel: CPU: 1
Jun 10 19:29:39 localhost kernel: EIP: 0060:[<c0188b71>] Not
tainted VLI
Jun 10 19:29:39 localhost kernel: EFLAGS: 00010286 (2.6.9-5.ELsmp)
Jun 10 19:29:39 localhost kernel: EIP is at object_path_length+0x10/0x25
Jun 10 19:29:39 localhost kernel: eax: 00000000 ebx: 00000001 ecx:
ffffffff edx: e0a8fb24
Jun 10 19:29:39 localhost kernel: esi: de3c089c edi: 00000000 ebp:
dde2b000 esp: d7a3fe4c
Jun 10 19:29:40 localhost kernel: ds: 007b es: 007b ss: 0068
Jun 10 19:29:40 localhost kernel: Process bash (pid: 2825,
threadinfo=d7a3f000 task=d739e630)
Jun 10 19:29:40 localhost kernel: Stack: 00000003 e0a8fb24 c0188cf8
e0a8fb24 c031fdc0 de3c089c e0a8fb24 de1ff188
Jun 10 19:29:40 localhost kernel: c0188dfa dde2b000 dde2b000
fffffff4 de3c089c d7a3ff0c c0188e47 d7a3f000
Jun 10 19:29:40 localhost kernel: 00000000 de3c089c d7a3ff0c
c0161400 dfe84b00 de3c089c 00000000 dfe84b00
Jun 10 19:29:40 localhost kernel: Call Trace:
Jun 10 19:29:40 localhost kernel: [<c0188cf8>]
sysfs_get_target_path+0x19/0x59
Jun 10 19:29:40 localhost kernel: [<c0188dfa>] sysfs_getlink+0xc2/0xe9
Jun 10 19:29:40 localhost kernel: [<c0188e47>]
sysfs_follow_link+0x26/0x3e
Jun 10 19:29:40 localhost kernel: [<c0161400>]
link_path_walk+0x8fa/0xba9
Jun 10 19:29:40 localhost kernel: [<c01619c2>] path_lookup+0x144/0x174
Jun 10 19:29:40 localhost kernel: [<c0161b06>] __user_walk+0x21/0x51
Jun 10 19:29:40 localhost kernel: [<c015d0ad>] vfs_stat+0x14/0x3a
Jun 10 19:29:40 localhost kernel: [<c015d6b6>] sys_stat64+0xf/0x23
Jun 10 19:29:40 localhost kernel: [<c02c62a3>] syscall_call+0x7/0xb
Jun 10 19:29:40 localhost kernel: Code: fe ff ff e8 82 b1 13 00 e9 3a ff
ff ff 90 31 d2 8b 40 24 42 85 c0 75 f8 89 d0 c3 57 89 c2 53 bb 01 00 00
00 8b 3a 31 c0 83 c9 ff <f2> ae f7 d1 49 8b 52 24 8d 5c 0b 01 85 d2 75
e9 89 d8 5b 5f c3
I guess we need to modify the firmware_class.c code to fix it.
Please let me know your opinions.
Thanks
Abhay
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/