> Date: Sun, 23 Feb 2014 13:31:10 +0000 > From: Stuart Henderson <st...@openbsd.org> > > On 2014/02/23 10:40, Remi Locherer wrote: > > On Sat, Feb 22, 2014 at 07:14:01PM +0100, Mark Kettenis wrote: > > > > From: Theo de Raadt <dera...@cvs.openbsd.org> > > > > Date: Sat, 22 Feb 2014 09:55:41 -0700 > > > > > > > > This menas the acpitz bug must be found, and fixed. You need to reach > > > > out to an acpi hacker, like pirofti, to help diagnose the AML issue > > > > which underlies this. > > > > > > I had a quick look at the AML and it looks is if the embedded > > > controller is involved in reading the temperature. Perhaps SMM is > > > touching it behind our back, so I looked at the global lock code again > > > that is supposed to protect against that happening. > > > > > > Noticed that acpiec(4) tries to acquire the global lock, but doesn't > > > actually check whether it got it. The diff below fixes this by > > > unifying the code that checks for recursion and does the spinning. > > > Might fix things, or might lock up the machine solidly. Only one way > > > to find out... > > > > Thanks for having a look. I didn't notice any difference after I applied > > your patch: > > - no lock up > > - same wrong value for acpitz0 > > - battery not detected > > - no diff in dmesg (beside the build time of the kernel) > > > > > If this doesn't help, you should check whether memory at the following > > > addresses: > > > > > > 0xDAF7CE18 > > > 0xDAF9EF18 > > > 0xDAF7ADC0 > > > 0xDAF79F98 > > > > > > isn't actually marked as available by the BIOS. ACPI apparently > > > stored important data at those addresses, but if OpenBSD thinks that > > > memory is available and overwrites things, bad things will happen. > > > > > > I believe the easiest way to find out is to type "machine memory" at > > > the boot> prompt. > > > > I can't see the first few lines of the "machine memory" output. Is there > > a way to scroll back or use some sort of paging? Since I'm not sure how to > > interprete the numbers I uploaded a photo from the output: > > http://picpaste.com/samsung900X3F-machine-memory.png > > > > Remi > > > > I think you've got enough of it; the addresses above are covered > by this region > > Region 11: type 4 at 0xdaeef000 for 704KB > > $ moo 0xdaeef000+(704*1024) > 0xdaf9f000 3673812992 > > i.e. marked as available.
Well Type 4 is "ACPI NVS", which means it isn't regarded as free memory by OpenBSD. Everything seems to point into the direction of a bug in apciec(4).
