On Tue, May 30, 2006 at 11:53:29AM -0300, Luiz Fernando N. Capitulino wrote: > On Tue, 30 May 2006 11:38:01 -0300 > "Luiz Fernando N. Capitulino" <[EMAIL PROTECTED]> wrote: > > | On Tue, 30 May 2006 10:21:41 +0200 > | Frank Gevaerts <[EMAIL PROTECTED]> 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 > | | > Frank Gevaerts <[EMAIL PROTECTED]> wrote: > | | > | > | | > | The panic was caused by the read urb being submitten in ipaq_open, > | | > | regardless of success, and never killed in case of failure. What my > | | > | patch basically does is to submit the urb only after succesfully > sending > | | > | the control message, and adding a sleep between tries. As long as this > | | > | patch is not applied, we hardly get any other error because the kernel > | | > | panics as soon as an ipaq reboots. > | | > > | | > 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. > > Thinking about this again, are you sure the read urb depends on the > control message? It's quite easy to test, just a add a long timeout after > the read URB was sent (say, five minutes) and waits for the read urb > callback to run. > > If it ran _before_ the timeout expires with no timeout error it does not > depend. Then we can do the simpler solution: just kill the read urb in the > ipaq_open's error path.
I'll try it sometime today. 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 ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
