Re: openssh problem after going from 5.2.1 to 5.3-beta7

2004-10-11 Thread Michael Ray
On Mon, 11 Oct 2004 11:48:06 -0700, you wrote: >I have a HP DL380g3 I was running 5.2.1-REL on (I think it was on -p9). >I did a source upgrade to 5.3-beta7, including mergemaster -p, followed >by mergemaster which did upgrade /etc/ssh/sshd_config. > >When I am now trying to connect from SecureCRT

Re: HyperSCSI on FreeBSD?

2004-10-11 Thread Jiawei Ye
On Mon, 11 Oct 2004 21:26:30 -0700, Justin Hopper <[EMAIL PROTECTED]> wrote: > Just curious if anyone was working on either a port of HyperSCSI to > FreeBSD, or perhaps some other similar project for exported file > systems. I'm not a fan of NFS myself, and the idea of iSCSI and > HyperSCSI seems

HyperSCSI on FreeBSD?

2004-10-11 Thread Justin Hopper
Just curious if anyone was working on either a port of HyperSCSI to FreeBSD, or perhaps some other similar project for exported file systems. I'm not a fan of NFS myself, and the idea of iSCSI and HyperSCSI seems pretty intriguing, but there seems to be no FreeBSD support mentioned anywhere. The

Re: msleep(9) and recursed mutex

2004-10-11 Thread John Baldwin
On Monday 11 October 2004 11:30 am, Hans Petter Selasky wrote: > On Mon, Oct 11, 2004 at 03:10:45PM +0200, [EMAIL PROTECTED] wrote: > > msleep(9) behaves strangely with recursed mutexes. > > In the attached code, calling foo_f() will make the kernel hang for > > two seconds. > > It seems like mslee

Re: msleep(9) and recursed mutex

2004-10-11 Thread John Baldwin
On Monday 11 October 2004 09:10 am, [EMAIL PROTECTED] wrote: > msleep(9) behaves strangely with recursed mutexes. > In the attached code, calling foo_f() will make the kernel hang for > two seconds. > It seems like msleep does not release the mtx mutex completely but > simply decrement its referenc

Re: openssh problem after going from 5.2.1 to 5.3-beta7

2004-10-11 Thread Ulf Zimmermann
Never mind, /usr/src/UPDATING: 20040226: Some sshd configuration defaults have changed: protocol version 1 is no longer enabled by default, and password authentication is disabled by default if PAM is enabled (which it is by default). OpenSSH clients should not be

openssh problem after going from 5.2.1 to 5.3-beta7

2004-10-11 Thread Ulf Zimmermann
I have a HP DL380g3 I was running 5.2.1-REL on (I think it was on -p9). I did a source upgrade to 5.3-beta7, including mergemaster -p, followed by mergemaster which did upgrade /etc/ssh/sshd_config. When I am now trying to connect from SecureCRT, I get: SecureCRT has disconnected from the server.

Re: msleep(9) and recursed mutex

2004-10-11 Thread Damien Bergamini
Thanks for your answer. I'll try your solution with condition variables and I'll let you know about the results. What I really want to do is quite simple: avoid wakeup_before_sleep conditions. -- Damien Bergamini | Really, you want to be using condition variables. Use a mutex | to protect your d

Re: msleep(9) and recursed mutex

2004-10-11 Thread Hans Petter Selasky
On Mon, Oct 11, 2004 at 03:10:45PM +0200, [EMAIL PROTECTED] wrote: > msleep(9) behaves strangely with recursed mutexes. > In the attached code, calling foo_f() will make the kernel hang for > two seconds. > It seems like msleep does not release the mtx mutex completely but > simply decrement its re

Re: msleep(9) and recursed mutex

2004-10-11 Thread Daniel Eischen
On Mon, 11 Oct 2004 [EMAIL PROTECTED] wrote: > msleep(9) behaves strangely with recursed mutexes. > In the attached code, calling foo_f() will make the kernel hang for > two seconds. > It seems like msleep does not release the mtx mutex completely but > simply decrement its reference count by one.

msleep(9) and recursed mutex

2004-10-11 Thread damien . bergamini
msleep(9) behaves strangely with recursed mutexes. In the attached code, calling foo_f() will make the kernel hang for two seconds. It seems like msleep does not release the mtx mutex completely but simply decrement its reference count by one. When calling msleep, the mtx mutex is still held which