Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DVB Master LP PCIe won't transmit on kernel 4.18 and 5.14 #7

Open
dhurrell opened this issue Jul 3, 2023 · 3 comments
Open

DVB Master LP PCIe won't transmit on kernel 4.18 and 5.14 #7

dhurrell opened this issue Jul 3, 2023 · 3 comments

Comments

@dhurrell
Copy link

dhurrell commented Jul 3, 2023

Hello,

I have a board recognised as "DVB Master LP PCIe, firmware version 1.2 (0x0102)". I've used this repo to build and install the drivers on Rocky Linux 8 (kernel 4.18) and 9 (kernel 5.14) - many thanks!

Unfortunately, although the kernel drivers appear to load successfully, and the device shows up under /dev/asitx0 and /dev/asirx0 as expected, the board never seems to transmit. Writing to /dev/asitx0 only succeeds until the write buffer is full, then blocks forever. In the output from txtest, there is no "transmit data status change detected" line (which is seen on a working platform), and it hangs forever after printing "Allocating 38352 bytes of memory." (in verbose mode).

Investigating further, it appears that the IRQ handler (in dvbm_lpfd.c in my case) registered via request_irq() is never called. This leads me to think the board is not actually doing anything, even after DMA is started (via dvbm_lpfd_start_tx_dma()) - but I don't know enough to figure out why.

Drivers compiled from the same source do work successfully on CentOS 7 with kernel 3.10, but not when I upgrade the CentOS 7 kernel to 5.4 (using the kernel available in ELRepo).

Does anyone have any ideas?

Many thanks!
David

@richard-vd
Copy link
Contributor

I have several production systems running well on Rocky Linux 9.1 (kernel 5.14) using dvbm driver version 3.15.0 from my patch in PR #6. The board used in these systems is DVB Master Quad-2in2out LP PCIe Mini BNC, firmware version 1.2 (0x0102). That is the only DVEO board I tested with on this OS. Did you use the code from my PR?

Years ago I experienced behaviour similar to what you described using your board type. That was resolved by disabling ASPM (Active State Power Management) on the PCIe link using a BIOS setting.

@dhurrell
Copy link
Author

dhurrell commented Jul 4, 2023

Hi Richard, many thanks for your response.

I've tried driver version 3.15.0 from your PR (both with and without using the DKMS installation method). I also tried the driver before your PR was merged on kernel 4.18 (Rocky 8.8), as your changes are only required on kernel 5.x.

My kernel 5.14 attempts are on Rocky 9.2, but I can't imagine that makes a difference given how consistent the behaviour has been across CentOS/Rocky and kernel versions (other than the default kernel 3.10 on CentOS 7.9, where it works).

Thanks also for the tip regarding ASPM. I had a play around with BIOS settings, but it looks like my hardware (a HP ProLiant DL360 Gen9) doesn't support ASPM anyway - the Linux kernel spits out these messages:

$ dmesg | grep -i aspm
[ 0.084577] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 0.095366] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
[ 0.099193] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
[ 0.099309] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
[ 5.403195] hpsa 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control

I tried changing other PCIe settings just in case, but no luck.

Any further suggestions are welcome! Thanks again for responding.

@richard-vd
Copy link
Contributor

richard-vd commented Jul 4, 2023

Does the HP DL360 G9 happen to be using Xeon E5-26xx v2 CPUs? Back in 2014 I had hanging writes with the DVB Master LP PCIe (your board type) on Supermicro 6017 machines, the issue wasn't present at boot but eventually it would always happen. I could only resolve that by replacing the CPU by a non-v2 type (e.g. replace E5-2603 v2 by E5-2603).

Edit: I see (here) that the DL360 G9 uses v3 or v4 CPUs, these should be fine to use with this board.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants