although the 'geom' driver has the capability of assigning an LED to indicate activity, assigning "kern.geom.disk.mmcsd0.led" to the correct 'led' device name does NOT appear to work. Upon further investigation, there appears to be no supporting code (i.e. calls to 'led_set' for example) in the mmcsd driver. And none of the code in the 'geom' driver appears to actually set the LED to 'on', except for errors. I first observed this in FreeBSD 11.0 on the Raspberry Pi 2 (RPI2 kernel). I can still observe it in the latest '-STABLE' release as of last week. I may be able to add a patch to this bug report that could possibly correct for this, either to the 'geom' driver or to the 'mmcsd' driver (as appropriate). In short, the mmcsd (or geom) driver would need to be updated to blink the LED in an appropriate manner while there is disk activity, using the appropriate sysctl variable (in this case, "kern.geom.disk.mmcsd0.led" or similar) to indicate which led to use (via 'led_set'), similar to some of the existing code in the geom driver. SYSTEM INFO: 'uname -a' string: FreeBSD pi2b 11.1-STABLE FreeBSD 11.1-STABLE #0 r330739: Sat Mar 10 16:07:22 PST 2018 bobf@hack.SFT.local:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm doing 'geom PART list' gives me this output: Geom name: mmcsd0 modified: false state: OK fwheads: 255 fwsectors: 63 last: 62333951 first: 63 entries: 4 scheme: MBR Providers: 1. Name: mmcsd0s1 Mediasize: 17805312 (17M) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 32256 Mode: r1w1e2 attrib: active rawtype: 12 length: 17805312 offset: 32256 type: !12 index: 1 end: 34838 start: 63 2. Name: mmcsd0s2 Mediasize: 31897145856 (30G) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 1060352 Mode: r1w1e3 rawtype: 165 length: 31897145856 offset: 17837568 type: freebsd index: 2 end: 62333951 start: 34839 Consumers: 1. Name: mmcsd0 Mediasize: 31914983424 (30G) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 0 Mode: r2w2e7 Geom name: mmcsd0s2 modified: false state: OK fwheads: 255 fwsectors: 63 last: 62299112 first: 0 entries: 8 scheme: BSD Providers: 1. Name: mmcsd0s2a Mediasize: 31897092096 (30G) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 1114112 Mode: r1w1e2 rawtype: 7 length: 31897092096 offset: 53760 type: freebsd-ufs index: 1 end: 62299112 start: 105 Consumers: 1. Name: mmcsd0s2 Mediasize: 31897145856 (30G) Sectorsize: 512 Stripesize: 4194304 Stripeoffset: 1060352 Mode: r1w1e3
You may want to check out https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189788 This proposed patch (from 2014) added a hook to do what you want. Not sure if any work is necessary to update the patch to 11.1
that patch looks pretty close to what I was thinking, actually, based on the code already in the geom driver that blinks the led on error, and also turns it off in a few places, but never seems to turn it on. The '!' is an interesting feature. Probably should be a separate patch, though. The 'led' driver handles polarity correctly if the DTD file has the right stuff in it to set the polarity [for example, the RPi model 1B has inverted polarity on the 'ok' LED].
someone in an IRC channel pointed out that the led device has enough inefficiency in it (due to looking up the LED pin name) to negatively impact the efficiency of disk access. So a patch to the led device may be needed to make solving this both reasonable and practical. cacheing an LED reference is one possibility, even if it's just "the last LED that was referenced", since disk access happens a LOT, and other kinds of LED activity typically don't. If the LED device were to be destroyed or altered, the led driver could flush the cache.
(In reply to bobf from comment #3) You may want to benchmark first. Originally I had thought there must be an impact, but in my tests (RPi, BBB, APU) there was no measurable difference (diskinfo, buildworld), so I abandoned any attempt at LED driver optimization. YMMV!