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

Francisco Jerez currojerez at gmail.com
Tue Dec 2 04:48:52 PST 2008


"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

> == 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
-------------- 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/20081202/b6215bad/attachment.pgp>

More information about the xorg mailing list