Fejlődök 2.6.26ra, de nem megy simán #4 KÉSZ

Előzetes tesztek alapján úgy nézett ki működik a dolog, 30 napot élt virtuális gépben, hogy biztosan ne legyen probléma.

Vettem ma egy szünetmentest APC BackUPS CS 500 VA-t, úgyhogy muszáj volt kernelt cserélni hogy beszélhessünk egymással (HID drivert nem forgattam az előzőbe), össze is kötöttem a 2 projektet, gondoltam áttérek 2.6.26ra.

A tesztek dacára élesben sikerült pofára esni.

Szerk: 12.07 16:10

A tesztek alapján a lirc problémát sikerült megoldani, úgyhogy egy grsec-lirc-layer7-oscon_patchek (acpi,logo,stb) alapján egy állatorvosi agyonpacsált lovat kreálni.

Be is bootolt, semmi gond nem is volt, egészen addig míg mencoder rel felvételt nem indítottam. Nos itt elhagyta a hangot, és levágta a billentyűzetet is.

Próbáltam -oac pcm el is, de ez volt a vég. Valamit nagyon sikerült elkúrni a V4L/ALSA körül (ez nem az én saram, mert ehhez speciel nemigen nyúltam hozzá, csak a lirc miatti def.-eket pakoltam vissza, a tunerkártya távirányítója műxik is.). Az snd-pcsp drivert kivágom, visszateszem a conservative cpufreq et. (2.6.25ös config alapján készült), aztán meglátjuk. Meg kap egy V4L autoselect et is a kodekekre, nem tudom ezt miért nem jegyezte meg 2.6.25ösből.

Tévézés nem fagyasztja meg, csak a felvétel. És nagyon úgyfest hangkezeléssel kapcsolatos a probléma.

Konkrét megoldási ötletem nincs, Egyelőre a fenti átkonfigurálással próbálkozok.

Szünetmentes viszont tök jó, azt mondja LOADPCT : 42.0 Percent Load Capacity, nem tudom mi a 100% 300 Watt, vagy 350, 130-145 között fogyaszthat most kernelfordítás közben a teljes rendszer.

Egy kis 2hangszórós minihifi, az ADSl modem, a monitor , és a kaszni lógnak rajta. A modem és a hifi egy PULSAR CL5-ös elosztón keresztül.

A pax vs LILO val kapcsolatos bootolási probléma, amivel KVM környezetben találkoztam éles rendszeren nem jelentkezett, úgyhogy nem kell áttérjek grubra szerencsére.

Az alap grub 14 színes, az kevés a boot háttérképemnek (debian-cafee), a grub2 meg meggárgyult tesztüzem során, nem találta meg a vinyót UUID alapján. Nagyon nem barátkoztam meg a grub bal finoman szólva. Nem sikerült megtalálni a közös hullámhosszt.

Szerk: nah, úgy néz ki conservative cpufreqre visszatérés, a snd-pcsp kidobása, egy kisrészben billentyűzetkezeléshez kapcsolódó BIOS hack megoldották a problémát. legfeljebb elkiabáltam.

Szerk 2.: most már biztos, hogy elkiabáltam suspend to ram visszatérésnél is jelentkezik probléma, az usb hiddel nem tud mit kezdeni. Visszatéréskor elpánikol az apcupsd/usbhid nél. Csinál zombit, mindent ahogy kell.Nem totál pánik, mert sikerült életre rugdosni a dó'gokat, de nem az igazi. Megpróbálom, hogy benthagyom az usb "keret"meghajtókat ehci-hcd, ohci-hcd,usbhid,usbcore, hátha rendesen működnek a bennük levő suspend() ill. resume() hívások.

A hanggal kapcsolatos probléma, úgy néz ki megoldódott.

Szerk 3. Újabb probléma.

Suspend to ram visszatérésnél:

kernel: BUG: unable to handle kernel paging request at ff846474
kernel: EIP: [<c086555a>] access_process_vm+0x12a/0x160 SS:ESP 0068:e2c27eec

Ha minden igaz, némi átkonfigurálással (powersave/V4l spéci saját gányolás/apcupsd) sikerült úrrá lenni a problémán.
Legalábbis most 3adjára sem reprodukálódott, bízom benne, hogy most már abbamarad a cirkusz.

A kernel bug következtében random kinyírt egy processzt a rendszer ettől függetlenül használható maradt. egyszer a cupsyst, egyszer a getty t, egyszer meg nemtommit. Kinyírtat úgy kell érteni, hogy ps aux -ra is azonnal dobott egy kern bug ot, ill. a problémás [code]proc/[pidszam]/cmdline -e olvasásra is.

Szerk4. Na végre. Újabb gond már nincs. Mission accomplished.

Hozzászólások

Bocs, de én csak azt nem értem igazából, hogy ha már ennyit dolgozol vele, akkor miért egy hónapokkal ezelőtti kernellel vacakolsz. Ha feltennéd a legutóbbi rc-t, még bugreportolni is volna értelme.

Amúgy nem bosszantani akarlak, de én hobbiból/unaloműzésképpen hetente frissítem a kernelemet mindig a legfrisseb rc-re, és az elmúlt 3 év alatt nem volt ennyi gondom vele összesen, mint amit itt leírtál. Igaz nem is használok lirc-et meg pax-ot. Lirc helyett tudom javasolni a vezeték nélküli egér használatát, pl. pyqt-ben összedobni hozzá egy saját magadra szabott kezelőfelületet tv-tuner + mplayer-hez, többet nem lesz vele gondod.

Sajnos a tunerkártyához kell a lirc_gpio anélkül nemmegy a távirányító. A kernelben levő evdev alapú bttv_ir nem kezeli. Az input eszközök között megvan, azonban semmire nem reagál.

Ezeket a problémákat nem a pax okozza, hanem sajnos még az ún. "vanilla" kernel, és azért 2.6.26 mert a debian visszaportolta a javításokat bele, tehát 2.6.26+ bőven.

Persze a saját gányolásaim is megvannak, mint pl. az alarm fájl visszaállítása az

proc-acpi

ban.

Arra meg nincs energiám, hogy már megoldott bugokra keresgessem elő a patcheket, bőven elég amit én pluszban megtalálok, de már van újabb is.

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

r=1 vagyok, de ugatok...

Igazából a windows sal is az az (egyik) nagy probléma - a gyenge suspend to ram kezelés mellett - , hogy távirányítóhoz abszolút semmi sincs, csak ott lirc féle móka sem.

Ha nagyon nem marad más megoldás, akkor tekintve hogy windowsban van DEP, linuxban meg úgy nagyjából alapból semmi, bizony megfontolandó a visszatérés, mert akkor már nagyon necces, hogy melyikre egyszerűbb működő rendszer használni.

----------

r=1 vagyok, de ugatok...

A 2.6.26ban van a nagyon hülye SIGWINCH bug, ami az agyadra fog menni ha sokat használsz terminált :)
Indíts el egy tetszőleges ncurses alapő programot, majd kezd el átméretezni a terminált.