Bug 7358 - FireMV 2400 card second M9 not initialized
Summary: FireMV 2400 card second M9 not initialized
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: 7.6 (2010.12)
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-29 03:33 UTC by Erwin Rol
Modified: 2013-02-28 00:29 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
the patch from the bug report (1.08 KB, patch)
2006-06-29 03:37 UTC, Erwin Rol
no flags Details | Splinter Review
Xorg config file for head 1&2 (2.33 KB, text/plain)
2007-03-14 10:04 UTC, Erwin Rol
no flags Details
Xorg config file for head 3&4 (2.39 KB, text/plain)
2007-03-14 10:05 UTC, Erwin Rol
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Erwin Rol 2006-06-29 03:33:59 UTC
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),
Comment 1 Erwin Rol 2006-06-29 03:37:09 UTC
Created attachment 6072 [details] [review]
the patch from the bug report
Comment 2 Dave Airlie 2006-06-29 04:18:59 UTC
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.
Comment 3 Erwin Rol 2006-06-29 04:48:33 UTC
(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.
Comment 4 Dave Airlie 2006-06-29 04:53:16 UTC
(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 airlied@gmail.com.

> 
> > 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..



Comment 5 Erwin Rol 2006-06-30 09:01:57 UTC
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.
Comment 6 Daniel Stone 2007-02-27 01:32:42 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 7 Erwin Rol 2007-03-14 10:03:32 UTC
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.
Comment 8 Erwin Rol 2007-03-14 10:04:48 UTC
Created attachment 9141 [details]
Xorg config file for head 1&2
Comment 9 Erwin Rol 2007-03-14 10:05:15 UTC
Created attachment 9142 [details]
Xorg config file for head 3&4
Comment 10 Erwin Rol 2007-03-14 10:06:29 UTC
(In reply to comment #5)

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

Comment 11 Chris Bainbridge 2012-12-17 19:08:47 UTC
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]


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.