Hi,
It seems to me that src/distrib/notes/octeon/hardware is out-of-sync
with www/octeon.html and some models are missing. The following patch
attempts to update src/distrib/notes/octeon/hardware so it contains the
same device list as octeon.html.
There is one thing I'm unsure about, in
On 10 Aug 2021, at 11:26, ropers wrote:
> Would this also preserve the LED status (Num, Scroll Lock, etc.)?
Nope, only encoding, custom keymap (if any), bell and repeat. LEDs have
escaped my attention because they are handled by lower level drivers
(pckbd, ukbd, etc), not wskbd. Preserving LEDs
Hi,
> ok gerhard@
Thanks for reporting, for the initial patch, and for checking the
final one. This now committed.
Yours,
Ingo
>> Index: date.c
>> ===
>> RCS file: /cvs/src/bin/date/date.c,v
>> retrieving revision 1.56
>> diff
Following snmpd, remove the public default community and move to snmpv3
by default. This is also what net-snmp does. I originally chose this
default because that's what snmpctl did and it allowed for easier
interoperability with snmpd(8).
Now that snmpd(8) moved on, so should snmp(1).
OK?
Probably not something many people will run into.
$ snmp mibtree -q
snmp: unknown option -- q
usage: snmp mibtree[-O fnS] [oid ...]
$ ./obj/snmp mibtree -q
snmp: unknown option -- q
usage: snmp mibtree [-O fnS] [oid ...]
mibtree is the only one not setting the usecommonopt.
OK?
martijn@
Hi,
Here a diff for www page: errata69
Typo errors
Right?
Index: errata69.html
===
RCS file: /cvs/www/errata69.html,v
retrieving revision 1.18
diff -u -r1.18 errata69.html
--- errata69.html 10 Aug 2021 18:48:57 -
On Wed, 2021-08-11 at 18:50 +0200, Ingo Schwarze wrote:
> Hi,
>
> in its current state, the editline(3) library is completely unfit
> to work with non-blocking I/O. Neither the API nor the implementation
> are even designed for that purpose.
>
> I do have some candidate ideas to minimally
On Wed, 2021-08-11 at 18:59 +0100, Stuart Henderson wrote:
> On 2021/08/11 19:34, Martijn van Duren wrote:
> > On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote:
> > > On 2021/08/11 16:35, Martijn van Duren wrote:
> > > > Following snmpd, remove the public default community and move to
Hi,
in its current state, the editline(3) library is completely unfit
to work with non-blocking I/O. Neither the API nor the implementation
are even designed for that purpose.
I do have some candidate ideas to minimally extend the API - without
adding any new functions - to also work with
On 2021/08/11 16:35, Martijn van Duren wrote:
> Following snmpd, remove the public default community and move to snmpv3
> by default. This is also what net-snmp does. I originally chose this
> default because that's what snmpctl did and it allowed for easier
> interoperability with snmpd(8).
v3
On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote:
> On 2021/08/11 16:35, Martijn van Duren wrote:
> > Following snmpd, remove the public default community and move to snmpv3
> > by default. This is also what net-snmp does. I originally chose this
> > default because that's what snmpctl
On 2021/08/11 19:34, Martijn van Duren wrote:
> On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote:
> > On 2021/08/11 16:35, Martijn van Duren wrote:
> > > Following snmpd, remove the public default community and move to snmpv3
> > > by default. This is also what net-snmp does. I originally
On Wed, 2021-08-11 at 18:59 +0100, Stuart Henderson wrote:
> On 2021/08/11 19:34, Martijn van Duren wrote:
> > On Wed, 2021-08-11 at 18:03 +0100, Stuart Henderson wrote:
> > > On 2021/08/11 16:35, Martijn van Duren wrote:
> > > > Following snmpd, remove the public default community and move to
On Thu, Aug 12, 2021 at 03:01:37PM +1000, Jonathan Gray wrote:
> On Thu, Aug 12, 2021 at 06:44:51AM +0200, Theo Buehler wrote:
> > There doesn't seem to be a good reason for omitting the newlines here.
> > If those are ever hit, it will look odd. Am I missing something?
>
> See the i386
Hello,
On Mon, Aug 09, 2021 at 01:17:27PM +0200, Alexander Bluhm wrote:
> On Fri, Aug 06, 2021 at 05:22:18PM +0200, Alexandr Nedvedicky wrote:
> > > Although I did not obverve it, there seems to be the same problem
> > > for snd_wl1 and rcv_up. For rcv_up I copied the comparison with
> > >
On Wed, 11 Aug 2021 18:50:10 +0200, Ingo Schwarze wrote:
> in its current state, the editline(3) library is completely unfit
> to work with non-blocking I/O. Neither the API nor the implementation
> are even designed for that purpose.
>
> Consequently, i propose that we document the facts up
There doesn't seem to be a good reason for omitting the newlines here.
If those are ever hit, it will look odd. Am I missing something?
Index: est.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/est.c,v
retrieving revision 1.40
diff -u
On Wed, Aug 11, 2021 at 03:44:33PM +0200, Ingo Schwarze wrote:
> Hi,
>
> > ok gerhard@
>
> Thanks for reporting, for the initial patch, and for checking the
> final one. This now committed.
>
> Yours,
> Ingo
Thanks to all for working together and getting this fixed.
Bryan
On Thu, Aug 12, 2021 at 06:44:51AM +0200, Theo Buehler wrote:
> There doesn't seem to be a good reason for omitting the newlines here.
> If those are ever hit, it will look odd. Am I missing something?
See the i386 p3_get_bus_clock() which is where this came from.
i386 prints the msr value and a
19 matches
Mail list logo
