On Mon, 7 Sep 2009, Miklos Szeredi wrote: > > This is unexpected, because port->serial is initialized in > > usb_serial_probe() and is not set to NULL until destroy_serial(), after > > which port should not be used at all. Can you add a > > > > #define DEBUG > > > > line at the start of usb-serial.c (before the #include lines) so that > > we can tell if destroy_serial() is getting called too early? When you > > do, post the dmesg log showing everything from the time you start > > running your test. > > drivers/usb/serial/usb-serial.c: serial_install > drivers/usb/serial/usb-serial.c: serial_open - port 0 ... > PPP generic driver version 2.4.2 > drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401 > drivers/usb/serial/usb-serial.c: serial_open - port 0 > drivers/usb/serial/usb-serial.c: serial_tiocmset - port 0 > drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401 > drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5404 > drivers/usb/serial/usb-serial.c: serial_chars_in_buffer = port 0 > drivers/usb/serial/usb-serial.c: serial_set_termios - port 0 > drivers/usb/serial/usb-serial.c: serial_open - port 0 This is the third open with no intervening closes. At this point port->port.count should be equal to 3 (it gets incremented in serial_open() and decremented when serial_close() calls tty_port_close_start()). > drivers/usb/serial/usb-serial.c: destroy_serial - GSM modem (1-port) > drivers/usb/serial/usb-serial.c: return_serial > drivers/usb/serial/usb-serial.c: serial_close - port 0 I don't understand this. How did we get to destroy_serial()? It is called from only one place: usb_serial_put(). That in turn is called from only a few places, of which the most important are serial_release() and usb_serial_disconnect(). But neither of them shows up in the debugging log. We need more debugging info. You can try printing the value of port->port.count just before the end of serial_open() and at the start of serial_close(). You can also add a WARN() at the start of destroy_serial() so that the stack dump will show how we got there. > drivers/usb/serial/usb-serial.c: serial_chars_in_buffer = port 0 > BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 > IP: [<ffffffffa01ca09c>] serial_chars_in_buffer+0x47/0x5f [usbserial] Now this is understandable. Since destroy_serial() was called too soon, anything afterward will try to follow a NULL pointer. Alan Stern -- 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
