Re: add nl(1)
On Wed, May 15, 2013 at 06:16:55AM -0600, Todd C. Miller wrote: I've taken your diff and merged some useful bits from FreeBSD. Specifically, the use of getline() and multibyte support for the -d option. I also made the functions non-static (though I don't think that is such a big deal) and tweaked the manual to treat '-' like cat(1) as per j...@wxcvbn.org's comments. Updated diff. I removed the int width handling and modified the separator printing based on your comment. Index: Makefile === RCS file: /cvs/src/usr.bin/Makefile,v retrieving revision 1.129 diff -u -p -r1.129 Makefile --- Makefile15 Mar 2013 06:01:41 - 1.129 +++ Makefile20 May 2013 09:28:57 - @@ -16,7 +16,7 @@ SUBDIR= apply apropos ar arch asa asn1_c m4 mail make man mandoc mesg mg \ midiplay mixerctl mkdep mklocale mkstr mktemp modstat nc netstat \ newsyslog \ - nfsstat nice nm nohup oldrdist pagesize passwd paste patch pctr \ + nfsstat nice nm nl nohup oldrdist pagesize passwd paste patch pctr \ pkg-config pkill \ pr printenv printf quota radioctl ranlib rcs rdist rdistd \ readlink renice rev rpcgen rpcinfo rs rsh rup ruptime rusers rwall \ Index: nl/Makefile === RCS file: nl/Makefile diff -N nl/Makefile --- /dev/null 1 Jan 1970 00:00:00 - +++ nl/Makefile 20 May 2013 09:28:57 - @@ -0,0 +1,6 @@ +# $OpenBSD$ +# $NetBSD: Makefile,v 1.4 2011/08/16 12:00:46 christos Exp $ + +PROG= nl + +.include bsd.prog.mk Index: nl/nl.1 === RCS file: nl/nl.1 diff -N nl/nl.1 --- /dev/null 1 Jan 1970 00:00:00 - +++ nl/nl.1 20 May 2013 09:28:57 - @@ -0,0 +1,216 @@ +.\$OpenBSD$ +.\$NetBSD: nl.1,v 1.12 2012/04/08 22:00:39 wiz Exp $ +.\ +.\ Copyright (c) 1999 The NetBSD Foundation, Inc. +.\ All rights reserved. +.\ +.\ This code is derived from software contributed to The NetBSD Foundation +.\ by Klaus Klein. +.\ +.\ Redistribution and use in source and binary forms, with or without +.\ modification, are permitted provided that the following conditions +.\ are met: +.\ 1. Redistributions of source code must retain the above copyright +.\notice, this list of conditions and the following disclaimer. +.\ 2. Redistributions in binary form must reproduce the above copyright +.\notice, this list of conditions and the following disclaimer in the +.\documentation and/or other materials provided with the distribution. +.\ +.\ THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS +.\ ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED +.\ TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +.\ PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS +.\ BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +.\ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +.\ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +.\ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN +.\ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) +.\ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +.\ POSSIBILITY OF SUCH DAMAGE. +.\ +.Dd $Mdocdate$ +.Dt NL 1 +.Os +.Sh NAME +.Nm nl +.Nd line numbering filter +.Sh SYNOPSIS +.Nm +.Op Fl p +.Op Fl b Ar type +.Op Fl d Ar delim +.Op Fl f Ar type +.Op Fl h Ar type +.Op Fl i Ar incr +.Op Fl l Ar num +.Op Fl n Ar format +.Op Fl s Ar sep +.Op Fl v Ar startnum +.Op Fl w Ar width +.Op Ar file +.Sh DESCRIPTION +The +.Nm +utility reads lines from the named +.Ar file , +applies a configurable line numbering filter operation and writes the result +to the standard output. +If +.Ar file +is a single dash +.Pq Sq \- +or absent, +.Nm +reads from the standard input. +.Pp +The +.Nm +utility treats the text it reads in terms of logical pages. +Unless specified otherwise, line numbering is reset at the start of each +logical page. +A logical page consists of a header, a body and a footer section; empty +sections are valid. +Different line numbering options are independently available for header, +body and footer sections. +.Pp +The starts of logical page sections are signaled by input lines containing +nothing but one of the following sequences of delimiter characters: +.Bd -unfilled -offset indent +.Bl -column \e:\e:\e: header +.It Em Line Start of +.It \e:\e:\e: header +.It \e:\e: body +.It \e:footer +.El +.Ed +.Pp +If the input does not contain any logical page section signaling directives, +the text being read is assumed to consist of a single logical page body. +.Pp +The following options are available: +.Bl -tag -width indent +.It Fl b Ar type +Specify the logical page body lines to be numbered. +Recognized +.Ar
Re: add nl(1)
On Mon, 20 May 2013 12:43:19 +0300, Arto Jonsson wrote: Updated diff. I removed the int width handling and modified the separator printing based on your comment. That looks good to me. - todd
Somewhat important ACPI diff
As diagnosed by some other people (armani@, jcs@?) a while ago, our
code to deal with IndexField() operators in our AML interpreter is
quite broken. It works for fields that are less than a byte in size,
but anything else is pretty much completely busted. I wouldn't be
surprised if this is the cause of many ACPI-related problems. One
that comes to mind are the ridiculous temperatures reported by
acpitz(4) that have been plaguing us since basically forever.
I don't have a lot of machines that have AML with IndexField()
operators. I've verified that those return the correct values, but
this defenitely could use further testing on a wide variety of
i386/amd64 hardware please.
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.200
diff -u -p -r1.200 dsdt.c
--- dsdt.c 10 Apr 2013 01:35:55 - 1.200
+++ dsdt.c 20 May 2013 16:55:27 -
@@ -2221,8 +2221,9 @@ aml_evalhid(struct aml_node *node, struc
return (0);
}
-void aml_rwfield(struct aml_value *, int, int, struct aml_value *, int);
void aml_rwgas(struct aml_value *, int, int, struct aml_value *, int, int);
+void aml_rwindexfield(struct aml_value *, struct aml_value *val, int);
+void aml_rwfield(struct aml_value *, int, int, struct aml_value *, int);
/* Get PCI address for opregion objects */
int
@@ -2341,6 +2342,81 @@ aml_rwgas(struct aml_value *rgn, int bpo
aml_freevalue(tmp);
}
+
+void
+aml_rwindexfield(struct aml_value *fld, struct aml_value *val, int mode)
+{
+ struct aml_value tmp, *ref1, *ref2;
+ void *tbit, *vbit;
+ int vpos, bpos, blen;
+ int indexval;
+ int sz, len;
+
+ ref2 = fld-v_field.ref2;
+ ref1 = fld-v_field.ref1;
+ bpos = fld-v_field.bitpos;
+ blen = fld-v_field.bitlen;
+
+ memset(tmp, 0, sizeof(tmp));
+ tmp.refcnt = 99;
+
+ /* Get field access size */
+ switch (AML_FIELD_ACCESS(fld-v_field.flags)) {
+ case AML_FIELD_WORDACC:
+ sz = 2;
+ break;
+ case AML_FIELD_DWORDACC:
+ sz = 4;
+ break;
+ case AML_FIELD_QWORDACC:
+ sz = 8;
+ break;
+ default:
+ sz = 1;
+ break;
+ }
+
+ if (blen aml_intlen) {
+ if (mode == ACPI_IOREAD) {
+ /* Read from a large field: create buffer */
+ _aml_setvalue(val, AML_OBJTYPE_BUFFER,
+ (blen + 7) 3, 0);
+ }
+ vbit = val-v_buffer;
+ } else {
+ if (mode == ACPI_IOREAD) {
+ /* Read from a short field: initialize integer */
+ _aml_setvalue(val, AML_OBJTYPE_INTEGER, 0, 0);
+ }
+ vbit = val-v_integer;
+ }
+ tbit = tmp.v_integer;
+ vpos = 0;
+
+ indexval = (bpos 3) ~(sz - 1);
+ bpos = bpos - (indexval 3);
+
+ while (blen 0) {
+ len = min(blen, (sz 3) - bpos);
+
+ /* Write index register */
+ _aml_setvalue(tmp, AML_OBJTYPE_INTEGER, indexval, 0);
+ aml_rwfield(ref2, 0, aml_intlen, tmp, ACPI_IOWRITE);
+ indexval += sz;
+
+ /* Read/write data register */
+ _aml_setvalue(tmp, AML_OBJTYPE_INTEGER, 0, 0);
+ if (mode == ACPI_IOWRITE)
+ aml_bufcpy(tbit, 0, vbit, vpos, len);
+ aml_rwfield(ref1, bpos, len, tmp, mode);
+ if (mode == ACPI_IOREAD)
+ aml_bufcpy(vbit, vpos, tbit, 0, len);
+ vpos += len;
+ blen -= len;
+ bpos = 0;
+ }
+}
+
void
aml_rwfield(struct aml_value *fld, int bpos, int blen, struct aml_value *val,
int mode)
@@ -2356,10 +2432,7 @@ aml_rwfield(struct aml_value *fld, int b
memset(tmp, 0, sizeof(tmp));
aml_addref(tmp, fld.write);
if (fld-v_field.type == AMLOP_INDEXFIELD) {
- _aml_setvalue(tmp, AML_OBJTYPE_INTEGER, fld-v_field.ref3, 0);
- aml_rwfield(ref2, 0, aml_intlen, tmp, ACPI_IOWRITE);
- aml_rwfield(ref1, fld-v_field.bitpos, fld-v_field.bitlen,
- val, mode);
+ aml_rwindexfield(fld, val, mode);
} else if (fld-v_field.type == AMLOP_BANKFIELD) {
_aml_setvalue(tmp, AML_OBJTYPE_INTEGER, fld-v_field.ref3, 0);
aml_rwfield(ref2, 0, aml_intlen, tmp, ACPI_IOWRITE);
@@ -2414,10 +2487,6 @@ aml_createfield(struct aml_value *field,
opcode == AMLOP_BANKFIELD) ?
AML_OBJTYPE_FIELDUNIT :
AML_OBJTYPE_BUFFERFIELD;
- if (opcode == AMLOP_INDEXFIELD) {
- indexval = bpos 3;
- bpos = 7;
- }
if (field-type == AML_OBJTYPE_BUFFERFIELD
data-type != AML_OBJTYPE_BUFFER)
Re: iked(8) and GCM
On Sat, May 18, 2013 at 04:30:43AM +0200, Reyk Floeter wrote: You're mixing up GCM and GMAC. You have to update your config to use aes-256-gcm instead of aes-256-gmac! The GMAC is actually only the authentication part and it is not encrypting the payload. You can see it as childsa enc null auth aes-256-gmac, but it is technically the encryption part that is calculating the GMAC. I see. Seems somewhat contradictory to the fact that ESP is supposed to provide confidentiality other than authenticity and integrity. But I have to admit that the iked.conf(5) manpage is not describing it and is just listing the aes-???-gmac as encryption ciphers, so it is also our fault. I even see the point that a cipher AES-something is misleading in a way that most people will asume that it is encrypting the payload. We will think about a way to improve this. Thanks.
Re: UPDATE: xf86-input-synaptics 1.7.0
On Thu, May 02, 2013 at 10:11:23PM +0600, Alexandr Shadchin wrote: Hi, This update xf86-input-synaptics to the latest release 1.7.0. http://koba.devio.us/distfiles/xf86-input-synaptics-1.7.0.diff Tested on amd64 and i386. Comments ? OK ? -- Alexandr Shadchin Prepare diff for xf86-input-synaptics 1.7.1 http://koba.devio.us/distfiles/xf86-input-synaptics-1.7.1.diff -- Alexandr Shadchin
Re: Somewhat important ACPI diff
Mark Kettenis mark.kette...@xs4all.nl writes:
As diagnosed by some other people (armani@, jcs@?) a while ago, our
code to deal with IndexField() operators in our AML interpreter is
quite broken. It works for fields that are less than a byte in size,
but anything else is pretty much completely busted. I wouldn't be
surprised if this is the cause of many ACPI-related problems. One
that comes to mind are the ridiculous temperatures reported by
acpitz(4) that have been plaguing us since basically forever.
I don't have a lot of machines that have AML with IndexField()
operators. I've verified that those return the correct values, but
this defenitely could use further testing on a wide variety of
i386/amd64 hardware please.
Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.200
diff -u -p -r1.200 dsdt.c
--- dsdt.c10 Apr 2013 01:35:55 - 1.200
+++ dsdt.c20 May 2013 16:55:27 -
@@ -2221,8 +2221,9 @@ aml_evalhid(struct aml_node *node, struc
return (0);
}
-void aml_rwfield(struct aml_value *, int, int, struct aml_value *, int);
void aml_rwgas(struct aml_value *, int, int, struct aml_value *, int, int);
+void aml_rwindexfield(struct aml_value *, struct aml_value *val, int);
+void aml_rwfield(struct aml_value *, int, int, struct aml_value *, int);
/* Get PCI address for opregion objects */
int
@@ -2341,6 +2342,81 @@ aml_rwgas(struct aml_value *rgn, int bpo
aml_freevalue(tmp);
}
+
+void
+aml_rwindexfield(struct aml_value *fld, struct aml_value *val, int mode)
+{
+ struct aml_value tmp, *ref1, *ref2;
+ void *tbit, *vbit;
+ int vpos, bpos, blen;
+ int indexval;
+ int sz, len;
+
+ ref2 = fld-v_field.ref2;
+ ref1 = fld-v_field.ref1;
+ bpos = fld-v_field.bitpos;
+ blen = fld-v_field.bitlen;
+
+ memset(tmp, 0, sizeof(tmp));
+ tmp.refcnt = 99;
+
+ /* Get field access size */
+ switch (AML_FIELD_ACCESS(fld-v_field.flags)) {
+ case AML_FIELD_WORDACC:
+ sz = 2;
+ break;
+ case AML_FIELD_DWORDACC:
+ sz = 4;
+ break;
+ case AML_FIELD_QWORDACC:
+ sz = 8;
+ break;
+ default:
+ sz = 1;
+ break;
+ }
+
+ if (blen aml_intlen) {
+ if (mode == ACPI_IOREAD) {
+ /* Read from a large field: create buffer */
+ _aml_setvalue(val, AML_OBJTYPE_BUFFER,
+ (blen + 7) 3, 0);
+ }
+ vbit = val-v_buffer;
+ } else {
+ if (mode == ACPI_IOREAD) {
+ /* Read from a short field: initialize integer */
+ _aml_setvalue(val, AML_OBJTYPE_INTEGER, 0, 0);
+ }
+ vbit = val-v_integer;
+ }
+ tbit = tmp.v_integer;
+ vpos = 0;
+
+ indexval = (bpos 3) ~(sz - 1);
+ bpos = bpos - (indexval 3);
+
+ while (blen 0) {
+ len = min(blen, (sz 3) - bpos);
+
+ /* Write index register */
+ _aml_setvalue(tmp, AML_OBJTYPE_INTEGER, indexval, 0);
+ aml_rwfield(ref2, 0, aml_intlen, tmp, ACPI_IOWRITE);
+ indexval += sz;
+
+ /* Read/write data register */
+ _aml_setvalue(tmp, AML_OBJTYPE_INTEGER, 0, 0);
+ if (mode == ACPI_IOWRITE)
+ aml_bufcpy(tbit, 0, vbit, vpos, len);
+ aml_rwfield(ref1, bpos, len, tmp, mode);
+ if (mode == ACPI_IOREAD)
+ aml_bufcpy(vbit, vpos, tbit, 0, len);
+ vpos += len;
+ blen -= len;
+ bpos = 0;
+ }
+}
+
void
aml_rwfield(struct aml_value *fld, int bpos, int blen, struct aml_value *val,
int mode)
@@ -2356,10 +2432,7 @@ aml_rwfield(struct aml_value *fld, int b
memset(tmp, 0, sizeof(tmp));
aml_addref(tmp, fld.write);
if (fld-v_field.type == AMLOP_INDEXFIELD) {
- _aml_setvalue(tmp, AML_OBJTYPE_INTEGER, fld-v_field.ref3, 0);
- aml_rwfield(ref2, 0, aml_intlen, tmp, ACPI_IOWRITE);
- aml_rwfield(ref1, fld-v_field.bitpos, fld-v_field.bitlen,
- val, mode);
+ aml_rwindexfield(fld, val, mode);
} else if (fld-v_field.type == AMLOP_BANKFIELD) {
_aml_setvalue(tmp, AML_OBJTYPE_INTEGER, fld-v_field.ref3, 0);
aml_rwfield(ref2, 0, aml_intlen, tmp, ACPI_IOWRITE);
@@ -2414,10 +2487,6 @@ aml_createfield(struct aml_value *field,
opcode == AMLOP_BANKFIELD) ?
AML_OBJTYPE_FIELDUNIT :
AML_OBJTYPE_BUFFERFIELD;
- if (opcode == AMLOP_INDEXFIELD) {
- indexval = bpos 3;
- bpos = 7;
- }
if (field-type == AML_OBJTYPE_BUFFERFIELD
data-type !=
Re: iked(8) and GCM
On 2013/05/20 10:56, Aaron Stellman wrote: On Sat, May 18, 2013 at 04:30:43AM +0200, Reyk Floeter wrote: You're mixing up GCM and GMAC. You have to update your config to use aes-256-gcm instead of aes-256-gmac! The GMAC is actually only the authentication part and it is not encrypting the payload. You can see it as childsa enc null auth aes-256-gmac, but it is technically the encryption part that is calculating the GMAC. I see. Seems somewhat contradictory to the fact that ESP is supposed to provide confidentiality other than authenticity and integrity. But I have to admit that the iked.conf(5) manpage is not describing it and is just listing the aes-???-gmac as encryption ciphers, so it is also our fault. I even see the point that a cipher AES-something is misleading in a way that most people will asume that it is encrypting the payload. We will think about a way to improve this. Thanks. If you make it a couple of paragraphs past the table, there is this paragraph, which is rather clear: Using AES-GMAC or NULL with ESP will only provide authentication. This is useful in setups where AH can not be used, e.g. when NAT is involved. Maybe a bit of redundancy would help, as this is a fairly important point, perhaps if the table were split up: Index: iked.conf.5 === RCS file: /cvs/src/sbin/iked/iked.conf.5,v retrieving revision 1.23 diff -u -p -r1.23 iked.conf.5 --- iked.conf.5 5 Mar 2013 19:16:01 - 1.23 +++ iked.conf.5 20 May 2013 19:22:45 - @@ -720,11 +720,16 @@ keyword: .It Li aes-128-gcm Ta 160 bits Ta [ESP only] .It Li aes-192-gcm Ta 224 bits Ta [ESP only] .It Li aes-256-gcm Ta 288 bits Ta [ESP only] +.It Li blowfish Ta 160 bits Ta [ESP only] +.It Li cast Ta 128 bits Ta [ESP only] +.El +.Pp +The following cipher types provide only authentication, +not encryption: +.Bl -column aes-128-gmac Key Length [ESP only] -offset indent .It Li aes-128-gmac Ta 160 bits Ta [ESP only] .It Li aes-192-gmac Ta 224 bits Ta [ESP only] .It Li aes-256-gmac Ta 288 bits Ta [ESP only] -.It Li blowfish Ta 160 bits Ta [ESP only] -.It Li cast Ta 128 bits Ta [ESP only] .It Li null Ta Ta [ESP only] .El .Pp
amd64errata.c,v 1.4
For our crash, v 1.4 of amd64errata.c is no-op unless we de-static
functions' prototypes.
acpiprt0 at acpi0: bus 0 (PCI0)
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Phenom(tm) 9550 Quad-Core Processor, 3600.54 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,
MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCHT,HXE,MMXX,FFXSR,LOHG,3DNOW2,3DNOW,LAHF,CM
PLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 1
6-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
kernel: protection fault trap, code=0
Stopped at amd64_errata_setmsr()+0x10: rdmsr
amd64_errata_setmsr() at amd64_errata_setmsr()+0x10
amd64_errata() at amd64 errata+0xc9
identifycpu() at identifycpu+0x729
cpu attach() at cpu_attach+0x2ce
config_attach() at config_attach+0x1d4
mpbios_cpu() at mpbios_cpu+0x5b
mpbios_scan() at mpbios_scan+0x355
config_attach() at config_attach+0x1d4
bios_attach() at bios_attach+0x296
config_attach() at config_attach+0x1d4
end trace frame: 0x81de9e30, count: 0
ddb{0}
ddb{0} trace
amd64_errata_setmsr() at amd64_errata_setmsr()+0x10
amd64_errata() at amd64_errata+0xc9
identifycpu() at identifycpu+0x729
cpu_attach() at cpu_attach+0x2ce
config_attach() at config_attach+0x1d4
mpbios_cpu() at mpbios_cpu+0x5b
mpbios_scan() at mpbios_scan+0x355
config_attach() at config_attach+0x1d4
bios_attach() at bios_attach+0x296
config_attach() at config_attach+0x1d4
mainbus_attach() at mainbus_attach+0x5b
config_attach() at config_attach+0x1d4
cpu_configure() at cpu_configure+0x17
main() at main+0x3f5
end trace frame: 0x0, count: -14
ddb{0}
Index: arch/amd64/amd64/amd64errata.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/amd64errata.c,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 amd64errata.c
--- arch/amd64/amd64/amd64errata.c 20 May 2013 17:34:08 - 1.4
+++ arch/amd64/amd64/amd64errata.c 20 May 2013 20:17:00 -
@@ -129,8 +129,8 @@ static const uint8_t amd64_errata_set9[]
DA_C3, HY_D0, HY_D1, HY_D1_G34R1, PH_E0, LN_B0, OINK
};
-static int amd64_errata_setmsr(struct cpu_info *, errata_t *);
-static int amd64_errata_testmsr(struct cpu_info *, errata_t *);
+int amd64_errata_setmsr(struct cpu_info *, errata_t *);
+int amd64_errata_testmsr(struct cpu_info *, errata_t *);
static errata_t errata[] = {
/*
Index: arch/i386/i386/amd64errata.c
===
RCS file: /cvs/src/sys/arch/i386/i386/amd64errata.c,v
retrieving revision 1.4
diff -u -p -u -p -r1.4 amd64errata.c
--- arch/i386/i386/amd64errata.c20 May 2013 17:34:08 - 1.4
+++ arch/i386/i386/amd64errata.c20 May 2013 20:17:01 -
@@ -129,8 +129,8 @@ static const uint8_t amd64_errata_set9[]
DA_C3, HY_D0, HY_D1, HY_D1_G34R1, PH_E0, LN_B0, OINK
};
-static int amd64_errata_setmsr(struct cpu_info *, errata_t *);
-static int amd64_errata_testmsr(struct cpu_info *, errata_t *);
+int amd64_errata_setmsr(struct cpu_info *, errata_t *);
+int amd64_errata_testmsr(struct cpu_info *, errata_t *);
static errata_t errata[] = {
/*
Re: Somewhat important ACPI diff
On Mon, May 20, 2013 at 06:57:56PM +0200, Mark Kettenis wrote:
As diagnosed by some other people (armani@, jcs@?) a while ago, our
code to deal with IndexField() operators in our AML interpreter is
quite broken. It works for fields that are less than a byte in size,
but anything else is pretty much completely busted. I wouldn't be
surprised if this is the cause of many ACPI-related problems. One
that comes to mind are the ridiculous temperatures reported by
acpitz(4) that have been plaguing us since basically forever.
I don't have a lot of machines that have AML with IndexField()
operators. I've verified that those return the correct values, but
this defenitely could use further testing on a wide variety of
i386/amd64 hardware please.
No regressions on Dell XPS 13 (L321X). hw.sensors.acpitz0.temp0 and
hw.sensors.acpitz1.temp0 still go from a normal reading (64 degC) to a
somewhat strange reading (27.80 degC) after suspend/resume. A reboot is
needed to get the normal temperature reading back.
hw.sensors.cpu{0-3}.temp0 continue to output correct readings post
suspend/resume.
--
James Turner
Re: Somewhat important ACPI diff
On Mon, May 20, 2013 at 06:57:56PM +0200, Mark Kettenis wrote: As diagnosed by some other people (armani@, jcs@?) a while ago, our code to deal with IndexField() operators in our AML interpreter is quite broken. It works for fields that are less than a byte in size, but anything else is pretty much completely busted. I wouldn't be surprised if this is the cause of many ACPI-related problems. One that comes to mind are the ridiculous temperatures reported by acpitz(4) that have been plaguing us since basically forever. I don't have a lot of machines that have AML with IndexField() operators. I've verified that those return the correct values, but this defenitely could use further testing on a wide variety of i386/amd64 hardware please. 6 amd64 boxes checked. 3 laptops, 3 non-laptops. intel procs (core and atom) amd procs. Various vintages, nothing more recent than 12 months or so. No regressions seen. Ken
Re: Somewhat important ACPI diff
On Mon, May 20, 2013 at 06:57:56PM +0200, Mark Kettenis wrote: As diagnosed by some other people (armani@, jcs@?) a while ago, our code to deal with IndexField() operators in our AML interpreter is quite broken. It works for fields that are less than a byte in size, but anything else is pretty much completely busted. I wouldn't be surprised if this is the cause of many ACPI-related problems. One that comes to mind are the ridiculous temperatures reported by acpitz(4) that have been plaguing us since basically forever. I don't have a lot of machines that have AML with IndexField() operators. I've verified that those return the correct values, but this defenitely could use further testing on a wide variety of i386/amd64 hardware please. Asus UX31E ultrabook here. This patch fixes kernel panics on boot in acpivout (get_bcl()), panics on AC plug/unplug, and battery information is now present in sysctl hw. Suspend/resume also gets further but still panics. Thanks for the patch!
