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
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
On Fri, 18 Feb 2005 16:18:41 +0300, Deomid Ryabkov <[EMAIL PROTECTED]> wrote:
> I have a strange case of occasional refused connect()'s.
> The system is running 4.10-STABLE.
>
> This was originally reported by one of our developers.
> The test script he provided is a simple Perl script that repeat
On Mon, 14 Feb 2005 08:04:50 -0500, David Schultz <[EMAIL PROTECTED]> wrote:
> Right, databases, language runtimes, and the small set of other
> applications for which it really matters usually have their own
> special-purpose allocators. I was counting on that when I said
> that replacing malloc
On Tue, 25 Jan 2005 14:04:45 -0800, Julian Elischer <[EMAIL PROTECTED]> wrote:
>
>
> Jose Hidalgo Herrera wrote:
>
> >The line causing the SEGFAULT is
> >rc = pthread_create(&threads[t], NULL, PrintHello, (void *)t);
> >
> >Why?, because t is declared as:
> >int t;
> >then you say:
> >args for s
On Mon, 24 Jan 2005 14:27:53 -0800 (PST), Yan Yu <[EMAIL PROTECTED]> wrote:
> Hi, all, I have a newbie Q:
> I am trying to use creating large number of threads and allocting
> memory to stress the system.
> My user program causes SEG fault in the kernel code, kse_release () in
> kern_kse.c.
>
On Fri, 15 Oct 2004 13:49:48 +0100, David Malone <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 14, 2004 at 04:27:38PM +0200, Oliver Fromme wrote:
> > On the other hand, the kernel should know that the mounts
> > come from the same NFS source, so it might actually be able
> > to handle it efficiently (i.
Marco Molteni wrote:
Makoto Matsushita wrote [2003-12-12]:
molter> what am I missing?
It seems that you forget to set PATH environment variable. As you
know, "env -i" does not pass any environment variable to child process
if any other variables are explicitly set.
Hi Makoto-san,
if you
David Schultz wrote:
On Tue, Nov 04, 2003, Igor Serikov wrote:
David,
Is it okay to have a condition that can be created by a mortal user and
then cannot be changed by the root? The waiting process cannot be killed
and would keep "waiting" till system reboot.
Aah, I see. No, it's not
David Schultz wrote:
On Sun, Oct 12, 2003, Dag-Erling Smrgrav wrote:
I've gotten used to the fact that there is a small discrepancy between
real and available memory, but I was surprised to see the following in
dmesg on a new P4 system:
real memory = 1073676288 (1023 MB)
avail memory = 1037799
On Tue, 2003-08-05 at 11:05, Simon Barner wrote:
> Hi,
>
> > Check PR 37569: This bugged the hell out of me also, so I created a
> > patch to allow enclosing the device name in quotes. The PR was logged
> > over a year ago: I can't remember the details, but the source has been
> > sitting silently
Hi,
Check PR 37569: This bugged the hell out of me also, so I created a
patch to allow enclosing the device name in quotes. The PR was logged
over a year ago: I can't remember the details, but the source has been
sitting silently in my tree and working since then. Whatever way the
problem is resolv
> Greetings,
>
> I have a loop which calls wait(), and I want another function to be
> called
> as close to once per minute as possible. Pseudo code:
>
[snip example]
>
> My concern is there is a small possibility that the alarm signal is
> delivered after the if() but before the wait. So it is
_WORD_SIZE == 32
#define HAVE_ELF32_DYN 1
#define HAVE_ELF64_DYN 0
#else
#define HAVE_ELF64_DYN 1
#define HAVE_ELF32_DYN 0
#endif
.. and cross your fingers before compiling.
--
Peter Edwards.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
I tend to avoid using "set", and use "print", with an assignment expression:
eg "print i = 1" or "p i = 1". It removes any namespace conflicts between
variables in the target process and gdb settings.
--
Peter.
> I need to set a variable value in gdb:
>
> (gdb) set xyz = 1 <- works
> (gdb) s
Is /usr/ports/sysutils/pstack
what you're looking for?
--
Peter.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
gt; suspended. Valid solution/workaround seems to be in calling
> PT_CONTINUE with sigcont, and PT_DETACH after it.
>
> Example is attached. Please cc me a reply:)
> Thanks
Does the patch in kern/35175 fix the problem?
--
Peter Edwards,
Openet Telecom.
To Unsubscribe: se
Hi,
kern_exit.c:wait1() has the following lines in -STABLE:
> if ((p->p_sigparent != SIGCHLD) ^ ((uap->options & WLINUXCLONE) != 0))
> continue;
As it is, if you ptrace(PT_ATTACH) to a process started with
rfork(flags|RFLINUXTHPN), and do a waitpid() as you normally would, this
causes
Zhihui Zhang wrote:
> ... I also do not read anything during the partial block write,
> and I think the disk controller should not do that either.
If you do a partial block write, surely at some point the block must be read
in order to preserve that segment of data you are _not_ overwriting?
Hi,
I recently wrote a program that was using ptrace() to suspend a process, and
resume it later. Maybe ptrace just isn't used enough, or maybe I just don't
get all the reasons behind why it's implemented the way it is, but it seems
to be somewhat buggy.
(I'm bringing this up on -hackers rather t
I've submitted PR33874 that implements a version of pstack for FreeBSD.
(er, actually due to "difficulties" with our mail server, it's logged
twice, the second being 33873: can someone delete one of them?)
Jos, if its still of use to you, can you see if it works?
Bernd Walter wrote:
>
> On Thu,
Hmm,
It appears, on second look, a little more complex. The cookies are used
properly in most places, but the fix was introduced in 1.36 breaks it.
I understand what's going on now, and I'll try a for a more complete
patch... Watch this space!
--
Peter.
Peter Edwards wrote:
>
>
Hi,
Here's a patch that fixes the problem for me. can someone review and
possibly commit it?
Here's my understanding:
The data returned by VOP_READDIR is not neccessarily the same as that
consumed from the directory vnode.
linux_getdents fills in a "doff" field in the linux_dirent structure
usi
Hi,
Just trying to take some of the aforementioned "magic" out of i386_btop
/ vtop :-)
>return( atop(vtophys(bktr->bigbuf) + offset) );
atop (I assume) stands for "address to page" (given a pointer, give the
number of the page it is in)
vtophys is "virtual to physical". (given a pointer in a
Paul Robinson wrote:
> I think this saving shows a little respect
> and concern for the less fortunate home user stuck with a 56K modem paying
> $x/hour where x can be anywhere between 0.5 and 5...
Sorry, can't resist.
Given (my) local call rates, if I started downloading the 3.4 ISO image
and di
"David E. Cross" wrote:
>
[snip]
> Take your average run-to-the mill PCI network driver... like FPA or FXP. Now
> look for the attach routines... there are *2* of them, with the exact same
> function name, and different arguments?!?!
>
> Huh, what is going on here? Help?
In if_fxp.c, goto the
"David E. Cross" wrote:
>
[snip]
> Take your average run-to-the mill PCI network driver... like FPA or FXP. Now
> look for the attach routines... there are *2* of them, with the exact same
> function name, and different arguments?!?!
>
> Huh, what is going on here? Help?
In if_fxp.c, goto the
Sounds like (the already fixed)
http://www.freebsd.org/cgi/query-pr.cgi?pr=10468
Snob Art Genre wrote:
> I will probably send-pr this, do you have anything to add to what I
> posted before I do so?
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body
Sounds like (the already fixed)
http://www.freebsd.org/cgi/query-pr.cgi?pr=10468
Snob Art Genre wrote:
> I will probably send-pr this, do you have anything to add to what I
> posted before I do so?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of
A quick look at the source reveals:
A MAXMAGIS constant in file.h that estimates a limit of 1000 lines in
magic. (The real number is 4802)
An array sized on MAXMAGIS, that is reallocated every ALLOC_INTR lines
of magic once MAXMAGIS is exceeded.
The patch updates MAXMAGIS to 5000 (give a bit of
A quick look at the source reveals:
A MAXMAGIS constant in file.h that estimates a limit of 1000 lines in
magic. (The real number is 4802)
An array sized on MAXMAGIS, that is reallocated every ALLOC_INTR lines
of magic once MAXMAGIS is exceeded.
The patch updates MAXMAGIS to 5000 (give a bit of
Dennis wrote:
> For "Fairness" gaps in between frames are better
> as you approach capacity of your wire.
Isn't there some ethernet requirement (implemented on the NIC) that a
transmitter holds off the wire a little to give other NICs enough time
to notice there's nothing being transmitted?
The
32 matches
Mail list logo
