Date: Thu, 24 May 2018 19:12:15 +0200 From: Mark Martinec <Mark.Martinec+freebsd@ijs.si> To: freebsd-stable@freebsd.org Cc: Mark Johnston <markj@freebsd.org>, owner-freebsd-stable@freebsd.org Subject: Re: The 11.1-RC3 can only boot and attach disks in "Safe mode", otherwise gets stuck attaching Message-ID: <9648ad1b41cf184dbcce788a014cf4fa@ijs.si> In-Reply-To: <81295bcacd7c44813de8d346c88cbb65@ijs.si> References: <e4acc16980fe65751325333870bf2b68@ijs.si> <20170717232434.GB21048@wkstn-mjohnston.west.isilon.com> <c8140f430fb2af93a6bc70a3df8cdadc@ijs.si> <9b3563aae75aa954d7fe31ffe25e1d29@ijs.si> <20170720000325.GB9198@wkstn-mjohnston.west.isilon.com> <81295bcacd7c44813de8d346c88cbb65@ijs.si>
next in thread | previous in thread | raw e-mail | index | archive | help
Just a short report to a thread I started when 11.1 came out. This machine would stall in a busy loop while attaching disks during boot. Rebuilding a kernel with EARLY_AP_STARTUP disabled avoided the problem. This was a situation through the whole 11.1 life cycle (i.e. patch releases did not help). Today I have upgraded this host to 11.2-BETA2, and it is no longer necessary to disable EARLY_AP_STARTUP. Good, thanks! Mark > 2017-07-20 02:03, Mark Johnston wrote: >> One thing to try at this point would be to disable EARLY_AP_STARTUP in >> the kernel config. That is, take a configuration with which you're >> able >> to reproduce the hang during boot, and remove "options >> EARLY_AP_STARTUP". > > 2017-07-20 15:45, Mark Martinec wrote: > Done. And it avoids the problem altogether! Thanks. > Tried a reboot several times and it succeeds every time. > > Here is all that I had in a config file for building a kernel, > i.e. I took away the 'options DDB' which also seemingly avoided > the problem: > include GENERIC > ident NELI > nooptions EARLY_AP_STARTUP > >> This feature has a fairly large impact on the bootup process and has >> had a few problems that manifested as hangs during boot. There was at >> least one other case where an innocuous change to the kernel >> configuration "fixed" the problem by introducing some second-order >> effect (causing kernel threads to be scheduled in a different >> order, for instance). [...]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9648ad1b41cf184dbcce788a014cf4fa>