Re: sign of char on arm64

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

disable hw vlan tagging support in ix(4)

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

Re: iked, don't return NULL in print_host

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 =

relayd and PUT

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

Re: Removal of PIM support in kernel

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

Re: relayd and PUT

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

sign of char on arm64

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

Re: sign of char on arm64

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

Re: OpenBSD OpenCL 2.x support perspective

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

faq14.html minor patch

$ 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

ksh: stop emitting carriage return twice

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

Re: sign of char on arm64

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

Re: remove one bug, add three

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

Re: sign of char on arm64

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 > >

Re: relayd and PUT

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. >

Re: faq14.html minor patch

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

syspatch / reorder_kernel

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

Re: syspatch / reorder_kernel

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

remove one bug, add three

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

Re: remove one bug, add three

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

Re: remove one bug, add three

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

net80211: set 'any channel' pointer to NULL

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:

Re: OpenBSD OpenCL 2.x support perspective

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

Re: iked, don't return NULL in print_host

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 =

Re: iked, don't return NULL in print_host

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 'À',

net80211: only trigger bgscan in RUN state

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:

net80211: panic if node's channel pointer is bogus

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:

Re: remove one bug, add three

> 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

Re: remove one bug, add three

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