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

Thu Dec 4 06:51:37 PST 2008

"Richard Schwarting" <aquarichy at gmail.com> writes:

> 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
>
Hello again,

I've done some corrections to the mode setting code (I'm attaching the
patch). Could you try it out over the last one and tell me if it works?

> 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
>>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Some-corrections-on-the-Lynx-modesetting-code.patch
Type: text/x-patch
Size: 4142 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20081204/76bda352/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20081204/76bda352/attachment.pgp>