You are not logged in.
The onboard Realtek sound of an Intel DQ87PG board becomes nearly completely muted after the latest kernel update.
I can still hear the whispering of "hissing" sounds after cranking up the volume to 100%.
Kernel Log (journalctl -k) shows nothing obvious. All sound related modules are loaded.
Sound is normal when downgrading the kernel (4.12.8) or using the LTS kernel.
Last edited by -thc (2017-12-04 18:09:36)
Offline
Update 4.13.4: Problem persists.
Offline
Offline
Thx, but the power save fix doesn't work with the "Line Out" output.
Offline
Let's rule out the most common offender with the 4.13 kernel. Can you add
intel_iommu=off
to your kernel parameters?
Offline
Thx. I've done that - no change in sound volume.
Offline
Update 4.13.5: Problem persists.
Offline
I cannot find the bug in upstream
Can anyone open it and relate with the Arch one and this topic?
Last edited by amhairghin (2017-10-13 07:21:26)
Offline
amhairghin you could open such a bug report yourself.
Offline
Update 4.13.6: Problem persists.
Offline
@-thc are you assuming the issue is an upstream one and someone else will report it to upstream?
Offline
Since I am a scientist by trade and we seem to be completely surrounded by people (electing ones and elected ones) who do nothing else but assuming - no, I try not to assume at all.
I have some understanding of the Linux kernel and how to compile it - but this problem is way out of my league. I'm not even sure if this is an upstream problem at all. Especially since there is no obvious error message attached to it.
My posts are primarily for documentation and search engines.
Since you are a veteran member of this board - if you don't think I should post here in that form - I will stop immediately.
Offline
I would suggest providing more information:
What is the systems audio configuration?
What you can detect that has changed between 4.12.y and 4.13.y for instance:
Are all the audio devices present the same?
The modules that are only loaded under 4.12 or only under 4.13 `lsmod`.
For each audio related kernel module have any paramaters changed between 4.12.y and 4.13.y `systool -vm modulename`
If there is nothing obvious in the results from the above bisect the kernel between 4.12 and 4.13 to determine which commit caused the issue.
Offline
Update 4.13.7: Problem persists.
I check parameters of sound module and not have any significant changes.
Kernel 4.12.13:
% systool -vm snd_hda_intel
Module = "snd_hda_intel"
Attributes:
coresize = "36864"
initsize = "0"
initstate = "live"
refcnt = "8"
taint = ""
uevent = <store method only>
Parameters:
align_buffer_size = "-1"
bdl_pos_adj = "-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1"
beep_mode = "Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y"
enable_msi = "-1"
enable = "Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y"
id = "(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)"
index = "-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1"
jackpoll_ms = "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0"
model = "(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)"
patch = "(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)"
position_fix = "-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1"
power_save = "0"
power_save_controller= "Y"
probe_mask = "-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1"
probe_only = "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0"
single_cmd = "-1"
snoop = "-1"
Sections:
.bss = "0xffffffffc0435180"
.data.unlikely = "0xffffffffc0434c88"
.data = "0xffffffffc0434180"
.exit.text = "0xffffffffc04312ea"
.gnu.linkonce.this_module= "0xffffffffc0434e40"
.init.text = "0xffffffffc0553000"
.note.gnu.build-id = "0xffffffffc0432000"
.ref.data = "0xffffffffc0434cc0"
.rodata.str1.1 = "0xffffffffc043324a"
.rodata.str1.8 = "0xffffffffc04335b0"
.rodata = "0xffffffffc0432040"
.smp_locks = "0xffffffffc0433938"
.strtab = "0xffffffffc0556c40"
.symtab = "0xffffffffc0554000"
.text = "0xffffffffc042e000"
__bug_table = "0xffffffffc0434a10"
__jump_table = "0xffffffffc0434000"
__mcount_loc = "0xffffffffc0433c68"
__param = "0xffffffffc0433940"
__tracepoints_ptrs = "0xffffffffc0433be8"
__tracepoints = "0xffffffffc0434d20"
__tracepoints_strings= "0xffffffffc0433c10"
__verbose = "0xffffffffc0434a20"
_ftrace_events = "0xffffffffc0434c90"
Kernel 4.13.7:
% systool -vm snd_hda_intel
Module = "snd_hda_intel"
Attributes:
coresize = "36864"
initsize = "0"
initstate = "live"
refcnt = "8"
taint = ""
uevent = <store method only>
Parameters:
align_buffer_size = "-1"
bdl_pos_adj = "-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1"
beep_mode = "Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y"
enable_msi = "-1"
enable = "Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y"
id = "(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)"
index = "-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1"
jackpoll_ms = "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0"
model = "(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)"
patch = "(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)"
position_fix = "-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1"
power_save = "0"
power_save_controller= "Y"
probe_mask = "-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1"
probe_only = "0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0"
single_cmd = "-1"
snoop = "-1"
Sections:
.bss = "0xffffffffc03e0180"
.data.unlikely = "0xffffffffc03dfc90"
.data = "0xffffffffc03df180"
.exit.text = "0xffffffffc03dc2ba"
.gnu.linkonce.this_module= "0xffffffffc03dfe40"
.init.text = "0xffffffffc051e000"
.note.gnu.build-id = "0xffffffffc03dd000"
.ref.data = "0xffffffffc03dfcc0"
.rodata.str1.1 = "0xffffffffc03de28a"
.rodata.str1.8 = "0xffffffffc03de5f8"
.rodata = "0xffffffffc03dd040"
.smp_locks = "0xffffffffc03de980"
.strtab = "0xffffffffc0521cb8"
.symtab = "0xffffffffc051f000"
.text = "0xffffffffc03d9000"
__bug_table = "0xffffffffc03dfa18"
__jump_table = "0xffffffffc03df000"
__mcount_loc = "0xffffffffc03deca8"
__param = "0xffffffffc03de988"
__tracepoints_ptrs = "0xffffffffc03dec30"
__tracepoints = "0xffffffffc03dfd20"
__tracepoints_strings= "0xffffffffc03dec50"
__verbose = "0xffffffffc03dfa28"
_ftrace_events = "0xffffffffc03dfc98"
Offline
What is the systems audio configuration?
Realtek onboard sound, pulseaudio, analog output.
What you can detect that has changed between 4.12.y and 4.13.y for instance:
Only that the sound volume is nearly inaudible low.
Are all the audio devices present the same?
Yes
The modules that are only loaded under 4.12 or only under 4.13 `lsmod`.
4.13.7 loads the additional module "agpgart" used by "intel_gtt.drm".
For each audio related kernel module have any paramaters changed between 4.12.y and 4.13.y `systool -vm modulename`
See amhairghin's answer.
If there is nothing obvious in the results from the above bisect the kernel between 4.12 and 4.13 to determine which commit caused the issue.
It's the 4.13 kernel. The problem is present in all 4.13 builds (even in 4.13-1) and is absent in all preceeding builds and the LTS builds.
Offline
loqs wrote:If there is nothing obvious in the results from the above bisect the kernel between 4.12 and 4.13 to determine which commit caused the issue.
It's the 4.13 kernel. The problem is present in all 4.13 builds (even in 4.13-1) and is absent in all preceeding builds and the LTS builds.
$ git bisect start
$ git bisect good v4.12
$ git bisect bad v4.13
Bisecting: 7028 revisions left to test after this (roughly 13 steps)
Which of the thousands of commits that made up 4.13 is the first to exhibit the issue that is what I was asking for and git bisect allows you to efficiently determine it.
Offline
I never did a bisect before - and bisecting the linux kernel is quite a task.
Anyway - if I did everything right, this should be it:
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[3db9e970e3b174a6c964c4dcc1df4939cc6d0387] ALSA: hda - Remove the generic bind ctl helpers
EDIT: If this is correct, then the actual pulseaudio/alsa subsystem still uses the legacy ctl functions - right?
EDIT 2: Turns out it's a lot more difficult than I thought:
- Reverting this single commit of an otherwise vanilla "linux-git" kernel doesn't bring back the sound
- Started the git bisect run again and after three tests bisect drops an error and aborts.
Sorry - I'm completely at sea here.
Last edited by -thc (2017-10-20 13:57:01)
Offline
Yes it is quite a task unfortunately I could not think of any alternatives to suggest.
git checkout 3db9e970e3b174a6c964c4dcc1df4939cc6d0387^
Will checkout the parent of the bad commit which should be the last good commit and you could see if that works.
Then if applying the single commit 3db9e970e3b174a6c964c4dcc1df4939cc6d0387 causes the issue the that would indicate that commit is causing the issue.
Regarding the error what was the command and the output it generated?
Edit:
I mean the error from the second bisect run.
Last edited by loqs (2017-10-20 17:23:11)
Offline
The error message from the second and the third bisect run (test 3):
[thc@cn2 linux]$ git bisect good
Bisecting: 975 revisions left to test after this (roughly 10 steps)
error: Your local changes to the following files would be overwritten by checkout:
Documentation/sphinx/tmplcvt
Please commit your changes or stash them before you switch branches.
Aborting
Offline
Change these two lines in the PKGBUILD to make bisecting easier
# sed -i '2iexit 0' scripts/depmod.sh
This stops complaints about scripts/depmod.sh being changed by not changing it.
# cp -al Documentation "${pkgdir}/usr/lib/modules/${_kernver}/build"
cp -a Documentation "${pkgdir}/usr/lib/modules/${_kernver}/build"
This stops complaints about anything in the Documentation tree being changed by not hardlinking to it from the pkgdir then chmodding it.
To fix the current complaint
git reset --hard
Offline
Thx - after making these changes to PKGBUILD the bisect run continued. Passing this step
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[3db9e970e3b174a6c964c4dcc1df4939cc6d0387] ALSA: hda - Remove the generic bind ctl helpers
again and - after the final bisect command - arriving here:
[thc@cn2 linux]$ git bisect good
99b5c5bb9a5435a5ae5d46445ac0f2bf6aa5ee52 is the first bad commit
commit 99b5c5bb9a5435a5ae5d46445ac0f2bf6aa5ee52
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed May 10 12:29:37 2017 +0200
ALSA: hda - Remove the use of set_fs()
set_fs() is used in HD-audio vmaster code to retrieve the TLV data of
each slave kctl. Since the slave is supposed to be a standard amp
kctl, we can call directly the supposed tlv callback instead of the
indirect call, so that we can remove the set_fs() hack.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
:040000 040000 70c0173e1911182dc3ba633f01bd7aa3f3276516 2d2d159f53dc20dde996c70458110d6670f5c6a3 M sound
Following your suggestion i did this checkout
git checkout 99b5c5bb9a5435a5ae5d46445ac0f2bf6aa5ee52^
and the sound was audible. After this checkout
git checkout 99b5c5bb9a5435a5ae5d46445ac0f2bf6aa5ee52
it wasn't. Which means - I did not finish the first bisect run, was jumping to conclusions and reverting the wrong commit - that's a little embarrassing.
Unfortunately the bad commit cannot be reverted:
[thc@cn2 linux]$ git revert 99b5c5bb9a5435a5ae5d46445ac0f2bf6aa5ee52
error: could not revert 99b5c5bb9a54... ALSA: hda - Remove the use of set_fs()
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
Offline
reporting-kernel-bugs
Would suggest waiting until 4.14rc-6 is released within the next 24 hours and checking if it already fixed by that release before reporting.
Offline
O.K.
Since "linux-git" from AUR is still 4.14rc4 - what's the next step? Should I use "linux-mainline" for testing the sound?
Offline
No need just run makepkg without the -e option after 4.14-rc6 is released and it will sync with upstream and checkout head.
you could add #tag=v4.14-rc6 to the source line so that it will checkout v4.14-rc6 (this is what linux-mainline does) or manually checkout v4.14-rc6
Alternatively from within the src/linux directory run `git fetch origin` to update the local clone against upstream then `git checkout v4.14-rc6`
then keep using the -e option.
Offline
O.K. - I will do that and post the result.
Offline