Hi,
Upon uhidev detach, free the list of sub devices.
Comments? OK?
diff --git sys/dev/usb/uhidev.c sys/dev/usb/uhidev.c
index 014dc052c1c..5fe2f702e21 100644
--- sys/dev/usb/uhidev.c
+++ sys/dev/usb/uhidev.c
@@ -451,6 +451,7 @@ uhidev_detach(struct device *self, int flags)
sc->
Hi,
In an attempt to fix a bug related to upd(4) I discovered that the
pseudo report id UHIDEV_CLAIM_MULTIPLE_REPORTID is conflicting with an
actual report id. The previous fix, reverted by now, avoided the
conflict by incrementing the pseudo report id was not a good idea
since a report id is expec
Hi,
On Tue, 2 Nov 2021 07:03:43 +
Jason McIntyre wrote:
> On Tue, Nov 02, 2021 at 12:02:07PM +0900, YASUOKA Masahiko wrote:
>> I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits.
>>
>> sbin/ipsecctl/ike.c:
>> 201 case ENCXF_AES:
>> 202
On Tue, 2 Nov 2021, Theo de Raadt wrote:
> Paul de Weerd wrote:
>
> > A recent commit by Theo changed the hw.perfpolicy behavior to always
> > run at full speed when AC power is on. This means that my workstation
> > (and servers, once I upgrade them) now consumes significantly more
> > power,
I am sure swabips died before you were born.
Klemens Nanni wrote:
> No idea what it was supposed to do back then; cvs blame points at
>
> revision 1.19
> date: 1998/09/03 06:24:18; author: jason; state: Exp; lines: +502
> -38;
> o OpenBSD gets if_media support (from NetBS
No idea what it was supposed to do back then; cvs blame points at
revision 1.19
date: 1998/09/03 06:24:18; author: jason; state: Exp; lines: +502
-38;
o OpenBSD gets if_media support (from NetBSD)
o rework/simplify if_xl to use
OK?
Index: ifconfig.c
On Tue, 02 Nov 2021 22:22:16 -, Klemens Nanni wrote:
> I looked at
> I had to look at the source to be sure what the three different return
> codes 0, 1 and 2 would mean and if there was more to it.
>
> Depending on the error, config(8) exists 1 or 2. 0 on success as usual.
OK millert@
-
I looked at
I had to look at the source to be sure what the three different return
codes 0, 1 and 2 would mean and if there was more to it.
Depending on the error, config(8) exists 1 or 2. 0 on success as usual.
OK?
Index: config.8
==
On Tue, Nov 02, 2021 at 06:38:24PM +0100, Stefan Sperling wrote:
> It looks like bwfm(4) does support WEP but the C_WEP capability is missing
> from ic_caps so net80211 believes WEP was not supported by this driver.
>
> I don't think we have any supported wifi device that does not support WEP.
> E
Solene Rapenne wrote:
> On mardi 2 novembre 2021 19:19:03 CET, Paul de Weerd wrote:
> > A recent commit by Theo changed the hw.perfpolicy behavior to always
> > run at full speed when AC power is on. This means that my workstation
> > (and servers, once I upgrade them) now consumes significantly
> Date: Tue, 2 Nov 2021 19:19:03 +0100
> From: Paul de Weerd
>
> A recent commit by Theo changed the hw.perfpolicy behavior to always
> run at full speed when AC power is on. This means that my workstation
> (and servers, once I upgrade them) now consumes significantly more
> power, even though
Paul de Weerd wrote:
> A recent commit by Theo changed the hw.perfpolicy behavior to always
> run at full speed when AC power is on. This means that my workstation
> (and servers, once I upgrade them) now consumes significantly more
> power, even though they usually idle.
Did you measure how mu
Paul de Weerd wrote:
> A recent commit by Theo changed the hw.perfpolicy behavior to always
> run at full speed when AC power is on. This means that my workstation
> (and servers, once I upgrade them) now consumes significantly more
> power, even though they usually idle.
Did you measure how mu
A recent commit by Theo changed the hw.perfpolicy behavior to always
run at full speed when AC power is on. This means that my workstation
(and servers, once I upgrade them) now consumes significantly more
power, even though they usually idle.
[weerd@pom] $ sysctl hw.{vendor,product,perfpolicy,se
On Tue, Nov 02, 2021 at 11:30:11AM -0600, Theo de Raadt wrote:
> Klemens Nanni wrote:
>
> > At least bwfm(4) does not support WEP:
> >
> > # ifconfig bwfm0 nwkey 12345
> > ifconfig: SIOCS80211NWKEY: Operation not supported by device
> > # echo $?
> > 0
> >
> > ifconfig
On Tue, Nov 02, 2021 at 05:26:17PM +, Klemens Nanni wrote:
> At least bwfm(4) does not support WEP:
>
> # ifconfig bwfm0 nwkey 12345
> ifconfig: SIOCS80211NWKEY: Operation not supported by device
> # echo $?
> 0
>
> ifconfig(8) must return non-zero in this ca
On Tue, Nov 02, 2021 at 05:26:17PM +, Klemens Nanni wrote:
> At least bwfm(4) does not support WEP:
>
> # ifconfig bwfm0 nwkey 12345
> ifconfig: SIOCS80211NWKEY: Operation not supported by device
> # echo $?
> 0
>
> ifconfig(8) must return non-zero in this ca
Klemens Nanni wrote:
> At least bwfm(4) does not support WEP:
>
> # ifconfig bwfm0 nwkey 12345
> ifconfig: SIOCS80211NWKEY: Operation not supported by device
> # echo $?
> 0
>
> ifconfig(8) must return non-zero in this case.
>
> This is relevant for an upcomin
I've recently started seeing a number of flaps with ospfd/ospf6d
with invalid seq nums / "seq num mismatch, bad flags" logged.
Not quite sure what's going yet as they must be occurring on
various local switched segments on one nic and also on ethernet
wan circuits direct to router on a separate pci
At least bwfm(4) does not support WEP:
# ifconfig bwfm0 nwkey 12345
ifconfig: SIOCS80211NWKEY: Operation not supported by device
# echo $?
0
ifconfig(8) must return non-zero in this case.
This is relevant for an upcoming installer fix, but also worth its
On Mon, Nov 01, 2021 at 12:56:26PM +0100, Stefan Sperling wrote:
> This patch adds 802.11n 40MHz support to the iwn(4) driver.
>
> This driver supports many different devices. Please try to be precise
> about which device you have tested so I can maintain a record of our
> test coverage.
Here is
On Tue, Nov 02, 2021 at 08:12:00AM -0600, Todd C. Miller wrote:
> On Mon, 01 Nov 2021 21:04:54 -0500, Scott Cheloha wrote:
>
> > Yes it would be simpler. However I didn't want to start changing the
> > input -- which we currently don't do -- without discussing it.
> >
> > The standard says we sho
Hi Todd,
Todd C. Miller wrote on Tue, Nov 02, 2021 at 08:20:47AM -0600:
> uniq appeared in research Unix version 3.
OK schwarze@.
If - like in this case - the indicated release is the first one in any
system to ever contain the feature, and not just the first one among
the direct ancestors of O
Hi,
Todd C. Miller wrote on Tue, Nov 02, 2021 at 08:12:00AM -0600:
> On Mon, 01 Nov 2021 21:04:54 -0500, Scott Cheloha wrote:
>> Yes it would be simpler. However I didn't want to start changing the
>> input -- which we currently don't do -- without discussing it.
>>
>> The standard says we shoul
uniq appeared in research Unix version 3.
- todd
Index: usr.bin/uniq/uniq.1
===
RCS file: /cvs/src/usr.bin/uniq/uniq.1,v
retrieving revision 1.21
diff -u -p -u -r1.21 uniq.1
--- usr.bin/uniq/uniq.1 23 Dec 2017 00:52:33 - 1.
Actually, the historic version of uniq used static 1000 byte buffers.
Solaris 2.6 includes a version that realloc()s the buffer but I
don't know when exactly that behavior was added.
- todd
> Date: Tue, 2 Nov 2021 15:05:46 +0100
> From: Frederic Cambus
>
> On Fri, Oct 29, 2021 at 06:20:07PM -0400, Brad Smith wrote:
>
> > > Therefore, here is a diff to enable spleen16x32 and spleen32x64 on riscv64
> > > for GENERIC kernels, like we do on amd64, arm64, armv7, and i386.
> > >
> > > C
On Mon, 01 Nov 2021 21:04:54 -0500, Scott Cheloha wrote:
> Yes it would be simpler. However I didn't want to start changing the
> input -- which we currently don't do -- without discussing it.
>
> The standard says we should "write one copy of each input line on the
> output." So, if we are being
On Fri, Oct 29, 2021 at 06:20:07PM -0400, Brad Smith wrote:
> > Therefore, here is a diff to enable spleen16x32 and spleen32x64 on riscv64
> > for GENERIC kernels, like we do on amd64, arm64, armv7, and i386.
> >
> > Comments? OK?
>
> Sounds like this should be enabled on powerpc64 too?
I got a
On Tue, Oct 26, 2021 at 01:24:30PM +, Klemens Nanni wrote:
> Mentioning `route nameserver' relevance made it obvious that the
> `preference' block duplicates lots of information and I despise adding
> to that.
route(8) is fixed/polished, unwind.conf(5) still lacks behind.
> So rearrange the l
On Tue, Nov 02, 2021 at 12:02:07PM +0900, YASUOKA Masahiko wrote:
> I'd like to clarify "aes" in ipsec.conf accepts 128:256 bits.
>
> sbin/ipsecctl/ike.c:
> 201 case ENCXF_AES:
> 202 enc_alg = "AES";
> 203
31 matches
Mail list logo
