On Fri, Dec 11, 2009 at 1:30 PM, Ben Skeggs <skeggsb at gmail.com> wrote:> On Fri, 2009-12-11 at 13:23 +0100, Anders Eriksson wrote: >> skeggsb at gmail.com said: >> > It'd be useful to know of any cases out there where UMS is being used because >> > KMS is failing, there's a couple of cases on RH bugzilla, but I don't recall >> > the details right now. >> >> Try this one. >> >> https://bugs.freedesktop.org/show_bug.cgi?id=24810 >> >> It used to work, but something changed which forced me back to UMS. > It's not a solution by any means, but try: > > ?Option "EXAPixmaps" "false" > > In your xorg.conf. ?There'll be more work done to help the situation on > low-mem cards. >Ah that is interesting, so this can workaround the problem on my nv25 that cannot render too big pictures in firefox. (my test case is a single picture : 3782x2592 resized to 550x368) So about that, I must mention the different behavior I got, in chronological order : 1) old ddx (10/01) : X instant crash 2) newer ddx, after all the "handle reloc failures" patches : picture is not displayed, just a black area instead. *much* better :) 3) after upgrading kernel/drm from 12/08 - 2.6.32-rc6 to 12/11 - 2.6.32 : X locks up. I don't even see the usual message in dmesg ([TTM] Out of aperture space or DRM memory quota.) The gpu or at least nouveau drm is in a bad state and I must reboot to cover. Any clues about that last behavior ? I am not sure how practical/possible regression testing will be since it seems to have been caused by the last merge. I will open a bug report thats better. Finally I am curious about what work will be done to help :) If I got it right (and I probably did not) : exapixmaps true -> always use videoram for pixmaps exapixmaps false -> never use videoram for pixmaps And so the solution would be something in between, like dynamically choose whether to use vram or not, depending on the pixmap size and the free vram ? And how hard is that ?
On Fri, Dec 11, 2009 at 8:11 PM, Xavier <shiningxc at gmail.com> wrote:> On Fri, Dec 11, 2009 at 1:30 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On Fri, 2009-12-11 at 13:23 +0100, Anders Eriksson wrote: >>> skeggsb at gmail.com said: >>> > It'd be useful to know of any cases out there where UMS is being used because >>> > KMS is failing, there's a couple of cases on RH bugzilla, but I don't recall >>> > the details right now. >>> >>> Try this one. >>> >>> https://bugs.freedesktop.org/show_bug.cgi?id=24810 >>> >>> It used to work, but something changed which forced me back to UMS. >> It's not a solution by any means, but try: >> >> ?Option "EXAPixmaps" "false" >> >> In your xorg.conf. ?There'll be more work done to help the situation on >> low-mem cards. >> > > Ah that is interesting, so this can workaround the problem on my nv25 > that cannot render too big pictures in firefox. (my test case is a > single picture : 3782x2592 resized to 550x368) > > So about that, I must mention the different behavior I got, in > chronological order : > 1) old ddx (10/01) : X instant crash > 2) newer ddx, after all the "handle reloc failures" patches : picture > is not displayed, just a black area instead. *much* better :) > 3) after upgrading kernel/drm from 12/08 - 2.6.32-rc6 to 12/11 - > 2.6.32 : X locks up. > I don't even see the usual message in dmesg ([TTM] Out of aperture > space or DRM memory quota.) > The gpu or at least nouveau drm is in a bad state and I must reboot to cover. > > Any clues about that last behavior ? I am not sure how > practical/possible regression testing will be since it seems to have > been caused by the last merge. I will open a bug report thats better. > > Finally I am curious about what work will be done to help :) > If I got it right (and I probably did not) : > exapixmaps true -> always use videoram for pixmaps > exapixmaps false -> never use videoram for pixmapsIt switches between a classic exa implementation which is used to working with a fixed amount of vram, but will never cooperate with dri2. The default is a "mixed" exa implementation that does work with dri2. Both are accelerated for 2d purposes.> And so the solution would be something in between, like dynamically > choose whether to use vram or not, depending on the pixmap size and > the free vram ? > And how hard is that ? > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau >
On Sun, Dec 13, 2009 at 9:35 PM, Xavier <shiningxc at gmail.com> wrote:> On Sat, Dec 12, 2009 at 10:50 PM, Maarten Maathuis <madman2003 at gmail.com> wrote: >> >> Can you retry with the latest ddx? >> >> Maarten. >> > > Awesome, it works, thanks ! :) >I did not update that box for 3 weeks. I just did today (drm+ddx), and it has regressed. X lockup is back, but it does not seem to be as bad as before : alt+sysrq+k kills X, then it gets restarted (probably by gdm) and everything is fine again. Still 5 minutes of firefox browsing causing X lockups is not cool :) I will do some bisection tomorrow, I guess I will start with ddx.
On Fri, 2010-01-08 at 00:51 +0100, Xavier wrote:> On Sun, Dec 13, 2009 at 9:35 PM, Xavier <shiningxc at gmail.com> wrote: > > On Sat, Dec 12, 2009 at 10:50 PM, Maarten Maathuis <madman2003 at gmail.com> wrote: > >> > >> Can you retry with the latest ddx? > >> > >> Maarten. > >> > > > > Awesome, it works, thanks ! :) > > > > I did not update that box for 3 weeks. I just did today (drm+ddx), and > it has regressed.Can you update your libdrm too please, the fix was moved to there and reverted in the DDX. Thanks, Ben.> X lockup is back, but it does not seem to be as bad as before : > alt+sysrq+k kills X, then it gets restarted (probably by gdm) and > everything is fine again. > Still 5 minutes of firefox browsing causing X lockups is not cool :) > > I will do some bisection tomorrow, I guess I will start with ddx. > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau
On Fri, Jan 8, 2010 at 1:14 AM, Ben Skeggs <skeggsb at gmail.com> wrote:> On Fri, 2010-01-08 at 00:51 +0100, Xavier wrote: >> On Sun, Dec 13, 2009 at 9:35 PM, Xavier <shiningxc at gmail.com> wrote: >> > On Sat, Dec 12, 2009 at 10:50 PM, Maarten Maathuis <madman2003 at gmail.com> wrote: >> >> >> >> Can you retry with the latest ddx? >> >> >> >> Maarten. >> >> >> > >> > Awesome, it works, thanks ! :) >> > >> >> I did not update that box for 3 weeks. I just did today (drm+ddx), and >> it has regressed. > Can you update your libdrm too please, the fix was moved to there and > reverted in the DDX. >Strange, I am 99% sure I did update libdrm , and before updating ddx. I will double-check tomorrow. And I indeed found this commit : http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=bb1947831d9a4e080b8d1e9dba086af6527ef479 So I assume the libdrm one is this one on the same day : http://cgit.freedesktop.org/mesa/drm/commit/?id=f1660c249198b5cc14ebbb75107da7bcb6972033 So by playing with these two commits, I should also be able to provide more information. Thanks !
Seemingly Similar Threads
- [Bug 23847] New: kernel BUG when using nouveau
- [Bug 27603] New: Celestia 1.6.0 crashes with nv04_surface_copy_swizzle assertion
- reserve_ram_pages_type failed
- [Bug 20612] New: nouveau xv crash with BadMatch ( invalid parameter attributes)
- preliminary nv50 wfb patch