Bug#524280: Display broken beyond recognition after upgrade to 1:6.12.2-1

[Jacek Politowski]

On Sat, Apr 18, 2009 at 12:34:06PM +0200, Michel Dänzer wrote:
>On Sat, 2009-04-18 at 12:13 +0200, Jacek Politowski wrote:
>> On Sat, Apr 18, 2009 at 11:40:37AM +0200, Michel Dänzer wrote:

>What else changed between the working and broken setups?
>xserver-xorg-core presumably, but maybe also the kernel? Are you using
>radeonfb for console?

>When you tested Option "DRI" "off", did you verify in the log file that
>direct rendering was indeed disabled?

Example ("DRI" "off", "NoAccel" "true"):
$ grep -i dri /var/log/Xorg.0.log
	X.Org Video Driver: 5.0
	X.Org XInput driver : 4.0
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
(II) Loading extension XFree86-DRI
(II) LoadModule: "dri2"
(II) Loading /usr/lib/xorg/modules/extensions//libdri2.so
(II) Module dri2: vendor="X.Org Foundation"
(II) Loading extension DRI2
(II) Scanning /usr/share/xserver-xorg/pci directory for additional PCI ID's supported by the drivers
(==) Matched radeon for the autoconfigured driver
(==) Assigned the driver to the xf86ConfigLayout
(II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so
	Module class: X.Org Video Driver
	ABI class: X.Org Video Driver, version 5.0
(II) RADEON: Driver for ATI Radeon chipsets:
(**) RADEON(0): Option "DRI" "off"
	ABI class: X.Org Video Driver, version 5.0
	ABI class: X.Org Video Driver, version 5.0
	ABI class: X.Org Video Driver, version 5.0
(II) AIGLX: Screen 0 is not DRI2 capable
(II) AIGLX: Screen 0 is not DRI capable
(II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0
	Module class: X.Org XInput Driver
	ABI class: X.Org XInput driver, version 4.0



I don't use radeonfb (or any other framebuffer) for console. Actually
I don't use console at all (at least in normal conditions) since my
Radeon X800 sends all output to D-Sub, until xserver driver senses that
only DVI port has anything connected to it and switch display to DVI
output.
So, until GDM login screen, my display stays asleep and I don't see
anything. This is supposed to be a known by ATI/AMD problem, and there
is no updated BIOS by my card manufacturer (Sapphire) to fix this issue.



I checked, and it seems I haven't rebooted (and probably also
restarted xserver) for quite some time... Previous reboot was on 27th
March. Since then, quite a lot happened.


Selected fragments from aptitude.log:

[UPGRADE] firmware-linux 0.15 -> 0.16

[UPGRADE] xorg 1:7.3+18 -> 1:7.4+1
[UPGRADE] xserver-xephyr 2:1.4.2-11 -> 2:1.6.0-1
[UPGRADE] xserver-xorg 1:7.3+18 -> 1:7.4+1
[UPGRADE] xserver-xorg-core 2:1.4.2-11 -> 2:1.6.0-1
[UPGRADE] xserver-xorg-input-evdev 1:2.0.8-1 -> 1:2.2.1-1
[UPGRADE] xserver-xorg-input-kbd 1:1.3.1-1 -> 1:1.3.2-3
[UPGRADE] xserver-xorg-input-mouse 1:1.3.0-1 -> 1:1.4.0-2
[UPGRADE] xserver-xorg-video-ati 1:6.9.0-1+lenny4 -> 1:6.12.2-1
[UPGRADE] xserver-xorg-video-chips 1:1.2.0-1 -> 1:1.2.1-2
[UPGRADE] xserver-xorg-video-cirrus 1:1.2.1-1.lenny1 -> 1:1.2.1-4
[UPGRADE] xserver-xorg-video-i128 1:1.3.0-1 -> 1:1.3.1-3
[UPGRADE] xserver-xorg-video-intel 2:2.3.2-2+lenny6 -> 2:2.6.3-1
[UPGRADE] xserver-xorg-video-mach64 6.8.0-1 -> 6.8.0+git20090201.d394e0b8-2
[UPGRADE] xserver-xorg-video-neomagic 1:1.2.1-1 -> 1:1.2.2-2
[UPGRADE] xserver-xorg-video-r128 6.8.0-1 -> 6.8.0+git20090201.08d56c88-2
[UPGRADE] xserver-xorg-video-radeon 1:6.9.0-1+lenny4 -> 1:6.12.2-1
[UPGRADE] xserver-xorg-video-s3 1:0.6.0-1 -> 1:0.6.1-2
[UPGRADE] xserver-xorg-video-siliconmotion 1:1.6.0-1 -> 1:1.7.0-2
[UPGRADE] xserver-xorg-video-sisusb 1:0.9.0-1 -> 1:0.9.1-1
[UPGRADE] xserver-xorg-video-tseng 1:1.2.0-1 -> 1:1.2.1-1
[UPGRADE] xserver-xorg-video-vmware 1:10.16.2-1 -> 1:10.16.5-3
[UPGRADE] xserver-xorg-video-voodoo 1:1.2.0-1 -> 1:1.2.1-1

[INSTALL, DEPENDENCIES] linux-image-2.6.26-2-686
(uname still shows 2.6.26-1 - LILO probably hasn't been invoked after)

[UPGRADE] xnest 2:1.6.0-1 -> 2:1.6.1-1
[UPGRADE] xserver-common 2:1.6.0-1 -> 2:1.6.1-1
[UPGRADE] xserver-xephyr 2:1.6.0-1 -> 2:1.6.1-1
[UPGRADE] xserver-xorg-core 2:1.6.0-1 -> 2:1.6.1-1

[UPGRADE] xnest 2:1.6.0-1 -> 2:1.6.1-1
[UPGRADE] xserver-common 2:1.6.0-1 -> 2:1.6.1-1
[UPGRADE] xserver-xephyr 2:1.6.0-1 -> 2:1.6.1-1
[UPGRADE] xserver-xorg-core 2:1.6.0-1 -> 2:1.6.1-1
(during this upgrade machine froze (described in initial bugreport),
I don't know though whether it was during processing of some X related
packages or other ones in this upgrade batch)

[UPGRADE] xnest 2:1.6.0-1 -> 2:1.6.1-1
[UPGRADE] xserver-common 2:1.6.0-1 -> 2:1.6.1-1
[UPGRADE] xserver-xephyr 2:1.6.0-1 -> 2:1.6.1-1
[UPGRADE] xserver-xorg-core 2:1.6.0-1 -> 2:1.6.1-1
(this is repeated attempt (successful) of upgrade previously
interrupted (had to do a hard reset, and 'dpkg-configure -a' before
aptitude run). It was performed right after freeze/reboot - from
remote machin via SSH, as display was already corrupted)


After realizing now, that I'm still running older kernel, I ran 'lilo'
and rebooted to new kernel, which of course didn't change anything.


As snapshot.debian.net seems inactive, only possible solution seems to
be to downgrade all X stuff to testing distribution state.
And it seems my last working setup was similar (or even exact) to
what's left in testing, so this should help.

Unfortuntately this leaves a lot of space where bug could emerge, but
if it doesn't help either, we'll know that problem probably is located
elsewhere.


-- 
Jacek Politowski