Bug 13528

Summary:	au0828: major drop in reception quality between 2.6.29.4 and 2.6.30 on HVR-950q
Product:	v4l-dvb	Reporter:	Jim Faulkner (jfaulkne)
Component:	dvb-usb	Assignee:	dvb-usb (v4l-dvb_dvb-usb)
Status:	CLOSED INVALID
Severity:	normal	CC:	devin.heitmueller, rjw
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.30	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	my dmesg under 2.6.29.4 my dmesg under 2.6.30 azap output under 2.6.29.4 with both au0828 and em28xx attached azap output under 2.6.30 with both au0828 and em28xx attached azap output under 2.6.30 only au0828 attached dmesg under 2.6.30 only au0828 attached

Description Jim Faulkner 2009-06-13 19:34:07 UTC

I am seeing a major drop in reception quality on my Hauppauge HVR-950q between 2.6.29.4 and 2.6.30.  I know that DTV reception can be finicky at times, however this very much seems to be a driver issue.

On kernels 2.6.29.4 and earlier, I have no problem getting in a local VHF DTV station (WTNH-DT).  After booting to 2.6.30, the station is unwatchable.  I get little to no picture at all using mythtv under 2.6.30, whereas mythtv has no issues with the signal on 2.6.29.4 and earlier.

This is entirely reproducable on my end.  I can boot into 2.6.29.4 and get a perfect picture, then reboot into 2.6.30 and get terrible reception, boot into 2.6.29.4 and it works great, boot into 2.6.30 and get terrible reception again.  This is all within a 10 minute period, clear weather and not touching the antenna.  I also have Windows on this machine and the Hauppauge signal strength monitor reports a very high signal to noise ratio and no errors on WTNH-DT.

I also have a em28xx based Hauppauge HVR-950 plugged into this machine.  It works just fine on both 2.6.29.4 and 2.6.30.

Comment 1 Jim Faulkner 2009-06-13 19:35:05 UTC

Created attachment 21898 [details]
my dmesg under 2.6.29.4

Comment 2 Jim Faulkner 2009-06-13 19:35:38 UTC

Created attachment 21899 [details]
my dmesg under 2.6.30

Comment 3 Devin Heitmueller 2009-06-23 01:22:22 UTC

djh - I will do some testing and see if I can reproduce this locally.  If so, I can bisect the tree and see when this actually got introduced.

Comment 4 Devin Heitmueller 2009-06-23 01:25:42 UTC

Jim,

Could you please run azap to tune to the station with both kernels, and post the output?  This will let me see the SNR data, which will help narrow down whether the problem is with the programming of the demodulator and tuner or whether it's an issue with the bridge.

Thanks,

Devin

Comment 5 Devin Heitmueller 2009-06-23 01:51:00 UTC

djh - I've just reviewed the dmesg output Jim provided, and the situation looks very strange.  In both cases it would appear that the hvr-950q is never actually used to do the tuning.  I see ATSC tuning requests for the hvr-950 (em28xx), but not for the 950q.

Look at the logs: 

The 2.6.29 shows both devices being initialized, and the firmware loading for the xc5000.  Then it shows a tuning attempt for the xc3028, which is for the hvr-950, *not* the hvr-950q

The 2.6.30 log again shows both devices being initialized, and the xc5000 firmware being loaded during analog initialization.  Then again we see the tuning attempt with the xc2028 driver.

Can you please remove the em28xx based HVR-950 from the product, retest, and provide dmesg output for the condition with only the HVR-950Q present in the system?

Comment 6 Jim Faulkner 2009-06-23 02:09:46 UTC

Created attachment 22059 [details]
azap output under 2.6.29.4 with both au0828 and em28xx attached

Comment 7 Jim Faulkner 2009-06-23 02:11:45 UTC

Created attachment 22060 [details]
azap output under 2.6.30 with both au0828 and em28xx attached

Comment 8 Devin Heitmueller 2009-06-23 02:14:51 UTC

djh - Looking at the two attachments, each only has a single invocation of azap.  In fact, it looks like the first attachment has an azap against the 950q and the second attachment has an azap against the 950.

Comment 9 Jim Faulkner 2009-06-23 02:21:22 UTC

Created attachment 22061 [details]
azap output under 2.6.30 only au0828 attached

Comment 10 Jim Faulkner 2009-06-23 02:23:39 UTC

Created attachment 22062 [details]
dmesg under 2.6.30 only au0828 attached

Comment 11 Jim Faulkner 2009-06-23 02:29:12 UTC

Is there a way to tell which adapter is assigned to which /dev/dvb/adapterX device?  If so I can test and let you know if the au0828 and em28xx are assigned different device names under 2.6.29.4 and 2.6.30.

I'm running "azap -a 0 WTNH-DT" for all of the tests I've done today.

Comment 12 Devin Heitmueller 2009-06-23 02:35:01 UTC

djh - the SNR stats actually look a little better with the 2.6.30 code.  The SNR floats at around 0xdc/0xe6 with 2.6.29 and 0xf0/0xfa with 2.6.30.

Still, there shouldn't be any changes to the SNR behavior in 2.6.30, since the xc5000 improvements didn't come until 2.6.31.

Comment 13 Devin Heitmueller 2009-06-23 02:39:24 UTC

djh - Jim, if you have femon installed, you can run that and it will tell you the frontend.  e.g.:

root@ubuntumb:~# femon -a 0
FE: Auvitek AU8522 QAM/8VSB Frontend (ATSC)
status       | signal 00fa | snr 00fa | ber 00000000 | unc 00000000 | 
status       | signal 00fa | snr 00fa | ber 00000000 | unc 00000000 | 
^C

Comment 14 Jim Faulkner 2009-06-23 21:23:15 UTC

Yep, the em28xx and au0828 simply switched device names between 2.6.29.4 and 2.6.30.  Strange, I thought udev took care of consistently naming devices.

So it looks like this is just a user error.  Sorry for the false alarm, feel free to close the bug.

Comment 15 Devin Heitmueller 2009-06-23 21:35:26 UTC

djh - that isn't terribly surprising.  With the addition of the HVR-950q analog support, the driver takes longer to initialize, so the HVR-950 wins the race to creating the DVB device object.

Not much I can do about that I'm afraid.

Comment 16 Devin Heitmueller 2009-06-24 20:42:41 UTC

djh - This was confirmed to be user error and *not* a regression, so this ticket should be closed (I'm mentioning this because it was just made a blocker for 2.6.29)

Comment 17 Rafael J. Wysocki 2009-06-29 13:36:43 UTC

Dropping from the list of regressions, closing.