Hi.
Is there a reason why in the case that a thread is not done yet,
pthread_join() does not call _thread_kern_sig_undefer() ?
We have a program where one thread consumes all CPU it can get for
blocks of data.
A status thread is spawned as soon as the main thread starts working on
a new block,
On Wed, Dec 31, 2003 at 12:16:42PM +0100, Marc Olzheim wrote:
Hi.
Is there a reason why in the case that a thread is not done yet,
pthread_join() does not call _thread_kern_sig_undefer() ?
Hmm, it isn't FreeBSD specific... OpenBSD does the same...
Zlo
On Wed, 31 Dec 2003, Marc Olzheim wrote:
Hi.
Is there a reason why in the case that a thread is not done yet,
pthread_join() does not call _thread_kern_sig_undefer() ?
We have a program where one thread consumes all CPU it can get for
blocks of data.
A status thread is spawned as soon
On Wed, Dec 31, 2003 at 08:47:03AM -0500, Daniel Eischen wrote:
Is there a reason why in the case that a thread is not done yet,
pthread_join() does not call _thread_kern_sig_undefer() ?
[snip]
No, it looks like you found a bug. Committed, thanks!
Hmm, ok ;-) But then why is
On Wed, 31 Dec 2003, Marc Olzheim wrote:
On Wed, Dec 31, 2003 at 08:47:03AM -0500, Daniel Eischen wrote:
Is there a reason why in the case that a thread is not done yet,
pthread_join() does not call _thread_kern_sig_undefer() ?
[snip]
No, it looks like you found a bug. Committed,
On Wed, Dec 31, 2003 at 09:22:14AM -0500, Daniel Eischen wrote:
Hmm, ok ;-) But then why is _thread_kern_sig_undefer() called within
every if-case, instead of just below the if ? It looked like it was
contructed this way to be able to omit _thread_kern_sig_undefer() in
that specific
Hey!
I have 5.1-RELEASE installed on my system, and I've never needed to do a
pciconf -lv to probe the system before. However, I tried doing it
earlier today after logging in through SSH and doing su - to become
superuser. I received this error:
[EMAIL PROTECTED] 09:12:42 root]# pciconf -lv
On 31-Dec-2003 William Michael Grim wrote:
Hey!
I have 5.1-RELEASE installed on my system, and I've never needed to do a
pciconf -lv to probe the system before. However, I tried doing it
earlier today after logging in through SSH and doing su - to become
superuser. I received this error:
Good call; I do in fact have securelevel enabled. I would like to keep it
enabled if possible. Is there any way to get to /dev/pci while in
securelevel 2, or do I have to temporarily drop the securelevel through
sysctl?
Many thanks in advance.
William Michael Grim
Student, Southern Illinois
On Wed, 31 Dec 2003, William Michael Grim wrote:
I have 5.1-RELEASE installed on my system, and I've never needed to do a
pciconf -lv to probe the system before. However, I tried doing it
earlier today after logging in through SSH and doing su - to become
superuser. I received this error:
On Dec 30, 2003, at 11:31 AM, Evren Yurtesen wrote:
The funny thing is that this works in Windows and Linux. So how come it
doesnt work in FreeBSD without any physical change? I think this is a
bug
in FreeBSD.
Some of these mouse/keyboards are weird. I've used one on FreeBSD in
the past, and
On 31-Dec-2003 William Michael Grim wrote:
Good call; I do in fact have securelevel enabled. I would like to keep it
enabled if possible. Is there any way to get to /dev/pci while in
securelevel 2, or do I have to temporarily drop the securelevel through
sysctl?
Many thanks in advance.
On 31-Dec-2003 Robert Watson wrote:
On Wed, 31 Dec 2003, William Michael Grim wrote:
I have 5.1-RELEASE installed on my system, and I've never needed to do a
pciconf -lv to probe the system before. However, I tried doing it
earlier today after logging in through SSH and doing su - to
On 2003-12-31 at 19:01:06 Robert Watson wrote:
superuser. I received this error:
[EMAIL PROTECTED] 09:12:42 root]# pciconf -lv
pciconf: /dev/pci: Operation not permitted
pciconf -lv appears to cause pciconf to open /dev/pci writable:
731 pciconf CALL open(0x8049a55,0x2,0)
731
On Wed, 31 Dec 2003, John Baldwin wrote:
History is in PR 32677. I do think your patch might be ok if it only
applies to the -l case. If so, then it should probably be committed and
MFC'd (along with the kernel pci_user.c change) so the PR can be closed.
Well, this patch changes only the
15 matches
Mail list logo
