Find the answer to your Linux question:
Results 1 to 9 of 9
So my hard drives (I have two 160 GB 7200 RPM ATA ones) are becoming a problem. Whenever a lot of data is being written to them (i.e. whenever I ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux Newbie
    Join Date
    May 2004
    Location
    Boston, MA
    Posts
    246

    Hard drives causing painful slowdown


    So my hard drives (I have two 160 GB 7200 RPM ATA ones) are becoming a problem. Whenever a lot of data is being written to them (i.e. whenever I copy a large file from one drive to another or from a network mounted share to one of my drives), my computer basically grinds to a halt. Music starts skipping, my wireless keyboard sends nonsense signals when I type, and all sorts of unpleasant experiences assail my fragile little brain.

    This happens even if I use, say,
    Code:
    nice -n 30 cp drive1/movie.avi drive2/
    so I assume it's not a processor problem. The benchmark of hdparm is as follows:
    Code:
    dan@george:~# hdparm -tT
    
     Timing buffer-cache reads:   2196 MB in  2.00 seconds = 1097.62 MB/sec
     Timing buffered disk reads:   22 MB in  3.04 seconds =   7.23 MB/sec
    and as far as I know, those numbers are pretty good.

    Can anybody think of what might relieve this awful bottleneck? This is a Slackware system with kernel 2.6.7.
    Situations arise because of the weather,
    And no kinds of love are better than others.

  2. #2
    Linux Newbie
    Join Date
    May 2004
    Location
    Boston, MA
    Posts
    246
    OK, here's an update, as well as a bump:

    My hard drives weren't set up to use DMA. So I tried
    Code:
    # hdparm -d1 /dev/hda
    
    /dev/hda:
     setting using_dma to 1 (on)
     HDIO_SET_DMA failed: Operation not permitted
     using_dma    =  0 (off)
    What's that?! I'm root! You must permit me all operations!

    But fine. I Googled this problem, and the results seemed to suggest that the kernel had been compiled without DMA support for my chipset. And sure enough, it had been! So I recompiled the kernel with the correct DMA support, booted up, and got the exact same error. Total bummer. Anyone think of anything yet?
    Situations arise because of the weather,
    And no kinds of love are better than others.

  3. #3
    Linux Guru sarumont's Avatar
    Join Date
    Apr 2003
    Location
    /dev/urandom
    Posts
    3,682
    The *exact* same error? Maybe your hard drives aren't DMA compatible...

    Seriously, though, does it work on /dev/hdb?
    "Time is an illusion. Lunchtime, doubly so."
    ~Douglas Adams, The Hitchhiker's Guide to the Galaxy

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Engineer
    Join Date
    Nov 2004
    Location
    home
    Posts
    796
    I got that exact same problem when tryin to set up hdparm today. Won't let me turn dma on, even though 'hdparm -i' shows that it's available, and still says operation not permitted when I try to tell it which dma to use with -X. No idea what cause this could be, dma IS enabled in the kernel.

  6. #5
    Linux Enthusiast
    Join Date
    Jun 2004
    Location
    Windsor, CO
    Posts
    656
    I had the same problem, it was fixed easily enough:
    Recompile the kernel again, but this time make sure the support for your chipset is compiled into the kernel (NOT as a module).
    And of course check that "enable DMA by default" is enabled in the kernel too.
    Emotions are the key to the soul.
    Registered Linux User #375050

  7. #6
    Linux Newbie
    Join Date
    May 2004
    Location
    Boston, MA
    Posts
    246
    Thanks sarumont and Stormblazer:

    I had compiled the support for my chipset directly into the kernel in the first place, and "Use PCI DMA by default when available" was also checked. The hdparm -d1 /dev/hdb returns the exact same error, and so does hdparm -d1 /dev/hdc, which is my CD/DVD drive. Pretty infuriating, huh?

  8. #7
    Linux Guru sarumont's Avatar
    Join Date
    Apr 2003
    Location
    /dev/urandom
    Posts
    3,682
    Quote Originally Posted by dan@george
    Thanks sarumont and Stormblazer:

    I had compiled the support for my chipset directly into the kernel in the first place, and "Use PCI DMA by default when available" was also checked. The hdparm -d1 /dev/hdb returns the exact same error, and so does hdparm -d1 /dev/hdc, which is my CD/DVD drive. Pretty infuriating, huh?
    Here's a thought...have you tried upgrading to a newer version of hdparm?
    "Time is an illusion. Lunchtime, doubly so."
    ~Douglas Adams, The Hitchhiker's Guide to the Galaxy

  9. #8
    Linux Engineer
    Join Date
    Nov 2004
    Location
    home
    Posts
    796
    I know that my kernel has this stuff compiled in, I don't mess with modules for IDE stuff, since they are a bit slower. I'm probably not running the latest version of hdparm though, but I'll worry about this later, since I plan on building LFS 6 soon, I'm still running 5.

  10. #9
    Linux Newbie
    Join Date
    May 2004
    Location
    Boston, MA
    Posts
    246
    So I upgraded from hdparm v5.5 to v5.9, but the error persists. Incidentally, I was able to enable 32 bit transfer mode with the special sync sequence using
    Code:
    # hpdarm -c3 /dev/hd{a,b}
    which sped up my buffered disk reads by about a factor of 2.

    That slowdown's still going on. I checked the info from hdparm on my disks, and got this:
    Code:
    # hdparm -i /dev/hda
    
    /dev/hda:
    
     Model=SAMSUNG SP1604N, FwRev=TM100-24, SerialNo=0731J1FWC10112
     Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
     RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
     BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
     CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
     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 
     UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 
     AdvancedPM=no WriteCache=enabled
     Drive conforms to: (null): 
    
     * signifies the current active mode
    Now since * is supposed to signify the currently active DMA mode, this output would seem to suggest that my drive is currently operating under UDMA5. However,
    Code:
    hdparm -d /dev/hda
    
    /dev/hda:
     using_dma    =  0 (off)
    Pretty strange, if you ask me. But I suppose you shouldn't, because I'm asking you.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •