Thanks for your help. I've now enabled a bunch of debug printouts to see what actually happens under the hood.
I took a closer look at the kernel log and I'm pretty sure I got one of those messages regarding the stuck encoder, and the encoder was still working just fine. Maybe the printouts are unrelated to the problem after all... I also downloaded the latest windows driver from Hauppauges website and extracted the various firmwares. I found one firmware that was different from what I was currently running. The new firmware v4l-cx25840.fw has a md5sum of 95bc688d3e7599fd5800161e9971cc55. I don't know if that is what "everybody else" is running? I don't know if that will help me, but I'm running the new one now. Now I'm just waiting for the problem to happen again so that I can take a dive in the now slightly more verbose kernel logs. :) Regards, Magnus fre 2011-06-17 klockan 20:51 -0500 skrev Mike Isely: > 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 > > _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
