Bug #2286

3.0 release catchall ticket

Added by justin almost 3 years ago. Updated over 1 year ago.

Status:ClosedStart date:01/22/2012
Priority:UrgentDue date:
Assignee:justin% Done:

0%

Category:-
Target version:-

Description

Catchall ticket for 3.0 release.


Related issues

Related to Bug #2266: panic during shutdown Closed 12/27/2011
Related to Bug #2301: installer crash x86_64 Closed 02/08/2012
Related to Bug #2276: umount mfs crash - Fatal trap 12 Closed 01/17/2012
Blocked by Bug #2284: another sysctl panic Closed
Blocked by Bug #2108: getcontext() is missing on DragonFly x86_64 Closed
Blocked by Bug #2290: mount_linprocfs panic: lockmgr: LK_RELEASE: no lock held Closed 01/26/2012
Blocked by Bug #2298: computer reboots for no apparent reason Closed 02/02/2012

History

#1 Updated by justin almost 3 years ago

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.

#2 Updated by justin almost 3 years ago

The release page at

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

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

#3 Updated by ftigeot almost 3 years ago

Bug #2276 umount mfs crash should be investigated

#4 Updated by pavalos almost 3 years ago

Bug #2284 should be fixed prior to release.

#5 Updated by marino almost 3 years ago

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.

#6 Updated by mneumann over 2 years ago

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

#7 Updated by masterblaster over 2 years ago

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;

#8 Updated by thomas.nikolajsen over 2 years ago

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

#9 Updated by thomas.nikolajsen over 2 years ago

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

#10 Updated by vsrinivas over 2 years ago

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.

#11 Updated by phma over 2 years ago

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

#12 Updated by vsrinivas over 2 years ago

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).

#13 Updated by justin over 2 years ago

Packages for 3.0 uploaded.

#14 Updated by justin over 2 years ago

tmpfs updates have been merged by Matt Dillon to 3.0.

b5c0b8b2961e85db9aa2fa2c2cd1a77d91a692e5
7ab26241a9129d73605c7fad365769264ed06366
3df0509c475eb0ce3da5b44bf7d7c5394abcfaa0

#15 Updated by thomas.nikolajsen over 2 years ago

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.

#16 Updated by dragonflybsd1 over 2 years ago

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.

#17 Updated by dragonflybsd1 over 2 years ago

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.

#18 Updated by vsrinivas over 2 years ago

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!

#19 Updated by ahuete.devel over 2 years ago

Hi Venk,

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

Cheers,
Antonio Huete

2012/2/16 Venkatesh Srinivas via Redmine <
>

>
> 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
>

#20 Updated by vsrinivas over 2 years ago

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.

#21 Updated by vsrinivas over 2 years ago

This bug should be marked 'closed'.

#22 Updated by tuxillo over 1 year ago

  • Status changed from New to In Progress

Hi,

All remaining issues to be handled in Showstopper panics for Release 3.2 (2402), they're already linked.

Justin, can you please close this one?

Thanks,
Antonio Huete

#23 Updated by justin over 1 year ago

  • Status changed from In Progress to Closed

Also available in: Atom PDF