I confirm the bug as originally reported here, with the exception that I
have not seen it happen without a suspend/resume (which the original
reporter says happens rarely). This is with the latest Karmic as of
December 14, 2009, running on an Intel Atom based ASUS EEE 900A netbook
with the OS running off a Secure DIgital flash card plugged into the
built-in reader.
What's strange about this is that while the CPU wait fluctuates around
70% at idle when this bug is triggered (it's normally 0% when the
machine is idle and working properly), there is apparently a lot of I/O
in the form of disk reads going on. In general, roughly 2 MB/sec is
being read from the disk. This is not coming from just one process but
a bunch of them, most of which ought not do be doing much to the disk at
all. The 'iowait' utility produces the following output when the bug is
triggered and the system is idle (note that this is just one snapshot --
the actual values fluctuate):
<pre>
Total DISK READ: 1644.73 K/s | Total DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
11336 be/4 koresko 39.16 K/s 0.00 B/s 0.00 % 0.00 % compiz.real --ignor
11343 be/4 koresko 150.11 K/s 0.00 B/s 0.00 % 0.00 % mail-notification
15311 be/4 koresko 117.48 K/s 0.00 B/s 0.00 % 0.00 % python /usr/bin/iot
7717 be/4 debian-t 375.29 K/s 0.00 B/s 0.00 % 0.00 % tor
14473 be/4 koresko 427.50 K/s 0.00 B/s 0.00 % 0.00 % firefox
11065 be/4 root 110.95 K/s 0.00 B/s 0.00 % 0.00 % X :0 -br -verbose -
898 be/4 haldaemo 199.06 K/s 0.00 B/s 0.00 % 0.00 % hald --daemon=yes
13122 be/4 koresko 71.79 K/s 0.00 B/s 0.00 % 0.00 % gnome-terminal
959 be/4 root 176.22 K/s 0.00 B/s 0.00 % 0.00 % NetworkManager
1024 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % console-kit-daemon
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init
2 be/3 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 rt/3 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [migration/0]
4 be/3 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
5 rt/3 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [watchdog/0]
1025 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % console-kit-daemon
9 be/3 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [events/0]
</pre>
It is sometimes (maybe 50%) possible to recover from this by logging out
and back in again. Killing the processes iowait says are beating on the
disk does not seem to reduce the disk reads.
As far as I can tell, this has nothing to do with hibernate as suggested
by Dominik Stadler. I *have* seen the Linux VM come back in a
suboptimal state on resume from hibernation, but as far as I can tell
that's a separate bug. In the hibernate situation the swap comes back
nearly full while the RAM is only about half used, and it takes a long
time for the RAM to get fully used again; the system is sluggish
meanwhile.
--
I/O slow after resume from suspend
https://bugs.launchpad.net/bugs/455661
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
