atkbdc broken on current ?
John Baldwin
jhb at freebsd.org
Fri Jun 17 21:21:52 UTC 2011
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
More information about the freebsd-current
mailing list