Acpi patch lässt sich nicht fehlerfrei auf 2.6.17 anwenden

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
Antworten
neuliing
Beiträge: 36
Registriert: 30.04.2006 22:25:52

Acpi patch lässt sich nicht fehlerfrei auf 2.6.17 anwenden

Beitrag von neuliing » 21.09.2006 00:11:39

Hallo, bisher habe ich mir immer den aktuellen stabilen Acpi Patch besorgt und dann dazu den passenden vanilla Kernel. Leider funktioniert das diesmal nicht, da ich beim Patchen Fehlermeldungen bekomme. Meine Suche hat mich auf folgenden Thread gebracht, wo jemand ein ähnliches Problem hat. Leider verstehe ich die Antwort des anderen Typen nicht. Kann mich jemand erleuchten?
Hier ist der Thread: http://marc.theaimsgroup.com/?l=linux-a ... 720566&w=2

Benutzeravatar
me
Beiträge: 868
Registriert: 30.10.2005 00:14:23
Lizenz eigener Beiträge: GNU General Public License
Wohnort: Paderborn
Kontaktdaten:

Beitrag von me » 21.09.2006 00:19:03

also du solltest erstmal ein nopaste mit allem erstellen.
und / oder du kannst ja einfach mal den neuen 2.6.18er kernel ausprobieren.
Anytime if we think we were right,
we were maybe wrong.

neuliing
Beiträge: 36
Registriert: 30.04.2006 22:25:52

Beitrag von neuliing » 21.09.2006 02:11:18

http://pastebin.com/790937

Der 18er ist doch noch nicht stable oder sind RCs stable?

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Beitrag von storm » 21.09.2006 07:31:37

Seit Dienstag ist 2.6.18 stable.

Zu deiner Frage: der Patch, den du einspielen wolltest, gehört eigentlich zu 2.6.18-rc1 und nicht zu 2.6.17. Len Brown beschreibt ja das Dilemma mit den nicht mehr existierenden Entwicklerversionen vom Kernel. Nach der Freigabe von 2.6.17 werden die reinkomenden Patches für 2.6.18(-rc1) in den *bestehende* Zweig eingepflegt, ohne dass sich der Name des Kernels ändert. Da du aber beim runterladen von 2.6.17 ältere Quellen bekommst, als die aus dem git-Zweig, schlägt das Patchen schon Mal fehl.
Wenn du also das Aktuellste aus der acpi-Entwicklung haben willst, solltest du einen git-Zweig haben oder dir immer den letzten Snapshot zum Zeitpunkt der Veröffentlichung des Patches ziehen.

ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

neuliing
Beiträge: 36
Registriert: 30.04.2006 22:25:52

Beitrag von neuliing » 21.09.2006 16:25:14

Mal sehen ob ich das richtig verstanden habe: Solange der 2.6.18 noch rc status hatte, wurden fleißig dafür acpi patches gebaut, die aber dann in den letzten stabilen kernel (2.6.17) Ordner gestellt. Stimmt das soweit?
Wie komme ich denn an den patch für den 2.6.17er Kernel? Die Version, die in dem o.g. Thread als fukntionsfähig beschrieben wird, läuft bei mir auch nicht fehlerfrei durch.

EDIT: der 2.6.18er ACPI patch ist aber noch RC, also nicht stable

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Beitrag von storm » 21.09.2006 18:13:50

neuliing hat geschrieben:Mal sehen ob ich das richtig verstanden habe: Solange der 2.6.18 noch rc status hatte, wurden fleißig dafür acpi patches gebaut, die aber dann in den letzten stabilen kernel (2.6.17) Ordner gestellt. Stimmt das soweit?
Aeh, nicht wirklich.
Ich versuchs nochmal:
Len Brown hat geschrieben: They don't apply because they're already in 2.6.17-git*,
which is where you should go to get the latest upstream.
(or apply -mm to get even later than that)
Was soviel heisst wie: der Patch den du einspielen wolltest, ist aus 2.6.17-git* [dem git-Zweig]. Dieser Quellcode ist bereits neuer als der 2.6.17-stable den du hast.
Und:
Linus' upstream tree continues to be named 2.6.17 for the period
after 2.6.18 integration is opened, but before 2.6.18-rc1 is declared.
We go through this naming issue every release.
Im Makefile des Kernels steht zwar noch 2.6.17 drin, aber er ist schon weiter.

Code: Alles auswählen

Zeitlinie:

2.6.17  -------> git*   -------> 2.6.18-rc1
release             |                 |_ nächster Zweig in der Entwicklung
    |               |
    |               |_ aktueller Entwicklungsstand beim Extrahieren des Patches
    |
    |__ deine Kernelquellen
Wie komme ich denn an den patch für den 2.6.17er Kernel? Die Version, die in dem o.g. Thread als fukntionsfähig beschrieben wird, läuft bei mir auch nicht fehlerfrei durch.
Weil auch diese Version zum git-Zweig gehört. Du brauchst aber deinen Kernel nicht zu patchen, da der aktuelle Stand von acpi im (stable) Kernel vorhanden ist. Diese Patches sind imo für Entwickler gedacht, die einen eigenen git-Zweig haben oder ihre Kernel aus selbigem erstellen. Das kann sogar bedeuten, dass du deinen Kernel durch das Einspielen des Patches instabil machst, er kann abstürzen oder oops'en.

Jetzt etwas klarer?
EDIT: der 2.6.18er ACPI patch ist aber noch RC, also nicht stable
Siehe oben. Du brauchst für den 2.6.18 keinen extra Patch, da dort die aktuellste Version von acpi drin ist.


ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

neuliing
Beiträge: 36
Registriert: 30.04.2006 22:25:52

Beitrag von neuliing » 21.09.2006 23:30:32

der Patch den du einspielen wolltest, ist aus 2.6.17-git* [dem git-Zweig]. Dieser Quellcode ist bereits neuer als der 2.6.17-stable den du hast.
wenn der neuer ist als 2.6.17 stable muss es doch ein 2.6.18er sein oder?
Weil auch diese Version zum git-Zweig gehört. Du brauchst aber deinen Kernel nicht zu patchen, da der aktuelle Stand von acpi im (stable) Kernel vorhanden ist
Gut zu wissen. Meine letzten drei Kernel habe ich dann wohl immer verhunzt (hat aber trotzdem funktioniert)
Heißt das etwa ich muss den suspend2disk patch auch nicht extra reinpacken?

Im Übrigen: Danke für deine Ausführungen.

storm
Beiträge: 1581
Registriert: 01.05.2004 13:21:26
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: DE

Beitrag von storm » 22.09.2006 17:00:20

neuliing hat geschrieben: wenn der neuer ist als 2.6.17 stable muss es doch ein 2.6.18er sein oder?
Nein, siehe Zeitlinie oben. Der wird mal ein 2.6.18, aber erst nach den release candidates. Das ist wie mit den ganzen und den reellen Zahlen. :)


Heißt das etwa ich muss den suspend2disk patch auch nicht extra reinpacken?
Ich weiss nicht, welchen Patch du da nimmst, wenn dein Kernel ohne Probleme übersetzt wird und läuft, lass es einfach so. Wenn das Patchen schon nur mit Fehlern oder Warnungen geht, dann solltest du nicht patchen.

ciao, storm
drivers/ata/libata-core.c: /* devices which puke on READ_NATIVE_MAX */

Antworten