On 02/02/17(Thu) 22:00, Pedro Caetano wrote:
> Hi,
>
> Running a release built with today's sources I've ran into a few more stack
> traces.
Please do not report traces that you get when setting pool_debug to 2.
As I mentioned in my original email it is for "people looking for small
coding tasks
Receiving these as well after an upgrade to latest snapshot.
OpenBSD 6.0-current (GENERIC.MP) #160: Thu Feb 2 08:25:02 MST 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 80
real mem = 16851230720 (16070MB)
avail mem = 16335859712 (15579MB)
m
Hi,
Running a release built with today's sources I've ran into a few more stack
traces.
--- syscall (number 54) ---
--- syscall (number 97) ---
--- syscall (number 105) ---
stack traces below, extracted from /var/run/dmesg.boot.
Cheers,
Pedro Caetano
ansible@q-tester $ > sysctl
kern.version
k
On 30/01/17(Mon) 22:02, Pedro Caetano wrote:
> Hi,
>
> On three of six VMs the following stack trace has been shown on logs.
> All the systems are amd64 running the same snapshot, sources fecthed from
> cvs january 28th, the only that crashed were running ospfd.
>
> stacks and dmesg below.
Thank
moptions+0x248
ip_ctloutput() at ip_ctloutput+0x461
sosetopt() at sosetopt+0x8e
sys_setsockopt() at sys_setsockopt+0x12d
syscall() at syscall+0x197
--- syscall (number 105) ---
end of kernel
end trace frame: 0x8f1ac05ae00, count: 250
0x8f0ed4335ea:
End of stack trace.
splassert: tsleep: want 0 have
Hi,
On three of six VMs the following stack trace has been shown on logs.
All the systems are amd64 running the same snapshot, sources fecthed from
cvs january 28th, the only that crashed were running ospfd.
stacks and dmesg below.
Best regards,
Pedro Caetano
splassert: tsleep: want 0 have 1
