xserver-xorg-driver-ati

Xorg fails to start on ATI FireMV 2400 quad monitor video card

Bug #1091380 reported by Chris Bainbridge on 2012-12-17

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	xserver-xorg-driver-ati	Unknown	High	freedesktop-bugs #7358
	xserver-xorg-video-ati (Ubuntu)	Invalid	Low	Unassigned

Bug Description

Using Ubuntu Precise with all latest updates.

[with FireMV 2400 must boot kernel with "nomodeset" otherwise it will hang, bug #1091382 ]

X.Org X Server 1.11.3
Release Date: 2011-12-16
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.42-23-generic x86_64 Ubuntu
Current Operating System: Linux tove 3.2.0-34-generic #53-Ubuntu SMP Thu Nov 15 10:48:16 UTC 2012 4
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-34-generic root=UUID=8415d962-23c8-4b89-9400-e0
Build Date: 29 August 2012 12:12:33AM
xorg-server 2:1.11.4-0ubuntu10.8 (For technical support please see http://www.ubuntu.com/support)
Current version of pixman: 0.24.4
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
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: Thu Dec 6 21:16:17 2012
(==) Using config file: "/etc/X11/xorg.conf"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
(II) [KMS] drm report modesetting isn't supported.
[tcsetpgrp failed in terminal_inferior: Operation not permitted]
  XRANDR name: DVI-1
  Connector: DVI-I
  CRT1: INTERNAL_DAC1
  DFP1: INTERNAL_TMDS1
  DDC reg: 0x60
  XRANDR name: DVI-0
  Connector: DVI-I
  CRT2: INTERNAL_DAC2
  DFP2: INTERNAL_DVO1
  DDC reg: 0x64
finished output detect: 0
Unhandled monitor type 0
finished output detect: 1
finished all detect
Unhandled monitor type 0
Entering TV Save
Save TV timing tables
s

At this point the system hangs or reboots. When hung there is no response to ping so I guess the GPU has hung the kernel.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-34.53-generic 3.2.33
Uname: Linux 3.2.0-34-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 2.0.1-0ubuntu15
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,mousepoll,scale,regex,imgpng,vpswitch,workarounds,wall,compiztoolbox,resize,place,gnomecompat,session,expo,move,ezoom,unitymtgrabhandles,staticswitcher]
CompositorRunning: None
Date: Mon Dec 17 18:35:45 2012
DistroCodename: precise
DistroVariant: ubuntu
DkmsStatus:
virtualbox, 4.1.12, 3.2.0-32-generic, x86_64: installed
virtualbox, 4.1.12, 3.2.0-33-generic, x86_64: installed
virtualbox, 4.1.12, 3.2.0-34-generic, x86_64: installed
ExtraDebuggingInterest: Yes,
GraphicsCard:
Advanced Micro Devices [AMD] nee ATI ES1000 [1002:515e] (rev 02) (prog-if 00 [VGA controller])
   Subsystem: Dell PowerEdge T105 Embedded ATI ES1000 [1028:0225]
Advanced Micro Devices [AMD] nee ATI FireMV 2250 [1002:719b] (prog-if 00 [VGA controller])
   Subsystem: Advanced Micro Devices [AMD] nee ATI Device [1002:0602]
   Subsystem: Advanced Micro Devices [AMD] nee ATI Device [1002:0603]
MachineType: Dell Inc. PowerEdge T105
MarkForUpload: True
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-34-generic root=UUID=8415d962-23c8-4b89-9400-e00e4ad9a25f ro
SourcePackage: xserver-xorg-video-ati
UpgradeStatus: Upgraded to precise on 2010-10-30 (778 days ago)
XorgConf:
Section "ServerFlags"
Option "NoTrapSignals" "true"
EndSection
dmi.bios.date: 07/30/2009
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.4.4
dmi.board.name: 0RR825
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 7
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.4.4:bd07/30/2009:svnDellInc.:pnPowerEdgeT105:pvr(none):rvnDellInc.:rn0RR825:rvrA00:cvnDellInc.:ct7:cvr:
dmi.product.name: PowerEdge T105
dmi.product.version: (none)
dmi.sys.vendor: Dell Inc.
nvidia-installer.log:

version.compiz: compiz 1:0.9.7.8+bzr3121-0ubuntu1
version.ia32-libs: ia32-libs 20090808ubuntu36
version.libdrm2: libdrm2 2.4.32-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.4-0ubuntu0.2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental 8.0.4-0ubuntu0.2
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.4-0ubuntu0.2
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu10.8
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1.2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu4.2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

See original description

Tags:

Revision history for this message

In freedesktop.org Bugzilla #7358, Xorgbugs (xorgbugs) wrote on 2006-06-29:

The FireMV 2400 card is a PCI card with two Radeon M9 chips connected via a PLX
PCI-PCI bridge. The system BIOS only initializes the first M9 but the driver
needs to initialize the second M9, this worked in Xorg 7.0 but doesn't work
anymore in 7.1. The result is the second M9 is completely un initialized and
will hard hang the system as soon as someone tries to access it (like moving the
mouse from screen 2 to 3).

The cause seems that Xorg 7.1 does a better job in detecting PCI-ROMs and finds
the PCI-ROM of the second chip (that is only 2k in size and does not hold the
BIOS, but probably just the chip settings), because it finds the ROM it does not
check if it is a multi device card, and so never initializes the second M9.

The diff shows a way to work around this problem on my (and only my) system, by
checking for the PCI-ID (2:5.0) of the second M9 and skip the BIOS detection
code and directly go to the multi device detection code. With this patch my card
works correctly. Of course this is no real sollution , it jsut shows that the
card does work, and where to look for a possible real solution.

diff -ru xorg-server-1.1.0.orig/hw/xfree86/os-support/bus/Pci.c
xorg-server-1.1.0.er/hw/xfree86/os-support/bus/Pci.c
--- xorg-server-1.1.0.orig/hw/xfree86/os-support/bus/Pci.c 2006-05-19
01:51:34.000000000 +0200
+++ xorg-server-1.1.0.er/hw/xfree86/os-support/bus/Pci.c 2006-06-29
00:25:52.000000000 +0200
@@ -1305,16 +1305,21 @@
PCITAG *pTag;
int i;

- /* fall back to the old code if the OS code fails */
- if (pciOSHandleBIOS) {
- n = pciOSHandleBIOS(Tag, basereg, buf, len);
- if (n)
- return n;
- }
+ /* MEGA DIRTY FOR ME ONLY TEST HACK */
+
+ if ( !((PCI_BUS_FROM_TAG(Tag) == 2) && (PCI_DEV_FROM_TAG(Tag) == 5) &&
(PCI_FUNC_FROM_TAG(Tag) == 0))) {
+ /* fall back to the old code if the OS code fails */
+ if (pciOSHandleBIOS) {
+ n = pciOSHandleBIOS(Tag, basereg, buf, len);
+ if (n)
+ return n;
+ }

- n = handlePciBIOS( Tag, basereg, buf, len );
- if (n)
- return n;
+ n = handlePciBIOS( Tag, basereg, buf, len );
+ if (n)
+ return n;
+
+ }

num = pciTestMultiDeviceCard(PCI_BUS_FROM_TAG(Tag),
PCI_DEV_FROM_TAG(Tag),

diff -ru xorg-server-1.1.0.orig/hw/xfree86/os-support/bus/Pci.c
xorg-server-1.1.0.er/hw/xfree86/os-support/bus/Pci.c
--- xorg-server-1.1.0.orig/hw/xfree86/os-support/bus/Pci.c      2006-05-19
01:51:34.000000000 +0200
+++ xorg-server-1.1.0.er/hw/xfree86/os-support/bus/Pci.c        2006-06-29
00:25:52.000000000 +0200
@@ -1305,16 +1305,21 @@
   PCITAG *pTag;
   int i;

-  /* fall back to the old code if the OS code fails */
-  if (pciOSHandleBIOS) {
-       n = pciOSHandleBIOS(Tag, basereg, buf, len);
-       if (n)
-               return n;
-  }
+  /* MEGA DIRTY FOR ME ONLY TEST HACK */
+
+  if ( !((PCI_BUS_FROM_TAG(Tag) == 2) && (PCI_DEV_FROM_TAG(Tag) == 5) &&
(PCI_FUNC_FROM_TAG(Tag) == 0))) {
+    /* fall back to the old code if the OS code fails */
+    if (pciOSHandleBIOS) {
+       n = pciOSHandleBIOS(Tag, basereg, buf, len);
+       if (n)
+                       return n;
+    }

-  n = handlePciBIOS( Tag, basereg, buf, len );
-  if (n)
-      return n;
+    n = handlePciBIOS( Tag, basereg, buf, len );
+    if (n)
+       return n;
+
+  }

num = pciTestMultiDeviceCard(PCI_BUS_FROM_TAG(Tag),
                               PCI_DEV_FROM_TAG(Tag),

Revision history for this message

In freedesktop.org Bugzilla #7358, Xorgbugs (xorgbugs) wrote on 2006-06-29:

Created attachment 6072
the patch from the bug report

Revision history for this message

In freedesktop.org Bugzilla #7358, Airlied-freedesktop (airlied-freedesktop) wrote on 2006-06-29:

can you attach the ROM output of the second ROM?

echo 1 > /sys/path_to_rom
then cat /sys/path_to_rom > /tmp/test.bin

it should be 2K...

I'm just trying to figure out how to fix this nicely from Linux or from X.

Revision history for this message

In freedesktop.org Bugzilla #7358, Xorgbugs (xorgbugs) wrote on 2006-06-29:

(In reply to comment #2)
> can you attach the ROM output of the second ROM?
>
> echo 1 > /sys/path_to_rom
> then cat /sys/path_to_rom > /tmp/test.bin

Technically no problem, but can we go around posting ATI roms on the net without
being sued by ATI ?

> it should be 2K...

ls -l shows its full length as specified in the BAR register, but reading it
will return only 2k (which is specified in the ROM header after the AA 55).

>
> I'm just trying to figure out how to fix this nicely from Linux or from X.

Revision history for this message

In freedesktop.org Bugzilla #7358, Airlied-freedesktop (airlied-freedesktop) wrote on 2006-06-29:

(In reply to comment #3)
> (In reply to comment #2)
> > can you attach the ROM output of the second ROM?
> >
> > echo 1 > /sys/path_to_rom
> > then cat /sys/path_to_rom > /tmp/test.bin
>
> Technically no problem, but can we go around posting ATI roms on the net without
> being sued by ATI ?

okay send me a copy by direct e-mail <email address hidden>.

>
> > it should be 2K...
>
> ls -l shows its full length as specified in the BAR register, but reading it
> will return only 2k (which is specified in the ROM header after the AA 55).
>
> >
> > I'm just trying to figure out how to fix this nicely from Linux or from X.

The problem is we can't trust any length field in a ROM we always discover a ROM
that lies through its arse.. I'm wondering if some sort of listing might be
needed. I'll think about it a bit, also why the old X code works and Linux
kernel doesn't..

Revision history for this message

In freedesktop.org Bugzilla #7358, Xorgbugs (xorgbugs) wrote on 2006-06-30:

I found out another problem, I move the card to the final machine and got the
following error from handlePciBIOS(...);

"Cannot find empty range to map base to"

This was because it tried to find a 64MB range in from 0xe800_0000 -
0xe080f_ffff. This range was the range for everything but the framebuffer.

The cause was that it tried to find a place to put the BIOS but used the lenght
of BAR0 (the framebuffer of 64MB).

The reason seemed to be that in HandlePciBios() there is the following code;

Acc1 = pciReadLong(Tag, PCI_CMD_STAT_REG);
pciWriteLong(Tag, PCI_CMD_STAT_REG, (Acc1 & ~PCI_ENA));

  for (i = 0; i < num; i++) {
    Acc2 = pciReadLong(pTag[i], PCI_CMD_STAT_REG);
    pciWriteLong(pTag[i], PCI_CMD_STAT_REG, (Acc2 | PCI_ENA));

n = handlePciBIOS( pTag[i], 0, buf, len );

    pciWriteLong(pTag[i], PCI_CMD_STAT_REG, Acc2);
    if (n)
      break;
  }
  pciWriteLong(Tag, PCI_CMD_STAT_REG, Acc1);
  return n;

There you can see the handlePciBIOS is always called with 0 as the region
number, when i change this to basereg (which is passed as an argument) it works.

Also i tried to replace handlePciBIOS with pciOSHandleBIOS but that did not
work. So it seems the second chip can only be initialized by the handlePciBIOS
function.

Revision history for this message

In freedesktop.org Bugzilla #7358, Daniel Stone (daniels) wrote on 2007-02-27:

Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Revision history for this message

In freedesktop.org Bugzilla #7358, Xorgbugs (xorgbugs) wrote on 2007-03-14:

#10

Ok I got the server working with DRI but it is very tricky. I made two xorg.conf files one for head 1&2 and one for head 3&4. The one for head 1&2 is a "normal" mergedfb config, the one for head 3&4 needs the Option "BiosLocation" "primary:0xc000" else it will not work.

Now the real tricky part is that the order of starting the servers is important, first head 3&4 then head 1&2, and you have to wait with the starting of head 1&2 until you have a picture on head 3&4. I start my servers like this;

/usr/bin/Xorg :1 vt07 -noreset -br -dpms -config /etc/X11/xorg_1.conf &
sleep 10
/usr/bin/Xorg :0 vt07 -noreset -br -dpms -config /etc/X11/xorg_0.conf &

After that I get two 1600x600 3D accelerated screens on 4 monitors. If you need something like one screen you will need DMX i guess.

I will attach the config files later.

Revision history for this message

In freedesktop.org Bugzilla #7358, Xorgbugs (xorgbugs) wrote on 2007-03-14:

#11

Created attachment 9141
Xorg config file for head 1&2

Revision history for this message

In freedesktop.org Bugzilla #7358, Xorgbugs (xorgbugs) wrote on 2007-03-14:

#12

Created attachment 9142
Xorg config file for head 3&4

Revision history for this message

In freedesktop.org Bugzilla #7358, Xorgbugs (xorgbugs) wrote on 2007-03-14:

#13

(In reply to comment #5)

The patching from comment #5 is not needed in Xorg 7.2, it works with the BiosLocation option.

Revision history for this message

Chris Bainbridge (chris-bainbridge) wrote on 2012-12-17:

BootDmesg.txt Edit (57.4 KiB, text/plain; charset="utf-8")
BootLog.gz Edit (928 bytes, application/x-gzip)
CurrentDmesg.txt Edit (3.4 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (2.6 KiB, text/plain; charset="utf-8")
DpkgLog.txt Edit (50.6 KiB, text/plain; charset="utf-8")
GconfCompiz.txt Edit (36.8 KiB, text/plain; charset="utf-8")
Lspci.txt Edit (11.9 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (640 bytes, text/plain; charset="utf-8")
MonitorsUser.xml.txt Edit (2.7 KiB, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (1.5 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (295 bytes, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (1.2 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (3.9 KiB, text/plain; charset="utf-8")
UdevDb.txt Edit (116.8 KiB, text/plain; charset="utf-8")
UdevLog.txt Edit (260.3 KiB, text/plain; charset="utf-8")
UnitySupportTest.txt Edit (583 bytes, text/plain; charset="utf-8")
XorgLog.txt Edit (59.3 KiB, text/plain; charset="utf-8")
XorgLogOld.txt Edit (60.5 KiB, text/plain; charset="utf-8")
Xrandr.txt Edit (6.7 KiB, text/plain; charset="utf-8")
xdpyinfo.txt Edit (24.9 KiB, text/plain; charset="utf-8")

summary:

- Xorg fails to start on ATI FireMV 2400 card
+ Xorg fails to start on ATI FireMV 2400 quad monitor video card

Revision history for this message

Chris Bainbridge (chris-bainbridge) wrote on 2012-12-17:

Also see bug #1091382 "Kernel fail to boot with ATI FireMV 2400 quad video (modeset)"

description:

updated

Revision history for this message

In freedesktop.org Bugzilla #7358, Chris Bainbridge (chris-bainbridge) wrote on 2012-12-17:

#14

Just to note that Xorg still fails on the FireMV 2400, I filed a bug on Launchpad before discovering this bug report https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1091380

[TBH, I didn't realise this card was unsupported, or so old and rare.. I guess there is little chance of the driver being fixed now that the more popular and modern eyefinity cards support multiple monitors and with better performance]

Bug Watch Updater (bug-watch-updater) on 2012-12-17

Changed in xserver-xorg-driver-ati:
importance:	Unknown → High
status:	Unknown → Confirmed

Revision history for this message

penalvch (penalvch) wrote on 2014-01-08:

#15

Chris Bainbridge, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-video-ati REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Changed in xserver-xorg-video-ati (Ubuntu):
importance:	Undecided → Low
status:	New → Incomplete

Revision history for this message

Chris Bainbridge (chris-bainbridge) wrote on 2014-01-09:

#16

I no longer have this video card.

Revision history for this message

penalvch (penalvch) wrote on 2014-01-09:

#17

Chris Bainbridge, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1091380/comments/16 regarding you no longer have the card. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

Changed in xserver-xorg-video-ati (Ubuntu):
status:	Incomplete → Invalid

Revision history for this message

In freedesktop.org Bugzilla #7358, Martin-peres-n (martin-peres-n) wrote on 2019-11-19:

#18

-- 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-ati/issues/2.