Siduction Forum
Siduction Forum => Experimental => Topic started by: agaida on 2011/01/06, 14:18:45
-
Hi, ein kleines Problem. Es ist ja schön, dass es am Morgen nach der Freigabe des .37 einen slh-Kernel gib. Was nicht schön ist - fglrx baut wie immer nicht mit diesem Kernel.
Das ist ja auch nicht weiter schlimm, dann ist der halt erst mal gestrichen. Aber WZT: Ich habe eine .37-rc-Kernel auf Arch am laufen, der baut diese blöden Module. Von den Patches sieht soweit auch alles so schlecht nicht aus. Was hab ich mit firegl am Start, kann man das irgendwie rauspatchen oder brauche ich die firegl-Objekte für fglrx?
Letzte Frage, die sich stellt: Gehört so was in die Update-Warnungen oder ist das mit dem nicht funktionierenden neuen Kernel ein Aptosid-Gemeinplatz? Ich will nicht wieder auf den radeon.
-
Hi agaida,
ich gebe dir Recht so was gehört normalerweise in die Update-Warnungen mit detailierten Hinweisen bei welcher Config das das Problem auftritt.
-
Problem gelöst: Man entsorge den slh-Kernel und zwar mit allen Sachen, von denen ich nicht weiss, ob ich sie brauche und was darin so alles verbaut ist. Dann nehme man den 37-rc7 aus experimental. Auch noch ein Reinfall - ein wesentliches Modul fehlt wie immer. linux-kbuild-2.6.37. Kurzer Fluch, man schweint sich das zusammen und installiert das. Dananch darf man auch die Kernel-Header für 2.6.37-rc7 installieren. Damit kann man dann auch den Ati-treiber basteln und per dpkg -i ins System blasen. Hurra, die Kernel-Module bauen auch ganz brav mit.
Ich habe keine Probleme damit, ein definitives Problem zu umgehen. Das kanns aber nicht sein. Wenn ein Kernel veröffentlicht wird, der nicht tut, sollte zumindest noch der Vorgänger da sein. Ich hab aber keine Chance mehr, an einen funktionierenden 2.6.36 - meinetwegen auch von slh - zu kommen. Das ist großer Mist. Ich weiss jetzt nicht, ob ich da überreagiere, aber die Funktionsfähigkeit meines Systems soll eigentlich nach der Freigabe eines Aptosid-Kernels noch vollständig gewährleistet sein. Das sollte auch für solche Kleinigkeiten wie proprietäre Treiber gelten. Wie man sieht, geht das sogar mit debian-Boardmitteln.
@bluelupo: Unsere Postings haben sich überschnitten. Dann schreib ich das mal da rein. Wie gesagt, ich bin da eventuell ein wenig härter drauf als der Normaluser. Der hat nur noch die Chance eines Fallbacks auf 2.6.32-5 oder das Ausweichen auf radeon. Beides nicht so schön und keine Eigenwerbung.
-
1. Es benutzt ja nicht jeder auf der Welt eine radeon Karte - warum sollte man also intel, nvidia, s3 oder was auch immer Nutzer benachteiligen nur weil es ATI nicht auf die Reihe bekommt?
2. Es gibt wohl genug Nutzer, die einen der freien Treiber benutzen und damit zurecht kommen.
3. Ein 2.6.36 Kernel sollte beim booten noch zur Auswahl stehen, wenn man ihn nicht selbst entfernt hat.
4. Rate mal warum der aptosid 2010-03 Release noch vor kernel 2.6.37 release war. Weil klar war, das radeon Nutzer wieder in die (selbstverschuldete) Röhre kucken. Genauso wie auch andere Sachen Änderungen verlangen. Cutting Edge hat halt nicht nur Sonnenseiten für jedermann.
5. Man kann es sich einfach machen und sich beschweren, dass Linux nicht die Hardware untersützt die man besitzt, oder man denkt mal darüber nach warum man eigentlich diese Hardware käuft…
6. Das der Debiankernel aus experimental als Fallback funktioniert erachte ich eher als Zufall, nicht als Absicht. Wenns der 2.6.32 Kernel aus testing wäre, wäre es Absicht (hatte dann ja auch lange genug Zeit)…
7. Wenn der proprietäre Treiber keine Rücksicht auf die Weiterentwicklungen des Kernels nimmt, warum sollte der Kernel dann auf den Stillstand des proprietären Treibers Rücksicht nehmen?
8. Wer von euch wird eigentlich davon abgehalten eine Warnung ins Forum zu posten für Radeon-Nutzer? Das von anderen zu erwarten ist ja schön und gut, aber selbst wenn ich wollte, könnte ich das dank fehlender Hardware schlecht machen…
9. Mit manchen Intelkarten gab bei früheren Kernelversionen probleme. Ich erinnere mich nicht daran, dass ein Radeon-Nutzer dann aufgesprungen ist um zu sagen: Alles anhalten, wir müssen warten bis das geht…
10. <insert>
-
@agaida, der wesentliche Punkt von DonKults Liste ist: Man deinstalliert nicht seine alten Kernel, sondern frühestens 4 Monate später. Es kostet auch nur ein paar Milli Gigabyte Plattenplatz. Weil also normalerweise ein Start mit altem Kernel möglich ist, ist es keine Upgrade-Warnung!!!
Und ausserdem: Wenn man sich mal die Mühe gemacht hat, die .1 und .2 Kernel Patches anzuschauen, weiss man, dass dort noch jede Menge (ich meine wirklich massenweise) Flüchtigkeitsfehler gepatcht werden müssen...
Oder, wir machen einen Request für ein
zusätzliches aptosid-experimental Repo
Pro Argumente:
- irrtümliche Annahmen alla Agaida, siehe oben.
- viele würden sich viele Kernel Upgrades ersparen.
- slh macht oft neue Kernel mit schon den Patches aus der stable-queue, die noch völlig ungetestet sind und oft zurückgezogen werden müssen von GKH vor dem .Release .
- ein stable aptosid Kernel würde dann auch meistens erst für normal User erscheinen, wenn Amd und Nvidia soweit sind.
Nachteil:
- slh hätte weniger Tester
-
Ich weiss jetzt nicht, ob ich da überreagiere,
Ich würde sagen JA, aptosid hat sich ja zum ziel gesetzt freie Software zu unterstützen, und nicht proprietäre Treiber, es steht ja jedem frei sie zu benutzen, aber Support (und seis auch nur in Form von Warnungen ala "geht jetzt nicht" zu erwarten ist ein bisschen viel verlangt, von einer Open Source Community. :wink:
Außerdem solltest du dir vielleicht zur Regel machen eine Kernel erst zu entsorgen, wen du dir sicher bist das du den neuen benutzen willst/kannst.
finde ich brummer
-
@ralul: bin grade aus der Session geflogen, deshalb eine direkte Antwort:
Der 2.6.36 war schon nicht unbedingt das Gelbe vom Ei, der 36-3 war dann wirklich nicht mehr prall. Das war also Flucht nach vorn. Schlimmer konnte es nicht werden. Meine Intel + ATI lief mit .36 ohne Probleme, der 965 mit ATI halt nicht. Ich kann übrigens auch Patches und Zusammenfassungen davon lesen. Der Rest steht in der Antwort auf das Posting von DonKult.
@DunKult:
Dann mal der Reihe nach:
zu 1. Echt billiges Argument, bei anderen würde ich nicht mal mehr antworten. Ist ja nur eine Kare der grossen 3.
zu 2. Das sehen ich, mein Notbuch und mein Desk anders. Bis jetzt ist der proprietäte Treiber besser, obwohl der freie aufgeholt hat. Da auch hier Debian an Aktualität nicht unbedingt in der ersten Reihe steht, baue ich das Teil regelmässig selbst. Wenn er gleichwertig ist, wird er benutzt.
zu 3. Die letzte Version des Kernels .36 habe ich nie stabil bekommen und deshalb entsorgt.Ich habe statt dessen den Sid als Fallback genutzt. Auf meinem Notebook hatte ich die Probleme nicht. Das ist aber nicht das Problem. Ich kann mir helfen.
zu 4. Cleverer Schachzug.
zu 5. Alternativen? nVidia??? Intel??? Meine Hardware wird unterstützt, auch wenn Sie nicht geziehlt für Linux gekauft wurde. Zu der Zeit, aus der die Graka stammt, war ich reiner Windows-Nutzer. Das sehe ich mal nicht als Argument für, sondern gegen Linux. Ich habe es einfach zu oft gehört, um es noch ernstnehmen zu können.
zu 6. Der einzige Zufall daran ist, dass ich ohne Probleme mal grade das fehlende kbuild zusammengewerfen konnte. Da ich den 2.6.37 seit rc3 ohne Probleme unter Arch am Fliegen habe, eigentlich kein Problem. Ohne die Probleme hätte ich aber gern auf diese Erfahrung verzichtet. Zufall bei einem Kernel in der vorletzten Version vor der Freigabe würde ich also ausschließen.
zu 7. Der proprietäre Treiber baut ohne Probleme - das Thema hatten wir schon.
zu 8. Deshalb die Frage, ob das eine stillschweigende Übereinkunft ist, dass der ATI-Treiber nicht baut. Das war bisher bei jedem neuen Kernel so ;) Ich dachte, bei Aptosid muss das so sein. Deshalb habe ich auch eine Warnung eingestellt, die man ja wahrscheinlich gleich auf Sticky setzen kann.
zu 9. Ich habe nicht gesagt: Alles anhalten. Ich erwarte eigentlich nur, dass im Rahmen der Möglichkeiten auf Qualität Wert gelegt wird.
zu 10. .. reichen nicht 9 Punkte.
Nur um meinen Standpunkt darzustellen: Egal welche Hardware ich nehme, mit ein wenig "Glück" werde ich immer auf der Verliererseite stehen. Ich könnte es verstehen, dass es bei solch trivialen Sachen wie Grafiktreibern bei echtem bleeding edge die einen oder anderen Probleme gibt. Und da tut es mir leid: Sid ist nicht bleeding. Schon gar nicht zur Zeit. Erfahrungen anderer Distributionen mit solchen Problemchen dürfen ruhig beigezogen werden. Das ist auch einer der Gründe, warum ich Sid und grade Aptosid in letzter Zeit sehr schätzen gelernt habe. Zwischen Revisionskontrollsystem und der Veröffentlichung eines debian-Pakets in experimental oder sid vergeht normalerweise eine gewisse Zeit. Natürlich ist es geil, am Tag nach der Freigabe einen Kernel der neusten Version zu haben. Nur der sollte dann auch ohne wenn und aber funktionieren. Mit dem RC klappt das ja auch.
Ich weiss auch nicht, wo das Problem sein soll: Ich nehme einen Quelltext und kompiliere ihn. Kompiliert der ohne Fehler, dann ist der eigentlich reif zur Veröffentlichung. Das ist nicht meine Meinung, so wird Linus kolportiert. Wenn ich mehrere Release-Kandidaten schon selbst kompiliert habe, die ohne Probleme laufen, kann eigentlich mit der final nichts schiefgehen. Dass ich den .37 aus experimental nicht probiert habe, lag nur daran, dass ich zu faul war, mir eine linux-kbuild-2.6.37 zusammenzubauen. Das schnelle Zugreifen auf den .37 lag auch daran, dass ich auf die Traces, die mit dem .36 passierten, keinen Bock mehr hatte. Ich habe darauf gewartet, dass das jemand, der das so oder so tut, erledigt. Getestet habe ich ja schon unter Arch. Und ich war sehr zufrieden. Selbst mein Catalyst lief seit 2 RCs ohne Probleme. So was macht einfach keinen Spass. Da passt was nicht. Und den Versuch, dass auf reines Anspruchsdenken meinerseits abzuwerten, finde ich ehrlich gesagt ein wenig schofelig.
Und in diesem Kontext finde ich ein zartes wzt nicht überreagiert.
-
Mehrere Kernelversionen zu maintainen liegt vollkommen außerhalb der sinnvollen Möglichkeiten - dafür haben wir schon alleine gar nicht genug "Humankapital" und ist für die Mehrzahl der Anwender auch gar nicht notwendig.
Nebenbei ist Kernelversion 2.6.37 ja nicht gerade ein direkter git-snapshot sondern eine offizieller Release der als "stable" von Upstream gekenzeichnet wird. Wäre sid nicht gerade im Deepfreeze würde auch hier 2.6.37 recht schnell Einzug halten (warum sonst sind in experimental die rc's getestet worden -- under anderem auch Ideen für backports und um nach dem Freeze wieder voll durchzustarten).
Man beachte übrigens mal den subtilen Unterschied von 'Bleeding edge' (Blutige Kante) vs. 'Cutting edge' (Scharfe Kante) - an letzter kann es sein, dass man sich schneidet wenn man nicht aufpasst, von erster tropft schon das Blut des Entwicklers, die Verwendung birgt also (große) Risiken.
aptosid ist als solches für mich daher 'cutting edge', da es durchaus sein kann, das der ein oder andere sich schneidet und bluten muss, wir aber dennoch weit entfernt von der 'bleeding edge' entfernt sind, die anderswo anzutreffen ist.
Es tut mir leid, dass es regelmäßig einige trifft - aber ehrlich gesagt, nur so kommen wir auch vorwärts, den durch warten dauert es nur länger bis jemand über den Fehler stolpert und ihn meldet, den ehrlichgesagt ist das genau das Ziel von debian unstable -- so viele Fehler wie möglich finden bevor es Leute aus testing oder stable trifft. Dafür kriegen wir ja im Austausch auch früher neues Spielzeug. Beides gleichzeitig geht eben nicht. Wenn wir immer warten würden bis jede Hardware mit jeder Kernelversion, dem XServer und allen anderen Programmen zurechtkommt können wir uns in Debian stable umtaufen, den das ist genau deren Ziel…
P.S.: Das du Probleme mit 2.6.36 hast höre ich jetzt zum ersten Mal, ich verfolge es allerdings auch nicht so direkt. Hast du es den gemeldet - bestenfalls upstream? Darf ich daraus dann schließen, das wir bei 2.6.35 stehen bleiben hätten sollen?
-
Ich könnte jetzt mal unken, warum fglrx gegen .37 aus Experimental baut und gegen .37 von aptosid nicht, der aptosid-kernel hat BKL entsorgt, was langfristig auch upstream so sein wird. Ich wage auch zu orakeln, daß auch Debian relativ bald BKL entsorgt.
-
Nö - bitte nicht debian stable, ich will auch meinen Spass haben. Die Idee des Vorhaltendes der Vorgängerversion unmaintainiert fänd ich nicht schlecht. Ich will auch sid nicht in die Richtung stable wandern sehen und kann eigentlich jedem Deiner Argumente folgen.
Ich beschwere mich auch nicht darüber, dass mal der eine oder andere mal getroffen wird - das gehört bei bleeding und auch cutting dazu. Dass es mich getroffen hat, who cares. Es sind nur ein oder zwei Feinheiten, die mich stören. Diese betreffen nicht aptosid, sondern eher debian, obwohl ich sie manchmal nachvollziehen kann. Bei Installationen, die nicht unbedingt rockstable laufen müssen, bevorzuge ich halt cutting oder bleeding. Wie man den Zustand ändern kann, weiss ich auch. In meinem Fall heisst das umbooten (nur für den Fall des Falles).
Kommen wir mal zu Punkten, die stören:
1. Bei den wenigen Abstürzen, die ich mit 4.5 hatte, konnte ich teilweise keine Fehler melden, da die debug-Pakete nicht verfügbar waren oder teilweise immer noch sind. Ok. Ich bin drum rumgekommen, insgesamt 5 Reports zu schreiben. Da derselbe Punkt unter Arch auch geknallt hat, hab ich das dann aus Arch gemeldet.
2. Einige Grafik-Probleme und Bau-Problem hatten sich direkt nach erscheinen des Catalyst 12/10 im Experimental erledigt, bevor ich dazu kam sie überhaupt zu melden. Da ich in der lezten Zeit eigentlich nur das Notebook benutzt habe und der Große ausblieb, traten ja auch keine Probleme mit ihm auf. Die kamen erst, als ich meine Programmdoku und ein wenig Grafik machen mussten. Da nehme ich halt lieber knappe 27" statt Notebook. Und da bin ich dann halt ins Messer gelaufen. Dass ich seit über einem Jahr keinen Kernel mehr auf meinem Phenom gestartet kriege, ohne Boot-Options, ist für mich normal geworden, die stehen in den defaults. Bei Instabilitäten heisst das dann erst mal immer Suche nach Gigabyte und eventuelle Lösungen. So komme ich auch immer in den "Genuss" des neuesten Bios für mein Board. Das kann man aber wirklich nicht verallgemeinern. Die selben Probleme bei jeder Distri. Das Problem ist bei Gigabyte bekannt und man telefoniert gelegentlich. Dem kann ich nur durch Tausch der Hardware entgehen. Bis dahin kann ich keine eindeutigen Fehler melden. Mein Laptop ist ja stabil.
3. Das Einzige, was mich an Aptosid gestört hat: Dass ich dieses eine kleine mickrige Paket selbst frickeln musste. Dass dadurch natürlich Leute bei debian davon abgehalten werden, bestimmte Sachen aus experimental zu missbrauchen, die definitiv noch nicht fertig sind, ist mir auch klar. Spätestens mit der Veröffentlichung eines Kernels für aptosid möchte ich diesen aber bei Bedarf auch selbst bauen können. Das geht aber nur mit Linux-kbuild-2.6.37. Ohne das Paket bekomme ich nicht mal die Header installiert. Das macht dann auch den Einsatz von anderen Sachen nicht unbedingt einfacher, man denke an VirtualBox. Da hat das dazusein, da eine Kernelanpassung samt Neubau ohne Probleme möglich sein soll. Es ist in dem Moment der offizielle Aptosid-Kernel. Genau dieser Punkt hat mich geärgert.
In solchen Augenblicken bin ich immer ein wenig nörgelig, da es mir vor einem halben oder dreiviertel Jahr nicht unbedingt möglich gewesen wäre, mal eben ein debian-Paket zu kapern und umzuwidmen. Ich hätte wahrscheinlich ein wenig lauter und länger geflucht. Ich frag mich dann immer, ob so was wirklich sein muss. Vielleicht bin ich an dieser Stelle auch zu sehr von Arch "verwöhnt", da ich mich erst daran gewöhnen muss, bei wirklich "aktuellen" Sachen nicht die Quellen zu saugen. Alles was ich zu meinem Glück gebraucht hätte, wäre so was gewesen:
http://aur.archlinux.org/packages/kernel26-mainline/kernel26-mainline/PKGBUILD
Und zum Thema beim alten Kernel bleiben: Um Gottes willen, alles - nur grade das nicht. Das gilt auch für den Rest der Pakete. Ab und zu hätte ich aber gerne die Chance, bestimmte Sachen gerne schmerzfrei selbst zu fixen, ohne mir selbst die Grundlagen bauen zu müssen.
Genug geweint, ich schau mir den .37 noch mal an, das fehlende Paket wird halt noch mal annektiert und auf den neuesten Stand gebracht, diesmal geb ich mir auch Mühe und ziehe die Sourcen aktuell.
-
Ich könnte jetzt mal unken, warum fglrx gegen .37 aus Experimental baut und gegen .37 von aptosid nicht, der aptosid-kernel hat BKL entsorgt, was langfristig auch upstream so sein wird. Ich wage auch zu orakeln, daß auch Debian relativ bald BKL entsorgt.
Kann sein, aber BKL war eigentlich schon in rc8 fast Geschichte oder irre ich mich da?
-
In exp. ist rc7 und da ist BKL drin.
BTW war die Möglichkeit, BKL zu entsorgen seit rc1 vorhanden, man muß es eben in der config angeben, oder eben nicht.
-
Die Frage nach rc8 war bewusst gewählt. Der Treiber baute auch noch gegen die rc8. Gegen die final bin ich grad dabei. Es lebe die heilige Empirie. Es kann aber sein, dass in dem Treiber noch irgendwas drin ist, was entsorgt gehört. Ich bau dann mal ein wenig ;)
-
Der baut mit Sicherheit auch gegen den Final, so BKL aktiviert ist.
Btw, ich schrieb es schon in einem anderen Thread, mit Vmware is auch Essig ohne BKL.
-
Dieses Problem habe ich zum Glück nicht mehr. Die Notwendigkeit des Einsatz von Desktopvirtualisierung ist bei mir deutlich geringer geworden und tendiert eigentlich gegen Null. Das benutze ich eigentlich nur noch um Windows-Software zu testen. Und dafür reicht VirtualBox.
-
@towo: Du meinst nicht zufälligerweise ungefähr diesen Schalter?
Big Kernel Lock (BKL)
CONFIG_BKL:
This is the traditional lock that is used in old code instead
of proper locking. All drivers that use the BKL should depend
on this symbol.
Say Y here unless you are working on removing the BKL.
Symbol: BKL [=y]
Type : boolean
Prompt: Big Kernel Lock
Defined at lib/Kconfig.debug:472
Depends on: SMP [=y] || PREEMPT [=y]
Location:
-> Kernel hacking
ähm. ja. mhh... :lol:
EDIT: Danke, das spart suchen und erklärt vieles.
-
Noch mal ein wenig Quellen und Commits lesen brachte das Folgene zu Vorschein:
Eingeführt wurde der Schalter am 21.10.2010 mit dem Commit 6de5bd128d381ad88ac6d419a5e597048eb468cf BKL: introduce CONFIG_BKL.
With all the patches we have queued in the BKL removal tree, only a
few dozen modules are left that actually rely on the BKL, and even
there are lots of low-hanging fruit. We need to decide what to do
about them, this patch illustrates one of the options:
Every user of the BKL is marked as 'depends on BKL' in Kconfig,
and the CONFIG_BKL becomes a user-visible option. If it gets
disabled, no BKL using module can be built any more and the BKL
code itself is compiled out.
The one exception is file locking, which is practically always
enabled and does a 'select BKL' instead. This effectively forces
CONFIG_BKL to be enabled until we have solved the fs/lockd
mess and can apply the patch that removes the BKL from fs/locks.c.
Signed-off-by: Arnd Bergmann <arnd>
Seit dem ist Schweigen im Walde und die Konfigution wurde nicht mehr geändert. Das Ding bricht noch so einiges. Wer Spass daran hat, sollte mal mit Grep oder einem grafischen Werkzeug wie irgendeinem Git-Frontend durch den Quellcode laufen. Danke Towo, übrigens funktioniert Appletalk auch nicht mehr. Das aber nur am Rande, wer benutzt schon so was.
Für mich ändert das jetzt nicht viel, Aptosid bleibt auf dem rc7. Ob der Aptosid-Kernel auf dem jetzigen Stand bleibt, ist da erst mal peng. wenn ich mal Zeit haben sollte, lerne ich, wie man Debian-Kernel baut und gut ist. Dass ich jetzt einen Mainline-Kernel für Arch habe, ist ja auch was Feines. Der braucht zwar noch ein wenig Zuwendung, aber das hat mal wieder richtig Spass gemacht. Nebenbei habe ich bemerkt, dass Smartgit bei etwas größeren Quellen ab Entwickler ein wenig fehlkonfiguriert ist sonst aber mit den dreihundertund M Quelltext ganz gut zurechtkommt. Ist ja auch was.
Eine vielleicht nicht ganz abwegige Idee wäre es vielleicht, den Schalter wieder einzuschalten. Im Juni ging man noch davon aus, dass man den BKL mit der .39 los wird. Diesen Gedanken halte ich ehrlich gesagt nicht für ganz abwegig.
-
Kleines Update: Ich hab den Schalter einfach mal wieder umgelegt und ohne weitere Änderungen neu kompiliert. Der Build lief absolut sauber durch. Danach das frisch gebaute Zeug ins System geblasen, die benötigten Kernelmodule bauen ohne Probleme.
@towo: Vielen Dank für den Tipp, das war's.