Re: How to diagnose system freezes?
One of my 9.1-BETA1 systems periodically freezes. If sound was playing, it would usually cycle with a very short period. so interrupts are off. And system stops being sensitive to keyboard/mouse. Also ping of this system doesn't get a response. I would normally think that this is the faulty memory. But memory was recently replaced and tested with memtest+ for hours both before and after freezes and it passes all tests. this is not a proof but if you can compile generic with make -j50 it is quite a good proof memory is not.. One out of the ordinary thing that is running on this system is nvidia driver. this is the most probable reason. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
On cooperative work [Was: Re: newbus' ivar's limitation..]
Hi, On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao wrote: > > You don't want to work cooperatively. > Why is it that mbuf's refactoring consultation is being held in internal, private, committers-and-invite-only-restricted meeting at BSDCan ? Why is it that so much review and discussion on changes are held privately ? - Arnaud ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao wrote: >> >> You don't want to work cooperatively. >> > Why is it that mbuf's refactoring consultation is being held in > internal, private, committers-and-invite-only-restricted meeting at > BSDCan ? > > Why is it that so much review and discussion on changes are held privately ? Arnaud, belive me, to date I don't recall a single major technical decision that has been settled exclusively in private (not subjected to peer review) and in particular in person (e-mail help you focus on a lot of different details that you may not have under control when talking to people, etc). Sometimes it is useful that a limited number of developers is involved in initial brainstorming of some works, but after this period constructive people usually ask for peer review publishing their plans on the mailing lists or other media. If you don't see any public further discussion this may be meaning: a) the BSDCan meetings have been fruitless and there is no precise plan/roadmap/etc. b) there is still not consensus on details and you can always publically asked on what was decided and what not. Just send a mail to interested recipients and CC any FreeBSD mailing list. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Hi, On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: > On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe wrote: >> Hi, >> >> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao wrote: >>> >>> You don't want to work cooperatively. >>> >> Why is it that mbuf's refactoring consultation is being held in >> internal, private, committers-and-invite-only-restricted meeting at >> BSDCan ? >> >> Why is it that so much review and discussion on changes are held privately ? > > Arnaud, > belive me, to date I don't recall a single major technical decision > that has been settled exclusively in private (not subjected to peer > review) and in particular in person (e-mail help you focus on a lot of > different details that you may not have under control when talking to > people, etc). > Whose call is it to declare something worth public discussion ? No one. Every time I see a "Suggested by:", "Submitted by:", "Reported by:", and especially "Approved by:", there should to be a public reference of the mentioned communication. > Sometimes it is useful that a limited number of developers is involved > in initial brainstorming of some works, > Never. > but after this period > constructive people usually ask for peer review publishing their plans > on the mailing lists or other media. > Again, never. By doing so, you merely put the community in a situation where, well, "We, committers, have come with this, you can either accept or STFU, but no major changes will be made because we decided so." The callout-ng conference at BSDCan was just beautiful, it was basically: Speaker: "we will do this" Audience: "how about this situation ? What you will do will not work." Speaker: "thank you for listening, end of the conference" It was beautiful to witness. > If you don't see any public further discussion this may be meaning: > a) the BSDCan meetings have been fruitless and there is no precise > plan/roadmap/etc. > so not only you make it private, but it shamelessly failed... > b) there is still not consensus on details > Then the discussion should stop, public records are kept for reference in the future. There is no problem with this. > and you can always publically asked on what was decided and what not. > Just send a mail to interested recipients and CC any FreeBSD mailing > list. > This is not the way "openness" should be about. - Arnaud > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 8/1/12, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: >> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe >> wrote: >>> Hi, >>> >>> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao >>> wrote: You don't want to work cooperatively. >>> Why is it that mbuf's refactoring consultation is being held in >>> internal, private, committers-and-invite-only-restricted meeting at >>> BSDCan ? >>> >>> Why is it that so much review and discussion on changes are held >>> privately ? >> >> Arnaud, >> belive me, to date I don't recall a single major technical decision >> that has been settled exclusively in private (not subjected to peer >> review) and in particular in person (e-mail help you focus on a lot of >> different details that you may not have under control when talking to >> people, etc). >> > Whose call is it to declare something worth public discussion ? No one. > > Every time I see a "Suggested by:", "Submitted by:", "Reported by:", > and especially "Approved by:", there should to be a public reference > of the mentioned communication. Not necessarilly. Every developer must ensure to produce a quality work, with definition of "quality" being discretional. Some people fail this expectation, while others do very good. As a general rule, some people send patches to experts on the matter and they just trust their judgment, others also full-fill testing cycles by thirdy part people, others again ask for public reviews. Often this process is adapted based on the dimension of the work and the number of architectural changes it introduces. As a personal matter, for a big architectural change things I would *personally* do are: - Prepare a master-plan with experts of the matter - Post a plan (after having achived consensus) on the public mailing list for further discussions - Adjust the plan based on public feedbacks (if necessary) - Implement the plan - Ask the experts if they have objections to the implementation - Ask testers to perform some stress-testing - Ask testers to perform benchmark (if I find people interested in that) - Send out to the public mailing list for public review - Integrate suggestions - Ask testers to stress-test again - Commit I think this model in general works fairly well, but people may have different ideas on that, meaning that people may want to not involve thirdy part for testing or review. This is going to be risky and lower the quality of their work but it is their call. >> Sometimes it is useful that a limited number of developers is involved >> in initial brainstorming of some works, >> > Never. > >> but after this period >> constructive people usually ask for peer review publishing their plans >> on the mailing lists or other media. >> > Again, never. By doing so, you merely put the community in a situation > where, well, "We, committers, have come with this, you can either > accept or STFU, but no major changes will be made because we decided > so." You are forgetting one specific detail: you can always review a work *after* it entered the tree. This is something you would never do, but sometimes, when poor quality code is committed there is nothing else you can do than just raise your concern after it is in. > The callout-ng conference at BSDCan was just beautiful, it was basically: > > Speaker: "we will do this" > Audience: "how about this situation ? What you will do will not work." > Speaker: "thank you for listening, end of the conference" > > It was beautiful to witness. Not sure if you realized but I was what you mention "Audience". I think you are referring to a specific case where a quick heads-up on a summer of code project has been presented, you cannot really believe all the technical discussion around FreeBSD evolve this way. >> If you don't see any public further discussion this may be meaning: >> a) the BSDCan meetings have been fruitless and there is no precise >> plan/roadmap/etc. >> > so not only you make it private, but it shamelessly failed... And so? I think you have a wrong point of view of what is shamelessly... I'm working on the same project since 6 months, i thought I could finish it in 1 but then I understood that in order to get the quality I was hoping I had to do more work... does it qualify as failed, according to your standard? >> b) there is still not consensus on details >> > Then the discussion should stop, public records are kept for reference > in the future. There is no problem with this. > >> and you can always publically asked on what was decided and what not. >> Just send a mail to interested recipients and CC any FreeBSD mailing >> list. >> > This is not the way "openness" should be about. There is not much more you can do when people don't share details and discussions automatically. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/l
Re: How to diagnose system freezes?
On Tue, Jul 31, 2012 at 11:14 PM, Yuri wrote: > On 07/31/2012 17:50, Mark Saad wrote: >> >> Yuri >>Install sysutils/mcelog and try running the example included . While >> not a complete definitative hardware test it can report other hardware >> issues that memtest86+ misses and it can be run on line in multiuser mode >> and via cron . > > > Thanks for suggesting this. I have a question, however. Let's say 'mcelog > --daemon' runs and encounters some MCE and logs it. Wouldn't this record be > lost during the subsequent ungraceful (poweroff) reboot? Nonfatal MCEs, if > any, will stay but what about the fatal one? > Daemon mode does not work on FreeBSD , and on most if not all linux distros it runs via cron. In this example you can have it write the logged results via syslog and hopefully you should be able to review them. /usr/local/bin/mcelog --ignorenodev --filter --no-dmi --syslog or /usr/local/bin/mcelog --no-dmi > /var/log/mce.log Now that being said , when mcelog reports an error , it continuously reports the error, each time mcelog is run, power cycling did not clear the mcelog . -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How to diagnose system freezes?
On Tue, Jul 31, 2012 at 5:02 PM, Yuri wrote: > One of my 9.1-BETA1 systems periodically freezes. If sound was playing, it > would usually cycle with a very short period. And system stops being > sensitive to keyboard/mouse. Also ping of this system doesn't get a > response. > I would normally think that this is the faulty memory. But memory was > recently replaced and tested with memtest+ for hours both before and after > freezes and it passes all tests. > One out of the ordinary thing that is running on this system is nvidia > driver. But the freezes happen even when there is no graphics activity. > Another out of the ordinary thing is that the kernel is built for DTrace. > But DTrace was never used in the sessions that had a freeze. > > What is the way to diagnose this problem? As an aside, where do you see things lockup (Xorg, Firefox, etc)? Can you remain sshed into the box or not? What sound driver are you using and how are you playing sound/video? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Hi, On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao wrote: > On 8/1/12, Arnaud Lacombe wrote: >> Hi, >> >> On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: >>> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe >>> wrote: Hi, On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao wrote: > > You don't want to work cooperatively. > Why is it that mbuf's refactoring consultation is being held in internal, private, committers-and-invite-only-restricted meeting at BSDCan ? Why is it that so much review and discussion on changes are held privately ? >>> >>> Arnaud, >>> belive me, to date I don't recall a single major technical decision >>> that has been settled exclusively in private (not subjected to peer >>> review) and in particular in person (e-mail help you focus on a lot of >>> different details that you may not have under control when talking to >>> people, etc). >>> >> Whose call is it to declare something worth public discussion ? No one. >> >> Every time I see a "Suggested by:", "Submitted by:", "Reported by:", >> and especially "Approved by:", there should to be a public reference >> of the mentioned communication. > > Not necessarilly. Every developer must ensure to produce a quality > work, with definition of "quality" being discretional. Some people > fail this expectation, while others do very good. As a general rule, > some people send patches to experts on the matter and they just trust > their judgment, others also full-fill testing cycles by thirdy part > people, others again ask for public reviews. Often this process is > adapted based on the dimension of the work and the number of > architectural changes it introduces. > > As a personal matter, for a big architectural change things I would > *personally* do are: > - Prepare a master-plan with experts of the matter > - Post a plan (after having achived consensus) on the public mailing > list for further discussions > - Adjust the plan based on public feedbacks (if necessary) > - Implement the plan > - Ask the experts if they have objections to the implementation > - Ask testers to perform some stress-testing > - Ask testers to perform benchmark (if I find people interested in that) > - Send out to the public mailing list for public review > - Integrate suggestions > - Ask testers to stress-test again > - Commit > > I think this model in general works fairly well, > I agree. > but people may have > different ideas on that, meaning that people may want to not involve > thirdy part for testing or review. This is going to be risky and lower > the quality of their work but it is their call. > >>> Sometimes it is useful that a limited number of developers is involved >>> in initial brainstorming of some works, >>> >> Never. >> >>> but after this period >>> constructive people usually ask for peer review publishing their plans >>> on the mailing lists or other media. >>> >> Again, never. By doing so, you merely put the community in a situation >> where, well, "We, committers, have come with this, you can either >> accept or STFU, but no major changes will be made because we decided >> so." > > You are forgetting one specific detail: you can always review a work > *after* it entered the tree. This is something you would never do, but > sometimes, when poor quality code is committed there is nothing else > you can do than just raise your concern after it is in. > Unfortunately, not. First, the developer will certainly have moved on after the commit, API may have been changed tree-wide, etc. Then, time is likely to have passed between the time you figure potential regression or bugs, which makes the first point even more problematic. Finally, if my point of view is being ignored *before* it goes to the tree, do you really expect it will be considered *after* ? >From my external point of view, committers not only have the possibility, but *do* commit mess in the tree without non-committers could say or do anything, just as well as committers being able to arbitrarily close PR even if the original reporter disagree. >> The callout-ng conference at BSDCan was just beautiful, it was basically: >> >> Speaker: "we will do this" >> Audience: "how about this situation ? What you will do will not work." >> Speaker: "thank you for listening, end of the conference" >> >> It was beautiful to witness. > > Not sure if you realized but I was what you mention "Audience". I > think you are referring to a specific case where a quick heads-up on a > summer of code project has been presented, you cannot really believe > all the technical discussion around FreeBSD evolve this way. > indeed, but that was still the case back then. >>> If you don't see any public further discussion this may be meaning: >>> a) the BSDCan meetings have been fruitless and there is no precise >>> plan/roadmap/etc. >>> >> so not only you make it private, but it shamelessly failed... > > And so? I think you have a wrong point of view of what
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Date: Wed, 1 Aug 2012 15:45:35 -0400 From: Arnaud Lacombe One obvious problem in FreeBSD is that committers are prosecutor, judge and jury altogether. As a user, I accept this. I think if you can make a meaningful contribution to FreeBSD developments in the design stages, then become a committer. Otherwise contribute as a user - testing and bug reports mainly. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Any interested party is very welcome to approach a developer and get added to the developer summits. Plenty of the people at the most recent developer summit weren't @freebsd.org committers - we had plenty of representation from companies using FreeBSD. If you want to participate, just ask a friendly developer who is going to the developer summit to sponsor you in going. You're pleasant in person, so I'd have no problem sponsoring you if I am going to an event. :) And/or, work with warner to get improvements into the tree and someone will sponsor a commit bit for you. Perhaps we as developers should more openly publish the results of developer summits. But as I said, they're not "closed" - they're just "invite only for non-developers." We're not going to exclude anyone from coming unless they really ARE going to just sit there and troll. You're motivated, you're enthusiastic and you want to see things change for the better. You're also not confrontational in person. I have no problem with you coming along. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 8/1/12, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao wrote: [ trimm ] >> You are forgetting one specific detail: you can always review a work >> *after* it entered the tree. This is something you would never do, but >> sometimes, when poor quality code is committed there is nothing else >> you can do than just raise your concern after it is in. >> > Unfortunately, not. First, the developer will certainly have moved on > after the commit, API may have been changed tree-wide, etc. Then, time > is likely to have passed between the time you figure potential > regression or bugs, which makes the first point even more problematic. > Finally, if my point of view is being ignored *before* it goes to the > tree, do you really expect it will be considered *after* ? There is one thing you are not considering: committers are as powerless as non-committers in face of someone stuck on his own buggy ideas/implementations. Often people are just convinced their idea is better than your and they won't change their mind, regardeless their status in the opensource community. And there is nothing more you can do apart from learning how to deal with such situations. Granted, there are projects blowing up and people abbandoning successful opensource community because of this. > From my external point of view, committers not only have the > possibility, but *do* commit mess in the tree without non-committers > could say or do anything, just as well as committers being able to > arbitrarily close PR even if the original reporter disagree. You should look at svn-src@ more often I suspect. You will see how many discussions are in there. >> And so? I think you have a wrong point of view of what is >> shamelessly... I'm working on the same project since 6 months, i >> thought I could finish it in 1 but then I understood that in order to >> get the quality I was hoping I had to do more work... does it qualify >> as failed, according to your standard? >> > not specifically, but at the end of that project of your, I would run > a post-mortem meeting to see what went correctly and where things got > out-of-control. Arnaud, my friend, I have a new for you: this stuff is hard. I see the brightest people I've ever met stuck for weeks on problems, thinking about how to fix them in elegant way. Sometimes things get understimated, sometimes not, this is just part of the game. But an important thing is accepting critics in costructive way and learn. This makes things much easier. > As for the mbuf meeting, all I can find from it online is: > > http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html > > which is not worth much... Rather than doing things internally, maybe > it is time to open up... oh, wait, you will certainly come to the > community with a design plan, figure out it's not gonna work while > doing the implementation, change the design plan while implementing, > go public with a +3k/-2k loc change patch, ask for benediction, go > ahead and commit it up until someone comes with an obvious design flaw > which would render the change pretty much useless, but there will be > man-month of work to fix it, so it's never gonna be done. > > One obvious problem in FreeBSD is that committers are prosecutor, > judge and jury altogether. That's not the first time I point this out. You are drammatizing. As I already told, please, if you are interested in this topic, ask for the state of the discussion and ask politely to be included from now on. Nobody will reject you only because you don't have a @freebsd.org. b) there is still not consensus on details >>> Then the discussion should stop, public records are kept for reference >>> in the future. There is no problem with this. >>> and you can always publically asked on what was decided and what not. Just send a mail to interested recipients and CC any FreeBSD mailing list. >>> This is not the way "openness" should be about. >> >> There is not much more you can do when people don't share details and >> discussions automatically. >> > keep reporting regressions, interface flaws, POLA violations, ABI > breakages, bugs, etc. I agree. But with the correct and humble mindset and avoiding aggressive behaviour. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 1:05 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao wrote: > > On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe > wrote: > >> Hi, > >> > >> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao > wrote: > >>> > >>> You don't want to work cooperatively. > >>> > >> Why is it that mbuf's refactoring consultation is being held in > >> internal, private, committers-and-invite-only-restricted meeting at > >> BSDCan ? > >> > >> Why is it that so much review and discussion on changes are held > privately ? > > > > Arnaud, > > belive me, to date I don't recall a single major technical decision > > that has been settled exclusively in private (not subjected to peer > > review) and in particular in person (e-mail help you focus on a lot of > > different details that you may not have under control when talking to > > people, etc). > > > Whose call is it to declare something worth public discussion ? No one. > > Every time I see a "Suggested by:", "Submitted by:", "Reported by:", > and especially "Approved by:", there should to be a public reference > of the mentioned communication. > > > Sometimes it is useful that a limited number of developers is involved > > in initial brainstorming of some works, > > > Never. > > > but after this period > > constructive people usually ask for peer review publishing their plans > > on the mailing lists or other media. > > > Again, never. By doing so, you merely put the community in a situation > where, well, "We, committers, have come with this, you can either > accept or STFU, but no major changes will be made because we decided > so." > > The callout-ng conference at BSDCan was just beautiful, it was basically: > > Speaker: "we will do this" > Audience: "how about this situation ? What you will do will not work." > Speaker: "thank you for listening, end of the conference" > > It was beautiful to witness. > > > If you don't see any public further discussion this may be meaning: > > a) the BSDCan meetings have been fruitless and there is no precise > > plan/roadmap/etc. > > > so not only you make it private, but it shamelessly failed... > > > b) there is still not consensus on details > > > Then the discussion should stop, public records are kept for reference > in the future. There is no problem with this. > > > and you can always publically asked on what was decided and what not. > > Just send a mail to interested recipients and CC any FreeBSD mailing > > list. > > > This is not the way "openness" should be about. > I attended the developer summit, and attended the mbuf working group ... I'm also not a committer. My ASCII transcription of the results of the white-board session were posted to freebsd-arch in june, the post is available for viewing here: http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html When the information is readily available (as it is in this case), there is a clear case of confusing one's inability to engage the entirety of FreeBSD with "openness". If you are concerned about the mbuf decisions, you should be subscribed to (and reading) the arch list. > - Arnaud > > > Attilio > > > > > > -- > > Peace can only be achieved by understanding - A. Einstein > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > -- regards, matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Hi, On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: > Any interested party is very welcome to approach a developer and get > added to the developer summits. Plenty of the people at the most > recent developer summit weren't @freebsd.org committers - we had > plenty of representation from companies using FreeBSD. > > If you want to participate, just ask a friendly developer who is going > to the developer summit to sponsor you in going. You're pleasant in > person, so I'd have no problem sponsoring you if I am going to an > event. :) > I have a very deep, quasi-philosophical, trouble/problem with that whole idea of sponsor-requirement to attend a such meeting. There is just something which does not feel right about it. From my point of view, this is a matter of common sense, focus is gonna be very narrow and deeply technical. Attendee should go there only if they think they will give positive feedback. As for myself, I would not attend a developer meeting on the fiber-channel over infiniband optimization, but would attend a developer meeting on next-generation mbuf. Now, maybe I'll just push the door of some developer meeting I'd be interested in during next BSDCan, and see what happen :-) The outcome might be interesting to study in a social interaction, prisoner dilemma related, point-of-view. - Arnaud > And/or, work with warner to get improvements into the tree and someone > will sponsor a commit bit for you. > > Perhaps we as developers should more openly publish the results of > developer summits. But as I said, they're not "closed" - they're just > "invite only for non-developers." We're not going to exclude anyone > from coming unless they really ARE going to just sit there and troll. > You're motivated, you're enthusiastic and you want to see things > change for the better. You're also not confrontational in person. I > have no problem with you coming along. > > > Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 8/1/12 12:45 PM, Arnaud Lacombe wrote: Hi, On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao wrote: As for the mbuf meeting, all I can find from it online is: http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html actually nothing has happenned on this yet that I know of, which is why there has been no action to see. We all agree that it is an item to put on our agenda but until there is someone who gets the free time it's just a "sanctioned priority item" which is not worth much... Rather than doing things internally, maybe it is time to open up... oh, wait, you will certainly come to the community with a design plan, figure out it's not gonna work while doing the implementation, change the design plan while implementing, go public with a +3k/-2k loc change patch, ask for benediction, go ahead and commit it up until someone comes with an obvious design flaw which would render the change pretty much useless, but there will be man-month of work to fix it, so it's never gonna be done. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Aug 1, 2012, at 3:39 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: >> Any interested party is very welcome to approach a developer and get >> added to the developer summits. Plenty of the people at the most >> recent developer summit weren't @freebsd.org committers - we had >> plenty of representation from companies using FreeBSD. >> >> If you want to participate, just ask a friendly developer who is going >> to the developer summit to sponsor you in going. You're pleasant in >> person, so I'd have no problem sponsoring you if I am going to an >> event. :) >> > I have a very deep, quasi-philosophical, trouble/problem with that > whole idea of sponsor-requirement to attend a such meeting. There is > just something which does not feel right about it. From my point of > view, this is a matter of common sense, focus is gonna be very narrow > and deeply technical. Attendee should go there only if they think they > will give positive feedback. As for myself, I would not attend a > developer meeting on the fiber-channel over infiniband optimization, > but would attend a developer meeting on next-generation mbuf. > > Now, maybe I'll just push the door of some developer meeting I'd be > interested in during next BSDCan, and see what happen :-) The outcome > might be interesting to study in a social interaction, prisoner > dilemma related, point-of-view. Given how ridiculously easy it is to get a proper invite, there's not need to be a jerk just to prove an obscure philosophical point about attendance. There's plenty of time to do that over the technical points being discussed. Warner > - Arnaud > >> And/or, work with warner to get improvements into the tree and someone >> will sponsor a commit bit for you. >> >> Perhaps we as developers should more openly publish the results of >> developer summits. But as I said, they're not "closed" - they're just >> "invite only for non-developers." We're not going to exclude anyone >> from coming unless they really ARE going to just sit there and troll. >> You're motivated, you're enthusiastic and you want to see things >> change for the better. You're also not confrontational in person. I >> have no problem with you coming along. >> >> >> Adrian > ___ > freebsd-curr...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 2:39 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: >> Any interested party is very welcome to approach a developer and get >> added to the developer summits. Plenty of the people at the most >> recent developer summit weren't @freebsd.org committers - we had >> plenty of representation from companies using FreeBSD. >> >> If you want to participate, just ask a friendly developer who is going >> to the developer summit to sponsor you in going. You're pleasant in >> person, so I'd have no problem sponsoring you if I am going to an >> event. :) >> > I have a very deep, quasi-philosophical, trouble/problem with that > whole idea of sponsor-requirement to attend a such meeting. There is > just something which does not feel right about it. From my point of > view, this is a matter of common sense, focus is gonna be very narrow > and deeply technical. Attendee should go there only if they think they > will give positive feedback. As for myself, I would not attend a > developer meeting on the fiber-channel over infiniband optimization, > but would attend a developer meeting on next-generation mbuf. > > Now, maybe I'll just push the door of some developer meeting I'd be > interested in during next BSDCan, and see what happen :-) The outcome > might be interesting to study in a social interaction, prisoner > dilemma related, point-of-view. Arnaud, I suggest that you attend some Internet Engineering Task Force Working Group meetings. They are, by rule, open. There is no procedure for excluding anyone. While this may be open, it can be painfully wasteful of time as one person can tie up the entire meeting and ensure nothing is accomplished. It happens all too often and has resulted in working groups being shut down as they have no chance on reaching consensus. One person can't block consensus in theory. but he can tie up so much time that no actual work is done.This is one of the primary reasons I stopped attending IETF meetings as opposed to being active on WG mail lists where a lot of the real work is done and annoying messages can simply be ignored. For a much smaller endeavor, like FreeBSD, this is simply unacceptable as is a brainstorming type of meeting with too many people present. almost all really effective projects are done by one or two people and they need the input of a fairly small set of other concerned people to vet the work. This has worked well, if not perfectly, for FreeBSD and many other projects. It may not be perfect, but trying to accomplish something that comes under the heading of brainstorming in a truly open environment is a wonderful goal, but really is not efficient. And, no, I don't expect you to agree. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Enumerating sleeping threads
Hello, What is the best way to enumerate the sleeping threads via sleepqueue(9)? Furthermore, when enumerating the threads that are on the run queue, what locks are needed, if any? Thank you. -- Daniel Rudy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Enumerating sleeping threads
On 2012/8/2 10:12, Daniel Rudy wrote: Hello, What is the best way to enumerate the sleeping threads via sleepqueue(9)? Furthermore, when enumerating the threads that are on the run queue, what locks are needed, if any? sleepqueue hash bucket is private data structure in subr_sleepqueue.c, I think you can not access it outside of the file. One way to enumerate the sleeping threads is iterating all threads in the system, and check their states. proc.h contains two macros: FOREACH_PROC_IN_SYSTEM FOREACH_THREAD_IN_PROC To access thread state, you should use thread lock, call thread_lock() and thread_unlock(). thread lock is not fixed, it might be sleep-queue's spinlock or per-cpu runqueue lock, there even is a blocked spin-lock for intermediate state change. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Enumerating sleeping threads
--- On Wed, 8/1/12, David Xu wrote: From: David Xu Subject: Re: Enumerating sleeping threads To: "Daniel Rudy" Cc: freebsd-hackers@freebsd.org Date: Wednesday, August 1, 2012, 7:25 PM On 2012/8/2 10:12, Daniel Rudy wrote: > Hello, > > What is the best way to enumerate the sleeping threads via > sleepqueue(9)? Furthermore, when enumerating the threads that are on > the run queue, what locks are needed, if any? sleepqueue hash bucket is private data structure in subr_sleepqueue.c, I think you can not access it outside of the file. One way to enumerate the sleeping threads is iterating all threads in the system, and check their states. proc.h contains two macros: FOREACH_PROC_IN_SYSTEM FOREACH_THREAD_IN_PROC To access thread state, you should use thread lock, call thread_lock() and thread_unlock(). thread lock is not fixed, it might be sleep-queue's spinlock or per-cpu runqueue lock, there even is a blocked spin-lock for intermediate state change. > Thank you. > The problem is that I want to avoid using proc.h in this. I'm considering adding a function to subr_sleepqueue.c to export the data structures, or at least export a PID list. The reason why I am doing it this way is security related. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Hi, On Wed, Aug 1, 2012 at 7:28 PM, Warner Losh wrote: > > On Aug 1, 2012, at 3:39 PM, Arnaud Lacombe wrote: > >> Hi, >> >> On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: >>> Any interested party is very welcome to approach a developer and get >>> added to the developer summits. Plenty of the people at the most >>> recent developer summit weren't @freebsd.org committers - we had >>> plenty of representation from companies using FreeBSD. >>> >>> If you want to participate, just ask a friendly developer who is going >>> to the developer summit to sponsor you in going. You're pleasant in >>> person, so I'd have no problem sponsoring you if I am going to an >>> event. :) >>> >> I have a very deep, quasi-philosophical, trouble/problem with that >> whole idea of sponsor-requirement to attend a such meeting. There is >> just something which does not feel right about it. From my point of >> view, this is a matter of common sense, focus is gonna be very narrow >> and deeply technical. Attendee should go there only if they think they >> will give positive feedback. As for myself, I would not attend a >> developer meeting on the fiber-channel over infiniband optimization, >> but would attend a developer meeting on next-generation mbuf. >> >> Now, maybe I'll just push the door of some developer meeting I'd be >> interested in during next BSDCan, and see what happen :-) The outcome >> might be interesting to study in a social interaction, prisoner >> dilemma related, point-of-view. > > Given how ridiculously easy it is to get a proper invite, there's not need to > be a jerk just to prove an obscure philosophical point about attendance. > There's plenty of time to do that over the technical points being discussed. > Let me explain my thoughts: I do not recognize the committers legitimacy to give such invite, and to some extend, I do not recognize committers self-given legitimacy altogether. This do not mean I'd praised a structure-less project; quite the opposite actually. Starting from that, I will certainly not defer to anybody to request such invite or commit bit. Feel free to kick me out of the meeting room if you want to; I would have proved my point. Now, if invites are so easy to get, just get rid of it. It's a worthless, cumbersome item. - Arnaud ps: please, do not get me wrong, I would apply this policy to anybody who propose to help. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Aug 1, 2012, at 9:28 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Aug 1, 2012 at 7:28 PM, Warner Losh wrote: >> >> On Aug 1, 2012, at 3:39 PM, Arnaud Lacombe wrote: >> >>> Hi, >>> >>> On Wed, Aug 1, 2012 at 4:06 PM, Adrian Chadd wrote: Any interested party is very welcome to approach a developer and get added to the developer summits. Plenty of the people at the most recent developer summit weren't @freebsd.org committers - we had plenty of representation from companies using FreeBSD. If you want to participate, just ask a friendly developer who is going to the developer summit to sponsor you in going. You're pleasant in person, so I'd have no problem sponsoring you if I am going to an event. :) >>> I have a very deep, quasi-philosophical, trouble/problem with that >>> whole idea of sponsor-requirement to attend a such meeting. There is >>> just something which does not feel right about it. From my point of >>> view, this is a matter of common sense, focus is gonna be very narrow >>> and deeply technical. Attendee should go there only if they think they >>> will give positive feedback. As for myself, I would not attend a >>> developer meeting on the fiber-channel over infiniband optimization, >>> but would attend a developer meeting on next-generation mbuf. >>> >>> Now, maybe I'll just push the door of some developer meeting I'd be >>> interested in during next BSDCan, and see what happen :-) The outcome >>> might be interesting to study in a social interaction, prisoner >>> dilemma related, point-of-view. >> >> Given how ridiculously easy it is to get a proper invite, there's not need >> to be a jerk just to prove an obscure philosophical point about attendance. >> There's plenty of time to do that over the technical points being discussed. >> > Let me explain my thoughts: I do not recognize the committers > legitimacy to give such invite, and to some extend, I do not recognize > committers self-given legitimacy altogether. This do not mean I'd > praised a structure-less project; quite the opposite actually. > Starting from that, I will certainly not defer to anybody to request > such invite or commit bit. Feel free to kick me out of the meeting > room if you want to; I would have proved my point. I think this proves the point everybody has been saying: you are being needlessly contrary and confrontational. Warner > Now, if invites are so easy to get, just get rid of it. It's a > worthless, cumbersome item. > > - Arnaud > > ps: please, do not get me wrong, I would apply this policy to anybody > who propose to help. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 01, 2012 at 09:36:26PM -0600, Warner Losh wrote: > > I think this proves the point everybody has been saying: you > are being needlessly contrary and confrontational. > Yep. In 18+ years of being subscribed to various freebsd lists, Arnaud has the honor of being only the 2nd person to earn a killfile entry. He's now sitting next to Jesus Monroy, Jr. -- Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 8/1/2012 8:36 PM, Warner Losh wrote: > I think this proves the point everybody has been saying: you are being > needlessly contrary and confrontational. Actually if you take a step back and look at what Arnaud is saying objectively, he's right. If anyone can attend the meeting by simply getting an invitation from a committer, the only purpose the invitation serves is to force the mere-mortal user to kiss someone's ring. That's precisely the kind of elitist crap that I've been railing against for so many years now. OTOH, currently the dev summits generally take place with limited resources, so it's not really possible to have "everyone" attend. And (TMK) the "invitation" process is really more like a restaurant with a sign that says "we reserve the right to refuse service to anyone." But on the _other_ other hand, the problem of things being discussed and/or decisions being taken exclusively at the dev summits, especially BSDCAN, has gotten quite bad over the last several years. Even amongst committers, the community has become divided between the "haves" who can travel to the summit, and the "have nots" who can't. Note, I'm quite sure that this statement will be met with howls of protest, from the "haves," that this isn't the case. Even if they were sincere, it's incredibly easy for the people with the privileges to see their privileged state as "normal," and lose sight of how the world looks from the cheap seats. In spite of Kevin's concerns (and I don't know what working groups he's been attending) the IETF model is really a good one to examine here. The majority of the work gets done on the mailing lists, with working group meetings serving as an opportunity for group discussion, presentations, etc. The results of the meetings are then published to the mailing list in the form of minutes, and the final decisions are made in public, on the lists. Another incredibly important feature, the meetings are open to remote participation in the sense that slide decks are published in advance, the meeting audio is streamed live, and there are jabber rooms for remote participants to interact with the people in the meeting. I used to ask the PTB to provide *some* form of remote participation for even a fraction of the events at the dev summit. I don't bother asking anymore because year after year my requests were met with any of: indifference, hostility, shrugged shoulders (that's a hard problem that we can't solve), or embarrassment. Since if the right people around here want something to happen, it happens; I finally came to the conclusion that they didn't want remote participation to happen, so it won't. That's a shame. If the only large, open project you've ever participated in is FreeBSD, what gets done around here feels "normal" to you. But don't be so quick to dismiss the viewpoints of people who have experience in the wider world. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
Yep. In 18+ years of being subscribed to various freebsd lists, Arnaud has the honor of being only the 2nd person to earn a killfile entry. He's now sitting next to Jesus Monroy, Jr. it is not a proud from you to talk about who you are blocking. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
