AutoTest/SuccessAfterFailure
The wiki is being retired!
Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to https://doc.coreboot.org/. Contributions welcome!
To increase test throughput and to ensure maximal test coverage, the REACTS runs all tests with RS232 logging disabled. In the event that a test boot fails, the REACTS will automatically rebuild, reflash, and retest the same code with RS232 logging enabled. In certain cases this process can cause the failure to be bypassed on the second test run, yielding confusing and conflicting results.
This page attempts to list some of the known causes of this behaviour.
1.) Altered ramstage memory layout. In at least one instance Raptor Engineering has observed the memory layout in ramstage changing due to the RS232 console alterations, and as a result buggy code that looks at the wrong memory bytes (for example if two .c files have differing ideas about the contents of a data structure) can sometimes boot when the RS232 console is enabled but not when it is is disabled (or vice versa).
2.) Race conditions that are triggered by the lack of slower printk() spinlocking during serial output, or simply by the increased boot speed.