Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 69284 - hdparm sets -d1 only for some drives
Summary: hdparm sets -d1 only for some drives
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 103202 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-10-28 08:28 UTC by Alexandru Toma
Modified: 2006-06-27 07:32 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
/etc/init.d/hdparm.diff (diff.hdparm,396 bytes, text/plain)
2005-08-20 11:59 UTC, Philip Kovacs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandru Toma 2004-10-28 08:28:34 UTC
I added the following line to my /etc/conf.d/hdparm: all_args="-d1"
Then I added hdparm to the default runlevel: rc-update -a hdparm default

When the computer boots it sets using_dma to on for most drives. I have four drives and hda, hdb & hdd all have their flags set to on but, for some reason, hdparm doesn't also set the using_dma flag to on for hdc.

However, if I manually run /etc/init.d/hdparm restart after that the flag gets set. Even starnger, sometimes, the flag still doesn't get set even after I restart the script so I added disc2_args="-d1" to conf.d/hdparm. This doesn't make the first problem disappear but at least now I know that restarting /etc/init.d/hdparm will _always_ set the using_dma flag.

hdparm -i /dev/hdc

/dev/hdc:

 Model=WDC WD1200JB-00FUA0, FwRev=15.05R15, SerialNo=WD-WCAES1128071
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=74
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648
 IORDY=on/off, tPIO={min:120,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: device does not report version: 

 * signifies the current active mode

The other drive that shares the ide channel with this one is the boot drive (hdd)

hdparm -i /dev/hdd

/dev/hdd:

 Model=Maxtor 6Y120L0, FwRev=YAR41BW0, SerialNo=Y31KM69E
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=240121728
 IORDY=on/off, tPIO={min:120,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 *udma6 
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: (null): 

 * signifies the current active mode

Could the udma6 udma5 supported modes difference be the cause of this?

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




Portage 2.0.50-r11 (default-x86-1.4, gcc-3.3.4, glibc-2.3.4.20040808-r1,
2.6.8-gentoo-r3)
=================================================================
System uname: 2.6.8-gentoo-r3 i686 AMD Athlon(tm) XP 1600+
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3/share/config /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="ftp://ftp.iasi.roedu.net/pub/mirrors/gentoo.org
http://gentoo.oregonstate.edu"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync1.ro.gentoo.org/gentoo-portage"
USE="3dnow 3dnowex X aalib alsa apache apm avi bitmap-fonts cdr crypt cups curl
encode f77 flac foomaticdb gd gif gphoto2 gpm gtk2 guile imlib imlib2 jikes jpeg
lcms libcaca libwww lzo mad matroska mikmod mmx motif mpeg mysql ncurses network
nls no_wxgtk1 oggvorbis opengl pam png python quicktime readline rtc ruby sdl
slang spell sse ssl tcpd tga theora tiff truetype x86 xchatdccserver xml2 xmms
xprint xv xvid zlib"
Comment 1 Alexandru Toma 2004-10-30 06:32:28 UTC
Another strange thing that I noticed today (don't know if this happened before). It seems that sometimes, for some unknown reason, after I restart the hdparm init script to enable using_dma, it gets set off.

I have a directory containing some big files (>300 MB). If, after I restart the hdparm script, I run cksfv or ed2k_hash (maybe this happens with other checksum utilities and programs but I have only tested with those) the using_dma flag gets set off during the time the program computes the hashes. I don't think this is cksfv or ed2k_hash related... I think it also happened when I copied a few files and deleted them afterwards.

Also, if I set the using_dma flag manually with hdparm -d1 /dev/hdc it seems this doesn't happen anymore; at least I haven't been able to reproduce the bug if I did this.

Steps to reproduce:
1. /etc/init.d/hdparm restart to enable using_dma on /dev/hdc
2. cksfv * in a directory with a few large files (it seems to happen more often with cksfv than with ed2k_hash)
3. hdparm /dev/hdc will show using_dma    =  0 (off)
Comment 2 Alexandru Toma 2004-11-11 13:13:32 UTC
> Also, if I set the using_dma flag manually with hdparm -d1 /dev/hdc it seems
> this doesn't happen anymore; at least I haven't been able to reproduce the
> bug if I did this.

Well, this has also happened now.
Comment 3 Dan Casimiro 2004-11-20 11:03:13 UTC
I am seeing the same sort of behavior.  Here is the output from hdparm -i /dev/hda on my system:


/dev/hda:

 Model=WDC WD1200JB-75CRA0, FwRev=16.06V16, SerialNo=WD-WMA8C2176126
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234375000
 IORDY=on/off, tPIO={min:120,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: device does not report version:

 * signifies the current active mode

Comment 4 Heinrich Wendel (RETIRED) gentoo-dev 2005-01-26 08:24:26 UTC
what about hdparm-5.8?
Comment 5 Alexandru Toma 2005-02-03 06:28:16 UTC
I have tried version 5.8 and I'm still having problems.

As I said in my first post, I have 4 hdds. I also have a cd-rom drive which I swap for hdc when I need to use it. I'm currently using the cd-rom drive for hdc, not the hdd like in the first post.

I have left only all_args="-d1" in my /etc/conf.d/hdparm. When the computer first boots up I get the following:

 * Starting hdparm...                                                     [ ok ]
 * Running hdparm on /dev/discs/disc2/disc...
 * Running hdparm on /dev/hdc...
 * Running hdparm on /dev/discs/disc1/disc...
 * Running hdparm on /dev/discs/disc0/disc...
 * Running hdparm on /dev/cdroms/cdrom0...

Which is a little strange.. why does the cdrom appear twice?
Then:

cloud root # hdparm /dev/hdc

/dev/hdc:
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)
 HDIO_GETGEO failed: Invalid argument

If I run /etc/init.d/hdparm restart the using_dma is set to 1 for a short period of time, but then it resets to 0. However, if I run "hdparm -d1 /dev/hdc" manually, the flag "sticks" to 1.
Comment 6 Alexandru Toma 2005-02-03 08:28:39 UTC
> I'm currently using the cd-rom drive for hdc, not the hdd like in the first post.

I'm currently using the cd-rom drive for hdc, not the hard-disk (not hdd as in /dev/hdd) like in the first post.
Comment 7 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-19 12:06:50 UTC
ok, it seems to be a gentoo-specific problem then
Comment 8 Alexandru Toma 2005-02-19 12:14:55 UTC
Yes, I think it's a problem with the init scripts, in my case at least.
Comment 9 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-19 12:41:40 UTC
Tavin: maybe you have an idea, it's your init script at last ;)
Comment 10 Georgi Georgiev 2005-07-03 05:25:27 UTC
Hm, this part causes trouble for me (not sure if it is related)

                        # check that the block device really exists
                        # by opening it for reading
                        if [ -b $device ] && ( : <$device ) 2>/dev/null
                        then
                                eval args=\${`basename $device`_args}
                                do_hdparm
                        fi

the "( : <$device )" test will fail if there is no disk in the cd-rom. Example:

# device=/dev/hdd; if [ -b $device ] && ( : <$device ) 2>/dev/null; then echo
YES; else echo NO; fi
NO
# hdparm -I $device

/dev/hdd:

ATAPI CD-ROM, with removable media
        Model Number:       _NEC DVD_RW ND-3540A                    
        Serial Number:      
        Firmware Revision:  1.01    
Standards:
        Likely used CD-ROM ATAPI-1
Configuration:
        DRQ response: 3ms.
        Packet size: 12 bytes
Capabilities:
        LBA, IORDY(cannot be disabled)
        DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4 
             Cycle time: no flow control=120ns  IORDY flow control=120ns


Why not replace the current broken test with "if hdparm -I $device >/dev/null
2>&1"? It makes more sense, since if "hdparm -I" fails, it is useless to try
anything else.
Comment 11 Alexandru Toma 2005-07-04 02:03:41 UTC
Just to give you guys an update on this... A while ago the behaviour of the 
init script changed.

It now correctly sets -d1 on boot. However, after a while it gets set to off 
and I have to manually set it to on. This doesn't last forever though, and 
after a while I have to manually set -d1 again. I usually do this 1-3 times a 
day.

This only happens for hdc.
Comment 12 Alexandru Toma 2005-07-08 05:03:06 UTC
I spoke too soon... -d1 gets set correctly only 90% of the time. The other 
10%, -d1 doesn't get set and I have to set it manually immediately after boot. 
I'm using hdparm 5.9 btw
Comment 13 Philip Kovacs 2005-08-20 11:59:30 UTC
Created attachment 66421 [details]
/etc/init.d/hdparm.diff

how about keeping it simple and just eliminating the attempt to open the
device?  diff attached.
Comment 14 Alexandru Toma 2005-08-21 08:38:44 UTC
Philip, I'm afraid that didn't solve the problem for me. I should also mention
that I get an error when hdparm tries to set the settings for hdc (the disc with
the problem; this is the only disc which refuses to accept -d1 from the init
script so I'm beginning to think the problem doesn't lie with the init script
but somewhere else):
HDIO_SET_MULTCOUNT failed: Device or resource busy

I also have -m16 added to conf.d/hdparm so that's the reason... however, I
should mention that when I set -d1 manually (hdparm -d1 /dev/hdc) -m16 also gets
set automatically even though it's not present on the command line.
Comment 15 Philip Kovacs 2005-08-21 09:43:46 UTC
ok, i filed bug #103202 which has to do with the specific problem with the init
script that i observe and which i see was mentioned above in this bug.
Comment 16 Heinrich Wendel (RETIRED) gentoo-dev 2005-08-23 03:30:17 UTC
*** Bug 103202 has been marked as a duplicate of this bug. ***
Comment 17 Philip Kovacs 2005-08-23 09:09:40 UTC
bug #103202 is not a duplicate of this one.   i posted a very specific problem
with the init script for hdparm.
Comment 18 SpanKY gentoo-dev 2006-02-14 08:05:34 UTC

*** This bug has been marked as a duplicate of 104683 ***
Comment 19 Alexandru Toma 2006-02-15 01:49:36 UTC
This bug is not a duplicate of bug #104683 ... This was not, originally, about CD/DVD drives (even though they were brought into discussion) but about HDD drives (I have four).

Besides, I have already tried hdparm-6.3 and the problem is still there: "-d1" gets set correctly by the init script for all drives except hdc for which I manually have to set it.

Please tell me what information you require as I don't know what information I should be providing.
Comment 20 SpanKY gentoo-dev 2006-06-27 07:32:23 UTC
run the latest version with debugging turned on

edit the start() func and put 'set -x' at the top of it

then post the output as an attachment