Re: xargs -0 and -L
On Tue, 2 Feb 2010, Ingo Schwarze wrote: Hi Antti, Antti Harri wrote on Tue, Feb 02, 2010 at 07:31:57PM +0200: xargs' -L switch isn't working when using -0 flag. After checking POSIX.1 (2008), i conclude that our implementation and manual are correct in this respect. The -L option is concerned with "lines of arguments from standard input". ASCII nul characters do not delimit lines. Also, be careful not to confuse -L with -n. Hello. Ahh, you're correct, thanks for a very thorough explanation. The talk about the size of the buffers in -n confused me and I did not use it. Here's a demonstration: $ cd /tmp/ $ mkdir foo bar $ find /tmp/foo /tmp/bar | xargs -L 1 echo /tmp/foo /tmp/bar $ find /tmp/foo /tmp/bar -print0 | xargs -0 -L 1 echo /tmp/foo /tmp/bar Fine, that's correct behaviour. Telling find(1) to -print0, you put the output on one single line, like this: $ printf "/tmp/foo\0/tmp/bar\0" | xargs -0 -L1 /tmp/foo /tmp/bar Your patch breaks X/Open System Interfaces (XSI) compatibility. Arguably, that's not terribly important because -0 is a non-standard extension anyway. But still, even if we didn't care about the standard, i don't see the point of changing this patch. As it is now, -L with and without -0 harmonize very well: schwa...@gini $ printf "a b\nc" | xargs -L1 a b c schwa...@gini $ printf "a\0b\nc" | xargs -0 -L1 a b c So, xargs -0 treats '\0' just like plain xargs treats the blank: delimiting an argument, but not a line. In addition to that, your patch is wrong because it treats '\0' as an end-of-line indicator even when -0 is not in effect. Tested also on OS X and Linux and they print two lines with -0. So you might wish to file bug reports with these operating systems. Yours, Ingo Index: xargs.c === RCS file: /cvs/src/usr.bin/xargs/xargs.c,v retrieving revision 1.26 diff -u -r1.26 xargs.c --- xargs.c 27 Oct 2009 23:59:50 - 1.26 +++ xargs.c 2 Feb 2010 16:45:26 - @@ -259,6 +259,7 @@ goto addch; goto arg2; case '\0': + count++; if (zflag) goto arg2; goto addch;
Re: uvm_pseg_get & uvm_pseg_lck fix
On Mon, Feb 01, 2010 at 11:30:06PM -0500, Ted Unangst wrote:
> 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.h 11 Aug 2009 18:43:33 - 1.82
> +++ uvm_extern.h 2 Feb 2010 04:28:09 -
> @@ -517,8 +517,9 @@
> vaddr_t *, vsize_t, int,
> boolean_t, vm_map_t);
> vaddr_t uvm_km_valloc(vm_map_t, vsize_t);
> -vaddr_t uvm_km_valloc_align(vm_map_t, vsize_t, vsize_t);
> +vaddr_t uvm_km_valloc_try(vm_map_t, vsize_t);
> vaddr_t uvm_km_valloc_wait(vm_map_t, vsize_t);
> +vaddr_t uvm_km_valloc_align(struct vm_map *, vsize_t,
> vsize_t, int);
> vaddr_t uvm_km_valloc_prefer_wait(vm_map_t, vsize_t,
> voff_t);
> void *uvm_km_getpage(boolean_t, int *);
> Index: uvm_km.c
> ===
> RCS file: /home/tedu/cvs/src/sys/uvm/uvm_km.c,v
> retrieving revision 1.75
> diff -u -r1.75 uvm_km.c
> --- uvm_km.c 25 Jul 2009 12:55:40 - 1.75
> +++ uvm_km.c 2 Feb 2010 04:27:35 -
> @@ -571,11 +571,17 @@
> vaddr_t
> uvm_km_valloc(struct vm_map *map, vsize_t size)
> {
> - return(uvm_km_valloc_align(map, size, 0));
> + return(uvm_km_valloc_align(map, size, 0, 0));
> }
>
> vaddr_t
> -uvm_km_valloc_align(struct vm_map *map, vsize_t size, vsize_t align)
> +uvm_km_valloc_try(struct vm_map *map, vsize_t size)
> +{
> + return(uvm_km_valloc_align(map, size, 0, UVM_FLAG_TRYLOCK));
> +}
> +
> +vaddr_t
> +uvm_km_valloc_align(struct vm_map *map, vsize_t size, vsize_t align, int
> flags)
> {
> vaddr_t kva;
> UVMHIST_FUNC("uvm_km_valloc"); UVMHIST_CALLED(maphist);
> @@ -592,7 +598,7 @@
>
> if (__predict_false(uvm_map(map, &kva, size, uvm.kernel_object,
> UVM_UNKNOWN_OFFSET, align, UVM_MAPFLAG(UVM_PROT_ALL, UVM_PROT_ALL,
> - UVM_INH_NONE, UVM_ADV_RANDOM, 0)) != 0)) {
> + UVM_INH_NONE, UVM_ADV_RANDOM, flags)) != 0)) {
> UVMHIST_LOG(maphist, "<- done (no VM)", 0,0,0,0);
> return(0);
> }
> Index: uvm_pager.c
> ===
> RCS file: /home/tedu/cvs/src/sys/uvm/uvm_pager.c,v
> retrieving revision 1.54
> diff -u -r1.54 uvm_pager.c
> --- uvm_pager.c 22 Jul 2009 21:05:37 - 1.54
> +++ uvm_pager.c 2 Feb 2010 04:23:57 -
> @@ -138,7 +138,7 @@
> {
> KASSERT(pseg->start == 0);
> KASSERT(pseg->use == 0);
> - pseg->start = uvm_km_valloc(kernel_map, MAX_PAGER_SEGS * MAXBSIZE);
> + pseg->start = uvm_km_valloc_try(kernel_map, MAX_PAGER_SEGS * MAXBSIZE);
I'd prefer
uvm_km_kmemalloc(kernel_map, NULL, MAX_PAGER_SEGS * MAXBSIZE,
UVM_KMF_TRYLOCK|UVM_KMF_VALLOC)
instead of introducing a new uvm_km_valloc_* function. There are plenty
of those already and most of them can be rewritten to uvm_km_kmemalloc
with suitable flags.
Apart from that, the diff looks fine to me.
> }
>
> /*
>
I think it'll only fix the problem partially though: uvm_km_free*
doesn't have a trylock variant and may sleep just as well on the lock.
I think what happens is that another uvm_km_pgremove is sleeping on
the wanted flag, holding the rwlock. I.e. another uvm_km_free is in
progress somewhere else, waiting for a busy kernelpage (which hopefully
is busy because of a 3rd kernel thread, possibly the pagedaemon).
To summarize:
[1] aiodone needs pseg mutex
[2] mutex is held by pagedaemon thread which illegally sleeps
[3] because the pagedaemon wants access to the uvm_map
[4] which is held by another kernel thread sleeping while locking uvm_map
[5] because another thread has its page marked busy
The thread in [5] could be the pagedaemon, in which case we have a
deadlock. However, making the allocation in [2] try-lock instead may
indeed remove the deadlock (assuming no other process would try to mark
pages busy that don't belong to it).
But I think the deadlock would still resurface, simply because this is a
kernel page and some other kernel thread may try to free its memory
between the pagedaemon starting a page-out and the aiodone daemon
cleaning up.
To make matters worse, it could be that a uvm object decided it needed
to be synced to disk: if memory serves me right any uvm_object io goes
through this code.
The only fix I can think of at the moment is not to use uvm_km_alloc and
uvm_km_free at all for the pseg code.
Ciao,
--
Ariane
Re: hi0
hi9 Dear friends, I'm sorry, wasted your valuable time, we are chinese a major international trading electronics wholesale company. Our company's electronic products have the best quality, cheapest price and best service. If you have time to buy 5 products that can free you of the postage. Thanks! The best wishes! hi8 o<7o<%o<"o<3o<)o<4o<%o<elcsky.com MSN: ele-...@hotmail.com EMAIL: elc...@188.com reserved: Beijing Fooda Electronics Co.,Ltd _ B?QuC) signigica Messenger para ti? www.vivirmessenger.com
Re: UBC?
>> The real issue came out quickly in response to direct questions, and it >> came out in a civil and informative manner. No problem. So what's your >> point, really? > > don't hide your questions behind buzzwords and then get upset when > someone makes fun of buzzwords. > Knock it off both of you fer crissake. Jeesus what a what to take a productive thread and turn it into a shitshow. Take this conversation to misc@ please so it doesn't hit my inbox. Yes the "ubc" buzzword was in the initial thread, which is why I asked the questions, and why it then went somewhere. Get over it. If the OP was somehow offended by what someone else said I regret that, but fine. There is no futher need to flog the carcass off the horse into a greasy puddle on the street. Particularly on *t...@* - please take other such discussions to misc@ and start another thread there about how much you hate us. now shut up, leave the OP alone, and let the rest of us use this thread for the *productive* use of examining several *real* issues that fall out of this instead of whining. Nobody gives a damn who won.
Re: xargs -0 and -L
Hi Antti, Antti Harri wrote on Tue, Feb 02, 2010 at 07:31:57PM +0200: > xargs' -L switch isn't working when using -0 flag. After checking POSIX.1 (2008), i conclude that our implementation and manual are correct in this respect. The -L option is concerned with "lines of arguments from standard input". ASCII nul characters do not delimit lines. Also, be careful not to confuse -L with -n. > Here's a demonstration: > > $ cd /tmp/ > $ mkdir foo bar > $ find /tmp/foo /tmp/bar | xargs -L 1 echo > /tmp/foo > /tmp/bar > $ find /tmp/foo /tmp/bar -print0 | xargs -0 -L 1 echo > /tmp/foo /tmp/bar Fine, that's correct behaviour. Telling find(1) to -print0, you put the output on one single line, like this: $ printf "/tmp/foo\0/tmp/bar\0" | xargs -0 -L1 /tmp/foo /tmp/bar Your patch breaks X/Open System Interfaces (XSI) compatibility. Arguably, that's not terribly important because -0 is a non-standard extension anyway. But still, even if we didn't care about the standard, i don't see the point of changing this patch. As it is now, -L with and without -0 harmonize very well: schwa...@gini $ printf "a b\nc" | xargs -L1 a b c schwa...@gini $ printf "a\0b\nc" | xargs -0 -L1 a b c So, xargs -0 treats '\0' just like plain xargs treats the blank: delimiting an argument, but not a line. In addition to that, your patch is wrong because it treats '\0' as an end-of-line indicator even when -0 is not in effect. > Tested also on OS X and Linux and they print two lines with -0. So you might wish to file bug reports with these operating systems. Yours, Ingo > Index: xargs.c > === > RCS file: /cvs/src/usr.bin/xargs/xargs.c,v > retrieving revision 1.26 > diff -u -r1.26 xargs.c > --- xargs.c 27 Oct 2009 23:59:50 - 1.26 > +++ xargs.c 2 Feb 2010 16:45:26 - > @@ -259,6 +259,7 @@ > goto addch; > goto arg2; > case '\0': > + count++; > if (zflag) > goto arg2; > goto addch;
Re: Questions regarding bind(2) and multicast addresses.
On Mon, Feb 01, 2010 at 06:32:37PM -0200, Christiano F. Haesbaert wrote: > 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 process that handles interface iwn0 should only receive packets > that came through iwn0, and process that handles interface em0, should > see only packets for em0. > > I'm interested in multicast packets, no doubts about joining the > group, that I understand. > > Well I obviously don't want to bind to INADDR_ANY, even so, if I did, > would the packets be delivered in both sockets ? > > I could also try to play with MCAST_BLOCK_SOURCE, but that doesn't > seem nice either. > > Pardon my ignorance here, but if I bind each socket to a unicast > address of the specified interface, I'll get what I want, but what > happens if the address changes ? Do I need to rebind the socket ? > I understand that if I need to rebind, I'll use AF_ROUTE to get > address changes and so on, that's wouldn't be much of a trouble. > > If that's any of concern, I'm joining multicast dns group, and the > protocol uses udp port 5353. > > Sorry for the long post. > I now realize how dumb my question was, I can't obviously bind the same address in two different sockets, sorry for the noise. -- Christiano Farina HAESBAERT Do NOT send me html mail.
Re: UBC?
On Tue, Feb 02, 2010 at 11:58:37AM -0700, Darrin Chandler wrote: > On Tue, Feb 02, 2010 at 06:36:14PM +, Jacob Meuser wrote: > > On Tue, Feb 02, 2010 at 10:09:58AM -0700, Darrin Chandler wrote: > > > On Tue, Feb 02, 2010 at 02:51:52AM +, Jacob Meuser wrote: > > > > are you talking about Bret's reply about buzzwords? imo, that's what > > > > that reply was about, buzzwords. there was nothing personal. see, > > > > the way buzzwords work, is they get stuck in your (as in most people) > > > > head, then they come out when you have a idea but don't know quite > > > > how to express it. which is clearly the situation here. > > > > > > It's not like UBC was totally unrelated to the topic. And that situation > > > was already handled fine by Bob Beck in a more productive and > > > informative way. > > > > > > > I think readers of OpenBSD lists are far too sensitive. there, that's > > > > a personal 'attack' on all y'all. > > > > > > Yeah, everything is fine the way it is. Alienating random users with > > > real questions is the cost of making a good OS. They're just too > > > sensitive. > > > > > > Except that I have a pretty thick skin and have been around on the lists > > > enough to see how things work. So why did this thread bother me? Because > > > there's a difference between some idiot asking idiotic questions on > > > misc@ and getting blasted, and an inquiry into a pretty common, genuine > > > issue on t...@. > > > > he asked about UBC. he did not originally present his real issue. > > > > but whatever. you can take it as a lesson to not hide your real > > questions/issues behind buzzwords, or you can get upset. it's > > your choice. > > The real issue came out quickly in response to direct questions, and it > came out in a civil and informative manner. No problem. So what's your > point, really? don't hide your questions behind buzzwords and then get upset when someone makes fun of buzzwords. > No, nevermind. I'm not interested in debating this. > You're grasping at anything to prop up your position. Just hold firm and > I'll stop bugging you about it. You win. Kind of. win what? > -- > Darrin Chandler| Phoenix BSD User Group | MetaBUG > dwchand...@stilyagin.com | http://phxbug.org/ | http://metabug.org/ > http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: UBC?
On Tue, Feb 02, 2010 at 06:36:14PM +, Jacob Meuser wrote: > On Tue, Feb 02, 2010 at 10:09:58AM -0700, Darrin Chandler wrote: > > On Tue, Feb 02, 2010 at 02:51:52AM +, Jacob Meuser wrote: > > > are you talking about Bret's reply about buzzwords? imo, that's what > > > that reply was about, buzzwords. there was nothing personal. see, > > > the way buzzwords work, is they get stuck in your (as in most people) > > > head, then they come out when you have a idea but don't know quite > > > how to express it. which is clearly the situation here. > > > > It's not like UBC was totally unrelated to the topic. And that situation > > was already handled fine by Bob Beck in a more productive and > > informative way. > > > > > I think readers of OpenBSD lists are far too sensitive. there, that's > > > a personal 'attack' on all y'all. > > > > Yeah, everything is fine the way it is. Alienating random users with > > real questions is the cost of making a good OS. They're just too > > sensitive. > > > > Except that I have a pretty thick skin and have been around on the lists > > enough to see how things work. So why did this thread bother me? Because > > there's a difference between some idiot asking idiotic questions on > > misc@ and getting blasted, and an inquiry into a pretty common, genuine > > issue on t...@. > > he asked about UBC. he did not originally present his real issue. > > but whatever. you can take it as a lesson to not hide your real > questions/issues behind buzzwords, or you can get upset. it's > your choice. The real issue came out quickly in response to direct questions, and it came out in a civil and informative manner. No problem. So what's your point, really? No, nevermind. I'm not interested in debating this. You're grasping at anything to prop up your position. Just hold firm and I'll stop bugging you about it. You win. Kind of. -- Darrin Chandler| Phoenix BSD User Group | MetaBUG dwchand...@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: UBC?
On Tue, Feb 02, 2010 at 10:09:58AM -0700, Darrin Chandler wrote: > On Tue, Feb 02, 2010 at 02:51:52AM +, Jacob Meuser wrote: > > are you talking about Bret's reply about buzzwords? imo, that's what > > that reply was about, buzzwords. there was nothing personal. see, > > the way buzzwords work, is they get stuck in your (as in most people) > > head, then they come out when you have a idea but don't know quite > > how to express it. which is clearly the situation here. > > It's not like UBC was totally unrelated to the topic. And that situation > was already handled fine by Bob Beck in a more productive and > informative way. > > > I think readers of OpenBSD lists are far too sensitive. there, that's > > a personal 'attack' on all y'all. > > Yeah, everything is fine the way it is. Alienating random users with > real questions is the cost of making a good OS. They're just too > sensitive. > > Except that I have a pretty thick skin and have been around on the lists > enough to see how things work. So why did this thread bother me? Because > there's a difference between some idiot asking idiotic questions on > misc@ and getting blasted, and an inquiry into a pretty common, genuine > issue on t...@. he asked about UBC. he did not originally present his real issue. but whatever. you can take it as a lesson to not hide your real questions/issues behind buzzwords, or you can get upset. it's your choice. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
xargs -0 and -L
Hi, xargs' -L switch isn't working when using -0 flag. Here's a demonstration: $ cd /tmp/ $ mkdir foo bar $ find /tmp/foo /tmp/bar | xargs -L 1 echo /tmp/foo /tmp/bar $ find /tmp/foo /tmp/bar -print0 | xargs -0 -L 1 echo /tmp/foo /tmp/bar Tested also on OS X and Linux and they print two lines with -0. Index: xargs.c === RCS file: /cvs/src/usr.bin/xargs/xargs.c,v retrieving revision 1.26 diff -u -r1.26 xargs.c --- xargs.c 27 Oct 2009 23:59:50 - 1.26 +++ xargs.c 2 Feb 2010 16:45:26 - @@ -259,6 +259,7 @@ goto addch; goto arg2; case '\0': + count++; if (zflag) goto arg2; goto addch;
Re: UBC?
On Tue, Feb 02, 2010 at 02:51:52AM +, Jacob Meuser wrote: > are you talking about Bret's reply about buzzwords? imo, that's what > that reply was about, buzzwords. there was nothing personal. see, > the way buzzwords work, is they get stuck in your (as in most people) > head, then they come out when you have a idea but don't know quite > how to express it. which is clearly the situation here. It's not like UBC was totally unrelated to the topic. And that situation was already handled fine by Bob Beck in a more productive and informative way. > I think readers of OpenBSD lists are far too sensitive. there, that's > a personal 'attack' on all y'all. Yeah, everything is fine the way it is. Alienating random users with real questions is the cost of making a good OS. They're just too sensitive. Except that I have a pretty thick skin and have been around on the lists enough to see how things work. So why did this thread bother me? Because there's a difference between some idiot asking idiotic questions on misc@ and getting blasted, and an inquiry into a pretty common, genuine issue on t...@. -- Darrin Chandler| Phoenix BSD User Group | MetaBUG dwchand...@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: cwm no blank labels
On Sun 2010.01.17 at 16:05 +0100, Thomas Pfaff wrote:
> This diff disallows setting blank labels and pressing Esc while editing
> the current one will leave it unchanged. I don't see the point in allowing
> empty labels as the windows will just show up as blank entries in the menu.
>
> Also remove `current' variable and just use `cc->label'.
hi,
i believe due to the nature of menu_filter(), you'll still run into
losing your label using just strlen(). below the least intrusive way
until we potentially look back at the menu code.
i don't use labels at all, so can you verify this fixes all your cases?
cheers,
okan
Index: calmwm.h
===
RCS file: /home/open/anoncvs/cvs/xenocara/app/cwm/calmwm.h,v
retrieving revision 1.115
diff -u -p -r1.115 calmwm.h
--- calmwm.h27 Jan 2010 03:04:50 - 1.115
+++ calmwm.h30 Jan 2010 20:14:49 -
@@ -320,6 +320,7 @@ struct menu {
char print[MENU_MAXENTRY + 1];
void*ctx;
shortdummy;
+ shortabort;
};
TAILQ_HEAD(menu_q, menu);
Index: kbfunc.c
===
RCS file: /home/open/anoncvs/cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.50
diff -u -p -r1.50 kbfunc.c
--- kbfunc.c15 Dec 2009 04:10:42 - 1.50
+++ kbfunc.c30 Jan 2010 20:36:18 -
@@ -400,19 +400,19 @@ kbfunc_client_label(struct client_ctx *c
{
struct menu *mi;
struct menu_qmenuq;
- char*current;
TAILQ_INIT(&menuq);
- current = cc->label;
+ /* dummy is set, so this will always return */
+ mi = menu_filter(cc->sc, &menuq, "label", cc->label, 1,
+ search_match_text, NULL);
- if ((mi = menu_filter(cc->sc, &menuq, "label", current, 1,
- search_match_text, NULL)) != NULL) {
+ if (!mi->abort) {
if (cc->label != NULL)
xfree(cc->label);
cc->label = xstrdup(mi->text);
- xfree(mi);
}
+ xfree(mi);
}
void
Index: menu.c
===
RCS file: /home/open/anoncvs/cvs/xenocara/app/cwm/menu.c,v
retrieving revision 1.19
diff -u -p -r1.19 menu.c
--- menu.c 15 Dec 2009 04:10:42 - 1.19
+++ menu.c 30 Jan 2010 20:35:01 -
@@ -223,6 +223,7 @@ menu_handle_key(XEvent *e, struct menu_c
mc->searchstr, sizeof(mi->text));
mi->dummy = 1;
}
+ mi->abort = 0;
return (mi);
case CTL_WIPE:
mc->searchstr[0] = '\0';
@@ -235,6 +236,7 @@ menu_handle_key(XEvent *e, struct menu_c
mi = xmalloc(sizeof *mi);
mi->text[0] = '\0';
mi->dummy = 1;
+ mi->abort = 1;
return (mi);
default:
break;
Re: UBC? And a Mr. Allen
FWIW, Hey, I have been to the RTFM side, as well as asking if "YXZ feature is looked into" But I see the response to Mr. Allen's RFC (See Initial Posting) appropriate. Including the initial inside humour. In fact, it did spawn a related set of tests where the differences between amd64, and i386 are different (it appeared to me at least) in the mechanisms used for allocations. I benefited from the result of the RFC if in fact I considered the response to the Initial Comment Request - appropriate. Oh, and Mr. Allen. Since it was a "bussword" RFC you posted, and your lack of comprehension and sensitivity to the response. I (Personally) would prefer if you used a Operating System running on x86 platforms that you decide (if you comprehend it) which licensing solution you can afford. Grow Up, code, hack, and be Free if you want to, but I politely invite you to not Whine on and on about your sensitivities. -- I like my Cheese with a bottle of Merlot, not with a sandwich and Baloney and an ASR38. (grumble) <^G -- DING!> Oh Wait, Leave out the ASR38 I need that for the wide listings... -sean > Date: Tue, 2 Feb 2010 02:51:52 + > From: jake...@sdf.lonestar.org > To: tech@openbsd.org > Subject: Re: UBC? > > 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 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. > > > > > > > > > > > > > > > > Well I certainly didn't get that impression from this thread, Sorry > > > > you did.. Happy Trails. > > > > > > > > > > > > > > Ditto. Thought this thread was fairly productive: > > > > > > - question raised > > > - clarification sought > > > - clarification provided > > > - solution given > > > - bug found > > > - patch proposed and debated > > > > > > > You could enforce minimum levels > > > > of civility, as many such communities do, without impeding the flow of > > > > technical information a it, but you choose not to. > > > > > > Civility is in the eye of the moderator. I prefer my debate unfiltered... > > > > There was some belittling of Allen for asking about UBC. I don't think > > it added anything. Not even humor. Beck's initial response was a good > > one, clarifying and offering something to try, but at least one person > > jumped in with unhelpful comments. There were also informative and > > interesting replies, and in fact these made of the bulk of the thread. > > While this thread was relatively mild compared to some I think Allen has > > a point. There's just no need to escalate what should have been a purely > > technical discussion into an ad hominem attack. > > are you talking about Bret's reply about buzzwords? imo, that's what > that reply was about, buzzwords. there was nothing personal. see, > the way buzzwords work, is they get stuck in your (as in most people) > head, then they come out when you have a idea but don't know quite > how to express it. which is clearly the situation here. > > I think readers of OpenBSD lists are far too sensitive. there, that's > a personal 'attack' on all y'all. > > -- > jake...@sdf.lonestar.org > SDF Public Access UNIX System - http://sdf.lonestar.org > _ Check your Hotmail from your phone. http://go.microsoft.com/?linkid=9708121
Re: uvm_fault in uvm_rb_space
On Mon, 1 Feb 2010 23:01:46 -0800 Greg Steuck wrote: > The other day amd64 4.6-release-ish locked up on me while starting a > bunch of programs in X. I think the standard answer here is "can you please try running a current snapshot and report back of the issue remains?".
Re: uvm_pseg_get & uvm_pseg_lck fix
On Mon, Feb 01, 2010 at 23:30 -0500, Ted Unangst wrote:
> I think this fixes the problem with sleeping and holding pseg_lck.
>
perhaps it also makes sense to honour UVMPAGER_MAPIN_WAITOK flag.
what do you think?
> 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.h 11 Aug 2009 18:43:33 - 1.82
> +++ uvm_extern.h 2 Feb 2010 04:28:09 -
> @@ -517,8 +517,9 @@
> vaddr_t *, vsize_t, int,
> boolean_t, vm_map_t);
> vaddr_t uvm_km_valloc(vm_map_t, vsize_t);
> -vaddr_t uvm_km_valloc_align(vm_map_t, vsize_t, vsize_t);
> +vaddr_t uvm_km_valloc_try(vm_map_t, vsize_t);
> vaddr_t uvm_km_valloc_wait(vm_map_t, vsize_t);
> +vaddr_t uvm_km_valloc_align(struct vm_map *, vsize_t,
> vsize_t, int);
> vaddr_t uvm_km_valloc_prefer_wait(vm_map_t, vsize_t,
> voff_t);
> void *uvm_km_getpage(boolean_t, int *);
> Index: uvm_km.c
> ===
> RCS file: /home/tedu/cvs/src/sys/uvm/uvm_km.c,v
> retrieving revision 1.75
> diff -u -r1.75 uvm_km.c
> --- uvm_km.c 25 Jul 2009 12:55:40 - 1.75
> +++ uvm_km.c 2 Feb 2010 04:27:35 -
> @@ -571,11 +571,17 @@
> vaddr_t
> uvm_km_valloc(struct vm_map *map, vsize_t size)
> {
> - return(uvm_km_valloc_align(map, size, 0));
> + return(uvm_km_valloc_align(map, size, 0, 0));
> }
>
> vaddr_t
> -uvm_km_valloc_align(struct vm_map *map, vsize_t size, vsize_t align)
> +uvm_km_valloc_try(struct vm_map *map, vsize_t size)
> +{
> + return(uvm_km_valloc_align(map, size, 0, UVM_FLAG_TRYLOCK));
> +}
> +
> +vaddr_t
> +uvm_km_valloc_align(struct vm_map *map, vsize_t size, vsize_t align, int
> flags)
> {
> vaddr_t kva;
> UVMHIST_FUNC("uvm_km_valloc"); UVMHIST_CALLED(maphist);
> @@ -592,7 +598,7 @@
>
> if (__predict_false(uvm_map(map, &kva, size, uvm.kernel_object,
> UVM_UNKNOWN_OFFSET, align, UVM_MAPFLAG(UVM_PROT_ALL, UVM_PROT_ALL,
> - UVM_INH_NONE, UVM_ADV_RANDOM, 0)) != 0)) {
> + UVM_INH_NONE, UVM_ADV_RANDOM, flags)) != 0)) {
> UVMHIST_LOG(maphist, "<- done (no VM)", 0,0,0,0);
> return(0);
> }
> Index: uvm_pager.c
> ===
> RCS file: /home/tedu/cvs/src/sys/uvm/uvm_pager.c,v
> retrieving revision 1.54
> diff -u -r1.54 uvm_pager.c
> --- uvm_pager.c 22 Jul 2009 21:05:37 - 1.54
> +++ uvm_pager.c 2 Feb 2010 04:23:57 -
> @@ -138,7 +138,7 @@
> {
> KASSERT(pseg->start == 0);
> KASSERT(pseg->use == 0);
> - pseg->start = uvm_km_valloc(kernel_map, MAX_PAGER_SEGS * MAXBSIZE);
> + pseg->start = uvm_km_valloc_try(kernel_map, MAX_PAGER_SEGS * MAXBSIZE);
> }
>
> /*
Re: uvm_pseg_get & uvm_pseg_lck fix
On Tue, Feb 02, 2010 at 15:21 +0300, Mike Belopuhov wrote: > On Mon, Feb 01, 2010 at 23:30 -0500, Ted Unangst wrote: > > I think this fixes the problem with sleeping and holding pseg_lck. > > > > perhaps it also makes sense to honour UVMPAGER_MAPIN_WAITOK flag. > what do you think? > no, i'm sorry, this is wrong.
