The other day amd64 4.6-release-ish locked up on me while starting a
bunch of programs in X.
I blindly typed in trace and got something hopefully useful:
uvm_fault(0x80c04300, 0xfe0019295000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at uvm_rb_space+0x16: movq0x4
On Tue, Feb 02, 2010 at 04:47:49PM +1100, Damien Miller wrote:
> On Tue, 2 Feb 2010, Ted Unangst wrote:
>
> > Ordinarily, extensions to standard utilities are bad, but I think it's
> > worth considering when the flag is easily understood and provides a
> > substantial benefit. I think case inse
On Tue, 2 Feb 2010, Ted Unangst wrote:
> Ordinarily, extensions to standard utilities are bad, but I think it's
> worth considering when the flag is easily understood and provides a
> substantial benefit. I think case insenstive matching in sed qualifies.
>
> The diff below actually implements
Ordinarily, extensions to standard utilities are bad, but I think it's
worth considering when the flag is easily understood and provides a
substantial benefit. I think case insenstive matching in sed qualifies.
The diff below actually implements this behavior two different ways.
Option 1 is t
I think this fixes the problem with sleeping and holding pseg_lck.
Index: uvm_extern.h
===
RCS file: /home/tedu/cvs/src/sys/uvm/uvm_extern.h,v
retrieving revision 1.82
diff -u -r1.82 uvm_extern.h
--- uvm_extern.h11 Aug 2009 18
On Mon, Feb 01, 2010 at 03:28:22PM -0700, Darrin Chandler wrote:
> On Mon, Feb 01, 2010 at 03:05:37PM -0700, Nick Bender wrote:
> > On Mon, Feb 1, 2010 at 2:46 PM, Bob Beck wrote:
> > > On 1 February 2010 14:09, Donald Allen wrote:
> > >> I have not responded to this thread because I was angered
On 1 February 2010 10:41, Ted Unangst wrote:
>> I think the pool allocator is doable. Will look at it when I get a spare
>> hour or two (may be a while ;)
>
> Noo!!!
>
> You are begging for pain. Multi backend allocators have not fared well.
>
On Mon, Feb 01, 2010 at 03:05:37PM -0700, Nick Bender wrote:
> On Mon, Feb 1, 2010 at 2:46 PM, Bob Beck wrote:
> > On 1 February 2010 14:09, Donald Allen wrote:
> >> I have not responded to this thread because I was angered by it and
> >> did not want to respond in anger. That has passed. But thi
On Mon, Feb 1, 2010 at 2:46 PM, Bob Beck wrote:
> On 1 February 2010 14:09, Donald Allen wrote:
>> I have not responded to this thread because I was angered by it and
>> did not want to respond in anger. That has passed. But this thread is
>> unfortunately all too typical of a pattern of ridicule
http://sites.google.com/site/jgctidjtom/yzmbbezipo
On 1 February 2010 14:09, Donald Allen wrote:
> I have not responded to this thread because I was angered by it and
> did not want to respond in anger. That has passed. But this thread is
> unfortunately all too typical of a pattern of ridicule and downright
> nastiness that occurs much too often
I have not responded to this thread because I was angered by it and
did not want to respond in anger. That has passed. But this thread is
unfortunately all too typical of a pattern of ridicule and downright
nastiness that occurs much too often on the OpenBSD lists. It's
unfortunate that you do this
Sorry if this is a little bit out of topic, but I'm developing it in
OpenBSD and I couldn't find a definitive answer.
My application has one process for each interface, therefore I have
one socket to each process, I need each socket to receive packets that
came only through their interface.
So pr
2010/2/2 Anton Maksimenkov :
> Overcomplicated using of RB_TREE in uvm_map_lookup_entry() making it
> hard to understand.
> I thinking about drop this RB_TREE out from uvm_map.c or completely
> rewrite using of this RB_TREE.
Oh, sorry, I mean "in uvm_map_findspace()" of course.
In uvm_map_lookup_e
2010/2/1 Bob Beck :
> On 31 January 2010 05:43, Anton Maksimenkov wrote:
>> Second, remove redundant "temp_entry" variable from both functions.
>> One "entry" variable is enough to do the job.
> I don't think you want to do that.. uvm_map_lookup_entry can screw
> with that pointer even when it fai
* Romey Valadez [2010-01-15 00:53]:
> this patch apply to OpenBSD v4.6 -stable
we really don't care much for diffs to -stable.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootser
On 31 January 2010 05:43, Anton Maksimenkov wrote:
> Here is some cleanup of uvm_map.c code.
>
> Second, remove redundant "temp_entry" variable from both functions.
> One "entry" variable is enough to do the job.
>
I don't think you want to do that.. uvm_map_lookup_entry can screw
with that point
On Mon, Feb 1, 2010 at 4:08 AM, Artur Grabowski wrote:
> caller holds lock on kernel_map. getpage pool is empty, caller wakes
> up the getpage thread, goes to sleep (still holding the kernel_map
> lock), getpage thread wakes up, deadlocks on the kernel_map lock. It's
> not an easily detectable rec
On Mon, Feb 1, 2010 at 9:07 AM, Owain Ainsworth wrote:
> On Mon, Feb 01, 2010 at 10:08:08AM +0100, Artur Grabowski wrote:
>> We could try some magic with allocating from a pool with NOWAIT and
>> then fall back to kmem_map when that fails, but the logic would become
>> hairy. Maybe a pool allocato
7.Promociones Febrero 2010.7
Administracin
via web accesible las 24 hs todos los das
del ao
No
utiliza tu servidor, ni tu Pc, no tens que
On Mon, Feb 01, 2010 at 10:08:08AM +0100, Artur Grabowski wrote:
> Ariane van der Steldt writes:
>
> > Why are the pventries allocated from the kmem_map anyway? I think they
> > should be allocated using the uvm_km_getpage instead. Or even better,
> > from a pvpool like amd64.
>
> Recursion.
>
You are seeing this message in Text format. if your email is in the junk
folder, add the sender email to your address book and move this email into your
inbox to view the HTML version.
Ariane van der Steldt writes:
> Why are the pventries allocated from the kmem_map anyway? I think they
> should be allocated using the uvm_km_getpage instead. Or even better,
> from a pvpool like amd64.
Recursion.
caller holds lock on kernel_map. getpage pool is empty, caller wakes
up the getpa
23 matches
Mail list logo
