On Fri, Mar 28, 2014 at 08:55:44AM +0100, Remi Locherer wrote: > On Sun, Feb 23, 2014 at 03:01:14PM +0100, Mark Kettenis wrote: > > > Date: Sun, 23 Feb 2014 13:31:10 +0000 > > > From: Stuart Henderson <[email protected]> > > > > > > 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 <[email protected]> > > > > > > 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). > > > > I applied the acpiec patch [1] and tested on the Samsung 900X3F. In one > out of about 10 boots it gets the temperature and battery facts > (or at least partly). But most of the time the behaviour is still the same > and it just reboots because it gets the temp wrong for acpitz0 and no > info for the battery. > > Below dmesg, sysctl hw, pcidump and acpidump from a successful boot. > > [1] http://marc.info/?l=openbsd-tech&m=139586828926337&w=2
I updated to a new snapshot and rebooted the notebook a couple of times with strange effects. This time it often recognized acpitz0 correctly and didn't shut down imediately. But it never recognized when I connected the A/C adapter (or removed it). Also the details about the battery where not always (or only partly) displayd with sysctl hw.sensors or apm. Each time the acpitz sensors were recognized correctly the keyboard back lit was switched on. When rebooting with the reboot command after the sensors were recognized correctly it also worked afterwards. But when I halted the notebook and switched it on after waiting a bit the chance was about 50% that it stayed up. Suspend and resume worked when acpitz was recognized correctly. Though sometimes while resuming it printed a warning (but with a kernel from an old snapshot): acpitz0: TZ00: failed to read temp I tried with kernels from from different snapshots but looked like this made no big difference. To me it's still unpredictable when it works and when not. I made the notebook to store dmesg and sysctl hw output during each shutdown and put the files here: https://relo.ch/dmesg-samsung900X3F/ # Examples where the it worked fine: https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404010021.txt https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404010023.txt https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404010028.txt # Examples with only partial battery stats https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201403310806.txt https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404010003.txt # Examples with an acpitz warning and automatic shutdown: https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201403310816.txt https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404010042.txt
