"Eduard Huguet" <eduardhc@xxxxxxxxx> writes: > I don't know if kernel oops is related to USB disconnection. Just look for "USB disconnect" in /var/log/kern.log* or dmesg output. > However, it > seems reasonable to suspect that the EIT reception has something to do with > this problems, as I never experienced problems with this card before. Could be. I've tried to look at the usbmon logs I've taken from the disconnects and it seems that there is always a control message just before the first failing (EPIPE) transaction (always bulk). The EPROTO failure can happen either for bulk or control transaction after the EPIPE failure. I made an async version of the halt clearing but it still does not prevent disconnects. I put a diff at http://brigitte.dna.fi/~apm/t500-stall-clear-async.diff but as with the sync diff, not intented to be applied, just for looking at :) It does sometimes prevent a disconnect, e.g. here: c359a7c0 1970475991 S Co:002:00 s 40 03 0000 0000 0006 6 = 0314000b ab20 f7629440 1970476114 C Bi:002:03 -32 40448 = 471fff10 00000000 00000000 00000000 00000000 00000000 00000000 00000000 f7546ec0 1970476132 S Co:002:00 s 02 01 0000 0083 0000 0 c359a7c0 1970476607 C Co:002:00 0 6 > f7546ec0 1970476618 C Co:002:00 0 0 But not always. Here's a sample where we have REQUEST_ENABLE_VIDEO just before the EPIPE and the EPROTO happens for a bulk transaction: f79380c0 582051665 S Co:002:00 s 40 0f 0000 0000 0004 4 = 0f101300 f79380c0 582051830 C Co:002:00 0 4 > f74acdc0 582053974 C Bi:002:03 -32 40448 = 4701311e 4527d078 77ad90fa 0c6c2255 353a8670 ebe754f4 34a7631f 0b869dc8 f74acbc0 582053986 S Co:002:00 s 02 01 0000 0083 0000 0 f77413c0 582054733 C Bi:002:02 -71 6144 = 47d9c4fe dad86b80 f3dbcf65 6d258bd4 23eb3d04 58fd9791 29741794 e87cbb16 and here we have REQUEST_I2C_WRITE before the EPIPE and the EPROTO failure happens for a control transaction (the I2C write): f79c1cc0 2568107515 S Co:002:00 s 40 03 0000 0000 0006 6 = 03140006 0019 f755f140 2568107736 C Bi:002:03 -32 40448 = 47023110 26e11251 26435261 0ce78c29 44235a42 35b08108 94a956b2 f58cb55d f7546ec0 2568107748 S Co:002:00 s 02 01 0000 0083 0000 0 f79c1cc0 2568108697 C Co:002:00 -71 6 > So what triggers the failures could be related to how control transactions get interleaved with streaming transactions, but then again there is obviously a lot of interleaved streaming/control activity that proceeds just fine. I haven't figured out any difference in the patterns that trigger the failure and patterns that do not. I have couple of gigs of logs if someone wants to analyze them :-) Hmm.. would some little test program be useful? I.e. cause those control transfers via some ioctls? Or would it be possible to use some existing tool? -- http://www.iki.fi/~ananaza/ _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
