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

[Richard Schwarting]

Hello.

I'm not sure if that changed anything, but things sort of work.

After patching, recompiling, and reinstalling the driver, X would
still be off centre.

However, I restarted the computer the first time I ran X, everything
appeared as I would hope.   I then brought it down and back up again,
but it was out of centre again.  Restarting it a dozen times didn't
help.

However, I tried putting my computer to sleep and waking it up, and,
as with a fresh restart, X displayed correctly again.  However, simply
switching VTs to a console and back to X make it off again.

I've updated the bug[1] with the log file with SMI_DEBUG defined and
from a session of (after resuming from suspend): X working, switching
to a console, switching back to not having it work.

Would it be worthwhile to have me try the driver without the patch
again and see whether I can make it work after suspend/resume or a
power cycle?

Thanks again Francisco.
  Richard

1. https://bugs.freedesktop.org/show_bug.cgi?id=18816

On Tue, Dec 2, 2008 at 15:32, Francisco Jerez <currojerez at gmail.com> wrote:
>> 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.
>>
> Hi, I think I have reproduced your problem, maybe the offset display is
> because screen centering is active on server start up.
>
> If so, the patch I'm attaching will probably solve it.
>
> BTW, I wonder if the UseBIOS option should default to off, with all
> these laptops with broken bioses.
>
>> 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
>>>
>> _______________________________________________
>> xorg mailing list
>> xorg at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xorg
>
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>