Developer Forum

e mercredi 22 juin 2005 15:50 +0200, Stelian Pop a crit :


Some more details which may be relevant.

The atp module is automatically loaded on boot. However, it looks like
its probe function was not called or didn't succeed on the first
invocation, in the previous tests I had to remove and reload the module
to make it work.

This time however, after the rmmod, when insmod'ing it again I get:
usbcore: deregistering driver atp
input: atp connected
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C00A039C LR: C00A037C SP: CD801D60 REGS: cd801cb0 TRAP: 0300
Not Tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 0000000C, DSISR: 40000000
TASK = cdea5790[4797] 'modprobe' THREAD: cd800000
Last syscall: 128
GPR00: DAF0F458 CD801D60 CDEA5790 DAF0F458 00000000 00000000 DAF0F47C
00000020
GPR08: DFFF9410 DAF0F45C 0000000C DAF0F464 0A6FFDC0 1001E294 00000000
100013C4
GPR16: 00000000 00000000 00000000 00000000 100013C4 1001EA00 1001EB70
00000000
GPR24: 00000000 10018868 C0340000 00000000 E2273294 DE49EC80 00000000
DAF0F458
NIP [c00a039c] sysfs_new_dirent+0x64/0x94
LR [c00a037c] sysfs_new_dirent+0x44/0x94
Call trace:
[c00a03f0] sysfs_make_dirent+0x24/0x90
[c00a1614] sysfs_add_link+0x94/0xd0
[c00a16c8] sysfs_create_link+0x78/0xc4
[c0132bfc] device_bind_driver+0x54/0x68
[c0132c98] driver_probe_device+0x88/0xe4
[c0132e34] __driver_attach+0x8c/0x98
[c0132228] bus_for_each_dev+0x74/0xa4
[c0132e64] driver_attach+0x24/0x34
[c0132750] bus_add_driver+0x98/0xc0
[c013327c] driver_register+0x38/0x4c
[c01a16c0] usb_register+0x68/0xcc
[e106a018] atp_init+0x18/0x48 [atp]
[c0038268] sys_init_module+0x228/0x328
[c0004660] ret_from_syscall+0x0/0x44

However, on my previous test I was able to rmmod the driver, reload it
again without any oops (and use it, it was functional), the oops
appeared only on the second rmmod. This looks like a synchronisation
issue somewhere...

Stelian.
--
Stelian Pop < XXXX@XXXXX.COM >

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Le mercredi 22 juin 2005 16:07 +0200, Stelian Pop a crit :

Ok, there are two separate problems here:

1. The sysfs intf entry is not created, and this causes the oops later
when trying to remove the entry, etc.

I've tracked this problem back to this patch:
[PATCH] driver core: fix error handling in bus_add_device
http://www.yqcomputer.com/ ;a=commit;h=ca2b94ba12f3c36fd3d6ed9d38b3798d4dad0d8b

Once the patch above is reverted, I have no more oops, my driver can
be loaded/unloaded just fine, and the /sys/devices/.../ is present.

However, I'm not really sure if the problem comes from the above
patch or from my driver which should manually call
usb_create_sysfs_intf_files() or something equivalent.

2. There is still a problem with the early loading of the driver. If
loaded at boot, it won't work. If I rmmod/insmod it later it does.

Stelian.
--
Stelian Pop < XXXX@XXXXX.COM >

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/

Le mercredi 22 juin 2005 12:03 -0400, Alan Stern a rit :
>> >>>> Notice the '1-2:1.1' is missing. Upon booting I get: >>>> >>>> Jun 22 13:34:04 localhost kernel: HID device not claimed by input or hiddev >>>> Jun 22 13:34:04 localhost kernel: usbhid: probe of 1-2:1.1 failed with error -5 >>>> Jun 22 13:34:04 localhost kernel: usb 1-2: device_add(1-2:1.1) ->> -5
>> You shouldn't call usb_create_sysfs_intf_files in any case.

Ok.
>> Your driver is returning -EIO from its probe routine according to the log, >> so it's not getting bound to the device.

Actually that's usbhid which returns -EIO.
>> Hence there shouldn't be any >> attempt to unbind the device when your driver is removed. This is a bug >> in usbcore; it tries to delete all the interfaces without checking whether >> they were successfully added.

Since this is fixed by reverting the device_add patch, I'm wondering if
this isn't a driver model core bug, where it tries to device_remove all
the "devices" even if they weren't correctly added before...

But I haven't looked closely at the code, this is just a thought.

Stelian.
--
Stelian Pop<< XXXX@XXXXX.COM >>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/