Re: acpiec(4): clear events based on vendor
On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. So this time it works... Did you apply the diff on top of a current sys? But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. And this time it does not? I'm confused :-) While at it I tried some recent snapshot kernels: - bsd.mp from May 23: shutdown because of wront acpitz temperatur - bsd.mp from June 6: hw.sensors.acpibat0.* recognized no reaction when I connect/reconnect the power supply - bsd.mp from June 10: same as June 6 # dmesg OpenBSD 5.5-current (GENERIC.MP) #172: Fri Jun 6 11:11:50 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3881746432 (3701MB) avail mem = 3769638912 (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.42 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,
Re: acpiec(4): clear events based on vendor
On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. So this time it works... Did you apply the diff on top of a current sys? I did a cvs up on June 10 and applied this diff on top of that. But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. And this time it does not? With this diff hw.sensors.acpiac0.indicator0 works correctly but hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 and June 10 it's the other way round. I'm confused :-) I can imagin - the complexity of acpi combined with Samsung's implementation and my imprecise description ... ;-) While at it I tried some recent snapshot kernels: - bsd.mp from May 23: shutdown because of wront acpitz temperatur - bsd.mp from June 6: hw.sensors.acpibat0.* recognized no reaction when I connect/reconnect the power supply - bsd.mp from June 10: same as June 6 # dmesg OpenBSD 5.5-current (GENERIC.MP) #172: Fri Jun 6 11:11:50 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3881746432 (3701MB) avail mem = 3769638912 (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.42 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
Re: acpiec(4): clear events based on vendor
Date: Wed, 11 Jun 2014 08:40:51 +0200 From: Remi Locherer remi.loche...@relo.ch On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. So this time it works... Did you apply the diff on top of a current sys? I did a cvs up on June 10 and applied this diff on top of that. But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. And this time it does not? With this diff hw.sensors.acpiac0.indicator0 works correctly but hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 and June 10 it's the other way round. I'm confused :-) I can imagin - the complexity of acpi combined with Samsung's implementation and my imprecise description ... ;-) Our acpi code does something wrong. This seems to be the root cause of the acpitz(4) problems that we're seeing on a wider variety of hardware. I really think we should try to fix that broader issue before trying to fix this more specific suspend/resume issue on Samsung hardware.
Re: acpiec(4): clear events based on vendor
On Wed, Jun 11, 2014 at 09:42:56PM +0200, Mark Kettenis wrote: Date: Wed, 11 Jun 2014 08:40:51 +0200 From: Remi Locherer remi.loche...@relo.ch On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. So this time it works... Did you apply the diff on top of a current sys? I did a cvs up on June 10 and applied this diff on top of that. But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. And this time it does not? With this diff hw.sensors.acpiac0.indicator0 works correctly but hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 and June 10 it's the other way round. I'm confused :-) I can imagin - the complexity of acpi combined with Samsung's implementation and my imprecise description ... ;-) Our acpi code does something wrong. This seems to be the root cause of the acpitz(4) problems that we're seeing on a wider variety of hardware. I really think we should try to fix that broader issue before trying to fix this more specific suspend/resume issue on Samsung hardware. Sure. This is not at all urgent. It can wait for someone to fix acpitz(4) on those machines.
Re: acpiec(4): clear events based on vendor
On Thu, Jun 12, 2014 at 12:45:23AM +0300, Paul Irofti wrote: On Wed, Jun 11, 2014 at 09:42:56PM +0200, Mark Kettenis wrote: Date: Wed, 11 Jun 2014 08:40:51 +0200 From: Remi Locherer remi.loche...@relo.ch On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. So this time it works... Did you apply the diff on top of a current sys? I did a cvs up on June 10 and applied this diff on top of that. But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. And this time it does not? With this diff hw.sensors.acpiac0.indicator0 works correctly but hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 and June 10 it's the other way round. I'm confused :-) I can imagin - the complexity of acpi combined with Samsung's implementation and my imprecise description ... ;-) Our acpi code does something wrong. This seems to be the root cause of the acpitz(4) problems that we're seeing on a wider variety of hardware. I really think we should try to fix that broader issue before trying to fix this more specific suspend/resume issue on Samsung hardware. Sure. This is not at all urgent. It can wait for someone to fix acpitz(4) on those machines. /me ducks :)
Re: acpiec(4): clear events based on vendor
On Wed, Jun 11, 2014 at 02:49:41PM -0700, Mike Larkin wrote: On Thu, Jun 12, 2014 at 12:45:23AM +0300, Paul Irofti wrote: On Wed, Jun 11, 2014 at 09:42:56PM +0200, Mark Kettenis wrote: Date: Wed, 11 Jun 2014 08:40:51 +0200 From: Remi Locherer remi.loche...@relo.ch On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. So this time it works... Did you apply the diff on top of a current sys? I did a cvs up on June 10 and applied this diff on top of that. But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. And this time it does not? With this diff hw.sensors.acpiac0.indicator0 works correctly but hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 and June 10 it's the other way round. I'm confused :-) I can imagin - the complexity of acpi combined with Samsung's implementation and my imprecise description ... ;-) Our acpi code does something wrong. This seems to be the root cause of the acpitz(4) problems that we're seeing on a wider variety of hardware. I really think we should try to fix that broader issue before trying to fix this more specific suspend/resume issue on Samsung hardware. Sure. This is not at all urgent. It can wait for someone to fix acpitz(4) on those machines. /me ducks :) I don't think there's any need for ducking, last I remember you don't own a Samsung machine.
Kill a warning building mg with clang
Hi tech@ -- Clang points this out when building mg: clang -O2 -pipe -Wall -DFKEYS -DREGEX -DXKEYS -c /home/brian/mg/buffer.c /home/brian/mg/buffer.c:461:11: warning: comparison of array 'bp-b_fname' not equal to a null pointer is always true [-Wtautological-pointer-compare] if (bp-b_fname != NULL *(bp-b_fname) != '\0' ^~~ 1 warning generated. Diff below to kill the warning. OK? ~Brian Index: buffer.c === RCS file: /cvs/src/usr.bin/mg/buffer.c,v retrieving revision 1.93 diff -u -p -r1.93 buffer.c --- buffer.c20 Mar 2014 07:47:29 - 1.93 +++ buffer.c12 Jun 2014 03:33:34 - @@ -458,7 +458,7 @@ anycb(int f) char pbuf[NFILEN + 11]; for (bp = bheadp; bp != NULL; bp = bp-b_bufp) { - if (bp-b_fname != NULL *(bp-b_fname) != '\0' + if (*(bp-b_fname) != '\0' (bp-b_flag BFCHG) != 0) { ret = snprintf(pbuf, sizeof(pbuf), Save file %s, bp-b_fname);