Fwd: X.org PCI changes breaks support for Silicon Motion SM720 Lynx3DM card?

[Richard Schwarting]

Thank you, again.

Yes, the MTRR errors do not appear to be fatal.

Option "UseBIOS" "off" makes a big difference.  The screen is no
longer just black, and I can see a background and the moving cursor!
However, it is as though the hsync and vsync are terribly off- as the
display is quite a bit off-centre, wraps around the screen, is
sometimes repeated along the horizontal, and has visible moving scan
lines.

I have uploaded a copy of my Xorg.0.log using the "UseBIOS" "off" and
using -logverbose 7 to the bug:
https://bugs.freedesktop.org/show_bug.cgi?id=18816

I will replace it with one with SMI_DEBUG defined this afternoon (I
didn't have time this morning :D).

I will also try different combinations of modes and v/hsync, though
I'm wondering whether the offset weird display is actually caused by
incorrectly set values for them, as I've tried rates that had worked
previously.

Cheers,
  Richard Schwarting

On Tue, Dec 2, 2008 at 04:48, Francisco Jerez <currojerez at gmail.com> wrote:
> Hi,
>
> "Richard Schwarting" <aquarichy at gmail.com> writes:
>
>> Thanks for the responses.
>>
>> == Silicon Motion from git ==
>>
>> Yes Francisco, I've tried the latest code from
>> git://anongit.freedesktop.org/xorg/driver/xf86-video-siliconmotion and
>> that led to what I thought was the same error, since I was still left
>> with a blank screen, but now I see that it is differently.
>>
>> Having just recompiled that driver, I get the following when running:
>> (==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec  2 00:24:54 2008
>> (==) Using config file: "/etc/X11/xorg.conf"
>> error setting MTRR (base = 0x14200000, size = 0x00800000, type = 1)
>> Invalid argument (22)
>> error setting MTRR (base = 0x14200000, size = 0x00800000, type = 1)
>> Invalid argument (22)
>> error setting MTRR (base = 0x14200000, size = 0x00800000, type = 1)
>> Invalid argument (22)
>>
> That happened because the SM720 framebuffer aperture is misaligned, I
> think the old pci layer code handled that automatically and split the
> memory range across several MTRRs.
>
> That error is worrisome, but it shouldn't be fatal. I think I'll have
> a look at it soon.
>
>> Of course, I should perhaps try the recent git silicon motion driver
>> with the current Xorg server in git, so I'm leaving that to set up
>> overnight.
>>
>> note: The vesa driver doesn't work with this card for me either right now.
>>
>> == MTRR error context ==
>>
>> For some added context, that error "error setting MTRR" appears to
>> come from the function "pci_device_linux_sysfs_map_range(...)" from
>> libpciaccess's linux_sysfs.c which appears to get called as a method
>> "map_range" of a structure of struct pci_system_methods
>> linux_sysfs_methods.
>>
>> I think this would be the map_range that's being called in
>> libpciaccess's pci_device_map_range in the lines:
>> err = (*pci_sys->methods->map_range)(dev,
>>                                              &mappings[devp->num_mappings]);
>> I'll try to verify that tomorrow.
>>
>> == Xorg.0.log ==
>>
>> For the Xorg.0.log from a run with the Xorg server packaged in Ubuntu
>> 8.10 and the current Silicon Motion driver from git, I've attached it
>> to:
>> https://bugs.freedesktop.org/attachment.cgi?bugid=18816
>>
>
> I had a look at it, and I suspect that you could get it working
> again by using Option "UseBIOS" "off" (or maybe Option "NoAccel") in
> the device config file section, but I don't exactly know what is going
> on. Could you send a more verbose log, e.g. with the "-logverbose 7"
> server option, and maybe rebuild the driver with "-DSMI_DEBUG" among
> the CFLAGS?
>
>> == Random Thoughts ==
>>
>> Since I think this is the same issue I encountered with Fedora 9 at
>> the start of the summer, I'm wondering whether I'm the only Linux user
>> left using this particular card or whether the others are just
>> avoiding the current X (or whether my system is in a faulty
>> configuration) :D
>