This reverts commit 01bbcb69f80e1058395b737ae399c6f4ef48691b.
The commit caused fence timeouts within nvc0_screen_destroy and most likely
other places as well.
The most obvious effect is, that userspace processes take minutes to actually
quit.
Signed-off-by: Karol Herbst
---
drm/nouveau/includ
Cought while working on travis-ci integration
Signed-off-by: Karol Herbst
---
drm/nouveau/uapi/drm/nouveau_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drm/nouveau/uapi/drm/nouveau_drm.h
b/drm/nouveau/uapi/drm/nouveau_drm.h
index 259588a..0bfaae8 100644
--- a/drm/no
https://bugs.freedesktop.org/show_bug.cgi?id=97588
--- Comment #17 from r...@mief.nl ---
I think this can be closed as it does seem to be a XFCE bug rather than
nouveau. I have confirmed that KDE/openbox do work when switching or
disconnecting the monitor.
For future reference, when people have
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous
prototype for 'nvkm_firmware_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous
prototype for 'nvkm_firmware_put' [-Wmissing-pr
Every other *_drm.h does #include "drm.h". Something else is wrong.
On Sun, Sep 18, 2016 at 6:21 AM, Karol Herbst wrote:
> Cought while working on travis-ci integration
>
> Signed-off-by: Karol Herbst
> ---
> drm/nouveau/uapi/drm/nouveau_drm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletio
odd, let me check again
2016-09-18 16:18 GMT+02:00 Ilia Mirkin :
> Every other *_drm.h does #include "drm.h". Something else is wrong.
>
> On Sun, Sep 18, 2016 at 6:21 AM, Karol Herbst wrote:
>> Cought while working on travis-ci integration
>>
>> Signed-off-by: Karol Herbst
>> ---
>> drm/nouvea
https://bugs.freedesktop.org/show_bug.cgi?id=97588
--- Comment #18 from poma ---
(In reply to Karol Herbst from comment #15)
> uhh I remember. At work on a xfce4 machine we also have troubles with a
> laptop + 2 external monitors on an AMD gpu. After login all screens are
> black and sometimes wh
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #9 from Luke Tidd ---
Hi! Sorry that took so long. My other machine didn't have enough memory to run
git bisect on the kernel.
Here's the goods. Any change marked bad exhibited the exact same symptoms
(monitor turns off shortly afte
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #10 from Ilia Mirkin ---
(In reply to Luke Tidd from comment #9)
> Hi! Sorry that took so long. My other machine didn't have enough memory to
> run git bisect on the kernel.
>
>
> Here's the goods. Any change marked bad exhibited th
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #11 from Luke Tidd ---
You are right, sorry new to git bisect. Was thrown off by "0 more steps to do".
git bisect start '--' 'drivers/gpu/drm/nouveau'
# good: [b562e44f507e863c6792946e4e1b1449fbbac85d] Linux 4.5
git bisect good b56
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #12 from Ilia Mirkin ---
(In reply to Luke Tidd from comment #11)
> # first bad commit: [a6a0f67ca7aae2e6bec7ebf55d1e4853dc220816]
> drm/nouveau/devinit/gf100-: detect if BIOS invoked devinit
That's interesting. It either used to run
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #13 from Ilia Mirkin ---
Another thing you could do is boot (any) kernel with nomodeset, and then using
envytools (https://github.com/envytools/envytools/), do
nvapeek 2240c
This should output 1 line, either a number or just "..." [
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #14 from Luke Tidd ---
kernel 4.7.4-1-ARCH
nomodeset single
# nvapeek 2240c
...
testing working kernel now.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #15 from Ilia Mirkin ---
(In reply to Luke Tidd from comment #14)
> kernel 4.7.4-1-ARCH
> nomodeset single
>
> # nvapeek 2240c
> ...
>
>
> testing working kernel now.
Hm, that means that the bit we're checking is 0, which indicate
FWIW I also have to carry a local patch doing this, otherwise I cannot
perform an out-of-tree module build.
On Mon, Sep 19, 2016 at 12:32 AM, Karol Herbst wrote:
> odd, let me check again
>
> 2016-09-18 16:18 GMT+02:00 Ilia Mirkin :
>> Every other *_drm.h does #include "drm.h". Something else is
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #16 from Luke Tidd ---
(In reply to Ilia Mirkin from comment #15)
> (In reply to Luke Tidd from comment #14)
> > kernel 4.7.4-1-ARCH
> > nomodeset single
> >
> > # nvapeek 2240c
> > ...
> >
> >
> > testing working kernel now.
>
>
On Sun, Sep 18, 2016 at 7:21 PM, Karol Herbst wrote:
> This reverts commit 01bbcb69f80e1058395b737ae399c6f4ef48691b.
>
> The commit caused fence timeouts within nvc0_screen_destroy and most likely
> other places as well.
>
> The most obvious effect is, that userspace processes take minutes to actu
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #17 from Luke Tidd ---
Created attachment 126609
--> https://bugs.freedesktop.org/attachment.cgi?id=126609&action=edit
dmesg 4.5.0-rc7 nouveau.debug=debug log_buf_len=1M single
--
You are receiving this mail because:
You are the a
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #18 from Luke Tidd ---
(In reply to Ilia Mirkin from comment #12)
> (In reply to Luke Tidd from comment #11)
> > # first bad commit: [a6a0f67ca7aae2e6bec7ebf55d1e4853dc220816]
> > drm/nouveau/devinit/gf100-: detect if BIOS invoked dev
On Sun, Sep 18, 2016 at 11:39 PM, Alexandre Courbot wrote:
> On Sun, Sep 18, 2016 at 7:21 PM, Karol Herbst wrote:
>> This reverts commit 01bbcb69f80e1058395b737ae399c6f4ef48691b.
I think you meant aff51175cdbf345740ec9203eff88e772af88059 - that's
the commit id that matters, not the one in Ben's
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #19 from Luke Tidd ---
Created attachment 126610
--> https://bugs.freedesktop.org/attachment.cgi?id=126610&action=edit
4.5.0-rc7 nouveau.debug=debug video=vesafb:off log_buf_len=1M
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #20 from Ilia Mirkin ---
(In reply to Luke Tidd from comment #18)
> https://bugs.freedesktop.org/attachment.cgi?id=126609
> I don't see "bios: running init tables" but here is the entire dmesg.
Indeed. So the "working" state is to no
On Mon, Sep 19, 2016 at 12:43 PM, Ilia Mirkin wrote:
> On Sun, Sep 18, 2016 at 11:39 PM, Alexandre Courbot wrote:
>> On Sun, Sep 18, 2016 at 7:21 PM, Karol Herbst wrote:
>>> This reverts commit 01bbcb69f80e1058395b737ae399c6f4ef48691b.
>
> I think you meant aff51175cdbf345740ec9203eff88e772af880
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #21 from Luke Tidd ---
# stat /sys/kernel/debug/dri/0/vbios.rom
File: '/sys/kernel/debug/dri/0/vbios.rom'
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 7h/7d Inode: 13648 Links: 1
Acc
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #22 from Ilia Mirkin ---
(In reply to Luke Tidd from comment #21)
> # stat /sys/kernel/debug/dri/0/vbios.rom
> File: '/sys/kernel/debug/dri/0/vbios.rom'
> Size: 0 Blocks: 0 IO Block: 4096 regular empty file
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #23 from Luke Tidd ---
Created attachment 126611
--> https://bugs.freedesktop.org/attachment.cgi?id=126611&action=edit
(broken) dmesg_4.7.4-1-ARCH nouveau.debug=debug,bios=trace
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #24 from Luke Tidd ---
Created attachment 126612
--> https://bugs.freedesktop.org/attachment.cgi?id=126612&action=edit
vbios.rom
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #25 from Ilia Mirkin ---
(In reply to Luke Tidd from comment #23)
> Created attachment 126611 [details]
> (broken) dmesg_4.7.4-1-ARCH nouveau.debug=debug,bios=trace
I am very confused by the lack of trace output for the bios executio
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #26 from Ilia Mirkin ---
0x13b154 = PXBAR.GPC_UNK1[0x2]+0x54
However GF104 only has 2 GPC's. Odd. At least the MMIO write failure makes
sense. I wonder if we're supposed to filter those out. That'd be pretty
annoying...
Another curi
https://bugs.freedesktop.org/show_bug.cgi?id=97620
--- Comment #27 from Ilia Mirkin ---
Looking at our VBIOS repo, we have a bunch (but not all) of GF104's that are
missing the 0x2240c write as well as one GK107. Every other (GF100+) GPU sets
0x2240c. I guess it's not as reliable as we'd hoped.
On 19/09/16 06:50, Alexandre Courbot wrote:
On Mon, Sep 19, 2016 at 12:43 PM, Ilia Mirkin wrote:
On Sun, Sep 18, 2016 at 11:39 PM, Alexandre Courbot wrote:
On Sun, Sep 18, 2016 at 7:21 PM, Karol Herbst wrote:
This reverts commit 01bbcb69f80e1058395b737ae399c6f4ef48691b.
I think you meant a
31 matches
Mail list logo