NoDDC option doesn't work for trident cyberblade/i1 resulting in system lockup

Bug #223774 reported by Daniel Dickinson
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Invalid
Undecided
Unassigned
X.Org X server
Invalid
Undecided
Unassigned
xf86-video-trident
Unknown
Critical
xserver-xorg-video-trident (Ubuntu)
Won't Fix
High
Unassigned
Declined for Gutsy by Steve Langasek
Nominated for Hardy by Damian Melniczuk
Intrepid
Won't Fix
High
Unassigned

Bug Description

In Gutsy it was possible get the display on a Toshiba Satellite 1800 (which I'm putting together for an group I'm part of) working by editing the Device section of of /etc/X11/xorg.conf to have Option "NoDDC" "true". This no longer works in Hardy and thus the laptop is a paperweight with Hardy. (vesa driver doesn't work either, for either)

The display adaptor built into the laptop is a Trident CyberBlade/i1

A fresh install of Hardy does not solve the problem. Only reverting to Gutsy and editing xorg.conf does.

In fact for Gutsy it is necessary to install an xorg.conf that has NoDDC before the initial installation of xserver.org is made or else the installer hangs with a blank screen during the configuration of that package.

This makes Ubuntu unsuitable for distribution with this laptop as it'd be far too easy for someone to end up with a non-working system, and depending on who gets it (it's a donation that's being raffled off), I may not be close enough to support the end user in case of trouble.

Tags: hardy lucid
Revision history for this message
Bryce Harrington (bryce) wrote :

Please attach your /var/log/Xorg.0.log from after trying to boot Hardy. The one from a working Gutsy would be useful for comparison, as well.

Changed in xorg:
status: New → Incomplete
Revision history for this message
Daniel Dickinson (cshore) wrote :
Download full text (3.7 KiB)

It turns out that the right xorg.conf works (but not the autogenerated from Hardy, and for Gutsy it must be present before the install configures xserver-xorg or it'll hang), provided the NoDDC option is present. I had that option when I tried in Hardy, but I got the xorg.conf wrong (it really sucks that you have no means of generating xorg.conf for cases where autodetection fails; this has been commented on on other bug reports, but you *really* need to do something about this. I would consider myself an advanced user but generating an xorg.conf without prompting (like that of dpkg-reconfigure xserver-xorg in gutsy and before) including not autodetecting, but selecting driver and general monitor type (e.g. 1024x768 @ 60Hz)) is quite more than I want to have to deal with. dpkg-reconfigure doesn't involve learning near as much as writing xorg.conf from scratch).

An I forgot to say that I'm using the alternate installer.

The xorg.conf I used in gutsy (and hardy when the default one failed) comes from http://michaelminn.com/linux/toshiba1800/ and is as follows:

 # xorg.conf (X.Org X Window System server configuration file)
 #
 # Custom file by Michael Minn

 Section "InputDevice"
  Identifier "Generic Keyboard"
  Driver "kbd"
  Option "XkbRules" "xorg"
  Option "XkbModel" "pc105"
  Option "XkbLayout" "us"
 EndSection

 Section "InputDevice"
  Identifier "Configured Mouse"
  Driver "mouse"
  Option "CorePointer"
  Option "Device" "/dev/input/mice"
  Option "Protocol" "ImPS/2"
 EndSection

 Section "Device"
     Identifier "Trident Microsystems CyberBlade/i1"
     Driver "trident"
     BusID "PCI:1:0:0"
     Option "NoDDC"
 EndSection

 Section "Monitor"
     Identifier "ToshLCD"
     Option "DPMS"
     HorizSync 30-71
     VertRefresh 50-100
 EndSection

 Section "Screen"
     Identifier "Default Screen"
     Monitor "ToshLCD"
     Device "Trident Microsystems CyberBlade/i1"
     DefaultDepth 16
     SubSection "Display"
         Depth 16
         Modes "1024x768"
     EndSubSection
     SubSection "Display"
         Depth 24
         Modes "1024x768"
     EndSubSection
     SubSection "Display"
         Depth 16
         Modes "800x600"
     EndSubSection
     SubSection "Display"
         Depth 24
         Modes "800x600"
     EndSubSection
 EndSection

 Section "ServerLayout"
  Identifier "Default Layout"
  Screen "Default Screen"
  InputDevice" "Configured Mouse"
 EndSection

Which I changed to :

# xorg.conf (X.Org X Window System server configuration file)
#
# Custom file by Michael Minn

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "us"
EndSection

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver "mouse"
 Option "CorePointer"
 Option "Device" "/dev/input/mice"
 Option "Protocol" "ImPS/2"
EndSection

Section "Device"
    Identifier "Trident Microsystems CyberBlade/i1"
    Driver "trident"
    BusID "PCI:1:0:0"
    Option "NoDDC"
EndSection

Section "Monitor"
    Identifier "...

Read more...

Bryce Harrington (bryce)
Changed in xserver-xorg-video-trident:
importance: Undecided → High
status: Incomplete → Triaged
Revision history for this message
Daniel Dickinson (cshore) wrote : Re: [Bug 223774] Re: [HARDY] NoDDC option doesn't work for trident cyberblade/i1 resulting in system lockup

For the record Debian Etch 'just works' with this laptop. It seems the
issue is a regression introduced by new auto-detection in (at least)
the Ubuntu version of X.Org

--
And that's my crabbing done for the day. Got it out of the way early,
now I have the rest of the afternoon to sniff fragrant tea-roses or
strangle cute bunnies or something. -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org
No more sea shells: Daniel's Weblog http://cshore.wordpress.com

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Forwarding report from Ubuntu: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-trident/+bug/223774

Sounds like trident needs autodetection added and/or needs DDC probing shut off to prevent lockups.

"it was possible get the display on a Toshiba Satellite 1800 working by editing the Device section of of /etc/X11/xorg.conf to have Option "NoDDC" "true". (vesa driver doesn't work either)

The display adaptor built into the laptop is a Trident CyberBlade/i1

It turns out that the right xorg.conf works (but not the autogenerated from Hardy, and for Gutsy it must be present before the install configures xserver-xorg or it'll hang during the configuration of that package), provided the NoDDC option is present.

http://launchpadlibrarian.net/14025687/Xorg.0.log.hardy

The xorg.conf I used in gutsy (and hardy when the default one failed) is derived one at from http://michaelminn.com/linux/toshiba1800/, the result of which looks like this:

# xorg.conf (X.Org X Window System server configuration file)
#
# Custom file by Michael Minn

Section "InputDevice"
 Identifier "Generic Keyboard"
 Driver "kbd"
 Option "XkbRules" "xorg"
 Option "XkbModel" "pc105"
 Option "XkbLayout" "us"
EndSection

Section "InputDevice"
 Identifier "Configured Mouse"
 Driver "mouse"
 Option "CorePointer"
 Option "Device" "/dev/input/mice"
 Option "Protocol" "ImPS/2"
EndSection

Section "Device"
    Identifier "Trident Microsystems CyberBlade/i1"
    Driver "trident"
    BusID "PCI:1:0:0"
    Option "NoDDC"
EndSection

Section "Monitor"
    Identifier "ToshLCD"
    Option "DPMS"
    HorizSync 30-71
    VertRefresh 50-100
EndSection

Section "Screen"
    Identifier "Default Screen"
    Monitor "ToshLCD"
    Device "Trident Microsystems CyberBlade/i1"
    DefaultDepth 24
    SubSection "Display"
        Depth 16
        Modes "1024x768" "800x600"
    EndSubSection
    SubSection "Display"
        Depth 24
        Modes "1024x768" "800x600"
    EndSubSection
EndSection

Section "ServerLayout"
 Identifier "Default Layout"
 Screen "Default Screen"
 InputDevice "Configured Mouse"
EndSection

Revision history for this message
Bryce Harrington (bryce) wrote : Re: [HARDY] NoDDC option doesn't work for trident cyberblade/i1 resulting in system lockup

I've forwarded your bug report upstream to https://bugs.freedesktop.org/show_bug.cgi?id=15937. Please subscribe to that bug in case upstream has questions or needs additional information.

Changed in xf86-video-trident:
status: Unknown → Confirmed
Revision history for this message
In , Azurit3 (azurit3) wrote :
Download full text (6.9 KiB)

Change to severity blocker, there is no known workaround and xorg/gdm don't work.

I have a laptop(Compaq 1201EA) that had XP installed until today, running with no problem.
As I'm using mainly Ubuntu 8.04 in my Desktop since it came out, and I'm enjoying it, so I decided to install it in the laptop too.
I tried to install Ubuntu 8.04 with the x86 live CD,
but found the laptop monitor will hang.

Hoping in text mode the problem didn't exist, I downloaded the x86 alternate desktop CD to install in text mode, and installed Ubuntu without any problem.
The fist time my computer was booting the newly installed Ubuntu installation, the same problem occurred. The monitor hangs while starting Ubuntu, and it doesn't react to Ctr+Alt+F1 or Ctr+Alt+Backspace

To be able to start a session without gdm to crash I disable it, by booting in safe mode and:
update-rc.d -f gdm remove

after that I installed ssh server so I could login through my Desktop:
sudo apt-get install openssh-server

In my Desktop:
ssh 192.168.1.2
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo apt-get install xresprobe
sudo apt-get install discover1
sudo apt-get install xserver-xorg-core-dbg
( tried to find xserver-xorg-video-trident-dbg but didn't found any. )
sudo update-rc.d -f gdm remove
sudo reboot

sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf_bak

sudo nano /etc/X11/xorg.conf
-----------------------
>Section "ServerFlags"
> Option "NoTrapSignals" "true"
>EndSection
-----------------------

sudo gdb /usr/bin/Xorg
(gdb) run -keeptty -dumbSched
-----------------------
Starting program: /usr/bin/Xorg -keeptty -dumbSched
[Thread debugging using libthread_db enabled]
This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.
X.Org X Server 1.4.0.90
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu9)
Current Operating System: Linux laptop 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686
Build Date: 15 April 2008 05:26:17PM
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Mon May 19 17:08:59 2008
(==) Using config file: "/etc/X11/xorg.conf"
[New Thread 0xb7c0b6b0 (LWP 5256)]
(II) Module "ramdac" already built-in
(II) Module "i2c" already built-in
(II) Module "ddc" already built-in
-----------------------

the last output was "ddc", It seems to get stuck in it
When I Ctr+C
-----------------------
Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb7c0b6b0 (LWP 5256)]
0xb7acf3a6 in mmioReadST0...

Read more...

Revision history for this message
In , Diego (panda84) wrote :
Revision history for this message
Bryce Harrington (bryce) wrote : Re: [HARDY] NoDDC option doesn't work for trident cyberblade/i1 resulting in system lockup

Don't think there's a reason to have two upstream tasks on this one.

Changed in xorg-server:
status: New → Invalid
Revision history for this message
Damian Melniczuk (quantumdamage) wrote :

I have tested Intrepid alpha 6 and still the same bug :(

Revision history for this message
Damian Melniczuk (quantumdamage) wrote :

And I have tested Intrepid beta and still the same bug :((
Now I try to install Debian Etch.

P.S. Can I somehow help to fix this bug?

Revision history for this message
Damian Melniczuk (quantumdamage) wrote :

I have tested Intrepid RC and still the same bug :((

Revision history for this message
Steve Langasek (vorlon) wrote :

I don't think it makes sense to metnion this in the intrepid release notes, given that this is not a regression from hardy.

Changed in ubuntu-release-notes:
status: New → Invalid
Revision history for this message
In , Timo Aaltonen (tjaalton) wrote :

*** This bug has been marked as a duplicate of bug 14048 ***

Revision history for this message
In , Timo Aaltonen (tjaalton) wrote :

actually, the bugs are different, and the backtrace looks different too..

Revision history for this message
Timo Aaltonen (tjaalton) wrote : Re: [HARDY] NoDDC option doesn't work for trident cyberblade/i1 resulting in system lockup

bug 181176 is the reason why people used NoDDC..

Bryce Harrington (bryce)
tags: added: hardy
Revision history for this message
Damian Melniczuk (quantumdamage) wrote :

I have tested Karmic on the same hardware and still nothing :/

Revision history for this message
Sergio Zanchetta (primes2h) wrote :

Thank you for reporting this bug to Ubuntu. Intrepid Ibex 8.10 reached EOL on 30 March 2010.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

Please feel free to report any other bugs you may find.
Thank you.

Changed in xserver-xorg-video-trident (Ubuntu Intrepid):
status: Triaged → Won't Fix
Revision history for this message
Sergio Zanchetta (primes2h) wrote :

I realized I had made a mistake, Intrepid Ibex 8.10 "will reach" EOL on 30 "APRIL" 2010.

Sorry for this.

Anyway, I think that one month doesn't make any difference now.

Changed in xf86-video-trident:
importance: Unknown → Critical
Changed in xf86-video-trident:
importance: Critical → Unknown
Changed in xf86-video-trident:
importance: Unknown → Critical
Revision history for this message
bugbot (bugbot) wrote :

This bug report was filed against an old version of Ubuntu.
Can you confirm whether this is still an issue in natty?

If you don't mind, it would be very helpful if you could update the bug
report in launchpad to 'Fix Released' if it is no longer an issue for
you, or if it is still occurring under natty, please tag the bug 'natty'
so it's easier for us to track.

Changed in xserver-xorg-video-trident (Ubuntu):
status: Triaged → New
status: New → Incomplete
Revision history for this message
Lloyd Ewing (l-ewing) wrote :

I believe this problem still exists in 10.04 Lucid. My attempts to install 10.04 appear to fail as described in this bug.

My computer is a Toshiba 7200CT, and the specs say that the video is a "Trident CyberBlade e-4 128-bit graphics accelerator". In xorg.conf it lists "BoardName Cyber 9540", which seems to be the correct driver. (The NoDCC work around does not help.)

I don't see a way to "tag the bug" to indicate that it affects Lucid. Would it improve the chances of fixing this bug it I try to install the Natty version of Ubuntu?

Changed in xserver-xorg-video-trident (Ubuntu):
status: Incomplete → Confirmed
tags: added: natty
Lloyd Ewing (l-ewing)
tags: added: lucid
removed: natty
summary: - [HARDY] NoDDC option doesn't work for trident cyberblade/i1 resulting in
+ [Hardy] NoDDC option doesn't work for trident cyberblade/i1 resulting in
system lockup
summary: - [Hardy] NoDDC option doesn't work for trident cyberblade/i1 resulting in
- system lockup
+ NoDDC option doesn't work for trident cyberblade/i1 resulting in system
+ lockup
Revision history for this message
In , G4JC (gaming4jc2) wrote :

I think the original bug report here (NoDCC causes hang) has been fixed. I am currently testing the trident driver on an ancient laptop here, and it has many bugs, but this isn't one of them. The "vesa" mode doesn't work, and most importantly auto-detection doesn't work. Manually writing your own Xorg configuration and assigning driver as "trident" however, works fine.

What you need is:
        Driver "trident"
        Option "AccelMethod" "EXA"

At that point you get the proper response from Xorg:
(WW) TRIDENT(0): Option "NoDCC" is not used

So it simply skips NoDCC in the config file and in turn skips the hang.

I will be opening another bug report regarding detection.

Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-trident/issues/6.

Changed in xf86-video-trident:
status: Confirmed → Unknown
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

this driver has been removed from Ubuntu, closing it's bugs

Changed in xserver-xorg-video-trident (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.