On Thu, Jan 22, 2009 at 9:12 PM, David Ehrmann wrote:
> On Thu, Jan 22, 2009 at 9:08 PM, David Ehrmann wrote:
>> On Thu, Jan 22, 2009 at 5:45 PM, Michael Proto wrote:
>>> On Thu, Jan 22, 2009 at 4:24 PM, David Ehrmann wrote:
On Fri, Jan 16, 2009 at 3:21 PM, David Ehrmann wrote:
> On F
On Jan 23, 2009, at 2:34 PM, Marat N.Afanasyev wrote:
Dan Langille wrote:
On Jan 22, 2009, at 11:38 AM, Dan Langille wrote:
Victor Balada Diaz wrote:
On Wed, Jan 21, 2009 at 07:22:06PM +0300, Marat N.Afanasyev wrote:
trouble with onboard re(4) was resolved in -CURRENT and -
STABLE, but stor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[redirected from -bugs@ to -sta...@]
Stephen Sanders wrote:
> I'm tracking what I believe to be a bug in 32 bit compat5x.
>
> The situation is as follows:
>
> 6.3 amd64 FreeBSD running 32 bit FreeBSD 5.3 applications. On fairly
> random intervals,
Bruce M Simpson wrote:
> [...]
> I also now understand that I can't rely on RAID alone to keep the
> integrity of my own data -- there is no substitute for backups,
That's 100% true. RAID -- even true hardware RAID -- is
*never* a substitute for backup. Consider:
- Fire.
- Theft.
- Lightn
Bruce M Simpson wrote:
> Following the rebuild procedure in the Handbook, if you try to run
> "atacontrol rebuild" from the FreeBSD 7.1 LiveFS, it'll break. I ran it
> thinking that it had some kind of magic in it which I couldn't achieve
> using dd alone, which is partly true, but also partly
On Jan 23, 2009, at 2:34 PM, Marat N.Afanasyev wrote:
Dan Langille wrote:
On Jan 22, 2009, at 11:38 AM, Dan Langille wrote:
Victor Balada Diaz wrote:
On Wed, Jan 21, 2009 at 07:22:06PM +0300, Marat N.Afanasyev wrote:
trouble with onboard re(4) was resolved in -CURRENT and -
STABLE, but stor
Dan Langille wrote:
On Jan 22, 2009, at 11:38 AM, Dan Langille wrote:
Victor Balada Diaz wrote:
On Wed, Jan 21, 2009 at 07:22:06PM +0300, Marat N.Afanasyev wrote:
trouble with onboard re(4) was resolved in -CURRENT and -STABLE,
but storms are not bound to ethernet only. storm may appear on a
Hi there,
I had a bit of a nasty experience this week with ataraid(4).
I thought I would summarize the issues I ran into so hopefully others
can benefit from my nasty experience, should they experience catastophic
failure of a Pseudo-RAID. I was surprised that I was unable to find much
in the
Pete Carah wrote:
Well, following up on my own reply earlier, I csup'd releng_7 with a
date of last dec 1; the result works fine
in the laptop. I'll reload the eastern soekris tonight and see how it
does. If the soekris is fine also then this gives a data point for
whenever the bad commit(s)
Andrei Kolu wrote:
> I configured iscsi-target on FreeBSD 7.1 and after I mounted target from
> VMware ESXi I got this following error message:
> ---
>
> Jan 23 14:26:35 srv6 iscsi-targe
I configured iscsi-target on FreeBSD 7.1 and after I mounted target from
VMware ESXi I got this following error message:
---
Jan 23 14:26:35 srv6 iscsi-target: pid 11892:disk.c:956: ***
On Fri, Jan 23, 2009 at 01:25:52PM +0300, Oleg Bulyzhin wrote:
...
> > understand - my question is whether there is strong objection
> > in applying the real fix (the one in HEAD) rather than this
> > workaround.
> > In my opinion the MFC is quite safe as I explained.
> >
> > cheers
> > luigi
>
>
On Fri, Jan 23, 2009 at 11:21:14AM +0100, Luigi Rizzo wrote:
> On Fri, Jan 23, 2009 at 12:44:20PM +0300, Oleg Bulyzhin wrote:
> > On Fri, Jan 23, 2009 at 10:23:12AM +0100, Luigi Rizzo wrote:
> >
> > > this is also in RELENG_7 but i am not sure whether this workaround
> > > has any drawback e.g., w
On Fri, Jan 23, 2009 at 12:44:20PM +0300, Oleg Bulyzhin wrote:
> On Fri, Jan 23, 2009 at 10:23:12AM +0100, Luigi Rizzo wrote:
>
> > this is also in RELENG_7 but i am not sure whether this workaround
> > has any drawback e.g., when curr_time passes a 32-bit boundary
> > there seems to be an incorre
On Fri, Jan 23, 2009 at 10:23:12AM +0100, Luigi Rizzo wrote:
> this is also in RELENG_7 but i am not sure whether this workaround
> has any drawback e.g., when curr_time passes a 32-bit boundary
> there seems to be an incorrect setting of q->numbytes
Workaround is fine in average. It may fail for
On Fri, Jan 23, 2009 at 11:53:37AM +0300, Oleg Bulyzhin wrote:
> On Fri, Jan 23, 2009 at 09:10:28AM +0100, Luigi Rizzo wrote:
> > in your logmessage for the q_time change in dummynet
> > http://svn.freebsd.org/viewvc/base?view=revision&revision=184414
> >
> > mentions an ABI change that would prev
On Fri, Jan 23, 2009 at 09:10:28AM +0100, Luigi Rizzo wrote:
> in your logmessage for the q_time change in dummynet
> http://svn.freebsd.org/viewvc/base?view=revision&revision=184414
>
> mentions an ABI change that would prevent backporting.
>
> However, as far as I can tell, the kernel side of t
in your logmessage for the q_time change in dummynet
http://svn.freebsd.org/viewvc/base?view=revision&revision=184414
mentions an ABI change that would prevent backporting.
However, as far as I can tell, the kernel side of the change is
fully self-contained in the ip_dummynet module, and the only
18 matches
Mail list logo
