bce causes hangs on i386

[Richard Hopkins]

Hi,
I'm currently running OpenBSD 6.7 i386 on a Dell Inspiron 1501 (2006)
and find it hangs with resuming after a sleep.  Everything else
including graphics and wireless (with fw_update) works great.

Steps to reproduce
1) Install OpenBSD 6.7 i386 (with default answers) and GENERIC kernel
2) Login as root
3) apmd
4) zzz
5) Resume

What happens here is either

1) Does not resume.  Screen stays black, and does not return to the
   console.  CPU fans increase.

2) It does resume successfully, but running ifconfig where it accesses
   bce causes the same hang issue described above.  Example commands
   are `ifconfig` and `ifconfig bce0`.  Running `ifconfig bwi0` is
   fine.

bce does work during install and subsequent boots and only causes
issues after at least one sleep.

Booting with `-c` and `disable bce0` will successfully allow a suspend
and resume without issue.

This may be related: on the same machine the amd64 6.7 hard panics on
boot with

panic: aml_die aml_parse:4376
...acpipci_attach
...config_attach
...acpi_foundhid
...

I'm happy to send more information or try patches if others have seen
this before.  I'm currently looking into if_bce.c.


Regards
Richard
OpenBSD 6.7 (GENERIC) #1: Sat May 16 15:49:28 MDT 2020    
r...@syspatch-67-i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem  = 201424 (1917MB)
avail mem = 1958764544 (1868MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 08/23/07, BIOS32 rev. 0 @ 0xfdc84, SMBIOS rev. 2.4 @ 
0xf0420 (37 entries)
bios0: vendor Dell Inc. version "2.6.1" date 08/23/2006
bios0: Dell Inc. Inspiron 1501
acpi0 at bios0: ACPI 1.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA SSDT APIC MCFG SLIC
acpi0: wakeup devices PB2_(S4) PB3_(S4) PB5_(S4) PB6_(S4) OHC1(S0) OHC2(S0) 
OHC3(S0) OHC4(S0) OHC5(S0) EHCI(S0) P2P_(S5) MODM(S3) SLPB(S4) LID_(S3)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Turion(tm) 64 Mobile Technology MK-36 ("AuthenticAMD" 686-class, 
512KB L2 cache) 2 GHz, 0f-4c-02
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,NXE,MMXX,FFXSR,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,SVM,EAPICSP,AMCR8
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 21, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-9
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PB2_)
acpiprt2 at acpi0: bus -1 (PB3_)
acpiprt3 at acpi0: bus 2 (PB5_)
acpiprt4 at acpi0: bus 5 (PB6_)
acpiprt5 at acpi0: bus 8 (P2P_)
acpiprt6 at acpi0: bus 1 (AGP_)
acpiec0 at acpi0
acpicpu0 at acpi0: !C3(@83 io@0x8015), !C2(@18 io@0x8014), C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 110 degC
"PNP0C14" at acpi0 not configured
acpibtn0 at acpi0: PWRB
"PNP0A08" at acpi0 not configured
acpicmos0 at acpi0
"SYN1015" at acpi0 not configured
acpibtn1 at acpi0: SLPB
acpibtn2 at acpi0: LID_
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT1 model "DELL00" serial 1 type LION oem "Sanyo"
acpivideo0 at acpi0: VGA_
acpivout0 at acpivideo0: LCD_
bios0: ROM list: 0xc/0xd000 0xcd000/0x1000
cpu0: PowerNow! K8 1996 MHz: speeds: 2000 1800 1600 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "ATI RS480 Host" rev 0x10
ppb0 at pci0 dev 1 function 0 "ATI RS480 PCIE" rev 0x00
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 5 function 0 "ATI Radeon XPRESS 200M" rev 0x00
drm0 at radeondrm0
radeondrm0: apic 1 int 17
ppb1 at pci0 dev 5 function 0 "ATI RS480 PCIE" rev 0x00
pci2 at ppb1 bus 2
ppb2 at pci0 dev 6 function 0 "ATI RX480 PCIE" rev 0x00
pci3 at ppb2 bus 5
bwi0 at pci3 dev 0 function 0 "Broadcom BCM4311" rev 0x01: apic 1 int 18, 
address 00:19:7d:69:93:07
ahci0 at pci0 dev 18 function 0 "ATI SB600 SATA" rev 0x00: apic 1 int 22, AHCI 
1.1
ahci0: port 0: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  naa.
sd0: 114473MB, 512 bytes/sector, 234441648 sectors, thin
ohci0 at pci0 dev 19 function 0 "ATI SB600 USB" rev 0x00: apic 1 int 16, 
version 1.0, legacy support
ohci1 at pci0 dev 19 function 1 "ATI SB600 USB" rev 0x00: apic 1 int 17, 
version 1.0, legacy support
ohci2 at pci0 dev 19 function 2 "ATI SB600 USB" rev 0x00: apic 1 int 18, 
version 1.0, legacy support
ohci3 at pci0 dev 19 function 3 "ATI SB600 USB" rev 0x00: apic 1 int 17, 
version 1.0, legacy support
ohci4 at pci0 dev 19 function 4 "ATI SB600 USB" rev 0x00: apic 1 int 18, 
version 1.0, legacy support
ehci0 at pci0 dev 19 function 5 "ATI SB600 USB2" rev 0x00: apic 1 int 19
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "ATI EHCI root hub" rev 2.00/1.00 
addr 1
piixpm0 at pci0 dev 20 function 0 "ATI SBx00 SMBus" rev 0x13: SMI
iic0 at piixpm0
spdmem0 at iic0 addr 0x50: 1GB DDR2 SDRAM non-parity PC2-6400CL6 SO-DIMM

Re: i915_request_create+0x4b: uvm_fault

[Stuart Henderson]

On 2020/06/14 15:45, Jonathan Gray wrote:
> On Sat, Jun 13, 2020 at 12:15:13PM +0100, Stuart Henderson wrote:
> > Same with a newer kernel.
> > 
> > OpenBSD 6.7-current (GENERIC.MP) #3: Thu Jun 11 19:47:48 BST 2020
> > st...@symphytum.spacehopper.org:/sys/arch/amd64/compile/GENERIC.MP
> > 
> > uvm_fault(0xfd86e2f6c120, 0x51, 0, 1) -> e
> > kernel: page fault trap, code=0
> > Stopped at  i915_request_create+0x4b:   movq0x50(%r14),%rdi
> > ddb{1}> tr
> 
> 0x50 is the offset in the struct of requests
> r14 in 1 in both traces and appears to be tl
> 
> I don't yet see how that is possible, can you try this diff and tell me
> if the printf triggers?

I'm running with it, hasn't triggered yet (3h uptime).

> Index: sys/dev/pci/drm/i915/i915_request.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_request.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 i915_request.c
> --- sys/dev/pci/drm/i915/i915_request.c   8 Jun 2020 04:48:11 -   
> 1.3
> +++ sys/dev/pci/drm/i915/i915_request.c   14 Jun 2020 05:33:44 -
> @@ -877,6 +877,11 @@ i915_request_create(struct intel_context
>   if (IS_ERR(tl))
>   return ERR_CAST(tl);
>  
> + if ((vaddr_t)tl == 1) {
> + printf("%s tl == 1\n", __func__);
> + return ERR_PTR(-EINVAL);
> + }
> +
>   /* Move our oldest request to the slab-cache (if not in use!) */
>   rq = list_first_entry(>requests, typeof(*rq), link);
>   if (!list_is_last(>link, >requests))
> 

Re: AMD EPYC 7551 box panic: pr_find_pagehead

[Kenneth R Westerback]

On Mon, Jun 15, 2020 at 08:03:40PM +0200, Janne Johansson wrote:
> Den m??n 15 juni 2020 kl 19:59 skrev Kenneth R Westerback <
> kwesterb...@gmail.com>:
> 
> > On Mon, Jun 15, 2020 at 07:15:36PM +0200, Janne Johansson wrote:
> > > Recent AMD box with a bunch of nvme drives, never booted anything,
> > crashes
> > The line
> >
> > scsibus2 at nvme1: 33 targets, initiator 0
> >
> > is also weird. I have never seen anything but 1 or 2 targets on nvme.
> >
> >
> My bad. It has four or five nvmes and there is some .. reflection going on.
> I seem to recall similar things in the old scsi1 days if you had bad
> termination, long since I saw mirrored devices like this on the bus.
> 
> 
> > Running a kernel with SCSIDEBUG will produce more information on the
> > negotiation/discovery interactions.
> > Clarification of "bunch of nvme drives" and a complete dmesg would
> > also help.
> >
> 
> If it would help, I could screenshot one page at a time, that seems to be
> the best I can do today.

Works for me, though I don't recommend sending all those pics to
bugs@.

> 
> -- 
> May the most significant bit of your life be positive.

The other random thing to try is to find the line

sc->sc_link.adapter_buswidth = sc->sc_nn + 1;

in /usr/src/sys/dev/ic/nvme.c

and replace the "sc->sc_nn + 1" with 1 or 2. Perhaps the nvme
controller is returning interesting values for the namespace count in
the identify message. I see there is already some weird code to deal
with Apple oddities. :-)

 Ken

Re: OpenBSD 6.7 crashes on APU2C4 with LTE modem Huawei E3372s-153 HiLink

[Gerhard Roth]

On 2020-06-13 01:24, Łukasz Lejtkowski wrote:

Good news - no more kernel panics on USB 3.0(xHCI), it’s fixed.

Bad news - after 2-3h LTE modem lost local network connection via USB 
3.0(cdce0). I have to remove modem and put it back to usb port - then 
local network connection between OpenBSD and modem back for 2-3h, 
sometimes 30-40 min. It looks like the same problem as kernel panic, but 
this time there is lost network connection via usb 3.0(xhci).


root@master[~]ping 192.168.8.1
PING 192.168.8.1 (192.168.8.1): 56 data bytes
ping: sendmsg: Network is down
ping: wrote 192.168.8.1 64 chars, ret=-1
ping: sendmsg: Network is down
ping: wrote 192.168.8.1 64 chars, ret=-1

192.168.8.1 is default static IP on lte modem.

Your changes in if_cdce.c 1.77 not completely fix the problem.


Hi,

yes, my patch just targeted to fix the panic as a reaction to USB 
problems; not the USB problems themself.


Does it recover after doing

# ifconfig cdcef0 down
# ifconfig cdcef0 up

Gerhard




On 11 Jun 2020, at 11:13, Łukasz Lejtkowski > wrote:


Hi Gerhard,

Today I added Your patches to 6.7-stable and moved back LTE modem to 
USB 3.0. So, just waiting for… nothing or kernel panic. I’ll let you 
know.


On 8 Jun 2020, at 19:13, Patrick Wildt > wrote:


On Mon, Jun 08, 2020 at 05:31:44PM +0200, Gerhard Roth wrote:

On 2020-05-25 13:19, Martin Pieuchot wrote:

On 25/05/20(Mon) 12:56, Gerhard Roth wrote:

On 5/22/20 9:05 PM, Mark Kettenis wrote:
From: Łukasz Lejtkowski >

Date: Fri, 22 May 2020 20:51:57 +0200

Probably power supply 12 V is broken. Showing 16,87 V(Fluke 179) -
too high. Should be 12,25-12,50 V. I replaced to the new one.


That might be why the device stops responding.  The fact that 
cleaning

up from a failed USB transaction leads to this panic is a bug though.

And somebody just posted a very similar panic with ure(4).  Something
in the network stack is holding a mutex when it shouldn't.


I think that holding the mutex is ok. The bug is calling the stop
routine in case of errors.

This is what common foo_start() does:

m_head = ifq_deq_begin(>if_snd);
if (foo_encap(sc, m_head, 0)) {
ifq_deq_rollback(>if_snd, m_head);
...
return;
}
ifq_deq_commit(>if_snd, m_head);

Here, ifq_deq_begin() grabs a mutex and it is held while
calling foo_encap().

For USB network interfaces foo_encap() mostly does this:

err = usbd_transfer(sc->sc_xfer);
if (err != USBD_IN_PROGRESS) {
foo_stop(sc);
return EIO;
}

And foo_stop() calls usbd_abort_pipe() -> xhci_command_submit(),
which might sleep.

How to fix? We could do the foo_encap() after the ifq_deq_commit(),
possibly dropping the current mbuf if encap fails (who cares
for the packets after foo_stop() anyway).


That's the approach taken by drivers using ifq_dequeue(9) instead of
ifq_deq_begin/commit().


Or change all the drivers to follow the path that if_aue.c takes:

err = usbd_transfer(c->aue_xfer);
if (err != USBD_IN_PROGRESS) {
...
/* Stop the interface from process context. */
usb_add_task(sc->aue_udev, >aue_stop_task);
return (EIO);
}


That's just trading the current problem for another one with higher
complexity.


Any ideas, what's better? Or alternative proposals?


Using ifq_dequeue(9) would have the advantage of unifying the code 
base.

It introduces a behavior change.  A simpler fix would be to call
foo_stop() in the error path after ifq_deq_rollback().



Hi,

two weeks passed any nobody objected Martin's proposal. So I thought,
we could try to move on this way.

Gerhard



From what I remember from various discussions, the goal should be to
check if there's a buffer free in the ring, then dequeue and send, and
it it can't be sent out, then drop it.  With USB apparently those
drivers "always" have an open buffer, so we can just dequeue and send,
like you do in this diff.  And if it gets dropped, that's fine.

That said, I think IFQ_DEQUEUE() is old compat code, and we actually
nowadays prefer:

m_head = ifq_dequeue(>if_snd);

If you look at the define for IFQ_DEQUEUE() you'll see it's marked
as compat code.  If you look at a new driver, like ixl(4), you'll
see that it also uses ifq_dequeue().

Sorry to to give you some work, but with that fixed: ok patrick@

Patrick



Index: sys/dev/usb/if_axe.c
===
RCS file: /cvs/src/sys/dev/usb/if_axe.c,v
retrieving revision 1.139
diff -u -p -u -p -r1.139 if_axe.c
--- sys/dev/usb/if_axe.c7 Jul 2019 06:40:10 -1.139
+++ sys/dev/usb/if_axe.c8 Jun 2020 15:13:25 -
@@ -1223,6 +1223,7 @@ axe_encap(struct axe_softc *sc, struct m
/* Transmit */
err = usbd_transfer(c->axe_xfer);
if (err != USBD_IN_PROGRESS) {
+c->axe_mbuf = NULL;
axe_stop(sc);
return(EIO);
}
@@ -1246,16 +1247,15 @@ axe_start(struct ifnet *ifp)
if (ifq_is_oactive(>if_snd))
return;

-m_head = ifq_deq_begin(>if_snd);
+IFQ_DEQUEUE(>if_snd, m_head);
if (m_head == NULL)
return;

if (axe_encap(sc, 

Re: AMD EPYC 7551 box panic: pr_find_pagehead

[Janne Johansson]

Den mån 15 juni 2020 kl 19:59 skrev Kenneth R Westerback <
kwesterb...@gmail.com>:

> On Mon, Jun 15, 2020 at 07:15:36PM +0200, Janne Johansson wrote:
> > Recent AMD box with a bunch of nvme drives, never booted anything,
> crashes
> The line
>
> scsibus2 at nvme1: 33 targets, initiator 0
>
> is also weird. I have never seen anything but 1 or 2 targets on nvme.
>
>
My bad. It has four or five nvmes and there is some .. reflection going on.
I seem to recall similar things in the old scsi1 days if you had bad
termination, long since I saw mirrored devices like this on the bus.


> Running a kernel with SCSIDEBUG will produce more information on the
> negotiation/discovery interactions.
> Clarification of "bunch of nvme drives" and a complete dmesg would
> also help.
>

If it would help, I could screenshot one page at a time, that seems to be
the best I can do today.

-- 
May the most significant bit of your life be positive.

Re: AMD EPYC 7551 box panic: pr_find_pagehead

[Kenneth R Westerback]

On Mon, Jun 15, 2020 at 07:15:36PM +0200, Janne Johansson wrote:
> Recent AMD box with a bunch of nvme drives, never booted anything, crashes
> with
> panic: pr_find_pagehead: dma256: page header missing
> after listing some sd(4) drives on 14-Jun snapshot installation.
> 
> That is the only odd output in the dmesg as far as I can see, picture
> included.
> 
> 6.7 release has the same issue.
> 
> 6.6 installer works and I can boot the installed OS but I have no net on
> the box (mcx 40/56/100GE card in it) yet.
> 
> 
> -- 
> May the most significant bit of your life be positive.

The line

scsibus2 at nvme1: 33 targets, initiator 0

is also weird. I have never seen anything but 1 or 2 targets on nvme.

Running a kernel with SCSIDEBUG will produce more information on the
negotiation/discovery interactions.

Clarification of "bunch of nvme drives" and a complete dmesg would
also help.

 Ken

Re: AMD EPYC 7551 box panic: pr_find_pagehead

[Janne Johansson]

Den mån 15 juni 2020 kl 19:55 skrev Janne Johansson :

>
> I currently only have remote-console access to it, but the three of the
> four nvmes all get tons of ghosts.
>
>
and I am sorry in advance for the pictures, but with no network configured
on the switches the box is connected to, all I can do is screenshot the
console window I used for installation (along with remote-cd-iso use for
install66/67.iso)

-- 
May the most significant bit of your life be positive.

Re: AMD EPYC 7551 box panic: pr_find_pagehead

[Mark Kettenis]

> From: Janne Johansson 
> Date: Mon, 15 Jun 2020 19:15:36 +0200
> Content-Type: multipart/mixed; boundary="ea5a1505a8229334"
> 
> Recent AMD box with a bunch of nvme drives, never booted anything, crashes
> with
> panic: pr_find_pagehead: dma256: page header missing
> after listing some sd(4) drives on 14-Jun snapshot installation.
> 
> That is the only odd output in the dmesg as far as I can see, picture
> included.

That Micron_9300_MTFD disk showing up twice is suspicious.

Does the machine boot with nvme(4) disabled and/or that particular
NVMe disk removed?

AMD EPYC 7551 box panic: pr_find_pagehead

[Janne Johansson]

Recent AMD box with a bunch of nvme drives, never booted anything, crashes
with
panic: pr_find_pagehead: dma256: page header missing
after listing some sd(4) drives on 14-Jun snapshot installation.

That is the only odd output in the dmesg as far as I can see, picture
included.

6.7 release has the same issue.

6.6 installer works and I can boot the installed OS but I have no net on
the box (mcx 40/56/100GE card in it) yet.


-- 
May the most significant bit of your life be positive.

Re: www.openbsd.org kernel hang, May 2 kernel.

[Mark Kettenis]

> Date: Mon, 15 Jun 2020 09:59:32 -0600
> From: Bob Beck 
> 
> May 2 kernel. This may have since been fixed, and I will be sysupgrading. 
> 
> Just recording here in case it hasn't been. lots of stuff in fltamapcopy
> when I broke into ddb

/* didn't work?  must be out of RAM.  sleep. */
if (UVM_ET_ISNEEDSCOPY(ufi->entry)) {
uvmfault_unlockmaps(ufi, TRUE);
uvm_wait("fltamapcopy");
continue;
}

Buy more RAM?  Memory leaks in httod?


> ddb{0}>  ps
>PID TID   PPIDUID  S   FLAGS  WAIT  COMMAND
>  32360  384138  87480  0  20x100010cron
>  41093  259088   1633  0  2   0newsyslog
>  93393  182254  23927  0  20x11ksh
>  19424  449656  98871   7001  20x10sh
>  16698  476674  20540  0  3   0  fltamapcopy   sshd
>  29935  404506  20540  0  3 0x2  fltamapcopy   sshd
>  47557   53289  20540  0  7 0x2sshd
>   5395  397919  20540  0  3 0x2  fltamapcopy   sshd
>   1633  120700  15128  0  3 0x2  fltamapcopy   newsyslog
>  98871   13776  34544   7001  30x12  fltamapcopy   sh
>  80040  469204  54944 67  7 0x2perl
>  34544  328300  15165   7001  30x10008a  pause sh
>  15165  330323  87480  0  30x100090  piperdcron
>  15128  394992   8074  0  30x10008a  pause sh
>   8074  220634  87480  0  30x100090  piperdcron
>  71858   82311  54944 67  3 0x2  fltamapcopy   perl
>   7870  305285  81510  0  30x80  selectrsync
>  81510  157165  21727  0  30x82  selectrsync
>  21727  276488   3060  0  30x10008a  pause ksh
>   3060  133467  20540  0  20x12sshd
>  94052  124863  73363  0  30x80  selectrsync
>  73363  394190  48990  0  30x82  selectrsync
>  48990  203526   9886  0  30x10008a  pause ksh
>   9886  418261  20540  0  30x12  fltamapcopy   sshd
>  71234   74430   3255  0  30x80  selectrsync
>  94525  117381   3255  0  30x100082  selectssh
>   3255  481676  40465  0  3 0x2  fltamapcopy   rsync
>  40465  165733  44158  0  30x10008a  pause sh
>  44158  344912  70368  0  30x10008a  pause sh
>  70368  193750  87480  0  30x100090  piperdcron
>  86547  303614  1  0  30x100080  kqreadhttpd
>  52411   97199  1 67  30x100092  kqreadhttpd
>  49367  169612  1 67  30x100012  fltamapcopy   httpd
>  96185  127828  1 67  20x100012httpd
>  43666  401716  1 67  30x100012  inode httpd
>  69693  409358  1 67  30x100012  fltamapcopy   httpd
>  19879   66075  1 67  30x100012  fltamapcopy   httpd
>  63555   14933  1 67  30x100012  fltamapcopy   httpd
>   3191  280664  1 67  30x100012  fltamapcopy   httpd
>  38761  137145  1 67  30x100012  fltamapcopy   httpd
>  13859  238489  1 67  20x100012httpd
>  48772  347381  1 67  30x100012  fltamapcopy   httpd
>  26692  413368  1 67  30x100012  inode httpd
>  621526961  1 67  30x100012  inode httpd
>  79903  196927  1 67  30x100012  fltamapcopy   httpd
>  53474  423418  1 67  30x100012  fltamapcopy   httpd
>  20857  408237  1 67  30x100012  fltamapcopy   httpd
>  84135   21480  1 67  30x100012  inode httpd
>  79469  483433  1 67  30x100012  fltamapcopy   httpd
>  44473  229666  1 67  30x100012  fltamapcopy   httpd
> * 3045  177399  1 67  70x100012httpd
>  15153  328527  1 67  30x100012  fltamapcopy   httpd
> 
> 
> 
> 
> >> OpenBSD/amd64 BOOT 3.47
> boot> 
> booting hd0a:/bsd: 12957000+2753544+331808+0+708608 
> [807954+128+1024848+749607]=0x1272c10
> entry point at 0x81001000
> [ using 2583568 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-2020 OpenBSD. All rights reserved.  https://www.OpenBSD.org
> 
> OpenBSD 6.7-beta (GENERIC.MP) #169: Sat May  2 01:24:52 MDT 2020
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 17119961088 (16326MB)
> avail mem = 16588488704 (15820MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x8ef68000 (43 entries)
> bios0: vendor Dell Inc. version "1.4.5" date 08/09/2016
> bios0: Dell 

www.openbsd.org kernel hang, May 2 kernel.

[Bob Beck]

May 2 kernel. This may have since been fixed, and I will be sysupgrading. 

Just recording here in case it hasn't been. lots of stuff in fltamapcopy
when I broke into ddb


ddb{0}>  ps
   PID TID   PPIDUID  S   FLAGS  WAIT  COMMAND
 32360  384138  87480  0  20x100010cron
 41093  259088   1633  0  2   0newsyslog
 93393  182254  23927  0  20x11ksh
 19424  449656  98871   7001  20x10sh
 16698  476674  20540  0  3   0  fltamapcopy   sshd
 29935  404506  20540  0  3 0x2  fltamapcopy   sshd
 47557   53289  20540  0  7 0x2sshd
  5395  397919  20540  0  3 0x2  fltamapcopy   sshd
  1633  120700  15128  0  3 0x2  fltamapcopy   newsyslog
 98871   13776  34544   7001  30x12  fltamapcopy   sh
 80040  469204  54944 67  7 0x2perl
 34544  328300  15165   7001  30x10008a  pause sh
 15165  330323  87480  0  30x100090  piperdcron
 15128  394992   8074  0  30x10008a  pause sh
  8074  220634  87480  0  30x100090  piperdcron
 71858   82311  54944 67  3 0x2  fltamapcopy   perl
  7870  305285  81510  0  30x80  selectrsync
 81510  157165  21727  0  30x82  selectrsync
 21727  276488   3060  0  30x10008a  pause ksh
  3060  133467  20540  0  20x12sshd
 94052  124863  73363  0  30x80  selectrsync
 73363  394190  48990  0  30x82  selectrsync
 48990  203526   9886  0  30x10008a  pause ksh
  9886  418261  20540  0  30x12  fltamapcopy   sshd
 71234   74430   3255  0  30x80  selectrsync
 94525  117381   3255  0  30x100082  selectssh
  3255  481676  40465  0  3 0x2  fltamapcopy   rsync
 40465  165733  44158  0  30x10008a  pause sh
 44158  344912  70368  0  30x10008a  pause sh
 70368  193750  87480  0  30x100090  piperdcron
 86547  303614  1  0  30x100080  kqreadhttpd
 52411   97199  1 67  30x100092  kqreadhttpd
 49367  169612  1 67  30x100012  fltamapcopy   httpd
 96185  127828  1 67  20x100012httpd
 43666  401716  1 67  30x100012  inode httpd
 69693  409358  1 67  30x100012  fltamapcopy   httpd
 19879   66075  1 67  30x100012  fltamapcopy   httpd
 63555   14933  1 67  30x100012  fltamapcopy   httpd
  3191  280664  1 67  30x100012  fltamapcopy   httpd
 38761  137145  1 67  30x100012  fltamapcopy   httpd
 13859  238489  1 67  20x100012httpd
 48772  347381  1 67  30x100012  fltamapcopy   httpd
 26692  413368  1 67  30x100012  inode httpd
 621526961  1 67  30x100012  inode httpd
 79903  196927  1 67  30x100012  fltamapcopy   httpd
 53474  423418  1 67  30x100012  fltamapcopy   httpd
 20857  408237  1 67  30x100012  fltamapcopy   httpd
 84135   21480  1 67  30x100012  inode httpd
 79469  483433  1 67  30x100012  fltamapcopy   httpd
 44473  229666  1 67  30x100012  fltamapcopy   httpd
* 3045  177399  1 67  70x100012httpd
 15153  328527  1 67  30x100012  fltamapcopy   httpd




>> OpenBSD/amd64 BOOT 3.47
boot> 
booting hd0a:/bsd: 12957000+2753544+331808+0+708608 
[807954+128+1024848+749607]=0x1272c10
entry point at 0x81001000
[ using 2583568 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-2020 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.7-beta (GENERIC.MP) #169: Sat May  2 01:24:52 MDT 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17119961088 (16326MB)
avail mem = 16588488704 (15820MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x8ef68000 (43 entries)
bios0: vendor Dell Inc. version "1.4.5" date 08/09/2016
bios0: Dell Inc. PowerEdge R230
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP BOOT SSDT SLIC HPET LPIT APIC MCFG WDAT SSDT DBGP DBG2 
SSDT SSDT SSDT SSDT DMAR R
acpi0: wakeup devices PEG0(S0) PEGP(S0) PEG1(S0) PEGP(S0) PEG2(S0) PEGP(S0) 
XHC_(S0) XDCI(S0) RP01(S0) P]
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) Xeon(R) CPU E3-1240 v5 @ 3.50GHz, 3692.79 MHz, 06-5e-03
cpu0: