From owner-freebsd-acpi@FreeBSD.ORG Fri May 1 19:30:30 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 BE6E3106572D for ; Fri, 1 May 2009 19:30:30 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 4007F8FC13 for ; Fri, 1 May 2009 19:30:30 +0000 (UTC) (envelope-from klingfon@gmail.com) Received: by ewy19 with SMTP id 19so2486195ewy.43 for ; Fri, 01 May 2009 12:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=HFGg1uuJ1vcgSijYGkfPmBhax/r6KEjZ1d8OkZSoQ6I=; b=guJUHqw0sj6+SxPZ0+m2riGc1Jgs3pkqNf+GNSfwKadJsncd+h/B9QhEcSQ5+pRV4T 0BjMNTTPkUt3qEz7MadAx31+KbUEqh505n9rpr0RUifOCge/uXpR1xcdLcF0kK2X9qnE Cxi7fP+ViIP/P2d0xq9DAIZsQE10eioqeaEDc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Ce6C6mb7WVvyWNhdHF8JNh3QeGDq4GDdjgb4bYPW12/taXy2G1tCcMfWPGq5xwJkE5 Ec12nAp4pFWttc94skOMiXIBvCZvz9Rc3G8tZUmy7BiGUxfk0E6IfJ3GytHi80zPa+WQ 7ai6GoVfjnLAO70Skh+kqtOdvBYaJWY9eWeVw= MIME-Version: 1.0 Received: by 10.210.18.8 with SMTP id 8mr3268693ebr.39.1241206228970; Fri, 01 May 2009 12:30:28 -0700 (PDT) In-Reply-To: <200905011450.13899.jhb@freebsd.org> References: <43b1bb350904230622u4b7790f0p9f665b649c97a3b@mail.gmail.com> <200904300836.34238.jhb@freebsd.org> <43b1bb350905011130q4f58c018g66a9e4624c364b65@mail.gmail.com> <200905011450.13899.jhb@freebsd.org> Date: Fri, 1 May 2009 21:30:28 +0200 Message-ID: <43b1bb350905011230p1372e1ffw5ab61985e7672e19@mail.gmail.com> From: Magnus Kling To: freebsd-acpi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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:30:31 -0000 2009/5/1 John Baldwin > 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 o= f > > > > debugging and testing if that is needed. > > > > > > > > > > > > (kgdb) frame 10 > > > > #10 0xc0db4ca8 in acpi_pci_child_location_str_method > (cbdev=3D0xc2212680, > > > > child=3D0xc2243400, buf=3D0xc22c2400 "slot=3D0 function=3D0 han= dle=3D", > > > > buflen=3D1024) > > > > 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 =3D {ap_dinfo =3D {pci_links =3D {stqe_next =3D 0xc0b00f8c}, res= ources =3D { > > > > stqh_first =3D 0xc0b00f8c, stqh_last =3D 0x1030000}, cfg =3D = {dev =3D > 0x0, > > > > bar =3D {4, 0, 0, 3257136600, 0, 0}, bios =3D 0, subvendor = =3D 0, > > > > subdevice =3D 0, vendor =3D 0, device =3D 0, cmdreg =3D 0, st= atreg =3D 0, > > > > baseclass =3D 0 '\0', subclass =3D 0 '\0', progif =3D 0 '\0',= revid =3D > 0 > > > > > > Hmm, this is all completely wrong and trashed. What if you do 'p > *child'? > > > > > > -- > > > John Baldwin > > > > > (kgdb) p *child > > $2 =3D {ops =3D 0xc2161800, link =3D {tqe_next =3D 0xc2243380, tqe_prev= =3D > > 0xc2243484}, devlink =3D {tqe_next =3D 0xc2243380, tqe_prev =3D 0xc2243= 48c}, > > parent =3D 0xc2212680, children =3D {tqh_first =3D 0xc2262880, tqh_la= st =3D > > 0xc2262704}, driver =3D 0xc0b7066c, devclass =3D 0xc211e240, unit =3D 0= , > > nameunit =3D 0xc2241640 "atapci0", desc =3D 0xc223f900 "Promise PDC20= 621 > > UDMA100 controller", busy =3D 0, state =3D DS_ATTACHED, devflags =3D 0, > > flags =3D 13, order =3D 0 '\0', pad =3D 0 '\0', ivars =3D 0xc223f5c0,= softc =3D > > 0xc2244800, sysctl_ctx =3D {tqh_first =3D 0xc2264380, tqh_last =3D 0xc2= 241594}, > > sysctl_tree =3D 0xc223f840} > > (kgdb) > > Maybe try adding KTR traces for all calls to device_set_ivars(). I wonde= r > 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 > Aha, I=B4m using a Promise Fasttrack SX4000 for a RAID1 setup. And the one included on the motherboard for the OS. And yes, I can confirm that without the Fasttrack SX4000 the system boots u= p correctly. (Pulled out the card and edited fstab.) So you are right regarding that the ata driver messes something up. Do you contact someone that is responsible for ata driver? Thank you for taking the time to "correct" this, Magnus