kernel fordítás, boot halál fekete képernyővel

 ( GCS | 2009. július 14., kedd - 9:02 )

Majd 15 éve használok Unix/Linux variánsokat. Mindíg is saját kernelt használtam, nem csak a stabilakat de az -rc -ket is.
Viszont egy jó ideje nem tudok működő kernelt fordítani. Legutolsó ami a mai napig biztosan működik, az a 2.6.30-rc2. Azóta az összes -rc és stabil kernelt próbáltam életre kelteni valahogy így:
Adott patch letölt, előző kernel könyvtár törlése. Kernel kitömörítése, patch bele. 2.6.30-rc2 konfigurációjának bemásolása .config -ként majd make oldconfig. Esetlegesen felmerülő kérdésekre értelemszerűen válaszolok. make && make modules_install install . Beállítom a grub-ben majd boot.
Eredmény: fekete képernyő a grub után és sokszor lefagy vagy csak ctrl+alt+del -re reagál. Van amikor sípolás van fekete képernyővel. Legvizuálisabb amikor simán újraindul rögtön a grub után a kernel betöltése helyett. Elég ritkán simán CRC hibát ír és azt hogy a rendszer halt állapotba került.

Amiket próbáltam: make allnoconfig, majd egyesével engedélyezni azokat a részeket amelyek szükségesek. Egyszer eljutottam odáig (folyamatosan engedélyezve a plusz lehetőségeket) 2.6.30(.1?)-al hogy ment a boot, volt hang, ment a hálózat és ment az Xorg-is. Sőt, hozzá tudtam adni a VirtualBox 3.0 kernel driver-eket és ment is a VirtualBox. Egy gond volt vele, nem volt hang a virtuális gépben. Engedélyeztem az ALSA OSS emulációját, majd reboot. Innentől megint halál, fekete képernyő. Időnként mentegettem a működő .config-ot, de valamit rosszul csinálhattam vagy nem tudom mi történt, de már azzal újrafordítva sem boot-ol.

Ami számíthat: Asus P5B alaplap, Core2Duo proci és 6 Gb RAM van a gépemben kétfejes ATI grafikus kártyával. 64 bites Debian testing/sid a rendszer, naprakészen tartva. A root FS az JFS.
Bármilyen ötletet szivesen veszek. Sajnos próbáltam Debian kernel-eket is, azok sem boot-olnak.

Egyszer úgy volt hogy meg kell néznem működik-e egy SB Audigy hangkártya. Ehhez visszaálltam 2.6.30-rc2 forrásra, bemásoltam a futó konfigurációt és csak az Audigy-t fordítottam pluszban bele. Tanulva az előzőekből extra névnek hozzátettem a -audigy jelzőt. Boot -> kernel halál. Innentől gyanakszom az új gcc-kre, libc6-ra, bármire ami userland. Hardware változtatás ugyanis nem volt. Egy szálon fordítok, régebben néha két szálon ment és akkor sem volt gond. Jó ideje már frissítettem BIOS-t, azaz nem az eredeti van az alaplapon (de hivatalos) és hosszú ideje semmi gondom nem volt vele. Most sem hiszem hogy az lenne a gond.

Hogyan tudnék ilyen problémát debug-olni? Ami eszembe jutott hogy felteszek egy stable chroot-ot és abban fordítok kernelt. Hazamegyek, ki is próbálom. Ha az abban fordított kernel sem működik, akkor végképp nem lesz ötletem mit csináljak. :-|
Olvastam valami JFS bugról, amely akadályozta a kernel helyes betöltését, de azt javították, nemde?
Ha memória hiba lenne, akkor a régi kernel sem boot-olna szerintem, valamint egyszer nem sikerült volna többszöri fordítással és többszöri boot-tal felépíteni egy egyre funkcionálisabb kernelt.

Update #1:
Régi saját fordítású kernelek akkor is boot-olnak, ha a modul könyvtárakat előzőleg leszedtem alóluk. Régi Debian kernelek közül egy ad crc error - System halted üzenetet, többi boot-ol.
Régi saját kernelek a következő üzenettel kezdenek (régen is így volt és sokáig működtek):

Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[    0.236787] PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved
[    0.236816] PCI: Not using MMCONFIG.
Loading, please wait...
[    1.144098] hub 4-0:1.0: unable to enumerate USB device on port 2
INIT: version 2.86 booting
[...]

Amely kernelek reset-elnek, azoknál a Decompressing Linux... villan fel közvetlen a reset előtt.

HW hiba szerintem kicsukva, gép napi 24 órában simán megy. Kb hat Firefox ablak ötven füllel + virtualizált OS + dnetc mindkét processzormagon + torrent miatt ami a hálózaton kifér három HDD-ről gyönyörűen megy. Memtest-et futtattam, 6 Gb-al elég lassan megy, de 37%-ig lefuttatva az összes tesztet egyetlen hibát sem kaptam.
Működő kernel újrafordítása ugyanazzal a konfigurációval (csupán kapott egy -retry verziónév toldást) fekete képernyőt ad. Ugyan nem fagy le (ctrl+alt+del -re újraindul), de a fekete képernyőn túl más nincsen.

Kérdés, mit jelent a parsing ELF közvetlenül a kernel betöltése után? Az a binárisok felépítése és azt leszámítva hogy a kernel tudja őket kezelni még nem tudom mit keres ott amikor még a root FS sincs csatolva?

Update #2:
Csomagfrissítés volt ismét. Rohanvást voltam, de mintha gcc is benne lett volna.
Letöltöttem a legújabb Karmic napi live CD-t, szépen boot-olt 2.6.31-3 csomagverziójú kernellel. Felmount-oltam a Debian partíciómat és lefordítottam az azon lévő 2.6.30.1-es kernelt a korábban mentett és működő konfigurációval. Ezzel ismét boot-ol a gép és a már futó rendszer alatt fordítottam VirtualBox 3.0.2 kernel modulokat. Azokat hiba nélkül betöltötte és működik is a virtualizáció. Ugyanaz az egy gond van vele mint előzőleg. Mivel kihagytam az ALSA OSS emulációját a kernel-ből, a virtualizált OS alatt nincs hang.
Ebből én azt a következtetést vonom le hogy a Debian gcc-je az ami nem bír a kernellel (vagy megint szerencsém lett volna?). Távoli ismeretségem van Martin Michlmayr GCC teszterrel (fejlesztővel?), majd megpróbálom izolálni a problémát a segítségével.

Update #3:
Ubuntu alatt bekapcsoltam még az ALSA OSS emulációját plusz egy-két kimarad USB-s opciót. Továbbra is boot-ol. Elkapott a kisértés, lefordítottam Debian alatt, most ott is boot-ol. Meglehet hrgy84 soraiban van némi igazság, vagy mégis az a bug, amiért kiadták a 2.6.30.2-őt:

commit d7de59fb74b6e9b94af8b9fcbfdf39eeae3b27be
Author: Linus Torvalds 
Date:   Sun Jul 12 11:25:04 2009 -0700

    Don't use '-fwrapv' compiler option: it's buggy in gcc-4.1.x
    
    commit a137802ee839ace40079bebde24cfb416f73208a upstream.
    
    This causes kernel images that don't run init to completion with certain
    broken gcc versions.
    
    This fixes kernel bugzilla entry:

http://bugzilla.kernel.org/show_bug.cgi?id=13012

I suspect the gcc problem is this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230

    Fix the problem by using the -fno-strict-overflow flag instead, which
    not only does not exist in the known-to-be-broken versions of gcc (it
    was introduced later than fwrapv), but seems to be much less disturbing
    to gcc too: the difference in the generated code by -fno-strict-overflow
    are smaller (compared to using neither flag) than when using -fwrapv.

Forrás.
Fordítottam 2.6.30.2-őt az előző konfiguráció alapján, szépen boot-ol és működik.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

régen én is forgattam, de ma már meghagyom ezeket a szopásokat a distributornak :>

Core2Duo T7100, 4G, Ubuntu 9.04, 2.6.30

Új disztrib kernelek sem mennek...

Első körön döglődő HW-re gyanakodnék.
Nekem egyszer volt a kernel betöltés CRC erroros, amikor nem volt rendesen rádugva a vinyó kábel, de ez jó régen volt.

Rövid ideig én is gondoltam rá, de asszem a régi kernelek mindegyike működik továbbra is. Majd végignézem az összeset. Újak közül meg egyik sem megy. Ilyen váltást hw hiba nem eredményez véleményem szerint.

Ha régi kernelt, régi, működő konfiggal újrafordítasz, az is működik? Lehet hogy már a fordításnál van a bibi.

Nem működik, azaz vagy az userland vagy maga a GCC problémázhat.
GRUB mekkora partíciót tud teljesen megcímezni?

Idézet:
Hogyan tudnék ilyen problémát debug-olni?

Soros konzol + CONFIG_EARLY_PRINTK=y ?

(azonban elotte egy memtest+portalanitas ajanlott, annak nagyobb az eselye)

CONFIG_EARLY_PRINTK=y asszem benne van. Soros konzolra mit/hogyan tudok tenni?

A kernel parancssorhoz add hozza:

console=ttyS0,115200n8

A tesztelnivalo gep ttyS0-jara radugsz egy nullmodem kabelt, a kabel masik vegere meg egy terminal emulatort (minicom/hyperterminal), es ott fogod latni a kernel uzeneteit. Remelhetoleg kiirja majd, hogy mi baja, ha nem, akkor is latod majd, hogy nagyjabol meddig jutott el. Innentol kiserletezni kell...

Vagy egy VT420-at :D

Nagyobb az eselye, hogy egy olyan gepet talal amin a minicom/hyperterminal elfutkos, de vegulis ez is tokeletesen mukodne... :-)))

Vigyázz, régen használtam ilyet. Fapados, de a célnak megfelelt.

Mi a helyzet a bootolható linux cd-kel? Pl system rescue cd, vagy linuxos telepítők elindulnak rajta?
Az nekem továbbra is több mint gyanús, hogy a gyári kernel is crc hibával nem töltődik be...

Az nem lehet, hogy az újabb kernelekbe bekerült vmi olyan feature, vagy patch, ami nem kompatibilis a gépeddel? Nekem pl a 2.6.24 működött eddig a legjobban, de az inteles fiúk "driverirogatósdiuk" miatt kénytelen vagyok frissítgetni, és velem is előfordul, hogy egy egy verzióban vmi nem tökéletes, hiába az azonos .config...

OFF/ Apropó, nem értem, mi a francnak kell a videódrivert a kernelbe fixen beledrótozni, miért nem lehet külön modulként fordítani??? Így mindig lehet új kernelt használni, ahogy fejlesztik a drivert, és ja, előfordul, hogy az újabb kernelben meg más nem megy... /OFF

<= Powered By Ubuntu & Gentoo Linux =>

'Software is like sex: It's better when it's free!'
By Linus Torvalds

Az is lehet hogy valamelyik kernel fejlesztés mellékhatása ez. Neten rákeresve elég sok ASUS alaplaposnak van/volt ezzel hasonló problémája.
Van aki kikapcsolta a VT támogatást a BIOS-ban és azóta boot-ol. Megnéztem, nem találtam meg hol lehetne kikapcsolni.
Lényeg, a futó kernel-t annak konfigurációjával újrafordítva is ugyanez a hiba van. Ergo nem kernel verzió és nem kernel konfiguráció probléma.

Próbáltam BIOS-t frissíteni, de nem jött össze. Se USB kulcsról, se CD-ről nem veszi észre már magát a meghajtót sem a kedves BIOS. Mondjuk van valami olyasmi is benne mintha nem lehetne kezelni a beépített flash-előjét. FreeDOS-sal boot-olva a DOS-os égető szerint nem AWARD BIOS-t szeretnék flash-elni így nem is megy tovább.

Ötletek összevissza, teljesség igénye nélkül:

- PCI= Direct,BIOS, vagy MMC? (megjegyzés: direct rulez)

- Próbáld meg, hogy lekapcsolod a gépet, áramtalanítod egy 5 percre, és utána próbálod indítani a gépet. (Vannak egyes suspend-to-ram problémák amiket így lehet megoldani, a hibajelenség az, hogy a rendszer nem jön vissza szundiból, a gépet le kell kapcsolni, áramtalanítani és újra bekapcs után megy rendesen. Ez alapján úgy tűnik a hw lekapcsolás elég érdekes újabban.../ újabban=2.6.26+/ )

A szundi lemenetel, vissazjövetel picit hasonló a boot hoz hw szempontból / pl. CPU booting (másodlagos cpu, szundinál mindig csak egy magot hagy meg, a másikat lekapcsolja )/. Egy próbát talán megér ha semmi egyéb ötlet nincs.

- Live CD/DVD -k bootolnak? telepítő cd/dvd? ha nagyon userland gyanus a dolog ?

- Használsz-e initramfs t ? Ha igen, betöltöd-e az initrd fájlt, ha igen megfelelőt-e? Mivel hazsnálsz extraversiont, lehet az initramfs körül van a gebasz? Ha mindenjó próbáld meg initramfs nélkül, ha nem használtál initramfst próbáld meg azzal. / 2.6.27nél ehci t tedd kernelbe uhci(?)t tedd modulba. ha ehci másodikként tölt be warning üzenet jön, hogy cseréld meg, ha mindkettő modul kicsit nehézkesebb szabályozni ki legyen gyorsabb, ha ehci kernelben van, másik modulban akkor biztosan nincs vita /

- Milyen memóriakezelést használsz? nohighmem highmem4g highmem64g ?

- Különféle bootparaméterek: vga=normal (framebuffer elkerülésére) mem=nopentium (ezzel óvatosan ha használsz PAE t akkor nem bootol /processzornál fagy be/ highmem4g nél viszont nekem bevált.)

- notsc (cpufreq váltáskor a tsc amúgy is unstable lesz, úgyhogy kb. tökfölösleges.

- BIOS alaplapi göncök letiltásakor javul e a helyzet? (hang, hálókártya, USB, proc hw virtualizáció support (s)vm, , cpufreq support (amd nél cool'n quiet, intelnél nem jut eszembe a neve, stb)?

- Ép e a fájlrendszered ? ép e a vinyód /mbr?/ ? (=livecd/dvd alól fsck.*fs + smartmontools)

- Megy-e a ventillátor? Nincs-e a biosban egymást kizáró 2 opció? pl. cpu fan warning és silent mode+asus qfan / silent mód és asus qfan alacsonyan tartja a venti fordulatszámot, ettől viszont a cpu fan bios warningot / is / dob...

- smp nélküli kernel

- Egyéb boot paraméterek amik segíthetnek esetleg:

noacpi noapic , vagy az a boot paraméter amivel a processzor szám megadható 1 nek (afféle nosmp?) acpi=ht estébé documentation/kernel-parameters.txt

- vedd ki az audigy hangkártyát anélkül hogy reagál.
- próbálj ki minél kevesebb dolgot kernelbe fordítani. csak processzor + root fájlrendszer support nohighmem el usb, alsa, estébé nélkül / ez vagy modulba, vagy sehogy / hogy bootol-e. MCE t szintén kapcsold ki./ machine check exception /

- 2.6.27+ fölött van valami AMI Bios workaround kiválsztható cucc.

U.I: Én elsőre arra tippelnék rossz az initrd.img...mivel ugyanaz a config, ugyanaz a kernel újrafordításnál nem volt jó.

Működő kernel újrafordítása ugyanazzal a konfigurációval (csupán kapott egy -retry verziónév toldást) fekete képernyőt ad.

Ez majdnem biztos (90%+) , hogy framebuffer megjelenítési próbléma vga=normal t neki, akkor többet látsz, hogy meddig jut el.

----------------------

r=1 vagyok, de ugatok...

PCI=direct asszem.

FB-t elkerültem azzal hogy nem is választottam ki a fordításnál.

Boot-okat próbáltam úgy is hogy megállítottam a gépet. Tápkábel kíhúzása után (csak) egy perc várakozás, tápkábel vissza, boot. Ugyanazzal az eredménnyel, fekete képernyő. Félreértés elkerülése érdekében: a grub boot sorai ottmaradnak kint, azok nem tünnek el. Viszont semmi más nem jelenik meg a képernyőn, marad üres fekete. Ezért sem hiszem hogy FB probléma. Boot sorból a quiet-et szoktam kivenni, nem kapok több információt.
Néha mintha töltene még valamit a gép, mintha csörögne egy kicsit a HDD, de nem jelenik meg plusz információ a képernyőn.
ctrl+alt+del hiába él, sysreq-ra nem ad semmilyen információt. Kernel-be fordított betűkészlet soha nem volt külön engedélyezve, meg fogom próbálni hátha mégis azokkal kiír valamit.

Legújabb Karmic CD-ről boot-oltam a memtest-et, Linux-ot nem. Majd megosztom mi volt az eredménye a telepítő elindításának.

Fordítottam olyan minimális kernel-t is amelyben nem volt SMP, ACPI, de nem hatotta meg.

Nem szeretem az initramfs-t, nem használom. Debian kernel-ek használják. Ami régi az boot-ol mindegy hogy initramfs-es vagy sem. Ami nem boot-ol, abból is van sima és initramfs-es; a lényeg hogy azok az újabb kernel-ek.

BIOS-ban kerestem hol lehet letiltani a HW virtualizáció támogatását (VT), de nem találtam meg. Ventik állandó fordulaton voltak alapból, nem ment a boot. Tegnap beállítottam halk üzemmódra őket, továbbra sem megy a boot.

Maradt benne a saját SB Live!-om, az Audigy nem került bele. Kernel opcióként volt bent egy ideig.

Memóriakezelés highmem4g asszem, de erre nem vennék mérget.

a grub boot sorai ottmaradnak kint, azok nem tünnek el.

hát ez így gáz. lilo -val sem bootol / vga=normal /? Ott talán jobban ki lehetne hozni, hogy a bootolás melyik fázisában dől össze. L I L O, vagy pedig ez még lemegy, aztán Bug Int...stb...

Én még az sb live ot is kivenném, meg az audigy t is, meg az ati t is (hátha táp kevés??? bár érdekes hogy kernelfüggő) és ati helyére valami pci os retek (s3trio64).

Nekem is ASUS alaplapom van, bár én a kvarcjáték kategóriában csodaintellel szemben (M3A), itt A menüben F4 re rejtett bios opciók is előjönnek.

Ha a LILO val kiderül, hogy a booton átlendül csak Bug INt kóddal összedől, akkor szép sorban:

- Serial port disabled.
- Onboard lan disabled
- Onboard audio szintén
- plug and play OS : No
- usb functions: disabled
- acpi 2.0 support disabled
- acpi apic support disabled
- amd cool n quiet (intel megfeleljőjét nem tudom, ami támogatja a cpufreqet) disabled
- a hw virt et néztem az alaplapi kézikönyvben nincs benne, de a biosban én már tiltottam le de lehet hogy rejtett opció volt
- fdd 1.44 floppy support legyen a biosban akkor is, ha nincs floppy meghajtó a gépben. van ezzel kapcsolatosan egy asus bios bug, persze ez simán lehet alaplapspecifikus. / hibajelenség, ha nincs fdd 1.44 nem bootol be cd ről :-) / IDE cd meghajtó :-) /
- ha highmem4g, akkor mivel nincs pae, tsc se nagyon ha van cpufreq a mem=nopentium megér egy próbát, max nem bootol :D

--------------

r=1 vagyok, de ugatok...

Kicsit késő van hogy nekiessek, így csak néhány megjegyzés:
- próbáltam elég alap kernellel is, se lan, se hangkártya, se USB, se ACPI, de még SMP sem volt; azzal se nagyon ment
- van IDE és sATA DVD író is a gépben, mindkettőről boot-ol, floppy támogatás kilőve
- Audigy nincs benne, Live!-ot és az ATI videókártyát kivehetem; de ha akkor van boot az nem izgalmas mert se hang, se grafikai megjelenítés nem lesz
- táp direkt nagyobb lett választva, 400 W-os; teljesítménye biztos hogy nem kernel függő
- lásd update #2 megjegyzéseimet: Ubuntu live CD-ről boot-olva és annak fordítóját használva működő kernel-t kaptam az előzőleg is használt (de Debian gcc-vel fordítva nem boot-oló) konfigurációval
- HW virtualizációt asszem én is láttam már a BIOS-omban, legutóbb nem találtam; de lásd fentebb, most ugyanazzal a konfigurációval csak Ubuntu alatt fordítva boot-ol/működik a kernel és van HW virtualizáció
- a HIGHMEM opciók nem csak 32 bites x86 kerneleknél van? x64-re fordítok, nem találom ezt az opciót, valszeg azért mert x64-on nincs is erre szükség

De igen, highmem csak x86nál van. nem figyeltem, hogy x64ed van.

update2 érdekes...most olvasom :)

Debianban is többféle gcc van. asszem 4.3.2 az alap.próbálj 4.1et vagy 4.2t, hátha :-)

Vagy ha uborka működik, akkor használd azt. :-)

ALSA t szerintem lehet használni virtual alatt.
Én már nem eméxem honnan, és miért de a kvm et ezekkel az opciókkal indítom:

export QEMU_AUDIO_DRV=sdl
export SDL_AUDIODRV=alsa
export SDL_VIDEO_X11_DGAMOUSE=0

És így a vdekvm az alsat használja az OSS helyett. az x11dga nememléxem miért van , valami oka annak is biztosan volt.

----------------

r=1 vagyok, de ugatok...

elvileg stock debian kernelt 4.1.X-el porgetik, de fixme
___
info

veletlen nem kapcsoltad ki a console dev supportot?

meg anno lattam valamit(fixme) Frans Popl-tol (debian kerneles), hogy az ujabb kernelekkel segfautol az init lehet itt van a kutya elasva

szerk:

megvan: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536354

de ez teged nem erint (s390)
___
info

sztem jfs környékén van a probléma, de ez csak egy tipp, minden alap nélkül :)

nincs cserediszked? felhúzhatnál rá egy alap os-t, pl. ext4-el, aztán azon nézd meg az új fordítású kerneleket.

Elolvasva a topicot, en elso korben grub cseret javaslok (pontosabban frissitest). A leirt hibajelensegek alapjan azt valoszinusitem, hogy valamiert az uj kernelek tarolasi helyet nem tudja becimezni a fajlrendszeren belul. Eleg alap fajlrendszer support van benne.

--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Szia,

Ez ott sántít, hogy az Ubuntu alatt fordított kernel-eket is ugyanazzal a grub-bel boot-olom. Ugyan lehet véletlen hogy az Ubuntu-val fordítottak mindíg jó helyre esnek, a Debian-osok meg egyszer sem; viszont kicsi a valószínűsége. Mindjárt írok még egy update-et.

/GCS

Üdv!

Nekem is debian, unstable, 2 gépen is, szintén saját 2.6.30 kernel.
Az előző verzió (2.6.30-2) még simán ment mindkét gépen, de a 30-3 fordítása óta egyiken sem. De ha a 30-2-t most újraforgatom, akkor az se jó, tehát vm fordítási hiba van. Sajnos nem emlékszem volt-e mostanában gcc update az utsó működő fordítás óta.
Most jön az, hogy régebbi gcc-t teszek fel... Talán...

Próbáld ki a 2.6.30.2-őt fordítani, a vanilla változatot.
Illetve és/vagy Ubuntu live CD alatt pörgesd a kernelt.
Tegnap nem jutottam el odáig hogy kipróbáljam a 2.6.30.2-őt, de bízom benne hogy boot-olna.

2.6.30.3-at lefordítottam 4.1-el,s megy minden simán(kernel és gcc is eredeti debianos)
A gond a 4.3-as gcc-vel volt.

Olvastad update #3-at? Kernel-ben küszöböltek ki egy gcc hibát, ami nem Debian specifikus. Lényeg, ha van időd/kedved akkor próbáld ki 4.3-as gcc-vel fordítani a 2.6.30.3-at. Azzal is mennie kell.

Hát sajnos mindkét gépen az alapértelmezett a 4.3 gcc, s akkor jött elő a probléma, amikor #3-ast fordítottam, tehát nem megy.
Igen, tudom, h a 2.6.30.3 elvileg gcc optimalizáláskor belekerülő bugot javítana, bár ez a debian changelogból nem igazán derül ki számomra.
4.1-el sima ügy.

Egy szó mint száz sajnos pont ez a felállás bootképtelen.

Na, frissült unstableben a gcc és a kernel forrás is, próbáltam egyet,s semmi gond. A changelogok alapján nem tudom megfejteni, hogy tudatos-e a javítás, de nem is vagyok járatos a kernel+gcc dolgokba.