Problema hunk patch ck 2.6.35.2

[Blallo]

quando vado a "pacciare" il 2.6.35.2 con la patch di kolivas, mi viene fuori

Codice: Seleziona tutto

patching file mm/swapfile.c
Hunk #1 FAILED at 319.
Hunk #2 succeeded at 410 (offset 2 lines).
Hunk #4 succeeded at 721 (offset 2 lines).
1 out of 4 hunks FAILED -- saving rejects to file mm/swapfile.c.rej

qualcuno sa come risolvere il problema?

[slux]

Non ho provato la patch di Kolivas ,ma volevo chiederti se avevi applicato anche questa patch al 2.6.35.2 http://lkml.org/lkml/2010/8/14/96
Senza questa patch il kernel va in panic al boot.Testata personalmente.

[Blallo]

no, non l'ho applicata
e neppure ho testato, visto che voglio ricompilarlo per forza con la patch ck

[Mario Vanoni]

Lo stesso Con Kolivas su
http://lkml.indiana.edu/hypermail/linux ... 00148.html
ha dubbi sulla sua creatura.

Stefano (ansa89) ha modificato la patch-2.6.35-ck1
in modo che patchi senza Hunk sul 2.6.35.2.

Funziona perfettamanere, provato su una macchina:

2.6.35.2 vanilla
time make -j 2 bzImage
6m19.707s
sar 1 su uno schermo parallelo mostra rari 0.50%idle

2.6.35.2-ck1
time make -j 2 bzImage
6m24.966s
sar 1 su uno schermo parallelo mostra piu` spesso 0.51%idle

UPDATE
la variante di Stefano

[Blallo]

Grazie della risposta Mario
la testerò
mi puoi dare la patch?

[Mario Vanoni]

Grazie della risposta Mario
la testerò
mi puoi dare la patch?

Vedi l'update del mio post.
*ck1.txt perche' questo forum non accetta *-ck1, SIC!

[hashbang]

quando vado a "pacciare" il 2.6.35.2 con la patch di kolivas, mi viene fuori

Codice: Seleziona tutto

patching file mm/swapfile.c
Hunk #1 FAILED at 319.
Hunk #2 succeeded at 410 (offset 2 lines).
Hunk #4 succeeded at 721 (offset 2 lines).
1 out of 4 hunks FAILED -- saving rejects to file mm/swapfile.c.rej

qualcuno sa come risolvere il problema?

io patchai il 2.6.35 VANILLA con la patch ck e poi lo aggiornai con la patch 2.6.35.1 e nel make menuconfig il kernel era rilevato come: Linux 2.6.35.2-ck1 tutto ciò senza hunk nel patching (uso prima l'opzione --dry-run per testare la corretta applicazione delle patch). Comunque non l'ho mai testato con quella compilazione (feci solo il config poi ci rinunciai) però penso che potrebbe funzionare. Col 2.6.35.2 ho provato, col mio metodo, ma rompe le scatole perchè trova una precedente patch applicata (credo si riferisca a -ck1). Forse vanno in conflitto le due patch L'ho provato su una sorgente 2.6.35.2 e finisce con HUNK 1 file (swaprc credo)

[hashbang]

Non ho provato la patch di Kolivas ,ma volevo chiederti se avevi applicato anche questa patch al 2.6.35.2 http://lkml.org/lkml/2010/8/14/96
Senza questa patch il kernel va in panic al boot.Testata personalmente.

Strano io uso il 2.6.35.2 non patchato e funziona perfettamente non è che forse hai tolto qualche driver importante?

[hashbang]

Lo stesso Con Kolivas su
http://lkml.indiana.edu/hypermail/linux ... 00148.html
ha dubbi sulla sua creatura.

Stefano (ansa89) ha modificato la patch-2.6.35-ck1
in modo che patchi senza Hunk sul 2.6.35.2.

Funziona perfettamanere, provato su una macchina:

2.6.35.2 vanilla
time make -j 2 bzImage
6m19.707s
sar 1 su uno schermo parallelo mostra rari 0.50%idle

2.6.35.2-ck1
time make -j 2 bzImage
6m24.966s
sar 1 su uno schermo parallelo mostra piu` spesso 0.51%idle

UPDATE
la variante di Stefano

Mario come l'hai applicata questa patch?

[Mario Vanoni]

@atomix600
Mario come l'hai applicata questa patch?

tar xjf 2.6.35.2.tar.bz2
cd 2.6.35.2
cp -a patch-2.6.35-ck1 .
(quella di Stefano alias ansa89!!!)
patch -p 1 < patch-2.6.35-ck1

[hashbang]

@atomix600
Mario come l'hai applicata questa patch?

tar xjf 2.6.35.2.tar.bz2
cd 2.6.35.2
cp -a patch-2.6.35-ck1 .
(quella di Stefano alias ansa89!!!)
patch -p 1 < patch-2.6.35-ck1

Ah ecco perchè non riuscivo, io davo

Codice: Seleziona tutto

patch patch-2.6.35-ck1 -p1 (--dry-run)

e si bloccava.

[slux]

Non ho provato la patch di Kolivas ,ma volevo chiederti se avevi applicato anche questa patch al 2.6.35.2 http://lkml.org/lkml/2010/8/14/96
Senza questa patch il kernel va in panic al boot.Testata personalmente.

Strano io uso il 2.6.35.2 non patchato e funziona perfettamente non è che forse hai tolto qualche driver importante?

Non ho sbagliato niente.E' stato lo stesso Torvald ad ammettere l'errore.La patch è scritta proprio di sua mano.
A me il sistema si è avviato bene la prima volta,ma dopo un riavvio in seguito ad un kernel oops,la macchina andava sempre in panic.Ho riavviato con il kernel default,fatto 2 ricerche,applicato la patch e adesso funziona perfettamente.Il problema si manifesta se si attiva una voce nel config.Se leggi con calma il thread ti sarà tutto più chiaro.E' un problema di lock fra processi comunque.

[Mario Vanoni]

Non ho provato la patch di Kolivas ,ma volevo chiederti se avevi applicato anche questa patch al 2.6.35.2 http://lkml.org/lkml/2010/8/14/96
Senza questa patch il kernel va in panic al boot.Testata personalmente.

Strano io uso il 2.6.35.2 non patchato e funziona perfettamente non è che forse hai tolto qualche driver importante?

Non ho sbagliato niente.E' stato lo stesso Torvald ad ammettere l'errore.La patch è scritta proprio di sua mano.
A me il sistema si è avviato bene la prima volta,ma dopo un riavvio in seguito ad un kernel oops,la macchina andava sempre in panic.Ho riavviato con il kernel default,fatto 2 ricerche,applicato la patch e adesso funziona perfettamente.Il problema si manifesta se si attiva una voce nel config.Se leggi con calma il thread ti sarà tutto più chiaro.E' un problema di lock fra processi comunque.

E` forse questo problema?
http://lkml.indiana.edu/hypermail/linux ... 01883.html
http://lkml.indiana.edu/hypermail/linux ... 02066.html
Nel 2.6.35.2 e` risolto senza patch.

[hashbang]

grazie per la patch Mario sembra andare tutto ok

[slux]

E` forse questo problema?
http://lkml.indiana.edu/hypermail/linux ... 01883.html
http://lkml.indiana.edu/hypermail/linux ... 02066.html
Nel 2.6.35.2 e` risolto senza patch.

Non credo Mario.
Questo è quello che Linus ha chiesto nel thread indicato da me:

Just to verify: you have CONFIG_HIGHPTE enabled on a x86-32 kernel,
right?

Mi sembra un pò diverso.