DragonFlyBSD

Need to have a set of binary packages available, and tested. i386 is available but untested as of this writing, x86_64 will be uploaded within the next 48 hours.

The release page at

http://www.dragonflybsd.org/release30/

Will need to be updated before release, with notes, dates, and checksums.

Bug #2276 umount mfs crash should be investigated

Bug #2284 should be fixed prior to release.

I feel so strong about 2108 (*context on x86_64) that I believe it should block the release of 3.0 until the fix is included. There are over 400 failures in the x86_64 bulkbuild report caused by Ruby193 alone, which is caused by bug 2108. All Boehm Garbage Collector failures are caused by this as well.

Am 24.01.2012 17:53, schrieb John Marino via Redmine:
> Issue #2286 has been updated by John Marino.
>
>
> I feel so strong about 2108 (*context on x86_64) that I believe it should block the release of 3.0 until the fix is included. There are over 400 failures in the x86_64 bulkbuild report caused by Ruby193 alone, which is caused by bug 2108. All Boehm Garbage Collector failures are caused by this as well.

Ruby19 can be compiled without the need of *context kernel support, but
it slows down execution I guess. If we cannot implement *context we
should at least fix the pkgsrc Ruby package.

Regards,

Michael

When it comes to boehm, just prevent it from using *context until a stable implementation is available. Following patch works for me:

--- a/devel/boehm-gc/patches/patch-ae
+++ b/devel/boehm-gc/patches/patch-ae
@@ -18,3 +18,12 @@ $NetBSD$
#endif /* !USE_ASM_PUSH_REGS */

#if defined(HAVE_PUSH_REGS) && defined(THREADS)
+@@ -175,7 +177,7 @@
+ # if defined(HAVE_PUSH_REGS)
+ GC_push_regs();
+ # elif defined(UNIX_LIKE) && !defined(DARWIN) && !defined(ARM32) && \
+- !defined(HURD)
++ !defined(HURD) && !defined(X86_64)
+ /* Older versions of Darwin seem to lack getcontext(). */
+ /* ARM Linux often doesn't support a real getcontext(). */
+ ucontext_t ctxt;

Bug #2290, mount_linprocfs panic: lockmgr: LK_RELEASE: no lock held,
should be fixed prior to release.

Bug 2296 (panic: assertion "m->wire_count > 0" failed)
should be fixed prior to release.

There are a few bugfixes in -master that should be merged into the release:

702c883ec92ded8a3fd9f214077f8b979c21f626 (rlimit check in tmpfs_write path)
23ecc5880dd169ab9c408114e82a49d099f45a8d (udp auto bind proc null fix)

There is a tmpfs data corruption bug that may have been fixed by three recent VM commits as well.

In addition, there are some outstanding complaints wrt the NFS client; some manifested as failure-to-push onto git trees on the official DF machines (EIO returned from perhaps badly-constructed RPCs?) and some perhaps tied to bug 2297.

Computer reboots for no apparent reason. http://bugs.dragonflybsd.org/issues/2298

Merged back 702c883ec92ded8a3fd9f214077f8b979c21f626 (rlimit check in tmpfs_write path), 23ecc5880dd169ab9c408114e82a49d099f45a8d (udp auto bind proc null fix), d52fdd344b45d86e656629e2f16e6e1f267b08a7 (linprocfs vnode locking).

tmpfs changes still need to be MFC-ed.

Should tmpfs NFS export support be MFC-ed? (see bug 2277).

Packages for 3.0 uploaded.

tmpfs updates have been merged by Matt Dillon to 3.0.

b5c0b8b2961e85db9aa2fa2c2cd1a77d91a692e5
7ab26241a9129d73605c7fad365769264ed06366
3df0509c475eb0ce3da5b44bf7d7c5394abcfaa0

I think we should MFC:
- tmpfs NFS export support (bug 2277)
- trouble building/loading crypto.ko
(http://leaf.dragonflybsd.org/mailarchive/kernel/2012-02/msg00001.html)

Will do in a few days if I see no objections.

Take note of #2305, dmalloc bug. It may be a candidate for MFC back to release 3.0. However, if it only triggers due to .preinit_array which is a 3.1 feature, then the MFC of the fix may not be required.

Justin C. Sherrill wrote:
> Packages for 3.0 uploaded.

I checked avalon reports and see a 2 FEB 2012 data on both i386 and x86_64 architectures.
The packages were built with an older version of 3.0 because the binutils 2.22 related failures are still there, resulting in hundreds of unbuilt packages (e.g. esound alone caused nearly 400 packages to not build)

The quote above makes it sound like the package building for the release is complete, but really each platform needs to be built to the latest world and the bulkbuild needs to be run again to allow the broken package that can actually build be created.

Added: Also the install phase / user issue primarily seen on ruby packages is still occurring breaking several hundred more packages so we need to get several eyes on that problem. We haven't had good package build on any platform since Oct 2011.

The MFS unmount panic was resolved by commit 0a5fa2b36cd3a10f75060ac42f431307aef7cea4 and has been MFCed. I deleted the bug instead of marking it closed by mistake, sorry!

Hi Venk,

I've recovered manually issue 2276, please close it.

Cheers,
Antonio Huete

2012/2/16 Venkatesh Srinivas via Redmine <
bugtracker-admin@leaf.dragonflybsd.org>

>
> Issue #2286 has been updated by Venkatesh Srinivas.
>
>
> The MFS unmount panic was resolved by commit
> 0a5fa2b36cd3a10f75060ac42f431307aef7cea4 and has been MFCed. I deleted the
> bug instead of marking it closed by mistake, sorry!
> ----------------------------------------
> Bug #2286: 3.0 release catchall ticket
> http://bugs.dragonflybsd.org/issues/2286
>
> Author: Justin C. Sherrill
> Status: New
> Priority: Urgent
> Assignee: Justin C. Sherrill
> Category:
> Target version:
>
>
> Catchall ticket for 3.0 release.
>
>
> --
> You have received this notification because you have either subscribed to
> it, or are involved in it.
> To change your notification preferences, please click here:
> http://bugs.dragonflybsd.org/my/account
>

The panic-during-shutdown mount bug has been root-cased and a fix is in progress.

Basically, VFS accounting holds a reference to the pfs mountpoint structure inside a vnode for nullfs cases; however it accesses a freed mount's mnt_op vector in the shutdown path, as its reference does not protect against the mount structure being freed.