On 7/23/2016 10:27 PM, Peter Wemm wrote: > 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 >>> >>> 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 resize >>> event when disk capacity changed. >> >> Are you sure about this? We have machines in the freebsd.org cluster that >> now panic on boot: >> >> 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 revert them. >> GEOM_PART: integrity check failed (da0, GPT) >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x48 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff80740005 >> stack pointer = 0x28:0xfffffe01f119db10 >> frame pointer = 0x28:0xfffffe01f119db30 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 13 (g_event) >> [ thread pid 13 tid 100019 ] >> Stopped at g_part_resize+0x35: testb $0x8,0x48(%rbx) >> >> >> >> 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 >> .. >> >> It is exploding here: >> g_part_resize(struct g_consumer *cp) >> { >> struct g_part_table *table; >> >> G_PART_TRACE((G_T_TOPOLOGY, "%s(%s)", __func__, >> cp->provider->name)); g_topology_assert(); >> >> table = cp->geom->softc; >> if (table->gpt_opened == 0) { >> ^^^^^^^^^ (table is null) >> >> Are you creating events too soon now? > > Sometimes da0 fails, other times da1 fails.. and sometimes it is completely > fine. There is some sort of race going on with this change during the very > first moments of bootup. >
On r303467 I ran into this: panic @ time 1470916206.652, thread 0xfffff8000412f000: g_resize_provider_event but withered cpuid = 0 Panic occurred in module kernel loaded at 0xffffffff80200000: Stack: -------------------------------------------------- kernel:kassert_panic+0x166 kernel:g_resize_provider_event+0x181 kernel:g_run_events+0x186^M^M kernel:fork_exit+0x83^M^M -------------------------------------------------- No further information available unfortunately. -- Regards, Bryan Drewery
signature.asc
Description: OpenPGP digital signature