Re: amdgpu doesn't start; [drm] failed to load ucode VCN0_RAM(0x3A)
Jonathan Gray writes: > On Tue, Mar 14, 2023 at 04:43:01AM -0600, bent...@openbsd.org wrote: > > Jonathan Gray writes: > > > On Mon, Mar 13, 2023 at 07:21:13PM -0600, bent...@openbsd.org wrote: > > > > Hi, > > > > > > > > Since the Linux 6.1.2 drm update, the Valve Steam Deck no longer starts > > > > amdgpu. Instead, these messages print, and X starts with wsfb instead. > > > > > > which firmware package do you have installed? > > > > amdgpu-firmware-20230310 > > > > Reverting to 20221109 shows the same behavior: same firmware errors with > > a post-6.1.2 kernel, fancy framebuffer with pre-6.1.2. > > It turns out this is a known problem > https://gitlab.freedesktop.org/drm/amd/-/issues/2385 > > You have one of the BIOS versions known to be incompatible with > indirect SRAM mode (F7A0113). > > a fix landed in the linux amd-staging-drm-next tree a day ago > https://gitlab.freedesktop.org/agd5f/linux/-/commit/70163f822695350651dbd2092 > f31915b5282c92f.patch > > Here is that patch, with some additional changes to handle > DMI_BIOS_VERSION. Thanks. With this patch amdgpu works on this machine.
Re: resistance against single-even upsets
On Tue, Mar 14, 2023 at 01:17:00PM -0500, Scott Cheloha wrote:
> > On Mar 14, 2023, at 11:32 AM, p...@delphinusdns.org wrote:
> >
> >> Synopsis: can we resist agains bit flipping?
> >> Category: system
> >> Environment:
> > System : OpenBSD 7.2
> > Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
> > r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.arm64
> > Machine : arm64
> >> Description:
> > https://en.wikipedia.org/wiki/Single-event_upset
> >
> > A single event upset gave someone in belgium who was in a poll, 4096
> > extra votes. When I think about this bit flip and look at the kernel
> > code for an ultra secure operating system there is not much stopping
> > someone to try an attack during a cosmic storm or increased solar
> > activity. Perhaps a bit flips somewhere in the CPU or RAM?
> >
> > pjp@polarstern$ grep sourceroute ip_input.c
> > int ip_dosourceroute = 0;
> >if (!ip_dosourceroute) {
> >if (!ip_dosourceroute)
> >_dosourceroute);
> >
> > Like here. As you know someone found something last week if this were
> > enabled. But the way this check is. It doesn't check for the low bit set
> > to
> > one but it checks for the inverted value, so if the 12th bit was flipped in
> > a
> > solar storm ip_dosourceroute would now be 4096. And the system would be
> > wide
> > open.
> >
> >> How-To-Repeat:
> > Hackers probably check the weather report like
> > https://spaceweather.com/ for increased solar activity and then fill
> > the CPU caches with attempts to get a bit flip happening. The odds
> > aren't in their favour but who knows they may get lucky.
> >> Fix:
> > I propose all these variables to be monitored occasionally with a CRC
> > check and if there is a bit flip happening to unset it to the right value.
> > This is a lot of work but may be worth it. OpenBSD would never be faring to
> > space right? I have no code but trying to think around how to do this.
>
> Why wouldn't you just buy ECC memory?
>
> https://en.wikipedia.org/wiki/ECC_memory
>
Good idea, but nothing is perfect of course :)
An interesting read and research:
https://www.vusec.net/projects/eccploit/
--
Kind regards,
Hiltjo
stuck after attaching scsibus at softraid0
Hi all, I'm stuck trying to install a new system. After attachting a scsibus to softraid0, nothing happens .. the machine just sits there. Inserting a USB device results in the kernel finding and attaching that, but no "root at sd0a" or (for bsd.rd) "root at rd0a". Booting verbosely (setting verbose in UKC) shows nothing after the scsibus attaches. ... >>> probing for vscsi0 >>> vscsi probe returned 1 vscsi0 at root >>> probing for scsibus* >>> scsibus probe returned 1 >>> scsibus probe won scsibus4 at vscsi0: 256 targets >>> probing for softraid0 >>> softraid probe returned 1 softraid0 at root >>> probing for scsibus* >>> scsibus probe returned 1 >>> scsibus probe won scsibus5 at softraid0: 256 targets When trying 'boot -a', I get the same, scsibus attaches to softraid0 and then nothing (plugging a USB device in still works as before), no question about which boot device to use. Any clues on how to get to further? dmesg (of both bsd.rd and bsd.mp (booted from an installation done on another machine)) included. I can send the verbose log on request, but I'm not including that now, as it's very long. Paul --- bsd.rd dmesg - >> OpenBSD/amd64 BOOTX64 3.63 boot> boot bsd.rd -a NOTE: random seed is being reused. booting hd0a:bsd.rd: 3920580+1647616+3882120+0+708608 [109+440400+293758]=0xa657c0 entry point at 0x1001000 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.3-beta (RAMDISK_CD) #1045: Mon Mar 13 03:06:45 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 67725537280 (64588MB) avail mem = 65668972544 (62626MB) random: good seed from bootblocks mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x794a3000 (79 entries) bios0: vendor American Megatrends Inc. version "0922" date 02/23/2023 bios0: ASUS ProArt X670E-CREATOR WIFI acpi0 at bios0: ACPI 6.4Undefined scope: \_SB_.PCI0.GPP7.UP00.DP40.UP00.DP68 acpi0: tables DSDT FACP SSDT SSDT SSDT FIDT MCFG HPET WDRT FPDT VFCT WPBT TPM2 SSDT CRAT CDIT SSDT SSDT SSDT SSDT SSDT WSMT APIC IVRS SSDT SSDT SSDT SSDT SSDT acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 9 7950X 16-Core Processor, 4500.00 MHz, 19-61-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,WAITPKG,L1DF,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache cpu0: apic clock running at 25MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 32 pa 0xfec0, version 21, 24 pins, can't remap ioapic1 at mainbus0: apid 33 pa 0xfec01000, version 21, 32 pins, can't remap acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (GPP3) acpiprt2 at acpi0: bus -1 (GPP4) acpiprt3 at acpi0: bus -1 (GPP5) acpiprt4 at acpi0: bus -1 (GPP6) acpiprt5 at acpi0: bus -1 (GPP9) acpiprt6 at acpi0: bus -1 (GPPA) acpiprt7 at acpi0: bus -1 (GPPB) acpiprt8 at acpi0: bus -1 (GPPC) acpiprt9 at acpi0: bus -1 (GPPD) acpiprt10 at acpi0: bus -1 (GPPE) acpiprt11 at acpi0: bus -1 (GPPF) acpiprt12 at acpi0: bus -1 (GPPG) acpiprt13 at acpi0: bus -1 (GPPH) acpiprt14 at acpi0: bus 105 (GP17) acpiprt15 at acpi0: bus -1 (GP18) acpiprt16 at acpi0: bus 106 (GP19) acpiprt17 at acpi0: bus -1 (GPP0) acpiprt18 at acpi0: bus
Re: resistance against single-even upsets
> On Mar 14, 2023, at 11:32 AM, p...@delphinusdns.org wrote:
>
>> Synopsis: can we resist agains bit flipping?
>> Category: system
>> Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
> r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
>> Description:
> https://en.wikipedia.org/wiki/Single-event_upset
>
> A single event upset gave someone in belgium who was in a poll, 4096
> extra votes. When I think about this bit flip and look at the kernel
> code for an ultra secure operating system there is not much stopping
> someone to try an attack during a cosmic storm or increased solar
> activity. Perhaps a bit flips somewhere in the CPU or RAM?
>
> pjp@polarstern$ grep sourceroute ip_input.c
> int ip_dosourceroute = 0;
>if (!ip_dosourceroute) {
>if (!ip_dosourceroute)
>_dosourceroute);
>
> Like here. As you know someone found something last week if this were
> enabled. But the way this check is. It doesn't check for the low bit set to
> one but it checks for the inverted value, so if the 12th bit was flipped in a
> solar storm ip_dosourceroute would now be 4096. And the system would be wide
> open.
>
>> How-To-Repeat:
> Hackers probably check the weather report like
> https://spaceweather.com/ for increased solar activity and then fill
> the CPU caches with attempts to get a bit flip happening. The odds
> aren't in their favour but who knows they may get lucky.
>> Fix:
> I propose all these variables to be monitored occasionally with a CRC
> check and if there is a bit flip happening to unset it to the right value.
> This is a lot of work but may be worth it. OpenBSD would never be faring to
> space right? I have no code but trying to think around how to do this.
Why wouldn't you just buy ECC memory?
https://en.wikipedia.org/wiki/ECC_memory
Re: resistance against single-even upsets
Peter J. Philipp wrote: > On Tue, Mar 14, 2023 at 10:34:48AM -0600, Theo de Raadt wrote: > > Good god, imagine this bit flip happened *anywhere else*, like in the > > page tables, or in the code or data or stack of chrome, or basically > > *anywhere* > > > > Shall we change them all? > > The example I gave was the last resort other than pf enabled to a kernel > compromise afaik. There is a few of them perhaps, they've not been fixed > for decades lying dormant with a sysctl knob to turn them off. There are a few of them???!?! You must be pretty uneducated about how computation actually happens. There are billions.
Re: resistance against single-even upsets
On Tue, Mar 14, 2023 at 10:34:48AM -0600, Theo de Raadt wrote:
> Good god, imagine this bit flip happened *anywhere else*, like in the
> page tables, or in the code or data or stack of chrome, or basically
> *anywhere*
>
> Shall we change them all?
The example I gave was the last resort other than pf enabled to a kernel
compromise afaik. There is a few of them perhaps, they've not been fixed
for decades lying dormant with a sysctl knob to turn them off.
> Shall we change the compiler to not allow checks like this?
No not at all.
> Shall we wait for a compiler diff from you?
No it's above my head and it would take me decades. :-)
Happy Pi day Theo, it's not quite April 1st but I think this is a bit more
serious. Just think about it, and perhaps in 10-20 years you can consider
it?
Best Regards,
-peter
> p...@delphinusdns.org wrote:
>
> > >Synopsis: can we resist agains bit flipping?
> > >Category: system
> > >Environment:
> > System : OpenBSD 7.2
> > Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
> >
> > r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.arm64
> > Machine : arm64
> > >Description:
> > https://en.wikipedia.org/wiki/Single-event_upset
> >
> > A single event upset gave someone in belgium who was in a poll, 4096
> > extra votes. When I think about this bit flip and look at the kernel
> > code for an ultra secure operating system there is not much stopping
> > someone to try an attack during a cosmic storm or increased solar
> > activity. Perhaps a bit flips somewhere in the CPU or RAM?
> >
> > pjp@polarstern$ grep sourceroute ip_input.c
> > int ip_dosourceroute = 0;
> > if (!ip_dosourceroute) {
> > if (!ip_dosourceroute)
> > _dosourceroute);
> >
> > Like here. As you know someone found something last week if this were
> > enabled. But the way this check is. It doesn't check for the low bit set
> > to
> > one but it checks for the inverted value, so if the 12th bit was flipped in
> > a
> > solar storm ip_dosourceroute would now be 4096. And the system would be
> > wide
> > open.
> >
> > >How-To-Repeat:
> > Hackers probably check the weather report like
> > https://spaceweather.com/ for increased solar activity and then fill
> > the CPU caches with attempts to get a bit flip happening. The odds
> > aren't in their favour but who knows they may get lucky.
> > >Fix:
> > I propose all these variables to be monitored occasionally with a CRC
> > check and if there is a bit flip happening to unset it to the right value.
> > This is a lot of work but may be worth it. OpenBSD would never be faring to
> > space right? I have no code but trying to think around how to do this.
> >
> >
> > dmesg:
> > cut
> >
>
Re: resistance against single-even upsets
This is a hardware issue.
Hardware failure is best guarded against using redundant systems.
Since random errors tend to lead to different outcomes, machines which
agree on what they were told would be the ones which did not
experience hardware failure.
Personally, I'd recommend 5x redundancy for machines where public
safety is a critical issue.
--
Raul
On Tue, Mar 14, 2023 at 12:33 PM wrote:
>
> >Synopsis: can we resist agains bit flipping?
> >Category: system
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST
> 2022
>
> r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
> >Description:
> https://en.wikipedia.org/wiki/Single-event_upset
>
> A single event upset gave someone in belgium who was in a poll, 4096
> extra votes. When I think about this bit flip and look at the kernel
> code for an ultra secure operating system there is not much stopping
> someone to try an attack during a cosmic storm or increased solar
> activity. Perhaps a bit flips somewhere in the CPU or RAM?
>
> pjp@polarstern$ grep sourceroute ip_input.c
> int ip_dosourceroute = 0;
> if (!ip_dosourceroute) {
> if (!ip_dosourceroute)
> _dosourceroute);
>
> Like here. As you know someone found something last week if this were
> enabled. But the way this check is. It doesn't check for the low bit set to
> one but it checks for the inverted value, so if the 12th bit was flipped in a
> solar storm ip_dosourceroute would now be 4096. And the system would be wide
> open.
>
> >How-To-Repeat:
> Hackers probably check the weather report like
> https://spaceweather.com/ for increased solar activity and then fill
> the CPU caches with attempts to get a bit flip happening. The odds
> aren't in their favour but who knows they may get lucky.
> >Fix:
> I propose all these variables to be monitored occasionally with a CRC
> check and if there is a bit flip happening to unset it to the right value.
> This is a lot of work but may be worth it. OpenBSD would never be faring to
> space right? I have no code but trying to think around how to do this.
>
>
> dmesg:
> cut
>
Re: resistance against single-even upsets
Good god, imagine this bit flip happened *anywhere else*, like in the
page tables, or in the code or data or stack of chrome, or basically
*anywhere*
Shall we change them all?
Shall we change the compiler to not allow checks like this?
Shall we wait for a compiler diff from you?
p...@delphinusdns.org wrote:
> >Synopsis:can we resist agains bit flipping?
> >Category:system
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
>
> r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
> >Description:
> https://en.wikipedia.org/wiki/Single-event_upset
>
> A single event upset gave someone in belgium who was in a poll, 4096
> extra votes. When I think about this bit flip and look at the kernel
> code for an ultra secure operating system there is not much stopping
> someone to try an attack during a cosmic storm or increased solar
> activity. Perhaps a bit flips somewhere in the CPU or RAM?
>
> pjp@polarstern$ grep sourceroute ip_input.c
> int ip_dosourceroute = 0;
> if (!ip_dosourceroute) {
> if (!ip_dosourceroute)
> _dosourceroute);
>
> Like here. As you know someone found something last week if this were
> enabled. But the way this check is. It doesn't check for the low bit set to
> one but it checks for the inverted value, so if the 12th bit was flipped in a
> solar storm ip_dosourceroute would now be 4096. And the system would be wide
> open.
>
> >How-To-Repeat:
> Hackers probably check the weather report like
> https://spaceweather.com/ for increased solar activity and then fill
> the CPU caches with attempts to get a bit flip happening. The odds
> aren't in their favour but who knows they may get lucky.
> >Fix:
> I propose all these variables to be monitored occasionally with a CRC
> check and if there is a bit flip happening to unset it to the right value.
> This is a lot of work but may be worth it. OpenBSD would never be faring to
> space right? I have no code but trying to think around how to do this.
>
>
> dmesg:
> cut
>
resistance against single-even upsets
>Synopsis: can we resist agains bit flipping?
>Category: system
>Environment:
System : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
Architecture: OpenBSD.arm64
Machine : arm64
>Description:
https://en.wikipedia.org/wiki/Single-event_upset
A single event upset gave someone in belgium who was in a poll, 4096
extra votes. When I think about this bit flip and look at the kernel
code for an ultra secure operating system there is not much stopping
someone to try an attack during a cosmic storm or increased solar
activity. Perhaps a bit flips somewhere in the CPU or RAM?
pjp@polarstern$ grep sourceroute ip_input.c
int ip_dosourceroute = 0;
if (!ip_dosourceroute) {
if (!ip_dosourceroute)
_dosourceroute);
Like here. As you know someone found something last week if this were
enabled. But the way this check is. It doesn't check for the low bit set to
one but it checks for the inverted value, so if the 12th bit was flipped in a
solar storm ip_dosourceroute would now be 4096. And the system would be wide
open.
>How-To-Repeat:
Hackers probably check the weather report like
https://spaceweather.com/ for increased solar activity and then fill
the CPU caches with attempts to get a bit flip happening. The odds
aren't in their favour but who knows they may get lucky.
>Fix:
I propose all these variables to be monitored occasionally with a CRC
check and if there is a bit flip happening to unset it to the right value.
This is a lot of work but may be worth it. OpenBSD would never be faring to
space right? I have no code but trying to think around how to do this.
dmesg:
cut
Re: amdgpu doesn't start; [drm] failed to load ucode VCN0_RAM(0x3A)
On Tue, Mar 14, 2023 at 04:43:01AM -0600, bent...@openbsd.org wrote:
> Jonathan Gray writes:
> > On Mon, Mar 13, 2023 at 07:21:13PM -0600, bent...@openbsd.org wrote:
> > > Hi,
> > >
> > > Since the Linux 6.1.2 drm update, the Valve Steam Deck no longer starts
> > > amdgpu. Instead, these messages print, and X starts with wsfb instead.
> >
> > which firmware package do you have installed?
>
> amdgpu-firmware-20230310
>
> Reverting to 20221109 shows the same behavior: same firmware errors with
> a post-6.1.2 kernel, fancy framebuffer with pre-6.1.2.
It turns out this is a known problem
https://gitlab.freedesktop.org/drm/amd/-/issues/2385
You have one of the BIOS versions known to be incompatible with
indirect SRAM mode (F7A0113).
a fix landed in the linux amd-staging-drm-next tree a day ago
https://gitlab.freedesktop.org/agd5f/linux/-/commit/70163f822695350651dbd2092f31915b5282c92f.patch
Here is that patch, with some additional changes to handle
DMI_BIOS_VERSION.
Index: sys/arch/amd64/amd64/bios.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/bios.c,v
retrieving revision 1.46
diff -u -p -r1.46 bios.c
--- sys/arch/amd64/amd64/bios.c 16 Oct 2022 15:03:39 - 1.46
+++ sys/arch/amd64/amd64/bios.c 14 Mar 2023 11:15:25 -
@@ -63,6 +63,7 @@ const char *smbios_uninfo[] = {
};
char smbios_bios_date[64];
+char smbios_bios_version[64];
char smbios_board_vendor[64];
char smbios_board_prod[64];
char smbios_board_serial[64];
@@ -138,9 +139,15 @@ bios_attach(struct device *parent, struc
printf(" vendor %s",
fixstring(scratch));
if ((smbios_get_string(, sb->version,
- scratch, sizeof(scratch))) != NULL)
- printf(" version \"%s\"",
- fixstring(scratch));
+ scratch, sizeof(scratch))) != NULL) {
+ sminfop = fixstring(scratch);
+ if (sminfop != NULL) {
+ strlcpy(smbios_bios_version,
+ sminfop,
+ sizeof(smbios_bios_version));
+ printf(" version \"%s\"", sminfop);
+ }
+ }
if ((smbios_get_string(, sb->release,
scratch, sizeof(scratch))) != NULL) {
sminfop = fixstring(scratch);
Index: sys/arch/i386/i386/bios.c
===
RCS file: /cvs/src/sys/arch/i386/i386/bios.c,v
retrieving revision 1.128
diff -u -p -r1.128 bios.c
--- sys/arch/i386/i386/bios.c 30 Jan 2023 10:49:04 - 1.128
+++ sys/arch/i386/i386/bios.c 14 Mar 2023 11:24:40 -
@@ -125,6 +125,7 @@ const char *smbios_uninfo[] = {
char smbios_bios_date[64];
+char smbios_bios_version[64];
char smbios_board_vendor[64];
char smbios_board_prod[64];
char smbios_board_serial[64];
@@ -291,9 +292,16 @@ biosattach(struct device *parent, struct
printf(" vendor %s",
fixstring(scratch));
if ((smbios_get_string(, sb->version,
- scratch, sizeof(scratch))) != NULL)
- printf(" version \"%s\"",
- fixstring(scratch));
+ scratch, sizeof(scratch))) != NULL) {
+ sminfop = fixstring(scratch);
+ if (sminfop != NULL) {
+ strlcpy(smbios_bios_version,
+ sminfop,
+
sizeof(smbios_bios_version));
+ printf(" version \"%s\"",
+ sminfop);
+ }
+ }
if ((smbios_get_string(, sb->release,
scratch, sizeof(scratch))) != NULL) {
sminfop = fixstring(scratch);
Index: sys/dev/pci/drm/drm_linux.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
retrieving revision 1.96
diff -u -p -r1.96 drm_linux.c
--- sys/dev/pci/drm/drm_linux.c 10 Feb 2023 14:34:16 - 1.96
+++ sys/dev/pci/drm/drm_linux.c 14 Mar 2023 11:16:04 -
@@ -490,15 +490,21 @@ dmi_first_match(const struct dmi_system_
#if NBIOS > 0
extern char smbios_bios_date[];
+extern char smbios_bios_version[];
#endif
const char *
Re: amdgpu doesn't start; [drm] failed to load ucode VCN0_RAM(0x3A)
Jonathan Gray writes: > On Mon, Mar 13, 2023 at 07:21:13PM -0600, bent...@openbsd.org wrote: > > Hi, > > > > Since the Linux 6.1.2 drm update, the Valve Steam Deck no longer starts > > amdgpu. Instead, these messages print, and X starts with wsfb instead. > > which firmware package do you have installed? amdgpu-firmware-20230310 Reverting to 20221109 shows the same behavior: same firmware errors with a post-6.1.2 kernel, fancy framebuffer with pre-6.1.2.
