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