Linux 3.13 és az Nvidia 143

Történt, hogy az eddigi itthoni filmnézegetős/netezős D525 alapú gépet le akartam cserélni egy kicsit erősebbre és kicsit Windowsosabbra. Kéznél is volt egy cégtől guberált P4M800S-es gép, egy GeForce FX 5200-as kártyával, XP matricával. Nosza, Debian telepítés, aztán jön a meglepetés, hogy az alaplapi integrált hálókártya nem megy. Némi netezés után kiderült, hogy 3.x szériában, 3.5 felett érdemes próbálkozni. Kerneltöltés, pótcselekvés, pöcc, röff. Háló van, hang van, kép van, minden van. Az-az, a glxgears nouveu driverrel, ablakban csak 130 fps-t hoz, anélkül meg 73 körül. Yeah, open-source performance és társai.
Kicsit körberöhögtetem magam a trollokkal a #nohup-on, lerántom az Nvidia 143-as legacy driver az Nvidiától, enter, enter, wtf?
A telepítés elhasal, mondván nem tudja a modult betölteni. Dehogyisnem...
Kitömörítem a telepítőcsomagot, adj neki, ugyanaz a hiba. Belenézve a usr/src/nv-be, ott figyel az nvidia.ko, insmod neki: 

ERROR: could not insert 'nvidia': Unknown symbol in module, or unknown parameter (see dmesg)

Jó, lássuk a dmesg-et: 

nvidia: Unknown symbol acpi_os_wait_events_complete (err 0)

Google-fu és lám, fémillió találat, hogy 3.13 után hirtelen az összes nvidia telepítő eldobja magát. Egyetlen gebasz csak az, hogy a találatok a 3xx szériáról szólnak, az 1xx driverről kuss.

Újabb google-fu és már látszik, hogy az ok, az acpi_os_wait_events_complete szimbólum kernelből történő kiirtása a bűnös. Egen, ilyen szoftverfejlesztők mellett a Linuxnak nincs szüksége konkurenciára. Azért vicces, hogy azok a fejlesztők akik sírnak, hogy az OS-üket a gyártók támogassák, tesznek keresztbe a gyártóknak.

Hagyjuk, vissza a forráshoz. Az Nvidiás srácok hála az égnek, elég lusták voltak, és a 3xx széria nv-acpi.c-ben található függvények nagyban hasonlítanak a 1xx széria nvacpi.c-jére. Némi keresgélés után meg is lett, hogy a 260-as sorától kezdődő elágazás bitre ugyanaz, mint a 331-hez gyártott patchben szereplő, és két sorral lejjebb ott is volt a NV_ACPI_OS_WAIT_EVENTS_COMPLETE();. Gyors kikommentelés, telepítő futtatás, és 2770 FPS-el pörögnek a fogaskerekek.

Yup, a kernel elbaszó developer team ismét bizonyított...

( hrgy84 | 2014. 03. 04., k – 19:03 )

Ohm, keptelen vagyok elmenni a teny mellett, hogy
1) legacy drivert hasznaltal. Windowsos eraban sem mukodnek az XP-s driverek Win 7 alatt, illetve pont ugyanilyen lutri a mukodesre birasuk.
2) a kernel API valtozas le nem koveteseert nem feltetlen a kernelfejlesztok a bunosok.

IMHO.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ohm, képtelen vagyok elmenni a tény mellett, hogy
1) a legacy az Nvidianal a legacy hardwaret jelenti, maga a driver 2013. december 06.-án lett utoljára frissítve, és nem csak ez érintett, hanem a 3xx mainline széria is.
2) Ha fejlesztek és tudom, hogy az API change befolyásolja a termékemet támogató gyártók drivereinek a működését, akkor minimum értesítem a gyártókat és csak akkor tolom át a változtatás, mikor ők megtették a szükséges lépéseket. T'od egy desktop piacon öt százalék alatti OS-nél elég egyértelmű a kutya és a farok viszonya.

IMHO.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

És ezért tart ott, ahol. T'od ha egy generikus OSt fejlesztenek, akkor megkövetelt egy minimális kommunikáció. Ha meg szeretnének túljutni a hobbyproject szintjén, akkor elvárt bizonyos iparágban megszokott kommunikációs és bevett fejlesztési gyakorlatok követése.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Szintén fx5200, szüleim gépét csak frissítettem (kellett nekik az automount, már jó ideje nem frissült a rendszer, így pacman -Su lett). Nem indul a grafikus rendszer. Mijazisten. Az nvidia modul betöltése nem sikerült, a hibaüzenet folytán eszembe jutott pont ez a topik, aztán gyorsan le a gyári nvidia, fel a nouveau. Fx5200-on nemigen lehet se így, se úgy komolyan játszani, meg amúgy is, szüleim inkább neteznek meg szöveget szerkesztenek, ahhoz nem kell csillió fps.

Viszont egy kérdés: ha tudvalevő, hogy a 3.13-as kernel nem megy az nvidia-val, akkor a disztrócsomagolók miért nem vonják vissza a 3.13-as kernelcsomagot? Ja, blídingedzs meg rollingriliz meg verzióbuziság. Nem hiszem, hogy olyan kva nagy változás lenne a 3.12 és a 3.13 között, hogy minden(ezen az)áron frissíteni kelljen. Ez meg már nem a kernelfejlesztők/nvidia sara, ez már a disztró(k) "felelőssége" (mint kb. másfél éve - kernelben valami miatt az egyik verziónál az ath driver bizonyos csipeknél nem ment - én meg szidtam a munkahelyet, hogy milyen sz.r, nem tudok csatlakozni a wifi-re - persze a kernel maradt, aztán innen-onnan szedjek le külsős csomagokat, amivel megy a wifi).

Nem mindenki használ nVidiát, akik használnak, azok egy része beéri a nouveau driverrel. Az nem volna jó, ha azok miatt, akiknek bajuk van a legfrissebb kernel, s a kernel részét nem képező nvidia driver együttnemműködésével, mások nem jutnának a friss kernelhez. Én fordítva látom ezt. Miért frissítesz kernelt, ha a régebbire van szükséged? Akinek ez az igénye, megteheti, de a többiek hagy kapják már meg a legfrissebbet, nem?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Úgy is jó, de akkor akik a régit akarják (vagy épp azt kell nekik használni) azok meg kaphassák meg a régit. És szerintem ez nem teljesül (legalábbis Arch alatt biztos nem (bár amint látom, patch van az nvidia csomaghoz)).

Nem (annyira) kötözködésképpen, de miben több a 3.13-as kernel, hogy mindenáron az kell, de már tegnapra, ha már tegnapelőttre nem lehet, és nem jó a 3.12-es még kb. egy-két hónapig, míg esetleg az nvidia lereagálja ezt a változást? Én speciel nemigen tapasztaltam változást kernelfrissülésekkor (pedig párat végigéltem). Ami ment, az a frissítés után is ment (leszámítva egy esetet). Ami meg nem ment... nos, olyan nem volt ;)

Persze értem egyébként, hogy a kettő egyszerre nem megy: frissesség + stabilitás, és mivel egyszerre nem megy, választani kell. Van, ahol a frissesség fontosabb, máshol pedig a stabilitás.

Szerk.: pont a kérdésedre nem válaszoltam (miért frissítek kernelt, ha a régire van szükségem): kénytelen voltam. Ahhoz, hogy az automount-hoz szükséges dolgokat telepítsem, frissíteni kellett mindent. Másrészt a fenének jutott eszébe, hogy olvastam egy ilyet itt - csak akkor ugrott be, mikor már kész volt a baj.

Az Arch infrastruktúráját nem ismerem. Fedora esetében a build szerverről letölthetem a korábbi csomagokat is, ha esetleg arra vágyom, frissítésnél megadhatok kivétel listát, szóval van mozgásterem.

Nyilván van, akinek kell az újabb kernel. Ha senkinek sem kellene, akkor az kb. azt jelentené, hogy semmi sem változott a 3.13-ban 3.12-höz képest. Azt végképp nem tudom, miért éppen az nVidiához kellene alkalmazkodni, miért nem azokhoz, akiknek a 3.13-ban megjelenő új feature-ök kellenek.

Ja, egyébként meg akinek nem kell semmi új, tegyen fel egy CentOS-t, Ubuntu LTS-t, Debiant, aztán béke van. Sokáig támogatott, viszont nem változik. Lehetőség mindenre van, ki-ki az igényeire szabott disztribúciót használhatja.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nyilván van, akinek kell az újabb kernel. Ha senkinek sem kellene, akkor az kb. azt jelentené, hogy semmi sem változott a 3.13-ban 3.12-höz képest.

Csak egy kis "szemét" kérdés: mekkora az a felhasználói bázis, akiknek tényleg kell a 3.13-as kernel, mert számukra valami újat hoz, amit ki is használnak ( Verzióbuzik nem számítanak :) )? Nagyobb vagy kisebb, mint a (legacy) nvidia-val szívók száma?

Azt végképp nem tudom, miért éppen az nVidiához kellene alkalmazkodni, miért nem azokhoz, akiknek a 3.13-ban megjelenő új feature-ök kellenek.

Mint ahogy írtam, a kettő együtt nem biztos, hogy megy.
Az Arch a 3.13 mellett döntött, és az új nvidia kártyásokat megsegíti (ahhoz van ui. patch). Nyilván a legacy driverekre is meg lehetne írni (gondolom én).
A CentOS, Ubuntu LTS, Debian (amiket írtál) pedig máshoz alkalmazkodik.
A felhasználó kezében meg ott a választás lehetősége, csak tudjon (jól) dönteni ;)

Szerintem sem. Csak lehet, hogy a jó(nak hitt) döntést meg kell változtatni, ami ebben az esetben sokszor kényelmetlen is lehet (jól belaksz egy rendszert, aztán rájössz, hogy...). Na, mindegy, végülis nincs nvidiám, úgyhogy annyira nem érint a probléma, szüleim gépén meg már a nouveau van, úgyhogy már azon a fronton sem. Akinek meg nvidiája van... az vegyen nfúrót :)

Ezt hogy érted? Lenne egy csapat, aki kéthavonta csinálna egy ilyet?

diff kernel-3.13 kernel-3.14

Mert azt, hogy melyik zárt driver-t mely változások érintenek, leginkább az tudja, aki a zárt driver-t csinálja. Első körben megpróbálja lefordítani az új kernelhez, nem sikerül, aztán keresi az okát.

Az nVidia eddig követte ezt, az Oracle is megteszi a VirtualBox kapcsán.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ilyen kis event handler oldalt tudnék elképzelni, amely legalább a szimbólumok, interfészek szintjén lebontja a változásokat. Erről igazából az tud nyilatkozni aki rendszeresen lát ilyet, illetve valóban az aki a drivert fejleszti. De ha a munkának ezt a részét el akarják hárítani maguktól, nyilván erre kell egy megfelelő "design pattern", ami lehetővé teszi, hogy a munkának csak azt a részét végezzék, amit akarnak. Így nagy általánosságban csak ennyit lehet mondani erről.

Nyilván egy ilyen pattern kialakításához közös megegyezésre lenne szükség.

Na, meg az a gond még, hogy ahhoz hogy komolyan együtt működjenek egy FOSS csapattal, még ha minkét fél tényleg hajlandó is az együtt működésre, lehet hogy túl sok információt ki kéne szivárogtatni a driver belső felépítéséről, ami már lehet hogy a részleges megfejtését is lehetővé tenné. Ez a valós probléma szerintem.

Eddig is erről volt szó.
Mindössze a kernel íróknak kéne, TÁJÉKOZTATNI a driverek íróit és VÁRNI, míg azok MÓDOSÍTJÁK a drivereket. De ehhez planning kellene, meg design, meg tesztelés, meg minőségbiztosítás, úgy ahogy RENDES termékeknél is csinálják.
Egy API change nem security patch jellegű dolog, pl. a fenti szimbólum, emlékeim szerint már 2.4-es kernelben is benne volt. Ebből adódóan, nem fog törést okozni, ha adott esetben egy vagy két verziót várnak
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

"VÁRNI, míg azok MÓDOSÍTJÁK a drivereket."

Én ezt nem várom el, mert ez tényleg nem az ő feladatuk. Ha van egy megbízható átgondolt tájékoztatási rendszer a háttérben, azt is mindenki tudni fogja, ha egy változtatás nem megy át rögtön, és addig nem használják az újabb kernelt(csak security karbantartott ágat).

Egen, klasszikus developer mailt linkeltél, lefordítom:
"Well, they haven't so far. :-)"
Oh, a gyártó nem jött sírni nekem, akkor a problémát elintézem egy smileyval.

"It doesn't, but removing the export was intentional, because that export is not needed for any in-the-tree modules any more."
Szándékosan kiszedtük mert a saját moduljainkhoz már nem kell, a többieket meg leszarjuk. A changelogban szót sem érdemel.

"In principle I can add the export back, but this function is supposed to be an internal ACPI interface and the NVidia driver is abusing it quite openly, so I'm not sure."

Ha nagyon kell akkor vissza is tehetném, mert ugyan szarul terveztük meg a kernelt, hiszen egy belső interfészhez szabadon hozzáfér egy külső modul és aktívan is használhatja is, de ezt sohasem ismernénk el. Amúgy fogalmam sincs mit csinál az Nvidia driver ezzel, de az biztos, hogy nem szabályos! Fujj, csúnya Nvidia!!!

"I guess I'll just send a patch for broader discussion."
Egy patchel megideologizáljuk a dolgot, de felelősséget senki nem fog vállalni érte. Majd két vagy három verzióval később visszatesszük a támogatást, de addigra az Nvidia úgyis kijavítja.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Én csak azt mondtam hogy jó lenne, azt nem hogy nincs. :)
Nyilván ha egy kicsit akarnák megtanulhatnák ezeket az oldalakat úgy használni ahogy nekik kényelmes. Azt hangsúlyoznám hogy kényelem fontos, mert nincs sok erőforrásuk erre a feladatra, és azt úgy osztják be ahogy tudják.