AMD 17h/1xh HD Audio testers wanted!
If you've an azalia(4) attaching as "AMD 17h/1xh HD Audio", please
test this diff and report regressions. Especially audio lock ups that
require reboot.
IIRC, MSI was disabled few years ago to "fix" such lockups, and now
this diff suggests we need MSI on certain boards.
Context and diff below:
- Forwarded message from Andreas Bartelt -
Date: Sat, 4 Mar 2023 16:12:22 +0100
From: Andreas Bartelt
To: Alexandre Ratchov , b...@openbsd.org
Subject: Re: audio(4) output doesn't work yet on ASUS ProArt X670E-CREATOR WIFI
mainboard (ALC1220
CODEC)
User-Agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:102.0) Gecko/20100101
Thunderbird/102.8.0
On 2/27/23 6:41 PM, Andreas Bartelt wrote:
> On 2/27/23 2:40 PM, Alexandre Ratchov wrote:
> > On Sat, Feb 25, 2023 at 05:20:53PM +0100, Andreas Bartelt wrote:
> > > Hi,
> > >
> > > I've tested a recent OpenBSD snapshot of CURRENT on an ASUS ProArt
> > > X670E-CREATOR WIFI mainboard. According to the information
> > > provided by ASUS,
> > > this mainboard features a "Realtek S1220A CODEC" which attaches as
> > > Realtek
> > > ALC1220 on OpenBSD -- however, audio output (tested with
> > > headphones on the
> > > line out connector) doesn't work there yet. Applications (e.g., mplayer,
> > > mpg123) hang and I can hear no sound.
> > >
> > > [I don't know if this helps but I previously also had access to an
> > > ASUS ROG
> > > STRIX B550-E GAMING mainboard which, according to ASUS, also features an
> > > S1220A CODEC which also attaches as Realtek ALC1220 on OpenBSD -- audio
> > > output (tested on the line out connector) works there without problems.]
> > >
> > > In order to verify that the new mainboard doesn't have a physical defect
> > > with regard to the line out audio connector, I've also tested a
> > > FreeBSD 13.2
> > > BETA3 snapshot on the ASUS ProArt X670E-CREATOR WIFI mainboard.
> > > Audio output
> > > worked there out-of-the-box, so this might be a fixable problem on
> > > OpenBSD.
> > >
> > > I've found some info with regard to audio debugging at
> > > https://www.openbsd.org/faq/faq13.html#audioprob . While running
> > > # cat > /dev/audio0 < /dev/zero
> > > play.bytes doesn't increase at all:
> > > # audioctl play.{bytes,errors}
> > > play.bytes=0
> > > play.errors=0
> > >
> >
> > mixerctl shows that the host manages communicate with the codec, but
> > above lines suggest that DMA doesn't start. Could you check if there
> > are any audio-related options in the BIOS? Especially, if there's an
> > option to disable the microphone (or "recording" or alike), please
> > enable it.
>
> There's no microphone or recording specific options available. I could
> only identify a single audio related configuration option. Under
> Advanced\Onboard Devices Configuration: enable/disable "HD Audio
> Controller" (description says Enable/Disable Azalia HD Audio). It does
> exactly that, i.e., disabling this option removes the azalia1 device from
> OpenBSD's dmesg.
>
> With this option enabled again, mp3 playback works with FreeBSD but hangs
> with OpenBSD -- same BIOS config.
>
I've made audio work on the ASUS ProArt X670E-CREATOR WIFI mainboard, simply
by enabling msi.
azalia1 at pci21 dev 0 function 6 "AMD 17h/1xh HD Audio" rev 0x00: msi
azalia1: codecs: Realtek ALC1220
audio0 at azalia1
The following diff fixes the problem:
Index: src/sys/dev/pci/azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.283
diff -u -p -r1.283 azalia.c
--- src/sys/dev/pci/azalia.c21 Feb 2023 13:42:59 - 1.283
+++ src/sys/dev/pci/azalia.c4 Mar 2023 15:02:31 -
@@ -554,7 +554,6 @@ azalia_pci_attach(struct device *parent,
if (PCI_VENDOR(sc->pciid) == PCI_VENDOR_AMD) {
switch (PCI_PRODUCT(sc->pciid)) {
case PCI_PRODUCT_AMD_17_HDA:
- case PCI_PRODUCT_AMD_17_1X_HDA:
case PCI_PRODUCT_AMD_HUDSON2_HDA:
pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
}
OK?
- End forwarded message -
Re: iwx(4) -77 firmware diff for testing
On 3/2/23 10:09, Stefan Sperling wrote: On Wed, Feb 22, 2023 at 03:31:28PM +0100, Stefan Sperling wrote: Below is my work-in-progress diff to update iwx(4) to latest firmware. Every system tracking -current should already have the new -77 firmware images. The new images contain security fixes of (to me) unknown severity. Unfortunately there have been quite a number of firmware API changes since our last upgrade and it took me quite some time to get all the required new bits in place and arrive at an operational state. While testing please enable additional debug output with: ifconfig iwx0 debug To activate it at boot time: echo debug >> /etc/hostname.iwx0 There are some known issue with occasional firmware errors. My devices eventually manage to connect and work regardless. If you see a firmware error in dmesg please include the extra information shown in dmesg after enabling the debugging mode as above. This information is hidden by default and the driver will only print "fatal firmware error" to dmesg without more context, but the extra context is needed for debugging. If you hit an error which looks like this: iwx0: firmware parse error 22, section type 19 iwx0: failed to load init firmware Then you will need to increase this constant in if_iwxvar.h until you get past the error: #define IWX_UCODE_SECT_MAX 56 This new version of the patch fixes two issues: IWX_UCODE_SECT_MAX was bumped to 57 to accommodate some AX211 devices. Fixed iwx0: 0x211A | ADVANCED_SYSASSERT with helpful hints from Johannes Berg at Linux/Intel. This was an annoying issue since it made connecting to an access point fail quite often. Root cause were changes in the mac context command, where the firmware now expects beacon-related info to be initialized early, already before we attempt to associate. The only remaining known issue is: iwx0: 0x20002806 | ADVANCED_SYSASSERT, as seen by jmc@ This seems related to background scans. I could not yet reproduce the error, roaming seems to work as expected for me, but this might depend on the RF environment. Since roaming is evidently not completely broken by this I will not treat this as a blocker for moving development into the tree. Patch test reports are still welcome but please be fast if there is an issue you are seeing that I am not aware of. I will start splitting/committing this soon. Hi Stefan, also this patch works for my AX201 iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x01, msix iwx0: hw rev 0x350, fw 77.f92b5fed.0 Best regards, Sven
Re: atactl: Update common SMART attribute names
On Sat, Feb 25, 2023, at 4:43 PM, Brian Conway wrote:
> The last times the attribute names were updated were 14 and 21 years
> ago. Modern drives, especially SSDs, get a lot of Unknown columns from
> the 'readattr' command.
>
> Attributes were coalesced from smartmontools, NetBSD's atactl, and
> Wikipedia's citations. Manufacturer-specific attributes and overrides
> were not attempted, as that's an imprecise art probably better left to
> smartmontools.
>
> Thanks for your time.
>
> Brian Conway
> RCE Software, LLC
ping
> diff --git sbin/atactl/atactl.c sbin/atactl/atactl.c
> index aaba61502..c4a1d20d5 100644
> --- sbin/atactl/atactl.c
> +++ sbin/atactl/atactl.c
> @@ -309,6 +309,28 @@ struct valinfo ibm_attr_names[] = {
> { 11, "Calibration Retry Count" },
> { 12, "Device Power Cycle Count" },
> { 13, "Soft Read Error Rate" },
> + { 100, "Erase/Program Cycles" },
> + { 103, "Translation Table Rebuild" },
> + { 160, "Uncorrectable Error Count" },
> + { 170, "Reserved Block Count" },
> + { 171, "Program Fail Count" },
> + { 172, "Erase Fail Count" },
> + { 173, "Wear Worst Case Erase Count" },
> + { 174, "Power-Off Retract Count" },
> + { 175, "Program Fail Count" },
> + { 176, "Erase Fail Count" },
> + { 177, "Wear Leveling Count" },
> + { 178, "Used Reserved Block Count" },
> + { 179, "Used Reserved Block Count Total" },
> + { 180, "Unused Reserved Block Count Total" },
> + { 181, "Program Fail Count Total" },
> + { 182, "Erase Fail Count" },
> + { 183, "Runtime Bad Block" },
> + { 184, "End-to-End error" },
> + { 185, "Head Stability" },
> + { 186, "Induced Op-Vibration Detection" },
> + { 187, "Reported Uncorrectable Errors" },
> + { 188, "Command Timeout" },
> { 189, "High Fly Writes" },
> { 190, "Airflow Temperature" },
> { 191, "G-Sense Error Rate" },
> @@ -341,8 +363,15 @@ struct valinfo ibm_attr_names[] = {
> { 228, "Power-Off Retract Count" },
> { 230, "GMR Head Amplitude" },
> { 231, "Temperature" },
> + { 232, "Available reserved space" },
> + { 233, "Media wearout indicator" },
> + { 235, "Power-Off Retract Count" },
> { 240, "Head Flying Hours" },
> + { 241, "Total LBAs Written" },
> + { 242, "Total LBAs Read" },
> + { 249, "NAND Writes (1GB)" },
> { 250, "Read Error Retry Rate" },
> + { 254, "Free Fall Sensor" },
> { 0, NULL },
> };
