On 2017-11-07 04:30, Stuart Henderson wrote:
Hi, my system that was hitting the crynlk hangs has been stable since
your commit (uptime now 19 days).
(I hope your new job is going well, Mike!)
--
Sent from a phone, apologies for poor formatting.
On 6 November 2017 23:49:40 Mike Belopuhov <[email protected]> wrote:
On Mon, Nov 06, 2017 at 23:17 +0200, Atanas Vladimirov wrote:
> Synopsis: System freeze
> Category: amd64
> Environment:
System : OpenBSD 6.2
Details : OpenBSD 6.2-current (GENERIC.MP) #197: Sun Nov 5
12:48:36
MST 2017
[email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
> Description:
The kernel didn't panics.
I'm chasing this bug last few months and finally I managed to
collect the
ddb output for a bug report.
This time I used a PS2 keyboard because it seems that an USB ports
didn't
works (IPMI also didn't works).
That's why it took me so long to report it.
Please, take a look at the pictures (attached) for the output of ps,
trace,
show registers and show panic.
Let me know if you need more information. Thanks.
> How-To-Repeat:
I don't know.
> Fix:
Unknown.
Hi,
Hello Mike, Stuart,
Atanas, are you using IPsec or maybe a crypto softraid on
this machine? How often does it hang?
I'm using IPsec (a few tunnels), no crypto softraid (I using only
software RAID1).
I'm observing this behavior a few months back (maybe 3-5) but till now I
couldn't enter
to ddb, because my usb keyboard was stopping to work when the system
freezed.
This hang happen a few times (2-3) after a reboot when moving to a newer
snapshot.
After that the system could run a few weeks (when I decide to upgrade to
new snapshot) and
not to hang at all.
This is another crynlk hang so this probably means that
something other than an uninitialized FPU context must be
causing this. Stuart, have you seen any hangs on your
systems after my diff went in?
I'm not around to look further at it, unfortunately. But
I can offer Atanas to try this diff that helped Stuart
before. Please run it for at least a week before reporting
back.
Regards,
Mike
Thanks for your time and effort. Now I'll build a kernel with your patch
and
let it run for a while (maybe a few weeks). Let me know if you have more
questions.
Thanks,
Atanas
P.S.: Mike, just a feedback, before I upgrade last night I was running
with
you patch [0] for a last few weeks with no issues.
[0] https://marc.info/?l=openbsd-tech&m=150298523506960&w=2
diff --git sys/arch/amd64/amd64/fpu.c sys/arch/amd64/amd64/fpu.c
index 07e16a0efb6..7a6714b8d5b 100644
--- sys/arch/amd64/amd64/fpu.c
+++ sys/arch/amd64/amd64/fpu.c
@@ -348,19 +348,10 @@ fpu_kernel_enter(void)
{
struct cpu_info *ci = curcpu();
struct savefpu *sfp;
int s;
- /*
- * Fast path. If the kernel was using the FPU before, there
- * is no work to do besides clearing TS.
- */
- if (ci->ci_fpcurproc == &proc0) {
- clts();
- return;
- }
-
s = splipi();
if (ci->ci_fpcurproc != NULL) {
fpusave_cpu(ci, 1);
uvmexp.fpswtch++;
