egyveleg: Lenny-ről Squeeze-re, oprofile, radeon, KMS, dpkg-divert, dvdisaster

(1) Először irdatlan munkával újrafordítottam (csomagba) a Lenny kernelt, hogy legyen mind debuginfo-m, mind vmlinux file-om. Enélkül ugyanis az oprofile nem használható, és én tudni akartam, pontosan hol is pocsékoljuk azt a sok CPU-t. Több helyről is puskáztam (pl. innen), de sok minden adódott, amit kénytelen voltam saját kútfőből meríteni. (A kommenteket most nem fordítom át magyarra a jegyzetemből.)

# as root:
apt-get install build-essential fakeroot devscripts
apt-get build-dep linux-2.6

joe /etc/apt/sources.list
# make sure that security.debian.org is the first deb-src line

# as non-root
apt-get source linux-image-2.6.26-2-amd64
cd linux-2.6-2.6.26

joe debian/config/defines
# append "+dbg.1" to [abi]/abiname

debian/rules debian/control-real

joe debian/rules.real
# add the following command to the
# "install-image_amd64_$(FEATURESET)_$(FLAVOUR)_plain_image" target:
# install -m644 '$(DIR)/vmlinux' $(INSTALL_DIR)/vmlinux-$(REAL_VERSION)

debian/rules source

dch --local +dbg.
# change the distro name to UNRELEASED when the editor is invoked
# add a single comment like "enable debug symbols"

fakeroot make -f debian/rules.gen setup_amd64_none_amd64
cd debian/build/build_amd64_none_amd64

sed 's/^# CONFIG_DEBUG_INFO is not set$/CONFIG_DEBUG_INFO=y/' \
    </boot/config-2.6.26-2-amd64 >| .config

diff /boot/config-2.6.26-2-amd64 .config
cd ../../..
nice -n 19 fakeroot make -f debian/rules.gen binary-arch_amd64_none_amd64 \
    DEBIAN_KERNEL_JOBS=$(( 2 * $(getconf _NPROCESSORS_ONLN) ))

cd ..
dpkg -c linux-image-2.6.26-2+dbg.1-amd64_2.6.26-26lenny4+dbg.1_amd64.deb \
    | less

# root-ként:
mount -o remount,rw /boot
dpkg -i linux-image-2.6.26-2+dbg.1-amd64_2.6.26-26lenny4+dbg.1_amd64.deb
mount -o remount,ro /boot

# Catalyst kernel driver átmentése
cp -aiv \
      /lib/modules/2.6.26-2{,+dbg.1}-amd64/kernel/drivers/char/drm/fglrx.ko

Na, ezek után kiderült némi oprofile futtatásból, hogy a CPU pocsékolásért nem a (meglehetősen perifériális) Pegasus driver a felelős, hanem az ehci-hcd interrupt handler-e. Ez megnyugtató volt, ugyanis ebből látszott, hogy nem az eszközzel van gáz közvetlenül; az ehci központi, és későbbi kerneleken (más gépeken) a dugasz nem is produkálta a csúcsokat.

Az ehci-hcd-nek meg lehet éppen mondani (

log2_irq_thresh

), hogy az interrupt-ok között minimum mennyi időnek (hány "microframe"-nek) kell eltelnie; ezt magasra állítva a csúcsok szépen kisimultak. Azonban az usb-s diszkem (nem pendrive, rendes diszk) elérési sebessége leesett kb. 3 MB/S-re, így ez ment a kukába.

(2) Ezután megpróbálkoztam a lenny-backports kernelével. Először is, ezalatt nem ficcent be a korábbi catalyst kernel modul. Aztán még az snd-hda-intel-lel működő alaplapi hangkártyát is használhatatlanná (vagy legalábbis teljesen újrakonfigurálandóvá) tette. Egy ideig bohóckodtam friss radeon ill. radeonhd X driver fordításával, ami úgy-ahogy ment is, de aztán kukáztam.

(3) Végül rászántam magam a Squeeze kézikönyv szerinti felhordására. A dist-upgrade sikeres volt. Végre megszabadultam a catalyst driver-től, mert a Squeeze-ben lévő radeon már jól viszi az alaplapi Radeon HD 4200-at (RS880-as chipset). 3D támogatásról lemondtam, nem fogok nexuiz-zal játszani. Egyébként a catalyst driver alatt az mplayer xv outputja irdatlan kernelmódú CPU terhelést generált (oly mértékben, hogy végül x11+zoom-ra raktam át), a squeeze free radeon driver-ével pedig meg sem moccan az IceWM CPU görbéje (kivétel persze a h264).

Azóta mindenestre folyamatos a konfig-hajtépés, ahogy tartottam is tőle. Csak a főbb dolgok:

(3.1) A radeon KMS hatására nagyítóval kellett néznem a konzolt. Kiderült, hogy Debian alatt kétféle csomag-erdővel lehet konzolt hekkelni, a kbd csúcsúval, illetve a console-tools csúcsúval. Kicsit romboid a függőségi fa, mert ezek közös célt szolgálnak, és közösen is dependálnak cuccokon. Önmagában a kbd alá is kétféle dolgot lehet berakni, a console-setup-ot meg a console-common-t. Vagy valami ilyesmi. Mindegy, az a lényeg, hogy míg a Lenny-ben a kbd volt a kevésbé ajánlott, a Squeeze-ben már a kbd az inkább ajánlott; például radeon KMS framebuffer alatt kizárólag a kbd + console-setup kombóval lehet fontot betölteni. (Keymap-ből n+1 éve ugyanazt a saját gyártmányt használom.) A console-terminus-ban nagyon király fontok vannak, 20x10 bold alatt esélytelen lennék a konzolon.

Egy ideig fontolgattam a

video=

paraméter használatát (kb. egy órát töltöttem vele, mire sikerült a kernel forrásban négyezer függvénymutatón keresztül eljutnom ahhoz a függvényhez, amelyik parse-olja), de annyira gáznak tűnt (1, 2), hogy a terminust választottam. (Amúgy is az ad jobb képet, ha a lehető legnagyobb felbontást választjuk, és a fontot is nagy felbontásban rendereltetjük. Kisebb felbontásnál dupla a veszteség: először is, a logikai pixelek torzan kerülnek a fizikai pixelekre, másodszor a font is sokkal durvábban formázott.)

(3.2) Az új X szerver (radeon-tól független) konfigjába egy elképesztő változás kúszott be. A billentyűzetem teljesen megzakkant. Nagy nehezen sikerült összevadásznom, hogy az

AllowEmptyInput / AutoAddDevices / AutoEnableDevices

opciókat kell hamisra állítva betuszkolnom a

ServerFlags

szakaszba.

(3.3) A dpkg-divert ritka jó. Nem is értem, hogy tudtam eddig meglenni nélküle. Eddig csak "izomból" symlinkeltem a bzip2/bunzip2/bzcat triumvirátust az lbzip2-re, és idegesített, hogy keresztbetettem a dpkg-nak. Na, a dpkg-divert-tel e hármast átirányítottam *.distrib névre, a symlink-ek pedig már nem ütköznek semmivel. Így nem is fáj annyira a kudarc, hogy az lbzip2 nem került bele az Alternatives rendszerbe.

(3.4) Dbus nálam természetesen nem fut rendszerszinten, ugyanakkor az Xsession elindította már Lenny alatt is, amikor beléptem az xdm-en keresztül. Kibírtam valahogy. Na, most megjelent egy újabb szutyok, a gvfsd. Sajnos leszedni nem lehetett, mert a Nautilus függ tőle. (Néha fut.) Mindenesetre a dpkg-divert-tel eltérítettem a gvfsd binárist, és a helyébe raktam egy shell script wrappert, amivel először megpróbáltam kíiratni az stderr-re (ergo terv szerint az ~/.xsession-errors-ba), hogy ki a parent processz: legalább azt lássam, ki indítja el. (A processzlistában ui. bejelentkezés után már csak 1-es PPID-del látszik.)

Na, azóta nem látom a gvfsd-t sehol :)

(3.5) Az inadyn-t, amit a DynDNS-hez szoktam használni, kivettem a /etc/rc.local-ból. Sajnos bugos, első indulásnál mindenképpen megpróbálja frissíteni a dyndns bejegyzését, akkor is, ha már a kurrens IP-re mutat az FQDN. (Nem ellenőrzi getaddrinfo()-val előtte.) Ezt a dyndns nem tolerálja (abuse), úgyhogy az inadyn használhatatlanná vált (persze ez nem a squeeze-en múlott).

Valaki azóta leforkolta az inadyn-t, valamelyik friss upstream verzióban már benne van a getaddrinfo(), megnéztem, de hát ki fog most ezzel vacakolni. DynDNS, csók. Ha kell, majd elindítom parancssorból az inadyn-t egyetlen iterációra.

(3.6) Örökzöld téma: debian-multimedia.org repó felvétele utolsó helyre. Itt egy script, ami megmutatja, mit installáltunk onnan:

dpkg --list \
| grep '^ii  ' \
| tr -s ' ' \
| cut -f 2 -d ' ' \
| xargs -r apt-cache showpkg -- \
| awk '
/^Package:.*$/ { package = $2 }
/\(\/var\/lib\/dpkg\/status\)/ { print package " " $2 }
' \
| grep debian-multimedia \
| cut -f 1 -d ' ' \
| sort

(3.7) Nagyon elégedett vagyok, hogy a wengophone-ból qutecom lett; bízom benne, hogy a debian-multimedia.org csomagjaival kombinálva a Lenny wengophone-nál megszokott vért pisálás (ffmpeg egyik anti verziójának kézi újrafordítása, hogy legyen rendes codec-támogatás...) a múlté.

(3.8) Hahh, asszony a totem-et szereti, nem az mplayer-t. Szolgálati közlemény: a totem lényegében használhatatlan a gstreamer0.10-ffmpeg csomag nélkül. (Valószínűleg benne volt a Recommended listában, de az avahi/mdns agysorvadás óta én mindig megadom a

--no-install-recommends

kapcsolót.) A totem hibaüzenete a hiányzó "DivX MPEG-4 Version 5 decoder"-ről természetesen annyit ért, mint halottnak a szenteltvíz, túrhattam a webet egy órán keresztül.

(3.9) Az

--auto-remove

kapcsolót és a purge parancsot együttesen ráeresztettem a dummy/transitional package-ekre (simán dpkg --list | grep kimenet alapján). Korrekt takarítást végzett. Ezután a

deborphan

bizonyult még hasznosnak. (Itt mondjuk arra kellett figyelnem, hogy a nice módot ne kapcsoljam ki, mert az levágta volna azokat a lib-eket is, amelyek csak Recommended függőségeket elégítenek ki. Mivel nálam csak akkor van fenn Recommended függőség, ha használom is, az

-n

kapcsolóval csak bajt okoztam volna.)

(3.10) Pirospont: ha egy csomagot

--purge

nélkül szedtünk le, és a konfig állományai fennmaradtak (= "rc" státusz), akkor ezeknek a letörléséhez elég a parancsot megismételni purge módban. Lenny alatt ez nem ment (a csomag már nem volt fenn), először újra fel kellett rakni a teljes csomagot, majd úgy purgálni.

(4) Összegzés: alapvetően a csomagkezelő és a disztribúció szempontjából az upgrade rendkívül simán zajlott, le a kalappal. A szabad X11 radeon driver 2D-re még jobb is, mint a Catalyst volt Lenny alatt; a hang nem változott; az ehci-hcd-t pedig időközben megfixálták. Azonban pusztán a két kiadás alapjául szolgáló upstream verziók között olyan böszme különbségek vannak, hogy a hajtépés elkerülhetetlen. Ezért is halogattam a frissítést, amíg tudtam. Ennyi idő alatt szerencsére a sok bug kijött más felhasználóknál, akik kellőképpen hangosan ordibáltak a neten.

Azt mondjuk nem értem, hogy a security.debian.org miért nincsen több országban, rendesen tükrözve. Olyan lassú, mint a reumás csiga. drpm-hez / yum Presto plugin-hoz hasonló növekményes frissítés ugye nincs, így nem kifejezetten kellemes 200KB/s sebességgel letölteni egy cirka száz megás openoffice biztonsági frissítést.

(5) Ennek a pontnak nincs köze a debianhoz, de leírom, mert érdekes. A dvdisaster programnak van egy szerényen meghúzódó kapcsolója; úgy hívják, hogy

--cache-size

. Az alapértelmezett értéke 32 MB.

Aki használja ezt a programot, biztosan észrevette már, hogy rengeteget seek-el, lényegében az egész gépet iowait-be taszítja. (Legalábbis nálam ez volt a helyzet RS02, augmented image módban.) Na, a cache méretet kéretik felpöccenteni legalább egy gigára, és máris csodálhatjuk a jelentősen felgyorsult, CPU-bound-dá vált processzünket. Szükségtelen mondani, hogy ennek hatására az egész gép megtáltosodik (nem a diszk a szűk keresztmetszet, illetve a

nice -n 19

-nek gyakorlati következménye van), illetve többmagos gépen több dvdisaster-t is futtathatunk egyszerre (természetesen külön image-eken).

A háttérben az áll, hogy a nagyobb cache méret nagyobb "stride" méretet eredményez. A "stride" az, amit a dvdisaster egyhuzamban, szekvenciálisan nyal be, mielőtt a következő "layer"-re seek-el az image file-ban. (A "layer" itt simán offszet-tartomány jelent.) Részletekért lásd az rs03.pdf-et (a 2.3-as ponttal bezárólag mindent megtudunk, ami most releváns), illetve a forrásban az

rs02-create.c

-ben a

create_reed_solomon()

függvényt.

Írtam az auktornak, hogy ugyan domborítsa már ki egy kicsit ennek a kapcsolónak a jelentőségét, de nincsenek nagy reményeim.