Re: uvm_fault on Framework 12th Gen Intel
On Sat, Aug 13, 2022 at 03:12:03PM +, Lucas Raab wrote: > Laurie and I have been exchanging notes about our respective > experiences. So far, my Framework 12th gen has been stable and > doesn't panic. > > Some notes: > * Using the default us encoding, I can swap between wsconsctl > keyboard.encoding values with no panics > * Setting /etc/kbdtype to us and swapping values with wsconsctl > doesn't cause panics > * kbd -l produces a list of encodings > * Laurie and I have identical BIOS versions and (seemingly) identical > hardware > > Happy to provide more info if needed > > Lucas > oh, I forgot to mention one bug we've both seen: the keyboard brightness function keys are unresponsive. Using xev, I can see that the F7/F8 keys are being registered, but when in function mode, their corresponding brightness keys are not. Same for F10/airplane mode. Interestingly, the other function keys like mute, volume adjustments, and media controls do.
Re: uvm_fault on Framework 12th Gen Intel
On Fri, Aug 12, 2022 at 06:07:28PM +0100, Laurence Tratt wrote: > On Wed, Aug 03, 2022 at 09:10:01AM +0100, Laurence Tratt wrote: > > [Framework laptop keyboard encoding crashing] > > I did a bit more digging and I've confused myself considerably, possibly > > because I don't know how wscons works. If I boot the machine without the > > external keyboard attached, stay in the console (i.e. outside X), and then > > plug in the external keyboard causes the laptop keyboard behaves bizarrely: > > for example "1" and "a" are inverted (i.e. I press "1" and "a" is > > displayed). After I unplug the external keyboard, I seem to get a new (more > > bizarre) map in the console where "a" is some sort of control code. > > I've been poking around a bit more trying to understand what's going on, and > I have some more information -- but nothing that I'd say is exactly > definitive. > > Although I didn't realise it (since it was the first thing I did in the > installer) /etc/kbdtype is set: > > $ cat /etc/kbdtype > uk > > And indeed, the first thing after the kernel boots and userland starts doing > its thing says: > > kbd: keyboard mapping set to uk > > Provided I don't have an external keyboard plugged in, then on the console > the laptop keyboard really does reflect the UK layout (including things like > the £ key), but X does not reflect that. However if I later try to set uk > encoding with kbd (as /etc/rc does with /etc/kbdtype) it doesn't work: > > $ doas kbd uk > kbd: WSKBDIO_SETENCODING /dev/wskbd0: Bad address > > I'm unsure how the call to kbd from /etc/rc can work but not subsequently if > I issue it manually. > > The final piece of information I've dug out is that (even with Miod's > patch), kbd -l causes a uvm_fault panic in wskbd_displayioctl_sc. I think > this is just the same underlying bug manifesting in a different way > > > Laurie > Laurie and I have been exchanging notes about our respective experiences. So far, my Framework 12th gen has been stable and doesn't panic. Some notes: * Using the default us encoding, I can swap between wsconsctl keyboard.encoding values with no panics * Setting /etc/kbdtype to us and swapping values with wsconsctl doesn't cause panics * kbd -l produces a list of encodings * Laurie and I have identical BIOS versions and (seemingly) identical hardware Happy to provide more info if needed Lucas
Re: uvm_fault on Framework 12th Gen Intel
On Wed, Aug 03, 2022 at 09:10:01AM +0100, Laurence Tratt wrote: [Framework laptop keyboard encoding crashing] > I did a bit more digging and I've confused myself considerably, possibly > because I don't know how wscons works. If I boot the machine without the > external keyboard attached, stay in the console (i.e. outside X), and then > plug in the external keyboard causes the laptop keyboard behaves bizarrely: > for example "1" and "a" are inverted (i.e. I press "1" and "a" is > displayed). After I unplug the external keyboard, I seem to get a new (more > bizarre) map in the console where "a" is some sort of control code. I've been poking around a bit more trying to understand what's going on, and I have some more information -- but nothing that I'd say is exactly definitive. Although I didn't realise it (since it was the first thing I did in the installer) /etc/kbdtype is set: $ cat /etc/kbdtype uk And indeed, the first thing after the kernel boots and userland starts doing its thing says: kbd: keyboard mapping set to uk Provided I don't have an external keyboard plugged in, then on the console the laptop keyboard really does reflect the UK layout (including things like the £ key), but X does not reflect that. However if I later try to set uk encoding with kbd (as /etc/rc does with /etc/kbdtype) it doesn't work: $ doas kbd uk kbd: WSKBDIO_SETENCODING /dev/wskbd0: Bad address I'm unsure how the call to kbd from /etc/rc can work but not subsequently if I issue it manually. The final piece of information I've dug out is that (even with Miod's patch), kbd -l causes a uvm_fault panic in wskbd_displayioctl_sc. I think this is just the same underlying bug manifesting in a different way Laurie
Re: uvm_fault on Framework 12th Gen Intel
On Wed, Aug 03, 2022 at 07:17:27AM +0200, Anton Lindqvist wrote: Hello Anton, >> `disable ucc` has no effect (it doesn't attach normally, so I guess that's >> not surprising?) -- I still get a kernel panic. > ucc does attach according to your dmesg. However, while ucc attaches it > sets it's own layout to `KB_US | KB_NOENCODING', meaning that > wskbd_load_keymap() requests are ignored since only one map is provided. OK, this one baffled me for a while! You're quite right, in the very first dmesg I got (which is the one I sent in my first email): ucc0 at uhidev1 reportid 1: 4 usages, 3 keys, enum wskbd1 at ucc0 mux 1 but I have a record of several subsequent dmesg's and not one of them contains ucc -- even if I boot with the same snapshot kernel (#658). It turns out that's because my first dmesg was recorded while attached to an external keyboard (via a hub) and all the subsequent ones without an external keyboard. Here's wsconsctl if I boot without the external keyboard attached: $ doas wsconsctl | grep "^keyboard" wsconsctl: Use explicit arg to view keyboard.map. keyboard.type=pc-xt keyboard.bell.pitch=400 keyboard.bell.period=100 keyboard.bell.volume=50 keyboard.bell.pitch.default=400 keyboard.bell.period.default=100 keyboard.bell.volume.default=50 keyboard.repeat.del1=400 keyboard.repeat.deln=100 keyboard.repeat.del1.default=400 keyboard.repeat.deln.default=100 keyboard.ledstate=0 keyboard.encoding=unknown_0 And when I attach the external keyboard this becomes: $ doas wsconsctl | grep "^keyboard" keyboard.type=pc-xt keyboard.bell.pitch=400 keyboard.bell.period=100 keyboard.bell.volume=50 keyboard.bell.pitch.default=400 keyboard.bell.period.default=100 keyboard.bell.volume.default=50 keyboard.repeat.del1=400 keyboard.repeat.deln=100 keyboard.repeat.del1.default=400 keyboard.repeat.deln.default=100 keyboard.ledstate=0 keyboard.encoding=uk keyboard1.type=usb keyboard1.bell.pitch=400 keyboard1.bell.period=100 keyboard1.bell.volume=50 keyboard1.bell.pitch.default=400 keyboard1.bell.period.default=100 keyboard1.bell.volume.default=50 keyboard1.repeat.del1=400 keyboard1.repeat.deln=100 keyboard1.repeat.del1.default=400 keyboard1.repeat.deln.default=100 keyboard1.ledstate=0 keyboard1.encoding=uk keyboard2.type=usb keyboard2.bell.pitch=400 keyboard2.bell.period=100 keyboard2.bell.volume=50 keyboard2.bell.pitch.default=400 keyboard2.bell.period.default=100 keyboard2.bell.volume.default=50 keyboard2.repeat.del1=400 keyboard2.repeat.deln=100 keyboard2.repeat.del1.default=400 keyboard2.repeat.deln.default=100 keyboard2.ledstate=0 keyboard2.encoding=us.noencoding keyboard3.type=usb keyboard3.bell.pitch=400 keyboard3.bell.period=100 keyboard3.bell.volume=50 keyboard3.bell.pitch.default=400 keyboard3.bell.period.default=100 keyboard3.bell.volume.default=50 keyboard3.repeat.del1=400 keyboard3.repeat.deln=100 keyboard3.repeat.del1.default=400 keyboard3.repeat.deln.default=100 keyboard3.ledstate=0 keyboard3.encoding=uk Note that after the external keyboard attaches keyboard.encoding has changed from unknown_0 to uk; if I unplug the external keyboard the encoding goes back to unknown_0. I did a bit more digging and I've confused myself considerably, possibly because I don't know how wscons works. If I boot the machine without the external keyboard attached, stay in the console (i.e. outside X), and then plug in the external keyboard causes the laptop keyboard behaves bizarrely: for example "1" and "a" are inverted (i.e. I press "1" and "a" is displayed). After I unplug the external keyboard, I seem to get a new (more bizarre) map in the console where "a" is some sort of control code. I eventually managed to trigger a panic in wskbd_translate by doing this: https://postimg.cc/JtrN1GWy Note this happened with the stock #658 kernel (i.e. without Miod's patch). I suppose this isn't a very interesting panic in the sense that something has gone wrong quite before this panic occurred, but still, it might be useful info for someone! Laurie
Re: uvm_fault on Framework 12th Gen Intel
On Tue, Aug 02, 2022 at 10:35:18PM +0100, Laurence Tratt wrote: > On Tue, Aug 02, 2022 at 07:00:52PM +, Miod Vallat wrote: > > Hello Miod, > > > Do the uvm_fault errors disappear if you `boot -c' and `disable ucc'? > > `disable ucc` has no effect (it doesn't attach normally, so I guess that's > not surprising?) -- I still get a kernel panic. ucc does attach according to your dmesg. However, while ucc attaches it sets it's own layout to `KB_US | KB_NOENCODING', meaning that wskbd_load_keymap() requests are ignored since only one map is provided.
Re: uvm_fault on Framework 12th Gen Intel
On Tue, Aug 02, 2022 at 07:00:52PM +, Miod Vallat wrote: Hello Miod, > Do the uvm_fault errors disappear if you `boot -c' and `disable ucc'? `disable ucc` has no effect (it doesn't attach normally, so I guess that's not surprising?) -- I still get a kernel panic. > Or if you `disable pckbd'? `disable pckbd` causes lines in dmesg like: pms1: disable error ... pckbc: command timeout pms1: disable error and so on. The keyboard is non-operational at that point and, since I (temporarily at least) don't have another machine, I don't have any way of executing wsconsctl to see if it panics. I can try tomorrow if it would be helpful? The patch you provided works (thanks!): $ doas wsconsctl keyboard.encoding keyboard.encoding=unknown_0 $ doas wsconsctl keyboard.encoding=uk wsconsctl: WSKBDIO_SETENCODING: Bad address $ doas wsconsctl keyboard.encoding=gb wsconsctl: gb: not a valid encoding I realise as I type the above that I've never had a need to configure a keyboard encoding before. I guess the "unknown_0" is unexpected? It may also be significant that "uk" (which I *guess* is the keyboard's encoding) borks in a different way than "gb"? Laurie
Re: uvm_fault on Framework 12th Gen Intel
On Tue, Aug 02, 2022 at 08:56:09PM +1000, Jonathan Gray wrote: Hello Jonathan, >> 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 A kernel with this patch has now survived 10 reboots (previously I was getting a panic perhaps 1 time in 3), so I think it's quite likely that the effect is real. Thanks! Laurie
Re: uvm_fault on Framework 12th Gen Intel
The following diff ought to fix the problem, although there is no reason
it should have occurred in the first place.
Do the uvm_fault errors disappear if you `boot -c' and `disable ucc'? Or
if you `disable pckbd'?
Index: wskbdutil.c
===
RCS file: /OpenBSD/src/sys/dev/wscons/wskbdutil.c,v
retrieving revision 1.19
diff -u -p -r1.19 wskbdutil.c
--- wskbdutil.c 30 Dec 2021 06:55:11 - 1.19
+++ wskbdutil.c 2 Aug 2022 19:00:40 -
@@ -405,6 +405,8 @@ wskbd_load_keymap(const struct wskbd_map
for (cur = layout & ~KB_HANDLEDBYWSKBD, stack_ptr = 0;
cur != 0; stack_ptr++) {
mp = mapdata->keydesc;
+ if (mp == NULL)
+ return(EFAULT); /* XXX */
while (mp->map_size > 0) {
if (cur == 0 || mp->name == cur) {
break;
Re: uvm_fault on Framework 12th Gen Intel
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
On Tue, Aug 02, 2022 at 11:54:48AM +1000, Jonathan Gray wrote:
Hello Jonathan,
>> 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 }
Thanks for expanding this (and duly noted!).
I also noted your commit to add some devices. The salient part of the dmesg
diff (ignoring all the CPU frequencies changing) is:
--- dmesg1Tue Aug 2 10:26:22 2022
+++ dmesg2Tue Aug 2 10:34:02 2022
@@ -1,7 +1,7 @@
-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
+OpenBSD 7.2-beta (GENERIC.MP) #0: Tue Aug 2 10:16:12 BST 2022
+ltr...@phase.tratt.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34006142976 (32430MB)
-avail mem = 32958144512 (31431MB)
+avail mem = 32958132224 (31431MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
@@ -251,18 +251,18 @@
"Intel Core 12G DTT" rev 0x02 at pci0 dev 4 function 0 not configured
ppb0 at pci0 dev 6 function 0 "Intel Core 12G PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
-nvme0 at pci1 dev 0 function 0 vendor "SanDisk", unknown product 0x5011 rev
0x01: msix, NVMe 1.4
+nvme0 at pci1 dev 0 function 0 "SanDisk SN850" rev 0x01: msix, NVMe 1.4
nvme0: WDS100T1X0E-00AFY0, firmware 614900WD, serial XYZ
scsibus1 at nvme0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0:
sd0: 953869MB, 512 bytes/sector, 1953525168 sectors
ppb1 at pci0 dev 7 function 0 "Intel Core 12G PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
-ppb2 at pci0 dev 7 function 1 vendor "Intel", unknown product 0x463f rev
0x02: msi
+ppb2 at pci0 dev 7 function 1 "Intel Core 12G PCIE" rev 0x02: msi
pci3 at ppb2 bus 43
ppb3 at pci0 dev 7 function 2 "Intel Core 12G PCIE" rev 0x02: msi
pci4 at ppb3 bus 84
-ppb4 at pci0 dev 7 function 3 vendor "Intel", unknown product 0x461f rev
0x02: msi
+ppb4 at pci0 dev 7 function 3 "Intel Core 12G PCIE" rev 0x02: msi
pci5 at ppb4 bus 125
"Intel Core 12G GNA" rev 0x02 at pci0 dev 8 function 0 not configured
"Intel Core 12G CL" rev 0x01 at pci0 dev 10 function 0 not configured
@@ -288,7 +288,7 @@
iic2 at dwiic2
ihidev1 at iic2 addr 0x2c gpio 3, vendor 0x93a product 0x274, PIXA3854
ihidev1: 67 report ids
-imt0 at ihidev1: clickpad, 5 contacts
+imt0 at ihidev1: touchpad, 5 contacts
wsmouse0 at imt0 mux 0
ims0 at ihidev1 reportid 2: 2 buttons
wsmouse1 at ims0 mux 0
@@ -300,8 +300,9 @@
hid at ihidev1 reportid 66 not configured
hid at ihidev1 reportid 67 not configured
"Intel 600 Series HECI" rev
Re: uvm_fault on Framework 12th Gen Intel
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:
>
