|Summary:||[nv96] Freespace 2 open crashes|
|Product:||Mesa||Reporter:||Maarten Maathuis <madman2003>|
|Component:||Drivers/DRI/nouveau||Assignee:||Nouveau Project <nouveau>|
|Status:||RESOLVED MOVED||QA Contact:|
|i915 platform:||i915 features:|
Description Maarten Maathuis 2013-12-20 23:05:10 UTC
This has been an issue for much longer, it looks to be a memory related problem. Textures are corrupted and after a little while the card hangs. I've confirmed with the binary blob that the hardware works fine. The errors that i got were: Dec 20 22:12:41 madman kernel: [ 66.490366] nouveau E[ PGRAPH][0000:01:00.0] TRAP_MP_EXEC - TP 0 MP 0: INVALID_OPCODE at 07d7e0 warp 15, opcode 80070279 00060780 Dec 20 22:12:41 madman kernel: [ 66.490379] nouveau E[ PGRAPH][0000:01:00.0] TRAP_MP_EXEC - TP 0 MP 1: INVALID_OPCODE at 07d7e0 warp 1, opcode 80070279 00060780 Dec 20 22:12:41 madman kernel: [ 66.490384] nouveau E[ PGRAPH][0000:01:00.0] TRAP Dec 20 22:12:41 madman kernel: [ 66.490390] nouveau E[ PGRAPH][0000:01:00.0] ch 4 [0x001f91e000 fs2_open] subc 3 class 0x8297 mthd 0x15f0 data 0x0dd80dd8 This was with a 3.13-rc4 kernel and a very recent git mesa (also tried mesa 9.25, had the same problem). In general i don't think any graphic intensive runs for a very long time. It's just that this one is very easy to make crash. My question is, what can i do to narrow this down? Keep in mind that this has been going on for more than 6 months probably (maybe even a year) and I can't take my kernel too far back into the past (because my system is compiled against modern linux headers).
Comment 1 Ilia Mirkin 2014-01-19 12:14:37 UTC
This error is telling you that an invalid opcode was attempted to get executed. On the bright side, envydis agrees that it's an invalid opcode. So either we have a bug in generating shaders, or it's something more sinister. If you run a debug mesa build with NV50_PROG_DEBUG=1, it should dump all the shaders being compiled -- that should at least let us know if we're generating the wrong opcodes or not. Basically look for the 80070279 00060780 sequence in the generated program binaries that are printed out. If you do find it, grab the whole shader binary as well as the lines that precede it, including the TGSI that caused it to be generated, and upload that here. If it's not there, then... that's very unfortunate -- it means some sort of memory corruption issue. Let's hope it's the more straightforward problem.
Comment 2 GitLab Migration User 2019-09-18 20:38:57 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1058.