* Re: [Suspend-devel] Resume performance
[not found] <48C10908.60101@gmail.com>
@ 2008-09-05 11:08 ` Rafael J. Wysocki
2008-09-05 13:46 ` Anders Aagaard
0 siblings, 1 reply; 10+ messages in thread
From: Rafael J. Wysocki @ 2008-09-05 11:08 UTC (permalink / raw)
To: Anders Aagaard; +Cc: suspend-devel, LKML
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'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?
> [373.945179 < 31.163290 >] r8169: eth0: link up
> [373.952159 < 31.170270 >] PM: Writing back config space on device
> 0000:02:02.0 at offset f (was 4020100, writing 4020104)
> [373.952172 < 31.170283 >] PM: Writing back config space on device
> 0000:02:02.0 at offset 5 (was 0, writing fddf8000)
> [373.952176 < 31.170287 >] PM: Writing back config space on device
> 0000:02:02.0 at offset 4 (was 0, writing fddfd000)
> [373.952180 < 31.170291 >] PM: Writing back config space on device
> 0000:02:02.0 at offset 3 (was 0, writing 4410)
> [373.952185 < 31.170296 >] PM: Writing back config space on device
> 0000:02:02.0 at offset 1 (was 2100000, writing 2100006)
>
> Notice the long delay between all hd's found and it writing back config
> space, note that this happens with or without that network card driver
> in the kernel.
>
> Attaching full log of boot + suspend/resume cycle, kernel booted with
> nosmp/noapic, it takes the same amount of time without those options,
> but timing data gets a bit garbled.
>
> Thanks for your work so far, it's working quite well and saving me a lot
> of power doing it this way, at this point I'm just trying to get it
> faster :)
Sure, 35 seconds to resume is hardly acceptable.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Suspend-devel] Resume performance
2008-09-05 11:08 ` [Suspend-devel] Resume performance Rafael J. Wysocki
@ 2008-09-05 13:46 ` Anders Aagaard
2008-09-05 18:43 ` Rafael J. Wysocki
0 siblings, 1 reply; 10+ messages in thread
From: Anders Aagaard @ 2008-09-05 13:46 UTC (permalink / raw)
To: linux-kernel; +Cc: suspend-devel
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.
>
>> 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.
>
>> [373.945179 < 31.163290 >] r8169: eth0: link up
>> [373.952159 < 31.170270 >] PM: Writing back config space on device
>> 0000:02:02.0 at offset f (was 4020100, writing 4020104)
>> [373.952172 < 31.170283 >] PM: Writing back config space on device
>> 0000:02:02.0 at offset 5 (was 0, writing fddf8000)
>> [373.952176 < 31.170287 >] PM: Writing back config space on device
>> 0000:02:02.0 at offset 4 (was 0, writing fddfd000)
>> [373.952180 < 31.170291 >] PM: Writing back config space on device
>> 0000:02:02.0 at offset 3 (was 0, writing 4410)
>> [373.952185 < 31.170296 >] PM: Writing back config space on device
>> 0000:02:02.0 at offset 1 (was 2100000, writing 2100006)
>>
>> Notice the long delay between all hd's found and it writing back config
>> space, note that this happens with or without that network card driver
>> in the kernel.
>>
>> Attaching full log of boot + suspend/resume cycle, kernel booted with
>> nosmp/noapic, it takes the same amount of time without those options,
>> but timing data gets a bit garbled.
>>
>> Thanks for your work so far, it's working quite well and saving me a lot
>> of power doing it this way, at this point I'm just trying to get it
>> faster :)
>
> Sure, 35 seconds to resume is hardly acceptable.
>
> Thanks,
> Rafael
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Suspend-devel] Resume performance
2008-09-05 13:46 ` Anders Aagaard
@ 2008-09-05 18:43 ` Rafael J. Wysocki
2008-09-07 10:35 ` Anders Aagaard
0 siblings, 1 reply; 10+ messages in thread
From: Rafael J. Wysocki @ 2008-09-05 18:43 UTC (permalink / raw)
To: Anders Aagaard; +Cc: suspend-devel, linux-kernel
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?
> >> 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).
Thanks,
Rafael
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Suspend-devel] Resume performance
2008-09-05 18:43 ` Rafael J. Wysocki
@ 2008-09-07 10:35 ` Anders Aagaard
2008-09-09 14:13 ` Rafael J. Wysocki
2008-09-12 12:23 ` Pavel Machek
0 siblings, 2 replies; 10+ messages in thread
From: Anders Aagaard @ 2008-09-07 10:35 UTC (permalink / raw)
To: suspend-devel; +Cc: linux-kernel
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.
Thanks a lot, Anders
>
> Thanks,
> Rafael
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Suspend-devel] Resume performance
2008-09-07 10:35 ` Anders Aagaard
@ 2008-09-09 14:13 ` Rafael J. Wysocki
2008-09-09 20:09 ` Anders Aagaard
2008-09-12 12:23 ` Pavel Machek
1 sibling, 1 reply; 10+ messages in thread
From: Rafael J. Wysocki @ 2008-09-09 14:13 UTC (permalink / raw)
To: Anders Aagaard; +Cc: suspend-devel, linux-kernel
On Sunday, 7 of September 2008, Anders Aagaard wrote:
> 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?
Well, it should be a bit less than that. Usually, the resume shouldn't take
more than 5 sec.
> 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).
That may matter a lot. It would be interesting to check if detaching any of
those devices from the first machine helps. ;-)
> 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.
Of course the USB devices are also resumed and that takes time (comparable
to the boot time).
Thanks,
Rafael
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Suspend-devel] Resume performance
2008-09-09 14:13 ` Rafael J. Wysocki
@ 2008-09-09 20:09 ` Anders Aagaard
2008-09-09 20:31 ` Rafael J. Wysocki
0 siblings, 1 reply; 10+ messages in thread
From: Anders Aagaard @ 2008-09-09 20:09 UTC (permalink / raw)
To: suspend-devel; +Cc: linux-kernel
Rafael J. Wysocki wrote:
> On Sunday, 7 of September 2008, Anders Aagaard wrote:
>> 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?
>
> Well, it should be a bit less than that. Usually, the resume shouldn't take
> more than 5 sec.
>
>> 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).
>
> That may matter a lot. It would be interesting to check if detaching any of
> those devices from the first machine helps. ;-)
>
>> 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.
>
> Of course the USB devices are also resumed and that takes time (comparable
> to the boot time).
Pulling out all my usb devices takes the resume time to 30.4
>
> Thanks,
> Rafael
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Suspend-devel] Resume performance
2008-09-09 20:09 ` Anders Aagaard
@ 2008-09-09 20:31 ` Rafael J. Wysocki
2008-09-09 20:31 ` Anders Aagaard
2008-09-11 8:53 ` Anders Aagaard
0 siblings, 2 replies; 10+ messages in thread
From: Rafael J. Wysocki @ 2008-09-09 20:31 UTC (permalink / raw)
To: Anders Aagaard; +Cc: suspend-devel, linux-kernel
On Tuesday, 9 of September 2008, Anders Aagaard wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 7 of September 2008, Anders Aagaard wrote:
> >> 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?
> >
> > Well, it should be a bit less than that. Usually, the resume shouldn't take
> > more than 5 sec.
> >
> >> 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).
> >
> > That may matter a lot. It would be interesting to check if detaching any of
> > those devices from the first machine helps. ;-)
> >
> >> 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.
> >
> > Of course the USB devices are also resumed and that takes time (comparable
> > to the boot time).
>
> Pulling out all my usb devices takes the resume time to 30.4
This is with the NVidia driver I guess? So your resume appears to be 1.6 s
faster without the USB devices. Perhaps the disks also add to the latency.
If you have CONFIG_PCIEASPM set in the kernel config, you can try to unset it
and see if that changes anything.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Suspend-devel] Resume performance
2008-09-09 20:31 ` Rafael J. Wysocki
@ 2008-09-09 20:31 ` Anders Aagaard
2008-09-11 8:53 ` Anders Aagaard
1 sibling, 0 replies; 10+ messages in thread
From: Anders Aagaard @ 2008-09-09 20:31 UTC (permalink / raw)
To: suspend-devel; +Cc: linux-kernel
Rafael J. Wysocki wrote:
> On Tuesday, 9 of September 2008, Anders Aagaard wrote:
>> Rafael J. Wysocki wrote:
>>> On Sunday, 7 of September 2008, Anders Aagaard wrote:
>>>> 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?
>>> Well, it should be a bit less than that. Usually, the resume shouldn't take
>>> more than 5 sec.
>>>
>>>> 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).
>>> That may matter a lot. It would be interesting to check if detaching any of
>>> those devices from the first machine helps. ;-)
>>>
>>>> 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.
>>> Of course the USB devices are also resumed and that takes time (comparable
>>> to the boot time).
>> Pulling out all my usb devices takes the resume time to 30.4
>
> This is with the NVidia driver I guess? So your resume appears to be 1.6 s
> faster without the USB devices. Perhaps the disks also add to the latency.
Correct, and I'm also thinking it's the disks, I'll try that as soon as
I have time to power this thing off.
>
> If you have CONFIG_PCIEASPM set in the kernel config, you can try to unset it
> and see if that changes anything.
I'm back to my normal kernel, so I didn't have that config option.
>
> Thanks,
> Rafael
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Suspend-devel] Resume performance
2008-09-09 20:31 ` Rafael J. Wysocki
2008-09-09 20:31 ` Anders Aagaard
@ 2008-09-11 8:53 ` Anders Aagaard
1 sibling, 0 replies; 10+ messages in thread
From: Anders Aagaard @ 2008-09-11 8:53 UTC (permalink / raw)
To: suspend-devel; +Cc: linux-kernel
Rafael J. Wysocki wrote:
> On Tuesday, 9 of September 2008, Anders Aagaard wrote:
>> Rafael J. Wysocki wrote:
>>> On Sunday, 7 of September 2008, Anders Aagaard wrote:
>>>> 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?
>>> Well, it should be a bit less than that. Usually, the resume shouldn't take
>>> more than 5 sec.
>>>
>>>> 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).
>>> That may matter a lot. It would be interesting to check if detaching any of
>>> those devices from the first machine helps. ;-)
>>>
>>>> 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.
>>> Of course the USB devices are also resumed and that takes time (comparable
>>> to the boot time).
>> Pulling out all my usb devices takes the resume time to 30.4
>
> This is with the NVidia driver I guess? So your resume appears to be 1.6 s
> faster without the USB devices. Perhaps the disks also add to the latency.
>
> If you have CONFIG_PCIEASPM set in the kernel config, you can try to unset it
> and see if that changes anything.
I did some more testing, including the old results for referance:
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
Nvidia - usb : 30.4
Latest tests:
ati-1hd : 5.96s
ati-1hd-nousb-noups : 5.92s
ati-1hd-bios disabled firewire,network,usb : 5.74s
I was sure it was the hd's that caused the latency, oh well, in either
case it's a massive improvement from what I had.
Thanks a lot for your help, Anders.
>
> Thanks,
> Rafael
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Suspend-devel] Resume performance
2008-09-07 10:35 ` Anders Aagaard
2008-09-09 14:13 ` Rafael J. Wysocki
@ 2008-09-12 12:23 ` Pavel Machek
1 sibling, 0 replies; 10+ messages in thread
From: Pavel Machek @ 2008-09-12 12:23 UTC (permalink / raw)
To: Anders Aagaard; +Cc: suspend-devel, linux-kernel
On Sun 2008-09-07 12:35:20, Anders Aagaard wrote:
> 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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2008-09-12 12:21 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <48C10908.60101@gmail.com>
2008-09-05 11:08 ` [Suspend-devel] Resume performance Rafael J. Wysocki
2008-09-05 13:46 ` Anders Aagaard
2008-09-05 18:43 ` Rafael J. Wysocki
2008-09-07 10:35 ` Anders Aagaard
2008-09-09 14:13 ` Rafael J. Wysocki
2008-09-09 20:09 ` Anders Aagaard
2008-09-09 20:31 ` Rafael J. Wysocki
2008-09-09 20:31 ` Anders Aagaard
2008-09-11 8:53 ` Anders Aagaard
2008-09-12 12:23 ` Pavel Machek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).