I uploaded a status report for the X201 and it contains the smashed stack message. Since then I booted several times but was not able to reproduce this stack smashing issue. It seems like that this kind of error occurs only once after flashing. Please find attached a diff of the notable differences of a new console log compared to the one I pushed to board-status. It supports that there is an issue with the initial raminit.
Cheers, Matthias
On 02/05/18 20:12, ron minnich wrote:
Yeah I think you want to hunt this stack smash error down, it's not something you want to ignore.
On Wed, May 2, 2018 at 11:09 AM Kyösti Mälkki kyosti.malkki@gmail.com wrote:
On Wed, May 2, 2018 at 8:53 PM, Nico Huber nico.h@gmx.de wrote:
On 02.05.2018 18:37, qtux wrote:
Thanks for your detailed explanation. So in essence shall I ignore the messages or blacklist lpc_ich?
Yes, either ;)
Besides, while preparing the status report, I sometimes find a "Smashed stack detected in romstage!" message in the console log, just before ramstage is starting. Is there something to worry about there?
Um, yes. I think that's not good. But I wonder why it's not happening consistently.
I commented about that earlier in this thread. Seemed like actual raminit eats a lot of stack, but loading from MRC cache or equivalent does not. One could find that struct and move it to BSS, declared with CAR_GLOBAL. I would rather not extend the boundary for stack-smashing detection.
Kyösti
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
On 03/05/18 21:51, qtux wrote:
I uploaded a status report for the X201 and it contains the smashed stack message. Since then I booted several times but was not able to reproduce this stack smashing issue. It seems like that this kind of error occurs only once after flashing. Please find attached a diff of the notable differences of a new console log compared to the one I pushed to board-status. It supports that there is an issue with the initial raminit.
Cheers, Matthias
On 02/05/18 20:12, ron minnich wrote:
Yeah I think you want to hunt this stack smash error down, it's not something you want to ignore.
On Wed, May 2, 2018 at 11:09 AM Kyösti Mälkki kyosti.malkki@gmail.com wrote:
On Wed, May 2, 2018 at 8:53 PM, Nico Huber nico.h@gmx.de wrote:
On 02.05.2018 18:37, qtux wrote:
Thanks for your detailed explanation. So in essence shall I ignore the messages or blacklist lpc_ich?
Yes, either ;)
Besides, while preparing the status report, I sometimes find a "Smashed stack detected in romstage!" message in the console log, just before ramstage is starting. Is there something to worry about there?
Um, yes. I think that's not good. But I wonder why it's not happening consistently.
I commented about that earlier in this thread. Seemed like actual raminit eats a lot of stack, but loading from MRC cache or equivalent does not. One could find that struct and move it to BSS, declared with CAR_GLOBAL. I would rather not extend the boundary for stack-smashing detection.
Kyösti
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
I uploaded a proposed fix for the smashed stack issue:
https://review.coreboot.org/#/c/coreboot/+/26388/
Side note: I tried adding CAR_GLOBAL to the ram_training and the raminfo struct. Both had no effect on the issue.
Cheers, Matthias
-
qtux