Comment 6 for bug 232197

I also see this on one of my two setups.

Dell E1405 laptop, 1GB RAM, hardy 8.04, kernel 2.6.24-19 x86, Core T2300 x86, intel 945 graphics, 1440x900: everything is ok (Firefox3)

Dell D830, hardy 8.04, 2GB RAM, kernel 2.6.24-19 64 bit, Core T7300, nVidia Quadro NVS 135M, 1920x1200: Firefox3, Opera, Epiphany freeze consistently on certain sites. Firefox2 does not freeze on the same sites.

I have Compiz disabled on the D830. Enabling it doesn't impact the firefox freeze problem. I also tried the latest driver directly from nvidia, and that also had no effect on the FF freeze.

When Firefox3 freezes, all of X becomes unresponsive for several seconds, about 10 seconds. I can move the mouse around smoothly, but nothing else seems to be alive. I have a few system graphs in my gnome panel that normally update every 250ms, and they all freeze. When they come back, the intermediate seconds are not recorded on the graphs, strangely. Even hitting Ctrl-Alt-F1 to get a console does not happen until the freeze is over. I get in /var/log/Xorg.0.log multiple entries of:

tossed event which came in late
mieqEnequeue: out-of-order valuator event; dropping.

I'm guessing those log entries are a symptom and not indicative of the cause. I think I've seen this in other apps besides web browsers, but it's much more sporadic. Right now it will freeze 100% of the time in firefox-3 at certain pages. The one I get it at is: http://grails.org/GORM+-+Defining+relationships. I actually don't get any freeze at stogame.net like the above poster did.

I just noticed this only seems to only happen when the firefox window is above a certain size. when i resize the window on the troublesome web site, so it's small, say about 25% of the screen surface area or approx 960x600, it seems ok and doesn't freeze. I can resize it and it will respond quickly as long as the size is small. but when the size gets above a certain amount, it will get very slow, and freeze for seconds. The larger the surface area, the longer the freeze seems to be.

You know, this reminds me of behavior I've seen programming for image buffers on accelerated graphics cards. If you tried to allocate an image buffer above what the graphics hardware could handle, the driver would fall back to a non-accelerated software buffer, which was much slower. Maybe that's what's going on but for some reason it locks some critical system resource as it accesses the slow software image buffer, so all the other processes get blocked. Just a total guess there.