On Fri, 2006-03-31 at 15:53 +0100, N.Pauli wrote: > On Fri, 31 Mar, Philippe De Ryck wrote: > > On Thu, 2006-03-30 at 23:19 +0100, N.Pauli wrote: > > > On Thu, 30 Mar, Philippe De Ryck wrote: > > > > On Thu, 2006-03-30 at 11:45 +0100, N.Pauli wrote: > > > > > Dear All, > > > > > > > > > > All of a sudden my machine has become incredibly slow to boot up and > > > > > to launch anything - boot up took over 5 minutes and launching an app > > > > > like Mozilla or OpenOffice can take just as long. All the > > while > > > > the harddisk drive light is burning constantly. It is as if there is > > > > some process that never completes, takes a long time to time out and > > > > restarts itself whenever I launch an app. Once I'm in, apps > > seem > > > > to run fairly normally. I've looked at 'top' and can't see any culprit > > > > there. I had this happen once before and it was solved by making sure > > > > that nothing was plugged in to a usb port while booting > > up or > > > > even logging on. The last significant things I have done prior to this > > > > happening do a normal update and upgrade using Synaptic and install > > > > Liferea. > > > > > > > > > > Can anybody give me any clues on where I can start looking to resolve > > > > > this? The machine is a 1100 Mhz Intel Celeron with 256 Mb RAM so it > > > > > shouldn't be struggling. I'm running Debian GNU/Linux testing > > > > / unstable and the 2.6.12-1-386 kernel. > > > > > > > > > > > Just an idea, but you might look into HDD-trouble. See what "hdparm > > > > -tT /dev/..." says. See what "smartctl -a /dev/..." says (good > > > > explanation can be found here: > > > > http://www.linuxjournal.com/article/6983). > > > > > > > > Maybe a monitor for disk activity can be useful too (gkrellm for example > > > > shows activity and speed). > > > > > > > > Good luck > > > > > > > > Philippe De Ryck > > > > > > > > > > > Philippe, > > > > > > That article on SMART Control was worth the price of admission alone! I'm > > > going to run the short test over night and see if that brings up anything > > > because all the other signs are healthy - yet the disk > > hangs for minutes on end at the slightest provocation. I tried to run the > > short (2 minute) test during the day but gave up after 40 minutes. > > > > > > Nigel > > > > > > > Nigel, > > > > I found the article very useful too! > > > > You say your disk hangs but all the attributes indicate a healthy disk. > > One way to know this for sure is to put your disk in another machine. If > > it works fine, you can exclude the disk. If it still hangs, you probably > > know for sure that the disk (or the content) is screwed. > > > > I've had some bad experience with an NVIDIA nforce2 chipset (incredibly > > slow) but since you haven't changed anything important on your setup, > > that wouldn't be the case. It might be another component that's failing. > > > > What does 'hdparm -tT /dev/hda' say? Are the speeds reasonable? > > Thanks for the suggestion, Philippe. Here's the output: > > ** > debianoak:/home/nbp# hdparm -tT /dev/hda > > /dev/hda: > Timing cached reads: 1192 MB in 2.00 seconds = 595.20 MB/sec > Timing buffered disk reads: 6 MB in 3.24 seconds = 1.85 MB/sec > ** > > That looks reasonable to me - very fast from the cache and a lot slower when > it has to be buffered (on the hard drive, presumably). But, what do I know!?
As noted by Brian, that is quite bad indeed. Around 50MB/sec is quite good. On my laptop I get around 25MB/sec, which is not marvellous but quite ok. A suggestion (aside from the -I suggestion from Brian): Do you have DMA enabled? You can check this by doing: 'hdparm -d /dev/hda' as root. If it says DMA is disabled, try enabling it: 'hdparm -d1 /dev/hda'. If this succeeds, 'hdparm -tT /dev/hda' should give some better results. If it shows an error message, post it. If DMA is enabled and you still get those shitty speeds something else is quite wrong. You can try to run the hdparm stuff from a livecd if you want to rule out your own software (kernel-image for instance). I can suggest knoppix, which has all the necessary tools available. Good luck! Philippe De Ryck > Following up Listrcv's suggestion I had a good look in /var/logs/syslog and > it looks as if it may be something to do with gconf2 being upgraded. This is > from my notes: > > ################################################################################################################ > # According to Synaptic's history, at 12:19 on 29/03/06 the following > upgrades happened: > # gconf2 (2.12.1-9) to 2.12.1-12 > # gconf2-common (2.12.1-9) to 2.12.1-12 > # These are the lines from syslog that bracket that time. > ################################################################################################################ > > Mar 29 11:34:01 localhost -- MARK -- > Mar 29 11:39:01 localhost /USR/SBIN/CRON[7813]: (root) CMD ( [ -d > /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin > +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm) > Mar 29 11:54:01 localhost -- MARK -- > Mar 29 12:09:01 localhost /USR/SBIN/CRON[8549]: (root) CMD ( [ -d > /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin > +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm) > Mar 29 12:17:01 localhost /USR/SBIN/CRON[8753]: (root) CMD ( run-parts > --report /etc/cron.hourly) > Mar 29 12:34:01 localhost -- MARK -- > Mar 29 12:35:15 localhost gconfd (root-9209): starting (version 2.12.1), pid > 9209 user 'root' > Mar 29 12:35:15 localhost gconfd (root-9209): Resolved address > "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration > source at position 0 > Mar 29 12:35:15 localhost gconfd (root-9209): Resolved address > "xml:readwrite:/root/.gconf" to a writable configuration source at position 1 > Mar 29 12:35:15 localhost gconfd (root-9209): Resolved address > "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration > source at position 2 > Mar 29 12:35:15 localhost gconfd (root-9209): Resolved address > "xml:readonly:/var/lib/gconf/debian.defaults" to a read-only configuration > source at position 3 > Mar 29 12:35:15 localhost gconfd (root-9209): Resolved address > "xml:readonly:/var/lib/gconf/defaults" to a read-only configuration source at > position 4 > Mar 29 12:35:45 localhost gconfd (root-9209): GConf server is not in use, > shutting down. > Mar 29 12:35:45 localhost gconfd (root-9209): Exiting > Mar 29 12:37:28 localhost init: Trying to re-exec init > Mar 29 12:37:39 localhost init: Trying to re-exec init > Mar 29 12:37:57 localhost gconfd (root-9935): starting (version 2.12.1), pid > 9935 user 'root' > Mar 29 12:37:57 localhost gconfd (root-9935): Resolved address > "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration > source at position 0 > Mar 29 12:37:57 localhost gconfd (root-9935): Resolved address > "xml:readwrite:/root/.gconf" to a writable configuration source at position 1 > Mar 29 12:37:57 localhost gconfd (root-9935): Resolved address > "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration > source at position 2 > Mar 29 12:37:57 localhost gconfd (root-9935): Resolved address > "xml:readonly:/var/lib/gconf/debian.defaults" to a read-only configuration > source at position 3 > Mar 29 12:37:57 localhost gconfd (root-9935): Resolved address > "xml:readonly:/var/lib/gconf/defaults" to a read-only configuration source at > position 4 > Mar 29 12:38:27 localhost gconfd (root-9935): GConf server is not in use, > shutting down. > Mar 29 12:38:27 localhost gconfd (root-9935): Exiting > # > # > # Carried on in this vein FOR OVER AN HOUR AND A HALF till... > # > # > Mar 29 14:09:41 localhost gconfd (nbp-16076): GConf server is not in use, > shutting down. > Mar 29 14:09:42 localhost gconfd (nbp-16076): Exiting > Mar 29 14:09:46 localhost gconfd (nbp-16156): starting (version 2.12.1), pid > 16156 user 'nbp' > Mar 29 14:09:46 localhost gconfd (nbp-16156): Resolved address > "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration > source at position 0 > Mar 29 14:09:46 localhost gconfd (nbp-16156): Resolved address > "xml:readwrite:/home/nbp/.gconf" to a writable configuration source at > position 1 > Mar 29 14:09:46 localhost gconfd (nbp-16156): Resolved address > "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration > source at position 2 > Mar 29 14:09:46 localhost gconfd (nbp-16156): Resolved address > "xml:readonly:/var/lib/gconf/debian.defaults" to a read-only configuration > source at position 3 > Mar 29 14:09:46 localhost gconfd (nbp-16156): Resolved address > "xml:readonly:/var/lib/gconf/defaults" to a read-only configuration source at > position 4 > Mar 29 14:09:53 localhost gconfd (nbp-16156): Resolved address > "xml:readwrite:/home/nbp/.gconf" to a writable configuration source at > position 0 > > ################################################## > # End of extract from syslog > ################################################# > It was after that upgrade that my slowness problems started and gconf began > to feature so heavily in syslog. > > There seems to be a repeating pattern of resolving an address to do with > gconfd first for user root and then user nbp - and making a real meal of it. > > Any ideas anyone? I'm going to try and find out more about what gconf does. > > Nigel > > -- > Nigel Pauli > Network Manager > St. John's School, Northwood > > > > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
