Hi, "Richard Schwarting" <[EMAIL PROTECTED]> 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
pgpkgrv6IV96m.pgp
Description: PGP signature
_______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg