From owner-freebsd-acpi@FreeBSD.ORG Fri May 1 19:08:36 2009 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83659106564A for ; Fri, 1 May 2009 19:08:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 544188FC08 for ; Fri, 1 May 2009 19:08:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 084F446B37; Fri, 1 May 2009 15:08:36 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id E2E368A023; Fri, 1 May 2009 15:08:34 -0400 (EDT) From: John Baldwin To: Magnus Kling Date: Fri, 1 May 2009 14:50:13 -0400 User-Agent: KMail/1.9.7 References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com> <200904300836.34238.jhb@freebsd.org> <43b1bb350905011130q4f58c018g66a9e4624c364b65@mail.gmail.com> In-Reply-To: <43b1bb350905011130q4f58c018g66a9e4624c364b65@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905011450.13899.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 01 May 2009 15:08:34 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: Fwd: Kernel panic on 7.2-RC1 when booting with ACPI enabled kernel. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:08:36 -0000 On Friday 01 May 2009 2:30:28 pm Magnus Kling wrote: > 2009/4/30 John Baldwin > > > On Saturday 25 April 2009 6:27:23 am Magnus Kling wrote: > > > 2009/4/24 John Baldwin > > > > Can you do 'frame 10' followed by 'p *(struct acpi_pci_devinfo > > > > *)child->ivars' > > > > > > > > -- > > > > John Baldwin > > > > > > > > > Sure, no problem. This is a none critical server so I can do alot of > > > debugging and testing if that is needed. > > > > > > > > > (kgdb) frame 10 > > > #10 0xc0db4ca8 in acpi_pci_child_location_str_method (cbdev=0xc2212680, > > > child=0xc2243400, buf=0xc22c2400 "slot=0 function=0 handle=", > > > buflen=1024) > > > at /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_pci.c:150 > > > 150 strlcat(buf, acpi_name(dinfo->ap_handle), buflen); > > > > > > (kgdb) p *(struct acpi_pci_devinfo *)child->ivars > > > $1 = {ap_dinfo = {pci_links = {stqe_next = 0xc0b00f8c}, resources = { > > > stqh_first = 0xc0b00f8c, stqh_last = 0x1030000}, cfg = {dev = 0x0, > > > bar = {4, 0, 0, 3257136600, 0, 0}, bios = 0, subvendor = 0, > > > subdevice = 0, vendor = 0, device = 0, cmdreg = 0, statreg = 0, > > > baseclass = 0 '\0', subclass = 0 '\0', progif = 0 '\0', revid = 0 > > > > Hmm, this is all completely wrong and trashed. What if you do 'p *child'? > > > > -- > > John Baldwin > > > (kgdb) p *child > $2 = {ops = 0xc2161800, link = {tqe_next = 0xc2243380, tqe_prev = > 0xc2243484}, devlink = {tqe_next = 0xc2243380, tqe_prev = 0xc224348c}, > parent = 0xc2212680, children = {tqh_first = 0xc2262880, tqh_last = > 0xc2262704}, driver = 0xc0b7066c, devclass = 0xc211e240, unit = 0, > nameunit = 0xc2241640 "atapci0", desc = 0xc223f900 "Promise PDC20621 > UDMA100 controller", busy = 0, state = DS_ATTACHED, devflags = 0, > flags = 13, order = 0 '\0', pad = 0 '\0', ivars = 0xc223f5c0, softc = > 0xc2244800, sysctl_ctx = {tqh_first = 0xc2264380, tqh_last = 0xc2241594}, > sysctl_tree = 0xc223f840} > (kgdb) Maybe try adding KTR traces for all calls to device_set_ivars(). I wonder if something is trashing this device's ivars. Oh, dear. The ata(4) driver overwrites the ivars of some PCI devices it attaches to. This is very, very wrong. Which ATA controller do you have? -- John Baldwin