[Megoldva] 5.9.1 és nouveau

VGA

Valami már megint nem jó. Vannak mindenféle flikkerek, bevillanások a monitoron 5.9.1-es kernel használatával. Illetve dmesg-ben:

[ 4252.484787] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 4254.489338] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 4256.495963] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 4270.284128] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 4272.292512] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 4274.299287] nouveau 0000:01:00.0: DRM: base-0: timeout

Szóval nem kell sietni, jó az az 5.8.18.

Megoldva 5.10.13-ban.

  • 985 megtekintés

( bimi3 | 2020. 10. 23., p – 20:55 )

AMD Ryzen APU-val, friss Mesa-val kiegészítve viszont teljesen korrekt az 5.9.1-es kernel. Ha ez vigasz.

Eddig úgy tűnik. Elhiszem, hogy nehéz video driver-t írni, s az állandóan változó belső kernel ABI miatt törnek ezek a kódok, de azért jó volna, ha rend lenne végre. Emlékszem, talán az 5.4-es kernel környékén az Intel i915 volt nagyon vacak, állandóan megfagyott a gép, akkor épp az nVidia-hoz való nouveau működött jól. Most meg épp az i915 jó, a nouveau meg nem.

Amúgy sejtettem, hogy baj lesz, mert 5.9-rc3 környékén kaptam e-mailt egy lengyel fazontól, aki érdeklődött egy bugreportom felől, s arról írt, hogy neki 5.9-rc3 nagyon nincs rendben nouveau-val. Nem használok rc kernelt, de ez a levél sejtette, hogy a végleges 5.9-ben is baj lesz a nouveau-val. És lőn. :(

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

Nem, nem nehéz drivert írni, az AMD-nek és az Intelnek érdekes megy. Ez az NV sara, hogy zárt driverezik, a nyílt drivere meg hulladék, használhatatlan, kernelverziótól függetlenül. Tanulság: NV kerülendő linuxozásnál. Én is most fetrengek ezzel, laptopot akarok venni, de ami jó lenne, az NV dedikált kártyás, azt nem akarom megvenni. Ez van, az NV ilyen. Szépen mutass be egy középső ujjat te is az enyvídilyának, ahogy Torvalds.

Az 5.9.x-es kernellel egyelőre minden NV driver bajos, a nyílt és a zárt is. Ha már NV-s géped van, használj rajta LTS kernelt, azt is csakis zárt NV driverrel, az a kombó mindig biztosan működni fog.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ha már NV-s géped van, használj rajta LTS kernelt, azt is csakis zárt NV driverrel, az a kombó mindig biztosan működni fog.

Ez a megoldás. Archon tudtommal van opcionálisan lts kernel, aki meg fedorázik fordítson rá lts kernelt, aztán hajrá. Mégis mi az akadálya? Locsemegének az agyára ment ez a mindenből legfrissebb legyen minden mánia, Neked raynes nem muszáj ezt követned, ha meg mégis, elég csak a kernelt visszatartani.

Rossz hírem van, én még locsemegénél is frissességmániásabb vagyok, nem hogy követem ebben, de szerintem előtte is járok. Nem fogok semmilyen kernelt visszatartani, pont ez a Linux egyik előnye, folyamatos a fejlődés, mindig gyorsan megkapja az ember a technikai újdonságokat, nem kell egy cég nagyléptékű kiadásmodelljeire várni, mire szíveskednek valamit támogatni, foltozni, magyarán nem kell MS-os patch keddre, meg Ubuntus féléves kiadásra várni, meg LTS-ezni. Ezért is használok friss rolling disztrót, azt is testinges tárolóval, friss kernelt, stb.. Erre már csak azért is szükség van, mert sok git-es programot szoktam kipróbálni, amiket forráskódból kell forgatni, és azoknál általában követelmény, hogy mindennek frissnek kell lennie ahhoz, hogy leforduljon.

Ugyanezért van, hogy a Linux kerneleseket szándékosan nem érdekli a visszafelé kompatiblitás. Ez nem a user ellen szól, hanem hogy szabadon fejleszthessenek, implementálhassák az új technológiákat, és ne attól kelljen rettegni, hogy valami cégnek a zárt forráskódú szutykával tartsák a visszafelé kompatibilitást, és emiatt hekkelések vagy kódvisszatartás történjenek, mert így a farka fogja csóválni a kutyát, és az meg pont a fordítottja annak, amit a kernelesek szeretnének.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Igen, a Debian elavultságáról megvan a véleményem. Az is igaz, hogy erre ők is rájöttek, mert manapság már a Debian sincs annyira elavulva verziók terén, mint pár évvel ezelőttig volt. Kicsit ráléptek ők is annak az útjára, hogy némileg újabbak a csomagverziók, meg kivételesen léptetnek csomagverziót kiadás közben is, nem megvárva a következő kiadást, szóval több irányban is enyhítettek a korábbi szigorúan elavult verziós csomagrendszeren. Ők is érzik, hogy szükséges lépés ez.

A Gentoo-t nem a testinggel borítottam meg, bár ott is kísérleteztem -9999-es verziójú csomagokkal, de arra gyorsan rájöttem, hogy nem jó ötlet. A rendszer vagy hiányos kernelkonfig vagy rossz USE flag használat, azaz user error miatt borult meg, de neki fogok futni újra, ha meglesz az új laptop, abban már 8 magos proci lesz és gyorsabban pörgetődnek ki a forráskódok.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ügyes vagy. Ezt figyelembe véve felhívom a figyelmedet arra a vl által kidolgozott/felfejlesztett módszerre, amire felhívta a figyelmemet, miszerint hogyan lehet nem éles rendszeren upgradelni. Ennek rengeteg előnye van. Hátránya max annyi, hogy a lefordított csomagoknak helyet kell fenntartani. Ezeket érdemes ideiglenesen eltárolni, legalább az eggyel régebbit, ha gebasz van, vissza lehessen tenni. Nálad ilyen tuti lesz, mert ámokfutó vagy. Ez amúgy is hasznos, ha több pc-d van. Mert a legizmosabbon érdemes fordítani csak.

Egyébként raynes nem értem ezt a régiségutálatot locsemegével. A kereskeselmi disztrókban is régiek a csomagok. Az mindegy, hogy Red Hat vagy SLED/SLES. Vajon ott nem javítják a régi hibás csomagot? Dehogynem. Ha meg debiannál nem javítják valamelyik harmadrangú alkalmazást, az a csomagoló hanyagsága. Ott megoldás lehet a saját csomag készítése. Emiatt nem kell fedorát meg archot használni, pláne úgy, hogy locsemege így is mániákusan csomagol meg fordít.

Rossz hírem van, én még locsemegénél is frissességmániásabb vagyok

PLUSZ

A Gentoo-t nem a testinggel borítottam meg, ... de neki fogok futni újra,

Ezt alaposan gondold át!

Ha frissességmániás vagy, gentooban csalódni fogsz. De már tisztában kell lenned vele, mert egyszer kipróbáltad.

bár ott is kísérleteztem -9999-es verziójú csomagokkal,

Igen. Ha kurvafriss cuccokat akarsz, mindsenből 9999-et kell felraknod és akkor garantálom, hogy a sok béta cucc és függőségeik miatt az összes szabadidőd debuggolással fog eltelni, sőt a munkahelyedről is kirúgnak, mert ott is folyamatosan gentoozni fox. A nejed elhagy, a gereked meg nem fog megismerni, mert nem lesz idd foglalkozni vele egy perced se.

Bocs a provokatív kérdésért. De minek Neked gentoo? A bloatlanításhoz jó megoldásokat kínál, de izmos gépen nem mindegy? Ha meg a systemDmentesség a cél van Archnak is onerrc-sített változata.

Nem értem, eltűnnek mostanában a hozzászólásaim, de több fórumról is, pedig biztosan elküldöm őket. A fene se érti ezt.

Még egyszer: nem, a Gentoo-t nem a v9999-es csomagokkal borítottam meg, hanem valami mással. Neki fogok futni még egyszer, de csak hogy tiszta legyen: a Gentoo-nak futok neki még egyszer, nem a v9999-es csomagozásnak. A túl friss csomagok Gentoo alatt azért sem érik meg, mert akkor egész nap fordulna valami kód, hiszen gyakrabban frissülnének és izzanak állandóan a gcc. Annyiból sem jó ötlet. Sajnos a forrásból forgatós disztrónak is megvan a maga hátránya.

Hogy a Gentoo minek? Azt lehet legjobban debloatosítani, nem csak a systemd-t lehet kihagyni, hanem USE flag-ek mentén még egy csomó rakat feature-t nem kell belefordítani a csomagokba, ki lehet csontozni a kernelt, ez pedig sokat lendít a csomagok soványságát. Systemd-mentes disztrók nem az igaziak, Void-nál a szoftverkínálattal és kódforgatással volt bajom, most Artix-ot használok, OpenRC-vel, és egyrészt eléggé nincs jól összerakva. Belövök egy OpenRC szolgáltatást, és hol elindul, hol nem, mint a mesében (pl. consolefont), plusz a háttérben ott fut a systemd is elogind-nek álcázva, és kevés mirror van Artixhoz és azok lassúak is, így dobni fogom.

Azt is világosan látom, hogy nem a OpenRC a baj, mert Gentoo alatt az normálisan ment, semmi baj nem volt vele. Meg önmagában az runit-tal sem volt gondom Void alatt, az is tette megbízhatóan a dolgát, egyszer belőttem, nem kellett hozzányúlni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( locsemege v | 2020. 10. 23., p – 22:27 )

Visszatettem 5.8.16-ot, ezzel nem jelentkezik a probléma, korábban is jó volt, de azért hirtelen csak beleszaladtam egy ilyenbe:

Oct 23 22:12:55 kernel: general protection fault, probably for non-canonical address 0x3d72d5dbe323fa0b: 0000 [#1] SMP NOPTI
Oct 23 22:12:55 kernel: CPU: 0 PID: 2689 Comm: compiz Not tainted 5.8.16-300.fc33.x86_64 #1
Oct 23 22:12:55 kernel: Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD MS-7388/MS-7388, BIOS V1.13 09/20/2010
Oct 23 22:12:55 kernel: RIP: 0010:kmem_cache_alloc_trace+0x7e/0x220
Oct 23 22:12:55 kernel: Code: 9b 01 00 00 4d 8b 07 65 49 8b 50 08 65 4c 03 05 50 82 d2 5d 4d 8b 20 4d 85 e4 0f 84 87 01 00 00 41 8b 47 20 49 8b 3f 4c 01 e0 <48> 8b 18 48 89 c1 49 33 9f 70 01 00 00 48 0f c9 48 31 cb 40 f6 c7
Oct 23 22:12:55 kernel: RSP: 0018:ffffb7f14227fc10 EFLAGS: 00010202
Oct 23 22:12:55 kernel: RAX: 3d72d5dbe323fa0b RBX: 0000000000000000 RCX: ffff9bd2073a86c0
Oct 23 22:12:55 kernel: RDX: 0000000000141d90 RSI: 0000000000000dc0 RDI: 000000000002f0c0
Oct 23 22:12:55 kernel: RBP: 0000000000000dc0 R08: ffff9bd267c2f0c0 R09: ffffb7f14227fbbc
Oct 23 22:12:55 kernel: R10: 0000000000000001 R11: 00000000000003ff R12: 3d72d5dbe323f9db
Oct 23 22:12:55 kernel: R13: 0000000000000060 R14: ffff9bd266c03500 R15: ffff9bd266c03500
Oct 23 22:12:55 kernel: FS:  00007fb7c9ad1780(0000) GS:ffff9bd267c00000(0000) knlGS:0000000000000000
Oct 23 22:12:55 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 23 22:12:55 kernel: CR2: 00005609b7f06000 CR3: 00000001c1ad8000 CR4: 00000000000006f0
Oct 23 22:12:55 kernel: Call Trace:
Oct 23 22:12:55 kernel:  ? nouveau_fence_new+0x33/0xb0 [nouveau]
Oct 23 22:12:55 kernel:  nouveau_fence_new+0x33/0xb0 [nouveau]
Oct 23 22:12:55 kernel:  nouveau_gem_ioctl_pushbuf+0xa9c/0x1190 [nouveau]
Oct 23 22:12:55 kernel:  ? nouveau_gem_ioctl_new+0xb0/0xb0 [nouveau]
Oct 23 22:12:55 kernel:  drm_ioctl_kernel+0x86/0xd0 [drm]
Oct 23 22:12:55 kernel:  drm_ioctl+0x206/0x390 [drm]
Oct 23 22:12:55 kernel:  ? nouveau_gem_ioctl_new+0xb0/0xb0 [nouveau]
Oct 23 22:12:55 kernel:  ? selinux_file_ioctl+0x122/0x1c0
Oct 23 22:12:55 kernel:  nouveau_drm_ioctl+0x55/0xa0 [nouveau]
Oct 23 22:12:55 kernel:  ksys_ioctl+0x82/0xc0
Oct 23 22:12:55 kernel:  __x64_sys_ioctl+0x16/0x20
Oct 23 22:12:55 kernel:  do_syscall_64+0x4d/0x90
Oct 23 22:12:55 kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Oct 23 22:12:55 kernel: RIP: 0033:0x7fb7c9d7658b
Oct 23 22:12:55 kernel: Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff ff ff 85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d bd c8 0c 00 f7 d8 64 89 01 48
Oct 23 22:12:55 kernel: RSP: 002b:00007ffef598eb98 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
Oct 23 22:12:55 kernel: RAX: ffffffffffffffda RBX: 00007ffef598ec00 RCX: 00007fb7c9d7658b
Oct 23 22:12:55 kernel: RDX: 00007ffef598ec00 RSI: 00000000c0406481 RDI: 0000000000000006
Oct 23 22:12:55 kernel: RBP: 00000000c0406481 R08: 000056522575fe40 R09: 0000565225771918
Oct 23 22:12:55 kernel: R10: 0000000000000001 R11: 0000000000000246 R12: 0000565225760910
Oct 23 22:12:55 kernel: R13: 0000000000000006 R14: 0000565225760450 R15: 000056522575fe40
Oct 23 22:12:55 kernel: Modules linked in: rfcomm snd_seq_dummy snd_hrtimer fuse xt_MASQUERADE xt_conntrack xt_CHECKSUM ipt_REJECT nf_nat_tftp nf_conntrack_tftp tun bridge stp llc nf_nat_ftp nf_conntrack_ftp nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_tables ebtable_nat ebtable_broute ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter cmac bnep f71882fg sunrpc edac_mce_amd kvm_amd pktcdvd ccp kvm snd_usb_audio snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_seq_midi snd_seq_midi_event btusb btrtl btbcm btintel bluetooth snd_usbmidi_lib mc pl2303 snd_hda_intel ecdh_generic rfkill ecc snd_intel_dspcfg snd_hda_codec irqbypass snd_ca0106 nouveau
Oct 23 22:12:55 kernel:  snd_ac97_codec snd_hda_core ac97_bus snd_rawmidi snd_hwdep snd_seq snd_seq_device snd_pcm mxm_wmi k10temp video i2c_algo_bit ttm snd_timer snd wmi_bmof soundcore drm_kms_helper sp5100_tco i2c_piix4 cec acpi_cpufreq drm binfmt_misc ip_tables ata_generic pata_acpi serio_raw pata_atiixp r8169 wmi overlay
Oct 23 22:12:55 kernel: ---[ end trace dccaff92f8d6406b ]---
Oct 23 22:12:55 kernel: RIP: 0010:kmem_cache_alloc_trace+0x7e/0x220
Oct 23 22:12:55 kernel: Code: 9b 01 00 00 4d 8b 07 65 49 8b 50 08 65 4c 03 05 50 82 d2 5d 4d 8b 20 4d 85 e4 0f 84 87 01 00 00 41 8b 47 20 49 8b 3f 4c 01 e0 <48> 8b 18 48 89 c1 49 33 9f 70 01 00 00 48 0f c9 48 31 cb 40 f6 c7
Oct 23 22:12:55 kernel: RSP: 0018:ffffb7f14227fc10 EFLAGS: 00010202
Oct 23 22:12:55 kernel: RAX: 3d72d5dbe323fa0b RBX: 0000000000000000 RCX: ffff9bd2073a86c0
Oct 23 22:12:55 kernel: RDX: 0000000000141d90 RSI: 0000000000000dc0 RDI: 000000000002f0c0
Oct 23 22:12:55 kernel: RBP: 0000000000000dc0 R08: ffff9bd267c2f0c0 R09: ffffb7f14227fbbc
Oct 23 22:12:55 kernel: R10: 0000000000000001 R11: 00000000000003ff R12: 3d72d5dbe323f9db
Oct 23 22:12:55 kernel: R13: 0000000000000060 R14: ffff9bd266c03500 R15: ffff9bd266c03500
Oct 23 22:12:55 kernel: FS:  00007fb7c9ad1780(0000) GS:ffff9bd267c00000(0000) knlGS:0000000000000000
Oct 23 22:12:55 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 23 22:12:55 kernel: CR2: 00005609b7f06000 CR3: 00000001c1ad8000 CR4: 00000000000006f0
Oct 23 22:12:56 kernel: BUG: unable to handle page fault for address: ffffb7f14227fd48
Oct 23 22:12:56 kernel: #PF: supervisor read access in kernel mode
Oct 23 22:12:56 kernel: #PF: error_code(0x0000) - not-present page

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

Mert a nouveau nyílt forrású, a támogatott kernel része, ráadásul emlékeim szerint egy idő után az nVidia támogatni kezdte a fejlesztését. Nem hiszem, hogy a zárt nvidia garantáltan hibátlan, az viszont szinte bizros, hogy nem támogat 10+ éves hardware-t. A gépem 12.5 éves, és nem vagyok benne biztos, hogy nem az előző gépemből mentettem át a VGA kártyát. De ha nem, akkor is 2008-as a hardware. Elég, ha azt mondom, nincs még rajta HDMI csatlakozó? DVI és analóg VGA van.

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

Talán emlékszel, 2008 környékén öregedtek el tömegével úgy néhány éves alaplapok, hogy az alaplapi tápegység elektrolit kondenzátorai kiszáradtak, tetejükön kinyíltak. Akkoriban piaci értéke, reklámértéke volt annak, hogy hosszú élettartamú, tartós elektrolit kondenzátorokkal, és a terhelésüket csökkentendő, többfázisú PWM tápegységekkel adjanak el alaplapokat. Az az MSI alaplap, amelyet amúgy napi igen sok órában nyúzok, és stabilan megy, ebből a sorozatból való. Az öregebbik HDD-mben 31897 üzemóra van, az SSD-mben 10035h+05m+50.750s, az a HDD, amit akkor tettem be, amikor már fogyatkozott a szabad hely, csak 3183 órát járt.

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

Én a floppyt már kiszedtem, viszont van ebben a gépben két darab IDE (PATA) interface-szel rendelkező DVD íróm, az más kérdés, hogy évente talán egyszer teszek bele lemezt, mert van jó néhány audio CD-m. Van még két darab 500 GB-os HDD, meg egy 120 GB-os SSD benne.

Alapvetően nem szeretem a pazarlást, ellenérzéseim vannak a fogyasztói társadalommal szemben, mint Hajbinak, de nem viszem a dolgot a szélsőségességig. Egyszerűen csak azért nem veszek és rakok össze új gépet, mert ez még működik. Szemben Hajbival, nálam az oprendszer viszont a legfrissebb, legkorszerűbbek egyike, Fedora 33. A software lecserélése ugyanis nem pazarlás, abból falom az újat. A pipewire médiaszerver meg annyira friss, hogy Wim Taymans munkáját napi szinten húzom ki a git repóból, fordítok belőle binárist, csinálok csomagokat, majd telepítem fel a gépemre és használom. Sőt, van, amit saját ízlés szerint patch-eltem meg. :)

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

Egyszerűen csak azért nem veszek és rakok össze új gépet, mert ez még működik.

Aham. Gondolom a kocsiddal is ezt csinálod. 30+ éves kocsival jársz, amíg tudod megcsináltatod, mert ezekre még nem kell annyit költeni, mint egy 10+ évesre. Azt meg leszarod, hogy biztonság és fogyasztás szempontjából mennyire elavult.

Nagyon fasza lehet sata2-es porton ssd-t használni. Bár az igaz, a 120-as sata3 ssd-k alig gyorsabbak a sata2 sávszélességénél. A ramod meg az alaplapi buszrendszered lomhaságáról ne is beszéljünk. A villanyórádat is gondolom jobban tekeri és okádja magából a forró levegőt. Bár van, aki erre megy, hogy a fűtésen spóroljon.  Az elavult kijelző is biztos jót tesz a szemednek, ahelyett, hogy egy korszerűbb minőségi laptop kijelzőét bámulnád.

Zsír új oprendszer egy őskövület laptopon. Semelyik hardver nem indokolja az újabb rendszert. Azon még a Centos 6 is bőven jó lenne. Következő hónapban lenne csak aktuális a frissítés 7-re.

Furcsa egy humanoid vagy Te. De szerintem a szoftver folyamatos lecserélése is pazarlás abban az esetben, amennyiben tökéletesen kielégíti az igényeidet a régi, illetve nem hoz annyi pluszt, mint amennyi munkát beleölsz. Van egy olyan érzésem, hogy a sokkal több időt áldozol a fedorád karbantartására havi szintem, mint én a gentoomra. Miért? A leírásaid és blogod alapján a karbantartásod (update, upgrade, bugosság miatt downgrade vagy debuggolás) és erre még rájönnek az egyedi csomag készítések és gondolom ennek hozománya néha a függőségek miatti csomagok készítése. Ezt akárhogy nézzük, nem akarom elhinni, hogy havi átlagban nem veszi több idődet el, mint nekem a hardened gentoo-n egy emerge -avuDN @world, amit jobb esetben három hetente indítok, de előfordul, hogy másfél hónapig megfeledkezem róla, aminél tényleg max annyi a hiba, hogy néha valami nem fordul le, mert vagy helytelenül lett stabilnak megjelölve vagy pont egy olyan időszakban frissítek, amikor hirtelen nagyobb változás van és több gépelést meg műveletet igényel. Első esetben ha lusta vagyok várok pár napot és megjavítják, második esetben magam javítom ki, ami nem nagy meló, mert vagy bizonyos függőség nélkül fordítom le vagy kimaszkolom és régebbire frissítem, vagy hagyom az eredetit. Nálad még a hardver tényező is nehezítő körülmény. Biztos vagyok benne, hogy nekem egy havi adag frissítés lefordítása az erőművemen nem vesz több időt el, mint a Te szuper laptopodon a dnf update + félévente ugye az upgrade.

Csak a rendcsinálás kedvéért írtam le, hogy tájékoztassalak. Mert már vágtad a fejemhez, bár lehet nem Te, hogy pont egy gentoos pofázik a fedorára mennyire melós rendszer az.

Ha meg ilyen fordítóbuzi vagy használhatnál slackwaret is, de bármilyen forrásalapú disztrót is, persze csak egy újabb erős laptoppal.

Desktop gép. Hogy férne egy notebookba két DVD író, két HDD meg egy SSD? Amúgy semmi különös, egy legfeljebb 3.2 GHz-ről járó AMD Phenom II X4 955 és 8 GB RAM. Amire használom, arra a mai napig megállja a helyét. Őszintén szólva nem izgat, hogy egy mikrokontrollerre egy C forrás 8 másodperc helyett lefordulhatna 2 másodperc alatt akár. Ha 8 óra lenne a fordítási idő, számítana, de így nem.

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

A nouveau elmarad a radeon/amdgpu-tól minőségben - már amennyire minőségről lehet beszélni (a zaelot-ok kedvéért).

Az AMD több energiát feccölt a nyílt driver-be, mint az Nvidia a nouveau-ba.

Egy nem olyan régi Phoronix cikk rá is mutat, hogy mekkora kódbázis (természetesen annak előnyeivel és hátrányaival):

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-AMDGPU-St…

Pont emiatt Linux esetén ha diszkrét grafikus kártya kell, akkor radeon-t használok. Elég zavaró, hogy az utóbbi időben nehéz olyan prémium brand gépet találni, amihez ne Nvidia kártyát adnának a rászoktatott vendorok. Hiába hasít jól a Navi és veszi fel a versenyt az RTX-ekkel. Jó az Nvidia politikája. Ahogy az Intel-é is.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

A zárt nvidia driver természetesen ott van a szeren.

De akad olyan use case, amikor nem akar zárt driver-rel menni az ember és akkor számít, hogy melyik nyílt driver implementáció tart előrébb.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nem akarom blacklist-re tenni a frissítését. Mert nyilván egy rakás egyéb bug javul az újabb kernelekben. Épp most örvendek annak, hogy az OpenWrt/LEDE 5.4.74-esében már nem dobódik el a wan interface. Ezt megelőzően úgy emlékszem, 5.4.67-et néztem, abban még rossz volt.

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

( trn | 2020. 10. 28., sze – 17:31 )

Elvileg az 5.10 LongTerm lesz 2026- ig tamogatva (ugy emlekszem, https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.10-LTS-Kern…  olvastam, ezert remelhetoleg kijavitjak. Egyebkent nalam a munkahelyi gepemben jelentkezik a problema, az itthoni gepemben viszont nem. Munkahelyen egy "kernel: nouveau 0000:01:00.0: NVIDIA GT218 (0a8280a2)" van.  itthon viszont egy ilyen: "kernel: nouveau 0000:01:00.0: NVIDIA GK104 (0e4070a2)" ez egy 01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 760] (rev a1) kartya. A jelenseg: ugy tunik, mintha "megfagyna" a desktop (Xfce), de atvaltva az 1. konzolra majd vissza megy random ideig, majd ujra jelentkezik es igy tovabb. Megoldas: isszaraktam a 5.8.16- os kernelt.

Azt mondják a nagyok nem érdemes vanilla kernelt használni, mert háklis lehet tőle a rendszer. Nyilván egy vanillához közeli disztrónál ez nem probléma. Slackware talán ilyen. Archnál nem vagyok ebben biztos, de fedoránál tuti van különbség legalább biztonsági szinten. Annak ellenére tudok a vanilla kernel repóról fedorán, de nem tudom mekkora öngyilkosság pl használni.

Néztem a changelog-ot, szerintem nem javult ez meg. Persze, ha valami más borzolta ezt szét, akkor még akár jó is lehet. Így aztán 5.8.17-re frissítettem a nouveau-t használó gépemen, a picike notira pedig ment az 5.9.2-es.

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

A legnagyobb szívás, hogy 5.9.3 changelog-jában egyetlen találat sincs a nouveau keresésre. :(( Talán 5.8.18-at még lefordítják Fedora 33-ra, utána meg tehetem exclude listára a kernelt a frissítések konfigjában. Nagyszerű. :(

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

Talán 5.8.18-at még lefordítják Fedora 33-ra, utána meg tehetem exclude listára a kernelt a frissítések konfigjában. Nagyszerű. :(

Úgy kell Neked! Használnál normális disztrót! :P

Többet nem ajánlok semmit. Nem vagy rá méltó! :P

Olyan rossz, hogy nekem nincsenek ilyen szörnyű problémáim. :(

Na jó, de gondolom azért, mert 5.4-es kernelt szállít. Fedora is jól teszi a dolgát, de mi a fenét csináljak, ha van egy több, mint 12 éves VGA kártyám, amire már nem nagyon tesztelnek a fejlesztők, aztán összeesik az egész kártyavárként új kernellel. Marad az, hogy megtiltom neki a kernel frissítését, és reménykedem, hogy közben kikalapálják, addig meg jajveszékelek a bugzillában.

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

Ami kb hetente 2x frissül ott is...

De alapesetben, ha stabil profilt használ az ember gentoon, akkor csak lts kernel van. Tehát a verziószám jódarabig marad, csak biztonsági frissítések és hibajavítás van. KB félévente van lts váltás. De ugye gentoonál ez így ebben a formában nem teljesen igaz. Mert a kernel forrása frissül, a kernel akkor, ha magam lefordítom és telepítem. Az pedig akkor történik, amikor nekem tetszik, mint ahogy a rendszert is akkor és úgy frissítem, ahogy akarom. Sőt ha úgy tetszik, megtartom a régi lts kernelt, amíg lehet, csak meg kell mondani a portage-nek. Még akár a 4.4-eset is használhatnám. Hány éve jött az ki? Lassan öt éve.

The Linux 340.* legacy driver series is the last to support the G8x, G9x, and GT2xx GPUs, and motherboard chipsets based on them. Support for X.Org xserver version 1.20 was added to the 340.* legacy driver series with version 340.107, and support for Linux kernels up to Linux 5.4 was added with version 340.108. No further releases from the 340.* series are planned.

Akkor tenyleg nem lesz jo neked a zart driver. A regi eszkoz miatt, a driver is regi.

Venni kellene egy GT710-et, esetleg egy GT730-at, bár ez utóbbi nagyon eszi a villanyt. Viszont mégsem tűnik jó ötletnek, mert EOL mindkettő, 4 illetve 6 évesek a chipek. Erre a gépre nem költenék, hiszen elavult már ennyi idősen, de mivel jól működik, kidobni sem szeretném.

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

Igen, csak mint fentebb Czo írta, a régi hardware-hez régi driver jó, de ahhoz csak régi kernel való, szóval vagy új gépet veszek lassan, vagy bízom a kernel fejlesztőkben és a nouveau-ban, vagy nézek valami PCI-E-s VGA kártyát. Ma a legolcsóbb szutyok is biztosan jobb, mint ez a több, mint 12 éves VGA.

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

Nem tudom milyen kartyarol van szo, de itt tudod csekkolni hogy benne van-e a lagacy-agban  meg a kartya, ha igen (jo esellyel), akkor azt a drivert kell feltenni neki.

https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/

Én is egy regi gepet nyuzok meg (munkahoz tokeletes, 2009-es i5/8GB/Asus P7P55LX), benne egy NV Geforce GTX275.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Megnéztem, azt írja az újság, hogy ehhez a GeForce 8500GT-hez a 340-es nvidia való, az 1.20-as Xorg-ot - Fedora 33-ban ez van - 340.107-től támogatják, a kernelt ez a driver 5.4-ig 340.108-as drivertől. Ezzel nem vagyok előrébb, mert 5.8.17-ig jó vagyok a nouveau-val is, ráadásul az 5.8 mégis csak egy nagyobb szám, mint az 5.4.

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

Itt most az a kerdes, hogy mi a fontos? Oreg vason legfrissebb kernel, vagy oreg gepen meg használható, stabil rendszer. Emlekeim szerint egy nyugdijas gepemben van egy ilyen kartya (passziv hutessel), valamiregi debiannal, evente egyszer kapcsolom be, tokjol mukodik, de nem is volt meg igenyem az 5x-es verzioju kerneleket probalgatni rajta.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Legfrissebb Fedora az igényem, az szállítja a legfrissebb kernelt is. Ráadásul ez épp az elsődleges gépem, ezen csinálok mindent, legyen munka, hobby, zene, film. A kis notebook-on csak zene, film, hírek olvasása, meg főzés közben receptek nézése. :) Amúgy azon is friss Fedora van, de az Intel VGA-s, az most épp működik. Azért írom így, mert 5.4-es kernel elején épp az Intel volt nagyon beteg, akkor a nouveau ment jól.

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

Legfrissebb Fedora az igényem

Ha ragaszkodik az ember a szoftver állandó aktualizálásához, ahhoz időnként a hardvert is aktualizálni kell. A 12 éves vas már az "időnként"-en rég túl van. Ez már csak egy ilyen világ.

Konyhanyelven: Nagymamának nem áll jól a vadi új bikini.

" az szállítja a legfrissebb kernelt is. "

Azért ne csináljunk úgy, mitha egy régebbi kernel felrakása akkora trúváj lenne... Főleg, hogy nem valami ancient, 3.x előtti kernelről beszélgetünk, hanem az 5-ös főágban párral visszább. Same with the closed driver.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( locsemege v | 2020. 11. 02., h – 21:08 )

Közben úgy látom, 5.8.18-at még lefordítják Fedora 33-hoz, így 5.9.4-ig reménykedhetek, vagy egy darabig utána is, csak akkor nem szabad hagynom a kernel frissítését.

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

( locsemege v | 2020. 11. 09., h – 22:40 )

Ugyan nem tudom, mi a bug és annak lehetséges javítása, de bizakodó vagyok. Néztem 5.9.7 előzetesét, és egy rakás nouveau patch van benne.

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

( locsemege v | 2020. 11. 11., sze – 17:05 )

Úgy néz ki, 5.9.7-ben, és ezáltal az azóta megjelent 5.9.8-ban megoldották a nouveau bugját. :)

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

Nem tudom, hiszen a nouveau-t használom. Ha megnézed a changelog-ot, azt javították, így nem hinném, hogy ennek hatása van a zárt nvidia driverre. Bár lehet még egy rakás patch, amelynek meg igen. Vagy a zárt driver-t is javíthatták.

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

Ez az állításom rágalom. :( Nem igaz. Nem javult meg. Egyszer csak előjött a baj megint, és roppant kellemetlen:

[ 5600.220947] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 5602.226127] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 5604.293012] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 5606.308804] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 5608.313840] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 5610.319525] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 5612.325614] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 5614.330375] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 5616.337322] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 5618.343844] nouveau 0000:01:00.0: DRM: base-0: timeout
[ 5620.348815] nouveau 0000:01:00.0: DRM: base-0: timeout

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

( locsemege v | 2020. 11. 17., k – 15:20 )

Úgy nézem, 5.9.9-ben sem lesz megoldás. :( Egyetlen nouveau javítás sincs, ami drm, az mind intel és amd.

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

( locsemege v | 2020. 12. 04., p – 21:13 )

Dolgoznak ezen a regresszión.

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

( locsemege v | 2021. 02. 04., cs – 18:37 )

Megoldva 5.10.13-ban. Már ez fut a gépemen, valóban működik.

commit e4d2a196fdc5f7eeab21d3d6a27566f3dc1f4d60
Author: Bastian Beranek <*>
Date:   Thu Jan 21 15:27:36 2021 +0100

    drm/nouveau/dispnv50: Restore pushing of all data.
    
    commit fd55b61ebd31449549e14c33574825d64de2b29b upstream.
    
    Commit f844eb485eb056ad3b67e49f95cbc6c685a73db4 introduced a regression for
    NV50, which lead to visual artifacts, tearing and eventual crashes.
    
    In the changes of f844eb485eb056ad3b67e49f95cbc6c685a73db4 only the first line
    was correctly translated to the new NVIDIA header macros:
    
    -               PUSH_NVSQ(push, NV827C, 0x0110, 0,
    -                                       0x0114, 0);
    +               PUSH_MTHD(push, NV827C, SET_PROCESSING,
    +                         NVDEF(NV827C, SET_PROCESSING, USE_GAIN_OFS, DISABLE));
    
    The lower part ("0x0114, 0") was probably omitted by accident.
    
    This patch restores the push of the missing data and fixes the regression.
    
    Signed-off-by: Bastian Beranek <*>
    Fixes: f844eb485eb05 ("drm/nouveau/kms/nv50-: use NVIDIA's headers for wndw image_set()")
    Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/14
    Signed-off-by: Ben Skeggs <*>
    Signed-off-by: Greg Kroah-Hartman <*>

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

( Nextra | 2021. 02. 04., cs – 22:42 )

Látom itt nvidia szakértők vannak. Kérdésem, mivel már annyi mindent olvastam s annak az ellenkezőjét is, hogy MA mi a tényállás nvidia fronton?

Van egy nvidia gt710 (gk208B) kártyám, és nvidia 460 zárt meghajtót használok, de míg a grubban a lecserélt háttérkép (splash) méret és arány helyesen  jelenlik meg, a tty az szvsz 640x480-ban egy FHD monitoron. Szörnyű.
Jelenlegi beállítások. 

GRUB_CMDLINE_LINUX="nouveau.modeset=0 "
GRUB_CMDLINE_LINUX_DEFAULT="quiet nosplash nopti noresume noiswmd audit=0"

/etc/modprobe.d/balcklist-nouveau.conf (és abban is)

Kell a nokmsboot most kernelbe vagy nem? Miért nem jó a tty felbontása? Az arch linuxosok szerint a vga= elavult, és a 

GRUB_GFXMODE=1920x1080-32
GRUB_GFXPAYLOAD_LINUX=keep

a megoldás, de ez nem elég. Ma vettem új FHD monitort, és még azt sem tudom hogy mi a jó vga paraméter hozzá, mert talán az menni fog.

Tudom a framebuffer a gond, de tényleg nincs erre valami gyógyír? (uvesafb nélkül) Olyat is olvastam hogy nem kell letiltani a nouveaut, mert már pariban van az nvidiával, s akkor jók lesznek a felbontások tty-ben is. Hát nem tudom.

Teljesítményben nem tudom, hogyan viszonyul egymáshoz a zárt és a nyílt driver, de gondolom, függ a hardware-től is. Én nem játszom, ami érdekel, hogy menjen a compiz. A nouveau driver már igen régóta támogatja a glx-et, így aztán zökkenőmentesen működik.

A kérdéseidre nem tudom a választ, nekem is a netről kellene kinéznem. Ha jól látom, a kernel commandline-ban nekem nincs nouveau specifikus bejegyzés. Egész egyszerűen minden autodetect, és minden jó is így.

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