Re: svn commit: r303019 - head/sys/geom
On 8/13/16 5:45 AM, Warner Losh wrote: > On Fri, Aug 12, 2016 at 3:06 PM, Ngie Cooper wrote: >> On Fri, Aug 12, 2016 at 8:23 AM, Bryan Drewery wrote: >> >> ... >> >>> No, I was missing r303637. Hard to say if it is related... Andrey says >>> it's not. I haven't dived into it yet and it's so far only happened >>> once (out of a few tests). We do have various customizations but I'm >>> inclined to think it's the stock code having problems. >> >> I hit it again on our internal vendor tree (what bdrewery was noting >> previously). I can provide some details about the panic if need be. > > Ideally, you'd reproduce it on an unmodified -current. In a vendor tree > there's > many chances that something else is odd or off that would make it hard for > the community to help. > > Warner > #4 0x80477b82 in g_resize_provider_event (arg=0xf80007f8d3a0, flag=) at /b/mnt/src/sys/geom/geom_subr.c:668 668 KASSERT(!(pp->flags & G_PF_WITHER), (gdb) p pp->mediasize $2 = 0 It seems that r303637 really does cover the panic we're hitting since the g_resize_provider_event was posted with mediasize==0 which r303637 avoids. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: svn commit: r303019 - head/sys/geom
On Fri, Aug 12, 2016 at 3:06 PM, Ngie Cooper wrote: > On Fri, Aug 12, 2016 at 8:23 AM, Bryan Drewery wrote: > > ... > >> No, I was missing r303637. Hard to say if it is related... Andrey says >> it's not. I haven't dived into it yet and it's so far only happened >> once (out of a few tests). We do have various customizations but I'm >> inclined to think it's the stock code having problems. > > I hit it again on our internal vendor tree (what bdrewery was noting > previously). I can provide some details about the panic if need be. Ideally, you'd reproduce it on an unmodified -current. In a vendor tree there's many chances that something else is odd or off that would make it hard for the community to help. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r303019 - head/sys/geom
On Fri, Aug 12, 2016 at 8:23 AM, Bryan Drewery wrote: ... > No, I was missing r303637. Hard to say if it is related... Andrey says > it's not. I haven't dived into it yet and it's so far only happened > once (out of a few tests). We do have various customizations but I'm > inclined to think it's the stock code having problems. I hit it again on our internal vendor tree (what bdrewery was noting previously). I can provide some details about the panic if need be. Thanks, -Ngie ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r303019 - head/sys/geom
On 8/12/16 8:21 AM, Warner Losh wrote: > On Fri, Aug 12, 2016 at 9:17 AM, Kenneth D. Merry wrote: >> On Fri, Aug 12, 2016 at 09:13:58 -0600, Warner Losh wrote: >>> On Fri, Aug 12, 2016 at 9:11 AM, Kenneth D. Merry wrote: On Fri, Aug 12, 2016 at 13:38:21 +0300, Andrey V. Elsukov wrote: > On 12.08.16 03:26, Bryan Drewery wrote: >> On r303467 I ran into this: >> >> panic @ time 1470916206.652, thread 0xf8000412f000: >> g_resize_provider_event but withered >> cpuid = 0 >> Panic occurred in module kernel loaded at 0x8020: >> >> 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. > > This one is related to r302087 :) It looks like there is a race. I think we need to replace the KASSERT in g_resize_provider_event() with a return in case the provider is withered. I won't be able to work on or test this until sometime next week. So if you guys want to go ahead and make the change, please do. >>> >>> But why are we calling g_resize_provider on a withered object? That's >>> the part I don't understand in this thread. >> >> It isn't withered when the event is queued, but it is withered by the time >> the event is executed. >> >> There is a check in g_resize_provider() to make sure it isn't withered. If >> not, the event is queued. But once g_resize_provider_event() runs, it is >> withered and we run into the KASSERT. >> >> There isn't adequate locking and ordering in there to prevent the race >> from happening, so the assert should be replaced with an "if (withered) >> return" statement. > > I'll grant that we may wither with outstanding events, but why is it > withering? That seems odd. Either we're bogusly posting this event > just before it will wither, or something else is bogusly withering it. > Just removing the assert isn't going to fix the underlying issue. > > Back to Bryan: just to be clear, this is with the latest version of > the code, and not the intermediate version that was fixed after > numerous problems surfaced, right? > No, I was missing r303637. Hard to say if it is related... Andrey says it's not. I haven't dived into it yet and it's so far only happened once (out of a few tests). We do have various customizations but I'm inclined to think it's the stock code having problems. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: svn commit: r303019 - head/sys/geom
On Fri, Aug 12, 2016 at 9:17 AM, Kenneth D. Merry wrote: > On Fri, Aug 12, 2016 at 09:13:58 -0600, Warner Losh wrote: >> On Fri, Aug 12, 2016 at 9:11 AM, Kenneth D. Merry wrote: >> > On Fri, Aug 12, 2016 at 13:38:21 +0300, Andrey V. Elsukov wrote: >> >> On 12.08.16 03:26, Bryan Drewery wrote: >> >> > On r303467 I ran into this: >> >> > >> >> > panic @ time 1470916206.652, thread 0xf8000412f000: >> >> > g_resize_provider_event but withered >> >> > cpuid = 0 >> >> > Panic occurred in module kernel loaded at 0x8020: >> >> > >> >> > 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. >> >> >> >> This one is related to r302087 :) >> > >> > It looks like there is a race. I think we need to replace the KASSERT >> > in g_resize_provider_event() with a return in case the provider is >> > withered. >> > >> > I won't be able to work on or test this until sometime next week. So if >> > you guys want to go ahead and make the change, please do. >> >> But why are we calling g_resize_provider on a withered object? That's >> the part I don't understand in this thread. > > It isn't withered when the event is queued, but it is withered by the time > the event is executed. > > There is a check in g_resize_provider() to make sure it isn't withered. If > not, the event is queued. But once g_resize_provider_event() runs, it is > withered and we run into the KASSERT. > > There isn't adequate locking and ordering in there to prevent the race > from happening, so the assert should be replaced with an "if (withered) > return" statement. I'll grant that we may wither with outstanding events, but why is it withering? That seems odd. Either we're bogusly posting this event just before it will wither, or something else is bogusly withering it. Just removing the assert isn't going to fix the underlying issue. Back to Bryan: just to be clear, this is with the latest version of the code, and not the intermediate version that was fixed after numerous problems surfaced, right? Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r303019 - head/sys/geom
On Fri, Aug 12, 2016 at 09:13:58 -0600, Warner Losh wrote: > On Fri, Aug 12, 2016 at 9:11 AM, Kenneth D. Merry wrote: > > On Fri, Aug 12, 2016 at 13:38:21 +0300, Andrey V. Elsukov wrote: > >> On 12.08.16 03:26, Bryan Drewery wrote: > >> > On r303467 I ran into this: > >> > > >> > panic @ time 1470916206.652, thread 0xf8000412f000: > >> > g_resize_provider_event but withered > >> > cpuid = 0 > >> > Panic occurred in module kernel loaded at 0x8020: > >> > > >> > 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. > >> > >> This one is related to r302087 :) > > > > It looks like there is a race. I think we need to replace the KASSERT > > in g_resize_provider_event() with a return in case the provider is > > withered. > > > > I won't be able to work on or test this until sometime next week. So if > > you guys want to go ahead and make the change, please do. > > But why are we calling g_resize_provider on a withered object? That's > the part I don't understand in this thread. It isn't withered when the event is queued, but it is withered by the time the event is executed. There is a check in g_resize_provider() to make sure it isn't withered. If not, the event is queued. But once g_resize_provider_event() runs, it is withered and we run into the KASSERT. There isn't adequate locking and ordering in there to prevent the race from happening, so the assert should be replaced with an "if (withered) return" statement. Ken -- Kenneth Merry k...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r303019 - head/sys/geom
On Fri, Aug 12, 2016 at 9:11 AM, Kenneth D. Merry wrote: > On Fri, Aug 12, 2016 at 13:38:21 +0300, Andrey V. Elsukov wrote: >> On 12.08.16 03:26, Bryan Drewery wrote: >> > On r303467 I ran into this: >> > >> > panic @ time 1470916206.652, thread 0xf8000412f000: >> > g_resize_provider_event but withered >> > cpuid = 0 >> > Panic occurred in module kernel loaded at 0x8020: >> > >> > 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. >> >> This one is related to r302087 :) > > It looks like there is a race. I think we need to replace the KASSERT > in g_resize_provider_event() with a return in case the provider is > withered. > > I won't be able to work on or test this until sometime next week. So if > you guys want to go ahead and make the change, please do. But why are we calling g_resize_provider on a withered object? That's the part I don't understand in this thread. Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r303019 - head/sys/geom
On Fri, Aug 12, 2016 at 13:38:21 +0300, Andrey V. Elsukov wrote: > On 12.08.16 03:26, Bryan Drewery wrote: > > On r303467 I ran into this: > > > > panic @ time 1470916206.652, thread 0xf8000412f000: > > g_resize_provider_event but withered > > cpuid = 0 > > Panic occurred in module kernel loaded at 0x8020: > > > > 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. > > This one is related to r302087 :) It looks like there is a race. I think we need to replace the KASSERT in g_resize_provider_event() with a return in case the provider is withered. I won't be able to work on or test this until sometime next week. So if you guys want to go ahead and make the change, please do. Ken -- Kenneth Merry k...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r303019 - head/sys/geom
On 12.08.16 03:26, Bryan Drewery wrote: > On r303467 I ran into this: > > panic @ time 1470916206.652, thread 0xf8000412f000: > g_resize_provider_event but withered > cpuid = 0 > Panic occurred in module kernel loaded at 0x8020: > > 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. This one is related to r302087 :) -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: svn commit: r303019 - head/sys/geom
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:0x80740005 >>> stack pointer = 0x28:0xfe01f119db10 >>> frame pointer = 0x28:0xfe01f119db30 >>> code segment= base 0x0, limit 0xf, 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 0xf8000426fa00 >>> g_part_resize() at g_part_resize+0x35/frame 0xfe01f119db30 >>> g_resize_provider_event() at g_resize_provider_event+0xb5/frame >>> 0xfe01f119d0 g_run_events() at g_run_events+0x20e/frame >>> 0xfe01f119dbb0 >>> .. >>> >>> 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 0xf8000412f000: > g_resize_provider_event but withered > cpuid = 0 > Panic occurred in module kernel loaded at 0x8020: > > 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: 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: 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^M^M (da13:da18 at mps0 bus 0 scbus0 target 12 lun 0^M^M mps0:0:da18: 14: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:0): s/n JPW9K0N00LTB4LPeriph destroyed^M^M detached^M^M da17 at mps0 bus 0 scbus0 target 10 lun 0^M^M da17: s/n JPW9K0N00JZESL detached^M^M da20 at mps0 bus 0 scbus0 target 16 lun 0^M^M da20: s/n JPW9K0N00K2PEL detached^M^M panic @ time 1470916206.652, thread 0xf8000412f000: g_resize_provider_event but withered^M^M ... -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: svn commit: r303019 - head/sys/geom
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:0x80740005 >> stack pointer= 0x28:0xfe01f119db10 >> frame pointer= 0x28:0xfe01f119db30 >> code segment = base 0x0, limit 0xf, 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 0xf8000426fa00 >> g_part_resize() at g_part_resize+0x35/frame 0xfe01f119db30 >> g_resize_provider_event() at g_resize_provider_event+0xb5/frame >> 0xfe01f119d0 g_run_events() at g_run_events+0x20e/frame >> 0xfe01f119dbb0 >> .. >> >> 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 0xf8000412f000: g_resize_provider_event but withered cpuid = 0 Panic occurred in module kernel loaded at 0x8020: 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
Re: svn commit: r303019 - head/sys/geom
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:0x80740005 > stack pointer = 0x28:0xfe01f119db10 > frame pointer = 0x28:0xfe01f119db30 > code segment = base 0x0, limit 0xf, 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 0xf8000426fa00 > g_part_resize() at g_part_resize+0x35/frame 0xfe01f119db30 > g_resize_provider_event() at g_resize_provider_event+0xb5/frame > 0xfe01f119d0 g_run_events() at g_run_events+0x20e/frame > 0xfe01f119dbb0 > .. > > 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. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: svn commit: r303019 - head/sys/geom
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:0x80740005 stack pointer = 0x28:0xfe01f119db10 frame pointer = 0x28:0xfe01f119db30 code segment= base 0x0, limit 0xf, 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 0xf8000426fa00 g_part_resize() at g_part_resize+0x35/frame 0xfe01f119db30 g_resize_provider_event() at g_resize_provider_event+0xb5/frame 0xfe01f119d0 g_run_events() at g_run_events+0x20e/frame 0xfe01f119dbb0 .. 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? At the very least, please reconsider having this MFC'ed without getting to the bottom of it. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: svn commit: r303019 - head/sys/geom
Thanks! On Tue, Jul 19, 2016 at 1:36 PM, 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. > > PR: 211028 > Reported by: Dexuan Cui > MFC after:3 weeks > > Modified: > head/sys/geom/geom_disk.c > > Modified: head/sys/geom/geom_disk.c > == > --- head/sys/geom/geom_disk.c Tue Jul 19 04:56:59 2016(r303018) > +++ head/sys/geom/geom_disk.c Tue Jul 19 05:36:21 2016(r303019) > @@ -126,7 +126,6 @@ g_disk_access(struct g_provider *pp, int > if (error != 0) > return (error); > } > - pp->mediasize = dp->d_mediasize; > pp->sectorsize = dp->d_sectorsize; > if (dp->d_maxsize == 0) { > printf("WARNING: Disk drive %s%d has no d_maxsize\n", > @@ -143,6 +142,7 @@ g_disk_access(struct g_provider *pp, int > pp->stripeoffset = dp->d_stripeoffset; > pp->stripesize = dp->d_stripesize; > dp->d_flags |= DISKFLAG_OPEN; > + g_resize_provider(pp, dp->d_mediasize); > } else if ((pp->acr + pp->acw + pp->ace) > 0 && (r + w + e) == 0) { > if (dp->d_close != NULL) { > error = dp->d_close(dp); > ___ > svn-src-all@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-all > To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org" -- Tomorrow Will Never Die ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r303019 - head/sys/geom
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. PR: 211028 Reported by: Dexuan Cui MFC after:3 weeks Modified: head/sys/geom/geom_disk.c Modified: head/sys/geom/geom_disk.c == --- head/sys/geom/geom_disk.c Tue Jul 19 04:56:59 2016(r303018) +++ head/sys/geom/geom_disk.c Tue Jul 19 05:36:21 2016(r303019) @@ -126,7 +126,6 @@ g_disk_access(struct g_provider *pp, int if (error != 0) return (error); } - pp->mediasize = dp->d_mediasize; pp->sectorsize = dp->d_sectorsize; if (dp->d_maxsize == 0) { printf("WARNING: Disk drive %s%d has no d_maxsize\n", @@ -143,6 +142,7 @@ g_disk_access(struct g_provider *pp, int pp->stripeoffset = dp->d_stripeoffset; pp->stripesize = dp->d_stripesize; dp->d_flags |= DISKFLAG_OPEN; + g_resize_provider(pp, dp->d_mediasize); } else if ((pp->acr + pp->acw + pp->ace) > 0 && (r + w + e) == 0) { if (dp->d_close != NULL) { error = dp->d_close(dp); ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"