login
Login
/
Register
Search
Search this site:
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2008
»
September
»
12
Re: [Suspend-devel] Resume performance
view
thread
Previous message: [
thread
] [
date
] [
author
]
Next message: [thread] [
date
] [
author
]
[view in full thread]
From: Pavel Machek
Subject:
Re: [Suspend-devel] Resume performance
Date: Friday, September 12, 2008 - 5:23 am
On Sun 2008-09-07 12:35:20, Anders Aagaard wrote:
quoted text
> Rafael J. Wysocki wrote: > > On Friday, 5 of September 2008, Anders Aagaard wrote: > >> Rafael J. Wysocki wrote: > >>> On Friday, 5 of September 2008, Anders Aagaard wrote: > >>>> Hi > >>> Hi, > >>> > >>> This is a kernel problem, so let's CC the LKML. > >>> > >>>> I have a intel P35 board with a quad core cpu in it, it's currently > >>>> running as a server for a small network, and I'd like to be able to shut > >>>> it down when idle, and use wake on lan to wake it up when it's needed. > >>>> Now I got that part working quite well, but for some reason I have a > >>>> long delay in resume. > >>>> > >>>> I seem to remember being able to resume this computer in 2-3 seconds > >>>> when I was testing it, now it needs 35 seconds to resume. It seems > >>>> regardless of resume options used, and it always resumes to a working > >>>> state without problems. > >>> What kernel are you using at the moment and which one was used for the > >>> testing? > >> I'm using gentoo's 2.6.25-r7, I've also tried vanilla sources. > > > > Would it be possible to test 2.6.27-rc5-gi7 from kernel.org? > > Tested, makes no difference. > > > > >>>> I've tried quite a lot of things, booting with noapic/nosmp, booting a > >>>> kernel without usb/network drivers, disabling ahci (using ata_piix > >>>> driver instead of ahci), and there's always that one long delay. And > >>>> I'm not quite sure how the kernel printk timing information works, so > >>>> I'm not sure whats causing that delay. > >>>> > >>>> Output from dmesg when booting with nosmp (to get accurate timing data): > >>>> scripts/show_delta -b "Force enabled HPET at resume" > >>>> [349.821150 < 7.039261 >] ata3.00: configured for UDMA/133 > >>>> [349.821160 < 7.039271 >] sd 2:0:0:0: [sdc] 976773168 512-byte hardware > >>>> sectors (500108 MB) > >>>> [349.821165 < 7.039276 >] sd 2:0:0:0: [sdc] Write Protect is off > >>>> [349.821166 < 7.039277 >] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 > >>>> [349.821173 < 7.039284 >] sd 2:0:0:0: [sdc] Write cache: enabled, read > >>>> cache: enabled, doesn't support DPO or FUA > >>>> [349.972801 < 7.190912 >] ata1: SATA link up 3.0 Gbps (SStatus 123 > >>>> SControl 300) > >>>> [349.979060 < 7.197171 >] ata1.00: configured for UDMA/133 > >>>> [349.979070 < 7.197181 >] sd 0:0:0:0: [sda] 976771055 512-byte hardware > >>>> sectors (500107 MB) > >>>> [349.979075 < 7.197186 >] sd 0:0:0:0: [sda] Write Protect is off > >>>> [349.979076 < 7.197187 >] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > >>>> [349.979083 < 7.197194 >] sd 0:0:0:0: [sda] Write cache: enabled, read > >>>> cache: enabled, doesn't support DPO or FUA > >>> It looks like this happens here. Can you try to unload the network driver > >>> before suspend, please? > >> I tried to build a kernel without it, and it still takes the exact same > >> amount to boot, I've also tried unloading usb drivers and it takes the > >> exact same amount of time. > > > > Can you try to boot with init=/bin/bash and suspend to RAM? (Please have a > > look at section 2 of Documentation/power/basic-pm-debugging.txt in the newer > > kernel sources). > > I checked without X before, but forgot to unload the nvidia module, that > apparently makes a big difference, I did some numbers with > scripts/show_delta -b "Back to C". > > Nvidia and X : 32 seconds > No X (same result as booting with init=/bin/bash) : 8.3 seconds > Git kernel : 8.2 seconds > Light kernel (no sound, network card and usb drivers) : 8.17 seconds > ATI card instead of nvidia : 8.22 seconds > > I think we found the problem, I already replaced nvidia hardware in one > computer to resolve another issue. Really appreciate your help on this > issue, this resume time works pretty well for me, it was a bit > ridiculous when I could boot faster than resume. > > Is 8 seconds fairly expected? My other computer (same ati card) boots > in about 2 seconds, but there's a lot less hardware in it (6 hd's and a > ton of usb devices in one computer, 1 hd and 1 usb device in the other). > I checked cold booting with and without usb devices, my light kernel > boots to /bin/bash in 2.5 seconds, normal kernel about 7-8. But I dont > see anything about usb on resume.
8 seconds sounds long but reasonable... Pavel -- (english)
http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [thread] [
date
] [
author
]
Messages in current thread:
Re: [Suspend-devel] Resume performance
, Rafael J. Wysocki
, (Fri Sep 5, 4:08 am)
Re: [Suspend-devel] Resume performance
, Anders Aagaard
, (Fri Sep 5, 6:46 am)
Re: [Suspend-devel] Resume performance
, Rafael J. Wysocki
, (Fri Sep 5, 11:43 am)
Re: [Suspend-devel] Resume performance
, Anders Aagaard
, (Sun Sep 7, 3:35 am)
Re: [Suspend-devel] Resume performance
, Rafael J. Wysocki
, (Tue Sep 9, 7:13 am)
Re: [Suspend-devel] Resume performance
, Anders Aagaard
, (Tue Sep 9, 1:09 pm)
Re: [Suspend-devel] Resume performance
, Rafael J. Wysocki
, (Tue Sep 9, 1:31 pm)
Re: [Suspend-devel] Resume performance
, Anders Aagaard
, (Tue Sep 9, 1:31 pm)
Re: [Suspend-devel] Resume performance
, Anders Aagaard
, (Thu Sep 11, 1:53 am)
Re: [Suspend-devel] Resume performance
, Pavel Machek
, (Fri Sep 12, 5:23 am)
Navigation
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Ingo Molnar
Re: [PATCH 0/3] v2 Make hierarchical RCU less IPI-happy and add more tracing
Jeremy Fitzhardinge
Re: Linux 2.6.28.10 and Linux 2.6.29.6 XEN Guest Support Broken x86_64 in BUILD
Nick Piggin
Re: [patch] CFS (Completely Fair Scheduler), v2
Gary Hade
Re: [PATCH 0/5][RFC] Physical PCI slot objects
Dave Johnson
Re: expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device?
linux-netdev
:
Arnd Bergmann
Re: 64-bit net_device_stats
Stephens, Allan
RE: [PATCH]: tipc: Fix oops on send prior to entering networked mode
frank.blaschka
[patch 3/5] [PATCH] qeth: support z/VM VSWITCH Port Isolation
Wu Fengguang
Re: [PATCH] dm9601: handle corrupt mac address
David Miller
Re: [PATCH net-2.6.24] Fix refcounting problem with netif_rx_reschedule()
git
:
Junio C Hamano
Re: [PATCH] [RFC] add Message-ID field to log on git-am operation
Junio C Hamano
Re: Handling large files with GIT
Karl
Re: [ANNOUNCE] pg - A patch porcelain for GIT
Josh Triplett
Re: [RFC][PATCH 00/10] Sparse: Git's "make check" target
Pierre Habouzit
Re: [PATCH] git-daemon: more powerful base-path/user-path settings, using formats.
git-commits-head
:
Linux Kernel Mailing List
MIPS: RBTX4939: Fix IOC pin-enable register updating
Linux Kernel Mailing List
regulator: update email address for Liam Girdwood
Linux Kernel Mailing List
[SCSI] ipr: add message to error table
Linux Kernel Mailing List
powerpc/32: Wire up the trampoline code for kdump
Linux Kernel Mailing List
USB: omap_udc: sync with OMAP tree
openbsd-misc
:
Josh Grosse
Re: error : pkg add phpMyAdmin
Brian Candler
Re: OBSD's perspective on SELinux
Jacob Meuser
Re: /dev/audio: Device busy
David Vasek
Re: Inexpensive, low power, "wall wart" computer
William Boshuck
Re: Richard Stallman...
Colocation donated by:
Syndicate