How to debug loader(8)
Hi. I have as issue with booting FreeBSD on retro server. loader(8) stuck during the boot (more details http://docs.freebsd.org/cgi/mid.cgi?CAO_2TxM4_7YpPV9iTXeX6S7w4T1zqiZJa0ewe5KKiusdmNiVnw) How can I debug why loader(8) is stuck. What information may be helpful? Thanks. -- S.Listopad ___ 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 9:30 PM, Doug Barton wrote: > 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 Doug makes some good points. The lack of any opportunity for remote participation in this day and age seems quite odd. Almost all conferences of more that half a dozen people are available remotely, at least for observers. Some are set up for full remote participation including presentations, questions (via chat) and voting/polling. It is surprising to me that something is not available for significant FreeBSD meetings. By the way, WGs that gave me major issues were SNMP and DNS. SNMP was dissolved and the DNS group finally accomplished its job about two years later than it should have by scheduling meetings, still open, outside of IETF meetings and thanks to the stubborn determination of Randy Bush. -- 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"
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 2 Aug 2012, at 05:30, Doug Barton wrote: > 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. You haven't asked for this for the Cambridge DevSummit, but others have and so we have arranged for cameras and microphones to be available for two of the sessions (the DocSummit and the ARM working group) to allow those who can not attend in person for various reasons to participate. I don't know how useful it will be (hopefully everything will work, but my experience with video conferencing is that it stops working as soon as you try to do something important with it), but there is certainly no active attempt to exclude people who can't attend. After each DevSummit, the results seem to appear on the wiki quite promptly - often during the sessions. At BSDCan this year, two of the working groups that I attended used OpenEtherPad to take minutes, so they were available in real time for non-attendees and people outside of the room were able to add things to them. There are usually people in the room on IRC as well, who are willing to relay things from people outside. David___ 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"
system wide major/minor page faults counters
Hi,
It would be useful to have system wide major and minor page faults
counters. Attached patch makes this possible.
Are there any objections to have it?
--
Andrey Zonov
Index: usr.bin/vmstat/vmstat.c
===
--- usr.bin/vmstat/vmstat.c (revision 238738)
+++ usr.bin/vmstat/vmstat.c (working copy)
@@ -473,6 +473,8 @@ fill_vmmeter(struct vmmeter *vmmp)
ADD_FROM_PCPU(i, v_cow_optim);
ADD_FROM_PCPU(i, v_zfod);
ADD_FROM_PCPU(i, v_ozfod);
+ ADD_FROM_PCPU(i, v_majflt);
+ ADD_FROM_PCPU(i, v_minflt);
ADD_FROM_PCPU(i, v_swapin);
ADD_FROM_PCPU(i, v_swapout);
ADD_FROM_PCPU(i, v_swappgsin);
@@ -511,6 +513,8 @@ fill_vmmeter(struct vmmeter *vmmp)
GET_VM_STATS(vm, v_cow_optim);
GET_VM_STATS(vm, v_zfod);
GET_VM_STATS(vm, v_ozfod);
+ GET_VM_STATS(vm, v_majflt);
+ GET_VM_STATS(vm, v_minflt);
GET_VM_STATS(vm, v_swapin);
GET_VM_STATS(vm, v_swapout);
GET_VM_STATS(vm, v_swappgsin);
@@ -966,6 +970,8 @@ dosum(void)
(void)printf("%9u copy-on-write optimized faults\n", sum.v_cow_optim);
(void)printf("%9u zero fill pages zeroed\n", sum.v_zfod);
(void)printf("%9u zero fill pages prezeroed\n", sum.v_ozfod);
+ (void)printf("%9u page faults\n", sum.v_majflt);
+ (void)printf("%9u page reclaims\n", sum.v_minflt);
(void)printf("%9u intransit blocking page faults\n", sum.v_intrans);
(void)printf("%9u total VM faults taken\n", sum.v_vm_faults);
(void)printf("%9u pages affected by kernel thread creation\n",
sum.v_kthreadpages);
Index: usr.bin/systat/vmstat.c
===
--- usr.bin/systat/vmstat.c (revision 238738)
+++ usr.bin/systat/vmstat.c (working copy)
@@ -82,6 +82,8 @@ static struct Info {
u_int v_cow_faults; /* number of copy-on-writes */
u_int v_zfod; /* pages zero filled on demand */
u_int v_ozfod; /* optimized zero fill pages */
+ u_int v_majflt; /* page faults */
+ u_int v_minflt; /* page reclaims */
u_int v_swapin; /* swap pager pageins */
u_int v_swapout;/* swap pager pageouts */
u_int v_swappgsin; /* swap pager pages paged in */
@@ -328,20 +330,22 @@ labelkre(void)
mvprintw(VMSTATROW + 1, VMSTATCOL + 9, "zfod");
mvprintw(VMSTATROW + 2, VMSTATCOL + 9, "ozfod");
mvprintw(VMSTATROW + 3, VMSTATCOL + 9 - 1, "%%ozfod");
- mvprintw(VMSTATROW + 4, VMSTATCOL + 9, "daefr");
- mvprintw(VMSTATROW + 5, VMSTATCOL + 9, "prcfr");
- mvprintw(VMSTATROW + 6, VMSTATCOL + 9, "totfr");
- mvprintw(VMSTATROW + 7, VMSTATCOL + 9, "react");
- mvprintw(VMSTATROW + 8, VMSTATCOL + 9, "pdwak");
- mvprintw(VMSTATROW + 9, VMSTATCOL + 9, "pdpgs");
- mvprintw(VMSTATROW + 10, VMSTATCOL + 9, "intrn");
- mvprintw(VMSTATROW + 11, VMSTATCOL + 9, "wire");
- mvprintw(VMSTATROW + 12, VMSTATCOL + 9, "act");
- mvprintw(VMSTATROW + 13, VMSTATCOL + 9, "inact");
- mvprintw(VMSTATROW + 14, VMSTATCOL + 9, "cache");
- mvprintw(VMSTATROW + 15, VMSTATCOL + 9, "free");
- if (LINES - 1 > VMSTATROW + 16)
- mvprintw(VMSTATROW + 16, VMSTATCOL + 9, "buf");
+ mvprintw(VMSTATROW + 4, VMSTATCOL + 9, "majflt");
+ mvprintw(VMSTATROW + 5, VMSTATCOL + 9, "minflt");
+ mvprintw(VMSTATROW + 6, VMSTATCOL + 9, "daefr");
+ mvprintw(VMSTATROW + 7, VMSTATCOL + 9, "prcfr");
+ mvprintw(VMSTATROW + 8, VMSTATCOL + 9, "totfr");
+ mvprintw(VMSTATROW + 9, VMSTATCOL + 9, "react");
+ mvprintw(VMSTATROW + 10, VMSTATCOL + 9, "pdwak");
+ mvprintw(VMSTATROW + 11, VMSTATCOL + 9, "pdpgs");
+ mvprintw(VMSTATROW + 12, VMSTATCOL + 9, "intrn");
+ mvprintw(VMSTATROW + 13, VMSTATCOL + 9, "wire");
+ mvprintw(VMSTATROW + 14, VMSTATCOL + 9, "act");
+ mvprintw(VMSTATROW + 15, VMSTATCOL + 9, "inact");
+ mvprintw(VMSTATROW + 16, VMSTATCOL + 9, "cache");
+ mvprintw(VMSTATROW + 17, VMSTATCOL + 9, "free");
+ if (LINES - 1 > VMSTATROW + 18)
+ mvprintw(VMSTATROW + 18, VMSTATCOL + 9, "buf");
mvprintw(GENSTATROW, GENSTATCOL, " Csw Trp Sys Int Sof Flt");
@@ -498,20 +502,22 @@ showkre(void)
PUTRATE(v_ozfod, VMSTATROW + 2, VMSTATCOL, 8);
putint(s.v_zfod != 0 ? (int)(s.v_ozfod * 100.0 / s.v_zfod) : 0,
VMSTATROW + 3, VMSTATCOL + 1, 8 - 1);
- PUTRATE(v_dfree, VMSTATROW + 4, VMSTATCOL + 2, 8 - 2);
- PUTRATE(v_pfree, VMSTATROW + 5, VMSTATCOL + 2, 8 - 2);
- PUTRATE(v_tfree, VMSTATROW + 6, VMSTATCOL, 8);
- PUTRATE(v_reactivated, VMSTATROW +
Re: How to debug loader(8)
On 02.08.2012 15:30, Sergey Listopad wrote: > Hi. > > I have as issue with booting FreeBSD on retro server. > loader(8) stuck during the boot (more details > http://docs.freebsd.org/cgi/mid.cgi?CAO_2TxM4_7YpPV9iTXeX6S7w4T1zqiZJa0ewe5KKiusdmNiVnw) > > How can I debug why loader(8) is stuck. What information may be helpful? Hi. It seems that biosdisk driver can't detect any disks except floppy. You can add some printfs to the bd_init() and bd_int13probe() functions in the sys/boot/i386/libi386/biosdisk.c file. Then recompile the loader and test. Also you can try to use grub loader, afaik it has a bit more quirks to the known problems. If it will work, we can try to fix our loader too. -- WBR, Andrey V. Elsukov ___ 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: system wide major/minor page faults counters
On Thu, Aug 02, 2012 at 05:50:25PM +0400, Andrey Zonov wrote: > Hi, > > It would be useful to have system wide major and minor page faults > counters. Attached patch makes this possible. > > Are there any objections to have it? I thought that struct vmmeter was engraved into our ABI much deeper, but inspection shows that at least base system successfully avoids dragging the structure into ABI at all. So what follows is only some comments and not objections. The description of v_majflt as 'page faults' and v_minflt as 'page reclaim' is very confusing, IMO. First, the v_majflt is not inclusive in regard of v_minflt. Second, reclaim usually has a connotation of thing being repurposed (I am probably wrong there), which is not case for minor page faults. As an additional twist, please note that not all page faults reach vm_fault_hold() at all. See for instance x86 handling of the spurious page faults, I believe that other architectures like MIPS also completely consume some page faults in MD code. The minfault counter probably should be incremented there too. And, not all calls to vm_fault_hold() are caused by hardware page faults. See the use of vm_fault_hold() and vm_fault_quick_hold_pages() scattered around the sys/. pgp53qNfxSORm.pgp Description: PGP signature
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 09:20, Scott Long wrote: > > On Aug 2, 2012, at 12:23 AM, Kevin Oberman > wrote: > >> Doug makes some good points. > > No, he doesn't. Yes I do! (So there) > He and Arnould being argumentative and accusatory > where none of that is warranted. > > I used to run the devsummits, and we did tele-conference lines for > remote people to participate. I singled out BSDCAN specifically since that's "where the action is" for the last several years. I do recall your efforts in this regard, but it so happened that I was able to attend most of them in person back then. No slight towards what you did was intended. > After I stepped down, others took it > up and did the same thing. Usually, the lines were unused. I > suspect that organizers simply stopped thinking about them after a > while because of poor interest. There is no conspiracy of exclusion > here, just simple human apathy. Here I have to disagree with you. Once again, speaking specifically about BSDCAN dev summits, I repeatedly asked the organizers to provide some sort of audio stream (phone, Internet, anything) and was repeatedly told it wasn't possible. This was not a case of lack of interest. This was a case of "We understand that it is something people want, but it isn't going to happen." > The invite system for the devsummit was, and still is, purely about > providing some order to the process. It ensures that people > attending are willing to demonstrate a minimum amount of interest, > more than just wondering by a room one day and dropping in for free > food and wifi. I specifically made allowances for this issue in my post. 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..]
On Aug 2, 2012, at 12:23 AM, Kevin Oberman wrote: > Doug makes some good points. No, he doesn't. He and Arnould being argumentative and accusatory where none of that is warranted. I used to run the devsummits, and we did tele-conference lines for remote people to participate. After I stepped down, others took it up and did the same thing. Usually, the lines were unused. I suspect that organizers simply stopped thinking about them after a while because of poor interest. There is no conspiracy of exclusion here, just simple human apathy. The invite system for the devsummit was, and still is, purely about providing some order to the process. It ensures that people attending are willing to demonstrate a minimum amount of interest, more than just wondering by a room one day and dropping in for free food and wifi. If anyone feels that they are being excluded, it's because they are too lazy to go beyond being argumentative on a mailing list. Scott ___ 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 2, 2012, at 9:20 AM, Scott Long wrote: > > On Aug 2, 2012, at 12:23 AM, Kevin Oberman wrote: > >> Doug makes some good points. > > No, he doesn't. He and Arnould being argumentative and accusatory where none > of that is warranted. > > I used to run the devsummits, and we did tele-conference lines for remote > people to participate. After I stepped down, others took it up and did the > same thing. Usually, the lines were unused. I suspect that organizers > simply stopped thinking about them after a while because of poor interest. > There is no conspiracy of exclusion here, just simple human apathy. The "Watson/Losh connection" worked really well in BSDCan 2010 :). Advertising the teleconferencing lines might be an issue (I would have loved to have joined in some of the remote conferences, if for nothing more than be a fly on the wall, this year), but that's a separate thing aside. There's some misunderstanding, assumption, etc mixed together in this mailing chain that I think is probably better resolved with some face-to-face conversations or maybe just more rational (and less heated) discussion. 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..]
On 08/02/2012 05:54, David Chisnall wrote: > On 2 Aug 2012, at 05:30, Doug Barton wrote: > >> 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. > > You haven't asked for this for the Cambridge DevSummit, You did read the part where I gave up, right? > but others > have and so we have arranged for cameras and microphones to be > available for two of the sessions (the DocSummit and the ARM working > group) to allow those who can not attend in person for various > reasons to participate. Well that's a start. :) And where was this availability announced? If I missed it, that's on me. But providing remote access that you don't tell people about isn't really any better than not providing it at all. > I don't know how useful it will be (hopefully everything will work, > but my experience with video conferencing is that it stops working as > soon as you try to do something important with it), If I can offer some advice from the trenches ... focus on making the audio robust, and put efforts into the video as resources permit. The combination of solid audio, making presentations available on line, and a chat room (IRC, jabber, whatever) allows for a great deal of remote participation. Video is nice, but if the video going down takes the audio with it, you're no better off than when you started. > but there is > certainly no active attempt to exclude people who can't attend. ... and here is where I need to push back. "No active attempt to exclude people" is not the same thing as actively encouraging remote participation. It's the latter that we're after. > After each DevSummit, the results seem to appear on the wiki quite > promptly - often during the sessions. At BSDCan this year, two of > the working groups that I attended used OpenEtherPad to take minutes, > so they were available in real time for non-attendees and people > outside of the room were able to add things to them. There are > usually people in the room on IRC as well, who are willing to relay > things from people outside. Those all sound like nice steps forward, thank you for pointing them out. Nothing would make me happier than to be proven wrong in this area. What would be nice I think would be if these steps were formalized, and shared more openly. Having things on the wiki is nice, but reporting things in detail on the mailing lists puts it in the archives for future reference, as well as making it more broadly available to start with. 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..]
On 08/02/2012 09:44, Garrett Cooper wrote: > > The "Watson/Losh connection" worked really well in BSDCan 2010 :). I wasn't going to mention that, since I didn't want to tell tales out of school. But the fact that remote participation actually was provided for "the right people," even though I was told repeatedly that it wasn't possible, actually highlights a big part of the problem. > Advertising the teleconferencing lines might be an issue (I would > have loved to have joined in some of the remote conferences, if for > nothing more than be a fly on the wall, this year), but that's a > separate thing aside. At various points when I was asking for remote participation at BSDCAN different people offered to provide this through their company's teleconferencing solutions, providing that the organizers could put a phone line in the room(s). They were told that it wasn't possible to do that. 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..]
On 2 Aug 2012, at 17:46, Doug Barton wrote: > Well that's a start. :) And where was this availability announced? If I > missed it, that's on me. But providing remote access that you don't tell > people about isn't really any better than not providing it at all. It's not widely advertised, because we're likely to be able to support a limited number of remote participants (10 seems like the upper limit for the technology that we're looking at, and I wouldn't be surprised if it degrades before then). As with all other things in the project, we welcome people who are willing to make an effort to engage. We provide it when people ask, not spontaneously, because organising cameras and decent microphones requires effort on the bart of the organisers. We only have one microphone available that will give good pickup over a whole room, for example, so we can't offer remote participation in parallel streams and we need to prioritise people who are willing to go to the massive effort of sending a one-line email saying 'I would like to make a contribution in this working group but am unable to attend'. The FreeBSD Foundation has also offered to fund new contributors who want to attend but are unable to afford to do so on their own. In spite of the fact that I spent some effort encouraging people to apply for this, only one person actually did. We make a considerable effort to ensure that DevSummits are easy to attend for anyone who wants to contribute to the projects. They are not intended as spectator events, but for anyone who wishes to engage with the community there are procedures in place for attending or participating remotely. I have very little sympathy with people who complain that the community isn't engaging with them, without making the effort to engage with the community. David ___ 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 08/02/2012 10:13, David Chisnall wrote: > On 2 Aug 2012, at 17:46, Doug Barton wrote: > >> Well that's a start. :) And where was this availability announced? >> If I missed it, that's on me. But providing remote access that you >> don't tell people about isn't really any better than not providing >> it at all. > > It's not widely advertised, because we're likely to be able to > support a limited number of remote participants (10 seems like the > upper limit for the technology that we're looking at, and I wouldn't > be surprised if it degrades before then). Welcome to the 21st Century. :) There are widely available audio and video conferencing solutions that easily scale into the thousands of users, at minimal cost. > As with all other things > in the project, we welcome people who are willing to make an effort > to engage. We provide it when people ask, not spontaneously, because > organising cameras and decent microphones requires effort on the bart > of the organisers. Yes, "It takes effort." I get that. I've been part of the effort to provide remote participation for other groups, on a much larger scale than anything FreeBSD can dream of. My point, and I cannot emphasize this highly enough, is that your entire mindset about this is all wrong. It needs to shift from "We'll do this on a small scale, for those who ask" to "We'll make providing robust remote participation a top priority, built into the planning from day 1." It's as simple as that. > The FreeBSD Foundation has also offered to fund new contributors who > want to attend but are unable to afford to do so on their own. In > spite of the fact that I spent some effort encouraging people to > apply for this, only one person actually did. It isn't just the financial cost of attending the summit. Often (as in my case) it's the lack of ability to take time away from personal, work, and/or family commitments. For others it may be the difficulty of doing the traveling at all. The fact that only 1 person took you up on this offer (and IIRC there have been similar results in the past) pretty clearly indicates that you're trying to solve the wrong problem. Given that the foundation has money to spend here, why not put 2 and 2 together and have the foundation invest in providing remote participation? That would benefit far more people, and almost certainly at less cost. 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..]
BTW, for those who'd like to get a flavor of what the IETF model looks like, the Vancouver meeting is in process now: https://datatracker.ietf.org/meeting/84/agenda.html Feel free to join in as a lurker. -- 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..]
On 08/02/2012 10:34, Doug Barton wrote: > BTW, for those who'd like to get a flavor of what the IETF model looks > like, the Vancouver meeting is in process now: > > https://datatracker.ietf.org/meeting/84/agenda.html > > Feel free to join in as a lurker. Sorry, this agenda makes it easier to see the remote participation stuff: https://tools.ietf.org/agenda/84/ -- 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..]
On 2 Aug 2012, at 18:28, Doug Barton wrote: > Welcome to the 21st Century. :) There are widely available audio and > video conferencing solutions that easily scale into the thousands of > users, at minimal cost. > > Yes, "It takes effort." I get that. I've been part of the effort to > provide remote participation for other groups, on a much larger scale > than anything FreeBSD can dream of. > > My point, and I cannot emphasize this highly enough, is that your entire > mindset about this is all wrong. It needs to shift from "We'll do this > on a small scale, for those who ask" to "We'll make providing robust > remote participation a top priority, built into the planning from day > 1." It's as simple as that. Thank you for volunteering to organise this. It's good to see people with both the motivation and experience required to do something well actively contributing to the project. David___ 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 2, 2012, at 10:46 AM, Doug Barton wrote: > Those all sound like nice steps forward, thank you for pointing them > out. Nothing would make me happier than to be proven wrong in this area. > What would be nice I think would be if these steps were formalized, and > shared more openly. Having things on the wiki is nice, but reporting > things in detail on the mailing lists puts it in the archives for future > reference, as well as making it more broadly available to start with. One thing to remember about the IETF. There's many vendors that devote significant resources to the IETF. While I was at Cisco, for example, I know that we provided audio and video bridges to IEFT meetings to facilitate remote attendance at the meetings. Cisco dedicated several engineers to ensure that the audio and video quality remained good during the meetings and were able to use facilities cisco normally used for things like WebEx and MeetingPlace. With a global presence and infrastructure, they were able to pull it off. I'm not aware of similar resources within the project. We don't have any such benefactor in the project, so we have to rely on the kindness of strangers. AsiaBSDcon live streams most of its talks, but uses a free service that changes from year to year and is quite good for talks, but can't do meetings at all. Other meeting things do meetings OK, but the video or audio quality sucks unless you have high end gear for the source. Mapping out what hardware, software and service combinations work would be very beneficial. I suspect this will vary based on geographic location (stuff that works good in the US won't work in EU or Asia and vice versa). These issues are what makes it hit or miss. While it is easy to skype one or two people into a meeting, that scales poorly to more than two. Plus if things are going poorly, the attempt to broadcast the meeting can derail or eat into the time available significantly. I guess this is a long way to say that while one to one, and one to many problems have relatively easy solutions, many to many like we need still remains fussy and difficult. Warner ___ 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 7: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. > Well, my talk was mainly there to collect some opinion on how to continue my work. IIRC, the only one objection was on supporting callout execution from hw interrupt context. Mainly, the objection moved was that there were no practical applications for that. It turned out I found some, and in any case it wasn't "it will not work" but "probably it's not an effort you want to put because the consumers that can exploit some functionality are few". I wasn't really so familiar with that so I hesitated in answering. In any case, I liked a lot the objection moved by Attilio because it gave me the possibility to investigate and find out the right direction. As you may see, there's a branch in projects/ in which the feature that "won't work" is implemented, so, maybe you're missing something. If you had some concerns on it you can raise up your hand and tell: "hey, that sucks". It would be better than getting this feedback after 3 months of work honestly. I have nothing in contrary about getting feedbacks (negative or positive). But probably you belong to that kind of people that are able to tell only behind a monitor, so this is my last word on the topic. Get a life. >> 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" Davide ___ 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 Thu, Aug 02, 2012 at 09:46:42AM -0700, Doug Barton wrote: > > but there is > > certainly no active attempt to exclude people who can't attend. > > ... and here is where I need to push back. "No active attempt to exclude > people" is not the same thing as actively encouraging remote > participation. It's the latter that we're after. s/encouraging remote/encouraging constructive remote/ The last thing we need is more people trying to get things done their way because they know best. People need to be willing to accept that maybe some widget they want won't be part of the goal of the project under discussion, for whatever reason. I've seen too many ... heated debates start up largely because people were not discussing things face to face. I'm not saying that all of the debates wouldn't happen if people were all in the same room, but a lot of them wouldn't. Larger/longer term projects should probably have their own mailing list set up for discussion. Regards, Gary ___ 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 Thursday, August 02, 2012 12:30:16 am Doug Barton wrote: > 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." The latter bits here are mostly true. The biggest constraint is space. Also, I don't know of anyone that has asked to attend the developer summit as a guest that wasn't invited. > 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. I find this a bit ironic from you given that I've met you in person at USENIX ATC which is an order of magnitude more expensive than BSDCan (and in fact, one of the reasons the US-based BSDCon died and was effectively supplanted by BSDCan was that BSDCan is far cheaper). > 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. To be honest, the preocuppations to date have been a bit more basic than that (figuring out a workable format, lots of effort on simple logistics like food and rooms). Also, in previous years we have often had breakout rooms in random conference rooms in what would be the equivalent of a dorm meeting area with no A/V equipment, etc. The last two years have cut down to fewer meetings in more reasonable rooms. The connectivity is now generally reliable as well. All that to say that now that some basic things are settled, we can probably make some forward progress on this. A first step might be to start recording the summit sessions (BSDCan already has a partner that does this). Live streaming I'm less sure of, mostly because I am completely ignorant of what is available. I do know that having a bunch of people skype in would not be feasible (not enough bandwidth to send video out in multiple streams). The video would need to go out in a single stream to a distributor of some sort. And, quite frankly, despite Doug's "haves" vs "have-nots" implications, we can't afford an expensive commercial solution (e.g. Cisco) AFAIK. -- John Baldwin ___ 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 08/02/2012 10:37, David Chisnall wrote: > > Thank you for volunteering to organise this. It's good to see people with > both the motivation and experience required to do something well actively > contributing to the project. Cheap copout. And quite sad, especially coming from a newly elected core team member. 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..]
On 08/02/2012 10:40, Warner Losh wrote: > One thing to remember about the IETF. There's many vendors that devote > significant resources to the IETF. While I was at Cisco, for example, I know > that we provided audio and video bridges to IEFT meetings to facilitate > remote attendance at the meetings. Cisco dedicated several engineers to > ensure that the audio and video quality remained good during the meetings and > were able to use facilities cisco normally used for things like WebEx and > MeetingPlace. With a global presence and infrastructure, they were able to > pull it off. I'm not aware of similar resources within the project. I'm not suggesting we need anything at the full WebEx audio/video/presentation/chat level. And apparently the Foundation has money to spend on dev summits. As I suggested in a previous message, this would be a good long-term investment that would benefit a lot of people, especially in comparison to the money set aside for travel grants which is now going begging. 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..]
On 08/02/2012 05:39, John Baldwin wrote: > I find this a bit ironic from you given that I've met you in person at > USENIX ATC which is an order of magnitude more expensive than BSDCan (and > in fact, one of the reasons the US-based BSDCon died and was effectively > supplanted by BSDCan was that BSDCan is far cheaper). Yep, back in 2004 when traveling to conferences was part of my job, and before my daughter was born. My life now is quite different. ... not to mention that this thread isn't about me. It's about the importance of remote participation to the FreeBSD community as a whole. 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..]
On 2 Aug 2012, at 18:47, Doug Barton wrote: > Cheap copout. And quite sad, especially coming from a newly elected core > team member. FreeBSD is a volunteer project. Our DevSummits are not run by a commercial organisation, they are run by volunteers. I am not being paid to organise the Cambridge DevSummit, I am doing it in my spare time, as are the other people here. The resources available are those that I can beg or borrow from the university and from other developers. The attendance fee is £50, which is just about enough to cover the costs (we hope). Comparing this to a professionally organised event like an IETF meeting, with large commercial sponsors (the IETF event you cite is hosted by Google), and complaining that it comes up short is insulting. Saying 'solutions exist, therefore you must have the time, expertise, and resources to deploy them' is insulting. It is not constructive. If you are willing to make a helpful contribution, then it is welcome. If you are going to complain, yet not offer anything constructive, then you are just trolling and I am wasting my time by reading your emails, let alone replying. We have arranged to borrow a decent microphone and camera from the video conferencing suite in the department and have planned to use Skype to allow remote participation in two sessions. If you wish to propose a more scalable solution that can be easily deployed here by people with no prior experience setting up such a system, then please do so. If you feel that you can do a better job organising a DevSummit than the people who have donated their free time to organise the ones in the past and the ones planned in the next few months, then I am certain that they would be very happy for you to assist in the organisation. If your attitude is 'well, I'm not going to do anything, but it must be easy because no effort from me is involved so you should do it' then I find your attitude personally insulting and unproductive. David ___ 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 08/02/2012 11:12, David Chisnall wrote: > FreeBSD is a volunteer project. Yeah, I get that. I've been around quite a bit longer than you have, in case you didn't notice. :) I understand what you're saying, it's going to take work to change this mindset, and to provide these resources. If you read my posts on a factual basis, I'm not suggesting that the dev summits provide remote participation at the same level as groups like the IETF or ICANN do, and your point (and Warner's) that these groups have significant financial backing is well taken. However, my point is that in spite of the fact that it's non-trivial, the mindset on this topic needs to change if the dev summits are going to continue to be significant focii of both work being done and decisions being made (which of course, they are). What I'm *not* doing is demanding that any one person, or even any one group take responsibility for solving the whole problem on their own. Unfortunately, due to my inability to actually attend these meetings, I won't be able to provide the kind of hands-on assistance that I'd like to be able to. However it sounds like there may be financial resources available through the foundation, which would go a long way towards making a solution possible. The next step would be for people to agree that this is a problem that *needs* to be solved, followed by willingness on the part of dev summit organizers to support these efforts, which will hopefully lead to people who are willing and interested to step up and actually provide solutions. It's already been true in the past that various companies have volunteered to do this. There is no reason to believe that it wouldn't happen again if organizers are willing to be supportive. What I'm hearing so far is defensiveness, and an attempt to focus the discussion on me. Neither is helpful. :) Acknowledging that this is a problem that needs to be solved does not imply that by not solving it you personally have failed in some way. I apologize if anything I've written so far has implied otherwise. 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..]
Thank you for your thoughtful reply, On 2 Aug 2012, at 19:33, Doug Barton wrote: > However, my point is that in spite of the fact that it's non-trivial, > the mindset on this topic needs to change if the dev summits are going > to continue to be significant focii of both work being done and > decisions being made (which of course, they are). I believe that, before that decision can be made, there needs to be some consensus on what the purpose of the DevSummits is. In my view, DevSummits do not exist to set project policy. They are places where: - People can talk face to face about their current and planned projects. - Developers can meet on a social basis, making remote working easier. The latter is very important - I've found in other projects that it's far easier to work with someone on the other side of the world when you've chatted with them over a few beverages-of-choice. Any official conversations happen on the mailing lists. DevSummits are for people working on similar things to meet and discuss their plans, and for people to have a chance to get to know what everyone else is doing, for a limited set of 'everyone else'. Slides and summaries so on from the more structured parts of this are available afterwards, which helps people who can't attend get the same benefit - they know what other people are working on. The original complaint that spawned this long discussion was that decisions about the project are made behind closed doors. This is obviously true in the literal sense, as code always wins over chatter in an open source project, and the person willing to sit down and write the code gets the final say on how it should work, although ideally with code review, design feedback and so on from others. Even if we broadcast everything that happens in the official parts of the DevSummits, that won't necessarily fix anything because a lot of the most productive conversations happen over dinner or in the pub. If there is a real problem to address, then it is people making policy decisions at DevSummits, without adequate consultation. I have not observed this happening, but I would regard it as no different to people making policy decisions via private email, and something that should be subject to the same response: revisit the decisions in public if there are legitimate concerns raised about it, subject to the usual open source rule that the person actually willing to do the work gets to make the final call. > What I'm *not* doing is demanding that any one person, or even any one > group take responsibility for solving the whole problem on their own. > Unfortunately, due to my inability to actually attend these meetings, I > won't be able to provide the kind of hands-on assistance that I'd like > to be able to. However it sounds like there may be financial resources > available through the foundation, which would go a long way towards > making a solution possible. Finance is not the only obstacle. In some venues, bandwidth is a problem (not at Cambridge hopefully - people will have stopped using it all to stream the olympics by then), but in other venues we only have WiFi, which is shared with a room full of developers. If we buy some equipment (decent microphones are not always available - we were unable to find one at FOSDEM for remote attendees, for example), then it would need to be transported between events, and someone would need to be responsible for looking after it and ensuring that it is set up correctly at each event. > The next step would be for people to agree that this is a problem that > *needs* to be solved, followed by willingness on the part of dev summit > organizers to support these efforts, which will hopefully lead to people > who are willing and interested to step up and actually provide > solutions. It's already been true in the past that various companies > have volunteered to do this. There is no reason to believe that it > wouldn't happen again if organizers are willing to be supportive. There are two proposals: Remote viewing and remote participation. Remote viewing, being non-interactive, does not have to be done via streaming, it can be done by recording the event and making it available online. Even this is not trivial: we've done it for the GNUstep devroom at FOSDEM most years, and it typically takes a long time to get the videos edited and uploaded. ARM sent a professional team to do it at EuroLLVM, and yet they didn't have enough equipment to cover everything (my tutorial, for example, was not recorded). I would say that this is something that is very useful for presentation-style events, but DevSummits are typically more round-table discussions and hacking sessions than presentations. Remote participation is bidirectional, and I am a lot more wary about that. The productivity of a meeting is usually inversely proportional to the number of attendees, and allowing a lot more people in does not ne
FreeBSD ZFS source
Hello, Excuse me for this newb question but exactly where are the current ZFS files located? I have been looking at the CVS on freebsd.org under /src/contrib/opensolaris/ but that does not seem to be the current ones. Is this correct? Regards___ 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: FreeBSD ZFS source
On Thu, Aug 02, 2012 at 22:48:50 +0200 , Fredrik wrote: > Hello, > > Excuse me for this newb question but exactly where are the current ZFS > files located? I have been looking at the CVS on freebsd.org under > /src/contrib/opensolaris/ but that does not seem to be the current > ones. Is this correct? $ find /usr/src -type d -iname zfs /usr/src/cddl/contrib/opensolaris/cmd/zfs /usr/src/cddl/sbin/zfs /usr/src/lib/libprocstat/zfs /usr/src/sys/boot/zfs /usr/src/sys/cddl/boot/zfs /usr/src/sys/cddl/contrib/opensolaris/common/zfs /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs /usr/src/sys/modules/zfs /usr/src/tools/regression/zfs Those are probably a good start. Some of them just contain a Makefile pointing you elsewhere in the tree, though. I might have missed something, and I'm sure someone will correct me if I have. -- Thanks and best regards, Chris Nehren pgp4qvQrT9NKB.pgp Description: PGP signature
Re: FreeBSD ZFS source
http://svnweb.freebsd.org/base/head/sys/cddl/contrib/opensolaris/common/ http://svnweb.freebsd.org/base/head/cddl/contrib/opensolaris/lib/ On 8/2/12, Fredrik wrote: > Hello, > > Excuse me for this newb question but exactly where are the current ZFS files > located? I have been looking at the CVS on freebsd.org under > /src/contrib/opensolaris/ but that does not seem to be the current ones. Is > this correct? > > Regards___ > 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" > ___ 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?
Yuri writes: > 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. So the sound continues, on and off, while everything else freezes? I would suspect that the sound device driver is locking out other devices and hogging the system. WHY does FreeBSD allow one device driver to lock out out everything else? And what can we do about it? I've seen a device driver lock out everything else for minutes-on-end, which of course resulted in data being lost. Losing data is one of the worst things an OS can do. This needs to be fixed. ___ 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?
the "cycle over a short period" may not be the driver writing the same crap to the card. I've seen similar failure modes in windows where during playback, if the system hangs for whatever reason, the card plays the last sample over and over in a loop. 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/2/12 9:53 AM, Doug Barton wrote: On 08/02/2012 09:44, Garrett Cooper wrote: The "Watson/Losh connection" worked really well in BSDCan 2010 :). I wasn't going to mention that, since I didn't want to tell tales out of school. But the fact that remote participation actually was provided for "the right people," even though I was told repeatedly that it wasn't possible, actually highlights a big part of the problem. bandwidth was limited and a single 1:1 skype connection was all we really could do. I did broadcast sessions a few years ago using the apple quicktime server but it was a lot of work and I think one person looked at part of one session. Doug ___ 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 Thu, Aug 2, 2012 at 5:37 PM, Julian Elischer wrote: > On 8/2/12 9:53 AM, Doug Barton wrote: >> >> On 08/02/2012 09:44, Garrett Cooper wrote: >>> >>> The "Watson/Losh connection" worked really well in BSDCan 2010 :). >> >> I wasn't going to mention that, since I didn't want to tell tales out of >> school. But the fact that remote participation actually was provided for >> "the right people," even though I was told repeatedly that it wasn't >> possible, actually highlights a big part of the problem. > > bandwidth was limited and a single 1:1 skype connection was all we really > could do. > > I did broadcast sessions a few years ago using the apple quicktime server > but it was a lot of work and I think one person looked at part of one > session. > >> Doug First, too many of these posts assume way too much. I don't think anyone should be thinking of any sort of what is commonly called "teleconferencing". That would be nice, but is far more complex and expensive, both in bandwidth and equipment, then should be considered as a starting point. I suggest the starting point is a webpage with a link to the slides being presented and a simple audio stream. This is trivially possible with a FreeBSD system and open-source software. A bandwidth of only about 70kbps would be needed. Less with reasonable codec choice. Several streams could be broadcast via a single, unicast stream to a well connected server which woild then stream to end users It might be augmented with jabber other open IM technology with someone at the meeting if procedures for this could be agreed to. (Some vetting is desirable, but will result in calls of censorship.) For small rooms, microphones are fairly easy to handle and one-way streams don't require echo cancellation. As costs for video come down, that might be something to think about some day, but is not required to allow remote "attendance". Of course, unless this is publicized, no one will come (which eliminates any technical issues). :-) -- 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"
