Created attachment 1728520 [details] dmesg output, pactl-list output and hwprobe output 1. Please describe the problem: I can't fix the no sound problem on the hp pavillon x2 detachable tablet on with fedora linux workstation 33. Other people who have the same issue, but use another linux, can solve the problem by manually providing the right UCM file for bytcr_rt5640 into /sys/share/alsa/ucm/, which is described here https://forum.level1techs.com/t/lubuntu-hp-pavilion-x2-detachable-pc-10-tablet-sound-issue/141652. Also, there is a very similar bug report here https://bugzilla.redhat.com/show_bug.cgi?id=1611529, but I can't solve it by the solution provided there. 2. What is the Version-Release number of the kernel: Linux 5.8.18-300.fc33.x86_64 x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : No, first time fedora for me, because it worked out of the box without hacking anything to either boot or install on the tablet. also, almost everything works out, except the sound. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Sound never worked, so everytime I reboot, sound still doesn't work. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Yes. 6. Are you running any modules that not shipped with directly Fedora's kernel?: I don't know. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Since I am no actual technician, I actually have almost no idea what I am doing. So I guess probably the chosen category of this bug report is wrong. :shrug:. But since it is a common issue and somehow it just doesn't seem to work with my tablet, maybe someone can help me.
Note to self, full hwprobe report is here: https://linux-hardware.org/index.php?probe=f2fb66005f HP product name "10-k010nz", specs page: https://support.hp.com/us-en/document/c04512570 Looking at the logs nothing stands out, so sound should work, but reading through: https://forum.level1techs.com/t/lubuntu-hp-pavilion-x2-detachable-pc-10-tablet-sound-issue/141652/31 That guy also never got it work. So I'm afraid that there is something special with your (and his) model ... One thing which you can try is: 1. Save all your work 2. Run the following 3 commands: sudo rm -f /var/lib/alsa/asound.state sync sudo reboot --force Note the last thing will immediately reboot the computer without the usual clean shutdown, this will stop the mixer settings from being saved giving you a clean slate wrt the mixer settings. If that does not help please do the following: sudo dnf install acpica-tools sudo acpidump -o acpidump.hp-x2-10-k010nz And attach the generated acpidump.hp-x2-10-k010nz file here. Have you tried using headphones to see if the headphones output does work ?
Good news, I was thinking about this some more and I think I know what is going on. I'll spare you the technical details. Can you try the following: 1. Reboot so that you are running the latest installed kernel (or just boot if the device is off) 2. Run "uname -r" 3. Become root (sudo su -) 4. Edit /boot/loader/entries/###################-<uname -r>.conf and add the end of the "options" line add: snd_soc_sst_bytcr_rt5640.quirk=0x543423 (and save the file_ 5. reboot 6. Do "cat /proc/cmdline" and check the snd_soc_sst_bytcr_rt5640.quirk=0x... option is there 7. Do "dmesg | grep 5640" the output should include: "bytcr_rt5640 bytcr_rt5640: quirk SSP0_AIF1 enabled" (previously this was "quirk SSP0_AIF2 enabled") 8. Test sound Note if the speakers now work, please open the gnome-control-panel sound settings and also test: 1. Test that the internal mic work: "sudo dnf install gnome-sound-recorder" Open gnome sound-recorder, make a recording and play it back 2. Plugin a headset (so 4 ring (TRRS) connector, builtin mic) and check that both the output and input device automatically switch to headphones / headset 3. Run the speaker-test in gnome's sound settings, chechk that the headphones work 4. Test that headset mic works, plug in the headset, check in gnome's sound settings that the Input Device is set to the headset and run gnome-sound-recorder again. Don't worry if any of these tests do not work, that just means that we need to adjust the quirks. Note if 3. fails, you obviously cannot test 3 and 4.
Unrelated to the sound issue, but not unimportant, your device uses an AXP288 PMIC with a micro-usb connector. A while ago a did a workaround specifically for HP x2 models with an AXP288 PMIC + a Type-C connector. This workaround matches on a product-name which starts with "HP Pavilion x2 Detachable". So that also matches your device, this workaround is pretty much wrong for your device (for one it tries to charge with 3A, which is too much for micro-usb chargers). Can you plug in the charger and then do: cat /sys/class/power_supply/axp288_charger/input_current_limit And let me know the output of that command (with the charger plugged in) ? I'm afraid that might say 3000000 which would be asking too much of the charger (most micro-usb chargers go up to 2A). Or it will say 500000 because it has detected the charger cannot handle 3000000 which means the device will not charge while running Linux as it is likely using more then 500mA all the time. Also I'm going to need the acpidump which I asked before to help fix this: sudo dnf install acpica-tools sudo acpidump -o acpidump.hp-x2-10-k010nz And attach the generated acpidump.hp-x2-10-k010nz file here.
(In reply to Hans de Goede from comment #2) > Good news, I was thinking about this some more and I think I know what is > going on. > > I'll spare you the technical details. > > Can you try the following: > > 1. Reboot so that you are running the latest installed kernel (or just boot > if the device is off) > 2. Run "uname -r" > 3. Become root (sudo su -) > 4. Edit /boot/loader/entries/###################-<uname -r>.conf > and add the end of the "options" line add: > snd_soc_sst_bytcr_rt5640.quirk=0x543423 > (and save the file_ > 5. reboot > 6. Do "cat /proc/cmdline" and check the snd_soc_sst_bytcr_rt5640.quirk=0x... > option is there > 7. Do "dmesg | grep 5640" the output should include: > "bytcr_rt5640 bytcr_rt5640: quirk SSP0_AIF1 enabled" > (previously this was "quirk SSP0_AIF2 enabled") > 8. Test sound > > Note if the speakers now work, please open the gnome-control-panel sound > settings and also test: > > 1. Test that the internal mic work: > "sudo dnf install gnome-sound-recorder" > Open gnome sound-recorder, make a recording and play it back > > 2. Plugin a headset (so 4 ring (TRRS) connector, builtin mic) and check that > both the > output and input device automatically switch to headphones / headset > > 3. Run the speaker-test in gnome's sound settings, chechk > that the headphones work > > 4. Test that headset mic works, plug in the headset, check > in gnome's sound settings that the Input Device is set to > the headset and run gnome-sound-recorder again. > > Don't worry if any of these tests do not work, that just means that > we need to adjust the quirks. Note if 3. fails, you obviously cannot > test 3 and 4. I followed your instructions, hoping I did everything right. But I guess the output of "cat /proc/cmdline" doesn't contain the desired quirk option, except I didnt understand what to look for. This is the result: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.8.18-300.fc33.x86_64 root=UUID=b078656f-93aa-470b-82cd-865cdce2be17 ro rootflags=subvol=root rhgb quiet If I do a "dmesg | grep 5640", I get the following result, without the new quirk: [root@localhost ~]# dmesg | grep 5640 [ 15.882216] bytcr_rt5640 bytcr_rt5640: quirk IN3_MAP enabled [ 15.882220] bytcr_rt5640 bytcr_rt5640: quirk realtek,jack-detect-source 2 [ 15.882223] bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-threshold-microamp 2000 [ 15.882226] bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-scale-factor 1 [ 15.882228] bytcr_rt5640 bytcr_rt5640: quirk DIFF_MIC enabled [ 15.882231] bytcr_rt5640 bytcr_rt5640: quirk SSP0_AIF2 enabled [ 15.882233] bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled [ 15.912552] bytcr_rt5640 bytcr_rt5640: snd-soc-dummy-dai <-> media-cpu-dai mapping ok [ 15.912615] bytcr_rt5640 bytcr_rt5640: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok [ 15.915336] bytcr_rt5640 bytcr_rt5640: rt5640-aif2 <-> ssp0-port mapping ok [ 15.926472] input: bytcr-rt5640 Headset as /devices/platform/80860F28:00/bytcr_rt5640/sound/card1/input22 I haven't done anything from your very first reply. I am gonna do that now.
Created attachment 1728853 [details] acpidump
(In reply to Hans de Goede from comment #1) > Note to self, full hwprobe report is here: > https://linux-hardware.org/index.php?probe=f2fb66005f > > HP product name "10-k010nz", specs page: > https://support.hp.com/us-en/document/c04512570 > > Looking at the logs nothing stands out, so sound should work, but reading > through: > https://forum.level1techs.com/t/lubuntu-hp-pavilion-x2-detachable-pc-10- > tablet-sound-issue/141652/31 > > That guy also never got it work. So I'm afraid that there is something > special with your (and his) model ... > > One thing which you can try is: > > 1. Save all your work > 2. Run the following 3 commands: > > sudo rm -f /var/lib/alsa/asound.state > sync > sudo reboot --force > > Note the last thing will immediately reboot the computer without the usual > clean shutdown, this will stop the mixer settings from being saved giving > you a clean slate wrt the mixer settings. > > If that does not help please do the following: > > sudo dnf install acpica-tools > sudo acpidump -o acpidump.hp-x2-10-k010nz > > And attach the generated acpidump.hp-x2-10-k010nz file here. > > Have you tried using headphones to see if the headphones output does work ? I did as instructed, still no sound. acpidump file is attached. Yes, I have tried plugin in headphones. I hear something, like a little buzz, sounds light a switch or something that is initialized. I have read about that in other posts. But no sound. Bluetooth headphone pairing works and sound works there. Not sure if that helps, probably not. Also, I have no idea, which card I need to have selected in the pulseaudio settings. For the upper setting "soundcard name", there is nothing selected under the profile dropdown. For the bottom setting "internal audio", that profil is automatically set to "Play HiFi quality music". The only other option I see there is "none".
(In reply to Hans de Goede from comment #3) > Unrelated to the sound issue, but not unimportant, your device uses an > AXP288 PMIC with a micro-usb connector. A while ago a did a workaround > specifically for HP x2 models with an AXP288 PMIC + a Type-C connector. > > This workaround matches on a product-name which starts with "HP Pavilion x2 > Detachable". So that also matches your device, this workaround is pretty > much wrong for your device (for one it tries to charge with 3A, which is too > much for micro-usb chargers). > > Can you plug in the charger and then do: > > cat /sys/class/power_supply/axp288_charger/input_current_limit > > And let me know the output of that command (with the charger plugged in) ? > > I'm afraid that might say 3000000 which would be asking too much of the > charger (most micro-usb chargers go up to 2A). Or it will say 500000 because > it has detected the charger cannot handle 3000000 which means the device > will not charge while running Linux as it is likely using more then 500mA > all the time. > > Also I'm going to need the acpidump which I asked before to help fix this: > > sudo dnf install acpica-tools > sudo acpidump -o acpidump.hp-x2-10-k010nz > > And attach the generated acpidump.hp-x2-10-k010nz file here. Yes, it says 3000000. :)
(In reply to Joshua Schär from comment #4) > I followed your instructions, hoping I did everything right. But I guess the > output of "cat /proc/cmdline" doesn't contain the desired quirk option, > except I didnt understand what to look for. This is the result: > > BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.8.18-300.fc33.x86_64 > root=UUID=b078656f-93aa-470b-82cd-865cdce2be17 ro rootflags=subvol=root rhgb > quiet Yes that is not what we want we want to have the " snd_soc_sst_bytcr_rt5640.quirk=0x543423" appended at the end. Did you perhaps literary edit '/boot/loader/entries/###################-<uname -r>.conf' ? With the ##### I meant replace this with whatever big hex-number was chosen for the system-id of your install (and '<uname -r>'should have been replaced with the output of "uname -r". IOW you should have edited an existing file. Also note that the "options ..." line needs to be a single line you cannot continue it on the next line, it needs to be a single long line. Another easier way of adding the quirk to the cmdline is to run: sudo grubby --update-kernel=ALL --args="snd_soc_sst_bytcr_rt5640.quirk=0x543423" I should have probably told you to use that from the start, sorry. Its just that I'm used to editing the conf files directly myself. > If I do a "dmesg | grep 5640", I get the following result, without the new > quirk: > > [root@localhost ~]# dmesg | grep 5640 > [ 15.882216] bytcr_rt5640 bytcr_rt5640: quirk IN3_MAP enabled > [ 15.882220] bytcr_rt5640 bytcr_rt5640: quirk realtek,jack-detect-source 2 > [ 15.882223] bytcr_rt5640 bytcr_rt5640: quirk > realtek,over-current-threshold-microamp 2000 > [ 15.882226] bytcr_rt5640 bytcr_rt5640: quirk > realtek,over-current-scale-factor 1 > [ 15.882228] bytcr_rt5640 bytcr_rt5640: quirk DIFF_MIC enabled > [ 15.882231] bytcr_rt5640 bytcr_rt5640: quirk SSP0_AIF2 enabled Yeah, so this one should become "quirk SSP0_AIF1 enabled" with the quirk and that will hopefully give you working sound. Also thank you for the acpidump and the input_current_limit info.
(In reply to Hans de Goede from comment #8) > (In reply to Joshua Schär from comment #4) > > I followed your instructions, hoping I did everything right. But I guess the > > output of "cat /proc/cmdline" doesn't contain the desired quirk option, > > except I didnt understand what to look for. This is the result: > > > > BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.8.18-300.fc33.x86_64 > > root=UUID=b078656f-93aa-470b-82cd-865cdce2be17 ro rootflags=subvol=root rhgb > > quiet > > Yes that is not what we want we want to have the " > snd_soc_sst_bytcr_rt5640.quirk=0x543423" appended at the end. > > Did you perhaps literary edit > '/boot/loader/entries/###################-<uname -r>.conf' ? With the ##### > I meant replace this with whatever big hex-number was chosen for the > system-id of your install (and '<uname -r>'should have been replaced with > the output of "uname -r". IOW you should have edited an existing file. Also > note that the "options ..." line needs to be a single line you cannot > continue it on the next line, it needs to be a single long line. > > Another easier way of adding the quirk to the cmdline is to run: > > sudo grubby --update-kernel=ALL > --args="snd_soc_sst_bytcr_rt5640.quirk=0x543423" > > I should have probably told you to use that from the start, sorry. Its just > that I'm used to editing the conf files directly myself. > > > If I do a "dmesg | grep 5640", I get the following result, without the new > > quirk: > > > > [root@localhost ~]# dmesg | grep 5640 > > [ 15.882216] bytcr_rt5640 bytcr_rt5640: quirk IN3_MAP enabled > > [ 15.882220] bytcr_rt5640 bytcr_rt5640: quirk realtek,jack-detect-source 2 > > [ 15.882223] bytcr_rt5640 bytcr_rt5640: quirk > > realtek,over-current-threshold-microamp 2000 > > [ 15.882226] bytcr_rt5640 bytcr_rt5640: quirk > > realtek,over-current-scale-factor 1 > > [ 15.882228] bytcr_rt5640 bytcr_rt5640: quirk DIFF_MIC enabled > > [ 15.882231] bytcr_rt5640 bytcr_rt5640: quirk SSP0_AIF2 enabled > > Yeah, so this one should become "quirk SSP0_AIF1 enabled" with the quirk and > that will hopefully give you working sound. > > Also thank you for the acpidump and the input_current_limit info. Hans, you did it! But wtf did I do wrong? I actually edited an existing file. I made sure it's the file with the same kernel I am running at the moment (5.8.18-300 and not 5.8.15-301). I appended the quirk with Shift+A. Guess that was wrong :) Thank you so much. I will contact the guy from the other post and refer him to this bug. Have a nice rest of the week! Cheers
(In reply to Joshua Schär from comment #9) > Hans, you did it! > But wtf did I do wrong? I actually edited an existing file. I made sure it's > the file with the same kernel I am running at the moment (5.8.18-300 and not > 5.8.15-301). I appended the quirk with Shift+A. Guess that was wrong :) > > Thank you so much. I will contact the guy from the other post and refer him > to this bug. Erm, your celebrating a little to early. But I'm glad that your sound is working now. To make this work out if the box with newer kernels (both for you and for all other possible linux users), a patch needs to be written to automatically apply the quirk on your model laptop. The driver has a long list of similar quirks already, so I just need to write a patch to add a new one. I can provide you with a test-kernel build with the patch added once the patch is done. But first we need to figure out the right quirk settings for your device. We've got the most important bit working now, but the quirk settings also influence if jack-detect (headphones being plugged in) and the internal microphone work. The settings I gave you for those are guessed and before I can write a kernel patch to fix this properly we need to confirm they are correct. So as I mentioned in a previous comment, please run the following tests: 1. Test that the internal mic work: "sudo dnf install gnome-sound-recorder" Open gnome sound-recorder, make a recording and play it back 2. Plugin a headset (so 4 ring (TRRS) connector, builtin mic) and check that both the output and input device automatically switch to headphones / headset 3. Run the speaker-test in gnome's sound settings, chechk that the headphones work 4. Test that headset mic works, plug in the headset, check in gnome's sound settings that the Input Device is set to the headset and run gnome-sound-recorder again. Don't worry if any of these tests do not work, that just means that we need to adjust the quirks. Note if 2. fails, you obviously cannot test 3 and 4. > Have a nice rest of the week! Thank you, you too.
> 1. Test that the internal mic work: > "sudo dnf install gnome-sound-recorder" > Open gnome sound-recorder, make a recording and play it back It doesn't record anything. > 2. Plugin a headset (so 4 ring (TRRS) connector, builtin mic) and check that > both the output and input device automatically switch to headphones / > headset It doesn't automatically switch. > 3. Run the speaker-test in gnome's sound settings, chechk that the > headphones work Playing back sound via headphones works. But I need to switch manually to the headphones channel. > > Have a nice rest of the week! > > Thank you, you too. Thanks.
Ok, so your device probably needs the exact same settings as my HP x2 10-n000nd, can you try: sudo grubby --update-kernel=ALL --args="snd_soc_sst_bytcr_rt5640.quirk=0x502f30" Grubby is smart enough to recognize the part before the '=' is the same and to update the existing parameter.
(In reply to Hans de Goede from comment #12) > Ok, so your device probably needs the exact same settings as my HP x2 > 10-n000nd, can you try: > > sudo grubby --update-kernel=ALL > --args="snd_soc_sst_bytcr_rt5640.quirk=0x502f30" This did the trick. All works: - recording from device - switching automatically to headphones output and input - recording and playing back on headphones works too What can I do now?
(In reply to Joshua Schär from comment #13) > What can I do now? I'll prepare a patch and a test kernel-build with that patch added for you to test tomorrow. Then once I have received positive testing feedback from you about that test kernel, then I'll submit the patch upstream and then after a while all recent kernels will do the right thing automatically :)
Ok, here is the promised test kernel: https://koji.fedoraproject.org/koji/taskinfo?taskID=55535491 Here are some generic instructions for installing a kernel directly from kojo (the Fedora build-system): https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Note before rebooting in the new kernel run: sudo grubby --update-kernel=ALL --remove-args="snd_soc_sst_bytcr_rt5640.quirk" To remove the quirk, note you could replace ALL with the test kernel version to keep the quirk on the others, but I'm not sure what grubby expects there... Once you have booted the new kernel, do: "cat /proc/cmdline" and check that the quirk is not there. And then re-test the sound. This test kernel also includes a patch to disable the workaround for the models with a Type-C charging connection on your model, so please also connect a charger and do: cat /sys/class/power_supply/axp288_charger/input_current_limit This should say 2000000 now, as one would expect with a micro-usb charger.
(In reply to Hans de Goede from comment #15) > Ok, here is the promised test kernel: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=55535491 > > Here are some generic instructions for installing a kernel directly from > kojo (the Fedora build-system): > > https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Hi Hans Should I download Kernel 5? Because in the instructions it says Kernel 4. Also, I am having Wifi issues suddenly. After 5 minutes or so, Wifi can't be connected anymore. Only reboot fixes the issue.
(In reply to Joshua Schär from comment #16) > Should I download Kernel 5? Because in the instructions it says Kernel 4. Yes, I guess I wrote those instructions when we were still shipping 4.y.z kernels. I've updated the instructions now. > Also, I am having Wifi issues suddenly. After 5 minutes or so, Wifi can't be > connected anymore. Only reboot fixes the issue. That is almost certainly unrelated. Still quite annoying. What does: dmesg | grep brcmfmac say ? And what does: dmesg | grep 8723 say ? And what is the output of uname -a ? Fedora currently is testing 5.9 kernels and soon the official Fedora kernels will be 5.9 based instead of 5.8. I wonder if you already made the jump and if that is causing the issue. Note the test kernel build which I did is 5.9 based.
(In reply to Hans de Goede from comment #17) > (In reply to Joshua Schär from comment #16) > > Should I download Kernel 5? Because in the instructions it says Kernel 4. > > Yes, I guess I wrote those instructions when we were still shipping 4.y.z > kernels. I've updated the instructions now. If I want to upgrade the kernel, it says the following (sorry its in german): [tablet@localhost kernel-update]$ sudo rpm -ivh --oldpackage kernel*.rpm | cat > output.txt Fehler: Fehlgeschlagene Abhängigkeiten: kernel-modules-uname-r = 5.9.8-200.rhbz1896924.fc33.x86_64 wird benötigt von kernel-5.9.8-200.rhbz1896924.fc33.x86_64 > dmesg | grep brcmfmac --> no output. > dmesg | grep 8723 ```[tablet@localhost kernel-update]$ dmesg | grep 8723 [ 14.912192] Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723 [ 14.916515] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_fw.bin [ 14.920137] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_config-OBDA8723.bin [ 15.543187] r8723bs: module is from the staging directory, the quality is unknown, you have been warned. [ 15.558357] RTL8723BS: module init start [ 15.558361] RTL8723BS: rtl8723bs v4.3.5.5_12290.20140916_BTCOEX20140507-4E40 [ 15.558362] RTL8723BS: rtl8723bs BT-Coex version = BTCOEX20140507-4E40 [ 15.740865] RTL8723BS: rtw_ndev_init(wlan0) [ 15.741578] RTL8723BS: module init ret =0 [ 28.375533] rtl8723bs: acquire FW from file:rtlwifi/rtl8723bs_nic.bin [ 31.759432] RTL8723BS: rtw_set_802_11_connect(wlan0) fw_state = 0x00000008 [ 39.365733] RTL8723BS: rtw_set_802_11_connect(wlan0) fw_state = 0x00000008 [ 39.495344] RTL8723BS: start auth [ 39.540485] RTL8723BS: auth success, start assoc [ 39.563719] RTL8723BS: rtw_cfg80211_indicate_connect(wlan0) BSS not found !! [ 39.563743] RTL8723BS: assoc success [ 39.671762] RTL8723BS: send eapol packet [ 39.680060] RTL8723BS: send eapol packet [ 39.682043] RTL8723BS: set pairwise key camid:4, addr:54:67:51:c0:78:ab, kid:0, type:AES [ 39.683501] RTL8723BS: set group key camid:5, addr:54:67:51:c0:78:ab, kid:1, type:TKIP [ 1250.913289] RTL8723BS: suspend start [ 1250.913373] RTL8723BS: rtw_cmd_thread(wlan0) stop_req:1, break [ 1250.914792] RTL8723BS: rtw_dev_unload: driver not in IPS [ 1250.925083] RTL8723BS: rtw suspend success in 12 ms [ 1283.290654] RTL8723BS: resume start [ 1283.301027] rtl8723bs: acquire FW from file:rtlwifi/rtl8723bs_nic.bin [ 1287.437050] RTL8723BS: rtw_resume_common:0 in 4146 ms [ 1288.075881] Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723 [ 1288.080305] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_fw.bin [ 1288.080342] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_config-OBDA8723.bin [ 1289.591791] RTL8723BS: rtw_set_802_11_connect(wlan0) fw_state = 0x00000008 [ 1297.774382] RTL8723BS: rtw_set_802_11_connect(wlan0) fw_state = 0x00000008 [ 1297.796435] RTL8723BS: start auth [ 1297.799983] RTL8723BS: auth success, start assoc [ 1297.820528] RTL8723BS: rtw_cfg80211_indicate_connect(wlan0) BSS not found !! [ 1297.820540] RTL8723BS: assoc success [ 1298.029912] RTL8723BS: send eapol packet [ 1298.037221] RTL8723BS: send eapol packet [ 1298.037423] RTL8723BS: set pairwise key camid:4, addr:54:67:51:c0:78:ab, kid:0, type:AES [ 1298.039026] RTL8723BS: set group key camid:5, addr:54:67:51:c0:78:ab, kid:1, type:TKIP [ 3456.140500] RTL8723BS: suspend start [ 3456.140546] RTL8723BS: rtw_cmd_thread(wlan0) stop_req:1, break [ 3456.142701] RTL8723BS: rtw_dev_unload: driver not in IPS [ 3456.153583] RTL8723BS: rtw suspend success in 13 ms [ 5043.570748] RTL8723BS: resume start [ 5043.580236] rtl8723bs: acquire FW from file:rtlwifi/rtl8723bs_nic.bin [ 5047.585963] RTL8723BS: rtw_resume_common:0 in 4015 ms [ 5048.223648] Bluetooth: hci0: RTL: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723 [ 5048.227956] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_fw.bin [ 5048.232356] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723bs_config-OBDA8723.bin [ 5049.818580] RTL8723BS: rtw_set_802_11_connect(wlan0) fw_state = 0x00000008 [ 5057.132929] RTL8723BS: rtw_set_802_11_connect(wlan0) fw_state = 0x00000008 [ 5057.262500] RTL8723BS: start auth [ 5057.270557] RTL8723BS: auth success, start assoc [ 5057.293294] RTL8723BS: rtw_cfg80211_indicate_connect(wlan0) BSS not found !! [ 5057.293324] RTL8723BS: assoc success [ 5057.445835] RTL8723BS: send eapol packet [ 5057.452125] RTL8723BS: send eapol packet [ 5057.452543] RTL8723BS: set pairwise key camid:4, addr:54:67:51:c0:78:ab, kid:0, type:AES [ 5057.456095] RTL8723BS: set group key camid:5, addr:54:67:51:c0:78:ab, kid:1, type:TKIP``` > And what is the output of uname -a ? [tablet@localhost kernel-update]$ uname -a Linux localhost.localdomain 5.8.18-300.fc33.x86_64 #1 SMP Mon Nov 2 19:09:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
(In reply to Hans de Goede from comment #17) > (In reply to Joshua Schär from comment #16) > > Should I download Kernel 5? Because in the instructions it says Kernel 4. > > Yes, I guess I wrote those instructions when we were still shipping 4.y.z > kernels. I've updated the instructions now. Wait, I didn't download all the files. `sudo rpm -ivh --oldpackage kernel*.rpm` seems to work. I will reboot now.
(In reply to Hans de Goede from comment #15) > Ok, here is the promised test kernel: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=55535491 > > Here are some generic instructions for installing a kernel directly from > kojo (the Fedora build-system): > > https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt > > Note before rebooting in the new kernel run: > > sudo grubby --update-kernel=ALL > --remove-args="snd_soc_sst_bytcr_rt5640.quirk" > > To remove the quirk, note you could replace ALL with the test kernel version > to keep the quirk on the others, but I'm not sure what grubby expects > there... > > Once you have booted the new kernel, do: "cat /proc/cmdline" and check that > the quirk is not there. > > And then re-test the sound. Sound works! Mic works! Headphones work! Headphone mic works! I checked and made sure, that the quirk is not included in /proc/cmdline. I also checked uname -r to see the kernel I booted. It's the new 5.9.8-200. > This test kernel also includes a patch to disable the workaround for the > models with a Type-C charging connection on your model, so please also > connect a charger and do: > > cat /sys/class/power_supply/axp288_charger/input_current_limit > > This should say 2000000 now, as one would expect with a micro-usb charger. It indeed does output 2000000 now. Thank you so much for your work!
Thank you for testing. I'll submit the sound-quirk and the charger-fix patches both upstream then, these should both get backported to one of the official 5.9.z releases once they have been accepted. In the mean time you can either keep using my test-kernel, or re-add the quirk on the commandline with grubby. > Thank you so much for your work! You're welcome I'm always happy when I can help someone to get their hardware to work well with Linux, and since you've stuck with me to the entire process I now also have fixes ready to add to the mainline kernel, so that e.g. Fedora 34 will just work out of the box on these devices. About the wifi thing: > > dmesg | grep 8723 > > ```[tablet@localhost kernel-update]$ dmesg | grep 8723 > [ 15.558361] RTL8723BS: rtl8723bs <snip> > > And what is the output of uname -a ? > > [tablet@localhost kernel-update]$ uname -a > Linux localhost.localdomain 5.8.18-300.fc33.x86_64 #1 SMP Mon Nov 2 19:09:05 > UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Ok so you have a rtl8723bs wifi chip and you are still on 5.8.z so weird that this regressed. First if all, can you run 5.9.8 for a while, with some luck whatever it was has been fixed there and then there is nothing which we need to do. If this still happens with 5.9.8, can you: 1. Find out (by booting older 5.8.z kernels) between which 2 kernel versions this broke 2. File a new bug for this (and let me know the bug nummer) ?
> About the wifi thing: > > > > dmesg | grep 8723 > > > > ```[tablet@localhost kernel-update]$ dmesg | grep 8723 > > [ 15.558361] RTL8723BS: rtl8723bs > > <snip> What does <snip> mean? > > > And what is the output of uname -a ? > > > > [tablet@localhost kernel-update]$ uname -a > > Linux localhost.localdomain 5.8.18-300.fc33.x86_64 #1 SMP Mon Nov 2 19:09:05 > > UTC 2020 x86_64 x86_64 x86_64 GNU/Linux > > Ok so you have a rtl8723bs wifi chip and you are still on 5.8.z so weird > that this regressed. What does that mean? That it booted back to 5.8 or that wifi uses something from 5.8? > First if all, can you run 5.9.8 for a while, with some luck whatever it was > has been fixed there and then there is nothing which we need to do. How can I set 5.9.8 to be the default boot kernel? > If this still happens with 5.9.8, can you: > > 1. Find out (by booting older 5.8.z kernels) between which 2 kernel versions > this broke > 2. File a new bug for this (and let me know the bug nummer) ? Sure, I will do that, if the wifi problem persists with 5.9.8.
> > And what is the output of uname -a ? > > [tablet@localhost kernel-update]$ uname -a > Linux localhost.localdomain 5.8.18-300.fc33.x86_64 #1 SMP Mon Nov 2 19:09:05 > UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Ah wait, this post was from before the kernel update. You responded to this post and I did not update this comment.
(In reply to Joshua Schär from comment #22) > > About the wifi thing: > > > > > > dmesg | grep 8723 > > > > > > ```[tablet@localhost kernel-update]$ dmesg | grep 8723 > > > [ 15.558361] RTL8723BS: rtl8723bs > > > > <snip> > > What does <snip> mean? That I removed part of the text which I was quoting. > > > > And what is the output of uname -a ? > > > > > > [tablet@localhost kernel-update]$ uname -a > > > Linux localhost.localdomain 5.8.18-300.fc33.x86_64 #1 SMP Mon Nov 2 19:09:05 > > > UTC 2020 x86_64 x86_64 x86_64 GNU/Linux > > > > Ok so you have a rtl8723bs wifi chip and you are still on 5.8.z so weird > > that this regressed. > > What does that mean? That it booted back to 5.8 or that wifi uses something > from 5.8? You ran this before updating to the test kernel. That is ok as I wanted to know with which version you were seeing wifi problems. > > First if all, can you run 5.9.8 for a while, with some luck whatever it was > > has been fixed there and then there is nothing which we need to do. > > How can I set 5.9.8 to be the default boot kernel? It should be the default already. The last installed kernel is the default. Since it is also the newest, you can also make it the default by doing: sudo grub2-set-default 0 And if you want to boot the second kernel in order from new to old do: sudo grub2-set-default 1 etc.
The sound quirk fixing the sound not working issue has been accepted upstream and should get merged into a 5.10-rc# kernel release soon: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?h=for-5.10 The 5.10 kernel will become available for Fedora (in the updates repo) about 6 weeks after it has been released. In the mean time you can use the cmdline quirk as a workaround, so I'm closing this bug. If you are still seeing issues with the wifi, please file a separate bug for that.