Re: soclose() so-so_upcall() = race?
On Fri, 7 Mar 2008, Alexander Motin wrote: As I can see so_upcall() callback is called with SOCKBUF_MTX unlocked. It means that SB_UPCALL flag can be removed during call and socket can be closed and deallocated with soclose() while callback is running. Am I right or I have missed something? How in that situation socket pointer protected from being used after free? There are known problems with so_upcall and locking, including this one. The other problems include: - The locking condition on entering the upcall depends on the invocation point and is inconsistent. - The protection of the upcall field and flag are inconsistent. - Consumers of so_upcall, such as socket accept filters, don't properly respect the locking environment they run in. - Some (all) accept filters produce nastily convoluted stack traces involving recursion across really odd combinations of sockets and protocols. For example, you can see soisdisconnected() calling soisconnected(). Some of this is inherent to the design of accept filters and so_upcall and follows from using a single function pointer for many different cases. I have an 8.x todo list item to try and figure out how to make so_upcall and accept filters rational in the context of fine-grained locking, but I've not yet reached that point on my todo list. I think we can continue to incrementally hack so_upcall and accept filters to fix many races, but the reality is that we need a more coherent model for dealing with accept filters. One idea that Colin Percival (I think) suggested is that we separate socket upcalls from accept filters, and that accept filters consistent of a predicate for completion rather than directly invoking socket state transitions. I've not explored the implications, but think it might well be a good idea to avoid the weird stack traces. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
sysctl: good practices and how to deprecate a node
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I'm currently working again on the Synaptics Touchpad support[1] in psm(4). The enable_synaptics() probe function adds a subtree to hw.psm; I didn't changed its behaviour for now. This subtree is created only if: o hw.psm.synaptics_support is true o no previous probe function took the device. If the function doesn't find a Synaptics touchpad, the tree is left created. First, is enable_synaptics() the right place to add this subtree (compared to a globally created tree, like hw.psm)? If enable_synaptics() is the way to go, should it be always created if hw.psm.synaptics_support is true, even if no touchpad is found? Or only when the touchpad is detected? In psmsoftintr(), the code in FreeBSD doesn't check for bad sysctl values. My patch doesn't do it either for now. But wrong values could cause division by zero for example. Is there a way to check sysctls only when they are modified, instead of before every use? Last question: I expanded the Synaptics subtree with my own nodes but there are three nodes which are not used anymore. How should I handle deprecation of these nodes? Thanks :) [1] See the wiki: http://wiki.freebsd.org/SynapticsTouchpad - -- Jean-Sébastien Pédron http://www.dumbbell.fr/ PGP Key: http://www.dumbbell.fr/pgp/pubkey.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfRFMUACgkQa+xGJsFYOlOrZwCfbtAZw1nZ6xImO+azyprKfl+1 kGcAnjifjCtz3BvXkuj9sEWuCUakKvp1 =oLs1 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
libpthread/fork issue
I'm working on FreeBSD 6.2 and I'm wondering if anybody can help with an issue I've found using fork and threads. The attached program demonstrates the problem. In short, if a process creates a thread, joins the thread, then forks a child process which creates a thread, the child's attempt to create a thread will cause the program to dump core with the following error message: Fatal error 'mutex is on list' at line 540 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0). This seems to be true using an SMP or UP kernel. If you run the attached program with no arguments, the parent process will not create and join a thread and will not crash. Here is the output: [Sherlock]$ ./threadTest child: born child: thread created child: thread joined parent: child died If you run the attached program with -crash, the parent process creates and joins a thread, causing the error: [Sherlock]$ ./threadTest -crash parent: thread created parent: thread joined child: born Fatal error 'mutex is on list' at line 540 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0) parent: child died Here is the backtrace of the resulting core: #0 0x28097537 in pthread_testcancel () from /lib/libpthread.so.2 [New Thread 0x8053200 (LWP 100163)] [New Thread 0x8053000 (LWP 100201)] (gdb) where #0 0x28097537 in pthread_testcancel () from /lib/libpthread.so.2 #1 0x2808689a in sigaction () from /lib/libpthread.so.2 #2 0x2808088d in pthread_kill () from /lib/libpthread.so.2 #3 0x28080256 in raise () from /lib/libpthread.so.2 #4 0x28159b78 in abort () from /lib/libc.so.6 #5 0x28097c6f in pthread_testcancel () from /lib/libpthread.so.2 #6 0x2808c85f in _pthread_mutex_trylock () from /lib/libpthread.so.2 #7 0x2808d590 in _pthread_mutex_lock () from /lib/libpthread.so.2 #8 0x28083361 in _spinlock () from /lib/libpthread.so.2 #9 0x280f7ddb in _UTF8_init () from /lib/libc.so.6 #10 0x28172940 in _thread_autoinit_dummy_decl_stub () from /lib/libc.so.6 #11 0x28074200 in ?? () #12 0x2804f405 in symlook_obj () from /libexec/ld-elf.so.1 #13 0x280883ff in pthread_attr_init () from /lib/libpthread.so.2 #14 0x280848fd in sigaction () from /lib/libpthread.so.2 #15 0x2808e915 in pthread_mutexattr_init () from /lib/libpthread.so.2 #16 0x28088116 in pthread_create () from /lib/libpthread.so.2 #17 0x08048795 in spawnThread (caller=0x80489f0 child) at threadTest.c:21 #18 0x08048879 in main (argc=2, argv=0x17e) at threadTest.c:62 Any help would be greatly appreciated. -Shaun Makefile Description: Makefile threadTest.c Description: threadTest.c ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Versioned symbols
Jeremy Chadwick escreveu: On Thu, Mar 06, 2008 at 11:28:39PM -0300, Adriano dos Santos Fernandes wrote: I want to make versioned symbols as they work in Linux, but I had no success with FreeBSD. This seems quite relevant, specific to RELENG_7. (Said feature isn't available in earlier releases): Thanks Jeremy... My usage for versioned symbols would be to have multiple shared libraries implementing the same entrypoints... For dlopen'ed libraries, I suppose there is no problem with unversioned symbols, correct? But I want a kind of Windows DLL semantics... If my app dynamic loads lib1 and lib2, that implements the same functions and latter it loads lib3, a different library linked against lib2 (-l2). I want that calls from lib3 always go to lib2. Are versioned symbols the only way to achieve that or there is another way? Thanks, Adriano ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Comments on pmake diffs for building on Linux
Tom Evans writes: Yup. The proof will be in the pudding, as they say. The proof of the pudding is in the eating, actually. There's no proof actually in the pudding. /pedant Add some brandy, or maybe rum :-) Makes the coding more fun. Maybe not faster or more accurate, but more fun. Robert Huff ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libpthread/fork issue
On Thu, Mar 06, 2008 at 09:45:15PM -0600, Marko, Shaun wrote: In short, if a process creates a thread, joins the thread, then forks a child process which creates a thread, the child's attempt to create a thread will cause the program to dump core with the following error message. fork and pthread should not be mixed. You can and normally should only assume that the current thread is present in the child. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysctl: good practices and how to deprecate a node
On Friday 07 March 2008 05:11:17 am Jean-Sébastien Pédron wrote: Hello, I'm currently working again on the Synaptics Touchpad support[1] in psm(4). The enable_synaptics() probe function adds a subtree to hw.psm; I didn't changed its behaviour for now. This subtree is created only if: o hw.psm.synaptics_support is true o no previous probe function took the device. If the function doesn't find a Synaptics touchpad, the tree is left created. First, is enable_synaptics() the right place to add this subtree (compared to a globally created tree, like hw.psm)? Sure. If enable_synaptics() is the way to go, should it be always created if hw.psm.synaptics_support is true, even if no touchpad is found? Or only when the touchpad is detected? Probably only if you have an actual touchpad. In psmsoftintr(), the code in FreeBSD doesn't check for bad sysctl values. My patch doesn't do it either for now. But wrong values could cause division by zero for example. Is there a way to check sysctls only when they are modified, instead of before every use? Yes, use a SYSCTL_PROC() for those nodes. Last question: I expanded the Synaptics subtree with my own nodes but there are three nodes which are not used anymore. How should I handle deprecation of these nodes? Just remove them. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libpthread/fork issue
On Thursday 06 March 2008 10:45:15 pm Marko, Shaun wrote: I'm working on FreeBSD 6.2 and I'm wondering if anybody can help with an issue I've found using fork and threads. The attached program demonstrates the problem. In short, if a process creates a thread, joins the thread, then forks a child process which creates a thread, the child's attempt to create a thread will cause the program to dump core with the following error message: Fatal error 'mutex is on list' at line 540 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0). This seems to be true using an SMP or UP kernel. If you run the attached program with no arguments, the parent process will not create and join a thread and will not crash. Here is the output: [Sherlock]$ ./threadTest child: born child: thread created child: thread joined parent: child died If you run the attached program with -crash, the parent process creates and joins a thread, causing the error: [Sherlock]$ ./threadTest -crash parent: thread created parent: thread joined child: born Fatal error 'mutex is on list' at line 540 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0) parent: child died Here is the backtrace of the resulting core: #0 0x28097537 in pthread_testcancel () from /lib/libpthread.so.2 [New Thread 0x8053200 (LWP 100163)] [New Thread 0x8053000 (LWP 100201)] (gdb) where #0 0x28097537 in pthread_testcancel () from /lib/libpthread.so.2 #1 0x2808689a in sigaction () from /lib/libpthread.so.2 #2 0x2808088d in pthread_kill () from /lib/libpthread.so.2 #3 0x28080256 in raise () from /lib/libpthread.so.2 #4 0x28159b78 in abort () from /lib/libc.so.6 #5 0x28097c6f in pthread_testcancel () from /lib/libpthread.so.2 #6 0x2808c85f in _pthread_mutex_trylock () from /lib/libpthread.so.2 #7 0x2808d590 in _pthread_mutex_lock () from /lib/libpthread.so.2 #8 0x28083361 in _spinlock () from /lib/libpthread.so.2 #9 0x280f7ddb in _UTF8_init () from /lib/libc.so.6 #10 0x28172940 in _thread_autoinit_dummy_decl_stub () from /lib/libc.so.6 #11 0x28074200 in ?? () #12 0x2804f405 in symlook_obj () from /libexec/ld-elf.so.1 #13 0x280883ff in pthread_attr_init () from /lib/libpthread.so.2 #14 0x280848fd in sigaction () from /lib/libpthread.so.2 #15 0x2808e915 in pthread_mutexattr_init () from /lib/libpthread.so.2 #16 0x28088116 in pthread_create () from /lib/libpthread.so.2 #17 0x08048795 in spawnThread (caller=0x80489f0 child) at threadTest.c:21 #18 0x08048879 in main (argc=2, argv=0x17e) at threadTest.c:62 Any help would be greatly appreciated. POSIX only lets you call exec() from a child process of a multithreaded app. Either fork before creating threads or just create more threads rather than forking. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Preparing an Oracle Database XE port/package -- any tips ?
Hi, After having to deploy an Oracle Database XE [1] installation (with Linux 32bit binaries from the official RPM package) on a production FreeBSD 6.2machine I realized it would be very much feasible to produce a FreeBSD port/package for it. I would like to know whether similar efforts have been undergoing and whether people came up with some tips tricks on this. The goal is not only to add the port into FreeBSD's ports tree but also to eventually convince Oracle (I work for them) to post the package on their official download page. [1] http://www.oracle.com/technology/products/database/xe/index.html Thank you for your time and help, Adrian Penisoara ROFUG / EnterpriseBSD ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Preparing an Oracle Database XE port/package -- any tips ?
Hi, On Fri, Mar 07, 2008 at 04:36:56PM +0200, Adrian Penisoara wrote: After having to deploy an Oracle Database XE [1] installation (with Linux 32bit binaries from the official RPM package) on a production FreeBSD 6.2machine I realized it would be very much feasible to produce a FreeBSD port/package for it. I would like to know whether similar efforts have been undergoing and whether people came up with some tips tricks on this. We run Oracle XE on two FreeBSD 6.3 machines at work - we've just manually set it up, but are very interested in a port of it. We did the same as you basically - just uncompress it and move the files in place. Regards, -- Rink P.W. Springer- http://rink.nu Anyway boys, this is America. Just because you get more votes doesn't mean you win. - Fox Mulder ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network Throughput between jail and base system
On Fri, Mar 07, 2008 at 12:13:04AM +0200, Stefan Lambrev wrote: Greetings, Ilias Marinos wrote: Hello all, I have a jail to my FreeBSD-STABLE, in which I run some uname -a will be more helpful then FreeBSD-STABLE. services.I have configured and setup this jail using ezjail-admin. [EMAIL PROTECTED]:~$ jls JID IP Address Hostname Path 1 192.168.1.100 ws/usr/jails/ws /usr/jails/ws #Jails ezjail_enable=YES ifconfig_lo1=192.168.1.100 netmask 0x # Jail iface I use lo1 as jail interface and I nat internet traffic to it with pf: nat on $ext_if from $ws to any - ($ext_if) Today I 've tried to scp a big directory inside the jail and I've noticed that I was secure copying with 2-3MB/s .That sounds too weird for me and I would like to hear some opinions , for what it may be the problem. You should investigate where the bottle-neck is. It's probably not in the network protocol. Most probably it is limitation of your CPU or your HDD(s). I think (not sure) jail have default limit to % of the CPU resources, so if you encrypt the stream most probably the limitation is in the CPU. You can check http://wiki.freebsd.org/JailResourceLimits for more information. Based upon that wiki page I'm led to believe that this is not in any branch of FreeBSD yet. That is, it's not in CVS. -- WXS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libpthread/fork issue
On Thu, 6 Mar 2008, Marko, Shaun wrote: I'm working on FreeBSD 6.2 and I'm wondering if anybody can help with an issue I've found using fork and threads. The attached program demonstrates the problem. In short, if a process creates a thread, joins the thread, then forks a child process which creates a thread, the child's attempt to create a thread will cause the program to dump core with the following error message: Fatal error 'mutex is on list' at line 540 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0). You are not allowed by POSIX to call any non-async-signal-safe function from a child of a threaded program. There's words or rationale to the effect that the only purpose for forking from a threaded program should be to call one of the exec* functions. Trying to create a thread from a child (like you are trying to do) is definitely not supported. -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
A (perhaps silly) kqueue question
I see an unusual symptom with one of our in-house applications. The main I/O loop calls kevent(), which in turn returns two events with EV_EOF error set, always for the same descriptors (they're both socket descriptors). As the man page is not pretty clear about it and I don't have my UNP copy at hand, I would like to ask the list whether the error events are supposed to be one-shot or not. Thanks for your kind input. -- Mahnahmahnah! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Preparing an Oracle Database XE port/package -- any tips ?
On Fri, 07 Mar 2008 16:14:15 +0100 Alexander Leidinger [EMAIL PROTECTED] wrote: Quoting Adrian Penisoara [EMAIL PROTECTED] (from Fri, 7 Mar 2008 16:36:56 +0200): Hi, After having to deploy an Oracle Database XE [1] installation (with Linux 32bit binaries from the official RPM package) on a production FreeBSD 6.2machine I realized it would be very much feasible to produce a FreeBSD port/package for it. I would like to know whether similar efforts have been undergoing and whether people came up with some tips tricks on this. The goal is not only to add the port into FreeBSD's ports tree but also to eventually convince Oracle (I work for them) to post the package on their official download page. I'm not aware of something like this. Feel free to ask questions regarding the linuxulator and our linux infrastructure in the ports on [EMAIL PROTECTED] Also feel free to ask for review of the port on [EMAIL PROTECTED] I've worked on such a port (probably that's what ady is referring to) but kinda' lost my interest in it ($REALLIFE got in the way). I'll try to find it (it was about 80% done) but I'm not sure it survived the clean-up sessions of my tmp/work dir (I don't know why I didn't ci it in our cvs ...). I'll work with Ady if he need help. Ady, BTW, after we have the port and, with some test cases provided by people that run it, can we hope for any kind of (semi-)official support ? -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect signature.asc Description: PGP signature
Re: soclose() so-so_upcall() = race?
Robert Watson wrote:
On Fri, 7 Mar 2008, Alexander Motin wrote:
As I can see so_upcall() callback is called with SOCKBUF_MTX unlocked.
It means that SB_UPCALL flag can be removed during call and socket can
be closed and deallocated with soclose() while callback is running. Am
I right or I have missed something? How in that situation socket
pointer protected from being used after free?
There are known problems with so_upcall and locking, including this
one. The other problems include:
- The locking condition on entering the upcall depends on the invocation
point
and is inconsistent.
- The protection of the upcall field and flag are inconsistent.
- Consumers of so_upcall, such as socket accept filters, don't properly
respect the locking environment they run in.
- Some (all) accept filters produce nastily convoluted stack traces
involving
recursion across really odd combinations of sockets and protocols. For
example, you can see soisdisconnected() calling soisconnected().
Some of this is inherent to the design of accept filters and so_upcall
and follows from using a single function pointer for many different
cases. I have an 8.x todo list item to try and figure out how to make
so_upcall and accept filters rational in the context of fine-grained
locking, but I've not yet reached that point on my todo list. I think
we can continue to incrementally hack so_upcall and accept filters to
fix many races, but the reality is that we need a more coherent model
for dealing with accept filters. One idea that Colin Percival (I think)
suggested is that we separate socket upcalls from accept filters, and
that accept filters consistent of a predicate for completion rather than
directly invoking socket state transitions. I've not explored the
implications, but think it might well be a good idea to avoid the weird
stack traces.
I've experimented with some changes to sowakeup() to better formalize it.
Code diff below. Observations noted in the comments.
--
Andre
Index: uipc_sockbuf.c
===
RCS file: /home/ncvs/src/sys/kern/uipc_sockbuf.c,v
retrieving revision 1.165
diff -u -p -r1.165 uipc_sockbuf.c
--- uipc_sockbuf.c 6 Sep 2006 21:59:36 - 1.165
+++ uipc_sockbuf.c 25 Feb 2007 15:22:32 -
@@ -173,11 +173,12 @@ sowakeup(struct socket *so, struct sockb
SOCKBUF_LOCK_ASSERT(sb);
- selwakeuppri(sb-sb_sel, PSOCK);
+#if 1
+ selwakeuppri(sb-sb_sel, PSOCK);/* removes thread from sleepq
*/
sb-sb_flags = ~SB_SEL;
if (sb-sb_flags SB_WAIT) {
sb-sb_flags = ~SB_WAIT;
- wakeup(sb-sb_cc);
+ wakeup(sb-sb_cc); /* removes thread from sleepq
too!? */
}
KNOTE_LOCKED(sb-sb_sel.si_note, 0);
SOCKBUF_UNLOCK(sb);
@@ -188,6 +189,46 @@ sowakeup(struct socket *so, struct sockb
if (sb-sb_flags SB_AIO)
aio_swake(so, sb);
mtx_assert(SOCKBUF_MTX(sb), MA_NOTOWNED);
+#else
+ /* Only wakeup if above low water mark. */
+ if (so-so_error == 0 sb-sb_lowat sbspace(sb))
+ return;
+ /* First run any upcalls which may process or modify the data. */
+ if (sb-sb_flags SB_UPCALL) {
+ /*
+* Upcall tells us whether to do a wakeup or not.
+* Need a flag on the socket to tell select/poll and kqueue
+* to ignore socket buffer until cleared.
+* Maybe we should defer the upcall to a worker thread using
+* task queue?
+*/
+ if ((*so-so_upcall)(so, sb, so-so_upcallarg, M_DONTWAIT)) {
+ sb-sb_flags |= SB_IGNORE;
+ SOCKBUF_UNLOCK(sb);
+ return; /* don't wakeup, more work! */
+ }
+ }
+ /* KQueue notifications. */
+ KNOTE_LOCKED(sb-sb_sel.si_note, 0);/* issues wakeup */
+ /* Someone doing select/poll? */
+ if (sb-sb_flags SB_SEL) {
+ selwakeuppri(sb-sb_sel, PSOCK); /* removes thread from sleepq
*/
+ sb-sb_flags = ~SB_SEL;
+ }
+ /* Someone waiting blocked on socket buffer. */
+ if (sb-sb_flags SB_WAIT) {
+ wakeup(sb-sb_cc); /* removes thread from sleepq
*/
+ sb-sb_flags = ~SB_WAIT;
+ }
+ /* Async IO notificatins. */
+ if (sb-sb_flags SB_AIO)
+ aio_swake(so, sb);
+ /* Socket buffer won't be accessed anymore. */
+ SOCKBUF_UNLOCK(sb);
+ /* Send SIGIO or SIGURG to thread. XXX: Is this still needed? */
+ if ((so-so_state SS_ASYNC) so-so_sigio != NULL)
+ pgsigio(so-so_sigio, SIGIO, 0);
+#endif
}
/*
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
pkg_add -r doesn't process sub dependencies?
Seems if you have package X which depends on package Y which depends on package Z then pkg_add -r X will always fail unless you first :- 1. pkg_add -r Y 2. pkg_add -r Z The failure will be:- pkg_add: could not find package Z ! This happens even though Z exists in the remote source package directory. Surely I've missed something very basic here and pkg_add isn't that broken? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
Vlad GALU wrote: I see an unusual symptom with one of our in-house applications. The main I/O loop calls kevent(), which in turn returns two events with EV_EOF error set, always for the same descriptors (they're both socket descriptors). As the man page is not pretty clear about it and I don't have my UNP copy at hand, I would like to ask the list whether the error events are supposed to be one-shot or not. Thanks for your kind input. You don't specify which version you are running Interstingly I may have seen a similar thing myself, but fixed it elsewhere. the question is a valid one.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
On 3/7/08, Julian Elischer [EMAIL PROTECTED] wrote: Vlad GALU wrote: I see an unusual symptom with one of our in-house applications. The main I/O loop calls kevent(), which in turn returns two events with EV_EOF error set, always for the same descriptors (they're both socket descriptors). As the man page is not pretty clear about it and I don't have my UNP copy at hand, I would like to ask the list whether the error events are supposed to be one-shot or not. Thanks for your kind input. You don't specify which version you are running Ah, yes, sorry. Fresh RELENG_7. Interstingly I may have seen a similar thing myself, but fixed it elsewhere. the question is a valid one.. -- Mahnahmahnah! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
Vlad GALU wrote: On 3/7/08, Julian Elischer [EMAIL PROTECTED] wrote: Vlad GALU wrote: I see an unusual symptom with one of our in-house applications. The main I/O loop calls kevent(), which in turn returns two events with EV_EOF error set, always for the same descriptors (they're both socket descriptors). As the man page is not pretty clear about it and I don't have my UNP copy at hand, I would like to ask the list whether the error events are supposed to be one-shot or not. Thanks for your kind input. You don't specify which version you are running Ah, yes, sorry. Fresh RELENG_7. Interstingly I may have seen a similar thing myself, but fixed it elsewhere. the question is a valid one.. Is this reproducable? Can you make this happen at will? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
On 3/7/08, Julian Elischer [EMAIL PROTECTED] wrote: Vlad GALU wrote: On 3/7/08, Julian Elischer [EMAIL PROTECTED] wrote: Vlad GALU wrote: I see an unusual symptom with one of our in-house applications. The main I/O loop calls kevent(), which in turn returns two events with EV_EOF error set, always for the same descriptors (they're both socket descriptors). As the man page is not pretty clear about it and I don't have my UNP copy at hand, I would like to ask the list whether the error events are supposed to be one-shot or not. Thanks for your kind input. You don't specify which version you are running Ah, yes, sorry. Fresh RELENG_7. Interstingly I may have seen a similar thing myself, but fixed it elsewhere. the question is a valid one.. Is this reproducable? Can you make this happen at will? I'll try. So far we haven't been able to trigger it at will, unfortunately :( It just pops out once in a while.. -- Mahnahmahnah! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: A (perhaps silly) kqueue question
On Fri, 7 Mar 2008, Vlad GALU wrote: I see an unusual symptom with one of our in-house applications. The main I/O loop calls kevent(), which in turn returns two events with EV_EOF error set, always for the same descriptors (they're both socket descriptors). As the man page is not pretty clear about it and I don't have my UNP copy at hand, I would like to ask the list whether the error events are supposed to be one-shot or not. I wonder if it's returning one event for the read socket buffer, and one event for the write socket buffer, since there are really two event sources for each socket? Not that this is desirable behavior, but it might explain it. If you shutdown() only read, do you get back one EOF kevent and one writable kevent? Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Preparing an Oracle Database XE port/package -- any tips ?
Quoting Adrian Penisoara [EMAIL PROTECTED] (from Fri, 7 Mar 2008 16:36:56 +0200): Hi, After having to deploy an Oracle Database XE [1] installation (with Linux 32bit binaries from the official RPM package) on a production FreeBSD 6.2machine I realized it would be very much feasible to produce a FreeBSD port/package for it. I would like to know whether similar efforts have been undergoing and whether people came up with some tips tricks on this. The goal is not only to add the port into FreeBSD's ports tree but also to eventually convince Oracle (I work for them) to post the package on their official download page. I'm not aware of something like this. Feel free to ask questions regarding the linuxulator and our linux infrastructure in the ports on [EMAIL PROTECTED] Also feel free to ask for review of the port on [EMAIL PROTECTED] Bye, Alexander. -- Security isn't. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Preparing an Oracle Database XE port/package -- any tips ?
I am defnitely interested in helping in this area if needed. A couple of years ago, I struggled mightily trying to get Oracle running on 5.1 On Fri, Mar 7, 2008 at 9:39 AM, Rink Springer [EMAIL PROTECTED] wrote: Hi, On Fri, Mar 07, 2008 at 04:36:56PM +0200, Adrian Penisoara wrote: After having to deploy an Oracle Database XE [1] installation (with Linux 32bit binaries from the official RPM package) on a production FreeBSD 6.2machine I realized it would be very much feasible to produce a FreeBSD port/package for it. I would like to know whether similar efforts have been undergoing and whether people came up with some tips tricks on this. We run Oracle XE on two FreeBSD 6.3 machines at work - we've just manually set it up, but are very interested in a port of it. We did the same as you basically - just uncompress it and move the files in place. Regards, -- Rink P.W. Springer- http://rink.nu Anyway boys, this is America. Just because you get more votes doesn't mean you win. - Fox Mulder ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-database To unsubscribe, send any mail to [EMAIL PROTECTED] -- ___ Jon Adams web: http://www.scis.nova.edu/~jonaadam mail: [EMAIL PROTECTED] - Strength does not come from physical capacity. It comes from an indomitable will. - Mohandas Gandhi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_add -r doesn't process sub dependencies?
Steven Hartland wrote: Seems if you have package X which depends on package Y which depends on package Z then pkg_add -r X will always fail unless you first :- 1. pkg_add -r Y 2. pkg_add -r Z The failure will be:- pkg_add: could not find package Z ! This happens even though Z exists in the remote source package directory... If you are using RELENG_7, pkg_add is looking in the wrong place on the remote server for packages. I just submitted a patch on the -STABLE list for this problem. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkg_add -r doesn't process sub dependencies?
- Original Message - From: walt [EMAIL PROTECTED] If you are using RELENG_7, pkg_add is looking in the wrong place on the remote server for packages. I just submitted a patch on the -STABLE list for this problem. I'm actually using PACKAGESITE which is meant to bypass all path calculations but it simply doesn't. I've now found PKG_ADD_BASE which seems to fix this issue but is not documented anywhere. I had to dig around in the code to find it, where its commented as:- /* Special tip that sysinstall left for us */ It seems really strange that the default behaviour of pkg_add -r can't deal with sub dependencies properly without this undocumented feature. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[kern/sys_pipe.c] PIPE_NODIRECT and pipe throughput
[originally posted to [EMAIL PROTECTED] Hello all, recently I've tried a few benchmarks around pipe throughput on Linux vs. FreeBSD. Everyone interesting can see my stuff at http://213.148.29.37/PipeBench, and initial post to Linux kernel developers mailing list at http://www.uwsg.iu.edu/hypermail/linux/kernel/0803.0/1837.html 1) It was noticed (http://www.uwsg.iu.edu/hypermail/linux/kernel/0803.0/1842.html) that the page flipping may be a reason of FreeBSD advantage. I've looked at kern/sys_pipe.c and found that defining PIPE_NODIRECT should disable it. Is that correct ? 2) When I've tried to run the kernel (7.0-STABLE) with PIPE_NODIRECT defined, I didn't see any slowdown (note 30% is promised in kern/sys_pipe.c comments) even for I/O buffer sizes = PIPE_MINDIRECT. So, what should be done with a pipe to see a difference between PIPE_NODIRECT enabled and disabled ? Thanks, Dmitry ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
