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