![]() But the thing doesn't seem random enough to suggest a simple hardware defect as the main cause, imho. Of course, actual hardware breakage is always an option. What other resources might become exhausted by concurrent access from graphics-intensive applications? Would that exhaustion be reported in some way? texture memory somehow clobber memory needed by GPU firmware for methods such like this? ![]() The load pattern must be part of the issue.ĭo things like stack overflows occur in GPU memory? Could excessive allocation of e.g. Therefore the command likely won't fail all the time. > happens a fair bit for CPU vs GPU syncs. > But 0x00406040 is a perfectly valid command, ever since the Riva TNT chips.Ĭould it be that the command is invalid AT THAT TIME? Perhaps due to a race condition? Could it be that the semaphore is already high? I don't need answers to these questions, as long as you know that the answers exists and don't help us here. ![]() Not sure whether this will be of any use, but I'm trying to think of ways which might cause this, in my own pretty naive way of thinking about hardware drivers and graphics cards. In any case, I wasn't aware that the actual problem might have occurred before the eventual crash the first time around. when logging to disk, that time might have been shorter. I guess that the freezing of the mouse cursor might have actually been due to the time it took to send those log messages. System crashed without further output to netconsole Received the attached error message on the netconsole receiverġ1. Noticed the mouse cursor movement to freeze for a momentġ0. I didn't close all non-essential aspects of my session. I had netconsole reporting to a different computer, with “dmesg -n 8”, which is where the attached log came from.ġ. I was able to reproduce this incident, again with stellarium and that big Wikipedia image in Firefox. I'll give a few details on each of these incidents with the corresponding unabridged log. I'll attach the unabridged logs shortly, but I can't even know whether these successfully flushed all their data. Unfortunately I don't have a serial terminal attached for logging at all times. The crashes themselves aren't reported as Oops, or maybe they are but the file system is already unavailable by that time, so I don't notice. I've read that you prefer untruncated dmesg output, but since this issue causes my system to reboot, calling dmesg is not an option, and since I'm reporting several incidents, this might be a quick starting point. It is the output of “grep -h -C1 -E '\] nouveau |Linux version'” applied to the currently available kernel logs. I'm attaching an abridged version of the log files first, for a quick glance. VGA compatible controller: NVIDIA Corporation G84 (rev a1) Most notably three crashes in the past few days, with kernel version 3.11.4-gentoo. I've encountered several system crashes in relation to nouveau and graphics work lately. This is taking my bug usptream from the distro level bug I first filed at Nouveau error lines in kernel log for three incidents
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |