ATTN: ruik, others: f2a85-m frequently crashes/freezes under high load. do you have it working? - coreboot

17 Jan 2014


      ruik, do you have a working setup with a f2a85-m motherboard at the
moment (i.e. .config file, graphics card, distro/kernel version being
used?) if nothing is working for you right now, how can we narrow this down?
to anyone else: do you find that using one graphics card with coreboot,
works while others do not? any ideas on how i can resolve this issue?
the problems i've been seeing are quite reliable. they happen when using
coreboot + one of a couple graphics card models i've tried + extended
high disk i/o, all together. at other times, these issues are more rare.
also, a somewhat older compilation of coreboot with a vga_bios and
without an external graphics card is crashing multiple times per day,
during that person's day-to-day work flow.
i would like to get coreboot with this motherboard working, so more
people here can use it. :)
below, i give details of the crashes i've observed, their timing and the
type of stress test. (i haven't bisected this problem as well as i could
have so far, but there may be multiple interacting and non-interacting
issues here that i've tried to pin down.) i've attached kernel and
coreboot logs to this email.
my guess is that this is an issue with option roms playing nasty with
coreboot, and that this issue is for some reason brought forth by the
high i/o test. if any of those factors are absent, crashes are far less
frequent, if at all.
- - - - - - - - -
i've been seeing crashing with f2a85-m motherboards with an a8-5600k
processor. vga bioses have not been compiled in to coreboot.
kernel-loading of recent amd microcode has not solved the problem.
option roms get loaded by seabios (or coreboot, in the case of using
grub2 as a payload.) the distro is debian. i've moved from wheezy to
sid, with kernel 3.12. this did not seem to change much.
most of the tests were based on this commit:
697c1ed1ff93c3da040dd4bff0cbd1886bd5bf05
the stress test i've been using is mostly running badblocks on repeat
using a couple sata drives. the other test has been building four
kernels at once.
the symptom of crashing under high disk i/o is usually xscreensaver
(grinding to a halt then...) freezing, with unresponsive keyboard and
ssh. the kernel generally continues dumping over serial.
* with coreboot/seabios and an nvidia graphics card under high disk i/o,
the crash generally happens within a few hours, perhaps later
occasionally. (one time, xscreensaver continued for 20 hours, but ssh
and keyboard access failed.)
* with *uefi* and an nvidia graphics card under high disk i/o, i haven't
recorded a crash yet. my first formal test lasted 23h before i rebooted
to enable serial output by the kernel.
* with coreboot/seabios and an nvidia card under high *cpu/mem* usage,
but *low disk i/o*, a box lasted for 2.5 *days* before i decided to shut
it down.
* with coreboot/seabios and *without* a graphics card under high disk
i/o, one test lasted 36h before crashing.
* with coreboot/*grub2* payload and an nvidia graphics card under high
disk i/o, the crash was after about 1.5h. (strangely, one badblocks
process thought it had run for about 2x the uptime of the machine.)
* with coreboot/seabios and an msi graphics card under high disk i/o,
the crash happened around 4.5 hours later.
* a machine running an older coreboot/seabios/vga bios without an
external card, and running the latest version of trisquel: has been
crashing multiple times per day under heavy, or even very light work load.
i had other data points, but wasn't always recording details. recent
coreboot/kernel logs are attached to this email.
if anyone has any idea of what the issue(s) may be here, or how i could
try narrowing this down, please help me out. thanks! :)
-andrew