Hello!
I'm trying to check out the FreeBSD source tree with the
tag=RELENG_7 in the same state that it had at the exact date/time,
e.g. 2009-05-04 18:00 UTC. So I'm
using the following supfile:
*default host=cvsup.ua.freebsd.org
*default base=/root/sup/base
*default delete use-rel-suffix compre
On Thu, 4 Jun 2009, Angelo Turetta wrote:
Tim Chase wrote:
Hello,
I decided to give the new zfs code a try and upgraded my stable-7 system
and discovered a panic that I can reproduce at will.
I just had the same problem, and it turned out I was not diligent when I
first set my zfs pool up :
On Thu, 4 Jun 2009, Kip Macy wrote:
As I mentioned in the initial e-mail, auto-tuning is only safe to rely
on on amd64.
OK, that wasn't clear to me with the latest zfs code. I'll try it
with a proper 512M setting as I was using before (along with setting
KVA_PAGES).
- Tim
___
On Thu, Jun 4, 2009 at 2:13 PM, Kip Macy wrote:
> As I mentioned in the initial e-mail, auto-tuning is only safe to rely
> on on amd64.
>
Tying ZFS in to UMA to allow zone limits to reduce memory pressure on
write as well as reduce the ARC's ability to grow without bound is on
my to do list. Howe
> So can we claim that the problem has been solved? Could you please give
> us a copy of output from 'ident /sys/dev/bce/* /sys/dev/mii/miidev
> /sys/dev/mii/brgphy*'?
Yes, it looks very much that way. I've no idea what changed to fix it, but
it is certainly working now on my test machine. I will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi, Pete,
Pete French wrote:
> Well, I found time to test this today after all - and it does actually
> fix the issue - my bce devices now work properly with lagg and lacp.
So can we claim that the problem has been solved? Could you please give
us a
As I mentioned in the initial e-mail, auto-tuning is only safe to rely
on on amd64.
-Kip
On Thu, Jun 4, 2009 at 7:48 AM, Tim Chase wrote:
> Hello,
>
> I decided to give the new zfs code a try and upgraded my stable-7 system
> and discovered a panic that I can reproduce at will.
>
> This is an i3
On Jun 4, 2009, at 10:48 AM, Tim Chase wrote:
vm.kmem_size="512M"
vm.kmem_size_max="512M"
vfs.zfs.arc_max="100M"
$1 = 0xc0792320 "kmem_malloc(131072): kmem_map too small: 325656576
total allocated"
It looks like you are suffering from fragmentation of your kmem
add
Tim Chase wrote:
Hello,
I decided to give the new zfs code a try and upgraded my stable-7 system
and discovered a panic that I can reproduce at will.
I just had the same problem, and it turned out I was not diligent when I
first set my zfs pool up :)
To use vm.kmem_size="512M" you need to p
I'm trying to use a virtual floppy from FreeBSD 7 (both 7-STABLE and
7_2_RELEASE) in a VMWare test installation.
Both running fdformat on a fresh floppy image and trying to mount a
preformatted one, I get errors like:
g_vfs_done():fd0[READ(offset=0, length=8192)]error = 6
Of course, after
Hello,
I decided to give the new zfs code a try and upgraded my stable-7 system
and discovered a panic that I can reproduce at will.
This is an i386 system with 1.5GB of RAM and a single zfs pool:
appbuild# zpool status
pool: backup
state: ONLINE
status: The p
> Well, I found time to test this today after all - and it does
> actually fix the issue - my bce devices now work properly
> with lagg and lacp.
Thanks for the confirmation.
Dave
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/ma
Dan Naumov wrote:
> Anyone else think that this combined with freebsd-update integration
> and a simplistic menu GUI for choosing the preferred boot environment
> would make an _awesome_ addition to the base system? :)
I guess freebsd-update is not a problem, should be "freebsd-update -b
". But I
Well, I found time to test this today after all - and it does actually
fix the issue - my bce devices now work properly with lagg and lacp.
thankyou!
-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-st
> That should be the packet length fix at line 5973 of if_bce.c. I did
That's the patch whcih was sent to the PR, yes ? I've tried that and it
doesn't fix it at all for me unfortunately.
> not test the teaming fix myself but another user provided a similar
> packet length fix which he claimed di
15 matches
Mail list logo
