Intel HDA driver: no sound, broken preferences on Thinkpad X220

[tidux]

The sound is known working on this laptop under both Windows 10 and Linux, and was not in a muted state before booting in to Haiku. This is a fresh boot of live media. The headphone channel is not in fact outputting sound to the headphones despite the UI suggesting it will.

~> uname -a Haiku shredder 1 hrev52060 Jul 3 2018 17:02:37 x86_64 x86_64 Haiku

See attached screenshot for the display errors in Media Preferences.

[tidux]

screenshot of issue

[waddlesplash]

Please attach a syslog.

[waddlesplash]

Oh, and try warm-rebooting from Linux. Sometimes HDA works in that state.

[tidux]

syslog with working sound, broken prefs UI

[tidux]

Warm-booting from Linux allowed sound to work, but the Media Preferences GUI for the HDA device is still broken in the same manner as before. See attached syslog. If warm-booting from Linux works but cold boot does not, this suggests the driver is not initializing the hardware correctly.

[waddlesplash]

korli: if you could try to investigate some of these HDA issues before beta1, that would be excellent...

[tidux]

Still present in Beta 1. It looks like the channels are being mapped as inputs when they're outputs or vice versa. Looking at the Linux kernel code for the HDA driver and eyeballing the comparison it looks like there's a lot more work going into device initialization on the Linux side... and this laptop's sound works on Linux. Might be a place to look.

[ttcoder]

@tidux I'm working on #14581 , which has the very same internals (if not quite the same vendor/id), including the same "widget IDs" and so on.

Does Linux produce some sort of "syslog" like Haiku, and if so could you attach it here (or ask me for my email addy if you'd rather send off-ticket). That could be a life saver.

Also what do you mean by " It looks like the channels are being mapped as inputs when they're outputs or vice versa.". Is that something you see in Media Prefs, or in the sylog, or somewhere else ?

Thanks

/me prepare to look up the linux code on github, but would rather do that only if all else fails

[tidux]

Here's all the output of Linux dmesg (kernel messages) generated by the HDA driver, and "lspci -vvv" output.

[tidux]

dmesg output

[tidux]

linux lspci -vvv

[korli]

To help you investigate:

your codec is handled here: ​https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_conexant.c#L1102 which applies the following: ​https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_conexant.c#L1037 specifically: ​https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_conexant.c#L943 described here: ​https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_conexant.c#L736

This means your codec needs: ​https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_conexant.c#L712 and ​https://github.com/torvalds/linux/blob/master/sound/pci/hda/thinkpad_helper.c#L37

you can try to patch your codec at this location: ​https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/audio/hda/hda_codec.cpp#n882

Be sure to check the subsystem and subvendor ids ( codec->controller->pci_info.u.h0.subsystem_id and codec->controller->pci_info.u.h0.subsystem_vendor_id ).

[ttcoder]

@tidux Let's go straight for better tracing options; with some luck it will be like a cheat sheet, leading to a fairly quick fix.

I've found this page ​https://www.kernel.org/doc/html/latest/sound/hd-audio/notes.html. It mentions a few hints. Here's those that seem most interesting to me; the first one might not be so easy, if so proceed to the next ones:

In general, I recommend you to enable the sound debug option,
CONFIG_SND_DEBUG=y, no matter whether you are debugging or not. This enables snd_printd() macro and others,
and you’ll get additional kernel messages at probing.

(those seem to be C++ defines, meaning you need to recompile the linux driver ?)

Seems it's possible to get pin configs directly from terminal; unfortunately the init_verbs can probably not get retrieved, but pin configs might be interesting anyway:

The following sysfs files are available under each codec-hwdep
device directory (e.g. /sys/class/sound/hwC0D0):
 (..)
driver_pin_configs: Shows the pin default values set by the codec
parser explicitly. This doesn’t show all pin values but only the changed values by the parser.

The document mentions "hwC0D0" in the path, whereas your dmesg output mentions "hdaudioC0D0". So some adapting might be needed. Anyway presumably you would retrieve the data by typing something like this in a terminal/xterm:

cat /sys/class/sound/hwC0D0/driver_pin_configs

This is the tracing that seems most hopeful to me:

The hd-audio driver gives a few basic tracepoints. hda:hda_send_cmd traces each CORB write (..)

Enabling all tracepoints can be done like
# echo 1 > /sys/kernel/debug/tracing/events/hda/enable

then after some commands, you can [get] traces from /sys/kernel/debug/tracing/trace file

I likely can decode the output by hand, the "hda-decode-verb" stuff mentionned below might not be necessary.

I wonder if it retro-actively includes tracing produced by the hda driver during boot-up though. If it does not, maybe it's possible to trigger a re-init of the driver, by hand, using the "reconfig" trick described in the document, after activating tracing.

[tidux]

CONFIG_SND_DEBUG=y is a kernel configuration option (from the Kconfig file, can be set graphically via "make menuconfig" at build time) and would require rebuilding the kernel. I'll check the other stuff later today when I have access to the machine.

[ttcoder]

Thanks tidux, appreciated. As soon as I get your data I'll report on my findings (either in your ticket or mine) as before.

[tidux]

Uploads delayed by Trac outage. Here you go.

[tidux]

Bumping ticket since Trac email notifications were broken earlier today, thanks waddlesplash for the fix.

[ttcoder]

Testing to see if I can get past the horrid captchas..

Edit: I've had to solve 20 catpchas to post (in Web+), dang it.

Anyway, even though the above is only four HDA verbs, that gave me enough to work with for a couple days, to "retool". Confirmed that implementing just those 4 verbs in haiku is not enough to get audio working. Now I'm ready for the full thing :-)

In other words,

You should type both those lines in terminal:

echo 1 > /sys/kernel/debug/tracing/events/hda/enable
echo 1 > /sys/class/sound/hwC0D0/reconfig

That will trigger a (second) reconfiguration *after* tracing-logging is enabled, so that the log will contain the whole initialization sequence.

The log should then contain many more than four verbs, it should be a flood comparable to this (partial) Haiku listing:

Welcome to the Haiku shell.

/boot/system/var/log> grep hda-verb syslog
KERN: hda: widgets: KERN:   hda-verb       <0x010a0000>:  [0] nid 0x10 (16) : pload 0x0   vid 0xa0000 (VID_GET_CONVERTER_FORMAT)
KERN:   hda-verb       <0x01420811>:  [0] nid 0x14 (20) : pload 0x811   vid 0x20000 (VID_SET_CONVERTER_FORMAT)
KERN:   hda-verb       <0x01470620>:  [0] nid 0x14 (20) : pload 0x20   vid 0x70600 (VID_SET_CONVERTER_STREAM_CHANNEL)
KERN: 20   hda-verb       <0x010a0000>:  [0] nid 0x10 (16) : pload 0x0   vid 0xa0000 (VID_GET_CONVERTER_FORMAT)
KERN:   hda-verb       <0x01520811>:  [0] nid 0x15 (21) : pload 0x811   vid 0x20000 (VID_SET_CONVERTER_FORMAT)
KERN:   hda-verb       <0x01570620>:  [0] nid 0x15 (21) : pload 0x20   vid 0x70600 (VID_SET_CONVERTER_STREAM_CHANNEL)
KERN: hda: widgets: KERN:   hda-verb       <0x010a0000>:  [0] nid 0x10 (16) : pload 0x0   vid 0xa0000 (VID_GET_CONVERTER_FORMAT)
KERN:   hda-verb       <0x01024011>:  [0] nid 0x10 (16) : pload 0x4011   vid 0x20000 (VID_SET_CONVERTER_FORMAT)
KERN:   hda-verb       <0x01070610>:  [0] nid 0x10 (16) : pload 0x10   vid 0x70600 (VID_SET_CONVERTER_STREAM_CHANNEL)
KERN: hda: widgets: KERN:   hda-verb       <0x010a0000>:  [0] nid 0x10 (16) : pload 0x0   vid 0xa0000 (VID_GET_CONVERTER_FORMAT)
KERN:   hda-verb       <0x01420811>:  [0] nid 0x14 (20) : pload 0x811   vid 0x20000 (VID_SET_CONVERTER_FORMAT)
KERN:   hda-verb       <0x01470620>:  [0] nid 0x14 (20) : pload 0x20   vid 0x70600 (VID_SET_CONVERTER_STREAM_CHANNEL)
KERN: 20   hda-verb       <0x010a0000>:  [0] nid 0x10 (16) : pload 0x0   vid 0xa0000 (VID_GET_CONVERTER_FORMAT)
KERN:   hda-verb       <0x01520811>:  [0] nid 0x15 (21) : pload 0x811   vid 0x20000 (VID_SET_CONVERTER_FORMAT)
KERN:   hda-verb       <0x01570620>:  [0] nid 0x15 (21) : pload 0x20   vid 0x70600 (VID_SET_CONVERTER_STREAM_CHANNEL)
KERN:   hda-verb       <0x010ba000>:  [0] nid 0x10 (16) : pload 0xa000   vid 0xb0000 (VID_GET_AMPLIFIER_GAIN_MUTE)
KERN:   hda-verb       <0x010b8000>:  [0] nid 0x10 (16) : pload 0x8000   vid 0xb0000 (VID_GET_AMPLIFIER_GAIN_MUTE)
KERN:   hda-verb       <0x0103a04a>:  [0] nid 0x10 (16) : pload 0xa04a   vid 0x30000 (VID_SET_AMPLIFIER_GAIN_MUTE)
KERN:   hda-verb       <0x0103904a>:  [0] nid 0x10 (16) : pload 0x904a   vid 0x30000 (VID_SET_AMPLIFIER_GAIN_MUTE)
KERN:   hda-verb       <0x010ba000>:  [0] nid 0x10 (16) : pload 0xa000   vid 0xb0000 (VID_GET_AMPLIFIER_GAIN_MUTE)

Then I'll ruthlessly adapt my code to match your log line-for-line. Thanks!

[ttcoder]

A quick drive-by "ping", just in case the bulk of the message above was missed (being edited after the fact and what-not...) Seems today I can post to tickets again without being mauled by captchas though, nice!

[tidux]

Trace of reconfiguring codec, starting pulseaudio again, and beginning audio playback.

[tidux]

Full trace added.

[ttcoder]

@tidux please see ticket:14581#comment:10

[waddlesplash]

FWIW, the media preferences brokenness is tracked as #9430.

[tidux]

The media preferences window layout is fixed, but channels are still mapped incorrectly on cold boot as of hrev53233 x86_gcc2hybrid.

[pulkomandy]

Removing HDA audio tickets from Beta2 milestone, no one has worked on it and opensound is available at least as a stopgap.

[waddlesplash]

Please retest under a recent nightly.