Re: kernel drm errors running latest snapshot

[Jonathan Gray]

On Fri, Sep 06, 2024 at 06:06:00AM +, Bunkmate wrote:
> >Synopsis:kernel drm errors running latest snapshot
> >Category:kernel drm
> >Environment:
>   System  : OpenBSD 7.6
>   Details : OpenBSD 7.6-beta (GENERIC.MP) #311: Thu Sep  5 10:15:45 
> MDT 2024
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   The latest snapshot has introduced drm errors.
> >How-To-Repeat:
>   Reboot system and review dmesg output.
> >Fix:
>   Unknown.
> 
> dmesg:
> OpenBSD 7.6-beta (GENERIC.MP) #311: Thu Sep  5 10:15:45 MDT 2024
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 16450445312 (15688MB)
> avail mem = 15928520704 (15190MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xe8d60 (52 entries)
> bios0: vendor American Megatrends International, LLC. version "F18" date 
> 03/22/2024
> bios0: Gigabyte Technology Co., Ltd. A520M S2H
> acpi0 at bios0: ACPI 6.2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT IVRS SSDT SSDT SSDT FIDT MCFG HPET FPDT TPM2 
> SSDT CRAT CDIT WPBT SSDT SSDT SSDT WSMT APIC SSDT SSDT SSDT
> acpi0: wakeup devices GP17(S4) XHC0(S4) XHC1(S4) GPP0(S4) PTXH(S4) PT20(S4) 
> PT21(S4) PT22(S4) PT23(S4) PT24(S4) PT26(S4) PT27(S4) PT28(S4) PT29(S4)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf000, bus 0-127
> acpihpet0 at acpi0: 14318180 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Ryzen 5 5600G with Radeon Graphics, 3900.01 MHz, 19-50-00, patch 
> 0a5f
> cpu0: cpuid 1 
> edx=178bfbff
>  
> ecx=76f8320b
> cpu0: cpuid 6 eax=4 ecx=1
> cpu0: cpuid 7.0 
> ebx=219c97a9
>  ecx=40068c edx=10
> cpu0: cpuid d.1 eax=f
> cpu0: cpuid 8001 edx=2fd3fbff 
> ecx=75c237ff
> cpu0: cpuid 8007 edx=6799
> cpu0: cpuid 8008 
> ebx=191ef657
> cpu0: cpuid 801F 
> eax=1780f 
> edx=1
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
> 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu0: mwait min=64, max=64, C-substates=1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: AMD Ryzen 5 5600G with Radeon Graphics, 3900.00 MHz, 19-50-00, patch 
> 0a5f
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: AMD Ryzen 5 5600G with Radeon Graphics, 3900.00 MHz, 19-50-00, patch 
> 0a5f
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: AMD Ryzen 5 5600G with Radeon Graphics, 3900.00 MHz, 19-50-00, patch 
> 0a5f
> cpu3: smt 0, core 3, package 0
> cpu4 at mainbus0: apid 8 (application processor)
> cpu4: AMD Ryzen 5 5600G with Radeon Graphics, 3900.00 MHz, 19-50-00, patch 
> 0a5f
> cpu4: smt 0, core 4, package 0
> cpu5 at mainbus0: apid 10 (application processor)
> cpu5: AMD Ryzen 5 5600G with Radeon Graphics, 3900.00 MHz, 19-50-00, patch 
> 0a5f
> cpu5: smt 0, core 5, package 0
> cpu6 at mainbus0: apid 1 (application processor)
> cpu6: AMD Ryzen 5 5600G with Radeon Graphics, 3900.00 MHz, 19-50-00, patch 
> 0a5f
> cpu6: smt 1, core 0, package 0
> cpu7 at mainbus0: apid 3 (application processor)
> cpu7: AMD Ryzen 5 5600G with Radeon Graphics, 3900.00 MHz, 19-50-00, patch 
> 0a5f
> cpu7: smt 1, core 1, package 0
> cpu8 at mainbus0: apid 5 (application processor)
> cpu8: AMD Ryzen 5 5600G with Radeon Graphics, 3900.00 MHz, 19-50-00, patch 
> 0a5f
> cpu8: smt 1, core 2, package 0
> cpu9 at mainbus0: apid 7 (application processor)
> cpu9: AMD Ryzen 5 5600G with Radeon Graphics, 3900.00 MHz, 19-50-00, patch 
> 0a5f
> cpu9: smt 1, core 3, package 0
> cpu10 at mainbus0: apid 9 (application processor)
> cpu10: AMD Ryzen 5 5600G with Radeon Graphics, 3900.00 MHz, 19-50-00, patch 
> 0a5f
> cpu10: smt 1, core 4, package 0
> cpu11 at mainbus0: apid 11 (application processor)
> cpu11: AMD Ryzen 5 5600G with Radeon Graphics, 3900.00 MHz, 19-50-00, patch 
> 0a5f
> cpu11: smt 1, core 5, package 0
> ioapic0 at mainbus0: apid 13 pa 0xfec0, version 21, 24 pins
> ioapic1 at mainbus0: apid 14 pa 0xfec01000, version 21, 32 pins
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (GPP6)
> acpiprt2 at acpi0: bus -1 (GPP7)
> acpiprt3 at acpi0: bus -1 (GPP8)
> acpiprt4 at acpi0: bus -1 (GPP9)
> acpiprt5 at acpi0: bus 6 (GP17)
> acpiprt6 at acpi0: bus -1 (GPP0)
> acpiprt7 at acpi0: bus -1 (GP18)
> acpiprt8 at acpi0: bus 5 (GPP4)
> acpiprt9 at acpi0: bus -1 (GPP5)
> acpiprt10 at acpi0: bus 1 (GPP3)
> acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
> acpicmos0 at acpi0
> com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4

Re: Boot fails with Intel GMA 945 (driver i915 crashes)

[Jonathan Gray]

On Tue, Sep 03, 2024 at 01:01:58AM +0300, xezo360hye wrote:
> > Synopsis:  Boot fails with Intel GMA 945 (driver i915 crashes)
> > Category:  system
> > Environment:
> System  : OpenBSD 7.5
> Details : OpenBSD 7.5 (GENERIC) #79: Wed Mar 20 15:33:49 MDT
> 2024
>  dera...@amd64.openbsd.org:/usr/src/sys/arch/
> amd64/compile/GENERIC
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> 
> > Description:
> I have an old laptop (Fujitsu-Siemens Amilo Li 1820) with Core 2 T5200
> processor and 945 GMA graphics chip in it. I have tried using FreeBSD and
> OpenBSD there. On FreeBSD, the system crashes when I do `kldload i945kms'.
> OpenBSD tries to load the driver itself and crashes on boot, entering ddb.
> 
> The kernel panic reason (`show panic') is "*cpu0: can't map aperture". Below
> I've copied the trace from the screen.
> 
> panic: can't map aperture
> Stopped at  db_enter+0x14:  popq%rbp
> TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> * 0  0  0 0x1  0x2000  swapper
> db_enter() at db_enter+0x14
> panic(8217cca3) at panic+0xb5
> i915_ggtt_init_hw(80078000) at i915_ggtt_init_hw+0x18d
> i915_driver_probe(80078000,0) at i915_driver_probe+0x407
> inteldrm_attachhook(80078000) at inteldrm_attachhook+0x47
> config_process_deferred_mountroot() at \
> config_process_deferred_mountroot+0x68
> main(e) at main+0x6cb
> end trace frame: 0x0, count: 8
> 
> I'm using the latest OpenBSD release, updated just yesterday. This is a
> full-disk installation made from and used on another machine (which works
> just fine), I've pulled the hard drive and put it into this laptop to see if
> OpenBSD would work better out of the box than FreeBSD. Apparently no.
> 
> I should also probably mention that on FreeBSD, the tty works fine until I
> load the i915kms module, OR try to `startx' with `xf86-video-intel'
> installed. Without it X defaults to the `vesa' driver and starts but does
> not give any sane picture (see attachment). In case these are related and
> info from FreeBSD is useful, I've already put the old drive back and will be
> able to provide further information as needed. I can also provide additional
> info about the OpenBSD system I'm running (although it's pretty much a fresh
> installation, except a few packages were added) but only when booted from
> another laptop.
> 
> > How-To-Repeat:
> step 1. boot openbsd on system with 945GMA chip
> step 2. watch openbsd die
> 
> 
> I'd be glad if I could somehow help to solve this issue, but please note
> that I'm very new to OpenBSD so don't expect me to rewrite a driver on my
> own.

look for a bios option to change the amount of stolen/video memory

This diff (against -current) turns the panic into a printf.
It should allow the console to go back to vga when this occurs.

to temporarily disable inteldrm, at the boot prompt

boot -c
disable inteldrm*
quit

Index: sys/dev/pci/drm/i915/gt/intel_ggtt.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/gt/intel_ggtt.c,v
diff -u -p -r1.12 intel_ggtt.c
--- sys/dev/pci/drm/i915/gt/intel_ggtt.c13 Aug 2024 00:08:07 -  
1.12
+++ sys/dev/pci/drm/i915/gt/intel_ggtt.c2 Sep 2024 22:46:09 -
@@ -101,8 +101,12 @@ static int ggtt_init_hw(struct i915_ggtt
PG_PMAP_WC);
if (bus_space_map(i915->bst, ggtt->gmadr.start,
ggtt->mappable_end,
-   BUS_SPACE_MAP_LINEAR | BUS_SPACE_MAP_PREFETCHABLE, &bsh))
-   panic("can't map aperture");
+   BUS_SPACE_MAP_LINEAR | BUS_SPACE_MAP_PREFETCHABLE, &bsh)) {
+   printf("%s: can't map aperture\n",
+   i915->sc_dev.dv_xname);
+   ggtt->vm.cleanup(&ggtt->vm);
+   return -EIO;
+   }
ggtt->iomap.base = ggtt->gmadr.start;
ggtt->iomap.size = ggtt->mappable_end;
ggtt->iomap.iomem = bus_space_vaddr(i915->bst, bsh);

Re: *ERROR* Unable to locate a BIOS ROM | *ERROR* Fatal error during GPU init

[Jonathan Gray]

On Sat, Aug 31, 2024 at 12:34:57PM +0300, Efe Kndmr wrote:
> OpenBSD 7.6-beta (GENERIC.MP) #299: Fri Aug 30 20:55:49 MDT 2024
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 25645088768 (24457MB)
> avail mem = 24844369920 (23693MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xaa857000 (58 entries)
> bios0: vendor LENOVO version "R0PET73W (1.50 )" date 11/07/2023
> bios0: LENOVO 20KN007UTX
> efi0 at bios0: UEFI 2.5
> efi0: Lenovo rev 0x730
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT BOOT BATB
> SSDT SSDT SSDT DBGP DBG2 POAT SSDT SSDT SSDT DMAR ASF! FPDT UEFI
> acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4)
> PEGP(S4) PEGA(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4)
> RP05(S4) PXSX(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 2399 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1305.95 MHz, 06-8e-0a,
> patch 00f6
> cpu0: cpuid 1
> edx=bfebfbff
> ecx=75fafbbf
> cpu0: cpuid 6 eax=27f7 ecx=9
> cpu0: cpuid 7.0
> ebx=29c67af
> edx=bc002e00
> cpu0: cpuid a vers=4, gp=4, gpwidth=48, ff=3, ffwidth=48
> cpu0: cpuid d.1 eax=f
> cpu0: cpuid 8001 edx=2c100800
> ecx=121
> cpu0: cpuid 8007 edx=100
> cpu0: msr 10a=a000c04
> cpu0: MELTDOWN
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
> 64b/line 4-way L2 cache, 6MB 64b/line 12-way L3 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1175.02 MHz, 06-8e-0a,
> patch 00f6
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 1013.28 MHz, 06-8e-0a,
> patch 00f6
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 907.61 MHz, 06-8e-0a, patch
> 00f6
> cpu3: smt 0, core 3, package 0
> cpu4 at mainbus0: apid 1 (application processor)
> cpu4: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.91 MHz, 06-8e-0a, patch
> 00f6
> cpu4: smt 1, core 0, package 0
> cpu5 at mainbus0: apid 3 (application processor)
> cpu5: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.91 MHz, 06-8e-0a, patch
> 00f6
> cpu5: smt 1, core 1, package 0
> cpu6 at mainbus0: apid 5 (application processor)
> cpu6: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.91 MHz, 06-8e-0a, patch
> 00f6
> cpu6: smt 1, core 2, package 0
> cpu7 at mainbus0: apid 7 (application processor)
> cpu7: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz, 897.91 MHz, 06-8e-0a, patch
> 00f6
> cpu7: smt 1, core 3, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf800, bus 0-63
> acpiec0 at acpi0
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 2 (RP01)
> acpiprt2 at acpi0: bus -1 (RP02)
> acpiprt3 at acpi0: bus -1 (RP03)
> acpiprt4 at acpi0: bus -1 (RP04)
> acpiprt5 at acpi0: bus 3 (RP05)
> acpiprt6 at acpi0: bus -1 (RP06)
> acpiprt7 at acpi0: bus -1 (RP07)
> acpiprt8 at acpi0: bus -1 (RP08)
> acpiprt9 at acpi0: bus 4 (RP09)
> acpiprt10 at acpi0: bus -1 (RP10)
> acpiprt11 at acpi0: bus 5 (RP11)
> acpiprt12 at acpi0: bus -1 (RP12)
> acpiprt13 at acpi0: bus -1 (RP13)
> acpiprt14 at acpi0: bus -1 (RP14)
> acpiprt15 at acpi0: bus -1 (RP15)
> acpiprt16 at acpi0: bus -1 (RP16)
> acpiprt17 at acpi0: bus -1 (RP17)
> acpiprt18 at acpi0: bus -1 (RP18)
> acpiprt19 at acpi0: bus -1 (RP19)
> acpiprt20 at acpi0: bus -1 (RP20)
> acpiprt21 at acpi0: bus -1 (RP21)
> acpiprt22 at acpi0: bus -1 (RP22)
> acpiprt23 at acpi0: bus -1 (RP23)
> acpiprt24 at acpi0: bus -1 (RP24)
> acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
> acpithinkpad0 at acpi0: version 2.0
> acpiac0 at acpi0: AC unit offline
> acpibat0 at acpi0: BAT0 model "01AV447" serial   371 type LiP oem "SMP"
> acpicmos0 at acpi0
> acpibtn0 at acpi0: SLPB(wakeup)
> "PNP0C14" at acpi0 not configured
> acpibtn1 at acpi0: LID_(wakeup)
> "PNP0C14" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> "USBC000" at acpi0 not configured
> acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
>

Re: S3 resume

[Jonathan Gray]

On Wed, Aug 21, 2024 at 10:11:45PM -0400, Josh Rickmar wrote:
> >Synopsis:S3 amdgpu resume broken on latest kernels
> >Category:amdgpu
> >Environment:
>   System  : OpenBSD 7.6
>   Details : OpenBSD 7.6-beta (GENERIC.MP) #48: Wed Aug 21 21:59:08 
> EDT 2024
>
> jr...@desktop.zettaport.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> 
> Initially I thought this was due to S0ix but after building my own
> bisecting my own kernels, it seems something tickled the S3 codepath
> for me in a way that breaks my resume.  I've bisected it down to this
> commit:
> 
> 2024-08-16 cc2e793a kettenis  Hook up a few more bits of suspend/resume power 
> management code.  This
> 
> and more specifically, an added call to amdgpu_pmops_suspend_noirq()
> that seems like it should not be running on my hardware.

does this help?

reverts our rev 1.16 'Skip the FADT check on OpenBSD' and adds

'drm/amd: Explicitly check for GFXOFF to be enabled for s0ix'
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=e4c44b1a19625348fc004ce8c5f828d5d80d037e

if it helps, is removing the ifdef without adding the if block enough?

Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_acpi.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_acpi.c,v
diff -u -p -r1.16 amdgpu_acpi.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_acpi.c17 Aug 2024 10:41:24 -  
1.16
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_acpi.c22 Aug 2024 05:12:52 -
@@ -1519,7 +1519,9 @@ bool amdgpu_acpi_is_s0ix_active(struct a
if (adev->asic_type < CHIP_RAVEN)
return false;
 
-#ifdef __linux__
+   if (!(adev->pm.pp_feature & PP_GFXOFF_MASK))
+   return false;
+
/*
 * If ACPI_FADT_LOW_POWER_S0 is not set in the FADT, it is generally
 * risky to do any special firmware-related preparations for entering
@@ -1532,7 +1534,6 @@ bool amdgpu_acpi_is_s0ix_active(struct a
  "To use suspend-to-idle change the sleep mode in 
BIOS setup.\n");
return false;
}
-#endif
 
 #if !IS_ENABLED(CONFIG_AMD_PMC)
dev_err_once(adev->dev,

Re: Oneshot S0

[Jonathan Gray]

On Fri, Aug 16, 2024 at 12:52:59AM +0200, Mark Kettenis wrote:
> 
> That diff skips amdgpu_pmops_prepare().  Here is a better diff.  And
> interestingly enough this fixes S3 suspend/resume on my m715q mini
> desktop with:
> 
> amdgpu0: RAVEN GC 9.1.0 8 CU rev 0x01

I agree this diff is better.

> 
> I had to backport the following diff that's not in linux-stable to get
> rid of a warning:
> 
> commit 3a9626c816db901def438dc2513622e281186d39
> Author: Mario Limonciello 
> Date:   Wed Feb 7 23:52:55 2024 -0600
> 
> drm/amd: Stop evicting resources on APUs in suspend
> 
> commit 5095d5418193 ("drm/amd: Evict resources during PM ops prepare()
> callback") intentionally moved the eviction of resources to earlier in
> the suspend process, but this introduced a subtle change that it occurs
> before adev->in_s0ix or adev->in_s3 are set. This meant that APUs
> actually started to evict resources at suspend time as well.
> 
> Explicitly set s0ix or s3 in the prepare() stage, and unset them if the
> prepare() stage failed.
> 
> v2: squash in warning fix from Stephen Rothwell
> 
> Reported-by: Jrg Billeter 
> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3132#note_2271038
> Fixes: 5095d5418193 ("drm/amd: Evict resources during PM ops prepare() 
> callback")

the commit this fixes was backported to linux 6.6.26

commit 8b5f720486ca87e102ee722a73ae0894c12f1e7a
Author: Mario Limonciello 
AuthorDate: Fri Oct 6 13:50:20 2023 -0500
Commit: Greg Kroah-Hartman 
CommitDate: Wed Apr 10 16:35:55 2024 +0200

drm/amd: Evict resources during PM ops prepare() callback

[ Upstream commit 5095d5418193eb2748c7d8553c7150b8f1c44696 ]

> 
> The diff also defines CONFIG_AMD_PMC and #ifdefs out the FADT check.
> With that suspend-to-idle also works on that m715q.  I'm still not
> entirely sure what to do there.  But I'll probably propose to commit
> those separately such that we can easily back those bits out.
> 
> Thoughts?  Tests?  ok?

ok jsg@

suspend/resume on t495 still works

bios0: vendor LENOVO version "R12ET61W(1.31 )" date 07/28/2022
bios0: LENOVO 20NJCTO1WW
efi0 at bios0: UEFI 2.7
efi0: Lenovo rev 0x11f0
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
...
amdgpu0: PICASSO GC 9.1.0 10 CU rev 0x01
amdgpu0: 1920x1080, 32bpp
wsdisplay0 at amdgpu0 mux 1: console (std, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uhub0 detached
ugen0 detached
video0 detached
uvideo0 detached
uhub2 detached
uhub1 detached
uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 
addr 1
uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 
addr 1
uhub1: device problem, disabling port 1
uhub1: device problem, disabling port 2
wakeups: 0 1
wakeup event: unknown

uhub problem is fixed by reverting xhci.c rev 1.133

> 
> 
> Index: dev/pci/drm/amd/amdgpu/amdgpu.h
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu.h,v
> diff -u -p -r1.24 amdgpu.h
> --- dev/pci/drm/amd/amdgpu/amdgpu.h   11 Apr 2024 03:24:40 -  1.24
> +++ dev/pci/drm/amd/amdgpu/amdgpu.h   15 Aug 2024 22:34:06 -
> @@ -1487,9 +1487,11 @@ static inline int amdgpu_acpi_smart_shif
>  #if defined(CONFIG_ACPI) && defined(CONFIG_SUSPEND)
>  bool amdgpu_acpi_is_s3_active(struct amdgpu_device *adev);
>  bool amdgpu_acpi_is_s0ix_active(struct amdgpu_device *adev);
> +void amdgpu_choose_low_power_state(struct amdgpu_device *adev);
>  #else
>  static inline bool amdgpu_acpi_is_s0ix_active(struct amdgpu_device *adev) { 
> return false; }
>  static inline bool amdgpu_acpi_is_s3_active(struct amdgpu_device *adev) { 
> return false; }
> +static inline void amdgpu_choose_low_power_state(struct amdgpu_device *adev) 
> { }
>  #endif
>  
>  #if defined(CONFIG_DRM_AMD_DC)
> Index: dev/pci/drm/amd/amdgpu/amdgpu_acpi.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_acpi.c,v
> diff -u -p -r1.14 amdgpu_acpi.c
> --- dev/pci/drm/amd/amdgpu/amdgpu_acpi.c  26 Jan 2024 11:36:26 -  
> 1.14
> +++ dev/pci/drm/amd/amdgpu/amdgpu_acpi.c  15 Aug 2024 22:34:06 -
> @@ -1519,6 +1519,7 @@ bool amdgpu_acpi_is_s0ix_active(struct a
>   if (adev->asic_type < CHIP_RAVEN)
>   return false;
>  
> +#ifdef __linux__
>   /*
>* If ACPI_FADT_LOW_POWER_S0 is not set in the FADT, it is generally
>* risky to do any special firmware-related preparations for entering
> @@ -1531,6 +1532,7 @@ bool amdgpu_acpi_is_s0ix_active(struct a
> "To use suspend-to-idle change the sleep mode in 
> BIOS setup.\n");
>   return false;
>   }
> +#endif
>  
>  #if !IS_ENABLED(CONFIG_AMD_PMC)
>   dev_err_once(adev->dev,
> @@ -1539,6 +1541,21 @@ bool amdgpu_acpi_is_s0ix_active(struct a
>  #else
>   return true;
>  #endif /* CONFIG_

Re: Oneshot S0

[Jonathan Gray]

for in_s0ix to be set the activate function needs to
call the pmops wrappers

that may help

amdgpu_pm_ops contains other function pointers that may
also be of interest

Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c,v
diff -u -p -r1.44 amdgpu_drv.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c 14 May 2024 04:55:42 -  
1.44
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c 15 Aug 2024 03:45:44 -
@@ -2412,9 +2412,10 @@ static void amdgpu_pmops_complete(struct
/* nothing to do */
 }
 
-static int amdgpu_pmops_suspend(struct device *dev)
+#endif /* notyet */
+
+static int amdgpu_pmops_suspend(struct drm_device *drm_dev)
 {
-   struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
 
adev->suspend_complete = false;
@@ -2427,9 +2428,8 @@ static int amdgpu_pmops_suspend(struct d
return amdgpu_device_suspend(drm_dev, true);
 }
 
-static int amdgpu_pmops_suspend_noirq(struct device *dev)
+static int amdgpu_pmops_suspend_noirq(struct drm_device *drm_dev)
 {
-   struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
 
adev->suspend_complete = true;
@@ -2439,18 +2439,19 @@ static int amdgpu_pmops_suspend_noirq(st
return 0;
 }
 
-static int amdgpu_pmops_resume(struct device *dev)
+static int amdgpu_pmops_resume(struct drm_device *drm_dev)
 {
-   struct drm_device *drm_dev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(drm_dev);
int r;
 
if (!adev->in_s0ix && !adev->in_s3)
return 0;
 
+#ifdef notyet
/* Avoids registers access if device is physically gone */
if (!pci_device_is_present(adev->pdev))
adev->no_hw_access = true;
+#endif
 
r = amdgpu_device_resume(drm_dev, true);
if (amdgpu_acpi_is_s0ix_active(adev))
@@ -2460,6 +2461,8 @@ static int amdgpu_pmops_resume(struct de
return r;
 }
 
+#ifdef notyet
+
 static int amdgpu_pmops_freeze(struct device *dev)
 {
struct drm_device *drm_dev = dev_get_drvdata(dev);
@@ -3672,14 +3675,15 @@ amdgpu_activate(struct device *self, int
case DVACT_QUIESCE:
rv = config_activate_children(self, act);
amdgpu_device_prepare(dev);
-   amdgpu_device_suspend(dev, true);
+   amdgpu_pmops_suspend(dev);
break;
case DVACT_SUSPEND:
+   amdgpu_pmops_suspend_noirq(dev);
break;
case DVACT_RESUME:
break;
case DVACT_WAKEUP:
-   amdgpu_device_resume(dev, true);
+   amdgpu_pmops_resume(dev);
rv = config_activate_children(self, act);
break;
}

Re: Missing 'format' word in glDrawPixels documentation

[Jonathan Gray]

doc/gl-docs is outdated and should either be removed or replaced with
the newer docbook pages converted.  I'm not sure how viable that is
with docbook2mdoc.

https://github.com/KhronosGroup/OpenGL-Refpages
https://mandoc.bsd.lv/docbook2mdoc/

https://registry.khronos.org/OpenGL-Refpages/gl2.1/
https://registry.khronos.org/OpenGL-Refpages/gl4/

On Sun, Jul 07, 2024 at 09:17:56AM +, ZenitDS wrote:
> Index: drawpixels.3gl
> ===
> RCS file: /cvs/xenocara/doc/gl-docs/GL/gl/drawpixels.3gl,v
> retrieving revision 1.1.1.1
> diff -u -p -r1.1.1.1 drawpixels.3gl
> --- drawpixels.3gl29 Nov 2006 17:00:40 -  1.1.1.1
> +++ drawpixels.3gl7 Jul 2024 09:15:55 -
> @@ -33,7 +33,7 @@ Specify the dimensions of the pixel rect
>  into the frame buffer.
>  .TP
>  \f2format\fP
> -Specifies the  of the pixel data.
> +Specifies the format of the pixel data.
>  Symbolic constants
>  \%\f3GL_COLOR_INDEX\fP,
>  \%\f3GL_STENCIL_INDEX\fP,
> 
> 

Re: Systems crash after call netstart

[Jonathan Gray]

On Wed, Jun 19, 2024 at 03:37:17PM +, Marco Agostani wrote:
> 
> >Synopsis:  ifconfig on a sec interface crash the system
> >Category:  System Hangs
> >Environment:
> System  : OpenBSD 7.5
> Details : OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 
> 2024
>  
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> I call sh /etc.netstart after a change to some interfaces the system 
> suddenly crash
> After some dig up I discovered that one interface is responsible for 
> the issue.
> /etc/hostname.sec7129
> 
>   10.0.1.234 10.0.1.233 description "to CAT tun7129"
>   up
>   !route add 10.219.128/19 10.0.1.233 -mpath -label AWSCAT
> 
>doing the same for exmaple on other sec interface has no issues
> 
> i.e.
> ifconfig sec8129 10.0.1.238 10.0.1.237 exit w/o doing nothing 
> weird
> 
>systemctl.conf contents
> 
> ddb.panic=1
> kern.bufcachepercent=60# Allow the kernel to use up to 90% of 
> the RAM for cache (default 10%)
> net.inet.ip.forwarding=1   # Permit forwarding (routing) of 
> packets through the firewall
> net.inet.icmp.errppslimit=1000 # Maximum number of outgoing ICMP 
> error messages per second
> net.inet.ip.mtudisc=1  # TCP MTU (Maximum Transmission Unit) 
> discovery off since our mss is small enough
> net.inet.tcp.rfc3390=1 # Enable RFC3390 TCP window increasing 
> so larger CWND can take affect
> net.inet.ip.ttl=64 # the TTL should match what we have 
> for "min-ttl" in scrub rule in pf.conf
> net.inet.tcp.ackonpush=1   # acks for packets with the push bit 
> set should not be delayed
> net.inet.tcp.ecn=0 # Explicit Congestion Notification 
> enabled
> net.inet.tcp.mssdflt=1452  # maximum segment size (1440 from 
> scrub pf.conf match statement)
> net.inet.carp.log=2# Log CARP state changes
> net.inet.carp.preempt=1# Enable CARP interfaces to preempt 
> each other (0 -> 1)
> net.inet.ip.forwarding=1   # Enable packet forwarding through the 
> firewall (0 -> 1)
> net.inet.ip.multipath=1# Enable multipathing
> 
> 
> >How-To-Repeat:
> ifconfig sec7129 10.0.1.234 10.0.1.233

trace in the png:

panic: kernel diagnostic assertion "!ISSET(rt->rt_flags, RTF_UP)" failed: file 
"/usr/src/sys/net/route.c", line 590
panic+0x130
__assert+0x29
rtfree+0x1bf
route_output+0x464
route_send+0x5b
sosend+0x385
dofilewritev+0x151
sys_writev+0xd2
syscall+0x55b
Xsyscall+0x128

Re: Minor doc-vs-implemention conflict in /etc/daily vs test(1)

[Jonathan Gray]

On Tue, Jun 18, 2024 at 11:32:58AM +1000, Jonathan Gray wrote:
> 
> v8 (Feb 1985) and later /bin/test has -L, no -h
> from looking at tuhs archives

checking some earlier manual pages

sunos 1.1 1984, test does not have -h
.\" @(#)test.1 1.1 83/08/08 SMI; from UCB 4.2
.TH TEST 1  "18 January 1983"

sunos 2.0 1985, test has -h
.\" @(#)test.1 1.5 85/04/05 SMI; from UCB 4.2
.TH TEST 1  "1 February 1985"

> 
> sunos 3.0 (Feb 1986) /bin/test has -h but no -L
> bitsavers sun/sunos/3.0/800-1289-03A_Doing_More_with_UNIX_198602.pdf
> pg 138
> 
> HP-UX (Oct 1987)
> /bin/ksh has -L
> bitsavers 
> hp/9000_hpux/1987/97089-90062_198710_HP-UX_Concepts_Shells_and_Misc_Tools.pdf
> pg 221
> 
> HP-UX 7.0 (Sep 1989) /bin/test has -h not no -L
> bitsavers 
> hp/9000_hpux/7.x/09000-90013_HP-UX_7.0_Reference_Vol_1_Section_1_Sep89.pdf
> pg 691
> 
> SVR3 (1987) /bin/test has neither
> bitsavers 
> att/unix/System_V_Release_3/UNIX_System_V_Users_Reference_Manual_1987.pdf
> 
> SVR4 (1989) /bin/test has -h and -L
> bitsavers 
> att/unix/System_V_Release_4/0-13-947037-9_Unix_System_V_Rel4_Users_Reference_Manual_1990.pdf
> 
> csrg bin/test/operators.c rev 5.2 (May 1993) adds -h, but not -L
> from looking a the sccs
> 
> 

Re: Minor doc-vs-implemention conflict in /etc/daily vs test(1)

[Jonathan Gray]

On Tue, Jun 18, 2024 at 12:10:03AM +0200, Ingo Schwarze wrote:
> Not a bug.
> But which one is preferable, test -L or test -h?
> 
> TLDR:
> If you follow David Korn, -L is the way to go.
> If you feel nostalgic about old SunOS, -h looks nicer.
> Both were standardized in POSIX Issue 6 (2001), with no preference given 
> there.
> Both always worked on OpenBSD, no matter which base system shell was used.
> In the OpenBSD ancestry, there was no difference in portability
> except between June 1993 and June 1995 (at most).
> 
> I admit that usually, when there are two equivalent syntaxes, deprecating
> one of them makes sense.  But in this case, with POSIX setting both in
> stone over 20 years ago, attempting to die on that particular molehill
> seems pointless to me.
> 
> Hence i suggest the patch below; OK?

ok jsg@

> 
> More complete history follows after the patch (just for the curious :-).
> This does not contradict what jmc@ wrote, but contains more information.

some extra notes on that below

> 
> Yours,
>   Ingo
> 
> 
> Index: test.1
> ===
> RCS file: /cvs/src/bin/test/test.1,v
> diff -u -p -r1.34 test.1
> --- test.110 Jun 2023 07:19:39 -  1.34
> +++ test.117 Jun 2024 21:22:30 -
> @@ -110,6 +110,8 @@ is set.
>  True if
>  .Ar file
>  exists and is a symbolic link.
> +Identical to
> +.Fl L .
>  .It Fl k Ar file
>  True if
>  .Ar file
> @@ -118,11 +120,8 @@ exists and its sticky bit is set.
>  True if
>  .Ar file
>  exists and is a symbolic link.
> -This operator is for compatibility purposes.
> -Do not rely on its existence;
> -use
> -.Fl h
> -instead.
> +Identical to
> +.Fl h .
>  .It Fl n Ar string
>  True if the length of
>  .Ar string
> Index: test.c
> ===
> RCS file: /cvs/src/bin/test/test.c,v
> diff -u -p -r1.20 test.c
> --- test.c11 Oct 2022 13:40:38 -  1.20
> +++ test.c17 Jun 2024 21:22:31 -
> @@ -110,7 +110,7 @@ struct t_op {
>   {"-t",  FILTT,  UNOP},
>   {"-z",  STREZ,  UNOP},
>   {"-n",  STRNZ,  UNOP},
> - {"-h",  FILSYM, UNOP},  /* for backwards compat */
> + {"-h",  FILSYM, UNOP},
>   {"-O",  FILUID, UNOP},
>   {"-G",  FILGID, UNOP},
>   {"-L",  FILSYM, UNOP},
> 
> 
>  - 8< - schnipp - >8 - 8< - schnapp - >8 -
> 
> History in OpenBSD ancestry:
> 
> OpenBSD:
> ksh(1) had both since the beginning, Aug 14, 1996 (pdksh 5.2.7).
> Before that, /bin/sh, which was ash, did not have a "test" builtin
> at all but used /bin/test instead, which also had both.
> csh(1) never had a "test" builtin.
> 
> NetBSD:
> /bin/test has -h since Feb 19, 1994 ("a la SunOS")
>   -L since Jun 30, 1994 ("from pdksh")
> 
> 4.4 BSD (June 1993) and 4.4BSD-Lite2 (June 1995):
> /bin/sh (ash) did not have a "test" builtin but used /bin/test instead.
> /bin/test had -h but not -L.
> 
> Version 7 AT&T UNIX (1979) and 4.3BSD-Reno (June 1990):
> /bin/sh (Bourne) did not have a "test" builtin but used /bin/test instead.
> /bin/test had neither -h nor -L.

"Dennis Ritchie implemented symlinks first, but doesn't take sole credit
for the idea, which came up in a group discussion at Berkeley."
https://groups.google.com/g/comp.unix.wizards/c/rkPBbdTELl0/m/skLmgp8G41QJ

v8 (Feb 1985) and later /bin/test has -L, no -h
from looking at tuhs archives

sunos 3.0 (Feb 1986) /bin/test has -h but no -L
bitsavers sun/sunos/3.0/800-1289-03A_Doing_More_with_UNIX_198602.pdf
pg 138

HP-UX (Oct 1987)
/bin/ksh has -L
bitsavers 
hp/9000_hpux/1987/97089-90062_198710_HP-UX_Concepts_Shells_and_Misc_Tools.pdf
pg 221

HP-UX 7.0 (Sep 1989) /bin/test has -h not no -L
bitsavers 
hp/9000_hpux/7.x/09000-90013_HP-UX_7.0_Reference_Vol_1_Section_1_Sep89.pdf
pg 691

SVR3 (1987) /bin/test has neither
bitsavers 
att/unix/System_V_Release_3/UNIX_System_V_Users_Reference_Manual_1987.pdf

SVR4 (1989) /bin/test has -h and -L
bitsavers 
att/unix/System_V_Release_4/0-13-947037-9_Unix_System_V_Rel4_Users_Reference_Manual_1990.pdf

csrg bin/test/operators.c rev 5.2 (May 1993) adds -h, but not -L
from looking a the sccs

Re: Unchartevice 6640MA dmesg + AHCI MSI quirk

[Jonathan Gray]

On Sat, Jun 15, 2024 at 09:35:30PM +, Klemens Nanni wrote:
> GENERIC and GENERIC_MP both hang with this diff after
>   cpu0: 4MB 64b/line 16-way L2 cache
> but I haven't looked into that yet.

...

> cpu0: ZHAOXIN KaiXian KX-6640MA@2.2+GHz, 2594.84 MHz, 07-0b-00

MTRR is not set on ramdisk kernels, try the diff below

Index: sys/arch/amd64/amd64/mtrr.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/mtrr.c,v
diff -u -p -r1.5 mtrr.c
--- sys/arch/amd64/amd64/mtrr.c 3 Apr 2024 02:01:21 -   1.5
+++ sys/arch/amd64/amd64/mtrr.c 16 Jun 2024 02:32:30 -
@@ -49,7 +49,7 @@ mem_range_attach(void)
if ((ci->ci_vendor == CPUV_AMD ||
 ci->ci_vendor == CPUV_INTEL ||
 ci->ci_vendor == CPUV_VIA) && 
-   (family == 0x6 || family == 0xf) &&
+   (family >= 0x6) &&
cpu_feature & CPUID_MTRR) {
mem_range_softc.mr_op = &mrops;
}

Re: Crash on resume from ZZZ

[Jonathan Gray]

On Mon, May 13, 2024 at 09:16:36PM -0700, Greg Steuck wrote:
> While restoring from suspend-to-disk my /bsd crashed

diff sent to this list earlier today committed as amdgpu_drv.c rev 1.44

Re: uvm_fault on unhibernating x395

[Jonathan Gray]

On Mon, May 13, 2024 at 08:10:32PM +0200, Florian Obser wrote:
> OCR'ed and edited a bit, there might be mistakes.
> Picture: https://dump.sha256.net/dump/unhibernating_panic.jpg
> 
> unhibernating & block 50329599 Length 243MB
> uvm_fault(0x826b2860, 0x38, 0, 1) →> e
> kernel: page fault trap, code=0
> Stopped at ttm_resource_manager_evict_all+0x5e: cmpq %rbx, 0x38(%r14)
> TID PID UID PRFLAGS   PFLAGS CPU COMMAND
> *   0   0   0   0x10  0x20   0K  swapper
> ttm_resource_manager_evict_all(8017f260,0,dba63e95861e671,8017,80170058,2)
>  at ttm_resource_
> manager_evict_all+0x5e
> amdgpu_device_prepare(80170058, 80170058, fac0345246af 9871, 
> 80170058,0,2) at amdgpu_device_prepare
> +0x61
> amdgpu_activate(8017, 2, b6a78044d3a303c5,0, 8014400, 
> fff f8228acc8) at amdgpu_activate+0x55
> config_activate_children(80144c00,2,172aac03cc1e?5dd,0,8014a000,2)
>  at config_activate_children+0x85
> config_activate_children(8014a000,2,172aac03cc1e75dd,0,80144100,2)
>  at config_activate_children+0x85
> config_activate_children(80144100,2,172aac03ccle75dd,0, 
> 80030280,2) at config_activate_chiLdren+0x85
> config_activate_children(80030280,2,172aac03cc1e7256,2,80030280,0)
> config_suspend_all (2,2,72519cb31f5203, fff f82a94a38,0,bfff50) at 
> config_suspend_all+0x1ae
> hibernate_resume(8c03129a1118d1c,82a9460,80142200,0.0,0) at 
> hibernate_resume+0x1b4
> diskconf (25badalafa9d6262,8, 82538360, 
> 82a8008,400056f4b50,8) at diskconf+0x188
> main(0,0,1001000, 800037c871f0,81fda030,82a94f40) at 
> main+0x510
> 
> I've bisected it to this changeset:
> https://codeberg.org/OpenBSD/src/commit/36668b1581688d40ad5fd6631f4f503e6d36091d
> 
> suspend / resume seems to be unaffected by this, reverting makes
> hibernate / unhibernate work again.

hibernate does DVACT_QUIESCE/DVACT_SUSPEND from
diskconf()/hibernate_resume() before config_process_deferred_mountroot()
attaches most of the driver.  So don't attempt to do anything.

Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c,v
diff -u -p -r1.43 amdgpu_drv.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c 11 Apr 2024 03:24:40 -  
1.43
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c 14 May 2024 02:50:02 -
@@ -3665,7 +3665,7 @@ amdgpu_activate(struct device *self, int
struct drm_device *dev = &adev->ddev;
int rv = 0;
 
-   if (dev->dev == NULL || amdgpu_fatal_error)
+   if (dev->dev == NULL || amdgpu_fatal_error || adev->shutdown)
return (0);
 
switch (act) {

Re: sincosl() segmentation fault

[Jonathan Gray]

On Wed, May 01, 2024 at 02:02:53PM +1000, Jonathan Gray wrote:
> On Tue, Apr 30, 2024 at 06:18:23PM +0100, colin.i.k...@gmail.com wrote:
> > >Synopsis:  sincosl() segmentation fault
> > >Category:  library
> > >Environment:
> > System  : OpenBSD 7.5
> > Details : OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024
> >  
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > calls to sincosl with long double arguments causes a segmentation fault.
> > >How-To-Repeat:
> > 
> > openbsd75$ cat x.c
> > #include 
> > 
> > int main(void)
> > {
> > long double theta = 0.0, s, c;
> > 
> > sincosl(theta, &s, &c);
> > }
> > openbsd75$ clang x.c -lm -o x 
> > openbsd75$ ./x
> > Segmentation fault (core dumped) 
> 
> NAN also crashes.
> 
> Both give the expected result with this diff.
> Thanks for the report.

committed to -current

Re: sincosl() segmentation fault

[Jonathan Gray]

On Tue, Apr 30, 2024 at 06:18:23PM +0100, colin.i.k...@gmail.com wrote:
> >Synopsis:sincosl() segmentation fault
> >Category:library
> >Environment:
>   System  : OpenBSD 7.5
>   Details : OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   calls to sincosl with long double arguments causes a segmentation fault.
> >How-To-Repeat:
> 
> openbsd75$ cat x.c
> #include 
> 
> int main(void)
> {
>   long double theta = 0.0, s, c;
> 
>   sincosl(theta, &s, &c);
> }
> openbsd75$ clang x.c -lm -o x 
> openbsd75$ ./x
> Segmentation fault (core dumped) 

NAN also crashes.

Both give the expected result with this diff.
Thanks for the report.

Index: lib/libm/src/s_sincosl.c
===
RCS file: /cvs/src/lib/libm/src/s_sincosl.c,v
diff -u -p -U10 -r1.1 s_sincosl.c
--- lib/libm/src/s_sincosl.c10 Mar 2018 20:52:58 -  1.1
+++ lib/libm/src/s_sincosl.c1 May 2024 03:47:16 -
@@ -65,26 +65,28 @@ sincosl(long double x, long double *sn, 
if (z.e < M_PI_4) {
/*
 * If x = +-0 or x is a subnormal number, then sin(x) = x and
 * cos(x) = 1.
 */
if (z.bits.ext_exp == 0) {
*sn = x;
*cs = 1;
} else
__kernel_sincosl(x, 0, 0, sn, cs);
+   return;
}
 
/* If x = NaN or Inf, then sin(x) and cos(x) are NaN. */
if (z.bits.ext_exp == 32767) {
*sn = x - x;
*cs = x - x;
+   return;
}
 
/* Split z.e into a 24-bit representation. */
e0 = ilogbl(z.e) - 23;
z.e = scalbnl(z.e, -e0);
for (i = 0; i < NX; i++) {
xd[i] = (double)((int32_t)z.e);
z.e = (z.e - xd[i]) * two24;
}
 

Re: Fwd: Assertion !cold failed in drm during sys_reboot

[Jonathan Gray]

On Tue, Apr 30, 2024 at 09:31:47AM -0500, Nathaniel Griswold wrote:
> 
> >Synopsis: Assertion !cold failed in drm after console ctrl-alt-del
> >Category: system
> >Environment:
> System  : OpenBSD 7.5
> Details : OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024
>  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> I was rebooting my system with ctrl-alt-del and got a panic. I believe i had 
> switched to
> a different console and possibly back in the meantime. xenodm was disabled. I 
> have intel_drm.
> >How-To-Repeat:
> 1) ctrl-alt-del on console
> 2) possibly switch consoles
> 3) possibly switch back

thanks for the report

for the archives, trace from the photo:

panic: kernel diagnostic assertion "!cold" failed: file 
"/usr/src/sys/dev/pci/drm/include/linux/completion.h", line 89
db_enter+0x14
panic+0xc3
__assert+0x29
drm_atomic_helper_swap_state+0x646
intel_atomic_commit+0x162
drm_atomic_commit+0xa7
drm_client_modeset_commit_atomic+0x178
drm_client_modeset_commit_locked+0x5a
drm_fb_helper_restore_fbdev_mode_unlocked+0x48
intel_fbdev_restore_mode+0x37
inteldrm_show_screen+0x88
wsdisplay_switch1+0xbc
internal_command+0x2b2
wskbd_translate+0xdf

drm code isn't able to handle requests when cold.  That is
partly why all drm drivers use config_mountroot().

Index: sys/dev/pci/drm/drm_fb_helper.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_fb_helper.c,v
diff -u -p -r1.38 drm_fb_helper.c
--- sys/dev/pci/drm/drm_fb_helper.c 5 Apr 2024 14:31:57 -   1.38
+++ sys/dev/pci/drm/drm_fb_helper.c 1 May 2024 01:47:05 -
@@ -242,6 +242,10 @@ __drm_fb_helper_restore_fbdev_mode_unloc
return 0;
 
 #ifdef __OpenBSD__
+   /* if we can't sleep, return */
+   if (cold)
+   return -ENXIO;
+
force = true;
 #endif
 

Re: amdgpu Xorg.0.log filled with flip queue failed and Page flip failed

[Jonathan Gray]

On Tue, Apr 16, 2024 at 02:32:17AM -0700, Nam Nguyen wrote:
> >Synopsis:amdgpu Xorg.0.log filled with flip queue failed and Page flip 
> >failed
> >Category:system
> >Environment:
>   System  : OpenBSD 7.5
>   Details : OpenBSD 7.5-current (GENERIC.MP) #25: Mon Apr 15 12:00:00 
> MDT 2024
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> 
> /var/log/Xorg.0.log gets filled up with the same repeating error while
> watching mpv yt-dlp and playing games/ezquake. This is on 6800xt amd64
> 3900x.
> 
> $ du -sh /var/log/Xorg.0.log  
> 1017M   /var/log/Xorg.0.log
> 
> >How-To-Repeat:
> 
> watch mpv yt-dlp several times leaves only two lines per video:
> [76.172] (WW) AMDGPU(0): flip queue failed: Invalid argument
> [76.172] (WW) AMDGPU(0): Page flip failed: Invalid argument
> [96.004] (WW) AMDGPU(0): flip queue failed: Invalid argument
> [96.004] (WW) AMDGPU(0): Page flip failed: Invalid argument
> [96.792] (WW) AMDGPU(0): flip queue failed: Invalid argument
> [96.792] (WW) AMDGPU(0): Page flip failed: Invalid argument

try the diff below which brings in
xf86-video-amdgpu-23.0.0..31a092ae71371fb473a3a51f70fe58e1f42e283b

the last commit is the one referenced in:
https://gitlab.freedesktop.org/drm/amd/-/issues/2852

https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/commit/31a092ae71371fb473a3a51f70fe58e1f42e283b

Index: driver/xf86-video-amdgpu/man/amdgpu.man
===
RCS file: /cvs/xenocara/driver/xf86-video-amdgpu/man/amdgpu.man,v
diff -u -p -r1.4 amdgpu.man
--- driver/xf86-video-amdgpu/man/amdgpu.man 1 Mar 2023 20:21:10 -   
1.4
+++ driver/xf86-video-amdgpu/man/amdgpu.man 16 Apr 2024 09:55:23 -
@@ -81,7 +81,8 @@ on. If this option is set, the default v
 accordingly. If this option isn't set, the default value of the property is
 .B auto,
 which means that TearFree is on for rotated outputs, outputs with RandR
-transforms applied and for RandR 1.4 secondary outputs, otherwise off.
+transforms applied, for RandR 1.4 secondary outputs and if 'VariableRefresh'
+is enabled, otherwise it's off.
 .TP
 .BI "Option \*qVariableRefresh\*q \*q" boolean \*q
 Enables support for enabling variable refresh on the Screen's CRTCs
Index: driver/xf86-video-amdgpu/src/amdgpu_kms.c
===
RCS file: /cvs/xenocara/driver/xf86-video-amdgpu/src/amdgpu_kms.c,v
diff -u -p -r1.6 amdgpu_kms.c
--- driver/xf86-video-amdgpu/src/amdgpu_kms.c   1 Mar 2023 20:21:10 -   
1.6
+++ driver/xf86-video-amdgpu/src/amdgpu_kms.c   16 Apr 2024 09:55:23 -
@@ -1657,6 +1657,10 @@ Bool AMDGPUPreInit_KMS(ScrnInfoPtr pScrn
from = xf86GetOptValBool(info->Options, 
OPTION_VARIABLE_REFRESH,
 &info->vrr_support) ? X_CONFIG 
: X_DEFAULT;
 
+   if (info->vrr_support && !info->tear_free)
+   xf86DrvMsg(pScrn->scrnIndex, X_WARNING,
+  "Enabling VariableRefresh while 
TearFree is disabled can cause instability!\n");
+
xf86DrvMsg(pScrn->scrnIndex, from, "VariableRefresh: 
%sabled\n",
   info->vrr_support ? "en" : "dis");
 
Index: driver/xf86-video-amdgpu/src/drmmode_display.c
===
RCS file: /cvs/xenocara/driver/xf86-video-amdgpu/src/drmmode_display.c,v
diff -u -p -r1.4 drmmode_display.c
--- driver/xf86-video-amdgpu/src/drmmode_display.c  5 Dec 2022 16:41:17 
-   1.4
+++ driver/xf86-video-amdgpu/src/drmmode_display.c  16 Apr 2024 09:55:23 
-
@@ -597,6 +597,7 @@ drmmode_crtc_update_tear_free(xf86CrtcPt
(drmmode_output->tear_free == 2 &&
 (crtc->scrn->pScreen->isGPU ||
  info->shadow_primary ||
+ info->vrr_support ||
  crtc->transformPresent || crtc->rotation != 
RR_Rotate_0))) {
drmmode_crtc->tear_free = TRUE;
return;
@@ -1268,6 +1269,11 @@ drmmode_set_mode(xf86CrtcPtr crtc, struc
if (output->crtc != crtc)
continue;
 
+   if (!drmmode_output->mode_output) {
+   ret = FALSE;
+   goto out;
+   }
+
output_ids[output_count] = 
drmmode_output->mode_output->connector_id;
output_count++;
}
@@ -1286,6 +1292,7 @@ drmmode_set_mode(xf86CrtcPtr crtc, struc
   "failed to set mode: %s\n", strerror(errno));
}
 
+out:
free(output_ids);
return ret;
 }

Re: protection fault in amap_wipeout

[Jonathan Gray]

On Sat, Apr 13, 2024 at 06:14:25PM +0200, Martin Pieuchot wrote:
> On 30/03/24(Sat) 18:38, Martin Pieuchot wrote:
> > Hello Alexander,
> > 
> > Thanks for the report.
> > 
> > On 01/03/24(Fri) 16:39, Alexander Bluhm wrote:
> > > Hi,
> > > 
> > > An OpenBSD 7.4 machine on KVM running postgress and pagedaemon
> > > crashed in amap_wipeout().
> > > 
> > > bluhm
> > > 
> > > kernel: protection fault trap, code=0
> > > Stopped at  amap_wipeout+0x76:  movq%rcx,0x28(%rax)
> > 
> > The problem is an incorrect call to amap_wipeout() in OOM situation
> > inside amap_copy().  At this moment the amap being copied/allocated
> > is not in the global list.  That's why you see this incorrect
> > dereference which corresponds to:
> > 
> > amap_list_remove(amap);
> > 
> > > ddb{3}> show panic
> > > the kernel did not panic
> > > 
> > > ddb{3}> trace
> > > amap_wipeout(fd8015b154d0) at amap_wipeout+0x76
> > > uvm_fault_check(8000232d6a20,8000232d6a58,8000232d6a80) at 
> > > uvm_faul
> > > t_check+0x2ad
> > > uvm_fault(fd811d150748,7d42519fb000,0,1) at uvm_fault+0xfb
> > > upageflttrap(8000232d6b80,7d42519fb3c0) at upageflttrap+0x65
> > > usertrap(8000232d6b80) at usertrap+0x1ee
> > > recall_trap() at recall_trap+0x8
> > > end of kernel
> > > end trace frame: 0x7d42519fb3f0, count: -6
> > 
> > Diff below should fix it.  I don't know how to test it.
> > 
> > ok?
> 
> Anyone?

ok jsg@

> 
> > Index: uvm/uvm_amap.c
> > ===
> > RCS file: /cvs/src/sys/uvm/uvm_amap.c,v
> > diff -u -p -r1.92 uvm_amap.c
> > --- uvm/uvm_amap.c  11 Apr 2023 00:45:09 -  1.92
> > +++ uvm/uvm_amap.c  30 Mar 2024 17:30:10 -
> > @@ -662,9 +658,10 @@ amap_copy(struct vm_map *map, struct vm_
> >  
> > chunk = amap_chunk_get(amap, lcv, 1, PR_NOWAIT);
> > if (chunk == NULL) {
> > -   /* amap_wipeout() releases the lock. */
> > -   amap->am_ref = 0;
> > -   amap_wipeout(amap);
> > +   amap_unlock(srcamap);
> > +   /* Destroy the new amap. */
> > +   amap->am_ref--;
> > +   amap_free(amap);
> > return;
> > }
> >  
> > 
> 
> 

Re: Thinkpad x201 LDVS1 not recognized until xenodm starts since 7.5 upgrade

[Jonathan Gray]

On Thu, Apr 11, 2024 at 11:17:01AM +0200, lidstah wrote:
> Le Mon, Apr 08, 2024 at 02:43:01PM +1000, Jonathan Gray a écrit :
> > 
> > I could not reproduce this on a thinkpad x201 with a snapshot or 7.5.
> > 
> > The machine I tested on has bios 1.40 compared to your 1.32.
> > 
> > Could be related to:
> > 
> > <1.37>
> >  BIOS: 1.37 / ECP: 1.14/1.14/1.14
> >  - (Fix) Fixed an issue where display blackout might occur by uninstalling
> >  video driver on the system with Windows Vista or Windows 7.
> > 
> > https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/6quj19uc.txt
> > https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/6quj19us.iso
> > 
> 
> That was it, thank you for taking the time to verify it on your x201,
> and thank you for the links, saved me some time! I'm a bit ashamed I
> failed to check the BIOS version before posting :/.
> 
> Best regards,

Glad to hear it works.  I later changed the code in -current that sets
up the initial framebuffer to be closer to linux.  That could help x201
on the old firmware.

Re: Thinkpad x201 LDVS1 not recognized until xenodm starts since 7.5 upgrade

[Jonathan Gray]

On Fri, Apr 05, 2024 at 03:01:15PM +0200, lidstah wrote:
> >Synopsis:Thinkpad x201 LVDS1 not recognized after upgrade to 7.5
> >Category:system
> >Environment:
>   System  : OpenBSD 7.5
>   Details : OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   After upgrading to OpenBSD 7.5 on a thinkpad x201, and after
>   bootloader and kernel messages, wscons shows nothing until xenodm
>   starts.  Xenodm starts in 640x400 mode. Once logged, a first xrandr
>   command doesn't show the LVDS1 video output. A second xrandr, for
>   e.g.: xrandr --output LVDS1 --mode 1280x800 correct the problem.
>   Switching to a virtual console with Ctrl-Alt-Fx then works as
>   intended.
> 
>   OpenBSD 7.5 has been upgraded from an almost fresh 7.4 install (two
>   weeks ago) The upgrade was done through sysupgrade, then sysmerge,
>   syspatch and pkg_add -u were run as usual.
> >How-To-Repeat:
>   Upgrade to OpenBSD 7.5 from 7.4 on a Lenovo Thinkpad x201.
> >Fix:
>   A workaround has been to put the following lines in
>   /etc/X11/xenodm/Xsetup_0:
>   # first xrandr to "discover" lvds1
>   ${exec_prefix}/bin/xrandr 
>   # correct resolution
>   ${exec_prefix}/bin/xrandr --output LVDS1 --mode 1280x800
> 
>   although this doesn't - of course - solve the wscons black screen
>   during boot it allows to recover usability of both X and wscons after
>   xenodm starts.

I could not reproduce this on a thinkpad x201 with a snapshot or 7.5.

The machine I tested on has bios 1.40 compared to your 1.32.

Could be related to:

<1.37>
 BIOS: 1.37 / ECP: 1.14/1.14/1.14
 - (Fix) Fixed an issue where display blackout might occur by uninstalling
 video driver on the system with Windows Vista or Windows 7.

https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/6quj19uc.txt
https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/6quj19us.iso

OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4062691328 (3874MB)
avail mem = 3918553088 (3737MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
bios0: vendor LENOVO version "6QET70WW (1.40 )" date 10/11/2012
bios0: LENOVO 3680MG1
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA DMAR 
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) 
EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 2660.21 MHz, 06-25-05, patch 
0007
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 
8-way L2 cache, 3MB 64b/line 12-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 2660.36 MHz, 06-25-05, patch 
0007
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 
8-way L2 cache, 3MB 64b/line 12-way L3 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 2660.26 MHz, 06-25-05, patch 
0007
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line 
8-way L2 cache, 3MB 64b/line 12-way L3 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 2660.72 MHz, 06-25-05, patch 
0007
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,API

Re: Stopped at smu7_powergate_uvd+0x23

[Jonathan Gray]

On Tue, Mar 12, 2024 at 09:05:35PM +1300, Avon Robertson wrote:
> On Tue, Mar 12, 2024 at 03:40:03PM +1100, Jonathan Gray wrote:
> > On Sat, Mar 09, 2024 at 02:42:25PM +1300, Avon Robertson wrote:
> > > I apologise for making this thread so disjointed. I need to
> > > find a method to include long mails such as this to a previous
> > > short post.
> > > 
> > > The serial output from a boot of the kernel that includes 
> > > Jonathon's reverting diff is below.
> > 
> > This diff should avoid the deref you saw, but I fear it will just move
> > the problem to another function.
> > 
> > Index: sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_clockpowergating.c
> > ===
> > RCS file: 
> > /cvs/src/sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_clockpowergating.c,v
> > diff -u -p -r1.1 smu7_clockpowergating.c
> > --- sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_clockpowergating.c  7 Jul 
> > 2021 02:38:30 -   1.1
> > +++ sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_clockpowergating.c  12 Mar 
> > 2024 04:33:25 -
> > @@ -115,7 +115,8 @@ void smu7_powergate_uvd(struct pp_hwmgr 
> >  {
> > struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
> >  
> > -   data->uvd_power_gated = bgate;
> > +   if (data)
> > +   data->uvd_power_gated = bgate;
> >  
> > if (bgate) {
> > amdgpu_device_ip_set_powergating_state(hwmgr->adev,
> > 
> 
> To avoid future misunderstanding by me, before I apply the above
> diff and capture the boot output, please tell me:
> 
>   1. you have read my email post dated Mon Mar 11 16:14:47 2024;

A gpu init failure when firmware is not available is expected.

>   2. that the above diff is to be applied, OR not applied on top 
>  of the previous diff.

Either is fine.  The previous diff didn't help so you can revert it.

Re: Stopped at smu7_powergate_uvd+0x23

[Jonathan Gray]

On Sat, Mar 09, 2024 at 02:42:25PM +1300, Avon Robertson wrote:
> I apologise for making this thread so disjointed. I need to
> find a method to include long mails such as this to a previous
> short post.
> 
> The serial output from a boot of the kernel that includes 
> Jonathon's reverting diff is below.

This diff should avoid the deref you saw, but I fear it will just move
the problem to another function.

Index: sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_clockpowergating.c
===
RCS file: 
/cvs/src/sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_clockpowergating.c,v
diff -u -p -r1.1 smu7_clockpowergating.c
--- sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_clockpowergating.c  7 Jul 
2021 02:38:30 -   1.1
+++ sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_clockpowergating.c  12 Mar 
2024 04:33:25 -
@@ -115,7 +115,8 @@ void smu7_powergate_uvd(struct pp_hwmgr 
 {
struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
 
-   data->uvd_power_gated = bgate;
+   if (data)
+   data->uvd_power_gated = bgate;
 
if (bgate) {
amdgpu_device_ip_set_powergating_state(hwmgr->adev,

Re: Stopped at smu7_powergate_uvd+0x23

[Jonathan Gray]

On Fri, Mar 08, 2024 at 03:35:31PM +1300, Avon Robertson wrote:
> Theo
> 
> Alas your suggestion failed as show below.
> 
> >From a cold boot using:
> 
> *  using a USB keyboard the machine responds to:
> boot> boot -c
>   and then at
> UKC> there is no displayed response to any keypress and the machine
>  appears to have hung.
> 
>  Timed roughly with a wristwatch, >10 minutes later the display
>  still shows:
> L1   [using 4019840 bytes of bsd ELF symbol table ]
> ...
> L10  User Kernel Config
> L11  UKC>
> 
> *  using a PS2 keyboard the machine responds to:
> boot> boot -c
>   and then the keyboard and machine also respond to:
> UKC> disable amdgpu0
> UKC> quit

try "disable amdgpu"

it will then print "amdgpu* disabled"

Re: Stopped at smu7_powergate_uvd+0x23

[Jonathan Gray]

Thanks for the detailed report.

smu7_powergate_uvd+0x23
pp_set_powergating_by_smu+0x15a
amdgpu_dpm_enable_uvd+0xc1
taskq_thread

POLARIS10 has UVD 6.3

If driver init fails the task gets removed by:

cancel_delayed_work_sync(&adev->uvd.idle_work);

uvd_v6_0_hw_fini
amdgpu_device_ip_fini_early
amdgpu_device_fini_hw
amdgpu_driver_unload_kms
amdgpu_driver_load_kms
amdgpu_attachhook

but your trace must occur before that gets cleaned up

smu7_powergate_uvd+0x23 is
/sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_clockpowergating.c:118

   114  void smu7_powergate_uvd(struct pp_hwmgr *hwmgr, bool bgate)
   115  {
   116  struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr->backend);
   117  
   118  data->uvd_power_gated = bgate;

Try the following revert of
'drm/amd/pm/smu7: fix a memleak in smu7_hwmgr_backend_init'
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.6.y&id=ae7cbf935b9a1b41f65fe6443e7cd0c401500b20

The matching OpenBSD commit was rev 1.9
date: 2024/01/29 01:51:19;  author: jsg;  state: Exp;  lines: +5 -1;  commitid: 
cUHNbtd9MymExldJ;

Index: sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c,v
diff -u -p -r1.10 smu7_hwmgr.c
--- sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c 6 Feb 2024 03:55:02 
-   1.10
+++ sys/dev/pci/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c 7 Mar 2024 02:43:27 
-
@@ -2974,8 +2974,6 @@ static int smu7_hwmgr_backend_init(struc
result = smu7_get_evv_voltages(hwmgr);
if (result) {
pr_info("Get EVV Voltage Failed.  Abort Driver 
loading!\n");
-   kfree(hwmgr->backend);
-   hwmgr->backend = NULL;
return -EINVAL;
}
} else {
@@ -3021,10 +3019,8 @@ static int smu7_hwmgr_backend_init(struc
}
 
result = smu7_update_edc_leakage_table(hwmgr);
-   if (result) {
-   smu7_hwmgr_backend_fini(hwmgr);
+   if (result)
return result;
-   }
 
return 0;
 }

Re: fxp(4) crashes on ifconfig rdomain when up

[Jonathan Gray]

On Thu, Feb 22, 2024 at 04:32:06PM +0200, d...@strangeloop.cc wrote:
> Hi Guys!
> 
> I was experimenting and learning rdomains but got a kernel panic memory
> managent fault every time, a few seconds after issuing ifconfig(8):
> 
> # ifconfig fxp0 rdomain 1
> 
> fatal kernel trap:
> 
> trap entry = 0x2 (memory management fault)
> a0 = 0x90041
> ...
> 
> After some debugging it seems like an array overflow when fxp_init() calls
> fxp_add_rfabuf() which in turn uses FXP_RXMAP_GET(sc) that will cause a read
> read beyond the end of the array - panic guaranteed!
> 
> #defineFXP_RXMAP_GET(sc)   ((sc)->sc_rxmaps[(sc)->sc_rxfree++])
> 
> This crash does NOT seem to happen if you try this with the interface down!
> 
> I wonder if anybody with a better understanding of fxp(4) driver could
> work out why this happens?
> 
> At the moment I am using this ugly hack as to prevent the panics. I have
> not noticed any side-effects. My laptop is behind fxp0 on rdomain 1 and this
> machine routes traffic elsewhere on rtable 0.

perhaps unrelated but the command test is wrong

the command is in the lower 3 bits, with flags in higher bits
the nop command is 0 so cb_command & 0 is always false

Index: sys/dev/ic/fxp.c
===
RCS file: /cvs/src/sys/dev/ic/fxp.c,v
diff -u -p -r1.133 fxp.c
--- sys/dev/ic/fxp.c10 Nov 2023 15:51:20 -  1.133
+++ sys/dev/ic/fxp.c22 Feb 2024 23:32:05 -
@@ -814,7 +814,7 @@ fxp_intr(void *arg)
 
while ((txcnt > 0) &&
   ((txs->tx_cb->cb_status & htole16(FXP_CB_STATUS_C)) 
||
-  (txs->tx_cb->cb_command & 
htole16(FXP_CB_COMMAND_NOP {
+  ((txs->tx_cb->cb_command & htole16(7)) == 
htole16(FXP_CB_COMMAND_NOP {
if (txs->tx_mbuf != NULL) {
FXP_MBUF_SYNC(sc, txs->tx_map,
BUS_DMASYNC_POSTWRITE);

Re: External display doesn't work (start?) anymore

[Jonathan Gray]

On Wed, Feb 21, 2024 at 02:12:35PM +0100, Kirill A. Korinsky wrote:
> On Tue, 20 Feb 2024 09:11:35 +0100,
> Jonathan Gray wrote:
> > 
> > Thanks, committed.
> 
> And I found one more unexpected side effect.
> 
> When I connect monitor I need to reconnect it physically some times.
> 
> Seems that it in kind of sleep or hibernate mode, and when I connect
> laptop the first time, it start to boot, but never light up. If I
> recconect the laptop (plug and unplug USB-C), it light up.
> 
> Wired, but this behaviour happenes not always. Seems that it need couple
> of minutes (5-10, not sure) to be disconnected from everything to go
> into that deep sleep state.
> 
> Anz thoughts?

Try directly connect with DisplayPort or HDMI if you can.  USB Type-C
involves dealing with another microcontroller.

Re: External display doesn't work (start?) anymore

[Jonathan Gray]

On Mon, Feb 19, 2024 at 12:33:09PM +0100, Kirill A. Korinsky wrote:
> On Mon, 19 Feb 2024 12:23:46 +0100,
> Jonathan Gray wrote:
> > 
> > Can you revert that and see if only 1 of the 3 commits is enough?
> > 
> > Diff below includes only
> > "drm/i915/pxp/mtl: Update pxp-firmware response timeout"
> >
> 
> It works.

Thanks, committed.

Re: External display doesn't work (start?) anymore

[Jonathan Gray]

On Mon, Feb 19, 2024 at 12:11:28PM +0100, Kirill A. Korinsky wrote:
> Greetings,
> 
> > I'm curious if some of the newer commits in linux change what you see.
> > combined diff below
> 
> Just applied it as https://marc.info/?l=openbsd-bugs&m=170833357114116&q=raw 
> on
> local root 
> https://github.com/openbsd/src/commit/cfda45639a5cff5780a6f40814e7d74479c846c3
> 
> And it help.
> 
> Thanks, this is much cleaner than my durty patch.

Can you revert that and see if only 1 of the 3 commits is enough?

Diff below includes only
"drm/i915/pxp/mtl: Update pxp-firmware response timeout"

diff --git sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c 
sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
index 89ed5ee9cde..2fde5c360cf 100644
--- sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
+++ sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
@@ -81,8 +81,17 @@ out_rq:
 
i915_request_add(rq);
 
-   if (!err && i915_request_wait(rq, 0, msecs_to_jiffies(500)) < 0)
-   err = -ETIME;
+   if (!err) {
+   /*
+* Start timeout for i915_request_wait only after considering 
one possible
+* pending GSC-HECI submission cycle on the other 
(non-privileged) path.
+*/
+   if (wait_for(i915_request_started(rq), 
GSC_HECI_REPLY_LATENCY_MS))
+   drm_dbg(&gsc_uc_to_gt(gsc)->i915->drm,
+   "Delay in gsc-heci-priv submission to 
gsccs-hw");
+   if (i915_request_wait(rq, 0, 
msecs_to_jiffies(GSC_HECI_REPLY_LATENCY_MS)) < 0)
+   err = -ETIME;
+   }
 
i915_request_put(rq);
 
@@ -186,6 +195,13 @@ out_rq:
i915_request_add(rq);
 
if (!err) {
+   /*
+* Start timeout for i915_request_wait only after considering 
one possible
+* pending GSC-HECI submission cycle on the other (privileged) 
path.
+*/
+   if (wait_for(i915_request_started(rq), 
GSC_HECI_REPLY_LATENCY_MS))
+   drm_dbg(&gsc_uc_to_gt(gsc)->i915->drm,
+   "Delay in gsc-heci-non-priv submission to 
gsccs-hw");
if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
  msecs_to_jiffies(timeout_ms)) < 0)
err = -ETIME;
diff --git sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h 
sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
index 09d3fbdad05..c4308291c00 100644
--- sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
+++ sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
@@ -12,6 +12,12 @@ struct i915_vma;
 struct intel_context;
 struct intel_gsc_uc;
 
+#define GSC_HECI_REPLY_LATENCY_MS 500
+/*
+ * Max FW response time is 500ms, but this should be counted from the time the
+ * command has hit the GSC-CS hardware, not the preceding handoff to GuC CTB.
+ */
+
 struct intel_gsc_mtl_header {
u32 validity_marker;
 #define GSC_HECI_VALIDITY_MARKER 0xA578875A
diff --git sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.c 
sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.c
index 86f58a5bddd..cc81a462492 100644
--- sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.c
+++ sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.c
@@ -111,7 +111,7 @@ gsccs_send_message(struct intel_pxp *pxp,
 
ret = intel_gsc_uc_heci_cmd_submit_nonpriv(>->uc.gsc,
   exec_res->ce, &pkt, 
exec_res->bb_vaddr,
-  GSC_REPLY_LATENCY_MS);
+  GSC_HECI_REPLY_LATENCY_MS);
if (ret) {
drm_err(&i915->drm, "failed to send gsc PXP msg (%d)\n", ret);
goto unlock;
diff --git sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.h 
sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.h
index 298ad38e6c7..9aae779c4da 100644
--- sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.h
+++ sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.h
@@ -8,16 +8,14 @@
 
 #include 
 
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
+
 struct intel_pxp;
 
-#define GSC_REPLY_LATENCY_MS 210
-/*
- * Max FW response time is 200ms, to which we add 10ms to account for overhead
- * such as request preparation, GuC submission to hw and pipeline completion 
times.
- */
 #define GSC_PENDING_RETRY_MAXCOUNT 40
 #define GSC_PENDING_RETRY_PAUSE_MS 50
-#define GSCFW_MAX_ROUND_TRIP_LATENCY_MS (GSC_PENDING_RETRY_MAXCOUNT * 
GSC_PENDING_RETRY_PAUSE_MS)
+#define GSCFW_MAX_ROUND_TRIP_LATENCY_MS (GSC_HECI_REPLY_LATENCY_MS + \
+(GSC_PENDING_RETRY_MAXCOUNT * 
GSC_PENDING_RETRY_PAUSE_MS))
 
 #ifdef CONFIG_DRM_I915_PXP
 void intel_pxp_gsccs_fini(struct intel_pxp *pxp);

Re: External display doesn't work (start?) anymore

[Jonathan Gray]

On Sun, Feb 18, 2024 at 09:01:13PM +0100, Kirill A. Korinsky wrote:
> Greetings,
> 
> Here an ugly patch which recovers support of LG UltraFine 5K which was broken
> since update drm to linux 6.6.12.
> 
> This Display is quite delicate if not to say unstable, and it won't start with
> timeout other whan 250ms.
> 
> A function intel_pxp_get_backend_timeout_ms returns two possible value: 250 or
> GSCFW_MAX_ROUND_TRIP_LATENCY_MS which is defined at the end as 40 * 50.
> 
> Before an update, this code has only 250 as timeout and it works.
> 
> Possible that intel_pxp_init doesn't initialize pxp->ctrl_gt the same way like
> linux, or such regression exists on linux as well.

I'm curious if some of the newer commits in linux change what you see.
combined diff below

commit 698e19da2914a0021a088b2b5d101d1854862315
Author: Zhanjun Dong 
Date:   Mon Nov 13 14:49:53 2023 -0800

drm/i915: Skip pxp init if gt is wedged

commit fb99e79ee62aaa07d9e77cb3a15c5f1ae2790e6a
Author: Alan Previn 
Date:   Wed Oct 11 14:01:57 2023 +0300

mei: update mei-pxp's component interface with timeouts

commit 8ae272348153ed2fa423f739047a592d9bd55ba2
Author: Alan Previn 
Date:   Sun Sep 17 14:19:31 2023 -0700

drm/i915/pxp/mtl: Update pxp-firmware response timeout

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=698e19da2914a0021a088b2b5d101d1854862315
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fb99e79ee62aaa07d9e77cb3a15c5f1ae2790e6a
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8ae272348153ed2fa423f739047a592d9bd55ba2

diff --git sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c 
sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
index 89ed5ee9cde..2fde5c360cf 100644
--- sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
+++ sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
@@ -81,8 +81,17 @@ out_rq:
 
i915_request_add(rq);
 
-   if (!err && i915_request_wait(rq, 0, msecs_to_jiffies(500)) < 0)
-   err = -ETIME;
+   if (!err) {
+   /*
+* Start timeout for i915_request_wait only after considering 
one possible
+* pending GSC-HECI submission cycle on the other 
(non-privileged) path.
+*/
+   if (wait_for(i915_request_started(rq), 
GSC_HECI_REPLY_LATENCY_MS))
+   drm_dbg(&gsc_uc_to_gt(gsc)->i915->drm,
+   "Delay in gsc-heci-priv submission to 
gsccs-hw");
+   if (i915_request_wait(rq, 0, 
msecs_to_jiffies(GSC_HECI_REPLY_LATENCY_MS)) < 0)
+   err = -ETIME;
+   }
 
i915_request_put(rq);
 
@@ -186,6 +195,13 @@ out_rq:
i915_request_add(rq);
 
if (!err) {
+   /*
+* Start timeout for i915_request_wait only after considering 
one possible
+* pending GSC-HECI submission cycle on the other (privileged) 
path.
+*/
+   if (wait_for(i915_request_started(rq), 
GSC_HECI_REPLY_LATENCY_MS))
+   drm_dbg(&gsc_uc_to_gt(gsc)->i915->drm,
+   "Delay in gsc-heci-non-priv submission to 
gsccs-hw");
if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
  msecs_to_jiffies(timeout_ms)) < 0)
err = -ETIME;
diff --git sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h 
sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
index 09d3fbdad05..c4308291c00 100644
--- sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
+++ sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
@@ -12,6 +12,12 @@ struct i915_vma;
 struct intel_context;
 struct intel_gsc_uc;
 
+#define GSC_HECI_REPLY_LATENCY_MS 500
+/*
+ * Max FW response time is 500ms, but this should be counted from the time the
+ * command has hit the GSC-CS hardware, not the preceding handoff to GuC CTB.
+ */
+
 struct intel_gsc_mtl_header {
u32 validity_marker;
 #define GSC_HECI_VALIDITY_MARKER 0xA578875A
diff --git sys/dev/pci/drm/i915/i915_driver.c sys/dev/pci/drm/i915/i915_driver.c
index 059fdca5d58..b5870fe9b26 100644
--- sys/dev/pci/drm/i915/i915_driver.c
+++ sys/dev/pci/drm/i915/i915_driver.c
@@ -810,7 +810,9 @@ int i915_driver_probe(struct drm_i915_private *i915, const 
struct pci_device_id
if (ret)
goto out_cleanup_modeset2;
 
-   intel_pxp_init(i915);
+   ret = intel_pxp_init(i915);
+   if (ret != -ENODEV)
+   drm_dbg(&i915->drm, "pxp init failed with %d\n", ret);
 
ret = intel_display_driver_probe(i915);
if (ret)
diff --git sys/dev/pci/drm/i915/pxp/intel_pxp.c 
sys/dev/pci/drm/i915/pxp/intel_pxp.c
index e079f5b6ee6..41ac603e1a7 100644
--- sys/dev/pci/drm/i915/pxp/intel_pxp.c
+++ sys/dev/pci/drm/i915/pxp/intel_pxp.c
@@ -199,6 +199,9 @@ int intel_pxp_init(struct drm_i915_private *i915)

Re: Trouble with console on UART

[Jonathan Gray]

On Sun, Jan 28, 2024 at 10:46:43AM +0900, Tranchemer Stéphane wrote:
> Thanks so much for this very clear explanation, I didn’t know that one.
> 
> I have a question regarding the patch I successfully applied on the kernel, 
> could such modification be accepted as a syspatch in the actual 7.4 release 
> or should it be expected in CURRENT and planned for the next to come 7.5 
> release?

I have committed it to -current, so it will be in 7.5.  Hardware support
changes don't normally get backported to stable branches.

> 
> Also Mark, I honestly would have never found myself the "mach comaddr 0xe060" 
> option to set at boot, is it something that there’s no other way than set it 
> yourself or could it be part of a patch to set up automatically?

the line can be placed in /etc/boot.conf

commands are described in boot(8)

> 
> Thank you all.
> 
> > 
> > Le 2024/01/28 à 03:46, Stuart Henderson  a écrit :
> > 
> > On 2024/01/28 00:20, stephane Tranchemer wrote:
> >> Got it !
> >> I had a hunch so I modified all the tty0X the same way as tty00 to see if
> >> someone answers:
> >> tty00   "/usr/libexec/getty std.115200" vt220on secure
> >> and I got a tty at next reboot.
> >> However I find myself on tty04, so it would mean that com4 goes invariably 
> >> to tty04 even if this port is the only com port I do have on my system as 
> >> show by dmesg?
> >> I would have expected to have it on tty00.
> > 
> > on amd64/i386, 00 to 03 are reserved for serial ports at specific known
> > addresses (0x3f8, 0x3e8, 0x2f8, 0x2e8). dynamically attached ports have
> > higher numbers.
> 

Re: Trouble with console on UART

[Jonathan Gray]

On Sat, Jan 27, 2024 at 07:54:43PM +0900, stran...@free.fr wrote:
> >Synopsis:Console is lost at boot when com0 is on a UART PCI  
> >Category:system amd64
> >Environment:
>   System  : OpenBSD 7.4
>   Details : OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec  8 15:39:04 MST 2023
>
> r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> Looking for a replacement for Soekris or PCengines machines, I chose a Qotom 
> mini-pc featured in a Servethehome video.
> 
> I chose the 8GB RAM 256GB SSD, Q20321G9 C3558R model
> 
> My intent is to use it as a OpenBSD router, so once I get it I started to 
> play with it.
> 
> Making a USB boot key from install74.img with Etcher (on a windows 
> workstation, sue me) I booted without problem after setting up the boot order 
> in the Bios/UEFI.Interestingly it comes with a preinstalled Windows install 
> without activation number on the SSD, well I just flushed it all.
> 
> The 2.5G and 10 SFP+ interfaces are seen as igc and ix interfaces, great.
> 
> Now there is the problem I stumbled into, it is the console port.
> 
> first, it is not enabled by default, you have to go into the Bios/UEFI to 
> enable it (meaning connecting a USB keyboard and a VGA monitor) and it 
> presents as such in the menus with a toggle to Enable/Disable:
> COM0(Pci Bus0,Dev26,Func0) 
> and also some nice options to change like the type of console or speed.
> 
> Doing so you get your display redirected on the console, fantastic.
> 
> However when you boot your OpenBSD you get this on the console:
> Using drive 0, partition 3.
> Loading..probing: pc0 mem[620K 993M 928M 91M 852K 3M 6144M a20=on]
> disk: hd0+
> >> OpenBSD/amd64 BOOT 3.65
> boot>booting hd0a:/bsd: 17241420+4137992+368672+0+1241088 
> [1340879+128+1321080+101331
> 
> And nothing more, your main display is on the VGA monitor, expected since the 
> redirecting of the tty on the console is not done.
> 
> In all logic I then tried to boot OpenBSD with 
> set tty com0
> But when doing this here is what you get:
> boot> set tty com0
> switching console to com0
> 
> And that's it... no more access to your keyboard and the console is lost.
> 
> Booting the OS completely here's what we can see on dmesg
> "Intel C3000 UART" rev 0x11 at pci0 dev 26 function 0 not configured
> 
> So it seems that from the moment you try telling to use the com0 port you 
> loose all access... this UART thing is not properly recognized.
> 
> For comparison on a PCengine machine:
> com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
> com0: console
> com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
> The com port there is ISA bus
> 
> Is there something I'm missing to catch the console or enable it in OpenBSD, 
> or is it a non-supported trouble.

pci serial is normally handled by puc(4), try this:

Index: sys/dev/pci/pucdata.c
===
RCS file: /cvs/src/sys/dev/pci/pucdata.c,v
diff -u -p -r1.118 pucdata.c
--- sys/dev/pci/pucdata.c   24 Oct 2022 05:57:58 -  1.118
+++ sys/dev/pci/pucdata.c   27 Jan 2024 11:46:33 -
@@ -306,6 +306,13 @@ const struct puc_device_description puc_
{ PUC_PORT_COM, 0x10, 0x },
},
},
+   {   /* Intel C3000 UART */
+   {   PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_C3000_HSUART, 0x, 
0x },
+   {   0x, 0x, 0x, 0x 
},
+   {
+   { PUC_PORT_COM, 0x10, 0x },
+   },
+   },
/*
 * XXX no entry because I have no data:
 * XXX Dolphin Peripherals 4006 (single parallel)

Re: Unable to boot -current without disabling amdgpu

[Jonathan Gray]

On Wed, Jan 24, 2024 at 12:54:10PM -0500, Josh Rickmar wrote:
> I may have stumbled upon a fix by accident.  Enabling resizable BAR in
> my UEFI settings seems to stop the crash.

I unsuccessfully tried to reproduce the problem by disabling CSM and
doing a new UEFI/GPT install on:

bios0: vendor American Megatrends Inc. version "P3.20" date 04/09/2019
bios0: ASRock X470 Gaming K4
..
cpu0: AMD Ryzen 5 2600X Six-Core Processor, 3600.00 MHz, 17-08-02, patch 
0800820b
..
amdgpu0: VEGA10 GC 9.0.1 56 CU rev 0x01

The card has the resizable BAR capability, but there are no system bios
options for it.  Resizable BAR seems to require >= Ryzen 3000 (Zen 2).

 33:0:0: ATI Radeon Rx Vega
0x: Vendor ID: 1002, Product ID: 687f
0x0004: Command: 0006, Status: 0010
0x0008: Class: 03 Display, Subclass: 00 VGA,
Interface: 00, Revision: c3
0x000c: BIST: 00, Header Type: 80, Latency Timer: 00,
Cache Line Size: 10
0x0010: BAR mem prefetchable 64bit addr: 0xe000/0x1000
0x0018: BAR mem prefetchable 64bit addr: 0xf000/0x0020
0x0020: BAR io addr: 0xe000/0x0100
0x0024: BAR mem 32bit addr: 0xfcb0/0x0008
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 1458 Product ID: 230c
0x0030: Expansion ROM Base Address: fcb8
0x0038: 
0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00
0x0048: Capability 0x09: Vendor Specific
0x0050: Capability 0x01: Power Management
State: D0
0x0064: Capability 0x10: PCI Express
Max Payload Size: 256 / 256 bytes
Max Read Request Size: 512 bytes
Link Speed: 8.0 / 8.0 GT/s
Link Width: x16 / x16
0x0100: Enhanced Capability 0x0b: Vendor-Specific
0x0150: Enhanced Capability 0x01: Advanced Error Reporting
0x0200: Enhanced Capability 0x15: Resizable BAR
0x0270: Enhanced Capability 0x19: Secondary PCIe Capability
0x02a0: Enhanced Capability 0x0d: Access Control Services
0x02b0: Enhanced Capability 0x0f: Address Translation Services
0x02c0: Enhanced Capability 0x13: Page Request Interface
0x02d0: Enhanced Capability 0x1b: Process Address Space ID
0x0320: Enhanced Capability 0x18: Latency Tolerance Reporting
0x00a0: Capability 0x05: Message Signalled Interrupts (MSI)
Enabled: yes

Re: Unable to boot -current without disabling amdgpu

[Jonathan Gray]

On Tue, Jan 23, 2024 at 10:55:26AM -0500, Josh Rickmar wrote:
> Latest -current is unhappy with my amd64 desktop.  I'm assuming this
> is due to the recent drm sync to newer Linux.  My GPU is a RX Vega 64.

An earlier snapshot worked?

> 
> It seems to kernel panic but I can't confirm this, the screen is black
> and it doesn't bring up networking/respond to pings.
> 
> I see the following errors in the dmesg buffer before the most recent
> boot:
> 
> amdgpu0: VEGA10 GC 9.0.1 64 CU rev 0x01
> [drm] *ERROR* IB test failed on gfx_low (-60).
> [drm] *ERROR* IB test failed on gfx_high (-60).
> [drm] *ERROR* IB test failed on comp_1.0.0 (-60).
> [drm] *ERROR* IB test failed on comp_1.1.0 (-60).
> [drm] *ERROR* IB test failed on comp_1.2.0 (-60).
> [drm] *ERROR* IB test failed on comp_1.3.0 (-60).
> [drm] *ERROR* IB test failed on comp_1.0.1 (-60).
> [drm] *ERROR* IB test failed on comp_1.1.1 (-60).
> [drm] *ERROR* IB test failed on comp_1.2.1 (-60).

Does the following change this?

The framebuffer offset/size can cause tests to fail.

Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c,v
diff -u -p -r1.11 amdgpu_gmc.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c 16 Jan 2024 23:37:52 -  
1.11
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c 24 Jan 2024 10:07:49 -
@@ -738,15 +738,6 @@ void amdgpu_gmc_get_vbios_allocations(st
} else {
size = amdgpu_gmc_get_vbios_fb_size(adev);
 
-#ifdef __amd64__
-   /*
-* XXX Workaround for machines where the framebuffer
-* size reported by the hardware is incorrect.
-*/
-   extern psize_t efifb_stolen();
-   size = max(size, efifb_stolen());
-#endif
-
if (adev->mman.keep_stolen_vga_memory)
size = max(size, (unsigned)AMDGPU_VBIOS_VGA_ALLOCATION);
}

Re: crash in r600_dri.so

[Jonathan Gray]

On Tue, Nov 21, 2023 at 11:57:40PM +1100, Jonathan Gray wrote:
> On Tue, Nov 21, 2023 at 08:19:11PM +1100, Jonathan Gray wrote:
> > On Mon, Nov 20, 2023 at 09:19:45PM +, Edd Barrett wrote:
> > > Hi Jonathan,
> > > 
> > > On Mon, Nov 20, 2023 at 07:16:14PM +1100, Jonathan Gray wrote:
> > > > When it last worked, were you running Mesa 23.1 (snapshots since early
> > > > November)?  Did this start with LLVM 16 (last few days)?
> > > 
> > > Looking back in my messages.0.gz, it seems I hadn't updated in a while.
> > > 
> > > The last working snapshot I had installed was:
> > > OpenBSD 7.4-current (GENERIC.MP) #1403: Thu Oct 12 19:56:46 MDT 2023
> > > 
> > > Unfortunatley I don't know what Mesa I had at the time.
> > 
> > That would have been Mesa 22.3.7
> > 
> > With Mesa 22.3.7 on -current I can't reproduce the crash.
> 
> works with 23.1.9 after reverting
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/244cc152d1b20592120ce1d5dd9627509b73d0b9

I committed a fix for this.  From Gert Wollny upstream:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26420

Index: src/gallium/drivers/r600/sfn/sfn_optimizer.cpp
===
RCS file: 
/cvs/xenocara/lib/mesa/src/gallium/drivers/r600/sfn/sfn_optimizer.cpp,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 sfn_optimizer.cpp
--- src/gallium/drivers/r600/sfn/sfn_optimizer.cpp  2 Nov 2023 04:32:35 
-   1.1.1.2
+++ src/gallium/drivers/r600/sfn/sfn_optimizer.cpp  1 Dec 2023 07:42:19 
-
@@ -373,7 +373,11 @@ CopyPropFwdVisitor::visit(AluInstr *inst
auto ii = dest->uses().begin();
auto ie = dest->uses().end();
 
-   while(ii != ie) {
+   /** libc++ seems to invalidate the end iterator too if a std::set is
+*  made empty by an erase operation,
+*  https://gitlab.freedesktop.org/mesa/mesa/-/issues/7931
+*/
+   while(ii != ie && !dest->uses().empty()) {
   auto i = *ii;
   ++ii;
   /* SSA can always be propagated, registers only in the same block

Re: Xorg crashing after waking monitor from standby

[Jonathan Gray]

On Sat, Nov 25, 2023 at 11:40:37AM +1100, Jonathan Gray wrote:
> On Thu, Nov 23, 2023 at 11:04:17PM +, Laurence Tratt wrote:
> >   OpenBSD 7.4-current (GENERIC.MP) #1461: Mon Nov 20 19:55:51 MST 2023
> >   dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >   real mem = 68431814656 (65261MB)
> >   avail mem = 66338226176 (63265MB)
> >   random: good seed from bootblocks
> >   mpath0 at root
> >   scsibus0 at mpath0: 256 targets
> >   mainbus0 at root
> >   bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x75a58000 (104 entries)
> >   bios0: vendor American Megatrends Inc. version "1501" date 10/05/2023
> >   bios0: ASUS ROG STRIX Z790-H GAMING WIFI
> >   efi0 at bios0: UEFI 2.8
> >   efi0: American Megatrends rev 0x5001b
> >   acpi0 at bios0: ACPI 6.4
> >   acpi0: sleep states S0 S3 S4 S5
> >   acpi0: tables DSDT FACP FIDT SSDT SSDT SSDT SSDT HPET APIC MCFG SSDT NHLT 
> > LPIT SSDT SSDT DBGP DBG2 SSDT DMAR FPDT SSDT SSDT SSDT BGRT WPBT TPM2 PHAT 
> > WSMT
> >   acpi0: wakeup devices PEG1(S4) PEGP(S4) PEGP(S4) PEG0(S4) PEGP(S4) 
> > RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) 
> > RP13(S4) PXSX(S4) RP14(S4) [...]
> >   acpitimer0 at acpi0: 3579545 Hz, 24 bits
> >   acpihpet0 at acpi0: 1920 Hz
> >   acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> >   cpu0 at mainbus0: apid 0 (boot processor)
> >   cpu0: 13th Gen Intel(R) Core(TM) i9-13900K, 5502.28 MHz, 06-b7-01, patch 
> > 011d
> >   cpu0: 
> > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,TAA_NO,MISC_PKG_CT,ENERGY_FILT,DOITM,SBDR_SSDP_N,FBSDP_NO,PSDP_NO,RRSBA,OVERCLOCK,GDS_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> >   cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 
> > 64b/line 16-way L2 cache, 36MB 64b/line 12-way L3 cache
> >   cpu0: smt 0, core 0, package 0
> >   mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> >   cpu0: apic clock running at 38MHz
> >   cpu0: mwait min=64, max=64, C-substates=0.2.0.1.0.1.0.1, IBE
> ...
> >   "INTC1085" at acpi0 not configured
> 
> This is an acpi gpio device.
> 
> In some cases interrupts and acpi events may not work if not configured.

kettenis@ noticed the gpi offsets for Alder Lake-S were wrong
updated diff:

Index: sys/dev/acpi/pchgpio.c
===
RCS file: /cvs/src/sys/dev/acpi/pchgpio.c,v
diff -u -p -r1.14 pchgpio.c
--- sys/dev/acpi/pchgpio.c  20 Oct 2022 20:40:57 -  1.14
+++ sys/dev/acpi/pchgpio.c  25 Nov 2023 12:18:52 -
@@ -115,6 +115,9 @@ const char *pchgpio_hids[] = {
"INT34C5",
"INT34C6",
"INTC1055",
+   "INTC1056",
+   "INTC1057",
+   "INTC1085",
NULL
 };
 
@@ -311,6 +314,78 @@ const struct pchgpio_device tgl_h_device
.npins = 480,
 };
 
+/* Alder Lake-S */
+
+const struct pchgpio_group adl_s_groups[] =
+{
+   /* Community 0 */
+   { 0, 0, 0, 24, 0 }, /* GPP_I */
+   { 0, 1, 25, 47, 32 },   /* GPP_R */
+   { 0, 2, 48, 59, 64 },   /* GPP_J */
+
+   /* Community 1 */
+   { 1, 0, 95, 118, 160 }, /* GPP_B */
+   { 1, 1, 119, 126, 192 },/* GPP_G */
+   { 1, 2, 127, 150, 224 },/* GPP_H */
+
+   /* Community 3 */
+   { 2, 1, 160, 175, 256 },/* GPP_A */
+   { 2, 2, 176, 199, 288 },/* GPP_C */
+
+   /* Community 4 */
+   { 3, 0, 200, 207, 320 },/* GPP_S */
+   { 3, 1, 208, 230, 352 },/* GPP_E */
+   { 3, 2, 231, 245, 384 },/* GPP_K */
+   { 3, 3, 246, 269, 416 },/* GPP_F */
+
+   /* Community 5 */
+   { 4, 0, 270, 294, 448 },/* GPP_D */
+};
+
+const struct pchgpio_device adl_s_device =
+{
+   .pad_size = 16,
+   .gpi_is = 0x200,
+   .gpi_ie = 0x220,
+   .groups = adl_s_groups,
+   .ngroups = nitems(adl_s_groups),
+   .npins = 480,
+};
+
+/* Alder Lake-N */
+
+const struct pchgpio_group adl_n_groups[] =
+{
+   /* Community 0 */
+   { 0, 0, 0, 25, 0 }, /* GPP_B */
+   { 0, 1, 26, 41, 32 },   /* GPP_T */
+   { 0, 2, 42, 66, 64 },   /* GPP_A */
+
+   /* Community 1 */
+  

Re: Xorg crashing after waking monitor from standby

[Jonathan Gray]

On Thu, Nov 23, 2023 at 11:04:17PM +, Laurence Tratt wrote:
>   OpenBSD 7.4-current (GENERIC.MP) #1461: Mon Nov 20 19:55:51 MST 2023
>   dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>   real mem = 68431814656 (65261MB)
>   avail mem = 66338226176 (63265MB)
>   random: good seed from bootblocks
>   mpath0 at root
>   scsibus0 at mpath0: 256 targets
>   mainbus0 at root
>   bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x75a58000 (104 entries)
>   bios0: vendor American Megatrends Inc. version "1501" date 10/05/2023
>   bios0: ASUS ROG STRIX Z790-H GAMING WIFI
>   efi0 at bios0: UEFI 2.8
>   efi0: American Megatrends rev 0x5001b
>   acpi0 at bios0: ACPI 6.4
>   acpi0: sleep states S0 S3 S4 S5
>   acpi0: tables DSDT FACP FIDT SSDT SSDT SSDT SSDT HPET APIC MCFG SSDT NHLT 
> LPIT SSDT SSDT DBGP DBG2 SSDT DMAR FPDT SSDT SSDT SSDT BGRT WPBT TPM2 PHAT 
> WSMT
>   acpi0: wakeup devices PEG1(S4) PEGP(S4) PEGP(S4) PEG0(S4) PEGP(S4) RP09(S4) 
> PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) 
> PXSX(S4) RP14(S4) [...]
>   acpitimer0 at acpi0: 3579545 Hz, 24 bits
>   acpihpet0 at acpi0: 1920 Hz
>   acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>   cpu0 at mainbus0: apid 0 (boot processor)
>   cpu0: 13th Gen Intel(R) Core(TM) i9-13900K, 5502.28 MHz, 06-b7-01, patch 
> 011d
>   cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,TAA_NO,MISC_PKG_CT,ENERGY_FILT,DOITM,SBDR_SSDP_N,FBSDP_NO,PSDP_NO,RRSBA,OVERCLOCK,GDS_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
>   cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 
> 64b/line 16-way L2 cache, 36MB 64b/line 12-way L3 cache
>   cpu0: smt 0, core 0, package 0
>   mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
>   cpu0: apic clock running at 38MHz
>   cpu0: mwait min=64, max=64, C-substates=0.2.0.1.0.1.0.1, IBE
...
>   "INTC1085" at acpi0 not configured

This is an acpi gpio device.

In some cases interrupts and acpi events may not work if not configured.

Index: sys/dev/acpi/pchgpio.c
===
RCS file: /cvs/src/sys/dev/acpi/pchgpio.c,v
diff -u -p -r1.14 pchgpio.c
--- sys/dev/acpi/pchgpio.c  20 Oct 2022 20:40:57 -  1.14
+++ sys/dev/acpi/pchgpio.c  25 Nov 2023 00:19:14 -
@@ -115,6 +115,9 @@ const char *pchgpio_hids[] = {
"INT34C5",
"INT34C6",
"INTC1055",
+   "INTC1056",
+   "INTC1057",
+   "INTC1085",
NULL
 };
 
@@ -311,6 +314,78 @@ const struct pchgpio_device tgl_h_device
.npins = 480,
 };
 
+/* Alder Lake-S */
+
+const struct pchgpio_group adl_s_groups[] =
+{
+   /* Community 0 */
+   { 0, 0, 0, 24, 0 }, /* GPP_I */
+   { 0, 1, 25, 47, 32 },   /* GPP_R */
+   { 0, 2, 48, 59, 64 },   /* GPP_J */
+
+   /* Community 1 */
+   { 1, 0, 95, 118, 160 }, /* GPP_B */
+   { 1, 1, 119, 126, 192 },/* GPP_G */
+   { 1, 2, 127, 150, 224 },/* GPP_H */
+
+   /* Community 3 */
+   { 2, 1, 160, 175, 256 },/* GPP_A */
+   { 2, 2, 176, 199, 288 },/* GPP_C */
+
+   /* Community 4 */
+   { 3, 0, 200, 207, 320 },/* GPP_S */
+   { 3, 1, 208, 230, 352 },/* GPP_E */
+   { 3, 2, 231, 245, 384 },/* GPP_K */
+   { 3, 3, 246, 269, 416 },/* GPP_F */
+
+   /* Community 5 */
+   { 4, 0, 270, 294, 448 },/* GPP_D */
+};
+
+const struct pchgpio_device adl_s_device =
+{
+   .pad_size = 16,
+   .gpi_is = 0x100,
+   .gpi_ie = 0x120,
+   .groups = adl_s_groups,
+   .ngroups = nitems(adl_s_groups),
+   .npins = 480,
+};
+
+/* Alder Lake-N */
+
+const struct pchgpio_group adl_n_groups[] =
+{
+   /* Community 0 */
+   { 0, 0, 0, 25, 0 }, /* GPP_B */
+   { 0, 1, 26, 41, 32 },   /* GPP_T */
+   { 0, 2, 42, 66, 64 },   /* GPP_A */
+
+   /* Community 1 */
+   { 1, 0, 67, 74, 96 },   /* GPP_S */
+   { 1, 1, 75, 94, 128 },  /* GPP_I */
+   { 1, 2, 95, 118, 160 }, /* GPP_H */
+   { 1, 3, 119, 139, 192 },/* GPP_D */
+
+   /* Community 4 */
+   { 2, 0, 169, 192, 256 },/* GPP_C */
+   { 2, 1, 193, 217, 288 },/* GPP_F */
+   { 2, 3, 224, 248, 320 },/* GPP_E */
+
+   /* Community 5 */
+   { 3, 0, 249, 256, 352 },/* GPP_R */
+};
+
+const struct pchgpio_device adl_n_device =
+{
+   .pad_size = 16,
+

Re: Xorg crashing after waking monitor from standby

[Jonathan Gray]

On Thu, Nov 23, 2023 at 11:04:17PM +, Laurence Tratt wrote:
> Perhaps 5-8 times in the past few weeks I've experienced X crashing.
> Interestingly, each time it's happened has been while the monitor has
> been in standby. Things seem to be fine until I wake the screen up by
> pressing a key. Almost immediately Xorg crashes, and drops me back to
> the console; perhaps 10 seconds later Xorg restarts and automatically
> puts me back into xenodm. Here's the salient part of the most recent
> Xorg.0.log.old output:
> 
>   [123208.185] (EE) Segmentation fault at address 0xe9d67855000
>   [123208.185] (EE) 
>   Fatal server error:
>   [123208.185] (EE) Caught signal 11 (Segmentation fault). Server aborting
>   [123208.185] (EE) 
>   [123208.185] (EE) 
>   Please consult the The X.Org Foundation support 
>at http://wiki.x.org
>for help. 
>   [123208.185] (EE) Please also check the log file at "/var/log/Xorg.0.log" 
> for additional information.
>   [123208.185] (EE) 
>   [123208.186] (EE) ws: /dev/wsmouse: unknown command 4
>   [123208.186] (II) AIGLX: Suspending AIGLX clients for VT switch
>   [123208.200] (EE) Server terminated with error (1). Closing log file.

see 'How to get a core file out of the X server?'
in /usr/xenocara/README
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/xenocara/README?rev=HEAD&content-type=text/plain

after that it should be possible to get a backtrace

Re: AX211 wifi firmware load issue

[Jonathan Gray]

On Thu, Nov 23, 2023 at 11:20:27AM +, Stuart Henderson wrote:
> On 2023/11/22 19:37, Gireesh wrote:
> > blinkopenbsd$ dmesg | grep iwx0
> > iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX211" rev 0x00, msix
> > iwx0: could not load firmware, 35
> > iwx0: failed to load init firmware
> > 
> > pcidump -v
> > 
> > 0:20:3: Intel Wi-Fi 6 AX211
> [..snip..]
> > 0x0164: Enhanced Capability 0x0b: Vendor-Specific
> > 0x0080: Capability 0x11: Extended Message Signalled Interrupts (MSI-X)
> > Enabled: yes; table size 16 (BAR 0:8192)
> > 
> > Computer in question
> > 
> > https://www.amazon.com/Beelink-Desktop-Computer-Support-Ethernet/dp/B0BVLS7ZHP
> 
> You really should include all the information when reporting a problem
> rather than just the bits which you think might be useful.
> 
> As luck would have it, I have one of those machines. Here's a real dmesg
> and full pcidump/acpidump as generated by sendbug -P.

Diff to add and match on some of those.  Based on tables in:

Intel Processor and Intel Core i3 N-Series
Datasheet, Volume 1 of 2, Doc. No.: 759603, Rev.: 001

Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
diff -u -p -r1.2054 pcidevs
--- sys/dev/pci/pcidevs 23 Nov 2023 05:08:56 -  1.2054
+++ sys/dev/pci/pcidevs 23 Nov 2023 12:38:17 -
@@ -5602,8 +5602,11 @@ product INTEL ADL_U9_HB_20x460a  Core 12
 product INTEL ADL_S_PCIE_1 0x460d  Core 12G PCIE
 product INTEL ADL_XDCI 0x460e  Core 12G xDCI
 product INTEL ADL_S_HB_6   0x4610  Core 12G Host
+product INTEL ADL_N_HB_1   0x4617  ADL-N Host
 product INTEL ADL_U15_HB_2 0x4619  Core 12G Host
 product INTEL ADL_U9_HB_3  0x461a  Core 12G Host
+product INTEL ADL_N_HB_2   0x461b  N200 Host
+product INTEL ADL_N_HB_3   0x461c  N100 Host
 product INTEL ADL_S_DTT0x461d  Core 12G DTT
 product INTEL ADL_XHCI 0x461e  Core 12G xHCI
 product INTEL ADL_TBT_PCIE30x461f  Core 12G PCIE
@@ -5896,7 +5899,48 @@ product INTEL 600SERIES_LP_ISH   0x51fc  60
 product INTEL 600SERIES_LP_UFS 0x51ff  600 Series UFS
 product INTEL 80960RD  0x5200  i960 RD
 product INTEL PRO_100_SERVER   0x5201  PRO 100 Server
+product INTEL ADL_N_ESPI   0x5481  ADL-N eSPI
+product INTEL ADL_N_P2SB   0x54a0  ADL-N P2SB
+product INTEL ADL_N_PMC0x54a1  ADL-N PMC
+product INTEL ADL_N_SMB0x54a3  ADL-N SMBus
+product INTEL ADL_N_SPI0x54a4  ADL-N SPI
+product INTEL ADL_N_TH 0x54a6  ADL-N TH
+product INTEL ADL_N_UART_0 0x54a8  ADL-N UART
+product INTEL ADL_N_UART_1 0x54a9  ADL-N UART
+product INTEL ADL_N_GSPI_0 0x54aa  ADL-N GSPI
+product INTEL ADL_N_GSPI_1 0x54ab  ADL-N GSPI
+product INTEL ADL_N_PCIE_9 0x54b0  ADL-N PCIE
+product INTEL ADL_N_PCIE_100x54b1  ADL-N PCIE
+product INTEL ADL_N_PCIE_110x54b2  ADL-N PCIE
+product INTEL ADL_N_PCIE_120x54b3  ADL-N PCIE
+product INTEL ADL_N_PCIE_1 0x54b8  ADL-N PCIE
+product INTEL ADL_N_PCIE_2 0x54b9  ADL-N PCIE
+product INTEL ADL_N_PCIE_3 0x54ba  ADL-N PCIE
+product INTEL ADL_N_PCIE_4 0x54bb  ADL-N PCIE
+product INTEL ADL_N_PCIE_7 0x54be  ADL-N PCIE
+product INTEL ADL_N_EMMC   0x54c4  ADL-N eMMC
+product INTEL ADL_N_I2C_4  0x54c5  ADL-N I2C
+product INTEL ADL_N_I2C_5  0x54c6  ADL-N I2C
+product INTEL ADL_N_UART_2 0x54c7  ADL-N UART
+product INTEL ADL_N_HDA0x54c8  ADL-N HDA
+product INTEL ADL_N_THC_0  0x54d0  ADL-N THC
+product INTEL ADL_N_THC_1  0x54d1  ADL-N THC
+product INTEL ADL_N_AHCI   0x54d3  ADL-N AHCI
+product INTEL ADL_N_UART_3 0x54da  ADL-N UART
+product INTEL ADL_N_HECI_1 0x54e0  ADL-N HECI
+product INTEL ADL_N_HECI_2 0x54e1  ADL-N HECI
+product INTEL ADL_N_HECI_3 0x54e4  ADL-N HECI
+product INTEL ADL_N_HECI_4 0x54e5  ADL-N HECI
+product INTEL ADL_N_I2C_0  0x54e8  ADL-N I2C
+product INTEL ADL_N_I2C_1  0x54e9  ADL-N I2C
+product INTEL ADL_N_I2C_2  0x54ea  ADL-N I2C
+product INTEL ADL_N_I2C_3  0x54eb  ADL-N I2C
+product INTEL ADL_N_XHCI   0x54ed  ADL-N xHCI
+product INTEL ADL_N_XDCI   0x54ee  ADL-N xDCI
+product INTEL ADL_N_SRAM   0x54ef  ADL-N SRAM
 product INTEL WL_22500_16  0x54f0  Wi-Fi 6 AX211
+product INTEL ADL_N_GSPI_2 0x54fb  ADL-N GSPI
+product INTEL ADL_N_UFS0x54ff  ADL-N UFS
 product INTEL I225_LMVP0x5502  I225-LMvP
 product INTEL I226_K   0x5504  I226-K
 product INTEL I219_LM180x550a  I219-LM
Index: sys/dev/pci/ichiic.c
===
RCS file: /cvs/src/sys/dev/pci/ichiic.c,v
diff -u -p -r1.51 ichiic.c
--- sys/dev/pci/ichiic.c5 Feb 2023 02:26:02 -   1.51
+++ sys/dev/pci/ichiic.c23 Nov 2023 12:38:18 -
@@ -139,6 +139,7 @@ const struct pci_matchid ichiic_ids[] = 
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_700SERIES_SMB },
 

Re: crash in r600_dri.so

[Jonathan Gray]

On Tue, Nov 21, 2023 at 08:19:11PM +1100, Jonathan Gray wrote:
> On Mon, Nov 20, 2023 at 09:19:45PM +, Edd Barrett wrote:
> > Hi Jonathan,
> > 
> > On Mon, Nov 20, 2023 at 07:16:14PM +1100, Jonathan Gray wrote:
> > > When it last worked, were you running Mesa 23.1 (snapshots since early
> > > November)?  Did this start with LLVM 16 (last few days)?
> > 
> > Looking back in my messages.0.gz, it seems I hadn't updated in a while.
> > 
> > The last working snapshot I had installed was:
> > OpenBSD 7.4-current (GENERIC.MP) #1403: Thu Oct 12 19:56:46 MDT 2023
> > 
> > Unfortunatley I don't know what Mesa I had at the time.
> 
> That would have been Mesa 22.3.7
> 
> With Mesa 22.3.7 on -current I can't reproduce the crash.

works with 23.1.9 after reverting
https://gitlab.freedesktop.org/mesa/mesa/-/commit/244cc152d1b20592120ce1d5dd9627509b73d0b9

Index: lib/mesa/src/gallium/drivers/r600/sfn/sfn_optimizer.cpp
===
RCS file: 
/cvs/xenocara/lib/mesa/src/gallium/drivers/r600/sfn/sfn_optimizer.cpp,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 sfn_optimizer.cpp
--- lib/mesa/src/gallium/drivers/r600/sfn/sfn_optimizer.cpp 2 Nov 2023 
04:32:35 -   1.1.1.2
+++ lib/mesa/src/gallium/drivers/r600/sfn/sfn_optimizer.cpp 21 Nov 2023 
12:41:07 -
@@ -407,11 +407,7 @@ CopyPropFwdVisitor::visit(AluInstr *inst
   if (can_propagate) {
  sfn_log << SfnLog::opt << "   Try replace in " << i->block_id() << ":"
  << i->index() << *i << "\n";
-
- if (i->as_alu() && i->as_alu()->parent_group()) {
-progress |= i->as_alu()->parent_group()->replace_source(dest, src);
- } else
-progress |= i->replace_source(dest, src);
+ progress |= i->replace_source(dest, src);
   }
}
if (instr->dest()) {

Re: crash in r600_dri.so

[Jonathan Gray]

On Mon, Nov 20, 2023 at 09:19:45PM +, Edd Barrett wrote:
> Hi Jonathan,
> 
> On Mon, Nov 20, 2023 at 07:16:14PM +1100, Jonathan Gray wrote:
> > When it last worked, were you running Mesa 23.1 (snapshots since early
> > November)?  Did this start with LLVM 16 (last few days)?
> 
> Looking back in my messages.0.gz, it seems I hadn't updated in a while.
> 
> The last working snapshot I had installed was:
> OpenBSD 7.4-current (GENERIC.MP) #1403: Thu Oct 12 19:56:46 MDT 2023
> 
> Unfortunatley I don't know what Mesa I had at the time.

That would have been Mesa 22.3.7

With Mesa 22.3.7 on -current I can't reproduce the crash.

> 
> Sorry, I appreciate that this is not very useful...
> 
> I've pulled out the GFX card and put in a:
> radeondrm0 at pci1 dev 0 function 0 "ATI Bonaire" rev 0x0
> 
> It's some OEM variant of a HD7790 I think. Anyway, this card does not have the
> same issue.

That is a "Southern Islands" card and does not use the R600
code in Mesa.

Some of the codenames are described in
https://www.x.org/wiki/RadeonFeature/

Re: crash in r600_dri.so

[Jonathan Gray]

On Sat, Nov 18, 2023 at 07:44:05PM +, Edd Barrett wrote:
> Hi,
> 
> Updated my snapshot yesterday and games/xonotic has started crashing as the
> game loads.

When it last worked, were you running Mesa 23.1 (snapshots since early
November)?  Did this start with LLVM 16 (last few days)?

> 
> I can repro every time. Imply start a single player game. It will crash during
> loading.

I can reproduce this but only with xonotic, not other GL programs.

radeondrm0 at pci1 dev 0 function 0 "ATI Mobility Radeon HD 3650" rev 0x00
radeondrm0: RV635

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00ac34678904 in 
std::__1::__tree_is_left_child*> 
(__x=0xabe72eef98)
at /usr/include/c++/v1/__tree:83
83  return __x == __x->__parent_->__left_;

(gdb) p __x->__parent_
$2 = (std::__1::__tree_node_base::__parent_pointer) 0x

A related issue, we have that change:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/7931
https://gitlab.freedesktop.org/mesa/mesa/-/commit/05fab97b2ce8ebd8420ded175101a0fa5110172c

> 
> My graphics card (is old):
> 
> vga1 at pci1 dev 0 function 0 "ATI Radeon HD 7470" rev 0x00
> 
> The amd64 snapshot:
> 
> OpenBSD 7.4-current (GENERIC.MP) #1453: Fri Nov 17 13:58:02 MST 2023
> 
> By building a debug pkg of xonotic, and using a xenocara diff from tb@ to 
> build
> xenocara without stripping libraries, I've managed to get the following
> backtrace.
> 
> Let me know if there's any other info that I could provide.
> 
> Cheers
> 
> #0  0x04adc0fe88f4 in 
> std::__1::__tree_is_left_child*> 
> (__x=0x4ae634544b8)
> at /usr/include/c++/v1/__tree:83
> #1  
> std::__1::__tree_next_iter*>*,
>  std::__1::__tree_node_base*> (__x=0x4ae634544b8) at 
> /usr/include/c++/v1/__tree:186
> #2  std::__1::__tree_const_iterator std::__1::__tree_node*, long>::operator++ (
> this=) at /usr/include/c++/v1/__tree:925
> #3  r600::CopyPropFwdVisitor::visit (this=0x7d16df2323f0, instr= out>)
> at 
> /usr/xenocara/lib/mesa/mk/libr600/../../src/gallium/drivers/r600/sfn/sfn_optimizer.cpp:378
> #4  0x04adc0fe9374 in r600::CopyPropFwdVisitor::visit 
> (this=0x7d16df2323f0, instr=)
> at 
> /usr/xenocara/lib/mesa/mk/libr600/../../src/gallium/drivers/r600/sfn/sfn_optimizer.cpp:631
> #5  0x04adc0fe75c4 in r600::copy_propagation_fwd (shader=...)
> at 
> /usr/xenocara/lib/mesa/mk/libr600/../../src/gallium/drivers/r600/sfn/sfn_optimizer.cpp:304
> #6  0x04adc0fe73ec in r600::optimize (shader=...)
> at 
> /usr/xenocara/lib/mesa/mk/libr600/../../src/gallium/drivers/r600/sfn/sfn_optimizer.cpp:59
> #7  0x04adc0f90a9f in r600_shader_from_nir (rctx=0x4ae0c032000, 
> pipeshader=0x4ae4c73f000, key=0x7d16df232788)
> at 
> /usr/xenocara/lib/mesa/mk/libr600/../../src/gallium/drivers/r600/sfn/sfn_nir.cpp:999
> #8  0x04adc103e700 in r600_pipe_shader_create (ctx=0x4ae0c032000, 
> shader=0x4ae4c73f000, key=...)
> at 
> /usr/xenocara/lib/mesa/mk/libr600/../../src/gallium/drivers/r600/r600_shader.c:231
> #9  0x04adc1072de4 in r600_shader_select (ctx=0x4ae63454480, 
> sel=0x4adc64f2350, dirty=0x7d16df23283f,
> precompile=)
> at 
> /usr/xenocara/lib/mesa/mk/libr600/../../src/gallium/drivers/r600/r600_state_common.c:967
> #10 0x04adc107a330 in r600_create_shader_state (ctx=0x4ae0c032000, 
> state=,
> pipe_shader_type=)
> at 
> /usr/xenocara/lib/mesa/mk/libr600/../../src/gallium/drivers/r600/r600_state_common.c:1071
> #11 0x04adc09d2bef in st_create_nir_shader (st=, 
> state=0x7d16df2328f8)
> at 
> /usr/xenocara/lib/mesa/mk/libmesa/../../src/mesa/state_tracker/st_program.c:551
> #12 0x04adc09d38d9 in st_create_fp_variant (st=0x4ae249ca000, 
> fp=0x4add664a630, key=0x7d16df232c40)
> at 
> /usr/xenocara/lib/mesa/mk/libmesa/../../src/mesa/state_tracker/st_program.c:1071
> #13 st_get_fp_variant (st=0x4ae249ca000, fp=0x4add664a630, key=0x7d16df232c40)
> at 
> /usr/xenocara/lib/mesa/mk/libmesa/../../src/mesa/state_tracker/st_program.c:1116
> #14 0x04adc09d419d in st_precompile_shader_variant (st=0x4ae249ca000, 
> prog=0x4add664a630)
> at 
> /usr/xenocara/lib/mesa/mk/libmesa/../../src/mesa/state_tracker/st_program.c:1303
> #15 st_finalize_program (st=0x4ae249ca000, prog=0x4add664a630)
> at 
> /usr/xenocara/lib/mesa/mk/libmesa/../../src/mesa/state_tracker/st_program.c:1365
> #16 0x04adc08fed81 in st_link_nir (ctx=0x4ae0e0dc000, 
> shader_program=0x4adc5ae1cb0)
> at 
> /usr/xenocara/lib/mesa/mk/libmesa/../../src/mesa/state_tracker/st_glsl_to_nir.cpp:956
> #17 0x04adc09cbe48 in link_shader (ctx=0x4ae0e0dc000, prog=0x4adc5ae1cb0)
> at 
> /usr/xenocara/lib/mesa/mk/libmesa/../../src/mesa/state_tracker/st_glsl_to_ir.cpp:91
> #18 st_link_shader (ctx=0x4ae0e0dc000, prog=0x4adc5ae1cb0)
> at 
> /usr/xenocara/lib/mesa/mk/libmesa/../../src/mesa/state_tracker/st_glsl_to_ir.cpp:106
> #19 0x04adc09cae83 in _mesa_glsl_link_shader (ctx=0x4ae0e0dc000, 
> prog=0x4adc5ae1cb0)
> at 
> /usr/xenocara/lib/mesa/m

Re: After 7.3 to 7.4 upgrade on an iMac11,2, the screen turns black

[Jonathan Gray]

On Wed, Oct 18, 2023 at 08:31:41PM +0200, Marcus Glocker wrote:
> When I revert this commit, the screen on my iMac11,2 works again:
> 
> https://marc.info/?l=openbsd-cvs&m=167989100718759&w=2

I can't think of anything else to try, so I have committed the revert.
Thanks for the report.

> 
> 
> Index: atombios_encoders.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/radeon/atombios_encoders.c,v
> retrieving revision 1.19
> diff -u -p -u -p -r1.19 atombios_encoders.c
> --- atombios_encoders.c   27 Mar 2023 04:23:40 -  1.19
> +++ atombios_encoders.c   18 Oct 2023 18:29:56 -
> @@ -2122,12 +2122,11 @@ int radeon_atom_pick_dig_encoder(struct 
>  
>   /*
>* On DCE32 any encoder can drive any block so usually just use crtc id,
> -  * but Apple thinks different at least on iMac10,1 and iMac11,2, so 
> there use linkb,
> +  * but Apple thinks different at least on iMac10,1, so there use linkb,
>* otherwise the internal eDP panel will stay dark.
>*/
>   if (ASIC_IS_DCE32(rdev)) {
> - if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1") ||
> - dmi_match(DMI_PRODUCT_NAME, "iMac11,2"))
> + if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1"))
>   enc_idx = (dig->linkb) ? 1 : 0;
>   else
>   enc_idx = radeon_crtc->crtc_id;
> 
> 

Re: After 7.3 to 7.4 upgrade on an iMac11,2, the screen turns black

[Jonathan Gray]

On Fri, Oct 20, 2023 at 04:37:36PM -0400, George Koehler wrote:
> On Thu, 19 Oct 2023 11:00:42 +1100
> Jonathan Gray  wrote:
> 
> > Are there multiple models of iMac11,2 or is this due to something
> > not acting as linux does?
> 
> Yes, iMac11,2 (21.5-inch, Mid 2010) has 3 models in everymac.com,
>  - Core i3 3.06 GHz, Radeon HD 4670, 256M vram
>  - Core i3 3.2  GHz, Radeon HD 5670, 512M vram
>  - Core i5 3.6  GHz, Radeon HD 5670, 512M vram
> 
> These Radeons might differ.  Marcus's 3.06 has product id 0x9488,
> which in drm/drm_pciids.h is CHIP_RV730.  An iMac11,2 3.2 in
> OpenBSD's dmesg collection has id 0x68c0, which is CHIP_REDWOOD.
> 
> An iMac probably has its original graphics card.  A Mac tower can
> swap cards; a PowerMac7,3 might have radeon or nvidia.
> 
> --gkoehler

This particular quirk is only done on the Radeon HD 4670/RV730 model due
to the earlier DCE test:

0x9488 Mobility Radeon HD 4670 (RV730)
0x68c0 Mobility Radeon HD 5730 (REDWOOD)

https://www.x.org/wiki/RadeonFeature/
RV730 is DCE3.2
REDWOOD is DCE4

if (ASIC_IS_DCE32(rdev)) {
if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1") ||
dmi_match(DMI_PRODUCT_NAME, "iMac11,2"))

Re: After 7.3 to 7.4 upgrade on an iMac11,2, the screen turns black

[Jonathan Gray]

On Wed, Oct 18, 2023 at 08:31:41PM +0200, Marcus Glocker wrote:
> When I revert this commit, the screen on my iMac11,2 works again:
> 
> https://marc.info/?l=openbsd-cvs&m=167989100718759&w=2

Are there multiple models of iMac11,2 or is this due to something
not acting as linux does?

I'm not opposed to reverting it and having a local diff, but would
prefer not to.

> 
> 
> Index: atombios_encoders.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/radeon/atombios_encoders.c,v
> retrieving revision 1.19
> diff -u -p -u -p -r1.19 atombios_encoders.c
> --- atombios_encoders.c   27 Mar 2023 04:23:40 -  1.19
> +++ atombios_encoders.c   18 Oct 2023 18:29:56 -
> @@ -2122,12 +2122,11 @@ int radeon_atom_pick_dig_encoder(struct 
>  
>   /*
>* On DCE32 any encoder can drive any block so usually just use crtc id,
> -  * but Apple thinks different at least on iMac10,1 and iMac11,2, so 
> there use linkb,
> +  * but Apple thinks different at least on iMac10,1, so there use linkb,
>* otherwise the internal eDP panel will stay dark.
>*/
>   if (ASIC_IS_DCE32(rdev)) {
> - if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1") ||
> - dmi_match(DMI_PRODUCT_NAME, "iMac11,2"))
> + if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1"))
>   enc_idx = (dig->linkb) ? 1 : 0;
>   else
>   enc_idx = radeon_crtc->crtc_id;
> 

Re: kernel diagnostic assertion "flags & (M_WAITOK | MNOWAIT)" failed, 7.3, incomplete report

[Jonathan Gray]

On Mon, Oct 09, 2023 at 05:05:42PM -0400, Scott Walters wrote:
> Sorry, this is not a real report.  I forgot to try to do Control Alt Escape 
> to get the
> ddb> prompt, and it didn't come up on its own even though ddb.panic is 1 in 
> sysctl.
> I switched to the non-SMP 7.3 kernel after that hoping it helps so sendbug 
> info below
> is wrong.  Crash is on the 7.3 MP kernel current as of a couple of weeks ago.
> 
> Going to try to get around to trying the RC's on a similar machine.
> 
> jpg attached.
> 
> >Synopsis:kernel panic 
> >Environment:
>   System  : OpenBSD 7.3
>   Details : OpenBSD 7.3 (GENERIC) #1072: Sat Mar 25 10:26:08 MDT 2023
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> kernel panic.
> >How-To-Repeat:
> Did not try to replicate, but was drawing an arc in xpaint when the 
> system
> became unresponsive then dropped to console as photographed a moment 
> later.
> Supposing that this is random and unrelated to user actions.

It could be you saw the problem fixed in
sys/dev/pci/drm/include/linux/gfp.h rev 1.7


revision 1.7
date: 2023/07/30 12:16:20;  author: jsg;  state: Exp;  lines: +1 -1;  commitid: 
nJseAF2KX36j82XS;
change __GFP_KSWAPD_RECLAIM from 0 to M_NOWAIT

aja@ reported a panic where __i915_gpu_coredump() used a combination of
gfp flags which resulted in neither M_WAITOK or M_NOWAIT.


This change is included in snapshot builds and will be in 7.4.

Re: `man backtrace` should name the required linker flag (`-lexecinfo`)

[Jonathan Gray]

On Sun, Oct 08, 2023 at 10:14:22PM -0400, Sean McBride wrote:
> Hello,
> 
> I've been trying to compile some open source C/C++ code on OpenBSD (that
> already builds on Mac, Windows, and linux) and one error I hit on one
> project was a link error trying to link to the backtrace() function.
> 
> So I went to check the man page.  But the man page does not document what
> linker flag is needed.  Luckily the FreeBSD man page does.
> 
> Contrast the first few lines of each:
> 
> ---
> FreeBSD:
> 
> NAME
>backtrace -- fill in the   backtrace of the currently executing 
> thread
> 
> LIBRARY
>Backtrace Access   Library (libexecinfo, -lexecinfo)
> 
> SYNOPSIS
>#include   
> ---
> 
> 
> ---
> OpenBSD:
> 
> NAME
>backtrace, backtrace_symbols,   backtrace_symbols_fd,
>backtrace_symbols_fmt, backtrace_symbols_fd_fmt -- fillin  the 
> back-
>trace of   the currently executing thread
> 
> SYNOPSIS
>#include   
> ---
> 
> 
> So tldr: `man backtrace` should name the required linker flag (-lexecinfo)

from mdoc(7):

.\" .Sh LIBRARY
.\" For sections 2, 3, and 9 only.
.\" Not used in OpenBSD.

note about it not being used added by jmc@ in 2010

Only use in base is in libelf.

Re: AMD gpu RX 6600 not recognized

[Jonathan Gray]

On Fri, Sep 29, 2023 at 10:09:17PM +0200, Solène Rapenne wrote:
> amdgpu_bar_sizes: RBCAP0 0x3f000 sizes: 256M 512M 1G 2G 4G 8G
> amdgpu_bar_sizes: RBCTRL0 0xd40 8G
> GMC real 0x1ff00 vis 0x1ff00, FB off 0x7c size 0x2,
> gart size 0x2000

Does limiting to a 32-bit size help?

Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c,v
retrieving revision 1.14
diff -u -p -r1.14 amdgpu_ttm.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c 13 Aug 2023 10:36:26 -  
1.14
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c 2 Oct 2023 10:48:45 -
@@ -1791,6 +1791,13 @@ int amdgpu_ttm_init(struct amdgpu_device
return r;
}
 
+#ifdef __OpenBSD__
+   if (amdgpu_vis_vram_limit == 0 && ((adev->flags & AMD_IS_APU) == 0)) {
+   if (amdgpu_vis_vram_limit > 4096)
+   amdgpu_vis_vram_limit = 4096;
+   }
+#endif
+
/* Reduce size of CPU-visible VRAM if requested */
vis_vram_limit = (u64)amdgpu_vis_vram_limit * 1024 * 1024;
if (amdgpu_vis_vram_limit > 0 &&
@@ -1810,11 +1817,13 @@ int amdgpu_ttm_init(struct amdgpu_device
adev->mman.aper_base_kaddr = ioremap_wc(adev->gmc.aper_base,
adev->gmc.visible_vram_size);
 #else
-   if (bus_space_map(adev->memt, adev->gmc.aper_base,
+   r = bus_space_map(adev->memt, adev->gmc.aper_base,
adev->gmc.visible_vram_size,
BUS_SPACE_MAP_LINEAR | BUS_SPACE_MAP_PREFETCHABLE,
-   &adev->mman.aper_bsh)) {
+   &adev->mman.aper_bsh);
+   if (r) {
adev->mman.aper_base_kaddr = NULL;
+   printf("bus_space_map ret %d\n", r);
} else {
adev->mman.aper_base_kaddr = bus_space_vaddr(adev->memt,
adev->mman.aper_bsh);

Re: AMD gpu RX 6600 not recognized

[Jonathan Gray]

On Mon, Sep 25, 2023 at 04:22:44PM +0200, Solène Rapenne wrote:
> > Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c,v
> > retrieving revision 1.14
> > diff -u -p -r1.14 amdgpu_ttm.c
> > --- sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c 13 Aug 2023 10:36:26
> > -  1.14
> > +++ sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c 21 Sep 2023 08:05:19
> > -
> > @@ -1792,6 +1792,7 @@ int amdgpu_ttm_init(struct amdgpu_device
> > }
> >  
> > /* Reduce size of CPU-visible VRAM if requested */
> > +amdgpu_vis_vram_limit = 512;
> > vis_vram_limit = (u64)amdgpu_vis_vram_limit * 1024 * 1024;
> > if (amdgpu_vis_vram_limit > 0 &&
> >     vis_vram_limit <= adev->gmc.visible_vram_size)
> 
> with this change, the card is recognized correctly without having to
> disable pci bar in the bios

a diff to print some more details

Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c,v
retrieving revision 1.14
diff -u -p -r1.14 amdgpu_ttm.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c 13 Aug 2023 10:36:26 -  
1.14
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c 26 Sep 2023 02:13:34 -
@@ -1744,6 +1744,54 @@ static int amdgpu_ttm_reserve_tmr(struct
return 0;
 }
 
+#define PCIE_ECAP_RESIZE_BAR   0x15
+#define RBCAP0 0x04
+#define RBCTRL00x08
+
+void
+amdgpu_bar_sizes(struct pci_dev *pdev)
+{
+   pcireg_t reg;
+   uint32_t offset, capid;
+   int i, size;
+
+   offset = PCI_PCIE_ECAP;
+   do {
+   reg = pci_conf_read(pdev->pc, pdev->tag, offset);
+   capid = PCI_PCIE_ECAP_ID(reg);
+   if (capid == PCIE_ECAP_RESIZE_BAR)
+   break;
+   offset = PCI_PCIE_ECAP_NEXT(reg);
+   } while (capid != 0);
+
+   if (capid == 0) {
+   printf("%s: could not find resize bar cap!\n", __func__);
+   return;
+   }
+
+   reg = pci_conf_read(pdev->pc, pdev->tag, offset + RBCAP0);
+   printf("%s: RBCAP0 0x%x sizes: ", __func__, reg);
+   reg = reg >> 4;
+   for (i = 0; i < 24; i++) {
+   size = 1 << i;
+   if (reg & size) {
+   if (size >= 1024)
+   printf("%dG ", size >> 10);
+   else
+   printf("%dM ", size);
+   }
+   }
+   printf("\n");
+
+   reg = pci_conf_read(pdev->pc, pdev->tag, offset + RBCTRL0);
+   printf("%s: RBCTRL0 0x%x", __func__, reg);
+   size = 1 << ((reg >> 8) & 0x1f);
+   if (size >= 1024)
+   printf(" %dG\n", size >> 10);
+   else
+   printf(" %dM\n", size);
+}
+
 /*
  * amdgpu_ttm_init - Init the memory management (ttm) as well as various
  * gtt/vram related fields.
@@ -1790,6 +1838,18 @@ int amdgpu_ttm_init(struct amdgpu_device
DRM_ERROR("Failed initializing VRAM heap.\n");
return r;
}
+
+#ifdef __OpenBSD__
+   if (amdgpu_vis_vram_limit == 0 && ((adev->flags & AMD_IS_APU) == 0)) {
+   amdgpu_bar_sizes(adev->pdev);
+   printf("GMC real 0x%llx vis 0x%llx,",
+   adev->gmc.real_vram_size, adev->gmc.visible_vram_size);
+   printf(" FB off 0x%lx size 0x%lx,",
+   adev->fb_aper_offset, adev->fb_aper_size);
+   printf(" gart size 0x%llx\n", adev->gmc.gart_size);
+   amdgpu_vis_vram_limit = 512;
+   }
+#endif
 
/* Reduce size of CPU-visible VRAM if requested */
vis_vram_limit = (u64)amdgpu_vis_vram_limit * 1024 * 1024;

Re: AMD gpu RX 6600 not recognized

[Jonathan Gray]

On Thu, Sep 21, 2023 at 11:40:24AM -0400, Solène Rapenne wrote:
> On Thu, 2023-09-21 at 17:50 +1000, Jonathan Gray wrote:
> > On Thu, Sep 21, 2023 at 09:05:50AM +0200, Solène Rapenne wrote:
> > > > Synopsis:   my GPU AMD Sapphire RX 6600 isn't recognized
> > > > Category:   kernel
> > > > Environment:
> > > System  : OpenBSD 7.4
> > > Details : OpenBSD 7.4-beta (GENERIC.MP) #1372: Wed Sep 20 
> > > 09:43:54 MDT 2023
> > >  
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > 
> > > Architecture: OpenBSD.amd64
> > > Machine : amd64
> > > > Description:
> > > I can't get accelerated graphics with a Sapphire RX 6600.
> > >     The amdgpu firmware is correctly installed after running fw_update
> > 
> > > [drm] *ERROR* visible_vram_size 1ff00 or aper_base_kaddr 0x0 is not 
> > > initialized.
> > > [drm] *ERROR* Failed to process memory training!
> > > [drm] *ERROR* sw_init of IP block  failed -22
> > > drm:pid0:amdgpu_device_init *ERROR* amdgpu_device_ip_init failed
> > > drm:pid0:amdgpu_attachhook *ERROR* Fatal error during GPU init
> > > efifb0 at mainbus0: 1920x1080, 32bpp
> > 
> > Does the bios have an option to disable resizable pci bar?
> > 
> > Doing an install with csm enabled (vga instead of efifb)
> > may also change things.
> 
> disabline the bar thing in the bios allowed me to have the GPU recognized, 
> but for some reason GDM started but didn't display anything. Enabling auto 
> login into gnome to circumvent the issue with GDM, I ended in a frozen gnome 
> with only gnome-shell loaded.
> 
> with xenodm and cwm it worked
> 
> until I've lost the screen, ssh was still working and I got access to dmesg 
> which has some stuff related to GPU

does this diff change what happens?

Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c,v
retrieving revision 1.10
diff -u -p -r1.10 amdgpu_gmc.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c 19 Jun 2023 00:38:02 -  
1.10
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c 22 Sep 2023 03:37:10 -
@@ -670,15 +670,6 @@ void amdgpu_gmc_get_vbios_allocations(st
} else {
size = amdgpu_gmc_get_vbios_fb_size(adev);
 
-#ifdef __amd64__
-   /*
-* XXX Workaround for machines where the framebuffer
-* size reported by the hardware is incorrect.
-*/
-   extern psize_t efifb_stolen();
-   size = max(size, efifb_stolen());
-#endif
-
if (adev->mman.keep_stolen_vga_memory)
size = max(size, (unsigned)AMDGPU_VBIOS_VGA_ALLOCATION);
}

Re: AMD gpu RX 6600 not recognized

[Jonathan Gray]

On Thu, Sep 21, 2023 at 09:55:44AM +0200, Solène Rapenne wrote:
> Le jeudi 21 septembre 2023 à 17:50 +1000, Jonathan Gray a écrit :
> > On Thu, Sep 21, 2023 at 09:05:50AM +0200, Solène Rapenne wrote:
> > > > Synopsis:   my GPU AMD Sapphire RX 6600 isn't recognized
> > > > Category:   kernel
> > > > Environment:
> > > System  : OpenBSD 7.4
> > > Details : OpenBSD 7.4-beta (GENERIC.MP) #1372: Wed Sep
> > > 20 09:43:54 MDT 2023
> > > 
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > 
> > > Architecture: OpenBSD.amd64
> > > Machine : amd64
> > > > Description:
> > > I can't get accelerated graphics with a Sapphire RX 6600.
> > >     The amdgpu firmware is correctly installed after running
> > > fw_update
> > 
> > > [drm] *ERROR* visible_vram_size 1ff00 or aper_base_kaddr 0x0 is
> > > not initialized.
> > > [drm] *ERROR* Failed to process memory training!
> > > [drm] *ERROR* sw_init of IP block  failed -22
> > > drm:pid0:amdgpu_device_init *ERROR* amdgpu_device_ip_init failed
> > > drm:pid0:amdgpu_attachhook *ERROR* Fatal error during GPU init
> > > efifb0 at mainbus0: 1920x1080, 32bpp
> > 
> > Does the bios have an option to disable resizable pci bar?
> > 
> > Doing an install with csm enabled (vga instead of efifb)
> > may also change things.
> 
> I have resizable pci bar enabled, I'll try to disable it.

There are also variables to limit the size of the window and the total,
which correspond to module parameters on linux.

amdgpu_vis_vram_limit

amdgpu_vram_limit

documented in
sys/dev/pci/drm/amd/amdgpu/amdgpu_drv.c

Perhaps this (untested) diff to limit to 512M would help.

Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c,v
retrieving revision 1.14
diff -u -p -r1.14 amdgpu_ttm.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c 13 Aug 2023 10:36:26 -  
1.14
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_ttm.c 21 Sep 2023 08:05:19 -
@@ -1792,6 +1792,7 @@ int amdgpu_ttm_init(struct amdgpu_device
}
 
/* Reduce size of CPU-visible VRAM if requested */
+amdgpu_vis_vram_limit = 512;
vis_vram_limit = (u64)amdgpu_vis_vram_limit * 1024 * 1024;
if (amdgpu_vis_vram_limit > 0 &&
vis_vram_limit <= adev->gmc.visible_vram_size)

Re: AMD gpu RX 6600 not recognized

[Jonathan Gray]

On Thu, Sep 21, 2023 at 09:05:50AM +0200, Solène Rapenne wrote:
> >Synopsis:my GPU AMD Sapphire RX 6600 isn't recognized
> >Category:kernel
> >Environment:
>   System  : OpenBSD 7.4
>   Details : OpenBSD 7.4-beta (GENERIC.MP) #1372: Wed Sep 20 09:43:54 
> MDT 2023
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   I can't get accelerated graphics with a Sapphire RX 6600.
> The amdgpu firmware is correctly installed after running fw_update

> [drm] *ERROR* visible_vram_size 1ff00 or aper_base_kaddr 0x0 is not 
> initialized.
> [drm] *ERROR* Failed to process memory training!
> [drm] *ERROR* sw_init of IP block  failed -22
> drm:pid0:amdgpu_device_init *ERROR* amdgpu_device_ip_init failed
> drm:pid0:amdgpu_attachhook *ERROR* Fatal error during GPU init
> efifb0 at mainbus0: 1920x1080, 32bpp

Does the bios have an option to disable resizable pci bar?

Doing an install with csm enabled (vga instead of efifb)
may also change things.

Re: blank screen after fresh installation of 7.2 in powerpc

[Jonathan Gray]

On Wed, Sep 13, 2023 at 04:56:24PM -0400, Nuno Vasconcellos wrote:
> I’m sorry Jonathan, the patch actually didn’t work since I had disabled 
> drmradeon in the kernel so I could get a working screen. Once I re-enabled 
> drmradeon and rebooted, I got the same issue.
> 
> I will let you know once I get it working.
> 
> Taking the opportunity, a question on the side, still related to this 
> subject, I noticed that r200 used to show up in a previous version of OpenBSD 
> but it is not in the 7.3 and reading here and there, I noticed that it is 
> related to Radeon 9200, the video card in my macppc. What this «absence» 
> imply?

As mentioned earlier, support for r200 acceleration was removed from the
main branch of the OpenGL library (Mesa).  Kernel support for
modesetting remains.

Re: Fwd: blank screen after fresh installation of 7.2 in powerpc

[Jonathan Gray]

On Tue, Sep 12, 2023 at 08:33:38PM -0400, Nuno Vasconcellos wrote:
> Jonathan, since my eMac is a PowerMac6,4, the solution proposed in the 
> following link resolved this problem in my case:
> 
> https://gitlab.freedesktop.org/drm/amd/-/issues/2844 
> 
> 
> Can this be put as a patch in the current release and become permanent fix 
> for future releases?

Yes, committed.  Thanks for reporting it.

Re: kernel protection fault when running as a HVM in Xen 4.15

[Jonathan Gray]

On Sun, Sep 10, 2023 at 03:48:34AM -0400, Solène Rapenne wrote:
> In the GitHub thread, Andrew Cooper, a Xen developer reported that it's
> a Xen and OpenBSD issue at the same time. I got the issue because of a
> new Xen version, here is his answer:
> 
> ---
> 
> I'm fairly sure it was broken in Xen 4.15 by 
> https://lore.kernel.org/xen-devel/0c8043e3-07aa-6242-19bd-07b04f574...@suse.com/,
>  a series committed over my objections concerning the correctness of the 
> changes.
> 
> It appears it was to shut up Linux, which makes different and equally dubious 
> model specific assumptions about the availability of certain MSRs.
> 
> - It is buggy for Linux to declare TSCFREQSEL missing to be a firmware bug - 
> it may legitimately be so due to levelling.
> - It's buggy for Xen to advertise the bit like that - because it's not 
> levelled and not part of the migration stream.
> - It's buggy for OpenBSD to perform any model-specific checks without first 
> checking for !hypervisor.

Do any of the architecture documents state that model specific registers
for a particular model are not implmented if the hypervisor bit is set?

They claim to be a particular model but don't implement the msrs for
that model.

> - And it's probably buggy for Xen to state "TSC counts at the P0 frequency" 
> without giving the P0 frequency, but the jury is still out on this final 
> point because there's no possible way the guest is going to get to see Pstate 
> information.

Re: i386 kernels broken on ALIX machines: identifycp_0x75b: rdmsr

[Jonathan Gray]

On Wed, Aug 16, 2023 at 10:37:56AM +0200, Paul de Weerd wrote:
> Hi Jonathan,
> 
> On Wed, Aug 16, 2023 at 04:37:45PM +1000, Jonathan Gray wrote:
> | I'm not sure when AMD added the MSR.
> | family 0fh is Athlon 64, which has microcode updates.
> | 
> | Index: sys/arch/i386/i386/machdep.c
> | ===
> | RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
> | retrieving revision 1.666
> | diff -u -p -r1.666 machdep.c
> | --- sys/arch/i386/i386/machdep.c9 Aug 2023 00:01:44 -   1.666
> | +++ sys/arch/i386/i386/machdep.c16 Aug 2023 06:26:24 -
> | @@ -1863,7 +1863,8 @@ identifycpu(struct cpu_info *ci)
> | uint64_t level = 0;
> | uint32_t dummy;
> |  
> | -   if (strcmp(cpu_vendor, "AuthenticAMD") == 0) {
> | +   if (strcmp(cpu_vendor, "AuthenticAMD") == 0 &&
> | +   ci->ci_family >= 0x0f) {
> | level = rdmsr(MSR_PATCH_LEVEL);
> | } else if (strcmp(cpu_vendor, "GenuineIntel") == 0) {
> | wrmsr(MSR_BIOS_SIGN, 0);
> 
> Thanks - I can confirm this fixes things on the ALIX.

thanks for the report, committed

Re: i386 kernels broken on ALIX machines: identifycp_0x75b: rdmsr

[Jonathan Gray]

On Tue, Aug 15, 2023 at 11:40:22PM -0700, Philip Guenther wrote:
> On Tue, 15 Aug 2023, Jonathan Gray wrote:
> > On Wed, Aug 16, 2023 at 08:14:17AM +0200, Paul de Weerd wrote:
> > > I still have a bunch of old ALIX machines (with ancient AMD Geode
> > > CPUs).  They have recently been broken, resulting in:
> > > 
> > > Using drive 0, partition 3.
> > > Loading..
> > > probing: pc0 com0 com1 pci mem[640K 255M a20=on] 
> > > disk: hd0+
> > > >> OpenBSD/i386 BOOT 3.65
> > > switching console to com0
> > > >> OpenBSD/i386 BOOT 3.65
> > > boot> 
> > > NOTE: random seed is being reused.
> > > booting hd0a:/bsd: 10631699+2581508+208904+0+1142784 
> > > [741328+107+609984+660770]=0xfd165c
> > > entry point at 0x201000
> > > 
> > > [ using 2012764 bytes of bsd ELF symbol table ]
> > > 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://urldefense.com/v3/__https://www.OpenBSD.org__;!!ORg
> > EfCBsr282Fw!sPHnpxSXkWt4yzRrr-P-B4uMXGltceezG9mMRHKe7ot0kp4wvCRc8R-9sUExn_65XdlAxQn7Qtmy9i7B$
> > > 
> > > OpenBSD 7.3-current (GENERIC) #820: Wed Aug  9 09:06:43 MDT 2023
> > > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> > > real mem  = 267931648 (255MB)
> > > avail mem = 245829632 (234MB)
> > > random: good seed from bootblocks
> > > mpath0 at root
> > > scsibus0 at mpath0: 256 targets
> > > mainbus0 at root
> > > bios0 at mainbus0: date 01/15/14, BIOS32 rev. 0 @ 0xfd0e4
> > > pcibios0 at bios0: rev 2.1 @ 0xf/0x1
> > > pcibios0: pcibios_get_intr_routing - function not supported
> > > pcibios0: PCI IRQ Routing information unavailable.
> > > pcibios0: PCI bus #0 is the last bus
> > > bios0: ROM list: 0xe/0xa800
> > > cpu0 at mainbus0: (uniprocessor)
> > > cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 
> > > 586-class) 499 MHz, 05-0a-02kernel: protection fau
> > lt trap, code=0
> > > Stopped at  identifycpu+0x75b:  rdmsr
> > > ddb> trace
> > > identifycpu(d0e9dff8) at identifycpu+0x75b
> > > cpu_attach(d1ab5180,d1ab5200,d11d4ea4) at cpu_attach+0x127
> > > config_attach(d1ab5180,d0eae388,d11d4ea4,d08f8240) at config_attach+0x19a
> > > config_found_sm(d1ab5180,d11d4ea4,d08f8240,0) at config_found_sm+0x29
> > > mainbus_attach(0,d1ab5180,0) at mainbus_attach+0x112
> > > config_attach(0,d0eabd28,0,0) at config_attach+0x19a
> > > config_rootfound(d0ca30ef,0) at config_rootfound+0xaf
> > > cpu_configure(e5497e72,11d2000,11e1000,11d5000,0) at cpu_configure+0x24
> > > main(0,0,0,0,0) at main+0x31b
> > > ddb> 
> > > 
> > > The bsd.rd kernel also fails to work:
> > > 
> > > cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 
> > > 586-class) 499 MHz, 05-0a-02fatal protection fault
> >  (4) in supervisor mode
> > > trap type 4 code 0 eip d03af033 cs 8 eflags 10046 cr2 0 cpl 0
> > > panic: trap type 4, code=0, pc=d03af033
> > > 
> > > Unfortunately, I can't tell what snapshot I was running before I
> > > upgraded, but it was at least a few months old.  I'll PXE boot a 7.3
> > > bsd.rd later to rummage around the filesystem.
> > 
> > I'm not sure when AMD added the MSR.
> > family 0fh is Athlon 64, which has microcode updates.
> > 
> > Index: sys/arch/i386/i386/machdep.c
> > ===
> > RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
> > retrieving revision 1.666
> > diff -u -p -r1.666 machdep.c
> > --- sys/arch/i386/i386/machdep.c9 Aug 2023 00:01:44 -   1.666
> > +++ sys/arch/i386/i386/machdep.c16 Aug 2023 06:26:24 -
> > @@ -1863,7 +1863,8 @@ identifycpu(struct cpu_info *ci)
> > uint64_t level = 0;
> > uint32_t dummy;
> >  
> > -   if (strcmp(cpu_vendor, "AuthenticAMD") == 0) {
> > +   if (strcmp(cpu_vendor, "AuthenticAMD") == 0 &&
> > +   ci->ci_family >= 0x0f) {
> 
> All the ucode they publish is for that family and up?
> ok guenther@

linux-firmware/amd-ucode starts at family 10h (and doesn't have much)

https://github.com/platomav/CPUMicrocodes/tree/master/AMD has
cpu0F00_ver0208_2007-06-14_C3A923BB.bin which is family 0fh

Re: i386 kernels broken on ALIX machines: identifycp_0x75b: rdmsr

[Jonathan Gray]

On Wed, Aug 16, 2023 at 08:14:17AM +0200, Paul de Weerd wrote:
> I still have a bunch of old ALIX machines (with ancient AMD Geode
> CPUs).  They have recently been broken, resulting in:
> 
> Using drive 0, partition 3.
> Loading..
> probing: pc0 com0 com1 pci mem[640K 255M a20=on] 
> disk: hd0+
> >> OpenBSD/i386 BOOT 3.65
> switching console to com0
> >> OpenBSD/i386 BOOT 3.65
> boot> 
> NOTE: random seed is being reused.
> booting hd0a:/bsd: 10631699+2581508+208904+0+1142784 
> [741328+107+609984+660770]=0xfd165c
> entry point at 0x201000
> 
> [ using 2012764 bytes of bsd ELF symbol table ]
> 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-current (GENERIC) #820: Wed Aug  9 09:06:43 MDT 2023
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> real mem  = 267931648 (255MB)
> avail mem = 245829632 (234MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 01/15/14, BIOS32 rev. 0 @ 0xfd0e4
> pcibios0 at bios0: rev 2.1 @ 0xf/0x1
> pcibios0: pcibios_get_intr_routing - function not supported
> pcibios0: PCI IRQ Routing information unavailable.
> pcibios0: PCI bus #0 is the last bus
> bios0: ROM list: 0xe/0xa800
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 
> 499 MHz, 05-0a-02kernel: protection fault trap, code=0
> Stopped at  identifycpu+0x75b:  rdmsr
> ddb> trace
> identifycpu(d0e9dff8) at identifycpu+0x75b
> cpu_attach(d1ab5180,d1ab5200,d11d4ea4) at cpu_attach+0x127
> config_attach(d1ab5180,d0eae388,d11d4ea4,d08f8240) at config_attach+0x19a
> config_found_sm(d1ab5180,d11d4ea4,d08f8240,0) at config_found_sm+0x29
> mainbus_attach(0,d1ab5180,0) at mainbus_attach+0x112
> config_attach(0,d0eabd28,0,0) at config_attach+0x19a
> config_rootfound(d0ca30ef,0) at config_rootfound+0xaf
> cpu_configure(e5497e72,11d2000,11e1000,11d5000,0) at cpu_configure+0x24
> main(0,0,0,0,0) at main+0x31b
> ddb> 
> 
> The bsd.rd kernel also fails to work:
> 
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 
> 499 MHz, 05-0a-02fatal protection fault (4) in supervisor mode
> trap type 4 code 0 eip d03af033 cs 8 eflags 10046 cr2 0 cpl 0
> panic: trap type 4, code=0, pc=d03af033
> 
> Unfortunately, I can't tell what snapshot I was running before I
> upgraded, but it was at least a few months old.  I'll PXE boot a 7.3
> bsd.rd later to rummage around the filesystem.

I'm not sure when AMD added the MSR.
family 0fh is Athlon 64, which has microcode updates.

Index: sys/arch/i386/i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.666
diff -u -p -r1.666 machdep.c
--- sys/arch/i386/i386/machdep.c9 Aug 2023 00:01:44 -   1.666
+++ sys/arch/i386/i386/machdep.c16 Aug 2023 06:26:24 -
@@ -1863,7 +1863,8 @@ identifycpu(struct cpu_info *ci)
uint64_t level = 0;
uint32_t dummy;
 
-   if (strcmp(cpu_vendor, "AuthenticAMD") == 0) {
+   if (strcmp(cpu_vendor, "AuthenticAMD") == 0 &&
+   ci->ci_family >= 0x0f) {
level = rdmsr(MSR_PATCH_LEVEL);
} else if (strcmp(cpu_vendor, "GenuineIntel") == 0) {
wrmsr(MSR_BIOS_SIGN, 0);

Re: buffer overprint in riscv64/cpu.c

[Jonathan Gray]

On Fri, Aug 04, 2023 at 01:26:08PM +0200, Peter J. Philipp wrote:
> On Tue, Aug 01, 2023 at 01:43:36PM +0200, p...@delphinusdns.org wrote:
> > >Synopsis:  non-terminated strings buffer in riscv64/cpu.c
> > >Category:  kernel
> > >Environment:
> > System  : OpenBSD 7.3
> > Details : OpenBSD 7.3-current (GENERIC.MP) #376: Thu Jul 13 
> > 03:59:40 MDT 2023
> >  
> > dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.riscv64
> > Machine : riscv64
> > >Description:
> > The cpu detect output is not NUL terminated, this causes *puke* to be
> > displayed on serial terminals.
> > >How-To-Repeat:
> > Using Qemu for riscv64 arch.
> > 
> > from a eeprom -p | grep isa output:
> > 
> > riscv,isa: 
> > 'rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc'
> > riscv,isa: 
> > 'rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc'
> > 
> > I counted this as 60 bytes long.
> > >Fix:
> > 
> > There is two approaches.  One is to explicitly NUL terminate the 32 byte
> > buffer or make it bigger.  I give an untested patch of the latter.

riscv,isa is going away:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aeb71e42caae2031ec849a858080d81462cacca9

I see no point in trying to parse it.

> > 
> > Index: cpu.c
> > ===
> > RCS file: /cvs/src/sys/arch/riscv64/riscv64/cpu.c,v
> > retrieving revision 1.14
> > diff -u -p -u -r1.14 cpu.c
> > --- cpu.c   15 Jun 2023 22:18:08 -  1.14
> > +++ cpu.c   1 Aug 2023 11:35:28 -
> > @@ -87,7 +87,7 @@ int cpu_errata_sifive_cip_1200;
> >  void
> >  cpu_identify(struct cpu_info *ci)
> >  {
> > -   char isa[32];
> > +   char isa[64];
> > uint64_t marchid, mimpid;
> > uint32_t mvendorid;
> > const char *vendor_name = NULL;
> > 
> > 
> 
> [tying in tech@]
> 
> This wasn't effective I just saw.  On another QEMU host the cpu ISA string is
> larger than 80 characters.  So I've made another patch.
> 
> With this patch it looks like so:
> 
> oceans$ dmesg|grep cpu
> cpu0 at mainbus0: vendor 0 arch 0 imp 0 rv64imafdch Zicbom Zicboz Zicsr 
> Zifencei Zihintpause Zawrs Zfa Zca Zcd Zba Zbb Zbc Zbs Sstc Svadu
> intc0 at cpu0
> cpu1 at mainbus0: vendor 0 arch 0 imp 0 rv64imafdch Zicbom Zicboz Zicsr 
> Zifencei Zihintpause Zawrs Zfa Zca Zcd Zba Zbb Zbc Zbs Sstc Svadu
> oceans# grep zicboz /root/eeprom-p.out
>  
> riscv,isa: 
> 'rv64imafdch_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_sstc_svadu'
> riscv,isa: 
> 'rv64imafdch_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_sstc_svadu'
> 
> This is in convention with the cpu.c found in qemu:
> 
> https://gitlab.com/qemu-project/qemu/-/blob/master/target/riscv/cpu.c
> 
> lines 64 through 84 is the description of it.
> 
> While I have no OpenBSD/riscv64 on true hardware it works on QEMU, and I
> googled for a dmesg online and the Hifive Unmatched should work as well.
> 
> patch follows:
> 
> Index: cpu.c
> ===
> RCS file: /cvs/src/sys/arch/riscv64/riscv64/cpu.c,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 cpu.c
> --- cpu.c 15 Jun 2023 22:18:08 -  1.14
> +++ cpu.c 4 Aug 2023 11:15:16 -
> @@ -84,15 +84,19 @@ struct cfdriver cpu_cd = {
>  
>  int cpu_errata_sifive_cip_1200;
>  
> +
>  void
>  cpu_identify(struct cpu_info *ci)
>  {
> - char isa[32];
> + char isa[255];
> + char szx_ext[255];  /* S, Z and X extension buffer */
> + char *extensions = "imafdqlcbkjtpvh";
>   uint64_t marchid, mimpid;
>   uint32_t mvendorid;
>   const char *vendor_name = NULL;
>   const char *arch_name = NULL;
>   struct arch *archlist = cpu_arch_none;
> + char *p, *pe, *end;
>   int i, len;
>  
>   mvendorid = sbi_get_mvendorid();
> @@ -126,8 +130,70 @@ cpu_identify(struct cpu_info *ci)
>  
>   len = OF_getprop(ci->ci_node, "riscv,isa", isa, sizeof(isa));
>   if (len != -1) {
> + /* terminate it, it could be non-terminated */
> + isa[sizeof(isa) - 1] = '\0';
> + 
> + /* PARSE the IMAFDQ... extensions */
> + pe = extensions;
> + if ((p = strchr(isa, 'i')) != NULL ||
> + (p = strchr(isa, 'I')) != NULL) {
> + for (; *pe != '\0'; pe++) {
> + if (((*p)|0x20) == *pe) {
> + if (p[1]) {
> + p++;
> + i++;
> + } else
> + break;
> + } 
> + /*
> + 

Re: taskq_next_work: page fault trap when staring Xfce

[Jonathan Gray]

On Mon, Jul 31, 2023 at 10:48:12PM +1000, Jonathan Gray wrote:
> On Sun, Jul 30, 2023 at 03:21:47PM +0900, YASUOKA Masahiko wrote:
> > Hello,
> > 
> > I got new vaio last week, the machine seems to have the same graphic
> > 
> >   inteldrm0 at pci0 dev 2 function 0 "Intel Graphics" rev 0x04
> >   drm0 at inteldrm0
> >   inteldrm0: msi, ALDERLAKE_P, gen 12
> > 
> > and has the same problem.  I found having Option "PageFlip" "off" in
> > /etc/X11/xorg.conf can workaround the problem.
> > 
> >   Section "Device"
> >   Identifier  "Card0"
> >   Driver  "modesetting"
> >   BusID   "PCI:0:2:0"
> >   Option  "PageFlip" "off"
> >   EndSection
> 
> running GENERIC I got the following with xfce.
> 
> matches the trace in an earlier report from sthen@
> https://marc.info/?l=openbsd-bugs&m=168234057913478&w=2
> 
> dpt_insert_entries+0xbc: movl 0x34(%r8),%r10d
> r80x81938fe0
> r10   0x1000
> 
>0x81ab0bc3 <+179>:   mov%r8,%rcx
>0x81ab0bc6 <+182>:   add$0x20,%rcx
>0x81ab0bca <+186>:   je 0x81ab0be8 
> 
>0x81ab0bcc <+188>:   mov0x34(%r8),%r10d
>0x81ab0bd0 <+192>:   test   %r10d,%r10d
>0x81ab0bd3 <+195>:   je 0x81ab0be8 
> 
> 
> (gdb) info line *0x81ab0bcc
> Line 34 of "/sys/dev/pci/drm/i915/i915_scatterlist.h"
>starts at address 0x81ab0bc1 
>and ends at 0x81ab0bd5 .
> 
> if (dma && s.sgp && sg_dma_len(s.sgp) == 0) {
> 
> dpt_insert_entries+0xbc
> dpt_bind_vma+0x64
> i915_vma_bind+0x317
> i915_vma_pin_ww+0x44b
> intel_plane_pin_fb+0x25c
> intel_prepare_plane_pin_fb+0x12c
> drm_atomic_helper_prepare_planes+0x5b
> intel_atomic_commit+0xda
> drm_atomic_helper_page_flip+0x77
> drm_mode_page_flip_ioctl+0x466
> drm_do_ioctl+0x285
> drmioctl+0xdc
> VOP_IOCTL+0x57
> vn_ioctl+0x6c

The fix is to not reset the end of list marker when
assigning a page.

Index: sys/dev/pci/drm/include/linux/scatterlist.h
===
RCS file: /cvs/src/sys/dev/pci/drm/include/linux/scatterlist.h,v
retrieving revision 1.5
diff -u -p -r1.5 scatterlist.h
--- sys/dev/pci/drm/include/linux/scatterlist.h 1 Jan 2023 01:34:58 -   
1.5
+++ sys/dev/pci/drm/include/linux/scatterlist.h 2 Aug 2023 04:02:02 -
@@ -119,7 +119,6 @@ sg_set_page(struct scatterlist *sgl, str
sgl->dma_address = page ? VM_PAGE_TO_PHYS(page) : 0;
sgl->offset = offset;
sgl->length = length;
-   sgl->end = false;
 }
 
 #define sg_dma_address(sg) ((sg)->dma_address)

Re: taskq_next_work: page fault trap when staring Xfce

[Jonathan Gray]

On Sun, Jul 30, 2023 at 03:21:47PM +0900, YASUOKA Masahiko wrote:
> Hello,
> 
> I got new vaio last week, the machine seems to have the same graphic
> 
>   inteldrm0 at pci0 dev 2 function 0 "Intel Graphics" rev 0x04
>   drm0 at inteldrm0
>   inteldrm0: msi, ALDERLAKE_P, gen 12
> 
> and has the same problem.  I found having Option "PageFlip" "off" in
> /etc/X11/xorg.conf can workaround the problem.
> 
>   Section "Device"
>   Identifier  "Card0"
>   Driver  "modesetting"
>   BusID   "PCI:0:2:0"
>   Option  "PageFlip" "off"
>   EndSection

running GENERIC I got the following with xfce.

matches the trace in an earlier report from sthen@
https://marc.info/?l=openbsd-bugs&m=168234057913478&w=2

dpt_insert_entries+0xbc: movl 0x34(%r8),%r10d
r8  0x81938fe0
r10 0x1000

   0x81ab0bc3 <+179>:   mov%r8,%rcx
   0x81ab0bc6 <+182>:   add$0x20,%rcx
   0x81ab0bca <+186>:   je 0x81ab0be8 

   0x81ab0bcc <+188>:   mov0x34(%r8),%r10d
   0x81ab0bd0 <+192>:   test   %r10d,%r10d
   0x81ab0bd3 <+195>:   je 0x81ab0be8 


(gdb) info line *0x81ab0bcc
Line 34 of "/sys/dev/pci/drm/i915/i915_scatterlist.h"
   starts at address 0x81ab0bc1 
   and ends at 0x81ab0bd5 .

if (dma && s.sgp && sg_dma_len(s.sgp) == 0) {

dpt_insert_entries+0xbc
dpt_bind_vma+0x64
i915_vma_bind+0x317
i915_vma_pin_ww+0x44b
intel_plane_pin_fb+0x25c
intel_prepare_plane_pin_fb+0x12c
drm_atomic_helper_prepare_planes+0x5b
intel_atomic_commit+0xda
drm_atomic_helper_page_flip+0x77
drm_mode_page_flip_ioctl+0x466
drm_do_ioctl+0x285
drmioctl+0xdc
VOP_IOCTL+0x57
vn_ioctl+0x6c

Re: taskq_next_work: page fault trap when staring Xfce

[Jonathan Gray]

On Wed, Jul 26, 2023 at 02:53:42PM +, Klemens Nanni wrote:
> startxfce4 in ~/.xsession leaves the screen black immediately after
> login from xenodm on an Intel T14g3 with latest snap and packages,
> sometimes it hangs completely and needs a hard reset, but this time
> I could switch to ttyC0 and use DDB:
> 
> 
> uvm_fault(0x825b0130, 0x820a8014, 0, 1) -> e
> uvm_fault(0x825b0130, 0x, 0, 2) -> e
> kernel: page fault trap, code=2
> Stopped at  taskq_next_work+0x80:   movq%rcx,0(%rdx)
> TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
>350x12  01  Xorg
> 0 0x14000  0x2004  drmtskl
> 0 0x14000  0x2000K drmwq
> 0 0x14000  0x2003  drmwq
> 0 0x14000  0x2002  drmwq
> 0 0x14000  0x2005  drmwq
> taskq_next_work(80044cf00, 800023153ef0) at taskq_next_work+0x80
> task_thread(80044cf00) at task_thread+0xeb
> end trace frame: 0x0, count: 13
> 
> 
> The graphics stack on this machine has always been unstable.
> Back at m2k23 I could not even use Qt programs like telegram-desktop
> without artifacts/glitches/hangs/crashes, but something improved and it
> is almost stable, i.e. firefox + telegram-desktop + gui apps maybe hang
> the machine once a week on GENERIC.MP when I'm unlucky.
> 'disable inteldrm' is stable (but yields other bugs in Qt apps).
> 
> 
> Xfce4, however, I have never been able to start in the first place.
> 
> Anything I should look for in DDB next time?
> Happy to poke at this in case anyone has a clue what's going on.

I tried xfce on 21AH t14 gen 3.

The first time, everything seemed fine.

The second time:
panic: pmap_get_ptp: unmanaged user PTP

another time with WITNESS
chillbufs+0xc6: movq %r8,0x8(%rdx)
r8 0x8251a868 cleancache+0x18 cachepages
rdx 0xc8abc8abd8fde6c7
Line 1765 of "/sys/kern/vfs_bio.c"
TAILQ_REMOVE(queue, bp, b_freelist);

chillbufs+0xc6
bufcache_release+0x10a
brelse+0x96
ffs_read+0x203
VOP_READ+0x45
uvn_io+0x26b
uvn_get+0x15d
uvm_fault_lower+0x336
uvm_fault+0x1b3
upageflttrap+0x65
usertrap+0x1ee
recall_trap+0x8

*xfsettingsd

removing ~/.config/xfce4/ before starting X, xfce starts again

There appears to be some kind of memory corruption.

often it is just
uvm_fault(0x82519940, 0x819e0014, 0, 1) -> e
and a hang

Re: iwm Bug report

[Jonathan Gray]

On Sun, Jul 30, 2023 at 04:39:08PM +0200, 4s6e46s46s...@tutanota.com wrote:
> Starting from 01.jpg to 10.jpg I have tried to provide the requested bug 
> report information in the form of camera pictures about this bug or error 
> message I am experiencing during the boot process.
> My OpenBSD is 7.3 after I had updated my machine to 7.3 with sysupgrade (just 
> a regular update, not -current)
> 
> My machine is a Lenovo Thinkpad x250
> 
> What I did prior to experiencing this error (I do not remember the exact 
> sequence of events, but I believe it was in the following order):
> - doas syspatch ( it downloaded new 15 patches I believe)
> - then I replaced a line in my hostname.iwm0 with something else that I had 
> copied from doing a search on how to write the hostname file, because I had 
> forgotten the syntax. I did this because my internet was very slow. I had 
> remembered that I have had this problem before, and that changing the 
> hostname.iwm0 did at least improve my internet speed somewhat because the 
> option or signal strength was limiting my speed somehow. I do not remember 
> the exact line I copied, but I believe it had the word monitor at the end, 
> media autoselect, 11 and a letter 
> - doas sh -x /etc/netstart
> - doas rcctl restart openvpn
> - Then I did a reboot because something was not working. I believe I had no 
> internet, and I was hoping a reboot might fix it. I also did have 2 external 
> hard drives mounted and decrypted at the time, and forgot to demount them  
> and remove them before rebooting via doas bioctl -d sdN. Not sure if this has 
> any significance 
> - then after rebooting I get the message in 01.jpg

iwm_setrates+0x20: movq 0(%rax),%r14
iwm_auth+0xc4
iwm_run+0x59
iwm_newstate_task+0xf1
taskq_thread+0x100

appears to be

struct iwm_softc *sc = IC2IFP(ic)->if_softc;

> 
> I believe I did have something like a "blue screen" crash during normal 
> runtime usage at least once on this machine while running OpenBSD.
> 
> I hope you can do something with this information. 
> 
> Is there anything I can do to fix this error and boot my OS again?

to temporarily disable iwm, at the boot prompt:

boot -c
disable iwm*
quit

Re: amdgpu: async flip with non-fast update

[Jonathan Gray]

On Fri, Jul 28, 2023 at 10:14:14PM +0100, Laurence Tratt wrote:
> I built a new kernel this morning which includes a number of amdgpu patches.
> I saw a bizarre situation where: the machine almost-but-not-quite ground to a
> halt for quite a while, with the display not updating properly. Then the
> display updated normally, the mouse continued working OK, but the keyboard
> mostly didn't work. Oddly, I could sort-of Ctrl+Alt+F1 to the console in the
> sense that X stopped updating -- but the display didn't show the consle. I
> could then Ctrl+Alt+F5 back and X would (slowly) update.
> 
> I've noticed I now have this in my dmesg:
> 
>   Jul 28 13:20:24 overdrive /bsd: drm:pid97220:amdgpu_dm_commit_planes 
> *WARNING* [drm] [PLANE:55:plane-3] async flip with non-fast update
> 
> which may perhaps be correlated with this? Output from /var/log/messages
> below of the session below.

does the following diff change the behaviour besides the message?

There is an open issue related to this on fdo:
https://gitlab.freedesktop.org/drm/amd/-/issues/2733

Index: sys/dev/pci/drm/amd/display/amdgpu_dm/amdgpu_dm.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/display/amdgpu_dm/amdgpu_dm.c,v
retrieving revision 1.95
diff -u -p -r1.95 amdgpu_dm.c
--- sys/dev/pci/drm/amd/display/amdgpu_dm/amdgpu_dm.c   28 Jul 2023 07:10:26 
-  1.95
+++ sys/dev/pci/drm/amd/display/amdgpu_dm/amdgpu_dm.c   29 Jul 2023 01:32:08 
-
@@ -7771,15 +7771,7 @@ static void amdgpu_dm_commit_planes(stru
 * Only allow immediate flips for fast updates that don't
 * change memory domain, FB pitch, DCC state, rotation or
 * mirroring.
-*
-* dm_crtc_helper_atomic_check() only accepts async flips with
-* fast updates.
 */
-   if (crtc->state->async_flip &&
-   acrtc_state->update_type != UPDATE_TYPE_FAST)
-   drm_warn_once(state->dev,
- "[PLANE:%d:%s] async flip with non-fast 
update\n",
- plane->base.id, plane->name);
bundle->flip_addrs[planes_count].flip_immediate =
crtc->state->async_flip &&
acrtc_state->update_type == UPDATE_TYPE_FAST &&
Index: sys/dev/pci/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c,v
retrieving revision 1.4
diff -u -p -r1.4 amdgpu_dm_crtc.c
--- sys/dev/pci/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c  28 Jul 2023 
06:39:55 -  1.4
+++ sys/dev/pci/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c  29 Jul 2023 
01:32:08 -
@@ -406,18 +406,6 @@ static int dm_crtc_helper_atomic_check(s
return -EINVAL;
}
 
-   /*
-* Only allow async flips for fast updates that don't change the FB
-* pitch, the DCC state, rotation, etc.
-*/
-   if (crtc_state->async_flip &&
-   dm_crtc_state->update_type != UPDATE_TYPE_FAST) {
-   drm_dbg_atomic(crtc->dev,
-  "[CRTC:%d:%s] async flips are only supported for 
fast updates\n",
-  crtc->base.id, crtc->name);
-   return -EINVAL;
-   }
-
/* In some use cases, like reset, no stream is attached */
if (!dm_crtc_state->stream)
return 0;

Re: amdgpu: Error waiting for DMUB idle / Error queuing DMUB command

[Jonathan Gray]

On Thu, Jun 29, 2023 at 09:58:25AM +0100, Laurence Tratt wrote:
> Upgrading to last night's snapshot I think updated amdgpu's firmware (to
> amdgpu-firmware-20230625). I'm now getting lots of stutter (X freezes for
> ~0.5-1s, key presses dropped etc) and lots of these in dmesg:
> 
>   [drm] *ERROR* Error waiting for DMUB idle: status=3
>   [drm] *ERROR* Error queuing DMUB command: status=2
> 
> I've rebuilt a new kernel (git# 2b5ea97f) but am seeing the same
> behaviour. dmesg below.

Paul de Weerd also reported problems with the firmware update.
We tracked it down to

amdgpu: DMCUB updates for DCN 3.1.4 and 3.1.5
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=ade163aaaeae0c1ad20cb3dd8ce878bf61c91b3a

(Ryzen 7000 includes DCN 3.1.5)

A diff to switch the port to a snapshot before that commit:

Index: Makefile
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/Makefile,v
retrieving revision 1.20
diff -u -p -r1.20 Makefile
--- Makefile27 Jun 2023 10:11:42 -  1.20
+++ Makefile29 Jun 2023 08:41:16 -
@@ -1,13 +1,16 @@
 FW_DRIVER= amdgpu
 FW_VER=20230625
-DISTNAME=  linux-firmware-${FW_VER}
-EXTRACT_SUFX=  .tar.xz
+DISTNAME=  linux-firmware-045b2136a61968e7984caeae857a326150bfe851
+#DISTNAME= linux-firmware-${FW_VER}
+#EXTRACT_SUFX= .tar.xz
 EXTRACT_FILES= ${DISTNAME}/{LICENSE.\*,\*.bin}
+REVISION=  0
 
 MAINTAINER=Jonathan Gray 
 
 HOMEPAGE=  
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu
-MASTER_SITES=  https://cdn.kernel.org/pub/linux/kernel/firmware/
+#MASTER_SITES= https://cdn.kernel.org/pub/linux/kernel/firmware/
+MASTER_SITES=  
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/snapshot/
 
 do-install:
${INSTALL_DATA_DIR} ${PREFIX}/firmware/amdgpu
Index: distinfo
===
RCS file: /cvs/ports/sysutils/firmware/amdgpu/distinfo,v
retrieving revision 1.18
diff -u -p -r1.18 distinfo
--- distinfo27 Jun 2023 10:11:42 -  1.18
+++ distinfo29 Jun 2023 08:43:15 -
@@ -1,2 +1,2 @@
-SHA256 (firmware/linux-firmware-20230625.tar.xz) = 
h1lxEcDUtxsx5Ty4WpLDhpIbhMglpALbjILg6GAVUA0=
-SIZE (firmware/linux-firmware-20230625.tar.xz) = 280854212
+SHA256 
(firmware/linux-firmware-045b2136a61968e7984caeae857a326150bfe851.tar.gz) = 
I5VDKGybmVgRYfpCojBZvBcpqbLb+OVuM+VBwRuB81U=
+SIZE (firmware/linux-firmware-045b2136a61968e7984caeae857a326150bfe851.tar.gz) 
= 439517447

Re: Is it possible to use the amdgpu driver with my Amd R7-240 gpu ?

[Jonathan Gray]

On Sat, Jun 24, 2023 at 09:32:48PM +0200, Matthieu Herrb wrote:
> On Sat, Jun 24, 2023 at 07:35:30PM +0300, chris greek wrote:
> > Is it possible to use the amdgpu driver with my Amd R7-240 gpu ?
> > Do i have to modify and compile the kernel so it would use amdgpu instead
> > of radeon ?
> 
> There is code to support your card (id 0x6631 if I figured it out
> correctly) in the amdgpu driver indeed. So as Jonathan said in answer
> to your previous mail you can tray to disable radrondrm from the boot
> prompt:
> 
>   boot -c
>   disable radeondrm*
>   quit
> 
> Then  the amdgpu driver should attach to your card.

No, amdgpu support for SI/CIK is not built.

It was used to bootstrap the driver in linux, and even now SI support is
labelled experimental.

Re: OpenBSD 7.3 can't boot after installed it says it misses some radeon firmware and the device is not configured

[Jonathan Gray]

On Sun, Jun 18, 2023 at 11:00:51PM +0300, chris greek wrote:
> The gpu card is a Radeon 7 240 with 2Gbytes of Ram.
> I would like to use amdgpu because its compatible and its faster with my
> gpu but i can't even boot.
>What should i select in the boot to disable radeon , maybe it misses
> some firmware i can find from linux ??

R7 240 is oland.  It will attach as radeondrm not amdgpu.

To disable radeondrm for a single boot from the boot prompt
you can run:

boot -c
disable radeondrm*
quit

> 
> Στις Κυρ 18 Ιουν 2023 στις 4:01 μ.μ., ο/η Jonathan Gray 
> έγραψε:
> 
> > On Sun, Jun 18, 2023 at 09:17:02AM +0300, chris greek wrote:
> > > OpenBSD 7.3 can't boot after installed it says it misses some radeon
> > > firmware and the device is not configured and the booting process
> > freezes.
> >
> > The installer downloads drm firmware if a mirror can be contacted.
> >
> > When rebooting after an install, if firmware is required, and it is not
> > found, the drm drivers detach.  On amd64, vga(4) or efifb(4) will then
> > claim the console.
> >
> > Do you see the same behaviour when using a snapshot?
> >
> > What is the last line show on screen?
> >
> > What model of computer and radeon is this?  It is unclear if you are
> > attempting to use radeondrm or amdgpu.
> >
> 

Re: OpenBSD 7.3 can't boot after installed it says it misses some radeon firmware and the device is not configured

[Jonathan Gray]

On Sun, Jun 18, 2023 at 09:17:02AM +0300, chris greek wrote:
> OpenBSD 7.3 can't boot after installed it says it misses some radeon
> firmware and the device is not configured and the booting process freezes.

The installer downloads drm firmware if a mirror can be contacted.

When rebooting after an install, if firmware is required, and it is not
found, the drm drivers detach.  On amd64, vga(4) or efifb(4) will then
claim the console.

Do you see the same behaviour when using a snapshot?

What is the last line show on screen?

What model of computer and radeon is this?  It is unclear if you are
attempting to use radeondrm or amdgpu.

Re: intel T14 gen 3, picom triggers page fault trap in dpt_insert_entries

[Jonathan Gray]

On Mon, Apr 24, 2023 at 01:49:32PM +0100, Stuart Henderson wrote:
> Running picom (with no special config or command line flags) on intel
> T14 gen 3 fairly easily triggers a crash in drm. If it doesn't fail the
> first time, exiting and restarting a few times pretty much always
> triggers it.
> 
> Full proc listing below after dmesg, Xorg is the only active process
> at the time.
> 
> xcompmgr hasn't yet triggered it.
> 
> 
> uvm_fault(0x824b4570, 0x81e73014, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped atdpt_insert_entries+0xbc:movl0x34(%r8),%r10d
> TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
>
> *459624  48440 350x12  04K Xorg   
> 
> dpt_insert_entries(81a1cc00,fd83b9afd178,0,0) at 
> dpt_insert_entries+0xbc

this is line 34 of /sys/dev/pci/drm/i915/i915_scatterlist.h

23  static __always_inline struct sgt_iter {
24  struct scatterlist *sgp;
25  union {
26  unsigned long pfn;
27  dma_addr_t dma;
28  };
29  unsigned int curr;
30  unsigned int max;
31  } __sgt_iter(struct scatterlist *sgl, bool dma) {
32  struct sgt_iter s = { .sgp = sgl };
33
34  if (dma && s.sgp && sg_dma_len(s.sgp) == 0) {
35  s.sgp = NULL;
36  } else if (s.sgp) {

sgl is pointing to something that isn't there?

I have an intel t14 gen 3 but can't reproduce this.
Running fvwm from xenocara and starting picom from xterm 20 times or so,
^C after each.

Looking over the local changes to i915_scatterlist.h the segment size
could be larger, I'm not sure if that would help.

Index: dev/pci/drm/i915/i915_scatterlist.h
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_scatterlist.h,v
retrieving revision 1.3
diff -u -p -r1.3 i915_scatterlist.h
--- dev/pci/drm/i915/i915_scatterlist.h 1 Jan 2023 01:34:54 -   1.3
+++ dev/pci/drm/i915/i915_scatterlist.h 24 Apr 2023 13:15:46 -
@@ -153,7 +153,7 @@ static inline unsigned int i915_sg_segme
 #else
 static inline unsigned int i915_sg_segment_size(struct device *dev)
 {
-   return PAGE_SIZE;
+   return round_down(UINT_MAX, PAGE_SIZE);
 }
 #endif
 

> dpt_bind_vma(81a1cc00,0,fd83b9afd178,0,400) at dpt_bind_vma+0x64
> i915_vma_bind(81ce4ec0,0,400,0,fd83b9afd178) at 
> i915_vma_bind+0x319
> i915_vma_pin_ww(81ce4ec0,800033b78db0,0,20,400) at 
> i915_vma_pin_ww+0x454
> intel_plane_pin_fb(81cc9000) at intel_plane_pin_fb+0x25c
> intel_prepare_plane_fb(814c7400,81cc9000) at 
> intel_prepare_plane_fb+0x127
> drm_atomic_helper_prepare_planes(8044c078,81cda000) at 
> drm_atomic_helper_prepare_planes+0x5b
> intel_atomic_commit(8044c078,81cda000,1) at 
> intel_atomic_commit+0xda
> drm_atomic_helper_page_flip(814c2800,81e41200,81d55300,1,800033b79048)
>  at drm_atomic_helper_page_flip+0x77
> drm_mode_page_flip_ioctl(8044c078,800033b793e0,8195bc00) 
> at drm_mode_page_flip_ioctl+0x466
> drm_do_ioctl(8044c078,100,c01864b0,800033b793e0) at 
> drm_do_ioctl+0x29e
> drmioctl(15700,c01864b0,800033b793e0,3,800033bba5c8) at drmioctl+0xdc
> VOP_IOCTL(fd845bb870f0,c01864b0,800033b793e0,3,fd845efad750,800033bba5c8)
>  at VOP_IOCTL+0x60
> vn_ioctl(fd845bd084c0,c01864b0,800033b793e0,800033bba5c8) at 
> vn_ioctl+0x79

Re: GPU acceleration (amdgpu) works with MBR install, but not with GPT install

[Jonathan Gray]

On Sun, Apr 02, 2023 at 11:01:08PM -0400, Thomas Frohwein wrote:
> >Synopsis:GPU acceleration (amdgpu) works with MBR install, but not with 
> >GPT install
> >Category:system
> >Environment:
>   System  : OpenBSD 7.3
>   Details : OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 
> 2023
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   I installed OpenBSD on a drive in GPT configuration and found out that 
> my Vega
> 64 GPU didn't run with acceleration. A look at `glxinfo -B` confirmed that
> llvmpipe was used. Another observation is a background with old(?) framebuffer
> content and colorful vertical stripes  in the background of the console after
> amdgpu is invoked.
> 
> It was more by accident that I had another install with MBR configuration on
> the same machine where I noticed no such issues. I reinstalled over the
> previous GPT install with MBR again and confirmed that this way, amdgpu is
> working as expected, including full GPU acceleration and with no vertical 
> stripe
> artifacts in the console anymore.
> 
> I installed again a third time, again with GPT in the installer, and this
> caused the artifacts in the console to appear again and the machine is back to
> using llvmpipe.
> 
> The association with a GPT install makes me think this problem might relate to
> what happens with efifb and how it transitions to amdgpu.
> 
> I'm attaching dmesg for both GPT and MBR configurations.
> 
> >How-To-Repeat:
>   
> 
> I have tried 2 different GPT installs that both led to this problem.
> >Fix:
>   Installing OpenBSD with MBR instead of GPT solves the issue and the
> GPU now works as expected.

Can you include pcidump -v output?

Also try this diff and report back on the values shown in dmesg

Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c,v
retrieving revision 1.9
diff -u -p -r1.9 amdgpu_gmc.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c 25 Jan 2023 02:44:50 -  
1.9
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c 3 Apr 2023 07:35:48 -
@@ -675,7 +675,7 @@ void amdgpu_gmc_get_vbios_allocations(st
 * size reported by the hardware is incorrect.
 */
extern psize_t efifb_stolen();
-   size = max(size, efifb_stolen());
+   printf("\nvbios %x efi %lx\n", size, efifb_stolen());
 #endif
 
if (adev->mman.keep_stolen_vga_memory)

Re: amdgpu doesn't start; [drm] failed to load ucode VCN0_RAM(0x3A)

[Jonathan Gray]

On Tue, Mar 14, 2023 at 10:23:15PM -0600, bent...@openbsd.org wrote:
> 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.

thanks for the report, committed

Re: amdgpu doesn't start; [drm] failed to load ucode VCN0_RAM(0x3A)

[Jonathan Gray]

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(&bios, 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(&bios, 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(&bios, 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(&bios, 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
+++ 

Re: amdgpu doesn't start; [drm] failed to load ucode VCN0_RAM(0x3A)

[Jonathan Gray]

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?

> 
> [drm] failed to load ucode VCN0_RAM(0x3A) [drm] psp gfx command 
> LOAD_IP_FW(0x6)
> failed and response status is (0x)
> [drm] *ERROR* ring vcn_dec_0 test failed (-60)
> [drm] *ERROR* hw_init of IP block  failed -60
> drm:pid0:amdgpu_device_init *ERROR* amdgpu_device_ip_init failed
> drm:pid0:amdgpu_attachhook *ERROR* Fatal error during GPU init
> efifb0 at mainbus0: 800x1280, 32bpp
> wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0
> wskbd1: connecting to wsdisplay0
> wskbd2: connecting to wsdisplay0
> wskbd3: connecting to wsdisplay0
> wsdisplay0: screen 1-5 added (std, vt100 emulation)
> [drm] Register(0) [mmUVD_POWER_STATUS] failed to reach value 0x0001 != 
> 0x000
> 2
> [drm] Register(0) [mmUVD_RBC_RB_RPTR] failed to reach value 0x0010 != 
> 0x
> 
> [drm] Register(0) [mmUVD_POWER_STATUS] failed to reach value 0x0001 != 
> 0x000
> 2
> 
> 
> dmesg/pcidump:
> 
> OpenBSD 7.3-beta (GENERIC.MP) #0: Sun Mar 12 06:44:43 MDT 2023
> pu...@framework.ajb.soy:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 15926702080 (15188MB)
> avail mem = 15424598016 (14710MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x796fc000 (53 entries)
> bios0: vendor Valve version "F7A0113" date 11/04/2022
> bios0: Valve Jupiter
> efi0 at bios0: UEFI 2.7
> efi0: Valve rev 0x10013
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP UEFI SSDT SSDT TPM2 ASF! BOOT HPET APIC MCFG SLIC 
> WDAT WDRT SSDT SSDT VFCT SSDT SSDT CRAT CDIT SSDT SSDT SSDT SSDT FPDT WSMT 
> SSDT SSDT BGRT
> acpi0: wakeup devices GPP0(S0) GPP1(S0) GPP2(S0) GPP3(S0) GPP4(S0) GPP5(S0) 
> GP17(S0) XHC0(S4) XHC1(S4) GP19(S0) XHC2(S4)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpihpet0 at acpi0: 14318180 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Custom APU 0405, 2800.01 MHz, 17-90-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,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,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
> 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu0: mwait min=64, max=64, C-substates=1.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Custom APU 0405, 2800.00 MHz, 17-90-02
> cpu1: 
> 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,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,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
> 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache
> cpu1: smt 1, core 0, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: AMD Custom APU 0405, 2800.00 MHz, 17-90-02
> cpu2: 
> 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,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,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 
> 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache
> cpu2: smt 0, core 1, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: AMD Custom APU 0405, 2800.00 MHz, 17-90-02
> cpu3: 
> 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,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,I

Re: Compulab Fitlet3 (Elkhart Lake - gen 11) Intel network hardware not configured

[Jonathan Gray]

On Sat, Feb 04, 2023 at 04:43:59PM -0700, David Rinehart wrote:
> >Synopsis:    Compulab Fitlet3 (Elkhart Lake - gen 11) Intel network
> hardware not configured
> >Category:    kernel
> >Environment:
>     System  : OpenBSD 7.2
>     Details : OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT
> 2022
>        
>  dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>     Architecture: OpenBSD.amd64
>     Machine : amd64
> >Description:
>     The network hardware on this machine reports not configured
> 
>     vendor "Intel", unknown product 0x4ba1 (class network subclass
> ethernet, rev 0x11) at pci0 dev 29 function 1 not configured
>     vendor "Intel", unknown product 0x4bb1 (class network subclass
> ethernet, rev 0x11) at pci0 dev 29 function 2 not configured

These are Synopsys based and not currently supported.

Elkhart Lake pci devices will be identified in future snapshots as I've
added them just now.

Re: blank screen after fresh installation of 7.2 in powerpc

[Jonathan Gray]

On Sun, Jan 08, 2023 at 07:01:54PM -0500, Nuno Vasconcellos wrote:
> >Synopsis:  blank screen after fresh installation 
> >Category:  powerpc   
> >Environment:
>   System  : OpenBSD 7.2
>   Details : OpenBSD 7.2-stable (GENERIC) #1: Sun Jan  8 16:55:44 EST 
> 2023
>
> va...@urca.my.domain:/usr/src/sys/arch/macppc/compile/GENERIC
> 
>   Architecture: OpenBSD.macppc
>   Machine : macppc
> >Description:
> After a fresh installation, the system booted with a blank screen.
> During the installation, it was noticed that fw_update installed 
> radeondrm.
> Applicable patches installed.
> Release notes checked.
> No newer release found.
> Changes made between OpenBSD versions checked.
> Another reboot and still blank screen.
> Remote access via ssh from another machine.
> Logs in dmesg.boot and /var/log/Xorg.o.log check.
> In dmesg.boot log the following line caught my attention:
> [drm] *ERROR* Unable to locate a BIOS ROM
> In /var/log/Xorg.O.log file, the following lines also caught my 
> attention: 
> [42.182] (EE) AIGLX error: dlopen of 
> /usr/X11R6/lib/modules/dri/r200_dri.so failed (File not found)
> [42.182] (EE) AIGLX error: unable to load driver r200
> The command ls -l /usr/X11R6/lib/modules/dri/ was run and provided 
> the following:
> total 128000
> -r--r--r--  4 root  bin  16549188 Sep 29 15:02 kms_swrast_dri.so
> -r--r--r--  4 root  bin  16549188 Sep 29 15:02 r300_dri.so
> -r--r--r--  4 root  bin  16549188 Sep 29 15:02 r600_dri.so
> -r--r--r--  4 root  bin  16549188 Sep 29 15:02 swrast_dri.so
> Video card is ATI Radeon 9200 identified with pci bus 0:16:0
> Machine is an Apple eMac PowerMac6,4
> >How-To-Repeat:
> Install using cd72.iso for macppc and following instructions at the 
> following link:
> https://ftp.openbsd.org/pub/OpenBSD/7.2/macppc/INSTALL.macppc
> >Fix:
> It seems that the fix is to provide the r200_dri.so file noted as not 
> found in Xorg.O.log (radeondrm needs to be reviewed and updated?)
> 

The Mesa "classic" drivers, including r200_dri.so were removed from
upstream Mesa.  Mesa falls back to software rendering.  The old paths
are tried as there is a messy way to build them out of another Mesa
tree.  OpenBSD does not include drivers from the amber tree of Mesa.

Does the console text show when the machine is booting?  Did you agree
to xenodm when installing?

> SENDBUG: dmesg, pcidump, acpidump and usbdevs are attached.
> SENDBUG: Feel free to delete or use the -D flag if they contain sensitive 
> information.
> 
> dmesg:
> OpenBSD 7.2-stable (GENERIC) #1: Sun Jan  8 16:55:44 EST 2023
> va...@urca.my.domain:/usr/src/sys/arch/macppc/compile/GENERIC
> real mem = 1073741824 (1024MB)
> avail mem = 1025462272 (977MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root: model PowerMac6,4
> cpu0 at mainbus0: 7447A (Revision 0x101): 1249 MHz: 512KB L2 cache
> mem0 at mainbus0
> spdmem0 at mem0: 512MB DDR SDRAM non-parity PC3200CL2.5
> spdmem1 at mem0: 512MB DDR SDRAM non-parity PC3200CL2.5
> memc0 at mainbus0: uni-n rev 0xd2
> "hw-clock" at memc0 not configured
> kiic0 at memc0 offset 0xf8001000
> iic0 at kiic0
> mpcpcibr0 at mainbus0 pci: uni-north
> pci0 at mpcpcibr0 bus 0
> pchb0 at pci0 dev 11 function 0 "Apple UniNorth AGP" rev 0x00
> agp at pchb0 not configured
> radeondrm0 at pci0 dev 16 function 0 "ATI Radeon 9200" rev 0x01
> drm0 at radeondrm0
> radeondrm0: irq 48
> mpcpcibr1 at mainbus0 pci: uni-north
> pci1 at mpcpcibr1 bus 0
> macobio0 at pci1 dev 23 function 0 "Apple Intrepid" rev 0x00
> openpic0 at macobio0 offset 0x4: version 0x4614 feature 3f0302 LE
> macgpio0 at macobio0 offset 0x50
> "modem-reset" at macgpio0 offset 0x1d not configured
> "modem-power" at macgpio0 offset 0x1c not configured
> macgpio1 at macgpio0 offset 0x9: irq 47
> "programmer-switch" at macgpio0 offset 0x11 not configured
> "fan" at macgpio0 offset 0x0 not configured
> "gpio0" at macgpio0 offset 0x6a not configured
> "gpio5" at macgpio0 offset 0x6f not configured
> "gpio6" at macgpio0 offset 0x70 not configured
> "extint-gpio4" at macgpio0 offset 0x5c not configured
> "gpio11" at macgpio0 offset 0x75 not configured
> "extint-gpio15" at macgpio0 offset 0x67 not configured
> "escc-legacy" at macobio0 offset 0x12000 not configured
> zs0 at macobio0 offset 0x13000: irq 22,23
> zstty0 at zs0 channel 0
> zstty1 at zs0 channel 1
> snapper0 at macobio0 offset 0x1: irq 30,1,2
> "timer" at macobio0 offset 0x15000 not configured
> adb0 at macobio0 offset 0x16000
> apm0 at adb0: battery flags 0x9, 0% charged
> piic0 at adb0
> iic1 at piic0
> "ivad-2" at iic1 addr 0x146 not configured
> "ivad-eeprom" at iic1 addr 0x153 not configured
> "ivad-pwm" at iic1 addr 0x14c not configured
> 

Re: Kernel process drmwq spikes CPU usage

[Jonathan Gray]

On Sat, Jan 07, 2023 at 09:46:17AM +, ba...@baak6.com wrote:
> >Synopsis:Kernel process drmwq spikes CPU usage every 20 seconds on
> Protectcli Vault-2 Port hardware.
> >Category:kernel
> >Environment:
> System  : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #4: Mon Dec 12 06:06:42 MST
> 2022
> 
> r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> I use this machine as a router. After upgrading to 7.2 I started
> getting pretty bad packet loss exactly every 20 seconds. After some
> investigation I noticed the drmwq kernel process using a lot of CPU every 20
> seconds. When I plug a screen into the HDMI port on the machine, it stops
> spiking the CPU and the problem goes away.
> >How-To-Repeat:
> Install OpenBSD 7.2 on a Protectcli Vault-2 port machine and observe
> kernel threads, the CPU will spike exactly every 20 seconds. This spike
> should cause packet loss that can be observed by running a ping.
> >Fix:
> Plug a screen into the HDMI port of the machine. The screen does not
> have to be turned on.
> 

Try this.  Diff against -current which has different drm code.
Check your dmesg for the message after it occurs.

Index: sys/dev/pci/drm/i915/display/intel_hotplug.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/display/intel_hotplug.c,v
retrieving revision 1.4
diff -u -p -r1.4 intel_hotplug.c
--- sys/dev/pci/drm/i915/display/intel_hotplug.c1 Jan 2023 01:34:56 
-   1.4
+++ sys/dev/pci/drm/i915/display/intel_hotplug.c9 Jan 2023 00:25:18 
-
@@ -194,7 +194,7 @@ intel_hpd_irq_storm_switch_to_polling(st
dev_priv->display.hotplug.stats[pin].state != 
HPD_MARK_DISABLED)
continue;
 
-   drm_info(&dev_priv->drm,
+   drm_warn(&dev_priv->drm,
 "HPD interrupt storm detected on connector %s: "
 "switching from hotplug detection to polling\n",
 connector->base.name);

Re: AMDGPU fails to initalize (Navi 21, 7.2)

[Jonathan Gray]

On Sat, Dec 10, 2022 at 09:55:54PM -0600, Isaac B Nudelman wrote:
> >> root on sd0a (b48c1009beaa6d30.a) swap on sd0b dump on sd0b
> >> hib block_io biowait error 22 blk 16815284 size 512
> 
> > This message is from hibernate code, was the machine previously
> > hibernated?
> 
> I don't use hibernate. I think I shutdown the system previously by holding
> the power button.
> 
> As far as applying the patch, I just pull the 7.2 kernel, patch, build, and
> reboot?

yes, along the lines of

cd /usr
cvs -q -d anoncvs.usa.openbsd.org:/cvs co -rOPENBSD_7_2 -P src/sys
cd /usr/src
patch -p0 < /path/to/diff
cd /sys/arch/amd64/compile/GENERIC.MP/
make obj && make config && make
doas make install
doas reboot

described more in
https://www.openbsd.org/stable.html
https://www.openbsd.org/anoncvs.html
release(8)

Re: AMDGPU fails to initalize (Navi 21, 7.2)

[Jonathan Gray]

On Sat, Dec 10, 2022 at 02:58:04AM -0600, Isaac Nudelman wrote:
> >Synopsis:AMDGPU fails to initialize on Navi 21
> >Category:system
> >Environment:
>   System  : OpenBSD 7.2
>   Details : OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 
> 2022
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   6900 XTXH is enumerated, but DRM fails to init it correctly. System 
> falls back to llvmpipe (which is not ideal). Card functions correctly under 
> Windows (there are some occasional graphics driver crashes there, but AMD / 
> Microsoft are to blame there) and under Linux (used 5.19 -> 6.0.12 and Mesa 
> git from a few days ago)

> root on sd0a (b48c1009beaa6d30.a) swap on sd0b dump on sd0b
> hib block_io biowait error 22 blk 16815284 size 512

This message is from hibernate code, was the machine previously hibernated?

> [drm] *ERROR* visible_vram_size 3ff00 or aper_base_kaddr 0x0 is not 
> initialized.
> [drm] *ERROR* Failed to process memory training!
> [drm] *ERROR* sw_init of IP block  failed -22
> drm:pid0:amdgpu_device_init *ERROR* amdgpu_device_ip_init failed
> drm:pid0:amdgpu_attachhook *ERROR* Fatal error during GPU init
> efifb0 at mainbus0: 2560x1440, 32bpp
> wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation), using wskbd0

The output of 'pcidump -v' would be helpful.

Try this.  Against -current, should apply to 7.2.

Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c
===
RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c,v
retrieving revision 1.6
diff -u -p -r1.6 amdgpu_gmc.c
--- sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c 29 Mar 2022 02:15:51 -  
1.6
+++ sys/dev/pci/drm/amd/amdgpu/amdgpu_gmc.c 11 Dec 2022 01:44:19 -
@@ -709,8 +709,10 @@ void amdgpu_gmc_get_vbios_allocations(st
 * XXX Workaround for machines where the framebuffer
 * size reported by the hardware is incorrect.
 */
-   extern psize_t efifb_stolen();
-   size = max(size, efifb_stolen());
+   if (adev->flags & AMD_IS_APU) {
+   extern psize_t efifb_stolen();
+   size = max(size, efifb_stolen());
+   }
 #endif
 
if (adev->mman.keep_stolen_vga_memory)

Re: The ddb that come up after a kernel panic won't respond to my USB keyboards

[Jonathan Gray]

On Sun, Nov 20, 2022 at 12:44:36AM -0300, Josmar Pierri wrote:
> Hi,
> 
> I discovered that neither of my keyboards are capable of sending
> keystrokes to ddb after a kernel panic.
> 
> Here is what I know so far:
> 
> 1 - It randomly happens under 7.2 on two different Dell R440 servers,
> and also happened the same way when they were running 7.1
> 
> 2 - It also happens on my old Dell desktop that now is running the
> latest 7.2 snapshot (GENERIC.MP#845 from today)
> 
> 3 - As said by man ddb, CTRL ALT ESC and CTRL ALT DEL should bring ddb
> up when machdep.kbdreset=2 and ddb.console=1 but, with my USB
> keyboards, nothing happens pressing them.
> 
> 4 - When I set ddb.trigger=1 the ddb appears as expected, however I
> can't type anything on it. No keys from my USB keyboards are accepted.
> 
> 5 - Unfortunately there is no PS/2 keyboard connector or serial port
> on any of these machines.
> 
> I'm stuck.
> Could someone please tell me what I'm missing?

Try machdep.forceukbd=1.  This sysctl exists on amd64 and i386 and
should let you use a USB keyboard with ddb.

Otherwise see crash(8).  With ddb.panic=0 the state can be saved to
disk without needing keyboard interaction, and can be examined later.

Re: HP ProBook 4530s laptop, kernel panic on suspend

[Jonathan Gray]

On Tue, Nov 08, 2022 at 11:44:06PM +0330, Ali Farzanrad wrote:
> >Synopsis:HP ProBook 4530s laptop, kernel panic on suspend
> >Category:kernel
> >Environment:
>   System  : OpenBSD 7.2
>   Details : OpenBSD 7.2 (GENERIC.MP) #0: Wed Oct 26 12:01:47 MDT 2022
>
> r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   I had an upgrade from (I think) OpenBSD 6.7 to 7.2 and then ran
>   sysmerge (to ignore my configs) and sysclean (with rm -rf) to
>   cleanup files.
>   I also did syspatch.
>   After upgrade whenever I try to suspend I receive kernel panic.
>   I don't remember if it did suspend correctly before, but I had a
>   different HP ProBook 4530s without radeon video graphics which
>   did suspend correctly.
>   Maybe it is related to radeondrm.
> >How-To-Repeat:
>   start apmd: rcctl -f start apmd
>   then zzz or ZZZ
> >Fix:
>   I have no idea.
>   When I did zzz, I received these kernel messages:
>   WARNING !list_empty(&lock->head) failed at 
> /usr/src/sys/dev/pcidrm/drm_modeset_lock.c:270
>   uvm_fault(0x823201f8, 0x20, 0, 1) -> e
>   kernel: page fault trap, code=0
>   Stopped at  mtx_enter_try+0x3e: movl0x8(%rdi),%edi
>   TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
>   *373147  24736  0 0x14000 0x42000K acpi0
>   mtx_enter_try(18) at mtx_enter_try+0x3e
>   mtx_enter(18) at mtx_enter+0x35
>   __ww_mutex_lock(18,80e96fc0,0,0) at __ww_mutex_lock+0x33
>   modeset_lock(18,80e96fc0,0,0) at modeset_lock+0x197
>   drm_modeset_lock_all_ctx(802a,80e96fc0) at 
> drm_modeset_lock_all_ctx+0x9c
>   drm_modeset_lock_all(802a) at drm_modeset_lock_all+0xc0
>   radeon_suspend_kms(802a,1,1,0) at radeon_suspend_kms+0x69
>   radeondrm_activate_kms(8029c000,2) at 
> radeondrm_activate_kms+0x53
>   config_activate_children(80132500,2) at 
> config_activate_children+0x85
>   config_activate_children(8029b000,2) at 
> config_activate_children+0x85
>   config_activate_children(80132300,2) at 
> config_activate_children+0x85
>   config_activate_children(8002f300,2) at 
> config_activate_children+0x85
>   config_suspend_all(2) at config_suspend_all+0x1aa
>   sleep_state(8002c400,1) at sleep_state+0xcf
>   end trace frame: 0x800022abb5f0, count: 0
>   https://www.openbsd.org/ddb.html describes the minimum info required in 
> bug
>   reports.  Insufficient info makes it difficult to find and fix bugs.
>   ddb{0}> bt
>   mtx_enter_try(18) at mtx_enter_try+0x3e
>   mtx_enter(18) at mtx_enter+0x35
>   __ww_mutex_lock(18,80e96fc0,0,0) at __ww_mutex_lock+0x33
>   modeset_lock(18,80e96fc0,0,0) at modeset_lock+0x197
>   drm_modeset_lock_all_ctx(802a,80e96fc0) at 
> drm_modeset_lock_all_ctx+0x9c
>   drm_modeset_lock_all(802a) at drm_modeset_lock_all+0xc0
>   radeon_suspend_kms(802a,1,1,0) at radeon_suspend_kms+0x69
>   radeondrm_activate_kms(8029c000,2) at 
> radeondrm_activate_kms+0x53
>   config_activate_children(80132500,2) at 
> config_activate_children+0x85
>   config_activate_children(8029b000,2) at 
> config_activate_children+0x85
>   config_activate_children(80132300,2) at 
> config_activate_children+0x85
>   config_activate_children(8002f300,2) at 
> config_activate_children+0x85
>   config_suspend_all(2) at config_suspend_all+0x1aa
>   sleep_state(8002c400,1) at sleep_state+0xcf
>   acpi_sleep_task(8002c400,1) at acpi_sleep_task+0x1d
>   acpi_thread(801288f0) at acpi_thread+0x1b8
>   end trace frame: 0x0, count: -16
>   ddb{0}>

Try the following patch.

You may also be able to switch this machine to only use the Radeon
in the bios settings.

Index: sys/dev/pci/drm/radeon/radeon_kms.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_kms.c,v
retrieving revision 1.90
diff -u -p -r1.90 radeon_kms.c
--- sys/dev/pci/drm/radeon/radeon_kms.c 15 Jul 2022 17:57:26 -  1.90
+++ sys/dev/pci/drm/radeon/radeon_kms.c 9 Nov 2022 02:24:00 -
@@ -874,7 +874,7 @@ radeondrm_activate_kms(struct device *se
struct radeon_device *rdev = (struct radeon_device *)self;
int rv = 0;
 
-   if (rdev->ddev == NULL)
+   if (rdev->ddev == NULL || radeon_fatal_error)
return (0);
 
switch (act) {

Re: ASIX AX88179: "axen0: invalid buffer(pkt#1), continue"

[Jonathan Gray]

On Sun, Oct 16, 2022 at 03:46:11AM -0600, Anthony J. Bentley wrote:
> On Valve's Steam Deck dock (https://www.steamdeck.com/en/dock), setting
> 'inet autoconf' in hostname.axen0 and running 'sh /etc/netstart axen0'
> (or equivalently, selecting axen0 during install) results in no response
> from the network, and this message in dmesg:
> 
> axen0: invalid buffer(pkt#1), continue
> 
> This continues to print in dmesg until the ethernet cable is unplugged.

some pcidevs changes unrelated to that issue
should make ccp(4) match

there are no docs for family 17h model 90h on
https://developer.amd.com/resources/developer-guides-manuals/
unsure what AMD 0x145a is

storage is from Longsys, FORESEE brand
controller seems to be from BayHub Technology, unclear which model

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2006
diff -u -p -r1.2006 pcidevs
--- pcidevs 3 Oct 2022 05:39:07 -   1.2006
+++ pcidevs 18 Oct 2022 03:34:22 -
@@ -834,6 +834,7 @@ product AMD 15_0X_DRAM  0x1602  15/0xh DR
 product AMD 15_0X_MISC 0x1603  15/0xh Misc Cfg
 product AMD 15_0X_CPU_PM   0x1604  15/0xh CPU Power
 product AMD 15_0X_HB   0x1605  15/0xh Host
+product AMD 17_90_XHCI_1   0x162c  17h/90h xHCI
 product AMD 17_6X_RC   0x1630  17h/6xh Root Complex
 product AMD 17_6X_IOMMU0x1631  17h/6xh IOMMU
 product AMD 17_6X_HB   0x1632  17h/6xh Host
@@ -841,6 +842,19 @@ product AMD 17_6X_PCIE_1   0x1633  17h/6xh 
 product AMD 17_6X_PCIE_2   0x1634  17h/6xh PCIE
 product AMD 17_6X_PCIE_3   0x1635  17h/6xh PCIE
 product AMD 17_6X_XHCI 0x1639  17h/6xh xHCI
+product AMD 17_90_XHCI_2   0x163b  17h/90h xHCI
+product AMD 17_90_HB   0x1645  17h/90h Host
+product AMD 17_90_PCIE_1   0x1647  17h/90h PCIE
+product AMD 17_90_PCIE_2   0x1648  17h/90h PCIE
+product AMD 17_90_CCP  0x1649  17h/90h Crypto
+product AMD 17_90_DF_0 0x1660  17h/90h Data Fabric
+product AMD 17_90_DF_1 0x1661  17h/90h Data Fabric
+product AMD 17_90_DF_2 0x1662  17h/90h Data Fabric
+product AMD 17_90_DF_3 0x1663  17h/90h Data Fabric
+product AMD 17_90_DF_4 0x1664  17h/90h Data Fabric
+product AMD 17_90_DF_5 0x1665  17h/90h Data Fabric
+product AMD 17_90_DF_6 0x1666  17h/90h Data Fabric
+product AMD 17_90_DF_7 0x1667  17h/90h Data Fabric
 product AMD 19_5X_DF_0 0x166a  19h/5xh Data Fabric
 product AMD 19_5X_DF_1 0x166b  19h/5xh Data Fabric
 product AMD 19_5X_DF_2 0x166c  19h/5xh Data Fabric
@@ -1221,6 +1235,7 @@ product ATI RENOIR0x1636  Renoir
 product ATI RENOIR_HDA 0x1637  Renoir HD Audio
 product ATI CEZANNE0x1638  Cezanne
 product ATI VANGOGH0x163f  Van Gogh
+product ATI VANGOGH_HDA0x1640  Van Gogh HD Audio
 product ATI LUCIENNE   0x164c  Lucienne
 product ATI YELLOW_CARP_1  0x164d  Yellow Carp
 product ATI RAPHAEL0x164e  Raphael
Index: ccp_pci.c
===
RCS file: /cvs/src/sys/dev/pci/ccp_pci.c,v
retrieving revision 1.6
diff -u -p -r1.6 ccp_pci.c
--- ccp_pci.c   11 Mar 2022 18:00:45 -  1.6
+++ ccp_pci.c   18 Oct 2022 03:01:07 -
@@ -48,6 +48,7 @@ static const struct pci_matchid ccp_pci_
{ PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_17_CCP_2 },
{ PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_17_1X_CCP },
{ PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_17_3X_CCP },
+   { PCI_VENDOR_AMD,   PCI_PRODUCT_AMD_17_90_CCP },
 };
 
 int

Re: page fault when booting with inteldrm

[Jonathan Gray]

On Sat, Oct 08, 2022 at 01:00:48AM +0100, Chris Narkiewicz wrote:
> I get occassional kernel panic when booting with intel drm.
> 
> Stacktrace screenshot and pcidump in the attachments.
> Dmesg from the crash. Last line is something I don't see with normal boot.

I don't understand why the suspend path is run.
Was the machine hibernated?

attempt to execute user address 0x0 in supervisor mode
intel_engines_reset_default_submission+0x3f
__intel_gt_unset_wedged+0x19d
intel_gt_unset_wedged+0x32
gt_sanitize+0x41
i915_gem_suspend_late+0x50
inteldrm_activate+0x1f8
config_activate_children+0x85
config_activate_children+0x85
config_suspend_all+0x1aa
sleep_state+0xcf
acpi_sleep_task+0x1d
acpi_thread+0x1b8

sys/dev/pci/drm/i915/gt/intel_engine_cs.c:1361

Re: amdgpu-firmware-20220913 page fault

[Jonathan Gray]

On Thu, Oct 06, 2022 at 11:21:04PM -0300, Claudio Correa wrote:
> 
> Hi,
> 
> the firmware amdgpu-firmware-20220913 results page fault
> on Dell Vostro 5471 with
> OpenBSD 7.2-current (GENERIC.MP) #767: Tue Oct  4 23:38:08 MDT 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> ddb{0}> machine ddbcpu 1
> freezes the prompt
> 
> regards

The topaz firmware has not changed since 2018
dd6f936 ("amdgpu: sync up topaz firmware with 18.10 release")
So it isn't related to the recent firmware changes.

Is this the first time you've installed OpenBSD on this machine?

topaz is different to most other parts in that it has no display
hardware.

trace is

amdgpu_bo_create+0xd7
amdgpu_bo_create_vm+0x38
amdgpu_vm_pt_create+0x1b7
amdgpu_vm_init+0x252
amdgpu_driver_open_kms+0xd3
drm_file_alloc+0x1c2
drmopen+0x11e

0x810d85a7 <+215>:   mov0x8(%rax),%rcx

sys/dev/pci/drm/include/drm/ttm/ttm_device.h:291

static inline struct ttm_resource_manager *
ttm_manager_type(struct ttm_device *bdev, int mem_type)
{
return bdev->man_drv[mem_type];
}

Re: time keeping on armv7

[Jonathan Gray]

On Tue, Sep 20, 2022 at 02:04:14PM +, Miod Vallat wrote:
> I recently installed OpenBSD to a PandaBoard (the original, not
> PandaBoard ES) and noticed that the clock was very quickly getting
> behind, with ntpd unable to cope.
> 
> The following extremely crude diff fixes it, but probably at the expense
> of breaking other omap systems. Is there a better way to figure out what
> is the real system clock frequency?

Cortex-A9 MPCore Technical Reference Manual
ARM DDI 0407I

"CLK
This is the main clock of the Cortex-A9 processor.
All Cortex-A9 processors in the Cortex-A9 MPCore processor and the SCU
are clocked with a distributed version of CLK.

PERIPHCLK
The Interrupt Controller, global timer, private timers, and watchdogs
are clocked with PERIPHCLK.
PERIPHCLK must be synchronous with CLK, and the PERIPHCLK clock
period, N, must be configured as a multiple of the CLK clock period.
This multiple N must be equal to, or greater than two."

OMAP4430 Multimedia Device Silicon Revision 2.x
Technical Reference Manual, Version AG
pg 1088:

 ref clock MPU_DPLL_CLKARM_FCLK
PRCM ->MPU DPLL>clock generator>Cortex-A9

So the device tree clock to use is mpu_periphclk?

Getting data from PRCM?

> 
> Index: sys/arch/armv7/omap/omapid.c
> ===
> RCS file: /OpenBSD/src/sys/arch/armv7/omap/omapid.c,v
> retrieving revision 1.5
> diff -u -p -u -p -r1.5 omapid.c
> --- sys/arch/armv7/omap/omapid.c  24 Oct 2021 17:52:27 -  1.5
> +++ sys/arch/armv7/omap/omapid.c  20 Sep 2022 13:54:01 -
> @@ -83,9 +83,12 @@ omapid_attach(struct device *parent, str
>   rev = bus_space_read_4(sc->sc_iot, sc->sc_ioh, O4_ID_CODE);
>   switch ((rev >> 12) & 0x) {
>   case 0xB852:
> - case 0xB95C:
>   board = "omap4430";
>   newclockrate = 400 * 1000 * 1000;
> + break;
> + case 0xB95C:
> + board = "omap4430";
> + newclockrate = 300 * 1000 * 1000;
>   break;
>   case 0xB94E:
>   board = "omap4460";
> 
> 
> 
> OpenBSD 7.2 (GENERIC) #11: Tue Sep 20 13:18:51 GMT 2022
> m...@enfer.gentiane.org:/usr/src/sys/arch/armv7/compile/GENERIC
> real mem  = 1021243392 (973MB)
> avail mem = 992374784 (946MB)
> random: boothowto does not indicate good seed
> mainbus0 at root: TI OMAP4 PandaBoard
> cpu0 at mainbus0 mpidr 0: ARM Cortex-A9 r1p2
> cpu0: 32KB 32b/line 4-way L1 VIPT I-cache, 32KB 32b/line 4-way L1 D-cache
> cortex0 at mainbus0
> amptimer0 at cortex0: 396000 kHz
> armliicc0 at cortex0: rtl 4 waymask: 0x000f
> omap0 at mainbus0
> omapid0 at omap0: omap4430
> amptimer0: adjusting clock: new rate 30 kHz
> prcm0 at omap0 rev 0.0
> ampintc0 at mainbus0 nirq 160, ncpu 2: "interrupt-controller"
> omwugen0 at mainbus0
> simplebus0 at mainbus0: "ocp"
> omsysc0 at simplebus0: "target-module"
> omsysc1 at simplebus0: "target-module"
> omsysc2 at simplebus0: "target-module"
> omsysc3 at simplebus0: "target-module"
> omsysc4 at simplebus0: "target-module"
> omsysc5 at simplebus0: "target-module"
> omsysc6 at simplebus0: "target-module"
> simplebus1 at simplebus0: "l4"
> simplebus2 at simplebus1: "cm1"
> omcm0 at simplebus2: "mpuss_cm"
> omclock0 at omcm0: "clk"
> omcm1 at simplebus2: "tesla_cm"
> omclock1 at omcm1: "clk"
> omcm2 at simplebus2: "abe_cm"
> omclock2 at omcm2: "clk"
> simplebus3 at simplebus1: "cm2"
> omcm3 at simplebus3: "l4_ao_cm"
> omclock3 at omcm3: "clk"
> omcm4 at simplebus3: "l3_1_cm"
> omclock4 at omcm4: "clk"
> omcm5 at simplebus3: "l3_2_cm"
> omclock5 at omcm5: "clk"
> omcm6 at simplebus3: "ducati_cm"
> omclock6 at omcm6: "clk"
> omcm7 at simplebus3: "l3_dma_cm"
> omclock7 at omcm7: "clk"
> omcm8 at simplebus3: "l3_emif_cm"
> omclock8 at omcm8: "clk"
> omcm9 at simplebus3: "d2d_cm"
> omclock9 at omcm9: "clk"
> omcm10 at simplebus3: "l4_cfg_cm"
> omclock10 at omcm10: "clk"
> omcm11 at simplebus3: "l3_instr_cm"
> omclock11 at omcm11: "clk"
> omcm12 at simplebus3: "ivahd_cm"
> omclock12 at omcm12: "clk"
> omcm13 at simplebus3: "iss_cm"
> omclock13 at omcm13: "clk"
> omcm14 at simplebus3: "l3_dss_cm"
> omclock14 at omcm14: "clk"
> omcm15 at simplebus3: "l3_gfx_cm"
> omclock15 at omcm15: "clk"
> omcm16 at simplebus3: "l3_init_cm"
> omclock16 at omcm16: "clk"
> omcm17 at simplebus3: "l4_per_cm"
> omclock17 at omcm17: "clk"
> simplebus4 at simplebus1: "scm"
> syscon0 at simplebus4: "scm_conf"
> simplebus5 at simplebus1: "scm"
> syscon1 at simplebus5: "omap4_padconf_global"
> pinctrl0 at simplebus5
> simplebus6 at simplebus1: "l4"
> "counter" at simplebus6 not configured
> "prm" at simplebus6 not configured
> "scrm" at simplebus6 not configured
> "scm" at simplebus6 not configured
> simplebus7 at simplebus6: "padconf"
> pinctrl1 at simplebus7
> "ocmcram" at simplebus0 not configured
> "dma-contr

Re: drm makes X crash (only with modesetting)

[Jonathan Gray]

On Sun, Sep 18, 2022 at 08:57:18PM +0200, Walter Alejandro Iglesias wrote:
> On Sep 18 2022, Walter Alejandro Iglesias wrote:
> > On Sep 18 2022, Walter Alejandro Iglesias wrote:
> > > On Sep 18 2022, Jonathan Gray wrote:
> > > > On Fri, Sep 16, 2022 at 10:19:15PM +1000, Jonathan Gray wrote:
> > > > > I'll see if I can reproduce this on another 965 machine.
> > > > 
> > > > I don't see any errors with fvwm2 on mobile 965 (x61).
> > > 
> > > I can not reproduce it in my thinkpad T410 either (same snapshot).
> > > 
> > > For me at least, it's curious that I can trigger the issue *only*
> > > brousing fvwm2 menus.  I don't know what fvwm2 does with its menus.
> > 
> > As it happened to me with other fvwm2 issue recently, today I noticed
> > that using fvwm2 default configuration I couldn't reproduce the bug.
> > 
> > This time it took me an hour to discover which setting made the
> > difference.  It came out that adding any of the following two options to
> > MenuStyle the bug is gone:
> > 
> >   MenuStyle * TrianglesSolid
> >   MenuStyle * TrianglesUseFore
> > 
> > Both disable the relief in menus arrows, so the relief shape is what
> > confuses drm, mesa or whatever is making X to crash.
> > 
> > That's mean that to reproduce the bug you have to remove the following
> 
> "That means", is what I meant. :-)
> 
> > line in the default fvwm2 config (line 275):
> > 
> >   MenuStyle * TrianglesSolid, TrianglesUseFore

that line does not appear in
/usr/X11R6/lib/X11/fvwm/.fvwmrc

is there another sample config?

Re: drm makes X crash (only with modesetting)

[Jonathan Gray]

On Fri, Sep 16, 2022 at 10:19:15PM +1000, Jonathan Gray wrote:
> I'll see if I can reproduce this on another 965 machine.

I don't see any errors with fvwm2 on mobile 965 (x61).
Can you include the full dmesg taken after the error occurs?
Do you have any settings in xorg.conf?

inteldrm0 at pci0 dev 2 function 0 "Intel GM965 Video" rev 0x0c
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xe000, size 0x1000
inteldrm0: apic 1 int 16, I965GM, gen 4

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel (0x8086)
Device: Mesa Intel(R) 965GM (CL) (0x2a02)
Version: 22.1.7
Accelerated: yes
Video memory: 192MB
Unified memory: yes
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) 965GM (CL)
OpenGL version string: 2.1 Mesa 22.1.7
OpenGL shading language version string: 1.20

OpenGL ES profile version string: OpenGL ES 2.0 Mesa 22.1.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

[   121.325] (II) modeset(0): [DRI2] Setup complete
[   121.325] (II) modeset(0): [DRI2]   DRI driver: crocus
[   121.325] (II) modeset(0): [DRI2]   VDPAU driver: va_gl

Re: drm makes X crash (only with modesetting)

[Jonathan Gray]

On Fri, Sep 16, 2022 at 01:55:13PM +0200, Walter Alejandro Iglesias wrote:
> Hello everone,
> 
> After upgrading to the latest snapshot I'm experiencing something
> similar to what's described here:

What snapshot were you running before?

> 
>   https://marc.info/?l=openbsd-bugs&m=166286641515911&w=2
> 
> I'm not sure if it's the same bug.  In my case Xorg crashes (trace
> below).

I don't think that is related.  Quite different hardware and a different
Mesa driver.

> 
> It happens with modesetting driver only, NOT with intel.
> 
> It happens using fvwm2 while browsing its menus.  Text desapears, the
> screen flashes a few times and eventually X crashes.
> 
> I've build a new kernel activating *all* the options in this patch
> but that did NOT solve the issue.
> 
>   https://marc.info/?l=openbsd-bugs&m=166286799416220&w=2

That is also unrelated.

> 
> 
> # egdb -ex bt -batch /usr/xobj/xserver/hw/xfree86/Xorg Xorg.core
> [New process 532797]
> [New process 424021]
> [New process 348856]
> Core was generated by `Xorg'.
> Program terminated with signal SIGABRT, Aborted.
> #0  thrkill () at /tmp/-:3
> [Current thread is 1 (process 532797)]
> #0  thrkill () at /tmp/-:3
> #1  0x0abab5e5b0fe in _libc_abort () at 
> /usr/src/lib/libc/stdlib/abort.c:51
> #2  0x0ab89683e00a in OsAbort ()
> #3  0x0ab896844e4e in AbortServer ()
> #4  0x0ab8968434eb in FatalError ()
> #5  0x0ab89683b684 in OsSigHandler ()
> #6  
> #7  thrkill () at /tmp/-:3
> #8  0x0abab5e5b0fe in _libc_abort () at 
> /usr/src/lib/libc/stdlib/abort.c:51
> #9  0x0abac74d84e8 in ?? () from /usr/X11R6/lib/modules/dri/crocus_dri.so
> #10 0x0abac74d5d30 in ?? () from /usr/X11R6/lib/modules/dri/crocus_dri.so
> #11 0x0abac6c10197 in ?? () from /usr/X11R6/lib/modules/dri/crocus_dri.so
> #12 0x0abb67a0d709 in _glamor_block_handler () from 
> /usr/X11R6/lib/modules/libglamoregl.so
> #13 0x0abb7863c24a in msBlockHandler () from 
> /usr/X11R6/lib/modules/drivers/modesetting_drv.so
> #14 0x0ab896694414 in BlockHandler ()
> #15 0x0ab896833b28 in WaitForSomething ()
> #16 0x0ab89668843c in Dispatch ()
> #17 0x0ab89669375c in dix_main ()
> #18 0x0ab89667a2d2 in _start ()
> 
> # dmesg | tail
> i915_vma_coredump_create: stub
> i915_vma_coredump_create: stub
> i915_vma_coredump_create: stub
> i915_vma_coredump_create: stub
> i915_vma_coredump_create: stub
> pool_fini: stub
> err_free_sgl: stub
> drm:pid77674:intel_gt_reset *NOTICE* [drm] Resetting chip for stopped 
> heartbeat on rcs0
> inteldrm0: no ifp
> drm:pid77674:mark_guilty *NOTICE* [drm] Xorg[27880] context reset due to GPU 
> hang

I'll see if I can reproduce this on another 965 machine.

> 
> 
> dmesg (generated by sendbug)
> 
> OpenBSD 7.2 (GENERIC.MP) #2: Fri Sep 16 12:36:28 CEST 2022
> morl...@chancha.roquesor.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4135260160 (3943MB)
> avail mem = 3992539136 (3807MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb920 (70 entries)
> bios0: vendor Hewlett-Packard version "786E1 v01.16" date 08/17/2011
> bios0: Hewlett-Packard HP Compaq dc7700 Convertible Minitower
> acpi0 at bios0: ACPI 1.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET
> acpi0: wakeup devices PCI0(S4) COM1(S4) PEG1(S4) IGBE(S4) PCX1(S4) PCX2(S4) 
> HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) EUS1(S3) EUS2(S3) 
> PBTN(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz, 1795.59 MHz, 06-0f-02
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 
> 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 199MHz
> cpu0: mwait min=64, max=64, C-substates=0.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz, 1795.51 MHz, 06-0f-02
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
> cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 
> 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf400, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG1)
> acpiprt2 at acpi0: bus 3

Re: re(4) drivers not working

[Jonathan Gray]

On Wed, Sep 14, 2022 at 10:23:32PM +0200, Adam Szewczyk wrote:
> After installation of OpenBSD as HVM on Qubes OS with passed through
> Realtek NIC driver starts to spamming with "re0: watchdog timeout" message
> and not working. Attaching dmesg.

Try without xen.  It may be messing up interrupts.

> 
> OpenBSD 7.1 (GENERIC.MP) #465: Mon Apr 11 18:03:57 MDT 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 1040183296 (991MB)
> avail mem = 991436800 (945MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfc10 (12 entries)
> bios0: vendor Xen version "4.14.5" date 08/24/2022
> bios0: Xen HVM domU
> acpi0 at bios0: ACPI 4.0
> acpi0: sleep states S3 S4 S5
> acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2593.27 MHz, 06-9e-0a
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2592.03 MHz, 06-9e-0a
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> acpihpet0 at acpi0: 6250 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpipci0 at acpi0 PCI0
> acpicmos0 at acpi0
> "ACPI0007" at acpi0 not configured
> "ACPI0007" at acpi0 not configured
> acpicpu0 at acpi0: C1(@1 halt!)
> acpicpu1 at acpi0: C1(@1 halt!)
> cpu0: using VERW MDS workaround (except on vmm entry)
> pvbus0 at mainbus0: Xen 4.14
> xen0 at pvbus0: features 0x2705, 2048 grant table frames, event channel 1
> xbf0 at xen0 backend 0 channel 6: disk
> scsibus1 at xbf0: 1 targets
> sd0 at scsibus1 targ 0 lun 0: 
> sd0: 10240MB, 512 bytes/sector, 20971520 sectors
> xbf1 at xen0 backend 0 channel 7: disk
> scsibus2 at xbf1: 1 targets
> sd1 at scsibus2 targ 0 lun 0: 
> sd1: 2048MB, 512 bytes/sector, 4194304 sectors
> xbf2 at xen0 backend 0 channel 8: disk
> scsibus3 at xbf2: 1 targets
> sd2 at scsibus3 targ 0 lun 0: 
> sd2: 10240MB, 512 bytes/sector, 20971520 sectors
> xnf0 at xen0 backend 113 channel 9: address 00:16:3e:5e:6c:00
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel
> 0 wired to compatibility, channel 1 wired to compatibility
> pciide0: channel 0 disabled (no drives)
> pciide0: channel 1 disabled (no drives)
> piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: SMBus
> disabled
> xspd0 at pci0 dev 2 function 0 "XenSource Platform Device" rev 0x01
> vga1 at pci0 dev 3 function 0 "Bochs VGA" rev 0x02
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> ehci0 at pci0 dev 4 function 0 "Intel 82801DB USB" rev 0x10: apic 1 int 35
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev
> 2.00/1.00 addr 1
> re0 at pci0 dev 6 function 0 "Realtek 8168" rev 0x15: RTL8168H/8111H
> (0x5400), msi, address 98:fa:9b:11:d0:cf
> rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
> isa0 at pcib0
> isadma0 at isa0
> fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
> pckbc0 at isa0 port 0x60/5 irq 1 irq 12
> pckbd0 at pckbc0 (kbd slot)
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pms0 at pckbc0 (aux slot)
> wsmouse0 at pms0 mux 0
> pcppi0 at isa0 port 0x61
> spkr0 at pcppi0
> uhidev0 at uhub0 port 1 configuration 1 interface 0 "QEMU QEMU USB Tablet"
> rev 2.00/0.00 addr 2
> uhidev0: iclass 3/0
> ums0 at uhidev0: 3 buttons, Z dir
> wsmouse1 at ums0 mux 0
> vscsi0 at root
> scsibus4 at vscsi0: 256 targets
> softraid0 at root
> scsibus5 at softraid0: 256 targets
> root on sd0a (e12f8a03b72580b6.

Re: i386 boot hangs: "init: can't open /dev/console: Device not configured"

[Jonathan Gray]

On Thu, Sep 01, 2022 at 04:26:18PM -0500, Scott Cheloha wrote:
> Hi,
> 
> mlarkin@ said someone needed to verify my i386/lapic.c changes on real
> hardware:
> 
> https://marc.info/?l=openbsd-tech&m=166186787532304&w=2
> 
> So, like a chucklehead, I thought "how hard could it be?" and tried
> installing OpenBSD/i386 to an external drive and booting my amd64
> laptop (Lenovo X1 Carbon 6th) from it.
> 
> The install -- booted from a USB-attached CD-ROM, installed to a USB-3
> external drive -- went fine.
> 
> When I tried to boot after installation, however, I hit a snag.
> init(8) hung the boot.  It kept printing:
> 
> init: can't open /dev/console: Device not configured
> init: can't open /dev/console: Device not configured
> init: can't open /dev/console: Device not configured
> 
> every fifteen or so seconds.  Keyboard was unresponsive.
> 
> A little searching led me to this reddit post from a few years ago:
> 
> https://reddit.com/r/openbsd/comments/8zganh/new_amd64_install_says_cant_open_devconsole/
> 
> A commenter on that post suggests that disabling 'inteldrm' and/or
> 'radeondrm' during boot from config(8) might do the trick.  It worked.
> With those drivers disabled, init(8) doesn't trip over /dev/console
> and the machine finishes booting, is stable, etc.  Obviously I don't
> have accelerated graphics, but the machine is otherwise perfectly
> usable from the console and vterms.
> 
> I have never seen this issue booting OpenBSD/amd64 on this (or any
> other) machine before.
> 
> I have attached both the amd64 dmesg and the i386 dmesg below.  Same
> machine, no changes to the BIOS between reboots.  They are booting
> from different disks: amd64 boots from the internal NVMe drive, i386
> boots from an external LaCiE drive over USB.
> 
> The issue persists on the i386 side even after installing all missing
> firmware.

The dmesg on i386 without inteldrm disabled likely has some hints
as to what is going on.

When the drm drivers fail to attach they try to detach and reprobe
vgafb/efifb.

Your amd64 dmesg is with efifb not vgafb.  You could try amd64
with csm/bios instead of efi to rule that out.

> 
> OpenBSD 7.2-beta (GENERIC.MP) #0: Tue Aug 30 20:15:55 CDT 2022
> s...@jetsam.attlocal.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 17018175488 (16229MB)
> avail mem = 16354238464 (15596MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xaa62d000 (63 entries)
> bios0: vendor LENOVO version "N23ET82W (1.57 )" date 07/21/2022
> bios0: LENOVO 20KHCTO1WW
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT 
> SSDT SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM 
> DMAR NHLT ASF! FPDT UEFI
> acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) 
> RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) 
> PXSX(S4) RP07(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 2399 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz, 1795.82 MHz, 06-8e-0a
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 
> 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 24MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz, 1795.82 MHz, 06-8e-0a
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 
> 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (applica

Re: Display regression - flickers with every mouse movement

[Jonathan Gray]

On Mon, Sep 12, 2022 at 01:54:11PM +0200, Matthias Schmidt wrote:
> Hi Jonathan,
> 
> * Jonathan Gray wrote:
> > 
> > Can you remove the lines added in the diff one at a time
> > to figure out which specific parameter is involved?
> 
> Result of commenting each of the following variables individually,
> building a new kernel and rebooting each time.
> 
> dev_priv->params.panel_use_ssc-> no flickering
> dev_priv->params.enable_dc-> no flickering
> dev_priv->params.enable_fbc   -> no flickering
> dev_priv->params.enable_psr   -> flickers
> dev_priv->params.disable_power_well -> no flickering
> dev_priv->params.enable_ips   -> no flickering
> 
> Then I built another kernel and commented all of the above expect
> for enable_psr.  This also leads to no flickering.
> 
> I didn't test all possible permutations :)  Is there anything else I
> should test?

thanks for testing all of these

I'll commit the following:

Index: sys/dev/pci/drm/i915/i915_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
retrieving revision 1.144
diff -u -p -r1.144 i915_drv.c
--- sys/dev/pci/drm/i915/i915_drv.c 8 Sep 2022 11:30:32 -   1.144
+++ sys/dev/pci/drm/i915/i915_drv.c 12 Sep 2022 12:01:54 -
@@ -2414,6 +2414,7 @@ inteldrm_attach(struct device *parent, s
i915_params_copy(&dev_priv->params, &i915_modparams);
dev_priv->params.enable_guc = 0;
dev_priv->params.request_timeout_ms = 0;
+   dev_priv->params.enable_psr = 0;
 
/* Setup the write-once "constant" device info */
device_info = mkwrite_device_info(dev_priv);

Re: Display regression - flickers with every mouse movement

[Jonathan Gray]

On Mon, Sep 12, 2022 at 09:40:59AM +0200, Matthias Schmidt wrote:
> Hi Jonathan,
> 
> * Jonathan Gray wrote:
> > On Mon, Sep 12, 2022 at 09:10:22AM +0200, Matthias Schmidt wrote:
> > > >Synopsis:Display flickers upon touchpad movement
> > > >Environment:
> > >   System  : OpenBSD 7.2
> > >   Details : OpenBSD 7.2 (GENERIC.MP) #720: Sun Sep 11 15:41:58 MDT 
> > > 2022
> > >
> > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > 
> > >   Architecture: OpenBSD.amd64
> > >   Machine : amd64
> > > >Description:
> > > 
> > > Hi,
> > > 
> > > I noticed a regression between 7.2-beta from Sept 6 and the current 
> > > snapshot.
> > > As soon as I move the mouse with the trackpad the screen flickers.  It 
> > > does not
> > > happen if I use the keyboard.  With all other snapshots before I never 
> > > had that
> > > issue.  I made a video for demonstration purposes:
> > > 
> > > https://xosc.org/misc/flickr.mp4
> > > 
> > > [ At first, I move the mouse, then type on the keyboard and the screen
> > > stops flickering, then switch to Firefox, move the mouse again and the
> > > screen again starts to flicker ]
> > > 
> > > Cheers
> > > 
> > >   Matthias
> > > 
> > > >How-To-Repeat:
> > > 
> > > Upgrade to latest snapshot on this type of machine.
> > > 
> > > >Fix:
> > > Dunno.
> > 
> > some defaults for power saving features recently changed
> > 
> > does this diff change what you see?
> 
> Indeed, this fixes the issue for me.  No more flickering here.
> 
> Cheers and thanks a lot for the fast response!
> 
>   Matthias

Can you remove the lines added in the diff one at a time
to figure out which specific parameter is involved?

descriptions from i915_params.c:

panel_use_ssc
"Use Spread Spectrum Clock with panels [LVDS/eDP] "

enable_dc
"Enable power-saving display C-states. "

enable_fbc
"Enable frame buffer compression for power savings "

enable_psr
"Enable PSR " (Panel Self Refresh)

disable_power_well
"Disable display power wells when possible "

enable_ips
"Enable IPS" (Intermediate Pixel Storage)

Re: Display regression - flickers with every mouse movement

[Jonathan Gray]

On Mon, Sep 12, 2022 at 09:10:22AM +0200, Matthias Schmidt wrote:
> >Synopsis:Display flickers upon touchpad movement
> >Environment:
>   System  : OpenBSD 7.2
>   Details : OpenBSD 7.2 (GENERIC.MP) #720: Sun Sep 11 15:41:58 MDT 
> 2022
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> 
> Hi,
> 
> I noticed a regression between 7.2-beta from Sept 6 and the current snapshot.
> As soon as I move the mouse with the trackpad the screen flickers.  It does 
> not
> happen if I use the keyboard.  With all other snapshots before I never had 
> that
> issue.  I made a video for demonstration purposes:
> 
> https://xosc.org/misc/flickr.mp4
> 
> [ At first, I move the mouse, then type on the keyboard and the screen
> stops flickering, then switch to Firefox, move the mouse again and the
> screen again starts to flicker ]
> 
> Cheers
> 
>   Matthias
> 
> >How-To-Repeat:
> 
> Upgrade to latest snapshot on this type of machine.
> 
> >Fix:
> Dunno.

some defaults for power saving features recently changed

does this diff change what you see?

Index: sys/dev/pci/drm/i915/i915_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
retrieving revision 1.144
diff -u -p -r1.144 i915_drv.c
--- sys/dev/pci/drm/i915/i915_drv.c 8 Sep 2022 11:30:32 -   1.144
+++ sys/dev/pci/drm/i915/i915_drv.c 11 Sep 2022 03:45:07 -
@@ -2415,6 +2415,13 @@ inteldrm_attach(struct device *parent, s
dev_priv->params.enable_guc = 0;
dev_priv->params.request_timeout_ms = 0;
 
+   dev_priv->params.panel_use_ssc = 0;
+   dev_priv->params.enable_dc = 0;
+   dev_priv->params.enable_fbc = 0;
+   dev_priv->params.enable_psr = 0;
+   dev_priv->params.disable_power_well = 0;
+   dev_priv->params.enable_ips = 0;
+
/* Setup the write-once "constant" device info */
device_info = mkwrite_device_info(dev_priv);
memcpy(device_info, info, sizeof(*device_info));

Re: X11 keeps reverting display to state from a few seconds ago

[Jonathan Gray]

On Sun, Sep 11, 2022 at 03:18:47AM +, James Cook wrote:
> >Synopsis:X11 keeps showing images from a few seconds ago
> >Category:kernel
> >Environment:
>   System  : OpenBSD 7.2
>   Details : OpenBSD 7.2-beta (GENERIC.MP) #718: Fri Sep  9 14:46:40 
> MDT 2022
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   After the latest sysupgrade -s, every few seconds, the contents of my
>   display briefly goes back to what it was a few seconds ago.

What were you running before this?

> 
>   For example, I have a clock on my screen. I'll watch the seconds tick:
>   :46
>   :47
>   :44
>   :48
>   ...
>   It appears other places too. E.g. as I type this (in nvim in xterm)
>   every once in a while the last few words I typed briefly disappear, and
>   then come back. The interruption lasts varying lengths of time, from a
>   small but noticable fraction of a second to maybe one second. How far
>   back in time it goes also varies too. I think I saw it go back more
>   than 20 seconds once.
> 
>   It doesn't seem to happen when I switch away from X11 to a virtual
>   console that's in text mode. I ran a "while true; sleep 1; date" loop
>   for a minute or two and didn't see any time travel.
> >How-To-Repeat:
>   In X11, observe anything on the screen that's changing.
> >Fix:
>   I haven't found a fix.

some defaults for power saving features recently changed

does this diff change what you see?

Index: sys/dev/pci/drm/i915/i915_drv.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
retrieving revision 1.144
diff -u -p -r1.144 i915_drv.c
--- sys/dev/pci/drm/i915/i915_drv.c 8 Sep 2022 11:30:32 -   1.144
+++ sys/dev/pci/drm/i915/i915_drv.c 11 Sep 2022 03:45:07 -
@@ -2415,6 +2415,13 @@ inteldrm_attach(struct device *parent, s
dev_priv->params.enable_guc = 0;
dev_priv->params.request_timeout_ms = 0;
 
+   dev_priv->params.panel_use_ssc = 0;
+   dev_priv->params.enable_dc = 0;
+   dev_priv->params.enable_fbc = 0;
+   dev_priv->params.enable_psr = 0;
+   dev_priv->params.disable_power_well = 0;
+   dev_priv->params.enable_ips = 0;
+
/* Setup the write-once "constant" device info */
device_info = mkwrite_device_info(dev_priv);
memcpy(device_info, info, sizeof(*device_info));

Re: No sound on Dell Latitude 3400

[Jonathan Gray]

On Wed, Aug 24, 2022 at 10:40:52AM +0300, fila...@infotec.ru wrote:
> >Synopsis:No sound with Intel 400 embeded card
> >Category:Hardware
> >Environment:
>   System  : OpenBSD 7.1
>   Details : OpenBSD 7.1 (GENERIC.MP) #3: Sun May 15 10:27:01 MDT 2022
>
> r...@syspatch-71-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   Hello. I have no sound on my Dell Latitude 3400.
> Audio card: Intel 400 Series HD Audio
> 
> mixerctl -v
> mixerctl: /dev/audioctl0: Device not configured
> 
> audioctl
> audioctl: /dev/audioctl0: Device not configured
> 
> cat > /dev/audio0 < /dev/zero &
> [1] 34556
> /bin/ksh: cannot create /dev/audio0: Device not configured
> 
> I started with OpenBSD 7.0. There were no sound too.
> Everything else seems to work fine.
> 
> Sincerely
> Kirill Filatov
> 
> P.S. Thank you very much for great software.
> It's a pleasure to work with such marvelous OS and other programs 
> from your team.
>   
> >How-To-Repeat:
>   
> >Fix:

>  0:31:3: Intel 400 Series HD Audio
>   0x: Vendor ID: 8086, Product ID: 02c8
>   0x0004: Command: , Status: 0010
>   0x0008: Class: 04 Multimedia, Subclass: 01 Audio,
>   Interface: 00, Revision: 00

this device is not subclass hd audio so needs to be added to
the match list

patch against -current

Index: sys/dev/pci/azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.274
diff -u -p -r1.274 azalia.c
--- sys/dev/pci/azalia.c21 Jun 2022 04:17:21 -  1.274
+++ sys/dev/pci/azalia.c24 Aug 2022 09:54:51 -
@@ -498,6 +498,7 @@ const struct pci_matchid azalia_pci_devi
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_CAVS },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_400SERIES_CAVS },
+   { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_400SERIES_LP_HDA },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_LP_HDA },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_HDA },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_JSL_HDA },

Re: EvolveIII laptop X quit working

[Jonathan Gray]

On Tue, Aug 09, 2022 at 10:29:41AM -0400, Nick Holland wrote:
> On 8/9/22 09:36, Jonathan Gray wrote:
> > On Sat, Aug 06, 2022 at 10:28:06AM -0400, Nick Holland wrote:
> > > > When looking at top what does Xorg have for WAIT?
> > > 
> > >   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU 
> > > COMMAND
> > > 41914 _x11 -22   -1   15M   26M idle  schto 0:01  0.00% Xorg
> > > 
> > > > this will run X with the older Mesa driver
> > > > MESA_LOADER_DRIVER_OVERRIDE=i965 startx
> > > > does that change anything?
> > > 
> > > Changes a little.
> > > X doesn't work, same WAIT, same blank screen.
> > > BUT... a "reboot" (via ssh) is actually successful(!).
> > 
> > Do you still see that when disabling acceleration?
> > 
> > before starting X create a /etc/X11/xorg.conf with:
> > 
> > Section "Device"
> > Identifier "Intel device"
> > Driver "modesetting"
> > Option "AccelMethod" "none"
> > EndSection
> 
> WORKS!
> 
> Also works running xenodm.  Probably not a surprise.

a long shot but does this change anything if you move away xorg.conf

errata described in
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-celeron-n-series-j-series-datasheet-spec-update.pdf

Index: sys/arch/amd64/amd64/cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.157
diff -u -p -r1.157 cpu.c
--- sys/arch/amd64/amd64/cpu.c  7 Aug 2022 23:56:06 -   1.157
+++ sys/arch/amd64/amd64/cpu.c  10 Aug 2022 04:04:14 -
@@ -465,6 +465,11 @@ cpu_init_mwait(struct cpu_softc *sc)
if ((cpu_ecxfeature & CPUIDECX_MWAIT) == 0 || cpuid_level < 0x5)
return;
 
+   /* APL30 A Store Instruction May Not Wake up MWAIT */
+   if (strcmp(cpu_vendor, "GenuineIntel") == 0 &&
+   curcpu()->ci_family == 6 && curcpu()->ci_model == 0x5c)
+   return;
+
/* get the monitor granularity */
CPUID(0x5, smallest, largest, extensions, cpu_mwait_states);
smallest &= 0x;

Re: EvolveIII laptop X quit working

[Jonathan Gray]

On Tue, Aug 09, 2022 at 10:29:41AM -0400, Nick Holland wrote:
> On 8/9/22 09:36, Jonathan Gray wrote:
> > On Sat, Aug 06, 2022 at 10:28:06AM -0400, Nick Holland wrote:
> > > > When looking at top what does Xorg have for WAIT?
> > > 
> > >   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU 
> > > COMMAND
> > > 41914 _x11 -22   -1   15M   26M idle  schto 0:01  0.00% Xorg
> > > 
> > > > this will run X with the older Mesa driver
> > > > MESA_LOADER_DRIVER_OVERRIDE=i965 startx
> > > > does that change anything?
> > > 
> > > Changes a little.
> > > X doesn't work, same WAIT, same blank screen.
> > > BUT... a "reboot" (via ssh) is actually successful(!).
> > 
> > Do you still see that when disabling acceleration?
> > 
> > before starting X create a /etc/X11/xorg.conf with:
> > 
> > Section "Device"
> > Identifier "Intel device"
> > Driver "modesetting"
> > Option "AccelMethod" "none"
> > EndSection
> 
> WORKS!
> 
> Also works running xenodm.  Probably not a surprise.
> 
> Well, the on-board trackpad doesn't work, but I'm pretty sure that
> is not a regression from 7.1  Don't think it worked properly then.
> 
> > xdriinfo will show swrast
> 
> yes
> 
> > glxinfo -B will show llvmpipe
> 
> Among other things, yes:
> name of display: :0
> display: :0  screen: 0
> direct rendering: Yes
> Extended renderer info (GLX_MESA_query_renderer):
> Vendor: Mesa/X.org (0x)
> Device: llvmpipe (LLVM 13.0.0, 128 bits) (0x)
> Version: 21.3.8
> Accelerated: no
> Video memory: 3894MB
> Unified memory: no
> Preferred profile: core (0x1)
> Max core profile version: 4.5
> Max compat profile version: 4.5
> Max GLES1 profile version: 1.1
> Max GLES[23] profile version: 3.2
> OpenGL vendor string: Mesa/X.org
> OpenGL renderer string: llvmpipe (LLVM 13.0.0, 128 bits)
> OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.3.8
> OpenGL core profile shading language version string: 4.50
> OpenGL core profile context flags: (none)
> OpenGL core profile profile mask: core profile
> 
> OpenGL version string: 4.5 (Compatibility Profile) Mesa 21.3.8
> OpenGL shading language version string: 4.50
> OpenGL context flags: (none)
> OpenGL profile mask: compatibility profile
> 
> OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.3.8
> OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
> 
> > 
> > > ugen1 at uhub0 port 7 "Realtek 802.11n WLAN Adapter" rev 2.00/2.00 addr 4
> > 
> > I'm curious why this doesn't match.  Can you show usbdevs output?
> 
> evolveiii# usbdevs -v
> Controller /dev/usb0:
> addr 01: 8086: Intel, xHCI root hub
>  super speed, self powered, config 1, rev 1.00
>  driver: uhub0
> addr 02: 07a6:0986 Admtek Inc., USB to 10/100TX
>  full speed, power 160 mA, config 1, rev 1.01, iSerial 0001
>  driver: aue0
> addr 03: 0bda:0129 Generic, USB2.0-CRW
>  high speed, power 500 mA, config 1, rev 39.60, iSerial 
> 2010020139600
>  driver: ugen0
> addr 04: 0bda:d723 Realtek, 802.11n WLAN Adapter
>  high speed, self powered, config 1, rev 2.00, iSerial 00e04c01
>  driver: ugen1
> addr 05: 058f:3822 Alcor Micro, USB 2.0 Camera
>  high speed, power 200 mA, config 1, rev 6.02
>  driver: uvideo0
> addr 06: 04b3:3100 IBM, product 0x3100
>  low speed, power 100 mA, config 1, rev 4.41
>  driver: uhidev0
> 
> (additional -v's didn't help with the realtek adapter)
> 
> don't tease me about getting the wireless working. :)

It appears to be RTL8723DU
https://www.realtek.com/en/products/communications-network-ics/item/rtl8723du

I gather this would need different firmware/driver to urtwn(4)

Re: EvolveIII laptop X quit working

[Jonathan Gray]

On Sat, Aug 06, 2022 at 10:28:06AM -0400, Nick Holland wrote:
> > When looking at top what does Xorg have for WAIT?
> 
>   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
> 41914 _x11 -22   -1   15M   26M idle  schto 0:01  0.00% Xorg
> 
> > this will run X with the older Mesa driver
> > MESA_LOADER_DRIVER_OVERRIDE=i965 startx
> > does that change anything?
> 
> Changes a little.
> X doesn't work, same WAIT, same blank screen.
> BUT... a "reboot" (via ssh) is actually successful(!).

Do you still see that when disabling acceleration?

before starting X create a /etc/X11/xorg.conf with:

Section "Device"
Identifier "Intel device"
Driver "modesetting"
Option "AccelMethod" "none"
EndSection

xdriinfo will show swrast
glxinfo -B will show llvmpipe

> ugen1 at uhub0 port 7 "Realtek 802.11n WLAN Adapter" rev 2.00/2.00 addr 4

I'm curious why this doesn't match.  Can you show usbdevs output?

Re: uvm_fault on Framework 12th Gen Intel

[Jonathan Gray]

On Tue, Aug 02, 2022 at 10:44:00AM +0100, Laurence Tratt wrote:
> I'm also starting to understand a bit more about some of the random panics:
> they seem to happen very soon after X starts. Sometimes the mouse appears as
> a two inch square of weird colours (!) -- things only last for a few seconds
> after that. Only once have I got a visible panic out of this which said
> solely:
> 
>   uvm_fault(0x822f0400, 0xfff80001660014, 0, 1) -> e
>   drm: Global state not read locked
>   drm: Global state not read locked
> 
> That particular panic was on my custom compiled kernel, not the most recent
> snapshot.

I don't see panics on a thinkpad with the same i7-1260P cpu

Does this change help?

drm/i915/adlp: Fix register corruption after DDI clock enabling

>From Imre Deak
59207e63801fbcd39ca68df6e2ba5ae90f76c0c3 in mainline linux

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=59207e63801fbcd39ca68df6e2ba5ae90f76c0c3

I also wonder if it is somehow possible the "XXX on T14 Gen 3 resume"
in sys/dev/pci/drm/i915/display/intel_bios.c intel_bios_is_port_edp()
may be involved, but that is a stretch.

Index: sys/dev/pci/drm/i915/i915_reg.h
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_reg.h,v
retrieving revision 1.29
diff -u -p -r1.29 i915_reg.h
--- sys/dev/pci/drm/i915/i915_reg.h 21 Jun 2022 09:46:33 -  1.29
+++ sys/dev/pci/drm/i915/i915_reg.h 2 Aug 2022 10:16:01 -
@@ -8308,6 +8308,7 @@ enum {
 #define   ICL_DELAY_PMRSP  REG_BIT(22)
 #define   DISABLE_FLR_SRC  REG_BIT(15)
 #define   MASK_WAKEMEM REG_BIT(13)
+#define   DDI_CLOCK_REG_ACCESS REG_BIT(7)
 
 #define GEN11_CHICKEN_DCPR_2   _MMIO(0x46434)
 #define   DCPR_MASK_MAXLATENCY_MEMUP_CLR   REG_BIT(27)
Index: sys/dev/pci/drm/i915/intel_pm.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/intel_pm.c,v
retrieving revision 1.63
diff -u -p -r1.63 intel_pm.c
--- sys/dev/pci/drm/i915/intel_pm.c 6 Jun 2022 07:10:15 -   1.63
+++ sys/dev/pci/drm/i915/intel_pm.c 2 Aug 2022 10:15:13 -
@@ -7606,6 +7606,9 @@ static void adlp_init_clock_gating(struc
 
/* Wa_22011091694:adlp */
intel_de_rmw(dev_priv, GEN9_CLKGATE_DIS_5, 0, DPCE_GATING_DIS);
+
+   /* Bspec/49189 Initialize Sequence */
+   intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, DDI_CLOCK_REG_ACCESS, 0);
 }
 
 static void dg1_init_clock_gating(struct drm_i915_private *dev_priv)

Re: uvm_fault on Framework 12th Gen Intel

[Jonathan Gray]

On Mon, Aug 01, 2022 at 11:28:08PM +0100, Laurence Tratt wrote:
> I've just got my sticky mits on a Framework 12th Gen Intel laptop. It
> somewhat works, but regularly hits kernel panics and other oddities on
> -current. I haven't worked out why yet, but uvm_faults seem to be frequent.
> For example setting the keyboard encoding causes a uvm_fault.
> 
>   $ doas wsconsctl keyboard.encoding=uk
>   uvm_fault(0xfd87b4e6a780, 0x8, 0, 1) -> e
> 
> Screenshot of this particular panic at https://postimg.cc/nM5rLGY6

wskbd_load_keymap+0x33: movl 0x8(%rax),%ecx
wskbd_displayioctl_sc+0x76c
wskbd_do_ioctl_sc+0xbb
wskbd_ioctl+0x4a
VOP_IOCTL+0x5c
vn_ioctl+0x75
sys_ioctl+0x2c4

   0x81017abe <+46>:je 0x81017b3e 

   0x81017ac0 <+48>:mov(%rdi),%rax
   0x81017ac3 <+51>:mov0x8(%rax),%ecx
   0x81017ac6 <+54>:xor%r13d,%r13d
   0x81017ac9 <+57>:mov$0x16,%r15d
   0x81017acf <+63>:test   %ecx,%ecx
   0x81017ad1 <+65>:jle0x81017bba 


info line *0x81017ac3
Line 405 of "/sys/dev/wscons/wskbdutil.c"
   starts at address 0x81017abe 
   and ends at 0x81017ad1 .

   395  int
   396  wskbd_load_keymap(const struct wskbd_mapdata *mapdata, kbd_t layout,
   397  struct wscons_keymap **map, int *maplen)
   398  {
   399  int i, s, kc, stack_ptr;
   400  const keysym_t *kp;
   401  const struct wscons_keydesc *mp, *stack[10];
   402  kbd_t cur;
   403  keysym_t ksg;
   404  
   405  for (cur = layout & ~KB_HANDLEDBYWSKBD, stack_ptr = 0;
   406   cur != 0; stack_ptr++) {
   407  mp = mapdata->keydesc;
   408  while (mp->map_size > 0) {
   409  if (cur == 0 || mp->name == cur) {
   410  break;
   411  }
   412  mp++;
   413  }
   414  
   415  if (stack_ptr == nitems(stack))
   416  panic("wskbd_load_keymap: %d: recursion too 
deep",
   417mapdata->layout);
   418  if (mp->map_size <= 0)
   419  return(EINVAL);
   420  
   421  stack[stack_ptr] = mp;
   422  cur = mp->base;
   423  }

> 
> I suspect that it's simply that some hardware isn't yet fully supported.
> There are a few more "not configured"s than normal in the dmesg and it even

should work

> contains this, which is a new one on me (presumably PCI related?):
> 
>   0:31:5: mem address conflict 0xfe01/0x1000
> 
> 
> Laurie
> 
> 
> OpenBSD 7.2-beta (GENERIC.MP) #658: Mon Aug  1 10:06:39 MDT 2022
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 34006142976 (32430MB)
> avail mem = 32958140416 (31431MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x3f085000 (54 entries)
> bios0: vendor INSYDE Corp. version "03.04" date 07/15/2022
> bios0: Framework Laptop (12th Gen Intel Core)
> acpi0 at bios0: ACPI 6.3
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT SSDT LPIT WSMT 
> SSDT SSDT DBGP DBG2 NHLT ECDT HPET APIC MCFG SSDT DMAR SSDT SSDT SSDT SSDT 
> FPDT ASF! PHAT BGRT
> acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEGP(S4) XHCI(S4) XDCI(S4) 
> HDAS(S4) CNVW(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) 
> RP04(S4) PXSX(S4) [...]
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpiec0 at acpi0
> acpihpet0 at acpi0: 1920 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: 12th Gen Intel(R) Core(TM) i7-1260P, 4689.83 MHz, 06-9a-03
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
> 10-way L2 cache, 18MB 64b/line 12-way L3 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 38MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.2.0.1.0.1, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: 12th Gen Intel(R) Core(TM) i7-1260P, 4689.82 MHz, 06-9a-03
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-C

Re: EvolveIII laptop X quit working

[Jonathan Gray]

On Tue, Jul 26, 2022 at 09:56:21AM -0400, Nick Holland wrote:
> On 7/26/22 8:43 AM, Jonathan Gray wrote:
> > On Mon, Jul 25, 2022 at 09:34:14PM +0100, Chris Narkiewicz wrote:
> > > On Mon, Jul 25, 2022 at 03:48:19PM -0400, Nick Holland wrote:
> > > > Sigh.  collect info, leave out most basic part: what I mean
> > > > by "X quit working"...
> > > 
> > > I checked your Xorg.0.log and it looks familiar. Please look for post
> > > "X11 hangs on StarLabs Mk IV - snapshot 06-06-2022" in the bugs@
> > > archive and recent discussion in t...@openbsd.org:
> > > "Xorg hanging on StarLabs Lite IV - infinite sleep in ioctl 
> > > drm_syncobj_array_wait_timeout"
> > 
> > this reminds me of Xorg being stuck on schto when running the intel xorg
> > driver on recent hardware
> > 
> > here is a diff which fixes some llist iterators, which makes the intel
> > xorg driver work on broadwell
> > 
> > does this also help these machines?
> 
> It doesn't seem to. Is there any more info I can give you to help?
> 
> Nick.

Is there anything in dmesg when this happens?
When looking at top what does Xorg have for WAIT?

this will run X with the older Mesa driver
MESA_LOADER_DRIVER_OVERRIDE=i965 startx
does that change anything?

Re: X vesa driver distorted display on startup

[Jonathan Gray]

On Tue, Jul 26, 2022 at 04:08:17AM +, Bill Chatfield wrote:
> You can consider this request canceled. I doubt it's going to get picked up 
> by anybody. I can understand that support for a 22 year old graphics card is 
> not a priority. But, I like OpenBSD so much I'm going to install it on a more 
> modern laptop. I find it to be better organized that Linux and friendlier 
> that other BSDs.

i810 is a special case.  Too old for inteldrm.  Not sure why it doesn't
work with vesa.  A PCI video card should be less trouble if you have one.

> 
> 
> 
>  On Monday, July 25, 2022, 03:51:14 AM EDT, Bill Chatfield 
>  wrote: 
> 
> >Synopsis:     >display on startup>
> >Category:    
> >Environment:
>     System  : OpenBSD 7.1
>     Details : OpenBSD 7.1 (GENERIC) #151: Mon Apr 11 18:57:52 MDT 2022
>              dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> 
>     Architecture: OpenBSD.i386
>     Machine : i386
> 
>