You are not logged in.
Greetings, I have been dealing with a very annoying issue ever since I seemingly got this system for the first time (which was some months ago) but I never experienced it much before as I used a bluetooth headset. I'm running a rig of the following specs:
Ryzen 9 9900X
Giagabyte B650 AORUS ELITE AX ICE
RX 9070 (not the XT version)
The issue is simple. If I cold boot (i.e. the system isn't initially running and I start it), I'm able to log into my window manager and everything mostly works, but the audio on the monitor speakers don't work and say "Dummy Output". If I reboot the system, this gets fixed and I'm able to see "Vega XX HDMI/DP audio" or something along the same lines.
So, to summarize, a cold boot = no audio. Warm boot = yes audio.
Audio:
Message: No device data found.
API: ALSA v: k7.0.12-zen1-1-zen status: kernel-api
Server-1: PipeWire v: 1.6.6 status: activeThis issue does not appear for my integrated GPU, which is able to initialize audio right from a cold boot. I've tried doing the following:
On BIOS:
* disable "fast boot"
* forcefully disable integrated GPU as well as the HD audio controller (which seems to pertain only to the integrated gpu)
Inside linux (I use Niri):
* restarted pipewire and wireplumber after logging in
* tried rescanning the PCIe bus
Outside Linux:
* Funnily, the issue even appears on Linux mint if I do a cold boot, so it's not really specific to Arch.
I would like to test out any other possible software-side workarounds or solutions before I deem that it's really a hardware-side issue. Can anyone please help?
I am indeed on a newer kernel 7.0.12-zen1-1-zen and have the following mesa version:
GPU0:
apiVersion = 1.4.348
driverVersion = 26.1.2
vendorID = 0x1002
deviceID = 0x7550
deviceType = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
deviceName = AMD Radeon RX 9070 (RADV GFX1201)
driverID = DRIVER_ID_MESA_RADV
driverName = radv
driverInfo = Mesa 26.1.2-arch1.2Offline
Stuff like that is can often be tied to the UEFI version, how up to date are you there?
Offline
Thanks for the suggestion. I found that my BIOS version was released about a year and a half ago. I updated my BIOS, but sadly, the issue still persists.
I was thinking I could probably instead have my Linux system detect if it's cold starting and do a hot-start immediately.
Offline
Mhm... when on a fixed boot where it works, try running an explicit
sudo alsactl store, does that help a subsequent cold boot?
Offline
This too didn't help. Guessing it is indeed something else at the hardware side. It's a bizarre issue but not something that's blocking me from getting my things done, so it seems I might just need to continue with this, for the time being, at least. I'll definitely still appreciate any other suggestions
Offline
This sounds very much like a timing issue where something tries to access hw before its fully initialised.
Is this with a HDMI , DP or something else monitor ? Is is connected directly to the vidoecard ?
Please run (as root)
# journalctl -b | curl -s -H "Accept: application/json, */*" --upload-file - 'https://paste.c-net.org/'and post the link it outputs.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Apologies for the late reply. I connect my GPU only to a DP monitor, and yes, it's directly connected to the videocard. I've disabled onboard GPU in the UEFI too
The link is:
Offline
A few weird lines in journal
Jul 26 15:06:41 borealis1 kernel: Linux agpgart interface v0.103
Jul 26 15:06:41 borealis1 kernel: x86/amd: Previous system reset reason [0x00080800]: software wrote 0x6 to reset control register 0xCF9
Jul 26 15:06:41 borealis1 kernel: amdgpu: Overdrive is enabled, please disable it before reporting any bugs unrelated to overdrive.Is your videocard a special type or have you overclocked it in firmware ?
Is amdgpu in the modules= line in mkinitcpio.conf ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
So, to summarize, a cold boot = no audio. Warm boot = yes audio.
But that's exclusive to the DP audio?
Is it strict DP or is there some adapter (eg. to HDMI) involved?
Does the journal in #7 reflect a good or a bad boot?
When the audio doesn't work, what's the output of "xrandr -q" and "glxinfo -B" (it's fine despite wayland, we want to know whether you're maybe running on the simpledrm device)
What happens when you
a) re-plug the monitor?
b) restart the GUI session?
Is this also a problem w/ any X11 session (openbox will do) - basically "does this happen because SDDM is running on X11 and the output handoff fails)
Offline
My apologies. I had acquired the logs from a hot boot rather than where the issue exists (cold boot). New logs at https://paste.c-net.org/EightsCrater
A few weird lines in journal
Jul 26 15:06:41 borealis1 kernel: Linux agpgart interface v0.103 Jul 26 15:06:41 borealis1 kernel: x86/amd: Previous system reset reason [0x00080800]: software wrote 0x6 to reset control register 0xCF9 Jul 26 15:06:41 borealis1 kernel: amdgpu: Overdrive is enabled, please disable it before reporting any bugs unrelated to overdrive.Is your videocard a special type or have you overclocked it in firmware ?
Is amdgpu in the modules= line in mkinitcpio.conf ?
I don't really think my video card is a "special type". It's a Sapphire Pure RX 9070, so I suppose consumer-grade. I have indeed undervolted it and reduced it's power util cap but the issue existed well before I did this.
Yes, I do have both amdgpu and radeon in my mkinitcpio:
MODULES=(amdgpu radeon)Sadly, adding these didn't make any difference. I keep them in my mkinitcpio anyway.
But that's exclusive to the DP audio?
Is it strict DP or is there some adapter (eg. to HDMI) involved?
Does the journal in #7 reflect a good or a bad boot?
When the audio doesn't work, what's the output of "xrandr -q" and "glxinfo -B" (it's fine despite wayland, we want to know whether you're maybe running on the simpledrm device)
What happens when you
a) re-plug the monitor?
b) restart the GUI session?
Is this also a problem w/ any X11 session (openbox will do) - basically "does this happen because SDDM is running on X11 and the output handoff fails)
It happened with both HDMI and DP.
The DP I use is just one cable, so I'm presuming it's strict DP.
I'm a bit used to doing a restart immediately after bootup, so I'm afraid I accidentally sent logs from a working session. I will be sending fresh logs: one from a non working session (attached above) and another where it does work.
Xrandr output seems normal:
WARNING: running xrandr against an Xwayland server. See the xrandr man page for details.
Screen 0: minimum 16 x 16, current 2560 x 1440, maximum 32767 x 32767
DP-1 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 600mm x 340mm
2560x1440 143.91*+
1920x1440 143.90
... more scalesGlxinfo: https://paste.c-net.org/FabrizioCroak
I'll let you know about replugging the monitor soon. Restarting the GUI session doesn't really work, sadly. I've tried to log in through multiple DEs/WMs and even multiple greeters (SDDM and lightdm, even restarted)
I haven't tried X11 but I did try live-booting Mint on a cold boot and that failed too, so I'd presume it's happening with X11 too. I will confirm this soon.
Offline
Here's the (hot) boot right after: https://paste.c-net.org/AnywayErica
I'll let you know about replugging as well as the X11 attempt on my next boot
Offline
Jul 27 21:27:58 borealis1 kernel: snd_hda_intel 0000:03:00.1: enabling device (0000 -> 0002)
Jul 27 21:27:58 borealis1 kernel: snd_hda_intel 0000:03:00.1: Force to non-snoop mode
Jul 27 21:27:58 borealis1 kernel: snd_hda_intel 0000:03:00.1: bound 0000:03:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu])Isn't there on the cold boot, as a matter of fact, 0000:03:00.1 doesn't show up at all.
tried rescanning the PCIe bus
How and what's the output of "lspci -nn" before and after?
Are resizable bars enabled?
Offline