LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: nardelli <jnardelli@infosciences.com>
Cc: linux-kernel@vger.kernel.org, linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] [PATCH] visor: Fix Oops on disconnect
Date: Mon, 24 May 2004 13:06:11 -0700	[thread overview]
Message-ID: <20040524200611.GC4558@kroah.com> (raw)
In-Reply-To: <40B24F52.8050805@infosciences.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 
> >/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.

thanks,

greg k-h

  reply	other threads:[~2004-05-24 20:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-20 23:08 nardelli
2004-05-21  4:30 ` [linux-usb-devel] " Greg KH
2004-05-21  5:03   ` Pete Zaitcev
2004-05-21 14:52     ` nardelli
2004-05-21 14:48   ` nardelli
2004-05-21 15:05     ` Alan Stern
2004-05-21 17:08       ` nardelli
2004-05-21 15:41     ` Greg KH
2004-05-21 19:51   ` nardelli
2004-05-21 20:01     ` jkroon
2004-05-21 20:22       ` nardelli
2004-05-21 20:44     ` Greg KH
2004-05-21 21:44       ` nardelli
2004-05-21 21:56         ` Greg KH
2004-05-21 22:04         ` nardelli
2004-05-21 22:30           ` Greg KH
2004-05-24 17:20             ` nardelli
2004-05-24 19:38               ` nardelli
2004-05-24 20:06                 ` Greg KH [this message]
2004-05-24 20:21                   ` nardelli
2004-05-25 13:15                   ` nardelli
2004-05-24 20:08               ` Greg KH
2004-05-24 21:42                 ` nardelli
2004-05-25 18:30                   ` Greg KH
2004-05-25 18:55                     ` nardelli
2004-05-21  4:31 ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040524200611.GC4558@kroah.com \
    --to=greg@kroah.com \
    --cc=jnardelli@infosciences.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --subject='Re: [linux-usb-devel] [PATCH] visor: Fix Oops on disconnect' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).