Re: atkbdc broken on current ?

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: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> > >> 
> > >> 9.0:
> > >> 
> > >> atkbdc0: <Keyboard controller (i8042)> 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