See below.. -Mike
On Fri, 17 Jun 2011, Magnus Ekhall wrote: > > > I can't say that I see any efforts to recover. Here is a longer, > consecutive part of the kernel log: > > Jun 12 09:15:05 digimatrix kernel: [67522.143822] pvrusb2: ***WARNING*** > device's encoder appears to be stuck (status=0x00000003) > Jun 12 09:15:05 digimatrix kernel: [67522.143829] pvrusb2: Encoder > command: 0x81 > Jun 12 09:15:05 digimatrix kernel: [67522.143833] pvrusb2: Giving up on > command. This is normally recovered via a firmware reload and > re-initialization; c > oncern is only warranted if this happens repeatedly and rapidly. > Jun 12 09:40:04 digimatrix kernel: [69021.735287] pvrusb2: ***WARNING*** > device's encoder appears to be stuck (status=0x00000003) > Jun 12 09:40:04 digimatrix kernel: [69021.735293] pvrusb2: Encoder > command: 0x81 > Jun 12 09:40:04 digimatrix kernel: [69021.735297] pvrusb2: Giving up on > command. This is normally recovered via a firmware reload and > re-initialization; c > oncern is only warranted if this happens repeatedly and rapidly. > Jun 12 17:17:28 digimatrix kernel: [96465.946075] ath: Failed to stop TX > DMA in 100 msec after killing last frame > Jun 12 17:17:28 digimatrix kernel: [96465.946128] ath: Failed to stop TX > DMA! > Jun 15 01:30:04 digimatrix kernel: [298828.093416] pvrusb2: > ***WARNING*** device's encoder appears to be stuck (status=0x00000003) > Jun 15 01:30:04 digimatrix kernel: [298828.093423] pvrusb2: Encoder > command: 0x81 > Jun 15 01:30:04 digimatrix kernel: [298828.093427] pvrusb2: Giving up on > command. This is normally recovered via a firmware reload and > re-initialization; > concern is only warranted if this happens repeatedly and rapidly. > Jun 15 20:59:34 digimatrix kernel: [369000.134310] pvrusb2: > ***WARNING*** device's encoder appears to be stuck (status=0x00000003) > Jun 15 20:59:34 digimatrix kernel: [369000.134317] pvrusb2: Encoder > command: 0x81 > Jun 15 20:59:34 digimatrix kernel: [369000.134321] pvrusb2: Giving up on > command. This is normally recovered via a firmware reload and > re-initialization; > concern is only warranted if this happens repeatedly and rapidly. > > > > As you can see the message regarding the stuck encoder is repeated, but > sometimes with hours between the messages, and sometimes with days. > > What would the recovery attempt log message look like? When the recovery happens, it typically takes less than a second. (It is usually so fast that people don't even notice it had to recover unless one looks at the kernel log.) The fact that you're going hours / days between errors means it's probably recovering OK. So you're generally not getting into a situation when it's in rapid loop repeatedly trying to recover. You might not be seeing the recovery related messages because those particular debug flags are likely turned off in the driver. You can, if you want, turn on additional debug flags without needing to rebuild anything. There's information on how to change that debug mask here: http://www.isely.net/pvrusb2/usage.html#Logging However that doesn't explain the behavior that's causing you a problem - that it's just getting jammed and NOT recovering. If you can pretty regularly get it to jam, while additional debug flags are on, we might be able to pin it down. Read on... > > I'm running an up to date mythbuntu where the pvrusb2 module is of > version: > srcversion: 8576222596CEAD8A32E8AB8 > vermagic: 2.6.38-8-generic SMP mod_unload modversions Assuming that the driver wasn't patched in this distribution then you're probably running the vanilla driver that comes with the 2.6.38 kernel. That's a mature, recent, driver. > > I'm starting to suspect problematic hardware, but I would like to look > at all other possibilities before I open my wallet. :) One thing we have to consider here is that the logic you're looking at, that is the behavior of the mpeg encoder dying and the driver recovering it automatically, has been a feature of the driver for *many* years. It's been a stable behavior over that time, so the fact that you're the first person in, well basically forever, to be reporting this issue leads me to suspect that you might indeed be dealing with marginal hardware. These pvrusb2-driver devices are never USB-powered - they always require an external power brick to run. The reason for this is that the mpeg encoder chip needs a lot of juice to do its job. It is likely the hottest part inside the box. So if, for example, the box might be getting too warm, then it's reasonable to suspect that the first chip to be affected by it will in fact be the encoder chip. The encoder chip is what is crashing on you... If your tuner is already out of warranty, a good experiment I'd probably try is to run it with the top removed and a fan blowing air across it. This wouldn't really be a "fix", but if having the air flowing across the board seems to lower the probability of these crashes then I'd say you've got a pretty strong datapoint that it's getting too hot. If you can run your tuner under Windows (yeah, I know, a pain), you can also diagnose bad hardware if running it under Windows also results in periodic failures. (However the inverse may not be true - it could be marginal hardware that only dies when driven hard enough and the two software environments - Linux vs Windows - are certainly going to be driving it differently.) > > And if a hardware problem is detectable and there is a way to work > around it (by re-initializing it) that's fine as well. Well the driver is already doing some of that re-initialization... -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
