Date: Mon, 7 Mar 2016 17:52:17 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: Dimitry Andric <dim@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r296428 - head/sys/boot/common Message-ID: <20160307155217.GJ67250@kib.kiev.ua> In-Reply-To: <1457365187.13785.174.camel@freebsd.org> References: <201603061557.u26FvhMi033982@repo.freebsd.org> <56DCD52F.4010709@freebsd.org> <AC0A9708-B618-4D05-8532-BD451AB94A60@FreeBSD.org> <1457365187.13785.174.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 07, 2016 at 08:39:47AM -0700, Ian Lepore wrote: > Is there no way to prevent the panic other than making the unwind data > be present? Why can't the kernel be fixed to cope with the missing > data in some gentler way during a transition period? Perhaps valid-but > -fake data could be generated if necessary? Being unable to get a > stack traceback through a loaded module would be a small price to pay > for trouble-free updgrades. It is practically impossible to recover from partially-loaded object file' module. The loader workaround currently only affects HEAD and since the MFC was done, 10.3 should be safe. We always required lastest stable for the jump to next major branch. What could be done is demoting the panics (there are several, besides the one which was triggered) to a message and refusing to load the affected module. OTOH, if the reaction would be a message and not panic, it definitely go ignored for quite some time.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160307155217.GJ67250>