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
Created attachment 43512 [details] Power manager activities during suspend/resume
Created attachment 43513 [details] Xorg messages from boot to resume
An apparently similar issue has been reproduced during Fedora 15 nouveau Test Day with the provided Live ISO.
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 ...
Created attachment 43841 [details] dmesg output with "drm.debug=14"
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).
Similar bug: bug 31676.
Created attachment 50998 [details] dmesg from the nouveau git
Bug still reproduced on the latest git version. See attached dmesg log.
Created attachment 56275 [details] [review] Apply power to the panel before enabling hotplug interrupts and before communicating with the panel on the I2C bus
(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.
(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.
(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 :)
As mentioned, the fix has been pushed. Please reopen if the issue persist
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.