Viestissä Lauantai 16 Elokuu 2003 13:19, Adam Williamson kirjoitti: > On Sat, 2003-08-16 at 04:35, Thomas Backlund wrote: > > Viestissä Lauantai 16 Elokuu 2003 03:50, Adam Williamson kirjoitti: > > > I've just started noticing this since I came in from work, about > > > 10:30pm. Since then I've updated to kernel 0.5mdk and a few other minor > > > updates (lm_sensors 2.8.0 and a couple of other small things). Certain > > > things, between which I can't find much of a link, seem to slow the > > > system down *massively*; the two I've noticed most so far are running > > > urpmi --auto-select, and saving a file with Galeon. When doing either > > > of these, the system becomes incredibly sluggish to respond - if I > > > bring a window forward, for instance, I can watch it redrawing in > > > separate stages, with several seconds between each, and the whole > > > system just has the very sluggish response you'd expect if 100% CPU > > > were being used or something. top does not report 100% CPU usage, > > > though. Anyone else seeing this? Any idea what the problem is? > > > > Just a thought... what does : > > # hdparm -iv /dev/hda > > > > tell you when it happends... > > > > here is mine (just an example of what you should see) > > /dev/hda: > > multcount = 16 (on) > > IO_support = 1 (32-bit) > > unmaskirq = 1 (on) > > using_dma = 1 (on) > > keepsettings = 0 (off) > > readonly = 0 (off) > > readahead = 8 (on) > > No, it's nothing to do with DMA or IO. hdparm is the very first thing I > check in such cases.
The reason I asked was because Stefan did see his nForce2 system drop out of dma under heavy load, and it newer recovered correctly, the problem with that is that I'm not able to reproduce the bug, so I wondered if you had the same problem.. Now on with the questions... Do you use acpi=on or acpi=off? Have you tried noapic? Does your m/b have any other integrated nic? is it supported, and if so does it behave the same way? Thomas
