On Tue, Dec 12, 2017 at 09:53:09PM -0600, Edgar Pettijohn wrote:
> $ diff -u faq14.html faq14.html.orig
>
>
fixed, thanks. could you please do diffs the other way around? it t
On Wed, Dec 13, 2017 at 12:25:39AM +, Rivo Nurges wrote:
> Hi!
>
> If you http PUT a "big" file through relayd, server<>relay read side
> will eventually get a EVBUFFER_TIMEOUT. Nothing comes back from the
> server until the PUT is done. I disabled server read timeouts for PUT
> requests.
>
>
Hi again,
I would like to mention that the committed patch for the trivial bugs
that I reported is not even complete: there are still two problematic
instructions literally one line above the one that did get fixed
correctly (and I actually find this mildly amusing, especially
considering the last
First, thanks to all people that answered, off-list or not.
On Tue, Dec 12, 2017 at 10:01:14PM +0100, Jeremie Courreges-Anglas wrote:
> On Tue, Dec 12 2017, Sebastien Marie wrote:
>
> [...]
>
> > But I would like confirmation because for all BSD where I have the
> > information, I always have a
$ diff -u faq14.html faq14.html.orig
--- faq14.html Tue Dec 12 21:50:14 2017
+++ faq14.html.orig Tue Dec 12 21:50:03 2017
@@ -391,7 +391,7 @@
Here is an example /etc/fstab
Hi!
Without text mangling this time...
Rivo
Index: usr.sbin/relayd/relay.c
===
RCS file: /cvs/src/usr.sbin/relayd/relay.c,v
retrieving revision 1.236
diff -u -p -r1.236 relay.c
--- usr.sbin/relayd/relay.c 28 Nov 2017 01:51:47 -0
Thanks for the info!
Forgot about few such examples, such as sources don't signal so there is a
timeout counter for (s,g) that need to be monitored, traffic utilization
that might trigger SFP and I guess many more
On Mon, Dec 11, 2017 at 11:33 PM, Claudio Jeker
wrote:
> On Tue, Dec 12, 201
Hi!
If you http PUT a "big" file through relayd, server<>relay read side
will eventually get a EVBUFFER_TIMEOUT. Nothing comes back from the
server until the PUT is done. I disabled server read timeouts for PUT
requests.
While trying to fix the issue I managed to trigger another problem. For
HTTP
On Tue, Dec 12 2017, Patrick Wildt wrote:
> On Tue, Dec 12, 2017 at 03:32:50PM +0100, Patrick Wildt wrote:
>> On Wed, Nov 29, 2017 at 07:50:21PM +0100, Claudio Jeker wrote:
>> > More or less. It seems that msg_local is garbage:
>> > $3 = {msg_data = 0x1b4e541fa4c0, msg_offset = 0, msg_local = {
>>
im still looking at vlan performance problems, as discussed by mpi@
at http://www.grenadille.net/post/2017/02/13/What-happened-to-my-vlan.
recently it occurred to me that we're making an implicit assumption
that having the chip handle the injection of vlan tags has zero
cost, and that all the loss
On Tue, Dec 12 2017, Sebastien Marie wrote:
[...]
> But I would like confirmation because for all BSD where I have the
> information, I always have a signed char (aarch64-freebsd,
> powerpc-netbsd, arm-netbsd, ...), except arm64 on OpenBSD.
>
> Is it expected ?
I would certainly not expect NetB
On Tue, Dec 12, 2017 at 10:44 AM, Sebastien Marie wrote:
>
> While working on porting rust to arm64, I found something that seems a
> bit odd for me, and I would like to have confirmation that it is
> expected: the signess of char on arm64.
...
> But I would like confirmation because for all BSD
Hi,
Here's a little nit that has been bugging me while writing tests for
Emacs editing mode in ksh. Since the map-CR-to-NL (ONLCR) output mode is
enabled by default on the tty, emitting a newline gets translated into a
carriage return (CR) followed by newline (NL). Parts of the Emacs
related code e
It is an artifact of the processor, not the operating system.
As a general rule (at least in the old days) this had to do with
how condition codes are updated, based upon each operation or
upon extra specific instructions... and this looseness fell out
of that.
> While working on porting rust to
Hi,
While working on porting rust to arm64, I found something that seems a
bit odd for me, and I would like to have confirmation that it is
expected: the signess of char on arm64.
In order to test the sign of 'char' (unsigned or signed), I use the
following C program:
$ cat sign-of-char.c
#inclu
Thanks Paul for you answer.
Still no answer about OpenCL kernel integration and tools for Linux but
not OpenBSD.
Could you advise how to use the same computation power as for Linux in
OpenBSD using OpenCL.
Thanks.
On 12/12/2017 11:39 AM, Paul Irofti wrote:
> On Tue, Dec 12, 2017 at 10:18:51AM +
On 12/12/17 15:02, kshe wrote:
> On Tue, 12 Dec 2017 12:44:03 +, Todd C. Miller wrote:
>> On Tue, 12 Dec 2017 11:57:58 +, kshe wrote:
>>
>>> Perhaps the worst part of all this, though, is how the change of
>>> behaviour, which made sed fail hard where it previously handled input in
>>> a pe
> Following the same kind of reasoning, I think OpenBSD should also
> modify the `echo' command to fail if given an argument like `-E', as
> its behaviour in that case differs from system to system, hence the
> current implementation is likewise "just creating a trap for the
> user", and surely thi
A node's channel pointer had better be pointing to a valid channel or ANYC.
Otherwise something has gone seriously wrong and there is no good
reason to continue running the program.
Index: ieee80211.c
===
RCS file: /cvs/src/sys/net80
The checkrssi crash on bugs@ exposed another issue:
We should only try to trigger a background scan while in RUN state.
The != SCAN condition was inherited from old code. It seems what
was really intended was > SCAN because it makes no sense to
update RSSI information in INIT state.
Index: ieee8
On Tue, Dec 12, 2017 at 03:32:50PM +0100, Patrick Wildt wrote:
> On Wed, Nov 29, 2017 at 07:50:21PM +0100, Claudio Jeker wrote:
> > More or less. It seems that msg_local is garbage:
> > $3 = {msg_data = 0x1b4e541fa4c0, msg_offset = 0, msg_local = {
> > ss_len = 128 '\200', ss_family = 192 'À',
On Wed, Nov 29, 2017 at 07:50:21PM +0100, Claudio Jeker wrote:
> More or less. It seems that msg_local is garbage:
> $3 = {msg_data = 0x1b4e541fa4c0, msg_offset = 0, msg_local = {
> ss_len = 128 '\200', ss_family = 192 'À',
> __ss_pad1 = 0x7f7da8c2 "Ì]\001", __ss_pad2 = 30024042514159,
If we're going to crash in the wireless stack because of a bogus
channel pointer, let that pointer be a NULL pointer to avoid
head-scratching every time someone runs into this.
Index: ieee80211_var.h
===
RCS file: /cvs/src/sys/net8021
On Tue, 12 Dec 2017 12:44:03 +, Todd C. Miller wrote:
> On Tue, 12 Dec 2017 11:57:58 +, kshe wrote:
>
> > Perhaps the worst part of all this, though, is how the change of
> > behaviour, which made sed fail hard where it previously handled input in
> > a perfectly defined and reasonable way,
On Tue, 12 Dec 2017 11:57:58 +, kshe wrote:
> Perhaps the worst part of all this, though, is how the change of
> behaviour, which made sed fail hard where it previously handled input in
> a perfectly defined and reasonable way, was apparently approved because
> "implementations do vary in how
On Tue, Dec 12, 2017 at 11:56:20AM +, Stuart Henderson wrote:
> Quick thought (I don't have time to look further now but I just noticed
> this and wanted to get it down before I forget).
>
> I just upgraded an Alix to 6.2 release and then wanted to run syspatch
> afterwards. I logged in just a
Hi,
While attempting to fix one bug, the recent commit to sed regarding the
`y' command has introduced three new problems.
The first one is that it happily uses a plain `char' as the index for
the array `check', which obviously leads to havoc as soon as one tries
to translate non-ASCII characters
Quick thought (I don't have time to look further now but I just noticed
this and wanted to get it down before I forget).
I just upgraded an Alix to 6.2 release and then wanted to run syspatch
afterwards. I logged in just after ssh had started, so reorder_kernel was
still running in the background
On Tue, Dec 12, 2017 at 10:18:51AM +0300, Denis wrote:
> Interesting in perspectives about OpenCL 2.x support in OpenBSD natively.
>
> Especially interesting in what does Theo think about it.
>
> Thanks
I am not Theo,
But as a former heavy OpenCL developer, my advice is to just use Windows
(or
29 matches
Mail list logo