Bug 34429 - [PATCH]Failure during resume on NV50: INIT_AUXCH: rd auxch fail -121
[PATCH]Failure during resume on NV50: INIT_AUXCH: rd auxch fail -121
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/nouveau
git
x86-64 (AMD64) Linux (All)
: medium major
Assigned To: Nouveau Project
Xorg Project Team
: patch
Depends on: 27398 31676
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-18 00:55 UTC by Fabian Moser
Modified: 2012-06-10 02:09 UTC (History)
2 users (show)

See Also:


Attachments
Kernel messages from boot thorugh suspend to resume (90.61 KB, text/plain)
2011-02-18 00:55 UTC, Fabian Moser
no flags Details
Power manager activities during suspend/resume (11.46 KB, text/plain)
2011-02-18 00:56 UTC, Fabian Moser
no flags Details
Xorg messages from boot to resume (39.13 KB, text/x-log)
2011-02-18 00:57 UTC, Fabian Moser
no flags Details
dmesg output with "drm.debug=14" (649.82 KB, text/plain)
2011-02-25 14:30 UTC, Yuriy Khomchik
no flags Details
dmesg from the nouveau git (965.28 KB, text/plain)
2011-09-09 06:09 UTC, Yuriy Khomchik
no flags Details
Apply power to the panel before enabling hotplug interrupts and before communicating with the panel on the I2C bus (1.02 KB, patch)
2012-01-29 00:51 UTC, Yuriy Khomchik
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Moser 2011-02-18 00:55:56 UTC
Created attachment 43511 [details]
Kernel messages from boot thorugh suspend to resume

Upon return from suspend, the display turns white and stays that way. The X server is unusable. Other VTs as well. The problem is 100% reproducible.

I'm using openSUSE 11.4 RC 1 on an HP 8440p with a NVS 3100m card (GT218M, thus NV50-type). I reported first at https://bugzilla.novell.com/show_bug.cgi?id=669932 and was asked to report here. 

I'm using packages dating git20110210 from http://download.opensuse.org/repositories/home:/jobermayr/openSUSE_Factory/x86_64/ 

Since the problem is reproduced every time, I would be happy to help if I can provide debugging information. The installation currently is dedicated for this sole purpose (I need suspend-resume in a would-be production system).

Bugs I found related but IMO still different enough to report this one:
https://bugs.freedesktop.org/show_bug.cgi?id=25762
https://bugs.freedesktop.org/show_bug.cgi?id=25410
Comment 1 Fabian Moser 2011-02-18 00:56:48 UTC
Created attachment 43512 [details]
Power manager activities during suspend/resume
Comment 2 Fabian Moser 2011-02-18 00:57:22 UTC
Created attachment 43513 [details]
Xorg messages from boot to resume
Comment 3 Fabian Moser 2011-02-22 07:57:49 UTC
An apparently similar issue has been reproduced during Fedora 15 nouveau Test Day with the provided Live ISO.
Comment 4 Yuriy Khomchik 2011-02-25 12:41:19 UTC
I have a similar problem on the same hardware with Ubuntu 11.04 Alpha 2.
dmesg output contains the same lines:
  ...
  [drm] nouveau 0000:01:00.0: Restoring mode...
  [drm] nouveau 0000:01:00.0: INIT_AUXCH: rd auxch fail -121
  [drm] nouveau 0000:01:00.0: INIT_AUXCH: rd auxch fail -121
  [drm] nouveau 0000:01:00.0: 0xBDCC: auxch rd fail: -121
  [drm] nouveau 0000:01:00.0: INIT_AUXCH: rd auxch fail -121
  ...
Comment 5 Yuriy Khomchik 2011-02-25 14:30:07 UTC
Created attachment 43841 [details]
dmesg output with "drm.debug=14"
Comment 6 Yuriy Khomchik 2011-04-25 15:05:58 UTC
Probably this bug is similar to bug 27398. Common features:
1. Identical lines in dmesg output (INIT_AUXCH: rd auxch fail -121).
2. Displays are connected via DisplayPort (bug 34429 - eDP, bug 27398 - DP).
3. Displays have not been initialized by BIOS (bug 34429 - after resume, bug 27398 - external display).
Comment 7 Yuriy Khomchik 2011-07-15 15:03:14 UTC
Similar bug: bug 31676.
Comment 8 Yuriy Khomchik 2011-09-09 06:09:20 UTC
Created attachment 50998 [details]
dmesg from the nouveau git
Comment 9 Yuriy Khomchik 2011-09-09 06:13:28 UTC
Bug still reproduced on the latest git version. See attached dmesg log.
Comment 10 Yuriy Khomchik 2012-01-29 00:51:57 UTC
Created attachment 56275 [details] [review]
Apply power to the panel before enabling hotplug interrupts and before communicating with the panel on the I2C bus
Comment 11 Ben Skeggs 2012-01-30 20:21:30 UTC
(In reply to comment #10)
> Created attachment 56275 [details] [review] [review]
> Apply power to the panel before enabling hotplug interrupts and before
> communicating with the panel on the I2C bus

I just pushed a slightly different version of this patch to nouveau git.
Comment 12 Yuriy Khomchik 2012-01-30 23:48:45 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > Created attachment 56275 [details] [review] [review] [review]
> > Apply power to the panel before enabling hotplug interrupts and before
> > communicating with the panel on the I2C bus
> 
> I just pushed a slightly different version of this patch to nouveau git.

Thanks, Ben.
Comment 13 Ben Skeggs 2012-01-31 00:46:10 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > Created attachment 56275 [details] [review] [review] [review] [review]
> > > Apply power to the panel before enabling hotplug interrupts and before
> > > communicating with the panel on the I2C bus
> > 
> > I just pushed a slightly different version of this patch to nouveau git.
> 
> Thanks, Ben.

No worries.  Thanks for tracking down the root cause of this.  I was aware of this GPIO function previously, but didn't honestly expect any VBIOS init table to default it to off when there was a panel attached :)
Comment 14 Emil Velikov 2012-06-10 02:09:29 UTC
As mentioned, the fix has been pushed. Please reopen if the issue persist