svn commit: r303019 - head/sys/geom

[Bryan Drewery]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20160811/78a19d56/attachment.sig>