From owner-freebsd-current@FreeBSD.ORG Tue Jun 24 01:06:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6AC9D360; Tue, 24 Jun 2014 01:06:28 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 478DE2A82; Tue, 24 Jun 2014 01:06:28 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s5O16Qhf010381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 18:06:26 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5O16Qi0010380; Mon, 23 Jun 2014 18:06:26 -0700 (PDT) (envelope-from jmg) Date: Mon, 23 Jun 2014 18:06:26 -0700 From: John-Mark Gurney To: John Baldwin Subject: Re: ahci panics when detaching... Message-ID: <20140624010626.GB1560@funkthat.com> Mail-Followup-To: John Baldwin , freebsd-current@freebsd.org References: <20140623134407.GD31367@funkthat.com> <201406231049.27909.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201406231049.27909.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 23 Jun 2014 18:06:27 -0700 (PDT) Cc: freebsd-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: Tue, 24 Jun 2014 01:06:28 -0000 John Baldwin wrote this message on Mon, Jun 23, 2014 at 10:49 -0400: > 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? Yes, but I didn't patch any of the pci code, or the resource code, so this bug is in the original code... My patches only effect the attach case, don't touch the detach case... I was hoping someone who knows the code was like, yeh, I do remeber that place in the code where we free something, but don't properly NULL out the pointer, etc... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."