Re: hp laptop with nvidia - slow X11
Hi Alexandre, Alexandre Ratchov wrote: Sorry, I don't know. I got mine while debugging the vesa bits of a boot loader. Try increasing X log verbosity. Or possibly guess it from the output of memconfig list, it's likely to be the only variable-length entry large around 256GB-512GB, with ending address right below 4GB. the output of my memconfig list is the following: 0/1 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 1/1 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 2/1 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 3/1 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 4/1 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 5/1 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 6/1 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 7/1 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 8/4000 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 84000/4000 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 88000/4000 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 8c000/4000 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 9/4000 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 94000/4000 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 98000/4000 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active 9c000/4000 BIOS write-back fixed-base fixed-length set-by-firmware active fix-active a/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active fix-active a4000/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active fix-active a8000/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active fix-active ac000/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active fix-active b/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active fix-active b4000/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active fix-active b8000/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active fix-active bc000/4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active fix-active c/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active c1000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active c2000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active c3000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active c4000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active c5000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active c6000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active c7000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active c8000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active c9000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active ca000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active cb000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active cc000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active cd000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active ce000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active cf000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active d/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active d1000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active d2000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active d3000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active d4000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active d5000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active d6000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active d7000/1000 BIOS write-protect fixed-base fixed-length set-by-firmware active fix-active d8000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active fix-active d9000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active fix-active da000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active fix-active db000/1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active fix-active dc000/1000 BIOS write-protect fixed-base fixed-length
Re: hp laptop with nvidia - slow X11
On Wed, Jun 17, 2015 at 10:37:34PM +0200, Riccardo Mottola wrote: Hi Alexandre, Alexandre Ratchov wrote: Acceleration is not needed on modern machines to get fast 2D display. The CPU speed and memory bandwidth are largely sufficient to make desktop very responsive and watch full-screen movies. Probably what you observe is that the video memory is setup in a very restricted mode, making it extreamly slow. For instance on my system, I measured 70MB/s with BIOS settings (i.e. memory was slower than a hard disk, ridiculous), and 7500MB/s when properly initialized. This is for intel chipset, but I remember similar stories about nvidia chips. well, yes, I expect any 64bit machine to get above the 4GB/s barrier, but 70MB/s are values I used to see with 25Mhz 68K CPUs If you manage to get the address of the video frame buffer, you could try to use the memconfig(8) utility to see if write-combining is enabled for the frame buffer, and possibly enable it. This might make things less worse. I'm not sure if setting mtrrs with memconfig is still enough nowadays, maybe someone would have a better insight. shouldn't the driver take care of something like that? if you manage to get the address... how do I do that? Perhaps in the X log? Sorry, I don't know. I got mine while debugging the vesa bits of a boot loader. Try increasing X log verbosity. Or possibly guess it from the output of memconfig list, it's likely to be the only variable-length entry large around 256GB-512GB, with ending address right below 4GB. I see this: [ 359.722] (II) NV(0): Creating default Display subsection in Screen section Default Screen Section for depth/fbbpp 24/32 [ 359.722] (==) NV(0): Depth 24, (--) framebuffer bpp 32 [ 359.722] (==) NV(0): RGB weight 888 [ 359.722] (==) NV(0): Default visual is TrueColor [ 359.722] (**) NV(0): Option AccelMethod EXA [ 359.722] (==) NV(0): Using hardware cursor [ 359.722] (==) NV(0): Using gamma correction (1.0, 1.0, 1.0) [ 359.722] (II) NV(0): MMIO registers mapped at 0x6f917826000 [ 359.722] (--) NV(0): Total video RAM: 128.0 MB [ 359.722] (--) NV(0): BAR1 size: 256.0 MB [ 359.722] (--) NV(0): Mapped memory: 127.0 MB [ 359.723] (II) NV(0): Linear framebuffer mapped at 0x6f9760e1000 Could the framebuffer be the start of the memory I need? I thought something like: $ sudo memconfig set -b 0x6f9760e1000 -l 0x7f0 write-combine this is the address relative to the Xorg process virtual address space; you need the physical address.
Re: hp laptop with nvidia - slow X11
Hi Alexandre, Alexandre Ratchov wrote: Acceleration is not needed on modern machines to get fast 2D display. The CPU speed and memory bandwidth are largely sufficient to make desktop very responsive and watch full-screen movies. Probably what you observe is that the video memory is setup in a very restricted mode, making it extreamly slow. For instance on my system, I measured 70MB/s with BIOS settings (i.e. memory was slower than a hard disk, ridiculous), and 7500MB/s when properly initialized. This is for intel chipset, but I remember similar stories about nvidia chips. well, yes, I expect any 64bit machine to get above the 4GB/s barrier, but 70MB/s are values I used to see with 25Mhz 68K CPUs If you manage to get the address of the video frame buffer, you could try to use the memconfig(8) utility to see if write-combining is enabled for the frame buffer, and possibly enable it. This might make things less worse. I'm not sure if setting mtrrs with memconfig is still enough nowadays, maybe someone would have a better insight. shouldn't the driver take care of something like that? if you manage to get the address... how do I do that? Perhaps in the X log? I see this: [ 359.722] (II) NV(0): Creating default Display subsection in Screen section Default Screen Section for depth/fbbpp 24/32 [ 359.722] (==) NV(0): Depth 24, (--) framebuffer bpp 32 [ 359.722] (==) NV(0): RGB weight 888 [ 359.722] (==) NV(0): Default visual is TrueColor [ 359.722] (**) NV(0): Option AccelMethod EXA [ 359.722] (==) NV(0): Using hardware cursor [ 359.722] (==) NV(0): Using gamma correction (1.0, 1.0, 1.0) [ 359.722] (II) NV(0): MMIO registers mapped at 0x6f917826000 [ 359.722] (--) NV(0): Total video RAM: 128.0 MB [ 359.722] (--) NV(0): BAR1 size: 256.0 MB [ 359.722] (--) NV(0): Mapped memory: 127.0 MB [ 359.723] (II) NV(0): Linear framebuffer mapped at 0x6f9760e1000 Could the framebuffer be the start of the memory I need? I thought something like: $ sudo memconfig set -b 0x6f9760e1000 -l 0x7f0 write-combine (127MB*1024*1024 = 3121152 = 0x7F0 as length) memconfig: can't set range: Invalid argument The man page says it needs a power of 2, it already is, but I tried 128MB, thus 0x800, as a length, but it I still get an invalid range. where am I erring? memconfig usage or base address? Riccardo
Re: hp laptop with nvidia - slow X11
Hi Mike, Mike Small wrote: Just to be sure nv doesn't support exa with this card did you try being explicit about it? I have an NVIDIA_NVS_3100M and thought for the longest time I was in the boat of needing nouveau or changes to nv but the following xorg.conf got me past the slowness (in 5.6): Section Device Identifier NVIDIA_NVS_3100M Driver nv Option AccelMethod EXA Option MigrationHeuristic greedy EndSection it works! it is a bit faster now... still quite slow but it starts to be in the usable range... it feels like my ThinkPad 600 pentium 166Mhz with NeoMagic :) But at least I can write this mail. I see this in the Xorg log now, not very reassuring: [ 359.878] (--) Depth 24 pixmap format is 32 bpp [ 359.878] (--) NV(0): 123.04 MB available for offscreen pixmaps [ 359.899] (**) NV(0): Option MigrationHeuristic greedy [ 359.899] (II) EXA(0): Offscreen pixmap area of 133109760 bytes [ 359.899] (II) EXA(0): Driver registered support for the following operations: [ 359.899] (II) Solid [ 359.899] (II) Copy [ 359.899] (II) UploadToScreen [ 359.899] (==) NV(0): Backing store enabled [ 359.899] (==) NV(0): Silken mouse disabled [ 359.899] (II) NV(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 359.900] (==) NV(0): DPMS enabled [ 363.463] (--) RandR disabled [ 363.477] (II) AIGLX: Screen 0 is not DRI2 capable [ 363.477] (EE) AIGLX: reverting to software rendering [ 363.488] (II) AIGLX: Loaded and initialized swrast [ 363.488] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 363.489] (II) NV(0): Setting screen physical size to 338 x 211 [ 363.489] (WW) NV(0): Failed to reserve EXA memory for the screen or EXA returned an area with a nonzero offset. Don't be surprised if your screen is corrupt. Especially the last WW which is memory related. Riccardo
Re: hp laptop with nvidia - slow X11
On Mon, Jun 15, 2015 at 11:19:13PM +0200, Riccardo Mottola wrote: Hi, for the same laptop for which I just posted a full dmesg about the battery problem, which reports this video card: vga1 at pci1 dev 0 function 0 NVIDIA GeForce 8400M GS rev 0xa1 I get a super-slow X11. Dragging an xterm may take half a second, up to the point where X11 looses track of the mouse move events. Scrolling XTerm is unusably slwo too. Using a larger editor like Emacs or Firefox... even worse. It looks totally unacelercated. Should the 8400 work? IN the Xorg log I see this: [ 5902.005] (II) VESA: driver for VESA chipsets: vesa [ 5902.005] (--) NV: Found NVIDIA GeForce 8400M GS at 01@00:00:0 [ 5902.005] (WW) Falling back to old probe method for vesa [ 5902.006] (II) Loading sub module int10 [ 5902.006] (II) LoadModule: int10 [ 5902.007] (II) Loading /usr/X11R6/lib/modules/libint10.so [ 5902.017] (II) Module int10: vendor=X.Org Foundation [ 5902.017]compiled for 1.16.4, module version = 1.0.0 [ 5902.017]ABI class: X.Org Video Driver, version 18.0 [ 5902.017] (II) NV(0): Initializing int10 [ 5902.017] (II) NV(0): Primary V_BIOS segment is: 0xc000 [ 5902.018] (--) NV(0): Console is VGA mode 0x3 [ 5902.018] (II) NV(0): Creating default Display subsection in Screen section Default Screen Section for depth/fbbpp 24/32 [ 5902.018] (==) NV(0): Depth 24, (--) framebuffer bpp 32 so the nv driver loaded.. but then further below: [ 5902.185] (**) NV(0): Driver mode 1280x800: 71.0 MHz (scaled from 0.0 MHz), 49.3 kHz, 59.9 Hz [ 5902.185] (II) NV(0): Modeline 1280x800x59.9 71.00 1280 1328 1360 1440 800 803 809 823 -hsync -vsync (49.3 kHz eP) [ 5902.185] (==) NV(0): DPI set to (96, 96) [ 5902.185] (II) Loading sub module fb [ 5902.185] (II) LoadModule: fb [ 5902.185] (II) Loading /usr/X11R6/lib/modules/libfb.so [ 5902.200] (II) Module fb: vendor=X.Org Foundation [ 5902.200]compiled for 1.16.4, module version = 1.0.0 [ 5902.200]ABI class: X.Org ANSI C Emulation, version 0.4 [ 5902.200] (II) Loading sub module xaa [ 5902.200] (II) LoadModule: xaa [ 5902.208] (WW) Warning, couldn't open module xaa [ 5902.208] (II) UnloadModule: xaa [ 5902.208] (II) Unloading xaa [ 5902.208] (EE) NV: Failed to load module xaa (module does not exist, 0) [ 5902.208] (II) Loading sub module ramdac [ 5902.208] (II) LoadModule: ramdac [ 5902.208] (II) Module ramdac already built-in [ 5902.208] (II) UnloadModule: vesa [ 5902.208] (II) Unloading vesa [ 5902.208] (--) Depth 24 pixmap format is 32 bpp [ 5902.224] (--) NV(0): 120.69 MB available for offscreen pixmaps [ 5902.228] (==) NV(0): Backing store enabled [ 5902.228] (==) NV(0): Silken mouse disabled [ 5902.230] (II) NV(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 5902.237] (==) NV(0): DPMS enabled [ 5905.804] (--) RandR disabled [ 5905.856] (II) AIGLX: Screen 0 is not DRI2 capable [ 5905.856] (EE) AIGLX: reverting to software rendering [ 5906.010] (II) AIGLX: Loaded and initialized swrast [ 5906.010] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 5906.011] (II) NV(0): Setting screen physical size to 338 x 211 I suppose the reverting to software rendering is the final error and clue to the problem: no kind of acceleration at all. Acceleration is not needed on modern machines to get fast 2D display. The CPU speed and memory bandwidth are largely sufficient to make desktop very responsive and watch full-screen movies. Probably what you observe is that the video memory is setup in a very restricted mode, making it extreamly slow. For instance on my system, I measured 70MB/s with BIOS settings (i.e. memory was slower than a hard disk, ridiculous), and 7500MB/s when properly initialized. This is for intel chipset, but I remember similar stories about nvidia chips. If you manage to get the address of the video frame buffer, you could try to use the memconfig(8) utility to see if write-combining is enabled for the frame buffer, and possibly enable it. This might make things less worse. I'm not sure if setting mtrrs with memconfig is still enough nowadays, maybe someone would have a better insight.
Re: hp laptop with nvidia - slow X11
On Mon, Jun 15, 2015 at 11:19:13PM +0200, Riccardo Mottola wrote: Hi, for the same laptop for which I just posted a full dmesg about the battery problem, which reports this video card: vga1 at pci1 dev 0 function 0 NVIDIA GeForce 8400M GS rev 0xa1 I get a super-slow X11. Dragging an xterm may take half a second, up to the point where X11 looses track of the mouse move events. Scrolling XTerm is unusably slwo too. Using a larger editor like Emacs or Firefox... even worse. It looks totally unacelercated. Should the 8400 work? IN the Xorg log I see this: [ 5902.005] (II) VESA: driver for VESA chipsets: vesa [ 5902.005] (--) NV: Found NVIDIA GeForce 8400M GS at 01@00:00:0 [ 5902.005] (WW) Falling back to old probe method for vesa [ 5902.006] (II) Loading sub module int10 [ 5902.006] (II) LoadModule: int10 [ 5902.007] (II) Loading /usr/X11R6/lib/modules/libint10.so [ 5902.017] (II) Module int10: vendor=X.Org Foundation [ 5902.017]compiled for 1.16.4, module version = 1.0.0 [ 5902.017]ABI class: X.Org Video Driver, version 18.0 [ 5902.017] (II) NV(0): Initializing int10 [ 5902.017] (II) NV(0): Primary V_BIOS segment is: 0xc000 [ 5902.018] (--) NV(0): Console is VGA mode 0x3 [ 5902.018] (II) NV(0): Creating default Display subsection in Screen section Default Screen Section for depth/fbbpp 24/32 [ 5902.018] (==) NV(0): Depth 24, (--) framebuffer bpp 32 so the nv driver loaded.. but then further below: [ 5902.185] (**) NV(0): Driver mode 1280x800: 71.0 MHz (scaled from 0.0 MHz), 49.3 kHz, 59.9 Hz [ 5902.185] (II) NV(0): Modeline 1280x800x59.9 71.00 1280 1328 1360 1440 800 803 809 823 -hsync -vsync (49.3 kHz eP) [ 5902.185] (==) NV(0): DPI set to (96, 96) [ 5902.185] (II) Loading sub module fb [ 5902.185] (II) LoadModule: fb [ 5902.185] (II) Loading /usr/X11R6/lib/modules/libfb.so [ 5902.200] (II) Module fb: vendor=X.Org Foundation [ 5902.200]compiled for 1.16.4, module version = 1.0.0 [ 5902.200]ABI class: X.Org ANSI C Emulation, version 0.4 [ 5902.200] (II) Loading sub module xaa [ 5902.200] (II) LoadModule: xaa [ 5902.208] (WW) Warning, couldn't open module xaa [ 5902.208] (II) UnloadModule: xaa [ 5902.208] (II) Unloading xaa [ 5902.208] (EE) NV: Failed to load module xaa (module does not exist, 0) Read Matthieu's comment in this thread: http://comments.gmane.org/gmane.os.openbsd.misc/205381 [ 5902.208] (II) Loading sub module ramdac [ 5902.208] (II) LoadModule: ramdac [ 5902.208] (II) Module ramdac already built-in [ 5902.208] (II) UnloadModule: vesa [ 5902.208] (II) Unloading vesa [ 5902.208] (--) Depth 24 pixmap format is 32 bpp [ 5902.224] (--) NV(0): 120.69 MB available for offscreen pixmaps [ 5902.228] (==) NV(0): Backing store enabled [ 5902.228] (==) NV(0): Silken mouse disabled [ 5902.230] (II) NV(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 5902.237] (==) NV(0): DPMS enabled [ 5905.804] (--) RandR disabled [ 5905.856] (II) AIGLX: Screen 0 is not DRI2 capable [ 5905.856] (EE) AIGLX: reverting to software rendering [ 5906.010] (II) AIGLX: Loaded and initialized swrast [ 5906.010] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 5906.011] (II) NV(0): Setting screen physical size to 338 x 211 I suppose the reverting to software rendering is the final error and clue to the problem: no kind of acceleration at all. Riccardo -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: hp laptop with nvidia - slow X11
On 06/15/15 17:19, Riccardo Mottola wrote: Hi, for the same laptop for which I just posted a full dmesg about the battery problem, which reports this video card: vga1 at pci1 dev 0 function 0 NVIDIA GeForce 8400M GS rev 0xa1 I get a super-slow X11. Dragging an xterm may take half a second, up to the point where X11 looses track of the mouse move events. Scrolling XTerm is unusably slwo too. Using a larger editor like Emacs or Firefox... even worse. It looks totally unacelercated. [snip] Sadly, Nvidia video cards are to be avoided. I think it would be fair to say that Nvidia is the most open-source hostile company out there. Because of this there is no Nvidia specific driver in OpenBSD. You are using it in vga compatible mode. Things work, but hardly with the speed that it delivers on Windows. There is a reverse engineered driver called nouveau. Look at https://en.wikipedia.org/wiki/Nouveau_(software) for more info. While theoretically portable to OpenBSD, it involves work, and when I looked at it a bit it was under constant change, such that a port dated Monday might be outdated by Saturday. I have a LOT of respect for the people doing this. It's hard. I did a little hardware poking on the 286, a long time ago. It's isn't simple. I also hope it was written under a reasonable license. Once nouveau stabilizes (I have no idea of its current state), someone may get the interest to port it. Maybe. But as of right now, it ought to be avoided. --STeve Andre'
hp laptop with nvidia - slow X11
Hi, for the same laptop for which I just posted a full dmesg about the battery problem, which reports this video card: vga1 at pci1 dev 0 function 0 NVIDIA GeForce 8400M GS rev 0xa1 I get a super-slow X11. Dragging an xterm may take half a second, up to the point where X11 looses track of the mouse move events. Scrolling XTerm is unusably slwo too. Using a larger editor like Emacs or Firefox... even worse. It looks totally unacelercated. Should the 8400 work? IN the Xorg log I see this: [ 5902.005] (II) VESA: driver for VESA chipsets: vesa [ 5902.005] (--) NV: Found NVIDIA GeForce 8400M GS at 01@00:00:0 [ 5902.005] (WW) Falling back to old probe method for vesa [ 5902.006] (II) Loading sub module int10 [ 5902.006] (II) LoadModule: int10 [ 5902.007] (II) Loading /usr/X11R6/lib/modules/libint10.so [ 5902.017] (II) Module int10: vendor=X.Org Foundation [ 5902.017]compiled for 1.16.4, module version = 1.0.0 [ 5902.017]ABI class: X.Org Video Driver, version 18.0 [ 5902.017] (II) NV(0): Initializing int10 [ 5902.017] (II) NV(0): Primary V_BIOS segment is: 0xc000 [ 5902.018] (--) NV(0): Console is VGA mode 0x3 [ 5902.018] (II) NV(0): Creating default Display subsection in Screen section Default Screen Section for depth/fbbpp 24/32 [ 5902.018] (==) NV(0): Depth 24, (--) framebuffer bpp 32 so the nv driver loaded.. but then further below: [ 5902.185] (**) NV(0): Driver mode 1280x800: 71.0 MHz (scaled from 0.0 MHz), 49.3 kHz, 59.9 Hz [ 5902.185] (II) NV(0): Modeline 1280x800x59.9 71.00 1280 1328 1360 1440 800 803 809 823 -hsync -vsync (49.3 kHz eP) [ 5902.185] (==) NV(0): DPI set to (96, 96) [ 5902.185] (II) Loading sub module fb [ 5902.185] (II) LoadModule: fb [ 5902.185] (II) Loading /usr/X11R6/lib/modules/libfb.so [ 5902.200] (II) Module fb: vendor=X.Org Foundation [ 5902.200]compiled for 1.16.4, module version = 1.0.0 [ 5902.200]ABI class: X.Org ANSI C Emulation, version 0.4 [ 5902.200] (II) Loading sub module xaa [ 5902.200] (II) LoadModule: xaa [ 5902.208] (WW) Warning, couldn't open module xaa [ 5902.208] (II) UnloadModule: xaa [ 5902.208] (II) Unloading xaa [ 5902.208] (EE) NV: Failed to load module xaa (module does not exist, 0) [ 5902.208] (II) Loading sub module ramdac [ 5902.208] (II) LoadModule: ramdac [ 5902.208] (II) Module ramdac already built-in [ 5902.208] (II) UnloadModule: vesa [ 5902.208] (II) Unloading vesa [ 5902.208] (--) Depth 24 pixmap format is 32 bpp [ 5902.224] (--) NV(0): 120.69 MB available for offscreen pixmaps [ 5902.228] (==) NV(0): Backing store enabled [ 5902.228] (==) NV(0): Silken mouse disabled [ 5902.230] (II) NV(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 5902.237] (==) NV(0): DPMS enabled [ 5905.804] (--) RandR disabled [ 5905.856] (II) AIGLX: Screen 0 is not DRI2 capable [ 5905.856] (EE) AIGLX: reverting to software rendering [ 5906.010] (II) AIGLX: Loaded and initialized swrast [ 5906.010] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 5906.011] (II) NV(0): Setting screen physical size to 338 x 211 I suppose the reverting to software rendering is the final error and clue to the problem: no kind of acceleration at all. Riccardo
