Bug #283
open
Low uptime while using YABEL on g505s
Added by nobody - over 3 years ago.
Updated over 3 years ago.
Description
Posted here originally.
Summary
With JDC_SUS_RLS I was able to maintain uptime of 40 days (had to reboot), however, with JDC_SEC_RLS it's no more than 4 days (2 weeks testing).
I could reproduce this behavior with self-compiled build (uptime no more than 8 days, 3 months testing). In bad cases uptime could be hours.
Symptoms
Any communication stops, display is lit and logon cursor stops blinking, fan is racing on top speed. With JDC_SEC_RLS fan speed is medium compared to low with JDC_SUS_RLS.
Action taken
Replaced power supply and RAM, used with UPS and without - no effect.
Motherboard
VALGC/GD LA-A091P, Rev : 1A, 2013-05-09
Configs in question could be found here. Self-compiled config attached. Affects, at least, stable release 4.12 (12 May).
Files
- Assignee set to Mike Banon
- % Done changed from 0 to 50
Both JDC_SUS_RLS and JDC_SEC_RLS have a YABEL enabled. If you'd compare their configs with a kdiff3 or meld, the only difference between them - is
# CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT is not set
vs
CONFIG_SECURITY_CLEAR_DRAM_ON_REGULAR_BOOT=y
It's a known problem that this config breaks S3 Suspend on AMD (PC freezes while trying to wake up) and I mentioned it in this README - https://github.com/mikebdp2/coreboot-g505s-builds . See a comment by Kyösti Mälkki under https://review.coreboot.org/c/coreboot/+/33956 :
AGESA has valuables in low memory and coreboot does not really keep account of them. I think it's BIOS_HEAP_START_ADDRESS + _SIZE you are not allowed to clear. So I expect S3 resume with that CLEAR_DRAM feature enabled to fail regardless of this commit.
So, if you would like to use this option, I suggest to disable a sleep mode / hibernation in your Linux distro, to avoid these freezes. If that's indeed a cause of your "low uptime" problem, please change % Done to 100%, otherwise please reply.
Thank you for the response.
I thought the sleep/hibernate was disabled, but after a double check I discovered it might not be completely. I'll begin to test it once again.
Though, while using JDC_SUS_RLS, I can confirm with help of monitoring software that laptop is not entering any sleep/hibernate and is working constantly. Maybe it tries to, but logs are absent regarding this.
Also available in: Atom
PDF