Date: Sat, 23 Jul 2016 22:27:15 -0700 From: Peter Wemm <peter@wemm.org> To: svn-src-all@freebsd.org Cc: svn-src-head@freebsd.org, "Andrey V. Elsukov" <ae@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r303019 - head/sys/geom Message-ID: <6198652.UmU69kS6Zt@overcee.wemm.org> In-Reply-To: <3277576.dFZ2EGo2Fh@overcee.wemm.org> References: <201607190536.u6J5aLl7015268@repo.freebsd.org> <3277576.dFZ2EGo2Fh@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2853987.LzzQhyQHJt Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Saturday, July 23, 2016 09:39:00 PM Peter Wemm wrote: > On Tuesday, July 19, 2016 05:36:21 AM Andrey V. Elsukov wrote: > > Author: ae > > Date: Tue Jul 19 05:36:21 2016 > > New Revision: 303019 > > URL: https://svnweb.freebsd.org/changeset/base/303019 > >=20 > > Log: > > Use g_resize_provider() to change the size of GEOM_DISK provider,= > > when it is being opened. This should fix the possible loss of a r= esize > > event when disk capacity changed. >=20 > Are you sure about this? We have machines in the freebsd.org cluster= that > now panic on boot: >=20 > Trying to mount root from zfs:zroot []... > GEOM_PART: da0 was automatically resized. > Use `gpart commit da0` to save changes or `gpart undo da0` to rever= t them. > GEOM_PART: integrity check failed (da0, GPT) >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 1; apic id =3D 01 > fault virtual address=09=3D 0x48 > fault code=09=09=3D supervisor read data, page not present > instruction pointer=09=3D 0x20:0xffffffff80740005 > stack pointer=09 =3D 0x28:0xfffffe01f119db10 > frame pointer=09 =3D 0x28:0xfffffe01f119db30 > code segment=09=09=3D base 0x0, limit 0xfffff, type 0x1b > =09=09=09=3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags=09=3D interrupt enabled, resume, IOPL =3D 0 > current process=09=09=3D 13 (g_event) > [ thread pid 13 tid 100019 ] > Stopped at g_part_resize+0x35: testb $0x8,0x48(%rbx) >=20 >=20 >=20 > db> where > Tracing pid 13 tid 100019 td 0xfffff8000426fa00 > g_part_resize() at g_part_resize+0x35/frame 0xfffffe01f119db30 > g_resize_provider_event() at g_resize_provider_event+0xb5/frame > 0xfffffe01f119d0 g_run_events() at g_run_events+0x20e/frame > 0xfffffe01f119dbb0 > .. >=20 > It is exploding here: > g_part_resize(struct g_consumer *cp) > { > struct g_part_table *table; >=20 > G_PART_TRACE((G_T_TOPOLOGY, "%s(%s)", __func__, > cp->provider->name)); g_topology_assert(); >=20 > table =3D cp->geom->softc; > if (table->gpt_opened =3D=3D 0) { > ^^^^^^^^^ (table is null) >=20 > Are you creating events too soon now? Sometimes da0 fails, other times da1 fails.. and sometimes it is comple= tely=20 fine. There is some sort of race going on with this change during the = very=20 first moments of bootup. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart2853987.LzzQhyQHJt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXlFG0AAoJEDXWlwnsgJ4EmLkH/A/haQXONwKWt/OP1PVowC2P ZjSzFQpHogYDJXo0HqENWYD6zNUCgz89lAYBV0jZ/m2vgEmQ3tNL2KD86j8a7Pj/ IsVgBebYT79hrVkBGs5E02iGTNEiDIe0aFupIKdouijiXbDf84eL00gIEJpOGWzy Fh6/Gtjn5LRNK6K9fA6sKJN2O3MH5kxTKqRFmw6/B07Z6vKKr3aG5vQSuISP5GV7 KOi9A1TtdrEpU2Q7OmMMone5zVWchHsmXPX4l1FkUBvxuBz786k6ZVFkHMw9CSjH RSAAB/15kc480IXf114DOL4Hd2oTXpwGaetzb3C8nxDYQIrJsMywwQ2BOyFLE54= =VtCP -----END PGP SIGNATURE----- --nextPart2853987.LzzQhyQHJt--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6198652.UmU69kS6Zt>