Bug 21423 - Failed query for restore registers (unknown HDMI output type)
Summary: Failed query for restore registers (unknown HDMI output type)
Status: RESOLVED WONTFIX
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/radeonhd (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Luc Verhaegen
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-26 13:36 UTC by guenther
Modified: 2011-11-07 15:32 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Alle m.E. relevanten Log-Files (26.00 KB, application/zip)
2009-04-26 13:36 UTC, guenther
no flags Details
glxinfo.zip, contents: glxinfo.log and xorg.conf (3.59 KB, application/zip)
2009-05-05 13:06 UTC, guenther
no flags Details

Description guenther 2009-04-26 13:36:38 UTC
Created attachment 25156 [details]
Alle m.E. relevanten Log-Files

Obwohl ich (seit SuSE-4.1) immer wieder Probleme mit ATI Karten hatte, lerne ich scheinbar nicht hinzu und bin wieder Besitzer einer HD4670.
Ablauf des Problems:  
- Installation OpenSuse-11.1 - alles ok. 
- upgrade auf current versions: - alles ok.
- Upgrade von KDE 4.13 nach 4.22 - noch alles ok
- Beim nachsten Start: startx endet mit weißem Schirm, und cursor-x in der Mitte.

Nach Neuinstallation :
 Exakt der selbe Ablauf.

Folgendes habe ich versucht:
- Installation von fglrx-Drivern: Totaches Chaos, Hang.
- Installation der folgenden Driver (nacheinander)
  xorg-x11-videoradeonhd-1,2,5-5.1.x86_64.rpm, 1.2.5-7.1, und ...debuginfo-1.2.5-7.1, alle enden mit dem weißen Schirm und dem cursor-Kreux in der Mitte. 
 
Im Anhang, radeonlogs.zip, sollten Zip-Files aller relevanten Logs zu finden sein, falls Infos fehlen, bitte Nachricht, und ich eiche sie nach.

Danke für Hilfen. ich weiß nicht mehr weiter.
Peter Günther
Comment 1 Rafał Miłecki 2009-04-26 23:19:00 UTC
Part of bug report translated to english:
> startx ends with a white screen, and cursor-x in the middle.

Important parts of attached Xorg.0.log:
(--) RADEONHD(0): Detected an RV730 on an unidentified card
(WW) RADEONHD(0): rhdAtomAllocateFbScratch: FW FB scratch area not located at the end of VRAM. Scratch End: 0x84fec VRAM End: 0x10000000
(EE) RADEONHD(0): RHDHdmiInit: unknown HDMI output type
(WW) RADEONHD(0): RHDCSInit: No CS for R600 and up yet.
last 2 lines:
(II) RADEONHD(0): Query for Restore Registers: failed
(II) RADEONHD(0): Query for Restore Registers: failed
Comment 3 Matthias Hopf 2009-05-04 07:29:09 UTC
Do you remember the version of the driver that worked last?

The driver is working flawlessly with an RV730 here on os11.1, so there's a subtle difference between our hardware and yours.
Comment 4 Matthias Hopf 2009-05-04 07:32:26 UTC
BTW - the 'Query for Restore Registers: failed' is apparently not harmful (I get it as well, though I don't know the origins by memory). It's neither a warning nor an error either.
Comment 5 guenther 2009-05-04 09:13:42 UTC
(In reply to comment #3)
> Do you remember the version of the driver that worked last?
> 
> The driver is working flawlessly with an RV730 here on os11.1, so there's a
> subtle difference between our hardware and yours.
> 

Sorry, i do not know the version-number which worked last. It worked fine with the version that came with os-11.1, and broke with the upgrade from kde-4.1.3 to kde-4.2.2, and never worked again. In the meantime. i tried the following radeonhd versions from the database:
1.2.3_081202, 1.2.5-5.1, 1.2.5-7.1, 1.2.5post_090425_8932f43-1.1, 1.2.5post_090430357f190-1.1, and debuginfo-1.2.5-7.1, always the x86_64 version. All fail with 'RHDHdmiInit: unknown HDMI output type'.
Peter
Comment 6 Matthias Hopf 2009-05-04 09:45:05 UTC
The 'RHDHdmiInit: unknown HDMI output type' message should uncorrelated - the port is still added as DVI output (HDMI handling in our AtomBIOS system is sub-optimal, still).
I'll ask Stefan on Wednesday which version we originally shipped with 11.1.

But chances are that this breaks not due to the driver version but due to some other upgrade (xserver, etc.). This still may indicate a bug in radeonhd, though.

One idea: maybe the KDE upgrade started a compositing manager, even though dri is not yet available. Can you try a failsafe session?
Comment 7 Rafał Miłecki 2009-05-04 09:49:53 UTC
> I'll ask Stefan on Wednesday which version we originally shipped with 11.1.

Just browse http://download.opensuse.org/distribution/11.1/repo/oss/suse/x86_64/

xorg-x11-driver-video-radeonhd-1.2.3_081202_ed532a7-1.1.x86_64.rpm

X Server version is in attached Xorg.0.log:
> X.Org X Server 1.5.2
Comment 8 guenther 2009-05-04 13:33:16 UTC
(In reply to comment #6)
> The 'RHDHdmiInit: unknown HDMI output type' message should uncorrelated - the
> port is still added as DVI output (HDMI handling in our AtomBIOS system is
> sub-optimal, still).
> I'll ask Stefan on Wednesday which version we originally shipped with 11.1.
> 
> But chances are that this breaks not due to the driver version but due to some
> other upgrade (xserver, etc.). This still may indicate a bug in radeonhd,
> though.
> 
> One idea: maybe the KDE upgrade started a compositing manager, even though dri
> is not yet available. Can you try a failsafe session?
> 
Just tried a failsave boot based on 2.6.27.21-0.1 as provided  in the GRUB menu by the installation of 11.1, but no change at all. I still believe the reason is caused by the KDE-4.2.2 OCI upgrade, because after the first beak, i did a new install, which worked fine up to the KDE upgrade. The upgrade is necessary because KDE-4.1.3 is so unstable that i concider it unusable.
(btw, i did the same with a VAJO notebook, and KDE-4.2.2 works almost perfect.
Onboard video-hw here js INTEL 945-GM) 
Peter.
Comment 9 guenther 2009-05-04 13:44:24 UTC
(In reply to comment #7)
> > I'll ask Stefan on Wednesday which version we originally shipped with 11.1.
> 
> Just browse
> http://download.opensuse.org/distribution/11.1/repo/oss/suse/x86_64/
> 
> xorg-x11-driver-video-radeonhd-1.2.3_081202_ed532a7-1.1.x86_64.rpm
> 
> X Server version is in attached Xorg.0.log:
> > X.Org X Server 1.5.2
> 
I tried to fall back to the 1.2.3... version by copying it from the installation-dvd and then installing it, but no change.

btw, the wrong-hdmi-type message is an (EE) type message which gives me the impression (from the logs) that it stops the execution of the radeonhd-driver.
Peter
Comment 10 Matthias Hopf 2009-05-05 04:02:26 UTC
One more thing:

please try

'X -ac & sleep 2 ; DISPLAY=:0 xterm'

and check whether you get anything reasonable (i.e. not a white screen). There should be an xterm running.

If you get the xterm, please do 'glxinfo > glxinfo.log' and attach the logfile.

Also, please attach your /etc/X11/xorg.conf.
Comment 11 guenther 2009-05-05 13:06:55 UTC
Created attachment 25485 [details]
glxinfo.zip, contents: glxinfo.log and xorg.conf
Comment 12 guenther 2009-05-05 13:18:31 UTC
(In reply to comment #10)
> One more thing:
> 
> please try
> 
> 'X -ac & sleep 2 ; DISPLAY=:0 xterm'
> 
> and check whether you get anything reasonable (i.e. not a white screen). There
> should be an xterm running.
> 
> If you get the xterm, please do 'glxinfo > glxinfo.log' and attach the logfile.
> 
> Also, please attach your /etc/X11/xorg.conf.
> 
Did as requested, worked as described. glxinfo.zip is sent, containing requested files.
Peter
Comment 13 Matthias Hopf 2009-05-06 03:04:33 UTC
As I assumed - this is presumably not a radeonhd issue, but a combination of KDE trying to use composite (probably using OpenGL), the logic of detecting whether 3D acceleration is available being broken (as Mesa now returns Direct Rendering: yes even for software rasterization), and the GLX_EXT_texture_from_pixmap being broken in the software rasterizer case.

An easy workaround would be - AFAIR - to disable the Composite extension in the Xserver: Add
  Option "Composite" "off"
in the "Extensions" section of your xorg.conf. If that doesn't help a KDE guru should help you how to switch of compositing by editing a KDE config file.
Comment 14 guenther 2009-05-06 06:59:11 UTC
(In reply to comment #13)
> As I assumed - this is presumably not a radeonhd issue, but a combination of
> KDE trying to use composite (probably using OpenGL), the logic of detecting
> whether 3D acceleration is available being broken (as Mesa now returns Direct
> Rendering: yes even for software rasterization), and the
> GLX_EXT_texture_from_pixmap being broken in the software rasterizer case.
> 
> An easy workaround would be - AFAIR - to disable the Composite extension in the
> Xserver: Add
>   Option "Composite" "off"
> in the "Extensions" section of your xorg.conf. If that doesn't help a KDE guru
> should help you how to switch of compositing by editing a KDE config file.
> 
Thanks, however the workaround did not help at all.
I opened bug no.191813 in bugs.kde.org 5 minutes ago, and will report the progess here asap.
I will be out of town starting tomorrow morning till may-18th, so i cannot checkout things in this period, however i will follow-up on both bugs daily and answer questions whenever possible.
thx, Peter 
Comment 15 Jeremy Huddleston Sequoia 2011-10-16 16:00:56 UTC
Does this issue occur with the preferred ati driver (xf86-vide-ati)?  If so, please move this to the Driver/Radeon component.  

Development of radeonhd has pretty much halted and development focus is on the ati driver.  Please see http://www.x.org/wiki/radeonhd

If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.
Comment 16 Jeremy Huddleston Sequoia 2011-11-07 15:32:13 UTC
Closing due to lack of response.  Please reopen and move to the Driver/Radeon 
component if this issue persists with xf86-video-ati


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.