MAX S8 4/8 "MXL5XX" Tuner Card Troubleshooting
MAX S8 4/8 · MXL5XX · DVB-S2 · Linux kernel driver
Platform: Ubuntu 24 LTS | Kernel: 6.8.x | Driver: dddvb (OE)
This article covers diagnosis and resolution of a common failure mode where one or more Digital Devices MAX S8 tuner cards fail to initialise at boot. The symptom is I2C timeout errors in dmesg with the MXL5XX tuner chip not being detected, while other cards on the same system initialise correctly.
The ddbridge driver is an out-of-tree (OE) kernel module. It is not part of the mainline Linux kernel and must be built and installed separately from the dddvb project.
Run the following to see relevant log lines:
dmesg | grep ddbridge | grep -E 'registering|fail|timeout'
ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
ddbridge 0000:01:00.0: No MXL5XX found!
ddbridge 0000:01:00.0: port_attach on port 0 failed
ddbridge 0000:01:00.0: fail3
ddbridge 0000:01:00.0: fail2
ddbridge 0000:01:00.0: fail1
ddbridge 0000:01:00.0: fail0
ddbridge 0000:01:00.0: fail
ddbridge 0000:81:00.0: Read mxl_fw from link 0
ddbridge 0000:81:00.0: Set fmode link 0 = 1
ddbridge 0000:81:00.0: DVB: registering adapter 0 frontend 0 (MXL5XX)...
ddbridge 0000:81:00.0: DVB: registering adapter 1 frontend 0 (MXL5XX)...
Key difference: a working card logs 'Read mxl_fw from link 0' followed by adapter registrations. A failing card never reaches firmware upload and only shows I2C timeouts.
Address
NUMA Node
Status
Result
0000:01:00.0
CPU 1 / Node 0
❌ FAILING
I2C timeouts — MXL5XX not found
0000:81:00.0
CPU 2 / Node 1
✅ OK
8 adapters registered (MXL5XX)
0000:82:00.0
⚠ The OE- suffix in dmesg (e.g. ddbridge(OE-)) means the module is a zombie — it was unloaded but got stuck. This requires a full server reboot to clear and cannot be resolved with rmmod.
Before assuming hardware failure, confirm whether the MXL5XX tuner chip is actually responding. This is the most important diagnostic step — it separates a dead card from a driver/slot problem.
sudo apt install i2c-tools
sudo i2cdetect -l | grep ddbridge
Expected output for a failing card (note: working cards do not expose I2C buses because firmware takes over):
i2c-4 i2c ddbridge_00.0.0 I2C adapter
i2c-77 i2c ddbridge_00.0.0 I2C adapter
⚠ Two entries with the same name is normal for ddbridge — they are the same bus exposed twice.
sudo i2cdetect -y 4
Expected output if the chip is alive:
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- 0c -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- 4d -- --
60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Chip
Role
0x0c
LNBH
LNB voltage controller
0x4d
CXD2099
CI (Common Interface) controller
0x60
MXL5XX
Main tuner chip — must be present for card to work
Critical: address 0x60 must be present. If it is missing, the MXL5XX chip is dead or unpowered and the card needs physical inspection or replacement.
sudo i2ctransfer -y 4 r1@0x60
If the chip is alive this returns:
0x00
✔ If i2ctransfer returns 0x00, the chip is alive and responding. The failure is in the driver's firmware upload process, not in the hardware. The card is not dead.
lsmod | grep -E 'ddbridge|dvb|cxd'
Look at the use count (third column). A value of -1 means the module is in a zombie unload state and the server must be rebooted.
sudo lspci -D | grep -i 'digital devices'
cat /sys/bus/pci/devices/0000:01:00.0/numa_node
Cards on different NUMA nodes (different CPU sockets) may have interrupt routing issues. Cards on NUMA node 1 (CPU 2) are generally more reliable on dual-socket servers.
sudo dmesg | grep -E 'DMAR|IOMMU|iommu' | head -20
cat /proc/interrupts | grep ddbridge
If IRQ remapping is active (IR-IO-APIC entries) and the failing card is on a different NUMA node to the working cards, cross-NUMA interrupt routing is likely causing the I2C timeouts.
sudo dmidecode -t bios | grep -E 'Version|Release'
⚠ A BIOS older than 5 years on a dual-socket server is a likely contributor to PCIe slot and NUMA interrupt routing issues.
sudo nano /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=off"
sudo update-grub && sudo reboot
This disables Intel VT-d/IOMMU which is enabled by default in Ubuntu kernels from 22.04 onwards. Effective when the issue is caused by cross-NUMA interrupt remapping blocking DMA completions.
sudo modprobe ddbridge fmode=1 msi=0
Forces legacy INTx interrupts instead of MSI. Make permanent by creating a modprobe config:
echo 'options ddbridge fmode=1 msi=0' | sudo tee /etc/modprobe.d/ddbridge.conf
sudo update-initramfs -u && sudo reboot
If software fixes do not resolve the issue, move the failing card from a CPU 1 slot into any available CPU 2 slot. This has been confirmed to resolve I2C timeout failures caused by NUMA node 0 interrupt routing problems.
• Power off the server completely and wait 30 seconds
• Move the failing card to a CPU 2 PCIe slot
• Power on and verify: dmesg | grep ddbridge | grep -E 'registering|fail|timeout'
✔ To confirm the slot is the problem and not the card, swap two cards between a CPU 1 and CPU 2 slot. If the previously working card then fails in the CPU 1 slot, the slot is confirmed faulty.
If the BIOS is from 2015 or earlier, a firmware update from the motherboard manufacturer may resolve ACPI and PCIe slot initialisation bugs affecting the CPU 1 domain.
⚠ The ddbridge module cannot be unloaded if any process has DVB devices open. Stop tvheadend, oscam, minisatip, or any other DVB client before attempting a reload.
sudo systemctl stop tvheadend oscam minisatip 2>/dev/null
echo '0000:01:00.0' | sudo tee /sys/bus/pci/devices/0000:01:00.0/driver/unbind
echo '0000:81:00.0' | sudo tee /sys/bus/pci/devices/0000:81:00.0/driver/unbind
echo '0000:82:00.0' | sudo tee /sys/bus/pci/devices/0000:82:00.0/driver/unbind
sudo rmmod ddbridge cxd2099 dvb_core mc
sudo depmod -a
Check all cards
Full ddbridge log
dmesg | grep ddbridge
Module state
List I2C buses
Scan I2C bus
sudo i2cdetect -y <bus_num>
Probe chip directly
sudo i2ctransfer -y <bus_num> r1@0x60
NUMA node of card
cat /sys/bus/pci/devices/0000:XX:00.0/numa_node
PCIe topology
sudo lspci -t
IOMMU status
sudo dmesg | grep -i iommu | head -10
BIOS version
Slot inventory
sudo dmidecode -t slot | grep -E 'Designation|Usage|Bus'
DVB devices
ls /dev/dvb/
This article is based on a live troubleshooting session on a dual-socket Intel server running Ubuntu 24 LTS with kernel 6.8.0 and the dddvb out-of-tree driver. The MXL5XX chip-alive check via i2ctransfer is the key technique that separates hardware failure from driver/slot issues.
« Zurück
Datenschutzerklärung | Impressum
Vorschläge aus der Wissensdatenbank werden geladen ...