Created attachment 1897727 [details] Output from alsa-info.sh Description of problem: No sound output from speakers but headphones work. Likely related that mute and mic leds on F5 and F8 keys do not work although keys are functional. Version-Release number of selected component (if applicable): kernel-5.18.11-200.fc36.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot machine 2. Play music 3. Actual results: Sound from headphones but nothing from speaker Expected results: Sound from both headphones and speakers Additional info: Seems to be common problems with HP laptops.See for example bko#200929 and bko#213953.Have tried numerous suggestions like hda-verb-quirks mentioned in some of the bug reports but so far no success producing any sound from the speakers.
Created attachment 1897842 [details] alsa-info.sh with codec coefficients dump
Same issue. I’ve tried 5.19 RC7, hdataskrejack’ing various jacks to internal speaker (I tried every single one), installing alsa-drivers or sof, switching to pulseaudio from pipewire, etc. I believe it’s an issue with the card and the bios perhaps. The same issue applies to the bluetooth in this device not functioning but that’s a different bug. I know it’s not an issue of windows fast boot not closing the card down correctly, as that’s a problem that can happen sometimes; I booted into Windows and shut down properly without fast boot enabled. I can test any suggestions of possible solutions or post any device info as well: I have a spare one not being used currently running a standard Fedora installation. PS: not sure what I did before this message; my apologies. I’m still learning this platform.
Looks like this laptop uses the Cirrus Logic CS35L41 amp to drive the speakers. This snippet from dmesg may also be relevant to this bug: [ 8.827274] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.0 failed with error -22 [ 8.827559] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.1 failed with error -22
It seems that a similar quirk recently added to /sound/pci/hda/patch_realtek.c may be sufficient to fix the issues? + SND_PCI_QUIRK(0x103c, 0x8ad1, "HP EliteBook 840 14 inch G9 Notebook PC", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), + SND_PCI_QUIRK(0x103c, 0x8ad2, "HP EliteBook 860 16 inch G9 Notebook PC", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), However, we would need to get the amp CS35L41 working first. There have been some recent changes in CS35L41 code so tried Linux fedora 5.19.0-65.fc37.x86_64 but all I get is an updated error message: [ 9.174327] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.0: error -EINVAL: Platform not supported -22 [ 9.174451] cs35l41-hda i2c-CSC3551:00-cs35l41-hda.1: error -EINVAL: Platform not supported -22 Error occurs around ACPI probing so the thinking is that BIOS DSDT tables have some issues? Current BIOS version from dmesg is: [ 0.000000] DMI: HP HP ENVY x360 2-in-1 Laptop 15-ey0xxx/8A31, BIOS F.05 04/07/2022 See that HP have an updated BIOS for this machine at https://support.hp.com/us-en/drivers. Unfortuately do not have a windows partition and have yet yet figured out how to update the BIOS within linux. @rhbug do you know which BIOS version you are running and if not the latest do you still have a windows partition to update to latest version? Would like to know if that fixes the CS35L41 amp issue. Thanks.
I'm running F.06 currently so it too seems affected. I'm trying to install Windows again to upgrade to F.07, but even the latest W11 ISO download doesn't contain the latest drivers apparently. Hopefully I'll be able to use the HP Cloud Recovery Tool to reinstall the recovery software onto my drive, so I can update the BIOS to F.07.
Thanks for the feedback. Did a dump and disassembly of my DSDT table. There is an entry for speaker (SPKR) but it is missing some properties which probably explains the error message. https://github.com/torvalds/linux/blob/d7227785e384d4422b3ca189aa5bf19f462337cc/sound/pci/hda/cs35l41_hda.c#L319 Scope (_SB.I2CB) { Device (SPKR) { Name (_HID, "CSC3551") // _HID: Hardware ID Name (_SUB, "103C8A31") // _SUB: Subsystem ID Name (_UID, One) // _UID: Unique ID Name (_DEP, Package (0x02) // _DEP: Dependencies { GPIO, I2CB }) Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Name (RBUF, ResourceTemplate () { I2cSerialBusV2 (0x0040, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2CB", 0x00, ResourceConsumer, , Exclusive, ) I2cSerialBusV2 (0x0041, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2CB", 0x00, ResourceConsumer, , Exclusive, ) GpioIo (Exclusive, PullNone, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPIO", 0x00, ResourceConsumer, , ) { // Pin list 0x001E } GpioIo (Exclusive, PullUp, 0x0000, 0x0000, IoRestrictionInputOnly, "\\_SB.GPIO", 0x00, ResourceConsumer, , ) { // Pin list 0x005A } GpioIo (Shared, PullUp, 0x0064, 0x0000, IoRestrictionInputOnly, "\\_SB.GPIO", 0x00, ResourceConsumer, , ) { // Pin list 0x001F } GpioInt (Edge, ActiveBoth, Shared, PullUp, 0x0064, "\\_SB.GPIO", 0x00, ResourceConsumer, , ) { // Pin list 0x001F } }) Return (RBUF) /* \_SB_.I2CB.SPKR._CRS.RBUF */ } Method (_STA, 0, NotSerialized) // _STA: Status { Return (0x0F) } Method (_DIS, 0, NotSerialized) // _DIS: Disable Device { } } }
Managed to update to BIOS version F07 using the USB BIOS recovery method. No differences in DSDT dump files and the error remains :( [ 8.920521] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.0 failed with error -22 [ 8.920572] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.1 failed with error -22
This problem also occurs with the latest 15-ew0000 models. I bought a new laptop and this has been a problem. Other distros suffer from this; it's a kernel issue.
This problem also occurs with hp 17_cr0xxx and fedora 36 (kernel 5.19.7-200.fc36.x86_64).
I'm going to further correct my comment, since it wasn't specific enough. Even on the latest kernel version, the CS35L41 system still doesn't work. I get the exact same errors from dmesg: [ 6.173951] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.0 failed with error -22 [ 6.173990] cs35l41-hda: probe of i2c-CSC3551:00-cs35l41-hda.1 failed with error -22 I also tried openSUSE to see if that changed anything; it didn't. This leads me to believe this is more of a general kernel issue.
This problem also occurs with hp 15-ey0xxx and Fedora 36 (kernel 5.19.15-201.fc36.x86_64).
I'm led to believe that this issue is caused by a lack of _DSD block in the ACPI table, for a number of models including Lenovo Legion 7i and Zenbook S [0]. Some relevant quirks to alsa must be made to fix this error. Alternatively, the BIOS can correct the issue by properly reporting the _DSD block. For this reason, I'd like to see if anyone is running the latest BIOS version, F.10 Rev.A (11/22/2022). It's possible that a fix is introduced by this. I'm going to test it out tonight. [0]: https://www.spinics.net/lists/alsa-devel/msg146434.html
Interesting. Complete newbie here, but I had no idea this issue affected more than HP laptops. It doesn't help optically that HP is dragging their heels on getting basic Linux support. I also wanted to note that some people have reported that if they boot into Windows first and THEN reboot to Linux, the audio works perfectly fine. Apparently, Linux can use the speakers, but doesn't know how to set them up [0]. I don't remember where, but someone theorized that if you could have Windows configure the speakers, and then copy the pin configuration on Linux and then save that, you could replicate it on startup with Linux. Probably not the best way to fix this problem anyway, so I digress. I noticed another thing: when I ran 'lspci -v | grep audio' I got: 00:1f.3 Multimedia audio controller: Intel Corporation Alder Lake PCH-P High Definition Audio Controller (rev 01) Kernel driver in use: sof-audio-pci-intel-tgl tgl. As in Tiger Lake. My laptop's chipset is Alder Lake. No clue if that actually matters, or how to switch it to an Alder Lake driver even if it did---I'd appreciate it if someone could give me some advice. These are some things I was looking into and wanted to relay them people way more knowledgeable on this stuff. Thank you. [0]: https://h30434.www3.hp.com/t5/Notebook-Audio/No-sound-from-internal-speakers-using-Linux/td-p/8478057
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This still exists on 38 latest, so the version should be updated before the end of this week to keep priority on this bug.
Bug still present in Fedora 38. Bumped version to 38 to keep bug open. Thanks rhbug
Having the same issue with an HP Envy 17 and Fedora 38.
On Fedora 39, Kernel 6.5.9-300.fc39.x86_64 and issue is still present.
Will this ever get patched?
Looks like there has been upstream work by Cirrus developers to overide broken _DSD settings in BIOS. This work has now been merged in kernel 6.8 and has been backported to kernel 6.7.1. Hopefully this should be working soon! https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.7.y&id=2b12fe9daa3e2ae2c637ad6f25de7436bbfa6571
At least on my machine, it does not work. I upgraded my kernel via the vanilla mainline repos to 6.8.0-0.rc0.20240121gt7a396820.210.vanilla.fc39.x86_64 as well as 6.8.0-0.0.next.20240119.208.vanilla.fc39.x86_64. Are these supposed to contain the fix?
(In reply to rhbug from comment #21) > At least on my machine, it does not work. I upgraded my kernel via the > vanilla mainline repos to > 6.8.0-0.rc0.20240121gt7a396820.210.vanilla.fc39.x86_64 as well as > 6.8.0-0.0.next.20240119.208.vanilla.fc39.x86_64. Are these supposed to > contain the fix? Same here, upgraded to kernel 6.8.0-0 and still no sound.
Unfortunately, according to a report on the Arch Linux forum, it appears a lot of models didn't get into the 6.8 patch and will be added in 6.9 https://bbs.archlinux.org/viewtopic.php?id=287450
Linux 6.8 is out. Once Fedora's kernel-6.8.0 is out, and the @kernel-vanilla/next starts pushing out 6.9.0, and assuming 6.9.0 does get these changes, it should be as easy as installing the vanilla kernel to fix this issue (as a temporary fix until 6.9's release and Fedora's subsequent release, which could be many weeks). https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories https://copr.fedorainfracloud.org/coprs/g/kernel-vanilla/next/builds/ You can also check this URL for a 6.9.0 inclusion: https://www.leemhuis.info/files/kernel-vanilla/repostatus.txt
The kernel vanilla repositories have released 6.9.0. Anyone here want to test if it got the fix? I tried it but it won't boot on my machine due to an odd dracut initqueue timeout - maybe luks/disk related - but shouldn't be related to the fix in question. If you want to test it, it's as easy as running: sudo dnf -y copr enable @kernel-vanilla/next sudo dnf upgrade kernel kernel-devel ( ensure 6.9.0 installed ) ( reboot into new kernel )
Never mind, the next vanilla kernel build worked for me (6.9.0-0.0.next.20240313.202.vanilla.fc39.x86_64) and DOES fix the speaker problem (they sound quite nice - a shame these B&O speakers went to waste until now). When 6.9.0 comes around on mainline, your speakers will work! The temporary fix for now is to install the vanilla kernel as noted above. I would recommend reading the wiki about the vanilla repos if you're going to install the fix before mainline 6.9.0 releases.
Just installed and speakers WORK!
It absolutely works now. Any expected time for mainline release?
Sorry, I mean, 6.9.0 in fedora's repos
That's hard to estimate, it would be whenever Linux 6.9 is officially released (plus however long Fedora takes to get it), which depends on how many changes it contains. 6.8 took about 2 months and came out 3 days ago, so best estimate would be at least 6 weeks from then. Unfortunately running on a next kernel directly after a release means testing on some pretty fresh code that hasn't been tested much, unlike later in the cycle. So if speakers are crucial to you, I would recommend installing the vanilla kernel but keeping a copy of at least one stable kernel at all times as a backup. Triple check that you never delete the stable ones in an update. After that, just keep an eye on Linux news for the 6.9 release and then you can remove the repos and update normally.
These fixes appear to be queued for 6.7.11 and 6.8.2 stable kernel updates as well.
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Currently on stable 6.8.9 and it does not have any sound. Nor does the latest @kernel-vanilla/stable-rc build: kernel-6.8.9-350.vanilla.fc40.x86_64. Only when 6.9.0 is fully on stable will this be completely resolved. Though the fixes have progressed onto @kernel-vanilla/mainline-wo-mergew as 6.9.0-0.rc7.20240511gtcf87f46f.362.vanilla.fc40.x86_64. In the meantime, this still affects Fedora 40, so this bug report could be updated to reflect that, though now it's just a waiting game until Fedora's mainline catches up to 6.9.0 for this to be resolved on default installs, so it's in essence "resolved".
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.