hard drive led always on

Hi All,

I have a triple boot system with Windows XP 64, Ubuntu 9.10 64, and FreeBSD 8.0-STABLE amd64.

When I boot in Windows or in Linux, the harddrive led on my panel acts as it should: Whenever there is disk activity it flickers, when there is none, it is off.

In FreeBSD 8.0-STABLE however, during boot up, the led turns on, and just sits there, (without flickering).

Now because it is working fine in Windows and in Linux, I suspect there is nothing wrong with the harddrive(s) themselves, but maybe it is a little bug somewhere. I have looked into the logs but I can't find anything related.

I have three harddrives in my system and 1 dvdrw drive:

Code:
ad0: 38172MB <MAXTOR 6L040J2 A93.0500> at ata0-master UDMA133 
ad1: 38166MB <Seagate ST340016A 3.75> at ata0-slave UDMA100 
ad4: 715404MB <SAMSUNG HD753LJ 1AA01109> at ata2-master UDMA100 SATA 3Gb/s
acd0: DVDR <Optiarc DVD RW AD-7203S/1.09> at ata5-master UDMA100 SATA 1.5Gb/s

uname:
Code:
FreeBSD phenomium 8.0-STABLE FreeBSD 8.0-STABLE #2: Tue Apr 20 23:43:08 CEST 2010     root@phenomium:/usr/obj/usr/src/sys/PHENOM05  amd64

dmesg: enclosed


Since I have a dvd rw drive and a radeon 2600hd card I have recompiled the kernel for dri and atapicam. Also I have put polling in because I have a somewhat busy network here.

kernel configuration: enclosed

As you can see I have added some hardware but have stripped a lot from the generic kernel aswell, like nic's I'd never use, and such.
Please note that the hard drive led phenomenon happens with a generic kernel aswell. Thus, in my humble opinion, it must be a driver somewhere, maybe the ataraid driver, which is loaded automatically in the kernel ?

If anyone has a clue about this, please let me know. I know I am nagging about something cosmetic (the harddrives perform perfectly), but this light is sitting in my face the whole day and it's getting pretty annoying...;)

If you need anything else for info, I'd be happy to provide.

SO...ANYONE ?

Rick
 

Attachments

  • dmesg.txt
    9 KB · Views: 286
  • kernelconfig.txt
    12.7 KB · Views: 292
I have seen such reports for ATI controllers. But is it still unresolved. You may try to use new ahci(4) driver for SATA controller instead of usual (note, that you will need to update fstab).
 
SirDice said:
Most likely it's the backgrounded fsck.


Absolutely not. I checked that, of course ;)

The led is always on, even when there is no activity whatsoever. I check this with systat -iostat 1 and top.

Rick
 
mav@ said:
I have seen such reports for ATI controllers. But is it still unresolved. You may try to use new ahci(4) driver for SATA controller instead of usual (note, that you will need to update fstab).

Thanks, I will give this a try and get back to you if this is the solution. I do have a question, however. You are saying that I need to update my fstab. In what way ? It doesn't provide any information about that in the man file.

Rick
 
unixland said:
You are saying that I need to update my fstab. In what way ? It doesn't provide any information about that in the man file.
Look more closely ;)

The ahci driver will make all the drives show up as da* instead of ad*.
 
( note: when switching to AHCI, my slices went from ad8s* to ada0s* ;) )
 
That's why you should use geom labels; they are so useful. No matter how you connect the disks, you can always identify it with a humanly readable and chosen label.

If you use partitions and you have a bit of space left after the last partition, you can write a geom label:
[CMD=""]glabel label systemdisk /dev/ad0[/CMD]
You may need to unmount for that, or boot single user and mount read-only, not sure if that works.

If it works you can write fstab entries like /dev/label/systemdisks1 for the first partition, etc. I love it. :)
 
DutchDaemon said:
( note: when switching to AHCI, my slices went from ad8s* to ada0s* ;) )

*grin* Yes, and non-SATA (eg. ATA) drives are indeed /dev/adxsx, so

SATA drives: /dev/adaXsX
ATA drives : /dev/adXsX
(where X is the number of the drive, and not necessarily the same number as with the ata driver...)

and so on...

It took me a while figuring it out which drive was which but I got it and now it's perfectly configured, even noticing a small barely noticeable performance boost.

However, the problem what this whole topic was about, the hdd led, it does keep burning all the time. It is very unfortunate. Apart from yanking out the wire to the led (which I do _not_ want to do :p) anyone else have useful thoughts about the matter ?

Rick
 
sub_mesa said:
That's why you should use geom labels; they are so useful. No matter how you connect the disks, you can always identify it with a humanly readable and chosen label.

If you use partitions and you have a bit of space left after the last partition, you can write a geom label:
[CMD=""]glabel label systemdisk /dev/ad0[/CMD]
You may need to unmount for that, or boot single user and mount read-only, not sure if that works.

If it works you can write fstab entries like /dev/label/systemdisks1 for the first partition, etc. I love it. :)

Be sure the actual /dev entries appear before changing
the fstab ... ...
 
Hard drive light always on

I switched from 8.0_RELEASE-p2 to 8-STABLE today and after rebooting I see my HDD light is always on, there's no activity in /usr/bin/top nor in /usr/sbin/iostat.

The same problem is talked about here with a solution being to use ahci, which I then set up and rebooted.
I ran into another problem which I'm assuming is down to my system setup.

disk1 (250GB) is setup with a 20GB UFS for base, the rest of the disk is using ZFS.
Booting up I see this warning;
kernel: ZFS WARNING: Unable to open /dev/ada0s2 for writing (error=1).
I'm also unable to import using [CMD=""]zpool import <poolname>[/CMD]

disk2 and disk3 are 100% ZFS and mount cleanly, so I'm guessing the mount issue is down to having UFS and ZFS partitions on one disk?
 
Solved. I took the least complicated route of backing up the drive and destroying the zpool, rebuilding it successfully after setting ahci in /boot/loader.conf and motherboard's bios.
 
unixland said:
However, the problem what this whole topic was about, the hdd led, it does keep burning all the time. It is very unfortunate. Apart from yanking out the wire to the led (which I do _not_ want to do :p) anyone else have useful thoughts about the matter ?

*bump* ;)

please, anyone ?
 
ok, looks like I found it, so solved for me too now.

solution: updated mainboard bios, so that I could set AHCI on for the SATA controller. Now the hard drive led only acts on I/O activity, as it should...

Rick
 
Upgrade to 8.1 from 8.0. Now HDD LED is always on. On 8.0 it worked normal. Setup AHCI for SATA in motherboard bios, and HDD LED start working normal. I didn't add
Code:
ahci_load="YES"
to /boot/loader.conf. Should I?
 
If you have drive(s) that support NCQ, and a SATA controller that supports AHCI, then yes, you should enable the ahci(4) driver. You will get better performance. Note: your disk device nodes will be renamed adaX instead of adX, so you may need to edit /etc/fstab.
 
sorry for my english, it's all Google translator fault. :)

I have WD5000AAKS-75YGA0.
Code:
atacontrol cap ad4
, said that it support NCQ. When i setup AHCI for SATA in BIOS and add
Code:
ahci_load="YES"
in /boot/loader.conf, i get low performance. I noticed it, when unpacking large archive with 7z and start watching movie with mplayer. mplayer lagged - showed the film few seconds and then stopped for a moment and then showed the film and stoped for a moment and so on.

When i got back to IDE (setup IDE in BIOS for SATA, remove ahci from loader.conf), i could watch the movie normal, while unpacking archive. But HDD LED is always on, and it shines right into my leg. Is it dangerous for my leg or maybe for HDD?
 
Have you also tried to compare time of unpacking that archive? With AHCI some benchmarks show up to twice higher performance, while 30% is quite usual. AHCI actively uses drive's internal request scheduler, so concurrent access behavior could (and even should) be different.

You may also try to increase sysctl vfs.read_max value by few times. Bigger read-ahead done by file system in that case could help mplayer to behave better under such I/O pressure.
 
mav@ said:
Have you also tried to compare time of unpacking that archive? With AHCI some benchmarks show up to twice higher performance, while 30% is quite usual. AHCI actively uses drive's internal request scheduler, so concurrent access behavior could (and even should) be different.

You may also try to increase sysctl vfs.read_max value by few times. Bigger read-ahead done by file system in that case could help mplayer to behave better under such I/O pressure.

Thanks, that helped.
Set
Code:
vfs.read_max=32
and now mplayer not lagging.

I tried to compare time of unpacking with this command
Code:
/usr/bin/time -p 7z x archive.7z
and didn't notice any visible difference.
 
I have the same problem (HD led always on), and I start using AHCI in my FreeBSD 8.1-RELEASE amd64 system.
After some changes (fstab, add the vfs.read_max=32, etc), the led of my mainboard continue ON. Do I need to change also the controller type in the machine Bios?

Thank's and excuse me my bad english.
 
Stupid question... Yes, changing in Bios the mode from IDE to AHCI runs fine. Now my problem is the SATA DVD-CD-RW; everytime I restart the Bios showme some "problem" with SATA-2 (the DVD-CD-RW port) and no start up I press the F1 key... :-/ But this is another question...

Bye and thanks.
 
Back
Top