> I suggest staying away from eclipse, that's not needed for kernel
> development. Other than that, it's just normal debugging, good luck
> with that :)
I resorted to good old vi as the editor that starts up fastest :-)
And I traced down the problem -- but not the root cause:
In usbrsa_attach, I allocate a private struct for port specific/driver
specific data:
static int usbrsa_attach(struct usb_serial *serial)
{
int i = 0;
int ret = 0;
struct usb_serial_port* serport;
struct usbrsa_port_private* priv = NULL;
...
for (i = 0; i < serial->num_ports; i++)
{
serport = serial->port[i];
// allocate struct for driver's private data
priv = kmalloc(sizeof(struct usbrsa_port_private), GFP_KERNEL);
....
usb_set_serial_port_data(serport,priv);
...
}
In usbrsa_release, the pointer to the private struct has become a NULL
pointer -- even though the pointer was not manipulated in between by
usbrsa_open or usbrsa_write. In fact, I have dumped the pointer in all other
functions like usbrsa_open, usbrsa_writeroom etc., and it is correct. The
null pointer in usbrsa_release then leads to a pointer dereferencing error
in release_baudrate_lcr_urb(priv);
static void usbrsa_release(struct usb_serial *serial)
{
int i;
struct usbrsa_port_private* priv;
struct usb_serial_port* serport;
...
for (i = 0; i < serial->num_ports; i++)
{
printk("%s: Mark1\n",__func__);
serport = serial->port[i];
priv = usb_get_serial_port_data(serport);
printk("%s: Mark2\n",__func__);
printk("%s: private struct at %p\n",__func__,priv);
printk("%s: Mark2a ",__func__);
release_baudrate_lcr_urb(priv);
Here the kernel log
[ 1856.366874] usbrsa_release: Mark2
[ 1856.366876] usbrsa_release: private struct at (null)
[ 1856.366878] usbrsa_release: Mark2a release_baudrate_lcr_urb: Start
[ 1856.366904] BUG: unable to handle kernel NULL pointer dereference at
0000000000000102
This could mean that usb_get_serial_port_data does not always work correctly
-- which I find rather unlikely. Are there any limitations known, for
instance when using the usb_get_serial_port_data in an SMP environment? Any
suggestions in which direction to dig?
Thanks Tilman
--
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
