On 2015-11-12 13:55, Nico Huber wrote:
Hi,
had a look at your logs:
On 11.11.2015 00:49, Patrick 'P. J.' McDermott wrote:
These systems fail to resume in one of the following ways:
- S3 resume (indicated by the SLP_TYP bit) is detected, SLP_TYP is cleared, DRAM receive-enable calibration fails with a timing under/overflow, the system resets, and coreboot boots normally into the payload (with the sleep LED still on) because SLP_TYP is now unset. See x200-resume-fail-receive-enable-calibration.log and t400-resume-fail-receive-enable-calibration.log.
- S3 resume is detected, SLP_TYP is cleared, raminit and the rest of romstage completes without error, but then something between the southbridge's smm_init() and cpu_initialize() hangs (maybe the system is stuck in SMM). See x200-resume-fail-smm-hang.log and t400-resume-fail-smm-hang.log.
I have yet no idea about the SMM hang.
- S3 resume is detected, SLP_TYP is cleared, romstage completes, but something within smm_init() hangs before dumping (possibly while clearing [1]) TCO1_STS bits. See t400-resume-fail-tco-hang.log
The logs are all a little garbled. It looks to me like this is exactly the same hang as in *-resume-fail-smm-hang.log.
There are a couple of other ways in which I've seen S3 resume fail, but these are the most common.
I thought of working around the first issue (clearing SLP_TYP, resetting due to a raminit error, then booting into the payload) by clearing SLP_TYP near the end of the romstage main() (after raminit). So I tried the following patch:
diff --git a/src/mainboard/lenovo/x200/romstage.c b/src/mainboard/lenovo/x200/romstage.c index 86a973f..915baf2 100644 --- a/src/mainboard/lenovo/x200/romstage.c +++ b/src/mainboard/lenovo/x200/romstage.c @@ -103,10 +103,6 @@ void main(unsigned long bist) #if CONFIG_HAVE_ACPI_RESUME printk(BIOS_DEBUG, "Resume from S3 detected.\n"); s3resume = 1;
/* Clear SLP_TYPE. This will break stage2 but* we care for that when we get there.*/outl(pm1_cnt & ~(7 << 10), DEFAULT_PMBASE + 0x04);#else printk(BIOS_DEBUG, "Resume from S3 detected, but disabled.\n"); #endif @@ -190,6 +186,11 @@ void main(unsigned long bist)
/* Magic for S3 resume */ pci_write_config32(PCI_DEV(0, 0, 0), D0F0_SKPD, SKPAD_ACPI_S3_MAGIC);
/* Clear SLP_TYPE. This will break stage2 but* we care for that when we get there.*/outl(pm1_cnt & ~(7 << 10), DEFAULT_PMBASE + 0x04);
But that just made these errors even more frequent. Trying to resume from S3 put the system into a reset loop with receive-enable calibration errors (see x200-patched-resume-fail-receive-enable-loop.log). So instead of rebooting into the payload or hanging, the system just resets forever.
This reset loop is very interesting. Did it end sometime? It could mean the worst, i.e. the RAM lost its configuration (self refresh failed). I suspect that's the case as there is not much difference in the normal vs. the resume path until receive-enable calibration.
No, it didn't end. I once left it running for probably at least 10 or 20 minutes, so it must have gone through hundreds of raminit/reset cycles.
As shown in *-resume-fail-receive-enable-calibration.log, that kind of raminit failure happens with an unpatched coreboot as well (more commonly on the X200 than the SMM hang does). So it makes some sense that patching romstage main() in the way that I did would cause that error to happen in a loop. Basically, that patch fixed the problem of losing SLP_TYP after reset but worsened the problem of raminit failing. (It's a little odd that the loop /never/ ended, while sometimes an unpatched coreboot would get past receive-enable calibration in the resume path.)
What doesn't make sense is that receive-enable calibration only fails when SLP_TYP is set. But it always works when SLP_TYP is unset (as in a normal boot or with an unpatched coreboot after S3 resume is detected, raminit fails, and the system resets).