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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
