Aplicando RT_PREEMPT

Question

Estou tentando instalar um kernel com o patch RT_PREEMPT em uma distro Lubuntu 16.04 e me deparo com alguns problemas que não sei como lidar. Eu fiz o download dos fontes para o kernel v4.4.12 (linux-4.4.12.tar.xz) e o que eu acredito ser o patch RT_PREEMPT apropriado (patches-4.4.12-rt20.tar.xz), ambos do kernel. org. Eu extraí as fontes do kernel com tar xf , cd 'd no diretório, então eu tento aplicar o patch com xzcat ../patches-4.4.12.tar.xz | patch -p1 (por recomendações aqui: link ). Este comando apenas gera uma grande quantidade de erros reclamando sobre patches para arquivos que não existem, patches aplicados anteriormente, pedaços falhos, etc. Alguns dos fragmentos de correção parecem ter sucesso, mas muitos deles falham.

Este não pode ser o meio correto para corrigir este kernel, não é? Alguma ideia de onde estou errado?

EDIT: Aqui está um exemplo que cobre os tipos de erros que estou vendo:

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 ignored -- 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 ignored -- 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 <[email protected]>
|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 <[email protected]>
|Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
|---
| drivers/misc/hwlat_detector.c | 34 +++++++++++++++++++++++++---------
| 1 file changed, 25 insertions(+), 9 deletions(-)
|
|diff --git a/drivers/misc/hwlat_detector.c b/drivers/misc/hwlat_detector.c
|index c07e85932cbf..0fcc0e38df42 100644
|--- a/drivers/misc/hwlat_detector.c
|+++ b/drivers/misc/hwlat_detector.c

    

Answer 1

Você provavelmente queria usar patch-4.4.12-rt20.patch.xz , não patches-4.4.12-rt20.tar.xz . Como a extensão sugere, o último é um arquivo tar, não um único arquivo de correção. Aparentemente, ele contém os mesmos patches que a versão de arquivo único, mas com mensagens de confirmação, etc.

patch é inteligente o suficiente para ignorar coisas inúteis (como a estrutura do arquivo tar, aparentemente), então algumas das correções funcionam. Mas suponho que os patches dos componentes possam depender um do outro e estarem na ordem errada no arquivo tar, por isso não se aplica de forma limpa.