Bug 4965

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
https://bugs.freedesktop.org/show_bug.cgi?id=615

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

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

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

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

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
tells you?

*** 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:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=10f4338ca8534823bc6c843edbbe42fd4e73d258

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

http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=299de0343c7d18448a69c635378342e9214b14af;hp=90b54929b626c80056262d9d99b3f48522e404d0

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.