Re: misc panics

[Stuart Henderson]

On 2020-12-27, Stuart Longland  wrote:
> Seems awfully strange for `/bsd` to become zero-length out-of-the-blue. 

Not if it crashed at a bad point in "reorder_kernel".

I would try GENERIC instead of GENERIC.MP to see if there's any change.

Re: misc panics

[Stuart Longland]

On 28/12/20 3:56 am, Bastien Durel wrote:
After that I got a (maybe) endless loop of panics inducing panics (I did 
not got the output, it was cycling fast), and after that the /bsd file 
was left empty :



OpenBSD/amd64 BOOT 3.52

boot> NOTE: random seed is being reused.
booting hd0a:/bsd: read header
 failed(0). will try /bsd

…

How can I figure out the cause of all these problems ?


Seems awfully strange for `/bsd` to become zero-length out-of-the-blue. 
 Got a `memtest86` disk handy?


I'd be checking:
- RAM
- disks
- CPU

I think from the `dmesg` the storage device is a SSD?  Could it be it 
has failed early?  Some do that, and they give practically no warning 
when they do.

--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Re: xterm dies

Theo de Raadt writes:

> Probably fixed by:
>
> CVSROOT:/cvs
> Module name:src
> Changes by: v...@cvs.openbsd.org2020/12/23 06:53:45
> 
> Modified files:
> sys/kern   : kern_event.c
> 
> Log message:
> Clear error before each iteration in kqueue_scan()
> 
> This fixes a regression where kqueue_scan() may incorrectly return
> EWOULDBLOCK after a timeout.
> 
> OK mpi@
>
>
> Please don't use terminology like "a few days ago".   You can easily be
> more precise.
[...]

Indeed. The problem was occurring using
OpenBSD 6.8-current (GENERIC.MP) #235: Tue Dec 22 11:31:52 MST 2020 .

Doing another sysupgrade just now seems to have taken care of it.

Thanks everyone for responding.

Cheers,
Björn

misc panics

[Bastien Durel]

Hello,

While in vacation, my home router crashed. I power-cycled it as soon as 
I returned, as console was unresponsive (I access it via serial console, 
so lines in following traces may be truncated)


I then crashed a few seconds after finished boot :


OpenBSD/amd64 (fremen.geekwu.org) (tty00)

login: panic: pool_do_get: art_table free list modified: page 
0xfd812b0ac000; item addr 0xfdc
Starting stack trace...
panic(81e7958a) at panic+0x11d
pool_do_get(82196790,a,8000339a7f14) at pool_do_get+0x321
pool_get(82196790,a) at pool_get+0x8f
art_table_get(80294480,fd812b0ac1a8,15) at art_table_get+0x7d
art_insert(80294480,fd812b2f2480,8193c908,2d) at 
art_insert+0xe3
rtable_insert(0,8193c900,880213a0,88021380,30,fd812b3cc738)
 at rtable_inc
rtrequest(1,8000339a8298,30,8000339a8210,0) at rtrequest+0x4fe
rtm_output(88021300,8000339a8340,8000339a8298,30,0) at 
rtm_output+0x526
route_output(fd80784e0b00,fd814a2f7b30,0,0) at route_output+0x396
route_usrreq(fd814a2f7b30,9,fd80784e0b00,0,0,8000227e4290) at 
route_usrreq+0x21a
sosend(fd814a2f7b30,0,8000339a8610,0,0,80) at sosend+0x36c
dofilewritev(8000227e4290,6,8000339a8610,0,8000339a8710) at 
dofilewritev+0x14d
sys_writev(8000227e4290,8000339a86b0,8000339a8710) at 
sys_writev+0xe2
syscall(8000339a8780) at syscall+0x389
Xsyscall() at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7d5530, count: 242
End of stack trace.
syncing disks...18 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10  
giving up


After I unplugged all but one ethernet cable, I had time to log in and 
enter a few commands (including syspatch, that only upgraded smtpd) 
before another crash :


fremen# ospfctl sh ne 
ID  Pri StateDeadTime Address Iface Uptime

51.255.165.194  1   DOWN/DOWN00:02:05 10.120.0.58 wg3   -
151.80.16.138   1   FULL/DR  00:00:17 10.120.0.2  tap0  00:01:30
10.42.42.21 1   2-WAY/WAIT   00:00:39 10.42.42.21 em1   -
fremen# fatal protection fault in supervisor mode
trap type 4 code 0 rip 81131c89 cs 8 rflags 10282 cr2 207673f0010 cpl 0 
rsp 800022717250
gsbase 0x8211cff0  kgsbase 0x0
panic: trap type 4, code=0, pc=81131c89
Starting stack trace...
panic(81de4ae4,81de4ae4,8000227171a0,4,800022717268,821e3d18)
 at pand
kerntrap(8000227171a0,8000227171a0,8b36cc049b52fe43,f7fffd812f03fdd0,fd812f03ff90,6148604
alltraps_kern_meltdown(4,6148601dcf42cca0,800022717264,0,f7fffd812f03fdd0,fd812f03ff90)
 at ab
pool_p_free(821e3d18,fd812f03ff90,3c3fbd5ca1bd0af6,fd812f03ff90,821e3d18,fff9
pool_put(821e3d18,fd812a7379d0,fa2dd1afa1e566dc,0,fd812a7379d0,0)
 at pool_put+0x16b
art_gc(0,0,cf984c543a977bcb,82114d50,82114d38,1) at art_gc+0x71
taskq_thread(82114d38,82114d38,0,0,82114d38,81be29b0)
 at taskq_threa1
end trace frame: 0x0, count: 250
End of stack trace.


After that I got a (maybe) endless loop of panics inducing panics (I did 
not got the output, it was cycling fast), and after that the /bsd file 
was left empty :



OpenBSD/amd64 BOOT 3.52
boot> 
NOTE: random seed is being reused.

booting hd0a:/bsd: read header
 failed(0). will try /bsd


I booted /bsd.booted and got another crash at the end of boot sequence :


boot> boot /bsd.booted
NOTE: random seed is being reused.
booting hd0a:/bsd.booted: 14415144+3195920+344096+0+880640 
[497303+128+1138200+861220]=0x145ad58
entry point at 0x81001000
0
ff810010[ using 2497880 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.8 (GENERIC.MP) #2: Sat Dec  5 07:17:48 MST 2020

r...@syspatch-68-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4196302848 (4001MB)
avail mem = 4054564864 (3866MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x8ce22000 (85 entries)
bios0: vendor American Megatrends Inc. version "5.12" date 11/23/2018
bios0: Default string Default string
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S3 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT HPET SSDT SSDT UEFI SSDT 
LPIT SSDT SSDT SSDT ST
acpi0: wakeup devices RP09(S3) PXSX(S3) RP10(S3) PXSX(S3) RP11(S3) PXSX(S3) 
RP12(S3) PXSX(S3) RP13(S]
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) Celeron(R) CPU 3855U @ 1.60GHz, 1596.81 MHz, 06-4e-03
cpu0: 

Re: xterm dies

[Theo de Raadt]

Probably fixed by:

CVSROOT:/cvs
Module name:src
Changes by: v...@cvs.openbsd.org2020/12/23 06:53:45

Modified files:
sys/kern   : kern_event.c

Log message:
Clear error before each iteration in kqueue_scan()

This fixes a regression where kqueue_scan() may incorrectly return
EWOULDBLOCK after a timeout.

OK mpi@


Please don't use terminology like "a few days ago".   You can easily be
more precise.



Björn Gohla  wrote:

> Hi All,
> 
> Since updating to snapshot a few days ago I've been having problems with
> xterm randomly dying. I was able to capture this on another terminal:
> 
> 16:51:12 bgohla@titanic[1] ~ $ xterm: Error 50, errno 35: Resource
> temporarily unavailable
> Reason: in_put: select() failed
> 16:51:12 bgohla@titanic[1] ~ $ man select
> [1]+  Exit 50 xterm sh
> 17:54:42 bgohla@titanic ~ $
> 
> This is very annoying (I even had to start this email over because of
> it).
> 
> There don't seem to be any recent changes to xterm, so I'm out of
> ideas where to look for the source of the error.
> 
> Any ideas what one can do in this situation? Would another sysupgrade -s
> help?
> 
> Cheers,
> Björn
> 

xterm dies

[Björn Gohla]

Hi All,

Since updating to snapshot a few days ago I've been having problems with
xterm randomly dying. I was able to capture this on another terminal:

16:51:12 bgohla@titanic[1] ~ $ xterm: Error 50, errno 35: Resource
temporarily unavailable
Reason: in_put: select() failed
16:51:12 bgohla@titanic[1] ~ $ man select
[1]+  Exit 50 xterm sh
17:54:42 bgohla@titanic ~ $

This is very annoying (I even had to start this email over because of
it).

There don't seem to be any recent changes to xterm, so I'm out of
ideas where to look for the source of the error.

Any ideas what one can do in this situation? Would another sysupgrade -s
help?

Cheers,
Björn

Re: Can't compile ruby passenger ports 6.8

[Stuart Henderson]

On 2020-12-25, Mik J  wrote:
> Hello,
> It has been many releases that I systematically have a problem compiling 
> ruby-passenger in the portsDo you know what could be the issue ?

No idea, but it works fine in bulk builds, so have a look at how
you have configured things for building ports on your system.
Look at mk.conf, directory layouts, filesystem mount options,
doas/sudo config if used, environment variables. 

If you can't figure it out, show the full build log not just an
excerpt, and as much information from the above as possible.
Or just pkg_add it.