2.6.28-rc2 / hso driver oops
Subsystems (5)
Hi.
Tried out 2.6.28-rc2 today on my EEE 901 and my Option Icon 225 and got the following oops:
hso: drivers/net/usb/hso.c: 1.2 Option Wireless
usbcore: registered new interface driver hso
usb 2-2: new full speed USB device using uhci_hcd and address 3 usb 2-2: configuration #1 chosen from 1 choice
hso0: Disabled Privacy Extensions
BUG: unable to handle kernel NULL pointer dereference at 000000d0 IP: [<c03589b9>] dev_driver_string+0x1/0x2a *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1d.0/usb2/idVendor Modules linked in: hso usb_storage rfcomm l2cap rt2860sta evdev
Pid: 230, comm: khubd Not tainted (2.6.28-rc2 #2) 901
EIP: 0060:[<c03589b9>] EFLAGS: 00010246 CPU: 0
EIP is at dev_driver_string+0x1/0x2a
EAX: 00000000 EBX: f2c88480 ECX: f7159cb0 EDX: 00000001
ESI: f2fdee40 EDI: f68bd200 EBP: f7159cf8 ESP: f7159cd0
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process khubd (pid: 230, ti=f7158000 task=f70b02b0 task.ti=f7158000)
Stack: f7159cf8 f81b8265 f2c88480 f6ab8440 00000003 00000003 00000000 00000112 00000000 f81b90c8 f7159d48 f81b840d c029f782 f68bd200 fffffffe f6b143a8 f7159d20 f7159d2c 00000000 f6b143a8 f81b90c8 f7159d38 f7159d40 c038886b Call Trace: [<f81b8265>] ? hso_create_net_device+0x305/0x32d [hso] [<f81b840d>] ? hso_probe+0x180/0x56c [hso] [<c029f782>] ? __sysfs_add_one+0x14/0x85 [<c038886b>] ? usb_autopm_do_device+0xb1/0xb9 [<c0388d77>] ? usb_probe_interface+0xe9/0x11c [<c035b10a>] ? driver_probe_device+0xa0/0x136 [<c035b213>] ? __device_attach+0x8/0xa [<c035a8fe>] ? bus_for_each_drv+0x3d/0x67 [<c035b284>] ? device_attach+0x50/0x64 [<c035b20b>] ? __device_attach+0x0/0xa [<c035a77e>] ? bus_attach_device+0x21/0x48 [<c03598e6>] ? device_add+0x307/0x456 [<c03880b2>] ? usb_set_configuration+0x400/0x449 [<c038e44b>] ? generic_probe+0x44/0x7d [<c038828e>] ? usb_probe_device+0x32/0x38 [<c035b10a>] ? driver_probe_device+0xa0/0x136 [<c035b213>] ? __device_attach+0x8/0xa [<c035a8fe>] ? bus_for_each_drv+0x3d/0x67 [<c035b284>] ? device_attach+0x50/0x64 [<c035b20b>] ? __device_attach+0x0/0xa [<c035a77e>] ? bus_attach_device+0x21/0x48 [<c03598e6>] ? device_add+0x307/0x456 [<c03831d1>] ? usb_new_device+0x4d/0x8e [<c038433c>] ? hub_thread+0x94d/0xdcb [<c021f6b7>] ? default_wake_function+0xb/0xd [<c0234b83>] ? autoremove_wake_function+0x0/0x33 [<c03839ef>] ? hub_thread+0x0/0xdcb [<c02348f9>] ? kthread+0x3b/0x61 [<c02348be>] ? kthread+0x0/0x61 [<c0203c1b>] ? kernel_thread_helper+0x7/0x10 Code: 32 fe ff ff b9 81 00 00 00 b8 03 00 00 00 f3 a5 c7 83 b8 13 00 00 03 00 00 00 59 5e 89 83 8c 0b 00 00 8d 65 f4 5b 5e 5f 5d c3 55 <8b> 90 d0 00 00 00 89 e5 85 d2 75 19 8b 90 cc 00 00 00 85 d2 75 EIP: [<c03589b9>] dev_driver_string+0x1/0x2a SS:ESP 0068:f7159cd0 ---[ end trace fe2452bf3bd83a7f ]---
Stock 2.6.28-rc2 + ec_all.patch from lkml + rt2860sta driver (though I can't see how either of these are implicated I can try without if necessary).
It looks like there are only a couple of changes since 2.6.27 to this driver so I can try reverting both of them, but neither looks especially likely? (8ef5ba63b94b04b182ac4a6009dbbf1406beb3c5 & e57b641dfafc10ce23d26cf271fd2638589fdb3f)
J.
Signature · 1 line
Revd. Jonathan McDowell, ULC | Shall I call the United Nations?
Quoted 5 lines · Jonathan McDowell
Hi.
Tried out 2.6.28-rc2 today on my EEE 901 and my Option Icon 225 and got the following oops:
Quoted 7 lines
hso:
drivers/net/usb/hso.c: 1.2 Option Wireless
usbcore: registered new interface driver hso
usb 2-2: new full speed USB device usinguhci_hcdand address 3 usb 2-2: configuration #1 chosen from 1 choice
hso0: Disabled Privacy ExtensionsBUG: unable to handle kernel NULL pointer dereference at 000000d0 IP: [<c03589b9>] dev_driver_string+0x1/0x2a
Something passed a null device pointer to dev_printk().
[...]
Quoted 1 line
[<
f81b8265>] ?hso_create_net_device+0x305/0x32d[hso]
[...]
I think that hso_create_rfkill() is the culprit here (and has been inlined into hso_create_net_device()). It's using hso_dev->dev as the first argument to dev_err() and it doesn't look like that field is initialised except by kzalloc. At a guess, it should be using &hso_dev->usb->dev.
Ben.
Signature · 3 lines
Ben Hutchings, Senior Software Engineer, Solarflare Communications Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked.
PATCH 1/1 Cleanup hso rfkill error handling [was: 2.6.28-rc2 / hso driver oops]
Quoted 17 lines · Ben Hutchings
Quoted 5 lines · Jonathan McDowell
Hi.
Tried out 2.6.28-rc2 today on my EEE 901 and my Option Icon 225 and got the following oops:
Quoted 7 lines
hso:
drivers/net/usb/hso.c: 1.2 Option Wireless
usbcore: registered new interface driver hso
usb 2-2: new full speed USB device usinguhci_hcdand address 3 usb 2-2: configuration #1 chosen from 1 choice
hso0: Disabled Privacy ExtensionsBUG: unable to handle kernel NULL pointer dereference at 000000d0 IP: [<c03589b9>] dev_driver_string+0x1/0x2aSomething passed a null device pointer to
dev_printk().[...]
Quoted 8 lines
Quoted 1 line
[<
f81b8265>] ?hso_create_net_device+0x305/0x32d[hso][...]
I think that
hso_create_rfkill()is the culprit here (and has been inlined intohso_create_net_device()). It's usinghso_dev->devas the first argument todev_err()and it doesn't look like that field is initialised except by kzalloc. At a guess, it should be using&hso_dev->usb->dev.
Yup, this appears to be the problem, thanks. I think &hso_net->net->dev is more intuitive for the error message, so I've used that. I've also added missing line endings on the error messages and set our local rfkill structure element to NULL on failure so we don't try to call rfkill_unregister on driver removal if we failed to register at all.
The patch below Works For Me (TM); the device is detected fine, can be removed without problems and connects ok. I'll have a prod at why the rfkill stuff isn't working next, but I believe this cleanup of the error handling is appropriate no matter what the issue with registration is.
-----
drivers/net/usb/hso.c +6 -4
@@ -2184,19 +2184,20 @@ static void hso_create_rfkill(struct hso_device *hso_dev, struct usb_interface *interface) {struct hso_net *hso_net =dev2net (hso_dev); -struct device *dev = hso_dev->dev; +struct device *dev = &hso_net->net->dev;char *rfkn; hso_net->rfkill =rfkill_allocate (&interface_to_usbdev (interface)->dev,RFKILL_TYPE_WLAN );if (!hso_net->rfkill) { -dev_err (dev,"%s - Out of memory" , __func__); +dev_err (dev,"%s - Out of memory\n" , __func__);return ; } rfkn =kzalloc (20 ,GFP_KERNEL );if (!rfkn) {rfkill_free (hso_net->rfkill); -dev_err (dev,"%s - Out of memory" , __func__); + hso_net->rfkill =NULL ; +dev_err (dev,"%s - Out of memory\n" , __func__);return ; } snprintf(rfkn, 20, "hso-%d",
@@ -2209,7 +2210,8 @@ static void hso_create_rfkill(struct hso_device *hso_dev,kfree (rfkn); hso_net->rfkill->name =NULL ;rfkill_free (hso_net->rfkill); -dev_err (dev,"%s - Failed to register rfkill" , __func__); + hso_net->rfkill =NULL ; +dev_err (dev,"%s - Failed to register rfkill\n" , __func__);return ; } }
-----
J.
Signature · 3 lines
/-\ | 101 things you can't have too much |@/ Debian GNU/Linux Developer | of : 32 - Answers. \- |
PATCH 1/1 Fix logic error in rfkill_check_duplicity
Quoted 1 line · Jonathan McDowell
I'll have a prod at why the [hso] rfkill stuff isn't working next
Ok, I believe this is due to the addition of rfkill_check_duplicity in rfkill and the fact that test_bit actually returns a negative value rather than the postive one expected (which is of course equally true). So when the second WLAN device (the hso device, with the EEE PC WLAN being the first) comes along rfkill_check_duplicity returns a negative value and so rfkill_register returns an error. Patch below fixes this for me.
The hso driver should probably be claiming to be a WWAN device as well, given that it's GSM/HSDPA rather than 802.11.
-----
net/rfkill/rfkill.c +1 -1
@@ -603,7 +603,7 @@ static int rfkill_check_duplicity(const struct rfkill *rfkil }/* 0: first switch of its kind */ -return test_bit (rfkill->type, seen); +return (test_bit (rfkill->type, seen)) ?1 :0 ; }static int rfkill_add_switch (struct rfkill *rfkill)
-----
J.
Signature · 3 lines
/-\ | Shall I call the United Nations? |@/ Debian GNU/Linux Developer | \- |
Re: [PATCH] Fix logic error in rfkill_check_duplicity
Quoted 10 lines · Jonathan McDowell
Quoted 1 line · Jonathan McDowell
I'll have a prod at why the [hso] rfkill stuff isn't working next
Ok, I believe this is due to the addition of
rfkill_check_duplicityin rfkill and the fact thattest_bitactually returns a negative value rather than the postive one expected (which is of course equally true). So when the second WLAN device (the hso device, with the EEE PC WLAN being the first) comes alongrfkill_check_duplicityreturns a negative value and sorfkill_registerreturns an error. Patch below fixes this for me.
Good catch, I screwed up on that one. Please forward it with my ack to [email protected] and to Ivo van Doorn <[email protected]> and John W. Linville <[email protected]>.
Quoted 18 lines
-----
net/rfkill/rfkill.c +1
-2@@ -603,7 +603,7 @@ static int rfkill_check_duplicity(const struct rfkill *rfkil }/* 0: first switch of its kind */ -return test_bit (rfkill->type, seen); +return (test_bit (rfkill->type, seen)) ?1 :0 ; }static int rfkill_add_switch (struct rfkill *rfkill) -----J.
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
PATCH 1/1 Fix logic error in rfkill_check_duplicity
In reply to Jonathan McDowell(already sent to lkml & netdev, resending here with Henrique's Ack as per his followup there)
Quoted 1 line · Jonathan McDowell
I'll have a prod at why the [hso] rfkill stuff isn't working next
Ok, I believe this is due to the addition of rfkill_check_duplicity in rfkill and the fact that test_bit actually returns a negative value rather than the postive one expected (which is of course equally true). So when the second WLAN device (the hso device, with the EEE PC WLAN being the first) comes along rfkill_check_duplicity returns a negative value and so rfkill_register returns an error. Patch below fixes this for me.
-----
net/rfkill/rfkill.c +1 -1
@@ -603,7 +603,7 @@ static int rfkill_check_duplicity(const struct rfkill *rfkil }/* 0: first switch of its kind */ -return test_bit (rfkill->type, seen); +return (test_bit (rfkill->type, seen)) ?1 :0 ; }static int rfkill_add_switch (struct rfkill *rfkill)
-----
J.
Signature · 3 lines
/-\ | Shall I call the United Nations? |@/ Debian GNU/Linux Developer | \- |