On 2/14/12 3:51 PM, Jan Mikkelsen wrote:
Coming back to the multicore issue:
The problem when a core fails is that it has affected more than its own state.
It will be holding locks on shared resources and may have corrupted shared
memory or asked a device to do the wrong thing. By the time yo
Mirrored SMP? Even NonStops require a supervisory CPU subsystem to
manage what is working or not.
SMP itself would have to be totally rethought.
My suggestion is to study the examples of NonStop and Guardian-90.
Julian Elischer wrote:
On 2/14/12 6:23 AM, Maninya M wrote:
For multicore deskt
Brandon Falk wrote:
On 2/14/2012 12:05 PM, Jason Hellenthal wrote:
On Tue, Feb 14, 2012 at 08:57:10AM -0800, Julian Elischer wrote:
On 2/14/12 6:23 AM, Maninya M wrote:
For multicore desktop computers, suppose one of the cores fails, the
FreeBSD OS crashes. My question is abou
On Tue, Feb 14, 2012 at 6:01 PM, Julian Elischer wrote:
> True, but you can't guarantee that a cpu is going to fail in a way that you
> can detect like that. what if the clock just stops..
The question is, are we planning to handle >95% of the errors for >99%
of the hardware we run on, or are we
> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Julian Elischer
> Sent: Tuesday, February 14, 2012 3:02 PM
> To: Rayson Ho
> Cc: Maninya M; freebsd-hackers@freebsd.org
> Subject: Re: OS support for fault tolerance
>
On 15/02/2012, at 3:57 AM, Julian Elischer wrote:
> On 2/14/12 6:23 AM, Maninya M wrote:
>> For multicore desktop computers, suppose one of the cores fails, the
>> FreeBSD OS crashes. My question is about how I can make the OS tolerate
>> this hardware fault.
>> The strategy is to checkpoint the
On 2/14/12 9:27 AM, Rayson Ho wrote:
On Tue, Feb 14, 2012 at 11:57 AM, Julian Elischer wrote:
but I'm interested in any answers people may have
The way other OSes handle this is by detecting any abnormal amounts of
faults (sometimes it's not the fault of the hardware - eg. when a
partical from
If you're able to install a port, it has a tool called shmux which you
can invoke with `-r sh', it may do what you want.
Jos
--
Jos Backus
jos at catnook.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-
On Tue, Feb 14, 2012 at 2:37 PM, Matthew Story wrote:
> On Tue, Feb 14, 2012 at 2:35 PM, Jilles Tjoelker wrote:
>
>> On Tue, Feb 14, 2012 at 01:34:49PM -0500, Matthew Story wrote:
>> > After reading the man-page, and browsing around the internet for a
>> minute,
>> > I was just wondering if there
On Tue, Feb 14, 2012 at 2:35 PM, Jilles Tjoelker wrote:
> On Tue, Feb 14, 2012 at 01:34:49PM -0500, Matthew Story wrote:
> > After reading the man-page, and browsing around the internet for a
> minute,
> > I was just wondering if there is an option in (any) xargs to
> short-circuit
> > on first f
On Tue, Feb 14, 2012 at 01:34:49PM -0500, Matthew Story wrote:
> After reading the man-page, and browsing around the internet for a minute,
> I was just wondering if there is an option in (any) xargs to short-circuit
> on first failure of [utility [arguments]].
> e.g.
> $ jot - 1 10 | xargs -e -n
> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Matthew Story
> Sent: Tuesday, February 14, 2012 11:18 AM
> To: freebsd-hackers@freebsd.org
> Subject: Re: xargs short-circuit
>
> On Tue, Feb 14, 2012 at 2:05 PM, De
On Tue, Feb 14, 2012 at 2:05 PM, Devin Teske wrote:
>
>
> > -Original Message-
> > From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> > hack...@freebsd.org] On Behalf Of Matthew Story
> > Sent: Tuesday, February 14, 2012 10:35 AM
> > To: freebsd-hackers@freebsd.org
> > Subjec
> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Matthew Story
> Sent: Tuesday, February 14, 2012 10:35 AM
> To: freebsd-hackers@freebsd.org
> Subject: xargs short-circuit
>
> After reading the man-page, and browsin
On Tue, Feb 14, 2012 at 1:34 PM, Matthew Story wrote:
> After reading the man-page, and browsing around the internet for a minute,
> I was just wondering if there is an option in (any) xargs to short-circuit
> on first failure of [utility [arguments]].
>
> e.g.
>
> $ jot - 1 10 | xargs -e -n1 sh -
On 2012-02-14 18:13, Joshua Isom wrote:
On 2/14/2012 10:57 AM, Julian Elischer wrote:
On 2/14/12 6:23 AM, Maninya M wrote:
For multicore desktop computers, suppose one of the cores fails, the
FreeBSD OS crashes. My question is about how I can make the OS tolerate
this hardware fault.
The stra
After reading the man-page, and browsing around the internet for a minute,
I was just wondering if there is an option in (any) xargs to short-circuit
on first failure of [utility [arguments]].
e.g.
$ jot - 1 10 | xargs -e -n1 sh -c 'echo "$*"; echo exit 1' worker || echo $?
1
1
such that any non
On Tue, Feb 14, 2012 at 12:05 PM, Jason Hellenthal wrote:
> How about core redundancy ? effectively this would reduce the amount of
> available cores in half in you spread a process to run on two cores at
> the same time but with an option to adjust this per process etc... I
> don't see it as unfe
On Tue, Feb 14, 2012 at 11:57 AM, Julian Elischer wrote:
> but I'm interested in any answers people may have
The way other OSes handle this is by detecting any abnormal amounts of
faults (sometimes it's not the fault of the hardware - eg. when a
partical from the outerspace hits a core and flips
(The email below did not show up on the online archive - resending...)
-- Forwarded message --
From: Rayson Ho
Date: Tue, Feb 14, 2012 at 12:27 PM
Subject: Re: OS support for fault tolerance
On Tue, Feb 14, 2012 at 11:57 AM, Julian Elischer wrote:
> but I'm interested in any an
On 2/14/2012 12:05 PM, Jason Hellenthal wrote:
>
> On Tue, Feb 14, 2012 at 08:57:10AM -0800, Julian Elischer wrote:
>> On 2/14/12 6:23 AM, Maninya M wrote:
>>> For multicore desktop computers, suppose one of the cores fails, the
>>> FreeBSD OS crashes. My question is about how I can make the OS tol
On 2/14/2012 10:57 AM, Julian Elischer wrote:
On 2/14/12 6:23 AM, Maninya M wrote:
For multicore desktop computers, suppose one of the cores fails, the
FreeBSD OS crashes. My question is about how I can make the OS tolerate
this hardware fault.
The strategy is to checkpoint the state of each cor
On Tue, Feb 14, 2012 at 8:57 AM, Julian Elischer wrote:
> On 2/14/12 6:23 AM, Maninya M wrote:
>>
>> For multicore desktop computers, suppose one of the cores fails, the
>> FreeBSD OS crashes. My question is about how I can make the OS tolerate
>> this hardware fault.
>> The strategy is to checkpo
OpenSSH:
After taking advantage of new 'KexAlgorithms'
# sshd -T | grep KexAlgorithms
will never show it ...
-
WiFi:
-
'media OFDM/54Mbps' breaks setup (supplied to 'ifconfig wlan0').
'ucastrate' and 'mcastrate' will set it instead.
-
gpart
-
On a MD vnode
On Tue, Feb 14, 2012 at 08:57:10AM -0800, Julian Elischer wrote:
> On 2/14/12 6:23 AM, Maninya M wrote:
> > For multicore desktop computers, suppose one of the cores fails, the
> > FreeBSD OS crashes. My question is about how I can make the OS tolerate
> > this hardware fault.
> > The strategy is
On 2/14/12 6:23 AM, Maninya M wrote:
For multicore desktop computers, suppose one of the cores fails, the
FreeBSD OS crashes. My question is about how I can make the OS tolerate
this hardware fault.
The strategy is to checkpoint the state of each core at specific intervals
of time in main memory.
For multicore desktop computers, suppose one of the cores fails, the
FreeBSD OS crashes. My question is about how I can make the OS tolerate
this hardware fault.
The strategy is to checkpoint the state of each core at specific intervals
of time in main memory. Once a core fails, its previous state
Hi,
Have any changes been made to libarchive from FreeBSD 7.0 to 8.2 and is it
possbile that
these changes can report a tar.gz file corrupted when issuing gzip --test
archive.tar.gz?
When making my move from 7.0 to 8.2 I made backups, which when testing
these on 7.0
ran fine. However, now these a
28 matches
Mail list logo
