![]() ![]() So I'd conclude that the line does not neccessarily lead to a crash, and that the critical value does not get written via nouveau_bo_wr32. Also with no subsequent error messages, or system crash. With no stack trace or other indication that my BUG_ON got triggered. Result: I managed to get that first DMA_PUSHER line all by itself: Unless static function scope variables don't work the same in kernel space and in unser space, this should report if, BEGIN_NV04, OUT_RING or some other command was used to write this value. Gave this a stab, using a BUG_ON conditional the way this attachment describes it. > it enters the ring, and emit useful information like a kernel stack trace? > Can we add a bit of debug code somewhere, to detect that specific value when the mystery is where does this 0x40 method come from. Report 0x00406040 value in nouveau_bo_wr32 Did I miss something?Ĭreated attachment 87553 The way I read BEGIN_NV04, I can find your subc = 0, and size = 0x10, but I'd read mthd = 0x40 directly from the least significant bits. I must confess, I cannot follow how you decode 0x00406040 to method = 0x10. Of course it would be nice if I had another card with the same kind of chips to plug into my system, just to rule out that alternative… 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 |