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
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?
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... (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.
(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?
(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.
(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?
(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.
(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.
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.
Created attachment 105515 [details] kernel log from linux 3.2
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/129.
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.