Hi Guys,
This seems liek a really basic question, I expect a simple 'no', but I
havn't found anything definative yet.
I currently have a hardware RAID5 array, using the Intel Matrix RAID
capability onboard, encrypted with GELI.
I need to add 2 new discs to the array. If I add a disc to the arr
On Fri, May 01, 2009 at 06:12:42PM +1000, ghostcorps wrote:
> Hi Guys,
>
> This seems liek a really basic question, I expect a simple 'no', but I
> havn't found anything definative yet.
>
> I currently have a hardware RAID5 array, using the Intel Matrix RAID
> capability onboard, encrypted with
Hi,
I recently updated the port, but didn't see this condition in testing.
Are you able to build libpcap *without* using the port from the same
tarball?
do-patch in the port doesn't touch those files.
Leo wrote:
Hi All,
I want to install libpcap from ports. But when I "make install clean",
t
Thanks Roland,
You have confirmed my worst fears. One thing though, apparently MatrixRAID
is a 'Firmware RAID' system as opposed to hard or software. I don't quite
know how that would effect anything but that's all I can say really. It
looks like I'm buying some more disks.
http://en.wikipedia.o
On Fri, May 01, 2009 at 09:02:46PM +1000, ghostcorps wrote:
> Thanks Roland,
>
> You have confirmed my worst fears. One thing though, apparently MatrixRAID
> is a 'Firmware RAID' system as opposed to hard or software.
That just means that the BIOS understands that RAID layout and knows how to
bo
On Fri, May 01, 2009 at 09:02:46PM +1000, ghostcorps wrote:
> Thanks Roland,
>
> You have confirmed my worst fears.
Well, there is one thing that _might_ work. It might also destroy your
data, hence the first step:
- Make a backup and verify it.
- Remove the array from fstab, so it isn't mou
Hi,
Can you please try this patch?
I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.
Sam Leffler wrote:
Bruce Simpson wrote:
Hi,
Looks like I'm late to the party. I was responsible for committing these
ath(4) changes to RELENG_7.
I can't remember if I tested the kernel c
This is just a quick update about some further investigations on
this. I tested out the patch that Niki Denev kindly sent me which
apparently fixes a length issue when zero copy sockets are not
in use. This did not, however, solve the problem, but as part of
this I ran tcpdump on the bce0 and bce1
Bruce Simpson wrote:
Hi,
Can you please try this patch?
I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.
Sam Leffler wrote:
Bruce Simpson wrote:
Hi,
Looks like I'm late to the party. I was responsible for committing
these
ath(4) changes to RELENG_7.
I can't remember i
On Wednesday 29 April 2009 4:28:09 pm Alan Amesbury wrote:
> One of my systems (FreeBSD 7.1-RELEASE-p3/amd64) has panicked a couple
> times recently without an identified cause. This most recent time I was
> able to obtain a crash dump from the system, but output from kgdb is
> garbled.
>
> -
On Thursday 30 April 2009 2:36:34 am pluknet wrote:
> Hi folks.
>
> Today I got a new locking issue.
> This is the first time I got it, and it's merely reproduced.
>
> The box has lost both remote connection and local access.
> No SIGINFO output on the local console even.
> Jumping in ddb> shows
Sam Leffler wrote:
Bruce Simpson wrote:
Hi,
Can you please try this patch?
I can't commit it until STABLE is unfrozen after 7.2-RELEASE is cut.
Sam Leffler wrote:
Bruce Simpson wrote:
Hi,
Looks like I'm late to the party. I was responsible for committing
these
ath(4) changes to RELENG_7
On Fri, 2009-05-01 at 07:52 +0200, Oliver Lehmann wrote:
> Hi Robert
>
> Oliver Lehmann wrote:
>
> > Robert Noland wrote:
> >
> > > It still might be useful... Option "BusType" "PCI"
>
> any new here?
No, sorry... I got distracted by over heating and trashing the disk in
my test machine... No
John Baldwin wrote:
> Drop the '0x8:' from this and it will work better. Also, 'bt' output would
> be
> good.
Thanks for the pointer (no pun intended).
(kgdb) list *0x80424561
0x80424561 is in turnstile_wait
(/usr/src/sys/kern/subr_turnstile.c:727).
722 el
Sam Leffler wrote:
...
the "ath_hal" device.
Do not modify ah_desc.h like you've done. Add this to conf/options
ATH_HAL opt_ah.h
and use that to enable AH_SUPPORT_AR5416.
To clarify the first comment: you've made it impossible to build code
w/o the extended format descriptor; this is wha
Bruce Simpson wrote:
Sam Leffler wrote:
...
the "ath_hal" device.
Do not modify ah_desc.h like you've done. Add this to conf/options
ATH_HAL opt_ah.h
and use that to enable AH_SUPPORT_AR5416.
To clarify the first comment: you've made it impossible to build code
w/o the extended format d
On Friday 01 May 2009 12:50:15 pm Alan Amesbury wrote:
> John Baldwin wrote:
>
> > Drop the '0x8:' from this and it will work better. Also, 'bt' output
would be
> > good.
>
> Thanks for the pointer (no pun intended).
>
>
> (kgdb) list *0x80424561
> 0x80424561 is in turnstile_
John Baldwin wrote:
> This is odd.
[snip]
> The trace actually ends here. There is nothing super bad here but there is a
> big problem actually in that the idle threads cannot block on a lock, so it
> is a problem for the ACPI code to be acquiring a mutex here. Perhaps the
> locks protecting
I gave the AMD64 version of 7.2 RC2 a spin and all installed as
expected off the dvd
INTEL S3200SHV MB, Core2Duo, 4G of RAM
In the past it had been suggested that for zfs tuning, something like
vm.kmem_size_max="1073741824"
vm.kmem_size="1073741824"
vfs.zfs.prefetch_disable=1
However doing a
> In the past it had been suggested that for zfs tuning, something like
>
> vm.kmem_size_max="1073741824"
> vm.kmem_size="1073741824"
> vfs.zfs.prefetch_disable=1
>
> However doing a simple test with bonnie and dd, there does not seem
> to be very much difference in 4 configs. Am I better off jus
At 04:53 PM 5/1/2009, Pete French wrote:
The tuning isn't there to improve performance, it's there to prevent
the box going titus due to a panic when the ARC gets too big, and
you are missing the mian one, which is to limit the size of the ARC.
On recent versions of BSD (and you are running 7.2,
One more test I just managed to do - using bce and lagg in 'failover' mode
works fine, so it would appear that the problem lies with LACP.
-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsu
On May 1, 2009, at 1:53 PM, Pete French wrote:
...
The tuning isn't there to improve performance, it's there to prevent
the box going titus due to a panic when the ARC gets too big, and
you are missing the mian one, which is to limit the size of the ARC.
On recent versions of BSD (and you are r
On Fri, May 1, 2009 at 4:12 PM, Louis Kowolowski
wrote:
> On May 1, 2009, at 1:53 PM, Pete French wrote:
>> ...
>> The tuning isn't there to improve performance, it's there to prevent
>> the box going titus due to a panic when the ARC gets too big, and
>> you are missing the mian one, which is to
On Fri, May 01, 2009 at 04:42:09PM -0400, Mike Tancsa wrote:
I gave the AMD64 version of 7.2 RC2 a spin and all installed as
expected off the dvd
INTEL S3200SHV MB, Core2Duo, 4G of RAM
The writes are all within the normal variance of the tests except for
b). Is there anything
Hello Everyone,
The branches supported by the FreeBSD Security Officer have been updated
to reflect the EoL (end-of-life) of FreeBSD 7.0. The new list is below
and at http://security.freebsd.org/ >. Please note that FreeBSD
7.0 was originally announced with an EoL date of February 28, 2009, but
26 matches
Mail list logo
