GrandCentralDispatch in FreeBSD?

2010-05-13 Thread Tom Evans
Hi Robert

I saw today that you've written a proof of concept MPM for apache in
GCD [1] - are there any plans to port GCD to FreeBSD?

Cheers

Tom

[1] http://lists.macosforge.org/pipermail/libdispatch-dev/2010-May/000352.html
___
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: GrandCentralDispatch in FreeBSD?

2010-05-13 Thread Christian Brueffer
On Thu, May 13, 2010 at 03:21:55PM +0100, Tom Evans wrote:
 Hi Robert
 
 I saw today that you've written a proof of concept MPM for apache in
 GCD [1] - are there any plans to port GCD to FreeBSD?
 

It's already there, see http://wiki.freebsd.org/GCD

- Christian

-- 
Christian Brueffer  ch...@unixpages.org bruef...@freebsd.org
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D


pgpSna1iEve0o.pgp
Description: PGP signature


Re: GrandCentralDispatch in FreeBSD?

2010-05-13 Thread Brooks Davis
On Thu, May 13, 2010 at 03:21:55PM +0100, Tom Evans wrote:
 Hi Robert
 
 I saw today that you've written a proof of concept MPM for apache in
 GCD [1] - are there any plans to port GCD to FreeBSD?

Robert ported it to FreeBSD when Apple released it:

http://libdispatch.macosforge.org/post/libdispatch-on-freebsd/

-- Brooks


pgpjEtJUN66Lc.pgp
Description: PGP signature


Re: GrandCentralDispatch in FreeBSD?

2010-05-13 Thread Robert N. M. Watson

On 13 May 2010, at 10:21, Tom Evans wrote:

 I saw today that you've written a proof of concept MPM for apache in
 GCD [1] - are there any plans to port GCD to FreeBSD?

Hi Tom--

Actually, I also ported GCD to FreeBSD last year, and developed the MPM on 
FreeBSD/GCD :-). It requires a post-8.0 version of 8-STABLE, and then 
libdispatch port + clang compiler. You can find out more here:

  http://wiki.freebsd.org/GCD

The clang dependency is due to C Blocks, and we have an unpatched gcc so 
gcc-compiled applications can't use blocks.

Robert___
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: [PATCH:] psm(4) IntelliMouse Explorer KVM hack breaks my mouse

2010-05-13 Thread Juergen Lock
On Wed, May 12, 2010 at 12:42:34PM +0200, Gary Jennejohn wrote:
 On Tue, 11 May 2010 20:41:41 +0200
 Juergen Lock n...@jelal.kn-bremen.de wrote:
 
   So now I made a patch that allows disabling that KVM hack via device
  hints, appended below.  (hint.psm.0.flags=0x1 - or do you guys
  think the hack should be disabled by default instead?)
  
 
 Don't change the behavior, leave it enabled by default.  For POLA.

Yeah ok I guess you are right...

 I've now put the patch on freefall:public_html too, and added links
to the relevant threads for it and the other pending src patches:

http://people.freebsd.org/~nox/

 Thanx, :)
Juergen
___
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


kgdb unuseable with cores on current (for some people)

2010-05-13 Thread Benjamin Kaduk

Hi all,

As was revealed in a recent thread here [1], several people have been 
unable to use kgdb on coredumps for the past few months (but possibly not 
everyone).


I am one of those affected, and have narrowed the breakage with a binary 
search to between SVN revisions 202883 and 202954 (that is, Jan 23 1200h 
and Jan 25 h).  Looking at the changes, alc's revision 202897 and 
attilio's revision 202933 look to be the most plausible culprits in terms 
of what they touched.  I will continue with my bisection, but with only 36 
revisions in play, it is probably worth looking for the bug in parallel 
with the bisection.


To recall, this manifests itself as kgdb printing the following on 
startup:

Cannot access memory at address 0xff0127e0

'bt' seems to think that it is on a NULL stack pointer (and fails), and 
attempting to set a different current process/thread using the 'proc' or 
'thread' commands errors with invalid [p|t]id.  However, I can walk the 
process list starting from allproc 


Looking at kgdb/kthr.c , the kgdb troubles would seem to stem from 
static struct kthr *first failing to get properly initialized, as the 
'proc' command searches starting from that pointer.  It's not immediately 
clear to me where in kgdb_thr_init() it is failing, though --- I see none 
of the warning messages from its error cases.


If no one has thoughts on a possible cause, I guess I can start 
instrumenting kgdb to locate its failure, but help would be appreciated.


Since this may be machine- and/or configuration-dependent, I have posted a 
dmesg and pciconf output here [2]; it's an amd64 machine with a Core2 Duo 
(T9400).



Thanks,

Ben Kaduk


[1] 
http://lists.freebsd.org/pipermail/freebsd-current/2010-May/017195.html


[2] http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/glossolalia/
___
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: kgdb unuseable with cores on current (for some people)

2010-05-13 Thread Kostik Belousov
On Fri, May 14, 2010 at 12:55:35AM -0400, Benjamin Kaduk wrote:
 Hi all,
 
 As was revealed in a recent thread here [1], several people have been 
 unable to use kgdb on coredumps for the past few months (but possibly not 
 everyone).
 
 I am one of those affected, and have narrowed the breakage with a binary 
 search to between SVN revisions 202883 and 202954 (that is, Jan 23 1200h 
 and Jan 25 h).  Looking at the changes, alc's revision 202897 and 
 attilio's revision 202933 look to be the most plausible culprits in terms 
 of what they touched.  I will continue with my bisection, but with only 36 
 revisions in play, it is probably worth looking for the bug in parallel 
 with the bisection.

Try reverting r202897 on fresh HEAD. I very much doubt that r202933
can be responsible.


pgpsGwYaRHMFk.pgp
Description: PGP signature