Re: [Cooker] weird slowdowns with Cooker today
Not directly connected, it's connected through a firewalled router. I doubt that's the answer, because the system response is fine all the time except when there's network traffic *to this system*. Look following Linux kernel mailing list summary from the kerneltraffic.org: Mika -- 1. Progress Toward 2.4.22; Problems With BitKeeper Gateway; Mysterious Kernel Lockups 5 Jul - 2 Aug (63 posts) Archive Link: Linux 2.4.22-pre3 Topics: FS: devfs, Version Control People: Ben Collins, Larry McVoy, Adrian Bunk, Marcelo Tosatti, Jim Gifford, Andrea Arcangeli, Jeff Garzik Marcelo Tosatti announced 2.4.22-pre3, and Ben Collins complained that the -pre version number was not shown in the sources. Neither -pre2 nor -pre3 had proper version tagging, he said, adding, It just makes it easier when tracking down regressions to have known points of reference common across BK/CVS/SVN/tar+diff. Marcelo said the sources looked properly tagged to him, and Larry McVoy asked, Hmm. Ben, look again in the CVS tree and make sure that the tags aren't there. Maybe the converter screwed up? Ben replied, Doesn't show up in linux-2.4/ChangeSet,v as a tag. Adrian Bunk also pointed out, -pre2 and -pre3 are also missing at http://ftp.kernel.org/pub/linux/kernel/v2.4/testing/cset/.; Jeff Garzik confirmed that whatever other problems there were, Marcelo had definitely tagged his own BitKeeper tree properly. A couple days later, Larry said, I think I've found the bug - it's in the code that collapses multiple changesets into one CVS checkin. It looks like we are picking up tags only if the tag was on the last changeset in the sequence instead of any changeset in the sequence. We're fixing it. Ben thanked him, and that was it for that subthread. Elsewhere, Jim Gifford reported on an ongoing problem he'd been having with the 2.4 series: lockups, after about two days. The 2.4.22-pre3 did not fix his problem, he said, although he could avoid the crash by running 'sync' every hour. Marcelo and Alan asked for more information, and together they eliminated compiler versions and bad memory. Jim continued to reproduce the problem over the course of several new pre-releases. At one point Marcelo noticed that Jim's kernel was not based on pristine sources (Jim had added some netfilter and megaraid patches), and asked if Jim could reproduce the lockups with the official kernel. Yes, the lockups still persisted. Andrea Arcangeli also got into the act, asking Jim to remove devfs and other modules that were not part of the main tree. Jim did this, and was unable to produce the lockup in -pre7. He asked if Marcelo wanted him to run other tests, but Marcelo replied, I guess most of us is already convinced that the lockups were caused by the non-stock code. But Jim tried running the stock -pre6 kernel, and was able to reproduce the lockup. He said, something in -pre7 seems to have fixed the problem. So he started adding the non-stock code back into -pre7, and later -pre8, piece by piece, to see if any of them would cause the problem. Eventually he felt he'd narrowed the problem down to some netfilter patches he'd applied; and Marc Heckmann, who also experienced similar lockups on his system, remarked that everyone who'd seen the problem had been using iptables. The situation was quite complex, and there was no absolutely clear resolution on the list. As Jim put it toward the end of the discussion, The wierd part is that people are having problems with different modules and it's hard to track down what is in common.
Re: [Cooker] weird slowdowns with Cooker today
On Sat, 2003-08-16 at 02:59, Ron Stodden wrote: Yes, I know this problem. You can avoid rebooting by: 1. Check that your swapfile is not full. If it is, generate a much bigger one. My swapfile is 1.5GB. Not likely to be the problem. Tip: Use a console (Ctrl+Alt+F2), log in as root, and run top. Swapfile stats are at the top. This will then be there whenever you want it. whether KDE is running or not. Don't run it from KDE, because of 2 below. Yes, thanks, I knew that. 2. When things slow down do Ctrl+Alt+Backspace and relog on. This is quick and will give you a new KDE and current applications setup. Particularly in this case a new Mozilla/Galeon, which in my case seems to trigger the slowdown problem. Not practical. Besides, I use GNOME. Can you check and see if the problem is linked directly to network transfers, as it seems to be for me ATM? Any type of heavy network transfer slows the system down. -- adamw
Re: [Cooker] weird slowdowns with Cooker today
On Sat, 2003-08-16 at 06:52, Tom Brinkman wrote: On Friday August 15 2003 08:08 pm, Adam Williamson wrote: K, so to reply to myself again, I realised I was once more being silly, and drew the obvious link between the two, and yes, the problem is heavy network usage. Basically, downloading a file from the internet will trigger it; do it any which way (urpmi, galeon, wget) and the system immediately begins to resemble treacle. I hope someone not using nvnet is seeing this, because if they aren't, it might be difficult to sort you never should'a chose a nforce chipset to begin with no problems here, kt400a, xp3000+ overclocked to 2288, and better performance than nF2. Face it, nVidia is a last resort, not a choice. Stop trolling; it's entirely irrelevant. This post was utterly and entirely pointless. (And besides, nforce2 is consistently shown to be substantially faster than the kt400, and kt400a was not available when I built the system. There are also no SFF PCs available based around the VIA chipsets. Is that enough reasons for you yet?) -- adamw
Re: [Cooker] weird slowdowns with Cooker today
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. -- adamw
Re: [Cooker] weird slowdowns with Cooker today
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
Re: [Cooker] weird slowdowns with Cooker today
On Sat, 2003-08-16 at 12:03, Thomas Backlund wrote: 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? acpi=off - ACPI still doesn't seem to work right on nforce2, the USB bus doesn't work. Not tried noapic, will do in a few minutes. Does your m/b have any other integrated nic? No. is it supported, and if so does it behave the same way? N/A. I do have a PCI network card lying around somewhere, I think - I may plug that in and try it out tonight. -- adamw
Re: [Cooker] weird slowdowns with Cooker today
On Sat, 2003-08-16 at 12:03, Thomas Backlund wrote: 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.. Oh, and just to clarify, remember it's heavy **NETWORK** load I'm talking about. Heavy disk load is fine; I'm testing this now by running updatedb, system response is fine. -- adamw
Re: [Cooker] weird slowdowns with Cooker today
On Sat, 2003-08-16 at 01:50, Adam Williamson wrote: 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? OK, more info, this is a little weird...I've booted with kernel-multimedia to try that, and the problem is still there, but it's not as *bad* - the system response is still sluggish under file downloads, but not *as* sluggish as with the main kernel. I'm really confused now...:) -- adamw
Re: [Cooker] weird slowdowns with Cooker today
On Sat, 16 Aug 2003, Adam Williamson wrote: OK, more info, this is a little weird...I've booted with kernel-multimedia to try that, and the problem is still there, but it's not as *bad* - the system response is still sluggish under file downloads, but not *as* sluggish as with the main kernel. I'm really confused now...:) Is this machine connected directly to the internet? Maybe you're the victim of excessive traffic / bad packets from infected Windows boxes? Some linux boxes routing on our university network apparently took some beating from blaster-infected machines ... Regards, Buchan -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7 ** Please click on http://www.cae.co.za/disclaimer.htm to read our e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy. **
Re: [Cooker] weird slowdowns with Cooker today
Adam Williamson wrote: On Sat, 2003-08-16 at 02:59, Ron Stodden wrote: Yes, I know this problem. You can avoid rebooting by: 1. Check that your swapfile is not full. If it is, generate a much bigger one. My swapfile is 1.5GB. Not likely to be the problem. Tip: Use a console (Ctrl+Alt+F2), log in as root, and run top. Swapfile stats are at the top. This will then be there whenever you want it. whether KDE is running or not. Don't run it from KDE, because of 2 below. Yes, thanks, I knew that. But the 1000 or so lurkers may not g, and should be grateful.. 2. When things slow down do Ctrl+Alt+Backspace and relog on. This is quick and will give you a new KDE and current applications setup. Particularly in this case a new Mozilla/Galeon, which in my case seems to trigger the slowdown problem. Not practical. Besides, I use GNOME. Can you check and see if the problem is linked directly to network transfers, as it seems to be for me ATM? Any type of heavy network transfer slows the system down. No, heavy network transfer (eg d/l cooker at broadband 300Kbs for half an hour, say) has no detectable performance penalty on anything. Processor is a 2.0GHz Pentium, memory 266MHz. -- Ron. [Melbourne, Australia] "If you keep a green bough in your heart, the singing bird will come" Get Fastest Mandrake downloader, English-only, from: http://members.optusnet.com.au/ronst/ Click all ye faithful!
Re: [Cooker] weird slowdowns with Cooker today
On Saturday 16 August 2003 08:05 am, Ron Stodden wrote: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head meta http-equiv=Content-Type content=text/html;charset=ISO-8859-1 title/title /head body Adam Williamson wrote:br blockquote type=cite cite=[EMAIL PROTECTED] pre wrap=On Sat, 2003-08-16 at 02:59, Ron Stodden wrote: /pre blockquote type=cite pre wrap=Yes, I know this problem. You can avoid rebooting by: 1. Check that your swapfile is not full. If it is, generate a much bigger one. /pre /blockquote pre wrap=! My swapfile is 1.5GB. Not likely to be the problem. /pre blockquote type=cite pre wrap=Tip: Use a console (Ctrl+Alt+F2), log in as root, and run top. Swapfile stats are at the top. This will then be there whenever you want it. whether KDE is running or not. Don't run it from KDE, because of 2 below. /pre /blockquote pre wrap=! Yes, thanks, I knew that./pre /blockquote But the 1000 or so lurkers may not lt;ggt;, and should be grateful..br blockquote type=cite cite=[EMAIL PROTECTED] blockquote type=cite pre wrap=2. When things slow down do Ctrl+Alt+Backspace and relog on. This is quick and will give you a new KDE and current applications setup. Particularly in this case a new Mozilla/Galeon, which in my case seems to trigger the slowdown problem. /pre /blockquote pre wrap=! Not practical. Besides, I use GNOME. Can you check and see if the problem is linked directly to network transfers, as it seems to be for me ATM? Any type of heavy network transfer slows the system down. /pre /blockquote No, heavy network transfer (eg d/l cooker at broadband 300Kbs for half an hour, say) has no detectable performance penalty on anything.nbsp;nbsp;nbsp;nbsp; Processor is a 2.0GHz Pentium, memory 266MHz.br pre class=moz-signature cols=72-- Ron. [Melbourne, Australia] If you keep a green bough in your heart, the singing bird will come Get Fastest Mandrake downloader, English-only, from: a class=moz-txt-link-freetext href=http://members.optusnet.com.au/ronst/;http://members.optusnet.com.au /ronst//a Click all ye faithful! /pre /body /html HTML??? On Cooker??? Hmm -- Ken Thompson WA7SYR Payette, Idaho Email: [EMAIL PROTECTED] Linux- Coming Soon To A Desktop Near You Registered Linux User #183936
Re: [Cooker] weird slowdowns with Cooker today
On Sat, 2003-08-16 at 14:29, Buchan Milne wrote: On Sat, 16 Aug 2003, Adam Williamson wrote: OK, more info, this is a little weird...I've booted with kernel-multimedia to try that, and the problem is still there, but it's not as *bad* - the system response is still sluggish under file downloads, but not *as* sluggish as with the main kernel. I'm really confused now...:) Is this machine connected directly to the internet? Maybe you're the victim of excessive traffic / bad packets from infected Windows boxes? Some linux boxes routing on our university network apparently took some beating from blaster-infected machines ... Not directly connected, it's connected through a firewalled router. I doubt that's the answer, because the system response is fine all the time except when there's network traffic *to this system*. -- adamw
Re: [Cooker] weird slowdowns with Cooker today
I am not sure if this is relevant for your case. I assembled a PC based on the MSI-6570 K7N2 Delta (Nforce2) MB with an Athlon XP (Barton) CPU. The first I noticed was that it would now and then freeze during e2fsck on large file systems. I did an extensive memory test without finding any faults, so the situation was unclear. Then I stumbled across a description of how to lower the CPU temperature by enabling the powersaving mode of the AMD Athlon/Duron processors. I found the Linux program athcool at http://members.jcom.home.ne.jp/jacobi/linux/softwares.html The following statement caught my attention: WARNING: Depending your motherboard and/or hardware components, enabling Athlon powersaving mode sometimes causes that (1) noisy sound playback (2) slowdown harddisk performance (3) system hangup or instable Evidently I was having (3) without having enabled powersaving. BUT: it turned out that the powersaving bit was turned on from the very start, presumably by the bios. After having turned off the powersaving bit by athcool I have NEVER had any single case of instability. I have had a few hangups during the boot-up procedure before powersaving was turned on. I did post a report on this problem on the MSI forum, but I have had absolutely ZERO response. Bjarne Thomsen lspcidrake -v unknown : Nvidia Corporation|nForce2 AGP Controller [BRIDGE_HOST] (vendor:10de device:01e0) unknown : Nvidia Corporation|nForce2 Memory Controller [MEMORY_RAM] (vendor:10de device:01eb subv:1462 subd:5700) unknown : Nvidia Corporation|nForce2 Memory Controller [MEMORY_RAM] (vendor:10de device:01ee subv:1462 subd:5700) unknown : Nvidia Corporation|nForce2 Memory Controller [MEMORY_RAM] (vendor:10de device:01ed subv:1462 subd:5700) unknown : Nvidia Corporation|nForce2 Memory Controller [MEMORY_RAM] (vendor:10de device:01ec subv:1462 subd:5700) unknown : Nvidia Corporation|nForce2 Memory Controller [MEMORY_RAM] (vendor:10de device:01ef subv:1462 subd:5700) unknown : Nvidia Corporation|nForce2 LPC / Legacy / System Management [BRIDGE_ISA] (vendor:10de device:0060 subv:1462 subd:5700) unknown : Nvidia Corporation|nForce2 SMBus 2.0 Controller [SERIAL_SMBUS] (vendor:10de device:0064 subv:1462 subd:5700) usb-ohci: Nvidia Corporation|nForce2 USB 1.0 OHCI Controller [SERIAL_USB] (vendor:10de device:0067 subv:1462 subd:5700) usb-ohci: Nvidia Corporation|nForce2 USB 1.0 OHCI Controller [SERIAL_USB] (vendor:10de device:0067 subv:1462 subd:5700) ehci-hcd: Nvidia Corporation|nForce2 USB 2.0 Enhanced Controller [SERIAL_USB] (vendor:10de device:0068 subv:1462 subd:5700) nvnet : Nvidia Corporation|nForce2 MCP Networking Adapter [NETWORK_ETHERNET] (vendor:10de device:0066 subv:1462 subd:570c) unknown : Nvidia Corporation|nForce2 APU [MULTIMEDIA_AUDIO] (vendor:10de device:006b subv:1462 subd:5700) snd-intel8x0: Nvidia Corporation|nForce2 Audio Codec Interface [MULTIMEDIA_AUDIO] (vendor:10de device:006a subv:1462 subd:5700) unknown : Nvidia Corporation|nForce2 External PCI Bridge [BRIDGE_PCI] (vendor:10de device:006c) unknown : Nvidia Corporation|nForce2 UDMA 100 IDE Controller [STORAGE_IDE] (vendor:10de device:0065 subv:1462 subd:5700) ohci1394: Nvidia Corporation|nForce2 Firewire Controller [SERIAL_FIREWIRE] (vendor:10de device:006e subv:1462 subd:570d) unknown : Nvidia Corporation|nForce2 AGP Host to PCI Bridge [BRIDGE_PCI] (vendor:10de device:01e8) aic7xxx : Adaptec|7892B [STORAGE_SCSI] (vendor:9005 device:0081 subv:9005 subd:62a1) 3c59x : 3Com Corporation|3c905C-TX [Fast Etherlink] [NETWORK_ETHERNET] (vendor:10b7 device:9200 subv:10b7 subd:1000) pdc-ultra : Promise Technology|PDC20376 FastTrak 376 Controller [STORAGE_RAID] (vendor:105a device:3376 subv:105a subd:6620) Card:NVIDIA GeForce4 (generic): NVidia|0x322 [DISPLAY_VGA] (vendor:10de device:0322 subv:1462 subd:9171) unknown : Unknown|USB OHCI Root Hub [Hub|Root Hub] (vendor: device:) unknown : Unknown|USB OHCI Root Hub [Hub|Root Hub] (vendor: device:) Removable:memory_card: JMTek|USBdisk [Mass Storage|SCSI|Bulk (Zip)] (vendor:0c76 device:0005) On Sat, 2003-08-16 at 12:21, Adam Williamson wrote: On Sat, 2003-08-16 at 06:52, Tom Brinkman wrote: On Friday August 15 2003 08:08 pm, Adam Williamson wrote: K, so to reply to myself again, I realised I was once more being silly, and drew the obvious link between the two, and yes, the problem is heavy network usage. Basically, downloading a file from the internet will trigger it; do it any which way (urpmi, galeon, wget) and the system immediately begins to resemble treacle. I hope someone not using nvnet is seeing this, because if they aren't, it might be difficult to sort you never should'a chose a nforce chipset to begin with no problems here, kt400a, xp3000+ overclocked to 2288, and better
Re: [Cooker] weird slowdowns with Cooker today
On Sun, 2003-08-17 at 00:02, Bjarne Thomsen wrote: I am not sure if this is relevant for your case. Doesn't look at all relevant, no, as this is a problem that has only manifested itself recently and is different in character from that one. But thanks for the info... -- adamw
[Cooker] weird slowdowns with Cooker today
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? -- adamw
Re: [Cooker] weird slowdowns with Cooker today
On Sat, 2003-08-16 at 01:50, Adam Williamson wrote: 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? OK, so to reply to myself again, I realised I was once more being silly, and drew the obvious link between the two, and yes, the problem is heavy network usage. Basically, downloading a file from the internet will trigger it; do it any which way (urpmi, galeon, wget) and the system immediately begins to resemble treacle. I hope someone not using nvnet is seeing this, because if they aren't, it might be difficult to sortof course, it could be related to the missing /lib/2.4.22-0./build directory problem which Thomas and I identified earlier, and which I am fudging by making a symlink to /usr/src/linux-2.4.22-0. ? If this fudge is incorrect, that could explain it. -- adamw
Re: [Cooker] weird slowdowns with Cooker today
Yes, I know this problem. You can avoid rebooting by: 1. Check that your swapfile is not full. If it is, generate a much bigger one. Tip: Use a console (Ctrl+Alt+F2), log in as root, and run top. Swapfile stats are at the top. This will then be there whenever you want it. whether KDE is running or not. Don't run it from KDE, because of 2 below. 2. When things slow down do Ctrl+Alt+Backspace and relog on. This is quick and will give you a new KDE and current applications setup. Particularly in this case a new Mozilla/Galeon, which in my case seems to trigger the slowdown problem. Adam Williamson wrote: 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? -- Ron. [Melbourne, Australia] If you keep a green bough in your heart, the singing bird will come Get Fastest Mandrake downloader, English-only, from: http://members.optusnet.com.au/ronst/ Click all ye faithful!
Re: [Cooker] weird slowdowns with Cooker today
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) ... Thomas
Re: [Cooker] weird slowdowns with Cooker today
On Friday August 15 2003 08:08 pm, Adam Williamson wrote: K, so to reply to myself again, I realised I was once more being silly, and drew the obvious link between the two, and yes, the problem is heavy network usage. Basically, downloading a file from the internet will trigger it; do it any which way (urpmi, galeon, wget) and the system immediately begins to resemble treacle. I hope someone not using nvnet is seeing this, because if they aren't, it might be difficult to sort you never should'a chose a nforce chipset to begin with no problems here, kt400a, xp3000+ overclocked to 2288, and better performance than nF2. Face it, nVidia is a last resort, not a choice. -- Tom Brinkman Corpus Christi, Texas
