+#. FIXME prlimit() does not suffer
+#. https://bugzilla.kernel.org/show_bug.cgi?id=5042
+#. http://sources.redhat.com/bugzilla/show_bug.cgi?id=12201
+#. Since versions 2.13, glibc has library implementations of
+#. getrlimit() and setrlimit() that use prlimit() to work around
+#. this bug.
+#. type: Plain text
+#: build/C/man2/getrlimit.2:540
+msgid ""
+"In older Linux kernels, the B<SIGXCPU> and B<SIGKILL> signals delivered when "
+"a process encountered the soft and hard B<RLIMIT_CPU> limits were delivered "
+"one (CPU) second later than they should have been. This was fixed in kernel "
+"2.6.8."
+msgstr ""
+
+#. see http://marc.theaimsgroup.com/?l=linux-kernel&m=114008066530167&w=2
+#. type: Plain text
+#: build/C/man2/getrlimit.2:548
+msgid ""
+"In 2.6.x kernels before 2.6.17, a B<RLIMIT_CPU> limit of 0 is wrongly "
+"treated as \"no limit\" (like B<RLIM_INFINITY>). Since Linux 2.6.17, "
+"setting a limit of 0 does have an effect, but is actually treated as a limit "
+"of 1 second."
+msgstr ""
+
+#. See https://lwn.net/Articles/145008/
+#. type: Plain text
+#: build/C/man2/getrlimit.2:553
+msgid ""
+"A kernel bug means that B<RLIMIT_RTPRIO> does not work in kernel 2.6.12; the "
+"problem is fixed in kernel 2.6.13."
+msgstr ""
+
+#. see http://marc.theaimsgroup.com/?l=linux-kernel&m=112256338703880&w=2
+#. type: Plain text
+#: build/C/man2/getrlimit.2:564
+msgid ""
+"In kernel 2.6.12, there was an off-by-one mismatch between the priority "
+"ranges returned by B<getpriority>(2) and B<RLIMIT_NICE>. This had the "
+"effect that the actual ceiling for the nice value was calculated as I<19\\ "
+"-\\ rlim_cur>. This was fixed in kernel 2.6.13."
+msgstr ""
+
+#. The relevant patch, sent to LKML, seems to be
+#. http://thread.gmane.org/gmane.linux.kernel/273462
+#. From: Roland McGrath <roland <at> redhat.com>
+#. Subject: [PATCH 7/7] make RLIMIT_CPU/SIGXCPU per-process
+#. Date: 2005-01-23 23:27:46 GMT
+#. Tested Solaris 10, FreeBSD 9, OpenBSD 5.0
+#. FIXME https://bugzilla.kernel.org/show_bug.cgi?id=50951