Bug 7998 - no dma on swsusp resume/suspend
Summary: no dma on swsusp resume/suspend
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Rafael J. Wysocki
URL:
Keywords:
Depends on:
Blocks: 7216
  Show dependency tree
 
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
Subsystem:
Regression: ---
Bisected commit-id:

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
Add an attachment (proposed patch, testcase, etc.)

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.