On Thu Feb 3 17:30:06 CST 2005, Ampere K. Hardraade wrote: > On February 1, 2005 03:36 pm, Dean Williams wrote: >> The installaton at "0x0938b08b" reference memory at "0x0b41d2ff". The> >> memory could not be written!.......................whatever that >> means.Perhaps this is an out of memory error? > > I have a similar problem in Linux a few weeks ago: > http://mail.flightgear.org/pipermail/flightgear-devel/2005-January/034368.html > > If these are indeed related, that means we can duplicate the error in Linux > and find out the exact cause of the problems. > >
I don't know if anything more has been done on this (I don't see anything in the archive), but I can reproduce something very much like this on linux. Equipment: Stock Fedora Core 2. "2100+MHz" Athlon processor. At least 256Mb RAM (might be 512Mb - I'll check) at 266MHz Matrox G200 AGP video card supposedly with 3D acceleration working. Standard 0.9.8 Flightgear plus scenery for Western Europe area. If I just type "fgfs" or "fgfs --disable-sound", all I get is the splash screen and plenty of disk-grinding noises followed by the splash-screen disappearing and the message "Killed" on stdout. (I tried the --disable-sound to try and avoid possible troubles with OpenAL). I get exactly the same thing with the motherboard's native S3 "ProSavage" KN133 video card too (has to use software rendering due to lack of DRI support). Interestingly, the FPS readout I see from "glxgears" is not radically different when comparing the two video cards. (About 150 - 180fps). This might indicate that I've not got the DRI running properly for the G200, or that the G200 is a total turkey(*). I do know that the G200 driver reports AGP x1, whereas I believe I should be able to get at least x2 from it. Whatever, the same RPM of FlightGear 0.9.8 runs perfectly well on a 2GHz Intel P4 with an Nvidia Quadra graphics card (using Nvidia's binary driver). So it's not the build per se. I might suggest that those of us who've seen this sort of problem seem to have slow 3D rendering. Is it possible that FlightGear is starting to send a screenfull of vertexes to the video card, but gives up (due to the slow card), aborts that frame and tries to start another. The same thing then happens again and again. This might trigger a slow memory leak internally which eventually leads to the "killed" message with nothing ever appearing on screen. It does seem that the length of time between the splash-screen appearing and the "killed" (or "aborted") message might be dependant on the amount of RAM (or maybe the amount of Swap) available. If the rendering hypothesis above was true, presumably such a scenario could only happen if the scene renderer thought that it should be able to run the screen at a given FPS yet the hardware refuses to oblige. It's just thoughts.. Anyone got any good ideas for ways to test them? I'll run experiments on my failing machine at home if anyone has suggestions. The "correct" behaviour for FlightGear should be to run, but with a uselessly slow frame rate on screen, surely? It used to do that, maybe back at about 0.9.1 or 0.9.2 Steve (*) Or both ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
