Kernel Bug Tracker – Bug 4965
Dual-head not working correctly with Matrox g550 in 2.6.13-rc
Last modified: 2005-08-29 03:43:13 UTC
AMD Sempron 2800+, Matrox G550
X related packages are version 6.8.2.dfsg.1-4
I have a dual-head setup with two monitors using Matrox G550. The primary
monitor is using 1400x1050 resolution and the secondary is to the right of the
primary with 1024x768 resolution. With 2.6.13-rc1 (and 188.8.131.52) the system
works fine. With 2.6.13-rc3 and -rc4 only the primary monitor is active, and it
functions as the secondary monitor (with 1024x768 resolution and mouse cursor
has to be moved to the right from the initial position to "get there").
Initially I thought that the problem was caused by the new Xorg packages in
Debian unstable because I could not fathom how the kernel could have anything to
do with such a problem. But then I tried the same X setup with another kernel
versions and the setup works consistently with 2.6.13-rc1 and always fails with
2.6.13-rc3 and -rc4 (-rc2 failed to compile).
If I modify xorg.conf to use only the primary monitor, then it works correctly
Steps to reproduce:
Boot with 2.6.13-rc, run startx and only the primary monitor gets an image,
and that is the image that should be on the secondary monitor.
Please attach the output of "dmesg -s 1000000" of both the -rc1 and the -rc3 kernel.
Is the problem still present in 2.6.13-rc3-mm3?
This problem has actually been around for at least a year.
Fedora users saw this as soon as we cut over to Xorg too, so it's interesting
that you now see it now that Debian has also moved away from XFree86.
There's an Xorg bug open on this. See
I'm unconvinced that this is a kernel bug.
But Dave, Jarmo says that 2.6.13-rc1 works OK and 2.6.13-rc3
Is there anything interesting in the X logs? (/var/log/XFree86.0.log
on my old machine)
diddling with card registers means we don't get the same state across reboots,
so it might just be working purely by chance.
Either that, or its a seperate bug to the one I'm thinking of.
Is it repeatably working ok on -rc1 ? Even from a cold power-on ?
I tried cold-booting with both rc1 and rc3, and the results were the same as
before: dual-head works ok with rc1 and fails (as previosly described) with rc3.
So far the same has happened with every reboot, cold or warm, so at least the
bug seems to occur only with rc3 whether it is an actual kernel bug or a bug in
/var/log/Xorg.0.log had one obvious difference between rc1 and rc3. Line "(II)
Truncating PCI BIOS Length to 36864" appears only when booted with rc3 (after
line "MGA(0): BIOS at 0xE7020000", and the same for the the second head MGA(1)).
BTW I was using xorg from ubuntu before upgrading to the Debian version and I
never saw the same problem. The last kernel I used with Ubuntu xorg was 184.108.40.206.
I can try 2.6.13-rc3-mm3 or any other kernel version in Monday if it necessary.
Created attachment 5420 [details]
dmesg -s 100000 from 2.6.13-rc1
Created attachment 5421 [details]
dmesg -s 100000 from 2.6.13-rc3
Not that there seems to be anything interesting differences between rc1 and
any changes in that area to mmap or /dev/mem?
It's not anything in the graphics drivers or AGP drivers, the problem is that
the MGA gets some information from the BIOS.. but the truncation stuff is
causing it to be unable to read that flag....
I just tried 2.6.13-rc5 and 2.6.13-rc4-mm1, and dual-head is not working
correctly with either of them, wherever the real problem is. If there is
anything I can do to pinpoint/fix the problem, leave a comment...
can you do as root with -rc1 and -rc3
lspci -v -s 3:0.0
and maybe lspci -v -H1 -s 3:0.0 and see if there are any differences in what it
*** Bug 4971 has been marked as a duplicate of this bug. ***
lspci -v -s 3:0.0 gives the following with -rc3:
0000:03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev
01) (prog-if 00 [VGA])
Subsystem: Matrox Graphics, Inc. Millennium G550 Dual Head DDR 32Mb
Flags: bus master, medium devsel, latency 32, IRQ 11
Memory at e4000000 (32-bit, prefetchable) [size=32M]
Memory at e7000000 (32-bit, non-prefetchable) [size=16K]
Memory at e8000000 (32-bit, non-prefetchable) [size=8M]
Expansion ROM at e7020000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Capabilities: [f0] AGP version 2.0
The output is identical to -rc1 except for line "Expansion ROM at e7020000
[disabled] [size=128K]", which does not exist with -rc1.
With lspci -v -H1 -s 3:0.0 both -rc1 and -rc3 give exactly the same output.
my guess is the PCI assigning resources is now putting the ROM somewhere and
pissing off X .... X is probably doing something broken but I'd hate to have to
try and fix it all ..
Greg any ideas? perhaps we can not assigned addresses for VGA Expansion ROMs...
This patch might have caused it:
Could you try reverting it (apply it with the -R option to patch) and see
if that solves this issue?
The mentioned patch is apparently not yet in -rc3, only in -rc5 (and -rc4-mm1).
According to log it was applied 7 days ago to Linus' tree. Anyway, reverting the
patch from -rc4-mm1 or -rc5 does not change anything.
how about reverting
I'd love to know what X is doing so badly.. maybe before the ROM wasn't showing
up and the code works but now it is and the X code breaks.. bad X..
Reverting that patch ([PATCH] PCI: pci_assign_unassigned_resources() on x86)
helped, now dualhead works ok with -rc3. lspci -v -s 3:0.0 also gives identical
output as -rc1, no "Expansion ROM at e7020000 [disabled] [size=128K]" line anymore.
ah nuts.. I thought that might be it .. there is a bug in the Xorg BIOS handling
by the looks of it.. it shouldn't matter to Xorg if the kernel assigns the BIOS
or not .. I'll see if I can track down what might be happening..
Greg any ideas on this? an X.org fix will take a while to propogate and it would
be nice not to break working dualhead..
Considering Linus' comments about 2.6.13 I was quite surprised that dual-head is
actually working with it. Then again, X related packages have been updated
in Debian unstable to version 6.8.2.dfsg.1-5, though there did not seem to be
any relevant (mga or pci/bios) changes reported. The "Expansion ROM at e7020000
[disabled] [size=128K]" line is still in lspci output, but there are no
"Truncating PCI BIOS Length to 36864" lines in Xorg.0.log anymore.
I will close this bug now that dual-head works fine with kernel 2.6.13 and X
6.8.2.dfsg.1-5. I'll mark the resolution to CODE_FIX though maybe the actual fix
is in Xorg.