Kernel Bug Tracker – Bug 8943
After wakeup from suspend to disk, machine loops in memory clean up
Last modified: 2007-08-27 13:45:43 UTC
Most recent kernel where this bug did not occur: 126.96.36.199 (latest version used before)
Hardware Environment: 1GB RAM, Intel Pentium M ICH6
Software Environment: Kernel 188.8.131.52, KDE 3.5.7. ATI display driver version 8.40.4-x86.x86_64
Use "Suspend to disk" feature. After resuming from this, the machine loops in memory management, by trying to clean up the memory. By monitoring the memory usage you can see that the kernel tries to clean up the whole memory. The memory usage stays below 100MB, whereas more then 500MB was in use before supsend.
Therefore the machine becomes unusable because of extensivly page in/page out activity and must be rebooted.
Steps to reproduce: Run "Suspend to disk" several times. After resuming the problem occurs.
I'm not sure that I understand this very well. Can you tell us more
about how you're monitoring the memory usage, and what resutls you are
seeing and what behaviour you're observing?
- It takes very long,until the original screen is restored, after the suspend image was read
- The disk is always heavily busy
- The machine responds very slowly to any action, e.g. starting new programs, switching to a running program or a different desktop
- The memory usage is display by the tool "xosview", which show the actual used memory. Under norma circumstances, approx. 25% - 40% of the memory (of 1 GB) is used for programs and the remaining part is used for file system caching. The overall memory usage is therefore near to 1GB, without making usage of the swap disk at all. When the problem occurs, not more than 80 - 90 MB of memory ("used + shared memory") is in use and the memory usage is not increasing anymore. So it looks as if the machine tries to run all programs in 100 MB of memory only. The memory ("used + shared memory") is always between 50MB and 80 MB. So once increased to 80 MB, the machine swaps out the memory immediately once again.
Can you please try without the ATI driver?
Checked without ati display driver and also with different versions of the ati driver.
The problem is not reproducible using the "radeon" display driver or versions of the ati driver >= 8.38.6
Using versions 8.39.4 or 8.40.4 the observed problem reappears.
As workarround I will use now the 8.38.6 version of the ati driver.
Thank's for your help
OK, thanks, I'll close the report as it appears to be a memory leak in