From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 21:21:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75578106566B for ; Fri, 17 Jun 2011 21:21:52 +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 33C058FC12 for ; Fri, 17 Jun 2011 21:21:52 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AD18146B1A; Fri, 17 Jun 2011 17:21:51 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 46EDA8A01F; Fri, 17 Jun 2011 17:21:51 -0400 (EDT) From: John Baldwin To: Damjan Marion Date: Fri, 17 Jun 2011 17:21:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110325; KDE/4.5.5; amd64; ; ) References: <5BEF0D0F-3717-42CE-ADF7-8876558004CA@gmail.com> <201105061147.33766.jhb@freebsd.org> In-Reply-To: <201105061147.33766.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201106171721.50686.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 17 Jun 2011 17:21:51 -0400 (EDT) Cc: freebsd-current@freebsd.org Subject: Re: atkbdc broken on current ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 17 Jun 2011 21:21:52 -0000 On Friday, May 06, 2011 11:47:33 am John Baldwin wrote: > On Thursday, May 05, 2011 5:04:54 pm Damjan Marion wrote: > > > > On May 5, 2011, at 7:43 PM, John Baldwin wrote: > > > > > On Thursday, May 05, 2011 9:21:04 am Damjan Marion wrote: > > >> > > >> Hi, > > >> > > >> I have issue with old HP DL380G3 server. When I use ILO virtual console to > > > manage server. Seems that 9-CURRENT fails to detect atkbdc. > > >> When I boot 8.2-RELEASE it works well. > > >> > > >> 8.2 dmesg shows: > > >> > > >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 > > >> > > >> 9.0: > > >> > > >> atkbdc0: failed to probe at port 0x60 on isa0 > > >> > > >> Is this a known issue? > > >> > > >> Should I enable some additional outputs, like KBDIO_DEBUG? > > > > > > I suspect this is a resource issue stemming from changes I made to the acpi(4) > > > bus driver quite a while ago to make it use rman_reserve_resource(). Can you > > > capture a full verbose dmesg from 9 along with devinfo -rv and devinfo -ur > > > output from 9? > > > > Here it is: > > > > http://web.me.com/dmarion/atkbdc.txt > > Ohh, hmm. Your BIOS has done "odd" things: > > isab0 pnpinfo vendor=0x1166 device=0x0201 subvendor=0x1166 subdevice=0x0201 class=0x060100 at slot=15 function=0 handle=\_SB_.PCI0.IBRG > isa0 > I/O ports: > 0x0-0xf > 0x20-0x21 > 0x40-0x43 > 0x60 > 0x61 > 0x64 > 0x80-0x8f > 0xa0-0xa1 > 0xc0-0xdf > 0x4d6 > > Still, I don't know how the ISA bus is actually allocating resources. Can > you add some code to the x86 nexus driver to drop into kdb when it receives > a SYS_RES_IOPORT allocation request from "isa0" and get a stack trace from > DDB and reply with the trace? So I think I just found the explanation for this and I think the change I just committed will fix your system: Author: jhb Date: Fri Jun 17 21:19:01 2011 New Revision: 223207 URL: http://svn.freebsd.org/changeset/base/223207 Log: Don't create a device_t object or parse current resources (via _CRS) for ACPI Device() objects that do not have any device IDs available via the _HID or _CID methods. Without a device ID a device driver cannot attach to the device anyway. Namespace objects that are devices but not of type ACPI_TYPE_DEVICE are not affected. A few BIOSes have also attached a _CRS method to a PCI device to allocate resources that are not managed via a BAR. With the previous code those resources are allocated from acpi0 directly which can interfere with the new PCI-PCI bridge driver (since the PCI device in question may be behind a bridge and its resources should be allocated from that bridge's windows instead). The resources were also orphaned and and would end up associated with some other random device whose device_t reused the pointer of the original ACPI-enumerated device (after it was free'd by the ACPI PCI bus driver) in devinfo output which was confusing. If we want to handle _CRS on PCI devices we can adjust the ACPI PCI bus driver to do that in the future and associate the resources with the proper device object respecting PCI-PCI bridges, etc. Note that with this change the ACPI PCI bus driver no longer has to delete ACPI-enumerated device_t devices that mirror PCI devices since they should in general not exist. There are rare cases when a BIOS will give a PCI device a _HID (e.g. I've seen a PCI-ISA bridge given a _HID for a system resource device). In that case we leave both the ACPI and PCI-enumerated device_t objects around just as in the previous code. Modified: head/sys/dev/acpica/acpi.c head/sys/dev/acpica/acpi_pci.c -- John Baldwin