Re: [SOLVED] Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
previously on this list Remi Locherer contributed: > After not looking into this for a while I tested the snapshot from July > 20 on the Samsung 900X3F. The Problem described in the bug report does > not happen anymore. Thanks for fixing this! > > (now I only wait for xhci and Atheros AR9462 support ;) ) Yeah it was reported during the last hackathon that the bug affecting HP machines was fixed which I guess fixed the Samsungs 900X3F too. I've been meaning to look into it but haven't fount the time yet. Is it understood why removing the battery between boots avoided the issue? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
[SOLVED] Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
On Sat, Feb 22, 2014 at 04:04:40PM +0100, Remi Locherer wrote: > >Synopsis:wrong acpitz temperature and acpibat0 not detecting battery > >Category:acpi > >Environment: > System : OpenBSD 5.5 > Details : OpenBSD 5.5-beta (GENERIC.MP) #2: Fri Feb 21 08:50:33 CET > 2014 > > r...@samsung.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > On the Samsung 900X3F acpitz0 reports wrong temperature which > leads to a shutdown. The battery is not recognized by acpibat. > > I also tested on OpenBSD 5.3 and 5.3: same result. > > # sysctl hw.sensors > hw.sensors.cpu0.temp0=45.00 degC > hw.sensors.cpu1.temp0=45.00 degC > hw.sensors.cpu2.temp0=45.00 degC > hw.sensors.cpu3.temp0=45.00 degC > hw.sensors.acpitz0.temp0=144.00 degC (zone temperature) > hw.sensors.acpitz1.temp0=29.80 degC (zone temperature) > hw.sensors.acpiac0.indicator0=Off (power supply) > hw.sensors.acpibtn0.indicator0=Off (lid open) > hw.sensors.softraid0.drive0=online (sd1), OK > > Whyle the notebook runs on battery: > # apm > Battery state: absent, 0% remaining, unknown life estimate > A/C adapter state: not connected > Performance adjustment mode: cool running (774 MHz > After not looking into this for a while I tested the snapshot from July 20 on the Samsung 900X3F. The Problem described in the bug report does not happen anymore. Thanks for fixing this! (now I only wait for xhci and Atheros AR9462 support ;) ) OpenBSD 5.6-beta (GENERIC.MP) #292: Sun Jul 20 05:27:41 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3881746432 (3701MB) avail mem = 3769630720 (3595MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries) bios0: vendor Phoenix Technologies Ltd. version "P00ACX" date 04/26/2013 bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM UEFI UEFI acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.38 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus 2 (RP04) acpiprt6 at acpi0: bus 3 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt1
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
On Fri, Apr 18, 2014 at 06:43:25PM +0300, Paul Irofti wrote:
> This is the important part of the trace:
>
> > 4e10 Store
> > 4e11 \\_SB_.PCI0.LPCB.H_EC.CTMP
> > locking
> > field: aml_rwgas bitpos 1536 bpos 0 blen 8,flags 0x11
> > read 03 00c0 0008 [\\_SB_.PCI0.LPCB.H_EC.ECR_]
> > gasio rd: 3 0xc0 1 1 851728760
> > aml_bufcpy: 0x90
> > unlocking
> > 4e28 Local0
> > 4e29 If
> > 4e2b LNotEqual
> > 4e2d Local0
> > 4e2e 0xff
> > 4e30 Return
> > 4e31 Add
> > 4e32 0x0aac
> > 4e35 Multiply
> > 4e36 Local0
> > 4e37 0x0a
> > acpitz0: critical temperature exceeded 144C, shutting down
>
> What happens is that we read 8 bits from bit-position (bitpos) 1536
> from the ECR field from the EC and then store it in Local0.
>
> What we read from there is 0x90, which is 144 in decimal.
>
> The revelant AML code looks like this:
>
> Store (\_SB.PCI0.LPCB.H_EC.CTMP, Local0)
> If (LNotEqual (Local0, 0xFF))
> Return (Add (0x0AAC, Multiply (Local0, 0x0A)))
>
> CTMP is supposed to keep the temperature in Celsius, thus it needs a
> conversion to Kelvin.
>
> So what this does is check if the value it just read is different from
> 0xFF and if so it converts the value to Kelvin degrees and returns them
> to the upper layers as required by the ACPI spec.
>
> Local0 * 10 + 2732 => 4172 which is 417.2K as dictated by the spec.
>
> Then userland transforms it back to Celsius and freaks out.
>
>
> The field, from your AML dump, looks like the following:
>
> Field (ECR, ByteAcc, Lock, Preserve) {
> [...]
> Offset (0xC0),
> CTMP, 8,
> [...] }
>
> Offset 0xC0 is the offset in bytes from the beginning of the field and
> it's 192 in decimal which translates to 192 * 4 = 1536 bits.
> This matches the bitpos from which the temperature was read, so the
> position is correct.
>
> Thus the bad news is that the bug is not a bitpos parsing bug...
>
> This happens only with OpenBSD? Linux or Windows runs fine, right?
Both Windows and Linux run fine. I can not test Windows anymore but I
just started Fedora 20 and verified that the two thermal zones present
temperatur values that make sense.
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
This is the important part of the trace:
> 4e10 Store
> 4e11 \\_SB_.PCI0.LPCB.H_EC.CTMP
> locking
> field: aml_rwgas bitpos 1536 bpos 0 blen 8,flags 0x11
> read 03 00c0 0008 [\\_SB_.PCI0.LPCB.H_EC.ECR_]
> gasio rd: 3 0xc0 1 1 851728760
> aml_bufcpy: 0x90
> unlocking
> 4e28 Local0
> 4e29 If
> 4e2b LNotEqual
> 4e2d Local0
> 4e2e 0xff
> 4e30 Return
> 4e31 Add
> 4e32 0x0aac
> 4e35 Multiply
> 4e36 Local0
> 4e37 0x0a
> acpitz0: critical temperature exceeded 144C, shutting down
What happens is that we read 8 bits from bit-position (bitpos) 1536
from the ECR field from the EC and then store it in Local0.
What we read from there is 0x90, which is 144 in decimal.
The revelant AML code looks like this:
Store (\_SB.PCI0.LPCB.H_EC.CTMP, Local0)
If (LNotEqual (Local0, 0xFF))
Return (Add (0x0AAC, Multiply (Local0, 0x0A)))
CTMP is supposed to keep the temperature in Celsius, thus it needs a
conversion to Kelvin.
So what this does is check if the value it just read is different from
0xFF and if so it converts the value to Kelvin degrees and returns them
to the upper layers as required by the ACPI spec.
Local0 * 10 + 2732 => 4172 which is 417.2K as dictated by the spec.
Then userland transforms it back to Celsius and freaks out.
The field, from your AML dump, looks like the following:
Field (ECR, ByteAcc, Lock, Preserve) {
[...]
Offset (0xC0),
CTMP, 8,
[...] }
Offset 0xC0 is the offset in bytes from the beginning of the field and
it's 192 in decimal which translates to 192 * 4 = 1536 bits.
This matches the bitpos from which the temperature was read, so the
position is correct.
Thus the bad news is that the bug is not a bitpos parsing bug...
This happens only with OpenBSD? Linux or Windows runs fine, right?
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
On Fri, Apr 18, 2014 at 12:34:44PM +0300, Paul Irofti wrote: > Closing in... what does this button do? > Shut down with lot of output of course ;) OpenBSD 5.5-current (GENERIC.MP) #3: Fri Apr 18 12:05:40 CEST 2014 r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3881746432 (3701MB) avail mem = 3769647104 (3595MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries) bios0: vendor Phoenix Technologies Ltd. version "P00ACX" date 04/26/2013 bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM UEFI UEFI acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.41 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus 2 (RP04) acpiprt6 at acpi0: bus 3 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpicpu2 at acpi0: C3, C2, C1, PSS acpicpu3 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 106 degC acpitz1 at acpi0: critical temperature is 106 degC acpibat0 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit offline acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 774 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1920x1080 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured azalia0 at pci0 dev 27 function 0 "Intel 7 Series HD Audio" rev 0x04: msi azalia0: codecs: Realtek ALC269, Intel/0x28
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
On Fri, Apr 18, 2014 at 12:34:44PM +0300, Paul Irofti wrote: > Closing in... what does this button do? In case someone wants to chime in and have a look at the issue: The diff consists of 3 parts: - acpiec clear events on resume and power-on (both events are good/tolarated on his machine) - enables acpi global lock support (needed for field locking when accessing the CTMP field that stores the current temperature) - tracing in the AML parser when CTMP is read and Local0 is written to to see where the bug starts manifesting So far I think at least the bit offset in the Field is calculated wrong by the parser: - tracer says 1500-something - my math shows it should be 1703 The last diff adds a bit of extra tracing around the read at this offset so that I can have more data and so that I can start looking at the bit offset calculations.
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
Closing in... what does this button do?
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.205
diff -u -p -r1.205 dsdt.c
--- dsdt.c 12 Dec 2013 20:56:01 - 1.205
+++ dsdt.c 18 Apr 2014 09:33:15 -
@@ -114,6 +114,8 @@ int aml_intlen = 64;
struct aml_nodeaml_root;
struct aml_value *aml_global_lock;
+int noisy;
+
/* Perfect Hash key */
#define HASH_OFF 6904
#define HASH_SIZE 179
@@ -736,72 +738,68 @@ static long global_lock_count = 0;
void
acpi_glk_enter(void)
{
- acpi_acquire_glk(&acpi_softc->sc_facs->global_lock);
-}
-
-void
-acpi_glk_leave(void)
-{
- int x;
-
- if (acpi_release_glk(&acpi_softc->sc_facs->global_lock)) {
- /*
-* If pending, notify the BIOS that the lock was released
-* by the OSPM. No locking is needed because nobody outside
-* the ACPI thread is touching this register.
-*/
- x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
- x |= ACPI_PM1_GBL_RLS;
- acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
- }
-}
-
-void
-aml_lockfield(struct aml_scope *scope, struct aml_value *field)
-{
int st = 0;
- if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
- return;
-
- /* If lock is already ours, just continue */
+ /* If lock is already ours, just continue. */
if (global_lock_count++)
return;
- /* Spin to acquire lock */
+ /* Spin to acquire the lock. */
while (!st) {
st = acpi_acquire_glk(&acpi_softc->sc_facs->global_lock);
/* XXX - yield/delay? */
}
-
- return;
}
void
-aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
+acpi_glk_leave(void)
{
- int st, x, s;
-
- if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
- return;
+ int st, x;
- /* If we are the last ones, turn out the lights */
+ /* If we are the last one, turn out the lights. */
if (--global_lock_count)
return;
- /* Release lock */
st = acpi_release_glk(&acpi_softc->sc_facs->global_lock);
if (!st)
return;
- /* Signal others if someone waiting */
- s = spltty();
+ /*
+* If pending, notify the BIOS that the lock was released by
+* OSPM. No locking is needed because nobody outside the ACPI
+* thread is supposed to touch this register.
+*/
x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
x |= ACPI_PM1_GBL_RLS;
acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
- splx(s);
+}
- return;
+void
+aml_lockfield(struct aml_scope *scope, struct aml_value *field)
+{
+ if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON) {
+ if (noisy)
+ printf("lock not needed\n");
+ return;
+ }
+
+ if (noisy)
+ printf("locking\n");
+ acpi_glk_enter();
+}
+
+void
+aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
+{
+ if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON) {
+ if (noisy)
+ printf("unlock not needed\n");
+ return;
+ }
+
+ if (noisy)
+ printf("unlocking\n");
+ acpi_glk_leave();
}
/*
@@ -2259,11 +2257,13 @@ aml_rwgas(struct aml_value *rgn, int bpo
void *tbit, *vbit;
int slen, type, sz;
- dnprintf(10," %5s %.2x %.8llx %.4x [%s]\n",
- mode == ACPI_IOREAD ? "read" : "write",
- rgn->v_opregion.iospace,
- rgn->v_opregion.iobase + (bpos >> 3),
- blen, aml_nodename(rgn->node));
+ if (noisy) {
+ printf(" %5s %.2x %.8llx %.4x [%s]\n",
+ mode == ACPI_IOREAD ? "read" : "write",
+ rgn->v_opregion.iospace,
+ rgn->v_opregion.iobase + (bpos >> 3),
+ blen, aml_nodename(rgn->node));
+ }
memset(&tmp, 0, sizeof(tmp));
pi.addr = rgn->v_opregion.iobase + (bpos >> 3);
if (rgn->v_opregion.iospace == GAS_PCI_CFG_SPACE)
@@ -2315,9 +2315,16 @@ aml_rwgas(struct aml_value *rgn, int bpo
if (mode == ACPI_IOREAD) {
/* Read bits from opregion */
+ if (noisy) {
+ printf("gasio rd: %d %#llx %d %d %d\n",
+ type, pi.addr, sz, slen, tbit);
+ }
acpi_gasio(acpi_softc, ACPI_IOREAD, type, pi.addr,
sz, slen, tbit);
aml_bufcpy(vbit, 0, tbit, bpos & 7, blen);
+ if (noisy) {
+ p
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
On Mon, Apr 14, 2014 at 07:09:47PM +0300, Paul Irofti wrote: > Thanks for testing! > > I need a bit more info, could you tell me what the output is when > applying the following diff on top of -current? Here you go: OpenBSD 5.5-current (GENERIC.MP) #2: Mon Apr 14 22:45:53 CEST 2014 r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3881746432 (3701MB) avail mem = 3769651200 (3595MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries) bios0: vendor Phoenix Technologies Ltd. version "P00ACX" date 04/26/2013 bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM UEFI UEFI acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.41 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus 2 (RP04) acpiprt6 at acpi0: bus 3 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpicpu2 at acpi0: C3, C2, C1, PSS acpicpu3 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 106 degC acpitz1 at acpi0: critical temperature is 106 degC acpibat0 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit offline acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 774 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1920x1080 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel 7 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured azalia0 at pci0 dev 27 function 0 "Intel 7 Serie
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
Thanks for testing!
I need a bit more info, could you tell me what the output is when
applying the following diff on top of -current?
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.205
diff -u -p -r1.205 dsdt.c
--- dsdt.c 12 Dec 2013 20:56:01 - 1.205
+++ dsdt.c 14 Apr 2014 16:06:58 -
@@ -114,6 +114,8 @@ int aml_intlen = 64;
struct aml_nodeaml_root;
struct aml_value *aml_global_lock;
+int noisy;
+
/* Perfect Hash key */
#define HASH_OFF 6904
#define HASH_SIZE 179
@@ -736,72 +738,68 @@ static long global_lock_count = 0;
void
acpi_glk_enter(void)
{
- acpi_acquire_glk(&acpi_softc->sc_facs->global_lock);
-}
-
-void
-acpi_glk_leave(void)
-{
- int x;
-
- if (acpi_release_glk(&acpi_softc->sc_facs->global_lock)) {
- /*
-* If pending, notify the BIOS that the lock was released
-* by the OSPM. No locking is needed because nobody outside
-* the ACPI thread is touching this register.
-*/
- x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
- x |= ACPI_PM1_GBL_RLS;
- acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
- }
-}
-
-void
-aml_lockfield(struct aml_scope *scope, struct aml_value *field)
-{
int st = 0;
- if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
- return;
-
- /* If lock is already ours, just continue */
+ /* If lock is already ours, just continue. */
if (global_lock_count++)
return;
- /* Spin to acquire lock */
+ /* Spin to acquire the lock. */
while (!st) {
st = acpi_acquire_glk(&acpi_softc->sc_facs->global_lock);
/* XXX - yield/delay? */
}
-
- return;
}
void
-aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
+acpi_glk_leave(void)
{
- int st, x, s;
-
- if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
- return;
+ int st, x;
- /* If we are the last ones, turn out the lights */
+ /* If we are the last one, turn out the lights. */
if (--global_lock_count)
return;
- /* Release lock */
st = acpi_release_glk(&acpi_softc->sc_facs->global_lock);
if (!st)
return;
- /* Signal others if someone waiting */
- s = spltty();
+ /*
+* If pending, notify the BIOS that the lock was released by
+* OSPM. No locking is needed because nobody outside the ACPI
+* thread is supposed to touch this register.
+*/
x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
x |= ACPI_PM1_GBL_RLS;
acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
- splx(s);
+}
+
+void
+aml_lockfield(struct aml_scope *scope, struct aml_value *field)
+{
+ if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON) {
+ if (noisy)
+ printf("lock not needed\n");
+ return;
+ }
+
+ if (noisy)
+ printf("locking\n");
+ acpi_glk_enter();
+}
+
+void
+aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
+{
+ if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON) {
+ if (noisy)
+ printf("unlock not needed\n");
+ return;
+ }
- return;
+ if (noisy)
+ printf("unlocking\n");
+ acpi_glk_leave();
}
/*
@@ -2335,6 +2333,10 @@ aml_rwgas(struct aml_value *rgn, int bpo
}
/* Copy target bits, then write to region */
aml_bufcpy(tbit, bpos & 7, vbit, 0, blen);
+ if (noisy) {
+ printf("gasio: %d %#llx %d %d %d\n", type, pi.addr, sz,
+ slen, tbit);
+ }
acpi_gasio(acpi_softc, ACPI_IOWRITE, type, pi.addr,
sz, slen, tbit);
@@ -2440,6 +2442,11 @@ aml_rwfield(struct aml_value *fld, int b
aml_rwgas(ref1, fld->v_field.bitpos, fld->v_field.bitlen,
val, mode, fld->v_field.flags);
} else if (fld->v_field.type == AMLOP_FIELD) {
+ if (noisy) {
+ printf("field: aml_rwgas bitpos %d bpos %d blen %d,"
+ "flags %#x\n", fld->v_field.bitpos, bpos, blen,
+ fld->v_field.flags);
+ }
aml_rwgas(ref1, fld->v_field.bitpos + bpos, blen, val, mode,
fld->v_field.flags);
} else if (mode == ACPI_IOREAD) {
@@ -2450,6 +2457,9 @@ aml_rwfield(struct aml_value *fld, int b
} else {
/* bufferfield:write */
val = aml_conve
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
On Sat, Apr 12, 2014 at 04:00:40PM +0300, Paul Irofti wrote: > > I'll send a tracing diff your way soon because I'm curious what the > > AML path is inside _TMP once your machine resumes. > > Here it is. Careful it might be really noisy and further tweaks might be > needed. Let me know what the output is and I'll see what needs to be > done next. This time the system didn't shut down after boot and I could do a suspend / resume cycle. It halted during resume because of acpitz. OpenBSD 5.5-current (GENERIC.MP) #1: Sun Apr 13 07:24:17 CEST 2014 r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3881746432 (3701MB) avail mem = 3769651200 (3595MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries) bios0: vendor Phoenix Technologies Ltd. version "P00ACX" date 04/26/2013 bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM UEFI UEFI acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.40 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus 2 (RP04) acpiprt6 at acpi0: bus 3 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpicpu2 at acpi0: C3, C2, C1, PSS acpicpu3 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 106 degC acpitz1 at acpi0: critical temperature is 106 degC acpibat0 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit offline acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 774 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1 d
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
On Sat, Apr 12, 2014 at 04:00:40PM +0300, Paul Irofti wrote: > > I'll send a tracing diff your way soon because I'm curious what the > > AML path is inside _TMP once your machine resumes. > > Here it is. Careful it might be really noisy and further tweaks might be > needed. Let me know what the output is and I'll see what needs to be > done next. > > Note, I'm interested first in the diff I sent earlier and afterwards in > this one. Here the dmesg from a kernel with your tracing diff applied. Thanks a lot for your time you're putting into this! Remi OpenBSD 5.5-current (GENERIC.MP) #1: Sun Apr 13 07:24:17 CEST 2014 r...@mistral.relo.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3881746432 (3701MB) avail mem = 3769651200 (3595MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries) bios0: vendor Phoenix Technologies Ltd. version "P00ACX" date 04/26/2013 bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM UEFI UEFI acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.41 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus 2 (RP04) acpiprt6 at acpi0: bus 3 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpicpu2 at acpi0: C3, C2, C1, PSS acpicpu3 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 106 degC acpitz1 at acpi0: critical temperature is 106 degC acpibat0 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit offline acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 774 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09 vga1 at pci0 dev 2 function 0 "Intel HD Graphics 4000" rev 0x09 intagp0 at vga
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
> I applied the previous patch to a fresh checked out source tree which didn't > contain below changes. Should I have applied several patches together? Nope. The way you applyed and tested is correct. Thanks! In general I don't send diffs on top of other diffs as it just makes it confusing for all involved.
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
On Sat, Apr 12, 2014 at 01:47:15PM +0300, Paul Irofti wrote:
> Very strange...
>
> I'm still investigating the issue and glancing at your acpidump.
> I'll send a tracing diff your way soon because I'm curious what the
> AML path is inside _TMP once your machine resumes.
>
> Until then I wanted to ask you if you're also testing with the glk diff
> when you're testing my acpiec_clear_events diff?
I applied the previous patch to a fresh checked out source tree which didn't
contain below changes. Should I have applied several patches together?
Applying this patch to a freshly checked out source tree results in the
same behaviour as with last tests: the system shuts down right after
boot because of wrong temperator for acpitz0 and sometimes it's getting it
right. Ususally battery data is absent or only partly there.
> You should have the following in /sys/dev/acpi:
>
>
> Index: dsdt.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
> retrieving revision 1.205
> diff -u -p -r1.205 dsdt.c
> --- dsdt.c12 Dec 2013 20:56:01 - 1.205
> +++ dsdt.c12 Apr 2014 10:45:02 -
> @@ -736,72 +736,58 @@ static long global_lock_count = 0;
> void
> acpi_glk_enter(void)
> {
> - acpi_acquire_glk(&acpi_softc->sc_facs->global_lock);
> -}
> -
> -void
> -acpi_glk_leave(void)
> -{
> - int x;
> -
> - if (acpi_release_glk(&acpi_softc->sc_facs->global_lock)) {
> - /*
> - * If pending, notify the BIOS that the lock was released
> - * by the OSPM. No locking is needed because nobody outside
> - * the ACPI thread is touching this register.
> - */
> - x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
> - x |= ACPI_PM1_GBL_RLS;
> - acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
> - }
> -}
> -
> -void
> -aml_lockfield(struct aml_scope *scope, struct aml_value *field)
> -{
> int st = 0;
>
> - if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
> - return;
> -
> - /* If lock is already ours, just continue */
> + /* If lock is already ours, just continue. */
> if (global_lock_count++)
> return;
>
> - /* Spin to acquire lock */
> + /* Spin to acquire the lock. */
> while (!st) {
> st = acpi_acquire_glk(&acpi_softc->sc_facs->global_lock);
> /* XXX - yield/delay? */
> }
> -
> - return;
> }
>
> void
> -aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
> +acpi_glk_leave(void)
> {
> - int st, x, s;
> + int st, x;
>
> - if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
> - return;
> -
> - /* If we are the last ones, turn out the lights */
> + /* If we are the last one, turn out the lights. */
> if (--global_lock_count)
> return;
>
> - /* Release lock */
> st = acpi_release_glk(&acpi_softc->sc_facs->global_lock);
> if (!st)
> return;
>
> - /* Signal others if someone waiting */
> - s = spltty();
> + /*
> + * If pending, notify the BIOS that the lock was released by
> + * OSPM. No locking is needed because nobody outside the ACPI
> + * thread is supposed to touch this register.
> + */
> x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
> x |= ACPI_PM1_GBL_RLS;
> acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
> - splx(s);
> +}
> +
> +void
> +aml_lockfield(struct aml_scope *scope, struct aml_value *field)
> +{
> + if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
> + return;
> +
> + acpi_glk_enter();
> +}
> +
> +void
> +aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
> +{
> + if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
> + return;
>
> - return;
> + acpi_glk_leave();
> }
>
> /*
> Index: acpiec.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
> retrieving revision 1.48
> diff -u -p -r1.48 acpiec.c
> --- acpiec.c 2 Jul 2013 18:37:47 - 1.48
> +++ acpiec.c 12 Apr 2014 10:45:03 -
> @@ -34,6 +34,7 @@
>
> int acpiec_match(struct device *, void *, void *);
> void acpiec_attach(struct device *, struct device *, void *);
> +int acpiec_activate(struct device *, int);
>
> u_int8_t acpiec_status(struct acpiec_softc *);
> u_int8_t acpiec_read_data(struct acpiec_softc *);
> @@ -54,6 +55,7 @@ int acpiec_getregister(const u_int8_t *
>
> void acpiec_wait(struct acpiec_softc *, u_int8_t, u_int8_t);
> void acpiec_sci_event(struct acpiec_softc *);
> +void acpiec_clear_events(struct acpiec_softc *);
>
> void acpiec_get_events(struct acpiec_softc *);
>
> @@ -82,7 +84,8 @@ voidacpiec_
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
> I'll send a tracing diff your way soon because I'm curious what the
> AML path is inside _TMP once your machine resumes.
Here it is. Careful it might be really noisy and further tweaks might be
needed. Let me know what the output is and I'll see what needs to be
done next.
Note, I'm interested first in the diff I sent earlier and afterwards in
this one.
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.205
diff -u -p -r1.205 dsdt.c
--- dsdt.c 12 Dec 2013 20:56:01 - 1.205
+++ dsdt.c 12 Apr 2014 12:57:31 -
@@ -114,6 +114,8 @@ int aml_intlen = 64;
struct aml_nodeaml_root;
struct aml_value *aml_global_lock;
+int noisy;
+
/* Perfect Hash key */
#define HASH_OFF 6904
#define HASH_SIZE 179
@@ -736,72 +738,58 @@ static long global_lock_count = 0;
void
acpi_glk_enter(void)
{
- acpi_acquire_glk(&acpi_softc->sc_facs->global_lock);
-}
-
-void
-acpi_glk_leave(void)
-{
- int x;
-
- if (acpi_release_glk(&acpi_softc->sc_facs->global_lock)) {
- /*
-* If pending, notify the BIOS that the lock was released
-* by the OSPM. No locking is needed because nobody outside
-* the ACPI thread is touching this register.
-*/
- x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
- x |= ACPI_PM1_GBL_RLS;
- acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
- }
-}
-
-void
-aml_lockfield(struct aml_scope *scope, struct aml_value *field)
-{
int st = 0;
- if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
- return;
-
- /* If lock is already ours, just continue */
+ /* If lock is already ours, just continue. */
if (global_lock_count++)
return;
- /* Spin to acquire lock */
+ /* Spin to acquire the lock. */
while (!st) {
st = acpi_acquire_glk(&acpi_softc->sc_facs->global_lock);
/* XXX - yield/delay? */
}
-
- return;
}
void
-aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
+acpi_glk_leave(void)
{
- int st, x, s;
+ int st, x;
- if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
- return;
-
- /* If we are the last ones, turn out the lights */
+ /* If we are the last one, turn out the lights. */
if (--global_lock_count)
return;
- /* Release lock */
st = acpi_release_glk(&acpi_softc->sc_facs->global_lock);
if (!st)
return;
- /* Signal others if someone waiting */
- s = spltty();
+ /*
+* If pending, notify the BIOS that the lock was released by
+* OSPM. No locking is needed because nobody outside the ACPI
+* thread is supposed to touch this register.
+*/
x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
x |= ACPI_PM1_GBL_RLS;
acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
- splx(s);
+}
+
+void
+aml_lockfield(struct aml_scope *scope, struct aml_value *field)
+{
+ if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
+ return;
+
+ acpi_glk_enter();
+}
+
+void
+aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
+{
+ if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
+ return;
- return;
+ acpi_glk_leave();
}
/*
@@ -3423,7 +3411,8 @@ aml_parse(struct aml_scope *scope, int r
/* No opcode handler */
aml_die("Unknown opcode: %.4x @ %.4x", opcode, pc);
}
- dnprintf(18,"%.4x %s\n", pc, aml_mnem(opcode, scope->pos));
+ if (noisy)
+ printf("%.4x %s\n", pc, aml_mnem(opcode, scope->pos));
/* --== Stage 1: Process opcode arguments ==-- */
memset(opargs, 0, sizeof(opargs));
Index: acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.48
diff -u -p -r1.48 acpiec.c
--- acpiec.c2 Jul 2013 18:37:47 - 1.48
+++ acpiec.c12 Apr 2014 12:57:32 -
@@ -34,6 +34,7 @@
intacpiec_match(struct device *, void *, void *);
void acpiec_attach(struct device *, struct device *, void *);
+intacpiec_activate(struct device *, int);
u_int8_t acpiec_status(struct acpiec_softc *);
u_int8_t acpiec_read_data(struct acpiec_softc *);
@@ -54,6 +55,7 @@ int acpiec_getregister(const u_int8_t *
void acpiec_wait(struct acpiec_softc *, u_int8_t, u_int8_t);
void acpiec_sci_event(struct acpiec_softc *);
+void acpiec_clear_events(struct acpiec_softc *);
void acpiec_get_events(struct acpiec_softc *
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
Very strange...
I'm still investigating the issue and glancing at your acpidump.
I'll send a tracing diff your way soon because I'm curious what the
AML path is inside _TMP once your machine resumes.
Until then I wanted to ask you if you're also testing with the glk diff
when you're testing my acpiec_clear_events diff?
You should have the following in /sys/dev/acpi:
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.205
diff -u -p -r1.205 dsdt.c
--- dsdt.c 12 Dec 2013 20:56:01 - 1.205
+++ dsdt.c 12 Apr 2014 10:45:02 -
@@ -736,72 +736,58 @@ static long global_lock_count = 0;
void
acpi_glk_enter(void)
{
- acpi_acquire_glk(&acpi_softc->sc_facs->global_lock);
-}
-
-void
-acpi_glk_leave(void)
-{
- int x;
-
- if (acpi_release_glk(&acpi_softc->sc_facs->global_lock)) {
- /*
-* If pending, notify the BIOS that the lock was released
-* by the OSPM. No locking is needed because nobody outside
-* the ACPI thread is touching this register.
-*/
- x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
- x |= ACPI_PM1_GBL_RLS;
- acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
- }
-}
-
-void
-aml_lockfield(struct aml_scope *scope, struct aml_value *field)
-{
int st = 0;
- if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
- return;
-
- /* If lock is already ours, just continue */
+ /* If lock is already ours, just continue. */
if (global_lock_count++)
return;
- /* Spin to acquire lock */
+ /* Spin to acquire the lock. */
while (!st) {
st = acpi_acquire_glk(&acpi_softc->sc_facs->global_lock);
/* XXX - yield/delay? */
}
-
- return;
}
void
-aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
+acpi_glk_leave(void)
{
- int st, x, s;
+ int st, x;
- if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
- return;
-
- /* If we are the last ones, turn out the lights */
+ /* If we are the last one, turn out the lights. */
if (--global_lock_count)
return;
- /* Release lock */
st = acpi_release_glk(&acpi_softc->sc_facs->global_lock);
if (!st)
return;
- /* Signal others if someone waiting */
- s = spltty();
+ /*
+* If pending, notify the BIOS that the lock was released by
+* OSPM. No locking is needed because nobody outside the ACPI
+* thread is supposed to touch this register.
+*/
x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
x |= ACPI_PM1_GBL_RLS;
acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
- splx(s);
+}
+
+void
+aml_lockfield(struct aml_scope *scope, struct aml_value *field)
+{
+ if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
+ return;
+
+ acpi_glk_enter();
+}
+
+void
+aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
+{
+ if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
+ return;
- return;
+ acpi_glk_leave();
}
/*
Index: acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.48
diff -u -p -r1.48 acpiec.c
--- acpiec.c2 Jul 2013 18:37:47 - 1.48
+++ acpiec.c12 Apr 2014 10:45:03 -
@@ -34,6 +34,7 @@
intacpiec_match(struct device *, void *, void *);
void acpiec_attach(struct device *, struct device *, void *);
+intacpiec_activate(struct device *, int);
u_int8_t acpiec_status(struct acpiec_softc *);
u_int8_t acpiec_read_data(struct acpiec_softc *);
@@ -54,6 +55,7 @@ int acpiec_getregister(const u_int8_t *
void acpiec_wait(struct acpiec_softc *, u_int8_t, u_int8_t);
void acpiec_sci_event(struct acpiec_softc *);
+void acpiec_clear_events(struct acpiec_softc *);
void acpiec_get_events(struct acpiec_softc *);
@@ -82,7 +84,8 @@ void acpiec_unlock(struct acpiec_softc
intacpiec_reg(struct acpiec_softc *);
struct cfattach acpiec_ca = {
- sizeof(struct acpiec_softc), acpiec_match, acpiec_attach
+ sizeof(struct acpiec_softc), acpiec_match, acpiec_attach,
+ NULL, acpiec_activate
};
struct cfdriver acpiec_cd = {
@@ -296,6 +299,8 @@ acpiec_attach(struct device *parent, str
acpi_set_gpehandler(sc->sc_acpi, sc->sc_gpe, acpiec_gpehandler,
sc, 1);
#endif
+
+ acpiec_clear_events(sc);
if (aml_evalname(sc->sc_acpi, sc->sc_devnode, "_GLK", 0, NULL, &res))
sc->sc_glk = 0;
@@ -307,6 +312,20 @@ ac
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
Hi Paul
On Wed, Apr 02, 2014 at 06:22:35PM +0300, Paul Irofti wrote:
> Hi Remi,
>
> thank you for the detailed report and for your patience.
>
> I was wondering if you could test the following diff and let me know
> what happens.
I applied this patch to a freshly checked out source tree on April 2
and tested a few boot sequences:
#1
https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404032101.txt
acpitz0 ok, battery sensors partly
zzz: imediate shutdown after resume: acpitz0 > 144
#2
https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404032104.txt
immediate shutdown, acpitz0 > 144
#3
https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404032136.txt
acpitz0 ok, battery sensors partly
zzz: imediate shutdown after resume: acpitz0 > 144
#4
https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404032138.txt
immediate shutdown, acpitz0 > 144
#5
https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404032140.txt
immediate shutdown, acpitz0 > 144
#6
https://relo.ch/dmesg-samsung900X3F/dmesg-samsung900X3F-201404032147.txt
acpitz0 ok, battery sensors partly, keyboard illumination on
zzz: imediate shutdown after resume: acpitz0 > 144,
keyboard illumination stays off during and after resume
Thank you for having a look into this!
Remi
>
> Thanks,
> Paul
>
> Index: dev/acpi/acpiec.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
> retrieving revision 1.48
> diff -u -p -r1.48 acpiec.c
> --- dev/acpi/acpiec.c 2 Jul 2013 18:37:47 - 1.48
> +++ dev/acpi/acpiec.c 2 Apr 2014 15:21:00 -
> @@ -34,6 +34,7 @@
>
> int acpiec_match(struct device *, void *, void *);
> void acpiec_attach(struct device *, struct device *, void *);
> +int acpiec_activate(struct device *, int);
>
> u_int8_t acpiec_status(struct acpiec_softc *);
> u_int8_t acpiec_read_data(struct acpiec_softc *);
> @@ -54,6 +55,7 @@ int acpiec_getregister(const u_int8_t *
>
> void acpiec_wait(struct acpiec_softc *, u_int8_t, u_int8_t);
> void acpiec_sci_event(struct acpiec_softc *);
> +void acpiec_clear_events(struct acpiec_softc *);
>
> void acpiec_get_events(struct acpiec_softc *);
>
> @@ -82,7 +84,8 @@ voidacpiec_unlock(struct acpiec_softc
> int acpiec_reg(struct acpiec_softc *);
>
> struct cfattach acpiec_ca = {
> - sizeof(struct acpiec_softc), acpiec_match, acpiec_attach
> + sizeof(struct acpiec_softc), acpiec_match, acpiec_attach,
> + NULL, acpiec_activate
> };
>
> struct cfdriver acpiec_cd = {
> @@ -296,6 +299,8 @@ acpiec_attach(struct device *parent, str
> acpi_set_gpehandler(sc->sc_acpi, sc->sc_gpe, acpiec_gpehandler,
> sc, 1);
> #endif
> +
> + /* acpiec_clear_events(sc); */
>
> if (aml_evalname(sc->sc_acpi, sc->sc_devnode, "_GLK", 0, NULL, &res))
> sc->sc_glk = 0;
> @@ -307,6 +312,20 @@ acpiec_attach(struct device *parent, str
> printf("\n");
> }
>
> +int
> +acpiec_activate(struct device *self, int act)
> +{
> + struct acpiec_softc *sc = (struct acpiec_softc *)self;
> +
> +
> + switch (act) {
> + case DVACT_RESUME:
> + acpiec_clear_events(sc);
> + break;
> + }
> + return (0);
> +}
> +
> void
> acpiec_get_events(struct acpiec_softc *sc)
> {
> @@ -552,4 +571,19 @@ acpiec_unlock(struct acpiec_softc *sc)
> }
>
> sc->sc_ecbusy = 0;
> +}
> +
> +void
> +acpiec_clear_events(struct acpiec_softc *sc)
> +{
> + int i;
> +
> + for (i = 0; i < 100; i++) {
> + /*acpiec_write_cmd(sc, EC_CMD_QR);*/
> + bus_space_write_1(sc->sc_cmd_bt, sc->sc_cmd_bh, 0, EC_CMD_QR);
> + sc->sc_gotsci = 0;
> + if ((acpiec_status(sc) & EC_STAT_SCI_EVT) != EC_STAT_SCI_EVT) {
> + break;
> + }
> + }
> }
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
Hi Remi,
thank you for the detailed report and for your patience.
I was wondering if you could test the following diff and let me know
what happens.
Thanks,
Paul
Index: dev/acpi/acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.48
diff -u -p -r1.48 acpiec.c
--- dev/acpi/acpiec.c 2 Jul 2013 18:37:47 - 1.48
+++ dev/acpi/acpiec.c 2 Apr 2014 15:21:00 -
@@ -34,6 +34,7 @@
intacpiec_match(struct device *, void *, void *);
void acpiec_attach(struct device *, struct device *, void *);
+intacpiec_activate(struct device *, int);
u_int8_t acpiec_status(struct acpiec_softc *);
u_int8_t acpiec_read_data(struct acpiec_softc *);
@@ -54,6 +55,7 @@ int acpiec_getregister(const u_int8_t *
void acpiec_wait(struct acpiec_softc *, u_int8_t, u_int8_t);
void acpiec_sci_event(struct acpiec_softc *);
+void acpiec_clear_events(struct acpiec_softc *);
void acpiec_get_events(struct acpiec_softc *);
@@ -82,7 +84,8 @@ void acpiec_unlock(struct acpiec_softc
intacpiec_reg(struct acpiec_softc *);
struct cfattach acpiec_ca = {
- sizeof(struct acpiec_softc), acpiec_match, acpiec_attach
+ sizeof(struct acpiec_softc), acpiec_match, acpiec_attach,
+ NULL, acpiec_activate
};
struct cfdriver acpiec_cd = {
@@ -296,6 +299,8 @@ acpiec_attach(struct device *parent, str
acpi_set_gpehandler(sc->sc_acpi, sc->sc_gpe, acpiec_gpehandler,
sc, 1);
#endif
+
+ /* acpiec_clear_events(sc); */
if (aml_evalname(sc->sc_acpi, sc->sc_devnode, "_GLK", 0, NULL, &res))
sc->sc_glk = 0;
@@ -307,6 +312,20 @@ acpiec_attach(struct device *parent, str
printf("\n");
}
+int
+acpiec_activate(struct device *self, int act)
+{
+ struct acpiec_softc *sc = (struct acpiec_softc *)self;
+
+
+ switch (act) {
+ case DVACT_RESUME:
+ acpiec_clear_events(sc);
+ break;
+ }
+ return (0);
+}
+
void
acpiec_get_events(struct acpiec_softc *sc)
{
@@ -552,4 +571,19 @@ acpiec_unlock(struct acpiec_softc *sc)
}
sc->sc_ecbusy = 0;
+}
+
+void
+acpiec_clear_events(struct acpiec_softc *sc)
+{
+ int i;
+
+ for (i = 0; i < 100; i++) {
+ /*acpiec_write_cmd(sc, EC_CMD_QR);*/
+ bus_space_write_1(sc->sc_cmd_bt, sc->sc_cmd_bh, 0, EC_CMD_QR);
+ sc->sc_gotsci = 0;
+ if ((acpiec_status(sc) & EC_STAT_SCI_EVT) != EC_STAT_SCI_EVT) {
+ break;
+ }
+ }
}
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
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 + > > > From: Stuart Henderson > > > > > > 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 > > > > > > 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) > > > 0xdaf9f0003673812992 > > > > > > 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
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
> Date: Sun, 23 Feb 2014 13:31:10 + > From: Stuart Henderson > > 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 > > > > 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) > 0xdaf9f0003673812992 > > 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).
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
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 > > > 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.
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
On Sat, Feb 22, 2014 at 07:14:01PM +0100, Mark Kettenis wrote: > > From: Theo de Raadt > > 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
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
> From: Theo de Raadt
> 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...
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.
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.205
diff -u -p -r1.205 dsdt.c
--- dsdt.c 12 Dec 2013 20:56:01 - 1.205
+++ dsdt.c 22 Feb 2014 18:03:16 -
@@ -736,72 +736,58 @@ static long global_lock_count = 0;
void
acpi_glk_enter(void)
{
- acpi_acquire_glk(&acpi_softc->sc_facs->global_lock);
-}
-
-void
-acpi_glk_leave(void)
-{
- int x;
-
- if (acpi_release_glk(&acpi_softc->sc_facs->global_lock)) {
- /*
-* If pending, notify the BIOS that the lock was released
-* by the OSPM. No locking is needed because nobody outside
-* the ACPI thread is touching this register.
-*/
- x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
- x |= ACPI_PM1_GBL_RLS;
- acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
- }
-}
-
-void
-aml_lockfield(struct aml_scope *scope, struct aml_value *field)
-{
int st = 0;
- if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
- return;
-
- /* If lock is already ours, just continue */
+ /* If lock is already ours, just continue. */
if (global_lock_count++)
return;
- /* Spin to acquire lock */
+ /* Spin to acquire the lock. */
while (!st) {
st = acpi_acquire_glk(&acpi_softc->sc_facs->global_lock);
/* XXX - yield/delay? */
}
-
- return;
}
void
-aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
+acpi_glk_leave(void)
{
- int st, x, s;
+ int st, x;
- if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
- return;
-
- /* If we are the last ones, turn out the lights */
+ /* If we are the last one, turn out the lights. */
if (--global_lock_count)
return;
- /* Release lock */
st = acpi_release_glk(&acpi_softc->sc_facs->global_lock);
if (!st)
return;
- /* Signal others if someone waiting */
- s = spltty();
+ /*
+* If pending, notify the BIOS that the lock was released by
+* OSPM. No locking is needed because nobody outside the ACPI
+* thread is supposed to touch this register.
+*/
x = acpi_read_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0);
x |= ACPI_PM1_GBL_RLS;
acpi_write_pmreg(acpi_softc, ACPIREG_PM1_CNT, 0, x);
- splx(s);
+}
+
+void
+aml_lockfield(struct aml_scope *scope, struct aml_value *field)
+{
+ if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
+ return;
+
+ acpi_glk_enter();
+}
+
+void
+aml_unlockfield(struct aml_scope *scope, struct aml_value *field)
+{
+ if (AML_FIELD_LOCK(field->v_field.flags) != AML_FIELD_LOCK_ON)
+ return;
- return;
+ acpi_glk_leave();
}
/*
Re: Samsung900X3F: wrong acpitz temperature, acpibat0 not detecting battery
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.
