Re: HauppaugeTV-quadHD DVB-T mpeg risc op code errors

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

 



On 31/07/17 13:55, Steven Toth wrote:
On Sun, Jul 30, 2017 at 8:55 AM, Dave Newman
<d.r.newman@xxxxxxxxxxxxxxxxxx> wrote:
I can confirm the problems with the cx23885 driver reported by Steven
Toth on 6 June 2017. He found that:

I tried the card in a different older Intel i7 board and it worked
flawlessly. I then started to wonder if it was some new
incompatibility introduced with Kaby Lake. I had tweaked the UEFI
settings on the new Kaby Lake board to enable VT-d/VT-x since I wanted
to run Linux as a host OS with Windows 10 running on top of qemu/KVM.
Upon resetting the UEFI settings to their defaults (VT-d/VT-x
disabled) the card worked without issue.

Like him:

- I have a recent Hauppauge WinTV-quadHD TV tuner PCIe card

- I have a new fast multi-processor CPU. He found that there were no
problems on

- Enabling debug output for the cx23885 driver *fixes* the issue
(options cx23885 debug=5), letting me run a scan of DVB channels.

Unlike him:

- my CPU is an 8 core Ryzen 1700 on a new Gigabyte AB350 motherboard.

- turning off iommu does not fix the problem.

I do not know the cx23885 code well enough to propose any patches, but I
am happy to do debugging and testing. One thing I noticed is that
i2cdetect output differs from that on
https://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-quadHD_(DVB-T/T2/C).
E.g.

       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: -- -- -- -- UU -- UU -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Anything from 60 and above is listed as UU.

The motherboard is known to have problems with chained IRQs, so the latest
Ubuntu kernels use independent IRQs to avoid an interrupt storm on IRQ 7.

Apart from that, let me know what else I should test.

David, thanks for the report.

Just to be clear, I didn't report the original issue, I merely
attempted to repro it on a Sandy Bridge quad core. I'm the original
cx23885/8 Linux driver developer, so I know the hardware well and have
a vested interested in chasing down any obvious problems.

I was unable to repro the issue.

That being said, another user reported success after disabling
VT-d/VT-x. Have you tried that?

- Steve

Sorry, I quoted the wrong author from the thread. It was Adam Zegelin.

My AMD motherboard uses different terminology. I have disabled the SVM mode needed for virtualisation. I have also disabled IOMMU on the motherboard (adding amd_iommu=off to the kernel boot parameters makes no difference). I have left SMT mode at the auto default. That is described as "CPU Simultaneous Multi-Threading technology", whatever that is.

So I am currently running the card with debug=5.

Any suggestions as to how I can narrow down the problem?

David Newman



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux