Hi Lucas,
On Mon, Mar 24, 2014 at 10:19 PM, Lucas Stach wrote:
> Hi Alexandre,
>
> Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot:
>> Hi everyone,
> [...]
>>
>> A few lines of hacks (not included here) are still needed to deal with cached
>> mappings triggering external aborts a
On Thu, Mar 13, 2014 at 12:05 PM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
Already said on IRC, but for posterity:
Reviewed-by: Ben Skeggs
> ---
> nouveau/nouveau.c | 29 -
> nouveau/private.h | 3 ++-
> 2 files changed, 30 insertions(+), 2 deletions(-)
>
>
On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot wrote:
> Set the correct subdev/engine classes when GK20A (0xea) is probed.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --g
On Tue, Mar 25, 2014 at 9:10 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:33PM +0900, Alexandre Courbot wrote:
>> GK20A does not embed a dedicated COPY engine and thus cannot allocate
>> the copy channel that nouveau_accel_init() attempts to create. It also
>> lacks any display hardwa
On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot wrote:
> Add a GR device for GK20A based on NVE4, with the correct classes
> definitions (GK20A's 3D class is 0xa297).
>
> Most of the NVE4 code can be used on GK20A, so make relevant bits of
> NVE4 available to other chips as well.
This will need
On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot wrote:
> Pad the microcode to a multiple of 0x40, otherwise firmware will fail to
> run from non-prepadded firmware files.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4
> 1 file changed,
On Tue, Mar 25, 2014 at 8:58 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:30PM +0900, Alexandre Courbot wrote:
> [...]
>> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> index 6ef8bf181b2d..f997a18f5760 100644
>>
On Tue, Mar 25, 2014 at 8:13 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:25PM +0900, Alexandre Courbot wrote:
>> Some chips that use system memory exclusively (e.g. GK20A) do not
>> expose 2 BAR regions. For them only BAR1 exists, and it should be used
>> for USERD mapping. Do not ma
On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
>> GK20A's timer is directly attached to the system timer and cannot be
>> calibrated. Skip the calibration phase on that chip since the
>> corresponding registers do not exi
Hi Alexandre,
Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot:
> Hi everyone,
[...]
>
> A few lines of hacks (not included here) are still needed to deal with cached
> mappings triggering external aborts and CPU/GPU memory coherency issues, but I
> hope to understand and address
On Mon, Mar 24, 2014 at 11:59:46AM -0700, Martin Peres wrote:
>
> Hello,
>
> One of my GPU (GK107/NVE7) fails to properly fetch its vbios from PROM
> at boot time but, if I blacklist the module and load it myself later on,
> it always succeeds. To make things weirder, the same card works great o
Hi,
I am unable to suspend using nouveau, so I have to use the NVIDIA
drivers currently, which I do not like to do (they don't work as well
for everything else and are proprietary)
So... to get to the basic info
01:00.0 VGA compatible controller: NVIDIA Corporation G84M [GeForce
8600M GT] (re
https://bugs.freedesktop.org/show_bug.cgi?id=76605
--- Comment #8 from Matthias Blankertz ---
With apitrace I couldn't get past the menu without the game becoming
unresponsive, but there is already some corruption.
The trace is too big to attach, I have uploaded it at
http://blankertz.org/~matth
https://bugs.freedesktop.org/show_bug.cgi?id=76605
--- Comment #7 from Ilia Mirkin ---
If you capture an apitrace of the game, do you still see the corruption when
replaying the trace?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=76605
--- Comment #6 from Matthias Blankertz ---
Created attachment 96388
--> https://bugs.freedesktop.org/attachment.cgi?id=96388&action=edit
Picture of corruption 2
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=76605
--- Comment #5 from Matthias Blankertz ---
Created attachment 96387
--> https://bugs.freedesktop.org/attachment.cgi?id=96387&action=edit
Picture of corruption 1
Sorry, couldn't get a real screenshot, so only a photo
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=76605
--- Comment #4 from Matthias Blankertz ---
There is no change in the behaviour, with 3.14-rc8 kernel with or without
nouveau.config=PCRYPT=0.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=76605
--- Comment #3 from Matthias Blankertz ---
Created attachment 96386
--> https://bugs.freedesktop.org/attachment.cgi?id=96386&action=edit
dmesg with 3.14-rc8 and nouveau.config=PCRYPT=0
--
You are receiving this mail because:
You are the assig
https://bugs.freedesktop.org/show_bug.cgi?id=76605
--- Comment #2 from Matthias Blankertz ---
Created attachment 96385
--> https://bugs.freedesktop.org/attachment.cgi?id=96385&action=edit
dmesg with 3.14-rc8
--
You are receiving this mail because:
You are the assignee for the bug.
___
On Tue, Mar 25, 2014 at 6:30 PM, Martin Peres wrote:
> On 25/03/2014 23:24, Ilia Mirkin wrote:
>>
>> On Tue, Mar 25, 2014 at 6:11 PM, Martin Peres
>> wrote:
>>>
>>> Other kind of accesses are unreliable on Maxwell cards. As advised by
>>> NVIDIA,
>>
>> Maxwell or Kepler?
>
>
> Damn, I meant Keple
On 25/03/2014 17:17, Christian Zander wrote:
On Mon, Mar 24, 2014 at 11:59:46AM -0700, Martin Peres wrote:
Hello,
One of my GPU (GK107/NVE7) fails to properly fetch its vbios from PROM
at boot time but, if I blacklist the module and load it myself later on,
it always succeeds. To make things we
On 25/03/2014 23:24, Ilia Mirkin wrote:
On Tue, Mar 25, 2014 at 6:11 PM, Martin Peres wrote:
Other kind of accesses are unreliable on Maxwell cards. As advised by NVIDIA,
Maxwell or Kepler?
Damn, I meant Kepler.
I updated the patch in my git tree:
http://cgit.freedesktop.org/~mperes/nouvea
On Tue, Mar 25, 2014 at 6:11 PM, Martin Peres wrote:
> Other kind of accesses are unreliable on Maxwell cards. As advised by NVIDIA,
Maxwell or Kepler?
> let's only use 32-bit accesses to fetch the vbios from PROM.
>
> This fixes vbios fetching on my nve7 which failed in certain specific
> condi
Other kind of accesses are unreliable on Maxwell cards. As advised by NVIDIA,
let's only use 32-bit accesses to fetch the vbios from PROM.
This fixes vbios fetching on my nve7 which failed in certain specific
conditions.
I suggest we Cc stable, for all kernels they still maintain after the big
re
https://bugs.freedesktop.org/show_bug.cgi?id=76605
Ilia Mirkin changed:
What|Removed |Added
Summary|Screen corruption and |[NV86] Screen corruption
https://bugs.freedesktop.org/show_bug.cgi?id=76605
--- Comment #1 from Ilia Mirkin ---
Can you check with 3.14-rc8? Alternatively try booting with
nouveau.config=PCRYPT=0. (Although I'm not seeing the MMIO write error that I
would expect to see if you had that particular issue, but it's easy enou
https://bugs.freedesktop.org/show_bug.cgi?id=76605
Priority: medium
Bug ID: 76605
Assignee: nouveau@lists.freedesktop.org
Summary: Screen corruption and crashes in bastion on NVS-140M
(G86)
Severity: normal
Classification
Here's a test program I just whipped up that demonstrates (some of)
the issues in the old code. This segfaults in either nouveau_bo_wrap
or nouveau_bo_new, or sometimes nouveau_bo_wrap fails to find the
handle. With the patch, it hasn't failed yet. Ben -- review please?
(Or someone else...) Admitte
Le 24/03/2014 02:03, Martin Peres a écrit :
From: Martin Peres
This should fix a deadlock that has been reported to us where fan_update()
would hold the fan lock and try to grab the alarm_program_lock to reschedule
an update. On an other CPU, the alarm_program_lock would have been taken
before
https://bugs.freedesktop.org/show_bug.cgi?id=71620
--- Comment #4 from Raphaël Droz ---
Created attachment 96365
--> https://bugs.freedesktop.org/attachment.cgi?id=96365&action=edit
.config diff
seems that it never happened with my previous config (used during several
weeks), but happened (onc
https://bugs.freedesktop.org/show_bug.cgi?id=71620
--- Comment #3 from Raphaël Droz ---
Created attachment 96364
--> https://bugs.freedesktop.org/attachment.cgi?id=96364&action=edit
stacktrace from kernel oops
same here (with a slightly different stack trace), see attachment
(using 10de:06e4 (
On Mon, Mar 24, 2014 at 10:50 PM, William Lewis
wrote:
> I hope I'm writing to people who can help me. If not you, then I have a
> serious inconvenience and am going to be at a complete loss for where to
> turn.
>
> Let me explain my setup. I have an HTPC with a GeForce GT620. It is
> connected
On Tue, Mar 25, 2014 at 1:57 AM, Alexei Ustyuzhaninov
wrote:
> Hi!
>
> I have a rather decent notebook (Toshiba Satellite P105-S9722) with Nvidia
> GeForce Go 7900 GS video card. I installed latest debian system with kernel
> 3.13-1-amd64 on it, but unfortunately nouveau driver doesn't work. When
https://bugs.freedesktop.org/show_bug.cgi?id=76585
Priority: medium
Bug ID: 76585
Assignee: nouveau@lists.freedesktop.org
Summary: [NVE6] kernel oops and Xorg crash when resuming after
suspend
QA Contact: xorg-t...@lists.x.org
34 matches
Mail list logo
