Re: Fwd: X.org PCI changes breaks support for Silicon Motion SM720 Lynx3DM card?
Right. So, VT switching does work before suspend. On Fri, Dec 12, 2008 at 11:51, Francisco Jerez curroje...@gmail.com wrote: Richard Schwarting aquari...@gmail.com writes: Hey. The patches cured XAA slowness for me and obviate the need for the UseBIOS NO option for both EXA and XAA for me. Hurrah. I mentioned before that after suspending in Fedora, resuming gives me a blank screen. If I do any VT switches, than light streaks start forming starting from the top and bottom edge and bleeding across vertically across the screen. This is with XAA acceleration, but it happens with EXA as well. When I had a working Ubuntu installation last week, I was able to suspend and restore freely. Is this likely a Fedora issue and not the driver/X? Hi, I've got some questions: Does VT switching work before suspending? You may still need to specify the UseBIOS off option for it to work. VT switching works without UseBIOS (at least as of patch 0005). Also, are you suspending to disk or ram? Does it restore the video state properly if you suspend on the terminal, with no X server started? Are you using a frontend like the hibernate script for suspending? Is it trying to restore the video state with something like vbetool? (If not, you might want to give it a try) Suspending without X has the same effect as suspending with X. A blank screen that slowly bleeds white across it. vbetool doesn't seem to help. I will investigate this issue more outside of X. Do you still need anything re: the silicon motion driver? I don't suffer corruption under EXA or XAA and until I have suspend and resume sorted out, I don't think there are any more issues on my system. Thank you! Richard Schwarting ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fwd: X.org PCI changes breaks support for Silicon Motion SM720 Lynx3DM card?
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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: Fwd: X.org PCI changes breaks support for Silicon Motion SM720 Lynx3DM card?
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 On Thu, Dec 4, 2008 at 06:51, Francisco Jerez [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: 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
Re: Fwd: X.org PCI changes breaks support for Silicon Motion SM720 Lynx3DM card?
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. 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 [EMAIL PROTECTED] wrote: 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 = 0x1420, size = 0x0080, type = 1) Invalid argument (22) error setting MTRR (base = 0x1420, size = 0x0080, type = 1) Invalid argument (22) error setting MTRR (base = 0x1420, size = 0x0080, 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Fwd: X.org PCI changes breaks support for Silicon Motion SM720 Lynx3DM card?
Hello. I have a Silicon Motion SM720 Lynx3DM card which X in Ubuntu 8.10 (and Fedora 9) will not start on. The log seems fine but ends with: AddScreen/ScreenInit failed for driver 0 The issue it experience seems to have been introduced by changes to X to use libpciaccess. Using GDB, and modified source littered with print statements, I see that it is failing like so: Xorg's dix/main.c's main() calls AddScreen(), which calls (*pfnInit)(...) pfnInit points to Silicon Motion's smi_driver.c's SMI_ScreenInit. SMI_ScreenInit calls SMI_MapMem(). SMI_MapMem calls libpciaccess's common_interface.c's pci_device_map_range(). It finds that the range that wants mapping is already mapped, and everything falls apart. The only other time pci_device_map_range() is called (and indeed for the same region) is earlier when dix.main.c's main() calls InitOutput(), InitOutput() called xf86Screen[0]-PreInit(...). PreInit pointed to Silicon Motion's smi_driver.c's SMI_PreInit() and SMI_PreInit calls SMI_MapMem (which maps the same region as later via pci_device_map_range()). So, I'm going to try and find out what the correct behaviour should be to fix it, but any hints would be gratefully appreciated. I've filed bug #18816 (https://bugs.freedesktop.org/show_bug.cgi?id=18816) with regard to this. Cheers, Richard Schwarting. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
