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
