| 2009-05-05 05:57:23 |
Chris |
description |
I seem to be affected by a bug similar to (or the same as) #79599 and #290184. I'm reporting this separately because those two bugs have been marked as "Rejected" and "Invalid", in one case with the observation that the bug policy requires a new bug to be filed when the original reporter is no longer seeing the problem. Also, I think I may have a lead on what is causing this issue.
My system: Acer Aspire 5100 laptop, 2 GB RAM, Intrepid amd64, kernel 2.6.27-11-generic #1 SMP Wed Apr 1 20:53:41 UTC 2009, ATI fglrx driver is the only proprietary module, running Gnome and Metacity with compositing enabled.
When I boot the system it is pretty fast. I can launch lots of programs and they don't take up the full 2 GB of memory, so a good fraction of it is used as cache and the swap space is empty.
After a suspend-to-ram and resume, only the first 1 GB of RAM is in use, and the swap is heavily used (about 800 MB is typical). I think this swapping is what accounts for the slowness and he heavy disk activity people are seeing.
In my case, the resume time can vary from about 5 seconds to >15 minutes (I cold-booted that time rather than keep waiting).
At a guess, it looks as if the suspend code thinks the suspended RAM can't exceed 1 GB. So when the system suspends, it swaps out everything above 1 GB. Resume is then very slow because critical parts of the OS need to get pulled back in from swap, and the system runs slowly after resume for the same reason. Strangely, the usage of real RAM tends to stay below 1 GB even after the machine has been running post-resume, so performance doesn't recover very well.
It may be relevant that my system was installed with only 1 GB of RAM in it, and upgraded to 2 GB after the install. |
I seem to be affected by a bug similar to (or the same as) #79599 and #290184. I'm reporting this separately because those two bugs have been marked as "Rejected" and "Invalid", in one case with the observation that the bug policy requires a new bug to be filed when the original reporter is no longer seeing the problem. Also, I think I may have a lead on what is causing this issue.
My system: Acer Aspire 5100 laptop, 2 GB RAM, Intrepid amd64, kernel 2.6.27-11-generic #1 SMP Wed Apr 1 20:53:41 UTC 2009, ATI fglrx driver is the only proprietary module, running Gnome and Metacity with compositing enabled.
When I boot the system it is pretty fast. I can launch lots of programs and they don't take up the full 2 GB of memory, so a good fraction of it is used as cache and the swap space is empty.
After a suspend-to-ram and resume, only the first 1 GB of RAM is in use, and the swap is heavily used (about 800 MB is typical). I think this swapping is what accounts for the slowness and he heavy disk activity people are seeing.
In my case, the resume time can vary from about 5 seconds to >15 minutes (I cold-booted that time rather than keep waiting).
At a guess, it looks as if the suspend code thinks the suspended RAM can't exceed 1 GB. So when the system suspends, it swaps out everything above 1 GB. Resume is then very slow because critical parts of the OS need to get pulled back in from swap, and the system runs slowly after resume for the same reason. Strangely, the usage of real RAM tends to stay below 1 GB even after the machine has been running post-resume, so performance doesn't recover very well.
It may be relevant that my system was installed with only 1 GB of RAM in it, and upgraded to 2 GB after the install.
UPDATE: Switching from the fglrx to the open-source ati video driver seems to have cured the problem. On my laptop it was necessary to tweak the file
/usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-acer.fdi
to add some more quirks to avoid having the screen go crazy after resume. The updated entry looks like this:
<match key="system.hardware.product" contains_outof="1520;1650;5100;5110;5570;5920">
<merge key="power_management.quirk.radeon_off" type="bool">true</merge>
<merge key="power_management.quirk.vbe_post" type="bool">true</merge>
<merge key="power_management.quirk.vbemode_restore" type="bool">true</merge>
<merge key="power_management.quirk.vbestate_restore" type="bool">true</merge>
</match>
|
|
