BFS e kernel 2.6.32.7[RISOLTO]

[Blallo]

Qualcuno è riuscito a patchare il 2.6.32.7 con la ck2?
da un hunk di troppo (makefile + altro)
nemmeno Mario è riuscito a risolverlo
siete a conoscenza di qualche patch/rimedio?

[Toni]

Codice: Seleziona tutto

--- linux-2.6.32-ck2.orig/init/calibrate.c	2009-12-29 10:13:33.337068516 +1100
+++ linux-2.6.32-ck2/init/calibrate.c	2009-12-29 10:19:21.515819654 +1100
@@ -172,5 +172,5 @@ void __cpuinit calibrate_delay(void)
 	}
 	printk(KERN_CONT "%lu.%02lu BogoMIPS (lpj=%lu)\n",                       <------------------ motivo per cui la patch viene rigettata
 			loops_per_jiffy/(500000/HZ),
-			(loops_per_jiffy/(5000/HZ)) % 100, loops_per_jiffy);
+			(loops_per_jiffy * 10 /(50000/HZ)) % 100, loops_per_jiffy);
 }

Ciao,
Applica la patch ck2 normalmente , poi con un editor apri il file init/calibrate.c e modifichi l'ultima riga cioè:

Codice: Seleziona tutto

(loops_per_jiffy/(5000/HZ)) % 100, loops_per_jiffy);

in

Codice: Seleziona tutto

(loops_per_jiffy * 10 /(50000/HZ)) % 100, loops_per_jiffy);

a questo punto ricompila tutto.


UPDATE:
il codice del 2.6.32.7 vanilla è questo:

Codice: Seleziona tutto

}
	if (!printed)
		pr_cont("%lu.%02lu BogoMIPS (lpj=%lu)\n",
			loops_per_jiffy/(500000/HZ),
			(loops_per_jiffy/(5000/HZ)) % 100, loops_per_jiffy);

è evidente il motivo del reject.
ciao

[Ansa89]

Oppure si potrebbe correggere la patch cambiando

Codice: Seleziona tutto

printk(KERN_CONT "%lu.%02lu BogoMIPS (lpj=%lu)\n",

con

Codice: Seleziona tutto

pr_cont("%lu.%02lu BogoMIPS (lpj=%lu)\n",

Giusto?

[Ansa89]

Offtopic: Come si fa a commentare delle righe in un file diff?

[Ansa89]

Resoconto: ho modificato la patch togliendo l'hunk relativo al "Makefile" (perché non mi interessava) e provando ad aggiustare quello relativo a "init/calibrate.c".
Risultato:

Codice: Seleziona tutto

patching file init/calibrate.c
Hunk #1 succeeded at 176 with fuzz 2.

Non so cosa voglia dire "fuzz 2", però la patch va a buon fine .

[shark1500]

Significa che ha sforato la riga ma che diff ha risolto .

Comunque non riallegare la patch di ck, ma allena una patch da mettere prima di quella di ck che fa in modo che dopo mettendo quella di ck funzioni tutto

[Blallo]

perfetti ragazzi, compila, funziona...e il 2.6.32.7 è una bomba!

[Ansa89]

Comunque non riallegare la patch di ck, ma allena una patch da mettere prima di quella di ck che fa in modo che dopo mettendo quella di ck funzioni tutto

Tolto l'allegato, ma non sono capace di creare una patch; finirebbe che faccio un casino colossale e non serve a niente .

[Mario Vanoni]

perfetti ragazzi, compila, funziona...e il 2.6.32.7 è una bomba!

Dati, stesso computer/OS/gcc:
kernel con patch -bfs313:
make - j 2 bzImage sui 5m33 ... 5m42
kernel 2.6.32.6-ck2
make - j 2 bzImage 5m21
kernel 2.6.33-rc6
make - j 2 bzImage 5m33
make - j 3 bzImage 5m31
make - j 4 bzImage 5m32

Quintessenza:
Ingo Molnar nel suo CFS ha incorporato idee BFS di Con Kolivas

Domanda:
Ha senso di appoggiare i kernel -stable,
unicamente perche' interessano le distro LTS?
Non e` meglio appoggiare Linus Torwalds?

[Ansa89]

Domanda:
Ha senso di appoggiare i kernel -stable,
unicamente perche' interessano le distro LTS?
Non e` meglio appoggiare Linus Torwalds?

Non ho capito la domanda .
L'accento era sul fatto che si usano energie per mantenere un kernel LTS, quando sarebbe meglio concentrarsi sul progredire del codice (vedi il caso delle migliorie dello scheduler)?

[Mario Vanoni]

Domanda:
Ha senso di appoggiare i kernel -stable,
unicamente perche' interessano le distro LTS?
Non e` meglio appoggiare Linus Torwalds?

Non ho capito la domanda .
L'accento era sul fatto che si usano energie per mantenere un kernel LTS, quando sarebbe meglio concentrarsi sul progredire del codice (vedi il caso delle migliorie dello scheduler)?

http://www.kernel.org/

mainline: 2.6.33-rc6 2010-01-29 [Full Source] [Patch] [View Patch] [View Inc.] [Gitweb] [Changelog]
stable: 2.6.32.7 2010-01-28 [Full Source] [Patch] [View Patch] [View Inc.] [Gitweb] [Changelog]
stable: 2.6.31.12 2010-01-18 [Full Source] [Patch] [View Patch] [View Inc.] [Gitweb] [Changelog]
stable: 2.6.30.10 2009-12-04 [Full Source] [Patch] [View Patch] [View Inc.] [Gitweb] [Changelog]
stable: 2.6.27.45 2010-01-28 [Full Source] [Patch] [View Patch] [View Inc.] [Gitweb] [Changelog]
stable: 2.4.37.9 2010-02-01 [Full Source] [Patch] [View Patch] [Gitweb] [Changelog]

Non sarebbe meglio mettere tutte le risorse sulla mainline?
Le stable servono unicamente ad allungare la vita delle distro LTS.

Preferisco un kernel, magari non al 100% stabile,
ma che abbia gli ultimi progressi raggiunti da menti capaci di innovazione,
e non da menti rivolte solo e continuamente alla retro compatibilita` per tot anni!
Vedi
http://lkml.indiana.edu/hypermail/linux ... 00858.html

2.6.32-stable
I'd like to announce that the 2.6.32-stable tree is also going to be
maintained as a "long-term" stable release, living for 2-3 years, like
the 2.6.27 kernel is. This is because a number (i.e. more than 2) Linux
distributions are basing their "enterprise" releases on this kernel
version, and it will make their lives easier if I keep it alive.

Tra 2-3 anni Linus Torwalds sara` magari al kernel 2.6.39!

[Toni]

Non sarebbe meglio mettere tutte le risorse sulla mainline?
Le stable servono unicamente ad allungare la vita delle distro LTS.

No,
Semplicemente per il fatto che il kernel è solo una piccola parte di una distro.

Differenti major release (esempio 2.6.27.x vs 2.6.32.x) comportano notevoli differenze nel restante 98 % di software di cui è composta una distro.

[Ansa89]

il kernel è solo una piccola parte di una distro.

Piccola parte _ESSENZIALE_.

[conraid]

Preferisco un kernel, magari non al 100% stabile,
ma che abbia gli ultimi progressi raggiunti da menti capaci di innovazione,
e non da menti rivolte solo e continuamente alla retro compatibilita` per tot anni!
Vedi
http://lkml.indiana.edu/hypermail/linux ... 00858.html

2.6.32-stable
I'd like to announce that the 2.6.32-stable tree is also going to be
maintained as a "long-term" stable release, living for 2-3 years, like
the 2.6.27 kernel is. This is because a number (i.e. more than 2) Linux
distributions are basing their "enterprise" releases on this kernel
version, and it will make their lives easier if I keep it alive.

la parola magica è proprio "enterprise". In quei contesti si preferisce un kernel stabile al 100% rispetto ad uno che abbia tutti gli ultimi progressi, e mi sembra anche normale

[Mario Vanoni]

Non sarebbe meglio mettere tutte le risorse sulla mainline?
Le stable servono unicamente ad allungare la vita delle distro LTS.

No,
Semplicemente per il fatto che il kernel è solo una piccola parte di una distro.

Differenti major release (esempio 2.6.27.x vs 2.6.32.x) comportano notevoli differenze nel restante 98 % di software di cui è composta una distro.

Osservazione di fatti reali.
Uso Slackware 12.2 su tre macchine,
aggiornando quello che mi convince.

Non aggiornero` alla 13.0, man che meno alla 13 -current,
la 13.1 mi puzza gia` adesso di esperimento, aspettero` magari la 13.3!

Il kernel di base della 12.2 e` il 2.6.27.7.

Ho aggiornato man mano i kernel,
mai problemi di stabilita` ecc. ecc.

Ora sono al kernel 2.6.33-rc6, tutto sempre perfetto.

Non capisco veramente dove sia il problema ad aggiornare il kernel.