Re: [linux-usb-devel] [PATCH] visor: Fix Oops on disconnect

From: Greg KH (
Date: 05/24/04

  • Next message: Greg KH: "Re: [linux-usb-devel] [PATCH] visor: Fix Oops on disconnect"
    Date:	Mon, 24 May 2004 13:06:11 -0700
    To: nardelli <>

    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
    > >/dev/urandom
    > >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
    > >associated
    > >with this. I'm not finished testing, so I'm not sure how severe a problem
    > >develops.
    > >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:
    > io_edgeport

    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.


    greg k-h
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

  • Next message: Greg KH: "Re: [linux-usb-devel] [PATCH] visor: Fix Oops on disconnect"

    Relevant Pages

    • Re: Discovering variable types...
      ... >- but I suppose MS expect us to use wrappers ... memory allocations for your variables from disk as well. ... >They most certainly are of fixed size, changing the size of a String ... >>me to keep buffer size and current postion right in the memory block. ...
    • Re: UMA caches draining
      ... system is quite low on memory. ... Will, for example, buffer cache allocate buffers ... then interrupt threads and i/o path should try hard to avoid allocations ...
    • Re: Discovering variable types...
      ... >memory it points to is on the heap. ... sequentially reading data, if one is randomly reading records, then a ... >project is what's prompting me to improve disk access. ... from a memory buffer I can do it in about a second. ...
    • Re: Multicast Directshow Graph Bridging, COW Rustling, & the Use of Portable Holes in Cartoon Ph
      ... memory to share buffer pools across processes and works pretty well. ... You get two basic Direct Show filters, ... issue each GMF-source a virtual memory alias with COW ...
    • Re: PCI bus-master and large contiguous memory buffers
      ... I built my scatter gather list in SRAM that was on my device, ... could have done it in system memory had I needed to. ... interrupt when a buffer was filled, the application would save the buffer to ... beginning of the recording I made a device IO control call to my driver. ...