Simplify tcpdump

fddi_bitswap is only used once, and it just adds a layer of indirection to its preprocessor condition. This also removes macros for BSDi and Ultrix. ok? Index: print-fddi.c === RCS file: /cvs/src/usr.sbin/tcpdump/print-fddi.c,v

htprot sanity check

Don't try to interpret htprot data if the last beacon didn't contain any such data. In other words, ensure we copied data from the beacon to ni->ni_htop1 before using ni->ni_htop1. Note that read and write of ni->ni_htop1 are not visible in this diff's context, but happen close-by in surrounding

Re: Firefox, malloc(3) and threads

I haven't tried anything too scientific yet, but pages seem to load quicker and firefox seems to be more responsive under load for me. Before this patch, loading a page would have a tendency to lock the browser for a few seconds on complex pages. Nothing seems to have broken, so I'll try harder.

Re: security(8) mailbox check question

Hi all, On 2016-01-23 Sat 22:31 PM |, Joerg Jung wrote: > On Sat, Jan 23, 2016 at 08:31:09PM +0100, Ingo Schwarze wrote: > > This was discussed several times before. e.g: http://openbsd-archive.7691.n7.nabble.com/security-8-check-maildir-as-well-as-mailbox-permissions-td239848.html -- Ray's

Re: security(8) mailbox check question

Hi Ted, On 2016-01-23 Sat 17:27 PM |, Ted Unangst wrote: > > I think the possibility to fill up /var makes it a poor choice. For mail servers, /var/mail/ can be a seperate mount point. /var/log/ is commonly a mount point on servers. As is /var/www/ /var/spool/{smtpd,postfix}

DDB is elf

Removes the abstraction layer to support multiple executable binaries. These days all our architectures are ELF and this would allows us to reuse the ELF parsing code more easily. Diff below includes the db_sifting() removal. ok? Index: db_elf.c

Kill db_sifting()

It is unused, ok? Index: db_sym.c === RCS file: /cvs/src/sys/ddb/db_sym.c,v retrieving revision 1.41 diff -u -p -r1.41 db_sym.c --- db_sym.c25 Jan 2016 14:50:13 - 1.41 +++ db_sym.c25 Jan 2016 14:53:41 - @@ -52,8

honour ERP protection in 11n mode

ERP (Extended Rate PHY) protection must be honoured in 11n mode on 2 GHz channels. >From an 11b client's point of view, 11n behaves like 11g in terms of frame protection, and we must enable ERP protection in 11n mode if requested by the AP. The drivers already enable ERP protection if

Re: libgen.h: unreachable decls

On Mon, 25 Jan 2016 06:14:39 +0100, =?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges- Anglas?= wrote: > I noticed those a while ago, the #if 0 is there since the beginning. > Can't see the point in keeping this as is. OK. The __loc1 symbol and the regcmp() and regex() functions were removed from Open

Re: Firefox, malloc(3) and threads

Hi Mark, even with 16GB RAM I needed to install smtube to get a decent view of videos prior to your patches. Patched last night but only tonight I am able to do some testing: At present I have openend - LibreOffice Writer with one doc - LibreOffice Calc with one doc - gimp with one picture -

Re: Firefox, malloc(3) and threads

Hi Mark, On Fri, Jan 22, 2016 at 10:46:39PM +0100, Mark Kettenis wrote: > Firefox makes a lot of concurrent malloc(3) calls. The locking to > make malloc(3) thread-safe is a bit...suboptimal. This diff makes > things better by using a mutex instead of spinlock. If you're running > Firefox you

Re: Xen virtual network (Netfront) driver

On Mon, Jan 25, 2016 at 12:04:03PM +0100, Mike Belopuhov wrote: > On 25 January 2016 at 01:38, Jonathon Sisson wrote: > > Not certain if this is debug output put there intentionally or > > Yes. > > > if this is some error condition? > > It is. Transmission is stuck and these

Re: Firefox, malloc(3) and threads

On Mon, Jan 25, 2016 at 10:06:22AM +0100, David Coppa wrote: > On Sun, Jan 24, 2016 at 7:47 PM, Adam Wolk wrote: > > On Fri, 22 Jan 2016 22:46:39 +0100 (CET) > > Mark Kettenis wrote: > > > >> Firefox makes a lot of concurrent malloc(3) calls. The

RCS: Mdocdate expansion

Hi, tj@ just noticed that our RCS still doesn't know how to expand Mdocdate. One consequence is that rcsdiff(1) shows wrong Mdocdate lines - typically, for each revision, the ones from the previous revision. That in turn causes cvsweb to show wrong Mdocdate lines in diffs. I'm showing the

Willing to help

Hi OpenBSD developers, First of all: Thanks by the project. I would like to receive some help/mentoring. I`m cursing a master degree course at PUC-Rio, and I need to "create a useful program that performs a service of interest to anyone other than exsively the student." So I would like to

Re: Firefox, malloc(3) and threads

On Sat, Jan 23, 2016 at 03:53:32PM +0100, Martin Natano wrote: > Yes! This absolutely makes Youtube videos watchable for me (on a > Thinkpad T520). There still is occassional stuttering, but _far_ less > disruptive than before. Another usecase where I see improvements is > reloading a

Re: Willing to help

Hi, Rodrigo Mosconi wrote on Mon, Jan 25, 2016 at 06:54:32PM -0200: > I would like to receive some help/mentoring. Please don't reply on tech@, this is off-topic here. I replied on misc@. Yours, Ingo

Re: Firefox, malloc(3) and threads

I've had the patch applied for two days now and have not seen any ill efects. This is a Thinkpad T410 running snapshots. Before, youtube was unwatchable. Sound would continue normally while video would freeze for long stretches, often over 10 seconds. Its not perfect now, but its very nearly

poll gpio ihidev interrupts

acpi described hid devices can have interrupts signalled by gpio. As there is currently no support for that here is an alternative to poll the devices at a fixed interval. This makes the keyboard/trackpad on the ideapad 100s mostly useable, clicking and dragging windows in X seems a bit off. I'm

Re: Firefox, malloc(3) and threads

On Mon, Jan 25, 2016 at 08:48:21AM +0100, Mark Kettenis wrote: > > From: "Peter N. M. Hansteen" > > Date: Sun, 24 Jan 2016 23:10:41 +0100 > > > > On 01/22/16 22:46, Mark Kettenis wrote: > > > Firefox makes a lot of concurrent malloc(3) calls. The locking to > > > make malloc(3)

Re: Firefox, malloc(3) and threads

On Sun, Jan 24, 2016 at 7:47 PM, Adam Wolk wrote: > On Fri, 22 Jan 2016 22:46:39 +0100 (CET) > Mark Kettenis wrote: > >> Firefox makes a lot of concurrent malloc(3) calls. The locking to >> make malloc(3) thread-safe is a bit...suboptimal. This

Re: Xen virtual network (Netfront) driver

On 25 January 2016 at 01:38, Jonathon Sisson wrote: > tech@, > > I've uploaded a few of the dmesgs gathered to dmesgd.nycbug.org: > > http://dmesgd.nycbug.org/index.cgi?action=dmesgd=index=Jonathon > > Currently I have m4.10xlarge, c4.8xlarge, m3.medium, and t2.nano > uploaded

Loops depending on undefined behavior

I've discussed the below with otto@, who thought it was sound but wanted confirmation before I commit. While debugging rarpd(8) for unrelated reasons, I noticed a loop of the following form: > for (i = 1; i; i <<= 1) where i is an int. This relies on shifting into and then out of the sign bit,