search for: etracer

...> [ ?285.941944] reserve_ram_pages_type failed 0x30d2000-0x30d3000, > track 0x8, req 0x10 > [ ?341.055291] reserve_ram_pages_type failed 0x1b90b000-0x1b90c000, > track 0x8, req 0x10 > [ ?355.005349] [drm] nouveau 0000:03:00.0: nouveau_channel_free: freeing fifo 2 > [ ?355.074031] etracer used greatest stack depth: 5632 bytes left > Using a more recent nv25 classic mesa, I get no crash/bug, no validate -12, but I still get all the reserve_ram_pages_type errors. They always come up on every new level started in etracer. So the game will run at 0fps for 10-30 seconds displaying &...

...OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at lists.freedesktop.org Reporter: thor at math.tu-berlin.de QA Contact: nouveau at lists.freedesktop.org etracer does render a useful display with the nouveau xorg driver. While the title and options screen renders successful, the main game remains at a solid blue screen, or at best, colored/shaded lines drawn from the top-left of the screen. The game is not playable. The hardware is an old Geforce FX5200 ca...

Hi Marek Thanks a lot for your rebasing work. Here is my report : - all my games that broke with temporaries patch (they were either completely black or lot of black screen flash every frame) behave badly, but in different ways : * etracer is very slow and often crash in ttm code [1] (I think this is an old bug that just resurrected, no idea why) * foobillard is very slow and still flash a bit * strangely, neverball seems to work, I get similar results than with old nvfx-next-6b branch with temporaries reverted. no black flash while...

On Thu, 09 Dec 2010 11:24:19 -0600 greened at obbligato.org (David A. Greene) wrote: > greened at obbligato.org (David A. Greene) writes: > > > Often I run a few different builds in parallel, with different > > obj/build directories. Is it possible that the test infrastructure > > writes something to the source directories or some common temp > > directory? That

greened at obbligato.org (David A. Greene) writes: > Often I run a few different builds in parallel, with different obj/build > directories. Is it possible that the test infrastructure writes > something to the source directories or some common temp directory? That > could confuse things when doing parallel build/test and would explain > all these failures. When I don't run

On Thu, Dec 9, 2010 at 9:46 AM, Török Edwin <edwintorok at gmail.com> wrote: > On Thu, 09 Dec 2010 11:24:19 -0600 > greened at obbligato.org (David A. Greene) wrote: > >> greened at obbligato.org (David A. Greene) writes: >> >> > Often I run a few different builds in parallel, with different >> > obj/build directories.  Is it possible that the test

hi, I am running debian lenny standard install and dovecot also as a standard install. I have a problem with POP3 access. The error message is: May 19 09:16:10 greenchilly dovecot: chdir(/home/vmail/example.com/john) failed with uid 5000: Permission denied May 19 09:16:10 greenchilly dovecot: child 26253 (pop3) returned error 89 May 19 09:16:10 greenchilly dovecot: pop3-login: Login:

Hi everyone, I run some functions using ORC JIT, now I need to add custom instrumentation. I want to add two callbacks to each function: ‘enterFunction' at the beginning and ‘leaveFunction' at the end. Intuition says that I could ‘just' insert CallInst's to the first and the last basic blocks in the function. Am I correct? Are there any other/better way to do this? Is there

Thanks for the hint, I didn’t know about this option. That’s a great reference! However, I am trying to be a compiler/language agnostic. Also (for whatever reasons) I need a numeric ID of a function rather then its address. So the question is still opened. May I assume that the following always holds: The first basic block in a function is an entry point and the last basic block in a function is

I've been noticing for a while that i've been getting general protection faults in ttm_to_swapout, this time i was printk'ing the virtual addresses. In case it's not obvious, the result of kmap_atomic() is wrong. This is nouveau/linux-2.6 which is somewhere after 2.6.32. I was wondering if anyone has ever seen anything like this? from_virtual ffff88003088b000 to_virtual

...wine "C:\Program Files\Guild Wars\Gw.exe" WINEDEBUG=-all will stop the flood of fixme messages generated from normal use. If you require debugging, omit this option. Troubleshooting: * Make sure 3D works in native applications before blaming Wine. Try glxgears, or a 3D game such as etracer or supertuxkart. DONE * Use the latest version of Wine, at least 1.0. Type 'wine --version' to check. YES * Try different versions of Windows in winecfg, such as Windows XP and 98. XP, 2000, 98 all same * Under the winecfg Graphics tab, try experimenting with the window settings...

Török Edwin <edwintorok at gmail.com> writes: >> > Which regression tests are failing with LLVM 2.8 and GCC 4.4.x? >> >> Too many to list. > > Can you give me 2 or 3 examples (that fail with LLVM 2.8 and GCC 4.4 > but work with LLVM 2.8 and GCC 4.3), also I'd like to know how they > fail. > If I have some time I'll check with my 4.4 to see if

On 3/22/23 15:45, Laszlo Ersek wrote: > On 3/21/23 18:28, Eric Blake wrote: > >> it is indeed a bug in busybox now that POSIX is moving towards >> standardizing realpath, so I've filed it: >> https://bugs.busybox.net/show_bug.cgi?id=15466 > > I've found another busybox bug. > > The "/bin/sh" utility is provided by busybox as well (via the

Hi, i'm trying to use Call of duty 4 on ubuntu 8.1 x64, i've installed wine using the deb repositories, so i've the 1.1.10 version.. When i'm in the call of duty 4 dir i type # aoss env WINEDEBUG=-all wine-pthread iw3mp.exe and this is the output: Code: ERROR: ld.so: object '/usr/$LIB/libaoss.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object

Jason Kim <jasonwkim at google.com> writes: >>> There is definitely something to this.  If I take a random failing >>> testcase and run the test in isolation in the shell, it works.  So >>> what, if anything, does lit/FileCheck/etc. do that might run >>> interference if there is another copy of lit/FileCheck/etc. running >>> at the same time? I

Before we get too far into this, I'd like to point out that there's a ready solution for the problem of the AsmPrinter being slow: Bitcode. If you want IR reading and writing to be fast, you should consider bitcode files rather than assembly (text) files anyway. Bitcode is smaller and faster. And the API is similar, so it's usually easy to change from assembly to bitcode.

Albert Graef wrote: > One thing I noticed is that writing LLVM assembler code (print() > methods) seems to be horribly slow now (some 4-5 times slower than in > LLVM 2.5). This is a real bummer for me, since Pure's batch compiler > uses those methods to produce output code which then gets fed into llvmc. Let me follow up with some concrete figures. Unfortunately, I don't have

This patch series silences some unknown cap warnings and fixes up coding style (patch 1+4). The most important part of this series are the two patches in the middle. They rework the state_fb code, so that we are able to render to not 64 byte aligned targets, as this is the only real use-case for render temporaries this allows us to drop temp code completely and simplifies a lot

For a long time the gallium pipe drivers for nvidia fixed function cards (nv0x, nv1x and, to some extent, nv2x) have remained unmaintained and godforsaken -- especially nv0x and nv1x had seen almost no progress since their creation. They've recently grown a classic mesa driver which implements many new features: texturing, hardware-accelerated tnl. However the killer feature is "it

Jeffrey Yasskin wrote: > See Owen's email about docs for the 2.6 release, but it's really not > that hard to keep up with trunk. I recently merged trunk LLVM into > Unladen Swallow, and the changes I needed to make are at > http://code.google.com/p/unladen-swallow/source/detail?r=724. Thanks Jeffrey, that was really very helpful! I have Pure working with both the LLVM 2.6