All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br>
To: Frank Gevaerts <frank.gevaerts@fks.be>
Cc: Frank Gevaerts <frank.gevaerts@fks.be>,
	Pete Zaitcev <zaitcev@redhat.com>,
	linux-kernel@vger.kernel.org, gregkh@suse.de,
	linux-usb-devel@lists.sourceforge.net
Subject: Re: usb-serial ipaq kernel problem
Date: Tue, 30 May 2006 12:56:33 -0300	[thread overview]
Message-ID: <20060530125633.58ec8d58@doriath.conectiva> (raw)
In-Reply-To: <20060530150627.GB27700@fks.be>

On Tue, 30 May 2006 17:06:27 +0200
Frank Gevaerts <frank.gevaerts@fks.be> wrote:

| On Tue, May 30, 2006 at 11:38:01AM -0300, Luiz Fernando N. Capitulino wrote:
| > On Tue, 30 May 2006 10:21:41 +0200
| > Frank Gevaerts <frank.gevaerts@fks.be> wrote:
| > 
| > | On Mon, May 29, 2006 at 07:33:30PM -0300, Luiz Fernando N. Capitulino wrote:
| > | > On Mon, 29 May 2006 22:47:24 +0200
| > | >  I see.
| > | > 
| > | >  Did you try to just kill the read urb in the ipaq_open's error path?
| > | 
| > | Yes, that's what I did at first. It works, but with the long waits (we see
| > | waits up to 80-90 seconds right now) I was afraid that the urb might timeout
| > | before the control message succeeds.
| > 
| >  Hmmm, I see.
| > 
| >  My only (obvious) question is that if it's really safe to send the read
| > urb after the control message..
| 
| Since it is bulk, it is not guaranteed to start before the control
| message anyway, so it should be safe.
| 
| The patch looks correct to me, but I would still like to increase
| KP_RETRIES a bit. If I read the code correctly, the current setup allows
| for 10 seconds between usb connect and acknowledging the control
| message. This is enough if the device is only connected when booted
| (which is the normal use case). However, in our case, we do
| software-initiated reboots of the ipaq while it is attached to the usb
| bus, which can take much longer, so for us KP_RETRIES should be at least
| 1000, maybe 2000. Of course, we can always run a patched kernel for this.

 Hmmm, what do you think about keeping the current default value and
adding a module parameter to change it?

| I'll test the patch later today.
| 
| Anyway, we have not seen the usb_serial_disconnect bug since applying
| your patch, so that bug is also probably gone (we have had nearly 1000
| successfull connects/disconnects since then)

 Nice to know.

-- 
Luiz Fernando N. Capitulino

  reply	other threads:[~2006-05-30 15:56 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-26 18:22 usb-serial ipaq kernel problem Frank Gevaerts
2006-05-26 20:34 ` Pete Zaitcev
2006-05-26 21:12   ` Frank Gevaerts
2006-05-27 11:41   ` Frank Gevaerts
2006-05-29 15:01   ` Luiz Fernando N. Capitulino
2006-05-29 16:25     ` Luiz Fernando N. Capitulino
2006-05-29 17:11       ` Luiz Fernando N. Capitulino
2006-05-29 19:43         ` Frank Gevaerts
2006-05-29 20:24           ` Luiz Fernando N. Capitulino
2006-05-29 20:47             ` Frank Gevaerts
2006-05-29 22:33               ` Luiz Fernando N. Capitulino
2006-05-30  8:21                 ` Frank Gevaerts
2006-05-30 14:38                   ` Luiz Fernando N. Capitulino
2006-05-30 14:53                     ` Luiz Fernando N. Capitulino
2006-05-30 15:09                       ` Frank Gevaerts
2006-05-30 17:48                       ` Frank Gevaerts
2006-05-30 18:33                         ` Pete Zaitcev
2006-05-30 19:04                           ` Frank Gevaerts
2006-05-30 20:53                           ` Luiz Fernando N. Capitulino
2006-05-31 21:38                           ` Frank Gevaerts
2006-05-31 21:55                             ` Greg KH
2006-05-31 22:42                               ` [PATCH] ipaq.c bugfixes Frank Gevaerts
2006-05-31 22:46                                 ` Greg KH
2006-06-01 19:18                                   ` Frank Gevaerts
2006-06-14 11:58                                     ` Frank Gevaerts
2006-06-14 12:05                                       ` [PATCH] ipaq.c connection open timing parameters Frank Gevaerts
2006-06-14 14:21                                         ` Frank Gevaerts
2006-06-14 13:58                                       ` [PATCH] ipaq.c bugfixes Luiz Fernando N. Capitulino
2006-06-14 14:18                                         ` Frank Gevaerts
2006-06-01 19:16                                 ` Frank Gevaerts
2006-06-02 12:59                                   ` [linux-usb-devel] " Luiz Fernando N. Capitulino
2006-06-02 13:10                                     ` Frank Gevaerts
2006-05-30 20:52                         ` usb-serial ipaq kernel problem Luiz Fernando N. Capitulino
2006-05-30 21:36                           ` Frank Gevaerts
2006-05-31 21:10                             ` Luiz Fernando N. Capitulino
2006-05-31 21:23                               ` Frank Gevaerts
2006-05-30 15:06                     ` Frank Gevaerts
2006-05-30 15:56                       ` Luiz Fernando N. Capitulino [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-05-22 14:30 Frank Gevaerts
2006-05-22 21:44 ` 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=20060530125633.58ec8d58@doriath.conectiva \
    --to=lcapitulino@mandriva.com.br \
    --cc=frank.gevaerts@fks.be \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=zaitcev@redhat.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.