[Nouveau] [Bug 93629] [NVE6] complete system freeze, PGRAPH engine fault on channel 2, SCHED_ERROR [ CTXSW_TIMEOUT ]

2016-04-13 Thread bugzilla-daemon
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 ]

2016-04-13 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=93629

Dan Moulding  changed:

   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 ?

2016-04-13 Thread Hans de Goede

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

2016-04-13 Thread bugzilla-daemon
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

2016-04-13 Thread Simone Mannori
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 Mirkin  wrote:
> 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