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
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.
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 option is used, because you end
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 still
>
> I certainly like to use names wherever i can.
>
Allright allright.. so openssl s_client does actually do it.. So benno,
you and philip have guilted me into it..
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
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 codepaths
Hi. I have a pair of openBSD boxes (5.8) setup as a core/firewall. I have
ten VLANs tied to a physical NIC (Intel 82599). This is a new setup and it
was just recently put in service. Traffic was fine (or at least we didn't
notice any issues) until a large job was run which roughly doubled traff
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) t
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
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&r2=1.319&f=h
Index: faq14.html
===
RCS file: /cvs/www/faq/faq14.html,v
retrie
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
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
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 n
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
DHCPREQ
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 e
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 perils of rebooting. I tested
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
>> > even when we rename it to ubm.
>>
>>
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 I
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.
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
> >> deri
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 "umb" (USB Mobil
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 hour, then bumped to a day fo
> 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.
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 ...
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 just a typo?
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
> =
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 basi
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. Instead of working on the last 32-bits, it
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 my
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 "d
> 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
On Wed, 01 Jun 2016 13:08:05 -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, I switched to this style myself some years ago.
- todd
Okan and I finally figured out what I was smoking when I wrote this
regress test: it's testing for correct tab spacing when displaying on a
terminal, correctly predicting the number of columns each tab will take
up (as naively counting each character as taking up exactly one column
will mess up the
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 ar_io
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!
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:
Thanks for the report. I agree with this fix.
The problem is that readlabel() calls editor_allocspace() which will use
th
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 n
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
On Wed, Jun 01, 2016 at 09:32:52AM -0600, 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 suggeste
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. W
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 byte. Thus it modi
Hi,
so here is an updated version of the MBIM patch (this time as one
single patch).
This is what has changed since the first version:
- 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
> - 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.
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.
>
> This diff fixes the co
On Wed, 01 Jun 2016 10:04:12 +0200, Martin Natano wrote:
> 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 millert@
- todd
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
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 O
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 3
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, Her
On Wed, 01 Jun 2016 01:43:06 -0400, "Ted Unangst" wrote:
> Let's make the defaults be the defaults.
OK millert@
- todd
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
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 sys/n
> 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 third-party library in firefo
> 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 last entry being removed,
which is
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,
> > > bu
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 possible for another
>
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.
This diff fixes the code so that we can have at least a 32-bit
address pool space b
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 non-encrypted default route, wh
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.
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 returns if it's not
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) i
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?
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 Glo
> 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: ntfs/ntfs_subr.c
>
> 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 while the last ref
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 by
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, th
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
>
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: /cvs/src/s
> 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 RET clock_gettime 0
>
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?
Pat
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 IKEv2,
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, Gerhard Roth wrote:
> > > >
> > > > This
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
> > >
> > > [C
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 (
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 is
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
> >
> > [Copyright 1]
> > [Code 1]
> > [Copyright 2]
> > [Code 2]
> >
> >
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 bul
78 matches
Mail list logo
