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

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

[Rolf Pedersen]

Hi Folks,
I just subscribed after having trouble with this card that worked for 3 
years on Skylake i5-6500 but stopped tuning when I moved it to AMD Ryzen 
5 3400G machine.  I found the workaround in the archived thread 
referenced in the subject line and don't know any way to reply directly 
to it: https://www.spinics.net/lists/linux-media/msg114563.html

My card is ATSC as on this page: 
https://www.kernel.org/doc/html/v4.10/media/v4l-drivers/cx23885-cardlist.html
57     Hauppauge WinTV-QuadHD-ATSC     0070:6a18, 0070:6b18

and

[rolf@x570i coup]$ lspcidrake -v | grep Conexant
cx23885         : Conexant Systems, Inc.|CX23887/8 PCIe Broadcast Audio 
and Video Decoder with 3D Comb [MULTIMEDIA_VIDEO] (vendor:14f1 
device:8880 subv:0070 subd:6b18) (rev: 04)
cx23885         : Conexant Systems, Inc.|CX23887/8 PCIe Broadcast Audio 
and Video Decoder with 3D Comb [MULTIMEDIA_VIDEO] (vendor:14f1 
device:8880 subv:0070 subd:6a18) (rev: 04)

Neither scan, dvbscan, nor w_scan2, nor Kaffeine TV, while finding 
working frequencies, could divulge any services.  The workaround was in 
the referenced post:  cx23885.debug=8

I've seen another report of a different kernel option that worked on 
Ryzen: |cx23885.dma_reset_workaround=2 here: 
https://www.dslreports.com/forum/r32639318-SFF-3400G-build#32640298

Ok.  Just wanted to join the chorus with a *metoo* in case I can provide 
some (guided) forensics.
Thanks,
Rolf
|

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

[Sean Young]

Hi,

On Thu, Apr 23, 2020 at 05:32:32AM -0700, Rolf Pedersen wrote:
> Hi Folks,
> I just subscribed after having trouble with this card that worked for 3
> years on Skylake i5-6500 but stopped tuning when I moved it to AMD Ryzen 5
> 3400G machine.  I found the workaround in the archived thread referenced in
> the subject line and don't know any way to reply directly to it:
> https://www.spinics.net/lists/linux-media/msg114563.html
> 
> My card is ATSC as on this page:
> https://www.kernel.org/doc/html/v4.10/media/v4l-drivers/cx23885-cardlist.html
> 57     Hauppauge WinTV-QuadHD-ATSC     0070:6a18, 0070:6b18
> 
> and
> 
> [rolf@x570i coup]$ lspcidrake -v | grep Conexant
> cx23885         : Conexant Systems, Inc.|CX23887/8 PCIe Broadcast Audio and
> Video Decoder with 3D Comb [MULTIMEDIA_VIDEO] (vendor:14f1 device:8880
> subv:0070 subd:6b18) (rev: 04)
> cx23885         : Conexant Systems, Inc.|CX23887/8 PCIe Broadcast Audio and
> Video Decoder with 3D Comb [MULTIMEDIA_VIDEO] (vendor:14f1 device:8880
> subv:0070 subd:6a18) (rev: 04)
> 
> Neither scan, dvbscan, nor w_scan2, nor Kaffeine TV, while finding working
> frequencies, could divulge any services.  The workaround was in the
> referenced post:  cx23885.debug=8
> 
> I've seen another report of a different kernel option that worked on Ryzen:
> |cx23885.dma_reset_workaround=2 here:
> https://www.dslreports.com/forum/r32639318-SFF-3400G-build#32640298
> 
> Ok.  Just wanted to join the chorus with a *metoo* in case I can provide
> some (guided) forensics.

So there is a commit for a related issue:

https://git.linuxtv.org/media_tree.git/commit/?id=4bd46aa0353e022c2401a258e93b107880a66533

That is kernel v5.0 and higher. So:

1. What kernel are you using?

2. What is the full lspci -n of your machine?

Thanks,

Sean

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

[Rolf Pedersen]

Hi,

On 04/23/2020 08:35 AM, Sean Young wrote:
> Hi,
>
> On Thu, Apr 23, 2020 at 05:32:32AM -0700, Rolf Pedersen wrote:
>> Hi Folks,
>> I just subscribed after having trouble with this card that worked for 3
>> years on Skylake i5-6500 but stopped tuning when I moved it to AMD Ryzen 5
>> 3400G machine.  I found the workaround in the archived thread referenced in
>> the subject line and don't know any way to reply directly to it:
>> https://www.spinics.net/lists/linux-media/msg114563.html
>>
>> My card is ATSC as on this page:
>> https://www.kernel.org/doc/html/v4.10/media/v4l-drivers/cx23885-cardlist.html
>> 57     Hauppauge WinTV-QuadHD-ATSC     0070:6a18, 0070:6b18
>>
>> and
>>
>> [rolf@x570i coup]$ lspcidrake -v | grep Conexant
>> cx23885         : Conexant Systems, Inc.|CX23887/8 PCIe Broadcast Audio and
>> Video Decoder with 3D Comb [MULTIMEDIA_VIDEO] (vendor:14f1 device:8880
>> subv:0070 subd:6b18) (rev: 04)
>> cx23885         : Conexant Systems, Inc.|CX23887/8 PCIe Broadcast Audio and
>> Video Decoder with 3D Comb [MULTIMEDIA_VIDEO] (vendor:14f1 device:8880
>> subv:0070 subd:6a18) (rev: 04)
>>
>> Neither scan, dvbscan, nor w_scan2, nor Kaffeine TV, while finding working
>> frequencies, could divulge any services.  The workaround was in the
>> referenced post:  cx23885.debug=8
>>
>> I've seen another report of a different kernel option that worked on Ryzen:
>> |cx23885.dma_reset_workaround=2 here:
>> https://www.dslreports.com/forum/r32639318-SFF-3400G-build#32640298
>>
>> Ok.  Just wanted to join the chorus with a *metoo* in case I can provide
>> some (guided) forensics.
> So there is a commit for a related issue:
>
> https://git.linuxtv.org/media_tree.git/commit/?id=4bd46aa0353e022c2401a258e93b107880a66533
>
> That is kernel v5.0 and higher. So:
>
> 1. What kernel are you using?
>
> 2. What is the full lspci -n of your machine?
>
> Thanks,
>
> Sean
>

[rolf@x570i ~]$ uname -r
5.5.15-desktop-3.mga7
[rolf@x570i ~]$
[rolf@x570i ~]$
[rolf@x570i ~]$ lspci -n
00:00.0 0600: 1022:15d0
00:00.2 0806: 1022:15d1
00:01.0 0600: 1022:1452
00:01.1 0604: 1022:15d3
00:01.2 0604: 1022:15d3
00:01.6 0604: 1022:15d3
00:08.0 0600: 1022:1452
00:08.1 0604: 1022:15db
00:08.2 0604: 1022:15dc
00:14.0 0c05: 1022:790b (rev 61)
00:14.3 0601: 1022:790e (rev 51)
00:18.0 0600: 1022:15e8
00:18.1 0600: 1022:15e9
00:18.2 0600: 1022:15ea
00:18.3 0600: 1022:15eb
00:18.4 0600: 1022:15ec
00:18.5 0600: 1022:15ed
00:18.6 0600: 1022:15ee
00:18.7 0600: 1022:15ef
01:00.0 0604: 12d8:2304 (rev 05)
02:01.0 0604: 12d8:2304 (rev 05)
02:02.0 0604: 12d8:2304 (rev 05)
03:00.0 0400: 14f1:8880 (rev 04)
04:00.0 0400: 14f1:8880 (rev 04)
05:00.0 0604: 1022:57ad
06:02.0 0604: 1022:57a3
06:04.0 0604: 1022:57a3
06:08.0 0604: 1022:57a4
06:09.0 0604: 1022:57a4
06:0a.0 0604: 1022:57a4
07:00.0 0280: 8086:2723 (rev 1a)
08:00.0 0200: 8086:1539 (rev 03)
09:00.0 1300: 1022:1485
09:00.1 0c03: 1022:149c
09:00.3 0c03: 1022:149c
0a:00.0 0106: 1022:7901 (rev 51)
0b:00.0 0106: 1022:7901 (rev 51)
0c:00.0 0108: 144d:a808
0d:00.0 0300: 1002:15d8 (rev c8)
0d:00.1 0403: 1002:15de
0d:00.2 1080: 1022:15df
0d:00.3 0c03: 1022:15e0
0d:00.4 0c03: 1022:15e1
0d:00.6 0403: 1022:15e3
0e:00.0 0106: 1022:7901 (rev 61)
[rolf@x570i ~]$

Thanks,
Rolf

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

[Sean Young]

Hi,

On Thu, Apr 23, 2020 at 08:49:17AM -0700, Rolf Pedersen wrote:
> Hi,
> 
> On 04/23/2020 08:35 AM, Sean Young wrote:
> > Hi,
> > 
> > On Thu, Apr 23, 2020 at 05:32:32AM -0700, Rolf Pedersen wrote:
> > > Hi Folks,
> > > I just subscribed after having trouble with this card that worked for 3
> > > years on Skylake i5-6500 but stopped tuning when I moved it to AMD Ryzen 5
> > > 3400G machine.  I found the workaround in the archived thread referenced in
> > > the subject line and don't know any way to reply directly to it:
> > > https://www.spinics.net/lists/linux-media/msg114563.html
> > > 
> > > My card is ATSC as on this page:
> > > https://www.kernel.org/doc/html/v4.10/media/v4l-drivers/cx23885-cardlist.html
> > > 57     Hauppauge WinTV-QuadHD-ATSC     0070:6a18, 0070:6b18
> > > 
> > > and
> > > 
> > > [rolf@x570i coup]$ lspcidrake -v | grep Conexant
> > > cx23885         : Conexant Systems, Inc.|CX23887/8 PCIe Broadcast Audio and
> > > Video Decoder with 3D Comb [MULTIMEDIA_VIDEO] (vendor:14f1 device:8880
> > > subv:0070 subd:6b18) (rev: 04)
> > > cx23885         : Conexant Systems, Inc.|CX23887/8 PCIe Broadcast Audio and
> > > Video Decoder with 3D Comb [MULTIMEDIA_VIDEO] (vendor:14f1 device:8880
> > > subv:0070 subd:6a18) (rev: 04)
> > > 
> > > Neither scan, dvbscan, nor w_scan2, nor Kaffeine TV, while finding working
> > > frequencies, could divulge any services.  The workaround was in the
> > > referenced post:  cx23885.debug=8
> > > 
> > > I've seen another report of a different kernel option that worked on Ryzen:
> > > |cx23885.dma_reset_workaround=2 here:
> > > https://www.dslreports.com/forum/r32639318-SFF-3400G-build#32640298
> > > 
> > > Ok.  Just wanted to join the chorus with a *metoo* in case I can provide
> > > some (guided) forensics.
> > So there is a commit for a related issue:
> > 
> > https://git.linuxtv.org/media_tree.git/commit/?id=4bd46aa0353e022c2401a258e93b107880a66533
> > 
> > That is kernel v5.0 and higher. So:
> > 
> > 1. What kernel are you using?
> > 
> > 2. What is the full lspci -n of your machine?
> > 
> > Thanks,
> > 
> > Sean
> > 
> 
> [rolf@x570i ~]$ uname -r
> 5.5.15-desktop-3.mga7
> [rolf@x570i ~]$
> [rolf@x570i ~]$
> [rolf@x570i ~]$ lspci -n
> 00:00.0 0600: 1022:15d0
> 00:00.2 0806: 1022:15d1
> 00:01.0 0600: 1022:1452
> 00:01.1 0604: 1022:15d3
> 00:01.2 0604: 1022:15d3
> 00:01.6 0604: 1022:15d3
> 00:08.0 0600: 1022:1452
> 00:08.1 0604: 1022:15db
> 00:08.2 0604: 1022:15dc
> 00:14.0 0c05: 1022:790b (rev 61)
> 00:14.3 0601: 1022:790e (rev 51)
> 00:18.0 0600: 1022:15e8
> 00:18.1 0600: 1022:15e9
> 00:18.2 0600: 1022:15ea
> 00:18.3 0600: 1022:15eb
> 00:18.4 0600: 1022:15ec
> 00:18.5 0600: 1022:15ed
> 00:18.6 0600: 1022:15ee
> 00:18.7 0600: 1022:15ef
> 01:00.0 0604: 12d8:2304 (rev 05)
> 02:01.0 0604: 12d8:2304 (rev 05)
> 02:02.0 0604: 12d8:2304 (rev 05)
> 03:00.0 0400: 14f1:8880 (rev 04)
> 04:00.0 0400: 14f1:8880 (rev 04)
> 05:00.0 0604: 1022:57ad
> 06:02.0 0604: 1022:57a3
> 06:04.0 0604: 1022:57a3
> 06:08.0 0604: 1022:57a4
> 06:09.0 0604: 1022:57a4
> 06:0a.0 0604: 1022:57a4
> 07:00.0 0280: 8086:2723 (rev 1a)
> 08:00.0 0200: 8086:1539 (rev 03)
> 09:00.0 1300: 1022:1485
> 09:00.1 0c03: 1022:149c
> 09:00.3 0c03: 1022:149c
> 0a:00.0 0106: 1022:7901 (rev 51)
> 0b:00.0 0106: 1022:7901 (rev 51)
> 0c:00.0 0108: 144d:a808
> 0d:00.0 0300: 1002:15d8 (rev c8)
> 0d:00.1 0403: 1002:15de
> 0d:00.2 1080: 1022:15df
> 0d:00.3 0c03: 1022:15e0
> 0d:00.4 0c03: 1022:15e1
> 0d:00.6 0403: 1022:15e3
> 0e:00.0 0106: 1022:7901 (rev 61)

Thanks.

I'm afraid that I should have asked for: lspci -v

That would be helpful, thanks.


Sean

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

[Rolf Pedersen]

[-- Attachment #1: Type: text/plain, Size: 3772 bytes --]

Okie-doke

On 04/23/2020 08:59 AM, Sean Young wrote:
> Hi,
>
> On Thu, Apr 23, 2020 at 08:49:17AM -0700, Rolf Pedersen wrote:
>> Hi,
>>
>> On 04/23/2020 08:35 AM, Sean Young wrote:
>>> Hi,
>>>
>>> On Thu, Apr 23, 2020 at 05:32:32AM -0700, Rolf Pedersen wrote:
>>>> Hi Folks,
>>>> I just subscribed after having trouble with this card that worked for 3
>>>> years on Skylake i5-6500 but stopped tuning when I moved it to AMD Ryzen 5
>>>> 3400G machine.  I found the workaround in the archived thread referenced in
>>>> the subject line and don't know any way to reply directly to it:
>>>> https://www.spinics.net/lists/linux-media/msg114563.html
>>>>
>>>> My card is ATSC as on this page:
>>>> https://www.kernel.org/doc/html/v4.10/media/v4l-drivers/cx23885-cardlist.html
>>>> 57     Hauppauge WinTV-QuadHD-ATSC     0070:6a18, 0070:6b18
>>>>
>>>> and
>>>>
>>>> [rolf@x570i coup]$ lspcidrake -v | grep Conexant
>>>> cx23885         : Conexant Systems, Inc.|CX23887/8 PCIe Broadcast Audio and
>>>> Video Decoder with 3D Comb [MULTIMEDIA_VIDEO] (vendor:14f1 device:8880
>>>> subv:0070 subd:6b18) (rev: 04)
>>>> cx23885         : Conexant Systems, Inc.|CX23887/8 PCIe Broadcast Audio and
>>>> Video Decoder with 3D Comb [MULTIMEDIA_VIDEO] (vendor:14f1 device:8880
>>>> subv:0070 subd:6a18) (rev: 04)
>>>>
>>>> Neither scan, dvbscan, nor w_scan2, nor Kaffeine TV, while finding working
>>>> frequencies, could divulge any services.  The workaround was in the
>>>> referenced post:  cx23885.debug=8
>>>>
>>>> I've seen another report of a different kernel option that worked on Ryzen:
>>>> |cx23885.dma_reset_workaround=2 here:
>>>> https://www.dslreports.com/forum/r32639318-SFF-3400G-build#32640298
>>>>
>>>> Ok.  Just wanted to join the chorus with a *metoo* in case I can provide
>>>> some (guided) forensics.
>>> So there is a commit for a related issue:
>>>
>>> https://git.linuxtv.org/media_tree.git/commit/?id=4bd46aa0353e022c2401a258e93b107880a66533
>>>
>>> That is kernel v5.0 and higher. So:
>>>
>>> 1. What kernel are you using?
>>>
>>> 2. What is the full lspci -n of your machine?
>>>
>>> Thanks,
>>>
>>> Sean
>>>
>> [rolf@x570i ~]$ uname -r
>> 5.5.15-desktop-3.mga7
>> [rolf@x570i ~]$
>> [rolf@x570i ~]$
>> [rolf@x570i ~]$ lspci -n
>> 00:00.0 0600: 1022:15d0
>> 00:00.2 0806: 1022:15d1
>> 00:01.0 0600: 1022:1452
>> 00:01.1 0604: 1022:15d3
>> 00:01.2 0604: 1022:15d3
>> 00:01.6 0604: 1022:15d3
>> 00:08.0 0600: 1022:1452
>> 00:08.1 0604: 1022:15db
>> 00:08.2 0604: 1022:15dc
>> 00:14.0 0c05: 1022:790b (rev 61)
>> 00:14.3 0601: 1022:790e (rev 51)
>> 00:18.0 0600: 1022:15e8
>> 00:18.1 0600: 1022:15e9
>> 00:18.2 0600: 1022:15ea
>> 00:18.3 0600: 1022:15eb
>> 00:18.4 0600: 1022:15ec
>> 00:18.5 0600: 1022:15ed
>> 00:18.6 0600: 1022:15ee
>> 00:18.7 0600: 1022:15ef
>> 01:00.0 0604: 12d8:2304 (rev 05)
>> 02:01.0 0604: 12d8:2304 (rev 05)
>> 02:02.0 0604: 12d8:2304 (rev 05)
>> 03:00.0 0400: 14f1:8880 (rev 04)
>> 04:00.0 0400: 14f1:8880 (rev 04)
>> 05:00.0 0604: 1022:57ad
>> 06:02.0 0604: 1022:57a3
>> 06:04.0 0604: 1022:57a3
>> 06:08.0 0604: 1022:57a4
>> 06:09.0 0604: 1022:57a4
>> 06:0a.0 0604: 1022:57a4
>> 07:00.0 0280: 8086:2723 (rev 1a)
>> 08:00.0 0200: 8086:1539 (rev 03)
>> 09:00.0 1300: 1022:1485
>> 09:00.1 0c03: 1022:149c
>> 09:00.3 0c03: 1022:149c
>> 0a:00.0 0106: 1022:7901 (rev 51)
>> 0b:00.0 0106: 1022:7901 (rev 51)
>> 0c:00.0 0108: 144d:a808
>> 0d:00.0 0300: 1002:15d8 (rev c8)
>> 0d:00.1 0403: 1002:15de
>> 0d:00.2 1080: 1022:15df
>> 0d:00.3 0c03: 1022:15e0
>> 0d:00.4 0c03: 1022:15e1
>> 0d:00.6 0403: 1022:15e3
>> 0e:00.0 0106: 1022:7901 (rev 61)
> Thanks.
>
> I'm afraid that I should have asked for: lspci -v
>
> That would be helpful, thanks.
>
>
> Sean
>
Please find output of `sudo lspci -v` attached.
Thanks,
Rolf


[-- Attachment #2: sudo.lspci-v.txt --]
[-- Type: text/plain, Size: 27235 bytes --]

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex
	Subsystem: ASUSTeK Computer Inc. Device 876b
	Flags: fast devsel

00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU
	Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU
	Flags: bus master, fast devsel, latency 0, IRQ 26
	Capabilities: [40] Secure device <?>
	Capabilities: [64] MSI: Enable+ Count=1/4 Maskable- 64bit+
	Capabilities: [74] HyperTransport: MSI Mapping Enable+ Fixed+

00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge
	Flags: fast devsel

00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 27
	Bus: primary=00, secondary=01, subordinate=04, sec-latency=0
	I/O behind bridge: None
	Memory behind bridge: fc000000-fc3fffff [size=4M]
	Prefetchable memory behind bridge: None
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Root Port (Slot+), MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [c0] Subsystem: ASUSTeK Computer Inc. Device 876b
	Capabilities: [c8] HyperTransport: MSI Mapping Enable+ Fixed+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [150] Advanced Error Reporting
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [2a0] Access Control Services
	Capabilities: [370] L1 PM Substates
	Capabilities: [3c4] Designated Vendor-Specific <?>
	Kernel driver in use: pcieport

00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 28
	Bus: primary=00, secondary=05, subordinate=0b, sec-latency=0
	I/O behind bridge: 0000f000-0000ffff [size=4K]
	Memory behind bridge: fc400000-fc9fffff [size=6M]
	Prefetchable memory behind bridge: None
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Root Port (Slot+), MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [c0] Subsystem: ASUSTeK Computer Inc. Device 876b
	Capabilities: [c8] HyperTransport: MSI Mapping Enable+ Fixed+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [150] Advanced Error Reporting
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [2a0] Access Control Services
	Capabilities: [370] L1 PM Substates
	Capabilities: [3c4] Designated Vendor-Specific <?>
	Kernel driver in use: pcieport

00:01.6 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP Bridge [6:0] (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 29
	Bus: primary=00, secondary=0c, subordinate=0c, sec-latency=0
	I/O behind bridge: None
	Memory behind bridge: fcf00000-fcffffff [size=1M]
	Prefetchable memory behind bridge: None
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Root Port (Slot+), MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [c0] Subsystem: ASUSTeK Computer Inc. Device 876b
	Capabilities: [c8] HyperTransport: MSI Mapping Enable+ Fixed+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [150] Advanced Error Reporting
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [2a0] Access Control Services
	Capabilities: [370] L1 PM Substates
	Capabilities: [3c4] Designated Vendor-Specific <?>
	Kernel driver in use: pcieport

00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge
	Flags: fast devsel

00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus A (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 30
	Bus: primary=00, secondary=0d, subordinate=0d, sec-latency=0
	I/O behind bridge: 0000e000-0000efff [size=4K]
	Memory behind bridge: fca00000-fcdfffff [size=4M]
	Prefetchable memory behind bridge: 00000000e0000000-00000000f01fffff [size=258M]
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Root Port (Slot-), MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [c0] Subsystem: ASUSTeK Computer Inc. Device 876b
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [2a0] Access Control Services
	Kernel driver in use: pcieport

00:08.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus B (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 31
	Bus: primary=00, secondary=0e, subordinate=0e, sec-latency=0
	I/O behind bridge: None
	Memory behind bridge: fce00000-fcefffff [size=1M]
	Prefetchable memory behind bridge: None
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Root Port (Slot-), MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [c0] Subsystem: ASUSTeK Computer Inc. Device 876b
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [150] Advanced Error Reporting
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [2a0] Access Control Services
	Kernel driver in use: pcieport

00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
	Subsystem: ASUSTeK Computer Inc. Device 876b
	Flags: 66MHz, medium devsel
	Kernel driver in use: piix4_smbus
	Kernel modules: i2c_piix4, sp5100_tco

00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
	Subsystem: ASUSTeK Computer Inc. Device 876b
	Flags: bus master, 66MHz, medium devsel, latency 0

00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 0
	Flags: fast devsel

00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 1
	Flags: fast devsel

00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 2
	Flags: fast devsel

00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 3
	Flags: fast devsel
	Kernel driver in use: k10temp
	Kernel modules: k10temp

00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 4
	Flags: fast devsel

00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 5
	Flags: fast devsel

00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 6
	Flags: fast devsel

00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Device 24: Function 7
	Flags: fast devsel

01:00.0 PCI bridge: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 3-Port/4-Lane Packet Switch (rev 05) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=01, secondary=02, subordinate=04, sec-latency=0
	I/O behind bridge: None
	Memory behind bridge: fc000000-fc3fffff [size=4M]
	Prefetchable memory behind bridge: None
	Capabilities: [40] Power Management version 3
	Capabilities: [5c] Vital Product Data
	Capabilities: [64] Vendor Specific Information: Len=34 <?>
	Capabilities: [b0] Subsystem: Device 0000:0000
	Capabilities: [c0] Express Upstream Port, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel
	Capabilities: [20c] Power Budgeting <?>
	Capabilities: [230] Latency Tolerance Reporting

02:01.0 PCI bridge: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 3-Port/4-Lane Packet Switch (rev 05) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 32
	Bus: primary=02, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: None
	Memory behind bridge: fc200000-fc3fffff [size=2M]
	Prefetchable memory behind bridge: None
	Capabilities: [40] Power Management version 3
	Capabilities: [4c] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [64] Vendor Specific Information: Len=34 <?>
	Capabilities: [b0] Subsystem: Device 0000:0000
	Capabilities: [c0] Express Downstream Port (Slot+), MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel
	Capabilities: [20c] Power Budgeting <?>
	Capabilities: [220] Access Control Services
	Kernel driver in use: pcieport

02:02.0 PCI bridge: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 3-Port/4-Lane Packet Switch (rev 05) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 33
	Bus: primary=02, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: None
	Memory behind bridge: fc000000-fc1fffff [size=2M]
	Prefetchable memory behind bridge: None
	Capabilities: [40] Power Management version 3
	Capabilities: [4c] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [64] Vendor Specific Information: Len=34 <?>
	Capabilities: [b0] Subsystem: Device 0000:0000
	Capabilities: [c0] Express Downstream Port (Slot+), MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel
	Capabilities: [20c] Power Budgeting <?>
	Capabilities: [220] Access Control Services
	Kernel driver in use: pcieport

03:00.0 Multimedia video controller: Conexant Systems, Inc. CX23887/8 PCIe Broadcast Audio and Video Decoder with 3D Comb (rev 04)
	Subsystem: Hauppauge computer works Inc. WinTV-quadHD
	Flags: bus master, fast devsel, latency 0, IRQ 137
	Memory at fc200000 (64-bit, non-prefetchable) [size=2M]
	Capabilities: [40] Express Endpoint, MSI 00
	Capabilities: [80] Power Management version 3
	Capabilities: [90] Vital Product Data
	Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [200] Virtual Channel
	Kernel driver in use: cx23885
	Kernel modules: cx23885

04:00.0 Multimedia video controller: Conexant Systems, Inc. CX23887/8 PCIe Broadcast Audio and Video Decoder with 3D Comb (rev 04)
	Subsystem: Hauppauge computer works Inc. Device 6b18
	Flags: bus master, fast devsel, latency 0, IRQ 156
	Memory at fc000000 (64-bit, non-prefetchable) [size=2M]
	Capabilities: [40] Express Endpoint, MSI 00
	Capabilities: [80] Power Management version 3
	Capabilities: [90] Vital Product Data
	Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [200] Virtual Channel
	Kernel driver in use: cx23885
	Kernel modules: cx23885

05:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57ad (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 24
	Bus: primary=05, secondary=06, subordinate=0b, sec-latency=0
	I/O behind bridge: 0000f000-0000ffff [size=4K]
	Memory behind bridge: fc400000-fc9fffff [size=6M]
	Prefetchable memory behind bridge: None
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Upstream Port, MSI 00
	Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [370] L1 PM Substates
	Capabilities: [400] Data Link Feature <?>
	Capabilities: [410] Physical Layer 16.0 GT/s <?>
	Capabilities: [440] Lane Margining at the Receiver <?>
	Kernel driver in use: pcieport

06:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3 (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 34
	Bus: primary=06, secondary=07, subordinate=07, sec-latency=0
	I/O behind bridge: None
	Memory behind bridge: fc900000-fc9fffff [size=1M]
	Prefetchable memory behind bridge: None
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Downstream Port (Slot+), MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [c0] Subsystem: ASUSTeK Computer Inc. Device 876b
	Capabilities: [c8] HyperTransport: MSI Mapping Enable+ Fixed+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [150] Advanced Error Reporting
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [2a0] Access Control Services
	Capabilities: [370] L1 PM Substates
	Capabilities: [400] Data Link Feature <?>
	Capabilities: [410] Physical Layer 16.0 GT/s <?>
	Capabilities: [440] Lane Margining at the Receiver <?>
	Kernel driver in use: pcieport

06:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a3 (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 35
	Bus: primary=06, secondary=08, subordinate=08, sec-latency=0
	I/O behind bridge: 0000f000-0000ffff [size=4K]
	Memory behind bridge: fc800000-fc8fffff [size=1M]
	Prefetchable memory behind bridge: None
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Downstream Port (Slot+), MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [c0] Subsystem: ASUSTeK Computer Inc. Device 876b
	Capabilities: [c8] HyperTransport: MSI Mapping Enable+ Fixed+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [150] Advanced Error Reporting
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [2a0] Access Control Services
	Capabilities: [370] L1 PM Substates
	Capabilities: [400] Data Link Feature <?>
	Capabilities: [410] Physical Layer 16.0 GT/s <?>
	Capabilities: [440] Lane Margining at the Receiver <?>
	Kernel driver in use: pcieport

06:08.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a4 (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 36
	Bus: primary=06, secondary=09, subordinate=09, sec-latency=0
	I/O behind bridge: None
	Memory behind bridge: fc400000-fc5fffff [size=2M]
	Prefetchable memory behind bridge: None
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Downstream Port (Slot-), MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [c0] Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1484
	Capabilities: [c8] HyperTransport: MSI Mapping Enable+ Fixed+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [400] Data Link Feature <?>
	Capabilities: [410] Physical Layer 16.0 GT/s <?>
	Capabilities: [440] Lane Margining at the Receiver <?>
	Kernel driver in use: pcieport

06:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a4 (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 38
	Bus: primary=06, secondary=0a, subordinate=0a, sec-latency=0
	I/O behind bridge: None
	Memory behind bridge: fc700000-fc7fffff [size=1M]
	Prefetchable memory behind bridge: None
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Downstream Port (Slot-), MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [c0] Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1484
	Capabilities: [c8] HyperTransport: MSI Mapping Enable+ Fixed+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [400] Data Link Feature <?>
	Capabilities: [410] Physical Layer 16.0 GT/s <?>
	Capabilities: [440] Lane Margining at the Receiver <?>
	Kernel driver in use: pcieport

06:0a.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 57a4 (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0, IRQ 40
	Bus: primary=06, secondary=0b, subordinate=0b, sec-latency=0
	I/O behind bridge: None
	Memory behind bridge: fc600000-fc6fffff [size=1M]
	Prefetchable memory behind bridge: None
	Capabilities: [50] Power Management version 3
	Capabilities: [58] Express Downstream Port (Slot-), MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [c0] Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1484
	Capabilities: [c8] HyperTransport: MSI Mapping Enable+ Fixed+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [400] Data Link Feature <?>
	Capabilities: [410] Physical Layer 16.0 GT/s <?>
	Capabilities: [440] Lane Margining at the Receiver <?>
	Kernel driver in use: pcieport

07:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
	Subsystem: Intel Corporation Device 0084
	Flags: bus master, fast devsel, latency 0, IRQ 39
	Memory at fc900000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [c8] Power Management version 3
	Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
	Capabilities: [40] Express Endpoint, MSI 00
	Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [14c] Latency Tolerance Reporting
	Capabilities: [154] L1 PM Substates
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

08:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
	Subsystem: ASUSTeK Computer Inc. Device 85f0
	Flags: bus master, fast devsel, latency 0, IRQ 24
	Memory at fc800000 (32-bit, non-prefetchable) [size=128K]
	I/O ports at f000 [size=32]
	Memory at fc820000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
	Capabilities: [70] MSI-X: Enable+ Count=5 Masked-
	Capabilities: [a0] Express Endpoint, MSI 00
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Device Serial Number d4-5d-64-ff-ff-51-25-e0
	Capabilities: [1a0] Transaction Processing Hints
	Kernel driver in use: igb
	Kernel modules: igb

09:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
	Subsystem: ASUSTeK Computer Inc. Device 876b
	Flags: fast devsel
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Endpoint, MSI 00
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [400] Data Link Feature <?>
	Capabilities: [410] Physical Layer 16.0 GT/s <?>
	Capabilities: [440] Lane Margining at the Receiver <?>

09:00.1 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller (prog-if 30 [XHCI])
	Subsystem: ASUSTeK Computer Inc. Device 876b
	Flags: bus master, fast devsel, latency 0, IRQ 111
	Memory at fc500000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

09:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller (prog-if 30 [XHCI])
	Subsystem: Advanced Micro Devices, Inc. [AMD] Device 148c
	Flags: bus master, fast devsel, latency 0, IRQ 39
	Memory at fc400000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable- Count=1/8 Maskable- 64bit+
	Capabilities: [c0] MSI-X: Enable+ Count=8 Masked-
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

0a:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) (prog-if 01 [AHCI 1.0])
	Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode]
	Flags: bus master, fast devsel, latency 0, IRQ 43
	Memory at fc700000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable+ Count=16/16 Maskable- 64bit+
	Capabilities: [d0] SATA HBA v1.0
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [400] Data Link Feature <?>
	Capabilities: [410] Physical Layer 16.0 GT/s <?>
	Capabilities: [440] Lane Margining at the Receiver <?>
	Kernel driver in use: ahci

0b:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) (prog-if 01 [AHCI 1.0])
	Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode]
	Flags: bus master, fast devsel, latency 0, IRQ 59
	Memory at fc600000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable+ Count=16/16 Maskable- 64bit+
	Capabilities: [d0] SATA HBA v1.0
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [400] Data Link Feature <?>
	Capabilities: [410] Physical Layer 16.0 GT/s <?>
	Capabilities: [440] Lane Margining at the Receiver <?>
	Kernel driver in use: ahci

0c:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 (prog-if 02 [NVM Express])
	Subsystem: Samsung Electronics Co Ltd Device a801
	Flags: bus master, fast devsel, latency 0, IRQ 41, NUMA node 0
	Memory at fcf00000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
	Capabilities: [70] Express Endpoint, MSI 00
	Capabilities: [b0] MSI-X: Enable+ Count=33 Masked-
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [148] Device Serial Number 00-00-00-00-00-00-00-00
	Capabilities: [158] Power Budgeting <?>
	Capabilities: [168] Secondary PCI Express <?>
	Capabilities: [188] Latency Tolerance Reporting
	Capabilities: [190] L1 PM Substates
	Kernel driver in use: nvme

0d:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Picasso (rev c8) (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. Device 876b
	Flags: bus master, fast devsel, latency 0, IRQ 109
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Memory at f0000000 (64-bit, prefetchable) [size=2M]
	I/O ports at e000 [size=256]
	Memory at fcd00000 (32-bit, non-prefetchable) [size=512K]
	[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Legacy Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable- Count=1/4 Maskable- 64bit+
	Capabilities: [c0] MSI-X: Enable+ Count=3 Masked-
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [200] Resizable BAR <?>
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [2a0] Access Control Services
	Capabilities: [2b0] Address Translation Service (ATS)
	Capabilities: [2c0] Page Request Interface (PRI)
	Capabilities: [2d0] Process Address Space ID (PASID)
	Capabilities: [320] Latency Tolerance Reporting
	Kernel driver in use: amdgpu
	Kernel modules: amdgpu

0d:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Raven/Raven2/Fenghuang HDMI/DP Audio Controller
	Subsystem: ASUSTeK Computer Inc. Device 876b
	Flags: bus master, fast devsel, latency 0, IRQ 139
	Memory at fcd88000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Legacy Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

0d:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) Platform Security Processor
	Subsystem: ASUSTeK Computer Inc. Device 876b
	Flags: bus master, fast devsel, latency 0, IRQ 5
	Memory at fcc00000 (32-bit, non-prefetchable) [size=1M]
	Memory at fcd8c000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable- Count=1/2 Maskable- 64bit+
	Capabilities: [c0] MSI-X: Enable- Count=2 Masked-
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>

0d:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1 (prog-if 30 [XHCI])
	Subsystem: ASUSTeK Computer Inc. Device 876b
	Flags: bus master, fast devsel, latency 0, IRQ 120
	Memory at fcb00000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable- Count=1/8 Maskable- 64bit+
	Capabilities: [c0] MSI-X: Enable+ Count=8 Masked-
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

0d:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1 (prog-if 30 [XHCI])
	Subsystem: ASUSTeK Computer Inc. Device 876b
	Flags: bus master, fast devsel, latency 0, IRQ 109
	Memory at fca00000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable- Count=1/8 Maskable- 64bit+
	Capabilities: [c0] MSI-X: Enable+ Count=8 Masked-
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Kernel driver in use: xhci_hcd
	Kernel modules: xhci_pci

0d:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller
	Subsystem: ASUSTeK Computer Inc. Device 87c6
	Flags: bus master, fast devsel, latency 0, IRQ 140
	Memory at fcd80000 (32-bit, non-prefetchable) [size=32K]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

0e:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 61) (prog-if 01 [AHCI 1.0])
	Subsystem: ASUSTeK Computer Inc. Device 876b
	Flags: bus master, fast devsel, latency 0, IRQ 76
	Memory at fce00000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: [48] Vendor Specific Information: Len=08 <?>
	Capabilities: [50] Power Management version 3
	Capabilities: [64] Express Endpoint, MSI 00
	Capabilities: [a0] MSI: Enable+ Count=1/2 Maskable- 64bit+
	Capabilities: [d0] SATA HBA v1.0
	Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
	Capabilities: [150] Advanced Error Reporting
	Capabilities: [270] Secondary PCI Express <?>
	Capabilities: [2a0] Access Control Services
	Kernel driver in use: ahci

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

[Sean Young]

Hi,

On Thu, Apr 23, 2020 at 09:09:35AM -0700, Rolf Pedersen wrote:
> Okie-doke
> 
> On 04/23/2020 08:59 AM, Sean Young wrote:
> > Hi,
> > 
> > On Thu, Apr 23, 2020 at 08:49:17AM -0700, Rolf Pedersen wrote:
> > > Hi,
> > > 
> > > On 04/23/2020 08:35 AM, Sean Young wrote:
> > > > Hi,
> > > > 
> > > > On Thu, Apr 23, 2020 at 05:32:32AM -0700, Rolf Pedersen wrote:
> > > > > Hi Folks,
> > > > > I just subscribed after having trouble with this card that worked for 3
> > > > > years on Skylake i5-6500 but stopped tuning when I moved it to AMD Ryzen 5
> > > > > 3400G machine.  I found the workaround in the archived thread referenced in
> > > > > the subject line and don't know any way to reply directly to it:
> > > > > https://www.spinics.net/lists/linux-media/msg114563.html
> > > > > 
> > > > > My card is ATSC as on this page:
> > > > > https://www.kernel.org/doc/html/v4.10/media/v4l-drivers/cx23885-cardlist.html
> > > > > 57     Hauppauge WinTV-QuadHD-ATSC     0070:6a18, 0070:6b18
> > > > > 
> > > > > and
> > > > > 
> > > > > [rolf@x570i coup]$ lspcidrake -v | grep Conexant
> > > > > cx23885         : Conexant Systems, Inc.|CX23887/8 PCIe Broadcast Audio and
> > > > > Video Decoder with 3D Comb [MULTIMEDIA_VIDEO] (vendor:14f1 device:8880
> > > > > subv:0070 subd:6b18) (rev: 04)
> > > > > cx23885         : Conexant Systems, Inc.|CX23887/8 PCIe Broadcast Audio and
> > > > > Video Decoder with 3D Comb [MULTIMEDIA_VIDEO] (vendor:14f1 device:8880
> > > > > subv:0070 subd:6a18) (rev: 04)
> > > > > 
> > > > > Neither scan, dvbscan, nor w_scan2, nor Kaffeine TV, while finding working
> > > > > frequencies, could divulge any services.  The workaround was in the
> > > > > referenced post:  cx23885.debug=8
> > > > > 
> > > > > I've seen another report of a different kernel option that worked on Ryzen:
> > > > > |cx23885.dma_reset_workaround=2 here:
> > > > > https://www.dslreports.com/forum/r32639318-SFF-3400G-build#32640298
> > > > > 
> > > > > Ok.  Just wanted to join the chorus with a *metoo* in case I can provide
> > > > > some (guided) forensics.
> > > > So there is a commit for a related issue:
> > > > 
> > > > https://git.linuxtv.org/media_tree.git/commit/?id=4bd46aa0353e022c2401a258e93b107880a66533
> > > > 
> > > > That is kernel v5.0 and higher. So:
> > > > 
> > > > 1. What kernel are you using?
> > > > 
> > > > 2. What is the full lspci -n of your machine?
> > > > 
> > > > Thanks,
> > > > 
> > > > Sean
> > > > 
> > > [rolf@x570i ~]$ uname -r
> > > 5.5.15-desktop-3.mga7
> > > [rolf@x570i ~]$
> > > [rolf@x570i ~]$
> > > [rolf@x570i ~]$ lspci -n
> > > 00:00.0 0600: 1022:15d0
> > > 00:00.2 0806: 1022:15d1
> > > 00:01.0 0600: 1022:1452
> > > 00:01.1 0604: 1022:15d3
> > > 00:01.2 0604: 1022:15d3
> > > 00:01.6 0604: 1022:15d3
> > > 00:08.0 0600: 1022:1452
> > > 00:08.1 0604: 1022:15db
> > > 00:08.2 0604: 1022:15dc
> > > 00:14.0 0c05: 1022:790b (rev 61)
> > > 00:14.3 0601: 1022:790e (rev 51)
> > > 00:18.0 0600: 1022:15e8
> > > 00:18.1 0600: 1022:15e9
> > > 00:18.2 0600: 1022:15ea
> > > 00:18.3 0600: 1022:15eb
> > > 00:18.4 0600: 1022:15ec
> > > 00:18.5 0600: 1022:15ed
> > > 00:18.6 0600: 1022:15ee
> > > 00:18.7 0600: 1022:15ef
> > > 01:00.0 0604: 12d8:2304 (rev 05)
> > > 02:01.0 0604: 12d8:2304 (rev 05)
> > > 02:02.0 0604: 12d8:2304 (rev 05)
> > > 03:00.0 0400: 14f1:8880 (rev 04)
> > > 04:00.0 0400: 14f1:8880 (rev 04)
> > > 05:00.0 0604: 1022:57ad
> > > 06:02.0 0604: 1022:57a3
> > > 06:04.0 0604: 1022:57a3
> > > 06:08.0 0604: 1022:57a4
> > > 06:09.0 0604: 1022:57a4
> > > 06:0a.0 0604: 1022:57a4
> > > 07:00.0 0280: 8086:2723 (rev 1a)
> > > 08:00.0 0200: 8086:1539 (rev 03)
> > > 09:00.0 1300: 1022:1485
> > > 09:00.1 0c03: 1022:149c
> > > 09:00.3 0c03: 1022:149c
> > > 0a:00.0 0106: 1022:7901 (rev 51)
> > > 0b:00.0 0106: 1022:7901 (rev 51)
> > > 0c:00.0 0108: 144d:a808
> > > 0d:00.0 0300: 1002:15d8 (rev c8)
> > > 0d:00.1 0403: 1002:15de
> > > 0d:00.2 1080: 1022:15df
> > > 0d:00.3 0c03: 1022:15e0
> > > 0d:00.4 0c03: 1022:15e1
> > > 0d:00.6 0403: 1022:15e3
> > > 0e:00.0 0106: 1022:7901 (rev 61)
> > Thanks.
> > 
> > I'm afraid that I should have asked for: lspci -v
> > 
> > That would be helpful, thanks.
> > 
> > 
> > Sean
> > 
> Please find output of `sudo lspci -v` attached.
> Thanks,
> Rolf
> 

> 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex
> 	Subsystem: ASUSTeK Computer Inc. Device 876b
> 	Flags: fast devsel
> 
> 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU
> 	Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU
> 	Flags: bus master, fast devsel, latency 0, IRQ 26
> 	Capabilities: [40] Secure device <?>
> 	Capabilities: [64] MSI: Enable+ Count=1/4 Maskable- 64bit+
> 	Capabilities: [74] HyperTransport: MSI Mapping Enable+ Fixed+

Can you please try this patch and let us know if it works:

From c761fe49e66236b7e459d9f501ed20fd401181b8 Mon Sep 17 00:00:00 2001
From: Sean Young <sean@mess.org>
Date: Thu, 23 Apr 2020 17:28:09 +0100
Subject: [PATCH] media: cx23885: add a missing vid for another problematic AMD
 IOMMU

The issue described in commit 95f408bbc4e4 ("media: cx23885: Ryzen DMA
related RiSC engine stall fixes") also affects this device.

Fixes: 95f408bbc4e4 ("media: cx23885: Ryzen DMA related RiSC engine stall fixes")

Cc: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
---
 drivers/media/pci/cx23885/cx23885-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/pci/cx23885/cx23885-core.c b/drivers/media/pci/cx23885/cx23885-core.c
index 7e0b0b7cc2a3..1ed3b76de2fa 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -2074,6 +2074,7 @@ static struct {
 	 * 0x1451 is PCI ID for the IOMMU found on Ryzen
 	 */
 	{ PCI_VENDOR_ID_AMD, 0x1451 },
+	{ PCI_VENDOR_ID_AMD, 0x15d1 }, /* Raven2 IOMMU */
 };
 
 static bool cx23885_does_need_dma_reset(void)
-- 
2.25.3

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

[Martin Burnicki]

Hi,

I came across this thread and want to let you know that I also have
problems with the cx23885 driver on a Ryzen system.

The only solution I found on the 'net that could make it work was to add
a line

options cx23885 debug=7

to the file /etc/modprobe.d/cx23885.conf

However, this causes a *huge* number of debug messages, so I also run
the command

rm -f /var/log/kern.log*

in a daily cronjob. This works stable here for some months now.

With lower debug levels the problem occurred less often, but it still
occurred. Only with debug level 7 (at least) the driver runs stable over
time here.

In case somebody is interested in details of the systemI'm running here:
https://burnicki.net/public_html/martin/tmp/system-etails.txt

The commit messages mentioned earlier in this thread are already pretty
old (from ~2018 or so), and I'm running kernel 5.3 on my Ubuntu system,
so I guess those commits are already in there, but the problem still occurs.


I'm not familiar with the video stuff, with the cx23885 driver, etc.,
but I'm maintaining another kernel driver for different PCI cards and
encountered similar problems as the cx23885 driver.

The symptoms were that the driver worked stable for many years on all
systems, but suddenly failed to work properly on systems with very new
chips sets and/or CPUs (not only AMD Ryzen).

It turned out that the problem was due to missing barriers when
accessing memory mapped registers.

In my original driver code (written many years ago) the driver accessed
the memory mapped registers directly

val = *mem_addr
*mem_addr = val

which worked without problems for a long time, so it looks like older
CPUs/chipsets didn't do reordering which would have been inhibited by
barriers.

As said above, with recent versions of CPUs/chipsets this seems indeed
to happen, but since I changed the driver code so that all access to
memory mapped registers uses the specific kernel inline functions (which
use barriers, AFAIK), all problems have vanished and my driver works
fine with the latest CPUs and chipsets.

So maybe somewhere in the cx23885 driver code a memory barrier may be
missing, and depending on whether debugging is enabled, or not, accesses
to the device are re-ordered, or not.

This is just an idea, and maybe this is not the case here, but by chance
someone who is familiar with the cx23885 code may have a look.

Martin

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

[Sean Young]

Hi,

On Fri, Apr 24, 2020 at 07:46:26PM +0200, Martin Burnicki wrote:
> I came across this thread and want to let you know that I also have
> problems with the cx23885 driver on a Ryzen system.
> 
> The only solution I found on the 'net that could make it work was to add
> a line
> 
> options cx23885 debug=7
> 
> to the file /etc/modprobe.d/cx23885.conf

Have you tried: 

options cx23885 dma_reset_workaround=2

?

> However, this causes a *huge* number of debug messages, so I also run
> the command
> 
> rm -f /var/log/kern.log*
> 
> in a daily cronjob. This works stable here for some months now.
> 
> With lower debug levels the problem occurred less often, but it still
> occurred. Only with debug level 7 (at least) the driver runs stable over
> time here.
> 
> In case somebody is interested in details of the systemI'm running here:
> https://burnicki.net/public_html/martin/tmp/system-etails.txt

Not found, I'm afraid.

> The commit messages mentioned earlier in this thread are already pretty
> old (from ~2018 or so), and I'm running kernel 5.3 on my Ubuntu system,
> so I guess those commits are already in there, but the problem still occurs.

Those commits check for a particular PCI PID/VIDs; newer IDs could be
missing, if they are still broken.

> I'm not familiar with the video stuff, with the cx23885 driver, etc.,
> but I'm maintaining another kernel driver for different PCI cards and
> encountered similar problems as the cx23885 driver.
> 
> The symptoms were that the driver worked stable for many years on all
> systems, but suddenly failed to work properly on systems with very new
> chips sets and/or CPUs (not only AMD Ryzen).
> 
> It turned out that the problem was due to missing barriers when
> accessing memory mapped registers.
> 
> In my original driver code (written many years ago) the driver accessed
> the memory mapped registers directly
> 
> val = *mem_addr
> *mem_addr = val
> 
> which worked without problems for a long time, so it looks like older
> CPUs/chipsets didn't do reordering which would have been inhibited by
> barriers.
> 
> As said above, with recent versions of CPUs/chipsets this seems indeed
> to happen, but since I changed the driver code so that all access to
> memory mapped registers uses the specific kernel inline functions (which
> use barriers, AFAIK), all problems have vanished and my driver works
> fine with the latest CPUs and chipsets.
> 
> So maybe somewhere in the cx23885 driver code a memory barrier may be
> missing, and depending on whether debugging is enabled, or not, accesses
> to the device are re-ordered, or not.
> 
> This is just an idea, and maybe this is not the case here, but by chance
> someone who is familiar with the cx23885 code may have a look.

That does seem possible.

Actually I think it would be very useful if you could try and track down
this issue, by replacing the various lines that do some debug action
with a memory barrier or nothing. That would tell where the problem is.

Unless anyone has better ideas, of course.

Thanks,

Sean

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

[Martin Burnicki]

Sean Young wrote:
> On Fri, Apr 24, 2020 at 07:46:26PM +0200, Martin Burnicki wrote:
>> I came across this thread and want to let you know that I also have
>> problems with the cx23885 driver on a Ryzen system.
>>
>> The only solution I found on the 'net that could make it work was to add
>> a line
>>
>> options cx23885 debug=7
>>
>> to the file /etc/modprobe.d/cx23885.conf
> 
> Have you tried: 
> 
> options cx23885 dma_reset_workaround=2

I think I remember I originally tried this when I set up this system,
and it didn't work, but that may not have been with a value of 2.

So I'm going to try this once more.

>> In case somebody is interested in details of the systemI'm running here:
>> https://burnicki.net/public_html/martin/tmp/system-etails.txt
> 
> Not found, I'm afraid.

Oops, that should have been

https://burnicki.net/martin/tmp/system-details.txt

Sorry!

>> The commit messages mentioned earlier in this thread are already pretty
>> old (from ~2018 or so), and I'm running kernel 5.3 on my Ubuntu system,
>> so I guess those commits are already in there, but the problem still occurs.
> 
> Those commits check for a particular PCI PID/VIDs; newer IDs could be
> missing, if they are still broken.

OK, yet I haven't checked if the IDs of my device are in the list that
is checked.

However, I'm basically wondering if there's indeed just a barrier
missing in the general code, which would make the specific workaround
obsolete.

>> I'm not familiar with the video stuff, with the cx23885 driver, etc.,
>> but I'm maintaining another kernel driver for different PCI cards and
>> encountered similar problems as the cx23885 driver.
>>
>> The symptoms were that the driver worked stable for many years on all
>> systems, but suddenly failed to work properly on systems with very new
>> chips sets and/or CPUs (not only AMD Ryzen).
>>
>> It turned out that the problem was due to missing barriers when
>> accessing memory mapped registers.
>>
>> In my original driver code (written many years ago) the driver accessed
>> the memory mapped registers directly
>>
>> val = *mem_addr
>> *mem_addr = val
>>
>> which worked without problems for a long time, so it looks like older
>> CPUs/chipsets didn't do reordering which would have been inhibited by
>> barriers.
>>
>> As said above, with recent versions of CPUs/chipsets this seems indeed
>> to happen, but since I changed the driver code so that all access to
>> memory mapped registers uses the specific kernel inline functions (which
>> use barriers, AFAIK), all problems have vanished and my driver works
>> fine with the latest CPUs and chipsets.
>>
>> So maybe somewhere in the cx23885 driver code a memory barrier may be
>> missing, and depending on whether debugging is enabled, or not, accesses
>> to the device are re-ordered, or not.
>>
>> This is just an idea, and maybe this is not the case here, but by chance
>> someone who is familiar with the cx23885 code may have a look.
> 
> That does seem possible.
> 
> Actually I think it would be very useful if you could try and track down
> this issue, by replacing the various lines that do some debug action
> with a memory barrier or nothing. That would tell where the problem is.

Will do, and will let you know as soon as possible.

Thanks,

Martin

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

[Martin Burnicki]

Hi,

Martin Burnicki wrote:
> Sean Young wrote:
>> On Fri, Apr 24, 2020 at 07:46:26PM +0200, Martin Burnicki wrote:
>>> I came across this thread and want to let you know that I also have
>>> problems with the cx23885 driver on a Ryzen system.
>>>
>>> The only solution I found on the 'net that could make it work was to add
>>> a line
>>>
>>> options cx23885 debug=7
>>>
>>> to the file /etc/modprobe.d/cx23885.conf
>>
>> Have you tried: 
>>
>> options cx23885 dma_reset_workaround=2
> 
> I think I remember I originally tried this when I set up this system,
> and it didn't work, but that may not have been with a value of 2.

I've tried this now once more on my Ubuntu system with 5.3.0-46-generic,
and indeed the workaround fixes the problem.

In case you are interested, here is the full dmesg output of the system
when the error occurs if *no* workaround is enabled:

https://burnicki.net/martin/tmp/dmesg-with-error.txt

See the "mpeg risc op code error" message close to the bottom of the file.


Thanks,

Martin

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

[Sean Young]

On Mon, Apr 27, 2020 at 09:03:22AM +0200, Martin Burnicki wrote:
> Martin Burnicki wrote:
> > Sean Young wrote:
> >> On Fri, Apr 24, 2020 at 07:46:26PM +0200, Martin Burnicki wrote:
> >>> I came across this thread and want to let you know that I also have
> >>> problems with the cx23885 driver on a Ryzen system.
> >>>
> >>> The only solution I found on the 'net that could make it work was to add
> >>> a line
> >>>
> >>> options cx23885 debug=7
> >>>
> >>> to the file /etc/modprobe.d/cx23885.conf
> >>
> >> Have you tried: 
> >>
> >> options cx23885 dma_reset_workaround=2
> > 
> > I think I remember I originally tried this when I set up this system,
> > and it didn't work, but that may not have been with a value of 2.
> 
> I've tried this now once more on my Ubuntu system with 5.3.0-46-generic,
> and indeed the workaround fixes the problem.
> 
> In case you are interested, here is the full dmesg output of the system
> when the error occurs if *no* workaround is enabled:
> 
> https://burnicki.net/martin/tmp/dmesg-with-error.txt
> 
> See the "mpeg risc op code error" message close to the bottom of the file.

Would you mind testing this patch please?

Thanks

Sean

From 216bd7f1a68de7a60bfa15a31f28343574bae313 Mon Sep 17 00:00:00 2001
From: Sean Young <sean@mess.org>
Date: Thu, 23 Apr 2020 17:28:09 +0100
Subject: [PATCH] media: cx23885: add a missing vid for other problematic AMD
 IOMMOs

The issue described in commit 95f408bbc4e4 ("media: cx23885: Ryzen DMA
related RiSC engine stall fixes") also affects this device.

Fixes: 95f408bbc4e4 ("media: cx23885: Ryzen DMA related RiSC engine stall fixes")

Cc: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
---
 drivers/media/pci/cx23885/cx23885-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/pci/cx23885/cx23885-core.c b/drivers/media/pci/cx23885/cx23885-core.c
index 7e0b0b7cc2a3..f18c5017be84 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -2074,6 +2074,8 @@ static struct {
 	 * 0x1451 is PCI ID for the IOMMU found on Ryzen
 	 */
 	{ PCI_VENDOR_ID_AMD, 0x1451 },
+	{ PCI_VENDOR_ID_AMD, 0x1481 },
+	{ PCI_VENDOR_ID_AMD, 0x15d1 }, /* Raven2 IOMMU */
 };
 
 static bool cx23885_does_need_dma_reset(void)
-- 
2.25.4

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

[Martin Burnicki]

Sean Young wrote:
> Would you mind testing this patch please?

I'm going to try it this evening.

I'll have to find out how to do an out-of-tree build for a copy of the
cx module that includes the patch.

My own kernel driver is always and only built out-of-tree, but for the
cx driver I need to see which files I need to copy to a local directory,
and if there is anything else that needs to be done to build a copy of
it out-of-tree.

Martin

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

[Martin Burnicki]

Hi,

Am 27.04.20 um 10:59 schrieb Martin Burnicki:
> Sean Young wrote:
>> Would you mind testing this patch please?
> 
> I'm going to try it this evening.
> 
> I'll have to find out how to do an out-of-tree build for a copy of the
> cx module that includes the patch.
> 
> My own kernel driver is always and only built out-of-tree, but for the
> cx driver I need to see which files I need to copy to a local directory,
> and if there is anything else that needs to be done to build a copy of
> it out-of-tree.

Sorry, I haven't managed to test the patch, yet.

Currently I have the driver loaded with

options cx23885 dma_reset_workaround=2

but today there were 3 occurrences of the risc opcode error:

root@pc:~# dmesg | grep risc
[166528.023263] cx23885: cx23885[0]: mpeg risc op code error
[166528.023273] cx23885: cx23885[0]:   cmds: init risc lo   : 0xff667000
[166528.023277] cx23885: cx23885[0]:   cmds: init risc hi   : 0x00000000
[166528.023293] cx23885: cx23885[0]:   cmds: risc pc lo     : 0xff667018
[166528.023296] cx23885: cx23885[0]:   cmds: risc pc hi     : 0x00000000
[166528.023319] cx23885: cx23885[0]:   risc0:
[166528.023324] cx23885: cx23885[0]:   risc1:
[166528.023330] cx23885: cx23885[0]:   risc2:
[166528.023334] cx23885: cx23885[0]:   risc3:
[180595.947077] cx23885: cx23885[0]: mpeg risc op code error
[180595.947087] cx23885: cx23885[0]:   cmds: init risc lo   : 0xfc6ee000
[180595.947090] cx23885: cx23885[0]:   cmds: init risc hi   : 0x00000000
[180595.947107] cx23885: cx23885[0]:   cmds: risc pc lo     : 0xfc6ee018
[180595.947110] cx23885: cx23885[0]:   cmds: risc pc hi     : 0x00000000
[180595.947133] cx23885: cx23885[0]:   risc0:
[180595.947138] cx23885: cx23885[0]:   risc1:
[180595.947143] cx23885: cx23885[0]:   risc2:
[180595.947147] cx23885: cx23885[0]:   risc3:
[180595.947263] cx23885: cx23885[0]: mpeg risc op code error
[180595.947270] cx23885: cx23885[0]:   cmds: init risc lo   : 0xfc6ee000
[180595.947274] cx23885: cx23885[0]:   cmds: init risc hi   : 0x00000000
[180595.947290] cx23885: cx23885[0]:   cmds: risc pc lo     : 0xfc6ee018
[180595.947293] cx23885: cx23885[0]:   cmds: risc pc hi     : 0x00000000
[180595.947315] cx23885: cx23885[0]:   risc0:
[180595.947319] cx23885: cx23885[0]:   risc1:
[180595.947324] cx23885: cx23885[0]:   risc2:
[180595.947328] cx23885: cx23885[0]:   risc3:

My wife is very happy that the recordings of the TV shows she wanted to
see later were aborted. ;-)

So the workaround doesn't seem to fix the problem anyway, and the patch
would just enable the workaround with out the specific option, right?

The effect of the workaround looks just like debug levels lower than 7,
it just seems to reduce the probability that the bug occurs, but doesn't
really fix it.

So my conclusion is still that that this smells like a missing memory
barrier or so in the driver.

Since the driver seems to work properly with older mainboards/CPU types,
this doesn't sound like a problem in the CX chip, IMO.

Martin

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

[Sean Young]

On Tue, Apr 28, 2020 at 08:24:20PM +0200, Martin Burnicki wrote:
> Hi,
> 
> Am 27.04.20 um 10:59 schrieb Martin Burnicki:
> > Sean Young wrote:
> >> Would you mind testing this patch please?
> > 
> > I'm going to try it this evening.
> > 
> > I'll have to find out how to do an out-of-tree build for a copy of the
> > cx module that includes the patch.
> > 
> > My own kernel driver is always and only built out-of-tree, but for the
> > cx driver I need to see which files I need to copy to a local directory,
> > and if there is anything else that needs to be done to build a copy of
> > it out-of-tree.
> 
> Sorry, I haven't managed to test the patch, yet.
> 
> Currently I have the driver loaded with
> 
> options cx23885 dma_reset_workaround=2
> 
> but today there were 3 occurrences of the risc opcode error:
> 
> root@pc:~# dmesg | grep risc
> [166528.023263] cx23885: cx23885[0]: mpeg risc op code error
> [166528.023273] cx23885: cx23885[0]:   cmds: init risc lo   : 0xff667000
> [166528.023277] cx23885: cx23885[0]:   cmds: init risc hi   : 0x00000000
> [166528.023293] cx23885: cx23885[0]:   cmds: risc pc lo     : 0xff667018
> [166528.023296] cx23885: cx23885[0]:   cmds: risc pc hi     : 0x00000000
> [166528.023319] cx23885: cx23885[0]:   risc0:
> [166528.023324] cx23885: cx23885[0]:   risc1:
> [166528.023330] cx23885: cx23885[0]:   risc2:
> [166528.023334] cx23885: cx23885[0]:   risc3:
> [180595.947077] cx23885: cx23885[0]: mpeg risc op code error
> [180595.947087] cx23885: cx23885[0]:   cmds: init risc lo   : 0xfc6ee000
> [180595.947090] cx23885: cx23885[0]:   cmds: init risc hi   : 0x00000000
> [180595.947107] cx23885: cx23885[0]:   cmds: risc pc lo     : 0xfc6ee018
> [180595.947110] cx23885: cx23885[0]:   cmds: risc pc hi     : 0x00000000
> [180595.947133] cx23885: cx23885[0]:   risc0:
> [180595.947138] cx23885: cx23885[0]:   risc1:
> [180595.947143] cx23885: cx23885[0]:   risc2:
> [180595.947147] cx23885: cx23885[0]:   risc3:
> [180595.947263] cx23885: cx23885[0]: mpeg risc op code error
> [180595.947270] cx23885: cx23885[0]:   cmds: init risc lo   : 0xfc6ee000
> [180595.947274] cx23885: cx23885[0]:   cmds: init risc hi   : 0x00000000
> [180595.947290] cx23885: cx23885[0]:   cmds: risc pc lo     : 0xfc6ee018
> [180595.947293] cx23885: cx23885[0]:   cmds: risc pc hi     : 0x00000000
> [180595.947315] cx23885: cx23885[0]:   risc0:
> [180595.947319] cx23885: cx23885[0]:   risc1:
> [180595.947324] cx23885: cx23885[0]:   risc2:
> [180595.947328] cx23885: cx23885[0]:   risc3:
> 
> My wife is very happy that the recordings of the TV shows she wanted to
> see later were aborted. ;-)

Drats.

> So the workaround doesn't seem to fix the problem anyway, and the patch
> would just enable the workaround with out the specific option, right?

Yes, that's right.

> The effect of the workaround looks just like debug levels lower than 7,
> it just seems to reduce the probability that the bug occurs, but doesn't
> really fix it.
> 
> So my conclusion is still that that this smells like a missing memory
> barrier or so in the driver.
> 
> Since the driver seems to work properly with older mainboards/CPU types,
> this doesn't sound like a problem in the CX chip, IMO.

I would agree with that. I would suspect same issue was being papered over
by the patch; now what that issue is, I don't know. Certainly some ordering
or barrier issue seems likely.

Actually I suspected this all along, but the workaround is the best we have.

I think, some time spent hunting down the issue would really be helpful
here. Hopefully that doesn't mean too many aborted recordings..

Thanks,

Sean

Re: HauppaugeTV-quadHD DVB-T & HVR5525 mpeg risc op code error

[Ken Smith]

Sean Young wrote:
> On Tue, Apr 28, 2020 at 08:24:20PM +0200, Martin Burnicki wrote:
>> Hi,
>>
>> Am 27.04.20 um 10:59 schrieb Martin Burnicki:
>>> Sean Young wrote:
>>>> Would you mind testing this patch please?
>>> I'm going to try it this evening.
>>>
>>> I'll have to find out how to do an out-of-tree build for a copy of the
>>> cx module that includes the patch.
>>>
>>> My own kernel driver is always and only built out-of-tree, but for the
>>> cx driver I need to see which files I need to copy to a local directory,
>>> and if there is anything else that needs to be done to build a copy of
>>> it out-of-tree.
>> Sorry, I haven't managed to test the patch, yet.
>>
>> Currently I have the driver loaded with
>>
>> options cx23885 dma_reset_workaround=2
>>
>> but today there were 3 occurrences of the risc opcode error:
>>
>>
> Drats.
>
>> So the workaround doesn't seem to fix the problem anyway, and the patch
>> would just enable the workaround with out the specific option, right?
> Yes, that's right.
>
>> The effect of the workaround looks just like debug levels lower than 7,
>> it just seems to reduce the probability that the bug occurs, but doesn't
>> really fix it.
>>
>> So my conclusion is still that that this smells like a missing memory
>> barrier or so in the driver.
>>
>> Since the driver seems to work properly with older mainboards/CPU types,
>> this doesn't sound like a problem in the CX chip, IMO.
> I would agree with that. I would suspect same issue was being papered over
> by the patch; now what that issue is, I don't know. Certainly some ordering
> or barrier issue seems likely.
>
> Actually I suspected this all along, but the workaround is the best we have.
>
> I think, some time spent hunting down the issue would really be helpful
> here. Hopefully that doesn't mean too many aborted recordings..
>
> Thanks,
>
> Sean
>

Hi, I'd like to resurrect this thread (copied below). I have a system 
showing this error. Its a HP ML350 server with 2x Xeon 5675 running 
Rocky Linux 8.5. It has a Hauppauge HVR5525 card that uses the same 
cx23885 kernel module as the quadHD card discussed above. The HVR5525 is 
a dual DVB-T2/DVB-S2 card.

In other threads I read about the dma_reset_workaround option. That 
option did not appear to be in the version included in standard kernel 
in Rocky 8.5. I have loaded a 5.4 kernel and compiled the DVB media 
modules from .git source and set dma_reset_workaround=2 in a file in 
modprobe.d. The built module shows version 0.0.4

Sadly the error remains. The system runs MythTV v.31. The main symptom 
is occasional aborted recordings. Although the card does appear to 
recover, not requiring a reboot/cold restart.

I'd appreciate some assistance with this. What information can I provide 
to help to trace this.

Many thanks

Ken

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: HauppaugeTV-quadHD DVB-T & HVR5525 mpeg risc op code error

[Martin Burnicki]

[-- Attachment #1.1: Type: text/plain, Size: 5025 bytes --]

Am 24.05.22 um 00:36 schrieb Ken Smith:
> 
> Sean Young wrote:
>> On Tue, Apr 28, 2020 at 08:24:20PM +0200, Martin Burnicki wrote:
>>> Hi,
>>>
>>> Am 27.04.20 um 10:59 schrieb Martin Burnicki:
>>>> Sean Young wrote:
>>>>> Would you mind testing this patch please?
>>>> I'm going to try it this evening.
>>>>
>>>> I'll have to find out how to do an out-of-tree build for a copy of the
>>>> cx module that includes the patch.
>>>>
>>>> My own kernel driver is always and only built out-of-tree, but for the
>>>> cx driver I need to see which files I need to copy to a local 
>>>> directory,
>>>> and if there is anything else that needs to be done to build a copy of
>>>> it out-of-tree.
>>> Sorry, I haven't managed to test the patch, yet.
>>>
>>> Currently I have the driver loaded with
>>>
>>> options cx23885 dma_reset_workaround=2
>>>
>>> but today there were 3 occurrences of the risc opcode error:
>>>
>>>
>> Drats.
>>
>>> So the workaround doesn't seem to fix the problem anyway, and the patch
>>> would just enable the workaround with out the specific option, right?
>> Yes, that's right.
>>
>>> The effect of the workaround looks just like debug levels lower than 7,
>>> it just seems to reduce the probability that the bug occurs, but doesn't
>>> really fix it.
>>>
>>> So my conclusion is still that that this smells like a missing memory
>>> barrier or so in the driver.
>>>
>>> Since the driver seems to work properly with older mainboards/CPU types,
>>> this doesn't sound like a problem in the CX chip, IMO.
>> I would agree with that. I would suspect same issue was being papered 
>> over
>> by the patch; now what that issue is, I don't know. Certainly some 
>> ordering
>> or barrier issue seems likely.
>>
>> Actually I suspected this all along, but the workaround is the best we 
>> have.
>>
>> I think, some time spent hunting down the issue would really be helpful
>> here. Hopefully that doesn't mean too many aborted recordings..
>>
>> Thanks,
>>
>> Sean
>>
> 
> Hi, I'd like to resurrect this thread (copied below). I have a system 
> showing this error. Its a HP ML350 server with 2x Xeon 5675 running 
> Rocky Linux 8.5. It has a Hauppauge HVR5525 card that uses the same 
> cx23885 kernel module as the quadHD card discussed above. The HVR5525 is 
> a dual DVB-T2/DVB-S2 card.
> 
> In other threads I read about the dma_reset_workaround option. That 
> option did not appear to be in the version included in standard kernel 
> in Rocky 8.5. I have loaded a 5.4 kernel and compiled the DVB media 
> modules from .git source and set dma_reset_workaround=2 in a file in 
> modprobe.d. The built module shows version 0.0.4
> 
> Sadly the error remains. The system runs MythTV v.31. The main symptom 
> is occasional aborted recordings. Although the card does appear to 
> recover, not requiring a reboot/cold restart.
> 
> I'd appreciate some assistance with this. What information can I provide 
> to help to trace this.

I'm also maintaining a driver which started to show problems on systems 
with new CPUs and chipsets quite some time ago, for example on some 
Ryzen CPUs. In my case it turned out that the problem was because my 
driver accessed memory locations on a my PCI card directly via a pointer.

Looks like the problem occurred because the CPU/chipset "optimized" and 
re-ordered the execution of some machine instructions. There are 
"barrier" instructions that can be inserted in the source code to avoid 
this, but my original code didn't use them because the driver had been 
working on many systems for a long time.

Anyway, the low level functions provided by the kernel to access 
registers on a peripheral are implemented to use those barriers, so 
simply using those primitives (writel, readl and friends) instead of 
accessing the registers directly via a pointer (*p = cmd; val = *(p+1) ) 
fixed the problem for my driver.

All the symptoms described here for the cx23885 module make me assume 
that the problem is very similar, i.e. due to a missing barrier 
instruction somewhere in the source code. Unfortunately I'm not familiar 
with the Linux media driver stuff, so I don't know where I could start 
to look for a missing barrier instruction.

The only workaround that fixed the problem for me, and that I'm still 
using, is to load the cx23885 module with a high debug level, by putting 
a line

options cx23885 debug=8

into a file

/etc/modprobe.d/cx23885.conf

This produces a HUGE amount of kernel log messages (dmesg), but with 
lower debug levels the driver still didn't work reliably.

To make this stable for a long time, I changed /var/log/ to NOT point to 
my SSD but to a real hard disk, and I created a cronjob file in 
/etc/etc/cron.d/ with the line

1 0-23 * * * root rm -f /var/log/kern.log*

to periodically remove the huge kernel log files.

This hack works for me since this has been discussed on this ML years ago.


Martin

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: HauppaugeTV-quadHD DVB-T & HVR5525 mpeg risc op code error

[Ken Smith]

>>>
>>
>> Hi, I'd like to resurrect this thread (copied below). I have a system 
>> showing this error. Its a HP ML350 server with 2x Xeon 5675 running 
>> Rocky Linux 8.5. It has a Hauppauge HVR5525 card that uses the same 
>> cx23885 kernel module as the quadHD card discussed above. The HVR5525 
>> is a dual DVB-T2/DVB-S2 card.
>>
>> In other threads I read about the dma_reset_workaround option. That 
>> option did not appear to be in the version included in standard 
>> kernel in Rocky 8.5. I have loaded a 5.4 kernel and compiled the DVB 
>> media modules from .git source and set dma_reset_workaround=2 in a 
>> file in modprobe.d. The built module shows version 0.0.4
>>
>> Sadly the error remains. The system runs MythTV v.31. The main 
>> symptom is occasional aborted recordings. Although the card does 
>> appear to recover, not requiring a reboot/cold restart.
>>
>> I'd appreciate some assistance with this. What information can I 
>> provide to help to trace this.
>
> I'm also maintaining a driver which started to show problems on 
> systems with new CPUs and chipsets quite some time ago, for example on 
> some Ryzen CPUs. In my case it turned out that the problem was because 
> my driver accessed memory locations on a my PCI card directly via a 
> pointer.
>
> Looks like the problem occurred because the CPU/chipset "optimized" 
> and re-ordered the execution of some machine instructions. There are 
> "barrier" instructions that can be inserted in the source code to 
> avoid this, but my original code didn't use them because the driver 
> had been working on many systems for a long time.
>
> Anyway, the low level functions provided by the kernel to access 
> registers on a peripheral are implemented to use those barriers, so 
> simply using those primitives (writel, readl and friends) instead of 
> accessing the registers directly via a pointer (*p = cmd; val = *(p+1) 
> ) fixed the problem for my driver.
>
> All the symptoms described here for the cx23885 module make me assume 
> that the problem is very similar, i.e. due to a missing barrier 
> instruction somewhere in the source code. Unfortunately I'm not 
> familiar with the Linux media driver stuff, so I don't know where I 
> could start to look for a missing barrier instruction.
>
> The only workaround that fixed the problem for me, and that I'm still 
> using, is to load the cx23885 module with a high debug level, by 
> putting a line
>
> options cx23885 debug=8
>
> into a file
>
> /etc/modprobe.d/cx23885.conf
>
> This produces a HUGE amount of kernel log messages (dmesg), but with 
> lower debug levels the driver still didn't work reliably.
>
> To make this stable for a long time, I changed /var/log/ to NOT point 
> to my SSD but to a real hard disk, and I created a cronjob file in 
> /etc/etc/cron.d/ with the line
>
> 1 0-23 * * * root rm -f /var/log/kern.log*
>
> to periodically remove the huge kernel log files.
>
> This hack works for me since this has been discussed on this ML years 
> ago.
>
>
> Martin
Thank you Martin and Robert.

I've been doing some testing today. intel_iommu=off and 
dma_reset_workaround=2 or dma_reset_workaround=0 didn't change the 
symptoms.

This system has journald. I initially set debug=1 to see where the 
messages go and I see what you mean about the volume of messages. I need 
to work out how to divert this torrent to /dev/null if that option is to 
be workable.

I fully understand your comment about out of order instructions, Martin. 
Looks like this driver may need the same attention as the one you 
maintain. One option for me is to move the HVR5525 to a lower power 
machine and run that as a slave MythBackend.

Many thanks


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: HauppaugeTV-quadHD DVB-T & HVR5525 mpeg risc op code error

[Ken Smith]

Ken Smith wrote:
>
>>>>
>>>
>>> Hi, I'd like to resurrect this thread (copied below). I have a 
>>> system showing this error. Its a HP ML350 server with 2x Xeon 5675 
>>> running Rocky Linux 8.5. It has a Hauppauge HVR5525 card that uses 
>>> the same cx23885 kernel module as the quadHD card discussed above. 
>>> The HVR5525 is a dual DVB-T2/DVB-S2 card.
>>>
>>> In other threads I read about the dma_reset_workaround option. That 
>>> option did not appear to be in the version included in standard 
>>> kernel in Rocky 8.5. I have loaded a 5.4 kernel and compiled the DVB 
>>> media modules from .git source and set dma_reset_workaround=2 in a 
>>> file in modprobe.d. The built module shows version 0.0.4
>>>
>>> Sadly the error remains. The system runs MythTV v.31. The main 
>>> symptom is occasional aborted recordings. Although the card does 
>>> appear to recover, not requiring a reboot/cold restart.
>>>
>>> I'd appreciate some assistance with this. What information can I 
>>> provide to help to trace this.
>>
>> I'm also maintaining a driver which started to show problems on 
>> systems with new CPUs and chipsets quite some time ago, for example 
>> on some Ryzen CPUs. In my case it turned out that the problem was 
>> because my driver accessed memory locations on a my PCI card directly 
>> via a pointer.
>>
>> Looks like the problem occurred because the CPU/chipset "optimized" 
>> and re-ordered the execution of some machine instructions. There are 
>> "barrier" instructions that can be inserted in the source code to 
>> avoid this, but my original code didn't use them because the driver 
>> had been working on many systems for a long time.
>>
>> Anyway, the low level functions provided by the kernel to access 
>> registers on a peripheral are implemented to use those barriers, so 
>> simply using those primitives (writel, readl and friends) instead of 
>> accessing the registers directly via a pointer (*p = cmd; val = 
>> *(p+1) ) fixed the problem for my driver.
>>
>> All the symptoms described here for the cx23885 module make me assume 
>> that the problem is very similar, i.e. due to a missing barrier 
>> instruction somewhere in the source code. Unfortunately I'm not 
>> familiar with the Linux media driver stuff, so I don't know where I 
>> could start to look for a missing barrier instruction.
>>
>> The only workaround that fixed the problem for me, and that I'm still 
>> using, is to load the cx23885 module with a high debug level, by 
>> putting a line
>>
>> options cx23885 debug=8
>>
>> into a file
>>
>> /etc/modprobe.d/cx23885.conf
>>
>> This produces a HUGE amount of kernel log messages (dmesg), but with 
>> lower debug levels the driver still didn't work reliably.
>>
>> To make this stable for a long time, I changed /var/log/ to NOT point 
>> to my SSD but to a real hard disk, and I created a cronjob file in 
>> /etc/etc/cron.d/ with the line
>>
>> 1 0-23 * * * root rm -f /var/log/kern.log*
>>
>> to periodically remove the huge kernel log files.
>>
>> This hack works for me since this has been discussed on this ML years 
>> ago.
>>
>>
>> Martin
> Thank you Martin and Robert.
>
> I've been doing some testing today. intel_iommu=off and 
> dma_reset_workaround=2 or dma_reset_workaround=0 didn't change the 
> symptoms.
>
> This system has journald. I initially set debug=1 to see where the 
> messages go and I see what you mean about the volume of messages. I 
> need to work out how to divert this torrent to /dev/null if that 
> option is to be workable.
>
> I fully understand your comment about out of order instructions, 
> Martin. Looks like this driver may need the same attention as the one 
> you maintain. One option for me is to move the HVR5525 to a lower 
> power machine and run that as a slave MythBackend.
>
> Many thanks
>
>
Update on this. I have moved the two DVBS2 tuners from the the ML350 
Server to a mini PC that has an i3 processor and I'm using that as a 
MythTV Slave Backend. It has logged three "mpeg risc op code error" 
events since I started it last Friday and so far no aborted recordings. 
This is a workaround fix that I'll live with for now. I noticed some 
recent patches for that module being published.

Thanks Ken

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: HauppaugeTV-quadHD DVB-T & HVR5525 mpeg risc op code error

[Ken Smith]

Ken Smith wrote:
> Ken Smith wrote:
>>
>>>>
>>>> Hi, I'd like to resurrect this thread (copied below). I have a 
>>>> system showing this error. Its a HP ML350 server with 2x Xeon 5675 
>>>> running Rocky Linux 8.5. It has a Hauppauge HVR5525 card that uses 
>>>> the same cx23885 kernel module as the quadHD card discussed above. 
>>>> The HVR5525 is a dual DVB-T2/DVB-S2 card.
>>>>
>>>> In other threads I read about the dma_reset_workaround option. That 
>>>> option did not appear to be in the version included in standard 
>>>> kernel in Rocky 8.5. I have loaded a 5.4 kernel and compiled the 
>>>> DVB media modules from .git source and set dma_reset_workaround=2 
>>>> in a file in modprobe.d. The built module shows version 0.0.4
>>>>
>>>> Sadly the error remains. The system runs MythTV v.31. The main 
>>>> symptom is occasional aborted recordings. Although the card does 
>>>> appear to recover, not requiring a reboot/cold restart.
>>>>
>>>> I'd appreciate some assistance with this. What information can I 
>>>> provide to help to trace this.
>>>
>>> I'm also maintaining a driver which started to show problems on 
>>> systems with new CPUs and chipsets quite some time ago, for example 
>>> on some Ryzen CPUs. In my case it turned out that the problem was 
>>> because my driver accessed memory locations on a my PCI card 
>>> directly via a pointer.
>>>
>>> Looks like the problem occurred because the CPU/chipset "optimized" 
>>> and re-ordered the execution of some machine instructions. There are 
>>> "barrier" instructions that can be inserted in the source code to 
>>> avoid this, but my original code didn't use them because the driver 
>>> had been working on many systems for a long time.
>>>
>>> Anyway, the low level functions provided by the kernel to access 
>>> registers on a peripheral are implemented to use those barriers, so 
>>> simply using those primitives (writel, readl and friends) instead of 
>>> accessing the registers directly via a pointer (*p = cmd; val = 
>>> *(p+1) ) fixed the problem for my driver.
>>>
>>> All the symptoms described here for the cx23885 module make me 
>>> assume that the problem is very similar, i.e. due to a missing 
>>> barrier instruction somewhere in the source code. Unfortunately I'm 
>>> not familiar with the Linux media driver stuff, so I don't know 
>>> where I could start to look for a missing barrier instruction.
>>>
>>> The only workaround that fixed the problem for me, and that I'm 
>>> still using, is to load the cx23885 module with a high debug level, 
>>> by putting a line
>>>
>>> options cx23885 debug=8
>>>
>>> into a file
>>>
>>> /etc/modprobe.d/cx23885.conf
>>>
>>> This produces a HUGE amount of kernel log messages (dmesg), but with 
>>> lower debug levels the driver still didn't work reliably.
>>>
>>> To make this stable for a long time, I changed /var/log/ to NOT 
>>> point to my SSD but to a real hard disk, and I created a cronjob 
>>> file in /etc/etc/cron.d/ with the line
>>>
>>> 1 0-23 * * * root rm -f /var/log/kern.log*
>>>
>>> to periodically remove the huge kernel log files.
>>>
>>> This hack works for me since this has been discussed on this ML 
>>> years ago.
>>>
>>>
>>> Martin
>> Thank you Martin and Robert.
>>
>> I've been doing some testing today. intel_iommu=off and 
>> dma_reset_workaround=2 or dma_reset_workaround=0 didn't change the 
>> symptoms.
>>
>> This system has journald. I initially set debug=1 to see where the 
>> messages go and I see what you mean about the volume of messages. I 
>> need to work out how to divert this torrent to /dev/null if that 
>> option is to be workable.
>>
>> I fully understand your comment about out of order instructions, 
>> Martin. Looks like this driver may need the same attention as the one 
>> you maintain. One option for me is to move the HVR5525 to a lower 
>> power machine and run that as a slave MythBackend.
>>
>> Many thanks
>>
>>
> Update on this. I have moved the two DVBS2 tuners from the the ML350 
> Server to a mini PC that has an i3 processor and I'm using that as a 
> MythTV Slave Backend. It has logged three "mpeg risc op code error" 
> events since I started it last Friday and so far no aborted 
> recordings. This is a workaround fix that I'll live with for now. I 
> noticed some recent patches for that module being published.
>
> Thanks Ken
>
Update to close out this thread. The Hauppauge HVR-5525 capture cards 
were not stable with the current DVB Media tree on either a ML350 with a 
Xeon or on an i3 powered PC. For the moment I've switched to using TBS 
cards.

:-) Ken



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: HauppaugeTV-quadHD DVB-T & HVR5525 mpeg risc op code error

[Ken Smith]

(Resend - first send did not reach the list  )


Ian Young wrote:
> On Tue, Apr 28, 2020 at 08:24:20PM +0200, Martin Burnicki wrote:
>> Hi,
>>
>> Am 27.04.20 um 10:59 schrieb Martin Burnicki:
>>> Sean Young wrote:
>>>> Would you mind testing this patch please?
>>> I'm going to try it this evening.
>>>
>>> I'll have to find out how to do an out-of-tree build for a copy of the
>>> cx module that includes the patch.
>>>
>>> My own kernel driver is always and only built out-of-tree, but for the
>>> cx driver I need to see which files I need to copy to a local directory,
>>> and if there is anything else that needs to be done to build a copy of
>>> it out-of-tree.
>> Sorry, I haven't managed to test the patch, yet.
>>
>> Currently I have the driver loaded with
>>
>> options cx23885 dma_reset_workaround=2
>>
>> but today there were 3 occurrences of the risc opcode error:
>>
>>
> Drats.
>
>> So the workaround doesn't seem to fix the problem anyway, and the patch
>> would just enable the workaround with out the specific option, right?
> Yes, that's right.
>
>> The effect of the workaround looks just like debug levels lower than 7,
>> it just seems to reduce the probability that the bug occurs, but doesn't
>> really fix it.
>>
>> So my conclusion is still that that this smells like a missing memory
>> barrier or so in the driver.
>>
>> Since the driver seems to work properly with older mainboards/CPU types,
>> this doesn't sound like a problem in the CX chip, IMO.
> I would agree with that. I would suspect same issue was being papered over
> by the patch; now what that issue is, I don't know. Certainly some 
> ordering
> or barrier issue seems likely.
>
> Actually I suspected this all along, but the workaround is the best we 
> have.
>
> I think, some time spent hunting down the issue would really be helpful
> here. Hopefully that doesn't mean too many aborted recordings..
>
> Thanks,
>
> Sean
>

Hi, I'd like to resurrect this thread (copied above). I have a system 
showing this error. Its a HP ML350 server with 2x Xeon 5675 running 
Rocky Linux 8.5. It has a Hauppauge HVR5525 card that uses the same 
cx23885 kernel module as the quadHD card discussed above. The HVR5525 is 
a dual DVB-T2/DVB-S2 card.

In other threads I read about the dma_reset_workaround option. That 
option did not appear to be in the version included in standard kernel 
in Rocky 8.5. I have loaded a 5.4 kernel and compiled the DVB media 
modules from .git source and set dma_reset_workaround=2 in a file in 
modprobe.d. The built module shows version 0.0.4

Sadly the error remains. The system runs MythTV v.31. The main symptom 
is occasional aborted recordings. Although the card does appear to 
recover, not requiring a reboot/cold restart.

I'd appreciate some assistance with this. What information can I provide 
to help to trace this.

Many thanks

Ken


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: HauppaugeTV-quadHD DVB-T & HVR5525 mpeg risc op code error

[Ken Smith]

Ian Young wrote:
> On Tue, Apr 28, 2020 at 08:24:20PM +0200, Martin Burnicki wrote:
>> Hi,
>>
>> Am 27.04.20 um 10:59 schrieb Martin Burnicki:
>>> Sean Young wrote:
>>>> Would you mind testing this patch please?
>>> I'm going to try it this evening.
>>>
>>> I'll have to find out how to do an out-of-tree build for a copy of the
>>> cx module that includes the patch.
>>>
>>> My own kernel driver is always and only built out-of-tree, but for the
>>> cx driver I need to see which files I need to copy to a local directory,
>>> and if there is anything else that needs to be done to build a copy of
>>> it out-of-tree.
>> Sorry, I haven't managed to test the patch, yet.
>>
>> Currently I have the driver loaded with
>>
>> options cx23885 dma_reset_workaround=2
>>
>> but today there were 3 occurrences of the risc opcode error:
>>
>>
> Drats.
>
>> So the workaround doesn't seem to fix the problem anyway, and the patch
>> would just enable the workaround with out the specific option, right?
> Yes, that's right.
>
>> The effect of the workaround looks just like debug levels lower than 7,
>> it just seems to reduce the probability that the bug occurs, but doesn't
>> really fix it.
>>
>> So my conclusion is still that that this smells like a missing memory
>> barrier or so in the driver.
>>
>> Since the driver seems to work properly with older mainboards/CPU types,
>> this doesn't sound like a problem in the CX chip, IMO.
> I would agree with that. I would suspect same issue was being papered over
> by the patch; now what that issue is, I don't know. Certainly some 
> ordering
> or barrier issue seems likely.
>
> Actually I suspected this all along, but the workaround is the best we 
> have.
>
> I think, some time spent hunting down the issue would really be helpful
> here. Hopefully that doesn't mean too many aborted recordings..
>
> Thanks,
>
> Sean
>

Hi, I'd like to resurrect this thread (copied above). I have a system 
showing this error. Its on a HP ML350 server with 2x Xeon 5675 running 
Rocky Linux 8.5. It has a Hauppauge HVR5525 card that uses the same 
cx23885 kernel module, as many PCIe cards do, as the quadHD card 
discussed above. The HVR5525 is a dual DVB-T2/DVB-S2 card.

Elsewhere I read about the dma_reset_workaround option. That option did 
not appear to be in the driver included in standard kernel in Rocky 8.5. 
I have tested with a 5.4 & 5.18 kernel and compiled the DVB media 
modules from .git source and set dma_reset_workaround=2 in a file in 
modprobe.d. The built module shows version 0.0.4

Sadly the error remains. The system runs MythTV v.31. The main symptom 
is aborted recordings. Although the card does appear to recover, not 
requiring a reboot/cold restart.

I've also logged this on Bugzilla. For some reason my original 
subscription to this list had stopped working so I may have missed some 
threads since Oct 2020.

I'd appreciate some assistance with this. What information can I 
provide, or testing can I do, to help to trace this.

Many thanks

Ken

Re: HauppaugeTV-quadHD DVB-T & HVR5525 mpeg risc op code error

[Ken Smith]

Apologies for multiple posts - e-mail configuration error at my end.


Ken Smith wrote:
>
>
> Ian Young wrote:
>> On Tue, Apr 28, 2020 at 08:24:20PM +0200, Martin Burnicki wrote:
>>> Hi,
>>>
>>> Am 27.04.20 um 10:59 schrieb Martin Burnicki:
>>>> Sean Young wrote:
>>>>> Would you mind testing this patch please?
>>>> I'm going to try it this evening.
>>>>
>>>> I'll have to find out how to do an out-of-tree build for a copy of the
>>>> cx module that includes the patch.
>>>>
>>>> My own kernel driver is always and only built out-of-tree, but for the
>>>> cx driver I need to see which files I need to copy to a local 
>>>> directory,
>>>> and if there is anything else that needs to be done to build a copy of
>>>> it out-of-tree.
>>> Sorry, I haven't managed to test the patch, yet.
>>>
>>> Currently I have the driver loaded with
>>>
>>> options cx23885 dma_reset_workaround=2
>>>
>>> but today there were 3 occurrences of the risc opcode error:
>>>
>>>
>> Drats.
>>
>>> So the workaround doesn't seem to fix the problem anyway, and the patch
>>> would just enable the workaround with out the specific option, right?
>> Yes, that's right.
>>
>>> The effect of the workaround looks just like debug levels lower than 7,
>>> it just seems to reduce the probability that the bug occurs, but 
>>> doesn't
>>> really fix it.
>>>
>>> So my conclusion is still that that this smells like a missing memory
>>> barrier or so in the driver.
>>>
>>> Since the driver seems to work properly with older mainboards/CPU 
>>> types,
>>> this doesn't sound like a problem in the CX chip, IMO.
>> I would agree with that. I would suspect same issue was being papered 
>> over
>> by the patch; now what that issue is, I don't know. Certainly some 
>> ordering
>> or barrier issue seems likely.
>>
>> Actually I suspected this all along, but the workaround is the best 
>> we have.
>>
>> I think, some time spent hunting down the issue would really be helpful
>> here. Hopefully that doesn't mean too many aborted recordings..
>>
>> Thanks,
>>
>> Sean
>>
>
> Hi, I'd like to resurrect this thread (copied above). I have a system 
> showing this error. Its on a HP ML350 server with 2x Xeon 5675 running 
> Rocky Linux 8.5. It has a Hauppauge HVR5525 card that uses the same 
> cx23885 kernel module, as many PCIe cards do, as the quadHD card 
> discussed above. The HVR5525 is a dual DVB-T2/DVB-S2 card.
>
> Elsewhere I read about the dma_reset_workaround option. That option 
> did not appear to be in the driver included in standard kernel in 
> Rocky 8.5. I have tested with a 5.4 & 5.18 kernel and compiled the DVB 
> media modules from .git source and set dma_reset_workaround=2 in a 
> file in modprobe.d. The built module shows version 0.0.4
>
> Sadly the error remains. The system runs MythTV v.31. The main symptom 
> is aborted recordings. Although the card does appear to recover, not 
> requiring a reboot/cold restart.
>
> I've also logged this on Bugzilla. For some reason my original 
> subscription to this list had stopped working so I may have missed 
> some threads since Oct 2020.
>
> I'd appreciate some assistance with this. What information can I 
> provide, or testing can I do, to help to trace this.
>
> Many thanks
>
> Ken
>
>