Mailinglist Archive: opensuse-bugs (7410 mails)
| < Previous | Next > |
[Bug 415105] nvidia driver: resume from s2ram very slow (3 minutes!)
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Tue, 19 Aug 2008 16:03:25 -0600 (MDT)
- Message-id: <20080819220325.640B8245390@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=415105
User koenig@xxxxxxxx added comment
https://bugzilla.novell.com/show_bug.cgi?id=415105#c6
--- Comment #6 from Harald Koenig <koenig@xxxxxxxx> 2008-08-19 16:03:24 MDT ---
(In reply to comment #5 from Stefan Seyfried)
just the resume takes only 12 seconds (wall clock), which is very usable...
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.
User koenig@xxxxxxxx added comment
https://bugzilla.novell.com/show_bug.cgi?id=415105#c6
--- Comment #6 from Harald Koenig <koenig@xxxxxxxx> 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.
| < Previous | Next > |