First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 69284
Alias:
Product:
Component:
Status: RESOLVED
Resolution: NEEDINFO
Assigned To: Gentoo's Team for Core System packages <base-system@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Alexandru Toma <flash3001@yahoo.com>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
diff.hdparm /etc/init.d/hdparm.diff text/plain Philip Kovacs 2005-08-20 11:59 0000 396 bytes Details
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 69284 depends on: Show dependency tree
Bug 69284 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2004-10-28 08:28 0000
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 From Alexandru Toma 2004-10-30 06:32:28 0000 -------
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 From Alexandru Toma 2004-11-11 13:13:32 0000 -------
> 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 From Dan Casimiro 2004-11-20 11:03:13 0000 -------
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 From Heinrich Wendel (RETIRED) 2005-01-26 08:24:26 0000 -------
what about hdparm-5.8?

------- Comment #5 From Alexandru Toma 2005-02-03 06:28:16 0000 -------
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 From Alexandru Toma 2005-02-03 08:28:39 0000 -------
> 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 From Heinrich Wendel (RETIRED) 2005-02-19 12:06:50 0000 -------
ok, it seems to be a gentoo-specific problem then

------- Comment #8 From Alexandru Toma 2005-02-19 12:14:55 0000 -------
Yes, I think it's a problem with the init scripts, in my case at least.

------- Comment #9 From Heinrich Wendel (RETIRED) 2005-02-19 12:41:40 0000 -------
Tavin: maybe you have an idea, it's your init script at last ;)

------- Comment #10 From Georgi Georgiev 2005-07-03 05:25:27 0000 -------
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 From Alexandru Toma 2005-07-04 02:03:41 0000 -------
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 From Alexandru Toma 2005-07-08 05:03:06 0000 -------
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 From Philip Kovacs 2005-08-20 11:59:30 0000 -------
Created an attachment (id=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 From Alexandru Toma 2005-08-21 08:38:44 0000 -------
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 From Philip Kovacs 2005-08-21 09:43:46 0000 -------
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 From Heinrich Wendel (RETIRED) 2005-08-23 03:30:17 0000 -------
*** Bug 103202 has been marked as a duplicate of this bug. ***

------- Comment #17 From Philip Kovacs 2005-08-23 09:09:40 0000 -------
bug #103202 is not a duplicate of this one.   i posted a very specific problem
with the init script for hdparm.

------- Comment #18 From SpanKY 2006-02-14 08:05:34 0000 -------

*** This bug has been marked as a duplicate of 104683 ***

------- Comment #19 From Alexandru Toma 2006-02-15 01:49:36 0000 -------
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 From SpanKY 2006-06-27 07:32:23 0000 -------
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

First Last Prev Next    No search results available      Search page      Enter new bug