Messages in this thread | | | Date | Tue, 30 May 2006 11:53:29 -0300 | From | "Luiz Fernando N. Capitulino" <> | Subject | Re: usb-serial ipaq kernel problem |
| |
On Tue, 30 May 2006 11:38:01 -0300 "Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br> wrote:
| On Tue, 30 May 2006 10:21:41 +0200 | Frank Gevaerts <frank.gevaerts@fks.be> 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 <frank.gevaerts@fks.be> 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.
-- 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/
| |