Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Feb 2005 17:38:08 +0900
From:      Pyun YongHyeon <yongari@kt-is.co.kr>
To:        John Baldwin <jhb@freebsd.org>
Cc:        sparc64@freebsd.org
Subject:   Re: Duplicate mbuf free panic in hme(4)
Message-ID:  <20050202083808.GC8538@kt-is.co.kr>
In-Reply-To: <20050122093954.GA21145@kt-is.co.kr>
References:  <200411301035.12035.jhb@FreeBSD.org> <200411301410.46329.jhb@FreeBSD.org> <20050122093954.GA21145@kt-is.co.kr>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 22, 2005 at 06:39:54PM +0900, To John Baldwin wrote:
 > On Tue, Nov 30, 2004 at 02:10:46PM -0500, John Baldwin wrote:
 >  > On Tuesday 30 November 2004 10:35 am, John Baldwin wrote:
 >  > > I got the following panic on my ultra60 while the box was idle over the
 >  > > holidays:
 >  > >
 >  > > Nov 26 00:20:25 amd[293]: reload of map /etc/amd.map is not needed (in
 >  > > sync) Nov 26 01:24:26 amd[293]: reload of map /etc/amd.map is not needed
 >  > > (in sync) Nov 26 02:28:26 amd[293]: reload of map /etc/amd.map is not
 >  > > needed (in sync) Nov 26 03:32:26 amd[293]: reload of map /etc/amd.map is
 >  > > not needed (in sync) Slab at 0xfffff80085467ed8, freei 2 = 0.
 >  > > panic: Duplicate free of item 0xfffff80085466200 from zone
 >  > > 0xfffff80027ffd5c0 (Mbuf)
 >  > >
 >  > > cpuid = 0
 >  > > KDB: enter: panic
 >  > > [thread 100039]
 >  > > Stopped at      kdb_enter+0x38: ta              %xcc, 1
 >  > > db> tr
 >  > > panic() at panic+0x19c
 >  > > uma_dbg_free() at uma_dbg_free+0x138
 >  > > uma_zfree_arg() at uma_zfree_arg+0x1a4
 >  > > m_freem() at m_freem+0x4c
 >  > > hme_intr() at hme_intr+0x2d0
 >  > > psycho_intr_stub() at psycho_intr_stub+0x8
 >  > > ithread_loop() at ithread_loop+0x218
 >  > > fork_exit() at fork_exit+0x9c
 >  > > fork_trampoline() at fork_trampoline+0x8
 >  > > db>
 >  > >
 >  > > Perhaps this can also explain the memory used after free panics that myself
 >  > > and others see on our sparcs under load?
 >  > 
 > 
 > When I read this mail, I couldn't reproduce this panic. With new
 > ata controller(hpt372) with UDMA100 disk I could easily reproduce
 > this panic. It seems that the panic is occurred under heavy system
 > I/O and the bug survivied for a long time. Anyway, it seems that
 > the following patch fix the issue to me. But it seems that hme(4)
 > now prints "device timeout" messages under heavy loads. That needs
 > more investigation.
 > 

For record, a fix for the panic was committed to HEAD.
"device timeout" message caused by DMA engine freeze is still
under investigation.

-- 
Regards,
Pyun YongHyeon
http://www.kr.freebsd.org/~yongari	|	yongari@freebsd.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050202083808.GC8538>