On 8 March 2010, at 12:33, Robert Watson wrote:
>
> On Mon, 8 Mar 2010, Doug Hardie wrote:
>
>> I run a number of 4 core systems with em interfaces. These are production
>> systems that are unmanned and located a long way from me. Under unusual
>> conditions it can take up to 6 hours to get
On Mon, 8 Mar 2010, Doug Hardie wrote:
I run a number of 4 core systems with em interfaces. These are production
systems that are unmanned and located a long way from me. Under unusual
conditions it can take up to 6 hours to get there. I have been waiting to
switch to 8.0 because of the di
On 8 March 2010, at 06:53, Robert Watson wrote:
>
> On Sun, 7 Mar 2010, Robert Watson wrote:
>
>> If your system shows a non-zero value, please send me a *private e-mail*
>> with the output of that command, plus also the output of "sysctl kern.smp",
>> "uptime", and a brief description of the
On Sun, 7 Mar 2010, Robert Watson wrote:
If your system shows a non-zero value, please send me a *private e-mail*
with the output of that command, plus also the output of "sysctl kern.smp",
"uptime", and a brief description of the workload and network interface
configuration. For example: it
On Sun, 7 Mar 2010 11:59:35 + (GMT) Robert Watson wrote:
> Please check the results of the following command:
>
> % sysctl net.inet.tcp.timer_race
> net.inet.tcp.timer_race: 0
Are the results for FreeBSD7 look interesting for you? Because currently we
have mostly FreeBSD7.1 hosts in produ
On Mar 7, 2010, at 12:33 PM, Mikolaj Golub wrote:
> On Sun, 7 Mar 2010 11:59:35 + (GMT) Robert Watson wrote:
>
>> Please check the results of the following command:
>>
>> % sysctl net.inet.tcp.timer_race
>> net.inet.tcp.timer_race: 0
>
> Are the results for FreeBSD7 look interesting for
Dear all:
I'm embarking on some new network stack locking work, which requires me to
address a number of loose ends in the current model. A few years ago, my
attention was drawn to a largly theoretical race, which had existed in the BSD
code since inception. It is detected and handled in pr
