Re: [patch] Fix device

On Wed, Jun 01, 2016 at 09:53:20PM -0300, Daniel Bolgheroni wrote: > Hi, > > between the 1.318 and 1.319 commits, a device was left unchanged, so fix > it. > fixed, thanks

Re: netcat service lookup

That's ok.. every newbie fucks that up the first time when sending out diffs. Those of us that commit generally speak only -current. Now you know :) > Oh, someone pointed the possible problem out to me: > I'm running OpenBSD 5.9 instead of current.

Re: netcat service lookup

Oh, someone pointed the possible problem out to me: I'm running OpenBSD 5.9 instead of current. Sorry. On Thu, Jun 2, 2016 at 3:58 AM, Andras Farkas wrote: >> Andras - your original diff does not apply to -current as mailed, and >> you also have a bug when the -v

Re: netcat service lookup

Andras - your original diff does not apply to -current as mailed, and you also have a bug when the -v option is used, because you end up putting port names in the portlist array instead of numbers and so -v doesn't work right. Try this instead: Thank you, I was trying to look for bugs and

Re: unsigned comparison issue in sys_mmap()?

Ingo Schwarze wrote: > Hi, > > when p->p_rlimit[RLIMIT_DATA].rlim_cur < ptoa(p->p_vmspace->vm_dused), > the following comparison fails because the subtraction wraps around > to huge positive values. > > I noticed this because i tried to do systematic testing of specific > malloc failure

unsigned comparison issue in sys_mmap()?

Hi, when p->p_rlimit[RLIMIT_DATA].rlim_cur < ptoa(p->p_vmspace->vm_dused), the following comparison fails because the subtraction wraps around to huge positive values. I noticed this because i tried to do systematic testing of specific malloc failure codepaths. But whenever i used setrlimit(2)

defer art table and node frees to tasks

if we traverse art tables and nodes via srps, this allows us to add sleeping srp_finalize calls before the pool_puts. ok? Index: art.c === RCS file: /cvs/src/sys/net/art.c,v retrieving revision 1.17 diff -u -p -r1.17 art.c --- art.c

[patch] Fix device

Hi, between the 1.318 and 1.319 commits, a device was left unchanged, so fix it. http://cvsweb.openbsd.org/cgi-bin/cvsweb/www/faq/faq14.html.diff?r1=1.318=1.319=h Index: faq14.html === RCS file: /cvs/www/faq/faq14.html,v retrieving

measure ndp expiries against time_uptime

this complements my diff to make arp use time_uptime for expiries too. the point is time_second can be skewed by clock adjustements while time_uptime is monotonic. this is mechanical. after this and arp go in i think i can get rid of ln_expire and simply populate the rtentry associated with this

Re: netcat service lookup

Bob Beck(b...@openbsd.org) on 2016.05.31 23:25:47 -0600: > Honestly, I care little about the incompatibility because we are > already different. > > However I do not think this is any "easier" - I never use > /etc/services because frankly I can't > predict what other non-openbsd systems will have

Re: dhclient reboot interval

Yes please. I played with lower values in the past too and saw no problems. And if we notice problems, we can fine tune it further. ok. Ted Unangst(t...@tedunangst.com) on 2016.06.01 15:37:53 -0400: > Is there a reason the reboot timeout is so long? > > Here's what I observe. I connect to one

dhclient reboot interval

Is there a reason the reboot timeout is so long? Here's what I observe. I connect to one network and get a lease. Later, I connect to a different network. dhclient then spends an annoyingly long time doing this: DHCPREQUEST on iwm0 to 255.255.255.255 DHCPREQUEST on iwm0 to 255.255.255.255

Re: bgpd: filter as path with operators

with feedback from florian, sthen and claudio: - i removed operators < <= > >= - i kept != and = for symmetry. - i thought about just using ! , but then it would be different from the prefix operators. Willing to change it if you want that. - i left the forth argument to aspath_match(), as its

Re: kdump small timespecs

Philip Guenther wrote: > On Wed, Jun 1, 2016 at 10:37 AM, Theo de Raadt > wrote: > >> Mark Kettenis wrote: > >> > I sympathise with the idea, but your implementation would still print > >> > "funny" times if your machine had been up for more than a day. > >> > >> The

Re: MBIM Patch (Round 2)

On Wed, Jun 1, 2016 at 8:34 PM, Stefan Sperling wrote: > On Wed, Jun 01, 2016 at 08:18:13PM +0200, David Coppa wrote: >> On Wed, Jun 1, 2016 at 6:11 PM, Stefan Sperling wrote: >> >> > I agree. And the driver can keep using the MBIM_ prefix for such macros >> >

Re: MBIM Patch (Round 2)

On Wed, Jun 01, 2016 at 08:35:39PM +0200, Gerhard Roth wrote: > Changing the name from 'mbim' to 'umbim' already took me serveral > hours because a simple sed(1) can't do the job. Don't have that > much lifetime left to go through this boredom once again. I spent many many hours renaming all the

Re: MBIM Patch (Round 2)

On 01.06.2016 20:28, Theo de Raadt wrote: As I said, we could still change the name of the interface to 'ubm' while keeping 'umbim' as the name of the driver. No, I don't understand the proposal. I think it should be ubm throughout, or I am threatening to rename ix(4) to a 8 character name.

Re: MBIM Patch (Round 2)

On Wed, Jun 01, 2016 at 08:18:13PM +0200, David Coppa wrote: > On Wed, Jun 1, 2016 at 6:11 PM, Stefan Sperling wrote: > > > I agree. And the driver can keep using the MBIM_ prefix for such macros > > even when we rename it to ubm. > > iirc, the chosen name for the new driver was

Re: MBIM Patch (Round 2)

On Wed, Jun 01, 2016 at 08:11:22PM +0200, Gerhard Roth wrote: > On 01.06.2016 17:32, Theo de Raadt wrote: > >>- renamed it from 'mbim' to 'umbim' > >>I tried 'ubm' as proposed by Theo but that felt weird. Esp. > >>when changing the prefixes of macros whose names were > >>

Re: kdump small timespecs

On Wed, Jun 1, 2016 at 10:37 AM, Theo de Raadt wrote: >> Mark Kettenis wrote: >> > I sympathise with the idea, but your implementation would still print >> > "funny" times if your machine had been up for more than a day. >> >> The perils of rebooting. I tested with an

Re: MBIM Patch (Round 2)

> As I said, we could still change the name of the interface to 'ubm' > while keeping 'umbim' as the name of the driver. No, I don't understand the proposal. I think it should be ubm throughout, or I am threatening to rename ix(4) to a 8 character name.

Re: MBIM Patch (Round 2)

On 01.06.2016 17:32, Theo de Raadt wrote: - renamed it from 'mbim' to 'umbim' I tried 'ubm' as proposed by Theo but that felt weird. Esp. when changing the prefixes of macros whose names were derived from the MBIM standard. I suggested that because ifconfig umbim0 ...

Re: MBIM Patch (Round 2)

On Wed, Jun 1, 2016 at 6:11 PM, Stefan Sperling wrote: > I agree. And the driver can keep using the MBIM_ prefix for such macros > even when we rename it to ubm. iirc, the chosen name for the new driver was "umb" (USB Mobile Broadband), not "ubm"... Has it changed again or it's

Re: continue in empty loops

On Wed, Jun 01, 2016 at 01:08:05PM -0400, Ted Unangst wrote: > I find this easier to read. My old eyes don't focus on the semicolon, which > makes me wonder what's supposed to be happening. Yes, please! ok natano@ > > > Index: pax/ar_io.c >

Re: kdump relative timestamps

ok Ted Unangst(t...@tedunangst.com) on 2016.06.01 13:41:01 -0400: > Relative timestamps are much easier to decipher than absolute, when attempting > to determine a program's behavior. Most of the time I care about how long > since the last time. However, if I grep the output, then I lose the

Re: iked: fix ipv6 address pool assignment

On 1 June 2016 at 17:46, Patrick Wildt wrote: > On Wed, Jun 01, 2016 at 03:47:45PM +0200, Mike Belopuhov wrote: >> On 1 June 2016 at 13:33, Patrick Wildt wrote: >> > Hi, >> > >> > The IPv6 address assignment was basically copied from the IPv4 >> > code.

kdump relative timestamps

Relative timestamps are much easier to decipher than absolute, when attempting to determine a program's behavior. Most of the time I care about how long since the last time. However, if I grep the output, then I lose the basis for relative times, and am back to doing large number substraction in

Re: kdump small timespecs

Mark Kettenis wrote: > I sympathise with the idea, but your implementation would still print > "funny" times if your machine had been up for more than a day. The perils of rebooting. I tested with an hour, then bumped to a day for margin. But really, I think even up to ten years would work. Any

Re: kdump small timespecs

> Mark Kettenis wrote: > > I sympathise with the idea, but your implementation would still print > > "funny" times if your machine had been up for more than a day. > > The perils of rebooting. I tested with an hour, then bumped to a day for > margin. But really, I think even up to ten years would

continue in empty loops

I find this easier to read. My old eyes don't focus on the semicolon, which makes me wonder what's supposed to be happening. Index: pax/ar_io.c === RCS file: /cvs/src/bin/pax/ar_io.c,v retrieving revision 1.55 diff -u -p -r1.55

Re: disklabel.c 1.219 breaks autom. disk allocation

On Wed, Jun 01, 2016 at 06:43:58PM +0200, Theo Buehler wrote: > On Wed, Jun 01, 2016 at 06:21:17PM +0200, Mark Patruck wrote: > > disklabel.c 1.219 breaks the automated disk allocation via > > template (disklabel -T) > > > > This fixes it for me: fix committed, thanks!

Re: utvfu driver port

On Wed, Jun 01, 2016 at 12:04:38PM +0200, Stefan Sperling wrote: > On Wed, Jun 01, 2016 at 01:40:14AM -0700, patrick keshishian wrote: > > Here it is... > > Thanks patrick! > > As far as I can see we don't have a man page for this driver yet. > Could you provide one? Hi Stefan, I expected the

disklabel.c 1.219 breaks autom. disk allocation

disklabel.c 1.219 breaks the automated disk allocation via template (disklabel -T) This fixes it for me: Index: disklabel.c === RCS file: /cvs/src/sbin/disklabel/disklabel.c,v retrieving revision 1.219 diff -u -p -r1.219 disklabel.c

Re: xhci(4) vs BIOS

On Tue, May 31, 2016 at 06:43:16PM +0200, Martin Pieuchot wrote: > I finally got my hands on a DELL Optiplex 3020. The BIOS on this > machines uses the xHCI controller to handle the keyboard and mouse. > > Turns out that I badly copy/pasted the ehci(4) code to take over the > HC from the BIOS.

Re: iked: fix ipv6 address pool assignment

On Wed, Jun 01, 2016 at 03:47:45PM +0200, Mike Belopuhov wrote: > On 1 June 2016 at 13:33, Patrick Wildt wrote: > > Hi, > > > > The IPv6 address assignment was basically copied from the IPv4 > > code. Instead of working on the last 32-bits, it actually worked > > on the fourth

Re: MBIM Patch (Round 2)

> - renamed it from 'mbim' to 'umbim' > I tried 'ubm' as proposed by Theo but that felt weird. Esp. > when changing the prefixes of macros whose names were >derived from the MBIM standard. I suggested that because ifconfig umbim0 ... Is annoyingly long.

Re: iked: fix ipv6 address pool assignment

On 1 June 2016 at 13:33, Patrick Wildt wrote: > Hi, > > The IPv6 address assignment was basically copied from the IPv4 > code. Instead of working on the last 32-bits, it actually worked > on the fourth byte. Thus it modified the network bits instead of > the host bits. > >

Re: Fix begin of word bug in ed

Hi Martijn, Martijn van Duren wrote on Sun, May 29, 2016 at 03:18:57PM +0200: > 1) It removes the isbinary test and the accompanying > NUL_TO_NEWLINE/NEWLINE_TO_NUL conversions. If a NUL-byte is found in a > text ed detects it as a binary file and converts every NUL to a newline > prior to doing

HP C8000 workstations

Hi all, I have a couple of HP C8000 workstations collecting dust at home. Now that the hppa64 port has been cancelled, my chances of ever running OpenBSD on one of them have gone from slim to none. They're not supported, something with the chipset (ZX1?) that is undocumented, I believe. So no

Simtec USB Entropy Key

Hi all, While cleaning out my closet I found a Simtec USB Entropy Key (hidden under those HP C8000 workstations :) It attaches as: May 31 13:09:26 pom /bsd: umodem0 at uhub3 May 31 13:09:26 pom /bsd: port 5 configuration 1 interface 0 "Simtec Electronics Entropy Key" rev 2.00/2.00 addr 6 May

Re: uvideo patches: Overview [0/4]

On Tue, May 17, 2016 at 05:15:51PM -0700, patrick keshishian wrote: > Greetings, > > I have been looking at uvideo trying to model a new driver I'm > attempting to port over and found a few issues (or what I precive > as issues). > > Since the list likes separate diffs for easier discussion,

Re: ancient relics in newsyslog

On Wed, 01 Jun 2016 01:43:06 -0400, "Ted Unangst" wrote: > Let's make the defaults be the defaults. OK millert@ - todd

Introduce arpreply()

Let's factorize some bits from arpinput() to make it more readable! This introduce arpreply() which looks like arprequest() but is used to answer requests. At the same time I get rid of the ``eaddr'' argument of carp_iamatch(), bluhm@ and Florian Riehm confirmed that it is not needed. ok? diff

Inserting new ARP entry

Diff below split the lookup inserting a new ARP entry in the routing table. This has been initially written to be able to defer the insertion to a task. It now seems that we won't need such deferral mechanism but in case somebody still see a value in it... diff --git sys/netinet/if_ether.c

Re: sqlite3 update

> Date: Wed, 1 Jun 2016 07:44:23 +0200 > From: Landry Breuil > > > (I don't really understand how things are working in Firefox on > > other OS, there are two different versions of sqlite in their > > tree...even in the one firefox tarball).. > > Nss is considered a

Re: make art_table_delete scrub the heap on all deletes

> On 1 Jun 2016, at 9:44 PM, Martin Pieuchot wrote: > > On 01/06/16(Wed) 19:27, David Gwynne wrote: >> >>> On 1 Jun 2016, at 4:13 PM, Martin Pieuchot wrote: >>> >>> On 01/06/16(Wed) 15:31, David Gwynne wrote: currently it leaves early if it is the

Re: sqlite3 update

On Wed, Jun 01, 2016 at 11:08:36AM +0100, Stuart Henderson wrote: > On 2016/06/01 07:44, Landry Breuil wrote: > > On Tue, May 31, 2016 at 11:36:35PM +0100, Stuart Henderson wrote: > > > Thanks for the pointer Ingo.. > > > > > > I'll be doing tests (including a bulk ports build) with this, > > >

Re: make art_table_delete scrub the heap on all deletes

On 01/06/16(Wed) 19:27, David Gwynne wrote: > > > On 1 Jun 2016, at 4:13 PM, Martin Pieuchot wrote: > > > > On 01/06/16(Wed) 15:31, David Gwynne wrote: > >> currently it leaves early if it is the last entry being removed, > >> which is an optimisation. in the future it is

Re: iked: address pools for both families

On 1 June 2016 at 10:16, Patrick Wildt wrote: > Hi, > > Currently there is only one address pool which is either v4 or v6. > This means that we cannot have dual-stack VPNs via iked. Clients > then might tunnel all IPv4 traffic, but IPv6 traffic is still using > the

Re: sqlite3 update

On 2016/06/01 09:09, Landry Breuil wrote: > And most importantly, 47 (released next week) requires 3.11. > /usr/obj/ports/firefox-47.0beta9/firefox-47.0b9/old-configure:SQLITE_VERSION=3.11.0 Ok, I'll update the diff this evening.

Re: iked: fix iked_cp_fixaddr()

On 1 June 2016 at 09:56, Patrick Wildt wrote: > Hi, > > iked_cp_fixaddr() is called to replace unspecified (e.g. 0.0.0.0) > addresses by specified (e.g. 192.0.2.1) ones. The function should > return if the address is already set. The check is wrong for the > IPv6 case, as it

Re: sqlite3 update

On 2016/06/01 07:44, Landry Breuil wrote: > On Tue, May 31, 2016 at 11:36:35PM +0100, Stuart Henderson wrote: > > Thanks for the pointer Ingo.. > > > > I'll be doing tests (including a bulk ports build) with this, > > but here's an update to sqlite 3.10.2 (the version which is > > in Firefox 46)

Re: utvfu driver port

On Wed, Jun 01, 2016 at 01:40:14AM -0700, patrick keshishian wrote: > Here it is... Thanks patrick! As far as I can see we don't have a man page for this driver yet. Could you provide one?

Re: utvfu driver port

On Wed, Jun 01, 2016 at 01:40:14AM -0700, patrick keshishian wrote: > On Wed, Jun 01, 2016 at 12:24:43AM -0700, patrick keshishian wrote: > > On Wed, Jun 01, 2016 at 08:58:21AM +0200, Marcus Glocker wrote: > > > On Wed, Jun 01, 2016 at 12:51:22AM -0400, Ted Unangst wrote: > > > > > > > Marcus

Re: ntfs mkdir errno value

> Date: Wed, 1 Jun 2016 10:04:12 +0200 > From: Martin Natano > > The following patch addresses an issue found by landry. mkdir on an ntfs > mountpoint returns ENOENT, while the error should be EROFS. We don't > support write access on ntfs. > > Ok? ok kettenis@ > Index:

Re: make art_table_delete scrub the heap on all deletes

> On 1 Jun 2016, at 4:13 PM, Martin Pieuchot wrote: > > On 01/06/16(Wed) 15:31, David Gwynne wrote: >> currently it leaves early if it is the last entry being removed, >> which is an optimisation. in the future it is possible for another >> cpu to have a reference to the table

Re: utvfu driver port

On Wed, Jun 01, 2016 at 12:24:43AM -0700, patrick keshishian wrote: > On Wed, Jun 01, 2016 at 08:58:21AM +0200, Marcus Glocker wrote: > > On Wed, Jun 01, 2016 at 12:51:22AM -0400, Ted Unangst wrote: > > > > > Marcus Glocker wrote: > > > > Me too. Would it be ok to merge utvfu.c and utvfu_ops.c

Re: MBIM Patch - Part 2 of 4

On 31/05/16(Tue) 13:08, Gerhard Roth wrote: > [...] > I'm quite sure this is a firmware bug and the only workaround I have > is the match by VID/PID. That still allows to match other MBIM devices > not listed in the table to be matched by Class/SubClass. I'd prefer if we could start like that,

Re: ancient relics in newsyslog

On Wed, Jun 01, 2016 at 01:43:06AM -0400, Ted Unangst wrote: > Let's make the defaults be the defaults. Reads fine. ok natano@ > > Index: Makefile > === > RCS file: /cvs/src/usr.bin/newsyslog/Makefile,v > retrieving revision 1.6 >

ntfs mkdir errno value

The following patch addresses an issue found by landry. mkdir on an ntfs mountpoint returns ENOENT, while the error should be EROFS. We don't support write access on ntfs. Ok? natano Index: ntfs/ntfs_subr.c === RCS file:

Re: kdump small timespecs

> From: "Ted Unangst" > Date: Tue, 31 May 2016 21:46:16 -0400 > > Small timespecs print funny: > > 57686 chrome CALL clock_gettime(CLOCK_MONOTONIC,0x7f7f0028) > 57686 chrome STRU struct timespec { 15411<"Dec 31 23:16:51 > 1969">.584609082 } > 57686 chrome

iked: fix iked_cp_fixaddr()

Hi, iked_cp_fixaddr() is called to replace unspecified (e.g. 0.0.0.0) addresses by specified (e.g. 192.0.2.1) ones. The function should return if the address is already set. The check is wrong for the IPv6 case, as it returns if it's not set. This causes the address to never be fixed. ok?

Re: MBIM Patch - Part 2 of 4

On 31/05/16(Tue) 15:52, Gerhard Roth wrote: > On Mon, 23 May 2016 17:47:28 +0200 Martin Pieuchot wrote: > > On 23/05/16(Mon) 16:51, Gerhard Roth wrote: > > > On Mon, 23 May 2016 16:18:29 +0200 Martin Pieuchot > > > wrote: > > > > On 23/05/16(Mon) 15:38,

iked: address pools for both families

Hi, Currently there is only one address pool which is either v4 or v6. This means that we cannot have dual-stack VPNs via iked. Clients then might tunnel all IPv4 traffic, but IPv6 traffic is still using the non-encrypted default route, which might be a security issue. To enable dual-stack

Re: utvfu driver port

On Wed, Jun 01, 2016 at 08:58:21AM +0200, Marcus Glocker wrote: > On Wed, Jun 01, 2016 at 12:51:22AM -0400, Ted Unangst wrote: > > > Marcus Glocker wrote: > > > Me too. Would it be ok to merge utvfu.c and utvfu_ops.c by including > > > both Copyrights in this file? Should it be > > > > > >

Re: utvfu driver port

On 31/05/16(Tue) 23:55, patrick keshishian wrote: > Hello, > > On Mon, May 30, 2016 at 04:22:56PM +0200, Martin Pieuchot wrote: > > On 26/05/16(Thu) 16:09, patrick keshishian wrote: > > > > > > Included is my initial effort to port the dual-licensed driver > > > for Fushicai Audio-Video Grabber

Re: sqlite3 update

On Wed, Jun 01, 2016 at 07:44:23AM +0200, Landry Breuil wrote: > On Tue, May 31, 2016 at 11:36:35PM +0100, Stuart Henderson wrote: > > Thanks for the pointer Ingo.. > > > > I'll be doing tests (including a bulk ports build) with this, > > but here's an update to sqlite 3.10.2 (the version which

Re: utvfu driver port

Hello, On Mon, May 30, 2016 at 04:22:56PM +0200, Martin Pieuchot wrote: > On 26/05/16(Thu) 16:09, patrick keshishian wrote: > > > > Included is my initial effort to port the dual-licensed driver > > for Fushicai Audio-Video Grabber (vendor 0x1b71 product 0x3002). > > Nice. Did you test both

[patch] Fix incorrect key-repeat behavior in wskbd

Hi tech@, When using wscons, the key-repeat behavior of wskbd doesn't handle the case where a key is pressed while a previous key-repeat is in progress (and the previous key is still being held). I've been using the following patch since OpenBSD 3.8 (the behavior wasn't present in OpenBSD 3.7

Re: make art_table_delete scrub the heap on all deletes

On 01/06/16(Wed) 15:31, David Gwynne wrote: > currently it leaves early if it is the last entry being removed, > which is an optimisation. in the future it is possible for another > cpu to have a reference to the table while the last reference is > being dropped, so we need to scrub it in case it