Re: AMD Ryzen based Asus ZENBOOK 14 UM433DA-PURE4 14" panic at first boot post install - how to debug further

[Jonathan Gray]

On Thu, Apr 29, 2021 at 10:27:49PM +0200, Peter Nicolai Mathias Hansteen wrote:
> I just spent the evening trying to work around an odd error that happens 
> after an apparently straightforward install on a new laptop.
> 
> The most useful info I can offer is that the install proceeds with no 
> complaints, but on first boot this happens:
> 
> 
> 
> 
> Followed by
> 
> 
> 
> This is a modern laptop so things such as serial consoles are not easily 
> available.
> 
> How do I go about supplying useful information here? I tried but failed to 
> collect useful things such as dmesg (trying to write to the install USB only 
> corrupts and so forth).
> 
> The store’s return policy is friendly enough that I can have this one lying 
> around at least a few days (actually 60 but I suspect the lady of the house 
> will not be quite as accommodating)
> 
> All the best,
> Peter
> 
> PS in case the attachments do not survive the pics are also up at 
> https://www.bsdly.net/~peter/20210429_190606.jpg 
>  and 
> https://www.bsdly.net/~peter/20210429_190645.jpg 
> 
> 

acpicpu0 at acpi0kernel: integer divide fault trap, code=0
Stopped at acpi_gasio+0x36: idivl %r8d,%eax
acpi_gasio(x,1,0,0.0.0) at acpi_gasio+0x36
acpi_write_pmreg(x,2,0,3,x,3) at acpi_write_pmreg+0xba
acpi_write_pmreg(x,10,0,3,x,x) at acpi_write_pmreg+0x18f
acpicpu_attach(...) at acpicpu_attach+0x1c3

acpi_gasio+0x36 is /usr/src/sys/dev/acpi/acpi.c line 265

acpi_gasio(struct acpi_softc *sc, int iodir, int iospace, uint64_t address,
int access_size, int len, void *buffer)
..
KASSERT((len % access_size) == 0);

acpi_write_pmreg+0xba is /usr/src/sys/dev/acpi/acpi.c line 1541

/*
 * For Hardware-reduced ACPI we also emulate PM1A_CNT using
 * SLEEP_CONTROL_REG.
 */
if (sc->sc_hw_reduced && reg == ACPIREG_PM1A_CNT) {
uint8_t value = (regval >> 8);

KASSERT(offset == 0);
acpi_gasio(sc, ACPI_IOWRITE,
sc->sc_fadt->sleep_control_reg.address_space_id,
sc->sc_fadt->sleep_control_reg.address,
sc->sc_fadt->sleep_control_reg.register_bit_width / 8,
sc->sc_fadt->sleep_control_reg.access_size, );
return;
}

If you can build a kernel on another machine try

Index: sys/dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.397
diff -u -p -r1.397 acpi.c
--- sys/dev/acpi/acpi.c 15 Mar 2021 22:44:57 -  1.397
+++ sys/dev/acpi/acpi.c 30 Apr 2021 01:57:00 -
@@ -262,6 +262,11 @@ acpi_gasio(struct acpi_softc *sc, int io
dnprintf(50, "gasio: %.2x 0x%.8llx %s\n",
iospace, address, (iodir == ACPI_IOWRITE) ? "write" : "read");
 
+   if (access_size == 0) {
+   printf("%s: invalid size 0\n", DEVNAME(sc));
+   return -1;
+   }
+
KASSERT((len % access_size) == 0);
 
pb = (uint8_t *)buffer;

Re: Heat problems probably caused by CPU Clocks

[jpeg bild]

Silly question, but after turning apmd on did you try doing "apm -L"?

Re: i386 pagedaemon panic pg->wire_count == 0

[Stuart Henderson]

On 2021/04/29 16:59, Alexander Bluhm wrote:
> On Thu, Apr 29, 2021 at 04:17:05PM +0200, Martin Pieuchot wrote:
> > On 29/04/21(Thu) 12:07, Alexander Bluhm wrote:
> > > On Thu, Apr 29, 2021 at 11:08:30AM +0200, Mark Kettenis wrote:
> > > > > > panic: kernel diagnostic assertion "pg->wire_count == 0" failed: 
> > > > > > file "/usr/src/sys/uvm/uvm_page.c", line 1265
> > > >
> > > > I suspect pmapae.c rev 1.61 causes this issue.  Does reverting that
> > > > commit "fix" the issue?
> > > >
> > > > It won't really fix the issue as you may still hit the "can't locate PD 
> > > > page"
> > > > panic.
> > >
> > > I think this diff prevents the panic.  But I need one more test run
> > > to be sure.
> 
> One test without and one with this diff.  Either panic or make build
> passes.  I am convinced that this triggers the bug.  And one of my
> i386 regress machines can easily reproduce it.  Console access for
> developers possible.

I only tried backing out the whole commit so far; it's been building
ports for 5h including some huge ram-hungry ones, I think I would have
seen it on at least one of the four machines by now.

Re: i386 pagedaemon panic pg->wire_count == 0

[Martin Pieuchot]

On 29/04/21(Thu) 16:59, Alexander Bluhm wrote:
> On Thu, Apr 29, 2021 at 04:17:05PM +0200, Martin Pieuchot wrote:
> > On 29/04/21(Thu) 12:07, Alexander Bluhm wrote:
> > > On Thu, Apr 29, 2021 at 11:08:30AM +0200, Mark Kettenis wrote:
> > > > > > panic: kernel diagnostic assertion "pg->wire_count == 0" failed: 
> > > > > > file "/usr/src/sys/uvm/uvm_page.c", line 1265
> > > > 
> > > > I suspect pmapae.c rev 1.61 causes this issue.  Does reverting that
> > > > commit "fix" the issue?
> > > > 
> > > > It won't really fix the issue as you may still hit the "can't locate PD 
> > > > page"
> > > > panic.
> > > 
> > > I think this diff prevents the panic.  But I need one more test run
> > > to be sure.
> 
> One test without and one with this diff.  Either panic or make build
> passes.  I am convinced that this triggers the bug.  And one of my
> i386 regress machines can easily reproduce it.  Console access for
> developers possible.
> 
> > This 4 pages pdir is never freed, so ok with me to revert this chunk if
> > it is the cause of the panic you see.
> 
> How to proceed?  Revert this chunk?  Or does someone want to look 
> into the underlying cause soon.

First revert, then look into the underlying cause.

Re: i386 pagedaemon panic pg->wire_count == 0

[Alexander Bluhm]

On Thu, Apr 29, 2021 at 04:17:05PM +0200, Martin Pieuchot wrote:
> On 29/04/21(Thu) 12:07, Alexander Bluhm wrote:
> > On Thu, Apr 29, 2021 at 11:08:30AM +0200, Mark Kettenis wrote:
> > > > > panic: kernel diagnostic assertion "pg->wire_count == 0" failed: file 
> > > > > "/usr/src/sys/uvm/uvm_page.c", line 1265
> > > 
> > > I suspect pmapae.c rev 1.61 causes this issue.  Does reverting that
> > > commit "fix" the issue?
> > > 
> > > It won't really fix the issue as you may still hit the "can't locate PD 
> > > page"
> > > panic.
> > 
> > I think this diff prevents the panic.  But I need one more test run
> > to be sure.

One test without and one with this diff.  Either panic or make build
passes.  I am convinced that this triggers the bug.  And one of my
i386 regress machines can easily reproduce it.  Console access for
developers possible.

> This 4 pages pdir is never freed, so ok with me to revert this chunk if
> it is the cause of the panic you see.

How to proceed?  Revert this chunk?  Or does someone want to look 
into the underlying cause soon.

bluhm

> > One of my i386 machines triggers it during every make build, the
> > other one is stable.
> > 
> > wire count is 1
> > 
> > struct vm_page at 0xd4fd3404 (76 bytes) {pageq = {tqe_next = (struct 
> > vm_page *)0x, tqe_prev = 0x}, objt = {rbt_parent = (struct 
> > rb_entry *)0xd267d084, rbt_left = (struct rb_entry *)0xd286028c, rbt_right 
> > = (struct rb_entry *)0xd4fd33c0, rbt_color = 0x0}, uanon = (struct vm_anon 
> > *)0x0, uobject = (struct uvm_object *)0xd0e58d0c, offset = 0x2552c000, 
> > pg_flags = 0x324, pg_version = 0x1, wire_count = 0x1, phys_addr = 
> > 0xcfd1e000, fpgsz = 0x0, mdpage = {pv_mtx = {mtx_owner = (volatile void 
> > *)0x0, mtx_wantipl = 0x90, mtx_oldipl = 0x90}, pv_list = (struct pv_entry 
> > *)0x0}}
> > 
> > bluhm
> > 
> > Index: arch/i386/i386/pmapae.c
> > ===
> > RCS file: /mount/openbsd/cvs/src/sys/arch/i386/i386/pmapae.c,v
> > retrieving revision 1.61
> > diff -u -p -r1.61 pmapae.c
> > --- arch/i386/i386/pmapae.c 24 Apr 2021 09:44:45 -  1.61
> > +++ arch/i386/i386/pmapae.c 28 Apr 2021 19:30:13 -
> > @@ -1938,20 +1938,7 @@ pmap_enter_special_pae(vaddr_t va, paddr
> > __func__, va);
> >  
> > if (!pmap->pm_pdir_intel) {
> > -#if notyet
> > -   /*
> > -* XXX mapping is established via pmap_kenter() and lost
> > -* after enabling PAE.
> > -*/
> > -   vapd = (vaddr_t)km_alloc(4 * NBPG, _any, _zero,
> > -   _waitok);
> > -#else
> > -   vapd = (vaddr_t)km_alloc(4 * NBPG, _any, _pageable,
> > -   _waitok);
> > -   if (vapd != 0)
> > -   bzero((void *)vapd, 4 * NBPG);
> > -#endif
> > -   if (vapd == 0)
> > +   if ((vapd = uvm_km_zalloc(kernel_map, 4 * NBPG)) == 0)
> > panic("%s: kernel_map out of virtual space!", __func__);
> > pmap->pm_pdir_intel = vapd;
> > if (!pmap_extract(pmap, (vaddr_t)>pm_pdidx_intel,
> > 

Re: i386 pagedaemon panic pg->wire_count == 0

[Martin Pieuchot]

On 29/04/21(Thu) 12:07, Alexander Bluhm wrote:
> On Thu, Apr 29, 2021 at 11:08:30AM +0200, Mark Kettenis wrote:
> > > > panic: kernel diagnostic assertion "pg->wire_count == 0" failed: file 
> > > > "/usr/src/sys/uvm/uvm_page.c", line 1265
> > 
> > I suspect pmapae.c rev 1.61 causes this issue.  Does reverting that
> > commit "fix" the issue?
> > 
> > It won't really fix the issue as you may still hit the "can't locate PD 
> > page"
> > panic.
> 
> I think this diff prevents the panic.  But I need one more test run
> to be sure.

This 4 pages pdir is never freed, so ok with me to revert this chunk if
it is the cause of the panic you see.  

> One of my i386 machines triggers it during every make build, the
> other one is stable.
> 
> wire count is 1
> 
> struct vm_page at 0xd4fd3404 (76 bytes) {pageq = {tqe_next = (struct vm_page 
> *)0x, tqe_prev = 0x}, objt = {rbt_parent = (struct rb_entry 
> *)0xd267d084, rbt_left = (struct rb_entry *)0xd286028c, rbt_right = (struct 
> rb_entry *)0xd4fd33c0, rbt_color = 0x0}, uanon = (struct vm_anon *)0x0, 
> uobject = (struct uvm_object *)0xd0e58d0c, offset = 0x2552c000, pg_flags = 
> 0x324, pg_version = 0x1, wire_count = 0x1, phys_addr = 0xcfd1e000, fpgsz 
> = 0x0, mdpage = {pv_mtx = {mtx_owner = (volatile void *)0x0, mtx_wantipl = 
> 0x90, mtx_oldipl = 0x90}, pv_list = (struct pv_entry *)0x0}}
> 
> bluhm
> 
> Index: arch/i386/i386/pmapae.c
> ===
> RCS file: /mount/openbsd/cvs/src/sys/arch/i386/i386/pmapae.c,v
> retrieving revision 1.61
> diff -u -p -r1.61 pmapae.c
> --- arch/i386/i386/pmapae.c   24 Apr 2021 09:44:45 -  1.61
> +++ arch/i386/i386/pmapae.c   28 Apr 2021 19:30:13 -
> @@ -1938,20 +1938,7 @@ pmap_enter_special_pae(vaddr_t va, paddr
>   __func__, va);
>  
>   if (!pmap->pm_pdir_intel) {
> -#if notyet
> - /*
> -  * XXX mapping is established via pmap_kenter() and lost
> -  * after enabling PAE.
> -  */
> - vapd = (vaddr_t)km_alloc(4 * NBPG, _any, _zero,
> - _waitok);
> -#else
> - vapd = (vaddr_t)km_alloc(4 * NBPG, _any, _pageable,
> - _waitok);
> - if (vapd != 0)
> - bzero((void *)vapd, 4 * NBPG);
> -#endif
> - if (vapd == 0)
> + if ((vapd = uvm_km_zalloc(kernel_map, 4 * NBPG)) == 0)
>   panic("%s: kernel_map out of virtual space!", __func__);
>   pmap->pm_pdir_intel = vapd;
>   if (!pmap_extract(pmap, (vaddr_t)>pm_pdidx_intel,
> 

Re: i386 pagedaemon panic pg->wire_count == 0

[Alexander Bluhm]

On Thu, Apr 29, 2021 at 11:08:30AM +0200, Mark Kettenis wrote:
> > > panic: kernel diagnostic assertion "pg->wire_count == 0" failed: file 
> > > "/usr/src/sys/uvm/uvm_page.c", line 1265
> 
> I suspect pmapae.c rev 1.61 causes this issue.  Does reverting that
> commit "fix" the issue?
> 
> It won't really fix the issue as you may still hit the "can't locate PD page"
> panic.

I think this diff prevents the panic.  But I need one more test run
to be sure.

One of my i386 machines triggers it during every make build, the
other one is stable.

wire count is 1

struct vm_page at 0xd4fd3404 (76 bytes) {pageq = {tqe_next = (struct vm_page 
*)0x, tqe_prev = 0x}, objt = {rbt_parent = (struct rb_entry 
*)0xd267d084, rbt_left = (struct rb_entry *)0xd286028c, rbt_right = (struct 
rb_entry *)0xd4fd33c0, rbt_color = 0x0}, uanon = (struct vm_anon *)0x0, uobject 
= (struct uvm_object *)0xd0e58d0c, offset = 0x2552c000, pg_flags = 0x324, 
pg_version = 0x1, wire_count = 0x1, phys_addr = 0xcfd1e000, fpgsz = 0x0, mdpage 
= {pv_mtx = {mtx_owner = (volatile void *)0x0, mtx_wantipl = 0x90, mtx_oldipl = 
0x90}, pv_list = (struct pv_entry *)0x0}}

bluhm

Index: arch/i386/i386/pmapae.c
===
RCS file: /mount/openbsd/cvs/src/sys/arch/i386/i386/pmapae.c,v
retrieving revision 1.61
diff -u -p -r1.61 pmapae.c
--- arch/i386/i386/pmapae.c 24 Apr 2021 09:44:45 -  1.61
+++ arch/i386/i386/pmapae.c 28 Apr 2021 19:30:13 -
@@ -1938,20 +1938,7 @@ pmap_enter_special_pae(vaddr_t va, paddr
__func__, va);
 
if (!pmap->pm_pdir_intel) {
-#if notyet
-   /*
-* XXX mapping is established via pmap_kenter() and lost
-* after enabling PAE.
-*/
-   vapd = (vaddr_t)km_alloc(4 * NBPG, _any, _zero,
-   _waitok);
-#else
-   vapd = (vaddr_t)km_alloc(4 * NBPG, _any, _pageable,
-   _waitok);
-   if (vapd != 0)
-   bzero((void *)vapd, 4 * NBPG);
-#endif
-   if (vapd == 0)
+   if ((vapd = uvm_km_zalloc(kernel_map, 4 * NBPG)) == 0)
panic("%s: kernel_map out of virtual space!", __func__);
pmap->pm_pdir_intel = vapd;
if (!pmap_extract(pmap, (vaddr_t)>pm_pdidx_intel,

pf_purge panic on i386 -current SP

[Olivier Cherrier]

>Synopsis:  PF crash with -current
>Category:  network
>Environment:
System  : OpenBSD 6.9
Details : OpenBSD 6.9-current (GENERIC) #787: Wed Apr 28 10:12:43 
MDT 2021
 
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC

Architecture: OpenBSD.i386
Machine : i386
>Description:
After some minutes with PF enabled, the kernel is crashing.
I use this machine as Wifi AP.

>How-To-Repeat:
ddb> 
ddb> trace
db_enter() at db_enter+0x4
panic(d0c23085) at panic+0xd3
kpageflttrap(f397ef40,efffab77) at kpageflttrap+0x137
trap(f397ef40) at trap+0x240
calltrap() at calltrap+0xc
pf_state_key_detach(d176b574,1) at pf_state_key_detach+0xc3
pf_remove_state(d176b574) at pf_remove_state+0x1ae
pf_purge_expired_states(7) at pf_purge_expired_states+0x20e
pf_purge(d0f34040) at pf_purge+0x28
taskq_thread(d19e0040) at taskq_thread+0x51
ddb> 
ddb> ps
   PID TID   PPIDUID  S   FLAGS  WAIT  COMMAND
 91680  102503  86353  0  30x90  netio perl
 84928  487950  1  0  30x100083  ttyin getty
 50357  420093  1  0  30x100098  poll  cron
 86353  02  1  0  30x90  selectperl
 26805  471539  1110  30x100090  poll  sndiod
 44815  194553  1 99  30x100090  poll  sndiod
 92894   38657  39396 95  30x100092  kqreadsmtpd
 61491  332672  39396103  30x100092  kqreadsmtpd
 24366  349089  39396 95  30x100092  kqreadsmtpd
 20583  221597  39396 95  30x100092  kqreadsmtpd
 67163  132034  39396 95  30x100092  kqreadsmtpd
 77706  254966  39396 95  30x100092  kqreadsmtpd
 39396  386710  1  0  30x100080  kqreadsmtpd
 50369  182299  1  0  30x80  selectsshd
 39209  467868  97466 83  30x100092  poll  ntpd
 97466   58794  48591 83  30x100092  poll  ntpd
 48591  467956  1  0  30x100080  poll  ntpd
 49544   87172  18811 74  30x100092  bpf   pflogd
 18811   89146  1  0  30x80  netio pflogd
 31306  123062  57102 73  30x100090  kqreadsyslogd
 57102  520337  1  0  30x100082  netio syslogd
--db_more--66513  416718  12345115  30x100092  
kqreadslaacd
 65901  456997  12345115  30x100092  kqreadslaacd
 12345  236602  1  0  30x100080  kqreadslaacd
 85951   82815  1  0  30x80  mfsidlmount_mfs
 50282  504359  0  0  3 0x14200  bored smr
 16344  105381  0  0  3 0x14200  pgzerozerothread
 22682  490669  0  0  3 0x14200  aiodoned  aiodoned
 21005  275523  0  0  3 0x14200  syncerupdate
   267  494740  0  0  3 0x14200  cleaner   cleaner
 16645  268424  0  0  3 0x14200  reaperreaper
 91185  338378  0  0  3 0x14200  pgdaemon  pagedaemon
 40905   20775  0  0  3 0x14200  bored crynlk
  3814  448551  0  0  3 0x14200  bored crypto
 81885  332216  0  0  3 0x14200  usbtskusbtask
 77033   54567  0  0  3 0x14200  usbatsk   usbatsk
 68119  192458  0  0  3 0x14200  bored sensors
*73472  495669  0  0  7 0x14200softnet
  3192  480294  0  0  3 0x14200  bored systqmp
 66611  471807  0  0  3 0x14200  bored systq
 78985  518909  0  0  3  0x40014200  bored softclock
 73474   63273  0  0  3  0x40014200idle0
  9405  333972  0  0  3 0x14200  kmalloc   kmthread
 1  352606  0  0  30x82  wait  init
--db_more--0   0 -1  0  3 0x10200  
scheduler swapper
ddb> 
ddb> show panic
uvm_fault(0xd0f28590, 0xefffa000, 0, 1) -> d

ddb> 
ddb> show pool
POOLpanic: uvm_fault(0xd0f28590, 0xf4bee000, 0, 1) -> e

 Stopped at db_enter+0x4:   popl%ebp
db_enter() at db_enter+0x4
panic(d0c23085) at panic+0xd3
kpageflttrap(f397ec18,f4bee856) at kpageflttrap+0x137
trap(f397ec18) at trap+0x240
calltrap() at calltrap+0xc
strlen(f4bee856) at strlen+0x10
   

Re: i386 pagedaemon panic pg->wire_count == 0

[Mark Kettenis]

> Date: Thu, 29 Apr 2021 09:52:10 +0100
> From: Stuart Henderson 
> 
> On 2021/04/27 10:35, Alexander Bluhm wrote:
> > On Mon, Apr 26, 2021 at 07:43:29PM +0200, Alexander Bluhm wrote:
> > > One of my i386 machines paniced during make -j 9 build.
> > 
> > This is perfectly reproducable.  Machine crashes while building
> > clang.  This time with snapshot kernel.
> 
> Same panic here building ports (base build was done with an older
> kernel) on 2/4 builders.
> 
> I'm now going to try with the "Convert allocations to km_alloc(9)"
> commit reverted (i386/pmap.c:1.211->1.212, i386/pmapae.c:1.60->1.61)
> 
> 
> > panic: kernel diagnostic assertion "pg->wire_count == 0" failed: file 
> > "/usr/src/sys/uvm/uvm_page.c", line 1265
> > Stopped at  db_enter+0x4:   popl%ebp
> > TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
> >  100962  21754 21 0x3  03  c++
> >  165585775 21 0x3  04  c++
> >  482715   4014 21 0x3  02  c++
> >  104450  78451 21 0x3  06  c++
> >  492054   2530 21 0x3  07  c++
> >  441463  23628 21 0x3  05  c++
> >  266171  31308 21 0x3  00  c++
> > *453385  97818  0 0x14000  0x2001K pagedaemon
> > db_enter() at db_enter+0x4
> > panic(d0bd507b) at panic+0xd3
> > __assert(d0c39ae9,d0bad7c6,4f1,d0c4a94c) at __assert+0x19
> > uvm_pagedeactivate(d4fd923c) at uvm_pagedeactivate+0x122
> > uvmpd_scan() at uvmpd_scan+0x294
> > uvm_pageout(d6fc34c8) at uvm_pageout+0x365
> 
> Exact same trace.
> 
> panic: kernel diagnostic assertion "pg->wire_count == 0" failed: file 
> "/usr/src/sys/uvm/uvm_page.c", line 1265
> Stopped at  db_enter+0x4:   popl%ebp
> TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
>  234486  25502  00x11  02  perl
>  214247  55192 55 0x2  0x4000  rustc.bin
>  471121  59408  00x13  03  perl
> * 31012  31392  0 0x14000  0x2001K pagedaemon
> 
> > version:OpenBSD 6.9-current (GENERIC.MP) #802: Mon Apr 26 02:54:36 
> > MDT 2021\012
> > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP\012
> 
> OpenBSD 6.9-current (GENERIC.MP) #0: Wed Apr 28 21:36:47 MDT 2021
> st...@i386.ports.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MMP
> 
> Built from a clean CVS checkout (no diffs) done at Thu Apr 29 01:20:58 UTC 
> 2021
> 
> > ddb{1}> show register
> > ds  0x10
> > es  0x10
> > fs  0x20
> > gs 0
> > edi   0xd0bd507bacx100_txpower_maxim+0xe81a
> > esi0x100
> > ebp   0xf582662c
> > ebx   0xf5826654
> > edx0x3fd
> > ecx0
> > eax  0x1
> > eip   0xd08a8874db_enter+0x4
> > cs   0x8
> > eflags 0x202
> > esp   0xf582662c
> > ss  0x10
> > db_enter+0x4:   popl%ebp
> 
> same except for
> 
> edi   0xd0bc972dacx100_txpower_maxim+0xc82f
> ebp   0xf598b6cc
> ebx   0xf598b6f4
> eip   0xd0817b04db_enter+0x4
> esp   0xf598b6cc
> 
> > ddb{1}> show uvmexp
> > Current UVM status:
> >   pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
> >   832339 VM pages: 517320 active, 5058 inactive, 1 wired, 147968 free (0 
> > zero)
> >   min  10% (25) anon, 10% (25) vnode, 5% (12) vtext
> >   freemin=27744, free-target=36992, inactive-target=208035, wired-max=277446
> >   faults=201515090, traps=201773820, intrs=2524713, ctxswitch=15585835 
> > fpuswitch=99375
> >   softint=3182921, syscalls=287857563, kmapent=15
> >   fault counts:
> > noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0
> > ok relocks(total)=269519(271199), anget(retries)=141363890(0), 
> > amapcopy=24784161
> > neighbor anon/obj pg=13486052/85376915, 
> > gets(lock/unlock)=27741219/271199
> > cases: anon=139829185, anoncow=1534705, obj=27205510, prcopy=534029, 
> > przero=32411649
> >   daemon and swap counts:
> > woke=2, revs=1, scans=101727, obscans=101727, anscans=0
> > busy=0, freed=101727, reactivate=0, deactivate=0
> > pageouts=0, pending=0, nswget=0
> > nswapdev=1
> > swpages=917207, swpginuse=0, swpgonly=0 paging=0
> >   kernel pointers:
> > objs(kern)=0xd0e719ac
> 
> Current UVM status:
>   pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
>   564802 VM pages: 298864 active, 47935 inactive, 1 wired, 100404 free (2361 
> zero)
>   min  10% (25) anon, 10% (25) vnode, 5% (12) vtext
>   freemin=18826, free-target=25101, inactive-target=141715, wired-max=188267
>   faults=827797786, traps=847312744, intrs=42461394, ctxswitch=169637771 
> fpuswitch=1593503
>   softint=25918765, syscalls=579364703, kmapent=28
>   fault counts:
> noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0
> ok 

Re: i386 pagedaemon panic pg->wire_count == 0

[Stuart Henderson]

On 2021/04/27 10:35, Alexander Bluhm wrote:
> On Mon, Apr 26, 2021 at 07:43:29PM +0200, Alexander Bluhm wrote:
> > One of my i386 machines paniced during make -j 9 build.
> 
> This is perfectly reproducable.  Machine crashes while building
> clang.  This time with snapshot kernel.

Same panic here building ports (base build was done with an older
kernel) on 2/4 builders.

I'm now going to try with the "Convert allocations to km_alloc(9)"
commit reverted (i386/pmap.c:1.211->1.212, i386/pmapae.c:1.60->1.61)


> panic: kernel diagnostic assertion "pg->wire_count == 0" failed: file 
> "/usr/src/sys/uvm/uvm_page.c", line 1265
> Stopped at  db_enter+0x4:   popl%ebp
> TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
>  100962  21754 21 0x3  03  c++
>  165585775 21 0x3  04  c++
>  482715   4014 21 0x3  02  c++
>  104450  78451 21 0x3  06  c++
>  492054   2530 21 0x3  07  c++
>  441463  23628 21 0x3  05  c++
>  266171  31308 21 0x3  00  c++
> *453385  97818  0 0x14000  0x2001K pagedaemon
> db_enter() at db_enter+0x4
> panic(d0bd507b) at panic+0xd3
> __assert(d0c39ae9,d0bad7c6,4f1,d0c4a94c) at __assert+0x19
> uvm_pagedeactivate(d4fd923c) at uvm_pagedeactivate+0x122
> uvmpd_scan() at uvmpd_scan+0x294
> uvm_pageout(d6fc34c8) at uvm_pageout+0x365

Exact same trace.

panic: kernel diagnostic assertion "pg->wire_count == 0" failed: file 
"/usr/src/sys/uvm/uvm_page.c", line 1265
Stopped at  db_enter+0x4:   popl%ebp
TIDPIDUID PRFLAGS PFLAGS  CPU  COMMAND
 234486  25502  00x11  02  perl
 214247  55192 55 0x2  0x4000  rustc.bin
 471121  59408  00x13  03  perl
* 31012  31392  0 0x14000  0x2001K pagedaemon

> version:OpenBSD 6.9-current (GENERIC.MP) #802: Mon Apr 26 02:54:36 
> MDT 2021\012
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP\012

OpenBSD 6.9-current (GENERIC.MP) #0: Wed Apr 28 21:36:47 MDT 2021
st...@i386.ports.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MMP

Built from a clean CVS checkout (no diffs) done at Thu Apr 29 01:20:58 UTC 2021

> ddb{1}> show register
> ds  0x10
> es  0x10
> fs  0x20
> gs 0
> edi   0xd0bd507bacx100_txpower_maxim+0xe81a
> esi0x100
> ebp   0xf582662c
> ebx   0xf5826654
> edx0x3fd
> ecx0
> eax  0x1
> eip   0xd08a8874db_enter+0x4
> cs   0x8
> eflags 0x202
> esp   0xf582662c
> ss  0x10
> db_enter+0x4:   popl%ebp

same except for

edi   0xd0bc972dacx100_txpower_maxim+0xc82f
ebp   0xf598b6cc
ebx   0xf598b6f4
eip   0xd0817b04db_enter+0x4
esp   0xf598b6cc

> ddb{1}> show uvmexp
> Current UVM status:
>   pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
>   832339 VM pages: 517320 active, 5058 inactive, 1 wired, 147968 free (0 zero)
>   min  10% (25) anon, 10% (25) vnode, 5% (12) vtext
>   freemin=27744, free-target=36992, inactive-target=208035, wired-max=277446
>   faults=201515090, traps=201773820, intrs=2524713, ctxswitch=15585835 
> fpuswitch=99375
>   softint=3182921, syscalls=287857563, kmapent=15
>   fault counts:
> noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0
> ok relocks(total)=269519(271199), anget(retries)=141363890(0), 
> amapcopy=24784161
> neighbor anon/obj pg=13486052/85376915, gets(lock/unlock)=27741219/271199
> cases: anon=139829185, anoncow=1534705, obj=27205510, prcopy=534029, 
> przero=32411649
>   daemon and swap counts:
> woke=2, revs=1, scans=101727, obscans=101727, anscans=0
> busy=0, freed=101727, reactivate=0, deactivate=0
> pageouts=0, pending=0, nswget=0
> nswapdev=1
> swpages=917207, swpginuse=0, swpgonly=0 paging=0
>   kernel pointers:
> objs(kern)=0xd0e719ac

Current UVM status:
  pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
  564802 VM pages: 298864 active, 47935 inactive, 1 wired, 100404 free (2361 
zero)
  min  10% (25) anon, 10% (25) vnode, 5% (12) vtext
  freemin=18826, free-target=25101, inactive-target=141715, wired-max=188267
  faults=827797786, traps=847312744, intrs=42461394, ctxswitch=169637771 
fpuswitch=1593503
  softint=25918765, syscalls=579364703, kmapent=28
  fault counts:
noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0
ok relocks(total)=1345165(1347679), anget(retries)=367906740(0), 
amapcopy=128308912
neighbor anon/obj pg=299836900/426127687, 
gets(lock/unlock)=116789120/1347679
cases: anon=273495004, anoncow=94411736, obj=109145091, prcopy=7641515, 
przero=343104381
  daemon and swap counts:
woke=3, revs=1, scans=78347,