Messages in this thread | | | Date | Mon, 29 May 2006 19:33:30 -0300 | From | "Luiz Fernando N. Capitulino" <> | Subject | Re: usb-serial ipaq kernel problem |
| |
On Mon, 29 May 2006 22:47:24 +0200 Frank Gevaerts <frank.gevaerts@fks.be> 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 <frank.gevaerts@fks.be> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |