Bug 16890 - Too long switch to console since 6.7.x
Summary: Too long switch to console since 6.7.x
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.3 (2007.09)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2008-07-29 09:11 UTC by Dmitry Butskoy
Modified: 2010-03-26 06:27 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
the patch (against 6.8.0) which fixes the issue. (557 bytes, patch)
2008-07-29 09:11 UTC, Dmitry Butskoy
no flags Details | Splinter Review

Description Dmitry Butskoy 2008-07-29 09:11:54 UTC
Created attachment 17967 [details] [review]
the patch (against 6.8.0) which fixes the issue.

Since the version of 6.7.191, the switch from X to VT console (Ctrl-Alt-Fn) takes up to 6 seconds (instead of 1 seconds before).

The monitor is "Flatron795FT Plus" (some old CRT display),
the card is "ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]",
it is dual-head card, but only one port is in use.

The console image appears fast as before (about 1 sec delay), but without "the final flip somewhere in monitor". Such a flip occurs only after 5-6 seconds, and during this period of time the console shivers.


Fortunately, I casually managed to find the solution. It looks strange, but the reason seems to be the uncommenting one of the previously commented out "usleep(100000);" delays...


Consider src/radeon_driver.c:RADEONRestore() : there is a fragment:

#if 1
    /* Temp fix to "solve" VT switch problems.  When switching VTs on
     * some systems, the console can either hang or the fonts can be
     * corrupted.  This hack solves the problem 99% of the time.  A
     * correct fix is being worked on.
     */
    usleep(100000);
#endif

In the versions before 6.7.x it was disabled (was "#if 0"), but now enabled.

When I change it back to "#if 0", the issue disappears. Additionally, I have experienced a little, and have found that on my system "usleep(80000)" is still OK, but usleep with >= 90000 causes the issue.


I can perform any additional tests, logs etc. if needed.
Comment 1 Corbin Simpson 2010-03-26 06:27:53 UTC
Is this still an issue? I mean, the code's still there, but hopefully you can use KMS these days, right?

Closing as FIXED since this entire chunk of code is hopefully deprecated, but if you absolutely need UMS, feel free to re-open.


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.