Ben Finney wrote:
> * the default text mode left by the boot loader
> (“initial Linux console”)
>
> * a mode switch to provide a high-resolution text console
> (“framebuffer text console”)
Ah --- so after modeswitching, the console is unusable ("no signal").
Is your display a flat panel/LCD? Not being able to debug in text
mode is a shame, but ok.
Actually, I wonder why the framebuffer console kicked in at all.
Isn't this card unrecognized by the radeon driver in 2.6.37? Does
"lsmod" show the radeon driver having been loaded, and does the
mode switch still happen if you do not start X?
> * a switch to a graphics console, on VC7, to present GDM 3
> (“graphics console”)
This is the term that confused me, since the framebuffer console is
drawn as a bitmap, making it graphical in a way. I'm no expert, so my
usual term for the thing you get when the X server is started is "X".
If you boot in recovery mode and start X manually with "xinit" (which
makes the graphics involved a little similar), do you still get snow?
Does /var/log/Xorg.0.log say anything interesting? Does using the
fbdev driver by putting the following in /etc/X11/xorg.conf:
Section "Device"
Identifier "videocard"
Driver "fbdev"
EndSection
or using the vesa driver by putting
# do not load radeon kernel driver
blacklist radeon
in a .conf file in /etc/modprobe.d and
Section "Device"
Identifier "videocard"
Driver "vesa"
EndSection
in xorg.conf produce different results?
2.6.38 added support for AMD Ontario APUs so it is hard to pin down
what particular code path has the problem. I am guessing the first
bad commit is v2.6.38-rc1~419^2~40^2~1 (drm/radeon/kms: add Ontario
Fusion APU pci ids, 2010-11-22).
Thanks and hope that helps,
Jonathan
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120315211431.GA30274@burratino
