I am using a Thinkpad X200T (further information at https://www.thinkwiki.org/wiki/Category:X200_Tablet let me know if I should provide any further command output). After updating the kernel to 4.10, following behavior can be observed: 1. If the laptop is running on power cable, everything is fine. 2. If the laptop is running from battery, the internal motherboard speaker does its beeps in full volume even if the volume is set to low or even muted from user space. 3. If the laptop is sent to suspend2ram while on power cable, the problem won't appear at wake up, even if waking up on battery. If the laptop is sent to suspend2ram while on battery, the problem will appear at wake up, even when waking up on power cable. 4. The problem appears in all minor versions of 4.10 and 4.11 but did not appear in versions of 4.9 and earlier, so it is a regression which happened in 4.10.
(In reply to Michael Kogan from comment #0) > I am using a Thinkpad X200T (further information at > https://www.thinkwiki.org/wiki/Category:X200_Tablet let me know if I should > provide any further command output). After updating the kernel to 4.10, > following behavior can be observed: > > 1. If the laptop is running on power cable, everything is fine. > 2. If the laptop is running from battery, the internal motherboard speaker > does its beeps in full volume even if the volume is set to low or even muted > from user space. this does not sound like an ACPI problem. > 3. If the laptop is sent to suspend2ram while on power cable, the problem > won't appear at wake up, even if waking up on battery. and even if boot with power cable detached? so there are two conditions that both can trigger the problem 1. boot on battery 2. suspend when running on battery right?
Thanks a lot for the quick reply! > this does not sound like an ACPI problem. This might be very well true, I cannot really tell where the origin of the problem is, it was just my best guess. > and even if boot with power cable detached? > so there are two conditions that both can trigger the problem > 1. boot on battery > 2. suspend when running on battery > right? It's just that the laptop seems to remember the power state when falling asleep. So: No matter if it has been booted on battery or on power cable, when waking up, it will beep or not beep according to the power status which was given when falling asleep. So, if we want to see if it will beep at wake up (which is the most annoying situation for me), this table will tell: Falling asleep | Waking up | Result On cable | On cable | No problem On cable | On battery | No problem On battery | On cable | Problem On battery | On battery | Problem So, it memorizes the status before falling asleep and acts accordingly, no matter the status at waking up.
Sorry, this bugzilla software is a bit confusing - whenever I want to comment, I need to choose a "resolved as" status though the problem is not yet resolved...
You don't need to touch that field, just leave it as Needinfo or Assigned. (In reply to Michael Kogan from comment #2) > Thanks a lot for the quick reply! > > > this does not sound like an ACPI problem. > > This might be very well true, I cannot really tell where the origin of the > problem is, it was just my best guess. > > > > and even if boot with power cable detached? > > > so there are two conditions that both can trigger the problem > > 1. boot on battery > > 2. suspend when running on battery > > right? > > It's just that the laptop seems to remember the power state when falling > asleep. So: No matter if it has been booted on battery or on power cable, > when waking up, it will beep or not beep according to the power status which > was given when falling asleep. So, if we want to see if it will beep at wake > up (which is the most annoying situation for me), this table will tell: > > Falling asleep | Waking up | Result > > On cable | On cable | No problem > On cable | On battery | No problem > On battery | On cable | Problem > On battery | On battery | Problem > > So, it memorizes the status before falling asleep and acts accordingly, no > matter the status at waking up. One important thing is where this beep comes from, BIOS or OS? During boot, does it beep before grub? Or after loading Linux kernel image?
if it is the first case, then I guess there is nothing we can do as this beep seems to be triggered by BIOS. BTW, do you have windows installed? Does it also beep in windows?
No, there is no beep at all while booting, neither before nor after grub. Beeps appear when going to sleep, waking up, battery being low. Unfortunately I have no Windows installed, but the problem is not present in kernels up to 4.9, then appears in 4.10 and 4.11 so it really seems like a regression in 4.10.
I see. So the problem is that 1. Beeps don't exist in 4.9 2. Beeps are always there in 4.10 and later, when suspending/resuming/battery_low, even if you muted, when suspend with power cable unplugged. I was not aware of such issue before, and I did hear beeps on some platforms before, and I always thought this comes from BIOS, but as this is a regression, please run git bisect to find out which commit introduces the problem, this is the most efficient way to find out what the problem is.
Exactly! I'm just a regular user and am a bit lost at the kernel git repo. Could you please point me to the first and last commit between which I should bisect? Thanks for your assistance so far!
Ah, I googled and found out that there is some kind of automated mechanism for the bisection, I will have another look myself.
Hi, Michael, is there any update?
Hi, thanks for asking! :) I am trying to figure out if it is possible to build the test kernels using the package management tools - asked on the forums but got no reply so far. Probably I will just do it by hand now...
Asked on another forums and got a reply now, it's still in the workings but looks like the problems are near to be sorted out: https://bbs.archlinux.org/viewtopic.php?pid=1722213
I'm sorry that the bisection is taking so long. I am stuck at a range of commits which lead to failure to load modules at boot - already skipped three commits and still cannot get past this problem. Is there some nifty way to jump out of this problematic commit range? Here is my "bisection journal" so far: 1. f4000cd99750065d5177555c0a805c97174d1b9f bad 2. 7079efc9d3e7f1f7cdd34082ec58209026315057 good 3. a67485d4bf97918225dfb5246e531643755a7ee1 bad --- from here on: CONFIG_MODVERSIONS=y ---- 4. 5e0df3a08f3d17485a5081634902424c6834e001 good 5. bfd5be0f9e0cdcaafaeaa1d59fbcfb5bacb1105a good 6. 7cd54aa8438947602cf68eda1db327822b9b8e6b skip 6'. c8e52ba5e2d6df5acaaeedda20d74f4ec3adcc82 skip 6''. fd00144301d64f1742541a3c5e64cd1c51f39c55 skip 6'''. bed5ab6375cd556d93661bbcea0d18c109c50df1
I am finally done with the bisection. Here is my complete "bisection journal": 1. f4000cd99750065d5177555c0a805c97174d1b9f bad 2. 7079efc9d3e7f1f7cdd34082ec58209026315057 good 3. a67485d4bf97918225dfb5246e531643755a7ee1 bad --- from here on: CONFIG_MODVERSIONS=y ---- 4. 5e0df3a08f3d17485a5081634902424c6834e001 good 5. bfd5be0f9e0cdcaafaeaa1d59fbcfb5bacb1105a good 6. 7cd54aa8438947602cf68eda1db327822b9b8e6b skip (desktop and TTY fail) 6'. c8e52ba5e2d6df5acaaeedda20d74f4ec3adcc82 skip (desktop and TTY fail) 6''. fd00144301d64f1742541a3c5e64cd1c51f39c55 skip (desktop and TTY fail) 6'''. bed5ab6375cd556d93661bbcea0d18c109c50df1 skip (desktop and TTY fail) 6''''. bdda9dd67445707a39ebb6d2be84dfb89ef0dea1 good 7. f7cc87413b389c49e5bbc93aa65e6e67f475fb78 good 8. 8a10c06a20ec8097a68fd7a4a1c0e285095b4d2f skip (desktop and TTY fail) 8'. d6d20012e116904065d192be6146040c99c03c3c skip (desktop and TTY fail) 8''. 46992d6b55b558ac4128c1f846de3cfddfa7cf7c skip (desktop and TTY fail) 8'''. d65cfe9094ba66b8a3c7b80823ba9229759b119d probably good (desktop and TTY worked once) 9. fecc8c0ebd30c41cc66303b6f9476481c5d6d260 bad 10. 984edbdccc6ff01b953492f72296685ce3ea2497 skip (build fails) 10'. 7a3ba767f6bf9d98f1c823417908719af4a22a65 skip (desktop and TTY fail) 10''. 1d9174fbc55ec99ccbfcafa3de2528ef78a849aa probably bad (desktop and TTY worked once) 11. b1a60995a684f2b6052cda640b0704361ab40089 skip (desktop and TTY fail) 11'. 8812872960824681147fad051e6e1406fdfa07f9 skip (desktop and TTY fail) 11''. 216ef0b6b8c7f041a618913e94da52c3fdf82a99 skip (desktop and TTY fail) 11'''. 62006c1702b3b1be0c0726949e0ee0ea2326be9c skip (desktop and TTY fail) 11''''. a8636c89648ab12e59d8f3aa667ec76fc96fd643 skip (desktop and TTY fail) Here is the git bisect output after the last step: There are only 'skip'ped commits left to test. The first bad commit could be any of: b1a60995a684f2b6052cda640b0704361ab40089 216ef0b6b8c7f041a618913e94da52c3fdf82a99 8812872960824681147fad051e6e1406fdfa07f9 62006c1702b3b1be0c0726949e0ee0ea2326be9c a8636c89648ab12e59d8f3aa667ec76fc96fd643 1d9174fbc55ec99ccbfcafa3de2528ef78a849aa Many commits had to be skipped, the symptoms were always the same: The system booted into a black screen with a spinning cursor ("hour glass"). If I tried to access the TTY using Ctrl+Alt+Fn I got into a completely black screen and the machine locked up. So I couldn't think of anything better than to skip those commits. Please let me know if I can do anything else to help hunt down this bug!
Can you make use of the bisection or is there anything else I should do?
the last two commits seem suspecious. could you please revert 1d9174fbc55ec99ccbfcafa3de2528ef78a849aa first and see if the problem exists. if no, please revert a8636c89648ab12e59d8f3aa667ec76fc96fd643 and see if the problem exists.
I get the following output: $ git revert 1d9174fbc55ec99ccbfcafa3de2528ef78a849aa HEAD detached at a8636c89648a You are currently bisecting, started from branch 'makepkg'. nothing to commit, working tree clean What does this mean? The branch name 'makepkg' is probably due to the fact that I build the kernels using makepkg, the package build tool in Arch Linux.
maybe that's because you are in a git bisect... try revert again after "git bisect reset"
This is what I get: $ git bisect reset Previous position of HEAD was a8636c89648a... PM / Runtime: Don't allow to suspend a device with an active child Changed to branch 'makepkg' $ git revert 1d9174fbc55ec99ccbfcafa3de2528ef78a849aa On branch makepkg nothing to commit, working tree clean
that's because a8636c89648a is before 1d9174fbc55ec99ccbfcafa3de2528ef78a849aa. that's okay. please just build the kernel using your current head (a8636c89648a) and see if the problem still exists. If yes, please run git reset --hard HEAD~1 and see if the problem still exists.
Sorry that I'm stealing your time, unfortunately I only know very basic git usage... I started the building process again but it looks like, since I did a reset of the bisection process it is now at revision 69973b830859bc6529a7a0468ba0d80ee5117826 (again at the newest revision?) How can I come back to a8636c89648a? Should I just repeat the complete bisection process following my bisection journal (I wouldn't have to build all the kernels again since I already know which is good, bad or needs to be skipped)?
to confirm if the problem is caused by the two suspicious commits, please 1. run "git checkout 1d9174fbc55ec99ccbfcafa3de2528ef78a849aa", and build your kernel to see if the problem exists. 1. run "git checkout a8636c89648ab12e59d8f3aa667ec76fc96fd643", and build your kernel to see if the problem exists. 1. run "git checkout 8812872960824681147fad051e6e1406fdfa07f9", and build your kernel to see if the problem exists.
Sorry for the delay! 1d9174fbc55ec99ccbfcafa3de2528ef78a849aa fails to compile with LD [M] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/rtl8821ae.o LD drivers/net/wireless/built-in.o LD drivers/net/built-in.o LD drivers/built-in.o LD vmlinux.o MODPOST vmlinux.o GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o kernel/built-in.o: In function `update_wall_time': (.text+0x7f067): undefined reference to `____ilog2_NaN' make: *** [Makefile:969: vmlinux] Error 1 Trying a8636c89648ab12e59d8f3aa667ec76fc96fd643 now.
Exactly the same error for a8636c89648ab12e59d8f3aa667ec76fc96fd643... Is this suspicious? Trying 8812872960824681147fad051e6e1406fdfa07f9 now!
Aand the same error for 8812872960824681147fad051e6e1406fdfa07f9. I think, I am doing something wrong... Below is the output I get from the git checkout command, is this correct? $ git checkout a8636c89648ab12e59d8f3aa667ec76fc96fd643 Note: checking out 'a8636c89648ab12e59d8f3aa667ec76fc96fd643'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at a8636c89648a... PM / Runtime: Don't allow to suspend a device with an active child
(In reply to Michael Kogan from comment #25) > Aand the same error for 8812872960824681147fad051e6e1406fdfa07f9. what error? you mean the build error? try save your .config file, and then run make clean and mrproper, and then copy your saved .config file to kernel source directory and rebuild. thanks, rui
Yes, I meant the build error. I did run make clean and make mrproper, then switched to the first of the three commits in question and built the kernel, however I again got the same build error. I need to go into a bit more detail though, because it might be that the way I am building the kernel has something to do with the error. Namely, I am building the kernel using package management tools in Arch Linux (makepkg). This is the output I get: $ make clean CLEAN . CLEAN arch/x86/entry/vdso CLEAN certs CLEAN usr CLEAN arch/x86/tools CLEAN .tmp_versions $ make mrproper CLEAN scripts/basic CLEAN scripts/kconfig CLEAN scripts/mod CLEAN scripts CLEAN include/config include/generated arch/x86/include/generated CLEAN .config .config.old .version $ git checkout 1d9174fbc55ec99ccbfcafa3de2528ef78a849aa Note: checking out '1d9174fbc55ec99ccbfcafa3de2528ef78a849aa'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at 1d9174fbc55e... PM / Runtime: Defer resuming of the device in pm_runtime_force_resume() $ makepkg # this is the command building the kernel using package management -> Creating working copy of linux git repo... Previous HEAD position was 1d9174fbc55e... PM / Runtime: Defer resuming of the device in pm_runtime_force_resume() Switched to and reset branch 'makepkg' It then continues with compiling and after a long time fails with the error in my previous comment. However, though the "reset branch 'makepkg'" looks suspicious, makepkg is exactly how I build all the kernels during the bisection and, though not all of them built successfully, most of them did and rarely did different commits lead to the same error... Is it possibly that the three commits in question now indeed all fail to build with the same error?
Stupid me, it was a problem with the new GCC version in Arch: https://bbs.archlinux.org/viewtopic.php?pid=1722233#p1722233 Initially, I downgraded GCC to be able to do the bisection but then forgot about it and it got updated at some point. Now I downgraded GCC to 6.3.x again and the compilation runs. I will report the test results for the three revisions you mentioned above asap. Sorry for the confusion!
Sorry for the delay, finally I could test the three revisions you mentioned. Unfortunately, all three of them led to the problem I described above (black screen with spinning mouse cursor, complete freeze when trying to change to a TTY). Please let me know what I can do to help find the root of the problem!
so the system fails even before you hear the beep? hmmm, how about this? first please check if the problem still exists in the latest upstream kernel, if yes, please try different pm_test modes and check if you can hear the beep.
Yes, it fails already at boot, so I have no possibility to go to suspend to RAM mode. I tested the pm_test modes using the 4.14 RC0 kernel (package linux414-4.14rc0.170909.0e271fd) from the Manjaro repos. I get beeps with core, processors and platform modes; no beeps with devices and freezer modes.
Is there anything else, I can do to help troubleshoot this issue?
Please re-test with the latest upstream kernel, 4.14-rc2 If that fails, please try the latest Linux-4.13.y stable kernel from Greg KH. Finally, since this is related to operations handled by the Embedded Controller, please verify that you are running the latest BIOS.
Guys, if our communication continues this way, I will test latest kernel versions every two weeks without any progress (sorry for the late reply btw.). :) I now tested the latest 4.14 and 4.13 versions available through package management (this is quickly done without me compiling the kernels again): 4.13.3 and 4.14.rc1.20170920.g820bf5c 4.13.3 has the beep issue. 4.14.rc1 freezes the machine some seconds after boot so I cannot test the suspend (If I try to use suspend, it freezes immediately). My BIOS version is indeed quite old: 2.07 (this is the latest 2.xx version). The latest available BIOS version is 3.21, here is the changelog by Lenovo: https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/7wuj43us.txt I am really dependent on my laptop staying functional so I am a bit afraid of bricking it during a BIOS update. From my perspective the problem should lie somewhere in one of the commits between kernel 4.9 and 4.10 which came out of the bisection I did. From 4.10 on all kernel versions showed this problem. Please please, could somebody have a glance at the corresponding code pieces, maybe the problem is easy to spot? Luckily, 4.9 seems to stay for over one more year, but I really intend to use my good old laptop longer than that!
(In reply to Michael Kogan from comment #31) > > I tested the pm_test modes using the 4.14 RC0 kernel (package > linux414-4.14rc0.170909.0e271fd) from the Manjaro repos. I get beeps with > core, processors and platform modes; no beeps with devices and freezer modes. this is interesting. system beeps with platform mode, but does not beep with devices mode. please echo echo platform > /sys/power/pm_test; echo freeze > /sys/power/state and echo none > /sys/power/pm_test; echo freeze > /sys/power/state can you hear the beep in these two cases?
No, I can't, in both cases. But if I do echo platform > /sys/power/pm_test and then just close the laptop lid, then open it again, it beeps. I see the "sleep" LED blinking between closing and opening as if it is trying to go to suspend to RAM but doesn't fully manage to. This is how I tested the other modes as well which led to my report in comment #31.
Is there any further testing I can do to help get this fixed?
Please, guys, don't leave me hanging with this! :) I am now hit by this bug on the 4.9 kernel: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861419 But I cannot update to newer kernels due to the beep bug...
just curious, as this is a regression, so in the previous working kernel, 1. you can always hear the beep if the volume is not muted 2. you can not hear the beep if the volume is muted is that true?
Yes, exactly, that was the behaviour with kernels up to 4.9! I have now found out that the beeps can be turned off in the BIOS, so I turned them off completely and updated to 4.14. So, though the bug is not fixed, my problem is somewhat fixed. :)
if the beep is gone when muted, it seems that this is a sound problem rather than ACPI issue. Bug reassigned.
It's not gone when muted from within Linux, only if the beep tone is disabled from BIOS completely (and in this case it is gone completely, no matter what you do in Linux).
I'm confused. you have confirmed that in the working kernel, the beep can be controlled within Linux, no?
No. :) Which comment do you refer to? In 4.9 and earlier (working) it can be controlled within Linux. In 4.10 and later (broken) it cannot be controlled within Linux. In any kernel you can switch the beeps off in BIOS permanently.
Sorry, I misread your last comment. Yes, in the _working_ kernel (till 4.9) the beep can be controlled from within Linux. Though I don't know if this indicates a sound problem, but I'm not an expert. :)
I mean, my bisection narrowed the problem down to 6 commits, isn't it possible to conclude from them which part of the kernel is the cause for the bug?
hmmm, let's confirm if the bisect result is true or not. first, please checkout v4.9-rc1, which is the parent of these commit, and confirm that the problem is not reproduced in that kernel. then, please checkout commit 1d9174fbc55ec99ccbfcafa3de2528ef78a849aa, and confirm that the problem is reproduced in that kernel.