En vez de hacer una entrada por cada nuevo kernel compilado, esta vez voy a agrupar las últimas compilaciones de kernels y resultados aquí, empezando por los tiempos de compilación:

$ time fakeroot make-kpkg -j4 --initrd --revision=3.12.13+1 --append-to-version=-amd64 kernel_image kernel_headers
real    12m55.263s
user    29m59.608s
sys     2m3.548s
$ time fakeroot make-kpkg -j4 --initrd --revision=3.13.5+1 --append-to-version=-amd64 kernel_image kernel_headers
real    13m11.417s
user    30m54.280s
sys     2m5.692s
$ time fakeroot make-kpkg -j4 --initrd --revision=3.13.6+1 --append-to-version=-amd64 kernel_image kernel_headers
real    13m22.339s
user    30m31.608s
sys     2m5.476s
$ time fakeroot make-kpkg -j4 --initrd --revision=3.13.7+1 --append-to-version=-amd64 kernel_image kernel_headers
real    13m28.211s
user    30m30.240s
sys     2m4.628s

Como se puede observar, el tiempo de compilación cada vez se eleva más. Evidentemente con nuevas versiones suele haber más código que compilar. Lo que no queda muy claro es porqué se disparó entonces en la versión 3.12.13 (he estado mirando si podría deberse a cambios en el compilador, pero es difícil decir si los parches que está añadiendo Debian a gcc 4.8.2 podrían afectar a la velocidad de compilación).

Crash cpufreq del modulo NVIDIA

(Ver aquí para más señas)

Cambié al kernel 3.13.5 el 27 de febrero después de un crash con el 3.12.13 y el nuevo driver de NVIDIA 331.49 (que evidentemente no arregló nada). Cuando salió, salté al 3.13.6, que no tiene cambios en el módulo drivers/cpufreq/cpufreq.c respecto al 3.13.5, así que se puede considerar a efectos prácticos el mismo testbed. En un mes he tenido 5 crashes más del módulo al arrancar (curiosamente todos en la 3.13.6, aunque eso es "ruido estadístico"), lo que calculo que es aproximadamente un 6% de todos los arranques, en línea con los resultados anteriores.

Mi esperanza ahora reside en los cambios en cpufreq.c del kernel 3.13.7, en concreto este y este:

cpufreq: use cpufreq_cpu_get() to avoid cpufreq_get() race conditions

commit 999976e0f6233322a878b0b7148c810544d6c8a8 upstream.

If a module calls cpufreq_get while cpufreq is initializing, it's possible for it to be called after cpufreq_driver is set but before cpufreq_cpu_data is written during subsys_interface_register. This happens because cpufreq_get doesn't take the cpufreq_driver_lock around its use of cpufreq_cpu_data.

cpufreq: Skip current frequency initialization for ->setpolicy drivers

commit 2ed99e39cb9392312c100d9da591c20641c64d12 upstream.

After commit da60ce9f2fac (cpufreq: call cpufreq_driver->get() after calling ->init()) __cpufreq_add_dev() sometimes fails for CPUs handled by intel_pstate, because that driver may return 0 from its ->get() callback if it has not run long enough to collect enough samples on the given CPU. That didn't happen before commit da60ce9f2fac which added policy->cur initialization to __cpufreq_add_dev() to help reduce code duplication in other cpufreq drivers.

Esto tiene buena pinta, pero no sería la primera vez que me llevo un chasco con estos fixes, así que a esperar a ver que pasa con este kernel.

:wq