El kernel 3.19 —el primero de 2015— ya está aquí para regocijo de todos los linuxeros de bien, que ya pueden descargarlo desde Kernel.org.
Este nuevo kernel también ha tenido sólo 7 release candidates, confirmándose la tendencia a acortarse las releases que describía Jonathan Corbet en su Kernel Report de la linux.conf.au 2015 (concretamente esta vez han sido 63 días, del 7 de diciembre al 8 de febrero).
En cuanto a las novedades de este kernel 3.19, tenéis la página
correspondiente de KernelNewbies y el seguimiento de
la merge window que hace LWN (1, 2 y
3) para una lista exhaustiva. No hay cosas significativas
que señalar en esta versión, la gran mayoría son cambios para soporte de
nuevo hardware, tanto drivers como architectura. De lo que no lo es, la
nueva system call execveat() y el soporte de RAID 5 y 6 en btrfs es
de lo que más puede llamar la atención. Del soporte para nuevo hardware,
las extensiones de protección de memoria Intel MPX es lo que más
destacará... cuando se dispongan de CPUs que lo soporten.
Y ahora hablemos de tiempos de compilación:
Compilando 3.17.7-amd64 desde 3.17.6-amd64 con -j4:
$ time fakeroot make-kpkg -j4 --initrd --revision=3.17.7+1 --append-to-version=-amd64 kernel_image kernel_headers
real 10m12.877s
user 24m40.804s
sys 1m36.644s
Compilando 3.18.1-amd64 desde 3.17.7-amd64 con -j4:
$ time fakeroot make-kpkg -j4 --initrd --revision=3.18.1+1 --append-to-version=-amd64 kernel_image kernel_headers
real 10m8.003s
user 24m57.948s
sys 1m36.812s
Compilando 3.18.2-amd64 desde 3.18.1-amd64 con -j4:
$ time fakeroot make-kpkg -j4 --initrd --revision=3.18.2+1 --append-to-version=-amd64 kernel_image kernel_headers
real 11m5.646s
user 24m53.180s
sys 1m36.780s
Compilando 3.18.3-amd64 desde 3.18.2-amd64 con -j4:
$ time fakeroot make-kpkg -j4 --initrd --revision=3.18.3+1 --append-to-version=-amd64 kernel_image kernel_headers
real 11m0.431s
user 24m58.016s
sys 1m36.740s
Compilando 3.18.4-amd64 desde 3.18.3-amd64 con -j4:
$ time fakeroot make-kpkg -j4 --initrd --revision=3.18.4+1 --append-to-version=-amd64 kernel_image kernel_headers
real 10m56.097s
user 24m59.228s
sys 1m35.992s
Compilando 3.18.5-amd64 desde 3.18.4-amd64 con -j4:
$ time fakeroot make-kpkg -j4 --initrd --revision=3.18.5+1 --append-to-version=-amd64 kernel_image kernel_headers
real 10m18.735s
user 24m50.244s
sys 1m36.060s
Compilando 3.18.6-amd64 desde 3.18.5-amd64 con -j4:
$ time fakeroot make-kpkg -j4 --initrd --revision=3.18.6+1 --append-to-version=-amd64 kernel_image kernel_headers
real 10m45.595s
user 24m46.096s
sys 1m34.616s
Los únicos cambios de código, aparte de los de pasar de la rama 3.17.x a
la 3.18.x (obvio), han sido en la 3.18.5, cuando quité todos los drivers
I²C excepto el i2c-i801, que es el que corresponde al chipset de mi
placa base (más sobre esto luego). Ya véis que los tiempos son muy
dispares, que varían casi un minuto, y no consigo imaginar por qué. Tal
vez debería empezar a mirar estrictamente tiempos de compilación,
dejando al margen la construcción de los paquetes .deb, que parece que
es una tarea bastante más pesada de lo que parece.
Bugs de la ACPI
Tengo un dispositivo PCI del que no tengo ningún driver gestionándolo:
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7751
Flags: medium devsel, IRQ 18
Memory at f7335000 (64-bit, non-prefetchable) [size=256]
I/O ports at f000 [size=32]
Estuve investigando un poco, porque pensé que se me había ido la mano borrando
opciones del kernel y había quitado algo que no debía. Tras un poco de
google-fu, encontré que el driver que daba soporte a este dispositivo
es drivers/i2c/busses/i2c-i801.c, y supuestamente el
chipset de mi placa (Intel 7 series/Panther Point) está soportado
desde hace tiempo.
He sido capaz de encontrar alguien con el mismo problema, por desgracia, tiene toda la pinta de ser un bug de la BIOS ACPI, ya que yo también tengo ese mensaje del kernel:
$ dmesg | grep -i ' error\|warn\|exception'
...
[ 6.718181] ACPI Warning: SystemIO range 0x000000000000f000-0x000000000000f01f conflicts with OpRegion 0x000000000000f000-0x000000000000f00f (\_SB_.PCI0.SBUS.SMBI) (20140926/utaddress-258)
...
Así que, aunque el driver está compilado, y tiene el soporte para el chipset, se da cuenta que ACPI le informa de problemas, y se niega a cargarse. La solución que propone ese mensaje es borrar la condición donde se comprueba el conflicto ACPI, que como os podéis imaginar como solución deja bastante que desear aunque funcionara.
Como la rama 3.19 tiene un par de commits sobre este fichero,
probaré primero por si suena la flauta. Y si no quedará para investigar
más adelante.:-/
NVIDIA tocando otra vez las...
Por si fuera poco, el driver de NVIDIA resulta que está haciendo otra vez de las suyas, aunque afortunadamente esta vez no afecta al funcionamiento de nada. Lo más que está haciendo es sacar unos Warnings muy feos en el log del kernel porque no es capaz de encontrar cierta función:
[ 13.763890] ------------[ cut here ]------------
[ 13.763901] WARNING: CPU: 2 PID: 860 at drivers/gpu/drm/drm_ioctl.c:143 drm_setversion+0xdc/0x174 [drm]()
[ 13.763936] No drm_driver.set_busid() implementation provided by nvidia_frontend_exit_module [nvidia]. Use drm_dev_set_unique() to set the unique n
ame explicitly.
[ 13.763937] Modules linked in:
[ 13.763938] x86_pkg_temp_thermal crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic aesn
i_intel snd_hda_intel aes_x86_64 snd_hda_controller ablk_helper cryptd nvidia(PO) snd_hda_codec snd_pcsp lrw snd_hwdep snd_pcm_oss gf128mul snd_mixer_
oss snd_pcm evdev glue_helper mxm_wmi drm iTCO_wdt iTCO_vendor_support microcode i2c_i801 i2c_core snd_timer acpi_cpufreq ie31200_edac edac_core mei_m
e mei xhci_pci xhci_hcd wmi battery lpc_ich mfd_core processor video button snd soundcore shpchp f71882fg coretemp loop firewire_sbp2 fuse autofs4 ext
4 crc16 jbd2 mbcache hid_generic usbhid hid sg sr_mod sd_mod cdrom ata_generic ahci libahci libata ehci_pci firewire_ohci ehci_hcd firewire_core crc_i
tu_t scsi_mod e1000e usbcore ptp usb_common pps_core thermal
[ 13.763962] fan thermal_sys
[ 13.763964] CPU: 2 PID: 860 Comm: Xorg Tainted: P O 3.18.6-amd64 #1
[ 13.763965] Hardware name: MSI MS-7751/Z77A-GD65 (MS-7751), BIOS V10.2 02/27/2012
[ 13.763966] 0000000000000000 0000000000000009 ffffffff8138d549 ffff880214d2fd58
[ 13.763968] ffffffff81039b5f ffff880214d2fdec ffffffffa031aa1d 0000800215306029
[ 13.763969] ffff8800d9864800 ffff880214d2fe10 ffff880215bb9f40 0000000000000010
[ 13.763970] Call Trace:
[ 13.763974] [<ffffffff8138d549>] ? dump_stack+0x41/0x51
[ 13.763977] [<ffffffff81039b5f>] ? warn_slowpath_common+0x78/0x90
[ 13.763981] [<ffffffffa031aa1d>] ? drm_setversion+0xdc/0x174 [drm]
[ 13.763982] [<ffffffff81039bbc>] ? warn_slowpath_fmt+0x45/0x4a
[ 13.763986] [<ffffffffa031aa1d>] ? drm_setversion+0xdc/0x174 [drm]
[ 13.763989] [<ffffffffa031a7a6>] ? drm_ioctl+0x37d/0x3e1 [drm]
[ 13.763992] [<ffffffffa031a941>] ? drm_version+0x88/0x88 [drm]
[ 13.763996] [<ffffffff8111f796>] ? do_filp_open+0x2b/0x6f
[ 13.763998] [<ffffffff81120b4a>] ? do_vfs_ioctl+0x34e/0x404
[ 13.763999] [<ffffffff81120c51>] ? SyS_ioctl+0x51/0x77
[ 13.764001] [<ffffffff81390d52>] ? system_call_fastpath+0x12/0x17
[ 13.764002] ---[ end trace f51b1c782d7d2ddb ]---
[ 14.654732] nvidia 0000:01:00.0: irq 31 for MSI/MSI-X
Y así cuatro veces, una por procesador (no lo voy a poner por cuadruplicado).
Parece que es un problema de integración con los kernel 3.18.x, lo que pasa por la puñetera cabezonería de NVIDIA de esconder su código, no jugar con las reglas de upstream y no tener el driver DRM integrado en el kernel. Los desarrolladores de Linux rompen APIs internas, y los de NVIDIA tienen que ir por detrás arreglando el código de "pegamento" con su blob, y los que salimos perdiendo somos los usuarios (esta vez no, pero otras veces no nos queda más remedio que buscarnos la vida para averiguar qué demonios pasa, y parchear los drivers a mano).
:wq