[Bug 415105] New: nvidia driver: resume from s2ram very slow (3 minutes!)
https://bugzilla.novell.com/show_bug.cgi?id=415105 Summary: nvidia driver: resume from s2ram very slow (3 minutes!) Product: openSUSE 11.0 Version: Final Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 3rd Party Driver AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: koenig@linux.de QAContact: sndirsch@novell.com Found By: --- running 11.0 x86_64 on a Lenovo T61p model 6457-5FG with nVidia Quadro FX 570M the resume from s2ram (powersave -u) takes almost 3 minutes ! using the "nv" driver does not show this problem using the same nvidia driver (173.14.9 and 173.14.12) on Ubuntu 8.04 on the same notebook, suspend/resume works like a charm (read: within seconds). when resuming from s2ram I immediately get a 1st beep, after 30s one more beep, 45s later next beep, then another 30s-45s before one more beep, and after some more waiting X11 works again:-( it takes ~70s after [starting the] resume before the notebook echos to ping (subtract maybe 5s-10s for the setup delay of our switch -- so maybe 60s after resume). triggering suspend from a text console doesn't help. using "vga=normal" instead of frame buffer console doesn't help. some time ago (befor holidays, so memory is pale and fading;) I've did some tracing for both the s2ram and the Xserver and I remeber that there are several phases where significant time is spend: - ~30+ seconds in kernel - some more delays in between next step (can't remember anymore) - ~80+ seconds in Xorg server in some vbe code looping waiting for some flag/state from ubuntu I got the hint (I've been told that this was needed on ubuntu 8.04 to avoid (similar?) resume problems) to edit /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-lenovo.fdi using this diff, but this didn't help either: --- 20-video-quirk-pm-lenovo.fdi.suse 2008-08-06 16:57:09.000000000 +0200 +++ 20-video-quirk-pm-lenovo.fdi.ubuntu 2008-08-06 16:00:50.000000000 +0200 @@ -43,13 +43,13 @@ </match> <!-- T61 (8895), intel card 32bit works with S3_MODE, but 64bit needs VBE_MODE T61p (6460), does not work with the NVidia driver--> - <match key="system.hardware.product" prefix_outof="6457;6460;6465"> + <match key="system.hardware.product" prefix_outof="6460;6465"> <merge key="power_management.quirk.s3_bios" type="bool">true</merge> <merge key="power_management.quirk.vbemode_restore" type="bool">true</merge> </match> <!-- These Thinkpads don't need a quirk: 6459 (T61p), 7664 (T60) see s2ram --> - <match key="system.hardware.product" prefix_outof="6459;7664;8918"> + <match key="system.hardware.product" prefix_outof="6457;6459;7664;8918"> <merge key="power_management.quirk.none" type="bool">true</merge> </match> I know it's triggered by the binary-only nvidia driver, but - is this a known problem for opensuse ? - is there a known fix (I'm happy with ugly dirty workarounds too;) - which information details do you need ? - do you think this problem is more related to kernel space or to user space/setup ? - what's the big difference between ubuntu 8.04 and opensuse 11.0 in this respect (using same hardware and same nvidia driver) ? thanks for any hints/pointers/questions! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=415105 User sndirsch@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=415105#c1 Stefan Dirsch <sndirsch@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.provo.novell.com |zoz@novell.com Component|X11 3rd Party Driver |Mobile Devices QAContact|sndirsch@novell.com |qa@suse.de --- Comment #1 from Stefan Dirsch <sndirsch@novell.com> 2008-08-06 09:22:29 MDT --- Reassigning to Mobile Devices team. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=415105 User koenig@linux.de added comment https://bugzilla.novell.com/show_bug.cgi?id=415105#c2 --- Comment #2 from Harald Koenig <koenig@linux.de> 2008-08-14 02:04:20 MDT --- just one more piece in this quest: I started a ssh login ito my notebook while it was still resuming and beeping. "s2ram" uses 100% cpu time and runs for more than 2 minutes: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 14611 3.7 0.0 15296 1144 ? R 08:52 2:17 /usr/sbin/s2ram so it would be a good start to get rid of those 2 minutes ;-) from what I remember from a debug session long time ago s2ram is looping in some vbe code. is that vbe stuff really necessary, or what about trying to just disable vbe in s2ram and directly jump to X11 and nvidia diver? maybe I'll play with this "sometime"... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=415105 Timo Hoenig <thoenig@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thoenig@novell.com AssignedTo|zoz@novell.com |seife@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=415105 User seife@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=415105#c3 Stefan Seyfried <seife@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #3 from Stefan Seyfried <seife@novell.com> 2008-08-18 04:52:36 MDT --- (In reply to comment #1 from Stefan Dirsch)
Reassigning to Mobile Devices team.
Why? The nvidia driver is the problem, since nv does not have it. Anyway. The whitelist contains a workaround that works without the nvidia driver. You can override the options that are used as shown here: http://en.opensuse.org/Pm-utils#Using_suspend_to_RAM_on_machines_that_are_no... I assume that S2RAM_OPTS="-f" will work for you. The FDI file does not help since we are not using the quirks from it right now.l -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=415105 User koenig@linux.de added comment https://bugzilla.novell.com/show_bug.cgi?id=415105#c4 --- Comment #4 from Harald Koenig <koenig@linux.de> 2008-08-18 07:24:03 MDT --- (In reply to comment #3 from Stefan Seyfried)
Anyway. The whitelist contains a workaround that works without the nvidia driver.
You can override the options that are used as shown here: http://en.opensuse.org/Pm-utils#Using_suspend_to_RAM_on_machines_that_are_no...
I assume that S2RAM_OPTS="-f" will work for you.
indeed, "-f" works fine for my T61p with nvidia driver! now the full sysmte/resume cycle is only (still?) ~22 seconds (with ~19 seconds system cpu time -- is there still room for more improvement ?!) for your records, here is the output of "s2ram -i" -- I've sent the full report to the suspend-devel list. --- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< --- This machine can be identified by: sys_vendor = "LENOVO" sys_product = "64575FG" sys_version = "ThinkPad T61p" bios_version = "7LETB9WW (2.19 )" --- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< --- thanks for your help!! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=415105 User seife@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=415105#c5 Stefan Seyfried <seife@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rwysocki@novell.com, pavel@novell.com --- Comment #5 from Stefan Seyfried <seife@novell.com> 2008-08-19 09:40:40 MDT --- (In reply to comment #4 from Harald Koenig)
indeed, "-f" works fine for my T61p with nvidia driver!
now the full sysmte/resume cycle is only (still?) ~22 seconds (with ~19 seconds system cpu time -- is there still room for more improvement ?!)
Sure there is. However, we need to find out where the time is spent. Maybe booting with "printk.time=1" boot parameter (or echo'ing 1 into /sys/module/printk/parameters/time before suspend) shows something in the printk timestamps during suspend. It might be a badly behaving driver or similar where unloading might help. If you find out it is a driver, just file a bug against it (component Kernel). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=415105 User koenig@linux.de added comment https://bugzilla.novell.com/show_bug.cgi?id=415105#c6 --- Comment #6 from Harald Koenig <koenig@linux.de> 2008-08-19 16:03:24 MDT --- (In reply to comment #5 from Stefan Seyfried)
(In reply to comment #4 from Harald Koenig)
indeed, "-f" works fine for my T61p with nvidia driver!
now the full sysmte/resume cycle is only (still?) ~22 seconds (with ~19 seconds system cpu time -- is there still room for more improvement ?!)
just the resume takes only 12 seconds (wall clock), which is very usable...
Sure there is. However, we need to find out where the time is spent.
Maybe booting with "printk.time=1" boot parameter (or echo'ing 1 into /sys/module/printk/parameters/time before suspend) shows something in the printk timestamps during suspend. It might be a badly behaving driver or similar where unloading might help.
I'l attach two dmesg outputs, one with wlan0 enabled (dmesg-susp-time-2) and the next one (dmesg-susp-time-4) with wifi disabled using the hardware switch from the notebook because I thought wifi initialisation might take some time, but in both cases my watch showed 12 secs for resume. if I correctly understand the timing data, it's not a single spot which takes most of the time, delays are quite distributed. spinning up the hard disk takes ~5 secs, usb takes some time too etc. I think the pure resume time of 12 secs is pretty good now (at least for now;) but thanks if you're interesed to do more optimisation, I'm happy to provide more data or do further tests... thanks again for your help making suspend usable with the nvidia driver!!! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=415105 User koenig@linux.de added comment https://bugzilla.novell.com/show_bug.cgi?id=415105#c7 --- Comment #7 from Harald Koenig <koenig@linux.de> 2008-08-19 16:04:40 MDT --- Created an attachment (id=234252) --> (https://bugzilla.novell.com/attachment.cgi?id=234252) suspend/resume dmesg timingwith wifi -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=415105 User koenig@linux.de added comment https://bugzilla.novell.com/show_bug.cgi?id=415105#c8 --- Comment #8 from Harald Koenig <koenig@linux.de> 2008-08-19 16:05:19 MDT --- Created an attachment (id=234253) --> (https://bugzilla.novell.com/attachment.cgi?id=234253) suspend/resume dmesg timing without wifi -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com