Bug 14048 - x86emu: trident: infinite loop
Summary: x86emu: trident: infinite loop
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Trident (show other bugs)
Version: 7.3 (2007.09)
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
: 11617 (view as bug list)
Depends on:
Reported: 2008-01-13 00:41 UTC by Timo Aaltonen
Modified: 2018-06-12 19:10 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:

dmesg output (11.58 KB, application/octet-stream)
2008-01-25 03:02 UTC, Diego
no flags Details
lspci output (948 bytes, application/octet-stream)
2008-01-25 03:04 UTC, Diego
no flags Details
Xorg.0.log not using Option "NoDDC" (18.59 KB, text/x-log)
2008-01-25 03:05 UTC, Diego
no flags Details
xorg.conf not using Option "NoDDC" (3.15 KB, application/octet-stream)
2008-01-25 03:21 UTC, Diego
no flags Details
Xorg.0.log using Option "NoDDC" (32.03 KB, patch)
2008-01-25 03:23 UTC, Diego
no flags Details | Splinter Review
Arch Linux's "X -configure" xorg.conf (3.01 KB, text/plain)
2009-03-07 01:16 UTC, Diego
no flags Details
Arch Linux's Xorg.0.log without Option "NoDDC". (33.24 KB, text/x-log)
2009-03-07 01:19 UTC, Diego
no flags Details

Description Timo Aaltonen 2008-01-13 00:41:37 UTC
Forwarded from https://launchpad.net/bugs/181176, also reported on Debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454304


When launching X at anytime, usally right off the start. Ie right after X launches and splash screen occurs.

 /usr/bin/X goes into infinate loop consuming 99% CPU.

Verified by booting to single user, starting sshd, and letting boot. As soon as screen goes blank,
login via ssh and run top.

This occurs on a Toshiba Satellite Laptop 1800 exact model PS181C BIOS version 1.2 (floppy is dead, cannot upgrade BIOS)

Other reports of similair problem on FORUM and at following link with Debian Kernel:

dpkg -i xserver-xorg-core-dbg_1.3.0.0.dfsg-12ubuntu8_i386.deb

and attached gdb to /usr/bin/X11 process. The following is the backtrace, repeated numerous times:

(gdb) bt full
#0 x86emuOp_opc80_byte_RM_IMM (op1=128 '\200')
    at ../../../../hw/xfree86/int10/../x86emu/ops.c:5205
        mod = <value optimized out>
        rl = <value optimized out>
        rh = <value optimized out>
        destreg = <value optimized out>
        imm = <value optimized out>
        destval = <value optimized out>
#1 0xb7bd11b3 in X86EMU_exec ()
    at ../../../../hw/xfree86/int10/../x86emu/decode.c:122
        op1 = <value optimized out>
#2 0xb7bbd825 in xf86ExecX86int10 (pInt=0x8217870)
    at ../../../../hw/xfree86/int10/xf86x86emu.c:40
        sig = 0
#3 0xb7bd93f9 in vbeDoEDID (pVbe=0x8217848, pDDCModule=0x0)
    at ../../../../hw/xfree86/vbe/vbe.c:190
        pMonitor = <value optimized out>
        pModule = (pointer) 0x1
        DDC_data = <value optimized out>
#4 0xb7c0aa20 in TRIDENTSwitchMode ()
   from /usr/lib/xorg/modules/drivers//trident_drv.so
No symbol table info available.
#5 0x080a8e54 in InitOutput (pScreenInfo=0x8202a80, argc=10, argv=0xbf9e45f4)
    at ../../../../hw/xfree86/common/xf86Init.c:601
        i = <value optimized out>
        j = -1208328589
        k = <value optimized out>
        scr_index = <value optimized out>
        modulelist = <value optimized out>
        optionlist = (pointer *) 0x82115e0
        layout = <value optimized out>
        screenpix24 = <value optimized out>
        pix24 = <value optimized out>
        pix24From = <value optimized out>
        autoconfig = <value optimized out>
        generation = 1
#6 0x08076ceb in main (argc=10, argv=0xbf9e45f4, envp=0xbf9e4620)
    at ../../dix/main.c:370
        i = <value optimized out>
        error = 136217184
        xauthfile = <value optimized out>
        alwaysCheckForInput = {0, 1}

adding option NoDDC makes it work ok.
Comment 1 Diego 2008-01-25 02:59:43 UTC
I absolutely confirm this bug. I posted some infos about this bug here:
But I was probably wrong about "xorg starts correctly" as it doesn't start and it behaves like Timo described (100% CPU).

So I correct my previous statement and re-post my infos (as attachments seem corrupted in the other bug).

Toshiba 1800-100 and Trident Ai1 (for
more info see the attached X org log and dmesg).

Not-working Distributions tested:
- Ubuntu 7.10 - Xorg 7.2
- Debian unstable - Xorg 7.3
- Fedora 7 - Xorg 7.2
Working distros:
- Debian 4.0 - Xorg 7.1
- a lot of other distros with Xorg <= 7.1

Other reports:

Add Option "NoDDC" in the "Device" section of xorg.conf

Bugs probably related (or duplicates):

Working combinations of xorg.conf:
driver trident + option noddc
Not working combinations:
driver trident without option noddc
driver vesa + option noddc

Going to attach some logs.
Comment 2 Diego 2008-01-25 03:02:39 UTC
Created attachment 13927 [details]
dmesg output
Comment 3 Diego 2008-01-25 03:04:38 UTC
Created attachment 13928 [details]
lspci output
Comment 4 Diego 2008-01-25 03:05:58 UTC
Created attachment 13929 [details]
Xorg.0.log not using Option "NoDDC"

Last two lines are:
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"(II) Module "ddc" already built-in
Comment 5 Diego 2008-01-25 03:21:20 UTC
Created attachment 13930 [details]
xorg.conf not using Option "NoDDC"

This xorg.conf is taken from Debian Etch and Xorg 7.1. Updating to testing / unstable results in Xorg 7.2 or 7.3 not starting. Using the same xorg.conf and adding
Option "NoDDC" fixes the problem.
Comment 6 Diego 2008-01-25 03:23:31 UTC
Created attachment 13931 [details] [review]
Xorg.0.log using Option "NoDDC"

Using Option "NoDDC" starts Xorg 7.2 and Xorg 7.3 correctly.
Comment 7 Brice Goglin 2008-03-15 02:12:15 UTC
Could this be fixed thanks to the recent patches from Bart? (bug#14332)
Comment 8 Diego 2008-03-18 05:05:52 UTC
(In reply to comment #7)
> Could this be fixed thanks to the recent patches from Bart? (bug#14332)

As I am not able to patch and compile by myself: is there a precompiled version I can test? (e.g. from Debian unstable/experimental, Fedora rawhide or so on).
Comment 9 Adam Jackson 2008-03-24 09:13:15 UTC
(In reply to comment #8)

> As I am not able to patch and compile by myself: is there a precompiled version
> I can test? (e.g. from Debian unstable/experimental, Fedora rawhide or so on).

Rawhide has these patches included now, yes.
Comment 10 Diego 2008-03-25 09:51:47 UTC
(In reply to comment #9)
> Rawhide has these patches included now, yes.

Unfortunately Fedora 9 beta (25/03/2008) still has the same bug.
If I start the installation in graphical mode the screen turns blank and CPU fan goes at the maximum speed (indicating constant 100% CPU usage); while if I start in text mode everything goes well.
Comment 11 Adam Jackson 2008-06-19 09:46:27 UTC
Meh.  Trident isn't that important, moving to 7.5.
Comment 12 Diego 2008-06-19 10:00:16 UTC
(In reply to comment #11)
> Meh.  Trident isn't that important, moving to 7.5.

Three releases with this nasty bug is not good however luckily there aren't a lot of these cards out there nowadays. If you need a tester I'm here...
Comment 13 Timo Aaltonen 2008-10-31 03:14:33 UTC
*** Bug 15937 has been marked as a duplicate of this bug. ***
Comment 14 Timo Aaltonen 2008-10-31 03:22:19 UTC
*** Bug 11617 has been marked as a duplicate of this bug. ***
Comment 15 Ian! D. Allen 2009-03-02 23:03:43 UTC
Without the NoDCC "work-around", Xorg 1.5.2 goes into an infinite CPU loop.
With NoDCC, Xorg 1.5.2 locks up the machine hard, requiring a power cycle.

Copying X.Org X Server and the associated /usr/lib/xorg directory
from Ubuntu 8.04 to the Ubuntu 8.10 machine allows the NoDCC work-around to
work without locking up the machine hard.

Toshiba Laptop "Satellite" Model PS181C-00CET
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 5d)

O/S Ubuntu 8.10

X.Org X Server 1.5.2
Release Date: 10 October 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-19-server i686 Ubuntu
Current Operating System: Linux toshiba-laptop 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686
Build Date: 24 October 2008  08:00:16AM
xorg-server 2:1.5.2-2ubuntu3 (buildd@rothera.buildd) 
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Module Loader present

------------ xorg.conf with work-around --------
# this works for X.Org (copied from Ubuntu 8.04)
# this locks up the machine hard for X.Org 1.5.2 (default in Ubuntu 8.10)
Section "Device"
	Identifier	"Configured Video Device"
	Option          "NoDDC"

Section "Monitor"
	Identifier	"Configured Monitor"
	VendorName "Toshiba"
        ModelName  "Unknown"
        HorizSync  31.5-90
        VertRefresh 60
	Option		"NoDDC"
	Option		"DPMS"	"True"

Section "Screen"
	Identifier	"Default Screen"
	Monitor		"Configured Monitor"
	Device		"Configured Video Device"
Comment 16 Diego 2009-03-07 01:15:38 UTC
I tried another distro which ships packages which are compiled from almost vanilla sources: Arch Linux 2009. To my surprise X.Org X Server 1.5.3 seems to work flawlessly even without the "NoDDC" option. So this bug is probably due to a weird patch downstream.

The xorg.conf is generated by X -configure, with no modifications.
Comment 17 Diego 2009-03-07 01:16:56 UTC
Created attachment 23619 [details]
Arch Linux's "X -configure" xorg.conf
Comment 18 Diego 2009-03-07 01:19:24 UTC
Created attachment 23620 [details]
Arch Linux's Xorg.0.log without Option "NoDDC".

This is the proof that XServer 1.5.3 works without "NoDDC" option enabled.
Comment 19 Diego 2009-03-07 01:27:10 UTC
Uh... and it works without xorg.conf too!
Comment 20 Luc Verhaegen 2010-10-24 15:12:17 UTC
This smells like another x86emu bug.
Comment 21 Alan Coopersmith 2012-03-12 17:59:00 UTC
Removed from X11R7.6 blocker list since it's unclear where the bug lies, or if it's even in our code and not a distro patch.   Also, because it's trident,
which is pretty unmaintained due to lack of interest.
Comment 22 Adam Jackson 2018-06-12 19:10:24 UTC
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.