Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)

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

* Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
@ 2018-04-16 14:33 Matt Turner
  2018-04-16 21:50 ` Bjorn Helgaas
  2020-02-22 16:55 ` Bjorn Helgaas
  0 siblings, 2 replies; 21+ messages in thread
From: Matt Turner @ 2018-04-16 14:33 UTC (permalink / raw)
  To: Yinghai Lu
  Cc: linux-pci, linux-alpha, Richard Henderson, Ivan Kokshaysky,
	Jay Estabrook, Bjorn Helgaas

Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
address limits in resource allocation) broke Alpha systems using
CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
into the upper addresses just below 4GB.

I can get a working kernel by ifdef'ing out the code in
drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
kernels.

How can we get Nautilus working again?

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2018-04-16 14:33 Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation) Matt Turner
@ 2018-04-16 21:50 ` Bjorn Helgaas
  2018-04-17  4:43   ` Matt Turner
  2020-02-22 16:55 ` Bjorn Helgaas
  1 sibling, 1 reply; 21+ messages in thread
From: Bjorn Helgaas @ 2018-04-16 21:50 UTC (permalink / raw)
  To: Matt Turner
  Cc: Yinghai Lu, linux-pci, linux-alpha, Richard Henderson,
	Ivan Kokshaysky, Jay Estabrook, Bjorn Helgaas

Hi Matt,

First of all, sorry about breaking Nautilus, and thanks very much for
tracking it down to this commit.

On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> address limits in resource allocation) broke Alpha systems using
> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
> into the upper addresses just below 4GB.
> 
> I can get a working kernel by ifdef'ing out the code in
> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> kernels.
> 
> How can we get Nautilus working again?

Can you collect a complete dmesg log, ideally both before and after
f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
erroneously assign space for something above 4GB.  But if we know the
correct host bridge apertures, we shouldn't assign space outside them,
regardless of the PCI bus address size.

Coincidentally, Christoph is replacing CONFIG_PCI_BUS_ADDR_T_64BIT
with CONFIG_ARCH_DMA_ADDR_T_64BIT, but I think that change is a no-op
with respect to the problem you're seeing.

[1] https://lkml.kernel.org/r/20180415145947.1248-10-hch@lst.de

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2018-04-16 21:50 ` Bjorn Helgaas
@ 2018-04-17  4:43   ` Matt Turner
  2018-04-17 19:43     ` Bjorn Helgaas
  0 siblings, 1 reply; 21+ messages in thread
From: Matt Turner @ 2018-04-17  4:43 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Yinghai Lu, linux-pci, linux-alpha, Richard Henderson,
	Ivan Kokshaysky, Jay Estabrook, Bjorn Helgaas

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> Hi Matt,
>
> First of all, sorry about breaking Nautilus, and thanks very much for
> tracking it down to this commit.

It's a particularly weird case, as far as I've been able to discern :)

> On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
>> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
>> address limits in resource allocation) broke Alpha systems using
>> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
>> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
>> into the upper addresses just below 4GB.
>>
>> I can get a working kernel by ifdef'ing out the code in
>> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
>> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
>> kernels.
>>
>> How can we get Nautilus working again?
>
> Can you collect a complete dmesg log, ideally both before and after
> f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
> erroneously assign space for something above 4GB.  But if we know the
> correct host bridge apertures, we shouldn't assign space outside them,
> regardless of the PCI bus address size.

I made a mistake in my initial report. Commit f75b99d5a77d is actually
the last *working* commit. My apologies. The next commit is
d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
breaks Nautilus I've confirmed.

Please find attached dmesgs from those two commits, from the commit
immediately before them, and another from 4.17-rc1 with my hack of #if
0'ing out the pci_bus_alloc_from_region(..., &pci_high) code.

Thanks for having a look!

[-- Attachment #2: dmesg-1-36e097a8a297 --]
[-- Type: application/octet-stream, Size: 11465 bytes --]

Initializing cgroup subsys cpu
Linux version 3.13.0-rc1-00013-g36e097a8a297 (mattst88@ivybridge) (gcc version 4.9.4 (Gentoo 4.9.4 p1.3, pie-0.6.4) ) #30 Mon Apr 16 19:04:08 PDT 2018
Booting on Nautilus using machine vector Nautilus from SRM
Major Options: EV67 LEGACY_START VERBOSE_MCHECK MAGIC_SYSRQ 
Command line: ro root=/dev/sda2 alim7101_wdt.use_gpio=1 console=ttyS0
memcluster 0, usage 1, start        0, end      256
memcluster 1, usage 0, start      256, end   130994
memcluster 2, usage 1, start   130994, end   131072
memcluster 3, usage 0, start   131072, end   524282
memcluster 4, usage 1, start   524282, end   524288
freeing pages 256:384
freeing pages 1562:130994
freeing pages 131072:524282
reserving pages 1562:1570
8192K Bcache detected; load hit latency 18 cycles, load miss latency 165 cycles
Iron stat_cmd 22100006
Iron ECC c00
irongate_init_arch: temporarily reserving region c0000000-ffff3fff for PCI
On node 0 totalpages: 524282
free_area_init_node: node 0, pgdat fffffc0000b8dce8, node_mem_map fffffc0001000080
  DMA zone: 14 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 2048 pages, LIFO batch:0
  Normal zone: 3570 pages used for memmap
  Normal zone: 522234 pages, LIFO batch:15
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 520698
Kernel command line: ro root=/dev/sda2 alim7101_wdt.use_gpio=1 console=ttyS0
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 524288 (order: 9, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 8, 2097152 bytes)
Sorting __ex_table...
Memory: 3098696K/4194256K available (6245K kernel code, 462K rwdata, 2076K rodata, 144K init, 396K bss, 1095560K reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:16
HWRPB cycle frequency bogus.  Estimated 796425571 Hz
Console: colour VGA+ 80x25
console [ttyS0] enabled
Calibrating delay loop... 1577.12 BogoMIPS (lpj=770048)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Performance events: Supported CPU type!
devtmpfs: initialized
NET: Registered protocol family 16
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:00.0: [1022:700e] type 00 class 0x060000
pci 0000:00:00.0: reg 0x14: [mem 0x42000000-0x42000fff pref]
pci 0000:00:00.0: reg 0x18: [io  0x102a0-0x102a3]
pci 0000:00:01.0: [1022:700f] type 01 class 0x060400
pci 0000:00:03.0: [10b9:5457] type 00 class 0x070300
pci 0000:00:03.0: reg 0x10: [mem 0x80970000-0x80970fff]
pci 0000:00:03.0: reg 0x14: [io  0x1000-0x10ff]
pci 0000:00:03.0: PME# supported from D3hot D3cold
pci 0000:00:06.0: [10b9:5451] type 00 class 0x040100
pci 0000:00:06.0: reg 0x10: [io  0x10000-0x100ff]
pci 0000:00:06.0: reg 0x14: [mem 0x80971000-0x80971fff]
pci 0000:00:06.0: supports D1 D2
pci 0000:00:06.0: PME# supported from D2 D3hot D3cold
pci 0000:00:07.0: [10b9:1533] type 00 class 0x060100
pci 0000:00:08.0: [9005:0080] type 00 class 0x010000
pci 0000:00:08.0: reg 0x10: [io  0x10100-0x101ff]
pci 0000:00:08.0: reg 0x14: [mem 0x80972000-0x80972fff 64bit]
pci 0000:00:08.0: reg 0x30: [mem 0x80940000-0x8095ffff pref]
pci 0000:00:09.0: [14e4:1645] type 00 class 0x020000
pci 0000:00:09.0: reg 0x10: [mem 0x80960000-0x8096ffff 64bit]
pci 0000:00:09.0: PME# supported from D3hot D3cold
pci 0000:00:0b.0: [1011:0019] type 00 class 0x020000
pci 0000:00:0b.0: reg 0x10: [io  0x10200-0x1027f]
pci 0000:00:0b.0: reg 0x14: [mem 0x80974000-0x809743ff]
pci 0000:00:0b.0: reg 0x30: [mem 0x80900000-0x8093ffff pref]
pci 0000:00:10.0: [10b9:5229] type 00 class 0x0101fa
pci 0000:00:10.0: reg 0x10: [io  0x01f0-0x01ff]
pci 0000:00:10.0: reg 0x14: [io  0x03f4-0x03f7]
pci 0000:00:10.0: reg 0x18: [io  0x0170-0x017f]
pci 0000:00:10.0: reg 0x1c: [io  0x0374-0x0377]
pci 0000:00:10.0: reg 0x20: [io  0x10290-0x1029f]
pci 0000:00:11.0: [10b9:7101] type 00 class 0x000000
pci 0000:00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
pci 0000:00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
pci 0000:00:14.0: [10b9:5237] type 00 class 0x0c0310
pci 0000:00:14.0: reg 0x10: [mem 0x80973000-0x80973fff]
pci 0000:01:05.0: [102b:0525] type 00 class 0x030000
pci 0000:01:05.0: reg 0x10: [mem 0x40000000-0x41ffffff pref]
pci 0000:01:05.0: reg 0x14: [mem 0x80810000-0x80813fff]
pci 0000:01:05.0: reg 0x18: [mem 0x80000000-0x807fffff]
pci 0000:01:05.0: reg 0x30: [mem 0x80800000-0x8080ffff pref]
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
nautilus_init_pci: 1032192k freed
pci 0000:00:01.0: BAR 9: assigned [mem 0x100000000-0x102ffffff pref]
pci 0000:00:01.0: BAR 8: assigned [mem 0xff000000-0xffbfffff]
pci 0000:00:0b.0: BAR 6: assigned [mem 0xffc00000-0xffc3ffff pref]
pci 0000:00:08.0: BAR 6: assigned [mem 0xffc40000-0xffc5ffff pref]
pci 0000:00:09.0: BAR 0: assigned [mem 0xffc60000-0xffc6ffff 64bit]
pci 0000:00:03.0: BAR 0: assigned [mem 0xffc70000-0xffc70fff]
pci 0000:00:06.0: BAR 1: assigned [mem 0xffc71000-0xffc71fff]
pci 0000:00:08.0: BAR 1: assigned [mem 0xffc72000-0xffc72fff 64bit]
pci 0000:00:14.0: BAR 0: assigned [mem 0xffc73000-0xffc73fff]
pci 0000:00:0b.0: BAR 1: assigned [mem 0xffc74000-0xffc743ff]
pci 0000:00:03.0: BAR 1: assigned [io  0x8000-0x80ff]
pci 0000:00:06.0: BAR 0: assigned [io  0x8400-0x84ff]
pci 0000:00:08.0: BAR 0: assigned [io  0x8800-0x88ff]
pci 0000:00:0b.0: BAR 0: assigned [io  0x8c00-0x8c7f]
pci 0000:00:10.0: BAR 4: assigned [io  0x8c80-0x8c8f]
pci 0000:01:05.0: BAR 0: assigned [mem 0x100000000-0x101ffffff pref]
pci 0000:01:05.0: BAR 2: assigned [mem 0xff000000-0xff7fffff]
pci 0000:01:05.0: BAR 6: assigned [mem 0x102000000-0x10200ffff pref]
pci 0000:01:05.0: BAR 1: assigned [mem 0xff800000-0xff803fff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0xff000000-0xffbfffff]
pci 0000:00:01.0:   bridge window [mem 0x100000000-0x102ffffff pref]
bio: create slab <bio-0> at 0
vgaarb: device added: PCI:0000:01:05.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:01:05.0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
NET: Registered protocol family 2
TCP established hash table entries: 32768 (order: 5, 262144 bytes)
TCP bind hash table entries: 32768 (order: 5, 262144 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP: reno registered
UDP hash table entries: 2048 (order: 3, 65536 bytes)
UDP-Lite hash table entries: 2048 (order: 3, 65536 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
pci 0000:00:07.0: Activating ISA DMA hang workarounds
PCI: CLS mismatch (64 != 32), using 64 bytes
srm_env: version 0.0.6 loaded successfully
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
msgmni has been set to 8068
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
rtc: SRM (post-2000) epoch (2000) detected
Real Time Clock Driver v1.12b
[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
loop: module loaded
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 29160 Ultra160 SCSI adapter>
        aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi 0:0:0:0: Direct-Access     CSC150GB 15K REFURBISHED  0126 PQ: 0 ANSI: 3
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
scsi target0:0:0: Beginning Domain Validation
scsi target0:0:0: wide asynchronous
scsi target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63)
scsi target0:0:0: Ending Domain Validation
random: nonblocking pool is initialized
tg3.c:v3.134 (Sep 16, 2013)
sd 0:0:0:0: [sda] 286749488 512-byte logical blocks: (146 GB/136 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: ab 00 10 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
tg3 0000:00:09.0 eth0: Tigon3 [partno(A6825-60101) rev 0105] (PCI:33MHz:32-bit) MAC address 00:17:a4:76:3d:87
tg3 0000:00:09.0 eth0: attached PHY is 5701 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
tg3 0000:00:09.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[0]
tg3 0000:00:09.0 eth0: dma_rwctrl[76ff1b0f] dma_mask[64-bit]
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-pci: OHCI PCI platform driver
ohci-pci 0000:00:14.0: OHCI PCI host controller
ohci-pci 0000:00:14.0: new USB bus registered, assigned bus number 1
ohci-pci 0000:00:14.0: irq 9, io mem 0xffc73000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
usbcore: registered new interface driver usb-storage
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
ali1535_smbus 0000:00:11.0: enabling device (0000 -> 0001)
atkbd serio0: keyboard reset failed on isa0060/serio0
i2c i2c-0: found ADM9240 revision 2
hwmon_vid: Unknown VRM version of your CPU
adm9240 0-002c: Using VRM: 0.0
adm9240 0-002c: status: config 0x01 mode 1
i2c i2c-0: Error: command never completed
atkbd serio1: keyboard reset failed on isa0060/serio1
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
lm75 0-004f: hwmon1: sensor 'lm75'
alim7101_wdt: Steve Hill <steve@navaho.co.uk>
alim7101_wdt: WDT driver for ALi M7101 initialised. timeout=30 sec (nowayout=1)
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using alpha/ev67 performance monitoring.
TCP: cubic registered
NET: Registered protocol family 10
NET: Registered protocol family 17
Key type dns_resolver registered
EXT4-fs (sda2): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (sda2): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
devtmpfs: mounted
Freeing unused kernel memory: 144K (fffffc0000b34000 - fffffc0000b58000)
udevd[495]: starting version 3.2.5
udevd[496]: starting eudev-3.2.5
EXT4-fs (sda2): re-mounted. Opts: (null)
IPv6: ADDRCONF(NETDEV_UP): enp0s9: link is not ready
tg3 0000:00:09.0 enp0s9: Link is up at 1000 Mbps, full duplex
tg3 0000:00:09.0 enp0s9: Flow control is on for TX and on for RX
IPv6: ADDRCONF(NETDEV_CHANGE): enp0s9: link becomes ready

[-- Attachment #3: dmesg-2-f75b99d5a77d --]
[-- Type: application/octet-stream, Size: 11384 bytes --]

Initializing cgroup subsys cpu
Linux version 3.13.0-rc1-00014-gf75b99d5a77d (mattst88@ivybridge) (gcc version 4.9.4 (Gentoo 4.9.4 p1.3, pie-0.6.4) ) #31 Mon Apr 16 19:08:06 PDT 2018
Booting on Nautilus using machine vector Nautilus from SRM
Major Options: EV67 LEGACY_START VERBOSE_MCHECK MAGIC_SYSRQ 
Command line: ro root=/dev/sda2 alim7101_wdt.use_gpio=1 console=ttyS0
memcluster 0, usage 1, start        0, end      256
memcluster 1, usage 0, start      256, end   130994
memcluster 2, usage 1, start   130994, end   131072
memcluster 3, usage 0, start   131072, end   524282
memcluster 4, usage 1, start   524282, end   524288
freeing pages 256:384
freeing pages 1562:130994
freeing pages 131072:524282
reserving pages 1562:1570
8192K Bcache detected; load hit latency 18 cycles, load miss latency 165 cycles
Iron stat_cmd 22100006
Iron ECC c00
irongate_init_arch: temporarily reserving region c0000000-ffff3fff for PCI
On node 0 totalpages: 524282
free_area_init_node: node 0, pgdat fffffc0000b8dd08, node_mem_map fffffc0001000080
  DMA zone: 14 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 2048 pages, LIFO batch:0
  Normal zone: 3570 pages used for memmap
  Normal zone: 522234 pages, LIFO batch:15
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 520698
Kernel command line: ro root=/dev/sda2 alim7101_wdt.use_gpio=1 console=ttyS0
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 524288 (order: 9, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 8, 2097152 bytes)
Sorting __ex_table...
Memory: 3098696K/4194256K available (6245K kernel code, 462K rwdata, 2076K rodata, 144K init, 396K bss, 1095560K reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:16
HWRPB cycle frequency bogus.  Estimated 796423714 Hz
Console: colour VGA+ 80x25
console [ttyS0] enabled
Calibrating delay loop... 1577.12 BogoMIPS (lpj=770048)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Performance events: Supported CPU type!
devtmpfs: initialized
NET: Registered protocol family 16
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:00.0: [1022:700e] type 00 class 0x060000
pci 0000:00:00.0: reg 0x14: [mem 0x42000000-0x42000fff pref]
pci 0000:00:00.0: reg 0x18: [io  0x102a0-0x102a3]
pci 0000:00:01.0: [1022:700f] type 01 class 0x060400
pci 0000:00:03.0: [10b9:5457] type 00 class 0x070300
pci 0000:00:03.0: reg 0x10: [mem 0x80970000-0x80970fff]
pci 0000:00:03.0: reg 0x14: [io  0x1000-0x10ff]
pci 0000:00:03.0: PME# supported from D3hot D3cold
pci 0000:00:06.0: [10b9:5451] type 00 class 0x040100
pci 0000:00:06.0: reg 0x10: [io  0x10000-0x100ff]
pci 0000:00:06.0: reg 0x14: [mem 0x80971000-0x80971fff]
pci 0000:00:06.0: supports D1 D2
pci 0000:00:06.0: PME# supported from D2 D3hot D3cold
pci 0000:00:07.0: [10b9:1533] type 00 class 0x060100
pci 0000:00:08.0: [9005:0080] type 00 class 0x010000
pci 0000:00:08.0: reg 0x10: [io  0x10100-0x101ff]
pci 0000:00:08.0: reg 0x14: [mem 0x80972000-0x80972fff 64bit]
pci 0000:00:08.0: reg 0x30: [mem 0x80940000-0x8095ffff pref]
pci 0000:00:09.0: [14e4:1645] type 00 class 0x020000
pci 0000:00:09.0: reg 0x10: [mem 0x80960000-0x8096ffff 64bit]
pci 0000:00:09.0: PME# supported from D3hot D3cold
pci 0000:00:0b.0: [1011:0019] type 00 class 0x020000
pci 0000:00:0b.0: reg 0x10: [io  0x10200-0x1027f]
pci 0000:00:0b.0: reg 0x14: [mem 0x80974000-0x809743ff]
pci 0000:00:0b.0: reg 0x30: [mem 0x80900000-0x8093ffff pref]
pci 0000:00:10.0: [10b9:5229] type 00 class 0x0101fa
pci 0000:00:10.0: reg 0x10: [io  0x01f0-0x01ff]
pci 0000:00:10.0: reg 0x14: [io  0x03f4-0x03f7]
pci 0000:00:10.0: reg 0x18: [io  0x0170-0x017f]
pci 0000:00:10.0: reg 0x1c: [io  0x0374-0x0377]
pci 0000:00:10.0: reg 0x20: [io  0x10290-0x1029f]
pci 0000:00:11.0: [10b9:7101] type 00 class 0x000000
pci 0000:00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
pci 0000:00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
pci 0000:00:14.0: [10b9:5237] type 00 class 0x0c0310
pci 0000:00:14.0: reg 0x10: [mem 0x80973000-0x80973fff]
pci 0000:01:05.0: [102b:0525] type 00 class 0x030000
pci 0000:01:05.0: reg 0x10: [mem 0x40000000-0x41ffffff pref]
pci 0000:01:05.0: reg 0x14: [mem 0x80810000-0x80813fff]
pci 0000:01:05.0: reg 0x18: [mem 0x80000000-0x807fffff]
pci 0000:01:05.0: reg 0x30: [mem 0x80800000-0x8080ffff pref]
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
nautilus_init_pci: 1032192k freed
pci 0000:00:01.0: BAR 9: can't assign mem pref (size 0x3000000)
pci 0000:00:01.0: BAR 8: assigned [mem 0xff000000-0xffbfffff]
pci 0000:00:0b.0: BAR 6: assigned [mem 0xffc00000-0xffc3ffff pref]
pci 0000:00:08.0: BAR 6: assigned [mem 0xffc40000-0xffc5ffff pref]
pci 0000:00:09.0: BAR 0: assigned [mem 0xffc60000-0xffc6ffff 64bit]
pci 0000:00:03.0: BAR 0: assigned [mem 0xffc70000-0xffc70fff]
pci 0000:00:06.0: BAR 1: assigned [mem 0xffc71000-0xffc71fff]
pci 0000:00:08.0: BAR 1: assigned [mem 0xffc72000-0xffc72fff 64bit]
pci 0000:00:14.0: BAR 0: assigned [mem 0xffc73000-0xffc73fff]
pci 0000:00:0b.0: BAR 1: assigned [mem 0xffc74000-0xffc743ff]
pci 0000:00:03.0: BAR 1: assigned [io  0x8000-0x80ff]
pci 0000:00:06.0: BAR 0: assigned [io  0x8400-0x84ff]
pci 0000:00:08.0: BAR 0: assigned [io  0x8800-0x88ff]
pci 0000:00:0b.0: BAR 0: assigned [io  0x8c00-0x8c7f]
pci 0000:00:10.0: BAR 4: assigned [io  0x8c80-0x8c8f]
pci 0000:01:05.0: BAR 0: can't assign mem pref (size 0x2000000)
pci 0000:01:05.0: BAR 2: assigned [mem 0xff000000-0xff7fffff]
pci 0000:01:05.0: BAR 6: assigned [mem 0xff800000-0xff80ffff pref]
pci 0000:01:05.0: BAR 1: assigned [mem 0xff810000-0xff813fff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0xff000000-0xffbfffff]
bio: create slab <bio-0> at 0
vgaarb: device added: PCI:0000:01:05.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:01:05.0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
NET: Registered protocol family 2
TCP established hash table entries: 32768 (order: 5, 262144 bytes)
TCP bind hash table entries: 32768 (order: 5, 262144 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP: reno registered
UDP hash table entries: 2048 (order: 3, 65536 bytes)
UDP-Lite hash table entries: 2048 (order: 3, 65536 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
pci 0000:00:07.0: Activating ISA DMA hang workarounds
PCI: CLS mismatch (64 != 32), using 64 bytes
srm_env: version 0.0.6 loaded successfully
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
msgmni has been set to 8068
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
rtc: SRM (post-2000) epoch (2000) detected
Real Time Clock Driver v1.12b
[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
loop: module loaded
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 29160 Ultra160 SCSI adapter>
        aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi 0:0:0:0: Direct-Access     CSC150GB 15K REFURBISHED  0126 PQ: 0 ANSI: 3
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
scsi target0:0:0: Beginning Domain Validation
scsi target0:0:0: wide asynchronous
scsi target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63)
scsi target0:0:0: Ending Domain Validation
random: nonblocking pool is initialized
tg3.c:v3.134 (Sep 16, 2013)
sd 0:0:0:0: [sda] 286749488 512-byte logical blocks: (146 GB/136 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: ab 00 10 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
tg3 0000:00:09.0 eth0: Tigon3 [partno(A6825-60101) rev 0105] (PCI:33MHz:32-bit) MAC address 00:17:a4:76:3d:87
tg3 0000:00:09.0 eth0: attached PHY is 5701 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
tg3 0000:00:09.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[0]
tg3 0000:00:09.0 eth0: dma_rwctrl[76ff1b0f] dma_mask[64-bit]
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-pci: OHCI PCI platform driver
ohci-pci 0000:00:14.0: OHCI PCI host controller
ohci-pci 0000:00:14.0: new USB bus registered, assigned bus number 1
ohci-pci 0000:00:14.0: irq 9, io mem 0xffc73000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
usbcore: registered new interface driver usb-storage
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
ali1535_smbus 0000:00:11.0: enabling device (0000 -> 0001)
atkbd serio0: keyboard reset failed on isa0060/serio0
i2c i2c-0: found ADM9240 revision 2
hwmon_vid: Unknown VRM version of your CPU
adm9240 0-002c: Using VRM: 0.0
adm9240 0-002c: status: config 0x01 mode 1
i2c i2c-0: Error: command never completed
atkbd serio1: keyboard reset failed on isa0060/serio1
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
lm75 0-004f: hwmon1: sensor 'lm75'
alim7101_wdt: Steve Hill <steve@navaho.co.uk>
alim7101_wdt: WDT driver for ALi M7101 initialised. timeout=30 sec (nowayout=1)
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: using alpha/ev67 performance monitoring.
TCP: cubic registered
NET: Registered protocol family 10
NET: Registered protocol family 17
Key type dns_resolver registered
EXT4-fs (sda2): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (sda2): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
devtmpfs: mounted
Freeing unused kernel memory: 144K (fffffc0000b34000 - fffffc0000b58000)
udevd[495]: starting version 3.2.5
udevd[496]: starting eudev-3.2.5
EXT4-fs (sda2): re-mounted. Opts: (null)
IPv6: ADDRCONF(NETDEV_UP): enp0s9: link is not ready
tg3 0000:00:09.0 enp0s9: Link is up at 1000 Mbps, full duplex
tg3 0000:00:09.0 enp0s9: Flow control is on for TX and on for RX
IPv6: ADDRCONF(NETDEV_CHANGE): enp0s9: link becomes ready

[-- Attachment #4: dmesg-3-d56dbf5bab8c --]
[-- Type: application/octet-stream, Size: 5884 bytes --]

Initializing cgroup subsys cpu
Linux version 3.13.0-rc1-00015-gd56dbf5bab8c (mattst88@ivybridge) (gcc version 4.9.4 (Gentoo 4.9.4 p1.3, pie-0.6.4) ) #32 Mon Apr 16 19:22:21 PDT 2018
Booting on Nautilus using machine vector Nautilus from SRM
Major Options: EV67 LEGACY_START VERBOSE_MCHECK MAGIC_SYSRQ 
Command line: ro root=/dev/sda2 alim7101_wdt.use_gpio=1 console=ttyS0
memcluster 0, usage 1, start        0, end      256
memcluster 1, usage 0, start      256, end   130994
memcluster 2, usage 1, start   130994, end   131072
memcluster 3, usage 0, start   131072, end   524282
memcluster 4, usage 1, start   524282, end   524288
freeing pages 256:384
freeing pages 1562:130994
freeing pages 131072:524282
reserving pages 1562:1570
8192K Bcache detected; load hit latency 18 cycles, load miss latency 165 cycles
Iron stat_cmd 22100006
Iron ECC c00
irongate_init_arch: temporarily reserving region c0000000-ffff3fff for PCI
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 520698
Kernel command line: ro root=/dev/sda2 alim7101_wdt.use_gpio=1 console=ttyS0
PID hash table entries: 4096 (order: 2, 32768 bytes)
Dentry cache hash table entries: 524288 (order: 9, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 8, 2097152 bytes)
Sorting __ex_table...
Memory: 3098696K/4194256K available (6245K kernel code, 462K rwdata, 2076K rodata, 144K init, 396K bss, 1095560K reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:16
HWRPB cycle frequency bogus.  Estimated 796423605 Hz
Console: colour VGA+ 80x25
console [ttyS0] enabled
Calibrating delay loop... 1577.12 BogoMIPS (lpj=770048)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Performance events: Supported CPU type!
devtmpfs: initialized
NET: Registered protocol family 16
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
pci 0000:00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
nautilus_init_pci: 1032192k freed
pci 0000:00:01.0: BAR 9: can't assign mem pref (size 0x3000000)
pci 0000:00:01.0: BAR 8: assigned [mem 0xff000000-0xffbfffff]
pci 0000:00:0b.0: BAR 6: assigned [mem 0xffc00000-0xffc3ffff pref]
pci 0000:00:08.0: BAR 6: assigned [mem 0xffc40000-0xffc5ffff pref]
pci 0000:00:09.0: BAR 0: assigned [mem 0x100000000-0x10000ffff 64bit]
pci 0000:00:03.0: BAR 0: assigned [mem 0xffc60000-0xffc60fff]
pci 0000:00:06.0: BAR 1: assigned [mem 0xffc61000-0xffc61fff]
pci 0000:00:08.0: BAR 1: assigned [mem 0x100010000-0x100010fff 64bit]
pci 0000:00:14.0: BAR 0: assigned [mem 0xffc62000-0xffc62fff]
pci 0000:00:0b.0: BAR 1: assigned [mem 0xffc63000-0xffc633ff]
pci 0000:00:03.0: BAR 1: assigned [io  0x8000-0x80ff]
pci 0000:00:06.0: BAR 0: assigned [io  0x8400-0x84ff]
pci 0000:00:08.0: BAR 0: assigned [io  0x8800-0x88ff]
pci 0000:00:0b.0: BAR 0: assigned [io  0x8c00-0x8c7f]
pci 0000:00:10.0: BAR 4: assigned [io  0x8c80-0x8c8f]
pci 0000:01:05.0: BAR 0: can't assign mem pref (size 0x2000000)
pci 0000:01:05.0: BAR 2: assigned [mem 0xff000000-0xff7fffff]
pci 0000:01:05.0: BAR 6: assigned [mem 0xff800000-0xff80ffff pref]
pci 0000:01:05.0: BAR 1: assigned [mem 0xff810000-0xff813fff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0xff000000-0xffbfffff]
bio: create slab <bio-0> at 0
vgaarb: device added: PCI:0000:01:05.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:01:05.0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
NET: Registered protocol family 2
TCP established hash table entries: 32768 (order: 5, 262144 bytes)
TCP bind hash table entries: 32768 (order: 5, 262144 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
TCP: reno registered
UDP hash table entries: 2048 (order: 3, 65536 bytes)
UDP-Lite hash table entries: 2048 (order: 3, 65536 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
pci 0000:00:07.0: Activating ISA DMA hang workarounds
srm_env: version 0.0.6 loaded successfully
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
msgmni has been set to 8068
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
rtc: SRM (post-2000) epoch (2000) detected
Real Time Clock Driver v1.12b
[drm] Initialized drm 1.1.0 20060810
[drm] radeon kernel modesetting enabled.
loop: module loaded
aic7xxx: PCI Device 0:8:0 failed memory mapped test.  Using PIO.
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 29160 Ultra160 SCSI adapter>
        aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi 0:0:0:0: Direct-Access     CSC150GB 15K REFURBISHED  0126 PQ: 0 ANSI: 3
scsi0:A:0:0: Tagged Queuing enabled.  Depth 253
scsi target0:0:0: Beginning Domain Validation
scsi target0:0:0: wide asynchronous
scsi target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63)
scsi target0:0:0: Ending Domain Validation
random: nonblocking pool is initialized
tg3.c:v3.134 (Sep 16, 2013)

[-- Attachment #5: lspci --]
[-- Type: application/octet-stream, Size: 9693 bytes --]

00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] AMD-760 [IGD4-1P] System Controller [1022:700e] (rev 13)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 255
	Region 0: Memory at <unassigned> (32-bit, prefetchable)
	Region 1: Memory at 42000000 (32-bit, prefetchable) [size=4K]
	Region 2: I/O ports at 102a0 [disabled] [size=4]
	Capabilities: [a0] AGP version 2.0
		Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
lspci: Unable to load libkmod resources: error -12

00:01.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] AMD-760 [IGD4-1P] AGP Bridge [1022:700f] (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 255
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=255
	Memory behind bridge: ff000000-ffbfffff
	Prefetchable memory behind bridge: c0000000-c2ffffff
	Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-

00:03.0 Modem [0703]: ULi Electronics Inc. M5457 AC'97 Modem Controller [10b9:5457] (prog-if 00 [Generic])
	Subsystem: ULi Electronics Inc. M5457 AC'97 Modem Controller [10b9:5457]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 255
	Interrupt: pin A routed to IRQ 255
	Region 0: Memory at ffc70000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at 8000 [size=256]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

00:06.0 Multimedia audio controller [0401]: ULi Electronics Inc. M5451 PCI AC-Link Controller Audio Device [10b9:5451] (rev 02)
	Subsystem: ULi Electronics Inc. M5451 PCI AC-Link Controller Audio Device [10b9:5451]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR+ <PERR+ INTx-
	Latency: 240 (500ns min, 6000ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at 8400 [size=256]
	Region 1: Memory at ffc71000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: snd_ali5451

00:07.0 ISA bridge [0601]: ULi Electronics Inc. M1533/M1535/M1543 PCI to ISA Bridge [Aladdin IV/V/V+] [10b9:1533]
	Subsystem: ULi Electronics Inc. ALi M1533 Aladdin IV/V ISA Bridge [10b9:1533]
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: [a0] Power Management version 1
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

00:08.0 SCSI storage controller [0100]: Adaptec AIC-7892A U160/m [9005:0080] (rev 02)
	Subsystem: Adaptec 29160 Ultra160 SCSI Controller [9005:e2a0]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 252 (10000ns min, 6250ns max), Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 5
	BIST result: 00
	Region 0: I/O ports at 8800 [disabled] [size=256]
	Region 1: Memory at ffc72000 (64-bit, non-prefetchable) [size=4K]
	Expansion ROM at ffc40000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: aic7xxx

00:09.0 Ethernet controller [0200]: Broadcom Limited NetXtreme BCM5701 Gigabit Ethernet [14e4:1645] (rev 15)
	Subsystem: Hewlett-Packard Company BCM5701 1000Base-T (HP, OEM 3COM) [103c:128a]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 248 (16000ns min), Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at ffc60000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [40] PCI-X non-bridge device
		Command: DPERE- ERO+ RBC=512 OST=1
		Status: Dev=ff:1f.1 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=512 DMOST=1 DMCRS=8 RSCEM- 266MHz- 533MHz-
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
	Capabilities: [50] Vital Product Data
		Product Name: PCI 10/100/1000 Ethernet Adapter
		Read-only fields:
			[PN] Part number: A6825-60101
			[EC] Engineering changes: B-4246
			[SN] Serial number: HYLR763D87
			[MN] Manufacture ID: 31 30 33 43
			[V0] Vendor specific: N/A
			[V0] Vendor specific: N/A
			[V0] Vendor specific: N/A
			[RV] Reserved: checksum bad, 24 byte(s) reserved
		Read/write fields:
			[YA] Asset tag: N/A
			[V1] Vendor specific: N/A
			[RW] Read-write area: 109 byte(s) free
		End
	Capabilities: [58] MSI: Enable- Count=1/8 Maskable- 64bit+
		Address: ee77290f5dfa4564  Data: 7bcf
	Kernel driver in use: tg3

00:0b.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip 21142/43 [1011:0019] (rev 41)
	Subsystem: Digital Equipment Corporation DE500B Fast Ethernet [1011:500b]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 255 (5000ns min, 10000ns max), Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at 8c00 [size=128]
	Region 1: Memory at ffc74000 (32-bit, non-prefetchable) [size=1K]
	Expansion ROM at ffc00000 [disabled] [size=256K]
	Kernel driver in use: tulip

00:10.0 IDE interface [0101]: ULi Electronics Inc. M5229 IDE [10b9:5229] (rev c4) (prog-if fa)
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 255 (500ns min, 1000ns max)
	Interrupt: pin A routed to IRQ 15
	Region 0: I/O ports at 01f0 [size=8]
	Region 1: I/O ports at 03f4
	Region 2: I/O ports at 0170 [size=8]
	Region 3: I/O ports at 0374
	Region 4: I/O ports at 8c80 [size=16]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: pata_ali

00:11.0 Non-VGA unclassified device [0000]: ULi Electronics Inc. M7101 Power Management Controller [PMU] [10b9:7101]
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Kernel driver in use: ali1535_smbus

00:14.0 USB controller [0c03]: ULi Electronics Inc. USB 1.1 Controller [10b9:5237] (rev 03) (prog-if 10 [OHCI])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 248 (20000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 9
	Region 0: Memory at ffc73000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: ohci-pci

01:05.0 VGA compatible controller [0300]: Matrox Electronics Systems Ltd. MGA G400/G450 [102b:0525] (rev 04) (prog-if 00 [VGA controller])
	Subsystem: Matrox Electronics Systems Ltd. Millennium G400 16Mb SGRAM [102b:19d8]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 248 (4000ns min, 8000ns max), Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at c0000000 (32-bit, prefetchable) [size=32M]
	Region 1: Memory at ff800000 (32-bit, non-prefetchable) [size=16K]
	Region 2: Memory at ff000000 (32-bit, non-prefetchable) [size=8M]
	Expansion ROM at c2000000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [f0] AGP version 2.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
		Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x1

[-- Attachment #6: dmesg-patched-4.17 --]
[-- Type: application/octet-stream, Size: 13465 bytes --]

Linux version 4.17.0-rc1-00021-ga27fc14219f2-dirty (mattst88@ivybridge) (gcc version 7.3.0 (Gentoo 7.3.0 p1.0)) #33 Mon Apr 16 21:18:02 PDT 2018
Booting on Nautilus using machine vector Nautilus from SRM
Major Options: EV67 LEGACY_START VERBOSE_MCHECK MAGIC_SYSRQ 
Command line: ro root=/dev/sda2 alim7101_wdt.use_gpio=1 console=ttyS0
memcluster 0, usage 1, start        0, end      256
memcluster 1, usage 0, start      256, end   130994
memcluster 2, usage 1, start   130994, end   131072
memcluster 3, usage 0, start   131072, end   524282
memcluster 4, usage 1, start   524282, end   524288
freeing pages 256:384
freeing pages 1805:130994
freeing pages 131072:524282
reserving pages 1805:1813
8192K Bcache detected; load hit latency 18 cycles, load miss latency 165 cycles
Iron stat_cmd 22100006
Iron ECC c00
irongate_init_arch: temporarily reserving region c0000000-ffff3fff for PCI
On node 0 totalpages: 524282
  DMA zone: 14 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 2048 pages, LIFO batch:0
  Normal zone: 3570 pages used for memmap
  Normal zone: 522234 pages, LIFO batch:15
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0 
Built 1 zonelists, mobility grouping on.  Total pages: 520698
Kernel command line: ro root=/dev/sda2 alim7101_wdt.use_gpio=1 console=ttyS0
Dentry cache hash table entries: 524288 (order: 9, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 8, 2097152 bytes)
Sorting __ex_table...
Memory: 3096824K/4194256K available (7843K kernel code, 524K rwdata, 2328K rodata, 168K init, 410K bss, 1097432K reserved, 0K cma-reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS: 16
HWRPB cycle frequency bogus.  Estimated 796476677 Hz
Console: colour VGA+ 80x25
console [ttyS0] enabled
Calibrating delay loop... 1577.12 BogoMIPS (lpj=770048)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 8192 (order: 3, 65536 bytes)
Mountpoint-cache hash table entries: 8192 (order: 3, 65536 bytes)
Performance events: Supported CPU type!
devtmpfs: initialized
random: get_random_u32 called from bucket_table_alloc+0x13c/0x260 with crng_init=0
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1866466235866741 ns
futex hash table entries: 256 (order: -1, 6144 bytes)
NET: Registered protocol family 16
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:00.0: [1022:700e] type 00 class 0x060000
pci 0000:00:00.0: reg 0x14: [mem 0x42000000-0x42000fff pref]
pci 0000:00:00.0: reg 0x18: [io  0x102a0-0x102a3]
pci 0000:00:01.0: [1022:700f] type 01 class 0x060400
pci 0000:00:03.0: [10b9:5457] type 00 class 0x070300
pci 0000:00:03.0: reg 0x10: [mem 0x80970000-0x80970fff]
pci 0000:00:03.0: reg 0x14: [io  0x1000-0x10ff]
pci 0000:00:03.0: PME# supported from D3hot D3cold
pci 0000:00:06.0: [10b9:5451] type 00 class 0x040100
pci 0000:00:06.0: reg 0x10: [io  0x10000-0x100ff]
pci 0000:00:06.0: reg 0x14: [mem 0x80971000-0x80971fff]
pci 0000:00:06.0: supports D1 D2
pci 0000:00:06.0: PME# supported from D2 D3hot D3cold
pci 0000:00:07.0: [10b9:1533] type 00 class 0x060100
pci 0000:00:08.0: [9005:0080] type 00 class 0x010000
pci 0000:00:08.0: reg 0x10: [io  0x10100-0x101ff]
pci 0000:00:08.0: reg 0x14: [mem 0x80972000-0x80972fff 64bit]
pci 0000:00:08.0: reg 0x30: [mem 0x80940000-0x8095ffff pref]
pci 0000:00:09.0: [14e4:1645] type 00 class 0x020000
pci 0000:00:09.0: reg 0x10: [mem 0x80960000-0x8096ffff 64bit]
pci 0000:00:09.0: PME# supported from D3hot D3cold
pci 0000:00:0b.0: [1011:0019] type 00 class 0x020000
pci 0000:00:0b.0: reg 0x10: [io  0x10200-0x1027f]
pci 0000:00:0b.0: reg 0x14: [mem 0x80974000-0x809743ff]
pci 0000:00:0b.0: reg 0x30: [mem 0x80900000-0x8093ffff pref]
pci 0000:00:10.0: [10b9:5229] type 00 class 0x0101fa
pci 0000:00:10.0: [Firmware Bug]: reg 0x10: invalid BAR (can't size)
pci 0000:00:10.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
pci 0000:00:10.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
pci 0000:00:10.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
pci 0000:00:10.0: reg 0x20: [io  0x10290-0x1029f]
pci 0000:00:10.0: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
pci 0000:00:10.0: legacy IDE quirk: reg 0x14: [io  0x03f6]
pci 0000:00:10.0: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
pci 0000:00:10.0: legacy IDE quirk: reg 0x1c: [io  0x0376]
pci 0000:00:11.0: [10b9:7101] type 00 class 0x000000
pci 0000:00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
random: fast init done
pci 0000:00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
pci 0000:00:14.0: [10b9:5237] type 00 class 0x0c0310
pci 0000:00:14.0: reg 0x10: [mem 0x80973000-0x80973fff]
pci 0000:01:05.0: [102b:0525] type 00 class 0x030000
pci 0000:01:05.0: reg 0x10: [mem 0x40000000-0x41ffffff pref]
pci 0000:01:05.0: reg 0x14: [mem 0x80810000-0x80813fff]
pci 0000:01:05.0: reg 0x18: [mem 0x80000000-0x807fffff]
pci 0000:01:05.0: reg 0x30: [mem 0x80800000-0x8080ffff pref]
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
nautilus_init_pci: 1032192k freed
pci 0000:00:01.0: BAR 9: assigned [mem 0xc0000000-0xc2ffffff pref]
pci 0000:00:01.0: BAR 8: assigned [mem 0xff000000-0xffbfffff]
pci 0000:00:0b.0: BAR 6: assigned [mem 0xffc00000-0xffc3ffff pref]
pci 0000:00:08.0: BAR 6: assigned [mem 0xffc40000-0xffc5ffff pref]
pci 0000:00:09.0: BAR 0: assigned [mem 0xffc60000-0xffc6ffff 64bit]
pci 0000:00:03.0: BAR 0: assigned [mem 0xffc70000-0xffc70fff]
pci 0000:00:06.0: BAR 1: assigned [mem 0xffc71000-0xffc71fff]
pci 0000:00:08.0: BAR 1: assigned [mem 0xffc72000-0xffc72fff 64bit]
pci 0000:00:14.0: BAR 0: assigned [mem 0xffc73000-0xffc73fff]
pci 0000:00:0b.0: BAR 1: assigned [mem 0xffc74000-0xffc743ff]
pci 0000:00:03.0: BAR 1: assigned [io  0x8000-0x80ff]
pci 0000:00:06.0: BAR 0: assigned [io  0x8400-0x84ff]
pci 0000:00:08.0: BAR 0: assigned [io  0x8800-0x88ff]
pci 0000:00:0b.0: BAR 0: assigned [io  0x8c00-0x8c7f]
pci 0000:00:10.0: BAR 4: assigned [io  0x8c80-0x8c8f]
pci 0000:01:05.0: BAR 0: assigned [mem 0xc0000000-0xc1ffffff pref]
pci 0000:01:05.0: BAR 2: assigned [mem 0xff000000-0xff7fffff]
pci 0000:01:05.0: BAR 6: assigned [mem 0xc2000000-0xc200ffff pref]
pci 0000:01:05.0: BAR 1: assigned [mem 0xff800000-0xff803fff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0xff000000-0xffbfffff]
pci 0000:00:01.0:   bridge window [mem 0xc0000000-0xc2ffffff pref]
pci 0000:01:05.0: vgaarb: setting as boot VGA device
pci 0000:01:05.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
pci 0000:01:05.0: vgaarb: bridge control possible
vgaarb: loaded
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
Advanced Linux Sound Architecture Driver Initialized.
NET: Registered protocol family 2
tcp_listen_portaddr_hash hash table entries: 2048 (order: 2, 32768 bytes)
TCP established hash table entries: 32768 (order: 5, 262144 bytes)
TCP bind hash table entries: 32768 (order: 5, 262144 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
UDP hash table entries: 2048 (order: 3, 65536 bytes)
UDP-Lite hash table entries: 2048 (order: 3, 65536 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
pci 0000:00:07.0: Activating ISA DMA hang workarounds
pci 0000:00:14.0: quirk_usb_early_handoff+0x0/0x980 took 51521 usecs
PCI: CLS mismatch (64 != 32), using 64 bytes
srm_env: version 0.0.6 loaded successfully
workingset: timestamp_bits=62 max_order=19 bucket_order=0
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A
rtc: SRM (post-2000) epoch (2000) detected
Real Time Clock Driver v1.12b
[drm] radeon kernel modesetting enabled.
loop: module loaded
scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 29160 Ultra160 SCSI adapter>
        aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi 0:0:0:0: Direct-Access     CSC150GB 15K REFURBISHED  0126 PQ: 0 ANSI: 3
scsi0:A:0:0: 
Tagged Queuing enabled.  Depth 253
scsi target0:0:0: Beginning Domain Validation
scsi target0:0:0: wide asynchronous
scsi target0:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 63)
scsi 0:0:0:0: Power-on or device reset occurred
scsi target0:0:0: Ending Domain Validation
scsi host1: pata_ali
scsi host2: pata_ali
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x8c80 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x8c88 irq 15
tg3.c:v3.137 (May 11, 2014)
sd 0:0:0:0: [sda] 286749488 512-byte logical blocks: (147 GB/137 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: ab 00 10 08
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
ata1.00: ATAPI: CD-540E, 1.0A, max UDMA/33
ata1.00: WARNING: ATAPI DMA disabled for reliability issues.  It can be enabled
ata1.00: WARNING: via pata_ali.atapi_dma modparam or corresponding sysfs node.
ata1.00: configured for UDMA/33
scsi 1:0:0:0: CD-ROM            TEAC     CD-540E          1.0A PQ: 0 ANSI: 5
tg3 0000:00:09.0 eth0: Tigon3 [partno(A6825-60101) rev 0105] (PCI:33MHz:32-bit) MAC address 00:17:a4:76:3d:87
tg3 0000:00:09.0 eth0: attached PHY is 5701 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
tg3 0000:00:09.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[0]
tg3 0000:00:09.0 eth0: dma_rwctrl[76ff1b0f] dma_mask[64-bit]
Linux Tulip driver version 1.1.15 (Feb 27, 2007)
tulip0: EEPROM default media type Autosense
tulip0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block
tulip0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block
tulip0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block
tulip0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block
net eth1: Digital DS21142/43 Tulip rev 65 at MMIO 0xffc74000, 00:00:f0:51:19:15, IRQ 11
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-pci: OHCI PCI platform driver
ohci-pci 0000:00:14.0: OHCI PCI host controller
ohci-pci 0000:00:14.0: new USB bus registered, assigned bus number 1
ohci-pci 0000:00:14.0: irq 9, io mem 0xffc73000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
usbcore: registered new interface driver usb-storage
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
ali1535_smbus 0000:00:11.0: enabling device (0000 -> 0001)
i2c i2c-0: found ADM9240 revision 2
hwmon_vid: Unknown VRM version of your CPU
adm9240 0-002c: Using VRM: 0.0
adm9240 0-002c: status: config 0x01 mode 1
atkbd serio0: keyboard reset failed on isa0060/serio0
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
atkbd serio1: keyboard reset failed on isa0060/serio1
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
i2c i2c-0: Error: command never completed
lm75 0-004f: hwmon1: sensor 'lm75'
alim7101_wdt: Steve Hill <steve@navaho.co.uk>
alim7101_wdt: WDT driver for ALi M7101 initialised. timeout=30 sec (nowayout=1)
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
random: crng init done
snd_ali5451 0000:00:06.0: AC'97 1 does not respond - RESET
snd_ali5451 0000:00:06.0: AC'97 1 access is not valid [0xffffffff], removing mixer.
snd_ali5451 0000:00:06.0: ali mixer 1 creating error.
pci_map_single: no HW sg
oprofile: using alpha/ev67 performance monitoring.
NET: Registered protocol family 10
Segment Routing with IPv6
NET: Registered protocol family 17
Key type dns_resolver registered
ALSA device list:
  #0: ALI 5451 at 0x8400, irq 10
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
devtmpfs: mounted
Freeing unused kernel memory: 168K
This architecture does not have kernel memory protection.
udevd[509]: starting version 3.2.5
udevd[510]: starting eudev-3.2.5
tulip 0000:00:0b.0 enp0s11: renamed from eth1
tg3 0000:00:09.0 enp0s9: renamed from eth0
EXT4-fs (sda2): re-mounted. Opts: (null)
IPv6: ADDRCONF(NETDEV_UP): enp0s9: link is not ready
tg3 0000:00:09.0 enp0s9: Link is up at 1000 Mbps, full duplex
tg3 0000:00:09.0 enp0s9: Flow control is on for TX and on for RX
IPv6: ADDRCONF(NETDEV_CHANGE): enp0s9: link becomes ready

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2018-04-17  4:43   ` Matt Turner
@ 2018-04-17 19:43     ` Bjorn Helgaas
  2018-04-18 20:48       ` Ivan Kokshaysky
  0 siblings, 1 reply; 21+ messages in thread
From: Bjorn Helgaas @ 2018-04-17 19:43 UTC (permalink / raw)
  To: Matt Turner
  Cc: Yinghai Lu, linux-pci, linux-alpha, Richard Henderson,
	Ivan Kokshaysky, Jay Estabrook, Bjorn Helgaas

On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
> On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > Hi Matt,
> >
> > First of all, sorry about breaking Nautilus, and thanks very much for
> > tracking it down to this commit.
> 
> It's a particularly weird case, as far as I've been able to discern :)
> 
> > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> >> address limits in resource allocation) broke Alpha systems using
> >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
> >> into the upper addresses just below 4GB.
> >>
> >> I can get a working kernel by ifdef'ing out the code in
> >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> >> kernels.
> >>
> >> How can we get Nautilus working again?
> >
> > Can you collect a complete dmesg log, ideally both before and after
> > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
> > erroneously assign space for something above 4GB.  But if we know the
> > correct host bridge apertures, we shouldn't assign space outside them,
> > regardless of the PCI bus address size.
> 
> I made a mistake in my initial report. Commit f75b99d5a77d is actually
> the last *working* commit. My apologies. The next commit is
> d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
> breaks Nautilus I've confirmed.
> 
> Please find attached dmesgs from those two commits, from the commit
> immediately before them, and another from 4.17-rc1 with my hack of #if
> 0'ing out the pci_bus_alloc_from_region(..., &pci_high) code.
> 
> Thanks for having a look!

We're telling the PCI core that the host bridge MMIO aperture is the
entire 64-bit address space, so when we assign BARs, some of them end
up above 4GB:

  pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
  pci 0000:00:09.0: BAR 0: assigned [mem 0x100000000-0x10000ffff 64bit]

But it sounds like the MMIO aperture really ends at 0xffffffff, so
that's not going to work.

There's probably some register in the chipset that tells us where the
MMIO aperture starts.  The best thing to do would be to read that
register, use it to initialize irongate_mem, and use that as the MMIO
aperture.

But I don't know where to look in the chipset, and it looks like the
current strategy is to infer the base by looking at BAR assignments of
PCI devices.  Can you try the patch below (based on v4.17-rc1) and
save the dmesg and /proc/iomem and /proc/ioports contents?  I'm
guessing at some things here, so I added a few debug printks, too.


diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
index ff4f54b86c7f..093ad6e5c75f 100644
--- a/arch/alpha/kernel/sys_nautilus.c
+++ b/arch/alpha/kernel/sys_nautilus.c
@@ -189,10 +189,14 @@ extern void pcibios_claim_one_bus(struct pci_bus *);
 
 static struct resource irongate_io = {
 	.name	= "Irongate PCI IO",
+	.start	= 0,
+	.end	= 0xffff,
 	.flags	= IORESOURCE_IO,
 };
 static struct resource irongate_mem = {
 	.name	= "Irongate PCI MEM",
+	.start	= 0,
+	.end	= 0xffffffff,
 	.flags	= IORESOURCE_MEM,
 };
 static struct resource busn_resource = {
@@ -208,7 +212,6 @@ nautilus_init_pci(void)
 	struct pci_controller *hose = hose_head;
 	struct pci_host_bridge *bridge;
 	struct pci_bus *bus;
-	struct pci_dev *irongate;
 	unsigned long bus_align, bus_size, pci_mem;
 	unsigned long memtop = max_low_pfn << PAGE_SHIFT;
 	int ret;
@@ -217,8 +220,8 @@ nautilus_init_pci(void)
 	if (!bridge)
 		return;
 
-	pci_add_resource(&bridge->windows, &ioport_resource);
-	pci_add_resource(&bridge->windows, &iomem_resource);
+	pci_add_resource(&bridge->windows, &irongate_io);
+	pci_add_resource(&bridge->windows, &irongate_mem);
 	pci_add_resource(&bridge->windows, &busn_resource);
 	bridge->dev.parent = NULL;
 	bridge->sysdata = hose;
@@ -237,33 +240,30 @@ nautilus_init_pci(void)
 	bus = hose->bus = bridge->bus;
 	pcibios_claim_one_bus(bus);
 
-	irongate = pci_get_domain_bus_and_slot(pci_domain_nr(bus), 0, 0);
-	bus->self = irongate;
-	bus->resource[0] = &irongate_io;
-	bus->resource[1] = &irongate_mem;
-
 	pci_bus_size_bridges(bus);
 
-	/* IO port range. */
-	bus->resource[0]->start = 0;
-	bus->resource[0]->end = 0xffff;
-
+	printk("bus->resource[1] %pR\n", &bus->resource[1]);
 	/* Set up PCI memory range - limit is hardwired to 0xffffffff,
 	   base must be at aligned to 16Mb. */
 	bus_align = bus->resource[1]->start;
 	bus_size = bus->resource[1]->end + 1 - bus_align;
 	if (bus_align < 0x1000000UL)
 		bus_align = 0x1000000UL;
+	printk("bus_align %#lx bus_size %#lx\n", bus_align, bus_size);
 
 	pci_mem = (0x100000000UL - bus_size) & -bus_align;
 
+	printk("memtop %#lx pci_mem %#lx\n", memtop, pci_mem);
+	irongate_mem.start = pci_mem;
 	bus->resource[1]->start = pci_mem;
-	bus->resource[1]->end = 0xffffffffUL;
-	if (request_resource(&iomem_resource, bus->resource[1]) < 0)
-		printk(KERN_ERR "Failed to request MEM on hose 0\n");
+	if (request_resource(&iomem_resource, &irongate_mem) < 0)
+		printk(KERN_ERR "Failed to request %pR on hose 0\n",
+		       &irongate_mem);
 
 	if (pci_mem < memtop)
 		memtop = pci_mem;
+	printk("memtop %#lx alpha_mv.min_mem_address %#lx\n", memtop,
+	       alpha_mv.min_mem_address);
 	if (memtop > alpha_mv.min_mem_address) {
 		free_reserved_area(__va(alpha_mv.min_mem_address),
 				   __va(memtop), -1, NULL);

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2018-04-17 19:43     ` Bjorn Helgaas
@ 2018-04-18 20:48       ` Ivan Kokshaysky
  2018-04-20 17:03         ` Bjorn Helgaas
  2018-04-22 20:07         ` Matt Turner
  0 siblings, 2 replies; 21+ messages in thread
From: Ivan Kokshaysky @ 2018-04-18 20:48 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Matt Turner, Yinghai Lu, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Bjorn Helgaas

On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
> On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
> > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > Hi Matt,
> > >
> > > First of all, sorry about breaking Nautilus, and thanks very much for
> > > tracking it down to this commit.
> > 
> > It's a particularly weird case, as far as I've been able to discern :)
> > 
> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> > >> address limits in resource allocation) broke Alpha systems using
> > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
> > >> into the upper addresses just below 4GB.
> > >>
> > >> I can get a working kernel by ifdef'ing out the code in
> > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> > >> kernels.
> > >>
> > >> How can we get Nautilus working again?
> > >
> > > Can you collect a complete dmesg log, ideally both before and after
> > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
> > > erroneously assign space for something above 4GB.  But if we know the
> > > correct host bridge apertures, we shouldn't assign space outside them,
> > > regardless of the PCI bus address size.
> > 
> > I made a mistake in my initial report. Commit f75b99d5a77d is actually
> > the last *working* commit. My apologies. The next commit is
> > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
> > breaks Nautilus I've confirmed.
> > 
> > Please find attached dmesgs from those two commits, from the commit
> > immediately before them, and another from 4.17-rc1 with my hack of #if
> > 0'ing out the pci_bus_alloc_from_region(..., &pci_high) code.
> > 
> > Thanks for having a look!
> 
> We're telling the PCI core that the host bridge MMIO aperture is the
> entire 64-bit address space, so when we assign BARs, some of them end
> up above 4GB:
> 
>   pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
>   pci 0000:00:09.0: BAR 0: assigned [mem 0x100000000-0x10000ffff 64bit]
> 
> But it sounds like the MMIO aperture really ends at 0xffffffff, so
> that's not going to work.

Correct... This would do as a quick fix, I think:

diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
index ff4f54b..477ba65 100644
--- a/arch/alpha/kernel/sys_nautilus.c
+++ b/arch/alpha/kernel/sys_nautilus.c
@@ -193,6 +193,8 @@ static struct resource irongate_io = {
 };
 static struct resource irongate_mem = {
 	.name	= "Irongate PCI MEM",
+	.start	= 0,
+	.end	= 0xffffffff,
 	.flags	= IORESOURCE_MEM,
 };
 static struct resource busn_resource = {
@@ -218,7 +220,7 @@ nautilus_init_pci(void)
 		return;
 
 	pci_add_resource(&bridge->windows, &ioport_resource);
-	pci_add_resource(&bridge->windows, &iomem_resource);
+	pci_add_resource(&bridge->windows, &irongate_mem);
 	pci_add_resource(&bridge->windows, &busn_resource);
 	bridge->dev.parent = NULL;
 	bridge->sysdata = hose;


> There's probably some register in the chipset that tells us where the
> MMIO aperture starts.  The best thing to do would be to read that
> register, use it to initialize irongate_mem, and use that as the MMIO
> aperture.

Surely there is the register, namely IRONGATE0->pci_mem, but it's
basically write-only for us as it contains utter crap on bootup.

> But I don't know where to look in the chipset, and it looks like the
> current strategy is to infer the base by looking at BAR assignments of
> PCI devices.  Can you try the patch below (based on v4.17-rc1) and
> save the dmesg and /proc/iomem and /proc/ioports contents?  I'm
> guessing at some things here, so I added a few debug printks, too.

No, the strategy was to do PCI resource allocations from scratch,
minimizing MMIO aperture to save as much RAM as possible in 4Gb
memory configuration. That's what all that hackery with bus sizing
was for. We pretended that irongate is sort of non-standard p2p bridge
(which is almost true wrt internal alpha ev6 "host bridge"),
called pci_bus_size_bridges() for it, then moved calculated MMIO
window up to 4G boundary and then did normal "assign unassigned".
However, it was broken long time ago in a more subtle way - even in
Matt's dmesg from working 3.13 kernels AGP framebuffer resource ended
up either unassigned or in the wrong place. This is relatively harmless
if you don't use graphics though. Not sure how to fix that, this
"root bridge" approach looks rather limiting to me.

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2018-04-18 20:48       ` Ivan Kokshaysky
@ 2018-04-20 17:03         ` Bjorn Helgaas
  2018-04-22 20:07         ` Matt Turner
  1 sibling, 0 replies; 21+ messages in thread
From: Bjorn Helgaas @ 2018-04-20 17:03 UTC (permalink / raw)
  To: Ivan Kokshaysky
  Cc: Matt Turner, Yinghai Lu, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Bjorn Helgaas

On Wed, Apr 18, 2018 at 09:48:08PM +0100, Ivan Kokshaysky wrote:
> On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
> > On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
> > > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > Hi Matt,
> > > >
> > > > First of all, sorry about breaking Nautilus, and thanks very much for
> > > > tracking it down to this commit.
> > > 
> > > It's a particularly weird case, as far as I've been able to discern :)
> > > 
> > > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> > > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> > > >> address limits in resource allocation) broke Alpha systems using
> > > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> > > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
> > > >> into the upper addresses just below 4GB.
> > > >>
> > > >> I can get a working kernel by ifdef'ing out the code in
> > > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> > > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> > > >> kernels.
> > > >>
> > > >> How can we get Nautilus working again?
> > > >
> > > > Can you collect a complete dmesg log, ideally both before and after
> > > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
> > > > erroneously assign space for something above 4GB.  But if we know the
> > > > correct host bridge apertures, we shouldn't assign space outside them,
> > > > regardless of the PCI bus address size.
> > > 
> > > I made a mistake in my initial report. Commit f75b99d5a77d is actually
> > > the last *working* commit. My apologies. The next commit is
> > > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
> > > breaks Nautilus I've confirmed.
> > > 
> > > Please find attached dmesgs from those two commits, from the commit
> > > immediately before them, and another from 4.17-rc1 with my hack of #if
> > > 0'ing out the pci_bus_alloc_from_region(..., &pci_high) code.
> > > 
> > > Thanks for having a look!
> > 
> > We're telling the PCI core that the host bridge MMIO aperture is the
> > entire 64-bit address space, so when we assign BARs, some of them end
> > up above 4GB:
> > 
> >   pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
> >   pci 0000:00:09.0: BAR 0: assigned [mem 0x100000000-0x10000ffff 64bit]
> > 
> > But it sounds like the MMIO aperture really ends at 0xffffffff, so
> > that's not going to work.
> 
> Correct... This would do as a quick fix, I think:
> 
> diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
> index ff4f54b..477ba65 100644
> --- a/arch/alpha/kernel/sys_nautilus.c
> +++ b/arch/alpha/kernel/sys_nautilus.c
> @@ -193,6 +193,8 @@ static struct resource irongate_io = {
>  };
>  static struct resource irongate_mem = {
>  	.name	= "Irongate PCI MEM",
> +	.start	= 0,
> +	.end	= 0xffffffff,
>  	.flags	= IORESOURCE_MEM,
>  };
>  static struct resource busn_resource = {
> @@ -218,7 +220,7 @@ nautilus_init_pci(void)
>  		return;
>  
>  	pci_add_resource(&bridge->windows, &ioport_resource);
> -	pci_add_resource(&bridge->windows, &iomem_resource);
> +	pci_add_resource(&bridge->windows, &irongate_mem);
>  	pci_add_resource(&bridge->windows, &busn_resource);
>  	bridge->dev.parent = NULL;
>  	bridge->sysdata = hose;

If it works for Matt, that looks reasonable to me.

> > There's probably some register in the chipset that tells us where the
> > MMIO aperture starts.  The best thing to do would be to read that
> > register, use it to initialize irongate_mem, and use that as the MMIO
> > aperture.
> 
> Surely there is the register, namely IRONGATE0->pci_mem, but it's
> basically write-only for us as it contains utter crap on bootup.
> 
> > But I don't know where to look in the chipset, and it looks like the
> > current strategy is to infer the base by looking at BAR assignments of
> > PCI devices.  Can you try the patch below (based on v4.17-rc1) and
> > save the dmesg and /proc/iomem and /proc/ioports contents?  I'm
> > guessing at some things here, so I added a few debug printks, too.
> 
> No, the strategy was to do PCI resource allocations from scratch,
> minimizing MMIO aperture to save as much RAM as possible in 4Gb
> memory configuration. That's what all that hackery with bus sizing
> was for. We pretended that irongate is sort of non-standard p2p bridge
> (which is almost true wrt internal alpha ev6 "host bridge"),
> called pci_bus_size_bridges() for it, then moved calculated MMIO
> window up to 4G boundary and then did normal "assign unassigned".
> However, it was broken long time ago in a more subtle way - even in
> Matt's dmesg from working 3.13 kernels AGP framebuffer resource ended
> up either unassigned or in the wrong place. This is relatively harmless
> if you don't use graphics though. Not sure how to fix that, this
> "root bridge" approach looks rather limiting to me.

I think the suggestion is that we should be able to enumerate all the
devices and learn their resource requirements, which only requires
config accesses and can be done with no MMIO accesses at all, and then
use that information to compute the size of the host bridge aperture,
program it, and enable it.

That does make good sense.  The problem in the ACPI world is that we
don't know how to program that host bridge aperture.  The firmware
tells us what it is with the _CRS (current resource settings) method.
There is a provision for changing it via _PRS and _SRS ("possible" and
"set" resource settings), but AFAIK no platforms implement those for
PCI host bridges, and Linux doesn't support them.

So I guess for now we're stuck with assuming a basically fixed
aperture, unless we hack around like Nautilus does.

Bjorn

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2018-04-18 20:48       ` Ivan Kokshaysky
  2018-04-20 17:03         ` Bjorn Helgaas
@ 2018-04-22 20:07         ` Matt Turner
  2018-04-23 17:34           ` Ivan Kokshaysky
  1 sibling, 1 reply; 21+ messages in thread
From: Matt Turner @ 2018-04-22 20:07 UTC (permalink / raw)
  To: Ivan Kokshaysky
  Cc: Bjorn Helgaas, Yinghai Lu, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Bjorn Helgaas

On Wed, Apr 18, 2018 at 1:48 PM, Ivan Kokshaysky
<ink@jurassic.park.msu.ru> wrote:
> On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
>> On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
>> > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > > Hi Matt,
>> > >
>> > > First of all, sorry about breaking Nautilus, and thanks very much for
>> > > tracking it down to this commit.
>> >
>> > It's a particularly weird case, as far as I've been able to discern :)
>> >
>> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
>> > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
>> > >> address limits in resource allocation) broke Alpha systems using
>> > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
>> > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
>> > >> into the upper addresses just below 4GB.
>> > >>
>> > >> I can get a working kernel by ifdef'ing out the code in
>> > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
>> > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
>> > >> kernels.
>> > >>
>> > >> How can we get Nautilus working again?
>> > >
>> > > Can you collect a complete dmesg log, ideally both before and after
>> > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
>> > > erroneously assign space for something above 4GB.  But if we know the
>> > > correct host bridge apertures, we shouldn't assign space outside them,
>> > > regardless of the PCI bus address size.
>> >
>> > I made a mistake in my initial report. Commit f75b99d5a77d is actually
>> > the last *working* commit. My apologies. The next commit is
>> > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
>> > breaks Nautilus I've confirmed.
>> >
>> > Please find attached dmesgs from those two commits, from the commit
>> > immediately before them, and another from 4.17-rc1 with my hack of #if
>> > 0'ing out the pci_bus_alloc_from_region(..., &pci_high) code.
>> >
>> > Thanks for having a look!
>>
>> We're telling the PCI core that the host bridge MMIO aperture is the
>> entire 64-bit address space, so when we assign BARs, some of them end
>> up above 4GB:
>>
>>   pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
>>   pci 0000:00:09.0: BAR 0: assigned [mem 0x100000000-0x10000ffff 64bit]
>>
>> But it sounds like the MMIO aperture really ends at 0xffffffff, so
>> that's not going to work.
>
> Correct... This would do as a quick fix, I think:
>
> diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
> index ff4f54b..477ba65 100644
> --- a/arch/alpha/kernel/sys_nautilus.c
> +++ b/arch/alpha/kernel/sys_nautilus.c
> @@ -193,6 +193,8 @@ static struct resource irongate_io = {
>  };
>  static struct resource irongate_mem = {
>         .name   = "Irongate PCI MEM",
> +       .start  = 0,
> +       .end    = 0xffffffff,
>         .flags  = IORESOURCE_MEM,
>  };
>  static struct resource busn_resource = {
> @@ -218,7 +220,7 @@ nautilus_init_pci(void)
>                 return;
>
>         pci_add_resource(&bridge->windows, &ioport_resource);
> -       pci_add_resource(&bridge->windows, &iomem_resource);
> +       pci_add_resource(&bridge->windows, &irongate_mem);
>         pci_add_resource(&bridge->windows, &busn_resource);
>         bridge->dev.parent = NULL;
>         bridge->sysdata = hose;

Thanks. But with that I get

PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:10.0: [Firmware Bug]: reg 0x10: invalid BAR (can't size)
pci 0000:00:10.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
pci 0000:00:10.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
pci 0000:00:10.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
pci 0000:00:10.0: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
pci 0000:00:10.0: legacy IDE quirk: reg 0x14: [io  0x03f6]
pci 0000:00:10.0: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
pci 0000:00:10.0: legacy IDE quirk: reg 0x1c: [io  0x0376]
pci 0000:00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
pci 0000:00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
pci 0000:00:01.0: BAR 9: assigned [mem 0xc0000000-0xc2ffffff pref]
pci 0000:00:01.0: BAR 8: assigned [mem 0xc3000000-0xc3bfffff]
pci 0000:00:0b.0: BAR 6: assigned [mem 0xc3c00000-0xc3c3ffff pref]
pci 0000:00:08.0: BAR 6: assigned [mem 0xc3c40000-0xc3c5ffff pref]
pci 0000:00:09.0: BAR 0: assigned [mem 0xc3c60000-0xc3c6ffff 64bit]
pci 0000:00:03.0: BAR 0: assigned [mem 0xc3c70000-0xc3c70fff]
pci 0000:00:06.0: BAR 1: assigned [mem 0xc3c71000-0xc3c71fff]
pci 0000:00:08.0: BAR 1: assigned [mem 0xc3c72000-0xc3c72fff 64bit]
pci 0000:00:14.0: BAR 0: assigned [mem 0xc3c73000-0xc3c73fff]
pci 0000:00:0b.0: BAR 1: assigned [mem 0xc3c74000-0xc3c743ff]
pci 0000:00:03.0: BAR 1: assigned [io  0x8000-0x80ff]
pci 0000:00:06.0: BAR 0: assigned [io  0x8400-0x84ff]
pci 0000:00:08.0: BAR 0: assigned [io  0x8800-0x88ff]
pci 0000:00:0b.0: BAR 0: assigned [io  0x8c00-0x8c7f]
pci 0000:00:10.0: BAR 4: assigned [io  0x8c80-0x8c8f]
pci 0000:01:05.0: BAR 0: assigned [mem 0xc0000000-0xc1ffffff pref]
pci 0000:01:05.0: BAR 2: assigned [mem 0xc3000000-0xc37fffff]
pci 0000:01:05.0: BAR 6: assigned [mem 0xc2000000-0xc200ffff pref]
pci 0000:01:05.0: BAR 1: assigned [mem 0xc3800000-0xc3803fff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0xc3000000-0xc3bfffff]
pci 0000:00:01.0:   bridge window [mem 0xc0000000-0xc2ffffff pref]

Looks like the bridge window is overlapping with some previously assigned BARs?

The result is the SCSI card failing to work:

scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
        <Adaptec 29160 Ultra160 SCSI adapter>
        aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

scsi0: ahc_intr - referenced scb not valid during SELTO scb(0, 255)
>>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
scsi0: Dumping Card State while idle, at SEQADDR 0x18
[snip endless spew]

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2018-04-22 20:07         ` Matt Turner
@ 2018-04-23 17:34           ` Ivan Kokshaysky
  2018-05-02 20:33             ` Bjorn Helgaas
                               ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: Ivan Kokshaysky @ 2018-04-23 17:34 UTC (permalink / raw)
  To: Matt Turner
  Cc: Bjorn Helgaas, Yinghai Lu, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Bjorn Helgaas

On Sun, Apr 22, 2018 at 01:07:38PM -0700, Matt Turner wrote:
> On Wed, Apr 18, 2018 at 1:48 PM, Ivan Kokshaysky
> <ink@jurassic.park.msu.ru> wrote:
> > On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
> >> On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
> >> > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >> > > Hi Matt,
> >> > >
> >> > > First of all, sorry about breaking Nautilus, and thanks very much for
> >> > > tracking it down to this commit.
> >> >
> >> > It's a particularly weird case, as far as I've been able to discern :)
> >> >
> >> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> >> > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> >> > >> address limits in resource allocation) broke Alpha systems using
> >> > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> >> > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
> >> > >> into the upper addresses just below 4GB.
> >> > >>
> >> > >> I can get a working kernel by ifdef'ing out the code in
> >> > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> >> > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> >> > >> kernels.
> >> > >>
> >> > >> How can we get Nautilus working again?
> >> > >
> >> > > Can you collect a complete dmesg log, ideally both before and after
> >> > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
> >> > > erroneously assign space for something above 4GB.  But if we know the
> >> > > correct host bridge apertures, we shouldn't assign space outside them,
> >> > > regardless of the PCI bus address size.
> >> >
> >> > I made a mistake in my initial report. Commit f75b99d5a77d is actually
> >> > the last *working* commit. My apologies. The next commit is
> >> > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
> >> > breaks Nautilus I've confirmed.
> >> >
> >> > Please find attached dmesgs from those two commits, from the commit
> >> > immediately before them, and another from 4.17-rc1 with my hack of #if
> >> > 0'ing out the pci_bus_alloc_from_region(..., &pci_high) code.
> >> >
> >> > Thanks for having a look!
> >>
> >> We're telling the PCI core that the host bridge MMIO aperture is the
> >> entire 64-bit address space, so when we assign BARs, some of them end
> >> up above 4GB:
> >>
> >>   pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
> >>   pci 0000:00:09.0: BAR 0: assigned [mem 0x100000000-0x10000ffff 64bit]
> >>
> >> But it sounds like the MMIO aperture really ends at 0xffffffff, so
> >> that's not going to work.
> >
> > Correct... This would do as a quick fix, I think:
> >
> > diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
> > index ff4f54b..477ba65 100644
> > --- a/arch/alpha/kernel/sys_nautilus.c
> > +++ b/arch/alpha/kernel/sys_nautilus.c
> > @@ -193,6 +193,8 @@ static struct resource irongate_io = {
> >  };
> >  static struct resource irongate_mem = {
> >         .name   = "Irongate PCI MEM",
> > +       .start  = 0,
> > +       .end    = 0xffffffff,
> >         .flags  = IORESOURCE_MEM,
> >  };
> >  static struct resource busn_resource = {
> > @@ -218,7 +220,7 @@ nautilus_init_pci(void)
> >                 return;
> >
> >         pci_add_resource(&bridge->windows, &ioport_resource);
> > -       pci_add_resource(&bridge->windows, &iomem_resource);
> > +       pci_add_resource(&bridge->windows, &irongate_mem);
> >         pci_add_resource(&bridge->windows, &busn_resource);
> >         bridge->dev.parent = NULL;
> >         bridge->sysdata = hose;
> 
> Thanks. But with that I get
> 
> PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffff]
> pci_bus 0000:00: root bus resource [bus 00-ff]
> pci 0000:00:10.0: [Firmware Bug]: reg 0x10: invalid BAR (can't size)
> pci 0000:00:10.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
> pci 0000:00:10.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
> pci 0000:00:10.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
> pci 0000:00:10.0: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
> pci 0000:00:10.0: legacy IDE quirk: reg 0x14: [io  0x03f6]
> pci 0000:00:10.0: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
> pci 0000:00:10.0: legacy IDE quirk: reg 0x1c: [io  0x0376]
> pci 0000:00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
> pci 0000:00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
> pci 0000:00:01.0: BAR 9: assigned [mem 0xc0000000-0xc2ffffff pref]
> pci 0000:00:01.0: BAR 8: assigned [mem 0xc3000000-0xc3bfffff]
> pci 0000:00:0b.0: BAR 6: assigned [mem 0xc3c00000-0xc3c3ffff pref]
> pci 0000:00:08.0: BAR 6: assigned [mem 0xc3c40000-0xc3c5ffff pref]
> pci 0000:00:09.0: BAR 0: assigned [mem 0xc3c60000-0xc3c6ffff 64bit]
> pci 0000:00:03.0: BAR 0: assigned [mem 0xc3c70000-0xc3c70fff]
> pci 0000:00:06.0: BAR 1: assigned [mem 0xc3c71000-0xc3c71fff]
> pci 0000:00:08.0: BAR 1: assigned [mem 0xc3c72000-0xc3c72fff 64bit]
> pci 0000:00:14.0: BAR 0: assigned [mem 0xc3c73000-0xc3c73fff]
> pci 0000:00:0b.0: BAR 1: assigned [mem 0xc3c74000-0xc3c743ff]
> pci 0000:00:03.0: BAR 1: assigned [io  0x8000-0x80ff]
> pci 0000:00:06.0: BAR 0: assigned [io  0x8400-0x84ff]
> pci 0000:00:08.0: BAR 0: assigned [io  0x8800-0x88ff]
> pci 0000:00:0b.0: BAR 0: assigned [io  0x8c00-0x8c7f]
> pci 0000:00:10.0: BAR 4: assigned [io  0x8c80-0x8c8f]
> pci 0000:01:05.0: BAR 0: assigned [mem 0xc0000000-0xc1ffffff pref]
> pci 0000:01:05.0: BAR 2: assigned [mem 0xc3000000-0xc37fffff]
> pci 0000:01:05.0: BAR 6: assigned [mem 0xc2000000-0xc200ffff pref]
> pci 0000:01:05.0: BAR 1: assigned [mem 0xc3800000-0xc3803fff]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0xc3000000-0xc3bfffff]
> pci 0000:00:01.0:   bridge window [mem 0xc0000000-0xc2ffffff pref]
> 
> Looks like the bridge window is overlapping with some previously assigned BARs?

No, there are no overlaps. This is AGP bridge window with AGP card BARs
inside it.

> The result is the SCSI card failing to work:
> 
> scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
>         <Adaptec 29160 Ultra160 SCSI adapter>
>         aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
> 
> scsi0: ahc_intr - referenced scb not valid during SELTO scb(0, 255)
> >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
> scsi0: Dumping Card State while idle, at SEQADDR 0x18
> [snip endless spew]

It looks like Irongate PCI memory window setting is completely wrong,
perhaps it starts at zero, so that PCI DMA doesn't work at all.

Please try the patch below. It tries to fix things properly, but if
PCI bus sizing fails for some reason, it falls back to a "safe" PCI
memory window placement at 3GB.

Ivan.

diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
index ff4f54b..b1fb9fd 100644
--- a/arch/alpha/kernel/sys_nautilus.c
+++ b/arch/alpha/kernel/sys_nautilus.c
@@ -187,10 +187,6 @@ nautilus_machine_check(unsigned long vector, unsigned long la_ptr)
 
 extern void pcibios_claim_one_bus(struct pci_bus *);
 
-static struct resource irongate_io = {
-	.name	= "Irongate PCI IO",
-	.flags	= IORESOURCE_IO,
-};
 static struct resource irongate_mem = {
 	.name	= "Irongate PCI MEM",
 	.flags	= IORESOURCE_MEM,
@@ -218,7 +214,7 @@ nautilus_init_pci(void)
 		return;
 
 	pci_add_resource(&bridge->windows, &ioport_resource);
-	pci_add_resource(&bridge->windows, &iomem_resource);
+	pci_add_resource(&bridge->windows, &irongate_mem);
 	pci_add_resource(&bridge->windows, &busn_resource);
 	bridge->dev.parent = NULL;
 	bridge->sysdata = hose;
@@ -238,20 +234,25 @@ nautilus_init_pci(void)
 	pcibios_claim_one_bus(bus);
 
 	irongate = pci_get_domain_bus_and_slot(pci_domain_nr(bus), 0, 0);
+	/* Pretend that it's not a root bus to allow sizing. */
+	bus->parent = bus;
 	bus->self = irongate;
-	bus->resource[0] = &irongate_io;
-	bus->resource[1] = &irongate_mem;
 
 	pci_bus_size_bridges(bus);
-
-	/* IO port range. */
-	bus->resource[0]->start = 0;
-	bus->resource[0]->end = 0xffff;
+	bus->parent = NULL;
 
 	/* Set up PCI memory range - limit is hardwired to 0xffffffff,
 	   base must be at aligned to 16Mb. */
-	bus_align = bus->resource[1]->start;
-	bus_size = bus->resource[1]->end + 1 - bus_align;
+	if (bus->resource[1]->end) {
+		bus_align = bus->resource[1]->start;
+		bus_size = bus->resource[1]->end + 1 - bus_align;
+		printk(KERN_INFO "PCI MEM size 0x%08lx, align 0x%08lx\n",
+			bus_size, bus_align);
+	} else {
+		bus_size = 0x100000000UL - memtop;
+		bus_align = bus_size;
+		printk(KERN_ERR "PCI MEM sizing failed, using 3GB limit\n");
+	}
 	if (bus_align < 0x1000000UL)
 		bus_align = 0x1000000UL;
 

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2018-04-23 17:34           ` Ivan Kokshaysky
@ 2018-05-02 20:33             ` Bjorn Helgaas
  2018-05-02 21:10               ` Matt Turner
  2018-05-07  0:46             ` Matt Turner
  2019-10-18  5:57             ` Matt Turner
  2 siblings, 1 reply; 21+ messages in thread
From: Bjorn Helgaas @ 2018-05-02 20:33 UTC (permalink / raw)
  To: Ivan Kokshaysky
  Cc: Matt Turner, Yinghai Lu, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Bjorn Helgaas

On Mon, Apr 23, 2018 at 06:34:23PM +0100, Ivan Kokshaysky wrote:
> On Sun, Apr 22, 2018 at 01:07:38PM -0700, Matt Turner wrote:
> > On Wed, Apr 18, 2018 at 1:48 PM, Ivan Kokshaysky
> > <ink@jurassic.park.msu.ru> wrote:
> > > On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
> > >> On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
> > >> > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > >> > > Hi Matt,
> > >> > >
> > >> > > First of all, sorry about breaking Nautilus, and thanks very much for
> > >> > > tracking it down to this commit.
> > >> >
> > >> > It's a particularly weird case, as far as I've been able to discern :)
> > >> >
> > >> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> > >> > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> > >> > >> address limits in resource allocation) broke Alpha systems using
> > >> > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> > >> > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
> > >> > >> into the upper addresses just below 4GB.
> > >> > >>
> > >> > >> I can get a working kernel by ifdef'ing out the code in
> > >> > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> > >> > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> > >> > >> kernels.
> > >> > >>
> > >> > >> How can we get Nautilus working again?
> > >> > >
> > >> > > Can you collect a complete dmesg log, ideally both before and after
> > >> > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
> > >> > > erroneously assign space for something above 4GB.  But if we know the
> > >> > > correct host bridge apertures, we shouldn't assign space outside them,
> > >> > > regardless of the PCI bus address size.
> > >> >
> > >> > I made a mistake in my initial report. Commit f75b99d5a77d is actually
> > >> > the last *working* commit. My apologies. The next commit is
> > >> > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
> > >> > breaks Nautilus I've confirmed.
> > >> >
> > >> > Please find attached dmesgs from those two commits, from the commit
> > >> > immediately before them, and another from 4.17-rc1 with my hack of #if
> > >> > 0'ing out the pci_bus_alloc_from_region(..., &pci_high) code.
> > >> >
> > >> > Thanks for having a look!
> > >>
> > >> We're telling the PCI core that the host bridge MMIO aperture is the
> > >> entire 64-bit address space, so when we assign BARs, some of them end
> > >> up above 4GB:
> > >>
> > >>   pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
> > >>   pci 0000:00:09.0: BAR 0: assigned [mem 0x100000000-0x10000ffff 64bit]
> > >>
> > >> But it sounds like the MMIO aperture really ends at 0xffffffff, so
> > >> that's not going to work.
> > >
> > > Correct... This would do as a quick fix, I think:
> > >
> > > diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
> > > index ff4f54b..477ba65 100644
> > > --- a/arch/alpha/kernel/sys_nautilus.c
> > > +++ b/arch/alpha/kernel/sys_nautilus.c
> > > @@ -193,6 +193,8 @@ static struct resource irongate_io = {
> > >  };
> > >  static struct resource irongate_mem = {
> > >         .name   = "Irongate PCI MEM",
> > > +       .start  = 0,
> > > +       .end    = 0xffffffff,
> > >         .flags  = IORESOURCE_MEM,
> > >  };
> > >  static struct resource busn_resource = {
> > > @@ -218,7 +220,7 @@ nautilus_init_pci(void)
> > >                 return;
> > >
> > >         pci_add_resource(&bridge->windows, &ioport_resource);
> > > -       pci_add_resource(&bridge->windows, &iomem_resource);
> > > +       pci_add_resource(&bridge->windows, &irongate_mem);
> > >         pci_add_resource(&bridge->windows, &busn_resource);
> > >         bridge->dev.parent = NULL;
> > >         bridge->sysdata = hose;
> > 
> > Thanks. But with that I get
> > 
> > PCI host bridge to bus 0000:00
> > pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffff]
> > pci_bus 0000:00: root bus resource [bus 00-ff]
> > pci 0000:00:10.0: [Firmware Bug]: reg 0x10: invalid BAR (can't size)
> > pci 0000:00:10.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
> > pci 0000:00:10.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
> > pci 0000:00:10.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
> > pci 0000:00:10.0: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
> > pci 0000:00:10.0: legacy IDE quirk: reg 0x14: [io  0x03f6]
> > pci 0000:00:10.0: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
> > pci 0000:00:10.0: legacy IDE quirk: reg 0x1c: [io  0x0376]
> > pci 0000:00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
> > pci 0000:00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
> > pci 0000:00:01.0: BAR 9: assigned [mem 0xc0000000-0xc2ffffff pref]
> > pci 0000:00:01.0: BAR 8: assigned [mem 0xc3000000-0xc3bfffff]
> > pci 0000:00:0b.0: BAR 6: assigned [mem 0xc3c00000-0xc3c3ffff pref]
> > pci 0000:00:08.0: BAR 6: assigned [mem 0xc3c40000-0xc3c5ffff pref]
> > pci 0000:00:09.0: BAR 0: assigned [mem 0xc3c60000-0xc3c6ffff 64bit]
> > pci 0000:00:03.0: BAR 0: assigned [mem 0xc3c70000-0xc3c70fff]
> > pci 0000:00:06.0: BAR 1: assigned [mem 0xc3c71000-0xc3c71fff]
> > pci 0000:00:08.0: BAR 1: assigned [mem 0xc3c72000-0xc3c72fff 64bit]
> > pci 0000:00:14.0: BAR 0: assigned [mem 0xc3c73000-0xc3c73fff]
> > pci 0000:00:0b.0: BAR 1: assigned [mem 0xc3c74000-0xc3c743ff]
> > pci 0000:00:03.0: BAR 1: assigned [io  0x8000-0x80ff]
> > pci 0000:00:06.0: BAR 0: assigned [io  0x8400-0x84ff]
> > pci 0000:00:08.0: BAR 0: assigned [io  0x8800-0x88ff]
> > pci 0000:00:0b.0: BAR 0: assigned [io  0x8c00-0x8c7f]
> > pci 0000:00:10.0: BAR 4: assigned [io  0x8c80-0x8c8f]
> > pci 0000:01:05.0: BAR 0: assigned [mem 0xc0000000-0xc1ffffff pref]
> > pci 0000:01:05.0: BAR 2: assigned [mem 0xc3000000-0xc37fffff]
> > pci 0000:01:05.0: BAR 6: assigned [mem 0xc2000000-0xc200ffff pref]
> > pci 0000:01:05.0: BAR 1: assigned [mem 0xc3800000-0xc3803fff]
> > pci 0000:00:01.0: PCI bridge to [bus 01]
> > pci 0000:00:01.0:   bridge window [mem 0xc3000000-0xc3bfffff]
> > pci 0000:00:01.0:   bridge window [mem 0xc0000000-0xc2ffffff pref]
> > 
> > Looks like the bridge window is overlapping with some previously assigned BARs?
> 
> No, there are no overlaps. This is AGP bridge window with AGP card BARs
> inside it.
> 
> > The result is the SCSI card failing to work:
> > 
> > scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
> >         <Adaptec 29160 Ultra160 SCSI adapter>
> >         aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
> > 
> > scsi0: ahc_intr - referenced scb not valid during SELTO scb(0, 255)
> > >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
> > scsi0: Dumping Card State while idle, at SEQADDR 0x18
> > [snip endless spew]
> 
> It looks like Irongate PCI memory window setting is completely wrong,
> perhaps it starts at zero, so that PCI DMA doesn't work at all.
> 
> Please try the patch below. It tries to fix things properly, but if
> PCI bus sizing fails for some reason, it falls back to a "safe" PCI
> memory window placement at 3GB.

Ping, Matt, any feedback on this patch?

> diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
> index ff4f54b..b1fb9fd 100644
> --- a/arch/alpha/kernel/sys_nautilus.c
> +++ b/arch/alpha/kernel/sys_nautilus.c
> @@ -187,10 +187,6 @@ nautilus_machine_check(unsigned long vector, unsigned long la_ptr)
>  
>  extern void pcibios_claim_one_bus(struct pci_bus *);
>  
> -static struct resource irongate_io = {
> -	.name	= "Irongate PCI IO",
> -	.flags	= IORESOURCE_IO,
> -};
>  static struct resource irongate_mem = {
>  	.name	= "Irongate PCI MEM",
>  	.flags	= IORESOURCE_MEM,
> @@ -218,7 +214,7 @@ nautilus_init_pci(void)
>  		return;
>  
>  	pci_add_resource(&bridge->windows, &ioport_resource);
> -	pci_add_resource(&bridge->windows, &iomem_resource);
> +	pci_add_resource(&bridge->windows, &irongate_mem);
>  	pci_add_resource(&bridge->windows, &busn_resource);
>  	bridge->dev.parent = NULL;
>  	bridge->sysdata = hose;
> @@ -238,20 +234,25 @@ nautilus_init_pci(void)
>  	pcibios_claim_one_bus(bus);
>  
>  	irongate = pci_get_domain_bus_and_slot(pci_domain_nr(bus), 0, 0);
> +	/* Pretend that it's not a root bus to allow sizing. */
> +	bus->parent = bus;
>  	bus->self = irongate;
> -	bus->resource[0] = &irongate_io;
> -	bus->resource[1] = &irongate_mem;
>  
>  	pci_bus_size_bridges(bus);
> -
> -	/* IO port range. */
> -	bus->resource[0]->start = 0;
> -	bus->resource[0]->end = 0xffff;
> +	bus->parent = NULL;
>  
>  	/* Set up PCI memory range - limit is hardwired to 0xffffffff,
>  	   base must be at aligned to 16Mb. */
> -	bus_align = bus->resource[1]->start;
> -	bus_size = bus->resource[1]->end + 1 - bus_align;
> +	if (bus->resource[1]->end) {
> +		bus_align = bus->resource[1]->start;
> +		bus_size = bus->resource[1]->end + 1 - bus_align;
> +		printk(KERN_INFO "PCI MEM size 0x%08lx, align 0x%08lx\n",
> +			bus_size, bus_align);
> +	} else {
> +		bus_size = 0x100000000UL - memtop;
> +		bus_align = bus_size;
> +		printk(KERN_ERR "PCI MEM sizing failed, using 3GB limit\n");
> +	}
>  	if (bus_align < 0x1000000UL)
>  		bus_align = 0x1000000UL;
>  

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2018-05-02 20:33             ` Bjorn Helgaas
@ 2018-05-02 21:10               ` Matt Turner
  0 siblings, 0 replies; 21+ messages in thread
From: Matt Turner @ 2018-05-02 21:10 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Ivan Kokshaysky, Yinghai Lu, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Bjorn Helgaas

On Wed, May 2, 2018 at 1:33 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Mon, Apr 23, 2018 at 06:34:23PM +0100, Ivan Kokshaysky wrote:
>> On Sun, Apr 22, 2018 at 01:07:38PM -0700, Matt Turner wrote:
>> > On Wed, Apr 18, 2018 at 1:48 PM, Ivan Kokshaysky
>> > <ink@jurassic.park.msu.ru> wrote:
>> > > On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
>> > >> On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
>> > >> > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> > >> > > Hi Matt,
>> > >> > >
>> > >> > > First of all, sorry about breaking Nautilus, and thanks very much for
>> > >> > > tracking it down to this commit.
>> > >> >
>> > >> > It's a particularly weird case, as far as I've been able to discern :)
>> > >> >
>> > >> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
>> > >> > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
>> > >> > >> address limits in resource allocation) broke Alpha systems using
>> > >> > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
>> > >> > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
>> > >> > >> into the upper addresses just below 4GB.
>> > >> > >>
>> > >> > >> I can get a working kernel by ifdef'ing out the code in
>> > >> > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
>> > >> > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
>> > >> > >> kernels.
>> > >> > >>
>> > >> > >> How can we get Nautilus working again?
>> > >> > >
>> > >> > > Can you collect a complete dmesg log, ideally both before and after
>> > >> > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
>> > >> > > erroneously assign space for something above 4GB.  But if we know the
>> > >> > > correct host bridge apertures, we shouldn't assign space outside them,
>> > >> > > regardless of the PCI bus address size.
>> > >> >
>> > >> > I made a mistake in my initial report. Commit f75b99d5a77d is actually
>> > >> > the last *working* commit. My apologies. The next commit is
>> > >> > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
>> > >> > breaks Nautilus I've confirmed.
>> > >> >
>> > >> > Please find attached dmesgs from those two commits, from the commit
>> > >> > immediately before them, and another from 4.17-rc1 with my hack of #if
>> > >> > 0'ing out the pci_bus_alloc_from_region(..., &pci_high) code.
>> > >> >
>> > >> > Thanks for having a look!
>> > >>
>> > >> We're telling the PCI core that the host bridge MMIO aperture is the
>> > >> entire 64-bit address space, so when we assign BARs, some of them end
>> > >> up above 4GB:
>> > >>
>> > >>   pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
>> > >>   pci 0000:00:09.0: BAR 0: assigned [mem 0x100000000-0x10000ffff 64bit]
>> > >>
>> > >> But it sounds like the MMIO aperture really ends at 0xffffffff, so
>> > >> that's not going to work.
>> > >
>> > > Correct... This would do as a quick fix, I think:
>> > >
>> > > diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
>> > > index ff4f54b..477ba65 100644
>> > > --- a/arch/alpha/kernel/sys_nautilus.c
>> > > +++ b/arch/alpha/kernel/sys_nautilus.c
>> > > @@ -193,6 +193,8 @@ static struct resource irongate_io = {
>> > >  };
>> > >  static struct resource irongate_mem = {
>> > >         .name   = "Irongate PCI MEM",
>> > > +       .start  = 0,
>> > > +       .end    = 0xffffffff,
>> > >         .flags  = IORESOURCE_MEM,
>> > >  };
>> > >  static struct resource busn_resource = {
>> > > @@ -218,7 +220,7 @@ nautilus_init_pci(void)
>> > >                 return;
>> > >
>> > >         pci_add_resource(&bridge->windows, &ioport_resource);
>> > > -       pci_add_resource(&bridge->windows, &iomem_resource);
>> > > +       pci_add_resource(&bridge->windows, &irongate_mem);
>> > >         pci_add_resource(&bridge->windows, &busn_resource);
>> > >         bridge->dev.parent = NULL;
>> > >         bridge->sysdata = hose;
>> >
>> > Thanks. But with that I get
>> >
>> > PCI host bridge to bus 0000:00
>> > pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>> > pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffff]
>> > pci_bus 0000:00: root bus resource [bus 00-ff]
>> > pci 0000:00:10.0: [Firmware Bug]: reg 0x10: invalid BAR (can't size)
>> > pci 0000:00:10.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
>> > pci 0000:00:10.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
>> > pci 0000:00:10.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
>> > pci 0000:00:10.0: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
>> > pci 0000:00:10.0: legacy IDE quirk: reg 0x14: [io  0x03f6]
>> > pci 0000:00:10.0: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
>> > pci 0000:00:10.0: legacy IDE quirk: reg 0x1c: [io  0x0376]
>> > pci 0000:00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
>> > pci 0000:00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
>> > pci 0000:00:01.0: BAR 9: assigned [mem 0xc0000000-0xc2ffffff pref]
>> > pci 0000:00:01.0: BAR 8: assigned [mem 0xc3000000-0xc3bfffff]
>> > pci 0000:00:0b.0: BAR 6: assigned [mem 0xc3c00000-0xc3c3ffff pref]
>> > pci 0000:00:08.0: BAR 6: assigned [mem 0xc3c40000-0xc3c5ffff pref]
>> > pci 0000:00:09.0: BAR 0: assigned [mem 0xc3c60000-0xc3c6ffff 64bit]
>> > pci 0000:00:03.0: BAR 0: assigned [mem 0xc3c70000-0xc3c70fff]
>> > pci 0000:00:06.0: BAR 1: assigned [mem 0xc3c71000-0xc3c71fff]
>> > pci 0000:00:08.0: BAR 1: assigned [mem 0xc3c72000-0xc3c72fff 64bit]
>> > pci 0000:00:14.0: BAR 0: assigned [mem 0xc3c73000-0xc3c73fff]
>> > pci 0000:00:0b.0: BAR 1: assigned [mem 0xc3c74000-0xc3c743ff]
>> > pci 0000:00:03.0: BAR 1: assigned [io  0x8000-0x80ff]
>> > pci 0000:00:06.0: BAR 0: assigned [io  0x8400-0x84ff]
>> > pci 0000:00:08.0: BAR 0: assigned [io  0x8800-0x88ff]
>> > pci 0000:00:0b.0: BAR 0: assigned [io  0x8c00-0x8c7f]
>> > pci 0000:00:10.0: BAR 4: assigned [io  0x8c80-0x8c8f]
>> > pci 0000:01:05.0: BAR 0: assigned [mem 0xc0000000-0xc1ffffff pref]
>> > pci 0000:01:05.0: BAR 2: assigned [mem 0xc3000000-0xc37fffff]
>> > pci 0000:01:05.0: BAR 6: assigned [mem 0xc2000000-0xc200ffff pref]
>> > pci 0000:01:05.0: BAR 1: assigned [mem 0xc3800000-0xc3803fff]
>> > pci 0000:00:01.0: PCI bridge to [bus 01]
>> > pci 0000:00:01.0:   bridge window [mem 0xc3000000-0xc3bfffff]
>> > pci 0000:00:01.0:   bridge window [mem 0xc0000000-0xc2ffffff pref]
>> >
>> > Looks like the bridge window is overlapping with some previously assigned BARs?
>>
>> No, there are no overlaps. This is AGP bridge window with AGP card BARs
>> inside it.
>>
>> > The result is the SCSI card failing to work:
>> >
>> > scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
>> >         <Adaptec 29160 Ultra160 SCSI adapter>
>> >         aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
>> >
>> > scsi0: ahc_intr - referenced scb not valid during SELTO scb(0, 255)
>> > >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
>> > scsi0: Dumping Card State while idle, at SEQADDR 0x18
>> > [snip endless spew]
>>
>> It looks like Irongate PCI memory window setting is completely wrong,
>> perhaps it starts at zero, so that PCI DMA doesn't work at all.
>>
>> Please try the patch below. It tries to fix things properly, but if
>> PCI bus sizing fails for some reason, it falls back to a "safe" PCI
>> memory window placement at 3GB.
>
> Ping, Matt, any feedback on this patch?

Sorry I haven't had a chance to test it and respond. I'll get to it by
this weekend at the latest.

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2018-04-23 17:34           ` Ivan Kokshaysky
  2018-05-02 20:33             ` Bjorn Helgaas
@ 2018-05-07  0:46             ` Matt Turner
  2019-10-18  5:57             ` Matt Turner
  2 siblings, 0 replies; 21+ messages in thread
From: Matt Turner @ 2018-05-07  0:46 UTC (permalink / raw)
  To: Ivan Kokshaysky
  Cc: Bjorn Helgaas, Yinghai Lu, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Bjorn Helgaas

On Mon, Apr 23, 2018 at 10:34 AM, Ivan Kokshaysky
<ink@jurassic.park.msu.ru> wrote:
> On Sun, Apr 22, 2018 at 01:07:38PM -0700, Matt Turner wrote:
>> On Wed, Apr 18, 2018 at 1:48 PM, Ivan Kokshaysky
>> <ink@jurassic.park.msu.ru> wrote:
>> > On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
>> >> On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
>> >> > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> >> > > Hi Matt,
>> >> > >
>> >> > > First of all, sorry about breaking Nautilus, and thanks very much for
>> >> > > tracking it down to this commit.
>> >> >
>> >> > It's a particularly weird case, as far as I've been able to discern :)
>> >> >
>> >> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
>> >> > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
>> >> > >> address limits in resource allocation) broke Alpha systems using
>> >> > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
>> >> > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
>> >> > >> into the upper addresses just below 4GB.
>> >> > >>
>> >> > >> I can get a working kernel by ifdef'ing out the code in
>> >> > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
>> >> > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
>> >> > >> kernels.
>> >> > >>
>> >> > >> How can we get Nautilus working again?
>> >> > >
>> >> > > Can you collect a complete dmesg log, ideally both before and after
>> >> > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
>> >> > > erroneously assign space for something above 4GB.  But if we know the
>> >> > > correct host bridge apertures, we shouldn't assign space outside them,
>> >> > > regardless of the PCI bus address size.
>> >> >
>> >> > I made a mistake in my initial report. Commit f75b99d5a77d is actually
>> >> > the last *working* commit. My apologies. The next commit is
>> >> > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
>> >> > breaks Nautilus I've confirmed.
>> >> >
>> >> > Please find attached dmesgs from those two commits, from the commit
>> >> > immediately before them, and another from 4.17-rc1 with my hack of #if
>> >> > 0'ing out the pci_bus_alloc_from_region(..., &pci_high) code.
>> >> >
>> >> > Thanks for having a look!
>> >>
>> >> We're telling the PCI core that the host bridge MMIO aperture is the
>> >> entire 64-bit address space, so when we assign BARs, some of them end
>> >> up above 4GB:
>> >>
>> >>   pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
>> >>   pci 0000:00:09.0: BAR 0: assigned [mem 0x100000000-0x10000ffff 64bit]
>> >>
>> >> But it sounds like the MMIO aperture really ends at 0xffffffff, so
>> >> that's not going to work.
>> >
>> > Correct... This would do as a quick fix, I think:
>> >
>> > diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
>> > index ff4f54b..477ba65 100644
>> > --- a/arch/alpha/kernel/sys_nautilus.c
>> > +++ b/arch/alpha/kernel/sys_nautilus.c
>> > @@ -193,6 +193,8 @@ static struct resource irongate_io = {
>> >  };
>> >  static struct resource irongate_mem = {
>> >         .name   = "Irongate PCI MEM",
>> > +       .start  = 0,
>> > +       .end    = 0xffffffff,
>> >         .flags  = IORESOURCE_MEM,
>> >  };
>> >  static struct resource busn_resource = {
>> > @@ -218,7 +220,7 @@ nautilus_init_pci(void)
>> >                 return;
>> >
>> >         pci_add_resource(&bridge->windows, &ioport_resource);
>> > -       pci_add_resource(&bridge->windows, &iomem_resource);
>> > +       pci_add_resource(&bridge->windows, &irongate_mem);
>> >         pci_add_resource(&bridge->windows, &busn_resource);
>> >         bridge->dev.parent = NULL;
>> >         bridge->sysdata = hose;
>>
>> Thanks. But with that I get
>>
>> PCI host bridge to bus 0000:00
>> pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>> pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffff]
>> pci_bus 0000:00: root bus resource [bus 00-ff]
>> pci 0000:00:10.0: [Firmware Bug]: reg 0x10: invalid BAR (can't size)
>> pci 0000:00:10.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
>> pci 0000:00:10.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
>> pci 0000:00:10.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
>> pci 0000:00:10.0: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
>> pci 0000:00:10.0: legacy IDE quirk: reg 0x14: [io  0x03f6]
>> pci 0000:00:10.0: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
>> pci 0000:00:10.0: legacy IDE quirk: reg 0x1c: [io  0x0376]
>> pci 0000:00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
>> pci 0000:00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
>> pci 0000:00:01.0: BAR 9: assigned [mem 0xc0000000-0xc2ffffff pref]
>> pci 0000:00:01.0: BAR 8: assigned [mem 0xc3000000-0xc3bfffff]
>> pci 0000:00:0b.0: BAR 6: assigned [mem 0xc3c00000-0xc3c3ffff pref]
>> pci 0000:00:08.0: BAR 6: assigned [mem 0xc3c40000-0xc3c5ffff pref]
>> pci 0000:00:09.0: BAR 0: assigned [mem 0xc3c60000-0xc3c6ffff 64bit]
>> pci 0000:00:03.0: BAR 0: assigned [mem 0xc3c70000-0xc3c70fff]
>> pci 0000:00:06.0: BAR 1: assigned [mem 0xc3c71000-0xc3c71fff]
>> pci 0000:00:08.0: BAR 1: assigned [mem 0xc3c72000-0xc3c72fff 64bit]
>> pci 0000:00:14.0: BAR 0: assigned [mem 0xc3c73000-0xc3c73fff]
>> pci 0000:00:0b.0: BAR 1: assigned [mem 0xc3c74000-0xc3c743ff]
>> pci 0000:00:03.0: BAR 1: assigned [io  0x8000-0x80ff]
>> pci 0000:00:06.0: BAR 0: assigned [io  0x8400-0x84ff]
>> pci 0000:00:08.0: BAR 0: assigned [io  0x8800-0x88ff]
>> pci 0000:00:0b.0: BAR 0: assigned [io  0x8c00-0x8c7f]
>> pci 0000:00:10.0: BAR 4: assigned [io  0x8c80-0x8c8f]
>> pci 0000:01:05.0: BAR 0: assigned [mem 0xc0000000-0xc1ffffff pref]
>> pci 0000:01:05.0: BAR 2: assigned [mem 0xc3000000-0xc37fffff]
>> pci 0000:01:05.0: BAR 6: assigned [mem 0xc2000000-0xc200ffff pref]
>> pci 0000:01:05.0: BAR 1: assigned [mem 0xc3800000-0xc3803fff]
>> pci 0000:00:01.0: PCI bridge to [bus 01]
>> pci 0000:00:01.0:   bridge window [mem 0xc3000000-0xc3bfffff]
>> pci 0000:00:01.0:   bridge window [mem 0xc0000000-0xc2ffffff pref]
>>
>> Looks like the bridge window is overlapping with some previously assigned BARs?
>
> No, there are no overlaps. This is AGP bridge window with AGP card BARs
> inside it.
>
>> The result is the SCSI card failing to work:
>>
>> scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
>>         <Adaptec 29160 Ultra160 SCSI adapter>
>>         aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
>>
>> scsi0: ahc_intr - referenced scb not valid during SELTO scb(0, 255)
>> >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
>> scsi0: Dumping Card State while idle, at SEQADDR 0x18
>> [snip endless spew]
>
> It looks like Irongate PCI memory window setting is completely wrong,
> perhaps it starts at zero, so that PCI DMA doesn't work at all.
>
> Please try the patch below. It tries to fix things properly, but if
> PCI bus sizing fails for some reason, it falls back to a "safe" PCI
> memory window placement at 3GB.
>
> Ivan.
>
> diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
> index ff4f54b..b1fb9fd 100644
> --- a/arch/alpha/kernel/sys_nautilus.c
> +++ b/arch/alpha/kernel/sys_nautilus.c
> @@ -187,10 +187,6 @@ nautilus_machine_check(unsigned long vector, unsigned long la_ptr)
>
>  extern void pcibios_claim_one_bus(struct pci_bus *);
>
> -static struct resource irongate_io = {
> -       .name   = "Irongate PCI IO",
> -       .flags  = IORESOURCE_IO,
> -};
>  static struct resource irongate_mem = {
>         .name   = "Irongate PCI MEM",
>         .flags  = IORESOURCE_MEM,
> @@ -218,7 +214,7 @@ nautilus_init_pci(void)
>                 return;
>
>         pci_add_resource(&bridge->windows, &ioport_resource);
> -       pci_add_resource(&bridge->windows, &iomem_resource);
> +       pci_add_resource(&bridge->windows, &irongate_mem);
>         pci_add_resource(&bridge->windows, &busn_resource);
>         bridge->dev.parent = NULL;
>         bridge->sysdata = hose;
> @@ -238,20 +234,25 @@ nautilus_init_pci(void)
>         pcibios_claim_one_bus(bus);
>
>         irongate = pci_get_domain_bus_and_slot(pci_domain_nr(bus), 0, 0);
> +       /* Pretend that it's not a root bus to allow sizing. */
> +       bus->parent = bus;
>         bus->self = irongate;
> -       bus->resource[0] = &irongate_io;
> -       bus->resource[1] = &irongate_mem;
>
>         pci_bus_size_bridges(bus);
> -
> -       /* IO port range. */
> -       bus->resource[0]->start = 0;
> -       bus->resource[0]->end = 0xffff;
> +       bus->parent = NULL;
>
>         /* Set up PCI memory range - limit is hardwired to 0xffffffff,
>            base must be at aligned to 16Mb. */
> -       bus_align = bus->resource[1]->start;
> -       bus_size = bus->resource[1]->end + 1 - bus_align;
> +       if (bus->resource[1]->end) {
> +               bus_align = bus->resource[1]->start;
> +               bus_size = bus->resource[1]->end + 1 - bus_align;
> +               printk(KERN_INFO "PCI MEM size 0x%08lx, align 0x%08lx\n",
> +                       bus_size, bus_align);
> +       } else {
> +               bus_size = 0x100000000UL - memtop;
> +               bus_align = bus_size;
> +               printk(KERN_ERR "PCI MEM sizing failed, using 3GB limit\n");
> +       }
>         if (bus_align < 0x1000000UL)
>                 bus_align = 0x1000000UL;
>

Dang. That doesn't work either. My serial console isn't working at the
moment, so I cannot capture the log.

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2018-04-23 17:34           ` Ivan Kokshaysky
  2018-05-02 20:33             ` Bjorn Helgaas
  2018-05-07  0:46             ` Matt Turner
@ 2019-10-18  5:57             ` Matt Turner
  2 siblings, 0 replies; 21+ messages in thread
From: Matt Turner @ 2019-10-18  5:57 UTC (permalink / raw)
  To: Ivan Kokshaysky
  Cc: Bjorn Helgaas, Yinghai Lu, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Bjorn Helgaas

On Mon, Apr 23, 2018 at 10:34 AM Ivan Kokshaysky
<ink@jurassic.park.msu.ru> wrote:
>
> On Sun, Apr 22, 2018 at 01:07:38PM -0700, Matt Turner wrote:
> > On Wed, Apr 18, 2018 at 1:48 PM, Ivan Kokshaysky
> > <ink@jurassic.park.msu.ru> wrote:
> > > On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
> > >> On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
> > >> > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > >> > > Hi Matt,
> > >> > >
> > >> > > First of all, sorry about breaking Nautilus, and thanks very much for
> > >> > > tracking it down to this commit.
> > >> >
> > >> > It's a particularly weird case, as far as I've been able to discern :)
> > >> >
> > >> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> > >> > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> > >> > >> address limits in resource allocation) broke Alpha systems using
> > >> > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> > >> > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
> > >> > >> into the upper addresses just below 4GB.
> > >> > >>
> > >> > >> I can get a working kernel by ifdef'ing out the code in
> > >> > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> > >> > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> > >> > >> kernels.
> > >> > >>
> > >> > >> How can we get Nautilus working again?
> > >> > >
> > >> > > Can you collect a complete dmesg log, ideally both before and after
> > >> > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
> > >> > > erroneously assign space for something above 4GB.  But if we know the
> > >> > > correct host bridge apertures, we shouldn't assign space outside them,
> > >> > > regardless of the PCI bus address size.
> > >> >
> > >> > I made a mistake in my initial report. Commit f75b99d5a77d is actually
> > >> > the last *working* commit. My apologies. The next commit is
> > >> > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
> > >> > breaks Nautilus I've confirmed.
> > >> >
> > >> > Please find attached dmesgs from those two commits, from the commit
> > >> > immediately before them, and another from 4.17-rc1 with my hack of #if
> > >> > 0'ing out the pci_bus_alloc_from_region(..., &pci_high) code.
> > >> >
> > >> > Thanks for having a look!
> > >>
> > >> We're telling the PCI core that the host bridge MMIO aperture is the
> > >> entire 64-bit address space, so when we assign BARs, some of them end
> > >> up above 4GB:
> > >>
> > >>   pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffffffffffff]
> > >>   pci 0000:00:09.0: BAR 0: assigned [mem 0x100000000-0x10000ffff 64bit]
> > >>
> > >> But it sounds like the MMIO aperture really ends at 0xffffffff, so
> > >> that's not going to work.
> > >
> > > Correct... This would do as a quick fix, I think:
> > >
> > > diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
> > > index ff4f54b..477ba65 100644
> > > --- a/arch/alpha/kernel/sys_nautilus.c
> > > +++ b/arch/alpha/kernel/sys_nautilus.c
> > > @@ -193,6 +193,8 @@ static struct resource irongate_io = {
> > >  };
> > >  static struct resource irongate_mem = {
> > >         .name   = "Irongate PCI MEM",
> > > +       .start  = 0,
> > > +       .end    = 0xffffffff,
> > >         .flags  = IORESOURCE_MEM,
> > >  };
> > >  static struct resource busn_resource = {
> > > @@ -218,7 +220,7 @@ nautilus_init_pci(void)
> > >                 return;
> > >
> > >         pci_add_resource(&bridge->windows, &ioport_resource);
> > > -       pci_add_resource(&bridge->windows, &iomem_resource);
> > > +       pci_add_resource(&bridge->windows, &irongate_mem);
> > >         pci_add_resource(&bridge->windows, &busn_resource);
> > >         bridge->dev.parent = NULL;
> > >         bridge->sysdata = hose;
> >
> > Thanks. But with that I get
> >
> > PCI host bridge to bus 0000:00
> > pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > pci_bus 0000:00: root bus resource [mem 0x00000000-0xffffffff]
> > pci_bus 0000:00: root bus resource [bus 00-ff]
> > pci 0000:00:10.0: [Firmware Bug]: reg 0x10: invalid BAR (can't size)
> > pci 0000:00:10.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
> > pci 0000:00:10.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
> > pci 0000:00:10.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
> > pci 0000:00:10.0: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
> > pci 0000:00:10.0: legacy IDE quirk: reg 0x14: [io  0x03f6]
> > pci 0000:00:10.0: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
> > pci 0000:00:10.0: legacy IDE quirk: reg 0x1c: [io  0x0376]
> > pci 0000:00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
> > pci 0000:00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
> > pci 0000:00:01.0: BAR 9: assigned [mem 0xc0000000-0xc2ffffff pref]
> > pci 0000:00:01.0: BAR 8: assigned [mem 0xc3000000-0xc3bfffff]
> > pci 0000:00:0b.0: BAR 6: assigned [mem 0xc3c00000-0xc3c3ffff pref]
> > pci 0000:00:08.0: BAR 6: assigned [mem 0xc3c40000-0xc3c5ffff pref]
> > pci 0000:00:09.0: BAR 0: assigned [mem 0xc3c60000-0xc3c6ffff 64bit]
> > pci 0000:00:03.0: BAR 0: assigned [mem 0xc3c70000-0xc3c70fff]
> > pci 0000:00:06.0: BAR 1: assigned [mem 0xc3c71000-0xc3c71fff]
> > pci 0000:00:08.0: BAR 1: assigned [mem 0xc3c72000-0xc3c72fff 64bit]
> > pci 0000:00:14.0: BAR 0: assigned [mem 0xc3c73000-0xc3c73fff]
> > pci 0000:00:0b.0: BAR 1: assigned [mem 0xc3c74000-0xc3c743ff]
> > pci 0000:00:03.0: BAR 1: assigned [io  0x8000-0x80ff]
> > pci 0000:00:06.0: BAR 0: assigned [io  0x8400-0x84ff]
> > pci 0000:00:08.0: BAR 0: assigned [io  0x8800-0x88ff]
> > pci 0000:00:0b.0: BAR 0: assigned [io  0x8c00-0x8c7f]
> > pci 0000:00:10.0: BAR 4: assigned [io  0x8c80-0x8c8f]
> > pci 0000:01:05.0: BAR 0: assigned [mem 0xc0000000-0xc1ffffff pref]
> > pci 0000:01:05.0: BAR 2: assigned [mem 0xc3000000-0xc37fffff]
> > pci 0000:01:05.0: BAR 6: assigned [mem 0xc2000000-0xc200ffff pref]
> > pci 0000:01:05.0: BAR 1: assigned [mem 0xc3800000-0xc3803fff]
> > pci 0000:00:01.0: PCI bridge to [bus 01]
> > pci 0000:00:01.0:   bridge window [mem 0xc3000000-0xc3bfffff]
> > pci 0000:00:01.0:   bridge window [mem 0xc0000000-0xc2ffffff pref]
> >
> > Looks like the bridge window is overlapping with some previously assigned BARs?
>
> No, there are no overlaps. This is AGP bridge window with AGP card BARs
> inside it.
>
> > The result is the SCSI card failing to work:
> >
> > scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
> >         <Adaptec 29160 Ultra160 SCSI adapter>
> >         aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
> >
> > scsi0: ahc_intr - referenced scb not valid during SELTO scb(0, 255)
> > >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
> > scsi0: Dumping Card State while idle, at SEQADDR 0x18
> > [snip endless spew]
>
> It looks like Irongate PCI memory window setting is completely wrong,
> perhaps it starts at zero, so that PCI DMA doesn't work at all.
>
> Please try the patch below. It tries to fix things properly, but if
> PCI bus sizing fails for some reason, it falls back to a "safe" PCI
> memory window placement at 3GB.
>
> Ivan.
>
> diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
> index ff4f54b..b1fb9fd 100644
> --- a/arch/alpha/kernel/sys_nautilus.c
> +++ b/arch/alpha/kernel/sys_nautilus.c
> @@ -187,10 +187,6 @@ nautilus_machine_check(unsigned long vector, unsigned long la_ptr)
>
>  extern void pcibios_claim_one_bus(struct pci_bus *);
>
> -static struct resource irongate_io = {
> -       .name   = "Irongate PCI IO",
> -       .flags  = IORESOURCE_IO,
> -};
>  static struct resource irongate_mem = {
>         .name   = "Irongate PCI MEM",
>         .flags  = IORESOURCE_MEM,
> @@ -218,7 +214,7 @@ nautilus_init_pci(void)
>                 return;
>
>         pci_add_resource(&bridge->windows, &ioport_resource);
> -       pci_add_resource(&bridge->windows, &iomem_resource);
> +       pci_add_resource(&bridge->windows, &irongate_mem);
>         pci_add_resource(&bridge->windows, &busn_resource);
>         bridge->dev.parent = NULL;
>         bridge->sysdata = hose;
> @@ -238,20 +234,25 @@ nautilus_init_pci(void)
>         pcibios_claim_one_bus(bus);
>
>         irongate = pci_get_domain_bus_and_slot(pci_domain_nr(bus), 0, 0);
> +       /* Pretend that it's not a root bus to allow sizing. */
> +       bus->parent = bus;
>         bus->self = irongate;
> -       bus->resource[0] = &irongate_io;
> -       bus->resource[1] = &irongate_mem;
>
>         pci_bus_size_bridges(bus);
> -
> -       /* IO port range. */
> -       bus->resource[0]->start = 0;
> -       bus->resource[0]->end = 0xffff;
> +       bus->parent = NULL;
>
>         /* Set up PCI memory range - limit is hardwired to 0xffffffff,
>            base must be at aligned to 16Mb. */
> -       bus_align = bus->resource[1]->start;
> -       bus_size = bus->resource[1]->end + 1 - bus_align;
> +       if (bus->resource[1]->end) {

Log inline below, but we get a segfault here, presumably because
bus->resource[1] is NULL.

In case it was supposed to be resource[0], I tried that as well (and
throughout) with the same result.

> +               bus_align = bus->resource[1]->start;
> +               bus_size = bus->resource[1]->end + 1 - bus_align;
> +               printk(KERN_INFO "PCI MEM size 0x%08lx, align 0x%08lx\n",
> +                       bus_size, bus_align);
> +       } else {
> +               bus_size = 0x100000000UL - memtop;
> +               bus_align = bus_size;
> +               printk(KERN_ERR "PCI MEM sizing failed, using 3GB limit\n");
> +       }
>         if (bus_align < 0x1000000UL)
>                 bus_align = 0x1000000UL;

[    0.045898] PCI host bridge to bus 0000:00
[    0.046874] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.047851] pci_bus 0000:00: root bus resource [mem 0x00000000]
[    0.048828] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.049804] pci 0000:00:00.0: [1022:700e] type 00 class 0x060000
[    0.050781] pci 0000:00:00.0: reg 0x14: [mem 0x40000000-0x40000fff pref]
[    0.051757] pci 0000:00:00.0: reg 0x18: [io  0x101f0-0x101f3]
[    0.052734] pci 0000:00:01.0: [1022:700f] type 01 class 0x060400
[    0.053710] pci 0000:00:03.0: [10b9:5457] type 00 class 0x070300
[    0.054687] pci 0000:00:03.0: reg 0x10: [mem 0x80128000-0x80128fff]
[    0.055664] pci 0000:00:03.0: reg 0x14: [io  0x1000-0x10ff]
[    0.056640] pci 0000:00:03.0: PME# supported from D3hot D3cold
[    0.057617] pci 0000:00:06.0: [10b9:5451] type 00 class 0x040100
[    0.058593] pci 0000:00:06.0: reg 0x10: [io  0x10000-0x100ff]
[    0.059570] pci 0000:00:06.0: reg 0x14: [mem 0x80129000-0x80129fff]
[    0.060546] pci 0000:00:06.0: supports D1 D2
[    0.061523] pci 0000:00:06.0: PME# supported from D2 D3hot D3cold
[    0.062499] pci 0000:00:07.0: [10b9:1533] type 00 class 0x060100
[    0.064453] pci 0000:00:09.0: [8086:107c] type 00 class 0x020000
[    0.065429] pci 0000:00:09.0: reg 0x10: [mem 0x800c0000-0x800dffff]
[    0.066406] pci 0000:00:09.0: reg 0x14: [mem 0x800e0000-0x800fffff]
[    0.067382] pci 0000:00:09.0: reg 0x18: [io  0x10180-0x101bf]
[    0.068359] pci 0000:00:09.0: reg 0x30: [mem 0x80100000-0x8011ffff pref]
[    0.069335] pci 0000:00:09.0: PME# supported from D0 D3hot D3cold
[    0.070312] pci 0000:00:0a.0: [1095:3124] type 00 class 0x010400
[    0.071289] pci 0000:00:0a.0: reg 0x10: [mem 0x8012b400-0x8012b47f 64bit]
[    0.072265] pci 0000:00:0a.0: reg 0x18: [mem 0x80120000-0x80127fff 64bit]
[    0.073242] pci 0000:00:0a.0: reg 0x20: [io  0x101c0-0x101cf]
[    0.074218] pci 0000:00:0a.0: reg 0x30: [mem 0x80000000-0x8007ffff pref]
[    0.075195] pci 0000:00:0a.0: supports D1 D2
[    0.076171] pci 0000:00:0b.0: [1011:0019] type 00 class 0x020000
[    0.077148] pci 0000:00:0b.0: reg 0x10: [io  0x10100-0x1017f]
[    0.078124] pci 0000:00:0b.0: reg 0x14: [mem 0x8012b000-0x8012b3ff]
[    0.079101] pci 0000:00:0b.0: reg 0x30: [mem 0x80080000-0x800bffff pref]
[    0.080078] pci 0000:00:10.0: [10b9:5229] type 00 class 0x0101fa
[    0.081054] pci 0000:00:10.0: [Firmware Bug]: reg 0x10: invalid BAR
(can't size)
[    0.082031] pci 0000:00:10.0: [Firmware Bug]: reg 0x14: invalid BAR
(can't size)
[    0.083007] pci 0000:00:10.0: [Firmware Bug]: reg 0x18: invalid BAR
(can't size)
[    0.083984] pci 0000:00:10.0: [Firmware Bug]: reg 0x1c: invalid BAR
(can't size)
[    0.084960] pci 0000:00:10.0: reg 0x20: [io  0x101e0-0x101ef]
[    0.085937] pci 0000:00:10.0: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
[    0.086914] pci 0000:00:10.0: legacy IDE quirk: reg 0x14: [io  0x03f6]
[    0.087890] pci 0000:00:10.0: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
[    0.088867] pci 0000:00:10.0: legacy IDE quirk: reg 0x1c: [io  0x0376]
[    0.089843] pci 0000:00:11.0: [10b9:7101] type 00 class 0x000000
[    0.090820] pci 0000:00:11.0: quirk: [io  0x4000-0x403f] claimed by
ali7101 ACPI
[    0.091796] pci 0000:00:11.0: quirk: [io  0x5000-0x501f] claimed by
ali7101 SMB
[    0.092773] pci 0000:00:14.0: [10b9:5237] type 00 class 0x0c0310
[    0.093749] pci 0000:00:14.0: reg 0x10: [mem 0x8012a000-0x8012afff]
[    0.094726] pci_bus 0000:01: extended config space not accessible
[    0.095703] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[    0.099609] Unable to handle kernel paging request at virtual
address 0000000000000008
[    0.100585] swapper(1): Oops 0
[    0.101562] pc = [<fffffc0000c085e0>]  ra = [<fffffc0000c085d4>]
ps = 0000    Not tainted
[    0.102539] pc is at nautilus_init_pci+0x1e0/0x3d4
[    0.103515] ra is at nautilus_init_pci+0x1d4/0x3d4
[    0.104492] v0 = 0000000000000001  t0 = 0000000000000000  t1 =
fffffc0000c40db8
[    0.105468] t2 = fffffc0000c40de0  t3 = 0000000000000062  t4 =
0000000000000001
[    0.106445] t5 = 0000000000000400  t6 = 0000000000000035  t7 =
fffffc00bf884000
[    0.107421] s0 = fffffc00bf86e400  s1 = fffffc00bf86e1b8  s2 =
00000000ffff4000
[    0.108398] s3 = fffffc0000c69638  s4 = fffffc0000d1c000  s5 =
fffffc0000c69638
[    0.109374] s6 = fffffc0000ca5cd8
[    0.110351] a0 = 0000000000000000  a1 = fffffd01fc0003f9  a2 =
0000000000000000
[    0.111328] a3 = fffffc000070c140  a4 = 0000000000000010  a5 =
0000000000000000
[    0.112304] t8 = fffffc0000ca5cd8  t9 = fffffc0000ca5cd8  t10=
0000000000000000
[    0.113281] t11= 0000000000000062  pv = fffffc0000363290  at =
0000000000000007
[    0.114257] gp = fffffc0000c95cd8  sp = (____ptrval____)
[    0.115234] Disabling lock debugging due to kernel taint
[    0.116210] Trace:
[    0.117187] [<fffffc00003101c8>] do_one_initcall+0x98/0x250
[    0.118164] [<fffffc0000a2ffc4>] kernel_init+0x20/0x17c
[    0.119140] [<fffffc0000a2ffa4>] kernel_init+0x0/0x17c
[    0.120117] [<fffffc00003117a8>] ret_from_kernel_thread+0x18/0x20
[    0.121093] [<fffffc0000a2ffa4>] kernel_init+0x0/0x17c
[    0.122070]
[    0.123046] Code:
[    0.123046]  261dffe5
[    0.124023]  2210acfc
[    0.124999]  6b5b6edf
[    0.125976]  27ba0009
[    0.126953]  a4290050
[    0.127929]  23bdd704
[    0.128906] <a4210008>
[    0.129882]  e420001a
[    0.130859]
[    0.132812] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2018-04-16 14:33 Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation) Matt Turner
  2018-04-16 21:50 ` Bjorn Helgaas
@ 2020-02-22 16:55 ` Bjorn Helgaas
  2020-02-28 23:51   ` Matt Turner
  1 sibling, 1 reply; 21+ messages in thread
From: Bjorn Helgaas @ 2020-02-22 16:55 UTC (permalink / raw)
  To: Matt Turner
  Cc: Yinghai Lu, linux-pci, linux-alpha, Richard Henderson,
	Ivan Kokshaysky, Jay Estabrook

On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> address limits in resource allocation) broke Alpha systems using
> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
> into the upper addresses just below 4GB.
> 
> I can get a working kernel by ifdef'ing out the code in
> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> kernels.
> 
> How can we get Nautilus working again?

I don't see a resolution in this thread, so I assume this is still
broken?  Anybody have any more ideas?

Bjorn

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2020-02-22 16:55 ` Bjorn Helgaas
@ 2020-02-28 23:51   ` Matt Turner
  2020-03-01 14:30     ` Ivan Kokshaysky
  2020-03-02 22:47     ` Bjorn Helgaas
  0 siblings, 2 replies; 21+ messages in thread
From: Matt Turner @ 2020-02-28 23:51 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Yinghai Lu, linux-pci, linux-alpha, Richard Henderson,
	Ivan Kokshaysky, Jay Estabrook

On Sat, Feb 22, 2020 at 8:55 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> > Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> > address limits in resource allocation) broke Alpha systems using
> > CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> > 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
> > into the upper addresses just below 4GB.
> >
> > I can get a working kernel by ifdef'ing out the code in
> > drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> > PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> > kernels.
> >
> > How can we get Nautilus working again?
>
> I don't see a resolution in this thread, so I assume this is still
> broken?  Anybody have any more ideas?

Indeed, still broken.

I can add Kconfig logic to unselect ARCH_DMA_ADDR_T_64BIT if
ALPHA_NAUTILUS, but then generic kernels won't work on Nautilus. It
doesn't look like we have any way of opting out of
ARCH_DMA_ADDR_T_64BIT at runtime, and doing enough plumbing to make
that work is not worth it for such niche hardware. Maybe removing
Nautilus from the generic kernel build is what I should do until such
a time that we really fix this?

Or maybe I could put a hack in pci.c that more or less undoes
d56dbf5bab8c on Nautilus. #if defined CONFIG_ARCH_DMA_ADDR_T_64BIT &&
!defined SYS_NAUTILUS.

Or maybe I just need to take a weekend and try to understand the PCI
code, instead of applying patches I don't understand and praying :)

Thoughts? Other suggestions?

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2020-02-28 23:51   ` Matt Turner
@ 2020-03-01 14:30     ` Ivan Kokshaysky
  2020-03-02 22:47     ` Bjorn Helgaas
  1 sibling, 0 replies; 21+ messages in thread
From: Ivan Kokshaysky @ 2020-03-01 14:30 UTC (permalink / raw)
  To: Matt Turner
  Cc: Bjorn Helgaas, Yinghai Lu, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook

On Fri, Feb 28, 2020 at 03:51:01PM -0800, Matt Turner wrote:
> On Sat, Feb 22, 2020 at 8:55 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> >
> > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> > > Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> > > address limits in resource allocation) broke Alpha systems using
> > > CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> > > 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
> > > into the upper addresses just below 4GB.
> > >
> > > I can get a working kernel by ifdef'ing out the code in
> > > drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> > > PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> > > kernels.
> > >
> > > How can we get Nautilus working again?
> >
> > I don't see a resolution in this thread, so I assume this is still
> > broken?  Anybody have any more ideas?
> 
> Indeed, still broken.
> 
> I can add Kconfig logic to unselect ARCH_DMA_ADDR_T_64BIT if
> ALPHA_NAUTILUS, but then generic kernels won't work on Nautilus. It
> doesn't look like we have any way of opting out of
> ARCH_DMA_ADDR_T_64BIT at runtime, and doing enough plumbing to make
> that work is not worth it for such niche hardware. Maybe removing
> Nautilus from the generic kernel build is what I should do until such
> a time that we really fix this?
> 
> Or maybe I could put a hack in pci.c that more or less undoes
> d56dbf5bab8c on Nautilus. #if defined CONFIG_ARCH_DMA_ADDR_T_64BIT &&
> !defined SYS_NAUTILUS.
> 
> Or maybe I just need to take a weekend and try to understand the PCI
> code, instead of applying patches I don't understand and praying :)
> 
> Thoughts? Other suggestions?

Well, it's difficult to debug without hardware in hand.

Actually, I have one of those machines, but I had to write it off
5-6 years ago as it started crashing like crazy, sometimes in SRM
console even before boot. Interestingly enough, the problem might be
not with the motherboard as I thought, but with the video adapter -
yesterday I tried this UP1500 without AGP card, it booted fine and
worked a couple of hours without any problem, which is pretty
encouraging.

So next week I'm going to return the poor guy to service (put it
into enclosure, replace old fans and so on). Then we will see.

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2020-02-28 23:51   ` Matt Turner
  2020-03-01 14:30     ` Ivan Kokshaysky
@ 2020-03-02 22:47     ` Bjorn Helgaas
  2020-03-08 15:30       ` Ivan Kokshaysky
  1 sibling, 1 reply; 21+ messages in thread
From: Bjorn Helgaas @ 2020-03-02 22:47 UTC (permalink / raw)
  To: Matt Turner
  Cc: Yinghai Lu, linux-pci, linux-alpha, Richard Henderson,
	Ivan Kokshaysky, Jay Estabrook, Nicholas Johnson,
	Benjamin Herrenschmidt

[+cc Nicholas, Ben, beginning of thread:
https://lore.kernel.org/r/CAEdQ38GUhL0R4c7ZjEZv89TmqQ0cwhnvBawxuXonSb9On=+B6A@mail.gmail.com]

On Fri, Feb 28, 2020 at 03:51:01PM -0800, Matt Turner wrote:
> On Sat, Feb 22, 2020 at 8:55 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> >
> > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> > > Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> > > address limits in resource allocation) broke Alpha systems using
> > > CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> > > 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
> > > into the upper addresses just below 4GB.
> > >
> > > I can get a working kernel by ifdef'ing out the code in
> > > drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> > > PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> > > kernels.
> > >
> > > How can we get Nautilus working again?
> >
> > I don't see a resolution in this thread, so I assume this is still
> > broken?  Anybody have any more ideas?
> 
> Indeed, still broken.
> 
> I can add Kconfig logic to unselect ARCH_DMA_ADDR_T_64BIT if
> ALPHA_NAUTILUS, but then generic kernels won't work on Nautilus. It
> doesn't look like we have any way of opting out of
> ARCH_DMA_ADDR_T_64BIT at runtime, and doing enough plumbing to make
> that work is not worth it for such niche hardware. Maybe removing
> Nautilus from the generic kernel build is what I should do until such
> a time that we really fix this?
> 
> Or maybe I could put a hack in pci.c that more or less undoes
> d56dbf5bab8c on Nautilus. #if defined CONFIG_ARCH_DMA_ADDR_T_64BIT &&
> !defined SYS_NAUTILUS.
> 
> Or maybe I just need to take a weekend and try to understand the PCI
> code, instead of applying patches I don't understand and praying :)

I don't have any *useful* ideas, but I think we did screw up the PCI
resource discovery when we started assuming that we know the host
bridge apertures up front.

That's generally true for many ACPI and DT systems, but in principle,
we *should* be able to enumerate the devices and learn their resource
requirements before computing the required host bridge apertures and
assigning the BARs.

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2020-03-02 22:47     ` Bjorn Helgaas
@ 2020-03-08 15:30       ` Ivan Kokshaysky
  2020-03-08 19:41         ` Matt Turner
  0 siblings, 1 reply; 21+ messages in thread
From: Ivan Kokshaysky @ 2020-03-08 15:30 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Matt Turner, Yinghai Lu, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Nicholas Johnson,
	Benjamin Herrenschmidt

On Mon, Mar 02, 2020 at 04:47:32PM -0600, Bjorn Helgaas wrote:
> [+cc Nicholas, Ben, beginning of thread:
> https://lore.kernel.org/r/CAEdQ38GUhL0R4c7ZjEZv89TmqQ0cwhnvBawxuXonSb9On=+B6A@mail.gmail.com]
> 
> On Fri, Feb 28, 2020 at 03:51:01PM -0800, Matt Turner wrote:
> > On Sat, Feb 22, 2020 at 8:55 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > >
> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
> > > > Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
> > > > address limits in resource allocation) broke Alpha systems using
> > > > CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
> > > > 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
> > > > into the upper addresses just below 4GB.
> > > >
> > > > I can get a working kernel by ifdef'ing out the code in
> > > > drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
> > > > PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
> > > > kernels.
> > > >
> > > > How can we get Nautilus working again?
> > >
> > > I don't see a resolution in this thread, so I assume this is still
> > > broken?  Anybody have any more ideas?
> > 
> > Indeed, still broken.
> > 
> > I can add Kconfig logic to unselect ARCH_DMA_ADDR_T_64BIT if
> > ALPHA_NAUTILUS, but then generic kernels won't work on Nautilus. It
> > doesn't look like we have any way of opting out of
> > ARCH_DMA_ADDR_T_64BIT at runtime, and doing enough plumbing to make
> > that work is not worth it for such niche hardware. Maybe removing
> > Nautilus from the generic kernel build is what I should do until such
> > a time that we really fix this?
> > 
> > Or maybe I could put a hack in pci.c that more or less undoes
> > d56dbf5bab8c on Nautilus. #if defined CONFIG_ARCH_DMA_ADDR_T_64BIT &&
> > !defined SYS_NAUTILUS.
> > 
> > Or maybe I just need to take a weekend and try to understand the PCI
> > code, instead of applying patches I don't understand and praying :)
> 
> I don't have any *useful* ideas, but I think we did screw up the PCI
> resource discovery when we started assuming that we know the host
> bridge apertures up front.
> 
> That's generally true for many ACPI and DT systems, but in principle,
> we *should* be able to enumerate the devices and learn their resource
> requirements before computing the required host bridge apertures and
> assigning the BARs.

Wholeheartedly agree. In fact, changes to generic PCI code required
for proper root bus sizing are quite minimal now since we have
struct pci_host_bridge. It's mostly additional checks for bus->self
being NULL (as it normally is on the root bus) in the
__pci_bus_size_bridges() path, plus new bridge->size_windows flag.
See patch below (tested on UP1500). Note that on irongate we're
only interested in calculation of non-prefetchable PCI memory aperture,
but one can do the same for io and prefetchable memory as well.

Ivan.

diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
index cd9a112d67ff..84eaf7f54982 100644
--- a/arch/alpha/kernel/sys_nautilus.c
+++ b/arch/alpha/kernel/sys_nautilus.c
@@ -187,10 +187,6 @@ nautilus_machine_check(unsigned long vector, unsigned long la_ptr)
 
 extern void pcibios_claim_one_bus(struct pci_bus *);
 
-static struct resource irongate_io = {
-	.name	= "Irongate PCI IO",
-	.flags	= IORESOURCE_IO,
-};
 static struct resource irongate_mem = {
 	.name	= "Irongate PCI MEM",
 	.flags	= IORESOURCE_MEM,
@@ -211,14 +207,13 @@ nautilus_init_pci(void)
 	struct pci_dev *irongate;
 	unsigned long bus_align, bus_size, pci_mem;
 	unsigned long memtop = max_low_pfn << PAGE_SHIFT;
-	int ret;
 
 	bridge = pci_alloc_host_bridge(0);
 	if (!bridge)
 		return;
 
 	pci_add_resource(&bridge->windows, &ioport_resource);
-	pci_add_resource(&bridge->windows, &iomem_resource);
+	pci_add_resource(&bridge->windows, &irongate_mem);
 	pci_add_resource(&bridge->windows, &busn_resource);
 	bridge->dev.parent = NULL;
 	bridge->sysdata = hose;
@@ -226,59 +221,47 @@ nautilus_init_pci(void)
 	bridge->ops = alpha_mv.pci_ops;
 	bridge->swizzle_irq = alpha_mv.pci_swizzle;
 	bridge->map_irq = alpha_mv.pci_map_irq;
+	bridge->size_windows = 1;
 
 	/* Scan our single hose.  */
-	ret = pci_scan_root_bus_bridge(bridge);
-	if (ret) {
+	if (pci_scan_root_bus_bridge(bridge)) {
 		pci_free_host_bridge(bridge);
 		return;
 	}
-
 	bus = hose->bus = bridge->bus;
 	pcibios_claim_one_bus(bus);
 
-	irongate = pci_get_domain_bus_and_slot(pci_domain_nr(bus), 0, 0);
-	bus->self = irongate;
-	bus->resource[0] = &irongate_io;
-	bus->resource[1] = &irongate_mem;
-
 	pci_bus_size_bridges(bus);
 
-	/* IO port range. */
-	bus->resource[0]->start = 0;
-	bus->resource[0]->end = 0xffff;
-
-	/* Set up PCI memory range - limit is hardwired to 0xffffffff,
-	   base must be at aligned to 16Mb. */
-	bus_align = bus->resource[1]->start;
-	bus_size = bus->resource[1]->end + 1 - bus_align;
+	/* Now we have PCI memory resources size and alignment stored
+	   in irongate_mem. Set up PCI memory range - limit is hardwired
+	   to 0xffffffff, base must be aligned to 16Mb. */
+	bus_align = irongate_mem.start;
+	bus_size = irongate_mem.end + 1 - bus_align;
 	if (bus_align < 0x1000000UL)
 		bus_align = 0x1000000UL;
 
 	pci_mem = (0x100000000UL - bus_size) & -bus_align;
 
-	bus->resource[1]->start = pci_mem;
-	bus->resource[1]->end = 0xffffffffUL;
-	if (request_resource(&iomem_resource, bus->resource[1]) < 0)
+	irongate_mem.start = pci_mem;
+	irongate_mem.end = 0xffffffffUL;
+	if (request_resource(&iomem_resource, &irongate_mem) < 0)
 		printk(KERN_ERR "Failed to request MEM on hose 0\n");
 
+	printk(KERN_INFO "Irongate pci_mem %pR\n", &irongate_mem);
+
 	if (pci_mem < memtop)
 		memtop = pci_mem;
 	if (memtop > alpha_mv.min_mem_address) {
 		free_reserved_area(__va(alpha_mv.min_mem_address),
 				   __va(memtop), -1, NULL);
-		printk("nautilus_init_pci: %ldk freed\n",
+		printk(KERN_INFO "nautilus_init_pci: %ldk freed\n",
 			(memtop - alpha_mv.min_mem_address) >> 10);
 	}
-
 	if ((IRONGATE0->dev_vendor >> 16) > 0x7006)	/* Albacore? */
 		IRONGATE0->pci_mem = pci_mem;
 
 	pci_bus_assign_resources(bus);
-
-	/* pci_common_swizzle() relies on bus->self being NULL
-	   for the root bus, so just clear it. */
-	bus->self = NULL;
 	pci_bus_add_devices(bus);
 }
 
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index f2461bf9243d..aecc81338a1f 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -846,7 +846,7 @@ static resource_size_t window_alignment(struct pci_bus *bus, unsigned long type)
 		 * Per spec, I/O windows are 4K-aligned, but some bridges have
 		 * an extension to support 1K alignment.
 		 */
-		if (bus->self->io_window_1k)
+		if (bus->self && bus->self->io_window_1k)
 			align = PCI_P2P_DEFAULT_IO_ALIGN_1K;
 		else
 			align = PCI_P2P_DEFAULT_IO_ALIGN;
@@ -920,7 +920,7 @@ static void pbus_size_io(struct pci_bus *bus, resource_size_t min_size,
 		calculate_iosize(size, min_size, size1, add_size, children_add_size,
 			resource_size(b_res), min_align);
 	if (!size0 && !size1) {
-		if (b_res->start || b_res->end)
+		if (bus->self && (b_res->start || b_res->end))
 			pci_info(bus->self, "disabling bridge window %pR to %pR (unused)\n",
 				 b_res, &bus->busn_res);
 		b_res->flags = 0;
@@ -930,7 +930,7 @@ static void pbus_size_io(struct pci_bus *bus, resource_size_t min_size,
 	b_res->start = min_align;
 	b_res->end = b_res->start + size0 - 1;
 	b_res->flags |= IORESOURCE_STARTALIGN;
-	if (size1 > size0 && realloc_head) {
+	if (bus->self && size1 > size0 && realloc_head) {
 		add_to_list(realloc_head, bus->self, b_res, size1-size0,
 			    min_align);
 		pci_info(bus->self, "bridge window %pR to %pR add_size %llx\n",
@@ -1073,7 +1073,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
 		calculate_memsize(size, min_size, add_size, children_add_size,
 				resource_size(b_res), add_align);
 	if (!size0 && !size1) {
-		if (b_res->start || b_res->end)
+		if (bus->self && (b_res->start || b_res->end))
 			pci_info(bus->self, "disabling bridge window %pR to %pR (unused)\n",
 				 b_res, &bus->busn_res);
 		b_res->flags = 0;
@@ -1082,7 +1082,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
 	b_res->start = min_align;
 	b_res->end = size0 + min_align - 1;
 	b_res->flags |= IORESOURCE_STARTALIGN;
-	if (size1 > size0 && realloc_head) {
+	if (bus->self && size1 > size0 && realloc_head) {
 		add_to_list(realloc_head, bus->self, b_res, size1-size0, add_align);
 		pci_info(bus->self, "bridge window %pR to %pR add_size %llx add_align %llx\n",
 			   b_res, &bus->busn_res,
@@ -1196,8 +1196,9 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct list_head *realloc_head)
 	unsigned long mask, prefmask, type2 = 0, type3 = 0;
 	resource_size_t additional_io_size = 0, additional_mmio_size = 0,
 			additional_mmio_pref_size = 0;
-	struct resource *b_res;
-	int ret;
+	struct resource *pref;
+	struct pci_host_bridge *host;
+	int hdr_type, i, ret;
 
 	list_for_each_entry(dev, &bus->devices, bus_list) {
 		struct pci_bus *b = dev->subordinate;
@@ -1217,10 +1218,20 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct list_head *realloc_head)
 	}
 
 	/* The root bus? */
-	if (pci_is_root_bus(bus))
-		return;
+	if (pci_is_root_bus(bus)) {
+		host = to_pci_host_bridge(bus->bridge);
+		if (!host->size_windows)
+			return;
+		pci_bus_for_each_resource(bus, pref, i)
+			if (pref && (pref->flags & IORESOURCE_PREFETCH))
+				break;
+		hdr_type = -1;
+	} else {
+		pref = &bus->self->resource[PCI_BRIDGE_RESOURCES + 2];
+		hdr_type = bus->self->hdr_type;
+	}
 
-	switch (bus->self->hdr_type) {
+	switch (hdr_type) {
 	case PCI_HEADER_TYPE_CARDBUS:
 		/* Don't size CardBuses yet */
 		break;
@@ -1242,10 +1253,9 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct list_head *realloc_head)
 		 * the size required to put all 64-bit prefetchable
 		 * resources in it.
 		 */
-		b_res = &bus->self->resource[PCI_BRIDGE_RESOURCES];
 		mask = IORESOURCE_MEM;
 		prefmask = IORESOURCE_MEM | IORESOURCE_PREFETCH;
-		if (b_res[2].flags & IORESOURCE_MEM_64) {
+		if (pref && (pref->flags & IORESOURCE_MEM_64)) {
 			prefmask |= IORESOURCE_MEM_64;
 			ret = pbus_size_mem(bus, prefmask, prefmask,
 				prefmask, prefmask,
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 3840a541a9de..681c79b4dc85 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -511,6 +511,7 @@ struct pci_host_bridge {
 	unsigned int	native_pme:1;		/* OS may use PCIe PME */
 	unsigned int	native_ltr:1;		/* OS may use PCIe LTR */
 	unsigned int	preserve_config:1;	/* Preserve FW resource setup */
+	unsigned int	size_windows:1;		/* Enable root bus sizing */
 
 	/* Resource alignment requirements */
 	resource_size_t (*align_resource)(struct pci_dev *dev,

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2020-03-08 15:30       ` Ivan Kokshaysky
@ 2020-03-08 19:41         ` Matt Turner
  2020-03-12  4:28           ` Matt Turner
  0 siblings, 1 reply; 21+ messages in thread
From: Matt Turner @ 2020-03-08 19:41 UTC (permalink / raw)
  To: Ivan Kokshaysky
  Cc: Bjorn Helgaas, Yinghai Lu, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Nicholas Johnson,
	Benjamin Herrenschmidt

On Sun, Mar 8, 2020 at 8:30 AM Ivan Kokshaysky <ink@jurassic.park.msu.ru> wrote:
> Wholeheartedly agree. In fact, changes to generic PCI code required
> for proper root bus sizing are quite minimal now since we have
> struct pci_host_bridge. It's mostly additional checks for bus->self
> being NULL (as it normally is on the root bus) in the
> __pci_bus_size_bridges() path, plus new bridge->size_windows flag.
> See patch below (tested on UP1500). Note that on irongate we're
> only interested in calculation of non-prefetchable PCI memory aperture,
> but one can do the same for io and prefetchable memory as well.

Thanks Ivan! The patch works for me as well.

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2020-03-08 19:41         ` Matt Turner
@ 2020-03-12  4:28           ` Matt Turner
  2020-03-12 20:19             ` Bjorn Helgaas
  0 siblings, 1 reply; 21+ messages in thread
From: Matt Turner @ 2020-03-12  4:28 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Yinghai Lu, Ivan Kokshaysky, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Nicholas Johnson,
	Benjamin Herrenschmidt

On Sun, Mar 8, 2020 at 12:41 PM Matt Turner <mattst88@gmail.com> wrote:
>
> On Sun, Mar 8, 2020 at 8:30 AM Ivan Kokshaysky <ink@jurassic.park.msu.ru> wrote:
> > Wholeheartedly agree. In fact, changes to generic PCI code required
> > for proper root bus sizing are quite minimal now since we have
> > struct pci_host_bridge. It's mostly additional checks for bus->self
> > being NULL (as it normally is on the root bus) in the
> > __pci_bus_size_bridges() path, plus new bridge->size_windows flag.
> > See patch below (tested on UP1500). Note that on irongate we're
> > only interested in calculation of non-prefetchable PCI memory aperture,
> > but one can do the same for io and prefetchable memory as well.
>
> Thanks Ivan! The patch works for me as well.

Bjorn, what would you like the next step to be?

If the PCI bits are fine with you, I assume you'd like them to go
through your tree, etc? I'm perfectly happy to see the alpha bits go
through the same tree.

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2020-03-12  4:28           ` Matt Turner
@ 2020-03-12 20:19             ` Bjorn Helgaas
  2020-03-12 20:49               ` Ivan Kokshaysky
  0 siblings, 1 reply; 21+ messages in thread
From: Bjorn Helgaas @ 2020-03-12 20:19 UTC (permalink / raw)
  To: Matt Turner
  Cc: Yinghai Lu, Ivan Kokshaysky, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Nicholas Johnson,
	Benjamin Herrenschmidt

On Wed, Mar 11, 2020 at 09:28:33PM -0700, Matt Turner wrote:
> On Sun, Mar 8, 2020 at 12:41 PM Matt Turner <mattst88@gmail.com> wrote:
> > On Sun, Mar 8, 2020 at 8:30 AM Ivan Kokshaysky <ink@jurassic.park.msu.ru> wrote:
> > > Wholeheartedly agree. In fact, changes to generic PCI code required
> > > for proper root bus sizing are quite minimal now since we have
> > > struct pci_host_bridge. It's mostly additional checks for bus->self
> > > being NULL (as it normally is on the root bus) in the
> > > __pci_bus_size_bridges() path, plus new bridge->size_windows flag.
> > > See patch below (tested on UP1500). Note that on irongate we're
> > > only interested in calculation of non-prefetchable PCI memory aperture,
> > > but one can do the same for io and prefetchable memory as well.
> >
> > Thanks Ivan! The patch works for me as well.
> 
> Bjorn, what would you like the next step to be?
> 
> If the PCI bits are fine with you, I assume you'd like them to go
> through your tree, etc? I'm perfectly happy to see the alpha bits go
> through the same tree.

Yes, I think this looks reasonable.  We should get this posted in the
usual format (commit log, signed-off-by, etc), and then get it into
-next to see how it flies.

Bjorn

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

* Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)
  2020-03-12 20:19             ` Bjorn Helgaas
@ 2020-03-12 20:49               ` Ivan Kokshaysky
  0 siblings, 0 replies; 21+ messages in thread
From: Ivan Kokshaysky @ 2020-03-12 20:49 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Matt Turner, Yinghai Lu, linux-pci, linux-alpha,
	Richard Henderson, Jay Estabrook, Nicholas Johnson,
	Benjamin Herrenschmidt

On Thu, Mar 12, 2020 at 03:19:00PM -0500, Bjorn Helgaas wrote:
> On Wed, Mar 11, 2020 at 09:28:33PM -0700, Matt Turner wrote:
> > If the PCI bits are fine with you, I assume you'd like them to go
> > through your tree, etc? I'm perfectly happy to see the alpha bits go
> > through the same tree.
> 
> Yes, I think this looks reasonable.  We should get this posted in the
> usual format (commit log, signed-off-by, etc), and then get it into
> -next to see how it flies.

Ok, I'll do it this weekend.

Ivan.

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

end of thread, other threads:[~2020-03-12 20:50 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-16 14:33 Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation) Matt Turner
2018-04-16 21:50 ` Bjorn Helgaas
2018-04-17  4:43   ` Matt Turner
2018-04-17 19:43     ` Bjorn Helgaas
2018-04-18 20:48       ` Ivan Kokshaysky
2018-04-20 17:03         ` Bjorn Helgaas
2018-04-22 20:07         ` Matt Turner
2018-04-23 17:34           ` Ivan Kokshaysky
2018-05-02 20:33             ` Bjorn Helgaas
2018-05-02 21:10               ` Matt Turner
2018-05-07  0:46             ` Matt Turner
2019-10-18  5:57             ` Matt Turner
2020-02-22 16:55 ` Bjorn Helgaas
2020-02-28 23:51   ` Matt Turner
2020-03-01 14:30     ` Ivan Kokshaysky
2020-03-02 22:47     ` Bjorn Helgaas
2020-03-08 15:30       ` Ivan Kokshaysky
2020-03-08 19:41         ` Matt Turner
2020-03-12  4:28           ` Matt Turner
2020-03-12 20:19             ` Bjorn Helgaas
2020-03-12 20:49               ` Ivan Kokshaysky

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).