On Mon, 29 May 2006 22:47:24 +0200 Frank Gevaerts <[EMAIL PROTECTED]> wrote:
| On Mon, May 29, 2006 at 05:24:10PM -0300, Luiz Fernando N. Capitulino wrote: | > On Mon, 29 May 2006 21:43:35 +0200 | > Frank Gevaerts <[EMAIL PROTECTED]> wrote: | > | > | On Mon, May 29, 2006 at 02:11:10PM -0300, Luiz Fernando N. Capitulino wrote: | > | > | > | > Frank, could you try this one please? | > | > | > | > I have no sure whether this makes sense, but every USB-Serial driver | > | > I know exits in the write URB callback if the URB got an error. | > | | > | It looks sane to me at least. | > | The machine is now running with this patch (and my ipaq_open patch, see | > | http://www.ussg.iu.edu/hypermail/linux/kernel/0605.2/1901.html). | > | > Hmmm. Then does the workqueue problem began to happen _after_ you applied | > your patch? | | No. I saw it a few times before that as well. Here is the oldest one I found (using 2.6.15) Okay. | > Are you sure your patch is the right thing to do? Does it look reasonable | > to submit that urb 1000 times that way? | | It only submits it once, just after the control message has succeeded. Oh, that's right. I didn't see the return statement. | The loop is needed because sometimes the ipaq takes a very long time | (more than a minute) before it starts accepting the control message. Ok. | > At first, it seems something else. | > | > Couldn't you run your test-case in a kernel previous to the TTY layer | > buffering revamp change? | | We first used 2.6.15. We got different types of error : a panic in | ipaq_read_bulk_callback(), the bug I mentionned in | http://www.ussg.iu.edu/hypermail/linux/kernel/0605.2/1770.html and the | current problem. We first tried upgrading to 2.6.16, which did not help. | | 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? -- Luiz Fernando N. Capitulino ------------------------------------------------------- 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
