From: Frank Gevaerts <frank.gevaerts@fks.be>
To: "Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br>
Cc: Frank Gevaerts <frank.gevaerts@fks.be>,
linux-usb-devel@lists.sourceforge.net, Greg KH <gregkh@suse.de>,
Pete Zaitcev <zaitcev@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] [PATCH] ipaq.c bugfixes
Date: Fri, 2 Jun 2006 15:10:34 +0200 [thread overview]
Message-ID: <20060602131034.GA28802@fks.be> (raw)
In-Reply-To: <20060602095935.65257a1b@doriath.conectiva>
On Fri, Jun 02, 2006 at 09:59:35AM -0300, Luiz Fernando N. Capitulino wrote:
> On Thu, 1 Jun 2006 21:16:54 +0200
> Frank Gevaerts <frank.gevaerts@fks.be> wrote:
>
> | When I changed te ipaq_open code to only submit the read urb after the
> | control message succeeds, these disappear.
> |
> | Whenever the usb_control_msg returns with ETIMEDOUT (-110), in both code
> | variants, when the device is disconnected we get:
>
> Did you mean that it happens even if you send the read urb after the
> control message?
Yes.
> | This seems to be 100% reproducible. I noticed that serial_open (in
> | usb-serial.c) sets port->tty = tty and tty->driver_data = port, but
> | doesn't set them back to NULL if the type->open() fails. Is that correct
> | ?
>
> I don't think it would cause the problem you're getting. 'port' is
> valid even if the driver's open() function fails.
We are currently trying a version where these are both set to NULL on
failure, and it does seem to help.
> | Also, we have discovered that the slow response of the ipaq on connect
> | is actually largely caused by the control message retries, so we have
> | added a sleep at the start of ipaq_open.
> |
> | The current patch we are testing (not yet ready for inclusion, since
> | it doesn't work correctly yet and it produces some output that is not
> | useful in general) is :
>
> Well, I'm afraid that every new patch leads to a new problem..
> Maybe it's something else..
I'm not sure it's a new problem every time. Some of the earlier bugs
could have been the same as this one (the stack trace was the same)
Frank
> --
> Luiz Fernando N. Capitulino
--
Frank Gevaerts frank.gevaerts@fks.be
fks bvba - Formal and Knowledge Systems http://www.fks.be/
Stationsstraat 108 Tel: ++32-(0)11-21 49 11
B-3570 ALKEN Fax: ++32-(0)11-22 04 19
next prev parent reply other threads:[~2006-06-02 13:11 UTC|newest]
Thread overview: 38+ 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 [this message]
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
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=20060602131034.GA28802@fks.be \
--to=frank.gevaerts@fks.be \
--cc=gregkh@suse.de \
--cc=lcapitulino@mandriva.com.br \
--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.