Re: quick fix for uvm deadlocks

Yes, this is much better. although I think this problem related to big mmaps has been with us for a while. and appears to avoid the problem with the offending test programs on my machines. I'm ok with that going in for the moment, although I want some of your time to look at that nasty shit we t

Re: quick fix for uvm deadlocks

On Wed, Feb 05, 2014 at 17:53, Bob Beck wrote: > On Wed, Feb 5, 2014 at 3:17 PM, Ted Unangst wrote: >> We are missing back pressure channels from uvm to the buf cache. The >> buf cache will happily sit on 9000 free pages while uvm churns around >> trying to scavenge up one more page. > Or are you

Re: quick fix for uvm deadlocks

On Wed, Feb 5, 2014 at 3:17 PM, Ted Unangst wrote: > We are missing back pressure channels from uvm to the buf cache. The > buf cache will happily sit on 9000 free pages while uvm churns around > trying to scavenge up one more page. Indeed, those are it's minimums (I presume in your case) and are

quick fix for uvm deadlocks

We are missing back pressure channels from uvm to the buf cache. The buf cache will happily sit on 9000 free pages while uvm churns around trying to scavenge up one more page. Fixing this is beyond the scope of a simple diff, but here's something that seems to help in a lot of the common cases, pa

Re: ok to kill stdio.h in strsep.c?

ok krw@ On 5 February 2014 13:15, Stefan Sperling wrote: > On Sat, Jan 25, 2014 at 01:49:24AM -0500, Jean-Philippe Ouellet wrote: >> It appeared in revision 1.3 ("Update from lite2.") >> >> It's the only one in the string family that has it, and nothing from it >> is used. > > I think this change

Re: ok to kill stdio.h in strsep.c?

On Sat, Jan 25, 2014 at 01:49:24AM -0500, Jean-Philippe Ouellet wrote: > It appeared in revision 1.3 ("Update from lite2.") > > It's the only one in the string family that has it, and nothing from it > is used. I think this change is fine. I'll commit this soon if I don't hear objections. > Inde

Use explicit_bzero in login_*

Index: login_chpass/login_chpass.c === RCS file: /cvs/src/libexec/login_chpass/login_chpass.c,v retrieving revision 1.16 diff -u -p -r1.16 login_chpass.c --- login_chpass/login_chpass.c 4 Dec 2012 02:24:47 - 1.16 +++ login_ch

fail to boot snapshot 5.5 on MBPro8,2

Hi, I tried to install 5.5 snapshots from 2. Feb and 3. Feb onto my laptop MacBook Pro 8,2 - both failed. Then used an older snapshot from spacehopper.org/mirrmon, which claimed to be 12 days old. Failed as well. MacBook Pro runs perfectly well with 5.4, and 5.5 bsd.rd lets me go into the ins

Re: somewhat important inteldrm fix

> Running the updated xf86-video-intel driver uncovered a bug in the > kernel drm code. The page fault handler wasn't handling some of the > possible errors correctly. This made the X server die with a SIGSEGV. > The diff below brings things closer to what Linux does, and seems to > fix the crash

Re: help needed from someone with an sk(4)

* David Higgs [2014-01-25 18:25]: > On Jan 25, 2014, at 12:48 AM, David Higgs wrote: > > On Fri, Jan 24, 2014 at 4:24 AM, Henning Brauer > wrote: > > * Henning Brauer [2014-01-24 05:50]: > > i need this tested on an sk(4). > I don't have that hardware at all. > > > this gets rif od a sligh

Re: somewhat important inteldrm fix

On Wed, Feb 5, 2014 at 11:43 AM, Mark Kettenis wrote: >> From: David Coppa >> Date: Wed, 5 Feb 2014 09:01:45 +0100 >> >> On Tue, Feb 4, 2014 at 11:55 PM, Mark Kettenis >> wrote: >> > Running the updated xf86-video-intel driver uncovered a bug in the >> > kernel drm code. The page fault handler

Re: somewhat important inteldrm fix

> From: David Coppa > Date: Wed, 5 Feb 2014 09:01:45 +0100 > > On Tue, Feb 4, 2014 at 11:55 PM, Mark Kettenis > wrote: > > Running the updated xf86-video-intel driver uncovered a bug in the > > kernel drm code. The page fault handler wasn't handling some of the > > possible errors correctly.

Re: exp() / expl() on Linux and OpenBSD (expl() bug?)

> Date: Wed, 5 Feb 2014 01:57:33 -0700 > From: David Coppa > > > Hi! > > I hit this problem while working on updating math/R from version > 2.15.3 to the latest version (3.0.2). > > It started happening since upstream switched from double functions > to C99 long double functions (expl, fabsl,

Re: exp() / expl() on Linux and OpenBSD (expl() bug?)

> Date: Wed, 5 Feb 2014 01:57:33 -0700 > From: David Coppa > > Hi! > > I hit this problem while working on updating math/R from version > 2.15.3 to the latest version (3.0.2). > > It started happening since upstream switched from double functions > to C99 long double functions (expl, fabsl, ...

exp() / expl() on Linux and OpenBSD (expl() bug?)

Hi! I hit this problem while working on updating math/R from version 2.15.3 to the latest version (3.0.2). It started happening since upstream switched from double functions to C99 long double functions (expl, fabsl, ...), during the R-3 development cycle. Take the following reduced test-case,

Re: somewhat important inteldrm fix

On Tue, Feb 4, 2014 at 11:55 PM, Mark Kettenis wrote: > Running the updated xf86-video-intel driver uncovered a bug in the > kernel drm code. The page fault handler wasn't handling some of the > possible errors correctly. This made the X server die with a SIGSEGV. > The diff below brings things