[arch-general] MAYDAY - drm/mesa/libgl/radeon updates - laptop stuck in 1152x864 - kdm locks on logout!
Guys, I got bit bad tonight by the updates tonight. X starts but is stuck at 1152x864, if I log out, X freezes. Looks like bad libdrm and lib32-libdrm packages. Specifically, I upgraded: [2009-12-23 00:30] starting full system upgrade [2009-12-23 00:31] upgraded libdrm (2.4.17-1 -> 2.4.17-2) [2009-12-23 00:31] upgraded libgl (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded ati-dri (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded lib32-libdrm (2.4.16-1 -> 2.4.17-2) [2009-12-23 00:31] upgraded lib32-libgl (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded lib32-mesa (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded mesa (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded system-config-printer-common (1.1.13-1 -> 1.1.15-1) [2009-12-23 00:31] upgraded system-config-printer-gnome (1.1.13-1 -> 1.1.15-1) Next logout, the machine changed from 1440x900 to 1152x864 (the initial frame buffer resolution). Currently I am not using KMS with the radeon driver due to the current driver/initrd issues. I tried using a minimal xorg.conf setting the preferred resolution to 1440x900 (like I have done before to switch between the radeon/radeonhd drivers). X crashed immediately. Yes I had screens defined. X always started just fine with this xorg before. This is a short log: (this is the complete Xorg.0.log) X.Org X Server 1.7.3.901 (1.7.4 RC 1) Release Date: 2009-12-11 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-ARCH x86_64 Current Operating System: Linux alchemy 2.6.32-ARCH #1 SMP PREEMPT Sun Dec 20 10:01:30 CET 2009 x86_64 Kernel command line: root=/dev/disk/by-uuid/b004715c-1666-458a-b827-2bbb1d4a735e ro Build Date: 12 December 2009 08:39:02PM <snipped the definitions> Fatal server error: no screens found Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. (WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor (WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor OK, so I had 2 choices, either try KMS with the nonworking drm or downgrade. I decided to downgrade. So I tried to downgrade with: pacman -U /var/cache/pacman/pkg/libdrm-2.4.17-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/libgl-7.6.1-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/ati-dri-7.6.1-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/lib32-libdrm-2.4.16-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/lib32-libgl-7.6.1-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/lib32-mesa-7.6.1-1-x86_64.pkg.tar.gz /var/cache/pacman/pkg/mesa-7.6.1-1-x86_64.pkg.tar.gz Which failed dependencies with mesa/libmesa requiring libdrm/lib32-libdrm > or = 2.4.17-2. HUH?? Deps whacked somewhere, I just upgraded from 2.4.17-1 and it was working fine... So I just eliminated the libdrm/lib32-libdrm packages and downgraded leaving drm the way mesa/libmesa wanted it. (Note the different downgrade times for libdrm below) X was still stuck in 1152x864, this caused me to suspect libdrm was the problem. So I went ahead and downgraded libdrm/lib32-drm with pacman -U --nodeps and then rebooted --> BING0 right back to 1440x900. Some notes on the log for the downgrade. The downgrade log looks weird to me. Maybe that's the way it should look, but I would expect correct version numbers: [2009-12-23 02:00] upgraded libgl (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:00] upgraded ati-dri (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:00] upgraded lib32-libgl (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:00] upgraded lib32-mesa (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:00] upgraded mesa (7.6.1-1 -> 7.6.1-1) [2009-12-23 02:04] upgraded libdrm (2.4.17-2 -> 2.4.17-1) [2009-12-23 02:04] upgraded lib32-libdrm (2.4.17-2 -> 2.4.16-1) I may have missed some changelog that says change your config to XYZ for these packages, but honestly it just looks like this set of updates isn't quite done cooking yet. Let me know if you need for info, etc. I'm glad to provide logs, etc. I'll also go ahead and open a ticket if you think it is necessary. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On 12/23/2009 02:24 AM, David C. Rankin wrote:
I got bit bad tonight by the updates tonight. X starts but is stuck at 1152x864, if I log out, X freezes. Looks like bad libdrm and lib32-libdrm packages. Specifically, I upgraded:
[2009-12-23 00:30] starting full system upgrade [2009-12-23 00:31] upgraded libdrm (2.4.17-1 -> 2.4.17-2) [2009-12-23 00:31] upgraded libgl (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded ati-dri (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded lib32-libdrm (2.4.16-1 -> 2.4.17-2) [2009-12-23 00:31] upgraded lib32-libgl (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded lib32-mesa (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded mesa (7.6-2 -> 7.6.1-1) [2009-12-23 00:31] upgraded system-config-printer-common (1.1.13-1 -> 1.1.15-1) [2009-12-23 00:31] upgraded system-config-printer-gnome (1.1.13-1 -> 1.1.15-1)
UUGH!, It get's worse. I don't know if this is the downgrade or if this is the latest kernel update, but compiz whitescreens. (that a hardware/software rendering issue) I checked glxinfo, and it says it is using Mesa: 03:00 alchemy:~> glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_MESA_copy_sub_buffer client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 2.1 Mesa 7.6.1 OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_copy_buffer, GL_ARB_depth_texture, GL_ARB_draw_buffers, Ouch! Now, I don't know if this happened after the kernel update to 26-2.6.32.2-1 or if it just happened tonight with the drm update and then downgrade. I can't think of any reason the upgrade/downgrade would have done it unless pacman left pieces of something on the system. Regardless, compiz is unusable now. I know for a fact it was working last week (slow with the radeon driver, but working). Anybody else see a change in direct rendering with the latest kernel? What else to check? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Wed, 2009-12-23 at 03:05 -0600, David C. Rankin wrote:
Ouch! Now, I don't know if this happened after the kernel update to 26-2.6.32.2-1 or if it just happened tonight with the drm update and then downgrade. I can't think of any reason the upgrade/downgrade would have done it unless pacman left pieces of something on the system.
Regardless, compiz is unusable now. I know for a fact it was working last week (slow with the radeon driver, but working). Anybody else see a change in direct rendering with the latest kernel? What else to check?
I don't know what you did exactly, but to make things clear: We're back on stable versions without experimental code. This means there's no 3D support for some newer ATI hardware, but at least the 2D is stable and usable. You're on the Mesa software rasterizer now, which does everything in software. Compiz will be painfully slow with that.
On 12/23/2009 03:15 AM, Jan de Groot wrote:
On Wed, 2009-12-23 at 03:05 -0600, David C. Rankin wrote:
Ouch! Now, I don't know if this happened after the kernel update to 26-2.6.32.2-1 or if it just happened tonight with the drm update and then downgrade. I can't think of any reason the upgrade/downgrade would have done it unless pacman left pieces of something on the system.
Regardless, compiz is unusable now. I know for a fact it was working last week (slow with the radeon driver, but working). Anybody else see a change in direct rendering with the latest kernel? What else to check?
I don't know what you did exactly, but to make things clear: We're back on stable versions without experimental code. This means there's no 3D support for some newer ATI hardware, but at least the 2D is stable and usable. You're on the Mesa software rasterizer now, which does everything in software. Compiz will be painfully slow with that.
Err, yep slow is a nice way to put it. The question is how do I get back to the usable 2D hardware setup? Should I set KMS back up? I'm up to date with all packages except the mesa/drm/libgl packages I just downgraded 1 version. Everything was great before the update today and the drm snafu. What's the best way to get back to the config I had 24 hours ago? I took /var/log/pacman.log and backed out all updates except the kde & gnome printer control center modules (I can't see them being related), but I'm still not back to where I was before the updates. Am I missing something? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Wed, 2009-12-23 at 03:37 -0600, David C. Rankin wrote:
Err, yep slow is a nice way to put it. The question is how do I get back to the usable 2D hardware setup? Should I set KMS back up? I'm up to date with all packages except the mesa/drm/libgl packages I just downgraded 1 version. Everything was great before the update today and the drm snafu. What's the best way to get back to the config I had 24 hours ago?
I took /var/log/pacman.log and backed out all updates except the kde & gnome printer control center modules (I can't see them being related), but I'm still not back to where I was before the updates. Am I missing something?
KMS is not recommended for ATI at this moment, so we'll ship it disabled by default. There's also no stable non-experimental 2D or 3D stack supporting KMS, so we'll have to do with user mode setting. At this moment, our driver in extra is a stable released version. This released version is rather old, and there's about 10-15 commits on the stable branch that should get applied to the package. This fixes several issues, but hasn't made it into a release.
On 12/23/2009 05:20 PM, Jan de Groot wrote:
On Wed, 2009-12-23 at 03:37 -0600, David C. Rankin wrote:
Err, yep slow is a nice way to put it. The question is how do I get back to the usable 2D hardware setup? Should I set KMS back up? I'm up to date with all packages except the mesa/drm/libgl packages I just downgraded 1 version. Everything was great before the update today and the drm snafu. What's the best way to get back to the config I had 24 hours ago?
I took /var/log/pacman.log and backed out all updates except the kde & gnome printer control center modules (I can't see them being related), but I'm still not back to where I was before the updates. Am I missing something?
KMS is not recommended for ATI at this moment, so we'll ship it disabled by default. There's also no stable non-experimental 2D or 3D stack supporting KMS, so we'll have to do with user mode setting. At this moment, our driver in extra is a stable released version. This released version is rather old, and there's about 10-15 commits on the stable branch that should get applied to the package. This fixes several issues, but hasn't made it into a release.
Ah! Thank you again. Currently I have extra enabled and community-testing enabled so I do expect things to break. The xf86-video-ati 6.12.99.git20091221-1 package works fine for me except for the mesa/hardware issue. The resolution killer turned out to be libdrm-2.4.17-2. For some reason the libdrm package just ignored the 1440x900 display data. I think all would work find if I could get the resolution set. I'll tinker some more. If anyone has any idea on how to set the resolution at 1440x900 with the new libdrm, I would welcome any thoughts. I have tried: Section "Monitor" Identifier "Monitor[0]" VendorName "TOSHIBA" ModelName "TOSHIBA 17IN TRUEBRIGHT" UseModes "Modes[0]" DisplaySize 367 230 HorizSync 30.0 - 70.0 VertRefresh 43.0 - 60.0 Option "CalcAlgorithm" "XServerPool" Option "DPMS" Option "PreferredMode" "1440x900" EndSection Section "Modes" Identifier "Modes[0]" EndSection Section "Screen" DefaultDepth 24 SubSection "Display" Depth 15 Modes "1440x900" "1024x768" "800x600" EndSubSection SubSection "Display" Depth 16 Modes "1440x900" "1024x768" "800x600" EndSubSection SubSection "Display" Depth 24 Modes "1440x900" "1024x768" "800x600" EndSubSection SubSection "Display" Depth 8 Modes "1440x900" "1024x768" "800x600" EndSubSection Device "Device[0]" Identifier "Screen[0]" Monitor "Monitor[0]" EndSection Section "Device" BoardName "RS690M" Driver "radeon" Identifier "Device[0]" VendorName "ATI" EndSection Section "ServerLayout" Option "Clone" "off" Option "Xinerama" "off" Screen 0 "Screen[0]" 0 0 EndSection Section "DRI" Group "video" Mode 0660 EndSection Section "Extensions" Option "Composite" "true" Option "DAMAGE" "true" EndSection And... a number of variations to the above from what you see above down to the bare minimum of: Section "Device" BoardName "RS690M" Driver "radeon" # Driver "radeonhd" Identifier "Device[0]" VendorName "ATI" EndSection but still no joy.... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
participants (2)
-
David C. Rankin
-
Jan de Groot