[Nouveau] [Bug 93629] [NVE6] complete system freeze, PGRAPH engine fault on channel 2, SCHED_ERROR [ CTXSW_TIMEOUT ]
https://bugs.freedesktop.org/show_bug.cgi?id=93629 --- Comment #17 from Karol Herbst--- (In reply to Dan Moulding from comment #16) > I'm experiencing this bug with kernel 4.4.6 and GK106 (GeForce GTX 645 OEM). > > For what it's worth, I've been experiencing this same bug for about two > years, ever since kernel 3.12 (I was on kernel 3.10 prior to that and never > experienced the bug). After each kernel upgrade I've done, I usually test > the built-in firmware to see if the problem is still there. For a while, I > thought the bug was gone as of the 4.4 kernel because I hadn't experienced > the problem for a long time on 4.4 with the built-in firmware. But recently > I upgraded my desktop environment to KDE Plasma 5 and now I've experienced > the lockup twice in less than a 24-hour period. > > I just switched back to the proprietary firmware (after moving/renaming the > binary blobs to match the names that the new version of the driver looks > for). > > I'm willing to test the built-in firmware more, in order to help debug this > longstanding problem. Is there something I can do to help gather more > information (traces, enable debug logging, etc)? if you are _sure_ that it never happened with 3.10 it would be really good if you git bisect the kernel and see which commit broke it. If you wait like one or two days for a freeze you should be through in a month :/ But maybe there is somebody who might know what it could be if it is really new with 3.12 (or 3.11) -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 93629] [NVE6] complete system freeze, PGRAPH engine fault on channel 2, SCHED_ERROR [ CTXSW_TIMEOUT ]
https://bugs.freedesktop.org/show_bug.cgi?id=93629 Dan Mouldingchanged: What|Removed |Added CC||dmould...@me.com --- Comment #16 from Dan Moulding --- I'm experiencing this bug with kernel 4.4.6 and GK106 (GeForce GTX 645 OEM). For what it's worth, I've been experiencing this same bug for about two years, ever since kernel 3.12 (I was on kernel 3.10 prior to that and never experienced the bug). After each kernel upgrade I've done, I usually test the built-in firmware to see if the problem is still there. For a while, I thought the bug was gone as of the 4.4 kernel because I hadn't experienced the problem for a long time on 4.4 with the built-in firmware. But recently I upgraded my desktop environment to KDE Plasma 5 and now I've experienced the lockup twice in less than a 24-hour period. I just switched back to the proprietary firmware (after moving/renaming the binary blobs to match the names that the new version of the driver looks for). I'm willing to test the built-in firmware more, in order to help debug this longstanding problem. Is there something I can do to help gather more information (traces, enable debug logging, etc)? -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] 2nd dvi connector on fx 380 not working, channel configuration problem ?
Hi, I've been debugging the problem of the 2nd dvi connector on fx 380 cards not working. I wanted to diff a dump of the pdisplay block registers under nouveau and the binary nvidia driver, but when running nvapeek under nvidia I get: a "WARN: Can't probe ..." error because of pci_device_map_range() failing, is there a way around this. I did learn something interesting though. If I rmmod nvidia.ko and then insmod nouveau.ko I do get outout on the 2nd dvi. Normally everything seems to work, but this is no output on the 2nd dvi, however if I first load and rmmod nvidia.ko, and then load nouveau.ko I get output, but not the desired output instead the monitor constantly shows the lasts contents of the vga-text-console which was shown before doing the insmod nouveau.ko. This feels like progress, but I'm not sure where to look at from here on. I do have pdisplay reg dumps of both a regular nouveau load, and one after first having loaded nvidia.ko. So any hints how to debug this further ? Regards, Hans ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 92077] nouveau graphics freeze when using KDE Plasma 5; PGR engine fault
https://bugs.freedesktop.org/show_bug.cgi?id=92077 --- Comment #16 from zoominee--- For information, the bug is still present. My package versions are now: mesa 11.1.2 xorg-server 1.18.1 xf86-video-nouveau 1.0.12 linux kernel 4.4.2 I've noticed that, with the chrome-based browsers (Opera etc.) scrolling up and down the page sometimes results in tear: the screen contains wide "columns" of 100 or so pixels that do not scroll and other columns that scroll up and down normally. Other windows and the desktop itself are unaffected. When this tearing happens, if I don't close the windows, the system freezes soon. I suspect that this is related to the bug I reported here. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] PA-RISC (hppa) video cards init failure loading the device driver kernel module
Dear Ilia, unfortunately, I have only bad news to report: - the nouveau options that you have suggested does not produce the expected resuls; nouveau.config=NvAGP=0 (I'm using Linux blsw 4.4.0-1-parisc64-smp #1 SMP Debian 4.4.6-1 (2016-03-17) parisc64 GNU/Linux) and nouveau.vram_pushbuf=1 does not fix the issue about NVIDA AGP init. The error is still there and the video card works in frame buffer mode only - I have tried another, more recent, NVIDIA AGP card (NV36GL [Quadro FX 1100] (rev a1)): this model, with or without options, is not able to make X11 works. - I have tried also a PCI video card (ATI 9200), but with this model the c8000 is not ble to complete the internal diagnostic,so the Linux boot does not start > 0e000e7a00e0 600601005d441002 CC_IODISC_PCI_DEVICE_CONFIG > pci_bus_walk line 2878 - bridge aperture too big then . the system boot process STOPs: e000108401e0 CC_BOOT_BOOT_FAILURE 030010d501e0 CC_CPU_STOP The problem is elsewhere. "TTM" module ? I'm perplexed and confused. Helge Deller told me that the hppa linux branch does not have a working kgdb support, therefore my only chance to find and fix this _very_nasty_ bug is insert some "printk" and hope to be able to find the source of the issue. Any idea ? Thanks in advance for the help Simone Mannori - ITALY On 4 April 2016 at 04:18, Ilia Mirkinwrote: > Not sure about the radeon issue, but > > "DRM: GPU lockup - switching to software fbcon" > > basically means "the CPU isn't able to submit commands, or the GPU > isn't executing the commands". Basically the GPU can only have so many > commands outstanding [well, command buffers], and we hit that limit. > From what I understand, PA-RISC has a "funny" architecture that is > very unlike x86 in terms of memory coherency, and is thus more likely > to hit issues that don't exist on other architectures. Perhaps you can > summarize the key points of oddness? Perhaps there's some debug > "disable caches" mode or something? Also note that nouveau won't work > well on an architecture with a non-4K page size. Not sure if that's > the situation for you. > > I see that it's using AGP - there's a high chance that something > AGP-related is broken - try booting with nouveau.config=NvAGP=0 (or > nouveau.agpmode=0 for pre-4.3 kernels). > > Perhaps it has issues DMA'ing the command buffer from system memory, > we can try forcing the pushbuf to be in vram - boot with > nouveau.vram_pushbuf=1 . > > If there are PCI slots and you have a PCI video card handy, I'd > definitely try that too. > > Good luck, > > -ilia > > On Sun, Apr 3, 2016 at 3:51 AM, Simone Mannori > wrote: >> Dear "nouveau" developers, >> >> I know that many very competent guys have already spent a lot of time >> and efforts on this issue without success. I have started to play with >> "hppa" two weeks ago and, with the support of the linux-parisc mailing >> list people, now I have a - almost fully - working workstation (hp >> c8000). >> >> Everythings work perfectly BUT the video card. No matter the model, >> type, driver, etc. the results are always the same: a very slow frame >> buffer mode only. >> >> I'm forwarding the results of my investigations with the hope that >> someone of you will help me to find the right path to fix this issue. >> >> Thanks in advance for your help. >> >> Simone Mannori - Italy >> >> //** >> >> -- Forwarded message -- >> From: Simone Mannori >> Date: 3 April 2016 at 09:34 >> Subject: Video cards init failure loading the device driver kernel module >> To: John David Anglin >> Cc: Helge Deller , Graham Gower >> , linux-parisc >> >> >> Dear All, >> >> following you suggestions, now I have an - almost - perfectly working >> hp c8000 workstation. >> >> Mission accomplished? Not exactly: despite a lot of efforts, the video >> card section is still not fully operative. Let me resume the >> situation. >> >> I'm using a c8000 with two PA-8800 and Debian 8.0, kernel: >> >> Linux version 4.4.0-1-parisc64-smp (debian-ker...@lists.debian.org) >> (gcc version 4.9.3 (GCC) ) #1 SMP Debian 4.4.6-1 (2016-03-17) >> >> I have two very different AGP video cards (ATI FireGL T2 and NVIDIA >> QUADRO MXR) that have the same issue, despite the two complety >> different drivers ("radeon" and "nouveau"). The full logs are in >> bottom of this post. Just to make a long history short: >> >> ATI FIRE GL T2 ("radeon") >> [ 47.836000] [drm:r100_ring_test [radeon]] *ERROR* radeon: ring test >> failed (scratch(0x15E4)=0xCAFEDEAD) >> [ 47.948000] [drm:r100_cp_init [radeon]] *ERROR* radeon: cp isn't >> working (-22). >> [ 48.036000] radeon :80:00.0: failed initializing CP