Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
On 08/02/2012 12:18, David Chisnall wrote: > Thank you for your thoughtful reply, You too ... I let some time go by to see what others had to say. I think it's disappointing that more people aren't concerned about this issue. > 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. And yet, that's exactly what happens. It's easy to understand why ... you have a bunch of people together in the same place, they all agree on a topic, and after all, since they are the ones who are there, they should be the ones to make the decision, right? It's not necessarily that they are trying to do something malicious, it's just human nature. I know, I used to travel to conferences for a living. > 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. I agree with these points as well. (Again, been there, done that.) In fact I'm quite confident that a lot of the "issues" people have with me are related to this deficiency. :) > Any official conversations happen on the mailing lists. This should be true, but it isn't. This is my point. > 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, ... so far, so good .. > for a limited set of 'everyone else'. ... and this is where I call shenanigans. This is an open project. Anything that is going to be done is going to be seen. If there are problems with a proposal it's better to see them early. If it's a good proposal, there is no reason not to share it. > 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. In the IETF context proposals often benefit from the real-time focus of attention, from both local and remote participants, that the meetings provide. There is no reason to believe that this would not be true in FreeBSD as well. > 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, That's an oft-repeated maxim, especially around here. But we've already demonstrated that it isn't true. The only time that this is true is if the work being done is in line with what the PTB want. I've demonstrated this time after time by volunteering to do various projects "my way" and being told that my efforts weren't welcome. Not to mention having my finished, working code reverted by a core team member for an inferior, broken result. So can we please stop repeating that BS and focus on the real issues? > 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. The community needs to not be accepting of the status quo, and demand that things be publicized on the lists first before decisions are made. Once again, if they are good decisions, they won't be harmed by sharing them in advance. If they are less-good, we could be saving someone efforts that would be otherwise wasted. > 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. Exactly. > 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 ro
Re: On cooperative work [Was: Re: newbus' ivar's limitation..]
> I suggest the starting point is a webpage with a link to the slides > being presented and a simple audio stream. two way, please. i am amazed that ietf had two-way back when it was the mbone. with multicast actually deployed, now it is one-way. randy ___ 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: pucdata.c addition
On 4 August 2012 10:52, David Boyd wrote:
> Can someone please add the following definition to pucdata.c?
>
> { 0x1415, 0x950a, 0x131f, 0x2032,
> "SIIG Cyber Serial Dual PCI 16C850 (20x family)",
> DEFAULT_RCLK * 10,
> PUC_PORT_4S, 0x10, 0, 8,
> },
I'll deal with it. In general, submitting a PR
(http://www.freebsd.org/send-pr.html) makes it easier to track these
things.
--
Eitan Adler
___
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: Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly)
On Sun, Aug 05, 2012 at 07:13:53PM +0300, Konstantin Belousov wrote: > On Sun, Aug 05, 2012 at 05:31:19PM +0200, Juergen Lock wrote: > > Hi kib, -current, seems we have a segfault in rtld when updating > > the multimedia/vlc port from the version currently in ports to the > > 2.0.3 CFT version from here: > > > > http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch > > > > (If you test the LIVEMEDIA knob you also need this update: > > > > http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch > > > > ) > Please do two things. > > 1. Provide me the output of readelf -a for the module that was loaded. > > 2. Recompile rtld with debug symbols and redo the build to get the useful > backtrace from core: > cd /usr/src/libexec/rtld-elf > make clean > make all install DEBUG_FLAGS=-g > Ok, someone who got the crash will have to do this as I couln't reproduce it here (sorry forgot to say...) Thanx, :) Juergen > > > > In article <20120804110952.4f3a9...@ernst.jennejohn.org> you write: > > >On Fri, 3 Aug 2012 18:36:33 +0200 > > >Juergen Lock wrote: > > > > > >> On Fri, Aug 03, 2012 at 05:00:37PM +0200, Rainer Hurling wrote: > > >> > On 03.08.2012 14:27 (UTC+2), Gary Jennejohn wrote: > > >> > > On Thu, 2 Aug 2012 22:56:26 +0200 > > >> > > Juergen Lock wrote: > > >> > > > > >> > > [trimmed irrelevant content] > > >> > >> Ok I added that check: > > >> > >> > > >> > >> http://people.freebsd.org/~nox/tmp/vlc-2.0.3-005.patch > > >> > >> > > >> > >> Enjoy, :) > > >> > >> > > >> > > > > >> > > AMD64 on HEAD. > > >> > > > > >> > > I always get this error, no matter which patch I use: > > >> > > > > >> > >GEN../modules/plugins.dat > > >> > > gmake[2]: *** [../modules/plugins.dat] Segmentation fault: 11 (core > > >> > > dumped) > > >> > > gmake[2]: Leaving directory > > >> > > `/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin' > > >> > > gmake[1]: *** [all-recursive] Error 1 > > >> > > gmake[1]: Leaving directory > > >> > > `/usr/ports/multimedia/vlc/work/vlc-2.0.3' > > >> > > gmake: *** [all] Error 2 > > >> > > *** [do-build] Error code 1 > > >> > > > >> > I get exactly the same error with CURRENT amd64. > > >> > > > >> Hm how old are both your installed src and ports? You two are the > > >> first to report this and I just tried to reproduce it on a head > > >> checkout from May 13 and ports from June 18, and couldn't. > > >> > > > > > >I update the ports and source trees almost every day. I do not install > > >new ports binaries unless absolutely necessary, so the ports binaries > > >are pretty much rather old. > > > > > >Just installed a new world/kernel today (updated yesterdya), r239006. > > > > > >> > BTW, mplayer from ports does not build with liveMedia-20120404 ... > > >> > > > >> > > Stop in /usr/ports/multimedia/vlc. > > >> > > *** [build] Error code 1 > > >> > > > > >> > > and there's a work/vlc-2.0.3/bin/vlc-cache-gen.core generated. > > >> > > > > >> > > May be because I have a mix of old and new dependencies, although > > >> > > the vlc > > >> > > port never tries to update any of them. > > >> > > > > >> Well ports never update dependencies themselves, you need to use > > >> tools like portmaster for that. > > >> > > > > > >I avoid using tools whenever possible. Maybe I will have to try > > >portmaster, but I dread seeing 50 ports updated just because I > > >want to update one port. > > > > > >I turned on -g in make.conf and ran vlc-cache-gen in gdb. Here's the > > >result. > > > > > >gdb /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen > > >GNU gdb 6.1.1 [FreeBSD] > > >Copyright 2004 Free Software Foundation, Inc. > > >GDB is free software, covered by the GNU General Public License, and you > > >are > > >welcome to change it and/or distribute copies of it under certain > > >conditions. > > >Type "show copying" to see the conditions. > > >There is absolutely no warranty for GDB. Type "show warranty" for details. > > >This GDB was configured as "amd64-marcel-freebsd"... > > >(gdb) r ../modules/ > > >Starting program: > > >/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen > > >../modules/ > > >[New LWP 100125] > > >[New Thread 802406400 (LWP 100125/vlc-cache-gen)] > > > > > >Program received signal SIGSEGV, Segmentation fault. > > >[Switching to Thread 802406400 (LWP 100125/vlc-cache-gen)] > > >0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1 > > >(gdb) bt > > >#0 0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1 > > >#1 0x0008006087e4 in symlook_obj () from /libexec/ld-elf.so.1 > > >#2 0x000800608ae7 in symlook_list () from /libexec/ld-elf.so.1 > > >#3 0x00080060911b in symlook_default () from /libexec/ld-elf.so.1 > > >#4 0x00080060939d in find_symdef () from /libexec/ld-elf.so.1 > > >#5 0x00080060375b in reloc_non_plt () from /libexec/ld-elf.so.1 > > >#6 0x000800606ae8 in relocate_object () from /libexec/ld-elf.so.1 > > >#7 0x0008006
Re: IPod crash seen with FreeBSD only
On Wed, Jul 18, 2012 at 11:22:50PM +0200, Hans Petter Selasky wrote: > Hi, > > I have one of those locked down silvery IPod's, and wanted to try out gnupod > to get some MP3's transferred to the device. I made it once, but then my luck > ended :-) Anyway I found what looks like a remote crash vulnerability in the > IPod firmware. How to make it crash: I had the same problem, but it only occurs when I plug in my ipod after the battery dies. I previously had to plug it into a Linux or Windows machine first and let it charge for a minute or two before I could plug into a FreeBSD machine without triggering the reset loop. Adding the quirk (with the correct product ID) fixes the problem for me. Thanks so much! -Mark ___ 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: Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly)
On Sun, Aug 05, 2012 at 05:31:19PM +0200, Juergen Lock wrote: > Hi kib, -current, seems we have a segfault in rtld when updating > the multimedia/vlc port from the version currently in ports to the > 2.0.3 CFT version from here: > > http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch > > (If you test the LIVEMEDIA knob you also need this update: > > http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch > > ) Please do two things. 1. Provide me the output of readelf -a for the module that was loaded. 2. Recompile rtld with debug symbols and redo the build to get the useful backtrace from core: cd /usr/src/libexec/rtld-elf make clean make all install DEBUG_FLAGS=-g > > In article <20120804110952.4f3a9...@ernst.jennejohn.org> you write: > >On Fri, 3 Aug 2012 18:36:33 +0200 > >Juergen Lock wrote: > > > >> On Fri, Aug 03, 2012 at 05:00:37PM +0200, Rainer Hurling wrote: > >> > On 03.08.2012 14:27 (UTC+2), Gary Jennejohn wrote: > >> > > On Thu, 2 Aug 2012 22:56:26 +0200 > >> > > Juergen Lock wrote: > >> > > > >> > > [trimmed irrelevant content] > >> > >> Ok I added that check: > >> > >> > >> > >> http://people.freebsd.org/~nox/tmp/vlc-2.0.3-005.patch > >> > >> > >> > >> Enjoy, :) > >> > >> > >> > > > >> > > AMD64 on HEAD. > >> > > > >> > > I always get this error, no matter which patch I use: > >> > > > >> > >GEN../modules/plugins.dat > >> > > gmake[2]: *** [../modules/plugins.dat] Segmentation fault: 11 (core > >> > > dumped) > >> > > gmake[2]: Leaving directory > >> > > `/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin' > >> > > gmake[1]: *** [all-recursive] Error 1 > >> > > gmake[1]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3' > >> > > gmake: *** [all] Error 2 > >> > > *** [do-build] Error code 1 > >> > > >> > I get exactly the same error with CURRENT amd64. > >> > > >> Hm how old are both your installed src and ports? You two are the > >> first to report this and I just tried to reproduce it on a head > >> checkout from May 13 and ports from June 18, and couldn't. > >> > > > >I update the ports and source trees almost every day. I do not install > >new ports binaries unless absolutely necessary, so the ports binaries > >are pretty much rather old. > > > >Just installed a new world/kernel today (updated yesterdya), r239006. > > > >> > BTW, mplayer from ports does not build with liveMedia-20120404 ... > >> > > >> > > Stop in /usr/ports/multimedia/vlc. > >> > > *** [build] Error code 1 > >> > > > >> > > and there's a work/vlc-2.0.3/bin/vlc-cache-gen.core generated. > >> > > > >> > > May be because I have a mix of old and new dependencies, although the > >> > > vlc > >> > > port never tries to update any of them. > >> > > > >> Well ports never update dependencies themselves, you need to use > >> tools like portmaster for that. > >> > > > >I avoid using tools whenever possible. Maybe I will have to try > >portmaster, but I dread seeing 50 ports updated just because I > >want to update one port. > > > >I turned on -g in make.conf and ran vlc-cache-gen in gdb. Here's the > >result. > > > >gdb /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen > >GNU gdb 6.1.1 [FreeBSD] > >Copyright 2004 Free Software Foundation, Inc. > >GDB is free software, covered by the GNU General Public License, and you are > >welcome to change it and/or distribute copies of it under certain conditions. > >Type "show copying" to see the conditions. > >There is absolutely no warranty for GDB. Type "show warranty" for details. > >This GDB was configured as "amd64-marcel-freebsd"... > >(gdb) r ../modules/ > >Starting program: > >/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen ../modules/ > >[New LWP 100125] > >[New Thread 802406400 (LWP 100125/vlc-cache-gen)] > > > >Program received signal SIGSEGV, Segmentation fault. > >[Switching to Thread 802406400 (LWP 100125/vlc-cache-gen)] > >0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1 > >(gdb) bt > >#0 0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1 > >#1 0x0008006087e4 in symlook_obj () from /libexec/ld-elf.so.1 > >#2 0x000800608ae7 in symlook_list () from /libexec/ld-elf.so.1 > >#3 0x00080060911b in symlook_default () from /libexec/ld-elf.so.1 > >#4 0x00080060939d in find_symdef () from /libexec/ld-elf.so.1 > >#5 0x00080060375b in reloc_non_plt () from /libexec/ld-elf.so.1 > >#6 0x000800606ae8 in relocate_object () from /libexec/ld-elf.so.1 > >#7 0x0008006084a8 in dlopen_object () from /libexec/ld-elf.so.1 > >#8 0x000800608f67 in rtld_dlopen () from /libexec/ld-elf.so.1 > >#9 0x000800affe95 in module_Load (p_this=0x80244c198, > >psz_file=0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin.so", > >p_handle=0x7fffd180, lazy=true) at posix/plugin.c:62 > >#10 0x000800adef4b in module_InitDynamic (obj=0x80244c198, > >path=0x802472c00 "../modules//codec/.libs/libfluidsy
Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly)
Hi kib, -current, seems we have a segfault in rtld when updating the multimedia/vlc port from the version currently in ports to the 2.0.3 CFT version from here: http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch (If you test the LIVEMEDIA knob you also need this update: http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch ) In article <20120804110952.4f3a9...@ernst.jennejohn.org> you write: >On Fri, 3 Aug 2012 18:36:33 +0200 >Juergen Lock wrote: > >> On Fri, Aug 03, 2012 at 05:00:37PM +0200, Rainer Hurling wrote: >> > On 03.08.2012 14:27 (UTC+2), Gary Jennejohn wrote: >> > > On Thu, 2 Aug 2012 22:56:26 +0200 >> > > Juergen Lock wrote: >> > > >> > > [trimmed irrelevant content] >> > >> Ok I added that check: >> > >> >> > >> http://people.freebsd.org/~nox/tmp/vlc-2.0.3-005.patch >> > >> >> > >> Enjoy, :) >> > >> >> > > >> > > AMD64 on HEAD. >> > > >> > > I always get this error, no matter which patch I use: >> > > >> > >GEN../modules/plugins.dat >> > > gmake[2]: *** [../modules/plugins.dat] Segmentation fault: 11 (core >> > > dumped) >> > > gmake[2]: Leaving directory >> > > `/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin' >> > > gmake[1]: *** [all-recursive] Error 1 >> > > gmake[1]: Leaving directory `/usr/ports/multimedia/vlc/work/vlc-2.0.3' >> > > gmake: *** [all] Error 2 >> > > *** [do-build] Error code 1 >> > >> > I get exactly the same error with CURRENT amd64. >> > >> Hm how old are both your installed src and ports? You two are the >> first to report this and I just tried to reproduce it on a head >> checkout from May 13 and ports from June 18, and couldn't. >> > >I update the ports and source trees almost every day. I do not install >new ports binaries unless absolutely necessary, so the ports binaries >are pretty much rather old. > >Just installed a new world/kernel today (updated yesterdya), r239006. > >> > BTW, mplayer from ports does not build with liveMedia-20120404 ... >> > >> > > Stop in /usr/ports/multimedia/vlc. >> > > *** [build] Error code 1 >> > > >> > > and there's a work/vlc-2.0.3/bin/vlc-cache-gen.core generated. >> > > >> > > May be because I have a mix of old and new dependencies, although the vlc >> > > port never tries to update any of them. >> > > >> Well ports never update dependencies themselves, you need to use >> tools like portmaster for that. >> > >I avoid using tools whenever possible. Maybe I will have to try >portmaster, but I dread seeing 50 ports updated just because I >want to update one port. > >I turned on -g in make.conf and ran vlc-cache-gen in gdb. Here's the >result. > >gdb /usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen >GNU gdb 6.1.1 [FreeBSD] >Copyright 2004 Free Software Foundation, Inc. >GDB is free software, covered by the GNU General Public License, and you are >welcome to change it and/or distribute copies of it under certain conditions. >Type "show copying" to see the conditions. >There is absolutely no warranty for GDB. Type "show warranty" for details. >This GDB was configured as "amd64-marcel-freebsd"... >(gdb) r ../modules/ >Starting program: >/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin/.libs/vlc-cache-gen ../modules/ >[New LWP 100125] >[New Thread 802406400 (LWP 100125/vlc-cache-gen)] > >Program received signal SIGSEGV, Segmentation fault. >[Switching to Thread 802406400 (LWP 100125/vlc-cache-gen)] >0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1 >(gdb) bt >#0 0x000800606588 in matched_symbol () from /libexec/ld-elf.so.1 >#1 0x0008006087e4 in symlook_obj () from /libexec/ld-elf.so.1 >#2 0x000800608ae7 in symlook_list () from /libexec/ld-elf.so.1 >#3 0x00080060911b in symlook_default () from /libexec/ld-elf.so.1 >#4 0x00080060939d in find_symdef () from /libexec/ld-elf.so.1 >#5 0x00080060375b in reloc_non_plt () from /libexec/ld-elf.so.1 >#6 0x000800606ae8 in relocate_object () from /libexec/ld-elf.so.1 >#7 0x0008006084a8 in dlopen_object () from /libexec/ld-elf.so.1 >#8 0x000800608f67 in rtld_dlopen () from /libexec/ld-elf.so.1 >#9 0x000800affe95 in module_Load (p_this=0x80244c198, >psz_file=0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin.so", >p_handle=0x7fffd180, lazy=true) at posix/plugin.c:62 >#10 0x000800adef4b in module_InitDynamic (obj=0x80244c198, >path=0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin.so", >fast=true) at modules/bank.c:536 >#11 0x000800adede2 in AllocatePluginFile (bank=0x7fffd490, >abspath=0x802472c00 "../modules//codec/.libs/libfluidsynth_plugin.so", >relpath=0x802472b80 "codec/.libs/libfluidsynth_plugin.so", >st=0x7fffd210) at modules/bank.c:479 >#12 0x000800adeca3 in AllocatePluginDir (bank=0x7fffd490, maxdepth=2, >absdir=0x802472b00 "../modules//codec/.libs", >reldir=0x802472a80 "codec/.libs") at modules/bank.c:440 >#13 0x000800adecd7 in AllocatePluginDir (bank=0x7fffd490, maxde
Re: ttydev_cdevsw has no d_purge
On Friday 03 August 2012 10:32:47 Ed Schouten wrote: > 2012/8/1 Hans Petter Selasky : > > I think the problem is like this, that in order to re-use the unit > > numbers for USB serial tty devices, the USB stack needs to wait until a > > TTY is actually freed, right? Else you will have a panic on creating > > devfs entries having the same name. > > Indeed. So the USB code could simply pick a different unit number. Hi Ed, USB could use a different Unit number. Some questions: When can the previous unit number be re-used? Is there a callback for this? When can the USB serial code assume that it will not be called again and that all callbacks are drained? --HPS ___ 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
Am 08/04/12 22:26, schrieb Doug Barton: > On 08/04/2012 00:40, O. Hartmann wrote: >> No, also in my case. I build world and the VBox software with each >> kernel - usually. > > You can ensure that by putting this in src.conf: > > PORTS_MODULES= emulators/virtualbox-ose-kmod > > You can place other modules in that list as well. I use vbox so you can > be pretty confident that this is going to keep working. :) > > Doug > Hello Doug. This is exactly how I build the kernel modules for nvidia and VBox ;-) So I guess this makes it unlikely - in my case - that the problems occur due to unsynchronized kernel/modules. Oliver signature.asc Description: OpenPGP digital signature
