Tools: Complete Guide to I Have No Sound, and I Must Hear: A Story of a Kernel Regression
The Prologue
The Diagnosis
Deep Dive into dmesg (The 0xFFFF Error)
What is CORB and why does it matter?
Eureka: The Software "Hot-swap"
Automation
Conclusion TL;DR: After a kernel update, my 15-year-old laptop lost sound with CORB reset timeout and CORBRP = 65535 (0xFFFF). Reinstalling audio servers didn't help. GRUB parameters were ignored. The fix? Force a PCI rescan via sysfs and automate it with a systemd service. Here's the full debugging journey. I use an old laptop — an Emachines E732. It’s so ancient that its maximum RAM is 8GB. Yet, it remains my reliable workhorse. Everything was fine until a routine sudo pacman -Syu on CachyOS. Suddenly, the sound was gone. Reinstalling pulseaudio or pipewire did nothing. I hopped over to EndeavourOS, where it worked... until I switched to the linux-zen kernel. Then it died again. Eventually, the sound vanished even on LTS kernels and LiveCDs. I almost gave up and bought a USB sound card, but then I realized: a workaround must exist. Standard tools were useless. aplay -l was laconic: However, inxi -Axxz confirmed the hardware was still there: And journalctl showed the first signs of trouble: The system knew the card existed but couldn't talk to it. Here’s what didn't work: The truth was buried in dmesg. When the snd_hda_intel driver tries to wake up, it hits a wall: CORB (Command Output Ring Buffer) is the ring buffer used by the driver to send commands to the audio codec. Trying to reload the module manually (modprobe -r / modprobe) just produced the same errors with different timestamps. The device was stuck. I noticed that during a cold boot, the kernel assigned the card an address in the lower memory range: BAR 0 [mem 0xd4400000-0xd4403fff 64bit]. I decided to try a "software hot-plug" via sysfs: It worked. The dmesg output changed. Upon rescan, the kernel assigned a new memory address (BAR 0): The Realtek ALC272 codec finally responded. I first tried a udev rule, but it failed due to a race condition: udev caught the "add" event and tried to "remove" the card while the kernel was still struggling to initialize it. The stable solution is a systemd oneshot service: /etc/systemd/system/fix-audio.service LTS doesn't guarantee the absence of regressions. Sometimes, progress (new power management or resource allocation logic) forgets about 15-year-old chipsets. Why not a kernel bug report?
The hardware is 15 years old. A proper report requires a kernel bisect (dozens of re-compilations). On an 8GB laptop, that's torture. I chose the efficient workaround: a 5-minute script vs. weeks of compilation for a fix that might never be merged. Maybe the hardware is just dying?
The logs say otherwise. If it were dying, it wouldn't work stably after a rescan — it would fail randomly or not be detected at all. This is a classic software/resource allocation issue. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse