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

Richard Schwarting aquarichy at gmail.com
Wed Dec 10 23:08:06 PST 2008 

Hello again.

I am a goat and in an effort to verify that the XAA and EXA
performance difference was or wasn't just a Ubuntu issue, I tried
installing Fedora 10.  Yada yada, Ubuntu got clobbered, Fedora has
broken dbus and .gstreamer-0.10 permissions, etc.

However!  I did salvage two Xorg.0.log's from my backup of my Ubuntu
installation:
one for EXA with SMI_DEBUG on, and one for XAA (sadly) without SMI_DEBUG.

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

I observe the same effect under Fedora 10, and will try to provide
more recent logs with -logverbose 7, with and without debugging, if
that all will help.

I'll note that Fedora 10 has a few separate issues:
* when it comes out of sleep, it is remains black with some colour at
the top and bottom that slowly bleeds across the screen.
* the X server (or is it GDM?) will often crash when VT switching.  I
observed this under Ubuntu 8.04 but never reported it.

Anyway, would you like me to continue reporting issues in here?  I'm
comfortable doing as much investigation as helps.

Cheers,
  Richard



2008/12/6 Francisco Jerez <currojerez at gmail.com>:
>> Yes Francisco.  This has fixed the issue of being off-centre and such.
>>
>> I'll note that, though X displayed correctly, while using it, new
>> windows would come up simply as white boxes for the first few seconds,
>> I'm not sure to.  As well, when I did open a window or a menu or such,
>> the entire desktop would freeze up for a few seconds, my cursor not
>> even moving and not responding to Ctrl-Alt-Fn.  After those few
>> seconds, things would proceed.
>>
>> I tried disabling acceleration by setting Option "NoAccel".  Now, my
>> desktop stopped freezing completely, but things still took an unusual
>> long time to start drawing, and the desktop felt sluggish.  Reading
>> the man page for siliconmotion, I opted to try Option "AccelMethod"
>> "EXA", and now things are mostly better.  Using EXA, there is the odd
>> glitch when the cursor hovers over a point (a rectangle around it
>> becomes a green color, for some inexplicable reason).
>>
>> Anyway, I'm interested in getting this fixed downstream before the
>> next set of distro releases so that others who suffer the same problem
>> won't need to wait 5 months :)  What more can I do in regard to this?
>> Just created distro-level bug reports and point them to this thread?
>>
>> Also, I'm curious whether you have a SM720 Lynx3DM handy yourself or
>> whether you have to do your work via another SM card.  Are they
>> similar enough that driver changes don't usually break support for
>> just one of the card types?  In the future, if there are any changes
>> you'd be interested to see tested on an Sm720 Lynx3DM, I'd be happy to
>> help (presuming this tablet hasn't fallen apart first.).  I'd make a
>> piont of testing newer versions of the driver periodically to help
>> catch issues with this card earlier.  Though, I wonder whether I'm the
>> only person still using Linux on one :)
>>
>> Thank you very much.  I hope to repay your helpfulness some day, as
>> you've really made my life a lot easier :)
>>
>> Cheers,
>>   Richard Schwarting
>>
>>
> In fact, the only Silicon Motion hardware I've got access to is another
> SM720 card. I'm not experiencing those problems on it. Would you send a
> full log? (BTW, could it be related to the great amount of logging that
> the SMI_DEBUG flag provokes?).
>
>> On Thu, Dec 4, 2008 at 06:51, Francisco Jerez <currojerez at gmail.com> wrote:
>>>> 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
>>>
>>> _______________________________________________
>>> 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
>

More information about the xorg mailing list