Aplicando RT_PREEMPT

Estoy tratando de instalar un kernel con el parche RT_PREEMPT en una distribución de Lubuntu 16.04 y me encuentro con algunos problemas que no estoy seguro de cómo lidiar. He descargado las fonts para kernel v4.4.12 (linux-4.4.12.tar.xz) y lo que creo que es el parche RT_PREEMPT apropiado (patches-4.4.12-rt20.tar.xz), ambos de kernel. org. Extraje las fonts del núcleo con tar xf , cd 'd en el directory, luego trato de aplicar el parche con xzcat ../patches-4.4.12.tar.xz | patch -p1 xzcat ../patches-4.4.12.tar.xz | patch -p1 (por recomendaciones aquí: https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO ). Este command solo genera una gran cantidad de errores quejándose de parches para files que no existen, parches previamente aplicados, trozos fallidos, etc. Algunos de los trozos de parches parecen tener éxito, pero muchos de ellos fallan.

Este no puede ser el medio correcto para parchear este kernel ¿o sí? ¿Alguna idea de dónde me estoy equivocando?

EDITAR: Aquí hay una muestra que cubre los types de errores que estoy viendo:

 rush@lubuntuvm:~/preempt-rt/linux-4.4.12$ xzcat ../patches-4.4.12-rt20.tar.xz | patch -p1 patching file arch/x86/kernel/nmi.c Hunk #1 FAILED at 231. Hunk #2 FAILED at 256. Hunk #3 FAILED at 305. 3 out of 3 hunks FAILED -- saving rejects to file arch/x86/kernel/nmi.c.rej patching file arch/x86/kernel/reboot.c patching file include/linux/kernel.h Hunk #1 succeeded at 255 (offset -4 lines). Hunk #2 FAILED at 460. 1 out of 2 hunks FAILED -- saving rejects to file include/linux/kernel.h.rej patching file kernel/panic.c Hunk #1 FAILED at 61. 1 out of 1 hunk FAILED -- saving rejects to file kernel/panic.c.rej patching file kernel/watchdog.c Hunk #1 FAILED at 361. 1 out of 1 hunk FAILED -- saving rejects to file kernel/watchdog.c.rej patching file kernel/stop_machine.c Hunk #12 succeeded at 482 (offset -10 lines). Hunk #13 succeeded at 544 (offset -10 lines). Hunk #14 succeeded at 648 (offset -10 lines). patching file block/blk-mq.c Reversed (or previously applied) patch detected! Assume -R? [n] n Apply anyway? [n] Skipping patch. 3 out of 3 hunks ignonetworking -- saving rejects to file block/blk-mq.c.rej patching file block/blk-mq.h Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 3 out of 3 hunks ignonetworking -- saving rejects to file block/blk-mq.h.rej patching file net/core/dev.c Hunk #1 succeeded at 3542 (offset -3 lines). Hunk #2 succeeded at 3552 (offset -3 lines). patching file arch/arm64/Kconfig patching file arch/arm64/include/asm/thread_info.h patching file arch/arm64/kernel/asm-offsets.c patching file arch/arm64/kernel/entry.S can't find file to patch at input line 794 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |-- |2.8.1 | |patches/0026-hwlat-detector-Use-trace_clock_local-if-available.patch0000644001303100130310000000625512741715155025466 0ustar rostedtrostedtFrom c184dd4a4a5d88b3223704297a42d1aaab973811 Mon Sep 17 00:00:00 2001 |From: Steven Rostedt <rostedt@goodmis.org> |Date: Mon, 19 Aug 2013 17:33:26 -0400 |Subject: [PATCH 026/351] hwlat-detector: Use trace_clock_local if available | |As ktime_get() calls into the timing code which does a read_seq(), it |may be affected by other CPUS that touch that lock. To remove this |dependency, use the trace_clock_local() which is already exported |for module use. If CONFIG_TRACING is enabled, use that as the clock, |otherwise use ktime_get(). | |Signed-off-by: Steven Rostedt <srostedt@networkinghat.com> |Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> |--- | drivers/misc/hwlat_detector.c | 34 +++++++++++++++++++++++++--------- | 1 file changed, 25 insertions(+), 9 deletions(-) | |diff --git a/drivers/misc/hwlat_detector.cb/drivers/misc/hwlat_detector.c |index c07e85932cbf..0fcc0e38df42 100644 |--- a/drivers/misc/hwlat_detector.c |+++ b/drivers/misc/hwlat_detector.c 

Probablemente haya querido tomar el patch-4.4.12-rt20.patch.xz , no patches-4.4.12-rt20.tar.xz . Como lo indica la extensión, este último es un file tar, no un solo file de parche. Aparentemente contiene los mismos parches que la versión de file único, pero con posts de confirmación, etc.

patch es lo suficientemente inteligente como para ignorar cosas inútiles (como la estructura del file tar, al parecer), por lo que algunos de los parches funcionan. Pero supongo que los parches de los componentes pueden depender el uno del otro, y estar en el order incorrecto en el file tar, por lo que no se aplica limpiamente.