ah, well thanks for taking a look. On Thu, Oct 8, 2015 at 3:09 PM, Mike Larkin <mlar...@azathoth.net> wrote:
> On Wed, Oct 07, 2015 at 11:17:25PM -0400, Dewey Hylton wrote: > > you missed my update which followed that post. it did not survive the > night > > - even with lm disabled in the kernel, some number of reboots later i > > encountered the same failure. that update is on the list, but i'll > include > > the copy/paste below. > > > > meanwhile, is there still hope for answers relating to acpi? > > > > I doubt it. I took a look at your AML and it seemed reasonable. > > -ml > > > ---------- Forwarded message ---------- > > From: Dewey Hylton <dewey.hyl...@gmail.com> > > To: misc@openbsd.org > > Cc: > > Date: Tue, 15 Sep 2015 19:19:10 +0000 (UTC) > > Subject: Re: requesting help working around boot failures with supermicro > > atom board > > Dewey Hylton <dewey.hylton <at> gmail.com> writes: > > > > > > > > Mark Kettenis <mark.kettenis <at> xs4all.nl> writes: > > > > > > Oh that is interesting. Can you try disabling the lm(4) driver in > > > > your kernel? You can do: > > > > > > > > # config -ef /bsd > > > > ... > > > > ukc> disable lm > > > > 254 lm0 disabled > > > > 255 lm* disabled > > > > 256 lm* disabled > > > > ukc> quit > > > > Saving modified kernel. > > > > # reboot > > > > > > > > That reboot will probably still hang. But it'd be interesting to see > > > > if any subsequent reboots work better. > > > > > > > > > sadly, the first thing i heard when entering the lab this morning was > > BEEEEEP! > > > > so disabling the sensor drivers in the kernel did not do the trick. > without > > other ideas, i'm down to providing acpidump output and hoping someone can > > tell me where to go next ... > > > > > > On Wed, Oct 7, 2015 at 12:41 AM, Mike Larkin <mlar...@azathoth.net> > wrote: > > > > > On Tue, Sep 15, 2015 at 02:45:02AM +0000, Dewey Hylton wrote: > > > > Mark Kettenis <mark.kettenis <at> xs4all.nl> writes: > > > > > > > > > > > > > > > # sysctl -a|grep 'sensors.*temp' > > > > > > hw.sensors.cpu0.temp0=30.00 degC > > > > > > hw.sensors.lm1.temp0=0.00 degC > > > > > > hw.sensors.lm1.temp1=14.00 degC > > > > > > hw.sensors.lm1.temp2=14.00 degC > > > > > > # reboot > > > > > > > > > > > > BEEEEEEEEEEEEEEEP! > > > > > > > > > > Oh that is interesting. Can you try disabling the lm(4) driver in > > > > > your kernel? You can do: > > > > > > > > > > # config -ef /bsd > > > > > ... > > > > > ukc> disable lm > > > > > 254 lm0 disabled > > > > > 255 lm* disabled > > > > > 256 lm* disabled > > > > > ukc> quit > > > > > Saving modified kernel. > > > > > # reboot > > > > > > > > > > That reboot will probably still hang. But it'd be interesting to > see > > > > > if any subsequent reboots work better. > > > > > > > > *this* interests me, and was basically what i was asking in the > original > > > > post - except i had no idea what might need to be disabled. one step > at a > > > > time, it's been interesting the things that have popped up. > > > > > > > > still no idea whether this has anything to do with the seemingly > > > > openbsd-only issue, but ... > > > > > > > > i made this change, booted the new kernel, ran 'cksum /dev/mem' a > bunch > > > of > > > > times in hopes of raising the temperature somewhat (did get to 36C, > > > which is > > > > higher than in my previous tests). then i rebooted, and the box came > > > back up > > > > without incident. > > > > > > > > so i'm going to run through this several times with reboots in every > 20 > > > > minutes or so and see if it survives the night. > > > > > > > > > > Based on this and my previous email, my recommendation would be to > disable > > > lm(4) on this particular machine.
