Re: repeatable panic on pageout with 945GM
On 06/04/16 15:02, Konstantin Belousov wrote: > On Sat, Jun 04, 2016 at 02:59:01PM -0400, Michael Butler wrote: >> On 06/04/16 13:47, Konstantin Belousov wrote: >> >> [ .. snip .. ] >> >>> I believe that this is a bug in amd64 pmap. Fictitious pages are not >>> promoted, in particular, the pv_table array does not span over the >>> dynamically registered fictitious ranges. As result, pa_to_pvh() returns >>> garbage and pvh must not be accessed in the case of 'small_mappings' in >>> several pmap functions. It is typically not accessed, except in case >>> when we have to drop and reacquire pv lock, to avoid LOR with pmap. >>> >>> i386 does not have the issue, due to pvh_global_lock. >>> >>> Below is the supposed fix (not tested). >> >> [ .. snip .. ] >> >> Is this something I should test and, should it not introduce any other >> issues, might get committed? > > Would be nice to test. I expect that this patch is going to be committed, > after the review. Now heading into the 5th day of panic-free operation using your patch with the previous band-aid removed - thanks! :-) imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: repeatable panic on pageout with 945GM
On 06/04/16 15:02, Konstantin Belousov wrote: > On Sat, Jun 04, 2016 at 02:59:01PM -0400, Michael Butler wrote: >> On 06/04/16 13:47, Konstantin Belousov wrote: >> >> [ .. snip .. ] >> >>> I believe that this is a bug in amd64 pmap. Fictitious pages are not >>> promoted, in particular, the pv_table array does not span over the >>> dynamically registered fictitious ranges. As result, pa_to_pvh() returns >>> garbage and pvh must not be accessed in the case of 'small_mappings' in >>> several pmap functions. It is typically not accessed, except in case >>> when we have to drop and reacquire pv lock, to avoid LOR with pmap. >>> >>> i386 does not have the issue, due to pvh_global_lock. >>> >>> Below is the supposed fix (not tested). >> >> [ .. snip .. ] >> >> Is this something I should test and, should it not introduce any other >> issues, might get committed? > > Would be nice to test. I expect that this patch is going to be committed, > after the review. > I will do so this evening and add a kprintf to the previous band-aid to see if it prevents the problematic condition from occurring. If it counts, my test laptop has a Core-2 Duo so it is entirely possible that multiple threads are running concurrently, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: repeatable panic on pageout with 945GM
On Sat, Jun 04, 2016 at 02:59:01PM -0400, Michael Butler wrote: > On 06/04/16 13:47, Konstantin Belousov wrote: > > [ .. snip .. ] > > > I believe that this is a bug in amd64 pmap. Fictitious pages are not > > promoted, in particular, the pv_table array does not span over the > > dynamically registered fictitious ranges. As result, pa_to_pvh() returns > > garbage and pvh must not be accessed in the case of 'small_mappings' in > > several pmap functions. It is typically not accessed, except in case > > when we have to drop and reacquire pv lock, to avoid LOR with pmap. > > > > i386 does not have the issue, due to pvh_global_lock. > > > > Below is the supposed fix (not tested). > > [ .. snip .. ] > > Is this something I should test and, should it not introduce any other > issues, might get committed? Would be nice to test. I expect that this patch is going to be committed, after the review. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: repeatable panic on pageout with 945GM
On 06/04/16 13:47, Konstantin Belousov wrote: [ .. snip .. ] > I believe that this is a bug in amd64 pmap. Fictitious pages are not > promoted, in particular, the pv_table array does not span over the > dynamically registered fictitious ranges. As result, pa_to_pvh() returns > garbage and pvh must not be accessed in the case of 'small_mappings' in > several pmap functions. It is typically not accessed, except in case > when we have to drop and reacquire pv lock, to avoid LOR with pmap. > > i386 does not have the issue, due to pvh_global_lock. > > Below is the supposed fix (not tested). [ .. snip .. ] Is this something I should test and, should it not introduce any other issues, might get committed? imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: repeatable panic on pageout with 945GM
>
> I believe that this is a bug in amd64 pmap. Fictitious pages are not
> promoted, in particular, the pv_table array does not span over the
> dynamically registered fictitious ranges. As result, pa_to_pvh() returns
> garbage and pvh must not be accessed in the case of 'small_mappings' in
> several pmap functions. It is typically not accessed, except in case
> when we have to drop and reacquire pv lock, to avoid LOR with pmap.
Cool. Thanks for explaining that.
-M
> i386 does not have the issue, due to pvh_global_lock.
>
> Below is the supposed fix (not tested).
>
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 7a93e76..e514b07 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -3947,12 +3947,14 @@ small_mappings:
> while ((pv = TAILQ_FIRST(&m->md.pv_list)) != NULL) {
> pmap = PV_PMAP(pv);
> if (!PMAP_TRYLOCK(pmap)) {
> -pvh_gen = pvh->pv_gen;
> +if ((m->flags & PG_FICTITIOUS) == 0)
> +pvh_gen = pvh->pv_gen;
> md_gen = m->md.pv_gen;
> rw_wunlock(lock);
> PMAP_LOCK(pmap);
> rw_wlock(lock);
> -if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) {
> +if (((m->flags & PG_FICTITIOUS) == 0 &&
> +pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) {
> rw_wunlock(lock);
> PMAP_UNLOCK(pmap);
> goto retry;
> @@ -5775,13 +5777,14 @@ small_mappings:
> TAILQ_FOREACH(pv, &m->md.pv_list, pv_next) {
> pmap = PV_PMAP(pv);
> if (!PMAP_TRYLOCK(pmap)) {
> -pvh_gen = pvh->pv_gen;
> +if ((m->flags & PG_FICTITIOUS) == 0)
> +pvh_gen = pvh->pv_gen;
> md_gen = m->md.pv_gen;
> rw_wunlock(lock);
> PMAP_LOCK(pmap);
> rw_wlock(lock);
> -if (pvh_gen != pvh->pv_gen ||
> -md_gen != m->md.pv_gen) {
> +if (((m->flags & PG_FICTITIOUS) == 0 &&
> +pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) {
> PMAP_UNLOCK(pmap);
> rw_wunlock(lock);
> goto retry_pv_loop;
> @@ -5985,12 +5988,14 @@ small_mappings:
> pvf = pv;
> pmap = PV_PMAP(pv);
> if (!PMAP_TRYLOCK(pmap)) {
> -pvh_gen = pvh->pv_gen;
> +if ((m->flags & PG_FICTITIOUS) == 0)
> +pvh_gen = pvh->pv_gen;
> md_gen = m->md.pv_gen;
> rw_wunlock(lock);
> PMAP_LOCK(pmap);
> rw_wlock(lock);
> -if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) {
> +if (((m->flags & PG_FICTITIOUS) == 0 &&
> +pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) {
> PMAP_UNLOCK(pmap);
> goto retry;
> }
> @@ -6248,11 +6253,13 @@ small_mappings:
> pmap = PV_PMAP(pv);
> if (!PMAP_TRYLOCK(pmap)) {
> md_gen = m->md.pv_gen;
> -pvh_gen = pvh->pv_gen;
> +if ((m->flags & PG_FICTITIOUS) == 0)
> +pvh_gen = pvh->pv_gen;
> rw_wunlock(lock);
> PMAP_LOCK(pmap);
> rw_wlock(lock);
> -if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) {
> +if (((m->flags & PG_FICTITIOUS) == 0 &&
> +pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) {
> PMAP_UNLOCK(pmap);
> goto restart;
> }
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: repeatable panic on pageout with 945GM
On Sat, Jun 04, 2016 at 10:02:33AM -0700, Matthew Macy wrote:
>
>
>
>
> >
> > This "band-aid" seems to have worked. I haven't had a single panic since
> > - Thanks! :-)
> >
> > I tried to compile with -O0 but, for some reason, it panics in the sound
> > driver with a double-fault. When I get time, I'll recompile only the
> > files involved and see if I can't get a decent trace (and dump) to
> > identify the cause,
>
> No need. Based on the line that it crashed at, the problem is that with no
> mappings no pv_entry has been allocated. Somehow on your laptop you're able
> to get in to a situation where fictitious pages have been added to the object
> that don't get mapped. This isn't a strange situation in and of itself, but
> you seem to be the only hitting this.
>
> In any event, the DRM 4.6 port will support AGP in about a week. It will
> probably have bugs, but this one isn't in any of its code paths.
>
>
> I'm glad your system works a bit better now.
>
I believe that this is a bug in amd64 pmap. Fictitious pages are not
promoted, in particular, the pv_table array does not span over the
dynamically registered fictitious ranges. As result, pa_to_pvh() returns
garbage and pvh must not be accessed in the case of 'small_mappings' in
several pmap functions. It is typically not accessed, except in case
when we have to drop and reacquire pv lock, to avoid LOR with pmap.
i386 does not have the issue, due to pvh_global_lock.
Below is the supposed fix (not tested).
diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 7a93e76..e514b07 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -3947,12 +3947,14 @@ small_mappings:
while ((pv = TAILQ_FIRST(&m->md.pv_list)) != NULL) {
pmap = PV_PMAP(pv);
if (!PMAP_TRYLOCK(pmap)) {
- pvh_gen = pvh->pv_gen;
+ if ((m->flags & PG_FICTITIOUS) == 0)
+ pvh_gen = pvh->pv_gen;
md_gen = m->md.pv_gen;
rw_wunlock(lock);
PMAP_LOCK(pmap);
rw_wlock(lock);
- if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) {
+ if (((m->flags & PG_FICTITIOUS) == 0 &&
+ pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) {
rw_wunlock(lock);
PMAP_UNLOCK(pmap);
goto retry;
@@ -5775,13 +5777,14 @@ small_mappings:
TAILQ_FOREACH(pv, &m->md.pv_list, pv_next) {
pmap = PV_PMAP(pv);
if (!PMAP_TRYLOCK(pmap)) {
- pvh_gen = pvh->pv_gen;
+ if ((m->flags & PG_FICTITIOUS) == 0)
+ pvh_gen = pvh->pv_gen;
md_gen = m->md.pv_gen;
rw_wunlock(lock);
PMAP_LOCK(pmap);
rw_wlock(lock);
- if (pvh_gen != pvh->pv_gen ||
- md_gen != m->md.pv_gen) {
+ if (((m->flags & PG_FICTITIOUS) == 0 &&
+ pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) {
PMAP_UNLOCK(pmap);
rw_wunlock(lock);
goto retry_pv_loop;
@@ -5985,12 +5988,14 @@ small_mappings:
pvf = pv;
pmap = PV_PMAP(pv);
if (!PMAP_TRYLOCK(pmap)) {
- pvh_gen = pvh->pv_gen;
+ if ((m->flags & PG_FICTITIOUS) == 0)
+ pvh_gen = pvh->pv_gen;
md_gen = m->md.pv_gen;
rw_wunlock(lock);
PMAP_LOCK(pmap);
rw_wlock(lock);
- if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) {
+ if (((m->flags & PG_FICTITIOUS) == 0 &&
+ pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) {
PMAP_UNLOCK(pmap);
goto retry;
}
@@ -6248,11 +6253,13 @@ small_mappings:
pmap = PV_PMAP(pv);
if (!PMAP_TRYLOCK(pmap)) {
md_gen = m->md.pv_gen;
- pvh_gen = pvh->pv_gen;
+ if ((m->flags & PG_FICTITIOUS) == 0)
+ pvh_gen = pvh->pv_gen;
rw_wunlock(lock);
PMAP_LOCK(pmap);
rw_wlock(lock);
- if (pvh_gen != pvh->pv_gen || md_gen != m->md.pv_gen) {
+ if (((m->flags & PG_FICTITIOUS) == 0 &&
+ pvh_gen != pvh->pv_gen) || md_gen != m->md.pv_gen) {
Re: repeatable panic on pageout with 945GM
> > This "band-aid" seems to have worked. I haven't had a single panic since > - Thanks! :-) > > I tried to compile with -O0 but, for some reason, it panics in the sound > driver with a double-fault. When I get time, I'll recompile only the > files involved and see if I can't get a decent trace (and dump) to > identify the cause, No need. Based on the line that it crashed at, the problem is that with no mappings no pv_entry has been allocated. Somehow on your laptop you're able to get in to a situation where fictitious pages have been added to the object that don't get mapped. This isn't a strange situation in and of itself, but you seem to be the only hitting this. In any event, the DRM 4.6 port will support AGP in about a week. It will probably have bugs, but this one isn't in any of its code paths. I'm glad your system works a bit better now. Cheers. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: repeatable panic on pageout with 945GM
On 06/02/16 22:31, Matthew Macy wrote:
> Tell me if that makes any difference.
>
> -M
>
>
> On Thu, 02 Jun 2016 16:55:53 -0700 K. Macy wrote
>
> > It looks like it might be trying to remove mappings for a page that
> doesn't
> > have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem
> > release mmap. Compile the kernel and driver with -O0 and look at the page.
> > It's too bad I don't support AGP yet with DRM 4.6. Maybe in a week or two.
>
>
>
> diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c
> index 013f0d5..917ece7 100644
> --- a/sys/vm/device_pager.c
> +++ b/sys/vm/device_pager.c
> @@ -211,7 +211,8 @@ cdev_pager_free_page(vm_object_t object, vm_page_t m)
> VM_OBJECT_ASSERT_WLOCKED(object);
> if (object->type == OBJT_MGTDEVICE) {
> KASSERT((m->oflags & VPO_UNMANAGED) == 0, ("unmanaged %p",
> m));
> - pmap_remove_all(m);
> + if (pmap_page_is_mapped(page))
> + pmap_remove_all(m);
> vm_page_lock(m);
> vm_page_remove(m);
> vm_page_unlock(m);
>
This "band-aid" seems to have worked. I haven't had a single panic since
- Thanks! :-)
I tried to compile with -O0 but, for some reason, it panics in the sound
driver with a double-fault. When I get time, I'll recompile only the
files involved and see if I can't get a decent trace (and dump) to
identify the cause,
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: repeatable panic on pageout with 945GM
> > Slight variation -won't build as above; trying with "pmap_page_is_mapped(m)" > Oops copy pasta + serious fatigue. But you got the right idea. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: repeatable panic on pageout with 945GM
On 06/02/16 22:31, Matthew Macy wrote:
> Tell me if that makes any difference.
>
> -M
>
>
> On Thu, 02 Jun 2016 16:55:53 -0700 K. Macy wrote
>
> > It looks like it might be trying to remove mappings for a page that
> doesn't
> > have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem
> > release mmap. Compile the kernel and driver with -O0 and look at the page.
> > It's too bad I don't support AGP yet with DRM 4.6. Maybe in a week or two.
>
>
>
> diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c
> index 013f0d5..917ece7 100644
> --- a/sys/vm/device_pager.c
> +++ b/sys/vm/device_pager.c
> @@ -211,7 +211,8 @@ cdev_pager_free_page(vm_object_t object, vm_page_t m)
> VM_OBJECT_ASSERT_WLOCKED(object);
> if (object->type == OBJT_MGTDEVICE) {
> KASSERT((m->oflags & VPO_UNMANAGED) == 0, ("unmanaged %p",
> m));
> - pmap_remove_all(m);
> + if (pmap_page_is_mapped(page))
> + pmap_remove_all(m);
> vm_page_lock(m);
> vm_page_remove(m);
> vm_page_unlock(m);
Slight variation -won't build as above; trying with "pmap_page_is_mapped(m)"
imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: repeatable panic on pageout with 945GM
Tell me if that makes any difference.
-M
On Thu, 02 Jun 2016 16:55:53 -0700 K. Macy wrote
> It looks like it might be trying to remove mappings for a page that doesn't
> have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem
> release mmap. Compile the kernel and driver with -O0 and look at the page.
> It's too bad I don't support AGP yet with DRM 4.6. Maybe in a week or two.
diff --git a/sys/vm/device_pager.c b/sys/vm/device_pager.c
index 013f0d5..917ece7 100644
--- a/sys/vm/device_pager.c
+++ b/sys/vm/device_pager.c
@@ -211,7 +211,8 @@ cdev_pager_free_page(vm_object_t object, vm_page_t m)
VM_OBJECT_ASSERT_WLOCKED(object);
if (object->type == OBJT_MGTDEVICE) {
KASSERT((m->oflags & VPO_UNMANAGED) == 0, ("unmanaged %p", m));
- pmap_remove_all(m);
+ if (pmap_page_is_mapped(page))
+ pmap_remove_all(m);
vm_page_lock(m);
vm_page_remove(m);
vm_page_unlock(m);
>
> -M
>
> On Thursday, June 2, 2016, Michael Butler
> wrote:
>
> > On 05/23/16 21:10, Michael Butler wrote:
> > > On 05/22/16 09:58, Michael Butler wrote:
> > >> With KDE and compositing enabled, I randomly get the following:
> > >>
> > >> (kgdb) info stack
> > >> #0 doadump (textdump=) at pcpu.h:221
> > >> #1 0x8064e98e in kern_reboot (howto=260) at
> > >> /usr/src/sys/kern/kern_shutdown.c:366
> > >> #2 0x8064eea1 in vpanic (fmt=, ap= > >> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759
> > >> #3 0x8064ed13 in panic (fmt=0x0) at
> > >> /usr/src/sys/kern/kern_shutdown.c:690
> > >> #4 0x809d18ed in vm_fault_hold (map=,
> > >> vaddr=, fault_type=,
> > >> fault_flags=, m_hold=) at
> > >> /usr/src/sys/vm/vm_fault.c:327
> > >> #5 0x809cf548 in vm_fault (map=0xf8000200,
> > >> vaddr= > >> optimized out>, fault_type=1 '\001', fault_flags=)
> > >> at /usr/src/sys/vm/vm_fault.c:273
> > >> #6 0x80a1849f in trap_pfault (frame=,
> > >> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741
> > >> #7 0x80a17b30 in trap (frame=0xfe00dbec5830) at
> > >> /usr/src/sys/amd64/amd64/trap.c:442
> > >> #8 0x809fd5a1 in calltrap () at
> > >> /usr/src/sys/amd64/amd64/exception.S:236
> > >> #9 0x80a0a3bb in pmap_remove_all (m=) at
> > >> /usr/src/sys/amd64/amd64/pmap.c:3950
> > >> #10 0x809c0c57 in cdev_pager_free_page (object= > >> out>, m=0xfe0001e410d0) at /usr/src/sys/vm/device_pager.c:214
> > >> #11 0x816aff33 in i915_gem_release_mmap (obj= >
> > [ .. snip .. ]
> >
> > Even with the most recent mesa update - something is upsetting this
> > device :-(
> >
> > (kgdb) bt
> > #0 doadump (textdump=) at pcpu.h:221
> > #1 0x805cfe9a in kern_reboot (howto=260) at
> > /usr/src/sys/kern/kern_shutdown.c:366
> > #2 0x805d03e1 in vpanic (fmt=, ap= > optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759
> > #3 0x805d0253 in panic (fmt=0x0) at
> > /usr/src/sys/kern/kern_shutdown.c:690
> > #4 0x8096c56e in vm_fault_hold (map=,
> > vaddr=, fault_type=,
> > fault_flags=, m_hold=) at
> > /usr/src/sys/vm/vm_fault.c:327
> > #5 0x80969f78 in vm_fault (map=0xf8000200, vaddr= > optimized out>, fault_type=1 '\001', fault_flags=)
> > at /usr/src/sys/vm/vm_fault.c:273
> > #6 0x809b556f in trap_pfault (frame=,
> > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741
> > #7 0x809b4c00 in trap (frame=0xfe00dc0ef310) at
> > /usr/src/sys/amd64/amd64/trap.c:442
> > #8 0x80999d81 in calltrap () at
> > /usr/src/sys/amd64/amd64/exception.S:236
> > #9 0x809a6d4e in pmap_remove_all (m=) at
> > /usr/src/sys/amd64/amd64/pmap.c:3950
> > #10 0x8095ab7b in cdev_pager_free_page (object= > out>, m=0xfe0001e2c270) at /usr/src/sys/vm/device_pager.c:214
> > #11 0x816aff33 in i915_gem_release_mmap (obj= > out>) at
> > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1691
> > #12 0x816b15ba in i915_gem_object_get_fence (obj= > optimized out>) at
> > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:105
> > #13 0x816b7f2e in i915_gem_execbuffer_reserve_object
> > (obj=0xf8009858f200, ring=)
> > at
> >
> > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:368
> >
> > #14 0x816b7d8f in i915_gem_execbuffer_reserve () at
> >
> > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:491
> >
> > #15 0x816b6bb5 in i915_gem_do_execbuffer () at
> >
> > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1036
> >
> > #16 0x816b7ad1 in i915_gem_execbuffer2 (dev=0xf800059e9000,
> > data=0xfff
Re: repeatable panic on pageout with 945GM
It looks like it might be trying to remove mappings for a page that doesn't have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem release mmap. Compile the kernel and driver with -O0 and look at the page. It's too bad I don't support AGP yet with DRM 4.6. Maybe in a week or two. -M On Thursday, June 2, 2016, Michael Butler wrote: > On 05/23/16 21:10, Michael Butler wrote: > > On 05/22/16 09:58, Michael Butler wrote: > >> With KDE and compositing enabled, I randomly get the following: > >> > >> (kgdb) info stack > >> #0 doadump (textdump=) at pcpu.h:221 > >> #1 0x8064e98e in kern_reboot (howto=260) at > >> /usr/src/sys/kern/kern_shutdown.c:366 > >> #2 0x8064eea1 in vpanic (fmt=, ap= >> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759 > >> #3 0x8064ed13 in panic (fmt=0x0) at > >> /usr/src/sys/kern/kern_shutdown.c:690 > >> #4 0x809d18ed in vm_fault_hold (map=, > >> vaddr=, fault_type=, > >> fault_flags=, m_hold=) at > >> /usr/src/sys/vm/vm_fault.c:327 > >> #5 0x809cf548 in vm_fault (map=0xf8000200, vaddr= >> optimized out>, fault_type=1 '\001', fault_flags=) > >> at /usr/src/sys/vm/vm_fault.c:273 > >> #6 0x80a1849f in trap_pfault (frame=, > >> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741 > >> #7 0x80a17b30 in trap (frame=0xfe00dbec5830) at > >> /usr/src/sys/amd64/amd64/trap.c:442 > >> #8 0x809fd5a1 in calltrap () at > >> /usr/src/sys/amd64/amd64/exception.S:236 > >> #9 0x80a0a3bb in pmap_remove_all (m=) at > >> /usr/src/sys/amd64/amd64/pmap.c:3950 > >> #10 0x809c0c57 in cdev_pager_free_page (object= >> out>, m=0xfe0001e410d0) at /usr/src/sys/vm/device_pager.c:214 > >> #11 0x816aff33 in i915_gem_release_mmap (obj= > [ .. snip .. ] > > Even with the most recent mesa update - something is upsetting this > device :-( > > (kgdb) bt > #0 doadump (textdump=) at pcpu.h:221 > #1 0x805cfe9a in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:366 > #2 0x805d03e1 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759 > #3 0x805d0253 in panic (fmt=0x0) at > /usr/src/sys/kern/kern_shutdown.c:690 > #4 0x8096c56e in vm_fault_hold (map=, > vaddr=, fault_type=, > fault_flags=, m_hold=) at > /usr/src/sys/vm/vm_fault.c:327 > #5 0x80969f78 in vm_fault (map=0xf8000200, vaddr= optimized out>, fault_type=1 '\001', fault_flags=) > at /usr/src/sys/vm/vm_fault.c:273 > #6 0x809b556f in trap_pfault (frame=, > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741 > #7 0x809b4c00 in trap (frame=0xfe00dc0ef310) at > /usr/src/sys/amd64/amd64/trap.c:442 > #8 0x80999d81 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:236 > #9 0x809a6d4e in pmap_remove_all (m=) at > /usr/src/sys/amd64/amd64/pmap.c:3950 > #10 0x8095ab7b in cdev_pager_free_page (object= out>, m=0xfe0001e2c270) at /usr/src/sys/vm/device_pager.c:214 > #11 0x816aff33 in i915_gem_release_mmap (obj= out>) at > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1691 > #12 0x816b15ba in i915_gem_object_get_fence (obj= optimized out>) at > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:105 > #13 0x816b7f2e in i915_gem_execbuffer_reserve_object > (obj=0xf8009858f200, ring=) > at > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:368 > #14 0x816b7d8f in i915_gem_execbuffer_reserve () at > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:491 > #15 0x816b6bb5 in i915_gem_do_execbuffer () at > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1036 > #16 0x816b7ad1 in i915_gem_execbuffer2 (dev=0xf800059e9000, > data=0xfe00dc0efa20, file=0xf80005db4a00) > at > > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1273 > #17 0x812c7eae in drm_ioctl (kdev=, > cmd=, data=0xfe00dc0efa20 "", flags= optimized out>, > p=) at > /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:467 > #18 0x804c721f in devfs_ioctl_f (fp=0xf800afba1550, > com=2151703657, data=0xfe00dc0efa20, cred=0xf800af2dc800, > td=0xf80005e2ca00) > at /usr/src/sys/fs/devfs/devfs_vnops.c:815 > #19 0x806377fe in kern_ioctl (td=, > fd=, com=, > data=0xfe00dc0efa20 "") at file.h:327 > #20 0x80637481 in sys_ioctl (td=0xf80005e2ca00, > uap=0xfe00dc0efb80) at /usr/src/sys/kern/sys_generic.c:743 > #21 0x809b5e79 in amd64_syscall (td=, > traced=0) at subr_syscall.c:135 > #22 0x8099a06b in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:396 > #23 0x0008024f57ca in ?? () > Previous frame inner to this frame (corrupt stack?) > Current language: auto; currently minimal > > Any hints welcome, > >
Re: repeatable panic on pageout with 945GM
On 05/23/16 21:10, Michael Butler wrote: > On 05/22/16 09:58, Michael Butler wrote: >> With KDE and compositing enabled, I randomly get the following: >> >> (kgdb) info stack >> #0 doadump (textdump=) at pcpu.h:221 >> #1 0x8064e98e in kern_reboot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:366 >> #2 0x8064eea1 in vpanic (fmt=, ap=> optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759 >> #3 0x8064ed13 in panic (fmt=0x0) at >> /usr/src/sys/kern/kern_shutdown.c:690 >> #4 0x809d18ed in vm_fault_hold (map=, >> vaddr=, fault_type=, >> fault_flags=, m_hold=) at >> /usr/src/sys/vm/vm_fault.c:327 >> #5 0x809cf548 in vm_fault (map=0xf8000200, vaddr=> optimized out>, fault_type=1 '\001', fault_flags=) >> at /usr/src/sys/vm/vm_fault.c:273 >> #6 0x80a1849f in trap_pfault (frame=, >> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741 >> #7 0x80a17b30 in trap (frame=0xfe00dbec5830) at >> /usr/src/sys/amd64/amd64/trap.c:442 >> #8 0x809fd5a1 in calltrap () at >> /usr/src/sys/amd64/amd64/exception.S:236 >> #9 0x80a0a3bb in pmap_remove_all (m=) at >> /usr/src/sys/amd64/amd64/pmap.c:3950 >> #10 0x809c0c57 in cdev_pager_free_page (object=> out>, m=0xfe0001e410d0) at /usr/src/sys/vm/device_pager.c:214 >> #11 0x816aff33 in i915_gem_release_mmap (obj=) at pcpu.h:221 #1 0x805cfe9a in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:366 #2 0x805d03e1 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0x805d0253 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:690 #4 0x8096c56e in vm_fault_hold (map=, vaddr=, fault_type=, fault_flags=, m_hold=) at /usr/src/sys/vm/vm_fault.c:327 #5 0x80969f78 in vm_fault (map=0xf8000200, vaddr=, fault_type=1 '\001', fault_flags=) at /usr/src/sys/vm/vm_fault.c:273 #6 0x809b556f in trap_pfault (frame=, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741 #7 0x809b4c00 in trap (frame=0xfe00dc0ef310) at /usr/src/sys/amd64/amd64/trap.c:442 #8 0x80999d81 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #9 0x809a6d4e in pmap_remove_all (m=) at /usr/src/sys/amd64/amd64/pmap.c:3950 #10 0x8095ab7b in cdev_pager_free_page (object=, m=0xfe0001e2c270) at /usr/src/sys/vm/device_pager.c:214 #11 0x816aff33 in i915_gem_release_mmap (obj=) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1691 #12 0x816b15ba in i915_gem_object_get_fence (obj=) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:105 #13 0x816b7f2e in i915_gem_execbuffer_reserve_object (obj=0xf8009858f200, ring=) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:368 #14 0x816b7d8f in i915_gem_execbuffer_reserve () at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:491 #15 0x816b6bb5 in i915_gem_do_execbuffer () at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1036 #16 0x816b7ad1 in i915_gem_execbuffer2 (dev=0xf800059e9000, data=0xfe00dc0efa20, file=0xf80005db4a00) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem_execbuffer.c:1273 #17 0x812c7eae in drm_ioctl (kdev=, cmd=, data=0xfe00dc0efa20 "", flags=, p=) at /usr/src/sys/modules/drm2/drm2/../../../dev/drm2/drm_drv.c:467 #18 0x804c721f in devfs_ioctl_f (fp=0xf800afba1550, com=2151703657, data=0xfe00dc0efa20, cred=0xf800af2dc800, td=0xf80005e2ca00) at /usr/src/sys/fs/devfs/devfs_vnops.c:815 #19 0x806377fe in kern_ioctl (td=, fd=, com=, data=0xfe00dc0efa20 "") at file.h:327 #20 0x80637481 in sys_ioctl (td=0xf80005e2ca00, uap=0xfe00dc0efb80) at /usr/src/sys/kern/sys_generic.c:743 #21 0x809b5e79 in amd64_syscall (td=, traced=0) at subr_syscall.c:135 #22 0x8099a06b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #23 0x0008024f57ca in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal Any hints welcome, imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: repeatable panic on pageout with 945GM
On 05/22/16 09:58, Michael Butler wrote: > With KDE and compositing enabled, I randomly get the following: > > (kgdb) info stack > #0 doadump (textdump=) at pcpu.h:221 > #1 0x8064e98e in kern_reboot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:366 > #2 0x8064eea1 in vpanic (fmt=, ap= optimized out>) at /usr/src/sys/kern/kern_shutdown.c:759 > #3 0x8064ed13 in panic (fmt=0x0) at > /usr/src/sys/kern/kern_shutdown.c:690 > #4 0x809d18ed in vm_fault_hold (map=, > vaddr=, fault_type=, > fault_flags=, m_hold=) at > /usr/src/sys/vm/vm_fault.c:327 > #5 0x809cf548 in vm_fault (map=0xf8000200, vaddr= optimized out>, fault_type=1 '\001', fault_flags=) > at /usr/src/sys/vm/vm_fault.c:273 > #6 0x80a1849f in trap_pfault (frame=, > usermode=0) at /usr/src/sys/amd64/amd64/trap.c:741 > #7 0x80a17b30 in trap (frame=0xfe00dbec5830) at > /usr/src/sys/amd64/amd64/trap.c:442 > #8 0x809fd5a1 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:236 > #9 0x80a0a3bb in pmap_remove_all (m=) at > /usr/src/sys/amd64/amd64/pmap.c:3950 > #10 0x809c0c57 in cdev_pager_free_page (object= out>, m=0xfe0001e410d0) at /usr/src/sys/vm/device_pager.c:214 > #11 0x816aff33 in i915_gem_release_mmap (obj= out>) at > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1691 > #12 0x816b104b in i915_gem_object_unbind > (obj=0xf8008ef11400) at > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:2738 > #13 0x816b47c8 in __i915_gem_shrink (dev_priv= out>, target=-1, purgeable_only=) > at > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:2056 > #14 0x816b3f47 in i915_gem_inactive_shrink (arg= out>) at > /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:4755 > #15 0x809ec628 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:899 > #16 0x80609dcc in fork_exit (callout=0x809ec260 > , arg=0x0, frame=0xfe00dbec5c00) at > /usr/src/sys/kern/kern_fork.c:1034 > #17 0x809fdade in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:611 > #18 0x in ?? () > > Any hints? Anyone? Another flavour .. almost like there's a mutex that should be held that isn't .. (kgdb) bt #0 0x8064e33f in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:686 #1 0x8064e03e in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:369 #2 0x8064e551 in kproc_shutdown (arg=0x104, howto=) at /usr/src/sys/kern/kern_shutdown.c:811 #3 0x8064e3c3 in vpanic (fmt=0xfe209000 , ap=0xfe00dbf2f180) at /usr/src/sys/kern/kern_shutdown.c:712 #4 0x809d04ed in vm_fault_hold (map=0xf8000200, vaddr=, fault_type=1 '\001', fault_flags=0, m_hold=0x0) at /usr/src/sys/vm/vm_fault.c:208 #5 0x809ce148 in mtrash_ctor (mem=, size=, arg=, flags=) at /usr/src/sys/vm/uma_dbg.c:143 #6 0x80a1709f in trap_fatal (frame=0x1, eva=18446735277650083840) at /usr/src/sys/amd64/amd64/trap.c:830 #7 0x80a16730 in trap (frame=0xfe00dbf2f570) at /usr/src/sys/amd64/amd64/trap.c:215 #8 0x809fc1a1 in Xxmm () at /usr/src/sys/amd64/amd64/exception.S:145 #9 0x80a08fbb in pmap_remove_all (m=) at atomic.h:186 #10 0x809bf937 in cdev_pager_allocate (handle=, tp=, ops=, size=, prot=, foff=, cred=) at /usr/src/sys/vm/device_pager.c:186 #11 0x816aff33 in i915_gem_release_mmap (obj=) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1691 #12 0x816b15ba in i915_gem_object_get_fence (obj=) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:105 #13 0x816afb32 in i915_gem_pager_fault (vm_obj=0xf8002c501a50, offset=, prot=, mres=) at /usr/src/sys/modules/drm2/i915kms/../../../dev/drm2/i915/i915_gem.c:1553 #14 0x809bf384 in dev_pager_dealloc (object=0xf8002c501a50) at /usr/src/sys/vm/device_pager.c:242 #15 0x809edfbf in vm_pager_bufferinit () at /usr/src/sys/vm/vm_pager.c:201 #16 0x809ce9e9 in vm_fault_hold (map=0xf80093759000, vaddr=, fault_type=2 '\002', fault_flags=0, m_hold=0x0) at pcpu.h:221 #17 0x809ce148 in mtrash_ctor (mem=, size=, arg=, flags=) at /usr/src/sys/vm/uma_dbg.c:143 #18 0x80a1709f in trap_fatal (frame=0x2, eva=18446735280090484736) at /usr/src/sys/amd64/amd64/trap.c:830 #19 0x80a16860 in trap (frame=0xfe00dbf2fc00) at /usr/src/sys/amd64/amd64/trap.c:481 #20 0x809fc1a1 in Xxmm () at /usr/src/sys/amd64/amd64/exception.S:145 #21 0x0008024f33b6 in ?? () Previous frame inner to this frame (corrupt stack?) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
