Re: PATCH: ACPI_DEBUG - format fixes
On Sat, May 17, 2014 at 06:21:10PM +0200, Fabian Raetz wrote:
> Hi,
>
> the following diff fixes kernel builds with ACPI_DEBUG defined.
> Not sure if these are the right ones, but at least it
> compiles again.
>
> Cheers,
> Fabian
>
committed. thanks.
>
> Index: acpi.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.257
> diff -u -p -r1.257 acpi.c
> --- acpi.c25 Apr 2014 14:37:06 - 1.257
> +++ acpi.c16 May 2014 22:09:26 -
> @@ -435,7 +435,7 @@ acpi_matchhids(struct acpi_attach_args *
> if (aa->aaa_dev == NULL || aa->aaa_node == NULL)
> return (0);
> if (_acpi_matchhids(aa->aaa_dev, hids)) {
> - dnprintf(5, "driver %s matches %s\n", driver, hids);
> + dnprintf(5, "driver %s matches %s\n", driver, (char *)hids);
> return (1);
> }
> return (0);
> @@ -1336,7 +1336,7 @@ acpi_map_pmregs(struct acpi_softc *sc)
> break;
> }
> if (size && addr) {
> - dnprintf(50, "mapping: %.4x %.4x %s\n",
> + dnprintf(50, "mapping: %.4lx %.4lx %s\n",
> addr, size, name);
>
> /* Size and address exist; map register space */
> Index: acpicpu.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpicpu.c,v
> retrieving revision 1.57
> diff -u -p -r1.57 acpicpu.c
> --- acpicpu.c 21 Jul 2010 19:35:15 - 1.57
> +++ acpicpu.c 16 May 2014 22:09:26 -
> @@ -344,7 +344,7 @@ acpicpu_attach(struct device *parent, st
> #ifdef ACPI_DEBUG
> printf(": %s: ", sc->sc_devnode->name);
> printf("\n: hdr:%x pblk:%x,%x duty:%x,%x pstate:%x "
> -"(%d throttling states)\n", sc->sc_acpi->sc_fadt->hdr_revision,
> +"(%ld throttling states)\n", sc->sc_acpi->sc_fadt->hdr_revision,
> sc->sc_pblk_addr, sc->sc_pblk_len, sc->sc_duty_off,
> sc->sc_duty_wid, sc->sc_acpi->sc_fadt->pstate_cnt,
> CPU_MAXSTATE(sc));
> @@ -519,7 +519,7 @@ acpicpu_getpct(struct acpicpu_softc *sc)
> goto ffh;
> }
>
> - dnprintf(10, "_PCT(ctrl) : %02x %04x %02x %02x %02x %02x %016x\n",
> + dnprintf(10, "_PCT(ctrl) : %02x %04x %02x %02x %02x %02x %016llx\n",
> sc->sc_pct.pct_ctrl.grd_descriptor,
> sc->sc_pct.pct_ctrl.grd_length,
> sc->sc_pct.pct_ctrl.grd_gas.address_space_id,
> @@ -528,7 +528,7 @@ acpicpu_getpct(struct acpicpu_softc *sc)
> sc->sc_pct.pct_ctrl.grd_gas.access_size,
> sc->sc_pct.pct_ctrl.grd_gas.address);
>
> - dnprintf(10, "_PCT(status): %02x %04x %02x %02x %02x %02x %016x\n",
> + dnprintf(10, "_PCT(status): %02x %04x %02x %02x %02x %02x %016llx\n",
> sc->sc_pct.pct_status.grd_descriptor,
> sc->sc_pct.pct_status.grd_length,
> sc->sc_pct.pct_status.grd_gas.address_space_id,
> 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 16 May 2014 22:09:26 -
> @@ -142,9 +142,10 @@ acpiec_read_data(struct acpiec_softc *sc
> u_int8_tval;
>
> acpiec_wait(sc, EC_STAT_OBF, EC_STAT_OBF);
> - dnprintf(40, "acpiec: read_data\n", (int)val);
> val = bus_space_read_1(sc->sc_data_bt, sc->sc_data_bh, 0);
>
> + dnprintf(40, "acpiec: read_data %d\n", (int)val);
> +
> return (val);
> }
>
> @@ -482,7 +483,7 @@ acpiec_getcrs(struct acpiec_softc *sc, s
> /* XXX: todo - validate _CRS checksum? */
> ecdtdone:
>
> - dnprintf(10, "%s: Data: 0x%x, S/C: 0x%x\n",
> + dnprintf(10, "%s: Data: 0x%lx, S/C: 0x%lx\n",
> DEVNAME(sc), ec_data, ec_sc);
>
> if (ctype == GAS_SYSTEM_IOSPACE)
> Index: atk0110.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/atk0110.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 atk0110.c
> --- atk0110.c 21 Feb 2014 16:25:57 - 1.8
> +++ atk0110.c 16 May 2014 22:09:27 -
> @@ -448,13 +448,13 @@ aibs_getvalue(struct aibs_softc *sc, int
> }
>
> if (aml_evalnode(sc->sc_acpi, n, 1, &req, &res)) {
> - dprintf("%s: %s: %i: evaluation failed\n",
> + dprintf("%s: %s: %lld: evaluation failed\n",
> DEVNAME(sc), n->name, i);
> aml_freevalue(&res);
> return (-1);
> }
> if (res.type != type) {
> - dprintf("%s: %s: %i: not an integer: type %i\n",
> + dprintf("%s: %s: %lld: not an integer: type %i\n",
> DEVNAME(sc), n->name, i, res.type);
> aml_freevalue(&res);
> return (-1);
> @@ -462,14 +462,14 @
Re: PATCH: ACPI_DEBUG - format fixes
On Sat, May 17, 2014 at 06:21:10PM +0200, Fabian Raetz wrote:
> Hi,
>
> the following diff fixes kernel builds with ACPI_DEBUG defined.
> Not sure if these are the right ones, but at least it
> compiles again.
>
> Cheers,
> Fabian
>
ok mlarkin@
>
> Index: acpi.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> retrieving revision 1.257
> diff -u -p -r1.257 acpi.c
> --- acpi.c25 Apr 2014 14:37:06 - 1.257
> +++ acpi.c16 May 2014 22:09:26 -
> @@ -435,7 +435,7 @@ acpi_matchhids(struct acpi_attach_args *
> if (aa->aaa_dev == NULL || aa->aaa_node == NULL)
> return (0);
> if (_acpi_matchhids(aa->aaa_dev, hids)) {
> - dnprintf(5, "driver %s matches %s\n", driver, hids);
> + dnprintf(5, "driver %s matches %s\n", driver, (char *)hids);
> return (1);
> }
> return (0);
> @@ -1336,7 +1336,7 @@ acpi_map_pmregs(struct acpi_softc *sc)
> break;
> }
> if (size && addr) {
> - dnprintf(50, "mapping: %.4x %.4x %s\n",
> + dnprintf(50, "mapping: %.4lx %.4lx %s\n",
> addr, size, name);
>
> /* Size and address exist; map register space */
> Index: acpicpu.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpicpu.c,v
> retrieving revision 1.57
> diff -u -p -r1.57 acpicpu.c
> --- acpicpu.c 21 Jul 2010 19:35:15 - 1.57
> +++ acpicpu.c 16 May 2014 22:09:26 -
> @@ -344,7 +344,7 @@ acpicpu_attach(struct device *parent, st
> #ifdef ACPI_DEBUG
> printf(": %s: ", sc->sc_devnode->name);
> printf("\n: hdr:%x pblk:%x,%x duty:%x,%x pstate:%x "
> -"(%d throttling states)\n", sc->sc_acpi->sc_fadt->hdr_revision,
> +"(%ld throttling states)\n", sc->sc_acpi->sc_fadt->hdr_revision,
> sc->sc_pblk_addr, sc->sc_pblk_len, sc->sc_duty_off,
> sc->sc_duty_wid, sc->sc_acpi->sc_fadt->pstate_cnt,
> CPU_MAXSTATE(sc));
> @@ -519,7 +519,7 @@ acpicpu_getpct(struct acpicpu_softc *sc)
> goto ffh;
> }
>
> - dnprintf(10, "_PCT(ctrl) : %02x %04x %02x %02x %02x %02x %016x\n",
> + dnprintf(10, "_PCT(ctrl) : %02x %04x %02x %02x %02x %02x %016llx\n",
> sc->sc_pct.pct_ctrl.grd_descriptor,
> sc->sc_pct.pct_ctrl.grd_length,
> sc->sc_pct.pct_ctrl.grd_gas.address_space_id,
> @@ -528,7 +528,7 @@ acpicpu_getpct(struct acpicpu_softc *sc)
> sc->sc_pct.pct_ctrl.grd_gas.access_size,
> sc->sc_pct.pct_ctrl.grd_gas.address);
>
> - dnprintf(10, "_PCT(status): %02x %04x %02x %02x %02x %02x %016x\n",
> + dnprintf(10, "_PCT(status): %02x %04x %02x %02x %02x %02x %016llx\n",
> sc->sc_pct.pct_status.grd_descriptor,
> sc->sc_pct.pct_status.grd_length,
> sc->sc_pct.pct_status.grd_gas.address_space_id,
> 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 16 May 2014 22:09:26 -
> @@ -142,9 +142,10 @@ acpiec_read_data(struct acpiec_softc *sc
> u_int8_tval;
>
> acpiec_wait(sc, EC_STAT_OBF, EC_STAT_OBF);
> - dnprintf(40, "acpiec: read_data\n", (int)val);
> val = bus_space_read_1(sc->sc_data_bt, sc->sc_data_bh, 0);
>
> + dnprintf(40, "acpiec: read_data %d\n", (int)val);
> +
> return (val);
> }
>
> @@ -482,7 +483,7 @@ acpiec_getcrs(struct acpiec_softc *sc, s
> /* XXX: todo - validate _CRS checksum? */
> ecdtdone:
>
> - dnprintf(10, "%s: Data: 0x%x, S/C: 0x%x\n",
> + dnprintf(10, "%s: Data: 0x%lx, S/C: 0x%lx\n",
> DEVNAME(sc), ec_data, ec_sc);
>
> if (ctype == GAS_SYSTEM_IOSPACE)
> Index: atk0110.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/atk0110.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 atk0110.c
> --- atk0110.c 21 Feb 2014 16:25:57 - 1.8
> +++ atk0110.c 16 May 2014 22:09:27 -
> @@ -448,13 +448,13 @@ aibs_getvalue(struct aibs_softc *sc, int
> }
>
> if (aml_evalnode(sc->sc_acpi, n, 1, &req, &res)) {
> - dprintf("%s: %s: %i: evaluation failed\n",
> + dprintf("%s: %s: %lld: evaluation failed\n",
> DEVNAME(sc), n->name, i);
> aml_freevalue(&res);
> return (-1);
> }
> if (res.type != type) {
> - dprintf("%s: %s: %i: not an integer: type %i\n",
> + dprintf("%s: %s: %lld: not an integer: type %i\n",
> DEVNAME(sc), n->name, i, res.type);
> aml_freevalue(&res);
> return (-1);
> @@ -462,14 +462,14 @@ aibs_
[PATCH] libssl:Remove NULL checks before calling free()
Hello,
After reading
http://www.openbsd.org/papers/bsdcan14-libressl/mgp00015.html , I
thought I'd help a bit with cleaning libssl by running this
Coccinelle[1] script on src/lib/libssl:
@@
identifier x;
@@
-if (x) { free(x); }
+free(x);
It removes unnecessary NULL checks that happen before a call to free(),
and could probably also be run on some other parts of the OpenBSD code.
Could you keep me CCed, since I have not subscribed to this list ?
Cyril.
[1] http://coccinelle.lip6.fr/
diff -u -p a/src/crypto/stack/stack.c b/src/crypto/stack/stack.c
--- a/src/crypto/stack/stack.c
+++ b/src/crypto/stack/stack.c
@@ -141,8 +141,7 @@ sk_new(int (*c)(const void *, const void
return (ret);
err:
- if (ret)
- free(ret);
+ free(ret);
return (NULL);
}
diff -u -p a/src/crypto/x509v3/v3_conf.c b/src/crypto/x509v3/v3_conf.c
--- a/src/crypto/x509v3/v3_conf.c
+++ b/src/crypto/x509v3/v3_conf.c
@@ -313,8 +313,7 @@ v3_generic_extension(const char *ext, ch
err:
ASN1_OBJECT_free(obj);
M_ASN1_OCTET_STRING_free(oct);
- if (ext_der)
- free(ext_der);
+ free(ext_der);
return extension;
}
diff -u -p a/src/crypto/x509v3/v3_utl.c b/src/crypto/x509v3/v3_utl.c
--- a/src/crypto/x509v3/v3_utl.c
+++ b/src/crypto/x509v3/v3_utl.c
@@ -422,7 +422,7 @@ unsigned char *string_to_hex(const char
return hexbuf;
err:
- if(hexbuf) free(hexbuf);
+ free(hexbuf);
X509V3err(X509V3_F_STRING_TO_HEX,ERR_R_MALLOC_FAILURE);
return NULL;
@@ -623,8 +623,7 @@ ASN1_OCTET_STRING *a2i_IPADDRESS_NC(cons
return ret;
err:
- if (iptmp)
- free(iptmp);
+ free(iptmp);
if (ret)
ASN1_OCTET_STRING_free(ret);
return NULL;
diff -u -p a/src/crypto/bn/bn_exp.c b/src/crypto/bn/bn_exp.c
--- a/src/crypto/bn/bn_exp.c
+++ b/src/crypto/bn/bn_exp.c
@@ -840,8 +840,7 @@ err:
BN_MONT_CTX_free(mont);
if (powerbuf != NULL) {
OPENSSL_cleanse(powerbuf, powerbufLen);
- if (powerbufFree)
- free(powerbufFree);
+ free(powerbufFree);
}
BN_CTX_end(ctx);
return (ret);
diff -u -p a/src/crypto/bn/bn_gf2m.c b/src/crypto/bn/bn_gf2m.c
--- a/src/crypto/bn/bn_gf2m.c
+++ b/src/crypto/bn/bn_gf2m.c
@@ -558,8 +558,7 @@ BN_GF2m_mod_mul(BIGNUM *r, const BIGNUM
bn_check_top(r);
err:
- if (arr)
- free(arr);
+ free(arr);
return ret;
}
@@ -621,8 +620,7 @@ BN_GF2m_mod_sqr(BIGNUM *r, const BIGNUM
bn_check_top(r);
err:
- if (arr)
- free(arr);
+ free(arr);
return ret;
}
@@ -1050,8 +1048,7 @@ BN_GF2m_mod_exp(BIGNUM *r, const BIGNUM
bn_check_top(r);
err:
- if (arr)
- free(arr);
+ free(arr);
return ret;
}
@@ -1113,8 +1110,7 @@ BN_GF2m_mod_sqrt(BIGNUM *r, const BIGNUM
bn_check_top(r);
err:
- if (arr)
- free(arr);
+ free(arr);
return ret;
}
@@ -1249,8 +1245,7 @@ BN_GF2m_mod_solve_quad(BIGNUM *r, const
bn_check_top(r);
err:
- if (arr)
- free(arr);
+ free(arr);
return ret;
}
diff -u -p a/src/crypto/ex_data.c b/src/crypto/ex_data.c
--- a/src/crypto/ex_data.c
+++ b/src/crypto/ex_data.c
@@ -444,8 +444,7 @@ skip:
storage[i]->argl, storage[i]->argp);
}
}
- if (storage)
- free(storage);
+ free(storage);
return 1;
}
@@ -489,8 +488,7 @@ skip:
storage[i]->argl, storage[i]->argp);
CRYPTO_set_ex_data(to, i, ptr);
}
- if (storage)
- free(storage);
+ free(storage);
return 1;
}
@@ -527,8 +525,7 @@ skip:
storage[i]->argl, storage[i]->argp);
}
}
- if (storage)
- free(storage);
+ free(storage);
if (ad->sk) {
sk_void_free(ad->sk);
ad->sk = NULL;
diff -u -p a/src/crypto/pem/pvkfmt.c b/src/crypto/pem/pvkfmt.c
--- a/src/crypto/pem/pvkfmt.c
+++ b/src/crypto/pem/pvkfmt.c
@@ -293,8 +293,7 @@ do_b2i_bio(BIO *in, int ispub)
ret = b2i_rsa(&p, length, bitlen, ispub);
err:
- if (buf)
- free(buf);
+ free(buf);
return ret;
}
diff -u -p a/src/crypto/pkcs7/pk7_doit.c b/src/crypto/pkcs7/pk7_doit.c
--- a/src/crypto/pkcs7/pk7_doit.c
+++ b/src/crypto/pkcs7/pk7_doit.c
@@ -190,8 +190,7 @@ static int pkcs7_encode_rinfo(PKCS7_RECI
EVP_PKEY_free(pkey);
if (pctx)
EVP_PKEY_CTX_free(pctx);
- if (ek)
- free(ek);
+ free(ek);
return ret;
}
diff -u -p a/src/crypto/asn1/bio_ndef.c b/src/crypto/asn1/bio_ndef.c
--- a/src/crypto/asn1/bio_ndef.c
+++ b/src/crypto/asn1/bio_ndef.c
@@ -146,8 +146,7 @@ BIO_new_NDEF(BIO *out, ASN1_VALUE *val,
err:
if (asn_bio)
BIO_free(asn_bio);
- if (ndef_aux)
- free(ndef_aux);
+ free(ndef_aux);
return NULL;
}
diff -u -p a/src/crypto/asn1/asn1_gen.c b/src/crypto/asn1/asn1_gen.c
--- a/src/crypto/asn1/asn1_gen.c
+++ b/src/crypto/asn1/asn1_gen.c
@@ -258,10 +258,8 @@ ASN1_generate_v3(char *str, X509V3_CTX *
ret = d2i_ASN1_TYPE(NULL, &cp, len);
err:
- if (orig_der)
- free(orig_der);
- if (new_der)
- free(new_der);
+ free(orig_der);
+ free(new_der);
return ret;
}
diff -u -p a/src/crypto/aes/aes_wrap.c b/src/crypto/aes/aes_wrap.c
--- a/src/crypto/aes/aes_wrap.c
+++ b/src/crypto/aes/aes_wrap.c
@@ -164,10 +164,8 @@ AES_wrap_unwrap_test(const unsigned char
ret = 1;
err:
- if (otmp)
- free(otmp);
- if (ptmp)
- free(ptmp);
+
Re: rsh vs net/ipcad - problems on 5.5
On 2014/05/20 12:36, Philip Guenther wrote: > On Tue, May 20, 2014 at 8:29 AM, Stuart Henderson wrote: > > > On 2014/05/20 16:41, viq wrote: > > > I encountered a strange problem when trying to communicate with > > net/ipcad: > > > > > > rsh localhost stats > > > rsh: poll: Undefined error: 0 > > > ... > > > Note that ipcad listens on port 514 and provides *its own* cisco-ish > > rshell interface that you connect to, this isn't about openbsd rshd. > > > > The error is coming from /usr/src/usr.bin/rsh/rsh.c:243 and since > > nothing changed here in many years, I'm wondering if there's anything > > up with poll(2). (If it's a direct bug with rsh, well, that's "fixed" > > a different way in -current).. > > > ... > > > 241 if ((pfd[0].revents & (POLLERR|POLLHUP|POLLNVAL)) || > > 242 (pfd[1].revents & (POLLERR|POLLHUP|POLLNVAL))) > > >> 243 err(1, "poll"); > > > > It's reporting that the second fd, the stderr fd, has been closed by the > other side (POLLHUP). Does ipcad implement the expected ordering in the > rsh protocol? > > > Philip Guenther Thanks for the cluebat / lesson in rsh :) Seems it's actually racey, sometimes closing the stderr first, sometimes closing port 514 first. So no it doesn't ... And rshd works fine, reinforcing this i.e. seems like an ipcad bug. Still it seems odd that it stopped working in 5.5 (though not enough for me to spend longer looking!). rsh ipcad 54 55 ok 55 54 ok 55 55 fail Anyway Viq, since rsh has gone away in -current, I suggest looking for an alternative; there are various things which might be suitable depending on what you're actually using it for .. Now to remove my test rshd configs before I forget :-)
Re: rsh vs net/ipcad - problems on 5.5
On Tue, May 20, 2014 at 8:29 AM, Stuart Henderson wrote: > On 2014/05/20 16:41, viq wrote: > > I encountered a strange problem when trying to communicate with > net/ipcad: > > > > rsh localhost stats > > rsh: poll: Undefined error: 0 > ... > Note that ipcad listens on port 514 and provides *its own* cisco-ish > rshell interface that you connect to, this isn't about openbsd rshd. > > The error is coming from /usr/src/usr.bin/rsh/rsh.c:243 and since > nothing changed here in many years, I'm wondering if there's anything > up with poll(2). (If it's a direct bug with rsh, well, that's "fixed" > a different way in -current).. > ... > 241 if ((pfd[0].revents & (POLLERR|POLLHUP|POLLNVAL)) || > 242 (pfd[1].revents & (POLLERR|POLLHUP|POLLNVAL))) > >> 243 err(1, "poll"); > It's reporting that the second fd, the stderr fd, has been closed by the other side (POLLHUP). Does ipcad implement the expected ordering in the rsh protocol? Philip Guenther
Re: rsh vs net/ipcad - problems on 5.5
On 2014/05/20 16:41, viq wrote:
> I encountered a strange problem when trying to communicate with net/ipcad:
>
> rsh localhost stats
> rsh: poll: Undefined error: 0
>
> Same thing on 5.1:
> rsh localhost stats
> connect to address ::1: Connection refused
> Trying 127.0.0.1...
> Interface vlan123: received 585816944, 5 m average 313 bytes/sec, 4
> pkts/sec, dropped 6078
> Flow entries made: 583
> Memory usage: 6% (65296 from 1048576)
> Free slots for rsh clients: 9
> IPCAD uptime is 159 days 7:04
> fw.example.com uptime is 159 days 7:04
>
> According to sthen@ this also works fine on 5.4 and he suspects
> breakage due to time_t changes. He also provided simple sample config
> http://pbot.rmdir.de/iFGRSOehzxnZ1flTJqum5Q because he's awesome like
> that ;)
>
> kern.version=OpenBSD 5.5 (GENERIC.MP) #0: Fri Apr 25 13:03:34 CEST 2014
>
> r...@stable-55-amd64.mtier.org:/binpatchng/work-binpatch55-amd64/src/sys/arch/amd64/compile/GENERIC.MP
> ipcad-3.7.3p1
> --
> viq
>
Note that ipcad listens on port 514 and provides *its own* cisco-ish
rshell interface that you connect to, this isn't about openbsd rshd.
Sample config inline at the bottom of this mail. (the pastebin above
was just meant for when I was talking about this on irc - it will expire).
The error is coming from /usr/src/usr.bin/rsh/rsh.c:243 and since
nothing changed here in many years, I'm wondering if there's anything
up with poll(2). (If it's a direct bug with rsh, well, that's "fixed"
a different way in -current)..
230 sigprocmask(SIG_SETMASK, omask, NULL);
231 pfd[1].fd = rfd2;
232 pfd[1].events = POLLIN;
233 pfd[0].fd = rem;
234 pfd[0].events = POLLIN;
235 do {
236 if (poll(pfd, 2, INFTIM) < 0) {
237 if (errno != EINTR)
238 err(1, "poll");
239 continue;
240 }
241 if ((pfd[0].revents & (POLLERR|POLLHUP|POLLNVAL)) ||
242 (pfd[1].revents & (POLLERR|POLLHUP|POLLNVAL)))
>> 243 err(1, "poll");
244 if (pfd[1].revents & POLLIN) {
245 errno = 0;
246 cc = read(rfd2, buf, sizeof buf);
247 if (cc <= 0) {
248 if (errno != EWOULDBLOCK)
249 pfd[1].revents = 0;
250 } else
251 (void)write(STDERR_FILENO, buf, cc);
252 }
253 if (pfd[0].revents & POLLIN) {
254 errno = 0;
255 cc = read(rem, buf, sizeof buf);
256 if (cc <= 0) {
257 if (errno != EWOULDBLOCK)
258 pfd[0].revents = 0;
259 } else
260 (void)write(STDOUT_FILENO, buf, cc);
261 }
262 } while ((pfd[0].revents & POLLIN) || (pfd[1].revents & POLLIN));
===
capture-ports disable;
interface em0;
rsh enable at 127.0.0.1;
rsh root@127.0.0.1 admin;
rsh 127.0.0.1;
rsh ttl = 3;
rsh timeout = 30;
dumpfile = ipcad.dump;
chroot = /var/ipcad;
pidfile = ipcad.pid;
memory_limit = 1m;
rsh vs net/ipcad - problems on 5.5
I encountered a strange problem when trying to communicate with net/ipcad: rsh localhost stats rsh: poll: Undefined error: 0 Same thing on 5.1: rsh localhost stats connect to address ::1: Connection refused Trying 127.0.0.1... Interface vlan123: received 585816944, 5 m average 313 bytes/sec, 4 pkts/sec, dropped 6078 Flow entries made: 583 Memory usage: 6% (65296 from 1048576) Free slots for rsh clients: 9 IPCAD uptime is 159 days 7:04 fw.example.com uptime is 159 days 7:04 According to sthen@ this also works fine on 5.4 and he suspects breakage due to time_t changes. He also provided simple sample config http://pbot.rmdir.de/iFGRSOehzxnZ1flTJqum5Q because he's awesome like that ;) kern.version=OpenBSD 5.5 (GENERIC.MP) #0: Fri Apr 25 13:03:34 CEST 2014 r...@stable-55-amd64.mtier.org:/binpatchng/work-binpatch55-amd64/src/sys/arch/amd64/compile/GENERIC.MP ipcad-3.7.3p1 -- viq
Re: link-local address issues
On Tue, May 20, 2014 at 12:02:47PM +0200, Stefan Sperling wrote: | On Tue, May 20, 2014 at 11:33:48AM +0200, Paul de Weerd wrote: | > As can be seen, the host part of the link-local address doesn't | > resemble the lladdr at all. This isn't a problem for outgoing | > connections, but when using SLAAC the global unicast address that is | > assigned is now suddenly different from what it used to be (so from | > what is in DNS), so I can't easily connect to my machines over IPv6 | > anymore. | | I"m seeing this, too (-current built last Sunday). | | What strikes me is that the link-local address contains the same | bits as the SLAAC address (lines aligned to make this easier to see): | | lladdr 40:61:86:85:70:71 | inet6 fe80::b020:cbf3:e5a1:d0d3%re0 prefixlen 64 scopeid 0x1 | inet6 2001:67c:1407:10:b020:cbf3:e5a1:d0d3 prefixlen 64 autoconf pltime 604638 vltime 2591838 |^^^ | | The first address is supposed to be the link-local address based | on the MAC (40:61:86:85:70:71), but somehow contains the SLAAC | address bits... ??? The SLAAC address isn't the source of these bits, they're generated and then used as the eui64 host part of both the link-local and the SLAAC address. Previously, the SLAAC address would also have the same bits as the link-local address (but then they'd both be based off the lladdr with the 6th bit inverted and 0xfffe inserted in the middle). This should be the behavior that you get with mpi's diff (thanks, Martin!). I'm updating my tree and will compile a new kernel shortly but won't be able to reboot and test until tonight. Cheers, Paul 'WEiRD' de Weerd | On another box which runs a snapshot built April 29 this still | works as expected: | | lladdr 00:00:24:c9:2f:01 | inet6 fe80::200:24ff:fec9:2f01%vr1 prefixlen 64 scopeid 0x2 -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: link-local address issues
On Tue, May 20, 2014 at 11:33:48AM +0200, Paul de Weerd wrote: > As can be seen, the host part of the link-local address doesn't > resemble the lladdr at all. This isn't a problem for outgoing > connections, but when using SLAAC the global unicast address that is > assigned is now suddenly different from what it used to be (so from > what is in DNS), so I can't easily connect to my machines over IPv6 > anymore. I"m seeing this, too (-current built last Sunday). What strikes me is that the link-local address contains the same bits as the SLAAC address (lines aligned to make this easier to see): lladdr 40:61:86:85:70:71 inet6 fe80::b020:cbf3:e5a1:d0d3%re0 prefixlen 64 scopeid 0x1 inet6 2001:67c:1407:10:b020:cbf3:e5a1:d0d3 prefixlen 64 autoconf pltime 604638 vltime 2591838 ^^^ The first address is supposed to be the link-local address based on the MAC (40:61:86:85:70:71), but somehow contains the SLAAC address bits... ??? On another box which runs a snapshot built April 29 this still works as expected: lladdr 00:00:24:c9:2f:01 inet6 fe80::200:24ff:fec9:2f01%vr1 prefixlen 64 scopeid 0x2
Re: link-local address issues
Hey Paul,
On 20/05/14(Tue) 11:33, Paul de Weerd wrote:
> Hi all, Martin,
>
> There seems to be an issue with generating eui64 addresses.
Indeed, thanks for reporting the problem.
> [weerd@pom] $ ifconfig em0
> em0: flags=8843 mtu 1500
> lladdr b8:ca:3a:93:03:e8
> inet6 fe80::3c16:979e:9360:ec89%em0 prefixlen 64 scopeid 0x1
> [weerd@pom] $ sysctl kern.version
> kern.version=OpenBSD 5.5-current (GENERIC.MP) #136: Mon May 19 09:40:42 MDT
> 2014
> t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> [weerd@twix] $ ifconfig vr0
> vr0: flags=48843 mtu 1500
> lladdr 00:0d:b9:14:6f:08
> inet6 fe80::cc08:36fd:9a4a:b30%vr0 prefixlen 64 scopeid 0x1
> [weerd@twix] $ sysctl kern.version
> kern.version=OpenBSD 5.5-current (GENERIC) #115: Mon May 19 08:39:42 MDT 2014
> t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
>
> [weerd@drop] $ ifconfig iwn0
> iwn0: flags=8843 mtu 1500
> lladdr 88:53:2e:d9:dd:9d
> inet6 fe80::c0d9:7d41:5229:b6f3%iwn0 prefixlen 64 scopeid 0x1
> [weerd@drop] $ sysctl kern.version
> kern.version=OpenBSD 5.5-current (GENERIC.MP) #6: Sat May 17 11:23:06 CEST
> 2014
> we...@drop.weirdnet.nl:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> (ifconfig output redacted for brevity)
>
> As can be seen, the host part of the link-local address doesn't
> resemble the lladdr at all. This isn't a problem for outgoing
> connections, but when using SLAAC the global unicast address that is
> assigned is now suddenly different from what it used to be (so from
> what is in DNS), so I can't easily connect to my machines over IPv6
> anymore.
>
> I'm not sure when this started, the last kernel that still worked with
> the 'regular' eui64 link-local address on machine 'pom' was:
This is regression introduced the 16/05 when I removed the link-layer
addresses from the RB-tree *and* the local list. The problem is that
I forgot a custom look in inet6 generating eui64 addreses. Diff below
fixes that for me, does it works for you?
Index: netinet6/in6_ifattach.c
===
RCS file: /home/ncvs/src/sys/netinet6/in6_ifattach.c,v
retrieving revision 1.68
diff -u -p -r1.68 in6_ifattach.c
--- netinet6/in6_ifattach.c 21 Jan 2014 10:18:26 - 1.68
+++ netinet6/in6_ifattach.c 20 May 2014 09:53:42 -
@@ -141,14 +141,12 @@ in6_get_rand_ifid(struct ifnet *ifp, str
/*
* Get interface identifier for the specified interface.
- * XXX assumes single sockaddr_dl (AF_LINK address) per an interface
*
* in6 - upper 64bits are preserved
*/
int
get_hw_ifid(struct ifnet *ifp, struct in6_addr *in6)
{
- struct ifaddr *ifa;
struct sockaddr_dl *sdl;
char *addr;
size_t addrlen;
@@ -156,21 +154,10 @@ get_hw_ifid(struct ifnet *ifp, struct in
static u_int8_t allone[8] =
{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
- TAILQ_FOREACH(ifa, &ifp->if_addrlist, ifa_list) {
- if (ifa->ifa_addr->sa_family != AF_LINK)
- continue;
- sdl = (struct sockaddr_dl *)ifa->ifa_addr;
- if (sdl == NULL)
- continue;
- if (sdl->sdl_alen == 0)
- continue;
+ sdl = (struct sockaddr_dl *)ifp->if_sadl;
+ if (sdl == NULL || sdl->sdl_alen == 0)
+ return -1;
- goto found;
- }
-
- return -1;
-
-found:
addr = LLADDR(sdl);
addrlen = sdl->sdl_alen;
Re: PATCH: acpibat - expose "capacity" as sensor
20.05.2014 13:32 пользователь "Landry Breuil"
написал:
>
> On Tue, May 20, 2014 at 01:19:44PM +0400, Vadim Zhukov wrote:
> > 17.05.2014 20:32 "Fabian Raetz" <
fabian.ra...@gmail.com>
> > ??:
> > >
> > > Hi,
> > >
> > > i want to expose "capacity" (full capacity design)
> > > as a sensor like the rest.
> > >
> > > This sensor will be used in an upcoming diff to upower to
> > > expose "energy-full-design" and "capacity" properties if
> > > this patch gets merged.
> > >
> > > Both patches together will fix wrong notifications about
> > > broken batteries in KDE4.
> > >
> > > Cheers,
> > > Fabian
> > >
> > >
> > > Index: acpidev.h
> > > ===
> > > RCS file: /cvs/src/sys/dev/acpi/acpidev.h,v
> > > retrieving revision 1.33
> > > diff -u -p -r1.33 acpidev.h
> > > --- acpidev.h 13 Jul 2012 10:37:40 - 1.33
> > > +++ acpidev.h 17 May 2014 15:51:29 -
> > > @@ -278,7 +278,7 @@ struct acpibat_softc {
> > > struct acpibat_bst sc_bst;
> > > volatile intsc_bat_present;
> > >
> > > - struct ksensor sc_sens[8];
> > > + struct ksensor sc_sens[9];
> > > struct ksensordev sc_sensdev;
> > > };
> > >
> > > Index: acpibat.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/acpi/acpibat.c,v
> > > retrieving revision 1.59
> > > diff -u -p -r1.59 acpibat.c
> > > --- acpibat.c 16 Oct 2011 11:59:21 - 1.59
> > > +++ acpibat.c 17 May 2014 15:51:29 -
> > > @@ -163,6 +163,12 @@ acpibat_monitor(struct acpibat_softc *sc
> > > sensor_attach(&sc->sc_sensdev, &sc->sc_sens[7]);
> > > sc->sc_sens[7].value = sc->sc_bst.bst_voltage * 1000;
> > >
> > > + strlcpy(sc->sc_sens[8].desc, "capacity",
> > > + sizeof(sc->sc_sens[8].desc));
> > > + sc->sc_sens[8].type = type;
> > > + sensor_attach(&sc->sc_sensdev, &sc->sc_sens[8]);
> > > + sc->sc_sens[8].value = sc->sc_bif.bif_capacity * 1000;
> >
> > It looks like a missing check for BIF_UNKNOWN, like in
acpibat_refresh().
> > Otherwise okay zhuk@.
>
> If you look at the surrounding code in acpibat_monitor(), none of the
> assignments check for *UNKNOWN values, so i dont think we should bother.
>
> I agree that 'design capacity' might be better than "capacity" too..
And this looks like a (small) bug. Maybe we should just put
SENSOR_S_UNKNOWN in acpibat_attach() everywhere, and just rely on
acpibat_refresh() to do the actual job? That's for a separate commit, of
course.
> todd, can you put this in snaps so that we know if there's some fallout
> ?
Why not just commit this? :)
link-local address issues
Hi all, Martin, There seems to be an issue with generating eui64 addresses. [weerd@pom] $ ifconfig em0 em0: flags=8843 mtu 1500 lladdr b8:ca:3a:93:03:e8 inet6 fe80::3c16:979e:9360:ec89%em0 prefixlen 64 scopeid 0x1 [weerd@pom] $ sysctl kern.version kern.version=OpenBSD 5.5-current (GENERIC.MP) #136: Mon May 19 09:40:42 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP [weerd@twix] $ ifconfig vr0 vr0: flags=48843 mtu 1500 lladdr 00:0d:b9:14:6f:08 inet6 fe80::cc08:36fd:9a4a:b30%vr0 prefixlen 64 scopeid 0x1 [weerd@twix] $ sysctl kern.version kern.version=OpenBSD 5.5-current (GENERIC) #115: Mon May 19 08:39:42 MDT 2014 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC [weerd@drop] $ ifconfig iwn0 iwn0: flags=8843 mtu 1500 lladdr 88:53:2e:d9:dd:9d inet6 fe80::c0d9:7d41:5229:b6f3%iwn0 prefixlen 64 scopeid 0x1 [weerd@drop] $ sysctl kern.version kern.version=OpenBSD 5.5-current (GENERIC.MP) #6: Sat May 17 11:23:06 CEST 2014 we...@drop.weirdnet.nl:/usr/src/sys/arch/amd64/compile/GENERIC.MP (ifconfig output redacted for brevity) As can be seen, the host part of the link-local address doesn't resemble the lladdr at all. This isn't a problem for outgoing connections, but when using SLAAC the global unicast address that is assigned is now suddenly different from what it used to be (so from what is in DNS), so I can't easily connect to my machines over IPv6 anymore. I'm not sure when this started, the last kernel that still worked with the 'regular' eui64 link-local address on machine 'pom' was: OpenBSD 5.5-current (GENERIC.MP) #105: Sun May 4 18:35:59 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP One final thing to note is that these 'new' addresses are persistent across reboots (so it's not a case of misapplied autoconfprivacy, I think). Before I go bisecting for the faulty commit, does anybody have an idea what might be going on? mpi, I'm CC:'ing you since you've been doing some changes in this and related areas so maybe this rings a bell with you. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: PATCH: acpibat - expose "capacity" as sensor
On Tue, May 20, 2014 at 01:19:44PM +0400, Vadim Zhukov wrote:
> 17.05.2014 20:32 "Fabian Raetz"
>
> ??:
> >
> > Hi,
> >
> > i want to expose "capacity" (full capacity design)
> > as a sensor like the rest.
> >
> > This sensor will be used in an upcoming diff to upower to
> > expose "energy-full-design" and "capacity" properties if
> > this patch gets merged.
> >
> > Both patches together will fix wrong notifications about
> > broken batteries in KDE4.
> >
> > Cheers,
> > Fabian
> >
> >
> > Index: acpidev.h
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/acpidev.h,v
> > retrieving revision 1.33
> > diff -u -p -r1.33 acpidev.h
> > --- acpidev.h 13 Jul 2012 10:37:40 - 1.33
> > +++ acpidev.h 17 May 2014 15:51:29 -
> > @@ -278,7 +278,7 @@ struct acpibat_softc {
> > struct acpibat_bst sc_bst;
> > volatile intsc_bat_present;
> >
> > - struct ksensor sc_sens[8];
> > + struct ksensor sc_sens[9];
> > struct ksensordev sc_sensdev;
> > };
> >
> > Index: acpibat.c
> > ===
> > RCS file: /cvs/src/sys/dev/acpi/acpibat.c,v
> > retrieving revision 1.59
> > diff -u -p -r1.59 acpibat.c
> > --- acpibat.c 16 Oct 2011 11:59:21 - 1.59
> > +++ acpibat.c 17 May 2014 15:51:29 -
> > @@ -163,6 +163,12 @@ acpibat_monitor(struct acpibat_softc *sc
> > sensor_attach(&sc->sc_sensdev, &sc->sc_sens[7]);
> > sc->sc_sens[7].value = sc->sc_bst.bst_voltage * 1000;
> >
> > + strlcpy(sc->sc_sens[8].desc, "capacity",
> > + sizeof(sc->sc_sens[8].desc));
> > + sc->sc_sens[8].type = type;
> > + sensor_attach(&sc->sc_sensdev, &sc->sc_sens[8]);
> > + sc->sc_sens[8].value = sc->sc_bif.bif_capacity * 1000;
>
> It looks like a missing check for BIF_UNKNOWN, like in acpibat_refresh().
> Otherwise okay zhuk@.
If you look at the surrounding code in acpibat_monitor(), none of the
assignments check for *UNKNOWN values, so i dont think we should bother.
I agree that 'design capacity' might be better than "capacity" too..
todd, can you put this in snaps so that we know if there's some fallout
?
Landry
Re: PATCH: acpibat - expose "capacity" as sensor
On Sat, May 17, 2014 at 06:32:10PM +0200, Fabian Raetz wrote:
> Hi,
>
> i want to expose "capacity" (full capacity design)
> as a sensor like the rest.
>
> This sensor will be used in an upcoming diff to upower to
> expose "energy-full-design" and "capacity" properties if
> this patch gets merged.
>
> Both patches together will fix wrong notifications about
> broken batteries in KDE4.
>
> Cheers,
> Fabian
>
I don't have any problems with this diff.
It might make sense to get this in snaps and have a few folks verify
it shows proper information on various machines though.
otherwise ok mlarkin@
>
> Index: acpidev.h
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpidev.h,v
> retrieving revision 1.33
> diff -u -p -r1.33 acpidev.h
> --- acpidev.h 13 Jul 2012 10:37:40 - 1.33
> +++ acpidev.h 17 May 2014 15:51:29 -
> @@ -278,7 +278,7 @@ struct acpibat_softc {
> struct acpibat_bst sc_bst;
> volatile intsc_bat_present;
>
> - struct ksensor sc_sens[8];
> + struct ksensor sc_sens[9];
> struct ksensordev sc_sensdev;
> };
>
> Index: acpibat.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpibat.c,v
> retrieving revision 1.59
> diff -u -p -r1.59 acpibat.c
> --- acpibat.c 16 Oct 2011 11:59:21 - 1.59
> +++ acpibat.c 17 May 2014 15:51:29 -
> @@ -163,6 +163,12 @@ acpibat_monitor(struct acpibat_softc *sc
> sensor_attach(&sc->sc_sensdev, &sc->sc_sens[7]);
> sc->sc_sens[7].value = sc->sc_bst.bst_voltage * 1000;
>
> + strlcpy(sc->sc_sens[8].desc, "capacity",
> + sizeof(sc->sc_sens[8].desc));
> + sc->sc_sens[8].type = type;
> + sensor_attach(&sc->sc_sensdev, &sc->sc_sens[8]);
> + sc->sc_sens[8].value = sc->sc_bif.bif_capacity * 1000;
> +
> sensordev_install(&sc->sc_sensdev);
> }
>
> @@ -176,7 +182,7 @@ acpibat_refresh(void *arg)
> sc->sc_devnode->name);
>
> if (!sc->sc_bat_present) {
> - for (i = 0; i < 8; i++) {
> + for (i = 0; i < 9; i++) {
> sc->sc_sens[i].value = 0;
> sc->sc_sens[i].status = SENSOR_S_UNSPEC;
> sc->sc_sens[i].flags = SENSOR_FINVALID;
> @@ -273,6 +279,16 @@ acpibat_refresh(void *arg)
> sc->sc_sens[7].value = sc->sc_bst.bst_voltage * 1000;
> sc->sc_sens[7].status = SENSOR_S_UNSPEC;
> sc->sc_sens[7].flags = 0;
> + }
> +
> + if (sc->sc_bif.bif_capacity == BIF_UNKNOWN) {
> + sc->sc_sens[8].value = 0;
> + sc->sc_sens[8].status = SENSOR_S_UNKNOWN;
> + sc->sc_sens[8].flags = SENSOR_FUNKNOWN;
> + } else {
> + sc->sc_sens[8].value = sc->sc_bif.bif_capacity * 1000;
> + sc->sc_sens[8].status = SENSOR_S_UNSPEC;
> + sc->sc_sens[8].flags = 0;
> }
> acpi_record_event(sc->sc_acpi, APM_POWER_CHANGE);
> }
>
Re: PATCH: acpibat - expose "capacity" as sensor
17.05.2014 20:32 пользователь "Fabian Raetz"
написал:
>
> Hi,
>
> i want to expose "capacity" (full capacity design)
> as a sensor like the rest.
>
> This sensor will be used in an upcoming diff to upower to
> expose "energy-full-design" and "capacity" properties if
> this patch gets merged.
>
> Both patches together will fix wrong notifications about
> broken batteries in KDE4.
>
> Cheers,
> Fabian
>
>
> Index: acpidev.h
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpidev.h,v
> retrieving revision 1.33
> diff -u -p -r1.33 acpidev.h
> --- acpidev.h 13 Jul 2012 10:37:40 - 1.33
> +++ acpidev.h 17 May 2014 15:51:29 -
> @@ -278,7 +278,7 @@ struct acpibat_softc {
> struct acpibat_bst sc_bst;
> volatile intsc_bat_present;
>
> - struct ksensor sc_sens[8];
> + struct ksensor sc_sens[9];
> struct ksensordev sc_sensdev;
> };
>
> Index: acpibat.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/acpibat.c,v
> retrieving revision 1.59
> diff -u -p -r1.59 acpibat.c
> --- acpibat.c 16 Oct 2011 11:59:21 - 1.59
> +++ acpibat.c 17 May 2014 15:51:29 -
> @@ -163,6 +163,12 @@ acpibat_monitor(struct acpibat_softc *sc
> sensor_attach(&sc->sc_sensdev, &sc->sc_sens[7]);
> sc->sc_sens[7].value = sc->sc_bst.bst_voltage * 1000;
>
> + strlcpy(sc->sc_sens[8].desc, "capacity",
> + sizeof(sc->sc_sens[8].desc));
> + sc->sc_sens[8].type = type;
> + sensor_attach(&sc->sc_sensdev, &sc->sc_sens[8]);
> + sc->sc_sens[8].value = sc->sc_bif.bif_capacity * 1000;
It looks like a missing check for BIF_UNKNOWN, like in acpibat_refresh().
Otherwise okay zhuk@.
> +
> sensordev_install(&sc->sc_sensdev);
> }
>
> @@ -176,7 +182,7 @@ acpibat_refresh(void *arg)
> sc->sc_devnode->name);
>
> if (!sc->sc_bat_present) {
> - for (i = 0; i < 8; i++) {
> + for (i = 0; i < 9; i++) {
> sc->sc_sens[i].value = 0;
> sc->sc_sens[i].status = SENSOR_S_UNSPEC;
> sc->sc_sens[i].flags = SENSOR_FINVALID;
> @@ -273,6 +279,16 @@ acpibat_refresh(void *arg)
> sc->sc_sens[7].value = sc->sc_bst.bst_voltage * 1000;
> sc->sc_sens[7].status = SENSOR_S_UNSPEC;
> sc->sc_sens[7].flags = 0;
> + }
> +
> + if (sc->sc_bif.bif_capacity == BIF_UNKNOWN) {
> + sc->sc_sens[8].value = 0;
> + sc->sc_sens[8].status = SENSOR_S_UNKNOWN;
> + sc->sc_sens[8].flags = SENSOR_FUNKNOWN;
> + } else {
> + sc->sc_sens[8].value = sc->sc_bif.bif_capacity * 1000;
> + sc->sc_sens[8].status = SENSOR_S_UNSPEC;
> + sc->sc_sens[8].flags = 0;
> }
> acpi_record_event(sc->sc_acpi, APM_POWER_CHANGE);
> }
>
Re: PATCH: acpibat - expose "capacity" as sensor
Hi, I have a similar diff in my tree. I think "design capacity" could be more clear for the sensor description. apart from that, ok armani@ fwiw 2014-05-19 23:58 GMT+02:00 Landry Breuil : > On Sun, May 18, 2014 at 08:56:15AM +0200, Landry Breuil wrote: > > On Sat, May 17, 2014 at 06:32:10PM +0200, Fabian Raetz wrote: > > > Hi, > > > > > > i want to expose "capacity" (full capacity design) > > > as a sensor like the rest. > > > > > > This sensor will be used in an upcoming diff to upower to > > > expose "energy-full-design" and "capacity" properties if > > > this patch gets merged. > > > > > > Both patches together will fix wrong notifications about > > > broken batteries in KDE4. > > > > Interesting - i've done a similar thing in the past to enable the 'lid > > open' sysctl status, so i'd welcome this kind of patch. Can you also > > show the diff for upower, and exactly what it fixes for KDE4 ? For > > example, the difference in upower -d output with and without that patch > > ? What's the exact difference between energy-full-design and capacity > > for upower ? > > i've successfully tested this on i386 (5 years old msi wind U100 > netbook) and amd64 (x200s), with sensors and the upower patch, and i > think this provides valuable information on the device status. Mike, > Mark, can you have a look at it ? I'd okay this but that's not my area. > > amd64: > > hw.sensors.acpibtn0.indicator0=On (lid open) > hw.sensors.acpibat0.power0=19.28 W (rate) > hw.sensors.acpibat0.watthour0=64.07 Wh (last full capacity) > hw.sensors.acpibat0.watthour1=3.20 Wh (warning capacity) > hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity) > hw.sensors.acpibat0.watthour3=59.04 Wh (remaining capacity), OK > hw.sensors.acpibat0.watthour4=84.24 Wh (capacity) > hw.sensors.acpibat0.raw0=2 (battery charging), OK > hw.sensors.acpiac0.indicator0=On (power supply) > > > (upower -d) > > energy: 61.06 Wh > energy-empty:0.2 Wh > energy-full: 64.07 Wh > energy-full-design: 84.24 Wh > energy-rate: 16.273 W > voltage: 12.48 V > percentage: 95% > capacity:76.0565% > > i386: > > hw.sensors.acpiac0.indicator0=On (power supply) > hw.sensors.acpibat0.current0=0.56 A (rate) > hw.sensors.acpibat0.amphour0=2.03 Ah (last full capacity) > hw.sensors.acpibat0.amphour1=0.00 Ah (warning capacity) > hw.sensors.acpibat0.amphour2=0.00 Ah (low capacity) > hw.sensors.acpibat0.amphour3=1.71 Ah (remaining capacity), OK > hw.sensors.acpibat0.amphour4=4.40 Ah (capacity) > hw.sensors.acpibat0.raw0=2 (battery charging), OK > hw.sensors.acpibtn0.indicator0=On (lid open) > > (upower -d) > > state: fully-charged > warning-level: none > energy: 25.335 Wh > energy-empty:0 Wh > energy-full: 25.3599 Wh > energy-full-design: 54.8592 Wh > energy-rate: 0 W > voltage: 12.468 V > percentage: 99% > capacity:46.2273% > >
