svn commit: r303019 - head/sys/geom

[Bryan Drewery]

On 8/11/2016 5:26 PM, Bryan Drewery wrote:
> 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.
> 


da13 at mps0 bus 0 scbus0 target 14 lun 0^M^M
da13: <ATA Hitachi HUA72205 A3PA> s/n JPW9K0N00LSZYL detached^M^M
(da24:mps0: mps0:0:Target 15 supports SSU^M^M
14:mps0: 0): Target 17 supports SSU^M^M
UNMAPPED^M^M
...
g_access(969): provider da13 has error^M^M
da24 at mps0 bus 0 scbus0 target 14 lun 0^M^M
g_access(969): provider da13 has error^M^M
da24: g_access(969): provider da13 has error^M^M
da24: <ATA Hitachi HUA72205, FW:A3PA, SN:JPW9K0N00LSZYL> SCSI-6 device^M^M
da24: Serial Number JPW9K0N00LSZYL^M^M
da24: 300.000MB/s transfers^M^M
da24: Command Queueing enabled^M^M
da24: 476940MB (976773168 512 byte sectors)^M^M
da24: quirks=0x2<NO_6_BYTE>^M^M
(da13:da18 at mps0 bus 0 scbus0 target 12 lun 0^M^M
mps0:0:da18: 14:<ATA Hitachi HUA72205 A3PA>0):  s/n
JPW9K0N00LT8ELremoving device entry^M^M
 detached^M^M
(da13:da16 at mps0 bus 0 scbus0 target 13 lun 0^M^M
mps0:0:da16: 14:<ATA Hitachi HUA72205 A3PA>0):  s/n JPW9K0N00LTB4LPeriph
destroyed^M^M
 detached^M^M
da17 at mps0 bus 0 scbus0 target 10 lun 0^M^M
da17: <ATA Hitachi HUA72205 A3PA> s/n JPW9K0N00JZESL detached^M^M
da20 at mps0 bus 0 scbus0 target 16 lun 0^M^M
da20: <ATA Hitachi HUA72205 A3PA> s/n JPW9K0N00K2PEL detached^M^M
panic @ time 1470916206.652, thread 0xfffff8000412f000:
g_resize_provider_event but withered^M^M

...

-- 
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-all/attachments/20160811/9043e8ed/attachment.sig>