Re: kern/145211: Memory modified after free
Anton Shterenlikht
From: Anton Shterenlikht <me...@bristol.ac.uk>
To: Nathaniel W Filardo <n...@cs.jhu.edu>, freebs...@freebsd.org
Cc: bug-fo...@freebsd.org
Subject: Re: kern/145211: Memory modified after free
Date: Wed, 31 Mar 2010 20:05:26 +0100
On Wed, Mar 31, 2010 at 06:50:12PM +0000, Nathaniel W Filardo wrote:
> The following reply was made to PR sparc64/145211; it has been noted by GNATS.
>
> From: Nathaniel W Filardo <n...@cs.jhu.edu>
> To: bug-fo...@freebsd.org
> Cc:
> Subject: Re: kern/145211: Memory modified after free
> Date: Wed, 31 Mar 2010 14:49:40 -0400
>
> It occurs to me to add that at least the second crash was correlated with a
> burst of traffic on bge2, which usually sits idle. FWIW, bge0 and bge3 are
> typically busy, and bge1 is not connected. Is it possible that this is a
> bge bug? I'll be recreating the busy-bge2 scenario to test other things
> anyway and will report should it trigger a panic again.
FWIW I've had this twice on ia64 -current.
It also seems to follow bge activity,
but not sure about the "bursts":
http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/tzav/messages
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
Nathaniel W Filardo
From: Nathaniel W Filardo <n...@cs.jhu.edu>
To: bug-fo...@freebsd.org
Cc:
Subject: Re: kern/145211: Memory modified after free
Date: Wed, 31 Mar 2010 14:49:40 -0400
--vDpvzslK0qRw06MN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
It occurs to me to add that at least the second crash was correlated with a
burst of traffic on bge2, which usually sits idle. FWIW, bge0 and bge3 are
typically busy, and bge1 is not connected. Is it possible that this is a
bge bug? I'll be recreating the busy-bge2 scenario to test other things
anyway and will report should it trigger a panic again.
While I'm recovering from filing an underinformative bug report, I'll note
that the machine is a Sun Fire V210 (with 2G of RAM and 2 1GHz CPUs).
Anything else that would help?
--nwf;
--vDpvzslK0qRw06MN
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkuzmUQACgkQTeQabvr9Tc/LkgCcCsjzML2Y64L3dFCpBLt8Wrhz
AjMAoIbbsLVLuxqQOAzHnoPcfv2/h72A
=tU8H
-----END PGP SIGNATURE-----
--vDpvzslK0qRw06MN--
Marius Strobl
From: Marius Strobl <mar...@alchemy.franken.de>
To: bug-fo...@FreeBSD.org, n...@cs.jhu.edu
Cc:
Subject: Re: kern/145211: Memory modified after free
Date: Thu, 1 Apr 2010 13:23:59 +0200
>
> Memory modified after free 0xfffff80005675000(2048) val=dead0003 @ 0xfffff80005675000
> Memory modified after free 0xfffff8000564c800(2048) val=dead0003 @ 0xfffff8000564c800
> panic: pcib: PCI bus B error AFAR 0 AFSR 0 PCI CSR 0x10730b2aff IOMMU 0x3060003 STATUS 0x2a0
This is the IOMMU reporting an error as STX_PCI_CTRL_MMU_ERR is set in
the PCI CSR and TOM_PCI_IOMMU_ERR is set in the IOMMO CSR. Moreover the
TOM_PCI_IOMMU_INVALID_ERR set in the latter suggests that a DMA buffer
was used after it had been unloaded (and thus the TTE invalidated). So
it's quite likely that both the UMA and the IOMMU complaints are caused
by the same problem. Unfortunately, neither allows to identify the
culprit. If you could move the traffic in question from bge2 to bge1
and either use r206020 or the following patch that should allow to
identify at least the driver involved, i.e. ata(4) or bge(4), by
additionally indicating whether pcib0 or pcib3 triggered the panic.
http://people.freebsd.org/~marius/psycho_schizo_device_get_nameunit.diff
Which version of if_bge.c were you running when the panic occurred?
Marius
Nathaniel W Filardo
From: Nathaniel W Filardo <n...@cs.jhu.edu>
To: Marius Strobl <mar...@alchemy.franken.de>
Cc: bug-fo...@freebsd.org
Subject: Re: kern/145211: Memory modified after free
Date: Thu, 1 Apr 2010 11:52:48 -0400
--z20Z95FJiBb6FirT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Thu, Apr 01, 2010 at 01:23:59PM +0200, Marius Strobl wrote:
> This is the IOMMU reporting an error as STX_PCI_CTRL_MMU_ERR is set in
> the PCI CSR and TOM_PCI_IOMMU_ERR is set in the IOMMO CSR. Moreover the
> TOM_PCI_IOMMU_INVALID_ERR set in the latter suggests that a DMA buffer
> was used after it had been unloaded (and thus the TTE invalidated). So
> it's quite likely that both the UMA and the IOMMU complaints are caused
> by the same problem. Unfortunately, neither allows to identify the
Thank you for decoding that for me.
> culprit. If you could move the traffic in question from bge2 to bge1
> and either use r206020 or the following patch that should allow to
> identify at least the driver involved, i.e. ata(4) or bge(4), by
> additionally indicating whether pcib0 or pcib3 triggered the panic.
> http://people.freebsd.org/~marius/psycho_schizo_device_get_nameunit.diff
Just csup'd and am now rebuilding; will let you know.
> Which version of if_bge.c were you running when the panic occurred?
$FreeBSD: src/sys/dev/bge/if_bge.c,v 1.284 2010/03/25 17:17:35 yongari Exp $
--z20Z95FJiBb6FirT
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAku0wVAACgkQTeQabvr9Tc9jgQCeNIHaRTCWFvsZyxIwvS7kqTVY
/XoAniK2Qq/z7NdJK9NrfNN/d+w+//dq
=TzYn
-----END PGP SIGNATURE-----
--z20Z95FJiBb6FirT--