Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
On Sun, Jul 19, 2009 at 9:15 AM, Mark Lord wrote: > Devin, > > Thanks for your good efforts and updates on the xc5000 driver. > But the version in 2.6.31 no longer works with mythfrontend > from the 0.21-fixes branch of MythTV. > > The mythbackend (recording) program tunes/records fine with it, > but any attempt to watch "Live TV" via mythfrontend just locks > up the UI for 30 seconds or so, and then it reverts to the menus. > > I find that rather odd, as mythfrontend normally has very little > interaction with the tuner devices. But it does try to read the > signal strength and quality from the tuner, so perhaps this is a > clue as to what has gone wrong? > > I also took just the xc5000.[ch] files from 2.6.31 and tried them > with 2.6.30, to help isolate things. Exactly the same behaviour > was observed there, too. The mythbackend could tune/record, > but the mythfrontend would lock up. > > ??? > Hello Mark, Thank you for the bug report. Michael Krufky and I tested the tuner changes with what I thought were all the tuners that used the xc5000 (yes, between the two of us we have quite a collection). Perhaps we missed one though. Replacing xc5000.[ch] would normally be a good idea from a testing standpoint. However, in this case it isn't very conclusive since the xc5000 performance and power management improvements exposed numerous bugs in various demods, bridges, and even one in dvb core (all of which I had to fix before the xc5000 work could be submitted upstream). Could you please provide the following: 1. Exactly which product you are using (including the USB/PCI id) 2. dmesg output from the time the card is inserted (or booted up if PCI) to the time *after* you attempted to use the frontend with mythtv. 3. Whether you are using the device for digital, analog, or both, and which the mythtv attempted to use when running the mythfrontend. Also, Could you please install the latest v4l-dvb code using the directions at http://linuxtv.org/repo and see if the problem still occurs. This will tell us if the problem is some patch that didn't make it upstream, and will make it easier for me to give you patches that provide more debug info. I will be afk until tonight, but will check my email as soon as I get home. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Devin Heitmueller wrote: On Sun, Jul 19, 2009 at 9:15 AM, Mark Lord wrote: .. The mythbackend (recording) program tunes/records fine with it, but any attempt to watch "Live TV" via mythfrontend just locks up the UI for 30 seconds or so, and then it reverts to the menus. .. Could you please provide the following: 1. Exactly which product you are using (including the USB/PCI id) .. Doh! Yes, of course! It's the popular Hauppauge HVR-950Q USB Stick: Bus 007 Device 006: ID 2040:7200 Hauppauge 3. Whether you are using the device for digital, analog, or both, and which the mythtv attempted to use when running the mythfrontend. .. Digital-only, since the tuner stick has never worked (and still doesn't) for analog NTSC with MythTV-0.21-fixes. That's okay, I really only use it for digital ATSC over-the-air (OTA) reception. 2. dmesg output from the time the card is inserted (or booted up if PCI) to the time *after* you attempted to use the frontend with mythtv. The remainder of this email contains (only) the dmesg output. Thanks. rocessor 1 APIC 0x1 ip 0x6000 Initializing CPU#1 Calibrating delay using timer specific routine.. 5319.72 BogoMIPS (lpj=2659862) CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 4096K CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 mce: CPU supports 6 MCE banks CPU1: Thermal monitoring enabled (TM2) x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106 CPU1: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz stepping 06 checking TSC synchronization [CPU#0 -> CPU#1]: passed. Brought up 2 CPUs Total of 2 processors activated (10639.55 BogoMIPS). NET: Registered protocol family 16 ACPI: bus type pci registered dca service started, version 1.8 PCI: MCFG configuration 0: base e000 segment 0 buses 0 - 255 PCI: MCFG area at e000 reserved in E820 PCI: Using MMCONFIG at e000 - efff PCI: Using configuration type 1 for base access bio: create slab at 0 ACPI: EC: Look up EC in DSDT ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: No dock devices found. ACPI: PCI Root Bridge [PCI0] (:00) pci :00:01.0: PME# supported from D0 D3hot D3cold pci :00:01.0: PME# disabled pci :00:1a.0: reg 20 io port: [0xfc00-0xfc1f] pci :00:1a.1: reg 20 io port: [0xf800-0xf81f] pci :00:1a.7: reg 10 32bit mmio: [0xfdfff000-0xfdfff3ff] pci :00:1a.7: PME# supported from D0 D3hot D3cold pci :00:1a.7: PME# disabled pci :00:1b.0: reg 10 64bit mmio: [0xfdff4000-0xfdff7fff] pci :00:1b.0: PME# supported from D0 D3hot D3cold pci :00:1b.0: PME# disabled pci :00:1c.0: PME# supported from D0 D3hot D3cold pci :00:1c.0: PME# disabled pci :00:1c.3: PME# supported from D0 D3hot D3cold pci :00:1c.3: PME# disabled pci :00:1d.0: reg 20 io port: [0xf400-0xf41f] pci :00:1d.1: reg 20 io port: [0xf000-0xf01f] pci :00:1d.2: reg 20 io port: [0xec00-0xec1f] pci :00:1d.7: reg 10 32bit mmio: [0xfdffe000-0xfdffe3ff] pci :00:1d.7: PME# supported from D0 D3hot D3cold pci :00:1d.7: PME# disabled pci :00:1f.0: quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO pci :00:1f.0: quirk: region 0480-04bf claimed by ICH6 GPIO pci :00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0800 (mask 003f) pci :00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0290 (mask 003f) pci :00:1f.2: reg 10 io port: [0xe800-0xe807] pci :00:1f.2: reg 14 io port: [0xe400-0xe403] pci :00:1f.2: reg 18 io port: [0xe000-0xe007] pci :00:1f.2: reg 1c io port: [0xdc00-0xdc03] pci :00:1f.2: reg 20 io port: [0xd800-0xd81f] pci :00:1f.2: reg 24 32bit mmio: [0xfdffd000-0xfdffd7ff] pci :00:1f.2: PME# supported from D3hot pci :00:1f.2: PME# disabled pci :00:1f.3: reg 10 32bit mmio: [0xfdffc000-0xfdffc0ff] pci :00:1f.3: reg 20 io port: [0x500-0x51f] pci :00:1f.6: reg 10 64bit mmio: [0xfdffb000-0xfdffbfff] pci :01:00.0: reg 10 32bit mmio: [0xfa00-0xfaff] pci :01:00.0: reg 14 64bit mmio: [0xc000-0xcfff] pci :01:00.0: reg 1c 64bit mmio: [0xf800-0xf9ff] pci :01:00.0: reg 24 io port: [0x5c00-0x5c7f] pci :01:00.0: reg 30 32bit mmio: [0x00-0x07] pci :00:01.0: bridge io port: [0x5000-0x5fff] pci :00:01.0: bridge 32bit mmio: [0xf800-0xfbff] pci :00:01.0: bridge 64bit mmio pref: [0xc000-0xcfff] pci :00:1c.0: bridge io port: [0xa000-0xafff] pci :00:1c.0: bridge 32bit mmio: [0xfdc0-0xfdcf] pci :00:1c.0: bridge 64bit mmio pref: [0xfdb0-0xfdbf] pci :04:00.0: reg 10 64bit mmio: [0xfdefc000-0xfdef] pci :04:00.0: reg 18 io port: [0x6c00-0x6cff] pci :04:00.0: reg 30 32bit mmio: [0x00-0x01] pci :04:00.0: supports D1 D2 pci :04:00.0: PME# supported from D0 D1 D2 D3hot D3cold pci :04:00.0: PME# disabled pci :00:1c.3: bridge io port: [0x6000-0x6fff] pci :00:1c.3: bridge 32bit mmio: [0xfde0-0xfdef] pci :00:1c.3: bri
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Devin Heitmueller wrote: On Sun, Jul 19, 2009 at 9:15 AM, Mark Lord wrote: Devin, Thanks for your good efforts and updates on the xc5000 driver. But the version in 2.6.31 no longer works with mythfrontend from the 0.21-fixes branch of MythTV. .. Also, Could you please install the latest v4l-dvb code using the directions at http://linuxtv.org/repo and see if the problem still occurs. This will tell us if the problem is some patch that didn't make it upstream, and will make it easier for me to give you patches that provide more debug info. .. Okay, I pulled in v4l-dvb-bdd711bbc07e, built/installed/rebooted, and ended up with exactly the same behaviour. So the good news is, nothing appears to have been left out in 2.6.31. :) But still no really good clues to go on, other than this observation from before: The mythbackend (recording) program tunes/records fine with it, but any attempt to watch "Live TV" via mythfrontend just locks up the UI for 30 seconds or so, and then it reverts to the menus. I find that rather odd, as mythfrontend normally has very little interaction with the tuner devices. But it does try to read the signal strength and quality from the tuner, so perhaps this is a clue as to what has gone wrong? .. Really, the mythfrontend DOES NOT DEAL WITH TUNERS directly, leaving that to the mythbackend. EXCEPT for when it wants to show a signal strength/quality indication onscreen, which is done when tuning to a new channel. So it's got to be something on that pathway, I suspect, but despite being a kernel developer, I'm not terribly knowledgeable about V4L, DVB, or the MythTV internals. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Mark Lord wrote: .. Really, the mythfrontend DOES NOT DEAL WITH TUNERS directly, leaving that to the mythbackend. EXCEPT for when it wants to show a signal strength/quality indication onscreen, which is done when tuning to a new channel. So it's got to be something on that pathway, I suspect, but despite being a kernel developer, I'm not terribly knowledgeable about V4L, DVB, or the MythTV internals. .. Okay, got it. Sort of. :) 1. Patched mythtv to not show the signal strength info. No effect. 2. Substituted a different brand/model/chipset DVB tuner for the 950Q, and everything was working fine again. So we know it's not a generic issue. 3. In mythtv-setup -> CaptureCards -> DVB:1 -> RecordingOptions there is a tickbox for "Open DVB Card on Demand". It was ticked, so I un-ticked that box. Everything now works! When that tickbox was selected, the xc5000 took five (5) seconds to "open", as it did the firmware upload every time. This appeared to exceed some timeout inside myth. With the tickbox NOT ticked, myth just opens the tuner once at startup, and keeps it open, so no more delay when it wants to use it. I wonder if we can be smarter/faster about the xc5000 firmware uploads? Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Mark Lord wrote: .. Digital-only, since the tuner stick has never worked (and still doesn't) for analog NTSC with MythTV-0.21-fixes. That's okay, I really only use it for digital ATSC over-the-air (OTA) reception. .. Further to the analog -- which I don't care a whole bunch about -- I did try tracing it through mythtv today. The mythbackend thread that dies (segfault) is trying to read audio frames from the usb-audio device of the 950Q (/dev/dsp1). It seems to suffer massive stack corruption from something in there, though I'm not at all sure what the cause might be. Presumable this same myth code works with other tuners that lack hardware mpeg encoding, but I don't have any of those here to test with. I wonder if it's a 64-bit thing? My mythbox is pure 64-bits. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Mark Lord wrote: .. 3. In mythtv-setup -> CaptureCards -> DVB:1 -> RecordingOptions there is a tickbox for "Open DVB Card on Demand". It was ticked, so I un-ticked that box. Everything now works! When that tickbox was selected, the xc5000 took five (5) seconds to "open", as it did the firmware upload every time. This appeared to exceed some timeout inside myth. With the tickbox NOT ticked, myth just opens the tuner once at startup, and keeps it open, so no more delay when it wants to use it. I wonder if we can be smarter/faster about the xc5000 firmware uploads? .. The firmware downloads take a little over six seconds, each time, and appear to be done after any "sleep" of the device. The "un-ticked checkbox" above means that the device will NEVER be put to sleep, though.. One problem (not new) remains: the device remains "live" on the USB even when the system is powered-off. It stays quite warm to the touch and is obviously wasting power this way. Is there not something the driver could do to put it to sleep on system shutdown, so that it draws much less power, per USB spec ? thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
On Sun, Jul 19, 2009 at 6:42 PM, Mark Lord wrote: > Mark Lord wrote: > .. >> >> 3. In mythtv-setup -> CaptureCards -> DVB:1 -> RecordingOptions >> there is a tickbox for "Open DVB Card on Demand". It was ticked, >> so I un-ticked that box. Everything now works! >> >> When that tickbox was selected, the xc5000 took five (5) seconds to >> "open", >> as it did the firmware upload every time. This appeared to exceed some >> timeout inside myth. >> >> With the tickbox NOT ticked, myth just opens the tuner once at startup, >> and keeps it open, so no more delay when it wants to use it. >> >> I wonder if we can be smarter/faster about the xc5000 firmware uploads? > > .. > > The firmware downloads take a little over six seconds, each time, > and appear to be done after any "sleep" of the device. > > The "un-ticked checkbox" above means that the device will NEVER > be put to sleep, though.. > > > One problem (not new) remains: the device remains "live" on the USB > even when the system is powered-off. It stays quite warm to the touch > and is obviously wasting power this way. > > Is there not something the driver could do to put it to sleep > on system shutdown, so that it draws much less power, per USB spec ? > > thanks! > Hello Mark, Yeah, the situation with the seven second firmware load time is well known. It's actually a result of the i2c's implementation in the au0828 hardware not properly supporting i2c clock stretching. Because of some bugs in the hardware, I have it clocked down to something like 30KHz as a workaround. I spent about a week investigating the i2c bus issue with my logic analyzer, and had to move on to other things. I documented the gory details here back in March if you really care: http://devinjh.livejournal.com/169333.html http://devinjh.livejournal.com/169075.html (and there is more discussion of the various issues at http://www.kernellabs.com/blog ) That said, the issue only occurs with the HVR-950q (and other devices that have both xc5000 and au0828). On most boards, the combined time to load the firmware and do the initial tune is actually about half the time required compared to before the xc5000 improvements (for example, the initial tune time on the PCTV 801e went from 3200ms down to 1100ms with subsequent tunes now taking about 350ms). There is a modprobe option I added for xc5000 called "no_poweroff=1" which results in the tuner never being put to sleep. People who are hitting the MythTV issue can work around the problem that way, at the expense of no power management (which is exactly how the product behaved before the xc5000 improvements). It is a limitation of the xc5000 hardware design that after putting the chip to sleep, the firmware must be reloaded. The xc5000 pulls about 300ma when powered up, which is why it is warm. In fact, my discomfort with how warm it got even when not in use was the whole reason I got the power management working in the first place. Regarding your comments on being able to "put it to sleep on system shutdown", *this* is something I actually was unaware of. I had not really investigated the behavior of the device after shutdown, but this is an area that could certainly use some additional investigation. I've heard similar comments about em28xx, so perhaps what needs to be happening is the dvb core needs to be calling the tuner's sleep function when the module is being unloaded. I would have to figure out the right place to make such a change though (dvb core? the bridge driver? the tuner driver?). Regarding the analog issue with audio, I am aware of the problem, and it is the big outstanding issue preventing people from using the analog support under MythTV (the issue *is* specific to MythTV as other apps work fine with analog audio). I just haven't had the cycles to investigate it yet, but I suspect it's probably a timing issue combined with MythTV doing something really dumb when it hits the exception condition (which causes the segfault). So in summary: 1. You found a regression in MythTV due to the need to reload firmware on the first tune. I can't help but want to blame MythTV for at least part of this given it must have some crappy code for timeout if it cannot distinguish between the time spent in the tuner initalization phase versus the actual tuning request (the timeout seems to be inclusive for both operations). Either I will have to spend some more time trying to "fix" the au0828 i2c bus so the firmware time is actually reasonable, or see if I can trace down which timeout MythTV hits and see if I can change the driver to load the firmware somewhere earlier (if possible). In the meantime, the workarounds are to use the no_poweroff option or uncheck that box in the mythtv-setup) 2. You hit the known analog audio issue that is preventing people from using analog with MythTV. I guess you can look at the analog support as a work in progress - it works with most apps, but there is something going on specifi
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Devin Heitmueller wrote: 2. You hit the known analog audio issue that is preventing people from using analog with MythTV. I guess you can look at the analog support as a work in progress - it works with most apps, but there is something going on specific to MythTV that I haven't isolated yet. Note this issue is completely related to the 950q analog project and has nothing to do with the xc5000 tuner improvements. .. One additional thing I noticed here, is that when tuning analog for the first time, the firmware is reloaded yet again.. even though it has already been loaded once for "digital" operation. Perhaps the extra 6-7second delay here is contributing to Myth's problems. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
On Sun, Jul 19, 2009 at 9:57 PM, Mark Lord wrote: > Devin Heitmueller wrote: >> >> 2. You hit the known analog audio issue that is preventing people >> from using analog with MythTV. I guess you can look at the analog >> support as a work in progress - it works with most apps, but there is >> something going on specific to MythTV that I haven't isolated yet. >> Note this issue is completely related to the 950q analog project and >> has nothing to do with the xc5000 tuner improvements. > > .. > > One additional thing I noticed here, is that when tuning analog > for the first time, the firmware is reloaded yet again.. even though > it has already been loaded once for "digital" operation. > > Perhaps the extra 6-7second delay here is contributing to Myth's problems. That theory would be very easy to check. Just modprobe xc5000 with no_poweroff=1, load up under digital mode, and then try analog mode and see if you hit the segfault. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Devin Heitmueller wrote: Yeah, the situation with the seven second firmware load time is well known. It's actually a result of the i2c's implementation in the au0828 hardware not properly supporting i2c clock stretching. Because of some bugs in the hardware, I have it clocked down to something like 30KHz as a workaround. I spent about a week investigating the i2c bus issue with my logic analyzer, and had to move on to other things. I documented the gory details here back in March if you really care: .. From your livejournal comments, it sounded like the slow clock might not be necessary until *after* the firmware transfer. Mmm.. I wonder if perhaps a higher clock speed could be used during the firmware download, and then switch to the slower 30KHz speed afterward ? This could reduce the firmware transfer to a couple of seconds, much better than the current 6-7 second pause. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
On Sun, Jul 19, 2009 at 10:18 PM, Mark Lord wrote: > Devin Heitmueller wrote: >> >> Yeah, the situation with the seven second firmware load time is well >> known. It's actually a result of the i2c's implementation in the >> au0828 hardware not properly supporting i2c clock stretching. Because >> of some bugs in the hardware, I have it clocked down to something like >> 30KHz as a workaround. I spent about a week investigating the i2c bus >> issue with my logic analyzer, and had to move on to other things. I >> documented the gory details here back in March if you really care: > > .. > > From your livejournal comments, it sounded like the slow clock might > not be necessary until *after* the firmware transfer. > > Mmm.. I wonder if perhaps a higher clock speed could be used > during the firmware download, and then switch to the slower 30KHz > speed afterward ? > > This could reduce the firmware transfer to a couple of seconds, > much better than the current 6-7 second pause. I did experiment with introducing a tuner callback to inform the bridge to enter a high speed mode, which in theory would have allowed the firmware load at 250Khz (and then revert to the slower speed after the load finished). However, for some unknown reason the tuner would not work after the load. I would see i2c errors on the bus when doing the tune, and I was not able to identify the cause. I spent a couple of nights playing with the idea, but didn't have more time to spend on it. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Devin Heitmueller wrote: On Sun, Jul 19, 2009 at 9:57 PM, Mark Lord wrote: .. One additional thing I noticed here, is that when tuning analog for the first time, the firmware is reloaded yet again.. even though it has already been loaded once for "digital" operation. Perhaps the extra 6-7second delay here is contributing to Myth's problems. That theory would be very easy to check. Just modprobe xc5000 with no_poweroff=1, load up under digital mode, and then try analog mode and see if you hit the segfault. .. I tried that today, and it didn't fix anything. Oh well. :) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
