Bug 83168 - [NV46] No display after suspend to RAM
Summary: [NV46] No display after suspend to RAM
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-28 00:19 UTC by Neven Sajko
Modified: 2014-08-31 22:52 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
the kernel log (60.67 KB, text/plain)
2014-08-28 00:19 UTC, Neven Sajko
no flags Details
kernel log from linux 3.2 (67.98 KB, text/plain)
2014-08-31 22:52 UTC, Neven Sajko
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Neven Sajko 2014-08-28 00:19:27 UTC
Created attachment 105362 [details]
the kernel log

When Linux resumes after suspension to RAM, I get no display until next  
boot, but the backlight is on. I think this was true since I started     
using this distro, but I rarely tried to use suspend.                   
This happens invariantly to Xorg.                                       
Although my hardware is 64-bit, I use a 32-bit Linux.                   
                                                                        
Software versions:                                                      
                                                                        
* Linux 3.16.1                                                          
                                                                        
* libdrm 2.4.56                                                         
                                                                        
* mesa 10.2.6                                                           
                                                                        
* xf86-video-nouveau 1.0.10                                             
                                                                        
nouveau reports errors like these to kernel log when the display should 
turn back on:                                                           
                                                                        
[  153.783362] nouveau E[    PBUS][0000:01:00.0] MMIO write of 0x00001e00 FAULT at 0x6813c8
[  153.788735] nouveau E[    PBUS][0000:01:00.0] MMIO write of 0x00002e00 FAULT at 0x6813c8
[  153.791840] nouveau E[    PBUS][0000:01:00.0] MMIO write of 0xf5153d80 FAULT at 0x6813c8
Comment 1 Neven Sajko 2014-08-28 00:27:38 UTC
lspci output:
VGA compatible controller: NVIDIA Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1) (prog-if 00 [VGA controller])

dmesg | grep -i chipset
[    0.965969] nouveau  [  DEVICE][0000:01:00.0] Chipset: G72 (NV46)


Do I have to take a MMIO dump?
Comment 2 Ilia Mirkin 2014-08-28 00:31:57 UTC
Has any kernel version worked for you? i.e. is this a recent regression, or was it always like this (or even worse)?

0x6813c8 = PRMDIO.PAL_INDEX

The 680* ones are in PRAMDAC but not documented in envytools...

Weird that the core frequency gets detected as 200 after resume instead of 222 as it was on start...
Comment 3 Neven Sajko 2014-08-28 02:31:55 UTC
(In reply to comment #2)
> Has any kernel version worked for you? i.e. is this a recent regression, or
> was it always like this (or even worse)?
> 
> 0x6813c8 = PRMDIO.PAL_INDEX
> 
> The 680* ones are in PRAMDAC but not documented in envytools...
> 
> Weird that the core frequency gets detected as 200 after resume instead of
> 222 as it was on start...

(In reply to comment #2)
> Has any kernel version worked for you? i.e. is this a recent regression, or
> was it always like this (or even worse)?
> 
> 0x6813c8 = PRMDIO.PAL_INDEX
> 
> The 680* ones are in PRAMDAC but not documented in envytools...
> 
> Weird that the core frequency gets detected as 200 after resume instead of
> 222 as it was on start...

I think this was like it is for a few months, it isn't a recent          
regression.
Comment 4 Ilia Mirkin 2014-08-28 02:33:27 UTC
(In reply to comment #3)
> I think this was like it is for a few months, it isn't a recent          
> regression.

Is that another way of saying that it was working fine a few months ago? Any idea what kernel worked?
Comment 5 Neven Sajko 2014-08-28 17:45:31 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > I think this was like it is for a few months, it isn't a recent          
> > regression.
> 
> Is that another way of saying that it was working fine a few months ago? Any
> idea what kernel worked?

No, I'm sorry for not being clear, I don't think it ever worked fine since I switched to Archlinux from Debian sometime in April.
Comment 6 Ilia Mirkin 2014-08-28 17:49:47 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > I think this was like it is for a few months, it isn't a recent          
> > > regression.
> > 
> > Is that another way of saying that it was working fine a few months ago? Any
> > idea what kernel worked?
> 
> No, I'm sorry for not being clear, I don't think it ever worked fine since I
> switched to Archlinux from Debian sometime in April.

So... it worked in debian. What linux kernel was that with?
Comment 7 Neven Sajko 2014-08-28 17:54:29 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > > > I think this was like it is for a few months, it isn't a recent          
> > > > regression.
> > > 
> > > Is that another way of saying that it was working fine a few months ago? Any
> > > idea what kernel worked?
> > 
> > No, I'm sorry for not being clear, I don't think it ever worked fine since I
> > switched to Archlinux from Debian sometime in April.
> 
> So... it worked in debian. What linux kernel was that with?

Sorry, I don't remember.
Comment 8 Ilia Mirkin 2014-08-28 18:52:15 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > So... it worked in debian. What linux kernel was that with?
> 
> Sorry, I don't remember.

OK. Well, the most likely way for you to get this resolved is to identify the kernel commit that caused the issue. In order to do that you need to find a kernel version that worked fine. Good candidates to try out are

3.2
3.6
3.9

(IIRC 3.2 is what one of the debian versions likes to use, 3.6 is before 3.7 which had a ton of changes, and 3.10 had a bunch as well iirc.) If any of those works, you need to do a bisect between that version and whatever the earliest kernel you're aware of that *doesn't* work. Hopefully it won't be some mega-change-everything commit.
Comment 9 Neven Sajko 2014-08-31 22:49:47 UTC
I built and installed linux 3.2 and it also didn't give a display after suspend.
I took a kernel log again while the display didn't work, and it seems that Nouveau didn't make any errors!? I'll upload it as linux3.2_log.txt.
Maybe I should try installing some stock, current distro to see if the problem is present there too.
Comment 10 Neven Sajko 2014-08-31 22:52:40 UTC
Created attachment 105515 [details]
kernel log from linux 3.2


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.