Bug 7998 - no dma on swsusp resume/suspend
no dma on swsusp resume/suspend
Status: CLOSED INSUFFICIENT_DATA
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend
i386 Linux
: P2 normal
Assigned To: Rafael J. Wysocki
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2007-02-13 01:00 UTC by maximilian attems
Modified: 2007-09-07 01:13 UTC (History)
0 users

See Also:
Kernel Version: 2.6.20
Tree: Mainline
Regression: ---


Attachments
dmesg output for one swsusp run (4.58 KB, text/plain)
2007-02-13 01:02 UTC, maximilian attems
Details
lspci x41 output (12.78 KB, text/plain)
2007-02-13 01:02 UTC, maximilian attems
Details
lsmod output (3.28 KB, text/plain)
2007-02-13 01:04 UTC, maximilian attems
Details

Description maximilian attems 2007-02-13 01:00:44 UTC
Most recent kernel where this bug did *NOT* occur: happens since 2.6.16 (no idea
about before)
Distribution: Debian Etch 4.0
Hardware Environment: ibm thinkpad x41
Software Environment:
Problem Description: slow suspend and resume

Steps to reproduce: echo disk > /sys/power/state
Comment 1 maximilian attems 2007-02-13 01:02:00 UTC
Created attachment 10400 [details]
dmesg output for one swsusp run
Comment 2 maximilian attems 2007-02-13 01:02:43 UTC
Created attachment 10401 [details]
lspci x41 output
Comment 3 maximilian attems 2007-02-13 01:04:00 UTC
Created attachment 10402 [details]
lsmod output

swsusp runs always with all those loaded.
Comment 4 maximilian attems 2007-02-14 03:24:03 UTC
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.
Comment 5 Rafael J. Wysocki 2007-05-30 10:28:58 UTC
Hmm, what exactly do you think is wrong?

There's nothing suspicious in the dmesg output.
Comment 6 maximilian attems 2007-06-03 08:14:13 UTC
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
Comment 7 Rafael J. Wysocki 2007-06-04 09:20:38 UTC
> if you need some timing i can clock

Yes, please.
Comment 8 maximilian attems 2007-06-12 09:46:23 UTC
40 seconds for writing the image
Comment 9 Tejun Heo 2007-06-14 01:51:55 UTC
What's the result of 'hdparm -t /dev/sda'?
Comment 10 Tejun Heo 2007-06-14 02:14:52 UTC
Also, how much memory do you have?
Comment 11 maximilian attems 2007-06-14 03:29:54 UTC
hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   58 MB in  3.09 seconds =  18.76 MB/sec

1g, see
 cat /proc/meminfo 
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

Comment 12 Tejun Heo 2007-06-14 03:56:44 UTC
18.76MB/s * 40s is ~750Mbytes, which isn't unusual for swsusp image size.  Is it a 4700rpm harddrive?
Comment 13 maximilian attems 2007-09-07 01:13:08 UTC
it is a 4200rpm harddrive closing the bug.

Note You need to log in before you can comment on or make changes to this bug.