Hi Peter,
Man, if only every bug report was this verbose. Thanks a lot!
In looking at the stuff you just sent, and the code, I agree with you
that this is a bug in the code. I don't have a Keyspan PDA device, and
didn't write that chunk of code, but can think of a fix for it. Try the
attached patch and let me know if it works for you.
(there's a small memory leak in this patch if you when you remove the
device, but it hopefully shouldn't oops anymore.)
Ultimately, I think that Brian Warner needs to take a look at this too
(he's the author of this portion of the driver.)
That whole usb_serial_probe / startup section of code needs to be
revisited soon. I know of a few different devices that wouldn't work
with that function in its present state.
Let me know if this works.
greg k-h
On Tue, Apr 11, 2000 at 04:20:43PM -0500, Peter E. Berger wrote:
> Hi Greg:
>
> Thanks for your response. Yes, the Keyspan device was plugged in
> when I first booted and across subsequent boots, but always with
> Linux and some variant of the usb-serial suite. As you suggested,
> I powered down, physically removed the device -- so no external USB
> devices are connected -- and rebooted. I have usb-serial debugging
> enabled in the kernel and usb support compiled as a module (full
> listing of my USB kernel options below). After booting I loaded the
> modules: usbcore, uhci, usb-serial, then used "logger" to note the
> time (16:38:39) in the system log file and then physically connected
> the Keyspan PDA. The full syslog is below, including the final Oops.
> I also attach "ksymoops" output showing the problem occured due to
> a NULL pointer dereference in keyspan_pda_startup(). From the dbg()
> messages I added to keyspan_pda_startup() I see that the Oops occured
> because serial->port[0].read_urb is NULL at the top of
> keyspan_pda_startup().
>
> I should warn you that I've made two changes to the sources while
> investigating this (and these are reflected in the logs below):
>
> 1. I've added some dbg() calls to help me get oriented in the code.
>
> 2. Earlier, when I first realized that the serial->port[0].read_urb
> was still NULL at the top of keyspan_pda_startup(), I looked at
> the usb_serial_probe() code and noticed that the "read_urb"
> element is not set until after returning from the startup routine.
> That is, in usb_serial_probe(), the "type->startup (serial)" call
> occurs before the loops labeled: "set up the endpoint information".
> Thinking that was the problem, I moved the startup code to below the
> "set up" loops. (But the problem still persists because "num_bulk_in"
> is 0 -- no bulk_in endpoints were found on the Keyspan PDA -- so
> the loop that sets up the port->read_urb elements never gets invoked,
> even though keyspan_startp_startup() needs a read_urb address to
> pass to FILL_INT_URB.)
>
> If you think my change is either wrong or confusing the issue, I'll
> reload the vanilla pre4-5 sources and rerun these tests.
>
>
> Thanks again for your great work on this usb-serial suite and for your
> help with my problem.
> --Peter
>
> P.S. Appended below are:
>
> 1. The USB related entries from my kernel .config file:
> 2. My system log from restart to Oops.
> 3. ksymoops output corresponding to the Oops.
>
diff -Naur -X dontdiff linux-2.3.99-pre4/drivers/usb/serial/keyspan_pda.c
linux-2.3.99-pre4-greg/drivers/usb/serial/keyspan_pda.c
--- linux-2.3.99-pre4/drivers/usb/serial/keyspan_pda.c Tue Apr 11 17:43:10 2000
+++ linux-2.3.99-pre4-greg/drivers/usb/serial/keyspan_pda.c Tue Apr 11 17:53:19
+2000
@@ -699,6 +699,10 @@
intin = serial->port[0].interrupt_in_endpoint;
/* set up the receive interrupt urb */
+ if ((serial->port[0].read_urb = usb_alloc_urb(0)) == NULL) {
+ err("can't allocate urb.");
+ return 1;
+ }
FILL_INT_URB(serial->port[0].read_urb, serial->dev,
usb_rcvintpipe(serial->dev, intin->bEndpointAddress),
serial->port[0].interrupt_in_buffer,
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
