Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 9:30 PM, Doug Barton do...@freebsd.org 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
VirtualBox: Eating up 100% CPU, freezing Windows 7
I discover that when running Windows 7 in a VirtualBox On FreeBSD 10 (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7 for more than a minute. For a minute or so, I can work, then, the freeze occurs again. I can't see this behaviour with a Ubuntu Guest on the same box. Is there Windows 7 specifica to be aware of? Regards, Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
2012/8/2 Julian Elischer jul...@freebsd.org: I think that the /dev/entries can (and SHOULD) go away when the hardware goes away and even be re-used. But here's the point. TTYs are used in a different way than other device nodes. Regular device nodes are simply opened by a set of independent process (e.g. dd if=/dev/da0, a music player opening /dev/dsp, etc). TTYs are used by a set of processes that share a weak relationship, namely all belonging to the same login session. Things *really* break if you were to forcefully remove a TTY device node and replace it by another TTY. Even for physical devices it would be really bad to do. Consider a system that has two USB to serial converters that are used for interactive login sessions. One is plugged in, the other one isn't. If you unplug one device and plug in the other, you never want the processes from the one login session to start interacting with the other device. Also, applications relying on the user accounting database (utmpx) will start to behave non-deterministically then. Do we really want biff and wall to write stuff to random TTYs? Whether or not the TTY is a pseudo-terminal or not is completely irrelevant in my opinion. -- Ed Schouten e...@80386.nl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
In message cajoyfbbbskrbxjkzdv-jghi4vjgw0s0n2dgvzgm5_odwcy6...@mail.gmail.com , Ed Schouten writes: 2012/8/2 Julian Elischer jul...@freebsd.org: TTYs are used *two* ways: As terminals and as comms to the real world. If a terminal-tty disappears, it should be handled like a HUP would be, analytically it is the exact same situation as a carrier drop on a modem. The implementation may need to do tricky stuff, but the result should be exactly like a HUP seen from userland. If a comms-tty disappears, it should be handled like any other disappearing device: ENXIO. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: On cooperative work
Has anyone, ever, proposed, thought about, or used a hierarchical feedback model, where conference participants are grouped into some tree, where one experienced (or trusted) person in a group would answer simple questions (coming from other members of the group), and forward advanced questions to the head presentor (or, generally, to a higher tree level) in a compact fashion? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Aug 2, 2012, at 12:23 AM, Kevin Oberman kob6...@gmail.com 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Warning: ifaddr refcount use patch (svn commit: r194760 - in head/sys: contrib/rdma net net80211 netinet netinet6 netipx (fwd))
Hi Robert, I am using Freebsd 8.2 and facing the Use-after-free issue because of the possible reference release on ifaddr without it being acquired. The issue is that ifa remains on the addr list of ifp but it is already free which leads to the panic in the code trying to traverse through the ifaddr list of ifp. I am wondering if the patches you mentioned in the thread are still available. Thanks, Suraj ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
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 kob6...@gmail.com 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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 kob6...@gmail.com 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Wed, Aug 1, 2012 at 7:05 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao atti...@freebsd.org wrote: On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao atti...@freebsd.org 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-hack...@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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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 necessarily improve
rtld dropping core on recent -current
% file /usr/local/bin/ppdpo /usr/local/bin/ppdpo: ELF 32-bit LSB shared object, Intel 80386, \ version 1 (FreeBSD), dynamically linked (uses shared libs), FreeBSD-style,\ for FreeBSD 10.0 (115), stripped % ldd /usr/local/bin/ppdpo /usr/local/bin/ppdpo: /usr/local/bin/ppdpo: signal 11 % gdb741 /usr/obj/usr/src/usr.bin/ldd/ldd ldd.core GNU gdb (GDB) 7.4.1 [GDB v7.4.1 for FreeBSD] Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i386-portbld-freebsd10.0. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/obj/usr/src/usr.bin/ldd/ldd...done. [New process 100147] Core was generated by `ldd'. Program terminated with signal 11, Segmentation fault. (gdb) bt #0 0x4804fa4e in digest_notes (obj=0x4806b000, note_start=1208398156,\ note_end=1208398204) at /usr/src/libexec/rtld-elf/rtld.c:1326 #1 0x480566dc in map_object (fd=3, path=0x48065320 /usr/local/bin/ppdpo,\ sb=0xbfbfd4dc) at /usr/src/libexec/rtld-elf/map_object.c:156 #2 0x48051627 in do_load_object (flags=optimized out, sbp=optimized out,\ path=optimized out, name=optimized out, fd=optimized out) at /usr/src/libexec/rtld-elf/rtld.c:2100 #3 load_object (name=0xbfbfd8d0 /usr/local/bin/ppdpo, fd_u=-1,\ refobj=0x48067000, flags=optimized out) at /usr/src/libexec/rtld-elf/rtld.c:2070 #4 0x48052303 in dlopen_object (name=0xbfbfd8d0 /usr/local/bin/ppdpo,\ fd=-1, refobj=0x48067000, lo_flags=6, mode=0, lockstate=0xbfbfd590) at /usr/src/libexec/rtld-elf/rtld.c:2799 #5 0x48052fea in rtld_dlopen (name=0xbfbfd8d0 /usr/local/bin/ppdpo,\ fd=-1, mode=512) at /usr/src/libexec/rtld-elf/rtld.c:2761 #6 0x0804935b in main (argc=1, argv=0xbfbfd760) at /usr/src/usr.bin/ldd\ /ldd.c:251 (gdb) list 1321obj-osrel = *(const int32_t *)(p); 1322dbg(note osrel %d, obj-osrel); 1323break; 1324case CRT_NOINIT_NOTETYPE: 1325/* FreeBSD 'crt does not call init' note */ 1326obj-crt_no_init = true; 1327dbg(note crt_no_init); 1328break; 1329} 1330} (gdb) print *obj-crt_no_init Cannot access memory at address 0x0 % pkg_info -W /usr/local/bin/ppdpo /usr/local/bin/ppdpo was installed by package cups-base-1.5.2_2 % portmaster cups-base % pkg_info -W /usr/local/bin/ppdpo /usr/local/bin/ppdpo was installed by package cups-base-1.5.2_2 % ldd /usr/local/bin/ppdpo /usr/local/bin/ppdpo: /usr/local/bin/ppdpo: signal 11 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
possible je-malloc issue
Libc built today.
Start X with fvwm window manager.
Open xterm and su to root.
1. Use nedit to edit a file and close.
fvwm drops core. If fvwm does not drop core repeat 1 until
she does.
(gdb) bt
#0 0x4841e294 in __jemalloc_arena_mapbits_get (chunk=0x800, pageind=245)
at
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:502
#1 0x4841e2c4 in __jemalloc_arena_mapbits_allocated_get (chunk=0x800,
pageind=245)
at
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:581
#2 0x4841e739 in __jemalloc_arena_salloc (ptr=0x80f58e0, demote=false)
at
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:902
#3 0x48423dd1 in __jemalloc_isalloc (ptr=0x800, demote=false)
at
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:791
#4 0x4842408e in free (ptr=0x80f58e0) at jemalloc_jemalloc.c:1212
#5 0x48164b7d in XFree (data=0x80f58e0) at XlibInt.c:1701
#6 0x080c4f2f in FlocaleFreeNameProperty (ptext=0xbfbfcfb4) at Flocale.c:2363
#7 0x0806d3ab in HandlePropertyNotify (ea=0xbfbfd014) at events.c:3422
#8 0x0806c369 in dispatch_event (e=0xbfbfd044) at events.c:4135
#9 0x0806ca5f in HandleEvents () at events.c:4179
#10 0x0808e06e in main (argc=1, argv=0xbfbfd7ac) at fvwm.c:2591
(gdb) frame 4
#4 0x4842408e in free (ptr=0x80f58e0) at jemalloc_jemalloc.c:1212
1212usize = isalloc(ptr, config_prof);
(gdb) print *ptr
Attempt to dereference a generic pointer.
(gdb) up 1
#5 0x48164b7d in XFree (data=0x80f58e0) at XlibInt.c:1701
1701XlibInt.c: No such file or directory.
(gdb) print *data
Attempt to dereference a generic pointer.
(gdb) up 1
#6 0x080c4f2f in FlocaleFreeNameProperty (ptext=0xbfbfcfb4) at Flocale.c:2363
2363Flocale.c: No such file or directory.
(gdb) print *ptext
$5 = {name = 0x80f58e0 Untitled, name_list = 0x0}
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: possible je-malloc issue
On Aug 2, 2012, at 3:32 PM, Steve Kargl wrote:
Libc built today.
Start X with fvwm window manager.
Open xterm and su to root.
1. Use nedit to edit a file and close.
fvwm drops core. If fvwm does not drop core repeat 1 until
she does.
(gdb) bt
#0 0x4841e294 in __jemalloc_arena_mapbits_get (chunk=0x800, pageind=245)
at
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:502
#1 0x4841e2c4 in __jemalloc_arena_mapbits_allocated_get (chunk=0x800,
pageind=245)
at
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:581
#2 0x4841e739 in __jemalloc_arena_salloc (ptr=0x80f58e0, demote=false)
at
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:902
#3 0x48423dd1 in __jemalloc_isalloc (ptr=0x800, demote=false)
at
/usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:791
#4 0x4842408e in free (ptr=0x80f58e0) at jemalloc_jemalloc.c:1212
#5 0x48164b7d in XFree (data=0x80f58e0) at XlibInt.c:1701
#6 0x080c4f2f in FlocaleFreeNameProperty (ptext=0xbfbfcfb4) at Flocale.c:2363
#7 0x0806d3ab in HandlePropertyNotify (ea=0xbfbfd014) at events.c:3422
#8 0x0806c369 in dispatch_event (e=0xbfbfd044) at events.c:4135
#9 0x0806ca5f in HandleEvents () at events.c:4179
#10 0x0808e06e in main (argc=1, argv=0xbfbfd7ac) at fvwm.c:2591
(gdb) frame 4
#4 0x4842408e in free (ptr=0x80f58e0) at jemalloc_jemalloc.c:1212
1212usize = isalloc(ptr, config_prof);
(gdb) print *ptr
Attempt to dereference a generic pointer.
(gdb) up 1
#5 0x48164b7d in XFree (data=0x80f58e0) at XlibInt.c:1701
1701XlibInt.c: No such file or directory.
(gdb) print *data
Attempt to dereference a generic pointer.
(gdb) up 1
#6 0x080c4f2f in FlocaleFreeNameProperty (ptext=0xbfbfcfb4) at Flocale.c:2363
2363Flocale.c: No such file or directory.
(gdb) print *ptext
$5 = {name = 0x80f58e0 Untitled, name_list = 0x0}
jemalloc is asserting that the page which contains 0x80f58e0 is allocated
according to the containing chunk's page map, but the chunk header isn't even
mapped, and the attempted read causes a segfault. This is almost certainly a
result of calling free() with a bogus pointer.
Jason___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: possible je-malloc issue
On Thu, Aug 02, 2012 at 04:21:20PM -0700, Jason Evans wrote:
On Aug 2, 2012, at 3:32 PM, Steve Kargl wrote:
(gdb) print *ptr
Attempt to dereference a generic pointer.
(gdb) up 1
#5 0x48164b7d in XFree (data=0x80f58e0) at XlibInt.c:1701
1701XlibInt.c: No such file or directory.
(gdb) print *data
Attempt to dereference a generic pointer.
(gdb) up 1
#6 0x080c4f2f in FlocaleFreeNameProperty (ptext=0xbfbfcfb4) at
Flocale.c:2363
2363Flocale.c: No such file or directory.
(gdb) print *ptext
$5 = {name = 0x80f58e0 Untitled, name_list = 0x0}
jemalloc is asserting that the page which contains 0x80f58e0 is allocated
according to the containing chunk's page map, but the chunk header isn't
even mapped, and the attempted read causes a segfault. This is almost
certainly a result of calling free() with a bogus pointer.
I suspect, but cannot prove it yet, that ptext-name points at
a static buffer. I'm trying to understand the code now. The
failure starts in
void FlocaleFreeNameProperty(FlocaleNameString *ptext)
{
if (ptext-name_list != NULL)
{
if (ptext-name != NULL ptext-name != *ptext-name_list)
XFree(ptext-name);
XFreeStringList(ptext-name_list);
ptext-name_list = NULL;
}
else if (ptext-name != NULL)
{
XFree(ptext-name);
}
ptext-name = NULL;
return;
}
In the code the XFree(ptext-name) appears protected by the check
for a NULL pointer, but it appears that 0x80f58e0 is invalid. I
don't know how to check for an non-NULL invalid pointer. I suppose
I can hack fvwm to leak memory at worse.
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: possible je-malloc issue
On Thu, Aug 02, 2012 at 04:36:35PM -0700, Steve Kargl wrote:
On Thu, Aug 02, 2012 at 04:21:20PM -0700, Jason Evans wrote:
On Aug 2, 2012, at 3:32 PM, Steve Kargl wrote:
(gdb) print *ptr
Attempt to dereference a generic pointer.
(gdb) up 1
#5 0x48164b7d in XFree (data=0x80f58e0) at XlibInt.c:1701
1701XlibInt.c: No such file or directory.
(gdb) print *data
Attempt to dereference a generic pointer.
(gdb) up 1
#6 0x080c4f2f in FlocaleFreeNameProperty (ptext=0xbfbfcfb4) at
Flocale.c:2363
2363Flocale.c: No such file or directory.
(gdb) print *ptext
$5 = {name = 0x80f58e0 Untitled, name_list = 0x0}
jemalloc is asserting that the page which contains 0x80f58e0 is allocated
according to the containing chunk's page map, but the chunk header isn't
even mapped, and the attempted read causes a segfault. This is almost
certainly a result of calling free() with a bogus pointer.
I suspect, but cannot prove it yet, that ptext-name points at
a static buffer. I'm trying to understand the code now. The
failure starts in
void FlocaleFreeNameProperty(FlocaleNameString *ptext)
{
if (ptext-name_list != NULL)
{
if (ptext-name != NULL ptext-name != *ptext-name_list)
XFree(ptext-name);
XFreeStringList(ptext-name_list);
ptext-name_list = NULL;
}
else if (ptext-name != NULL)
{
XFree(ptext-name);
}
ptext-name = NULL;
return;
}
In the code the XFree(ptext-name) appears protected by the check
for a NULL pointer, but it appears that 0x80f58e0 is invalid. I
don't know how to check for an non-NULL invalid pointer. I suppose
I can hack fvwm to leak memory at worse.
I think I found the problem in fvwm/add_window.c
one finds the global entity
char NoName[] = Untitled; /* name if no name in XA_WM_NAME */
then later in fvwm/events.c one finds
FlocaleNameString new_name = { NoName, NULL };
At some point FlocaleFreeNameProperty is called to
free the FlocaleNameString that contains NoName,
and XFree() is not happy.
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ttydev_cdevsw has no d_purge
On 8/2/12 4:23 AM, Ed Schouten wrote: 2012/8/2 Julian Elischer jul...@freebsd.org: I think that the /dev/entries can (and SHOULD) go away when the hardware goes away and even be re-used. But here's the point. TTYs are used in a different way than other device nodes. Regular device nodes are simply opened by a set of independent process (e.g. dd if=/dev/da0, a music player opening /dev/dsp, etc). TTYs are used by a set of processes that share a weak relationship, namely all belonging to the same login session. Things *really* break if you were to forcefully remove a TTY device node and replace it by another TTY. Even for physical devices it would be really bad to do. Consider a system that has two USB to serial converters that are used for interactive login sessions. One is plugged in, the other one isn't. If you unplug one device and plug in the other, you never want the processes from the one login session to start interacting with the other device. Also, applications relying on the user accounting database (utmpx) will start to behave non-deterministically then. Do we really want biff and wall to write stuff to random TTYs? they would only do that if they were refering to the node BY NAME. Once it's opened, the accesses go via teh internal ( vnode?) objects. if you make the name go away then that wouldn't have any effect on processes that already have the node open. It would be a property of the driver though to decide what happens, but EVENTUALLY yu are going to need to do something about it. Whether or not the TTY is a pseudo-terminal or not is completely irrelevant in my opinion. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On Thu, Aug 2, 2012 at 5:37 PM, Julian Elischer jul...@freebsd.org 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rtld dropping core on recent -current
On Thu, 2 Aug 2012 14:39:54 -0700
Steve Kargl s...@troutmask.apl.washington.edu wrote:
% file /usr/local/bin/ppdpo
/usr/local/bin/ppdpo: ELF 32-bit LSB shared object, Intel 80386, \
version 1 (FreeBSD), dynamically linked (uses shared libs),
FreeBSD-style,\ for FreeBSD 10.0 (115), stripped
% ldd /usr/local/bin/ppdpo
/usr/local/bin/ppdpo:
/usr/local/bin/ppdpo: signal 11
It is weird that program tries to dlopen what appears to be the binary
(itself?), but that did uncover the issue. Please try attached patch,
I only very lightly tested it here.
Also available here:
http://people.freebsd.org/~kan/rtld-digest-notes.diff
--
Alexander Kabaev
diff --git a/libexec/rtld-elf/map_object.c b/libexec/rtld-elf/map_object.c
index 509a64f..350d437 100644
--- a/libexec/rtld-elf/map_object.c
+++ b/libexec/rtld-elf/map_object.c
@@ -153,7 +153,6 @@ map_object(int fd, const char *path, const struct stat *sb)
break;
note_start = (Elf_Addr)(char *)hdr + phdr-p_offset;
note_end = note_start + phdr-p_filesz;
- digest_notes(obj, note_start, note_end);
break;
}
@@ -292,6 +291,11 @@ map_object(int fd, const char *path, const struct stat *sb)
obj-relro_page = obj-relocbase + trunc_page(relro_page);
obj-relro_size = round_page(relro_size);
+if (note_start note_end)
+{
+ digest_notes(obj, note_start, note_end);
+}
+
munmap(hdr, PAGE_SIZE);
return (obj);
signature.asc
Description: PGP signature
Re: rtld dropping core on recent -current
On Thu, Aug 02, 2012 at 09:55:36PM -0400, Alexander Kabaev wrote: On Thu, 2 Aug 2012 14:39:54 -0700 Steve Kargl s...@troutmask.apl.washington.edu wrote: % file /usr/local/bin/ppdpo /usr/local/bin/ppdpo: ELF 32-bit LSB shared object, Intel 80386, \ version 1 (FreeBSD), dynamically linked (uses shared libs), FreeBSD-style,\ for FreeBSD 10.0 (115), stripped % ldd /usr/local/bin/ppdpo /usr/local/bin/ppdpo: /usr/local/bin/ppdpo: signal 11 It is weird that program tries to dlopen what appears to be the binary (itself?), but that did uncover the issue. Please try attached patch, I only very lightly tested it here. Also available here: http://people.freebsd.org/~kan/rtld-digest-notes.diff The patch appears to fix the problem. Before the patch % find /usr/local/bin -type f | xargs -n1 file -F ' ' | grep ELF \ | grep ELF | cut -f1 -d' ' | xargs ldd -f '%A %o\n' | grep libpng.so.6 /usr/local/bin/ppdc: signal 11 /usr/local/bin/ppdhtml: signal 11 /usr/local/bin/ipptool: signal 11 /usr/local/bin/cupstestdsc: signal 11 /usr/local/bin/cupstestppd: signal 11 /usr/local/bin/lpstat: signal 11 /usr/local/bin/lpq: signal 11 /usr/local/bin/lpr: signal 11 /usr/local/bin/ppdpo: signal 11 /usr/local/bin/cancel: signal 11 /usr/local/bin/lpoptions: signal 11 /usr/local/bin/lppasswd: signal 11 /usr/local/bin/ppdi: signal 11 /usr/local/bin/ppdmerge: signal 11 /usr/local/bin/inkscape libpng.so.6 /usr/local/bin/inkview libpng.so.6 /usr/local/bin/lp: signal 11 /usr/local/bin/lprm: signal 11 After applying the patch and rebuilding % find /usr/local/bin -type f | xargs -n1 file -F ' ' | grep ELF \ | cut -f1 -d' ' | xargs ldd -f '%A %o\n' | grep libpng.so.6 /usr/local/bin/inkscape libpng.so.6 /usr/local/bin/inkview libpng.so.6 Thanks for the quick response. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: VirtualBox: Eating up 100% CPU, freezing Windows 7
On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: I discover that when running Windows 7 in a VirtualBox On FreeBSD 10 (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7 for more than a minute. For a minute or so, I can work, then, the freeze occurs again. I can't see this behaviour with a Ubuntu Guest on the same box. Is there Windows 7 specifica to be aware of? I am seeing the same thing. Also Win7 guest with Windows showing idle process at 99%, but my system is showing VB at 100%. The VM is only running a single CPU, so FreeBSD is still running OK, but the Win7 system seems to freeze up periodically. 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way since VB was updated to 4.1.18. Guest additions for 4.1.18 installed.All ports current. I'm thinking of backing off to 4.1.16. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: VirtualBox: Eating up 100% CPU, freezing Windows 7
On Thu, Aug 2, 2012 at 9:18 PM, Kevin Oberman kob6...@gmail.com wrote: On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: I discover that when running Windows 7 in a VirtualBox On FreeBSD 10 (r238968: Wed Aug 1 14:26:40 CEST 2012), VBox is most recent from the ports, that the VirtualBox eats up 100% CPU time and freezes Windows 7 for more than a minute. For a minute or so, I can work, then, the freeze occurs again. I can't see this behaviour with a Ubuntu Guest on the same box. Is there Windows 7 specifica to be aware of? I am seeing the same thing. Also Win7 guest with Windows showing idle process at 99%, but my system is showing VB at 100%. The VM is only running a single CPU, so FreeBSD is still running OK, but the Win7 system seems to freeze up periodically. 9.1-PRERELEASE on amd64 updated yesterday (though it has been this way since VB was updated to 4.1.18. Guest additions for 4.1.18 installed.All ports current. I'm thinking of backing off to 4.1.16. I've been seeing consistent hangs with VBox 4.1.18, but mostly with shared folders and the like under Windows 7 with certain paths using Cygwin (probably an application issue, but I haven't dug into why things are that way). I'm not sure what the exact revision is for 9.1-BETA1, but there are a handful of threading and amd64-specific signal, etc related changes that may or may not affect things. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
