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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]