Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Jun 2011 09:47:26 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        Kevin Oberman <kob6558@gmail.com>
Cc:        zeus@ibs.dn.ua, freebsd-mobile@freebsd.org
Subject:   Re: ath 9285 cannot map register space
Message-ID:  <201106230947.26876.jhb@freebsd.org>
In-Reply-To: <BANLkTikM-MBxDf2rSnD9H4-sY%2B74LWr6hw@mail.gmail.com>
References:  <20110622122719.GC46814@relay.ibs.dn.ua> <201106221603.56422.jhb@freebsd.org> <BANLkTikM-MBxDf2rSnD9H4-sY%2B74LWr6hw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, June 22, 2011 6:23:37 pm Kevin Oberman wrote:
> On Wed, Jun 22, 2011 at 10:03 AM, John Baldwin <jhb@freebsd.org> wrote:
> > On Wednesday, June 22, 2011 1:21:50 pm Zeus V Panchenko wrote:
> >> John Baldwin (jhb@freebsd.org) [11.06.22 18:46] wrote:
> >> > > > dmesg | grep ath
> >> > > ath0: <Atheros 9285> irq 18 at device 0.0 on pci9
> >> > > ath0: 0x10000 bytes of rid 0x10 res 3 failed (0, 0xffffffff).
> >> > > ath0: cannot map register space
> >> > > device_attach: ath0 attach returned 6
> >> > >
> >> > >
> >> > > is it working at all, pls?
> >> >
> >> > This is likely fixed in HEAD.
> >> >
> >>
> >> mmm ... is it possible to have it in STABLE somehow, pls?
> >
> > Hmm, it's a rather big set of changes to the PCI code.  I might take a gander
> > at making a candidate patch for 8.
> 
> John,
> 
> Adrian posted instruction for building the driver as a module on 8.
> It's posted to the wireless list at:
> http://www.freebsd.org/cgi/getmsg.cgi?fetch=167507+172298+/usr/local/www/db/text/2011/freebsd-wireless/20110417.freebsd-wireless
> 
> So no need to do it again.

No, his issue is a PCI issue (the 'cannot map register space') which is
likely fixed by this change (but it needs other stuff MFC'd first before
it will work):

Author: jhb
Date: Tue May  3 17:37:24 2011
New Revision: 221393
URL: http://svn.freebsd.org/changeset/base/221393

Log:
  Reimplement how PCI-PCI bridges manage their I/O windows.  Previously the
  driver would verify that requests for child devices were confined to any
  existing I/O windows, but the driver relied on the firmware to initialize
  the windows and would never grow the windows for new requests.  Now the
  driver actively manages the I/O windows.
  
  This is implemented by allocating a bus resource for each I/O window from
  the parent PCI bus and suballocating that resource to child devices.  The
  suballocations are managed by creating an rman for each I/O window.  The
  suballocated resources are mapped by passing the bus_activate_resource()
  call up to the parent PCI bus.  Windows are grown when needed by using
  bus_adjust_resource() to adjust the resource allocated from the parent PCI
  bus.  If the adjust request succeeds, the window is adjusted and the
  suballocation request for the child device is retried.
  
  When growing a window, the rman_first_free_region() and
  rman_last_free_region() routines are used to determine if the front or
  end of the existing I/O window is free.  From using that, the smallest
  ranges that need to be added to either the front or back of the window
  are computed.  The driver will first try to grow the window in whichever
  direction requires the smallest growth first followed by the other
  direction if that fails.
  
  Subtractive bridges will first attempt to satisfy requests for child
  resources from I/O windows (including attempts to grow the windows).  If
  that fails, the request is passed up to the parent PCI bus directly
  however.
  
  The PCI-PCI bridge driver will try to use firmware-assigned ranges for
  child BARs first and only allocate a "fresh" range if that specific range
  cannot be accommodated in the I/O window.  This allows systems where the
  firmware assigns resources during boot but later wipes the I/O windows
  (some ACPI BIOSen are known to do this) to "rediscover" the original I/O
  window ranges.
  
  The ACPI Host-PCI bridge driver has been adjusted to correctly honor
  hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge
  makes a wildcard request for an I/O window range.
  
  The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option
  is enabled.  This is a transition aide to allow platforms that do not
  yet support bus_activate_resource() and bus_adjust_resource() in their
  Host-PCI bridge drivers (and possibly other drivers as needed) to use the
  old driver for now.  Once all platforms support the new driver, the
  kernel option and old driver will be removed.
  
  PR:           kern/143874 kern/149306
  Tested by:    mav

Modified:
  head/sys/amd64/pci/pci_bus.c
  head/sys/conf/options
  head/sys/dev/acpica/acpi_pcib_acpi.c
  head/sys/dev/acpica/acpi_pcib_pci.c
  head/sys/dev/pci/pci.c
  head/sys/dev/pci/pci_pci.c
  head/sys/dev/pci/pcib_private.h
  head/sys/i386/pci/pci_bus.c
  head/sys/sparc64/pci/apb.c
  head/sys/sparc64/pci/ofw_pcib.c
  head/sys/x86/pci/qpi.c
  head/sys/x86/x86/mptable_pci.c

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106230947.26876.jhb>