Very Computer

Hi,

I just built a new system with the following specs:

* Asus A7N266-C motherboard (with nForce audio, but not the network or
video options)

* Athlon XP 18800+ (1.53GHz) processor

* WD 40GB Hard Drive (about 8 months old)

* 768 MB DDR RAM

I could not get redhat 7.3 to install - I tried 5 or 6 times and each
time it died during installation of the packages with a python error
that said something about "device busy"

I then installed rh 7.2 (no problem) and then was able to install rh 7.3
using the "upgrade" feature.

I've ended up with the following kernel version (from "uname -a"):

Linux titanium.part.net 2.4.18-3 #1 Thu Apr 18 07:32:41 EDT 2002 i686
unknown

And have KDE 3.0 as my desktop.

Every thing seems great -- except one problem... the system seems to
"block" during i/o to my hard drive. It's even a little weirder than
that, here's a description of a common occurance:

In a shell (within Konsole) I use the "gunzip" command to uncompress a
fairly large (60 megabyte) file...

After hitting return, the command runs a 5 or 10 seconds and then gives
me a new shell prompt.  During this time, every thing is fine.

Immediately following the command "completing" the entire system blocks
for another 10 seconds (cannot move mouse, or type, or anything) --
interestingly enough the "hard-drive active led" on the computer shows
that the hd is very busy during this time. To make things even weirder,
just a moment before the system "recovers", the CPU usage jumps to 100%
for about half a second or so.

Once the "block" recovers, everything is fine.  The system seems
completely usable / stable otherwise.

Any ideas???

Thanks,
James

    James> Immediately following the command "completing" the entire
    James> system blocks for another 10 seconds (cannot move mouse, or
    James> type, or anything) -- interestingly enough the "hard-drive
    James> active led" on the computer shows that the hd is very busy
    James> during this time. To make things even weirder, just a
    James> moment before the system "recovers", the CPU usage jumps to
    James> 100% for about half a second or so.

Is DMA enabled on your drive? Use hdparm to check.

/Shyamal

That did it ... Thanks!   (I learn something new every day!)

BTW: Is there a standard way to make the setting "permanent" or do I
just add it to a start-up script?

James

--

One good way to stress test this is to use a shell script that keeps
doing large disk transfers, with a command like "dd if=/dev/hda
of=/dev/null", or use some stress testing program for the io subsystem.
There's one on freshmeat, cannot recall the name right now.

Shyam.

    James> That did it ... Thanks!  (I learn something new every day!)

I'm glad it worked out!

    James> BTW: Is there a standard way to make the setting
    James> "permanent" or do I just add it to a start-up script?

It depends on your distribution. Usually you add something to
/etc/rc.local or somewhere in /etc/init.d/* where it looks like it
will "look right". For example, on Slackware it used to be
/etc/rc.local as far as I remember. On Debian the best bet is to
install the hwtools package and add those lines in
/etc/init.d/hwtools.

On some distributions you want to check why DMA was not turned on,
because they try pretty hard to get this right in the first place. I
can't help you there though....

Cheers!
Shyamal

If it's turned on I get blocks but not as usually.

any ideas ?

Quote:> I have a linux server that does the same blocking when I/O.
> I check the DMA using hdparm and it's ok.
> If I switch it off doing hdparm -d0 /dev/hda it gets worse.

> If it's turned on I get blocks but not as usually.
> any ideas ?

--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin /
http://www.brainbench.com     /  "He is a rhythmic movement of the
-----------------------------/    penguins, is Tux." --MegaHAL

Quote:> On 11 Jul 2002 02:45:23 -0700, Francesc Guasch staggered into the Black
> Sun and said:
> > I have a linux server that does the same blocking when I/O.
> Do you mean, "When 1 process is accessing the disk for extended periods

Quote:> of time, all the other processes stop or slow down dramatically"?  If

Quote:> that's it, you should either switch from IDE to SCSI disks, or make sure
> that you've applied the -u1 setting to hdparm.  -u1 typically improves
> interactive performance on IDE disks.

this is the info of the drive:

# hdparm -i /dev/hda

/dev/hda:

 Model=ST320410A, FwRev=3.34, SerialNo=3FG092G7
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=39102336
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive Supports : Reserved : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5 ATA-6