On Monday, February 28, 2011 3:39:28 pm Roman Divacky wrote:
> 3) it changes the first keyhit limit to 5 seconds from 3
>so that constant propagation can take place
Does this make booting take 2 seconds longer as a result?
I'm curious as to why '3*FOO' isn't a constant but '5*FOO' is?
I thin
hi there,
I have a patch that shrinks boot2 some:
1) it switches kname to be just a pointer instead of an array
thus avoiding a couple of memcpy()s
2) it changes ioctl to unsigned from uint8_t
3) it changes the first keyhit limit to 5 seconds from 3
so that constant propagation can take p
On Monday, February 28, 2011 9:49:07 am Nathan Whitehorn wrote:
> BSDinstall has acquired at this point its final form (prior to a future
> merge with pc-sysinstall), and I believe is ready to replace sysinstall
> on the 9.0 snapshot ISOs. Barring any objections, I would like to pull
> this swit
On 02/28/11 08:56, Bruce Cran wrote:
On Mon, 28 Feb 2011 08:49:07 -0600
Nathan Whitehorn wrote:
- There is only one CD image produced, which is always also a live CD
It would be really useful if a netinstall ISO could be made too -
people still have slow Internet connections where having a bo
On Mon, 28 Feb 2011 08:49:07 -0600
Nathan Whitehorn wrote:
> - There is only one CD image produced, which is always also a live CD
It would be really useful if a netinstall ISO could be made too -
people still have slow Internet connections where having a bootonly
disc is nice. For example Debia
e who has provided testing and feedback over the last
two months!
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Fri, 2011-02-25 at 13:08 +0100, Olivier Smedts wrote:
> Not the same sysmacros.h, the one patched is
> sys/cddl/contrib/opensolaris/uts/common/sys/sysmacros.h, the other one
> you referenced (sys/cddl/compat/opensolaris/sys/sysmacros.h) is
> removed by the patch.
So it is - apologies for the n
2011/2/25 Bruce Cran :
> On Fri, Feb 25, 2011 at 10:59:04AM +0100, Olivier Smedts wrote:
>>
>> Added ? The patch fails because the svn tag is not expanded, but what
>> the patch does is remove the file. You can do so after patching if it
>> failed.
>
> It looks like there are two patches to sysmacr
On Fri, Feb 25, 2011 at 10:59:04AM +0100, Olivier Smedts wrote:
>
> Added ? The patch fails because the svn tag is not expanded, but what
> the patch does is remove the file. You can do so after patching if it
> failed.
It looks like there are two patches to sysmacros.h - the first adds SIGNOF an
2011/2/25 Bruce Cran :
> On Wed, 2011-02-23 at 23:28 +0100, Olivier Smedts wrote:
>
>> I'm successfuly using the following on latest 9-CURRENT :
>> http://people.freebsd.org/~mm/patches/zfs/v28/head-zfsv28-20110219-nopython.patch.xz
>
> sys/cddl/compat/opensolaris/sys/sysmacros.h will fail to patch
On Wed, 2011-02-23 at 23:28 +0100, Olivier Smedts wrote:
> I'm successfuly using the following on latest 9-CURRENT :
> http://people.freebsd.org/~mm/patches/zfs/v28/head-zfsv28-20110219-nopython.patch.xz
sys/cddl/compat/opensolaris/sys/sysmacros.h will fail to patch on the
latest -CURRENT but tha
2011/2/23 Jason Garrett :
> On Mon, Feb 7, 2011 at 08:01, Anonymous wrote:
>
>> Anonymous writes:
>>
>> > Pawel Jakub Dawidek writes:
>> >
>> >> The new patchset is ready for testing:
>> >>
>> >> http://people.freebs
On Mon, Feb 7, 2011 at 08:01, Anonymous wrote:
> Anonymous writes:
>
> > Pawel Jakub Dawidek writes:
> >
> >> The new patchset is ready for testing:
> >>
> >> http://people.freebsd.org/~pjd/patches/zfs_20101212.patch.bz2
> >>
>
On Wed, Feb 09, 2011 at 10:28:53AM -0500, David Boyd wrote:
> Having some time to test 9.0-CURRENT with the new dialog command has
> uncovered only one major omission (for us): prgbox/dialog_prgbox.
>
> This is used in most (if not all) of our installation/management scripts.
>
> Was prgbox omitt
On 02/09/11 10:15, Garrett Cooper wrote:
On Wed, Feb 9, 2011 at 7:28 AM, David Boyd wrote:
Having some time to test 9.0-CURRENT with the new dialog command has
uncovered only one major omission (for us): prgbox/dialog_prgbox.
This is used in most (if not all) of our installation/management scr
On Wed, Feb 9, 2011 at 7:28 AM, David Boyd wrote:
> Having some time to test 9.0-CURRENT with the new dialog command has
> uncovered only one major omission (for us): prgbox/dialog_prgbox.
>
> This is used in most (if not all) of our installation/management scripts.
>
> Was prgbox omitted for any
Having some time to test 9.0-CURRENT with the new dialog command has
uncovered only one major omission (for us): prgbox/dialog_prgbox.
This is used in most (if not all) of our installation/management scripts.
Was prgbox omitted for any particular reason?
I realize that change is inevitable.
Is
Anonymous writes:
> Pawel Jakub Dawidek writes:
>
>> The new patchset is ready for testing:
>>
>> http://people.freebsd.org/~pjd/patches/zfs_20101212.patch.bz2
>>
>
> `-e' option in zdb(8) now looks under /dev/dsk by default
>
>
On 02/05/11 03:04, Anonymous wrote:
Nathan Whitehorn writes:
As part of work on a new installer, I would like to update the base
system dialog and libdialog to the newer one provided by Thomas Dickey
(http://invisible-island.net/dialog/, ports as devel/cdialog). This is
a much nicer, fuller fe
Nathan Whitehorn writes:
> As part of work on a new installer, I would like to update the base
> system dialog and libdialog to the newer one provided by Thomas Dickey
> (http://invisible-island.net/dialog/, ports as devel/cdialog). This is
> a much nicer, fuller featured version of dialog that s
2011/2/2 Christopher Olsen :
> Pawel,
>
> I have the latest current source and I patched with your zfs patch from
> zfs_20101213.patch and I am having trouble compiling my kernel.. Is there a
> more current patch to work with the latest –CURRENT source?
An answer from yesterday (working for me t
Pawel,
I have the latest current source and I patched with your zfs patch from
zfs_20101213.patch and I am having trouble compiling my kernel.. Is there a
more current patch to work with the latest –CURRENT source?
-Christopher
___
freebsd-cur
ub Dawidek
Cc: freebsd...@freebsd.org; freebsd-current@freebsd.org
Subject: RE: My ZFS v28 Testing Experience
>Before we go any further could you please confirm that you commented out this
>line in sys/modules/zfs/Makefile:
>
> CFLAGS+=-DDEBUG=1
>
>This turns all kind of ZFS
>Before we go any further could you please confirm that you commented out this
>line in sys/modules/zfs/Makefile:
>
> CFLAGS+=-DDEBUG=1
>
>This turns all kind of ZFS debugging and slows it down a lot, but for the
>correctness testing is invaluable. This will >be t
t). --ascii-lines helps here.
script would help.
Thanks!
with default options) in syscons, en_US.UTF-8. I'll provide additional
testing/details if this information is not enough to reproduce.
/head uses xterm emulation by default. This may or may not affect
pseudographics.
Thanks,
-Ga
>>
>> Apart from OPTIONS there is also ports/154121 (--hline).
>
> Thanks for the hints. Garbage means screen is totally unreadable, not minor
> issues with pseudographic characters (sorry, not sure how to make a
> screenshot of that). --ascii-lines helps here.
scri
121 (--hline).
Thanks for the hints. Garbage means screen is totally unreadable, not
minor issues with pseudographic characters (sorry, not sure how to make
a screenshot of that). --ascii-lines helps here.
with default options) in syscons, en_US.UTF-8. I'll provide additional
testing/de
from OPTIONS there is also ports/154121 (--hline).
> with default options) in syscons, en_US.UTF-8. I'll provide additional
> testing/details if this information is not enough to reproduce.
/head uses xterm emulation by default. This may or may not affect
pseudographics.
side the screen (built
with default options) in syscons, en_US.UTF-8. I'll provide additional
testing/details if this information is not enough to reproduce.
TIA,
Yuri
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mai
On Wed, Jan 12, 2011 at 11:03:19PM -0400, Chris Forgeron wrote:
> I've been testing out the v28 patch code for a month now, and I've yet to
> report any real issues other than what is mentioned below.
>
> I'll detail some of the things I've tested, hopefully th
I've been testing out the v28 patch code for a month now, and I've yet to
report any real issues other than what is mentioned below.
I'll detail some of the things I've tested, hopefully the stability of v28 in
FreeBSD will convince others to give it a try so the final rel
On Thursday, January 06, 2011 6:09:27 am Erik Trulsson wrote:
> On Wed, Jan 05, 2011 at 06:57:14PM -0600, Nathan Whitehorn wrote:
> > As part of work on a new installer, I would like to update the base
> > system dialog and libdialog to the newer one provided by Thomas Dickey
> > (http://invisibl
On 01/06/11 05:09, Erik Trulsson wrote:
On Wed, Jan 05, 2011 at 06:57:14PM -0600, Nathan Whitehorn wrote:
As part of work on a new installer, I would like to update the base
system dialog and libdialog to the newer one provided by Thomas Dickey
(http://invisible-island.net/dialog/, ports as deve
On Thu, 6 Jan 2011 12:09:27 +0100
Erik Trulsson wrote:
> Why not keep the old version as libdialog and instead use a new name
> for the new library (libndialog or whatever) ?
> (I am not saying you should do this - it is a real question.)
Because then we can never upgrade to a newer version of l
On Wed, Jan 05, 2011 at 06:57:14PM -0600, Nathan Whitehorn wrote:
> As part of work on a new installer, I would like to update the base
> system dialog and libdialog to the newer one provided by Thomas Dickey
> (http://invisible-island.net/dialog/, ports as devel/cdialog). This is a
> much nicer
On 01/05/11 18:57, Nathan Whitehorn wrote:
- /usr/src/gnu/lib/dialog -- new dialog library
This was a typo. It should be /usr/src/gnu/lib/libdialog. Apologies for
the noise.
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.or
As part of work on a new installer, I would like to update the base
system dialog and libdialog to the newer one provided by Thomas Dickey
(http://invisible-island.net/dialog/, ports as devel/cdialog). This is a
much nicer, fuller featured version of dialog that simplifies the
creation of new d
On Wed, Dec 15, 2010 at 10:15:40AM +0200, Andrei Kolu wrote:
> 2010/12/14 Pawel Jakub Dawidek
> >
> > On Mon, Dec 13, 2010 at 10:45:56PM +0100, Pawel Jakub Dawidek wrote:
> > > Hi.
> > >
> > > The new patchset is ready for testing:
> > >
Pawel Jakub Dawidek writes:
> The new patchset is ready for testing:
>
> http://people.freebsd.org/~pjd/patches/zfs_20101212.patch.bz2
>
`-e' option in zdb(8) now looks under /dev/dsk by default
$ zdb -ec blah
Configuration for import:
vdev_children: 1
On Fri, Dec 17, 2010 at 12:54:36AM +0300, Rechistov Grigory (Речистов Григорий)
wrote:
> I started to check the new ZFS version inside a VirtualBox machine. So far
> it works for me without crashes, but I got some observations worth
> mentioning. Here are the steps I made:
>
> 1. Installed 8.
On 12/15/2010 23:19, Pawel Jakub Dawidek wrote:
On Wed, Dec 15, 2010 at 10:15:00PM -0500, ben wilber wrote:
On Mon, Dec 13, 2010 at 10:45:56PM +0100, Pawel Jakub Dawidek wrote:
Hi.
The new patchset is ready for testing:
Running fine for 24 hours now under load with a ~50 disk v15 (not
2010/12/13 Pawel Jakub Dawidek :
> Please test, test, test. Chances are this is the last patchset before
> v28 going to HEAD (finally). Especially test new changes, like boot
> support and sendfile(2) support. Also be sure to verify if you can
> import for existing ZFS pools (v13-v15) when running
On 17/12/2010 08:56, Rechistov Grigory (Речистов Григорий) wrote:
By the way, could someone suggest what types of stability tests I might
perform? I.e. examples of disk- and FS-intensive workloads.
Run blogbench and bonnie++ at the same time, possibly with tarring and
untarring /usr/ports.
_
I got more stacktraces in course of compilation of bash, see the updated
dmesg.
By the way, could someone suggest what types of stability tests I might
perform? I.e. examples of disk- and FS-intensive workloads.
On Fri, 17 Dec 2010 00:54:36 +0300, Rechistov Grigory (Речистов Григорий)
wr
On Fri, 17 Dec 2010 01:29:14 +0300, Olivier Smedts
wrote:
2010/12/16 Rechistov Grigory (Речистов Григорий) :
I started to check the new ZFS version inside a VirtualBox machine. So
far
it works for me without crashes, but I got some observations worth
mentioning. Here are the steps I made:
2010/12/16 Rechistov Grigory (Речистов Григорий) :
> I started to check the new ZFS version inside a VirtualBox machine. So far
> it works for me without crashes, but I got some observations worth
> mentioning. Here are the steps I made:
>
> 1. Installed 8.1-RELEASE (from minimal install CD)
> 2.
I started to check the new ZFS version inside a VirtualBox machine. So far
it works for me without crashes, but I got some observations worth
mentioning. Here are the steps I made:
1. Installed 8.1-RELEASE (from minimal install CD)
2. Csup'ped sources to CURRENT (as of 14/12/2010) [note that
2010/12/13 Pawel Jakub Dawidek :
> Please test, test, test. Chances are this is the last patchset before
> v28 going to HEAD (finally). Especially test new changes, like boot
> support and sendfile(2) support. Also be sure to verify if you can
> import for existing ZFS pools (v13-v15) when running
2010/12/13 Pawel Jakub Dawidek :
> Please test, test, test. Chances are this is the last patchset before
> v28 going to HEAD (finally). Especially test new changes, like boot
> support and sendfile(2) support. Also be sure to verify if you can
> import for existing ZFS pools (v13-v15) when running
First of all, thank pjd@, mm@ and others who made zfs go ahead in
FreeBSD! You are absolutely monsters!
Now one question, what I do wrong, that I can't use /boot/zfsboot to
boot MBR+zfs-only FreeBSD?
More info. If I use /boot/zfsboot form recent STABLE (from snapshot CD
or built myself) to boo
On Wed, Dec 15, 2010 at 10:15:00PM -0500, ben wilber wrote:
> On Mon, Dec 13, 2010 at 10:45:56PM +0100, Pawel Jakub Dawidek wrote:
> > Hi.
> >
> > The new patchset is ready for testing:
>
> Running fine for 24 hours now under load with a ~50 disk v15 (not
> upgrade
On Mon, Dec 13, 2010 at 10:45:56PM +0100, Pawel Jakub Dawidek wrote:
> Hi.
>
> The new patchset is ready for testing:
Running fine for 24 hours now under load with a ~50 disk v15 (not
upgraded) pool from -CURRENT. Thanks!
Only strange thing is the rc script complains:
/etc/
I've installed and complied it on 9-Current 2010.12.12, looks to be running
fine.
I've imported a v15 6 disk raidz that was created under 8.1-Stable, and so far
it's passing all tests.
I'll be doing some serious Send/Receive testing in the next few days, so I'll
see
Anonymous writes:
> $ zfs allow
> Traceback (most recent call last):
> File "/usr/lib/zfs/pyzfs.py", line 35, in
> import zfs.util
> File "/usr/local/lib/python2.7/site-packages/zfs/util.py", line 31, in
>
> import solaris.misc
> ImportError: No module named solaris.misc
> Exit
Pawel Jakub Dawidek writes:
> Hi.
>
> The new patchset is ready for testing:
>
> http://people.freebsd.org/~pjd/patches/zfs_20101212.patch.bz2
>
> When applying the patch be sure to use correct options for patch(1)!:
>
> # cd /usr/src
> # fetch
Thanks for the notice.
I have found the cause of this error (wrong constants), tested the code
in both directions again (v15->v28 and v28->v15) + fixed it in perforce.
Bugfix patch (apply after pjd's patch):
http://people.freebsd.org/~mm/patches/zfs/v28/head-zfs_ioctl_compat.c.patch
Dňa 14.12.20
2010/12/14 Pawel Jakub Dawidek :
> On Tue, Dec 14, 2010 at 03:20:05PM +0100, Olivier Smedts wrote:
>> > make installworld
>>
>> That's what I wanted to do, and why I rebooted single-user on the new
>> kernel. But isn't the v13-v15 userland supposed to work with the v28
>> kernel ?
>
> Yes, it is su
On Tue, Dec 14, 2010 at 03:20:05PM +0100, Olivier Smedts wrote:
> > make installworld
>
> That's what I wanted to do, and why I rebooted single-user on the new
> kernel. But isn't the v13-v15 userland supposed to work with the v28
> kernel ?
Yes, it is suppose to work. Exactly to be able to follo
- Original Message -
From: "Olivier Smedts"
make installworld
That's what I wanted to do, and why I rebooted single-user on the new
kernel. But isn't the v13-v15 userland supposed to work with the v28
kernel ?
Not if you have just upgrade from 8-STABLE to Current.
Regards
Ste
2010/12/14 Steven Hartland :
> - Original Message - From: "Olivier Smedts"
>
>> I tried it on my 8-STABLE box (root zpool v15 on 2 mirrored vdevs with
>> an usb l2 cache). I checked-out CURRENT sources with svn, applied the
>> patch (it applied cleanly). Did not modify kernel config (no
>>
- Original Message -
From: "Olivier Smedts"
I tried it on my 8-STABLE box (root zpool v15 on 2 mirrored vdevs with
an usb l2 cache). I checked-out CURRENT sources with svn, applied the
patch (it applied cleanly). Did not modify kernel config (no
debugging) or make.conf. buildworld, bui
2010/12/13 Pawel Jakub Dawidek :
> Hi.
>
> The new patchset is ready for testing:
>
> http://people.freebsd.org/~pjd/patches/zfs_20101212.patch.bz2
>
> When applying the patch be sure to use correct options for patch(1)!:
>
> # cd /usr/src
> # f
On Mon, Dec 13, 2010 at 11:00:31PM -, Steven Hartland wrote:
> What's the expected behaviour for the sendfile changes as
> sendfile is one of the problems we have here with the
> double memory allocation required for it under ZFS compared
> to UFS. Does this patch address that?
No. The patch d
On Mon, Dec 13, 2010 at 10:45:56PM +0100, Pawel Jakub Dawidek wrote:
> Hi.
>
> The new patchset is ready for testing:
>
> http://people.freebsd.org/~pjd/patches/zfs_20101212.patch.bz2
You can also download the whole source tree already patched from here:
http://peo
On Mon, Dec 13, 2010 at 10:45:56PM +0100, Pawel Jakub Dawidek wrote:
> Hi.
>
> The new patchset is ready for testing:
>
> http://people.freebsd.org/~pjd/patches/zfs_20101212.patch.bz2
>
> When applying the patch be sure to use correct options for patch(1)!:
>
Hi.
The new patchset is ready for testing:
http://people.freebsd.org/~pjd/patches/zfs_20101212.patch.bz2
When applying the patch be sure to use correct options for patch(1)!:
# cd /usr/src
# fetch http://people.freebsd.org/~pjd/patches/zfs_20101212.patch.bz2
On 19 November 2010 01:56, Sean Bruno wrote:
> On Thu, 2010-11-18 at 13:17 -0800, Ivan Voras wrote:
>> I have an IPMI-enabled server with BMC watchdog, and if I understand it
>> correctly, /dev/fido will be attached as the result of loading ipmi.ko.
>>
>> Is there some easy way to test if everythi
I have an IPMI-enabled server with BMC watchdog, and if I understand it
correctly, /dev/fido will be attached as the result of loading ipmi.ko.
Is there some easy way to test if everything works?
___
freebsd-current@freebsd.org mailing list
http://lis
On Wed, Nov 03, 2010 at 07:28:15PM +0100, Olivier Smedts wrote:
> > http://people.freebsd.org/~pjd/patches/zfs_20100831.patch.bz2
>
> Hello,
>
> Any status update on this ? I regularly check
> http://people.freebsd.org/~pjd/patches/ to see if there's an updated
> version of your patch. 2 m
2010/8/31 Pawel Jakub Dawidek :
> Hello.
>
> I'd like to give you ZFS v28 for testing. If you are neither brave nor
> mad, you can stop here.
>
> The patchset is very experimental. It can eat your cookie and hurt your
> teddy bear, so be warned. Don't try it for an
On Fri, 15 Oct 2010, Robert N. M. Watson wrote:
On 15 Oct 2010, at 20:39, Garrett Cooper wrote:
But there are already some cases that aren't properly handled
today in the ddb area dealing with dumping that aren't handled
properly. Take for instance the following two scenarios:
1. Call doadu
On 15 Oct 2010, at 20:39, Garrett Cooper wrote:
>But there are already some cases that aren't properly handled
> today in the ddb area dealing with dumping that aren't handled
> properly. Take for instance the following two scenarios:
> 1. Call doadump twice from the debugger.
> 2. Call doadu
On Fri, Oct 15, 2010 at 12:25 PM, Robert Watson wrote:
> On Thu, 14 Oct 2010, Attilio Rao wrote:
>
>>> No, what I'm saying is: UMA needs to not call its drain handlers, and
>>> ideally not call into VM to fill slabs, from the dumping context. That's
>>> easy to implement and will cause the dump to
On Thu, 14 Oct 2010, Attilio Rao wrote:
No, what I'm saying is: UMA needs to not call its drain handlers, and
ideally not call into VM to fill slabs, from the dumping context. That's
easy to implement and will cause the dump to fail rather than causing the
system to hang.
My point is, howeve
2010/10/14 Robert N. M. Watson :
>
> On 14 Oct 2010, at 15:10, Attilio Rao wrote:
>
>>> My concern is less about occasional lost dumps that destabilising the
>>> dumping process: calls into the memory allocator can currently trigger a
>>> lot of interesting behaviours, such as further calls back
On 14 Oct 2010, at 15:10, Attilio Rao wrote:
>> My concern is less about occasional lost dumps that destabilising the
>> dumping process: calls into the memory allocator can currently trigger a lot
>> of interesting behaviours, such as further calls back into the VM system,
>> which can then t
2010/10/14 Robert N. M. Watson :
>
> On 13 Oct 2010, at 18:46, Ryan Stone wrote:
>
>> On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote:
>>> + /*
>>> + * get and fill a header mbuf, then chain data as an
>>> extended
>>> + * mbuf.
>>> +
On 13 Oct 2010, at 18:46, Ryan Stone wrote:
> On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote:
>> + /*
>> +* get and fill a header mbuf, then chain data as an
>> extended
>> +* mbuf.
>> +*/
>> + MGETHDR(m, M_DONTWAIT
On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson wrote:
> + /*
> +* get and fill a header mbuf, then chain data as an
> extended
> +* mbuf.
> +*/
> + MGETHDR(m, M_DONTWAIT, MT_DATA);
>
> The idea of calling into the mbuf allo
On Wed, Oct 13, 2010 at 01:04:54PM +0200, Attilio Rao wrote:
> 2010/10/9 Robert Watson :
> > (1) Did you consider using tftp as the network dump protocol, rather than a
> > custom protocol? ??It's also a simple UDP-based, ACKed file transfer
> > protocol, with the advantage that it's widely suppo
2010/10/9 Robert Watson :
> On Fri, 8 Oct 2010, Attilio Rao wrote:
>
>>> GENERAL FRAMEWORK ARCHITECTURE
>>>
>>> Netdump is composed, right now, by an userland "server" and a kernel
>>> "client". The former is run on the target machine (where the dump will
>>> phisically happen) and it is responsibl
On Sat, Oct 09, 2010 at 02:15:39AM +0100, Robert Watson wrote:
> Network dumps would be a great addition to the FreeBSD debugging suite!
> [...]
It seems that at EuroBSDCon there was a discussion of Contiki[1] and
the uIPv6 stack[2] that it contains, and I think something like this
could be a gre
On Fri, 8 Oct 2010, Attilio Rao wrote:
GENERAL FRAMEWORK ARCHITECTURE
Netdump is composed, right now, by an userland "server" and a kernel
"client". The former is run on the target machine (where the dump will
phisically happen) and it is responsible for receiving the packets
containing cor
s, among
> the netdump methods, the existence of 2 versions of polling hooks,
> where the "unlocked" is meant as reducing locking as much as possible.
>
> PATCH AND FURTHER WORK
>
> The patch is not totally complete and it is not intended to be
> committed in SVN yet
FYI: http://article.gmane.org/gmane.os.freebsd.devel.acpi/6440
If you can test and would like to report, please followup to that thread on
acpi@
mailing list. Please do not followup to this post.
Thanks!
--
Andriy Gapon
___
freebsd-current@freebsd.org
The 1st error is caught :).
Prior actions was triggering netdump, leaving db>
and entering again, then trigger netdump once more.
Dumping 1146 MB: 1131 1115 1099 1083 1067 1051 1035 1019 1003 987 971
955 939 923 907 891 875 859 843 827 811 795. . . . . . . . . . .
** DUMP FAILED (ERROR 60) **
Fai
> From: Ryan Stone
> Date: Wed, Sep 29, 2010 at 11:32 AM
> Subject: Re: [PATCH] Netdump for review and testing -- preliminary version
> To: Sergey Kandaurov
>
>
>> db> netdump
>>
>> ---
>> netdump in progress. searching
-- Forwarded message --
Replying to the list this time...
From: Ryan Stone
Date: Wed, Sep 29, 2010 at 11:32 AM
Subject: Re: [PATCH] Netdump for review and testing -- preliminary version
To: Sergey Kandaurov
> db> netdump
>
> ---
2010/9/29 Sergey Kandaurov :
> [just don't know what namely need to test, so]
>
> All made according to your instructions.
> The only way I could trigger netdump was
> to run its ddb command by hand. Neither
> debug.kdb.enter nor debug.kdb.panic don't do it.
You probabilly need to use KDB_UNATTEND
on 28/09/2010 20:39 Attilio Rao said the following:
> In order to work into an "up and running" system (meant as with all
> the devices in place) the netdump handler hooks as a pre-sync handler
> (differently from other dumping routines). It however suffers some
I actually like this idea. I think
[just don't know what namely need to test, so]
All made according to your instructions.
The only way I could trigger netdump was
to run its ddb command by hand. Neither
debug.kdb.enter nor debug.kdb.panic don't do it.
Some numbers and output (bit verbose
but again don't know what need to show her
eadlocks during inspections*. That reflects, among
the netdump methods, the existence of 2 versions of polling hooks,
where the "unlocked" is meant as reducing locking as much as possible.
PATCH AND FURTHER WORK
The patch is not totally complete and it is not intended to be
committed in
On 09/02/10 17:48, Pawel Jakub Dawidek wrote:
On Tue, Aug 31, 2010 at 11:59:15PM +0200, Pawel Jakub Dawidek wrote:
[...]
Ok, now that I know you read everything carefully, here is the patch:
http://people.freebsd.org/~pjd/patches/zfs_20100831.patch.bz2
Now it is even easier to test ne
Hi,
I have just imported your VirtualBox appliance,
created some zpool and wanted to try *dedup* on
FreeBSD, but while I was able to enable *dedup*,
I was not able to check *dedupratio* because
that 'property' is not available, on OpenSolaris
it looked like that:
# zpool get dedupratio pool
NAME
s-v28-20100831.patch
>>
>> For users who don't want to compile I have created a mfsBSD ISO image
>> with a zfs-only install of 9-CURRENT-amd64:
>> http://mfsbsd.vx.sk/iso/mfsbsd-se-head-zfsv28-amd64.iso
>>
>> You can read more about all of this here:
&g
Wiadomość napisana przez Anonymous w dniu 2010-09-05, o godz. 20:56:
> Pawel Jakub Dawidek writes:
>
>> Hello.
>>
>> I'd like to give you ZFS v28 for testing. If you are neither brave nor
>> mad, you can stop here.
> [...]
>> So test whatever y
ore about all of this here:
> http://blog.vx.sk/archives/9-Help-testing-ZFS-v28-in-FreeBSD.html
>
> More information about ZFS pool and filesystem versions:
> http://blog.vx.sk/archives/4-ZFS-pool-and-filesystem-versions.html
>
> Thanks to everybody participating in tes
created a mfsBSD ISO image
with a zfs-only install of 9-CURRENT-amd64:
http://mfsbsd.vx.sk/iso/mfsbsd-se-head-zfsv28-amd64.iso
You can read more about all of this here:
http://blog.vx.sk/archives/9-Help-testing-ZFS-v28-in-FreeBSD.html
More information about ZFS pool and filesystem versions:
http://
Pawel Jakub Dawidek writes:
> Hello.
>
> I'd like to give you ZFS v28 for testing. If you are neither brave nor
> mad, you can stop here.
[...]
> So test whatever you can and report back. Look for regressions,
> strange behaviour,
I wonder why new files tend to have
I got this compile error agains todays current patched with patch -p0 -E <
/usr/src9/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:
In function 'zfs_ioc_recv':
/usr/src9/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:3586:
error: too fe
601 - 700 of 1012 matches
Mail list logo
