https://bugzilla.novell.com/show_bug.cgi?id=741485 https://bugzilla.novell.com/show_bug.cgi?id=741485#c0 Summary: progressive system slowdown, eventually grinding to a halt. Reproducible with Konqueror Classification: openSUSE Product: openSUSE 11.4 Version: Final Platform: 64bit OS/Version: SuSE Other Status: NEW Severity: Critical Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers@forge.provo.novell.com ReportedBy: andreas_nordal_4@hotmail.com QAContact: qa@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) KHTML/4.7.2 (like Gecko) Konqueror/4.7 SUSE Note: "Operating System" should be OpenSuse 12.1 rather than "SuSE Other", but that was not an option in the menu for filing this bug. My computer slowly grinds to a halt when visiting http://tineskreativehjorne.com with Konqueror using KHTML. Symptoms: The computer gets progressively slower. From regular-slow with swapping, to painstakingly slow, to completely unusable, and infinitely beyond. It seems Linux is too busy to take user input into account (where's that 200 line patch?). Programs don't make much progress either. I managed to reproduce this a second time after emptying Konqueror's web cache. Although I think I can reproduce this systematically, I haven't tried more than twice. I have also experienced this progressive slowdown in several other ways (copying files to USB stick, copying files to network attached storage) that I don't remember equally well, all with OpenSuse 12.1, but I'll focus on the web testcase for now. System info: 2 GB RAM + 2 GB swap Processor: Core 2 Duo T8100 kernel used for the web testcase: kernel-desktop-3.1.0-1.2.1.x86_64 special kernel parameters: NOHZ=off (due to bug 579932) Reproducible: Always Steps to Reproduce: With Konqueror: 1. Set default rendering engine to KHTML 2. If having visited http://tineskreativehjorne.com before, clear the cache. 3. Go to http://tineskreativehjorne.com Actual Results: In the second reproduction, I just watched the early phase, with swap usage rising to 600 MB, and then killed Konqueror before it was too late, which immediately made the system snappy again. Thus, the description below is from the first: When Konqueror showed that it had loaded 97% of that page, things started to get slow. At first, my computer just felt regular-slow – my harddisk was swapping heroically, but I was actually able to open ksysguard, iotop, etc. However, trying to close the likely offending tab of Konqueror proved futile – I clicked the button at ~10Hz (yes I have measured my endurance clicking frequency) for a minute, at least, but there was no response! The only other open tab was showing a local directory containing 22 folders and 39 files. I had a feeling that performance was degrading, so I placed Konqueror and Ksysguard next to each other on the screen, and just let Linux swap in peace for 15 mins. When I came back, moving the mouse cursor required extreme patience. Konqueror had loaded 98% of the page. I tried killing Konqueror from Ksysguard: Right-clicking on "konqueror" and selecting "kill process", in between I had a toilet visit, and to my horror, suddenly "ksysguard" was selected for killing. However, that didn't matter, because 5 mins later, still none of them had been killed (as it turned out, I was still waiting for the confirmation dialog!), at which point I realised I had to pull the plug. Konqueror's memory use had been slowly fluctuating roughly between 1.52 and 1.57 GB all the time since measuring started (at 97% loaded). Konqueror with WebKit, and Firefox, are able to show the page without problems, using only 162 and 130 MB memory, respectively. After having succeeded to show the page using WebKit in Konqueror, switching to KHTML again did not make it fail, and it just used 254 MB memory. However, all I did from this state to reproduce, was to reopen* Konqueror, empty its cache, and go to the page again. *Since I am also seeing this bug: https://bugs.kde.org/show_bug.cgi?id=257012 what I mean by "reopen"ing Konqueror is actually close, kill, open. Expected Results: No program should be able to cause significantly worse system slowdown than a dedicated memory leaker like this C program (which achieves only "regular-slow" on my scale): #include int main(){ for(;;) malloc(4096-8); } I could not create a working offline testcase because Firefox's Save->"webpage: complete", for this particular site, fails to save everything except the html file, as does "wget -p". Other ways to reproduce: I remember the same progressive slowdown when trying to install the OpenSuse KDE live-CD to a USB stick. Unetbootin failed every time (I didn't know I had to use Imagewriter). After a few tries, my computer became slower. The next attempt seemed to take forever, and in that time, the user interface had become dead slow. I had to pull the plug then too. These might look related to my USB scenario above: bug 710133 https://bugzilla.kernel.org/show_bug.cgi?id=15783 However, they aren't about _progressive_ slowdown. Also, I don't see any "page allocation failure" messages in dmesg after the web testcase, as talked about in the second. What I see (excluding the boot phase) is 3 types of messages that are network related (starting with SFW2-INext, martian source, and ll header). I guess they are unrelated. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.