Bug 226684

Summary:	mmcsd driver does not indicate SD card activity on 'activity' LED
Product:	Base System	Reporter:	Bob Frazier <bobf>
Component:	arm	Assignee:	freebsd-arm (Nobody) <freebsd-arm>
Status:	New ---
Severity:	Affects Many People	CC:	emaste, ksw.childe, ronald-lists
Priority:	---
Version:	11.1-STABLE
Hardware:	Any
OS:	Any

Description Bob Frazier 2018-03-17 22:38:41 UTC

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

Comment 1 Keith White 2018-03-18 23:58:33 UTC

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

Comment 2 Bob Frazier 2018-03-20 08:10:48 UTC

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].

Comment 3 Bob Frazier 2018-03-29 18:55:19 UTC

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.

Comment 4 Keith White 2018-03-29 19:24:24 UTC

(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!