Searched hist:"426 fcab8" (Results 1 – 1 of 1) sorted by relevance
/openbmc/phosphor-net-ipmid/sol/ |
H A D | sol_context.cpp | 426fcab8 Wed Mar 13 09:56:50 CDT 2024 Konstantin Aladyshev <aladyshev22@gmail.com> SOL: Another attempt to fix coredump issue
The commit "SOL: Fix coredump due to recursive call deadlock" (5499bf862d1240bdbc061afc6e3d4f332c31329a) tried to fix coredump issue when the buffer size is larger than the send threshold (i.e. user types too fast in the SoL session). Despite of the commit message the provided solution doesn't seem to fix the crashdump issue. Revert 5499bf862d and implement a proper solution.
Normally 'enableAccumulateTimer()' launches a timer to accumulate data before send, and after the timeout the 'charAccTimerHandler()' sends all the data via the 'sendOutboundPayload()' function. If the buffer is not ready at that moment, the 'charAccTimerHandler()' relaunches the timer via the 'enableAccumulateTimer()' call. At the same time the 'enableAccumulateTimer()' function has an optimization: if the data size is more than 'sendThreshold' there is no point in timer, data can be send directly from the function. For that the current code calls the 'charAccTimerHandler()'. In the end this can create an endless recursion in times when buffer is not ready: enableAccumulateTimer() charAccTimerHandler() sendOutboundPayload() enableAccumulateTimer() ... To solve the issue we need to be careful about when we call the 'enableAccumulateTimer()' function: - first of all we don't need to call it from 'sendOutboundPayload()' since it is already called from the 'charAccTimerHandler()', - secondary in the 'enableAccumulateTimer' optimization case we don't need to call 'charAccTimerHandler()' which can re-launch timer but can just use 'sendOutboundPayload()' directly.
Tested: SOL console in ipmitool works fine if holding arrow up/down key for a long time.
Change-Id: Ibec03fc1394f23ba39b6f2d5a929928588e00590 Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
|