Created attachment 48426 [details] 2.6.34 dmesg Hi, I have an old HTPC, with an older yet Soltek motherboard, AMD64 939, and a Radeon 9000 (r200). I had been using a quite old kernel, 2.6.32, because I got no video output with newer ones. These days I've had some time to test things out and I am now running 2.6.34 where everything works fine, however with any newer kernel I do have a usable kms console but a black screen on xorg. I tried every major stable kernel between 2.6.32 and 2.6.39 (vanilla kernels). Xorg server between 1.9.4 and 1.10.99.901, mesa between 7.9.2 and 7.10.3, and forcing different resolutions, on both VGA-0 and DVI-0 outputs; yet I can't get video working on 2.6.35+ kernels. I even tried with XAA, disabling ColorTiling, PCI bus type, disabling AGP Fast Writes, disabling DRI, ... to no avail. Nothing works with a sync extension enabled kernel. I attach the logs I found relevant. You can see the any differences in xorg between a working 2.6.34 kernel and a failing 2.6.35, are a quite longer EDID dump under 2.6.35 and the sync extension which was included on that kernel, which also enabled two new GL extensions, GLX_SGI_swap_control and GLX_MESA_swap_control. Everything else looks exactly the same. On my TV, which I connect from the DVI-0 output to a HDMI input (although I also tried through VGA), I can see it sets the video mode correctly, 1920*1080@50. In fact the kms console works fine all along. Even with the black xorg screen, I can switch back to a kms console and it works. I considered doing a bisect between 2.6.34 and 2.6.35 but there are far too many commits within drm for it to be feasible (it is not exactly fast this oldie). If you have any ideas where might be the problem or anything else which might be useful to fix this, I'd be really grateful.
Created attachment 48427 [details] 2.6.35 dmesg
Created attachment 48428 [details] xrandr output under 2.6.34
Created attachment 48429 [details] xrandr output under 2.6.35
Created attachment 48430 [details] xorg log under 2.6.34
Created attachment 48431 [details] xorg log under 2.6.35
Created attachment 48432 [details] xorg.conf
(In reply to comment #7) > I even tried with XAA, disabling ColorTiling, PCI bus type, disabling AGP Fast > Writes, disabling DRI, ... to no avail. Most of these X driver options are ineffective with KMS. > On my TV, which I connect from the DVI-0 output to a HDMI input (although I > also tried through VGA), I can see it sets the video mode correctly, > 1920*1080@50. In fact the kms console works fine all along. > Even with the black xorg screen, I can switch back to a kms console and it > works. What X clients are (supposed to be) running at that point? A login manager such as gdm or kdm, or a user session? If the latter, is it using an OpenGL compositing manager? > I considered doing a bisect between 2.6.34 and 2.6.35 but there are far too > many commits within drm for it to be feasible (it is not exactly fast this > oldie). As a quick'n'dirty test, you could try compiling the 2.6.35 radeon driver with KMS_DRIVER_MINOR modified to 3 in drivers/gpu/drm/radeon/radeon_drv.c . If that works around the problem, it's probably indeed related to the GLX sync extensions, and there's probably no point in bisecting the kernel.
(In reply to comment #7) > > I even tried with XAA, disabling ColorTiling, PCI bus type, disabling AGP Fast > > Writes, disabling DRI, ... to no avail. > Most of these X driver options are ineffective with KMS. I see. > > On my TV, which I connect from the DVI-0 output to a HDMI input (although I > > also tried through VGA), I can see it sets the video mode correctly, > > 1920*1080@50. In fact the kms console works fine all along. > > Even with the black xorg screen, I can switch back to a kms console and it > > works. > What X clients are (supposed to be) running at that point? A login manager such > as gdm or kdm, or a user session? If the latter, is it using an OpenGL > compositing manager? The only application running is XBMC, with no even a windows manager. I use xinit, with an empty .xinitrc and launch xbmc in full screen mode. xbmc is using OpenGL. > > I considered doing a bisect between 2.6.34 and 2.6.35 but there are far too > > many commits within drm for it to be feasible (it is not exactly fast this > > oldie). > As a quick'n'dirty test, you could try compiling the 2.6.35 radeon driver with > KMS_DRIVER_MINOR modified to 3 in drivers/gpu/drm/radeon/radeon_drv.c . If that > works around the problem, it's probably indeed related to the GLX sync > extensions, and there's probably no point in bisecting the kernel. It does look like that. As soon as the new kernel is compiled I'll see whether it works or not and get you back the result.
(In reply to comment #8) > The only application running is XBMC, with no even a windows manager. > > I use xinit, with an empty .xinitrc and launch xbmc in full screen mode. (In the future, please include this kind of information in bug reports; this isn't exactly a standard setup) Does setting the environment variable vblank_mode=0 for xbmc work around the problem?
(In reply to comment #9) > (In reply to comment #8) > > The only application running is XBMC, with no even a windows manager. > > I use xinit, with an empty .xinitrc and launch xbmc in full screen mode. > (In the future, please include this kind of information in bug reports; this > isn't exactly a standard setup) Yeah, I know it is not standard at all, a completely custom Gentoo HTPC/NAS. I tried to include everything I could think of but I was pretty sure I would forget something. > Does setting the environment variable vblank_mode=0 for xbmc work around the > problem? Both ways are successful. I had just compiled a new 2.6.35.9 with KMS_DRIVER_MINOR set to 3 and it works fine that way. Right now I booted from a previously compiled 2.6.39.1, setting the env vblank_mode to 0 and it also works fine. I understand we are disabling the sync extension, are we? Or does the vlank_mode=0 do anything else? I am now checking how well video plays. On 2.6.39.1 with vblank_mode=0 video playback is quite worse than I was used to. There is no tearing, but there is some kind of blockiness in the animation. On 2.6.35.9 with KMS_DRIVER_MINOR=3 video is almost like in not sync enabled kernels although there is still some blockiness, not as noticeable as in the other kernel though (vblank_mode is not set). You'll tell me whether we dig further to find if I can use the sync extension on this card or I shall force the older kms driver minor.
(In reply to comment #9) > (In reply to comment #8) > Does setting the environment variable vblank_mode=0 for xbmc work around the > problem? Michel, upon further testing how it performs in the three different scenarios, video playback is definitely worse with the 2.6.35 patched kernel and even worse with vblank_mode=0 with a 2.6.39 kernel. With the patched kernel it seems playback starts playing fine but after a while it gets that blockiness I told you before. BTW, I am running the latest xorg release candidate, but mesa 7.9.2. I didn't notice any difference at all between all the xorg releases I tested, whereas with mesa 7.10 playback gets worse than with 7.9.x compiled without llvm, gles or gallium. With 7.10 playback is unchanged by any of these.
> > The only application running is XBMC, with no even a windows manager. > > I use xinit, with an empty .xinitrc and launch xbmc in full screen mode. > Does setting the environment variable vblank_mode=0 for xbmc work around the > problem? Sorry to bother you again Michel. It seems the video I was playing was the cause of the blockiness. Instead of an OTA recorded video I am now using a dvdrip and playback is smooth in all three cases. I am really sorry for the confusion. It's just the recorded video I chose at random had stuttering on some parts. As far as I'm concerned I can settle for any of the options you gave me. Unless you deem it worth looking for the black screen's cause with vblank/sync enabled, I'm willing to try anything you ask me to. Anyway, thanks a lot for your help.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.