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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox