Re: make -j and errors
On Wed, Sep 26, 2012 at 06:21:34PM +0200, Marc Espie wrote: but what about commands that take a long time to run ? Well, make already has a standard mechanism to flag those, that's called .PRECIOUS What if most everything takes a fairly long time to run? Say, largish C++ sources or whatever? Mark every target as .PRECIOUS? So, instead of the -dq quick death debugging option, I suggest we move to the following semantics: in case of an error, send ^C to all jobs making targets that are not tagged .PRECIOUS, wait for everything to come back, and that's it... I think currently running jobs should be allowed to finish, as the default behavior. Why would you want to stop (at least potentially) successful work in progress? Is it because some very prominent things are done using a build-from-scratch every time? For those things, I agree that forcibly dying ASAP would save time and frustration. But for the more correct use of being able to fix a problem and have make pick up where it left off on the next invocation, your idea does not save time and frustration. If that's the case, then things that need a full build from scratch should know to invoke make with the proper flags. Kanpai! Darrin
Re: random() always returns 0 with srandom(0)
On Wed, Mar 21, 2012 at 12:37:47PM -0500, Jeremy C. Reed wrote: My co-worker was troubleshooting why some of our unittests (that work on multiple operating systems and architectures) failed on OpenBSD and saw that if you call srandom(0) to initialize the RNG, random() will always return 0. (I was able to reproduce this.) Nice work by your co-working for pinpointing the problem, finding how the issue was dealt with elsewhere, and proposing solutions, and then making sure word got to an appropriate list. Please pass along my thanks as an OpenBSD user. -- http://code.phxbsd.com/
Re: Help with Port(s)?
On Thu, Oct 27, 2011 at 03:10:54PM -0400, cody chandler wrote: I'm interested in helping with port(s). I'm new and have a lot to learn but if someone would not mind teaching I'd like to help! See http://www.openbsd.org/faq/ports/index.html for starters. -- http://code.phxbsd.com/
Re: better cpu throttling
On Wed, Jun 30, 2010 at 07:59:00PM -0600, Tobias Weingartner wrote: On Wednesday, June 30, Darrin Chandler wrote: What you're saying is true, but that's not the only use case. Streaming media may not benefit from 100% cpu but may not be able to work properly at 0%. The same goes for other common tasks as well. Running at 30% or 50% will indeed save power for those cases where running at 100% won't make what you're doing finish faster and running at 0% won't work. You're assuming that the switch is so slow that running at a constant average factor (of whatever) is better than simply switching to high mode when there are things to do (not in idle loop), and going back to low mode when there is nothing left to do (in idle loop/etc). The system could litteraly be switching high/low several thousand times a second... Try the diff, see if it works for you. It's been pointed out to me off list. Of course I should have tested first and then came with issues as I found them. -- 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: better cpu throttling
On Wed, Jun 30, 2010 at 03:34:14PM -0400, Ted Unangst wrote: On Wed, Jun 30, 2010 at 3:23 PM, Luis Henriques luis.hen...@gmail.com wrote: Probably, a silly question, but here it goes: With this patch, I will not be able to set the perflevel to, say, 50% and keep the system using that performance level forever. Is this correct? I guess that with current apmd we are able to do this. If both of these two statements are true (maybe they are not!), we should also have a mechanism to disable this code (either at runtime or compile time). You are correct, but I wonder why you would ever want a machine only running at 50% all the time. When it is busy, it's still slow, and when it's not, it's still using power. This only makes sense once you think of it or have it mentioned to you, as I well know. ;-) We are thinking that states other than 0 and 100 are not very useful. This is true when you have a bucket of work to do, like compiling a kernel or something. It's less true when you are playing media, where a 20 minute video takes 20 minutes regardless of cpu at 100% or cpu at 30%. But this is not the final diff. It will probably have some means of control eventually, until then, it'd be nice if people evaluated if this meets their needs. :) -- 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: better cpu throttling
On Wed, Jun 30, 2010 at 11:44:46PM +0200, Peter Hessler wrote: On 2010 Jun 30 (Wed) at 22:25:45 +0100 (+0100), Luis Henriques wrote: :Eventually there are usage scenarios where setting the maximum :performance to 50% (or whatever value) may make sense -- if you want to :save some power, for example. It doesn't really save any power. I've done tests while doing compiles at apm -L vs autoscaling. I get significatly longer battery life with cranking up to 100% speed during the compile, then going back down to 0% vs staying at 0% the entire time. What you're saying is true, but that's not the only use case. Streaming media may not benefit from 100% cpu but may not be able to work properly at 0%. The same goes for other common tasks as well. Running at 30% or 50% will indeed save power for those cases where running at 100% won't make what you're doing finish faster and running at 0% won't work. -- 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 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: 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 Mon, Feb 01, 2010 at 03:05:37PM -0700, Nick Bender wrote: On Mon, Feb 1, 2010 at 2:46 PM, Bob Beck b...@ualberta.ca wrote: On 1 February 2010 14:09, Donald Allen donaldcal...@gmail.com 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. -- 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: Make remote debugging with KGDB possible
On Tue, Dec 15, 2009 at 12:56:24PM -0500, Simon Perreault wrote:
Hello,
This patch makes remote debugging with KGDB possible. It fixes a known bug,
see
e.g. http://kerneltrap.org/mailarchive/openbsd-misc/2008/10/7/3537224.
Simon
P.S. This is my first contribution, please tell me if I did anything wrong.
If this doesn't get picked up then use sendbug(1) including a
description of the problem, how to reproduce, and your patch. In fact,
that's probably the best thing to do anyway. :)
Index: sys/dev/isa/com_isa.c
===
RCS file: /cvs/src/sys/dev/isa/com_isa.c,v
retrieving revision 1.4
diff -N -u sys/dev/isa/com_isa.c
--- sys/dev/isa/com_isa.c 24 Oct 2005 14:22:34 - 1.4
+++ sys/dev/isa/com_isa.c 15 Dec 2009 17:54:34 -
@@ -129,7 +129,7 @@
iobase = ia-ia_iobase;
iot = ia-ia_iot;
-#ifdef KGBD
+#ifdef KGDB
if ((iobase != comconsaddr)
(iobase != com_kgdb_addr)) {
#else
--
DNS64 open-source -- http://ecdysis.viagenie.ca
STUN/TURN server-- http://numb.viagenie.ca
vCard 4.0 -- http://www.vcarddav.org
--
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: kernel hacking
On Thu, Dec 10, 2009 at 10:40:16AM -0700, Bob Beck wrote: 2009/12/10 Bret S. Lambert bret.lamb...@gmail.com: On Thu, Dec 10, 2009 at 02:24:00PM -0300, Robert Yuri wrote: which the best way to learn about OpenBSD kernel ? I found a bunch of docs from FreeBSD site such as developer's handbook at http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ , there any same that for openbsd ? /usr/src/sys/ /usr/src/sys/nfs /usr/src/sys/kern/vfs.* a bottle of red wine lots of lube and a teacup to collect your tears. nfs? ditch the teacup and get a funnel, because the tears will easily fill the empty wine bottle. -- 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: too many cpus
On Mon, Dec 07, 2009 at 11:34:31AM -0500, Ted Unangst wrote: Thanks, I don't think we sync any more, but it's reasonable to use the same option, and while I don't normally think of using number options, this is probably even better than 'c'. Switching to '1' will save me minor amounts of muscle memory induced grief when bouncing around different systems. -- 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: ksh vi mode werase (^W) handling
On Tue, Jun 09, 2009 at 06:49:06AM -0700, Darrin Chandler wrote: Hmm. It's not doing that for me. Both 'b' and 'B' seem to be working, with 'b' using '/' and other punctuation, and 'B' only caring about ' '. Can you see if you have to do anything special to break it? Of course I have 1 computer without the new ksh, and guess where I was testing? I will try a little later, and I think you are right. -- 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
