Re: Stop scheduler on panic

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Kostik,

thanks a lot!
I am not really sorry for taking part in tricking you into doing this :)
I guess I now own that cognac back :)

on 13/11/2011 10:32 Kostik Belousov said the following:
I was tricked into finishing the work by Andrey Gapon, who developed the
patch to reliably stop other processors on panic. The patch greatly
improves the chances of getting dump on panic on SMP host. Several people
already saw the patchset, and I remember that Andrey posted it to some
lists.

The change stops other (*) processors early upon the panic. This way, no
parallel manipulation of the kernel memory is performed by CPUs. In
particular, the kernel memory map is static. Patch prevents the panic
thread from blocking and switching out.

* - in the context of the description, other means not current.

Since other threads are not run anymore, lock owner cannot release a lock
which is required by panic thread. Due to this, we need to fake a lock
acquisition after the panic, which adds minimal overhead to the locking
cost. The patch tries to not add any overhead on the fast path of the lock
acquire. The check for the after-panic condition was reduced to single
memory access, done only when the quick cas lock attempt failed, and
braced with __unlikely compiler hint.

For now, the new mode of operation is disabled by default, since some
further USB changes are needed to make USB keyboard usable in that
environment.

With the patch, getting a dump from the machine without debugger compiled
in is much more realistic. Please comment, I will commit the change in 2
weeks unless strong reasons not to are given.

http://people.freebsd.org/~kib/misc/stop_cpus_on_panic.1.patch



- --
Andriy Gapon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOwOYqAAoJEHSlLSemUf4v8VYH/13H/MXhxOc6Vz6r+M6x4yDn
03/TwS+QO7+689KEWvr5NQjPcV7cI3Ku3UIS3QlSUQIZYhhepJjK1UgQHM7ra5yr
qzXwpEEealJc7GKSjMTIAsjpfcPgRdT66nwymPZWS3ojZJVXYPiGmc4p3uDVrAgv
MnuKOdOVUaeI4tOqYa4wWoCSz++tTpbqIGQrlLTWn8yzhGDvNdj2YTEPoETbrTWO
E/t8r+BPqeE5pkJjEoDMOpdZqzBB/45x5krocVVCWZL8gt5hp7c5CutGe6lsJ3on
Agv5CGyCQb50AmyapDhc/miECtf4qEekFxO3wiqNBTgHxoN2uxvkIMvUhNlxqGg=
=yxdc
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • [ANNOUNCE] 2.6.31-rc4-rt1
    ... This is a major rework of the rt patch series. ... interrupt threading is now a pure extension of the mainline ... type in the lock definition. ...
    (Linux-Kernel)
  • Re: [ANNOUNCE] 2.6.31-rc4-rt1
    ... This is a major rework of the rt patch series. ... interrupt threading is now a pure extension of the mainline ... type in the lock definition. ...
    (Linux-Kernel)
  • Re: [PATCH] mmap: avoid unnecessary anon_vma lock acquisition in vma_adjust()
    ... can you grab Hugh's patch from his message? ... need the anon_vma lock when we're only adjusting the end of a vma, ... so simply avoid loading vma->anon_vma to avoid the lock. ...
    (Linux-Kernel)
  • Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler
    ... existed of a set of patches suitable ... plus an additional patch for Preempt-RT only. ... the splitup of the interrupt handler was also needed for ... * uart_start, which takes the lock. ...
    (Linux-Kernel)
  • Re: Stop scheduler on panic
    ... patch to reliably stop other processors on panic. ... parallel manipulation of the kernel memory is performed by CPUs. ... Since other threads are not run anymore, lock owner cannot release a lock ... Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ ...
    (freebsd-arch)