Open tommycw1 opened 3 years ago
What Motherboard do you have tommycw1 ?.
Hi shspvr
tom@mythfe:~$ sudo dmidecode | grep -A3 "type 2"
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: 970A-UD3P
You don't need to mess with gen mode if it in the small 1x slot
Now as for motherboard it is only 2.0 standard you need more up to date motherboard with 3.0 standard in order to have that option gen mode option and it only apply to long 16x Slot or 8x Half Slot
@shspvr - Thanks - makes sense
I've been googling around about this and found several other similar issues like this:
options cx23885 debug=7
or
options cx23885 debug=6
May be workarounds for this issue.
Later, #51 & #69 reported similar issues - in these thread it seems people are instructing to use a km option of
options cx23885 dma_reset_workaround=2
These are a couple years old though so I'm not sure if this is still valid on a 5.4 kernel
@b-rad-NDi - can you confirm if any of these options are still valid for the 5.4 Ubuntu 20.04 kernel?
@b-rad-NDi
I was able to confirm that the dma_reset_workaround option was still a valid option in the kernel module for 5.4 by listing all of the available parameters with the following:
tom@mythfe:~$ modinfo cx23885 | grep parm
parm: disable_analog_audio:disable analog audio ALSA driver (int)
parm: audio_debug:enable debug messages [analog audio] (int)
parm: ci_dbg:Enable CI debugging (int)
parm: ci_irq_enable:Enable IRQ from CAM (int)
parm: ir_888_debug:enable debug messages [CX23888 IR controller] (int)
parm: mpegbufs:number of mpeg buffers, range 2-32 (int)
parm: mpeglines:number of lines in an MPEG buffer, range 2-32 (int)
parm: mpeglinesize:number of bytes in each line of an MPEG buffer, range 512-1024 (int)
parm: v4l_debug:enable V4L debug messages (int)
parm: alt_tuner:Enable alternate tuner configuration (int)
parm: adapter_nr:DVB adapter numbers (array of short)
parm: i2c_debug:enable debug messages [i2c] (int)
parm: i2c_scan:scan i2c bus at insmod time (int)
parm: dma_reset_workaround:periodic RiSC dma engine reset; 0-force disable, 1-driver detect (default), 2-force enable (int)
parm: debug:enable debug messages (int)
parm: card:card type (array of int)
parm: vbibufs:number of vbi buffers, range 2-32 (int)
parm: vbi_debug:enable debug messages [vbi] (int)
parm: video_nr:video device numbers (array of int)
parm: vbi_nr:vbi device numbers (array of int)
parm: video_debug:enable debug messages [video] (int)
parm: irq_debug:enable debug messages [IRQ handler] (int)
parm: vid_limit:capture memory limit in megabytes (int)
parm: netup_card_rev:NetUP Dual DVB-T/C CI card revision (int)
parm: enable_885_ir:Enable integrated IR controller for supported
So I added:
options cx23885 dma_reset_workaround=2
to /etc/modprobe.d/cx23885.conf. I rebooted the computer and I now have a working QuadHD card!
I do however still get the following reported on kern.log every time I tune to a new channel:
Dec 23 16:13:39 mythfe kernel: [ 6241.798482] si2157 6-0060: found a 'Silicon Labs Si2157-A30'
Dec 23 16:13:39 mythfe kernel: [ 6241.820899] si2157 6-0060: firmware version: 3.0.5
Not sure if this is expected behavior or a remaining issue.
Wondering two things:
These messages:
Dec 23 16:13:39 mythfe kernel: [ 6241.798482] si2157 6-0060: found a 'Silicon Labs Si2157-A30'
Dec 23 16:13:39 mythfe kernel: [ 6241.820899] si2157 6-0060: firmware version: 3.0.5
Are red herrings, they are output every single time a card is opened. It really signifies nothing. It's a bad design decision to have done it that way, but it wasn't mine.
I have added a couple new iommu pci id's to my builds that were just pushed to launchpad. If yours is not one of them you'll have to figure out what it is and then I can add it to the list of cpu's the fix is applied to by default.
Thanks for this @b-rad-NDi - glad to know this is a non-event. Looks like the si2157 module doesn't have any options to turn this off unfortunately...
tom@mythfe:~$ modinfo si2157 | grep parm
parm: tuner_lock_debug:if set, signal lock is briefly waited on after setting params (int)
Oh well - nbd I guess.
I poked around your github commits quickly and didn't see anything that jumped out at me about IOMMUs, so not sure where to look, but here is mine:
tom@mythfe:~$ sudo dmidecode | grep -A3 "type 2"
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: 970A-UD3P
tom@mythfe:~$ lspci | grep IOMMU
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD/ATI] RD890S/RD990 I/O Memory Management Unit (IOMMU)
So to make sure I'm clear on this, I changed motherboards and OSs at the same time. It sounds like my issue wasn't related to the OS change from Ubuntu 16.04->20.04 but related to my mobo change and it's IOMMU. Is that correct?
This is almost exclusively an AMD issue. If you look in cx23885-core.c you'll see the list of current id's. I can't recall offhand how to find them, but I don't think you get it from lspci.
Newer Intel mobos can have issues, but they are fixed by forcing the pcie slot to gen1 mode.
@b-rad-NDi - OK, yes, I see in the code now here:
Interestingly it talks about this being an issue with Ryzen, but I'm running an older mobo/processor. My media server PC that I have this card installed in is using this processor:
tom@mythfe:~$ cat /proc/cpuinfo | grep "model name"
model name : AMD FX(tm)-6300 Six-Core Processor
on this mobo:
tom@mythfe:~$ sudo dmidecode |grep -i product
Product Name: 970A-UD3P
Anyway, my desktop (not the box with this card installed) happens to be Ryzen 7 and when I look at that IOMMU, I see the same vendor ID number as one of the two refered to in cx23885-core.c 0x1451
tom@orbital:~$ lspci -nn | grep IOMMU
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) I/O Memory Management Unit [1022:1451]
Doing the same in the box this card IS installed in shows a very different ID
tom@mythfe:~$ sudo lspci -nn | grep IOMMU
00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD/ATI] RD890S/RD990 I/O Memory Management Unit (IOMMU) [1002:5a23]
So, I believe the ID that needs to be added is 0x5a23
Is the SVM and IOMMU Controller disable or enable it not needed unless your running a virtual machines it maybe the source of your problem. Besure Cool & Quiet disable
@tommycw1 : I'll add this to my builds and submit it for inclusion upstream.
I found this issue while trying to run a Hauppauge QuadHD on Debian Buster with Linux kernel 5.10 on an AMD Ryzen system. I can confirm that using options cx23885 dma_reset_workaround=2
allowed me to resolve the no signal issue.
Unfortunately, options cx23885 dma_reset_workaround=2
still causes mpeg risc op code error
messages. Is this expected?
$ uname -a
Linux pony 5.10.0-0.bpo.7-amd64 #1 SMP Debian 5.10.40-1~bpo10+1 (2021-06-04) x86_64 GNU/Linux
I am having issues with this card on two systems:
The AMD system posts:
Audio risc op code error
while the Intel system posts:
mpeg risc op code error
IOMMU is enabled on both systems as it is required for PCIe passthrough of devices to VMs.
On the other hand, I am getting no problems with Ubuntu server 20.04.2 LTS 5.4.0-77-generic on an HP T620 Plus thin client running an AMD GX-420CA SOC, no IOMMU enabled by me. I believe my issues are related to IOMMU. I will try on the Ryzen system with amd_iommu=off and report back, unfortunately the Intel system is a production machine so I cannot afford much downtime.
Edit: The two issues were resolved with different solutions. The AMD system needed analog audio disabled on the cx23885 driver.
The Intel system needed dma_reset_workaround=2
set. All 4 tuners are functional now, both DVB-C and DVB-T but I still get a single mpeg risc op code error
as @sergiud. It does not seem to cause any problems though.
I'm posting here because my issue is stated in the title. I'm dual-booting Ubuntu 16.04/kernel 4.15 (Linux Mint 18.2) and 20.04/kernel 5.4 (Linux Mint 20.2) on the same Intel-based hardware. The Hauppauge WinTV-QuadHD-ATSC (card 57) is recognized on both systems.
The QuadHD card works just fine on the 16.04 system with Tvheadend and Kodi, but Tvheadend says "Scan - no data" with the registered cx23885 devices on the 20.04 OS with kernel 5.4.
My processor is an Intel Haswell model i5-4690S quad-core CPU @3.20 GHz so the AMD Ryzen workarounds don't apply. I confess to trying them anyway. There's no way to set the gen mode on the PCI-e bus in the BIOS. There's no IOMMU found with lspci -nn | grep IOMMU
.
I was perfectly happy with the very stable and fully-functional older OS and hardware, but the LTS support for 16.04 recently expired. (The new 20.04/5.4 setup also had frequent link up/down trouble with the Intel onboard NIC, which works flawlessly with 16.04/4.15. The boot option to limit the sleep state didn't help. I'm now using a USB-to-Ethernet adapter that works fine for both OSes.)
I tried a spare WinTV-HVR-955Q USB tuner with the newer OS. It has the same issue, reporting as a single version of the same LG Electronics LGDT3306A VSB/QAM devices in the QuadHD card. It has the same Tvheadend "Scan - no data" in 20.04/5.4.
The same "cx23885 driver version 0.0.4 loaded" appears in the system logs of 16.04/4.15 and 20.04/5.4. There are no error messages other than a single set of "frequency 0 out of range (54000000..858000000)" for all four adapters at startup, something that's been there even with the 16.04 system for as long as I can recall. (The 1609 QuadHD card was purchased in October 2017.) They don't cause any problems.
$ uname -a
Linux Onyx 5.4.0-81-generic #91-Ubuntu SMP Thu Jul 15 19:09:17 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Here's some relevant lines from dmesg | grep cx238
:
[ 4.375105] cx23885: cx23885 driver version 0.0.4 loaded
[ 4.375226] cx23885: CORE cx23885[0]: subsystem: 0070:6a18, board: Hauppauge WinTV-QuadHD-ATSC [card=57,autodetected]
[ 4.734365] cx23885: cx23885[0]: hauppauge eeprom: model=165100
[ 4.783947] cx25840 11-0044: cx23888 A/V decoder found @ 0x88 (cx23885[0])
[ 5.459381] cx25840 11-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes)
[ 5.491184] cx23885: cx23885_dvb_register() allocating 1 frontend(s)
[ 5.491186] cx23885: cx23885[0]: cx23885 based dvb card
[ 5.491187] cx23885: dvb_register(): board=57 port=1
[ 5.504339] dvbdev: DVB: registering new adapter (cx23885[0])
[ 5.504351] cx23885 0000:03:00.0: DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3306A VSB/QAM Frontend)...
... same for the other three
[ 6.527240] cx23885: cx23885_dev_checkrevision() Hardware revision = 0xd0
[ 6.527244] cx23885: cx23885[1]/0: found at 0000:04:00.0, rev: 4, irq: 18, latency: 0, mmio: 0xc0400000
[ 6.856017] cx23885 0000:04:00.0: DVB: adapter 3 frontend 0 frequency 0 out of range (54000000..858000000)
[ 6.992413] cx23885 0000:04:00.0: DVB: adapter 2 frontend 0 frequency 0 out of range (54000000..858000000)
[ 7.132029] cx23885 0000:03:00.0: DVB: adapter 1 frontend 0 frequency 0 out of range (54000000..858000000)
[ 7.279214] cx23885 0000:03:00.0: DVB: adapter 0 frontend 0 frequency 0 out of range (54000000..858000000)
What's different between kernel 4.15 and kernel 5.4? The Hauppauge drivers are reporting the same version. The hardware is exactly the same. I'm thinking it is something OS related. For now, I'm okay with dual-booting to record shows, but I'd hate to need another computer just to record my shows and have a supported OS, too.
I've been using a QuadHD tuner on Ubuntu 16.04 LTS for about 1.5 years as a tuner in a MythTV backed.
I recently had a mobo die so I put in another old mobo and installed a fresh copy of Ubuntu 20.04 LTS onto the box
Here is my kernel:
The OS sees the hardware on the PCI bus:
The OS creates all 4 DVB devs:
and the OS loads the appropriate module:
I had started seeing issues that appeared that the OS was intermittently seeing the device, losing contact and finding again over and over.
I thought that maybe when my mobo died this card was also damaged so I contacted Hauppague tech support and they told me to send in my card. I sent my card into Hauppauge under warranty they ran it, say it is fine and returned it to me.
I received from tech support this:
JHenriquez@hauppauge.com Dec 14, 2020, 1:23 PM (8 days ago)
Hello,
I was ask by sales to email you about your situation with your QuadHD.
I asked our Linux engineer that works on our PPA and submitting the updates to Linux to be included in the kernels and he stated the following about your problem.
“This is a problem that has cropped up every now and again. Something has happened in newer kernels to make it more prevalent.
For a lot of intel users forcing the pcie slot that the card is plugged into to gen1 mode has fixed them completely.”
He also stated that the issue is related to the analog parts on the board that we actually do not use and he would look into this and disabling it in future patches.
But you can contact him directly and submit any issues at his GIT page. https://github.com/b-rad-ndi/ubuntu-media-tree-kernel-builder
So, since the OS is finding the correct kernel module, I didn't think I needed to install this PPA/kernel. Prior to sending in my card, I did install the PPA and I installed the km but had the same issues. I have since revered back to the stock kernel as you can see in my uname -a above.
Following the advice I received form tech support - I reinstalled my card after receiving back from Hauppague and (unfortunately) verified it still cannot tune to any channels. Then I rebooted the machine and went into BIOS to investigate setting the PCIE port to Gen 1. It was mentioned this was a solution for many Intel users, and I'm using an AMD processor, but I decided to look anyway. My mobo's BIOS does not have any setting regarding the PCIE ports unfortunately so I cannot try this out.
Next I started looking for other issued in this repo and found https://github.com/b-rad-NDi/Ubuntu-media-tree-kernel-builder/issues/119 which seems similar. I noted it was suggested to disable analogue audio using the km options
options cx23885 disable_analog_audio=1
So I added that to my /etc/modprobe.d/linuxtv.conf, rebooted the box and still have the issues.
I have noted that I am seeing an error related to this km in dmesg, every time I try to tune to a channel, I get the following tacked to the end of dmesg:
Next I added this repo and installed the kernel:
I have verified I still have the same issues, I cannot tune to any channel on any of the 4 QuadHD tuners and get the same dmesg errors.
Is there any other recommendations for troubleshooting?