On Fri, Mar 2, 2012 at 14:37, Steffen Daode Nurpmeso
wrote:
>
> Hi,
>
> David Coppa wrote:
> > still rocking hard
>
> My old Athlon 1600+ blow dries something like
>
> B I'm gruvm up the country, where the memory tastes like wine.
>
> Is this a regression, then??
>
> --steffen
>
System is really
Hi,
David Coppa wrote:
> still rocking hard
My old Athlon 1600+ blow dries something like
I'm gruvm up the country, where the memory tastes like wine.
Is this a regression, then??
--steffen
On Sat, Feb 18, 2012 at 05:09:02PM +0100, Ariane van der Steldt wrote:
> Hi,
>
> Just to prove my point that vmmap testing is still relevant: today a bug
> got found and fixed, where grepping a 1.7GB file on i386 tripped an
> assertion (I love assertions).
>
> This brings the latest versions to:
On Sat, Feb 18, 2012 at 05:09:02PM +0100, Ariane van der Steldt wrote:
> Hi,
>
> Just to prove my point that vmmap testing is still relevant: today a bug
> got found and fixed, where grepping a 1.7GB file on i386 tripped an
> assertion (I love assertions).
>
> This brings the latest versions to:
On Sat, Feb 18, 2012 at 5:09 PM, Ariane van der Steldt
wrote:
> Hi,
>
> Just to prove my point that vmmap testing is still relevant: today a bug
> got found and fixed, where grepping a 1.7GB file on i386 tripped an
> assertion (I love assertions).
>
> This brings the latest versions to:
> http://w
Hi,
Just to prove my point that vmmap testing is still relevant: today a bug
got found and fixed, where grepping a 1.7GB file on i386 tripped an
assertion (I love assertions).
This brings the latest versions to:
http://www.stack.nl/~ariane/vmmap_sys.diff.65
(apply against /usr/src/sys)
http://w
On Fri, Feb 17, 2012 at 10:01:49PM +0600, Anton Maksimenkov wrote:
> I want to ask you about vmmap changes introduced here and in your
> presentation http://openbsd.org/papers/tdose_memalloc/presentation.html
>
> 1. http://openbsd.org/papers/tdose_memalloc/presentation.html#%2816%29
> "Browsers, j
On 2012/02/17 22:01, Anton Maksimenkov wrote:
> Hello.
>
> I want to ask you about vmmap changes introduced here and in your
> presentation http://openbsd.org/papers/tdose_memalloc/presentation.html
>
> 1. http://openbsd.org/papers/tdose_memalloc/presentation.html#%2816%29
> "Browsers, java & mon
> I want to ask you about vmmap changes introduced here and in your
> presentation http://openbsd.org/papers/tdose_memalloc/presentation.html
>
> 1. http://openbsd.org/papers/tdose_memalloc/presentation.html#%2816%29
> "Browsers, java & mono breakage"
> You pointed to some buggy software. If I und
Hello.
I want to ask you about vmmap changes introduced here and in your
presentation http://openbsd.org/papers/tdose_memalloc/presentation.html
1. http://openbsd.org/papers/tdose_memalloc/presentation.html#%2816%29
"Browsers, java & mono breakage"
You pointed to some buggy software. If I underst
Ariane van der Steldt wrote [2012-01-14 08:42+0100]:
> As far as I'm concerned, this diff will be commited once we unlock after
> release (in a coordinated manner ofcourse, since this is uvm we're
> talking about).
> It's about time too, ofcourse: 64 revisions of the same diff is alot. :D
> --
> A
On Sat, Jan 14, 2012 at 8:42 AM, Ariane van der Steldt wrote:
> Everybody thanks for testing this, it's been a tremendous help to me.
>
> As far as I'm concerned, this diff will be commited once we unlock after
> release (in a coordinated manner ofcourse, since this is uvm we're
> talking about).
On Sat, Jan 07, 2012 at 11:47:32PM +0100, Juan Francisco Cantero Hurtado wrote:
> On Fri, 06 Jan 2012 23:51:28 +0100, Ariane van der Steldt
> wrote:
> > I found and fixed the i386 bug. Please test this, to confirm that it
> > fixes the problem (and doesn't introduce anything else, ofcourse).
> >
On Fri, 06 Jan 2012 23:51:28 +0100, Ariane van der Steldt
wrote:
Hi,
I found and fixed the i386 bug. Please test this, to confirm that it
fixes the problem (and doesn't introduce anything else, ofcourse).
(vmmap_sys relative to /usr/src/sys, vmmap_userland relative to /usr/src)
New version
Hi,
I found and fixed the i386 bug. Please test this, to confirm that it
fixes the problem (and doesn't introduce anything else, ofcourse).
(vmmap_sys relative to /usr/src/sys, vmmap_userland relative to /usr/src)
New version of the diff:
http://www.stack.nl/~ariane/vmmap_sys.diff.64
with corre
On Thu, Jan 05, 2012 at 07:57:55PM +0100, Juan Francisco Cantero Hurtado wrote:
> On Fri, 30 Dec 2011 17:55:27 +0100, Ariane van der Steldt
> wrote:
>
> > On Fri, Dec 30, 2011 at 03:04:30PM +0100, Ariane van der Steldt wrote:
> >> On Fri, Dec 30, 2011 at 02:42:18PM +0100, Ariane van der Steldt
On Fri, 30 Dec 2011 17:55:27 +0100, Ariane van der Steldt
wrote:
On Fri, Dec 30, 2011 at 03:04:30PM +0100, Ariane van der Steldt wrote:
On Fri, Dec 30, 2011 at 02:42:18PM +0100, Ariane van der Steldt wrote:
> The huge diff included below is to replace vmmap for something that
> works a lot b
On Fri, Dec 30, 2011 at 05:55:27PM +0100, Ariane van der Steldt wrote:
> - it's only a 3^W 10494 line diff :P
Wow, you weren't kidding.
> I'll need testing on any and all architectures.
I'm now running this on my sparc64, macppc and amd64 boxes, the amd64 is the
only one i currently actually use
On Sat, Dec 31, 2011 at 11:24:54AM +0100, Alexander Schrijver wrote:
> On Fri, Dec 30, 2011 at 05:55:27PM +0100, Ariane van der Steldt wrote:
> > I'll need testing on any and all architectures.
>
> Is this in snapshots too?
No, it's not in snapshots.
--
Ariane
On Fri, Dec 30, 2011 at 05:55:27PM +0100, Ariane van der Steldt wrote:
> I'll need testing on any and all architectures.
Is this in snapshots too?
On Fri, Dec 30, 2011 at 03:04:30PM +0100, Ariane van der Steldt wrote:
> On Fri, Dec 30, 2011 at 02:42:18PM +0100, Ariane van der Steldt wrote:
> > The huge diff included below is to replace vmmap for something that
> > works a lot better. This is the second version I plan to commit.
> > I have bee
On Fri, Dec 30, 2011 at 02:42:18PM +0100, Ariane van der Steldt wrote:
> The huge diff included below is to replace vmmap for something that
> works a lot better. This is the second version I plan to commit.
> I have been running this on my laptop for months and have had no
> problems.
>
> The cur
On Wed, May 18, 2011 at 08:08:29PM +, Miod Vallat wrote:
> > In fact kernel_map itself is 0 when my machine stops. So the command
> > above also fails.
>
> [...]
>
> > ddb> x kernel_map
> > kernel_map: 0
>
> Use x/qx, you're on a 64-bit platform and this is a 64 bit pointer (of
> which
> In fact kernel_map itself is 0 when my machine stops. So the command
> above also fails.
[...]
> ddb> x kernel_map
> kernel_map: 0
Use x/qx, you're on a 64-bit platform and this is a 64 bit pointer (of
which the upper 32 bits are zero).
On Wed, May 18, 2011 at 04:46:01PM +0200, Ariane van der Steldt wrote:
>
> So in the case of a crash, please show me ddb output for:
> show map /f *kernel_map
> This time with an asterisk and not, as in the original mail, without
> one.
In fact kernel_map itself is 0 when my machine stops. So t
On Wed, May 18, 2011 at 02:07:28AM +0200, Ariane van der Steldt wrote:
> On Wed, May 11, 2011 at 05:05:32PM +0200, Ariane van der Steldt wrote:
> > On Wed, May 11, 2011 at 03:44:45AM +0200, Ariane van der Steldt wrote:
> > > On Wed, May 11, 2011 at 03:43:19AM +0200, Ariane van der Steldt wrote:
> >
On Wed, May 11, 2011 at 05:05:32PM +0200, Ariane van der Steldt wrote:
> On Wed, May 11, 2011 at 03:44:45AM +0200, Ariane van der Steldt wrote:
> > On Wed, May 11, 2011 at 03:43:19AM +0200, Ariane van der Steldt wrote:
> > > The newest version of vmmap (as of now) is vmmap_sys.diff.26
> > > Since t
On Mon, 16 May 2011, Stuart Henderson wrote:
On 2011/05/16 11:37, Eivind E wrote:
If I start a program with this patch (usually I just use top),
then gdb top `pgrep top`, then bt, the machine hangs.
there is a newer diff; I won't post the whole thing but in
uvm_map.c around line 5954, replace
On 2011/05/16 13:04, Amit Kulkarni wrote:
> > there is a newer diff; I won't post the whole thing but in
> > uvm_map.c around line 5954, replace this:
> >
> >KASSERT(start >= srcmap->min_offset && end <= srcmap->max_offset);
> >
> > with this:
> >
> >if ((start & PAGE_MASK) != 0 ||
> there is a newer diff; I won't post the whole thing but in
> uvm_map.c around line 5954, replace this:
>
>KASSERT(start >= srcmap->min_offset && end <= srcmap->max_offset);
>
> with this:
>
>if ((start & PAGE_MASK) != 0 || (end & PAGE_MASK) != 0 || end <
start)
>re
On 2011/05/16 11:37, Eivind E wrote:
> If I start a program with this patch (usually I just use top),
> then gdb top `pgrep top`, then bt, the machine hangs.
there is a newer diff; I won't post the whole thing but in
uvm_map.c around line 5954, replace this:
KASSERT(start >= srcmap->min_o
On Wed, 11 May 2011, Ariane van der Steldt wrote:
Hi,
The newest version of vmmap (as of now) is vmmap_sys.diff.26
Since the diff is scheduled to go in may 20 and has a lot of changes and
fixes, please test this diff and report any failures and successes.
If I start a program with this patch
On Wed, May 11, 2011 at 03:44:45AM +0200, Ariane van der Steldt wrote:
> On Wed, May 11, 2011 at 03:43:19AM +0200, Ariane van der Steldt wrote:
> > The newest version of vmmap (as of now) is vmmap_sys.diff.26
> > Since the diff is scheduled to go in may 20 and has a lot of changes and
> > fixes, pl
On Wed, May 11, 2011 at 03:43:19AM +0200, Ariane van der Steldt wrote:
> The newest version of vmmap (as of now) is vmmap_sys.diff.26
> Since the diff is scheduled to go in may 20 and has a lot of changes and
> fixes, please test this diff and report any failures and successes.
I use this separate
34 matches
Mail list logo
