BAR 7 io space assignment errors

linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

* BAR 7 io space assignment errors
@ 2015-05-15 17:28 Guenter Roeck
  2015-05-15 19:25 ` Bjorn Helgaas
  0 siblings, 1 reply; 9+ messages in thread
From: Guenter Roeck @ 2015-05-15 17:28 UTC (permalink / raw)
  To: linux-pci

Hi all,

ever since 3.18(ish), we see lots of pcie io range allocation error messages
when booting our systems.

pcieport 0000:02:00.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
pcieport 0000:02:00.0: BAR 7: no space for [io  size 0x1000]
pcieport 0000:02:00.0: BAR 7: failed to assign [io  size 0x1000]

This is repeated for each port.

What we atually _want_ is no IO address range, but so far I have not been able to
tell this to the code (or to the bridge).

The IO space "0x1000-0xfff" gives an indication of what is going on, at least
to some degree. The io range is calculated in pbus_size_io() as
	b_res->start = min_align;
	b_res->end = b_res->start + size0 - 1;
with size0 == 0, so end < start.

Searching for the get_res_add_size and the BAR7 message suggests that many
others see the problem as well, so it appears that we are not alone.
I have not been able to find a solution, though.

Any idea what we may have to do to fix the problem, or in other words
what may be wrong ?

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BAR 7 io space assignment errors
  2015-05-15 17:28 BAR 7 io space assignment errors Guenter Roeck
@ 2015-05-15 19:25 ` Bjorn Helgaas
  2015-05-15 20:04   ` Guenter Roeck
  0 siblings, 1 reply; 9+ messages in thread
From: Bjorn Helgaas @ 2015-05-15 19:25 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: linux-pci@vger.kernel.org, Yinghai Lu

[+cc Yinghai]

Hi Guenter,

On Fri, May 15, 2015 at 12:28 PM, Guenter Roeck <groeck@juniper.net> wrote:
> Hi all,
>
> ever since 3.18(ish), we see lots of pcie io range allocation error messages
> when booting our systems.
>
> pcieport 0000:02:00.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
> pcieport 0000:02:00.0: BAR 7: no space for [io  size 0x1000]
> pcieport 0000:02:00.0: BAR 7: failed to assign [io  size 0x1000]
>
> This is repeated for each port.
>
> What we atually _want_ is no IO address range, but so far I have not been able to
> tell this to the code (or to the bridge).

What information does the core have that we could use to figure out
that you want no I/O space?  For example, does the host bridge have no
I/O apertures?  Or are there no devices below 02:00.0 that require I/O
space?  If you can post a complete dmesg log, that should contain this
information.

I think we currently will try to assign enough I/O space for any I/O
BARs below the bridge.  Or, if the bridge supports hotplug, we will
try to assign at least pci_hotplug_io_size, which defaults to 256.

> The IO space "0x1000-0xfff" gives an indication of what is going on, at least
> to some degree. The io range is calculated in pbus_size_io() as
>         b_res->start = min_align;
>         b_res->end = b_res->start + size0 - 1;
> with size0 == 0, so end < start.
>
> Searching for the get_res_add_size and the BAR7 message suggests that many
> others see the problem as well, so it appears that we are not alone.
> I have not been able to find a solution, though.
>
> Any idea what we may have to do to fix the problem, or in other words
> what may be wrong ?

Is the problem that some device doesn't work, or is it just extra
annoying messages.  We should fix something in either case, of course,
but it's more urgent if a device used to work but no longer does.

Bjorn

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BAR 7 io space assignment errors
  2015-05-15 19:25 ` Bjorn Helgaas
@ 2015-05-15 20:04   ` Guenter Roeck
  2015-05-15 22:11     ` Bjorn Helgaas
  0 siblings, 1 reply; 9+ messages in thread
From: Guenter Roeck @ 2015-05-15 20:04 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: linux-pci@vger.kernel.org, Yinghai Lu

Hi Bjorn,

On Fri, May 15, 2015 at 02:25:34PM -0500, Bjorn Helgaas wrote:
> [+cc Yinghai]
> 
> Hi Guenter,
> 
> On Fri, May 15, 2015 at 12:28 PM, Guenter Roeck <groeck@juniper.net> wrote:
> > Hi all,
> >
> > ever since 3.18(ish), we see lots of pcie io range allocation error messages
> > when booting our systems.
> >
> > pcieport 0000:02:00.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
> > pcieport 0000:02:00.0: BAR 7: no space for [io  size 0x1000]
> > pcieport 0000:02:00.0: BAR 7: failed to assign [io  size 0x1000]
> >
> > This is repeated for each port.
> >
> > What we atually _want_ is no IO address range, but so far I have not been able to
> > tell this to the code (or to the bridge).
> 
> What information does the core have that we could use to figure out
> that you want no I/O space?  For example, does the host bridge have no
> I/O apertures?  Or are there no devices below 02:00.0 that require I/O
> space?  If you can post a complete dmesg log, that should contain this
> information.
> 
We know that we don't need IO space behind the bridge.

Question would be what information the core would need. I have tried
to pre-program PCI_IO_BASE and PCI_IO_LIMIT on the bridge ports,
but that doesn't seem to be the right solution (and it was just a
wild shot anyway ;-).

> Is the problem that some device doesn't work, or is it just extra
> annoying messages.  We should fix something in either case, of course,
> but it's more urgent if a device used to work but no longer does.
> 
Just the extra annoying messages. The messages below are just the beginning;
there are many more when the actual devices behind the bridge ports come
online.

Thanks,
Guenter

---

dmesg log:

Dec 31 16:00:35 fpc0 kernel: Using P2020 PTXPMB machine description
Dec 31 16:00:35 fpc0 kernel: Memory CAM mapping: 256/256/256 Mb, residual: 3328Mb
Dec 31 16:00:35 fpc0 kernel: Initializing cgroup subsys cpuset
Dec 31 16:00:35 fpc0 kernel: Initializing cgroup subsys cpu
Dec 31 16:00:35 fpc0 kernel: Initializing cgroup subsys cpuacct
Dec 31 16:00:35 fpc0 kernel: Linux version 4.0.2-juniper-00581-ge031ee2-dirty (groeck@svl-evodev-groeck) (gcc version 4.8.2 (GCC) ) #1 SMP PREEMPT Thu May 14 23:53:42 PDT 2015
Dec 31 16:00:35 fpc0 kernel: Found initrd at 0xdce1a000:0xeffff8b0
Dec 31 16:00:35 fpc0 kernel: Found legacy serial port 0 for /soc/uart0
Dec 31 16:00:35 fpc0 kernel:   mem=fff704500, taddr=fff704500, irq=0, clk=400000002, speed=0
Dec 31 16:00:35 fpc0 kernel: Found legacy serial port 1 for /soc/uart1
Dec 31 16:00:35 fpc0 kernel:   mem=fff704600, taddr=fff704600, irq=0, clk=400000002, speed=0
Dec 31 16:00:35 fpc0 kernel: CPU maps initialized for 1 thread per core
Dec 31 16:00:35 fpc0 kernel:  (thread shift is 0)
Dec 31 16:00:35 fpc0 kernel: bootconsole [udbg0] enabled
Dec 31 16:00:35 fpc0 kernel: CPLD at 0xfff000000 size 0x10000
Dec 31 16:00:35 fpc0 kernel: P2020 PTX PMB board from Juniper Networks
Dec 31 16:00:35 fpc0 kernel: Top of RAM: 0x100000000, Total RAM: 0x100000000
Dec 31 16:00:35 fpc0 kernel: Memory hole size: 0MB
Dec 31 16:00:35 fpc0 kernel: Zone ranges:
Dec 31 16:00:35 fpc0 kernel:   DMA      [mem 0x0000000000000000-0x000000002fffffff]
Dec 31 16:00:35 fpc0 kernel:   Normal   empty
Dec 31 16:00:35 fpc0 kernel:   HighMem  [mem 0x0000000030000000-0x00000000ffffffff]
Dec 31 16:00:35 fpc0 kernel: Movable zone start for each node
Dec 31 16:00:35 fpc0 kernel: Early memory node ranges
Dec 31 16:00:35 fpc0 kernel:   node   0: [mem 0x0000000000000000-0x00000000ffffffff]
Dec 31 16:00:35 fpc0 kernel: Initmem setup node 0 [mem 0x0000000000000000-0x00000000ffffffff]
Dec 31 16:00:35 fpc0 kernel: On node 0 totalpages: 1048576
Dec 31 16:00:35 fpc0 kernel: free_area_init_node: node 0, pgdat c06bc820, node_mem_map dadec000
Dec 31 16:00:35 fpc0 kernel:   DMA zone: 1536 pages used for memmap
Dec 31 16:00:35 fpc0 kernel:   DMA zone: 0 pages reserved
Dec 31 16:00:35 fpc0 kernel:   DMA zone: 196608 pages, LIFO batch:31
Dec 31 16:00:35 fpc0 kernel:   HighMem zone: 851968 pages, LIFO batch:31
Dec 31 16:00:35 fpc0 kernel: MMU: Allocated 1088 bytes of context maps for 255 contexts
Dec 31 16:00:35 fpc0 kernel: PERCPU: Embedded 10 pages/cpu @dadc1000 s10896 r8192 d21872 u40960
Dec 31 16:00:35 fpc0 kernel: pcpu-alloc: s10896 r8192 d21872 u40960 alloc=10*4096
Dec 31 16:00:35 fpc0 kernel: pcpu-alloc: [0] 0 [0] 1 
Dec 31 16:00:35 fpc0 kernel: Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 1047040
Dec 31 16:00:35 fpc0 kernel: Kernel command line: root=/dev/ram rw ramdisk_size=10000000 raid=noautodetect console=ttyS0,9600 cache-sram-size=0x10000 ip=128.0.0.16:128.0.0.4:128.0.0.4:192.0.0.0:fpc0:eth0:off
Dec 31 16:00:35 fpc0 kernel: PID hash table entries: 4096 (order: 2, 16384 bytes)
Dec 31 16:00:35 fpc0 kernel: Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Dec 31 16:00:35 fpc0 kernel: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Dec 31 16:00:35 fpc0 kernel: Sorting __ex_table...
Dec 31 16:00:35 fpc0 kernel: Memory: 3773792K/4194304K available (5292K kernel code, 272K rwdata, 1108K rodata, 276K init, 418K bss, 420512K reserved, 0K cma-reserved, 3407868K highmem)
Dec 31 16:00:35 fpc0 kernel: Kernel virtual memory layout:
Dec 31 16:00:35 fpc0 kernel:   * 0xfffbf000..0xfffff000  : fixmap
Dec 31 16:00:35 fpc0 kernel:   * 0xffc00000..0xffe00000  : highmem PTEs
Dec 31 16:00:35 fpc0 kernel:   * 0xffbed000..0xffc00000  : early ioremap
Dec 31 16:00:35 fpc0 kernel:   * 0xf1000000..0xffbed000  : vmalloc & ioremap
Dec 31 16:00:35 fpc0 kernel: SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Dec 31 16:00:35 fpc0 kernel: Preemptible hierarchical RCU implementation.
Dec 31 16:00:35 fpc0 kernel:         Additional per-CPU info printed with stalls.
Dec 31 16:00:35 fpc0 kernel: NR_IRQS:512 nr_irqs:512 16
Dec 31 16:00:35 fpc0 kernel: mpic: Setting up MPIC " OpenPIC  " version 1.2 at fff740000, max 2 CPUs
Dec 31 16:00:35 fpc0 kernel: mpic: ISU size: 256, shift: 8, mask: ff
Dec 31 16:00:35 fpc0 kernel: mpic: Initializing for 256 sources
Dec 31 16:00:35 fpc0 kernel: time_init: decrementer frequency = 50.000000 MHz
Dec 31 16:00:35 fpc0 kernel: time_init: processor frequency   = 1200.000006 MHz
Dec 31 16:00:35 fpc0 kernel: clocksource: timebase mult[14000000] shift[24] registered
Dec 31 16:00:35 fpc0 kernel: clockevent: decrementer mult[ccccccd] shift[32] cpu[0]
Dec 31 16:00:35 fpc0 kernel: Console: colour dummy device 80x25
Dec 31 16:00:35 fpc0 kernel: kmemleak: Kernel memory leak detector disabled
Dec 31 16:00:35 fpc0 kernel: kmemleak: Early log buffer exceeded (746), please increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE
Dec 31 16:00:35 fpc0 kernel: pid_max: default: 32768 minimum: 301
Dec 31 16:00:35 fpc0 kernel: Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Dec 31 16:00:35 fpc0 kernel: Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
Dec 31 16:00:35 fpc0 kernel: Initializing cgroup subsys blkio
Dec 31 16:00:35 fpc0 kernel: Initializing cgroup subsys devices
Dec 31 16:00:35 fpc0 kernel: Initializing cgroup subsys freezer
Dec 31 16:00:35 fpc0 kernel: Initializing cgroup subsys debug
Dec 31 16:00:35 fpc0 kernel: mpic: requesting IPIs...
Dec 31 16:00:35 fpc0 kernel: Brought up 2 CPUs
Dec 31 16:00:35 fpc0 kernel: devtmpfs: initialized
Dec 31 16:00:35 fpc0 kernel: NET: Registered protocol family 16
Dec 31 16:00:35 fpc0 kernel: Found FSL PCI host bridge at 0x0000000fff70a000. Firmware bus number: 0->0
Dec 31 16:00:35 fpc0 kernel: PCI host bridge /pcie@a000 (primary) ranges:
Dec 31 16:00:35 fpc0 kernel:  MEM 0x0000000c00000000..0x0000000c3fffffff -> 0x0000000080000000 
Dec 31 16:00:35 fpc0 kernel:   IO 0x0000000fffc00000..0x0000000fffc0ffff -> 0x0000000000000000
Dec 31 16:00:35 fpc0 kernel: /pcie@a000: PCICSRBAR @ 0xfff00000
Dec 31 16:00:35 fpc0 kernel: /pcie@a000: Setup 64-bit PCI DMA window
Dec 31 16:00:35 fpc0 kernel: /pcie@a000: WARNING: Outbound window cfg leaves gaps in memory map. Adjusting the memory map could reduce unnecessary bounce buffering.
Dec 31 16:00:35 fpc0 kernel: /pcie@a000: DMA window size is 0x80000000
Dec 31 16:00:35 fpc0 kernel: software IO TLB [mem 0x16cfd000-0x1acfd000] (64MB) mapped at [d6cfd000-dacfcfff]
Dec 31 16:00:35 fpc0 kernel: PCI: Probing PCI hardware
Dec 31 16:00:35 fpc0 kernel: fsl-pci fff70a000.pcie: PCI host bridge to bus 0000:00
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:00: root bus resource [mem 0xc00000000-0xc3fffffff] (bus address [0x80000000-0xbfffffff])
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:00: root bus resource [bus 00-ff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to ff
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: [1957:0071] type 01 class 0x0b2000
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: reg 0x10: [mem 0xfff00000-0xffffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: supports D1 D2
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: [111d:807a] type 01 class 0x060400
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: PCI bridge to [bus 01-ff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0:   bridge window [mem 0xc00000000-0xc3fffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: [111d:807a] type 01 class 0x060400
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: PME# supported from D0 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: [111d:807a] type 01 class 0x060400
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: [111d:807a] type 01 class 0x060400
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: PME# supported from D0 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: [111d:807a] type 01 class 0x060400
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: PME# supported from D0 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: [111d:807a] type 01 class 0x060400
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: PME# supported from D0 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: [111d:807a] type 01 class 0x060400
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: PME# supported from D0 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: [111d:807a] type 01 class 0x060400
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: PME# supported from D0 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: [111d:807a] type 01 class 0x060400
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: PME# supported from D0 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: [111d:807a] type 01 class 0x060400
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: PME# supported from D0 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: [111d:807a] type 01 class 0x060400
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: PME# supported from D0 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: [111d:807a] type 01 class 0x060400
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: PME# supported from D0 D3hot D3cold
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: PCI bridge to [bus 02-ff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0:   bridge window [mem 0xc00000000-0xc2fffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: PCI bridge to [bus 40-4f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0:   bridge window [mem 0xc04000000-0xc07ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: PCI bridge to [bus 90-9f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0:   bridge window [mem 0xc08000000-0xc0bffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: PCI bridge to [bus 80-8f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0:   bridge window [mem 0xc00000000-0xc03ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: PCI bridge to [bus 50-5f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0:   bridge window [mem 0xc0c000000-0xc0fffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: PCI bridge to [bus 30-3f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0:   bridge window [mem 0xc28000000-0xc2bffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: PCI bridge to [bus 70-7f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0:   bridge window [mem 0xc1c000000-0xc1fffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: PCI bridge to [bus 60-6f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0:   bridge window [mem 0xc14000000-0xc17ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:20:00.0: [1304:0004] type 00 class 0xff0000
Dec 31 16:00:35 fpc0 kernel: pci 0000:20:00.0: reg 0x10: [mem 0x00000000-0x03ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: PCI bridge to [bus 20-2f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0:   bridge window [mem 0xc20000000-0xc23ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: PCI bridge to [bus 10-1f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0:   bridge window [mem 0xc24000000-0xc27ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: PCI bridge to [bus b0-bf]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0:   bridge window [mem 0xc18000000-0xc1bffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: PCI bridge to [bus a0-af]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0:   bridge window [mem 0xc10000000-0xc13ffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to ff
Dec 31 16:00:35 fpc0 kernel: PCI: Cannot allocate resource region 0 of PCI bridge 1, will remap
Dec 31 16:00:35 fpc0 kernel: PCI: Cannot allocate resource region 0 of device 0000:00:00.0, will remap
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: bridge window [io  0x1000-0x0fff] to [bus 40-4f] add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 40-4f] add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: bridge window [io  0x1000-0x0fff] to [bus 90-9f] add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 90-9f] add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: bridge window [io  0x1000-0x0fff] to [bus 80-8f] add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 80-8f] add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: bridge window [io  0x1000-0x0fff] to [bus 50-5f] add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 50-5f] add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: bridge window [io  0x1000-0x0fff] to [bus 30-3f] add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 30-3f] add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: bridge window [io  0x1000-0x0fff] to [bus 70-7f] add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 70-7f] add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: bridge window [io  0x1000-0x0fff] to [bus 60-6f] add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 60-6f] add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: bridge window [io  0x1000-0x0fff] to [bus 20-2f] add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 20-2f] add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: bridge window [io  0x1000-0x0fff] to [bus 10-1f] add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 10-1f] add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: bridge window [io  0x1000-0x0fff] to [bus b0-bf] add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus b0-bf] add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: bridge window [io  0x1000-0x0fff] to [bus a0-af] add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus a0-af] add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: bridge window [io  0x1000-0x0fff] to [bus 02-ff] add_size b000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 02-ff] add_size 1600000
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 1600000
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 01-ff] add_size 1600000
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 1600000
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: BAR 0: no space for [mem size 0x00100000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: BAR 0: failed to assign [mem size 0x00100000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: BAR 9: no space for [mem size 0x01600000 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: BAR 9: failed to assign [mem size 0x01600000 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: BAR 0: no space for [mem size 0x00100000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: BAR 0: failed to assign [mem size 0x00100000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: BAR 9: no space for [mem size 0x01600000 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: BAR 9: failed to assign [mem size 0x01600000 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 1600000
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size b000
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: BAR 9: assigned [mem 0xc30000000-0xc315fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: BAR 7: no space for [io  size 0xb000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: BAR 7: failed to assign [io  size 0xb000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: BAR 7: no space for [io  size 0xb000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: BAR 7: failed to assign [io  size 0xb000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: res[9]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: BAR 9: assigned [mem 0xc30000000-0xc301fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: BAR 9: assigned [mem 0xc30200000-0xc303fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: BAR 9: assigned [mem 0xc30400000-0xc305fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: BAR 9: assigned [mem 0xc30600000-0xc307fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: BAR 9: assigned [mem 0xc30800000-0xc309fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: BAR 9: assigned [mem 0xc30a00000-0xc30bfffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: BAR 9: assigned [mem 0xc30c00000-0xc30dfffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: BAR 9: assigned [mem 0xc30e00000-0xc30ffffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: BAR 9: assigned [mem 0xc31000000-0xc311fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: BAR 9: assigned [mem 0xc31200000-0xc313fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: BAR 9: assigned [mem 0xc31400000-0xc315fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: BAR 7: no space for [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: BAR 7: failed to assign [io  size 0x1000]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0: PCI bridge to [bus 40-4f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0:   bridge window [mem 0xc04000000-0xc07ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:00.0:   bridge window [mem 0xc30000000-0xc301fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0: PCI bridge to [bus 90-9f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0:   bridge window [mem 0xc08000000-0xc0bffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:01.0:   bridge window [mem 0xc30200000-0xc303fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0: PCI bridge to [bus 80-8f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0:   bridge window [mem 0xc00000000-0xc03ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:02.0:   bridge window [mem 0xc30400000-0xc305fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0: PCI bridge to [bus 50-5f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0:   bridge window [mem 0xc0c000000-0xc0fffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:03.0:   bridge window [mem 0xc30600000-0xc307fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0: PCI bridge to [bus 30-3f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0:   bridge window [mem 0xc28000000-0xc2bffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:04.0:   bridge window [mem 0xc30800000-0xc309fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0: PCI bridge to [bus 70-7f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0:   bridge window [mem 0xc1c000000-0xc1fffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:06.0:   bridge window [mem 0xc30a00000-0xc30bfffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0: PCI bridge to [bus 60-6f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0:   bridge window [mem 0xc14000000-0xc17ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:07.0:   bridge window [mem 0xc30c00000-0xc30dfffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:20:00.0: BAR 0: assigned [mem 0xc20000000-0xc23ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0: PCI bridge to [bus 20-2f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0:   bridge window [mem 0xc20000000-0xc23ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:08.0:   bridge window [mem 0xc30e00000-0xc30ffffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0: PCI bridge to [bus 10-1f]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0:   bridge window [mem 0xc24000000-0xc27ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:09.0:   bridge window [mem 0xc31000000-0xc311fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0: PCI bridge to [bus b0-bf]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0:   bridge window [mem 0xc18000000-0xc1bffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0c.0:   bridge window [mem 0xc31200000-0xc313fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0: PCI bridge to [bus a0-af]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0:   bridge window [mem 0xc10000000-0xc13ffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:02:0d.0:   bridge window [mem 0xc31400000-0xc315fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0: PCI bridge to [bus 02-ff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0:   bridge window [mem 0xc00000000-0xc2fffffff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:01:00.0:   bridge window [mem 0xc30000000-0xc315fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0: PCI bridge to [bus 01-ff]
Dec 31 16:00:35 fpc0 kernel: pci 0000:00:00.0:   bridge window [mem 0xc00000000-0xc3fffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:00: Some PCI device resources are unassigned, try booting with pci=realloc
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:00: resource 4 [io  0x0000-0xffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:00: resource 5 [mem 0xc00000000-0xc3fffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:01: resource 1 [mem 0xc00000000-0xc3fffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:02: resource 1 [mem 0xc00000000-0xc2fffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:02: resource 2 [mem 0xc30000000-0xc315fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:40: resource 1 [mem 0xc04000000-0xc07ffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:40: resource 2 [mem 0xc30000000-0xc301fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:90: resource 1 [mem 0xc08000000-0xc0bffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:90: resource 2 [mem 0xc30200000-0xc303fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:80: resource 1 [mem 0xc00000000-0xc03ffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:80: resource 2 [mem 0xc30400000-0xc305fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:50: resource 1 [mem 0xc0c000000-0xc0fffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:50: resource 2 [mem 0xc30600000-0xc307fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:30: resource 1 [mem 0xc28000000-0xc2bffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:30: resource 2 [mem 0xc30800000-0xc309fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:70: resource 1 [mem 0xc1c000000-0xc1fffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:70: resource 2 [mem 0xc30a00000-0xc30bfffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:60: resource 1 [mem 0xc14000000-0xc17ffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:60: resource 2 [mem 0xc30c00000-0xc30dfffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:20: resource 1 [mem 0xc20000000-0xc23ffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:20: resource 2 [mem 0xc30e00000-0xc30ffffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:10: resource 1 [mem 0xc24000000-0xc27ffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:10: resource 2 [mem 0xc31000000-0xc311fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:b0: resource 1 [mem 0xc18000000-0xc1bffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:b0: resource 2 [mem 0xc31200000-0xc313fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:a0: resource 1 [mem 0xc10000000-0xc13ffffff]
Dec 31 16:00:35 fpc0 kernel: pci_bus 0000:a0: resource 2 [mem 0xc31400000-0xc315fffff 64bit pref]
Dec 31 16:00:35 fpc0 kernel: Setting up Freescale MSI support
Dec 31 16:00:35 fpc0 kernel: Freescale Elo series DMA driver
Dec 31 16:00:35 fpc0 kernel: fsl-elo-dma fff70c300.dma0: #0 (fsl,eloplus-dma-channel), irq 76
Dec 31 16:00:35 fpc0 kernel: fsl-elo-dma fff70c300.dma0: #1 (fsl,eloplus-dma-channel), irq 77
Dec 31 16:00:35 fpc0 kernel: fsl-elo-dma fff70c300.dma0: #2 (fsl,eloplus-dma-channel), irq 78
Dec 31 16:00:35 fpc0 kernel: fsl-elo-dma fff70c300.dma0: #3 (fsl,eloplus-dma-channel), irq 79
Dec 31 16:00:35 fpc0 kernel: fsl-elo-dma fff721300.dma1: #0 (fsl,eloplus-dma-channel), irq 20
Dec 31 16:00:35 fpc0 kernel: fsl-elo-dma fff721300.dma1: #1 (fsl,eloplus-dma-channel), irq 21
Dec 31 16:00:35 fpc0 kernel: fsl-elo-dma fff721300.dma1: #2 (fsl,eloplus-dma-channel), irq 22
Dec 31 16:00:35 fpc0 kernel: fsl-elo-dma fff721300.dma1: #3 (fsl,eloplus-dma-channel), irq 23
Dec 31 16:00:35 fpc0 kernel: vgaarb: loaded
Dec 31 16:00:35 fpc0 kernel: SCSI subsystem initialized
Dec 31 16:00:35 fpc0 kernel: pps_core: LinuxPPS API ver. 1 registered
Dec 31 16:00:35 fpc0 kernel: pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
Dec 31 16:00:35 fpc0 kernel: PTP clock support registered
Dec 31 16:00:35 fpc0 kernel: Switched to clocksource timebase
Dec 31 16:00:35 fpc0 kernel: NET: Registered protocol family 2
Dec 31 16:00:35 fpc0 kernel: TCP established hash table entries: 8192 (order: 3, 32768 bytes)
Dec 31 16:00:35 fpc0 kernel: TCP bind hash table entries: 8192 (order: 4, 98304 bytes)
Dec 31 16:00:35 fpc0 kernel: TCP: Hash tables configured (established 8192 bind 8192)
Dec 31 16:00:35 fpc0 kernel: TCP: reno registered
Dec 31 16:00:35 fpc0 kernel: UDP hash table entries: 512 (order: 2, 16384 bytes)
Dec 31 16:00:35 fpc0 kernel: UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
Dec 31 16:00:35 fpc0 kernel: NET: Registered protocol family 1
Dec 31 16:00:35 fpc0 kernel: RPC: Registered named UNIX socket transport module.
Dec 31 16:00:35 fpc0 kernel: RPC: Registered udp transport module.
Dec 31 16:00:35 fpc0 kernel: RPC: Registered tcp transport module.
Dec 31 16:00:35 fpc0 kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
Dec 31 16:00:35 fpc0 kernel: PCI: CLS 0 bytes, default 32
Dec 31 16:00:35 fpc0 kernel: Trying to unpack rootfs image as initramfs...
Dec 31 16:00:35 fpc0 kernel: Freeing initrd memory: 313236K (dce1a000 - effff000)
Dec 31 16:00:35 fpc0 kernel: futex hash table entries: 512 (order: 2, 16384 bytes)
Dec 31 16:00:35 fpc0 kernel: audit: initializing netlink subsys (disabled)
Dec 31 16:00:35 fpc0 kernel: audit: type=2000 audit(19.136:1): initialized
Dec 31 16:00:35 fpc0 kernel: squashfs: version 4.0 (2009/01/31) Phillip Lougher
Dec 31 16:00:35 fpc0 kernel: NFS: Registering the id_resolver key type
Dec 31 16:00:35 fpc0 kernel: Key type id_resolver registered
Dec 31 16:00:35 fpc0 kernel: Key type id_legacy registered
Dec 31 16:00:35 fpc0 kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Dec 31 16:00:35 fpc0 kernel: fuse init (API version 7.23)
Dec 31 16:00:35 fpc0 kernel: bounce: pool size: 64 pages
Dec 31 16:00:35 fpc0 kernel: io scheduler noop registered
Dec 31 16:00:35 fpc0 kernel: io scheduler deadline registered
Dec 31 16:00:35 fpc0 kernel: io scheduler cfq registered (default)
Dec 31 16:00:35 fpc0 kernel: pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Dec 31 16:00:35 fpc0 kernel: Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
Dec 31 16:00:35 fpc0 kernel: console [ttyS0] disabled
Dec 31 16:00:35 fpc0 kernel: serial8250.0: ttyS0 at MMIO 0xfff704500 (irq = 42, base_baud = 25000000) is a 16550A
Dec 31 16:00:35 fpc0 kernel: console [ttyS0] enabled
Dec 31 16:00:35 fpc0 kernel: bootconsole [udbg0] disabled
Dec 31 16:00:35 fpc0 kernel: serial8250.0: ttyS1 at MMIO 0xfff704600 (irq = 42, base_baud = 25000000) is a 16550A
Dec 31 16:00:35 fpc0 kernel: Generic non-volatile memory driver v1.1
Dec 31 16:00:35 fpc0 kernel: brd: module loaded
Dec 31 16:00:35 fpc0 kernel: loop: module loaded
Dec 31 16:00:35 fpc0 kernel: ptxpmb-cpld fff000000.cpld: Revision 0x07 carrier type 0x10 [FPC]
Dec 31 16:00:35 fpc0 kernel: st: Version 20101219, fixed bufsize 32768, s/g segs 256
Dec 31 16:00:35 fpc0 kernel: 1 ofpart partitions found on MTD device fff100000.nvram
Dec 31 16:00:35 fpc0 kernel: Creating 1 MTD partitions on "fff100000.nvram":
Dec 31 16:00:35 fpc0 kernel: 0x000000000000-0x000000040000 : "nvram"
Dec 31 16:00:35 fpc0 kernel: ftl_cs: FTL header not found.
Dec 31 16:00:35 fpc0 kernel: fff800000.flash: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000020 Chip ID 0x000056
Dec 31 16:00:35 fpc0 kernel: Amd/Fujitsu Extended Query Table at 0x0040
Dec 31 16:00:35 fpc0 kernel:   Amd/Fujitsu Extended Query version 1.1.
Dec 31 16:00:35 fpc0 kernel: fff800000.flash: Swapping erase regions for top-boot CFI table.
Dec 31 16:00:35 fpc0 kernel: number of CFI chips: 1
Dec 31 16:00:35 fpc0 kernel: 2 ofpart partitions found on MTD device fff800000.flash
Dec 31 16:00:35 fpc0 kernel: Creating 2 MTD partitions on "fff800000.flash":
Dec 31 16:00:35 fpc0 kernel: 0x000000000000-0x000000380000 : "unused"
Dec 31 16:00:35 fpc0 kernel: ftl_cs: FTL header not found.
Dec 31 16:00:35 fpc0 kernel: 0x000000380000-0x000000400000 : "uboot"
Dec 31 16:00:35 fpc0 kernel: ftl_cs: FTL header not found.
Dec 31 16:00:35 fpc0 kernel: ffff80000.flash: Found 1 x16 devices at 0x0 in 8-bit bank. Manufacturer ID 0x000001 Chip ID 0x0000da
Dec 31 16:00:35 fpc0 kernel: NOR chip too large to fit in mapping. Attempting to cope...
Dec 31 16:00:35 fpc0 kernel: Amd/Fujitsu Extended Query Table at 0x0040
Dec 31 16:00:35 fpc0 kernel:   Amd/Fujitsu Extended Query version 1.3.
Dec 31 16:00:35 fpc0 kernel: ffff80000.flash: Swapping erase regions for top-boot CFI table.
Dec 31 16:00:35 fpc0 kernel: number of CFI chips: 1
Dec 31 16:00:35 fpc0 kernel: Reducing visibility of 1024KiB chip to 512KiB
Dec 31 16:00:35 fpc0 kernel: 1 ofpart partitions found on MTD device ffff80000.flash
Dec 31 16:00:35 fpc0 kernel: Creating 1 MTD partitions on "ffff80000.flash":
Dec 31 16:00:35 fpc0 kernel: 0x000000000000-0x000000080000 : "uboot"
Dec 31 16:00:35 fpc0 kernel: ftl_cs: FTL header not found.
Dec 31 16:00:35 fpc0 kernel: libphy: Fixed MDIO Bus: probed
Dec 31 16:00:35 fpc0 kernel: libphy: Freescale PowerQUICC MII Bus: probed
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff724000.dTSEC0: enabled errata workarounds, flags: 0x4
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff724000.dTSEC0 eth0: mac: 02:00:00:00:00:10
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff724000.dTSEC0 eth0: Running with NAPI enabled
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff724000.dTSEC0 eth0: RX BD ring size for Q[0]: 256
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff724000.dTSEC0 eth0: TX BD ring size for Q[0]: 256
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff725000.dTSEC1: enabled errata workarounds, flags: 0x4
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff725000.dTSEC1 eth1: mac: 02:00:01:00:00:10
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff725000.dTSEC1 eth1: Running with NAPI enabled
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff725000.dTSEC1 eth1: RX BD ring size for Q[0]: 256
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff725000.dTSEC1 eth1: TX BD ring size for Q[0]: 256
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff726000.dTSEC2: enabled errata workarounds, flags: 0x4
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff726000.dTSEC2 eth2: mac: 02:00:00:00:00:10
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff726000.dTSEC2 eth2: Running with NAPI enabled
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff726000.dTSEC2 eth2: RX BD ring size for Q[0]: 256
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff726000.dTSEC2 eth2: TX BD ring size for Q[0]: 256
Dec 31 16:00:35 fpc0 kernel: i2c /dev entries driver
Dec 31 16:00:35 fpc0 kernel: mpc-i2c fff703000.i2c-master-0: timeout 1000000 us
Dec 31 16:00:35 fpc0 kernel: mpc-i2c fff703100.i2c-master-1: timeout 1000000 us
Dec 31 16:00:35 fpc0 kernel: at24 2-0051: 256 byte 24c02 EEPROM, writable, 1 bytes/write
Dec 31 16:00:35 fpc0 kernel: at24 2-0052: 256 byte 24c02 EEPROM, writable, 1 bytes/write
Dec 31 16:00:35 fpc0 kernel: i2c i2c-2: Added multiplexed i2c bus 3
Dec 31 16:00:35 fpc0 kernel: i2c i2c-2: Added multiplexed i2c bus 4
Dec 31 16:00:35 fpc0 kernel: i2c i2c-2: Added multiplexed i2c bus 5
Dec 31 16:00:35 fpc0 kernel: i2c i2c-2: Added multiplexed i2c bus 6
Dec 31 16:00:35 fpc0 kernel: i2c i2c-2: Added multiplexed i2c bus 7
Dec 31 16:00:35 fpc0 kernel: i2c i2c-2: Added multiplexed i2c bus 8
Dec 31 16:00:35 fpc0 kernel: i2c i2c-2: Added multiplexed i2c bus 9
Dec 31 16:00:35 fpc0 kernel: i2c i2c-2: Added multiplexed i2c bus 10
Dec 31 16:00:35 fpc0 kernel: pca954x 2-0076: registered 8 multiplexed busses for I2C switch pca9548
Dec 31 16:00:35 fpc0 kernel: i2c i2c-0: Added multiplexed i2c bus 2
Dec 31 16:00:35 fpc0 kernel: i2c i2c-0: Added multiplexed i2c bus 11
Dec 31 16:00:35 fpc0 kernel: i2c i2c-0: Added multiplexed i2c bus 12
Dec 31 16:00:35 fpc0 kernel: i2c i2c-0: Added multiplexed i2c bus 13
Dec 31 16:00:35 fpc0 kernel: i2c i2c-0: Added multiplexed i2c bus 14
Dec 31 16:00:35 fpc0 kernel: i2c i2c-0: Added multiplexed i2c bus 15
Dec 31 16:00:35 fpc0 kernel: i2c i2c-0: Added multiplexed i2c bus 16
Dec 31 16:00:35 fpc0 kernel: i2c i2c-0: Added multiplexed i2c bus 17
Dec 31 16:00:35 fpc0 kernel: platform max1139@35: Driver iio_hwmon requests probe deferral
Dec 31 16:00:35 fpc0 kernel: random: nonblocking pool is initialized
Dec 31 16:00:35 fpc0 kernel: booke_wdt: powerpc book-e watchdog driver loaded
Dec 31 16:00:35 fpc0 kernel: jnx-ptxpmb-wdt jnx-ptxpmb-wdt: initialized
Dec 31 16:00:35 fpc0 kernel: nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
Dec 31 16:00:35 fpc0 kernel: ipip: IPv4 over IPv4 tunneling driver
Dec 31 16:00:35 fpc0 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
Dec 31 16:00:35 fpc0 kernel: ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
Dec 31 16:00:35 fpc0 kernel: arp_tables: (C) 2002 David S. Miller
Dec 31 16:00:35 fpc0 kernel: TCP: cubic registered
Dec 31 16:00:35 fpc0 kernel: Initializing XFRM netlink socket
Dec 31 16:00:35 fpc0 kernel: NET: Registered protocol family 10
Dec 31 16:00:35 fpc0 kernel: sit: IPv6 over IPv4 tunneling driver
Dec 31 16:00:35 fpc0 kernel: NET: Registered protocol family 17
Dec 31 16:00:35 fpc0 kernel: NET: Registered protocol family 15
Dec 31 16:00:35 fpc0 kernel: bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
Dec 31 16:00:35 fpc0 kernel: Ebtables v2.0 registered
Dec 31 16:00:35 fpc0 kernel: 8021q: 802.1Q VLAN Support v1.8
Dec 31 16:00:35 fpc0 kernel: Key type dns_resolver registered
Dec 31 16:00:35 fpc0 kernel: registered taskstats version 1
Dec 31 16:00:35 fpc0 kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Dec 31 16:00:35 fpc0 kernel: fsl-gianfar fff724000.dTSEC0 eth0: Link is Up - 100Mbps/Half - flow control off
Dec 31 16:00:35 fpc0 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Dec 31 16:00:35 fpc0 kernel: IP-Config: Complete:
Dec 31 16:00:35 fpc0 kernel:      device=eth0, hwaddr=02:00:00:00:00:10, ipaddr=128.0.0.16, mask=192.0.0.0, gw=128.0.0.4
Dec 31 16:00:35 fpc0 kernel:      host=fpc0, domain=, nis-domain=(none)
Dec 31 16:00:35 fpc0 kernel:      bootserver=128.0.0.4, rootserver=128.0.0.4, rootpath=
Dec 31 16:00:35 fpc0 kernel: Freeing unused kernel memory: 276K (c0643000 - c0688000)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BAR 7 io space assignment errors
  2015-05-15 20:04   ` Guenter Roeck
@ 2015-05-15 22:11     ` Bjorn Helgaas
  2015-05-16  2:27       ` Guenter Roeck
  0 siblings, 1 reply; 9+ messages in thread
From: Bjorn Helgaas @ 2015-05-15 22:11 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: linux-pci@vger.kernel.org, Yinghai Lu

On Fri, May 15, 2015 at 01:04:22PM -0700, Guenter Roeck wrote:
> Hi Bjorn,
> 
> On Fri, May 15, 2015 at 02:25:34PM -0500, Bjorn Helgaas wrote:
> > [+cc Yinghai]
> > 
> > Hi Guenter,
> > 
> > On Fri, May 15, 2015 at 12:28 PM, Guenter Roeck <groeck@juniper.net> wrote:
> > > Hi all,
> > >
> > > ever since 3.18(ish), we see lots of pcie io range allocation error messages
> > > when booting our systems.
> > >
> > > pcieport 0000:02:00.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
> > > pcieport 0000:02:00.0: BAR 7: no space for [io  size 0x1000]
> > > pcieport 0000:02:00.0: BAR 7: failed to assign [io  size 0x1000]
> > >
> > > This is repeated for each port.
> > >
> > > What we atually _want_ is no IO address range, but so far I have not been able to
> > > tell this to the code (or to the bridge).
> > 
> > What information does the core have that we could use to figure out
> > that you want no I/O space?  For example, does the host bridge have no
> > I/O apertures?  Or are there no devices below 02:00.0 that require I/O
> > space?  If you can post a complete dmesg log, that should contain this
> > information.
> > 
> We know that we don't need IO space behind the bridge.
> 
> Question would be what information the core would need. I have tried
> to pre-program PCI_IO_BASE and PCI_IO_LIMIT on the bridge ports,
> but that doesn't seem to be the right solution (and it was just a
> wild shot anyway ;-).

The core tries to assign address space before drivers start claiming
devices because it's very difficult to move devices after drivers are
attached.  To avoid assigning I/O space to a bridge, the core would have to
know that (1) no devices below the bridge have I/O BARs, and (2) there's no
hotplug slot where a new device could be added below the bridge.

In your specific case, I suspect that you have hotplug bridges, but you
*know* exactly what devices can be "hot-plugged" and you know they don't
need I/O space.  But there's no good way to tell that to the PCI core.

> > Is the problem that some device doesn't work, or is it just extra
> > annoying messages.  We should fix something in either case, of course,
> > but it's more urgent if a device used to work but no longer does.
> > 
> Just the extra annoying messages. The messages below are just the beginning;
> there are many more when the actual devices behind the bridge ports come
> online.

This sounds like an interesting topology.  A device coming online later is
a hotplug event from the core's point of view.  Since the core can't tell
what a hot-added device is going to be, it allocates a default amount of
space (pci_hotplug_io_size) to accomodate it.  You can influence that with
the "pci=hpiosize=" boot parameter.  Maybe "pci=hpiosize=0" would help in
your case, but we'd still have the problem that the messages don't make
sense to the average user (including me).

  fsl-pci fff70a000.pcie: PCI host bridge to bus 0000:00
  pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
  pci 0000:00:00.0: PCI bridge to [bus 01-ff]      # Root Port
  pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]

The host bridge does have an I/O aperture, and it looks like firmware set
up the 00:00.0 bridge with a small piece of that.  That's sort of a waste:
supposedly we have 64K of I/O space available on bus 00, and 4K of that is
routed to [bus 01-ff].  The other 60K could be used by other devices on bus
00, but it doesn't look like there *are* any, so it is wasted.

  pci 0000:01:00.0: PCI bridge to [bus 02-ff]      # Upstream Port
  pci 0000:02:00.0: PCI bridge to [bus 40-4f]      # Downstream Port 0x0
  ...
  pci 0000:02:0d.0: PCI bridge to [bus a0-af]      # Downstream Port 0xa

  pci 0000:02:00.0: bridge window [io  0x1000-0x0fff] to [bus 40-4f] add_size 1000
  ...
  pci 0000:02:0d.0: bridge window [io  0x1000-0x0fff] to [bus a0-af] add_size 1000

I'm guessing these Downstream Ports all have "is_hotplug_bridge" set
because they have the "Hot-Plug Capable" bit set in their Slot Capabilities
register.  We're trying to allocate 0x1000 I/O ports for each, and there
are 0xb of them, so we'd need 0xb000 I/O ports at the 01:00.0 bridge:

  pci 0000:01:00.0: bridge window [io  0x1000-0x0fff] to [bus 02-ff] add_size b000

pci_hotplug_io_size defaults to 256, but standard PCI bridges don't support
I/O windows smaller than 4K, so they all got rounded up to 4K (0x1000).

I would love it if somebody would clean up those messages and make them all
consistent.  There's useful information there, so I'm not sure we want to
get rid of them, but I think there's some redundancy we might be able to
fix.

Bjorn

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BAR 7 io space assignment errors
  2015-05-15 22:11     ` Bjorn Helgaas
@ 2015-05-16  2:27       ` Guenter Roeck
  2015-05-16 13:12         ` Bjorn Helgaas
  0 siblings, 1 reply; 9+ messages in thread
From: Guenter Roeck @ 2015-05-16  2:27 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: linux-pci@vger.kernel.org, Yinghai Lu

On Fri, May 15, 2015 at 05:11:49PM -0500, Bjorn Helgaas wrote:
> On Fri, May 15, 2015 at 01:04:22PM -0700, Guenter Roeck wrote:
> > Hi Bjorn,
> > 
> > On Fri, May 15, 2015 at 02:25:34PM -0500, Bjorn Helgaas wrote:
> > > [+cc Yinghai]
> > > 
> > > Hi Guenter,
> > > 
> > > On Fri, May 15, 2015 at 12:28 PM, Guenter Roeck <groeck@juniper.net> wrote:
> > > > Hi all,
> > > >
> > > > ever since 3.18(ish), we see lots of pcie io range allocation error messages
> > > > when booting our systems.
> > > >
> > > > pcieport 0000:02:00.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
> > > > pcieport 0000:02:00.0: BAR 7: no space for [io  size 0x1000]
> > > > pcieport 0000:02:00.0: BAR 7: failed to assign [io  size 0x1000]
> > > >
> > > > This is repeated for each port.
> > > >
> > > > What we atually _want_ is no IO address range, but so far I have not been able to
> > > > tell this to the code (or to the bridge).
> > > 
> > > What information does the core have that we could use to figure out
> > > that you want no I/O space?  For example, does the host bridge have no
> > > I/O apertures?  Or are there no devices below 02:00.0 that require I/O
> > > space?  If you can post a complete dmesg log, that should contain this
> > > information.
> > > 
> > We know that we don't need IO space behind the bridge.
> > 
> > Question would be what information the core would need. I have tried
> > to pre-program PCI_IO_BASE and PCI_IO_LIMIT on the bridge ports,
> > but that doesn't seem to be the right solution (and it was just a
> > wild shot anyway ;-).
> 
> The core tries to assign address space before drivers start claiming
> devices because it's very difficult to move devices after drivers are
> attached.  To avoid assigning I/O space to a bridge, the core would have to
> know that (1) no devices below the bridge have I/O BARs, and (2) there's no
> hotplug slot where a new device could be added below the bridge.
> 
> In your specific case, I suspect that you have hotplug bridges, but you
> *know* exactly what devices can be "hot-plugged" and you know they don't
> need I/O space.  But there's no good way to tell that to the PCI core.
> 
Yes, most of the devices are not really hotplug devices but ASICs
or FPGAs which just come online later.

> > > Is the problem that some device doesn't work, or is it just extra
> > > annoying messages.  We should fix something in either case, of course,
> > > but it's more urgent if a device used to work but no longer does.
> > > 
> > Just the extra annoying messages. The messages below are just the beginning;
> > there are many more when the actual devices behind the bridge ports come
> > online.
> 
> This sounds like an interesting topology.  A device coming online later is
> a hotplug event from the core's point of view.  Since the core can't tell
> what a hot-added device is going to be, it allocates a default amount of
> space (pci_hotplug_io_size) to accomodate it.  You can influence that with
> the "pci=hpiosize=" boot parameter.  Maybe "pci=hpiosize=0" would help in
> your case, but we'd still have the problem that the messages don't make
> sense to the average user (including me).
> 
Also, I don't really want to specify lots of boot parameters if I can avoid it.

>   fsl-pci fff70a000.pcie: PCI host bridge to bus 0000:00
>   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>   pci 0000:00:00.0: PCI bridge to [bus 01-ff]      # Root Port
>   pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
> 
> The host bridge does have an I/O aperture, and it looks like firmware set
> up the 00:00.0 bridge with a small piece of that.  That's sort of a waste:
> supposedly we have 64K of I/O space available on bus 00, and 4K of that is
> routed to [bus 01-ff].  The other 60K could be used by other devices on bus
> 00, but it doesn't look like there *are* any, so it is wasted.
> 
The problem is that I can not reprogram PCI_IO_BASE on 0000:00:00.0.
Here is a debug log:

pci 0000:00:00.0: io base written 0xe0f0 reads back as 0x0
pci 0000:00:00.0: io base written 0xf000 reads back as 0x0

The io ranges of ports behind it (ie the ones below) are programmable.
I can try to find out if there is a means to program the io range
on 0000:00:00.0, but I would prefer to just disable the io range for
everything downstream of it.

>   pci 0000:01:00.0: PCI bridge to [bus 02-ff]      # Upstream Port
>   pci 0000:02:00.0: PCI bridge to [bus 40-4f]      # Downstream Port 0x0
>   ...
>   pci 0000:02:0d.0: PCI bridge to [bus a0-af]      # Downstream Port 0xa
> 
>   pci 0000:02:00.0: bridge window [io  0x1000-0x0fff] to [bus 40-4f] add_size 1000
>   ...
>   pci 0000:02:0d.0: bridge window [io  0x1000-0x0fff] to [bus a0-af] add_size 1000
> 
> I'm guessing these Downstream Ports all have "is_hotplug_bridge" set
> because they have the "Hot-Plug Capable" bit set in their Slot Capabilities
> register.  We're trying to allocate 0x1000 I/O ports for each, and there

Correct.

> are 0xb of them, so we'd need 0xb000 I/O ports at the 01:00.0 bridge:
> 

>   pci 0000:01:00.0: bridge window [io  0x1000-0x0fff] to [bus 02-ff] add_size b000
> 
> pci_hotplug_io_size defaults to 256, but standard PCI bridges don't support
> I/O windows smaller than 4K, so they all got rounded up to 4K (0x1000).
> 
> I would love it if somebody would clean up those messages and make them all
> consistent.  There's useful information there, so I'm not sure we want to
> get rid of them, but I think there's some redundancy we might be able to
> fix.
> 
"bridge window [io  0x1000-0x0fff]" for sure looks odd. Maybe it means
something to you, but for me it is just confusing.

Guenter

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BAR 7 io space assignment errors
  2015-05-16  2:27       ` Guenter Roeck
@ 2015-05-16 13:12         ` Bjorn Helgaas
  2015-05-16 16:41           ` Guenter Roeck
  0 siblings, 1 reply; 9+ messages in thread
From: Bjorn Helgaas @ 2015-05-16 13:12 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: linux-pci@vger.kernel.org, Yinghai Lu

On Fri, May 15, 2015 at 07:27:13PM -0700, Guenter Roeck wrote:
> On Fri, May 15, 2015 at 05:11:49PM -0500, Bjorn Helgaas wrote:
> > This sounds like an interesting topology.  A device coming online later is
> > a hotplug event from the core's point of view.  Since the core can't tell
> > what a hot-added device is going to be, it allocates a default amount of
> > space (pci_hotplug_io_size) to accomodate it.  You can influence that with
> > the "pci=hpiosize=" boot parameter.  Maybe "pci=hpiosize=0" would help in
> > your case, but we'd still have the problem that the messages don't make
> > sense to the average user (including me).
> > 
> Also, I don't really want to specify lots of boot parameters if I can avoid it.

Yes, I agree completely.  I hate boot parameters.

> >   fsl-pci fff70a000.pcie: PCI host bridge to bus 0000:00
> >   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> >   pci 0000:00:00.0: PCI bridge to [bus 01-ff]      # Root Port
> >   pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
> > 
> > The host bridge does have an I/O aperture, and it looks like firmware set
> > up the 00:00.0 bridge with a small piece of that.  That's sort of a waste:
> > supposedly we have 64K of I/O space available on bus 00, and 4K of that is
> > routed to [bus 01-ff].  The other 60K could be used by other devices on bus
> > 00, but it doesn't look like there *are* any, so it is wasted.
> > 
> The problem is that I can not reprogram PCI_IO_BASE on 0000:00:00.0.
> Here is a debug log:
> 
> pci 0000:00:00.0: io base written 0xe0f0 reads back as 0x0
> pci 0000:00:00.0: io base written 0xf000 reads back as 0x0

That's odd; that's a non-conformant bridge.  Per spec (PCI-to-PCI Bridge
r1.2, sec 3.2.5.6), for a bridge that implements an I/O address range, the
upper four bits of I/O Base is writable.

But I suspect this bridge is discovered via OF and there's something broken
about how config access is done.  That's arch code and I don't know much
about it.

Or maybe the hardware itself is not quite spec-compliant, although it would
be strange to have I/O aperture addresses hard-wired into the hardware.  

> The io ranges of ports behind it (ie the ones below) are programmable.
> I can try to find out if there is a means to program the io range
> on 0000:00:00.0, but I would prefer to just disable the io range for
> everything downstream of it.

As far as I can tell, you don't need any I/O port space anywhere in this
hierarchy.  If you could disable this host bridge I/O aperture:

  PCI host bridge /pcie@a000 (primary) ranges:
    IO 0x0000000fffc00000..0x0000000fffc0ffff -> 0x0000000000000000

e.g., remove it from the OF description of the bridge, the core could know
that it needn't bother trying to assign I/O space.  It might not be smart
enough to notice that today, but it would at least be possible in
principle.

> "bridge window [io  0x1000-0x0fff]" for sure looks odd. Maybe it means
> something to you, but for me it is just confusing.

"The I/O Limit register can be programmed to a smaller value than the I/O
Base register, if there are no I/O addresses on the secondary side of the
bridge."  So this would ordinarily mean the I/O window is disabled.  But I
agree, this is a confusing way to say it.

Bjorn

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BAR 7 io space assignment errors
  2015-05-16 13:12         ` Bjorn Helgaas
@ 2015-05-16 16:41           ` Guenter Roeck
  2015-05-18 15:55             ` Bjorn Helgaas
  0 siblings, 1 reply; 9+ messages in thread
From: Guenter Roeck @ 2015-05-16 16:41 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: linux-pci@vger.kernel.org, Yinghai Lu

Hi Bjorn,

On Sat, May 16, 2015 at 08:12:09AM -0500, Bjorn Helgaas wrote:
> > The problem is that I can not reprogram PCI_IO_BASE on 0000:00:00.0.
> > Here is a debug log:
> > 
> > pci 0000:00:00.0: io base written 0xe0f0 reads back as 0x0
> > pci 0000:00:00.0: io base written 0xf000 reads back as 0x0
> 
> That's odd; that's a non-conformant bridge.  Per spec (PCI-to-PCI Bridge
> r1.2, sec 3.2.5.6), for a bridge that implements an I/O address range, the
> upper four bits of I/O Base is writable.
> 
> But I suspect this bridge is discovered via OF and there's something broken
> about how config access is done.  That's arch code and I don't know much
> about it.
> 
Maybe. I'll dig into it some more.

> Or maybe the hardware itself is not quite spec-compliant, although it would
> be strange to have I/O aperture addresses hard-wired into the hardware.  
> 
This is a Freesale P2020. We should have the specification somewhere.
Guess it may be time for some digging in there.

> > The io ranges of ports behind it (ie the ones below) are programmable.
> > I can try to find out if there is a means to program the io range
> > on 0000:00:00.0, but I would prefer to just disable the io range for
> > everything downstream of it.
> 
> As far as I can tell, you don't need any I/O port space anywhere in this
> hierarchy.  If you could disable this host bridge I/O aperture:
> 
>   PCI host bridge /pcie@a000 (primary) ranges:
>     IO 0x0000000fffc00000..0x0000000fffc0ffff -> 0x0000000000000000
> 
> e.g., remove it from the OF description of the bridge, the core could know
> that it needn't bother trying to assign I/O space.  It might not be smart
> enough to notice that today, but it would at least be possible in
> principle.
> 
I tried this. Unfortunately, the PCI core code still tries to assign
the IO space to all ports downstream of it, and I end up with the same
problem, ie lots of BAR 7 messages.

PCI host bridge /pcie@a000 (primary) ranges:
 MEM 0x0000000c00000000..0x0000000c3fffffff -> 0x0000000080000000 
...
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
pci 0000:00:00.0:   bridge window [mem 0xc00000000-0xc3fffffff]
pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]

Partially this is because pci_read_bridge_io() doesn't care if IO is supported
or not - it reads 0x0 from the IO_BASE/IO_LIMIT register and interprets it as 
0x0000-0x0fff range. Even if I change pci_read_bridge_io() to not add an io
range if base == limit == 0, the result is not much better. Then I get

pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0:   bridge window [mem 0xc00000000-0xc3fffffff]
pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]

and no BAR 7 message for the root port, but still for all other ports.

> > "bridge window [io  0x1000-0x0fff]" for sure looks odd. Maybe it means
> > something to you, but for me it is just confusing.
> 
> "The I/O Limit register can be programmed to a smaller value than the I/O
> Base register, if there are no I/O addresses on the secondary side of the
> bridge."  So this would ordinarily mean the I/O window is disabled.  But I
> agree, this is a confusing way to say it.
> 
Yes, but there is no way to tell the core to keep that IO disabled. Even if
I explicitly disable it on a port by writing limit < base into PCI_IO_BASE /
PCI_IO_LIMIT, pci_bridge_check_ranges() simply overwrites it. It also does
not care if the root bridge has no io space assigned to it - it still tries
to assign IO space to each downstream port and then complains that it
doesn't work.

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BAR 7 io space assignment errors
  2015-05-16 16:41           ` Guenter Roeck
@ 2015-05-18 15:55             ` Bjorn Helgaas
  2015-05-19  0:18               ` Guenter Roeck
  0 siblings, 1 reply; 9+ messages in thread
From: Bjorn Helgaas @ 2015-05-18 15:55 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: linux-pci@vger.kernel.org, Yinghai Lu

On Sat, May 16, 2015 at 09:41:51AM -0700, Guenter Roeck wrote:
> Hi Bjorn,
> 
> On Sat, May 16, 2015 at 08:12:09AM -0500, Bjorn Helgaas wrote:
> > > The problem is that I can not reprogram PCI_IO_BASE on 0000:00:00.0.
> > > Here is a debug log:
> > > 
> > > pci 0000:00:00.0: io base written 0xe0f0 reads back as 0x0
> > > pci 0000:00:00.0: io base written 0xf000 reads back as 0x0
> > 
> > That's odd; that's a non-conformant bridge.  Per spec (PCI-to-PCI Bridge
> > r1.2, sec 3.2.5.6), for a bridge that implements an I/O address range, the
> > upper four bits of I/O Base is writable.
> > 
> > But I suspect this bridge is discovered via OF and there's something broken
> > about how config access is done.  That's arch code and I don't know much
> > about it.
> > 
> Maybe. I'll dig into it some more.
> 
> > Or maybe the hardware itself is not quite spec-compliant, although it would
> > be strange to have I/O aperture addresses hard-wired into the hardware.  
> > 
> This is a Freesale P2020. We should have the specification somewhere.
> Guess it may be time for some digging in there.

Hmm, I spoke too fast above.  I assumed that we checked whether the
bridge actually implements an I/O aperture, but pci_read_bridge_io()
doesn't do that.  On a bridge that doesn't implement an I/O range, both I/O
Base and I/O Limit must be read-only zeroes.  But pci_read_bridge_io()
doesn't test whether they are writable, so it treats that situation as an
enabled [io 0x0000-0x0fff] window.

pci_bridge_check_ranges() *does* check for writability, but it might be
too late to make a difference in this case.  I would like to get rid of 
pci_bridge_check_ranges() anyway; it seems like whatever it does should be
folded into pci_read_bridge_io() and pci_read_bridge_mmio_pref().

Bottom line, 

1) I don't know whether your bridge actually implements an I/O aperture,
and 2) I think pci_read_bridge_io() should check for writability.

> > > The io ranges of ports behind it (ie the ones below) are programmable.
> > > I can try to find out if there is a means to program the io range
> > > on 0000:00:00.0, but I would prefer to just disable the io range
> > > fpci_bridge_check_rangesor
> > > everything downstream of it.
> > 
> > As far as I can tell, you don't need any I/O port space anywhere in this
> > hierarchy.  If you could disable this host bridge I/O aperture:
> > 
> >   PCI host bridge /pcie@a000 (primary) ranges:
> >     IO 0x0000000fffc00000..0x0000000fffc0ffff -> 0x0000000000000000
> > 
> > e.g., remove it from the OF description of the bridge, the core could know
> > that it needn't bother trying to assign I/O space.  It might not be smart
> > enough to notice that today, but it would at least be possible in
> > principle.
> > 
> I tried this. Unfortunately, the PCI core code still tries to assign
> the IO space to all ports downstream of it, and I end up with the same
> problem, ie lots of BAR 7 messages.

Yep, sounds like the core isn't smart enough to notice that.  But it
*could* and probably should be.

> PCI host bridge /pcie@a000 (primary) ranges:
>  MEM 0x0000000c00000000..0x0000000c3fffffff -> 0x0000000080000000 
> ...
> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> pci 0000:00:00.0:   bridge window [io  0x0000-0x0fff]
> pci 0000:00:00.0:   bridge window [mem 0xc00000000-0xc3fffffff]
> pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
> 
> Partially this is because pci_read_bridge_io() doesn't care if IO is supported
> or not - it reads 0x0 from the IO_BASE/IO_LIMIT register and interprets it as 
> 0x0000-0x0fff range. Even if I change pci_read_bridge_io() to not add an io
> range if base == limit == 0, the result is not much better. Then I get
> 
> pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> pci 0000:00:00.0:   bridge window [mem 0xc00000000-0xc3fffffff]
> pci 0000:00:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
> 
> and no BAR 7 message for the root port, but still for all other ports.

Right.  All the other bridges (01:00.0, 02:00.0, etc.) have a non-zero I/O
Base, so they clearly implement I/O apertures.  We should make the core
smart enough to stop trying to assign I/O space when there's none
available.

We just have to figure out the best way to do that.  If we find a bridge
(either host bridge or PCI-PCI bridge) that doesn't implement an I/O
aperture, we should be able to just ignore I/O space below it.  If we find
one with a disabled aperture, we probably want to size the downstream
devices and potentially enable the aperture.

Bjorn

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: BAR 7 io space assignment errors
  2015-05-18 15:55             ` Bjorn Helgaas
@ 2015-05-19  0:18               ` Guenter Roeck
  0 siblings, 0 replies; 9+ messages in thread
From: Guenter Roeck @ 2015-05-19  0:18 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: linux-pci@vger.kernel.org, Yinghai Lu

On Mon, May 18, 2015 at 10:55:46AM -0500, Bjorn Helgaas wrote:
> On Sat, May 16, 2015 at 09:41:51AM -0700, Guenter Roeck wrote:
> > Hi Bjorn,
> > 
> > On Sat, May 16, 2015 at 08:12:09AM -0500, Bjorn Helgaas wrote:
> > > > The problem is that I can not reprogram PCI_IO_BASE on 0000:00:00.0.
> > > > Here is a debug log:
> > > > 
> > > > pci 0000:00:00.0: io base written 0xe0f0 reads back as 0x0
> > > > pci 0000:00:00.0: io base written 0xf000 reads back as 0x0
> > > 
> > > That's odd; that's a non-conformant bridge.  Per spec (PCI-to-PCI Bridge
> > > r1.2, sec 3.2.5.6), for a bridge that implements an I/O address range, the
> > > upper four bits of I/O Base is writable.
> > > 
> > > But I suspect this bridge is discovered via OF and there's something broken
> > > about how config access is done.  That's arch code and I don't know much
> > > about it.
> > > 
> > Maybe. I'll dig into it some more.
> > 
> > > Or maybe the hardware itself is not quite spec-compliant, although it would
> > > be strange to have I/O aperture addresses hard-wired into the hardware.  
> > > 
> > This is a Freesale P2020. We should have the specification somewhere.
> > Guess it may be time for some digging in there.
> 
> Hmm, I spoke too fast above.  I assumed that we checked whether the
> bridge actually implements an I/O aperture, but pci_read_bridge_io()
> doesn't do that.  On a bridge that doesn't implement an I/O range, both I/O
> Base and I/O Limit must be read-only zeroes.  But pci_read_bridge_io()
> doesn't test whether they are writable, so it treats that situation as an
> enabled [io 0x0000-0x0fff] window.
> 
> pci_bridge_check_ranges() *does* check for writability, but it might be
> too late to make a difference in this case.  I would like to get rid of 
> pci_bridge_check_ranges() anyway; it seems like whatever it does should be
> folded into pci_read_bridge_io() and pci_read_bridge_mmio_pref().
> 
> Bottom line, 
> 
> 1) I don't know whether your bridge actually implements an I/O aperture,

I don't think it does.

> and 2) I think pci_read_bridge_io() should check for writability.
> 

Something like the patch below ? It seems to address my problem. At the
same time it tries to be minimalistic, ie if a bridge is already configured
for an IO window it will still try to assign it (and the message will still
be seen), even if its parent does not support it (or has it disabled).

I don't know if there is a better way to check if a port supports IO.
If there is, please let me know.

Thanks,
Guenter

---
>From 4d9c3f95290d13c0bbd3a0a6c8043ccb2b53d06f Mon Sep 17 00:00:00 2001
From: Guenter Roeck <groeck@juniper.net>
Date: Mon, 18 May 2015 13:27:27 -0700
Subject: [PATCH] pci: Only enable IO window if supported

The PCI subsystem always assumes that I/O is suported and tries
to assign an I/O window to a bus even if that is not the case.

This may result in messages such as

pcieport 0000:02:00.0: res[7]=[io  0x1000-0x0fff] get_res_add_size add_size 1000
pcieport 0000:02:00.0: BAR 7: no space for [io  size 0x1000]
pcieport 0000:02:00.0: BAR 7: failed to assign [io  size 0x1000]

for each port, even if one of its parent ports does not support I/O
in the first place.

To avoid this message, check if a port supports I/O before enabling I/O
on it. Also check if port's parent supports I/O, and only modify its I/O
resource size if it does.

Signed-off-by: Guenter Roeck <groeck@juniper.net>
---
 drivers/pci/probe.c     |   14 ++++++++++++++
 drivers/pci/setup-bus.c |    2 +-
 include/linux/pci.h     |    9 +++++++++
 3 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index afae480..1eb9fc6 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -354,6 +354,20 @@ static void pci_read_bridge_io(struct pci_bus *child)
 	base = (io_base_lo & io_mask) << 8;
 	limit = (io_limit_lo & io_mask) << 8;
 
+	/* If necessary, check if the bridge supports an I/O aperture */
+	if (!io_base_lo && !io_limit_lo) {
+		u16 io;
+
+		if (!pci_parent_supports_io(child))
+			return;
+
+		pci_write_config_word(dev, PCI_IO_BASE, 0xe0f0);
+		pci_read_config_word(dev, PCI_IO_BASE, &io);
+		pci_write_config_word(dev, PCI_IO_BASE, 0x0);
+		if (!io)
+			return;
+	}
+
 	if ((io_base_lo & PCI_IO_RANGE_TYPE_MASK) == PCI_IO_RANGE_TYPE_32) {
 		u16 io_base_hi, io_limit_hi;
 
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index e3e17f3..4fde12a 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -695,7 +695,7 @@ static void pci_bridge_check_ranges(struct pci_bus *bus)
 	b_res[1].flags |= IORESOURCE_MEM;
 
 	pci_read_config_word(bridge, PCI_IO_BASE, &io);
-	if (!io) {
+	if (!io && pci_parent_supports_io(bus)) {
 		pci_write_config_word(bridge, PCI_IO_BASE, 0xe0f0);
 		pci_read_config_word(bridge, PCI_IO_BASE, &io);
 		pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2d39586..174600f 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -489,6 +489,15 @@ static inline bool pci_is_root_bus(struct pci_bus *pbus)
 	return !(pbus->parent);
 }
 
+/*
+ * Returns true if the parent bus supports an I/O aperture.
+ */
+static inline bool pci_parent_supports_io(struct pci_bus *pbus)
+{
+	return pci_is_root_bus(pbus) || pci_is_root_bus(pbus->parent) ||
+	       (pbus->parent->resource[0]->flags & IORESOURCE_IO);
+}
+
 /**
  * pci_is_bridge - check if the PCI device is a bridge
  * @dev: PCI device
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2015-05-19  0:18 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-05-15 17:28 BAR 7 io space assignment errors Guenter Roeck
2015-05-15 19:25 ` Bjorn Helgaas
2015-05-15 20:04   ` Guenter Roeck
2015-05-15 22:11     ` Bjorn Helgaas
2015-05-16  2:27       ` Guenter Roeck
2015-05-16 13:12         ` Bjorn Helgaas
2015-05-16 16:41           ` Guenter Roeck
2015-05-18 15:55             ` Bjorn Helgaas
2015-05-19  0:18               ` Guenter Roeck

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).