+++ This bug was initially created as a clone of Bug #569074 +++ Description of problem: Resuming after suspend fails on this Ideapad Y550 which has an NV50 (NVIDIA GeForce GT 130M). Version-Release number of selected component (if applicable): 2.6.34-20.fc14.x86_64 How reproducible: always Steps to Reproduce: 1. suspend 2. resume 3. screen stays black (INIT_ZM_I2C_BYTE fails) --- Additional comment from bskeggs on 2010-06-06 19:03:02 EDT --- (In reply to comment #6) > (In reply to comment #5) > > Bad news is the display still stays blank after resume. Here are the details > from the log: > > kernel: [drm] nouveau 0000:01:00.0: 0xD62F: Failed parsing init table opcode: > INIT_ZM_I2C_BYTE -6 This is likely the reason why. I'd say there's more setup for your card in that init table that we're skipping because INIT_ZM_I2C_BYTE fails. Can you file a new bug report against rawhide to track this issue please. It'd be great if you could include your dmesg output after a suspend/resume with "drm.debug=14 log_buf_len=1M" appended to your boot options, as well as a vbios image (I may want vbtracetool traces later too, but we'll discuss that when you open a new bug). Thanks!
Created attachment 421689 [details] drm.debug=14 messages log Doesn't seem like drm.debug=14 increased the verbosity of the drm debugging. Not sure what I'm missing.
Yeah, you need to use the "dmesg" command. The debug level messages don't make it to /var/log/messages.
Created attachment 421692 [details] vbios vbios collected with: sudo ./vbtracetool -w 2>/tmp/vbios.rom
Created attachment 421695 [details] gzip'd dmesg output dmesg with drm.debug=14 This dmesg also shows that a NULL pointer (comparable to bz#569074) still exists (even with rawhide's 2.6.34 kernel's use of 2.6.35-rc1's drm and ttm): BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 IP: [<ffffffffa007e701>] nouveau_ttm_io_mem_reserve+0x8d/0xb5 [nouveau]
Thanks for that :) Can I also get "./vbtracetool -lp 2>post.iolog" from you please?
Created attachment 424609 [details] gzip'd post.iolog Collected with: ./vbtracetool -lp 2>post.iolog But it blanked the screen as soon as I issued the command. I then rebooted and this file is what remained.
This is hopefully fixed in http://koji.fedoraproject.org/koji/buildinfo?buildID=183345 Can you confirm?
(In reply to comment #7) > This is hopefully fixed in > http://koji.fedoraproject.org/koji/buildinfo?buildID=183345 > > Can you confirm? Unfortunately, the screen still stays black on resume: nouveau 0000:01:00.0: power state changed by ACPI to D0 nouveau 0000:01:00.0: power state changed by ACPI to D0 nouveau 0000:01:00.0: power state changed by ACPI to D0 nouveau 0000:01:00.0: power state changed by ACPI to D0 nouveau 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 nouveau 0000:01:00.0: setting latency timer to 64 [drm] nouveau 0000:01:00.0: POSTing device... [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xD359 [drm] nouveau 0000:01:00.0: 0xD62F: i2c wr fail: -6 [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xD8A4 [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xE3D3 [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xE408 [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xE59C [drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xE601 [drm] nouveau 0000:01:00.0: Couldn't find matching output script table [drm] nouveau 0000:01:00.0: 0xC078: parsing output script 0 [drm] nouveau 0000:01:00.0: Reinitialising engines... [drm] nouveau 0000:01:00.0: Restoring GPU objects... [drm] nouveau 0000:01:00.0: Restoring mode... [drm] nouveau 0000:01:00.0: Couldn't find matching output script table [drm] nouveau 0000:01:00.0: Couldn't find matching output script table
Hmm, maybe a new issue has snuck in too. [drm] nouveau 0000:01:00.0: Couldn't find matching output script table [drm] nouveau 0000:01:00.0: Couldn't find matching output script table These weren't in previous logs. Could I see a drm.debug=14 log again please :)
Also, with nouveau loaded can you mount debugfs (mount -t debugfs debugfs /sys/kernel/debug) and attach /sys/kernel/debug/dri/vbios.rom to this bug.
Created attachment 432301 [details] vbios.rom from 2.6.35-0.36.rc4.git5.fc14.x86_64 # cat /sys/kernel/debug/dri/0/name nouveau 0000:01:00.0 pci:0000:01:00.0 # cp /sys/kernel/debug/dri/0/vbios.rom vbios.rom.`uname -r`
Created attachment 432306 [details] dmesg from 2.6.35-0.36.rc4.git5.fc14.x86_64 w/ drm.debug=14 suspend and resume was performed w/ drm.debug=14
Ben, Just FYI.. I also tried the RHEL6 kernel from rhbz#596679 and after resume with that kernel I got a rapidly flickering white screen (rather than the usual all black screen).
Mike, thank you for all of that! A sneaky regression did indeed sneak in for LVDS on some chipsets. kernel-2.6.34.1-15.fc13 is building in koji at the moment, and will hopefully fix the problem. http://koji.fedoraproject.org/koji/taskinfo?taskID=2323487
(In reply to comment #14) > Mike, thank you for all of that! A sneaky regression did indeed sneak in for > LVDS on some chipsets. > > kernel-2.6.34.1-15.fc13 is building in koji at the moment, and will hopefully > fix the problem. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=2323487 Works great, thanks Ben!
Is this fixed in rawhide 2.6.35-rc kernels?
It's fixed in kernel-2.6.35-0.54.rc5.git7.fc14