Bug#901497: Hard system hangs after upgrade from 18.0.5-1 to 18.1.1-1

2018-06-14 Thread Jacek Politowski 
Package: libgl1-mesa-dri
Version: 18.1.1-1
Followup-For: Bug #901497

Dear Maintainer,

I've also encountered hard video/mouse hangs after upgrade of mesa to 18.1.1-1.

It seems 100% reproducible with Firefox (Debian package 60.0.2-1), for example
on https://racetime.io/.

Disabling hardware acceleration in Firefox doesn't change anything.

Chromium seems unaffected (webpages that hang my video/mouse/keyboard in
Firefox work flawlessly in Chromium).


To test this situation I've downgraded following packages:
libegl-mesa0:amd64 18.1.1-1 -> 18.0.5-1
libegl1-mesa:amd64 18.1.1-1 -> 18.0.5-1
libgbm1:amd64 18.1.1-1 -> 18.0.5-1
libgl1-mesa-dri:amd64 18.1.1-1 -> 18.0.5-1
libgl1-mesa-glx:amd64 18.1.1-1 -> 18.0.5-1
libglapi-mesa:amd64 18.1.1-1 -> 18.0.5-1
libgles2-mesa:amd64 18.1.1-1 -> 18.0.5-1
libglx-mesa0:amd64 18.1.1-1 -> 18.0.5-1
libosmesa6:amd64 18.1.1-1 -> 18.0.5-1
librdmacm1:amd64 18.1-1 -> 18.0-1
libibverbs1:amd64 18.1-1 -> 18.0-1
libwayland-egl1-mesa:amd64 18.1.1-1 -> 18.0.5-1
mesa-va-drivers:amd64 18.1.1-1 -> 18.0.5-1
mesa-vdpau-drivers:amd64 18.1.1-1 -> 18.0.5-1

Downgrade seems to have solved the issue.


To test it further, I've upgraded some of them back:
[UPGRADE] libegl-mesa0:amd64 18.0.5-1 -> 18.1.1-1
[UPGRADE] libegl1-mesa:amd64 18.0.5-1 -> 18.1.1-1
[UPGRADE] libgbm1:amd64 18.0.5-1 -> 18.1.1-1
[UPGRADE] libgl1-mesa-dri:amd64 18.0.5-1 -> 18.1.1-1
[UPGRADE] libgl1-mesa-glx:amd64 18.0.5-1 -> 18.1.1-1
[UPGRADE] libgles2-mesa:amd64 18.0.5-1 -> 18.1.1-1
[UPGRADE] libibverbs1:amd64 18.0-1 -> 18.1-1
[UPGRADE] librdmacm1:amd64 18.0-1 -> 18.1-1
[UPGRADE] libwayland-egl1-mesa:amd64 18.0.5-1 -> 18.1.1-1
[UPGRADE] mesa-va-drivers:amd64 18.0.5-1 -> 18.1.1-1
[UPGRADE] mesa-vdpau-drivers:amd64 18.0.5-1 -> 18.1.1-1

keeping only few of them downgraded (lucky guess):
[HOLD] libglapi-mesa:amd64 18.0.5-1
[HOLD] libglx-mesa0:amd64 18.0.5-1
[HOLD] libosmesa6:amd64 18.0.5-1


This configuration seems stable for me (of course also after reboot). I can now
visit any web page with Firefox with no need to login remotely via SSH (or use
SysRq) to reboot hanged system.


-- Package-specific info:
glxinfo:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_context_flush_control, GLX_ARB_create_context, 
GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_no_config_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGIS_multisample, 
GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
GLX_SGI_make_current_read
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_context_flush_control, GLX_ARB_create_context, 
GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_buffer_age, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_video_sync
Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD RV770 (DRM 2.50.0 / 4.14.0-3-amd64, LLVM 6.0.0) (0x9442)
Version: 18.1.1
Accelerated: yes
Video memory: 1024MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 3.3

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

2009-05-14 Thread Jacek Politowski 
On Thu, May 14, 2009 at 09:47:26AM +0200, Michel Dänzer wrote:
On Wed, 2009-05-13 at 13:13 +0200, Jacek Politowski wrote:

 I started git bisect between revisions
 a6561f2ec673b38907f7181235386f32e60c32ba and
 da021c36bbdf3bca31ee50ebe01cdb9495c09b36
 (...) (the same error for every tested build).

I think commit da021c36bbdf3bca31ee50ebe01cdb9495c09b36 fixed this,
so
something like

git show da021c36bbdf3bca31ee50ebe01cdb9495c09b36 | patch -p1

Ok, I've applied this patch and continued git bisect session.

Driver builds correctly, so I was able to finish the search.

Result follows:
$ git bisect visualize
commit b01e35168de40d192fd7a9ce6884b9c7419afbd4
Author: Alex Deucher alexdeuc...@gmail.com
Date:   Mon Nov 24 21:06:42 2008 -0500

Fix up posted logic

noticed by benh on IRC


This is the first revision that shows symptoms from my initial
bug report.


-- 
Jacek Politowski



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

2009-05-14 Thread Jacek Politowski 
On Thu, May 14, 2009 at 02:49:56PM -0400, Alex Deucher wrote:

 $ git bisect visualize
 commit b01e35168de40d192fd7a9ce6884b9c7419afbd4
(...)
 This is the first revision that shows symptoms from my initial
 bug report.

Does this patch (against master) fix it?

I'm writing this under Gnome, on system that has

(II) Module radeon: vendor=X.Org Foundation
compiled for 1.6.1, module version = 6.12.2

in Xorg.0.log :-)

Your patch applied against current master seems to have fixed the
issue.


Thanks everyone for great support!

-- 
Jacek Politowski



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

2009-05-13 Thread Jacek Politowski 
On Wed, May 13, 2009 at 08:25:08AM +0200, Michel Dänzer wrote:
On Wed, 2009-05-13 at 02:09 +0200, Jacek Politowski wrote:

 Going upwards, from working to buggy revision, I treated FTBFS
 (failing to build from source) commits as bad for git bisect. Going
 from buggy revision downwards - to working one - I treated FTBFS
 commits as good for git bisect.

It's better not to mark such commits as good or bad at all. Either use
git bisect skip or switch to a nearby commit that can be used to verify
the problem being bisected manually.

Maybe it's better, but with git bisect skip I'd still be in testing
session - I tried that. I also tried skipping more (N - for N={1..4})
revisions with git reset --hard HEAD~N, but it was also pointless
then.

Judging from compilation errors, I made an assumption that it was
always the same error causing compilation failure for me. Now I have
narrowed down the list of possible commits to 46 and can start with
narrower boundaries - manageable even with git bisect skip (to
proove/contradict that all the commits in between are failing to
build).

And I'll try that on next possible occasion - possibly even today.


-- 
Jacek Politowski



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

2009-05-13 Thread Jacek Politowski 
On Wed, May 13, 2009 at 10:34:39AM +0200, Michel Dänzer wrote:

The point is that if you say git bisect good/bad for a commit where you
couldn't verify the problem you're bisecting, the result of the bisect
run may be incorrect.

I know that. But even when such assumption leads to incorrect results,
I can always do a replay changing guessed good/bad answer. This will
lead ultimately to close enough result, just like it did in my
example.


Also note that if you know the fix for a build problem and you're
confident it doesn't affect the problem you're bisecting, it's
legitimate to manually apply the build fix.

I also know that.

However I'm just a regular user. Don't expect me to be able to fix
compilation error of xorg video driver... Especially to fix it in a
way that I'm confident won't break anything else.


I started git bisect between revisions
a6561f2ec673b38907f7181235386f32e60c32ba and
da021c36bbdf3bca31ee50ebe01cdb9495c09b36, but I really don't think
it's getting anywhere. I've attached an exemplary log of 'make'
invocation (the same error for every tested build).

Being able to fix this build problem, I'd be able to do further git
bisect on driver repository.


-- 
Jacek Politowski
Script started on śro, 13 maj 2009, 12:49:12
j...@unstable-builder:~/workspace/radeon/upstream/gitrepo/xf86-video-ati$ make
make  all-recursive
make[1]: Wejście do katalogu 
`/home/jpol/workspace/radeon/upstream/gitrepo/xf86-video-ati'
Making all in src
make[2]: Wejście do katalogu 
`/home/jpol/workspace/radeon/upstream/gitrepo/xf86-video-ati/src'
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. 
-I./AtomBios/includes  -Wall -I/usr/include/xorg -I/usr/include/pixman-1 
-I/usr/include/drm -I/usr/include/X11/dri-DDISABLE_EASF 
-DENABLE_ALL_SERVICE_FUNCTIONS -DATOM_BIOS -DATOM_BIOS_PARSER -DDRIVER_PARSER 
-g -O2 -MT radeon_accel.lo -MD -MP -MF .deps/radeon_accel.Tpo -c -o 
radeon_accel.lo radeon_accel.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I./AtomBios/includes -Wall 
-I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/drm 
-I/usr/include/X11/dri -DDISABLE_EASF -DENABLE_ALL_SERVICE_FUNCTIONS 
-DATOM_BIOS -DATOM_BIOS_PARSER -DDRIVER_PARSER -g -O2 -MT radeon_accel.lo -MD 
-MP -MF .deps/radeon_accel.Tpo -c radeon_accel.c  -fPIC -DPIC -o 
.libs/radeon_accel.o
In file included from radeon_accel.c:86:
radeon_drm.h:584: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before 
‘*’ token
radeon_drm.h:610: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before 
‘*’ token
radeon_drm.h:627: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before 
‘*’ token
radeon_drm.h:635: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before 
‘*’ token
radeon_drm.h:644: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before 
‘*’ token
radeon_drm.h:648: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before 
‘*’ token
radeon_drm.h:689: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before 
‘*’ token
radeon_drm.h:701: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before 
‘*’ token
radeon_drm.h:718: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before 
‘*’ token
radeon_accel.c: In function ‘RADEONEngineInit’:
radeon_accel.c:379: error: ‘drm_radeon_getparam_t’ has no member named ‘value’
make[2]: *** [radeon_accel.lo] Błąd 1
make[2]: Opuszczenie katalogu 
`/home/jpol/workspace/radeon/upstream/gitrepo/xf86-video-ati/src'
make[1]: *** [all-recursive] Błąd 1
make[1]: Opuszczenie katalogu 
`/home/jpol/workspace/radeon/upstream/gitrepo/xf86-video-ati'
make: *** [all] Błąd 2
j...@unstable-builder:~/workspace/radeon/upstream/gitrepo/xf86-video-ati$ exit

Script done on śro, 13 maj 2009, 12:49:16
# bad: [da021c36bbdf3bca31ee50ebe01cdb9495c09b36] radeon_drm.h: remove kernel 
defines
# good: [a6561f2ec673b38907f7181235386f32e60c32ba] Move DRI to a separate struct
git bisect start 'da021c36bbdf3bca31ee50ebe01cdb9495c09b36' 
'a6561f2ec673b38907f7181235386f32e60c32ba'
# skip: [4a9e8d9fe24278b56aef51677fd35289d01584a7] set grey levels correctly 
for temporal dithering
git bisect skip 4a9e8d9fe24278b56aef51677fd35289d01584a7
# skip: [dc795ba66a8c0eb2c3fdb86bd42dfc17e0aa3b6e] Fixups from last DFP/LCD 
refactor
git bisect skip dc795ba66a8c0eb2c3fdb86bd42dfc17e0aa3b6e
# skip: [5708624d1151877dd66a462d4a75fed6774604a7] Turn coherent mode off by 
default on DVI
git bisect skip 5708624d1151877dd66a462d4a75fed6774604a7
# skip: [d744dc013cf5ca3141c0fdf55e36d713fe9f53ba] Fix connector table mapping 
for lvtma/kaleidoscope/uniphy.
git bisect skip d744dc013cf5ca3141c0fdf55e36d713fe9f53ba

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

2009-05-12 Thread Jacek Politowski 
On Tue, Apr 21, 2009 at 11:09:41AM -0400, Alex Deucher wrote:

Any chance you could try 6.10.0 from the tarballs above and then use
git bisect to track down what commit broke this?
It's easy to do and would be a big help.  I can walk you through if need be.

Finally I was able to do some testing with git bisect.

What I managed to find out:

Last working commit is: 
a6561f2ec673b38907f7181235386f32e60c32ba

First commit with corrupted display:
da021c36bbdf3bca31ee50ebe01cdb9495c09b36


I believe all 46 commits between them fail to build from source on my
VirtualBox builder.


All done with simple procedure:
$ git bisect start 'a0dd5d7ee3f038a9bfe051db8dbfac4934a81581' 
'c83fbdfa076c107012b7dfbbfbbb2feede00542b'
$ ./autogen.sh --prefix=/usr
$ make
## copy .libs/*so to proper locations on my system with Radeon card
## (except for ati_drv.so - this one was left unchanged all the time)
$ sudo reboot
$ git bisect good/bad
$ ./autogen.sh --prefix=/usr
$ make
... and so on (without any 'make clean' or anything else)


Going upwards, from working to buggy revision, I treated FTBFS
(failing to build from source) commits as bad for git bisect. Going
from buggy revision downwards - to working one - I treated FTBFS
commits as good for git bisect.


I believe the same error was causing build failures all the time (and
it's also quite late here already), so I haven't checked all the
revisions between working and buggy commit - only those few, that
binary search of git bisect stumbled upon.

If necessary, I can try building revisions between
a6561f2ec673b38907f7181235386f32e60c32ba and
da021c36bbdf3bca31ee50ebe01cdb9495c09b36 on next possible occasion.


-- 
Jacek Politowski



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

2009-04-23 Thread Jacek Politowski 
On Tue, Apr 21, 2009 at 11:09:41AM -0400, Alex Deucher wrote:
2009/4/19 Jacek Politowski j...@jp.pl.eu.org:

 Basically only version 6.9.0 works (both - in X from testing and from
 unstable). Unfortunately I don't have access to source package of 6.10
 version of radeon driver.

You can grab source packages from cgit:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/

Sources, I believe, not source packages ;-


Any chance you could try 6.10.0 from the tarballs above and then use
git bisect to track down what commit broke this?
It's easy to do and would be a big help.  I can walk you through if need be.

I should be able to do this sort of testing during weekend.

As I'm not very accustomed to building stuff from pristine sources,
I'll try to build 6.9.0 first - to verify it works like the version
from Debian packages, proving also my building process is correct.

Judging from Debian package 'xserver-xorg-video-radeon' contents, I'll
need 'radeon_drv.so', 'theatre_detect_drv.so', 'theatre_drv.so' and
'theatre200_drv.so'. Just compile it (in the same virtualized
environment, as Debian packages mentioned in my previous tests) and
copy these files to appriopriate location on my system?


-- 
Jacek Politowski



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

2009-04-20 Thread Jacek Politowski 
On Sun, Apr 19, 2009 at 09:55:46PM +0200, Jacek Politowski wrote:
On Sun, Apr 19, 2009 at 12:46:47PM +0200, Michel Dänzer wrote:
On Sun, 2009-04-19 at 08:55 +0200, Jacek Politowski wrote:

 I'll try to upgrade again to current unstable version and try packages
 I've built earlier (6.9.0, 6.11.0) - this time remembering always to
 reboot after installation.

Sounds like a good plan; (...)

(...and I tested:)
1) 6.12.2
2) 6.9.0
3) 6.11.0
4) 6.10.99.0
5) 6.9.0
6) 6.12.2
7) 6.9.0
8) 6.9.0
9) 6.11.0
10) 6.10.99.0


I realized that, during these checks with reboot, I forgot to check
also 6.12.2 with your patch applied.

Unfortunately it still doesn't work. Updated logs are posted to the
same location as before: 
http://mongoose.rallypl.eu.org/tmp/radeonlogs.tar.gz


-- 
Jacek Politowski



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

2009-04-19 Thread Jacek Politowski 
On Sat, Apr 18, 2009 at 04:19:19PM +0200, Jacek Politowski wrote:

 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.

Ok, I've downgraded all/most of X stuff to Squeeze state.

Curiously, didn't help at first, when I started GDM after upgrade. But
after reboot (/sbin/reboot) everything works fine again, with
effectively my original configuration (effectively, because
previously I didn't have DRI, NoAccel and R4xxATOM entries, now I have
them commented out).

Section InputDevice
Identifier  Generic Keyboard
Driver  kbd
Option  XkbRules  xorg
Option  XkbModel  pc104
Option  XkbLayout pl
EndSection

Section InputDevice
Identifier  Configured Mouse
Driver  mouse
EndSection

Section Device
Identifier  Configured Video Device
Option  AccelMethod   EXA
Option  AccelDFS  on
Option  DisplayPriority   HIGH
#   Option  DRI   off
#   Option  NoAccel   true
#   Option  R4xxATOM  true
EndSection

Section Monitor
Identifier  Configured Monitor
EndSection

Section Screen
Identifier  Default Screen
Monitor Configured Monitor
EndSection


Full aptitude log from downgrade operation:
[REMOVE, NOT USED] console-setup
[REMOVE, NOT USED] console-terminus
[REMOVE, NOT USED] libpciaccess0
[REMOVE, NOT USED] libvolume-id0
[HOLD, DEPENDENCIES] apt
[HOLD, DEPENDENCIES] apt-utils
[HOLD, DEPENDENCIES] capplets-data
[HOLD, DEPENDENCIES] gnome-accessibility
[HOLD, DEPENDENCIES] gnome-core
[HOLD, DEPENDENCIES] libept0
[HOLD, DEPENDENCIES] synaptic
[INSTALL, DEPENDENCIES] xserver-xorg-input-all
[INSTALL, DEPENDENCIES] xserver-xorg-input-synaptics
[INSTALL, DEPENDENCIES] xserver-xorg-input-wacom
[INSTALL, DEPENDENCIES] xserver-xorg-video-all
[INSTALL, DEPENDENCIES] xserver-xorg-video-apm
[INSTALL, DEPENDENCIES] xserver-xorg-video-ark
[INSTALL, DEPENDENCIES] xserver-xorg-video-ati
[INSTALL, DEPENDENCIES] xserver-xorg-video-cyrix
[INSTALL, DEPENDENCIES] xserver-xorg-video-dummy
[INSTALL, DEPENDENCIES] xserver-xorg-video-fbdev
[INSTALL, DEPENDENCIES] xserver-xorg-video-glint
[INSTALL, DEPENDENCIES] xserver-xorg-video-i740
[INSTALL, DEPENDENCIES] xserver-xorg-video-imstt
[INSTALL, DEPENDENCIES] xserver-xorg-video-mga
[INSTALL, DEPENDENCIES] xserver-xorg-video-nsc
[INSTALL, DEPENDENCIES] xserver-xorg-video-nv
[INSTALL, DEPENDENCIES] xserver-xorg-video-openchrome
[INSTALL, DEPENDENCIES] xserver-xorg-video-radeonhd
[INSTALL, DEPENDENCIES] xserver-xorg-video-rendition
[INSTALL, DEPENDENCIES] xserver-xorg-video-s3virge
[INSTALL, DEPENDENCIES] xserver-xorg-video-savage
[INSTALL, DEPENDENCIES] xserver-xorg-video-sis
[INSTALL, DEPENDENCIES] xserver-xorg-video-tdfx
[INSTALL, DEPENDENCIES] xserver-xorg-video-tga
[INSTALL, DEPENDENCIES] xserver-xorg-video-trident
[INSTALL, DEPENDENCIES] xserver-xorg-video-v4l
[INSTALL, DEPENDENCIES] xserver-xorg-video-vesa
[INSTALL, DEPENDENCIES] xserver-xorg-video-vga
[REMOVE, DEPENDENCIES] xserver-common
[DOWNGRADE] x11-common 1:7.4+1 - 1:7.3+18
[DOWNGRADE] xnest 2:1.6.1-1 - 2:1.4.2-11
[DOWNGRADE] xserver-xephyr 2:1.6.1-1 - 2:1.4.2-11
[DOWNGRADE] xserver-xorg 1:7.4+1 - 1:7.3+18
[DOWNGRADE] xserver-xorg-core 2:1.6.1-1 - 2:1.4.2-11
[DOWNGRADE] xserver-xorg-input-evdev 1:2.2.1-1 - 1:2.0.8-1
[DOWNGRADE] xserver-xorg-input-kbd 1:1.3.2-3 - 1:1.3.1-1
[DOWNGRADE] xserver-xorg-input-mouse 1:1.4.0-2 - 1:1.3.0-1
[DOWNGRADE] xserver-xorg-video-chips 1:1.2.1-2 - 1:1.2.0-1
[DOWNGRADE] xserver-xorg-video-cirrus 1:1.2.1-4 - 1:1.2.1-1.lenny1
[DOWNGRADE] xserver-xorg-video-i128 1:1.3.1-3 - 1:1.3.0-1
[DOWNGRADE] xserver-xorg-video-intel 2:2.7.0-1 - 2:2.3.2-2+lenny6
[DOWNGRADE] xserver-xorg-video-mach64 6.8.0+git20090201.d394e0b8-2 - 6.8.0-1
[DOWNGRADE] xserver-xorg-video-neomagic 1:1.2.2-2 - 1:1.2.1-1
[DOWNGRADE] xserver-xorg-video-r128 6.8.0+git20090201.08d56c88-2 - 6.8.0-1
[DOWNGRADE] xserver-xorg-video-radeon 1:6.12.2-1 - 1:6.9.0-1+lenny4
[DOWNGRADE] xserver-xorg-video-s3 1:0.6.1-2 - 1:0.6.0-1
[DOWNGRADE] xserver-xorg-video-siliconmotion 1:1.7.0-2 - 1:1.6.0-1
[DOWNGRADE] xserver-xorg-video-sisusb 1:0.9.1-1 - 1:0.9.0-1
[DOWNGRADE] xserver-xorg-video-tseng 1:1.2.1-1 - 1:1.2.0-1
[DOWNGRADE] xserver-xorg-video-vmware 1:10.16.5-3 - 1:10.16.2-1
[DOWNGRADE] xserver-xorg-video-voodoo 1:1.2.1-1 - 1:1.2.0-1
[HOLD] aptitude
[HOLD] gnome-desktop-environment
[HOLD] libapt-pkg-perl


Any suggestions how to diagnose this problem further?
I'll try to upgrade again to current unstable version and try packages
I've built earlier (6.9.0, 6.11.0) - this time remembering always to
reboot after installation.


-- 
Jacek Politowski



-- 
To UNSUBSCRIBE

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

2009-04-19 Thread Jacek Politowski 
On Sun, Apr 19, 2009 at 12:46:47PM +0200, Michel Dänzer wrote:
On Sun, 2009-04-19 at 08:55 +0200, Jacek Politowski wrote:

 I'll try to upgrade again to current unstable version and try packages
 I've built earlier (6.9.0, 6.11.0) - this time remembering always to
 reboot after installation.

Sounds like a good plan; even better if you could try to always
up/downgrade as few packages at a time as possible. Also, it might be
useful if you could record Xorg.0.log files and kernel output for each
case.

Meanwhile, I upgraded kernel to 2.6.29, which changed nothing in
behaviour of Xorg (both version from unstable distribution and
downgraded to versions from testing)


To be able to change as few packages as possible, at first I stayed at
working Xorg from testing and changed only xserver-xorg-video-radeon.


Basically only version 6.9.0 works (both - in X from testing and from
unstable). Unfortunately I don't have access to source package of 6.10
version of radeon driver.


I've installed Debian/testing on new VirtualBox machine to build
packages.

In all packages with version higher than 6.9.0, I had to manually
change versioned build-dependency on 'xserver-xorg-dev' before
building, because higher version was theoretically required.

1) 6.12.2
(binary package built from unstable distribution source package) 
Display corrupted.

2) 6.9.0
(binary package installed directly from testing repo)
Correct image. Works perfectly.

3) 6.11.0
(binary package built from Brice's source packages)
Display corrupted.

4) 6.10.99.0
(binary package built from Brice's source packages)
Display corrupted.

5) 6.9.0
(binary package built, to verify correctness of my building process,
from source packages from testing repo)
Correct image. Works perfectly.


After that I upgraded X back to unstable, full aptitude log:

[INSTALL, DEPENDENCIES] console-setup
[INSTALL, DEPENDENCIES] console-terminus
[INSTALL, DEPENDENCIES] libpciaccess0
[INSTALL, DEPENDENCIES] xserver-common
[REMOVE, DEPENDENCIES] xserver-xorg-video-cyrix
[REMOVE, DEPENDENCIES] xserver-xorg-video-glint
[REMOVE, DEPENDENCIES] xserver-xorg-video-imstt
[REMOVE, DEPENDENCIES] xserver-xorg-video-nsc
[REMOVE, DEPENDENCIES] xserver-xorg-video-tga
[REMOVE, DEPENDENCIES] xserver-xorg-video-vga
[UPGRADE] x11-common 1:7.3+18 - 1:7.4+1
[UPGRADE] xnest 2:1.4.2-11 - 2:1.6.1-1
[UPGRADE] xserver-xephyr 2:1.4.2-11 - 2:1.6.1-1
[UPGRADE] xserver-xorg 1:7.3+18 - 1:7.4+1
[UPGRADE] xserver-xorg-core 2:1.4.2-11 - 2:1.6.1-1
[UPGRADE] xserver-xorg-input-all 1:7.3+18 - 1:7.4+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-input-synaptics 0.14.7~git20070706-3 - 1.1.0-1
[UPGRADE] xserver-xorg-input-wacom 0.8.1.6-1 - 0.8.3.2-1
[UPGRADE] xserver-xorg-video-all 1:7.3+18 - 1:7.4+1
[UPGRADE] xserver-xorg-video-apm 1:1.2.0-1 - 1:1.2.1-2
[UPGRADE] xserver-xorg-video-ark 1:0.7.0-1 - 1:0.7.1-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-dummy 1:0.3.0-1 - 1:0.3.1-2
[UPGRADE] xserver-xorg-video-fbdev 1:0.4.0-1 - 1:0.4.0-4
[UPGRADE] xserver-xorg-video-i128 1:1.3.0-1 - 1:1.3.1-3
[UPGRADE] xserver-xorg-video-i740 1:1.2.0-1 - 1:1.3.0-1
[UPGRADE] xserver-xorg-video-intel 2:2.3.2-2+lenny6 - 2:2.7.0-1
[UPGRADE] xserver-xorg-video-mach64 6.8.0-1 - 6.8.0+git20090201.d394e0b8-2
[UPGRADE] xserver-xorg-video-mga 1:1.4.9.dfsg-1 - 1:1.4.9.dfsg-4
[UPGRADE] xserver-xorg-video-neomagic 1:1.2.1-1 - 1:1.2.2-2
[UPGRADE] xserver-xorg-video-nv 1:2.1.10-1 - 1:2.1.13-1
[UPGRADE] xserver-xorg-video-openchrome 1:0.2.903+svn741-1 - 
1:0.2.903+svn741-1+b1
[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.0jp1tst1 - 1:6.12.2-1
[UPGRADE] xserver-xorg-video-radeonhd 1.2.1-2 - 1.2.5-1
[UPGRADE] xserver-xorg-video-rendition 1:4.2.0.dfsg.1-2 - 1:4.2.1-1
[UPGRADE] xserver-xorg-video-s3 1:0.6.0-1 - 1:0.6.1-2
[UPGRADE] xserver-xorg-video-s3virge 1:1.10.1-1 - 1:1.10.2-2
[UPGRADE] xserver-xorg-video-savage 1:2.2.1-2.lenny1 - 1:2.2.1-5
[UPGRADE] xserver-xorg-video-siliconmotion 1:1.6.0-1 - 1:1.7.0-2
[UPGRADE] xserver-xorg-video-sis 1:0.10.0-1 - 1:0.10.1-2
[UPGRADE] xserver-xorg-video-sisusb 1:0.9.0-1 - 1:0.9.1-1
[UPGRADE] xserver-xorg-video-tdfx 1:1.4.0-1 - 1:1.4.1-1
[UPGRADE] xserver-xorg-video-trident 1:1.3.0-1 - 1:1.3.1-1
[UPGRADE] xserver-xorg-video-tseng 1:1.2.0-1 - 1:1.2.1-1
[UPGRADE] xserver-xorg-video-v4l 0.2.0-1 - 0.2.0-3
[UPGRADE] xserver-xorg-video-vesa 1:1.3.0-4 - 1:2.2.0-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


and tested further:

6) 6.12.2
(binary package installed directly from unstable repo)
Display corrupted.
At 1280x1024 resolution - I had to connect second

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

2009-04-18 Thread Jacek Politowski 
On Sat, Apr 18, 2009 at 11:40:37AM +0200, Michel Dänzer wrote:
On Sat, 2009-04-18 at 02:56 +0200, Jacek Politowski wrote:

 Neither 6.11.0, built from your sources, nor 6.9.0 built from official
 Debian's repo solves my problem.
 
 So, either I'm doing something wrong while building/installing
 package, [...]

 grep -A2 radeon_drv /var/log/Xorg.0.log

 should verify this in each case.

For self-built 6.9.0 (sources taken from pool on pl.debian.org mirror):

$ grep -A2 radeon_drv /var/log/Xorg.0.log
(II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so
(II) Module radeon: vendor=X.Org Foundation
compiled for 1.6.1, module version = 4.3.0
$ dpkg -S /usr/lib/xorg/modules/drivers/radeon_drv.so
xserver-xorg-video-radeon: /usr/lib/xorg/modules/drivers/radeon_drv.so
$ dpkg -s xserver-xorg-video-radeon | grep Version
Version: 1:6.9.0-1+lenny4.0jp1


Module version surprised me here, for other builds it's much more
predictable.
Although compiled for 1.6.0 in stock 6.12.2 also seems interesting
for me.


For stock Debian's 6.12.2:

$ grep -A2 radeon_drv /var/log/Xorg.0.log
(II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so
(II) Module radeon: vendor=X.Org Foundation
compiled for 1.6.0, module version = 6.12.2
You have new mail in /var/mail/jacek
$ dpkg -S /usr/lib/xorg/modules/drivers/radeon_drv.so
xserver-xorg-video-radeon: /usr/lib/xorg/modules/drivers/radeon_drv.so
$ dpkg -s xserver-xorg-video-radeon | grep Version
Version: 1:6.12.2-1


And for 6.11.0 built from Brice's source packages:

$ grep -A2 radeon_drv /var/log/Xorg.0.log
(II) Loading /usr/lib/xorg/modules/drivers//radeon_drv.so
(II) Module radeon: vendor=X.Org Foundation
compiled for 1.6.1, module version = 6.11.0
$ dpkg -S /usr/lib/xorg/modules/drivers/radeon_drv.so
xserver-xorg-video-radeon: /usr/lib/xorg/modules/drivers/radeon_drv.so
$ dpkg -s xserver-xorg-video-radeon | grep Version
Version: 1:6.11.0-1.0jp1


-- 
Jacek Politowski



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

2009-04-18 Thread 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

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

2009-04-17 Thread Jacek Politowski 
On Thu, Apr 16, 2009 at 10:45:16PM +0200, Brice Goglin wrote:
Jacek Politowski wrote:

 Where to find 6.1{0,1}.0? I can't find it neither on
 snapshot.debian.net nor on regular mirror (ftp.pl.debian.org).

I only have packages for 6.10.99.0 and 6.11.0 for i386.
If you want to rebuild them, they're at
http://people.debian.org/~bgoglin/rebuilds/Xserver1.6/

Neither 6.11.0, built from your sources, nor 6.9.0 built from official
Debian's repo solves my problem.

So, either I'm doing something wrong while building/installing
package, or it's not the radeon driver what's making my display
corrupted.

Possibly it's time to reassign the bug, only where to?


-- 
Jacek Politowski



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

2009-04-16 Thread Jacek Politowski 
On Thu, Apr 16, 2009 at 08:48:10AM +0200, Michel Dänzer wrote:
On Thu, 2009-04-16 at 00:07 +0200, Jacek Politowski wrote:

 Package: xserver-xorg-video-radeon
 Version: 1:6.12.2-1
 Severity: normal

 After recent upgrade (I believe) display got totally corrupted.
(...)
 I'm using AGP Radeon X800 GTO with HP LP2475w monitor, connected via DVI.
 This card has both D-Sub and DVI connectors.
 
 Upgrade:
 xserver-xorg-video-radeon 1:6.9.0-1+lenny4 - 1:6.12.2-1
 
 After this upgrade I haven't rebooted machine, nor have I restarted 
 GDM/logged
 out, until today's upgrade:
 [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
(...)
 After this, machine booted to described state.

So you never tested xserver-xorg-video-radeon 1:6.12.2-1 with
xserver-xorg-core 2:1.6.0-1?

Yup, that's right. I've never tested this combination.

Does
   Option  DRI off
work around the problem?

No, it doesn't.


-- 
Jacek Politowski



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

2009-04-16 Thread Jacek Politowski 
On Thu, Apr 16, 2009 at 12:12:26PM -0400, Alex Deucher wrote:
On 4/16/09, Jacek Politowski j...@jp.pl.eu.org wrote:
 On Thu, Apr 16, 2009 at 08:48:10AM +0200, Michel Dänzer wrote:
  On Thu, 2009-04-16 at 00:07 +0200, Jacek Politowski wrote:

   Package: xserver-xorg-video-radeon
   Version: 1:6.12.2-1
   Severity: normal

   After recent upgrade (I believe) display got totally corrupted.
  (...)
   I'm using AGP Radeon X800 GTO with HP LP2475w monitor, connected via DVI.
   This card has both D-Sub and DVI connectors.
  
   Upgrade:
   xserver-xorg-video-radeon 1:6.9.0-1+lenny4 - 1:6.12.2-1
  
   After this upgrade I haven't rebooted machine, nor have I restarted 
 GDM/logged
   out, until today's upgrade:
   [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
  (...)
   After this, machine booted to described state.
(...)
  Does
 Option  DRI off
  work around the problem?

  No, it doesn't.

Does:
Option NoAccel TRUE
work around the problem?

That was the first thing I've checked. Sorry, I obviously forgot to
mention that in my initial bug report.

Combinig
Option DRI off
and
Option NoAccel true
doesn't help either.


I've tried to boot Windows XP on the machine and it works correctly,
this probably rules out hardware failure.

I also tried:
Option R4xxATOM true
(_also_ together with DRI off and NoAccel true) but it didn't help too.


-- 
Jacek Politowski



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

2009-04-16 Thread Jacek Politowski 
On Thu, Apr 16, 2009 at 01:06:19PM -0400, Alex Deucher wrote:
 On 4/16/09, Alex Deucher alexdeuc...@gmail.com wrote:
 On 4/16/09, Jacek Politowski j...@jp.pl.eu.org wrote:
 On Thu, 2009-04-16 at 00:07 +0200, Jacek Politowski wrote:

 Package: xserver-xorg-video-radeon
 Version: 1:6.12.2-1
 Severity: normal

 After recent upgrade (I believe) display got totally corrupted.
  (...)
 I'm using AGP Radeon X800 GTO with HP LP2475w monitor, connected via 
 DVI.

(...)
 Switching back to 6.9.0 with your current kernel/xserver/etc. fixes
  it?  How about 6.10.0 or 6.11.0 or 6.12.1?  It would be helpful to
  narrow down where the problem was introduced.

 Does the attached patch help?

Switching back to 6.9.0 was impossible due to dependency conflict, as
it provides 'xserver-xorg-video-2' and xserver-xorg-core explicitly
conflicts with 'xserver-xorg-video-2'.

Where to find 6.1{0,1}.0? I can't find it neither on
snapshot.debian.net nor on regular mirror (ftp.pl.debian.org).


Unfortunately your patch doesn't help either.


I installed under VirtualBox, on other machine, fresh Sid instance to
build xserver-xorg-video-radeon with your patch.

Then I did something like this:

$ apt-get source xserver-xorg-video-radeon
$ apt-get build-dep xserver-xorg-video-radeon

$ patch  debian524280.diff
### .diff and patched file in the same directory, patch applied cleanly

### added new revision in changelog

$ dpkg-buildpackage -rfakeroot -us -uc
### built cleanly - xserver-xorg-video-radeon_6.12.2-1.0jp1_i386.deb

### copied package to my machine and installed:
$ sudo dpkg -i xserver-xorg-video-radeon_6.12.2-1.0jp1_i386.deb
### installed correctly
$ dpkg -s xserver-xorg-video-radeon
Version: 1:6.12.2-1.0jp1

### started GDM
$ sudo /etc/init.d/gdm start


Display still corrupted.

-- 
Jacek Politowski



-- 
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org