Bug 299168 – Kernel 2.6.32 defeats external Firewire disk power management

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description Timothy Miller 2009-12-31 23:21:27 UTC]

I have a 500GB Western Digital MyBook external Firewire hard drive.  This drive's on-board controller has a power management feature that will spin down the disk if it's idle for 10 minutes and spin it up again on demand.  

- If I connect this drive via Firewire to either a Mac or a Windows PC (and mount it), and I don't access files on that volume for 10 minutes, the drive will spin down appropriately.  
- If I connect it to my Gentoo box and DON'T mount it, it will spin down after 10 minutes.
- If I mount it but do not otherwise access any files on the volume (no reads or writes besides what's necessary to mount it), it NEVER spins down.

Other info:
- I'm running Linux kernel 2.6.32
- No desktop environment is running
- While there are processes that access the internal disks, nothing is pointed at the external drive, so nothing should access it.  And things like updatedb only run once per day on cron.
- The format is ext3, but since I'm not writing to the disk, the journal manager should have nothing to do.  
- The drive has an activity light that blinks when it's being accessed even the tiniest bit.  I never see it blink.
- There appears to be no way via Firewire to affect the drive's power management.  According to my research, this is all in the drive's internal Firewire-to-SATA controller.  No host involvement is required (or allowed) to cause the disk to spin down.

I have run "lm-profiler" that spends 600 seconds looking for disk access to any drive.  It found only two processes with disk activity during that time.  The first is "md3_raid1", which only applies to the internal RAID1 array.  The other is "flush-9:3".  This appears to be a kernel thread, but I cannot find out what it does.  This is what I find when I grep the process table:

root     18222     2  0 Dec30 ?        00:00:30 [flush-9:3]

I've used lsof and fuser to look to see if any process has either the device node or the mounted volume.  I find nothing.

I think I've ruled out any user process being responsible for this.  Nothing is doing any reads or writes to the drive.  So the only thing I can conceive of is that the kernel driver is performing some OTHER (non read/write) access to the drive that is keeping the controller from powering down the disk.  (Or it's doing nothing but continually rereading some small bit of data cached in the controller.)

(Shortly, I will connect the drive via USB instead of Firewire to see if it makes a difference.  I'll report back.)

Linux appears to have a major bug that prevents Firewire drives (or this one anyhow) from performing power management.  This is a major problem that has the potential to shorten the lifespan of the drive.

I'm reporting this here first because I'm using Gentoo, and I'd like to see if any Gentoo devs can advise me on further investigating this before I escalate it to the kernel bug tracker.  

Any suggestions on next steps?


Reproducible: Always




Portage 2.1.7.16 (default/linux/amd64/10.0, gcc-4.4.2, glibc-2.11-r1, 2.6.32-gentoo-r1 x86_64)
=================================================================
System uname: Linux-2.6.32-gentoo-r1-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q9450_@_2.66GHz-with-gentoo-2.0.1
Timestamp of tree: Thu, 31 Dec 2009 08:00:01 +0000
app-shells/bash:     4.0_p35
dev-java/java-config: 2.1.10
dev-lang/python:     2.6.4, 3.1.1-r1
dev-util/cmake:      2.8.0
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.0
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.13, 2.65
sys-devel/automake:  1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils:  2.20
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.30-r1
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=core2 -ggdb -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -march=core2 -ggdb -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--jobs=5"
FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms splitdebug strict unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://gentoo.netnitco.net http://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ ftp://mirror.datapipe.net/gentoo ftp://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ http://gentoo.mirrors.easynews.com/linux/gentoo/ ftp://ftp.free.fr/mirrors/ftp.gentoo.org/ ftp://gentoo.imj.fr/pub/gentoo/ ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/"
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1"
LINGUAS="en en_US"
MAKEOPTS="--jobs=5"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X a52 aac aalib acl acpi alsa amd64 apache2 aspell autotrace bash-completion berkdb bidi bonjour bzip2 cairo cdda cdio cdr cli composite cracklib crypt ctype cups curl cxx dbus dri dts dvd dvdr encode exif fbcon ffmpeg fftw filter flac fontconfig fortran freetype gcj gd gdbm gmm gnutls gpm gs hal httpd iconv imagemagick ipp ipv6 jadetex java jpeg jpeg2k kde kde4 kerberos kvm lame lapack latex lcms ldap live lm_sensors lzma mad matroska mjpeg mkl mmx mng modules mp3 mpeg mudflap multilib mysql mysqli ncurses nls nptl nptlonly ogg oggvorbis openexr opengl openmp openssl pam pcre pdf perl php plasma plotutils png ppds pppd python qemu qt3support qt4 quicktime readline reflection rss ruby samba sasl semantic-desktop session smp spl sql sse sse2 sse3 ssl stream svg sysfs tcl tcpd theora threads thumbnail tiff tk truetype unicode utempter vcd vlm vnc vorbis webkit wxwindows x264 xcomposite xml xorg xv xvid zeroconf zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_US" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="radeon" 
Unset:  CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

[Comment 1 Timothy Miller 2009-12-31 23:41:51 UTC]

I just tested this on USB.  The drive spins down as it should after 10 minutes if inactivity.  The only difference between this and the Firewire scenario is the cable and the interface.  Same drive, same host, same conditions.

So Linux seems to have a problem with Firewire drives.

[Comment 2 Timothy Miller 2010-01-03 17:12:43 UTC]

Since no one here wanted to comment, I went ahead and submitted the bug upstream:
http://bugzilla.kernel.org/show_bug.cgi?id=14981

[Comment 3 Stefan Richter 2010-01-04 08:40:39 UTC]

I will check with other FireWire disks (I don't have a WD didk enclosure) and comment at the upstream bug entry.

[Comment 4 Mike Pagano 2010-01-09 18:36:20 UTC]

Thanks, we'll watch the progress on the upstream bug.