Re: SSL3 hello over SSL2
On Thu, 17 Apr 2014, Martin Nilsson wrote: ... I don't know. I just know that the client part failed to connect to a server where I removed all SSL2 code. Yeah, we're going to be stuck with grotty understand the backwards compat handshake server code for a while to come, even past the time when the clients are actually willing to fallback to SSLv2, which is *real* dumbness. Philip
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) {
+ printf(aml_bufcpy: %#x\n, val-v_integer);
+
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
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/0x2806, using
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 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.
