On Wed, 22 Jun 2005, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Daniel Eischen <[EMAIL PROTECTED]> writes:
> : We do protect the malloc lock across a fork(), but that's it.
>
> With 4.x libc_r, you could easily get hangs accross a fork() if you
> did anything before the
Hello Norbert,
I did some more testing with kbdmux.
1. I wait for the screen saver becoming active.
2. I press the control key.
3. All keys, I press after that,
come as control keys, e.g.
I press 'j' or 'J' and see a
linefeed, I press 'I' and see a tab.
4. I wait a second time for the
On Wed, 22 Jun 2005 16:52:58 -0500
Dan Nelson <[EMAIL PROTECTED]> wrote:
> In the last episode (Jun 22), Mauser said:
> > Unloading syscall kernel module can cause a system crash. It occurs
> > when we unload the module while a process is executing our syscall.
> > Example:
> >
> > $ cat kldtest
In the last episode (Jun 22), Mauser said:
> Unloading syscall kernel module can cause a system crash. It occurs when we
> unload the module while a process is executing our syscall. Example:
>
> $ cat kldtest.c
...
> static int test_syscall(struct thread *td, void *arg) {
> struct timeval tv
Hi there,
I've been running into some problems with what is supposed to be a
filtering bridge with IPFW, on FreeBSD 5.4-REL0.
IPFW has been compiled into kernel:
options BRIDGE
options IPFIREWALL
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPDIVERT
a
i don't know if kld should check if the module is used or not before
unloading it.
but i should.
On 6/22/05, Mauser <[EMAIL PROTECTED]> wrote:
> Unloading syscall kernel module can cause a system crash. It occurs when we
> unload the module while a process is executing our syscall. Example:
>
>
Unloading syscall kernel module can cause a system crash. It occurs when we
unload the module while a process is executing our syscall. Example:
$ cat kldtest.c
#include
#include
#include
#include
#include
#include
#include
#include
#include
static int test_nw;
static int test_syscall
In message: <[EMAIL PROTECTED]>
Daniel Eischen <[EMAIL PROTECTED]> writes:
: We do protect the malloc lock across a fork(), but that's it.
With 4.x libc_r, you could easily get hangs accross a fork() if you
did anything before the exec (like setup fd's for stdin/out). This
was due to
On Wed, 22 Jun 2005, Luigi Rizzo wrote:
> reading also the continuation of this mail thread, I wonder if there
> is any relationship with this issue i found a few days ago debugging
> asterisk. It happens when linking the code with libc_r, but maybe
> some of the bugs in libc_r were also imported
Daniel Eischen wrote:
> On Tue, 21 Jun 2005, Michal Mertl wrote:
>
> > Dag-Erling Smrgrav wrote:
> > > Charles Sprickman <[EMAIL PROTECTED]> writes:
> > > > 1. FreeBSD and threads. On FreeBSD there's a native user-level
> > > > implementation of threads called 'pthread' and there's also an
> > > >
On Tuesday 21 June 2005 11:16 am, John Baldwin wrote:
> On Monday 16 May 2005 08:51 am, Stefan Farfeleder wrote:
> > On Mon, May 16, 2005 at 02:11:42PM +0300, Juho Vuori wrote:
> > > The below included simple program reliably printfs "error 4\n" on
> > > 5.4-RELEASE. Am I understanding something wr
On Mon, Jun 20, 2005 at 07:50:31PM +0200, GiZmen wrote:
> hi,
>
> I have problem with mount_nullfs and jails. My system FreeBSD 5.4-STABLE
> when have two jails and each of this jails has couple mount_nullfs freeze
> without kernel panic. It freezes out in random times. Sometimes it can run
> for
reading also the continuation of this mail thread, I wonder if there
is any relationship with this issue i found a few days ago debugging
asterisk. It happens when linking the code with libc_r, but maybe
some of the bugs in libc_r were also imported in other thread
libraries.
cheers
On Wed, 22 Jun 2005, Peter Edwards wrote:
> On 6/22/05, Kamal R. Prasad <[EMAIL PROTECTED]> wrote:
> >
> > The child process should be able to call any system
> > calls it likes -without assuming that pthreads from
> > the parent process have been copied over to the child
> > process. I spose most
On Wed, 22 Jun 2005, Norbert Koch wrote:
> > [snip]
> > > at least some assumptions that the child won't be
> > > doing much before
> > > execing or exiting. (But Im sure one of the
> >
> > The child process should be able to call any system
> > calls it likes -without assuming that pthreads from
On 6/22/05, Kamal R. Prasad <[EMAIL PROTECTED]> wrote:
> [snip]
> > at least some assumptions that the child won't be
> > doing much before
> > execing or exiting. (But Im sure one of the
>
> The child process should be able to call any system
> calls it likes -without assuming that pthreads from
> [snip]
> > at least some assumptions that the child won't be
> > doing much before
> > execing or exiting. (But Im sure one of the
>
> The child process should be able to call any system
> calls it likes -without assuming that pthreads from
> the parent process have been copied over to the chil
apologies for the ommited subject
Stefan
Zitat von [EMAIL PROTECTED]:
> Hi list
>
> I have an Intel Motherboard with a SRCS16 raid controller. According to
> amr(4), this controller should be supported. Unfortunately the 5.4
> Install
> CD does not recognize the raid controller. Loading amr
Hello,
I did some more testing with kbdmux.
1. I wait for the screen saver becoming active.
2. I press the control key.
3. All keys, I press after that,
come as control keys, e.g.
I press 'j' or 'J' and see a
linefeed, I press 'I' and see a tab.
4. I wait a second time for the screen save
[snip]
> at least some assumptions that the child won't be
> doing much before
> execing or exiting. (But Im sure one of the
The child process should be able to call any system
calls it likes -without assuming that pthreads from
the parent process have been copied over to the child
process. I spo
Hi list
I have an Intel Motherboard with a SRCS16 raid controller. According to
amr(4), this controller should be supported. Unfortunately the 5.4 Install
CD does not recognize the raid controller. Loading amr before booting does
not help (results in the error message seen in the dmesg below).
On 6/20/05, Charles Sprickman <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Just curious if there's any regulars here who would like to help Ethan
> out:
>
[snip]
>
> ... It happens when the main thread forks to execute an active
> check. On the second fork to create the grandchild, the grandchild is
22 matches
Mail list logo
