| Summary: | FireMV 2400 card second M9 not initialized | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Erwin Rol <xorgbugs> | ||||||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||||||
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||
| Severity: | major | ||||||||||
| Priority: | high | CC: | airlied, alexdeucher, chris.bainbridge | ||||||||
| Version: | 7.6 (2010.12) | ||||||||||
| Hardware: | x86 (IA32) | ||||||||||
| OS: | Linux (All) | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 6072 [details] [review] the patch from the bug report 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. (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. (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.. 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.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future. 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. Created attachment 9141 [details]
Xorg config file for head 1&2
Created attachment 9142 [details]
Xorg config file for head 3&4
(In reply to comment #5) The patching from comment #5 is not needed in Xorg 7.2, it works with the BiosLocation option. 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] -- 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. |
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.
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),