On Wed, 19 Aug 2009, Bruno [UTF-8] Prémont wrote: > I did try to understand what happens exactly, using backtrace from > kernel compiled with debug info and running objdump on usbserial.ko. > Verifying by adding a few printk()'s inside serial_do_free() confirms my > understanding of the objdump and also tells me that after unplug > serial_do_free() is called twice (with different addresses for port->serial->type)! In fact, with different values for port->serial. Probably because port was deallocated before the second call occurred. > The first one (right after unplug) survives, the second one (when exiting > minicom) crashes. > > Extract from the logs with my printk()'s > [ 266.290632] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 > [ 266.290938] ftdi_sio 2-2:1.1: device disconnected > [ 266.292378] tty_port_close_start: count = -1 > [ 266.292535] serial_do_free(port @da0d9000) > [ 266.292692] serial @da3e9840 > [ 266.292791] type @deb45660 > /* exit minicom */ > [ 290.728196] serial_do_free(port @da0d9000) > [ 290.728341] serial @da0d9200 > [ 290.728461] type @3a6e6967 > [ 290.728591] BUG: unable to handle kernel paging request at 3a6e6983 > [ 290.728823] IP: [<deb02d5d>] serial_do_free+0x6d/0xd0 [usbserial] > Printk's were added: > > if (port->console) > return; > /* here */ > serial = serial->port; > owner = serial->type->driver.owner /* crash here */ > > Is it useful to check calls to serial_do_free() for my pl2303 > usb2serial converter? (e.g. to compare behavior from both of them) You could try; it wouldn't hurt. More useful would be to add some debugging messages to destroy_serial(). There should not be any calls to serial_do_free() after destroy_serial() runs. Also add some messages to the places that call usb_serial_put() and usb_serial_get_by_index(). 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
