<lists <at> wrant.com> writes: > > > Whether they are identical or not, showing us a dmesg diff with a known > > working release booted from both a working and the non-working system > > could also be helpful. > > Another Supermicro X7SPA-HF-D525 board (same chipset/CPU combination) > has been having the same issue since early 2011 (the entire life span > of the system), always running a recent snapshot: > > http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA-HF-D525.cfm > > There is absolutely no sense in running a 2010 snapshot now, except for > experiments as suggested by Benny. > > Please try and see if it makes a difference comparing reboots of the > system over SSH, on the local console, over serial console, and with > serial over LAN. I can provide test results over all these methods > given some tech suggestion / solution. > > You may want to have a DMI / PCI / ACPI dumps, let me know how / if you > want these from my system too (attach brief newbie instructions please). > > So far, nothing has solved it yet for me too, except power cycle via the > PSU breaker each time this happens. Never tried any other OS except > OpenBSD, thought it was the hardware (memory by the beep code) fault, > but it's not (confirmed with long runs of memtest). The system > runs for very long intervals without any other issues, except the > reboot behaviour in the original post, confirming same problem. Running > latest BIOS and IPMI firmwares. > > Thanks, Dewey for testing this more extensively than I had the nerve to.
this is great information, and i've passed it along to supermicro as a "i'm not the only one with this issue" datapoint. since i'm apparently not alone, this looks more like a board/firmware design issue - just curious why none of my other boards have this issue. i'm not knowledgeable enough to provide newbie instructions on the dumps, but if doing this makes sense to anyone here with more hardware experience i'm certainly willing to try it. regarding the comparison of reboots, do you mean testing reboots initiated via different means (ssh/console/etc.)? if so, i've done that and ruled them out. last test was a shell script with sleep/reboot commands which executed via rc.local - meaning there was no user login prior to the failure. thanks for this information.
