From owner-freebsd-current@FreeBSD.ORG Mon Jun 23 13:44:09 2014 Return-Path: Delivered-To: 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 81974C61; Mon, 23 Jun 2014 13:44:09 +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 5C9C029EF; Mon, 23 Jun 2014 13:44:09 +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 s5NDi8vK036455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 06:44:08 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s5NDi89u036454; Mon, 23 Jun 2014 06:44:08 -0700 (PDT) (envelope-from jmg) Date: Mon, 23 Jun 2014 06:44:08 -0700 From: John-Mark Gurney To: current@FreeBSD.org Subject: ahci panics when detaching... Message-ID: <20140623134407.GD31367@funkthat.com> Mail-Followup-To: current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 23 Jun 2014 06:44:08 -0700 (PDT) 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 13:44:09 -0000 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... Attach dmesg: atapci0: at device 0.0 on pci2 ahci1: at channel -1 on atapci0 ahci1: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported ahci1: quirks=0x1 ahcich6: at channel 0 on ahci1 ahcich7: at channel 1 on ahci1 ata2: at channel 0 on atapci0 [eject card] ahcich6: stopping AHCI engine failed ahcich6: stopping AHCI FR engine failed ahcich6: detached ahcich7: stopping AHCI engine failed ahcich7: stopping AHCI FR engine failed ahcich7: detached ahci1: detached ata2: detached atapci0: detached Fatal trap 9: general protection fault while in kernel mode Also, has anyone thought about adding a case in your trap handler that when we hit the deadc0de address, to print up a special message or something? At least flag it, or do we not get the faulting address? This is HEAD as of r266429. Let me know if there is anything else you need to know. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."