|
|
|
[
Permlink
| « Hide
]
Mm Alder added a comment - 24/Feb/08 01:29 PM - edited
added crashDiagnostics1.txt – SwapBuffers crash
Since someone might now actually look at the problem, I assembled a few diagnostics files to look at.
I was looking at another problem (Why does SLVoice keep sending stuff when I'm not doing anything?) using a viewer compiled from source (1.18.5.3) when the graphics driver crashed. In the way old times, in this condition, the system would just hang. Intel then added a monitor to watch for infinite loops and forced a BSOD. Later they modified the behavior to switch the graphics to VGA mode so you can save files and clean up before rebooting. So although the driver crashes, the system still runs with that old time VGA look. I noticed that the crash didn't affect SLVoice at all, so I looked at the other processes and noticed that the viewer was still running, actually using all the CPU cycles of one of the two cores on my machine. So I attached the Visual C++ debugger to the process and recorded some of the information it showed. That is contained in the crashDiagnostics1.txt file attached here. At this point I decided to compile and link a version with the /DEBUG flag set for the linker. This gives nicer stack traces. I was able to get two more crashes and am attaching that information as crashDiagnostics2.txt and crashDiagnostics3.txt. Unlike the first, which happened after I'd been logged on to SecondLife for a while, these latter two occurred during log on. All three crashes left the viewer spinning in tight loops in the Intel OpenGL driver. The latter two in exactly the same place. Looking down the call stack showed that the first was a call to SwapBuffers and the other two were calls to glClear, though not at the same place in the SL code. I'm guessing that the ialmnt5 graphics driver was running on another thread and that the OpenGL driver thread is spinning in the loop waiting for an event from the crashed thread that will never come. The other threads probably kept on going as far as they could. So the diagnostics may not be the same as the situation at the time of the crash, but likely the OpenGL calls are the ones that lead to the crash. I'm using the latest drivers available for my machine from the manufacturer. The drivers available from Intel are dated later, but they won't install on my machine. One of the problems with this bug is that no one knows the conditions that can reproduce it on demand. I'm hoping that someone with a better understanding of OpenGL can interpret these diagnostics so that the crash can be efficiently initiated. I've given the register information for each of the instructions in the tight loop for anyone fluent in Intel assembler language. Is this an event loop? a mutex? or what? Note that none of these crashes had anything to do with occlusion, so the fix mentioned in the description is not likely to help. I have a 945GM on my laptop running XP, and I thought I'd add this here. I used to be plagued by random crashes until I messed around with various drivers, and eventually found a setup that let me stay on SL pretty much crash-free (well, except for teleporting crashes).
Driver Version: 6.14.10.4543 Intel Graphic Media Accelerator settings: Asynchronous Flip: OFF The latest drivers I can install are 14.32.3, which cause a BSOD. SL doesn't look pretty, but it works. I'm making some progress trying to figure out the trigger to the crashes and learning about OpenGL in the process.
I'm told that crashes in glClear and SwapBuffers may result from earlier OpenGL calls because instructions are queued up for optimization. So I'm using glFlush and glFinish to force execution in order to narrow down the offenders. I was able to get it to crash in another place. I tried compiling with glGetError checks on and none were found even when it crashed. I tried running with GLIntercept. I can't get it to crash with command logging on. It hasn't detected any problems otherwise when it crashes. I was able to get it to step out of the infinite loop by editing the register values, so I'm trying to figure out what the loop is trying to do. I was able to connect with the Intel 945 chipset on a IBM thinkpad T60 using the Release Canidate version 1.20 - the video settings default to low
Intel Core Duo processor T7200(2GHz), T7400(2.16GHz) PC2-5300 Non-Parity (NP) Double Data Rate Two (DDR2) Technology This system is okay to run the newest release but it runs it basically with out any proper graphic support. Driver Version - 6.14.10.4860 - Fails to run under currently released version of 1.19 darcy, try updating your graphics drivers.
http://downloadcenter.intel.com/Product_Filter.aspx?ProductID=2301&lang=eng Having same problem with Linux build. I know the sysreq page doesn't list the Intel chipsets as supported, but it used to not list them for Windows either. I really do hope this is just a LL slip-up and not just a sweeping of everyone running a Linux laptop under the rug.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Meta Issue
Open
Normal
Meta Issue: Intel 9xx graphics chipset crashes
