Hello,
I had the same problem some weeks ago...
The DMA was disabled, you can see it with this command (no option to hdparm)
hdparm /dev/hda
The problem was that the ide module used was generic-ide and not the one
specially suited for my mother board (some via-cxxx)
To correct the problem (if it is the same) you have to first load the
right ide module because after generic-ide was loaded he can't be replaced.
In my case, that was initrd that loaded the generic-ide so I had to
create a new initrd-image with the right module (the config file is
/etc/mkinitrd/modules)
good luck
Jean-François
PS : I apologize for my poor english. I'm sorry I can't give you much
precise information but my debian box is at home...
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!?
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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
