# Why is the HDD led always on?



## rowo (Jul 19, 2018)

It seems to be FreeBSD-specific. Thus the led doesn't reflect disk activity.


----------



## k.jacker (Jul 19, 2018)

Yes, that's as little information as possible.
I disagree with your scientific statement, though.
Hdd activity leds are not controlled by FreeBSD. I'd suspect a bad disk, cable or controller...


----------



## rowo (Jul 19, 2018)

No , the hardware is ok. The led works as expected when using Linux.


----------



## rowo (Jul 19, 2018)

This is the main board: https://www.gigabyte.com/se/Motherboard/GA-MA69VM-S2-rev-10#ov


----------



## Phishfry (Jul 19, 2018)

Is this truly the LED on the hard drive or a Case LED tied to a motherboard header for disk?

The reason I ask is motherboard header LED might be controlled by system GPIO signaling whereas disk LED is actual drive activity.


----------



## rowo (Jul 20, 2018)

The LED cable is tied to the main board.


----------



## ralphbsz (Jul 20, 2018)

Is the disk actually busy?  Try running `iostat` to diagnose this.


----------



## Chris_H (Jul 20, 2018)

The LED is on, because it is plugged into a source of power. Simply remove the power to fix the problem.
Sorry. Couldn't resist. 

--Chris


----------



## Chris_H (Jul 20, 2018)

Seroiously tho. The latch on the drive is inverted. Could be caused by several reasons. Without being there to examine it. The easiest way to determine what's going on is with dmesg(8). Boot verbose, and have a look (or post the output here). /var/log/messages may even be providing you some clues. The fact that Linux seems to work, is purely coincidence.

HTH

--Chris


----------



## Phishfry (Jul 20, 2018)

ralphbsz said:


> Is the disk actually busy?  Try running `iostat` to diagnose this.


I agree with this. You need to see if the disk is actually busy, either by software or looking at the drive LED.
The boards GPIO subsystem controls the HDD Activity LED on the front panel header.
So my guess is something is not right there with the motherboard Super-IO controller and how it is detected by FreeBSD..
That or an ACPI bug as the GPIO signal from the SuperIO chip gets routed through the ACPI subsystem.


----------



## rowo (Jul 20, 2018)

Here ist the output of dmesg

```
[root@ghost /home/ghost]# dmesg 
Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 11.1-RELEASE-p11 #0: Thu Jun 21 03:46:08 UTC 2018
    root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0)
VT(vga): resolution 640x480
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (2605.96-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x60fb2  Family=0xf  Model=0x6b  Stepping=2
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x2001<SSE3,CX16>
  AMD Features=0xea500800<SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow!>
  AMD Features2=0x11f<LAHF,CMP,SVM,ExtAPIC,CR8,Prefetch>
  SVM: NAsids=64
real memory  = 4294967296 (4096 MB)
avail memory = 4096249856 (3906 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: <GBT    GBTUACPI>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
random: unblocking device.
ioapic0: Changing APIC ID to 2
ioapic0 <Version 2.1> irqs 0-23 on motherboard
SMP: AP CPU #1 Launched!
random: entropy device external interface
kbd1 at kbdmux0
netmap: loaded module
module_register_init: MOD_LOAD (vesa, 0xffffffff80f5ec40, 0) error 19
nexus0
vtvga0: <VT VGA driver> on motherboard
cryptosoft0: <software crypto> on motherboard
aesni0: No AESNI support.
acpi0: <GBT GBTUACPI> on motherboard
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
attimer0: <AT timer> port 0x40-0x43 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff irq 0,8 on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
atrtc0: <AT realtime clock> port 0x70-0x73 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
acpi_button0: <Power Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pcib0: Length mismatch for 3 range: 2ec00000 vs 2ed10000
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 2.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xef00-0xef7f mem 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 18 at device 0.0 on pci1
vgapci0: Boot video device
ahci0: <AMD SB600 AHCI SATA controller> port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 18.0 on pci0
ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported
ahci0: quirks=0x7000<NOMSI,ATI_PMP_BUG,MAXIO_64K>
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich2: <AHCI channel> at channel 2 on ahci0
ahcich3: <AHCI channel> at channel 3 on ahci0
ohci0: <OHCI (generic) USB controller> mem 0xfe02e000-0xfe02efff irq 16 at device 19.0 on pci0
usbus0 on ohci0
usbus0: 12Mbps Full Speed USB v1.0
ohci1: <OHCI (generic) USB controller> mem 0xfe02d000-0xfe02dfff irq 17 at device 19.1 on pci0
usbus1 on ohci1
usbus1: 12Mbps Full Speed USB v1.0
ohci2: <OHCI (generic) USB controller> mem 0xfe02c000-0xfe02cfff irq 18 at device 19.2 on pci0
usbus2 on ohci2
usbus2: 12Mbps Full Speed USB v1.0
ohci3: <OHCI (generic) USB controller> mem 0xfe02b000-0xfe02bfff irq 17 at device 19.3 on pci0
usbus3 on ohci3
usbus3: 12Mbps Full Speed USB v1.0
ohci4: <OHCI (generic) USB controller> mem 0xfe02a000-0xfe02afff irq 18 at device 19.4 on pci0
usbus4 on ohci4
usbus4: 12Mbps Full Speed USB v1.0
ehci0: <EHCI (generic) USB 2.0 controller> mem 0xfe029000-0xfe0290ff irq 19 at device 19.5 on pci0
ehci0: AMD SB600/700 quirk applied
usbus5: EHCI version 1.0
usbus5 on ehci0
usbus5: 480Mbps High Speed USB v2.0
atapci0: <ATI IXP600 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf900-0xf90f at device 20.1 on pci0
ata0: <ATA channel> at channel 0 on atapci0
hdac0: <ATI SB600 HDA Controller> mem 0xfe024000-0xfe027fff irq 16 at device 20.2 on pci0
isab0: <PCI-ISA bridge> at device 20.3 on pci0
isa0: <ISA bus> on isab0
pcib2: <ACPI PCI-PCI bridge> at device 20.4 on pci0
pci2: <ACPI PCI bus> on pcib2
re0: <RealTek 8169SC/8110SC Single-chip Gigabit Ethernet> port 0xde00-0xdeff mem 0xfdfff000-0xfdfff0ff irq 23 at device 15.0 on pci2
re0: Chip rev. 0x18000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
re0: Using defaults for TSO: 65518/35/2048
re0: Ethernet address: 00:1a:4d:f8:5a:d2
re0: netmap queues/slots: TX 1/256, RX 1/256
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
ppc0: <Parallel port> port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppbus0: <Parallel port bus> on ppc0
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
powernow0: <PowerNow! K8> on cpu0
powernow1: <PowerNow! K8> on cpu1
Timecounters tick every 1.000 msec
nvme cam probe device init
hdacc0: <Realtek ALC888 HDA CODEC> at cad 3 on hdac0
hdaa0: <Realtek ALC888 Audio Function Group> at nid 1 on hdacc0
pcm0: <Realtek ALC888 (Rear Analog 7.1/2.0)> at nid 20,22,21,23 and 24,26 on hdaa0
pcm1: <Realtek ALC888 (Front Analog)> at nid 27 and 25 on hdaa0
pcm2: <Realtek ALC888 (Rear Digital)> at nid 30 and 31 on hdaa0
ugen5.1: <ATI EHCI root HUB> at usbus5
ugen4.1: <ATI OHCI root HUB> at usbus4
uhub0: <ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus5
uhub1: <ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus4
ugen3.1: <ATI OHCI root HUB> at usbus3
ugen2.1: <ATI OHCI root HUB> at usbus2
uhub2: <ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3
uhub3: <ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2
ugen1.1: <ATI OHCI root HUB> at usbus1
ugen0.1: <ATI OHCI root HUB> at usbus0
uhub4: <ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
uhub5: <ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
(aprobe0:ahcich0:0:15:0): NOP FLUSHQUEUE. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
(aprobe0:ahcich0:0:15:0): CAM status: Command timeout
(aprobe0:ahcich0:0:15:0): Error 5, Retries exhausted
(aprobe2:ahcich2:0:15:0): NOP FLUSHQUEUE. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
(aprobe2:ahcich2:0:15:0): CAM status: Command timeout
(aprobe2:ahcich2:0:15:0): Error 5, Retries exhausted
(aprobe0:ahcich0:0:15:0): NOP FLUSHQUEUE. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
(aprobe0:ahcich0:0:15:0): CAM status: Command timeout
(aprobe0:ahcich0:0:15:0): Error 5, Retries exhausted
(aprobe2:ahcich2:0:15:0): NOP FLUSHQUEUE. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
(aprobe2:ahcich2:0:15:0): CAM status: Command timeout
(aprobe2:ahcich2:0:15:0): Error 5, Retries exhausted
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <Hitachi HDT721010SLA360 ST6OA31B> ATA8-ACS SATA 2.x device
ada0: Serial Number STH607MS1Y918S
cd0 at ata0 bus 0 scbus4 target 0 lun 0
ada0: 300.000MB/s transferscd0:  (<HL-DT-ST CD-RW GCE-8240B 1.06> Removable CD-ROM SCSI device
SATA 2.x, cd0: 16.700MB/s transfersUDMA6,  (WDMA2, PIO 8192bytesATAPI 12bytes, )
PIO 65534bytesada0: Command Queueing enabled
)
cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed
ada0: 953868MB (1953523055 512 byte sectors)
ada1 at ahcich2 bus 0 scbus2 target 0 lun 0
ada1: <Hitachi HDT721010SLA360 ST6OA31B> ATA8-ACS SATA 2.x device
ada1: Serial Number STF6L7MS281K9K
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 953868MB (1953523055 512 byte sectors)
Trying to mount root from ufs:/dev/label/rootfs0 [rw,noatime]...
uhub1: 2 ports with 2 removable, self powered
uhub2: 2 ports with 2 removable, self powered
uhub3: 2 ports with 2 removable, self powered
uhub4: 2 ports with 2 removable, self powered
uhub5: 2 ports with 2 removable, self powered
WARNING: /: TRIM flag on fs but disk does not support TRIM
uhub0: 10 ports with 10 removable, self powered
ugen0.2: <B16b02 USB-PS2 Optical Mouse> at usbus0
ugen5.2: <HP Photosmart B110 series> at usbus5
umass0 on uhub0
umass0: <HP Photosmart B110 series, class 0/0, rev 2.00/1.00, addr 2> on usbus5
umass0:  SCSI over Bulk-Only; quirks = 0x0000
umass0:5:0: Attached to scbus5
(probe0:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00 
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code)
(probe0:umass-sim0:0:0:0): Error 22, Unretryable error
da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
da0: <HP Photosmart B110 1.00> Removable Direct Access SPC-3 SCSI device
da0: 40.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
da0: quirks=0x2<NO_6_BYTE>
fuse-freebsd: version 0.4.4, FUSE ABI 7.8
Cuse v0.1.34 @ /dev/cuse
re0: link state changed to DOWN
ugen1.2: <Hewlett-Packard DeskJet 940C> at usbus1
ugen5.3: <Ralink 802.11 n WLAN> at usbus5
ums0 on uhub5
ums0: <B16b02 USB-PS2 Optical Mouse, class 0/0, rev 2.00/98.02, addr 2> on usbus0
ums0: 4 buttons and [XYZ] coordinates ID=0
ulpt0 on uhub0
ulpt0: <HP Photosmart B110 series, class 0/0, rev 2.00/1.00, addr 2> on usbus5
ulpt0: using bi-directional mode
ulpt0: output error
ulpt1 on uhub4
ulpt1: <Hewlett-Packard DeskJet 940C, class 0/0, rev 1.10/1.00, addr 2> on usbus1
ulpt1: using bi-directional mode
re0: link state changed to UP
```


----------



## ralphbsz (Jul 20, 2018)

Why does disk ada0 get lots of IO errors when being recognized (look for "NOP FLUSHQUEUE") ?  Something is broken on the SATA interface there; we're getting "command timeout".  This might be connected to the disk light staying on,.  Suggestion: Try replacing the SATA data and power cables to that disk.


----------



## SirDice (Jul 20, 2018)

ralphbsz said:


> Suggestion: Try replacing the SATA data and power cables to that disk.


If that doesn't help or work it's likely the disk itself is dead or dying.


----------



## rowo (Jul 20, 2018)

No, the disks are ok. I tested them with smartctl. A timeout error also occurs during the boot process when using Linux , that's just normal. But when using various different Linux distros, the LED works just normal, showing read/write activity.


----------



## Chris_H (Jul 20, 2018)

Have you used the disk with Linux _since_ the LED stayed lit?
The messages say hardware, _not_ software. I don't see the disk dying. Nor do I see impending doom. For some reason, the latch remains inverted, after (drive) initialization.
You should also consider removing the trim feature from your drive, as it's not supported:
WARNING: /: TRIM flag on fs but disk does not support TRIM
See tunefs(8) for how to implement the -t flag.

--Chris


----------



## Phishfry (Jul 20, 2018)

rowo said:


> <ATI SB600 HDA Controller>


The ATI chipsets were always trouble for me. Maybe look to see if there is not some quirks needed for the chipset.


----------



## rowo (Jul 20, 2018)

Yes, I have been booting Linux and FreeBSD several times, the LED still behaves normal when using Linux.

I tried to disable TRIM by

```
tunefs -t disable /dev/ada1s3
```
and rebooted - but still the same: after reboot the LED is on.

I then looked very carefully at the LED during the boot process. It stayed normal (getting on during read and off when there was nor activity) until the file system was mounted:

```
Trying to mount root from ufs:/dev/ada1s3a [rw]
```

From this point the LED stays on until reboot/shutdown.


----------



## rowo (Jul 20, 2018)

Phishfry said:


> The ATI chipsets were always trouble for me. Maybe look to see if there is not some quirks needed for the chipset.



I found an old thread https://forums.freebsd.org/threads/hard-drive-led-always-on.13467/

The suggestions are:

add to /mnt/boot/loader.conf 
ahci_load="YES"

change ada to da in fstab

sysctl vfs.read_max=32

I will try that tomorrow.


----------



## ralphbsz (Jul 21, 2018)

rowo said:


> ... A timeout error ..., that's just normal.


Nope, it is not normal.  Something is busted.  You should never get timeouts on disk interfaces (with the exception perhaps being drives with removable media when the media is out).

I think loading ahci will not help, because it's already running (plus, that advice was from a FreeBSD 8.0 thread, which is ancient).  The sysctl for VFS should have nothing to do with the LED (unless it causes the disk to actually be 100% busy, which makes no sense, but we're clearly discussing things that are either bugs, hardware problems, or make no sense here).

My advice remains: make sure the disk is really idly, by using a tool like iostat.  Also listen to the disk; if it is busy, you will hear it seek.  If the LED is on while the disk is idle, it must be some low-level communication problem between the FreeBSD SATA (=ahci) driver and the hardware, perhaps brought on by error conditions.


----------



## rowo (Jul 21, 2018)

Well, the disk is really idle most of the time. The "LED always on" phenomenon also occurs when booting FreeBSD from a USB stick. It does NOT occur when booting from a Linux USB Stick, so it must be something FreeBSD specific.


----------



## ralphbsz (Jul 21, 2018)

Strange.  Clearly, the FreeBSD SATA driver does something to the hardware that's different from Linux.  But we know that the FreeBSD SATA driver is not fundamentally broken, and I'm sure there are hundreds or thousands of computers with the same chipset that work correctly under FreeBSD.  And your disks are not terribly unusual either; standard Hitachi DeskStar.  So your machine must have some unusual configuration or hardware problem that tickles a bug in the FreeBSD driver.  If you are still getting the timeout errors, that's probably correlated with the problem.


----------



## rowo (Jul 23, 2018)

Yes, it's strange and FreeBSD specific. I installed OpenBSD and the LED activity is normal like when using Linux.


----------

