Re: Nova-T 500 Channel scanning + EIT + Kernel oops...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"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

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux