Had posted this in the security forum as I was a bit worried about it at first, but now I just think its something misconfigured or something. Only seems to have started recently and I cant think what it could be. The hard drive light isnt on flat out but flickers every second or so. Havent really installed anything recently, but have installed 2.6.10 kernel with a few new options. My hdd wont even spin down in laptop mode. Obviously I'm getting pretty sh**full battery life at the moment. Have tried turning off logging and still same thing. Using iostat, I can see that my ext3 partition is getting read and written to a lot. Not a memory prob as my swap partition isnt getting touched. Still does it with internet disconnected. Looked at lsof and there is a massive amount of files open and its just too much for me to digest seeing as I dont know what half of the programs or files are. So, anyone have any advise how I can diagnose this.
Cheers.
BTW in my acpi log I'm getting battery events every 40 secs. It's allways been doing that though (I think) Wouldnt be surprised if it some sort of logging though. Have run rkhunter and chkrootkit too. Nothing exciting with them.

Hi,

Had this problem (non laptop) with HD's using cache, needed to change some settings using hdparm.

What does hdparm /dev/hda tell you?
Output should look like this (except last line):

/dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on) (<== this was my problem)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 9729/255/63, sectors = 156301488, start = 0

PS: Used /dev/hda, change a to appropriate hd.

PPSS: Be carefull when using hdparm, if unsure check the manpage, if still unsure ask here.

Hope this helps.

Alrighty. Am reading the man page. Your right, it looks like I could really reek some havok with this. Heres what it says for my hdd
/dev/hda:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 60011642880, start = 0
You can see the read ahead is high, which was set with laptopmode,but drive still goes all the time. Remember reading about dma in kernel config. What kind of laptop is yours druuna. I thought it was only with certain older machines that dma played up. I've got a R40 thinkpad.

Hi again,

To get some info about your hd try: hdparm -i /dev/hda

multcount = 0 (off) => Think you can set this (hdparm -m 16 /dev/hda, or -m0 to disable again)
You could try setting IO_support to 32 bit (hdparm -c1 /dev/hda, to turn back -c0)

To try these all together:
hdparm -c1 -m16 /dev/hda

To 'reset' them again:
hdparm -c0 -m0 /dev/hda

The read-ahead option is -a. The default is 8 (-a 8, use multiples of 8).

The problems I had were on a desktop and a server, my laptop (asus) never had any hd trouble.

The default kernel options concerning this are ok (most of the time ).

BTW: The best and safest way to do all this is as root in runlevel 1, especially if you are going to test/try speed settings.

Some related links:

Linux Gazette
O’Reilly
Linux NetMag Please do read their liability disclaimer.

Hope this clears things up a bit.

Thanks for those links. Didnt fix my problem, but gave my hdd a bit of a tweak. With dma off, didnt make any difference.

Dont seem to be getting anywhere. I ran the disk checking program that is included in the laptop-mode text file. When I look at it in tty12 it says its going to sleep when I pull the plug, then coming active when I plug it back in. However, when its unpluged, the light still flickers. Heres the result from two iostat runs on my / partition done within about 20 seconds of each other
debian:~# iostat /dev/hda3
Linux 2.6.10 (debian) 02/23/05

avg-cpu: %user %nice %sys %iowait %idle
13.68 0.02 1.53 0.94 83.83

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
hda3 3.87 25.04 25.39 389242 394760

debian:~# iostat /dev/hda3
Linux 2.6.10 (debian) 02/23/05

avg-cpu: %user %nice %sys %iowait %idle
13.68 0.02 1.53 0.94 83.83

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
hda3 3.86 24.99 25.34 389242 394760

So this is showing (please correct me if im wrong) that something IS writing to the hdd and therefore it cant be asleep?

Dunno whats going on with laptop mode, cause it doesnt seem to be actually doing anything. I set the flag on /proc/sys/vm/block-flush and from dmesg, the two processes that are writing to the disk are pdflush and kjournald. Heres a bit of output

sh(5554): dirtied inode 34041 (mtab) on hda3
sh(5554): dirtied inode 470343 (gconv-modules) on hda3
sh(5554): dirtied inode 465796 (ISO8859-1.so) on hda3
sh(5554): dirtied inode 34018 (sysstat) on hda3
kjournald(291): WRITE block 15344 on hda3
kjournald(291): WRITE block 15352 on hda3
kjournald(291): WRITE block 15360 on hda3
kjournald(291): WRITE block 15368 on hda3
kjournald(291): WRITE block 15376 on hda3
kjournald(291): WRITE block 15384 on hda3
kjournald(291): WRITE block 15392 on hda3
kjournald(291): WRITE block 15400 on hda3
kjournald(291): WRITE block 15408 on hda3
kjournald(291): WRITE block 15416 on hda3
kjournald(291): WRITE block 15424 on hda3
kjournald(291): WRITE block 15432 on hda3
kjournald(291): WRITE block 15440 on hda3
kjournald(291): WRITE block 15448 on hda3
kjournald(291): WRITE block 15456 on hda3
kjournald(291): WRITE block 15464 on hda3
kjournald(291): WRITE block 15472 on hda3
kjournald(291): WRITE block 15480 on hda3
kjournald(291): WRITE block 15488 on hda3
kjournald(291): WRITE block 15496 on hda3
kjournald(291): WRITE block 15504 on hda3
kjournald(291): WRITE block 15512 on hda3
kjournald(291): WRITE block 15520 on hda3
kjournald(291): WRITE block 15528 on hda3
kjournald(291): WRITE block 15536 on hda3
pdflush(162): WRITE block 524328 on hda3
pdflush(162): WRITE block 524352 on hda3
pdflush(162): WRITE block 524368 on hda3
pdflush(162): WRITE block 524376 on hda3
pdflush(162): WRITE block 524424 on hda3
pdflush(162): WRITE block 524632 on hda3
pdflush(162): WRITE block 524696 on hda3
pdflush(162): WRITE block 524744 on hda3
pdflush(162): WRITE block 524808 on hda3
pdflush(162): WRITE block 524944 on hda3
pdflush(162): WRITE block 3932200 on hda3
pdflush(162): WRITE block 3932216 on hda3
pdflush(162): WRITE block 3932224 on hda3
pdflush(162): WRITE block 3932232 on hda3
pdflush(162): WRITE block 3932600 on hda3
pdflush(162): WRITE block 3932608 on hda3
pdflush(162): WRITE block 3932752 on hda3
pdflush(162): WRITE block 7342720 on hda3
pdflush(162): WRITE block 7343856 on hda3
pdflush(162): WRITE block 7864656 on hda3
pdflush(162): WRITE block 10747976 on hda3
pdflush(162): WRITE block 13893664 on hda3
pdflush(162): WRITE block 13893672 on hda3
top(5059): dirtied inode 666683 (utmp) on hda3
netdaemon(4059): dirtied inode 32831 (interfaces) on hda3
gnome-system-mo(5452): dirtied inode 34041 (mtab) on hda3
kjournald(291): WRITE block 15544 on hda3
kjournald(291): WRITE block 15552 on hda3
kjournald(291): WRITE block 15560 on hda3
kjournald(291): WRITE block 15568 on hda3
kjournald(291): WRITE block 15576 on hda3
pdflush(162): WRITE block 524392 on hda3
pdflush(162): WRITE block 524696 on hda3
pdflush(162): WRITE block 10747976 on hda3
top(5059): dirtied inode 666683 (utmp) on hda3
gnome-system-mo(5452): dirtied inode 34041 (mtab) on hda3
kjournald(291): WRITE block 15584 on hda3
kjournald(291): WRITE block 15592 on hda3
kjournald(291): WRITE block 15600 on hda3
kjournald(291): WRITE block 15608 on hda3
netdaemon(4059): dirtied inode 32831 (interfaces) on hda3
pdflush(162): WRITE block 524696 on hda3
pdflush(162): WRITE block 10747976 on hda3
kjournald(291): WRITE block 15616 on hda3
kjournald(291): WRITE block 15624 on hda3
kjournald(291): WRITE block 15632 on hda3
pdflush(162): WRITE block 524392 on hda3
top(5059): dirtied inode 666683 (utmp) on hda3
gnome-system-mo(5452): dirtied inode 34041 (mtab) on hda3
kjournald(291): WRITE block 15640 on hda3
kjournald(291): WRITE block 15648 on hda3
kjournald(291): WRITE block 15656 on hda3
kjournald(291): WRITE block 15664 on hda3
pdflush(162): WRITE block 524696 on hda3
pdflush(162): WRITE block 10747976 on hda3
top(5059): dirtied inode 666683 (utmp) on hda3
gnome-system-mo(5452): dirtied inode 34041 (mtab) on hda3
netdaemon(4059): dirtied inode 32831 (interfaces) on hda3
kjournald(291): WRITE block 15672 on hda3
kjournald(291): WRITE block 15680 on hda3
kjournald(291): WRITE block 15688 on hda3
kjournald(291): WRITE block 15696 on hda3
kjournald(291): WRITE block 15704 on hda3
DROPPED IN=ppp0 OUT= MAC= SRC=203.221.205.18 DST=203.221.121.124 LEN=48 TOS=0x00
PREC=0x00 TTL=120 ID=36372 DF PROTO=TCP SPT=4568 DPT=445 SEQ=2807124720 ACK=0 W
INDOW=8160 RES=0x00 SYN URGP=0 OPT (0204055001010402)
pdflush(162): WRITE block 524392 on hda3
pdflush(162): WRITE block 10747976 on hda3
kjournald(291): WRITE block 15712 on hda3
kjournald(291): WRITE block 15720 on hda3
kjournald(291): WRITE block 15728 on hda3
pdflush(162): WRITE block 524696 on hda3
top(5059): dirtied inode 666683 (utmp) on hda3
DROPPED IN=ppp0 OUT= MAC= SRC=203.221.205.18 DST=203.221.121.124 LEN=48 TOS=0x00
PREC=0x00 TTL=120 ID=36520 DF PROTO=TCP SPT=4568 DPT=445 SEQ=2807124720 ACK=0 W
INDOW=8160 RES=0x00 SYN URGP=0 OPT (0204055001010402)
gnome-system-mo(5452): dirtied inode 34041 (mtab) on hda3
kjournald(291): WRITE block 15736 on hda3
kjournald(291): WRITE block 15744 on hda3
kjournald(291): WRITE block 15752 on hda3
kjournald(291): WRITE block 15760 on hda3
pdflush(162): WRITE block 524696 on hda3
pdflush(162): WRITE block 10747976 on hda3
top(5059): dirtied inode 666683 (utmp) on hda3
netdaemon(4059): dirtied inode 32831 (interfaces) on hda3
gnome-system-mo(5452): dirtied inode 34041 (mtab) on hda3
bash(5555): dirtied inode 861598 (dmesg) on hda3
bash(5555): dirtied inode 246088 (ld-linux.so.2) on hda3
bash(5555): dirtied inode 243901 (ld-2.3.2.so) on hda3
dmesg(5555): dirtied inode 33763 (ld.so.cache) on hda3
dmesg(5555): dirtied inode 245526 (libc.so.6) on hda3
dmesg(5555): dirtied inode 245495 (libc-2.3.2.so) on hda3
debian:~#

Not sure if this will help you, but I had a similar problem that the HD was accesses fairly often. I have my Linux lappie (Debian) connected to a router, another WinXP box is also connected to the router.

My /var/log/syslog was clogged with messages about dropped packages about every 30 seconds (Guarddog is my firewall and is doing the logging). Everytime something is written to the log, the hard disk is activated. The packages had Source and Destination Ports (SPT and DPT) of 137/138 (NetBIOS) and 520 (Routing Information Protocol, RIP) coming from a Windows machine connected to the same router as my laptop, and the router itself (as identified by the IP addresses).
On the Windows machine I disabled the service "TCP/IP NetBIOS Helper", and in the router I specified that I did not want the RIP (there's only one way to route from the router, and that's to my ISP..), I also configured Guarddog to allow Windows Networking (NetBIOS) on the local zone. The log got nice and clean again.

Hope it is of some help,
/TLV

Cheers TLV for that. I actually disabled logging in gaurddog and that didnt make any difference so I turned it back on. The problem was fixed by adding 'noatime' to my fstab. However the light still flickers. The output of iostat shows no writing or reading though and hdparm shows the drive is spinning down. Still got me buggered why this has only just started doing it, and why the light is still flickering when drive isnt being accessed. TLV, how long do you get out of your R40. With laptop-mode and ondemand cpu governor still only get 2 and half hours out of it. Its taken me a long time to get around to get acpi working properly and now it seems its not making much difference.

I don't really use the battery for any longer periods of time - it's mostly on AC, so I have never tested my battery-time. I don't use laptop mode either.

I know that there was recently a big discussion over at the Linux-Thinkpad mailinglist as to why ACPI suspend drained the battery so fast to IBM lappies. (I haven't caught with those e-mail yet...) But that shouldn't impact a not-suspended lappie.

Maybe some HD-protection thingy in BIOS is playing with the HD?


/TLV

It would be interesting to know if this behaviour happens when you are in single-user mode.

Yeah mine only lasts about 10 hours when suspended.My protected area actually gets disabled when linux starts up, but I cant see it afterwards. Might have to log in in single user mode and see what happens.