>>>[ 243.148375] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
>>>[ 243.148471] BUG: unable to handle kernel NULL pointer dereference at (null)
>>>[ 243.148508] IP: [<ffffffffa0468527>] stop_read_write_urbs+0x37/0x80 [usb_wwan]
Yes, this is easily reproducible with any driver based on usb_wwan.
I've tested both qcserial and option. The immediate cause of this is
that the &port->dev drvdata is NULL when stop_read_write_urbs is called,
so that
portdata = usb_get_serial_port_data(port);
ends up being NULL. This problem can also hit in resume I believe. I
think some of the solution may be moving device_del from disconnect to
destroy (cut'n paste patch - probably white space damaged):
diff --git a/drivers/usb/serial/usb-serial.c b/drivers/usb/serial/usb-serial.c
index aa4b0d7..0a57500 100644
--- a/drivers/usb/serial/usb-serial.c
+++ b/drivers/usb/serial/usb-serial.c
@@ -152,6 +152,8 @@ static void destroy_serial(struct kref *kref)
for (i = 0; i < serial->num_port_pointers; ++i) {
port = serial->port[i];
if (port) {
+ if (device_is_registered(&port->dev))
+ device_del(&port->dev);
port->serial = NULL;
put_device(&port->dev);
}
@@ -1116,8 +1118,6 @@ static void usb_serial_disconnect(struct usb_interface *interface)
}
kill_traffic(port);
cancel_work_sync(&port->work);
- if (device_is_registered(&port->dev))
- device_del(&port->dev);
}
}
serial->type->disconnect(serial);
But there are so many skeletons in the current usb-next code that I have
a really hard time debugging this. One example: using rfkill
block/unblock to temporarily disconnect the internal modem only works
when connected to AC. If on battery, then nothing happens on reconnect
(no USB device detected). The same happens for Bluetooth as well, so
it's not a serial thingy.
Connecting AC power (this will trigger an autosuspend policy change on
my laptop, and I suspect that is the real differenc) will suddenly make
the devices appear again. Quite a suprise.
I suspect the weird cut-power patches accounts for this, and will send
another mail to flag the problem.
But the end result is that I spent too much of the debugging time I had
today chasing unrelated problems.
BTW, Thomas, I am unable to reproduce your qmi_wwan problems. So I'd
like more details about those. But given the problems I've had today, I
expect you are facing some unrelated problem with the USB core. It is
really unfit for release in usb-next. I'd recommend you run 3.5 on any
production system for now, possibly with a number of cherry-picked
patches if you need some newer feature.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
