Nouveau - Jul 2017 - [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote:
> On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de>
wrote:
> > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote:
> >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote:
> >> >
> >> > Some display stuff did change for 4.13 for GM20x+ boards. If
it's not
> >> > too much trouble, a bisect would be pretty useful.
> >>
> >> Bisection seemingly went fine, but the result is odd.
> >>
> >> e98c58e55f68f8785aebfab1f8c9a03d8de0afe1 is the first bad commit
> >
> > But it really really is bad.  Looking at gitk fork in the road leading
> > to it...
> >
> > 52d9d38c183b drm/sti:fix spelling mistake: "compoment" ->
"component" - good
> > e4e818cc2d7c drm: make drm_panel.h self-contained                    
- good
> > 9cf8f5802f39 drm: add missing declaration to drm_blend.h             
- good
> >
> > Before the git highway splits, all is well.  The lane with commits
> > works fine at both ends, but e98c58e55f68 is busted.  Merge arfifact?
> 
> Hmmm... that tree does not appear to have gotten a v4.12 backmerge at
> any point. The last backmerge from Linus as far as I can tell was
> v4.11-rc7. Could be an interaction with some out-of-tree change.
FWIW, checking out the fingered commit then..

git log --oneline 52d9d38c183b..e98c58e55f68|grep nouveau and reverting
the lot helped not at all.

Checking out 6b7781b42dc9 and reverting the fingered commit did.  Given
the nouveau bits reverted are mostly the vblank changes, CC to Daniel,
maybe he'll know why both GTX 980 and GeForce 8600 GT get all upset.

Either I'm damn lucky, both of my nvidia equipped boxen going boom 100%
repeatably, or there are a lot of folks out there who haven't yet tried
suspend with our latest/greatest kernel.  I suspect the later.

	-Mike

On 7/12/17 7:19 PM, Mike Galbraith wrote:
> On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote:
>> On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at
gmx.de> wrote:
>>> On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote:
>>>> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote:
>>>>> Some display stuff did change for 4.13 for GM20x+ boards.
If it's not
>>>>> too much trouble, a bisect would be pretty useful.
>>>> Bisection seemingly went fine, but the result is odd.
>>>>
>>>> e98c58e55f68f8785aebfab1f8c9a03d8de0afe1 is the first bad
commit
>>> But it really really is bad.  Looking at gitk fork in the road
leading
>>> to it...
>>>
>>> 52d9d38c183b drm/sti:fix spelling mistake: "compoment"
-> "component" - good
>>> e4e818cc2d7c drm: make drm_panel.h self-contained                  
- good
>>> 9cf8f5802f39 drm: add missing declaration to drm_blend.h           
- good
>>>
>>> Before the git highway splits, all is well.  The lane with commits
>>> works fine at both ends, but e98c58e55f68 is busted.  Merge
arfifact?
>> Hmmm... that tree does not appear to have gotten a v4.12 backmerge at
>> any point. The last backmerge from Linus as far as I can tell was
>> v4.11-rc7. Could be an interaction with some out-of-tree change.
> FWIW, checking out the fingered commit then..
>
> git log --oneline 52d9d38c183b..e98c58e55f68|grep nouveau and reverting
> the lot helped not at all.
>
> Checking out 6b7781b42dc9 and reverting the fingered commit did.  Given
> the nouveau bits reverted are mostly the vblank changes, CC to Daniel,
> maybe he'll know why both GTX 980 and GeForce 8600 GT get all upset.
>
> Either I'm damn lucky, both of my nvidia equipped boxen going boom 100%
> repeatably, or there are a lot of folks out there who haven't yet tried
> suspend with our latest/greatest kernel.  I suspect the later.
>
> 	-Mike
>
I should have had a look at my inbox, would have save me a log of work 
bisecting. Yet i come to the same conclusion:

# first bad commit: [e98c58e55f68f8785aebfab1f8c9a03d8de0afe1] Merge tag 
'drm-misc-next-2017-05-16' of git://anongit.freedesktop.org/git/drm-misc
into drm-next


I suspect it is some vblank change as it shows up in every trace i have 
seen while bisecting, but that is just a wild guess...

Greetings,

Tobias

This patch brings back the old nouveau_drm_preclose and nouveau_drm_postclose
functions for closing down a drm device

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de>
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 90757af9bc73..0ca2b65bdc4f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -877,7 +877,7 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file
*fpriv)
 }
 
 static void
-nouveau_drm_postclose(struct drm_device *dev, struct drm_file *fpriv)
+nouveau_drm_preclose(struct drm_device *dev, struct drm_file *fpriv)
 {
 	struct nouveau_cli *cli = nouveau_cli(fpriv);
 	struct nouveau_drm *drm = nouveau_drm(dev);
@@ -892,7 +892,12 @@ nouveau_drm_postclose(struct drm_device *dev, struct
drm_file *fpriv)
 	mutex_lock(&drm->client.mutex);
 	list_del(&cli->head);
 	mutex_unlock(&drm->client.mutex);
+}
 
+static void
+nouveau_drm_postclose(struct drm_device *dev, struct drm_file *fpriv)
+{
+	struct nouveau_cli *cli = nouveau_cli(fpriv);
 	nouveau_cli_fini(cli);
 	kfree(cli);
 	pm_runtime_mark_last_busy(dev->dev);
@@ -964,6 +969,7 @@ driver_stub = {
 	.load = nouveau_drm_load,
 	.unload = nouveau_drm_unload,
 	.open = nouveau_drm_open,
+	.preclose = nouveau_drm_preclose,
 	.postclose = nouveau_drm_postclose,
 	.lastclose = nouveau_vga_lastclose,
 
-- 
2.13.2