@Networker17 wrote:
"running gag" or "never-endig-story" - I don't know?
c2960x-universalk9-mz.152-7.E6.bin ...does not seem to solve this issue
CPU utilization for five seconds: 39%/0%; one minute: 39%; five minutes: 39%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
179 210992768 19554357 10790 23.33% 23.21% 23.24% 0 Hulc LED Process
141 5239200 782643 6694 0.59% 0.59% 0.59% 0 hpm counter proc
CSCtg86211
- Created Date - May 18, 2010
- Last Modified - Aug 21, 2024
- Status - Terminated
- Severity - 3 Moderate
- Known Fixed Releases (0)
Neither really. It's also documented, in that "bug":
"Workaround: This is an expected behavior and there is no workaround."
What Cisco doesn't describe, as it's a software process, it may have an execution priority relative to other processes, and further, that priority may be lower than other processes. I.e. even if that process were using 100% of the CPU, it would usually have very little impact to other higher priority processes. To itself, or other processes of the same priority or lower priority, those could be severely impacted if you run out of CPU. However, I suspect managing LEDs is not a high priority process.
Further, on a switch, ideally all (programmed) data forwarding doesn't need CPU at all.
Lastly, the "bug" was closed (I presume because of what I noted in red).
Or as us software developers might say "it's not a bug, it's a feature". ; )
