Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Garrett Cooper]

On Thu, Aug 2, 2012 at 9:18 PM, Kevin Oberman  wrote:
> On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O.
>  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"

Re: VirtualBox: Eating up 100% CPU, freezing Windows 7

[Kevin Oberman]

On Thu, Aug 2, 2012 at 12:54 AM, Hartmann, O.
 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: rtld dropping core on recent -current

[Steve Kargl]

On Thu, Aug 02, 2012 at 09:55:36PM -0400, Alexander Kabaev wrote:
> On Thu, 2 Aug 2012 14:39:54 -0700
> Steve Kargl  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: rtld dropping core on recent -current

[Alexander Kabaev]

On Thu, 2 Aug 2012 14:39:54 -0700
Steve Kargl  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: On cooperative work [Was: Re: newbus' ivar's limitation..]

[Kevin Oberman]

On Thu, Aug 2, 2012 at 5:37 PM, Julian Elischer  wrote:
> On 8/2/12 9:53 AM, Doug Barton wrote:
>>
>> On 08/02/2012 09:44, Garrett Cooper wrote:
>>>
>>> The "Watson/Losh connection" worked really well in BSDCan 2010 :).
>>
>> I wasn't going to mention that, since I didn't want to tell tales out of
>> school. But the fact that remote participation actually was provided for
>> "the right people," even though I was told repeatedly that it wasn't
>> possible, actually highlights a big part of the problem.
>
> bandwidth was limited and a single 1:1 skype connection was all we really
> could do.
>
> I did broadcast sessions a few years ago using the apple quicktime server
> but it was a lot of work and I think one person looked at part of one
> session.
>
>> Doug

First, too many of these posts assume way too much. I don't think
anyone should be thinking of any sort of what is commonly called
"teleconferencing". That would be nice, but is far more complex and
expensive, both in bandwidth and equipment, then should be considered
as a starting point.

I suggest the starting point is a webpage with a link to the slides
being presented and a simple audio stream. This is trivially possible
with a FreeBSD system and open-source software. A bandwidth of only
about 70kbps would be needed. Less with reasonable codec choice.
Several streams could be broadcast via a single, unicast stream to a
well connected server which woild then stream to end users It might be
augmented with jabber other open IM technology with someone at the
meeting if procedures for this could be agreed to. (Some vetting is
desirable, but will result in calls of censorship.)

For small rooms, microphones are fairly easy to handle and one-way
streams don't require echo cancellation.
As costs for video come down, that might be something to think about
some day, but is not required to allow remote "attendance".

Of course, unless this is publicized, no one will come (which
eliminates any technical issues).  :-)
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
freebsd-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..]

[Julian Elischer]

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: ttydev_cdevsw has no d_purge

[Julian Elischer]

On 8/2/12 4:23 AM, Ed Schouten wrote:

2012/8/2 Julian Elischer :

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: possible je-malloc issue

[Steve Kargl]

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: possible je-malloc issue

[Steve Kargl]

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

[Jason Evans]

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"

possible je-malloc issue

[Steve Kargl]

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"

rtld dropping core on recent -current

[Steve Kargl]

% 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 
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:
...
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=, sbp=,\
path=, name=, 
fd=) at /usr/src/libexec/rtld-elf/rtld.c:2100
#3  load_object (name=0xbfbfd8d0 "/usr/local/bin/ppdpo", fd_u=-1,\
refobj=0x48067000, flags=)
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"

Re: On cooperative work [Was: Re: newbus' ivar's limitation..]

[David Chisnall]

Thank you for your thoughtful reply,

On 2 Aug 2012, at 19:33, Doug Barton wrote:

> However, my point is that in spite of the fact that it's non-trivial,
> the mindset on this topic needs to change if the dev summits are going
> to continue to be significant focii of both work being done and
> decisions being made (which of course, they are).

I believe that, before that decision can be made, there needs to be some 
consensus on what the purpose of the DevSummits is.  In my view, DevSummits do 
not exist to set project policy.  They are places where:

- People can talk face to face about their current and planned projects.
- Developers can meet on a social basis, making remote working easier.

The latter is very important - I've found in other projects that it's far 
easier to work with someone on the other side of the world when you've chatted 
with them over a few beverages-of-choice.  

Any official conversations happen on the mailing lists.  DevSummits are for 
people working on similar things to meet and discuss their plans, and for 
people to have a chance to get to know what everyone else is doing, for a 
limited set of 'everyone else'.  Slides and summaries so on from the more 
structured parts of this are available afterwards, which helps people who can't 
attend get the same benefit - they know what other people are working on.

The original complaint that spawned this long discussion was that decisions 
about the project are made behind closed doors.  This is obviously true in the 
literal sense, as code always wins over chatter in an open source project, and 
the person willing to sit down and write the code gets the final say on how it 
should work, although ideally with code review, design feedback and so on from 
others.  Even if we broadcast everything that happens in the official parts of 
the DevSummits, that won't necessarily fix anything because a lot of the most 
productive conversations happen over dinner or in the pub.  

If there is a real problem to address, then it is people making policy 
decisions at DevSummits, without adequate consultation.  I have not observed 
this happening, but I would regard it as no different to people making policy 
decisions via private email, and something that should be subject to the same 
response: revisit the decisions in public if there are legitimate concerns 
raised about it, subject to the usual open source rule that the person actually 
willing to do the work gets to make the final call.

> What I'm *not* doing is demanding that any one person, or even any one
> group take responsibility for solving the whole problem on their own.
> Unfortunately, due to my inability to actually attend these meetings, I
> won't be able to provide the kind of hands-on assistance that I'd like
> to be able to. However it sounds like there may be financial resources
> available through the foundation, which would go a long way towards
> making a solution possible.

Finance is not the only obstacle.  In some venues, bandwidth is a problem (not 
at Cambridge hopefully - people will have stopped using it all to stream the 
olympics by then), but in other venues we only have WiFi, which is shared with 
a room full of developers.  If we buy some equipment (decent microphones are 
not always available - we were unable to find one at FOSDEM for remote 
attendees, for example), then it would need to be transported between events, 
and someone would need to be responsible for looking after it and ensuring that 
it is set up correctly at each event.  

> The next step would be for people to agree that this is a problem that
> *needs* to be solved, followed by willingness on the part of dev summit
> organizers to support these efforts, which will hopefully lead to people
> who are willing and interested to step up and actually provide
> solutions. It's already been true in the past that various companies
> have volunteered to do this. There is no reason to believe that it
> wouldn't happen again if organizers are willing to be supportive.

There are two proposals:  Remote viewing and remote participation.  Remote 
viewing, being non-interactive, does not have to be done via streaming, it can 
be done by recording the event and making it available online.  Even this is 
not trivial: we've done it for the GNUstep devroom at FOSDEM most years, and it 
typically takes a long time to get the videos edited and uploaded.  ARM sent a 
professional team to do it at EuroLLVM, and yet they didn't have enough 
equipment to cover everything (my tutorial, for example, was not recorded).  I 
would say that this is something that is very useful for presentation-style 
events, but DevSummits are typically more round-table discussions and hacking 
sessions than presentations.

Remote participation is bidirectional, and I am a lot more wary about that.  
The productivity of a meeting is usually inversely proportional to the number 
of attendees, and allowing a lot more people in does not ne

Re: On cooperative work [Was: Re: newbus' ivar's limitation..]

[Doug Barton]

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..]

[David Chisnall]

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..]

[Doug Barton]

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..]

[Doug Barton]

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..]

[Doug Barton]

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..]

[John Baldwin]

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..]

[Gary Palmer]

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..]

[Davide Italiano]

On Wed, Aug 1, 2012 at 7:05 PM, Arnaud Lacombe  wrote:
> Hi,
>
> On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao  wrote:
>> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe  wrote:
>>> Hi,
>>>
>>> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao  wrote:

 You don't want to work cooperatively.

>>> Why is it that mbuf's refactoring consultation is being held in
>>> internal, private, committers-and-invite-only-restricted meeting at
>>> BSDCan ?
>>>
>>> Why is it that so much review and discussion on changes are held privately ?
>>
>> Arnaud,
>> belive me, to date I don't recall a single major technical decision
>> that has been settled exclusively in private (not subjected to peer
>> review) and in particular in person (e-mail help you focus on a lot of
>> different details that you may not have under control when talking to
>> people, etc).
>>
> Whose call is it to declare something worth public discussion ? No one.
>
> Every time I see a "Suggested by:", "Submitted by:", "Reported by:",
> and especially "Approved by:", there should to be a public reference
> of the mentioned communication.
>
>> Sometimes it is useful that a limited number of developers is involved
>> in initial brainstorming of some works,
>>
> Never.
>
>> but after this period
>> constructive people usually ask for peer review publishing their plans
>> on the mailing lists or other media.
>>
> Again, never. By doing so, you merely put the community in a situation
> where, well, "We, committers, have come with this, you can either
> accept or STFU, but no major changes will be made because we decided
> so."
>
> The callout-ng conference at BSDCan was just beautiful, it was basically:
>
> Speaker: "we will do this"
> Audience: "how about this situation ? What you will do will not work."
> Speaker: "thank you for listening, end of the conference"
>
> It was beautiful to witness.
>

Well, my talk was mainly there to collect some opinion on how to
continue my work.
IIRC, the only one objection was on supporting callout execution from
hw interrupt context. Mainly, the objection moved was that there were
no practical applications for that. It turned out I found some, and in
any case it wasn't "it will not work" but "probably it's not an effort
you want to put because the consumers that can exploit some
functionality are few". I wasn't really so familiar with that so I
hesitated in answering. In any case, I liked a lot the objection moved
by Attilio because it gave me the possibility to investigate and find
out the right direction. As you may see, there's a branch in projects/
in which the feature that "won't work" is implemented, so, maybe
you're missing something.
If you had some concerns on it you can raise up your hand and tell:
"hey, that sucks". It would be better than getting this feedback after
3 months of work honestly. I have nothing in contrary about getting
feedbacks (negative or positive). But probably you belong to that kind
of people that are able to tell only behind a monitor, so this is my
last word on the topic.
Get a life.


>> If you don't see any public further discussion this may be meaning:
>> a) the BSDCan meetings have been fruitless and there is no precise
>> plan/roadmap/etc.
>>
> so not only you make it private, but it shamelessly failed...
>
>> b) there is still not consensus on details
>>
> Then the discussion should stop, public records are kept for reference
> in the future. There is no problem with this.
>
>> and you can always publically asked on what was decided and what not.
>> Just send a mail to interested recipients and CC any FreeBSD mailing
>> list.
>>
> This is not the way "openness" should be about.
>
>  - Arnaud
>
>> Attilio
>>
>>
>> --
>> Peace can only be achieved by understanding - A. Einstein
> ___
> freebsd-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..]

[Warner Losh]

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..]

[David Chisnall]

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..]

[Doug Barton]

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..]

[Doug Barton]

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..]

[Doug Barton]

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..]

[David Chisnall]

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..]

[Doug Barton]

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..]

[Doug Barton]

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..]

[Garrett Cooper]

On Aug 2, 2012, at 9:20 AM, Scott Long wrote:

> 
> On Aug 2, 2012, at 12:23 AM, Kevin Oberman  wrote:
> 
>> Doug makes some good points.
> 
> No, he doesn't.  He and Arnould being argumentative and accusatory where none 
> of that is warranted.
> 
> I used to run the devsummits, and we did tele-conference lines for remote 
> people to participate.  After I stepped down, others took it up and did the 
> same thing.  Usually, the lines were unused.  I suspect that organizers 
> simply stopped thinking about them after a while because of poor interest.  
> There is no conspiracy of exclusion here, just simple human apathy.

The "Watson/Losh connection" worked really well in BSDCan 2010 :).
Advertising the teleconferencing lines might be an issue (I would have 
loved to have joined in some of the remote conferences, if for nothing more 
than be a fly on the wall, this year), but that's a separate thing aside.
There's some misunderstanding, assumption, etc mixed together in this 
mailing chain that I think is probably better resolved with some face-to-face 
conversations or maybe just more rational (and less heated) discussion.
Thanks!
-Garrett___
freebsd-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..]

[Doug Barton]

On 08/02/2012 09:20, Scott Long wrote:
> 
> On Aug 2, 2012, at 12:23 AM, Kevin Oberman 
> wrote:
> 
>> Doug makes some good points.
> 
> No, he doesn't. 

Yes I do! (So there)

> He and Arnould being argumentative and accusatory
> where none of that is warranted.
> 
> I used to run the devsummits, and we did tele-conference lines for
> remote people to participate. 

I singled out BSDCAN specifically since that's "where the action is" for
the last several years. I do recall your efforts in this regard, but it
so happened that I was able to attend most of them in person back then.
No slight towards what you did was intended.

> After I stepped down, others took it
> up and did the same thing.  Usually, the lines were unused.  I
> suspect that organizers simply stopped thinking about them after a
> while because of poor interest.  There is no conspiracy of exclusion
> here, just simple human apathy.

Here I have to disagree with you. Once again, speaking specifically
about BSDCAN dev summits, I repeatedly asked the organizers to provide
some sort of audio stream (phone, Internet, anything) and was repeatedly
told it wasn't possible. This was not a case of lack of interest. This
was a case of "We understand that it is something people want, but it
isn't going to happen."

> The invite system for the devsummit was, and still is, purely about
> providing some order to the process.  It ensures that people
> attending are willing to demonstrate a minimum amount of interest,
> more than just wondering by a room one day and dropping in for free
> food and wifi. 

I specifically made allowances for this issue in my post.

Doug

-- 

I am only one, but I am one.  I cannot do everything, but I can do
something.  And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)
___
freebsd-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))

[suraj sandhu]

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..]

[Scott Long]

On Aug 2, 2012, at 12:23 AM, Kevin Oberman  wrote:

> Doug makes some good points.

No, he doesn't.  He and Arnould being argumentative and accusatory where none 
of that is warranted.

I used to run the devsummits, and we did tele-conference lines for remote 
people to participate.  After I stepped down, others took it up and did the 
same thing.  Usually, the lines were unused.  I suspect that organizers simply 
stopped thinking about them after a while because of poor interest.  There is 
no conspiracy of exclusion here, just simple human apathy.

The invite system for the devsummit was, and still is, purely about providing 
some order to the process.  It ensures that people attending are willing to 
demonstrate a minimum amount of interest, more than just wondering by a room 
one day and dropping in for free food and wifi.  If anyone feels that they are 
being excluded, it's because they are too lazy to go beyond being argumentative 
on a mailing list.

Scott

___
freebsd-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

[deeptech71]

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..]

[David Chisnall]

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: ttydev_cdevsw has no d_purge

[Poul-Henning Kamp]

In message 
, Ed Schouten writes:
>2012/8/2 Julian Elischer :

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..]

[Wojciech Puchar]

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

[Ed Schouten]

2012/8/2 Julian Elischer :
> 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 
___
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

[Hartmann, O.]

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"