squeeze 2.6.39 kernel + radeon probléma

Debian GNU/Linux

Sziasztok!

Az ASRock E350M1/USB3 gépemen (AMD E-350 APU) van egy console only squeeze (2.6.32-5-amd64 kernel).
Ezt frissítettem 2.6.39-bpo.2-amd64 kernelre backports-ból, de ezzel a kernellel boot után nem jelent meg a login, csak nagy felbontású random pixelek jelentek meg. A boot rendesen megjelent egy darabig, csak aztán videomódot váltott, és ez jelent meg:

Ezt leszámítva működik a rendszer, minden elindul, ssh-n be lehet lépni.

Egy másik fórumon kapott segítség alapján letiltottam az új kernelhez melléket radeon modult, és így rendesen be is tudok lépni, de pl. a sensors már nem látja a GPU hőmérsékletét (arról nem is beszélve, hogy ha esetleg el akarnék indítani egy GUI-t...)

Van ötletetek, hogy hogyan kéne konfigurálni a modult / megadni a megfelelő boot paramétereket? (még olyan tippet kaptam, hogy a max framebuffer-t kéne talán beállítani, de ezt nem tudom, hol lehetne megtenni...)

Köszi a segítséget előre is. :)

  • 2056 megtekintés

( borbi v | 2011. 08. 24., sze – 18:33 )

/etc/modprobe.d/radeon-kms.conf

"options radeon modeset=0"

?

( Oscon | 2011. 08. 25., cs – 10:26 )

a max framebuffer-t kéne talán beállítani

Van valami elkerülhetetlen oka a kernelfrissítésnek ? A 2.6.32 hosszú karbantartású, jó eséllyel stabilabb,
kevésbé problematikusabb mint a 2.6.39 amit hamar úgyis lecserélnek a bpo tárolóban ?.
És kezdődik az egész cirkusz előről ...Új driver, új nyavalyákkal ...

hogy ha esetleg el akarnék indítani egy GUI-t

Az szép halálnak néz ki, 2.6.39es radeon dri egy squeeze féle "régi" xorg driverrel. Szeretsz lottózni ? :-)

hogy a max framebuffer-t kéne talán beállítani

A boot paraméternél kell megadni. Attól függően, hogy milyen framebuffer drivert használsz.

OFF:

Ha tényleg a KMS okozza nálad a gondot, akkor nem biztos, hogy a framebuffer állítás szerencsét/eredményt hoz.
Nekem ugyan intel KMS-el és integrált / X3100 / csodaintel
lassítóval / (C)opyright Pontscho /, de kiábrándító volt a tapasztalatom.
(ha be volt kapcsolva, X indulásakor kicsapta a dri-t,
és villogó függőleges csíkosba váltotta a vt-ket vesafb-vel és intelfb-vel is.
Úgyhogy repült a KMS ahogy volt. Anélkül meg voila, gond egy szál se. Még dri is volt,
már amennyire a 3d lassító képességei engedték.

OFF 2:

Ha nincs GUI, akkor szvsz nincs sok értelme a radeon GPU hőmérséklet sasolásnak. ;-) Nem valószínű, hogy tartósan megizzad. :-)
Sőt, ha nincs GUI, akkor minek a radeon driver egyáltalán ?
Nyomj be egy vesafb-t a kernelbe, boot paraméternek add meg a vga=xxx -el a felbontást, oszt kész.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.

Van valami elkerülhetetlen oka a kernelfrissítésnek ? A 2.6.32 hosszú karbantartású, jó eséllyel stabilabb,
kevésbé problematikusabb mint a 2.6.39 amit hamar úgyis lecserélnek a bpo tárolóban ?.
És kezdődik az egész cirkusz előről ...Új driver, új nyavalyákkal ...
Egyáltalán nem ment a sensors a régivel, 2.6.39-be került be elsőként a chip támogatása. :)

Ha nincs GUI, akkor szvsz nincs sok értelme a radeon GPU hőmérséklet sasolásnak. ;-) Nem valószínű, hogy tartósan megizzad. :-)
Sőt, ha nincs GUI, akkor minek a radeon driver egyáltalán ?
Nyomj be egy vesafb-t a kernelbe, boot paraméternek add meg a vga=xxx -el a felbontást, oszt kész.
A CPU mag hőmérséklet húzza magával a GPU-t is, de fordítottat még értelemszerűen nem teszteltem (bár valószínüleg abba az irányba is meglesz a korreláció)
Ameddig nincs GUI addig mindegy, ha meg lesz, akkor úgy tűnk kénytelen leszek rendes drivert feltenni a KMS helyett

OFF:
Csak akkor miért létezik egyáltalán a KMS driver?

Lehet, hogy egyszerűbb lenne backportolni azt az egy szem thermal_drivert a 2.6.32-be... (?)

Mint egyetlen apró driverért állandóan kernelt frissíteni. Amúgy val'szeg driver bug, lehet hogy 3.0.xban már javították.

Csak akkor miért létezik egyáltalán a KMS driver?

Miért ne ? ;-) Inkább legyen eggyel több, mint egy sem.

--------

Nem vezetek...Jobb így. Nekem is
meg mindenki másnak is.