Summary: | [ATI/radeon] monitor resolution/frequency is locked | ||||||
---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Dams <anvil> | ||||
Component: | Driver/Radeon | Assignee: | Xorg Project Team <xorg-team> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | major | ||||||
Priority: | high | CC: | anvil, dberkholz, eric, hyu, kem, mharris, michel, mike.auty, talbotscott | ||||
Version: | 6.8.1 | ||||||
Hardware: | x86 (IA32) | ||||||
OS: | Linux (All) | ||||||
Whiteboard: | |||||||
i915 platform: | i915 features: | ||||||
Attachments: |
|
Description
Dams
2004-10-03 02:16:51 UTC
*** Bug 1175 has been marked as a duplicate of this bug. *** Created attachment 1057 [details]
output of /var/log/xorg.log
line reading:
(WW) RADEON(0): Failed to set up write-combining range (0xe0000000,0x4000000)
(II) RADEON(0): Dynamic Clock Scaling Disabled
hopefully will assist in resolving bug.
(II) RADEON(0): Validating modes on Primary head --------- (II) RADEON(0): Panel size found from DDC: 1920x1440 This is interesting. Is this a monitor (CRT) or an LCD/DFP display? Since this is reported for Radeon 7200, I'm assuming it is a monitor, so it shouldn't be detecting a panel size per se. On a separate note, are you using 'rhgb' to boot? (Graphical boot) If so, please try disabling rhgb, and rebooting the machine and trying to reproduce this issue. Report back your findings. Thanks in advance. If disabling rhgb and rebooting works around this problem, then it might possibly be DRI/multi-X-server related. If this stops the problem from occuring, boot into runlevel 3, then run startx on display :0 with DRI enabled, and a second copy of startx on :1 to see if it hangs. It definitely looks like the radeon display detection code is screwy here. (II) RADEON(0): I2C bus "DDC" initialized. (II) RADEON(0): Legacy BIOS detected (WW) RADEON(0): No Connector Info Table found! This seems related to the problem. It appears it can't find the connector table in the BIOS, and then guesses wrong that it is a flat panel display, but it is really a CRT. Hui, Michel: Any thoughts? RADEONQueryConnectedMonitors() calls RADEONGetConnectorInfoFromBIOS() which fails with FALSE in the following code for a LegacyBIOS: } else { if ((tmp = RADEON_BIOS16(info->ROMHeaderStart + 0x50))) { for (i = 1; i < 4; i++) { if (!RADEON_BIOS8(tmp + i*2) && i > 1) break; /* end of table */ tmp0 = RADEON_BIOS16(tmp + i*2); if (((tmp0 >> 12) & 0x1f) == 0) continue; /* no connector */ /* internal DDC_DVI port will get assigned to PortInfo[0], or if there is no DDC_DVI (like in some IGPs). */ tmp1 = ((((tmp0 >> 8) & 0xf) == DDC_DVI) || (tmp1 == 1)) ? 0 : 1; /* determine port info index */ pRADEONEnt->PortInfo[tmp1].DDCType = (tmp0 >> 8) & 0x0f; if (pRADEONEnt->PortInfo[tmp1].DDCType > DDC_CRT2) pRADEONEnt->PortInfo[tmp1].DDCType = DDC_NONE_DETECTED; pRADEONEnt->PortInfo[tmp1].DACType = (tmp0 & 0x01) ? DAC_TVDAC : DAC_PRIMARY; pRADEONEnt->PortInfo[tmp1].ConnectorType = (tmp0 >> 12) & 0x0f; if (pRADEONEnt->PortInfo[tmp1].ConnectorType > CONNECTOR_UNSUPPORTED) pRADEONEnt->PortInfo[tmp1].ConnectorType = CONNECTOR_UNSUPPORTED; pRADEONEnt->PortInfo[tmp1].TMDSType = ((tmp0 >> 4) & 0x01) ? TMDS_EXT : TMDS_INT; /* some sanity checks */ if (((pRADEONEnt->PortInfo[tmp1].ConnectorType != CONNECTOR_DVI_D) && (pRADEONEnt->PortInfo[tmp1].ConnectorType != CONNECTOR_DVI_I)) && pRADEONEnt->PortInfo[tmp1].TMDSType == TMDS_INT) pRADEONEnt->PortInfo[tmp1].TMDSType = TMDS_UNKNOWN; xf86DrvMsg(0, X_INFO, "Connector%d: DDCType-%d, DACType-%d, TMDSType-%d, ConnectorType-%d\n", tmp1, pRADEONEnt->PortInfo[tmp1].DDCType, pRADEONEnt->PortInfo[tmp1].DACType, pRADEONEnt->PortInfo[tmp1].TMDSType, pRADEONEnt->PortInfo[tmp1].ConnectorType); } } else { xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "No Connector Info Table found!\n"); return FALSE; } This causes the Connector Info Table message we see in the log file to get output. Back in RADEONQueryConnectedMonitors(), the following is what is executed for this block above: if (!RADEONGetConnectorInfoFromBIOS(pScrn)) { /* Below is the most common setting, but may not be true */ pRADEONEnt->PortInfo[0].MonType = MT_UNKNOWN; pRADEONEnt->PortInfo[0].MonInfo = NULL; pRADEONEnt->PortInfo[0].DDCType = DDC_DVI; pRADEONEnt->PortInfo[0].DACType = DAC_TVDAC; pRADEONEnt->PortInfo[0].TMDSType = TMDS_INT; pRADEONEnt->PortInfo[0].ConnectorType = CONNECTOR_DVI_D; pRADEONEnt->PortInfo[1].MonType = MT_UNKNOWN; pRADEONEnt->PortInfo[1].MonInfo = NULL; pRADEONEnt->PortInfo[1].DDCType = DDC_VGA; pRADEONEnt->PortInfo[1].DACType = DAC_PRIMARY; pRADEONEnt->PortInfo[1].TMDSType = TMDS_EXT; pRADEONEnt->PortInfo[1].ConnectorType = CONNECTOR_CRT; } The comment there "Below is the most common setting, but may not be true" definitely seems to not be true for a Radeon 7200, as it has one single head, and is not DVI. I think 2 things could/should be done in this case.. The first is to fix the BIOS detection code to handle this card's BIOS table correctly, so that the broken fallback path doesn't get taken. Since the driver worked in previous releases of X, this should be possible I'm assuming. The second would be to fix the fallback to perhaps be a bit more sane? Or perhaps to make the fallback PCI ID specific? Any thoughts? Discussed this with Anvil in IRC a bit. I got him to try: Option "MonitorLayout" "CRT,None" and that got past this problem but the server crashed with a different error/bug. Anvil: Can you file a new bug report for the new bug that occurs when you use MonitorLayout, and attach the config file and log file, and carbon copy me on it? TIA Here's another reference to this problem, copied over from bug #1175 for completeness: http://bugs.gentoo.org/show_bug.cgi?id=62702 Thanks Mike for the heads up. It looks like a DDC detection problem, there are several related bugs in the Bugzilla. I remember I tested two 7200 cards (one normal and one AIW) when xorg 6.8 was about to release, they all worked fine. I haven't tried xorg code since then. I'll take some time in next few days to revisit this issue according to all the recent bug reports. Thanks for the help! I don't believe I got any of my CCs (have to check that) anyway: #3 device is LCD panel (Samsung SyncMaster 193P) Tried w/O RHGB, no change, Tried startx from level 3 = no change Please try the patch I posted in Bug #1622, the patch should fix this 7200 problem too. Please test it, thx. It's normal for R7200 failing connector detection, old version of BIOS doesn't support it. The dual-head issue is different, I'll look at that later. I've tested the patch from bug 1559 with the 7200 I have here, and it fixes the detection problems. I still need to test it on other cards to make sure there are no regressions. Red Hat bug report, for cross referencing: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132865 (In reply to comment #14) > I've tested the patch from bug 1559 with the 7200 I have here, and it fixes the > detection problems. > > I still need to test it on other cards to make sure there are no regressions. Is this bug fixed now? As the original submitter (Dams) doesn't reply, presumed fixed. |
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.