snmpd(8) remove OID CONFIGURATION
Hello tech@,
Working on something else, this bit of code is somewhat in my way and it
feels like an early testing feature instead of actually being useful.
Is anyone actually using this, or can it be removed?
martijn@
Index: mps.c
===
RCS file: /cvs/src/usr.sbin/snmpd/mps.c,v
retrieving revision 1.28
diff -u -p -r1.28 mps.c
--- mps.c 24 Oct 2019 12:39:27 - 1.28
+++ mps.c 12 Feb 2020 06:47:36 -
@@ -51,17 +51,6 @@ struct ber_oid *
extern void control_event_add(struct ctl_conn *, int, int, struct timeval *);
/* XXX */
int
-mps_getstr(struct oid *oid, struct ber_oid *o, struct ber_element **elm)
-{
- char*s = oid->o_data;
-
- if (s == NULL)
- return (-1);
- *elm = ober_add_string(*elm, s);
- return (0);
-}
-
-int
mps_setstr(struct oid *oid, struct ber_oid *o, struct ber_element **elm)
{
struct ber_element *ber = *elm;
@@ -88,18 +77,6 @@ int
mps_getint(struct oid *oid, struct ber_oid *o, struct ber_element **elm)
{
*elm = ober_add_integer(*elm, oid->o_val);
- return (0);
-}
-
-int
-mps_setint(struct oid *oid, struct ber_oid *o, struct ber_element **elm)
-{
- long longi;
-
- if (ober_get_integer(*elm, ) == -1)
- return (-1);
- oid->o_val = i;
-
return (0);
}
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/snmpd/parse.y,v
retrieving revision 1.57
diff -u -p -r1.57 parse.y
--- parse.y 2 Jan 2020 10:55:53 - 1.57
+++ parse.y 12 Feb 2020 06:47:36 -
@@ -138,8 +138,8 @@ typedef struct {
%token NUMBER
%typehostcmn
%typesrcaddr
-%typeoptwrite yesno seclevel socktype proto
-%type objtype cmd
+%typeyesno seclevel socktype proto
+%type cmd
%type oid hostoid trapoid
%type auth
%type enc
@@ -152,7 +152,6 @@ grammar : /* empty */
| grammar varset '\n'
| grammar main '\n'
| grammar system '\n'
- | grammar mib '\n'
| grammar error '\n'{ file->errors++; }
;
@@ -349,61 +348,6 @@ sysmib : CONTACT STRING{
struct ber_oid o = OID(MIB_sysServices);
mps_set(, NULL, $2);
}
- ;
-
-mib: OBJECTID oid NAME STRING optwrite objtype {
- struct oid *oid;
- if ((oid = (struct oid *)
- calloc(1, sizeof(*oid))) == NULL) {
- yyerror("calloc");
- free($2);
- free($6.data);
- YYERROR;
- }
-
- smi_oidlen($2);
- bcopy($2, >o_id, sizeof(struct ber_oid));
- free($2);
- oid->o_name = $4;
- oid->o_data = $6.data;
- oid->o_val = $6.value;
- switch ($6.type) {
- case 1:
- oid->o_get = mps_getint;
- oid->o_set = mps_setint;
- break;
- case 2:
- oid->o_get = mps_getstr;
- oid->o_set = mps_setstr;
- break;
- }
- oid->o_flags = OID_RD|OID_DYNAMIC;
- if ($5)
- oid->o_flags |= OID_WR;
-
- if (smi_insert(oid) == -1) {
- yyerror("duplicate oid");
- free(oid->o_name);
- free(oid->o_data);
- YYERROR;
- }
- }
- ;
-
-objtype: INTEGER NUMBER{
- $$.type = 1;
- $$.data = NULL;
- $$.value = $2;
- }
- | OCTETSTRING STRING{
- $$.type = 2;
- $$.data = $2;
- $$.value = strlen($2);
- }
- ;
-
-optwrite : READONLY { $$ = 0; }
- | READWRITE { $$ = 1; }
;
oid: STRING{
Index: snmpd.conf.5
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpd.conf.5,v
retrieving revision 1.42
diff -u -p -r1.42 snmpd.conf.5
--- snmpd.conf.510 Feb
Re: macppc base-clang -msvr4-struct-return
George Koehler wrote: > On Tue, 11 Feb 2020 18:58:48 +0100 > Jeremie Courreges-Anglas wrote: > > > So the steps would be: > > - build and install a new clang > > - bump the major of libc++, build and install it > > - rebuild and reinstall clang > > - build new snap > > You are the first person to suggest bumping .so majors; I didn't think > to do so. If libc++ needs a major bump, then libc++abi and libLLVM > might also need them. These 3 are the only .so (that I can find) > built by base-clang on powerpc. > > Across base + xenocara + ports, almost nothing uses these 3 .so on > powerpc. The only users that I find are > - /usr/bin/clang* using libc++.so.3.0 and libc++abi.so.1.0 > - nothing using libLLVM.so.1.0 > > (xenocara/lib/mesa uses libLLVM only for i386 amd64 arm64. I looked > for ports with LLVM in WANTLIB, found only devel/py-llvmlite, but it > requires base-clang, and ports doesn't use base-clang for powerpc.) > > If we don't bump majors, then people who upgrade OpenBSD macppc would > get the new libc++.so.3.0 and libc++abi.so.1.0 at the same time as the > new clang; and people on other platforms won't see an unnecessary > major bump. > > If we do bump majors, then people who had used /usr/bin/clang++ on > OpenBSD macppc might be able to run their old binaries with the old > libc++.so.3.0 and libc++abi.so.1.0, while the new clang would use > libc++.so.4.0 and libc++abi.so.2.0. We always bump minors or majors when the ABI changes (depends which kind of ABI changes, but majors are common). We never sneak in a ABI change. You are changing the ABI. There's only one way this goes.. Yes the files change on all architectures. There's nothing wrong with that. As long as it can build through..
Re: macppc base-clang -msvr4-struct-return
On Tue, 11 Feb 2020 18:58:48 +0100 Jeremie Courreges-Anglas wrote: > So the steps would be: > - build and install a new clang > - bump the major of libc++, build and install it > - rebuild and reinstall clang > - build new snap You are the first person to suggest bumping .so majors; I didn't think to do so. If libc++ needs a major bump, then libc++abi and libLLVM might also need them. These 3 are the only .so (that I can find) built by base-clang on powerpc. Across base + xenocara + ports, almost nothing uses these 3 .so on powerpc. The only users that I find are - /usr/bin/clang* using libc++.so.3.0 and libc++abi.so.1.0 - nothing using libLLVM.so.1.0 (xenocara/lib/mesa uses libLLVM only for i386 amd64 arm64. I looked for ports with LLVM in WANTLIB, found only devel/py-llvmlite, but it requires base-clang, and ports doesn't use base-clang for powerpc.) If we don't bump majors, then people who upgrade OpenBSD macppc would get the new libc++.so.3.0 and libc++abi.so.1.0 at the same time as the new clang; and people on other platforms won't see an unnecessary major bump. If we do bump majors, then people who had used /usr/bin/clang++ on OpenBSD macppc might be able to run their old binaries with the old libc++.so.3.0 and libc++abi.so.1.0, while the new clang would use libc++.so.4.0 and libc++abi.so.2.0. --George
Re: sparc64: magma(4): timeout_add(9) -> timeout_add_msec(9)
On Mon, Feb 10, 2020 at 05:37:04PM -0600, Scott Cheloha wrote: > This code converts between milliseconds and ticks. If we strip out > the conversions we can just use milliseconds directly with > timeout_add_msec(9) and delete the conversion code, too. I agree. > This is only built for sparc64. It ought to compile but I'm not sure. > > Assuming it compiles, ok? Builds fine, but I don't have the hardware. OK kn
Re: sparc64: stp(4): tsleep(9) -> tsleep_nsec(9)
On Mon, Feb 10, 2020 at 05:28:43PM -0600, Scott Cheloha wrote:
> The parameter name "ms" is misleading. All the calling code uses
> microseconds. I think the author's thought process in choosing that
> name was roughly: "microseconds" -> "Micro Seconds" -> "ms".
>
> In any case, I've renamed the parameter to the less misleading
> "usecs".
Looks good to me.
> This driver is only built on sparc64. I think this ought to compile.
> If someone could confirm that it compiles that would help.
>
> If someone has one of these things that would be even better, though I
> have my doubts.
Compiles fine, but I have no real hardware to test.
> #ifdef DEBUG
> - if (nticks > 60 * hz)
> - panic("stp4020: preposterous delay: %u", nticks);
> + if (usecs > 60 * 100)
Counting zeroes and lack of names or units on one site always make me
double check, how about the following? Seems verbose indeed but is
obvious to read, imho.
if (USEC_TO_NSEC(usecs) > SEC_TO_NSEC(60))
Re: sys/cdefs.h: fix __predict_false fallback implementation
On Tue, Feb 11 2020, "Todd C. Miller" wrote: > On Tue, 11 Feb 2020 21:44:21 +, Nicholas Marriott wrote: > >> Looks like the existing code is OK, you still want to test the original >> expression even if you are predicting it is false, no? > > Right, the code is correct as written. Woops, brain fart on my side, thanks. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: sys/cdefs.h: fix __predict_false fallback implementation
On Tue, 11 Feb 2020 21:44:21 +, Nicholas Marriott wrote: > Looks like the existing code is OK, you still want to test the original > expression even if you are predicting it is false, no? Right, the code is correct as written. - todd
Re: sys/cdefs.h: fix __predict_false fallback implementation
Looks like the existing code is OK, you still want to test the original expression even if you are predicting it is false, no? On Tue, Feb 11, 2020 at 07:33:19PM +0100, Jeremie Courreges-Anglas wrote: > > Found while looking at __ISO_C_VISIBLE. I'm not sure which compilers > would be affected. The fallback could simply be > #define __predict_true(exp) (exp) > #define __predict_false(exp) (exp) > but I settled for a minimal change. > > ok? > > > Index: cdefs.h > === > RCS file: /d/cvs/src/sys/sys/cdefs.h,v > retrieving revision 1.43 > diff -u -p -p -u -r1.43 cdefs.h > --- cdefs.h 29 Oct 2018 17:10:40 - 1.43 > +++ cdefs.h 11 Feb 2020 18:27:18 - > @@ -193,7 +193,7 @@ > #define __predict_false(exp) __builtin_expect(((exp) != 0), 0) > #else > #define __predict_true(exp) ((exp) != 0) > -#define __predict_false(exp) ((exp) != 0) > +#define __predict_false(exp) ((exp) == 0) > #endif > > /* Delete pseudo-keywords wherever they are not available or needed. */ > > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE >
Re: macppc base-clang -msvr4-struct-return
Jeremie Courreges-Anglas wrote: > On Tue, Feb 11 2020, George Koehler wrote: > > On Tue, 11 Feb 2020 15:20:00 +0100 > > Jeremie Courreges-Anglas wrote: > > > >> fwiw I'm already ok with the diff George sent for ports/devel/llvm. > >> I'm mostly ok with this one but it would be nice to know whether > >> base-clang can rebuild itself. :) > > > > base-clang can't rebuild itself in the normal way. I have been > > exchanging mails with Todd Mortimer, who has been testing my diff with > > a faster macppc machine. The diff changes the ABI between > > /usr/bin/clang and /usr/lib/libc++.so.3.0, so when we install a new > > libc++ built by clang -msvr4-struct-return, but still have a clang > > built as if by -maix-struct-return, then clang crashes and can't > > rebuild itself! It might be possible to use a static-link clang to > > cross the ABI change. > > > > A backtrace from clang pointed to a function in libc++ that returns a > > std::string::iterator, a small struct where sizeof(iterator) == 4. > > So the steps would be: > - build and install a new clang > - bump the major of libc++, build and install it > - rebuild and reinstall clang > - build new snap > > Assuming those steps are correct, you could ask Theo to handle the ABI > break. A note in current.html could be useful too. Sure, commit it then I'll follow.
Re: Audio control API, part 1: libsndio, sndiod bits
On Tue, Feb 11, 2020 at 07:01:28PM +0100, Florian Obser wrote: > I've been running the base diffs since you posted them. Firefox, > chrome and mpv still make noise :) > > I'm puzzled by this: > > $ cat /etc/mixerctl.conf > outputs.master=255,255 > record.enable=off > > $ mixerctl outputs.master > outputs.master=255,255 > > $ sndioctl > output.level=127 > > I don't understand how they relate and why one goes to 255 and the > other to 127. > The error reporting is confusing, too: > > $ sndioctl output.level=128 > integer overflow > > But no regressions to report :) > Thanks, the code is base on MIDI bits, which uses the 0..127 range; sndiod, aucat and many codecs also use the 0..127 range. Anyway, replaced the error message by: $ sndioctl output.level=128 128: expected integer in the 0..127 range [...] I'm wondering if persents or floating points in the [0:1] range would be less confusing and solve most "units" problems.
sys/cdefs.h: fix __predict_false fallback implementation
Found while looking at __ISO_C_VISIBLE. I'm not sure which compilers would be affected. The fallback could simply be #define __predict_true(exp)(exp) #define __predict_false(exp) (exp) but I settled for a minimal change. ok? Index: cdefs.h === RCS file: /d/cvs/src/sys/sys/cdefs.h,v retrieving revision 1.43 diff -u -p -p -u -r1.43 cdefs.h --- cdefs.h 29 Oct 2018 17:10:40 - 1.43 +++ cdefs.h 11 Feb 2020 18:27:18 - @@ -193,7 +193,7 @@ #define __predict_false(exp) __builtin_expect(((exp) != 0), 0) #else #define __predict_true(exp)((exp) != 0) -#define __predict_false(exp) ((exp) != 0) +#define __predict_false(exp) ((exp) == 0) #endif /* Delete pseudo-keywords wherever they are not available or needed. */ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Audio control API, part 1: libsndio, sndiod bits
I've been running the base diffs since you posted them. Firefox, chrome and mpv still make noise :) I'm puzzled by this: $ cat /etc/mixerctl.conf outputs.master=255,255 record.enable=off $ mixerctl outputs.master outputs.master=255,255 $ sndioctl output.level=127 I don't understand how they relate and why one goes to 255 and the other to 127. The error reporting is confusing, too: $ sndioctl output.level=128 integer overflow But no regressions to report :) -- I'm not entirely sure you are real.
Re: macppc base-clang -msvr4-struct-return
On Tue, Feb 11 2020, George Koehler wrote: > On Tue, 11 Feb 2020 15:20:00 +0100 > Jeremie Courreges-Anglas wrote: > >> fwiw I'm already ok with the diff George sent for ports/devel/llvm. >> I'm mostly ok with this one but it would be nice to know whether >> base-clang can rebuild itself. :) > > base-clang can't rebuild itself in the normal way. I have been > exchanging mails with Todd Mortimer, who has been testing my diff with > a faster macppc machine. The diff changes the ABI between > /usr/bin/clang and /usr/lib/libc++.so.3.0, so when we install a new > libc++ built by clang -msvr4-struct-return, but still have a clang > built as if by -maix-struct-return, then clang crashes and can't > rebuild itself! It might be possible to use a static-link clang to > cross the ABI change. > > A backtrace from clang pointed to a function in libc++ that returns a > std::string::iterator, a small struct where sizeof(iterator) == 4. So the steps would be: - build and install a new clang - bump the major of libc++, build and install it - rebuild and reinstall clang - build new snap Assuming those steps are correct, you could ask Theo to handle the ABI break. A note in current.html could be useful too. > This was not a problem with ports-clang, because we use ports-gcc to > build ports-clang; and ports-clang uses libestdc++ (from ports-gcc), > not libc++ (from base). Both ports-clang and libestdc++ got built by > gcc -msvr4-struct-return. --George Yep. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: macppc base-clang -msvr4-struct-return
On Tue, 11 Feb 2020 15:20:00 +0100 Jeremie Courreges-Anglas wrote: > fwiw I'm already ok with the diff George sent for ports/devel/llvm. > I'm mostly ok with this one but it would be nice to know whether > base-clang can rebuild itself. :) base-clang can't rebuild itself in the normal way. I have been exchanging mails with Todd Mortimer, who has been testing my diff with a faster macppc machine. The diff changes the ABI between /usr/bin/clang and /usr/lib/libc++.so.3.0, so when we install a new libc++ built by clang -msvr4-struct-return, but still have a clang built as if by -maix-struct-return, then clang crashes and can't rebuild itself! It might be possible to use a static-link clang to cross the ABI change. A backtrace from clang pointed to a function in libc++ that returns a std::string::iterator, a small struct where sizeof(iterator) == 4. This was not a problem with ports-clang, because we use ports-gcc to build ports-clang; and ports-clang uses libestdc++ (from ports-gcc), not libc++ (from base). Both ports-clang and libestdc++ got built by gcc -msvr4-struct-return. --George
sys/cdefs.h: visibility for old C++ standards
IIUC we should limit the visibility of C features to ANSI C (instead of C11) for old C++ standards. I guess this is low priority so I didn't do much testing, but I can do a base+xenocara build on amd64 and sparc64 if deemed useful. Thoughts? Index: cdefs.h === RCS file: /d/cvs/src/sys/sys/cdefs.h,v retrieving revision 1.43 diff -u -p -p -u -r1.43 cdefs.h --- cdefs.h 29 Oct 2018 17:10:40 - 1.43 +++ cdefs.h 30 Jan 2020 19:05:23 - @@ -382,6 +382,9 @@ (defined(__cplusplus) && __cplusplus >= 201103) # undef __ISO_C_VISIBLE # define __ISO_C_VISIBLE 1999 +#elif (defined(__cplusplus) && __cplusplus < 201103) +#undef __ISO_C_VISIBLE +#define __ISO_C_VISIBLE1990 #endif /* -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: iwm: interrupt cleanup
On Tue, Feb 11, 2020 at 04:51:08PM +0100, Tobias Heider wrote:
> Hi,
>
> here are some small improvements for iwm's interrupt handler.
>
> - Hardware errors (r1 == 0x || (r1 & 0xfff0) == 0xa5a5a5a0) should
> be checked in both cases (ict and non-ict).
> - r1 and r2 should be uint32, they are read with bus_space_read_4()
> - (Slightly) better explanation for hardware bug mitigation
>
> ok?
Yes, sure.
> diff --git a/sys/dev/pci/if_iwm.c b/sys/dev/pci/if_iwm.c
> index 34877135003..518595c601e 100644
> --- a/sys/dev/pci/if_iwm.c
> +++ b/sys/dev/pci/if_iwm.c
> @@ -8589,8 +8589,9 @@ iwm_intr(void *arg)
> {
> struct iwm_softc *sc = arg;
> int handled = 0;
> - int r1, r2, rv = 0;
> + int rv = 0;
> int isperiodic = 0;
> + uint32_t r1, r2;
>
> IWM_WRITE(sc, IWM_CSR_INT_MASK, 0);
>
> @@ -8617,19 +8618,24 @@ iwm_intr(void *arg)
> if (r1 == 0x)
> r1 = 0;
>
> - /* i am not expected to understand this */
> + /*
> + * Workaround for hardware bug where bits are falsely cleared
> + * when using interrupt coalescing. Bit 15 should be set if
> + * bits 18 and 19 are set.
> + */
> if (r1 & 0xc)
> r1 |= 0x8000;
> +
> r1 = (0xff & r1) | ((0xff00 & r1) << 16);
> } else {
> r1 = IWM_READ(sc, IWM_CSR_INT);
> - if (r1 == 0x || (r1 & 0xfff0) == 0xa5a5a5a0)
> - goto out;
> r2 = IWM_READ(sc, IWM_CSR_FH_INT_STATUS);
> }
> if (r1 == 0 && r2 == 0) {
> goto out_ena;
> }
> + if (r1 == 0x || (r1 & 0xfff0) == 0xa5a5a5a0)
> + goto out;
>
> IWM_WRITE(sc, IWM_CSR_INT, r1 | ~sc->sc_intmask);
>
>
>
iwm: interrupt cleanup
Hi,
here are some small improvements for iwm's interrupt handler.
- Hardware errors (r1 == 0x || (r1 & 0xfff0) == 0xa5a5a5a0) should
be checked in both cases (ict and non-ict).
- r1 and r2 should be uint32, they are read with bus_space_read_4()
- (Slightly) better explanation for hardware bug mitigation
ok?
diff --git a/sys/dev/pci/if_iwm.c b/sys/dev/pci/if_iwm.c
index 34877135003..518595c601e 100644
--- a/sys/dev/pci/if_iwm.c
+++ b/sys/dev/pci/if_iwm.c
@@ -8589,8 +8589,9 @@ iwm_intr(void *arg)
{
struct iwm_softc *sc = arg;
int handled = 0;
- int r1, r2, rv = 0;
+ int rv = 0;
int isperiodic = 0;
+ uint32_t r1, r2;
IWM_WRITE(sc, IWM_CSR_INT_MASK, 0);
@@ -8617,19 +8618,24 @@ iwm_intr(void *arg)
if (r1 == 0x)
r1 = 0;
- /* i am not expected to understand this */
+ /*
+* Workaround for hardware bug where bits are falsely cleared
+* when using interrupt coalescing. Bit 15 should be set if
+* bits 18 and 19 are set.
+*/
if (r1 & 0xc)
r1 |= 0x8000;
+
r1 = (0xff & r1) | ((0xff00 & r1) << 16);
} else {
r1 = IWM_READ(sc, IWM_CSR_INT);
- if (r1 == 0x || (r1 & 0xfff0) == 0xa5a5a5a0)
- goto out;
r2 = IWM_READ(sc, IWM_CSR_FH_INT_STATUS);
}
if (r1 == 0 && r2 == 0) {
goto out_ena;
}
+ if (r1 == 0x || (r1 & 0xfff0) == 0xa5a5a5a0)
+ goto out;
IWM_WRITE(sc, IWM_CSR_INT, r1 | ~sc->sc_intmask);
Re: em(4) reset I210 wake status
On Wed, Feb 05, 2020 at 10:32:09PM +0800, Nathanael Rensen wrote:
> When I boot an APU2 using wake-on-lan and then attempt to power off with
> shutdown -hp it wakes itself up again. To prevent this it is necessary to
> clear the I210 PME_STATUS flag. This is described in section 5.6.2 of the
> I210 datasheet:
>
> The PE_WAKE_N remains asserted until the operating system either writes
> a 1b to the PMCSR.PME_Status bit or writes a 0b to the PMCSR.PME_En bit.
>
> In addition the WUS (wake up status) register is not automatically cleared,
> as described in section 8.2.13 of the i210 datasheet:
>
> This register is not cleared when PE_RST_N is asserted. It is only
> cleared when LAN_PWR_GOOD is deasserted or when cleared by the software
> device driver.
>
> Nathanael
>
> Index: sys/dev/pci/if_em.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_em.c,v
> retrieving revision 1.344
> diff -u -p -r1.344 if_em.c
> --- sys/dev/pci/if_em.c 4 Feb 2020 10:59:23 - 1.344
> +++ sys/dev/pci/if_em.c 5 Feb 2020 14:01:34 -
> @@ -561,6 +561,9 @@ em_attach(struct device *parent, struct
> #endif
> printf(", address %s\n", ether_sprintf(sc->sc_ac.ac_enaddr));
>
> + if (sc->hw.wus)
> + printf("%s wakeup: %d\n", sc->sc_dev.dv_xname, sc->hw.wus);
> +
Why do you need that? Is there a point to know which device got the
wakeup? In any case this should be folded into the regular device dmesg
line and not be a new line. e.g
em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03: msi, address XX:YY, wakeup
Not sure if any other driver prints a message for a wakeup event.
So maybe hw.wus is not needed and then only the if_em_hw.c part of the
diff is needed.
> /* Indicate SOL/IDER usage */
> if (em_check_phy_reset_block(>hw))
> printf("%s: PHY reset is blocked due to SOL/IDER session.\n",
> Index: sys/dev/pci/if_em_hw.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_em_hw.c,v
> retrieving revision 1.106
> diff -u -p -r1.106 if_em_hw.c
> --- sys/dev/pci/if_em_hw.c4 Feb 2020 10:59:23 - 1.106
> +++ sys/dev/pci/if_em_hw.c5 Feb 2020 14:01:34 -
> @@ -1678,6 +1678,12 @@ em_init_hw(struct em_hw *hw)
> ctrl = (ctrl & ~E1000_TXDCTL_WTHRESH) |
> E1000_TXDCTL_FULL_TX_DESC_WB;
> E1000_WRITE_REG(hw, TXDCTL(1), ctrl);
> + hw->wus = E1000_READ_REG(hw, WUS);
> + if (hw->wus)
> + E1000_WRITE_REG(hw, WUS, reg_data);
What is reg_data? Guess you want to write back hw->wus or 0 to clear it.
> + reg_data = E1000_READ_REG(hw, WUC);
> + if (reg_data & E1000_WUC_PME_STATUS)
> + E1000_WRITE_REG(hw, WUC, reg_data);
> break;
> }
>
> Index: sys/dev/pci/if_em_hw.h
> ===
> RCS file: /cvs/src/sys/dev/pci/if_em_hw.h,v
> retrieving revision 1.80
> diff -u -p -r1.80 if_em_hw.h
> --- sys/dev/pci/if_em_hw.h4 Feb 2020 10:59:23 - 1.80
> +++ sys/dev/pci/if_em_hw.h5 Feb 2020 14:01:34 -
> @@ -1482,6 +1482,7 @@ struct em_hw {
> uint16_t swfw;
> boolean_t eee_enable;
> int sw_flag;
> +int wus;
> };
>
> #define E1000_EEPROM_SWDPIN0 0x0001 /* SWDPIN 0 EEPROM Value */
>
--
:wq Claudio
Re: [PATCH] pledge: allow kern.somaxconn sysctl for inet
On Mon, Feb 03, 2020 at 12:52:05AM +, Jimmy Brush wrote:
> No golang tcp server can be pledged without this change because it
> queries kern.somaxconn before it listens on a tcp socket[1][2][3].
>
> I cannot think of any advantage this change would give an attacker
> who has compromised a pledged process.
>
> [1] https://golang.org/src/net/sock_posix.go#L57
> [2] https://golang.org/src/net/net.go#L373
> [3] https://golang.org/src/net/sock_bsd.go#L27
>
> ---
> sys/kern/kern_pledge.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git sys/kern/kern_pledge.c sys/kern/kern_pledge.c
> index 9f436df4893..8d1203198ed 100644
> --- sys/kern/kern_pledge.c
> +++ sys/kern/kern_pledge.c
> @@ -904,6 +904,12 @@ pledge_sysctl(struct proc *p, int miblen, int *mib, void
> *new)
> return (0);
> }
>
> + if ((p->p_p->ps_pledge & PLEDGE_INET)) {
> + if (miblen == 2 && /* kern.somaxconn */
> + mib[0] == CTL_KERN && mib[1] == KERN_SOMAXCONN)
> + return (0);
> + }
> +
> if ((p->p_p->ps_pledge & (PLEDGE_ROUTE | PLEDGE_INET | PLEDGE_DNS))) {
> if (miblen == 6 && /* getifaddrs() */
> mib[0] == CTL_NET && mib[1] == PF_ROUTE &&
>
I think go should not query the sysctl and instead just use a reasonably
high default (or let users choose). The kernel will then use the minimum
of the two values. At least this is what all other daemons do.
Guess that option will not happen...
--
:wq Claudio
Re: macppc base-clang -msvr4-struct-return
On Wed, Feb 05 2020, Todd Mortimer wrote: > Hi George, > > On Tue, Feb 04, 2020 at 08:39:12PM -0500, George Koehler wrote: >> Hello tech list, >> >> This is a diff for base-clang. It would change the powerpc target to >> return small structs in registers r3 and r4. This would fix an >> incompatibility with gcc in OpenBSD macppc. I fear that if I commit >> the diff, I might break snapshot builds. I am looking for help. > > The diff looks sane to me. I don't see anything that would obviously > break snaps, and the option is limited to only the ppc platform. > > I am running it through a release build here (amd64) and will know how > that turned out tomorrow after work, so will be able to confirm that you > won't break snaps on that arch. I don't expect there to be any problem > there. I should be able to test it on macppc over the weekend, so if > you're paranoid you can wait to see how that goes. fwiw I'm already ok with the diff George sent for ports/devel/llvm. I'm mostly ok with this one but it would be nice to know whether base-clang can rebuild itself. :) -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: piixpm(4) support for AMD FCH watchdog
On Sat, Feb 08, 2020 at 01:07:01PM +0800, Nathanael Rensen wrote:
> The diff below adds support for the watchdog as found in the embedded
> AMD FCH (fusion controller hub) as found on APU2.
>
> Index: sys/dev/pci/piixpm.c
> ===
> RCS file: /cvs/src/sys/dev/pci/piixpm.c,v
> retrieving revision 1.42
> diff -u -p -r1.42 piixpm.c
> --- sys/dev/pci/piixpm.c 21 Jan 2020 06:37:24 - 1.42
> +++ sys/dev/pci/piixpm.c 8 Feb 2020 04:44:42 -
> @@ -54,8 +54,10 @@ struct piixpm_softc {
> struct device sc_dev;
>
> bus_space_tag_t sc_iot;
> + bus_space_tag_t sc_memt;
> bus_space_handle_t sc_ioh;
> bus_space_handle_t sc_sb800_ioh;
> + bus_space_handle_t sc_wdt_mh;
> void * sc_ih;
> int sc_poll;
> int sc_is_sb800;
> @@ -83,6 +85,8 @@ int piixpm_i2c_exec(void *, i2c_op_t, i2
>
> int piixpm_intr(void *);
>
> +int piixpm_wdt_cb(void *arg, int period);
> +
> struct cfattach piixpm_ca = {
> sizeof(struct piixpm_softc),
> piixpm_match,
> @@ -127,7 +131,7 @@ piixpm_attach(struct device *parent, str
> struct piixpm_softc *sc = (struct piixpm_softc *)self;
> struct pci_attach_args *pa = aux;
> bus_space_handle_t ioh;
> - u_int16_t val, smb0en;
> + u_int16_t val, smb0en, wdten = 0;
> bus_addr_t base;
> pcireg_t conf;
> pci_intr_handle_t ih;
> @@ -136,6 +140,7 @@ piixpm_attach(struct device *parent, str
> int numbusses, i;
>
> sc->sc_iot = pa->pa_iot;
> + sc->sc_memt = pa->pa_memt;
> numbusses = 1;
>
> if ((PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> @@ -160,7 +165,7 @@ piixpm_attach(struct device *parent, str
>
> /*
>* AMD Bolton matches PCI_PRODUCT_AMD_HUDSON2_SMB but
> - * uses old register layout. Therefor check PCI_REVISION.
> + * uses old register layout. Therefore check PCI_REVISION.
>*/
> if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_AMD &&
> ((PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_HUDSON2_SMB &&
> @@ -170,6 +175,7 @@ piixpm_attach(struct device *parent, str
> AMDFCH41_PM_DECODE_EN);
> val = bus_space_read_1(sc->sc_iot, ioh, 1);
> smb0en = val & AMDFCH41_SMBUS_EN;
> + wdten = val & AMDFCH41_WDT_EN;
>
> bus_space_write_1(sc->sc_iot, ioh, 0,
> AMDFCH41_PM_DECODE_EN + 1);
> @@ -282,7 +288,59 @@ piixpm_attach(struct device *parent, str
> config_found(self, , iicbus_print);
> }
>
Why are you registering the watchdog late and not in the FCH specific
block above? Do other AMD SBx00 or KERNCZ chips support the watchdog in
the same way?
> + /* Register watchdog */
> + if (wdten && bus_space_map(sc->sc_memt, AMDFCH41_WDTREG_BASE,
> + AMDFCH41_WDTREG_SIZE, 0, >sc_wdt_mh) == 0) {
> + val = bus_space_read_1(sc->sc_memt, sc->sc_wdt_mh,
> + AMDFCH41_WDTREG_CTL);
> + if (val & AMDFCH41_WDTREG_CTL_FIRED) {
> + printf("%s watchdog caused previous restart\n",
> + sc->sc_dev.dv_xname);
> + bus_space_write_1(sc->sc_memt, sc->sc_wdt_mh,
> + AMDFCH41_WDTREG_CTL,
> + val | AMDFCH41_WDTREG_CTL_FIRED);
> + }
> +
> + if (val & AMDFCH41_WDTREG_CTL_DISABLED)
> + printf("%s watchdog disabled\n", sc->sc_dev.dv_xname);
> + else {
> + printf("%s watchdog found\n", sc->sc_dev.dv_xname);
The printf used here are non standard. Ideally this printing is folded
into the attach line of piixpm(4), e.g:
piixpm0 at pci0 dev 20 function 0 "AMD Hudson-2 SMBus" rev 0x42: SMI, watchdog
Same for the 'watchdog caused previous restart'. I think the common idiom
is to print ', watchdog' and ', reboot on timeout' for the two cases.
Also move the if (val & AMDFCH41_WDTREG_CTL_FIRED) check after
if (val & AMDFCH41_WDTREG_CTL_DISABLED)
> +
> + /* Set 1 second counter period */
> + bus_space_write_1(sc->sc_iot, sc->sc_sb800_ioh, 0,
> + AMDFCH41_PM_DECODE_EN + 3);
> + val = bus_space_read_1(sc->sc_iot, sc->sc_sb800_ioh, 1);
> + val = (val & ~AMDFCH41_WDT_MASK) | AMDFCH41_WDT_1S;
> + bus_space_write_1(sc->sc_iot, sc->sc_sb800_ioh, 1, val);
> +
> + wdog_register(piixpm_wdt_cb, sc);
> + }
> + }
> +
> return;
> +}
> +
> +int
> +piixpm_wdt_cb(void *arg, int period)
> +{
> + struct piixpm_softc *sc = (struct piixpm_softc *)arg;
> + u_int16_t val;
> +
> + val =
Re: PT_ATTACH wait(2) and reparent
On Tue, Feb 11, 2020 at 02:03:40PM +0100, Martin Pieuchot wrote:
> On 06/02/20(Thu) 12:08, Martin Pieuchot wrote:
> > As exposed recently via the t_ptrace regression and some make changes an
> > exit status might reported twice to its parent via wait(2).
> >
> > The diff below fixes that by making sure we do not re-parent a child to
> > the same parent.
> >
> > With it the above mentioned regression as well as the ptrace one that
> > I'm porting from FreeBSD pass.
> >
> > ok?
>
> Anyone?
>
> This fix is straightforward: there's no need to give the child back to
> the old parent if we *are* the old parent 8)
>
> > Index: kern/kern_exit.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_exit.c,v
> > retrieving revision 1.182
> > diff -u -p -r1.182 kern_exit.c
> > --- kern/kern_exit.c19 Dec 2019 17:40:10 - 1.182
> > +++ kern/kern_exit.c6 Feb 2020 11:02:01 -
> > @@ -584,7 +584,8 @@ proc_finish_wait(struct proc *waiter, st
> > * we need to give it back to the old parent.
> > */
> > pr = p->p_p;
> > - if (pr->ps_oppid && (tr = prfind(pr->ps_oppid))) {
> > + if (pr->ps_oppid != 0 && (pr->ps_oppid != pr->ps_pptr->ps_pid) &&
> > + (tr = prfind(tr->ps_oppid))) {
> > atomic_clearbits_int(>ps_flags, PS_TRACED);
> > pr->ps_oppid = 0;
> > proc_reparent(pr, tr);
> >
>
OK claudio@
--
:wq Claudio
Re: Push KERNEL_LOCK() down in pgsigio() and selwakeup()
On 09/02/20(Sun) 16:40, Visa Hankala wrote: > [...] > In addition, > IPL_AUDIO is above IPL_MPFLOOR on some architectures. That's because audio interrupt handlers have been considered MP-safe, we now know they aren't 8)
Re: PT_ATTACH wait(2) and reparent
On 06/02/20(Thu) 12:08, Martin Pieuchot wrote:
> As exposed recently via the t_ptrace regression and some make changes an
> exit status might reported twice to its parent via wait(2).
>
> The diff below fixes that by making sure we do not re-parent a child to
> the same parent.
>
> With it the above mentioned regression as well as the ptrace one that
> I'm porting from FreeBSD pass.
>
> ok?
Anyone?
This fix is straightforward: there's no need to give the child back to
the old parent if we *are* the old parent 8)
> Index: kern/kern_exit.c
> ===
> RCS file: /cvs/src/sys/kern/kern_exit.c,v
> retrieving revision 1.182
> diff -u -p -r1.182 kern_exit.c
> --- kern/kern_exit.c 19 Dec 2019 17:40:10 - 1.182
> +++ kern/kern_exit.c 6 Feb 2020 11:02:01 -
> @@ -584,7 +584,8 @@ proc_finish_wait(struct proc *waiter, st
>* we need to give it back to the old parent.
>*/
> pr = p->p_p;
> - if (pr->ps_oppid && (tr = prfind(pr->ps_oppid))) {
> + if (pr->ps_oppid != 0 && (pr->ps_oppid != pr->ps_pptr->ps_pid) &&
> +(tr = prfind(tr->ps_oppid))) {
> atomic_clearbits_int(>ps_flags, PS_TRACED);
> pr->ps_oppid = 0;
> proc_reparent(pr, tr);
>
Re: setlocale() in cron
Hi, Jan Stary wrote on Mon, Feb 10, 2020 at 01:13:58PM +0100: > Why does cron(8) and crontab(1) need to setlocale()? Committed; thanks to millert@ for cross-checking. Ingo > Index: cron.c > === > RCS file: /cvs/src/usr.sbin/cron/cron.c,v > retrieving revision 1.77 > diff -u -p -r1.77 cron.c > --- cron.c23 Oct 2017 15:15:22 - 1.77 > +++ cron.c10 Feb 2020 12:12:13 - > @@ -28,7 +28,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -83,8 +82,6 @@ main(int argc, char *argv[]) > struct sigaction sact; > sigset_t blocked, omask; > struct group *grp; > - > - setlocale(LC_ALL, ""); > > setvbuf(stdout, NULL, _IOLBF, 0); > setvbuf(stderr, NULL, _IOLBF, 0); > Index: crontab.c > === > RCS file: /cvs/src/usr.sbin/cron/crontab.c,v > retrieving revision 1.93 > diff -u -p -r1.93 crontab.c > --- crontab.c 28 Jun 2019 13:32:47 - 1.93 > +++ crontab.c 10 Feb 2020 12:12:13 - > @@ -26,7 +26,6 @@ > #include > #include > #include > -#include > #include > #include > #include > @@ -92,7 +91,6 @@ main(int argc, char *argv[]) > user_gid = getgid(); > crontab_gid = getegid(); > > - setlocale(LC_ALL, ""); > openlog(__progname, LOG_PID, LOG_CRON); > > setvbuf(stderr, NULL, _IOLBF, 0);
Re: iwm: work around missing Tx completion interrupts
On Mon, Feb 10, 2020 at 01:14:25PM +0100, Mark Kettenis wrote: > Stefan Sperling schreef op 2020-02-06 12:45: > > At 36c3 I noticed roaming failures with iwm(4) where we would get stuck > > trying to roam to a different AP. Debugging this with bluhm@ we found > > that the reason it gets stuck is a non-zero refcount on the ic_bss node. > > > > When roaming, we wait for this reference count to hit zero before > > switching > > the new AP. A non-zero reference count implies that the driver still has > > outstanding frames destined for the old AP queued to hardware. > > What we observed was that the reference count never went back to zero > > so roaming never completed and no further data frames could be sent. > > ifconfig iwm0 down/up was required to get the interface working again. > > > > iwm(4) decrements the refcount whenever hardware signals Tx completion > > for a frame at Tx queue index 'N'. We observed that we sometimes get an > > interrupt for frame 'N - 2' followed by an interrupt for frame 'N', > > with no interrupt being received for frame 'N - 1'. > > I don't really know how the rings work on this hardware, but coalescing > interrupts like that doesn't sound unreasonable. Interrupt coalescing is indeed enabled so it could be related to that. I don't know how it is supposed to work either. We will never know for sure until somebody leaks datasheets. You could be correct that "missed Tx completion" is what coalescing looks like for individually transmitted frames. I would expect coalescing to signal one interrupt with multiple 'packets', which contain firmware command responses and/or 802.11 frames, delivered for processing by the driver. But that's just a guess based on how interrupts behave when receiving frames. The proposed fix is about Tx. Since we do not yet aggregrate on Tx it seems reasonable to assume that each frame will be completed separately which is what happens virtually 99.9% of the time. It is also possible that the amount of frames in the air at 36c3 triggered errors in the firmware or hardware that lead to the symptoms we observed.
Re: patch: Enable dock audio on Thinkpad dock (Thinkpad L460)
On Wednesday, January 8, 2020, Abel Abraham Camarillo Ojeda < acam...@verlet.org> wrote: > > > On Mon, Dec 30, 2019 at 1:24 PM Abel Abraham Camarillo Ojeda < > acam...@verlet.org> wrote: > >> The following enables audio via the dock station port in my thinkpad L460. >> But, anyone knows if its possible to automatically disable the laptop >> speaker >> when I plug in the audio port in the dock? it doesn't appear to have a >> *_sense, >> ideas? >> >> this also enables the annoying beep (echo -e "\a"; in console) >> >> patch inline and attached: >> > > Hi, comments, oks? > Anyone? regards > > Thanks > > >> Index: azalia_codec.c >> === >> RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v >> retrieving revision 1.178 >> diff -u -p -r1.178 azalia_codec.c >> --- azalia_codec.c 14 Oct 2019 02:04:35 - 1.178 >> +++ azalia_codec.c 30 Dec 2019 19:06:16 - >> @@ -159,6 +159,17 @@ azalia_codec_init_vtbl(codec_t *this) >> this->subid == 0x503c17aa) >> this->qrks |= AZ_QRK_WID_TPDOCK2; >> break; >> + case 0x10ec0293: >> + this->name = "Realtek ALC293"; >> + this->qrks |= AZ_QRK_WID_CDIN_1C | AZ_QRK_WID_BEEP_1D; >> + >> + /* >> +* Enable dock audio on Thinkpad docks >> +* 0x17aa : 0x5051 = Thinkpad L460 >> +*/ >> + if (this->subid == 0x505117aa) >> + this->qrks |= AZ_QRK_WID_TPDOCK2; >> + break; >> case 0x10ec0298: >> this->name = "Realtek ALC298"; >> if (this->subid == 0x320019e5 || >> >> mixerctl diff: >> >> --- tmp/mixerctl_orig Mon Dec 30 12:08:15 2019 >> +++ tmp/mixerctl_patch Mon Dec 30 12:06:22 2019 >> @@ -1,35 +1,41 @@ >> -inputs.dac-0:1=126,126 >> -inputs.dac-2:3=126,126 >> +inputs.dac-0:1=174,174 >> +inputs.dac-2:3=174,174 >> inputs.mic2=85,85 >> inputs.mic=85,85 >> inputs.mix2_source=dac-2:3,mix >> inputs.mix3_source=dac-0:1,mix >> inputs.mix_mic2=120,120 >> -inputs.mix_source=mic2 >> +inputs.mix_source=spkr3,mic2 >> +inputs.mix_spkr3=120,120 >> +inputs.spkr3=85,85 >> outputs.hp_boost=off >> outputs.hp_eapd=on >> outputs.hp_mute=off >> outputs.hp_sense=unplugged >> outputs.hp_source=mix3 >> outputs.master.mute=off >> -outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp >> -outputs.master=126,126 >> +outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp,spkr2 >> +outputs.master=190,190 >> outputs.mic2_dir=input-vr80 >> outputs.mic2_sense=unplugged >> +outputs.spkr2_boost=off >> +outputs.spkr2_eapd=on >> +outputs.spkr2_mute=off >> +outputs.spkr2_source=mix2 >> outputs.spkr_eapd=on >> outputs.spkr_mute=off >> outputs.spkr_muters=hp >> outputs.spkr_source=mix2 >> record.adc-0:1=124,124 >> record.adc-0:1_mute=off >> record.adc-0:1_source=mic >> record.adc-2:3=124,124 >> record.adc-2:3_mute=off >> -record.adc-2:3_source=mic2 >> +record.adc-2:3_source=spkr3 >> record.adc-4:5=124,124 >> record.adc-4:5_mute=off >> -record.adc-4:5_source=mic2 >> +record.adc-4:5_source=spkr3 >> record.enable=sysctl >> record.volume.mute=off >> record.volume.slaves=adc-0:1,adc-2:3,adc-4:5 >> record.volume=124,124 >> >> dmesg: >> >> OpenBSD 6.6-current (GENERIC.MP) #9: Mon Dec 30 13:01:52 CST 2019 >> acam...@merced.00z.us:/usr/obj/sys/arch/amd64/compile/GENERIC.MP >> real mem = 17028538368 (16239MB) >> avail mem = 16491659264 (15727MB) >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root >> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xd705d000 (63 entries) >> bios0: vendor LENOVO version "R08ET64W (1.38 )" date 05/02/2019 >> bios0: LENOVO 20FVA09400 >> acpi0 at bios0: ACPI 5.0 >> acpi0: sleep states S0 S3 S4 S5 >> acpi0: tables DSDT FACP UEFI SSDT ECDT HPET APIC MCFG SSDT DBGP DBG2 BOOT >> BATB SLIC SSDT SSDT MSDM DMAR ASF! FPDT UEFI >> acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) XHCI(S3) >> acpitimer0 at acpi0: 3579545 Hz, 24 bits >> acpiec0 at acpi0 >> acpihpet0 at acpi0: 2399 Hz >> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >> cpu0 at mainbus0: apid 0 (boot processor) >> cpu0: Intel(R) Core(TM) i3-6100U CPU @ 2.30GHz, 2195.54 MHz, 06-4e-03 >> 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,SDBG, >> FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT, >> DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP, >> LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX, >> BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX, >> SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF, >> SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN >> 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 24MHz >> cpu0:
