Multiple GUI apps freezing with high I/O wait during typing

Also effecting pidgin. Could it be libgtk or libqt?

> Could it be libgtk or libqt?

Unlikely to be libgtk, and I hadn't meant to post that question. But it is something effecting multiple apps.

This is beginning to get interesting ... I use a USB keyboard when I am home (and I just got back from a trip). This APPEARS to be tied to use of the USB keyboard! If I switch to the laptop keyboard, I cannot reproduce the problem.

Since it does not happen except when using my USB keyboard, it seems invalid to leave this associated with an application.

This appears to be generic, not app specific, and happens whenever I am using an external USB keyboard, not the built-in keyboard. And only on Karmic.

See: http://lwn.net/Articles/328363/

See also Bug 424935.

See also Bug 381300, Bug 131094 and others. There has been a lot of discussion from people far more knowledgeable about kernel issues and IO WAIT than I. The truly wacky thing here is that I see this problem in Karmic when doing nothing more than just TYPING. If I run LatencyTop, I've seen:

     EXT3: Waiting for journal access 9959.4 msec 93.4 %

I've tried switching to data=writeback, but that has not fixed the issue. I have run the fsync-tester, from http://bugzilla.kernel.org/show_bug.cgi?id=12309, and received figures such as:

fsync time: 0.0293
fsync time: 0.0293
fsync time: 6.3766
fsync time: 0.0269
fsync time: 0.0258
fsync time: 0.6859
fsync time: 0.0255
fsync time: 0.0258
fsync time: 2.4765
fsync time: 0.0275
fsync time: 0.6968
fsync time: 1.7163
fsync time: 0.0270
fsync time: 0.0250
fsync time: 1.1506
fsync time: 0.6978
fsync time: 20.6614
fsync time: 0.0272
fsync time: 0.0278
fsync time: 0.0268
fsync time: 0.0329
fsync time: 0.0261
fsync time: 4.6135
fsync time: 1.9741
fsync time: 14.4094
fsync time: 0.8622
fsync time: 0.0273
fsync time: 0.0256
fsync time: 0.0354
fsync time: 0.0279

The larger numbers corresponding to times when the system is unresponsive. If I keeping typing while the system feels frozen, I can even get the Firefox windows to be marked gray until I stop typing and let the system recover.

This is the result using noop as the scheduler:

$ ./fsync-tester
fsync time: 0.0295
fsync time: 0.0276
fsync time: 0.0286
fsync time: 0.0270
fsync time: 0.0295
fsync time: 5.5557
fsync time: 24.7745
fsync time: 0.0298
fsync time: 0.0264
fsync time: 0.0260
fsync time: 0.0295
fsync time: 0.0268
fsync time: 0.0265
fsync time: 0.0269

And this with the deadline scheduler:

$ ./fsync-tester
fsync time: 0.0672
fsync time: 0.0268
fsync time: 0.0295
fsync time: 0.0282
fsync time: 0.0277
fsync time: 0.0291
fsync time: 0.0290
fsync time: 0.0277
fsync time: 5.3127
fsync time: 8.2069
fsync time: 0.0284
fsync time: 0.0263
fsync time: 0.0290

All I was doing was typing in this box. So I have no idea what to make of this, other than that I keep encountering what seems to be a serious IO WAIT problem in Karmic that I don't see anywhere else.

I don't know exactly what changed, but I was having the problem earlier today, did a large batch of updates, including linux-image 2.6.31-10-31, and the problem is no longer present. It was constantly reproducible for the past weeks, so this is a noticeable change.

I can no longer reproduce this with firefox, pidgin, or any other app that exhibited it. Assuming that it does not get re-broken with 2.6.31-10-32, and can't otherwise be reproduced tomorrow, I'll mark it as fix released.

Cannot reproduce this anymore, whereas it was consistent for weeks.

It's baaaak

Is there a limited queue for keystrokes? If I type more slowly, this does not happen, but when I type at my normal speed, this is (once again) all to easy and consistent to reproduce.

As experiment, and because I figure that I've nothing to lose, I installed 2.6.32-rc4 from the mainline PPA. No change. The high I/O Wait during typing is still present.

Reverting to Jaunty, all is well in this respect.

Reproducible with x-edgers and Mozilla daily PPAs. :-(

Not a FF bug

I wasn't getting this error on a clean install of Karmic, so I started comparing my original karmic install, which was upgraded from Jaunty, and a clean install. What I found was that I had not yet installed the hdapsd package on the clean install. From testing, I reproduced that if I stop hdapsd, the problem cannot be reproduced, and upon starting hdaps, the problem is easily reproduced.

I do not have hdaps installed and the bug is still reproducible

I can confirm that Karmic does something fishy, is it ext4 that is the culprit ?

Issuing a svn up on a large project totally hangs my freshly installed, newly bought machine but works fine at work on my Hardy installed, slower machine.

In theory my Home machine should be +- 25% faster with moer graphic mem etc but in reality is about 5 times slower....

I've mounted the working dir as both data=writeback and noatime, no luck there.

Some figures. The above mentioned svn up gives me 50% iowait and takes a huge amount of time, the same at work takes at it worst up 10% iowait and completes in no time.

I have two disks and mounted disk2 as /srv which I use as data-disk and I have my home-dir there as well. No speedup.

Cheers

//Marcus

Have you tried turing down the hdapsd sensitivity? It sounds like when you type on your keyboard that's enough movement to trigger hdapsd shutting down the HD.

No reaction since a year, and no real bug in hdapsd, setting to invalid then.