Most recent kernel where this bug did *NOT* occur: happens since 2.6.16 (no idea
Distribution: Debian Etch 4.0
Hardware Environment: ibm thinkpad x41
Problem Description: slow suspend and resume
Steps to reproduce: echo disk > /sys/power/state
Created attachment 10400 [details]
dmesg output for one swsusp run
Created attachment 10401 [details]
lspci x41 output
Created attachment 10402 [details]
swsusp runs always with all those loaded.
The strange thing is that dmesg output says that DMA is put on, but the
operation is that slow that i can read any percentage number after the other.
haven't timed it, but 30 seconds is a rough guess.
Hmm, what exactly do you think is wrong?
There's nothing suspicious in the dmesg output.
the slowness of writing the image on disc is the issue.
i can easily read any percentage nr while it is counting up.
if you need some timing i can clock. ;)
btw the bug is still reproducible with 2.6.22-rc3 and has been since .14,
with the exception of one specific rc, which i don't remember
> if you need some timing i can clock
40 seconds for writing the image
What's the result of 'hdparm -t /dev/sda'?
Also, how much memory do you have?
hdparm -t /dev/sda
Timing buffered disk reads: 58 MB in 3.09 seconds = 18.76 MB/sec
MemTotal: 1027192 kB
MemFree: 71256 kB
Buffers: 49556 kB
Cached: 302572 kB
SwapCached: 0 kB
Active: 735064 kB
Inactive: 110036 kB
HighTotal: 121728 kB
HighFree: 1100 kB
LowTotal: 905464 kB
LowFree: 70156 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 4 kB
Writeback: 0 kB
AnonPages: 492988 kB
Mapped: 60880 kB
Slab: 41188 kB
SReclaimable: 30728 kB
SUnreclaim: 10460 kB
PageTables: 2480 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 513596 kB
Committed_AS: 840612 kB
VmallocTotal: 114680 kB
VmallocUsed: 5120 kB
VmallocChunk: 109172 kB
18.76MB/s * 40s is ~750Mbytes, which isn't unusual for swsusp image size. Is it a 4700rpm harddrive?
it is a 4200rpm harddrive closing the bug.