From owner-freebsd-current@FreeBSD.ORG Mon Jun 23 15:52:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 914CFCDD; Mon, 23 Jun 2014 15:52:22 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0811F264B; Mon, 23 Jun 2014 15:52:22 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 11651B9A3; Mon, 23 Jun 2014 11:52:21 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: ahci panics when detaching... Date: Mon, 23 Jun 2014 10:49:27 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20140623134407.GD31367@funkthat.com> In-Reply-To: <20140623134407.GD31367@funkthat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201406231049.27909.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 23 Jun 2014 11:52:21 -0400 (EDT) Cc: John-Mark Gurney , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 15:52:22 -0000 On Monday, June 23, 2014 9:44:08 am John-Mark Gurney wrote: > So, when I try to eject a ESATA card, the machine panics... I am able > to successfully eject other cards, an ethernet (re) and a serial card > (uart), and both handle the removal of their device w/o issue and with > out crashes... > > When I try w/ ahci, I get a panic... The panic backtrace is: > #8 0xffffffff80ced4e2 in calltrap () at ../../../amd64/amd64/exception.S:231 > #9 0xffffffff8093d037 in rman_get_rid (r=0xfffff800064c9380) > at ../../../kern/subr_rman.c:979 > #10 0xffffffff8092b888 in resource_list_release_active (rl=0xfffff80006d39c08, > bus=0xfffff80002cd9000, child=0xfffff80006b6d700, type=3) > at ../../../kern/subr_bus.c:3419 > #11 0xffffffff8065d7a1 in pci_child_detached (dev=0xfffff80002cd9000, > child=0xfffff80006b6d700) at ../../../dev/pci/pci.c:4133 > ---Type to continue, or q to quit--- > #12 0xffffffff80929708 in device_detach (dev=0xfffff80006b6d700) > at bus_if.h:181 > #13 0xffffffff8065f9f7 in pci_delete_child (dev=0xfffff80002cd9000, > child=0xfffff80006b6d700) at ../../../dev/pci/pci.c:4710 > > In frame 9: > (kgdb) fr 9 > #9 0xffffffff8093d037 in rman_get_rid (r=0xfffff800064c9380) > at ../../../kern/subr_rman.c:979 > 979 return (r->__r_i->r_rid); > (kgdb) print r > $1 = (struct resource *) 0xfffff800064c9380 > (kgdb) print/x *r > $4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de, > r_bushandle = 0xdeadc0dedeadc0de} > > So, looks like something is corrupted the resource data... This is the malloc junking on free. However, I wonder if the problem is that the resource was freed without being properly cleared from the resource_list in the PCI ivars. Is this with local patches that you have? -- John Baldwin