Re: [linux-usb-devel] [PATCH] visor: Fix Oops on disconnect
From: Greg KH (greg_at_kroah.com)
Date: Mon, 24 May 2004 13:06:11 -0700 To: nardelli <email@example.com>
On Mon, May 24, 2004 at 03:38:58PM -0400, nardelli wrote:
> nardelli wrote:
> >One more question - my system does not really like it when I redirect
> >to either the first or second port. I know that it obviosuly makes no
> >sense to
> >do such a thing, but is it expected that there should be no problems
> >with this. I'm not finished testing, so I'm not sure how severe a problem
> >I'll report in when I know more about this.
> Here's some preliminary info:
> 1) Whether writing to the 1st or 2nd port, the machine hangs pretty badly
> after catting /dev/urandom for more than 1 second or two. This continues
> even after catting has stopped, and the device has been disconnected. This
> smells like some type of resource leak, probably memory, to me.
Which machine dies? The pilot or the Linux box?
> 2) I've included an Oops when writing to the 1st serial port, showing some
> difficulty allocating memory.
So we ran out of memory? Not good.
> 3) After looking at visor_write(), I was a bit surprised to see it
> allocating its own urb and buffer, while I thought it would be using
> the ones that were allocated in usb-serial.usb_serial_probe(). After
> looking at other serial devices that use usb_submit_urb() in their
> write() functions, I found that the following used the buffers/urb
> allocated for them:
> cyberjack, digi_acceleport, generic, io_ti, ipaq, ir-usb, keyspan_pda,
> kobil_sct, mct_u232, omninet, pl2303, safe_serial
> while I found that the following created their own (some for each write):
> empeg, ftdi_sio, keyspan, kl5kusb105, visor, whiteheat
> I'm not so sure about:
It uses it's own buffers from what I remember.
> Is this expected behavior, or am I just missing something here?
Expected, not all of the usb-serial drivers have to do the same thing,
as they operate on very different types of hardware.
> It would seem like reusing the buffer and urb would be advantageous,
> but there may be more issues here than I am aware of.
Reusing the buffer and urb is _slow_. The visor driver creates a new
buffer for every call to write. It is entirely possible that you can
starve the kernel of memory by sending it the output of a raw device
node, as that data comes faster than the USB data can be sent.
But this is a different problem from the one you originally set out to
fix, how about sending a new patch for the treo disconnect problem, and
then we can work on the next issues.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/