All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
  2019-10-28 17:13 ` Oxford Semiconductor Ltd OX16PCI954 - weird dmesg Bjorn Helgaas
@ 2019-10-28 16:37   ` Carlo Pisani
  2019-10-28 18:48     ` Bjorn Helgaas
  2019-10-28 16:46   ` Carlo Pisani
  1 sibling, 1 reply; 13+ messages in thread
From: Carlo Pisani @ 2019-10-28 16:37 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: linux-pci

> > > These resources are supplied to the PCI core, probably from DT.  A
> > > complete dmesg log would show more.

The rb532 does not have device tree support, so the answer is no.
I am using a common vanilla kernel without any extra patch.


> It's hard to tell what this 00:00.0 device is.  The Vendor ID 0x111d
> is "Microsemi / PMC / IDT" (now owned by Microchip Technology, per
> https://pci-ids.ucw.cz/read/PC/111d).
>
> The Device ID of 0x0000 looks invalid (though that's defined by the
> vendor, and I think the PCIe spec would allow 0).
>
> The class code is invalid.  Likely the device has configuration
> registers for the PCI host bridge.

> > pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff]
> > pci_bus 0000:00: root bus resource [io  0x18800000-0x188fffff]
> > pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
> > pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
> > pci 0000:00:00.0: [111d:0000] type 00 class 0x000000
> > pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x07ffffff pref]
> > pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
> > pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
>
> It's hard to tell what this 00:00.0 device is.  The Vendor ID 0x111d
> is "Microsemi / PMC / IDT" (now owned by Microchip Technology, per
> https://pci-ids.ucw.cz/read/PC/111d).

> Can you collect the output of "lspci -vvxxx" as root?

uc-rb532 ~ # lspci -vvxxx
00:00.0 Non-VGA unclassified device: Integrated Device Technology,
Inc. Device 0000
        Subsystem: Device 0214:011d
        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: 60 (2000ns min, 14000ns max), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 140
        Region 0: Memory at <unassigned> (32-bit, prefetchable)
        Region 1: I/O ports at <ignored>
        Region 2: I/O ports at <ignored>
00: 1d 11 00 00 57 01 a0 22 00 00 00 00 04 3c 00 00
10: 08 00 00 00 01 00 80 18 01 00 00 18 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 14 02 1d 01
30: 00 00 00 00 00 00 00 00 00 00 00 00 8c 01 08 38
40: 80 80 00 00 6e 0d 00 00 00 00 00 00 51 00 00 00
50: 00 00 00 00 55 00 00 00 00 00 00 18 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:02.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S
[Rhine-III] (rev 86)
        Subsystem: AST Research Inc Device 086c
        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: 64
        Interrupt: pin A routed to IRQ 142
        Region 0: I/O ports at 18800000 [size=256]
        Region 1: Memory at 50014000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=100mA
PME(D0-,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: via-rhine
00: 06 11 06 31 87 00 10 02 86 00 00 02 00 40 00 00
10: 01 00 80 18 00 40 01 50 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 0d 10 6c 08
30: 00 00 00 00 40 00 00 00 00 00 00 00 8e 01 00 00
40: 01 00 82 f6 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:03.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S
[Rhine-III] (rev 86)
        Subsystem: AST Research Inc Device 086c
        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: 64
        Interrupt: pin A routed to IRQ 143
        Region 0: I/O ports at 18800400 [size=256]
        Region 1: Memory at 50014100 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=100mA
PME(D0-,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: via-rhine
00: 06 11 06 31 87 00 10 02 86 00 00 02 00 40 00 00
10: 01 04 80 18 00 41 01 50 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 0d 10 6c 08
30: 00 00 00 00 40 00 00 00 00 00 00 00 8f 01 00 00
40: 01 00 82 f6 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:04.0 Network controller: Atheros Communications Inc. Device 0029 (rev 01)
        Subsystem: Atheros Communications Inc. Device 2091
        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: 168, Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 142
        Region 0: Memory at 50000000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=100mA
PME(D0+,D1-,D2-,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: ath9k
00: 8c 16 29 00 06 00 b0 02 01 00 80 02 04 a8 00 00
10: 00 00 00 50 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 8c 16 91 20
30: 00 00 00 00 44 00 00 00 00 00 00 00 8e 01 00 00
40: 80 00 00 00 01 00 82 48 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:05.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad
16950 UART) function 0 (Uart) (rev 01) (prog-if 06 [16950])
        Subsystem: Oxford Semiconductor Ltd Device 0000
        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-
        Interrupt: pin A routed to IRQ 143
        Region 0: I/O ports at 18800800 [size=32]
        Region 1: Memory at 50010000 (32-bit, non-prefetchable) [size=4K]
        Region 2: I/O ports at 18800820 [size=32]
        Region 3: Memory at 50011000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA
PME(D0+,D1-,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: serial
00: 15 14 01 95 03 00 90 02 01 06 00 07 00 00 80 00
10: 01 08 80 18 00 00 01 50 21 08 80 18 00 10 01 50
20: 00 00 00 00 00 00 00 00 00 00 00 00 15 14 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 8f 01 00 00
40: 01 00 02 6c 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:05.1 Non-VGA unclassified device: Oxford Semiconductor Ltd
OX16PCI954 (Quad 16950 UART) function 0 (Disabled) (rev 01)
        Subsystem: Oxford Semiconductor Ltd Device 0000
        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-
        Interrupt: pin A routed to IRQ 143
        Region 0: I/O ports at <unassigned> [disabled]
        Region 1: I/O ports at <unassigned> [disabled]
        Region 2: I/O ports at <unassigned> [disabled]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA
PME(D0+,D1-,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 15 14 00 95 00 00 90 02 01 00 00 00 00 00 80 00
10: 01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 15 14 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 8f 01 00 00
40: 01 00 02 6c 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0a.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad
16950 UART) function 0 (Uart) (rev 01) (prog-if 06 [16950])
        Subsystem: Oxford Semiconductor Ltd Device 0000
        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-
        Interrupt: pin A routed to IRQ 140
        Region 0: I/O ports at 18800840 [size=32]
        Region 1: Memory at 50012000 (32-bit, non-prefetchable) [size=4K]
        Region 2: I/O ports at 18800860 [size=32]
        Region 3: Memory at 50013000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA
PME(D0+,D1-,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: serial
00: 15 14 01 95 03 00 90 02 01 06 00 07 00 00 80 00
10: 41 08 80 18 00 20 01 50 61 08 80 18 00 30 01 50
20: 00 00 00 00 00 00 00 00 00 00 00 00 15 14 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 8c 01 00 00
40: 01 00 02 6c 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00:0a.1 Non-VGA unclassified device: Oxford Semiconductor Ltd
OX16PCI954 (Quad 16950 UART) function 0 (Disabled) (rev 01)
        Subsystem: Oxford Semiconductor Ltd Device 0000
        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-
        Interrupt: pin A routed to IRQ 140
        Region 0: I/O ports at <unassigned> [disabled]
        Region 1: I/O ports at <unassigned> [disabled]
        Region 2: I/O ports at <unassigned> [disabled]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA
PME(D0+,D1-,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 15 14 00 95 00 00 90 02 01 00 00 00 00 00 80 00
10: 01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 15 14 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 8c 01 00 00
40: 01 00 02 6c 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


> If those UARTs are capable of DMA, it's conceivable they could corrupt
something.

yes, it looks like something corrupts the memory.

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
  2019-10-28 17:13 ` Oxford Semiconductor Ltd OX16PCI954 - weird dmesg Bjorn Helgaas
  2019-10-28 16:37   ` Carlo Pisani
@ 2019-10-28 16:46   ` Carlo Pisani
  1 sibling, 0 replies; 13+ messages in thread
From: Carlo Pisani @ 2019-10-28 16:46 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: linux-pci

http://www.downthebunker.com/chunk_of/stuff/public/projects/sonoko-x11/devices/io/miniPCI-uart-4x-serial.png

This is a pic of one of the two miniPCI quad-UART modules.

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
       [not found] <CA+QBN9C_o8HanAzXpDUN410g2o5+xfx64pbX3_VHVDKcj5N3kA@mail.gmail.com>
@ 2019-10-28 17:13 ` Bjorn Helgaas
  2019-10-28 16:37   ` Carlo Pisani
  2019-10-28 16:46   ` Carlo Pisani
  0 siblings, 2 replies; 13+ messages in thread
From: Bjorn Helgaas @ 2019-10-28 17:13 UTC (permalink / raw)
  To: Carlo Pisani; +Cc: linux-pci

[+cc linux-pci -- please "reply-all" so the discussion stays on the
mailing list so everybody can benefit]

On Fri, Oct 25, 2019 at 07:39:14PM +0200, Carlo Pisani wrote:
> > These resources are supplied to the PCI core, probably from DT.  A
> > complete dmesg log would show more.
> 
> Kernel command line: console=ttyS0,9600 gpio=8191 mem=64M
> kmac=00:0C:42:0E:8F:01 board=500r5 boot=1  root=/dev/sda3
> init=/sbin/init msg=hAlloworld
> korina mac = 00:0C:42:0E:8F:01
> PID hash table entries: 256 (order: -2, 1024 bytes)
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 57840K/65536K available (4762K kernel code, 175K rwdata, 816K
> rodata, 188K init, 111K bss, 7696K reserved, 0K cma-reserved)
> NR_IRQS:256
> Initializing IRQ's: 168 out of 256
> calculating r4koff... 000c34f8(799992)
> CPU frequency 400.00 MHz
> clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff,
> max_idle_ns: 9556397797 ns
> sched_clock: 32 bits at 199MHz, resolution 5ns, wraps every 10737525757ns
> Calibrating delay loop... 397.82 BogoMIPS (lpj=795648)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
> max_idle_ns: 7645041785100000 ns
> futex hash table entries: 256 (order: -1, 3072 bytes)
> NET: Registered protocol family 16
> PCI: Initializing PCI
> SCSI subsystem initialized
> libata version 3.00 loaded.
> PCI host bridge to bus 0000:00

I wish we printed something about which host bridge driver we're using
here.  Are you booting with a DT?  If so, can you attach it?

> pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff]
> pci_bus 0000:00: root bus resource [io  0x18800000-0x188fffff]
> pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
> pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
> pci 0000:00:00.0: [111d:0000] type 00 class 0x000000
> pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x07ffffff pref]
> pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
> pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)

It's hard to tell what this 00:00.0 device is.  The Vendor ID 0x111d
is "Microsemi / PMC / IDT" (now owned by Microchip Technology, per
https://pci-ids.ucw.cz/read/PC/111d).

The Device ID of 0x0000 looks invalid (though that's defined by the
vendor, and I think the PCIe spec would allow 0).

The class code is invalid.  Likely the device has configuration
registers for the PCI host bridge.

> pci 0000:00:02.0: [1106:3106] type 00 class 0x020000
> pci 0000:00:02.0: reg 0x10: [io  0x0000-0x00ff]
> pci 0000:00:02.0: reg 0x14: [mem 0x00000000-0x000000ff]
> pci 0000:00:02.0: supports D1 D2
> pci 0000:00:02.0: PME# supported from D1 D2 D3hot D3cold
> pci 0000:00:03.0: [1106:3106] type 00 class 0x020000
> pci 0000:00:03.0: reg 0x10: [io  0x0000-0x00ff]
> pci 0000:00:03.0: reg 0x14: [mem 0x00000000-0x000000ff]
> pci 0000:00:03.0: supports D1 D2
> pci 0000:00:03.0: PME# supported from D1 D2 D3hot D3cold
> pci 0000:00:04.0: [168c:0029] type 00 class 0x028000
> pci 0000:00:04.0: reg 0x10: [mem 0x00000000-0x0000ffff]
> pci 0000:00:04.0: PME# supported from D0 D3hot
> pci 0000:00:05.0: [1415:9501] type 00 class 0x070006
> pci 0000:00:05.0: reg 0x10: [io  0x0000-0x001f]
> pci 0000:00:05.0: reg 0x14: [mem 0x00000000-0x00000fff]
> pci 0000:00:05.0: reg 0x18: [io  0x0000-0x001f]
> pci 0000:00:05.0: reg 0x1c: [mem 0x00000000-0x00000fff]
> pci 0000:00:05.0: supports D2
> pci 0000:00:05.0: PME# supported from D0 D2 D3hot
> pci 0000:00:05.1: [1415:9500] type 00 class 0x000000
> pci 0000:00:05.1: reg 0x10: [io  0x0000-0x0007]
> pci 0000:00:05.1: reg 0x14: [io  0x0000-0x0007]
> pci 0000:00:05.1: reg 0x18: [io  0x0000-0x001f]
> pci 0000:00:05.1: reg 0x1c: [mem 0x00000000-0x00000fff]
> pci 0000:00:05.1: supports D2
> pci 0000:00:05.1: PME# supported from D0 D2 D3hot
> pci 0000:00:0a.0: [1415:9501] type 00 class 0x070006
> pci 0000:00:0a.0: reg 0x10: [io  0x0000-0x001f]
> pci 0000:00:0a.0: reg 0x14: [mem 0x00000000-0x00000fff]
> pci 0000:00:0a.0: reg 0x18: [io  0x0000-0x001f]
> pci 0000:00:0a.0: reg 0x1c: [mem 0x00000000-0x00000fff]
> pci 0000:00:0a.0: supports D2
> pci 0000:00:0a.0: PME# supported from D0 D2 D3hot
> pci 0000:00:0a.1: [1415:9500] type 00 class 0x000000
> pci 0000:00:0a.1: reg 0x10: [io  0x0000-0x0007]
> pci 0000:00:0a.1: reg 0x14: [io  0x0000-0x0007]
> pci 0000:00:0a.1: reg 0x18: [io  0x0000-0x001f]
> pci 0000:00:0a.1: reg 0x1c: [mem 0x00000000-0x00000fff]
> pci 0000:00:0a.1: supports D2
> pci 0000:00:0a.1: PME# supported from D0 D2 D3hot
> pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
> pci 0000:00:04.0: BAR 0: assigned [mem 0x50000000-0x5000ffff]
> pci 0000:00:05.0: BAR 1: assigned [mem 0x50010000-0x50010fff]
> pci 0000:00:05.0: BAR 3: assigned [mem 0x50011000-0x50011fff]
> pci 0000:00:0a.0: BAR 1: assigned [mem 0x50012000-0x50012fff]
> pci 0000:00:0a.0: BAR 3: assigned [mem 0x50013000-0x50013fff]
> pci 0000:00:02.0: BAR 0: assigned [io  0x18800000-0x188000ff]
> pci 0000:00:02.0: BAR 1: assigned [mem 0x50014000-0x500140ff]
> pci 0000:00:03.0: BAR 0: assigned [io  0x18800400-0x188004ff]
> pci 0000:00:03.0: BAR 1: assigned [mem 0x50014100-0x500141ff]
> pci 0000:00:05.0: BAR 0: assigned [io  0x18800800-0x1880081f]
> pci 0000:00:05.0: BAR 2: assigned [io  0x18800820-0x1880083f]
> pci 0000:00:0a.0: BAR 0: assigned [io  0x18800840-0x1880085f]
> pci 0000:00:0a.0: BAR 2: assigned [io  0x18800860-0x1880087f]
> clocksource: Switched to clocksource MIPS
> NET: Registered protocol family 2
> TCP established hash table entries: 1024 (order: 0, 4096 bytes)
> TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> TCP: Hash tables configured (established 1024 bind 1024)
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> PCI: CLS 16 bytes, default 16
> io scheduler noop registered
> io scheduler deadline registered (default)
> Serial: 8250/16550 driver, 9 ports, IRQ sharing disabled
> serial8250: ttyS0 at MMIO 0x0 (irq = 104, base_baud = 12499875) is a 16550A
> console [ttyS0] enabled
> console [ttyS0] disabled
> serial8250.0: ttyS0 at MMIO 0x0 (irq = 104, base_baud = 12499875) is a 16550A
> console [ttyS0] enabled
> PCI: Enabling device 0000:00:05.0 (0000 -> 0003)
> ttyS1: detected caps 00000700 should be 00000500
> 0000:00:05.0: ttyS1 at I/O 0x18800800 (irq = 143, base_baud = 115200)
> is a 16C950/954
> ttyS2: detected caps 00000700 should be 00000500
> 0000:00:05.0: ttyS2 at I/O 0x18800808 (irq = 143, base_baud = 115200)
> is a 16C950/954
> ttyS3: detected caps 00000700 should be 00000500
> 0000:00:05.0: ttyS3 at I/O 0x18800810 (irq = 143, base_baud = 115200)
> is a 16C950/954
> ttyS4: detected caps 00000700 should be 00000500
> 0000:00:05.0: ttyS4 at I/O 0x18800818 (irq = 143, base_baud = 115200)
> is a 16C950/954
> PCI: Enabling device 0000:00:0a.0 (0000 -> 0003)
> ttyS5: detected caps 00000700 should be 00000500
> 0000:00:0a.0: ttyS5 at I/O 0x18800840 (irq = 140, base_baud = 115200)
> is a 16C950/954
> ttyS6: detected caps 00000700 should be 00000500
> 0000:00:0a.0: ttyS6 at I/O 0x18800848 (irq = 140, base_baud = 115200)
> is a 16C950/954
> ttyS7: detected caps 00000700 should be 00000500
> 0000:00:0a.0: ttyS7 at I/O 0x18800850 (irq = 140, base_baud = 115200)
> is a 16C950/954
> ttyS8: detected caps 00000700 should be 00000500
> 0000:00:0a.0: ttyS8 at I/O 0x18800858 (irq = 140, base_baud = 115200)
> is a 16C950/954
> loop: module loaded
> nbd: registered device at major 43
> null: module loaded
> scsi host0: pata-rb532-cf
> ata1: PATA max PIO4 irq 149
> Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> tun: Universal TUN/TAP device driver, 1.6
> tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> ata1.00: CFA: HMS360404D5CF00, DN4OCA2A, max PIO4
> ata1.00: 7999488 sectors, multi 0: LBA
> eth0: korina-0.10 04Mar2008
> via_rhine: v1.10-LK1.5.1 2010-10-09 Written by Donald Becker
> PCI: Enabling device 0000:00:02.0 (0080 -> 0083)
> via-rhine 0000:00:02.0 eth1: VIA Rhine III at 0xc0012000,
> 00:0c:42:0e:8f:02, IRQ 142
> via-rhine 0000:00:02.0 eth1: MII PHY found at address 1, status 0x7869
> advertising 05e1 Link 45e1
> PCI: Enabling device 0000:00:03.0 (0080 -> 0083)
> via-rhine 0000:00:03.0 eth2: VIA Rhine III at 0xc0014100,
> 00:0c:42:0e:8f:03, IRQ 143
> via-rhine 0000:00:03.0 eth2: MII PHY found at address 1, status 0x7869
> advertising 05e1 Link 41e1
> PCI: Enabling device 0000:00:04.0 (0000 -> 0002)
> ath: EEPROM regdomain: 0x809c
> ath: EEPROM indicates we should expect a country code
> ath: doing EEPROM country->regdmn map search
> ath: country maps to regdmn code: 0x52
> ath: Country alpha2 being used: CN
> ath: Regpair used: 0x52
> ata1.00: configured for PIO4
> scsi 0:0:0:0: Direct-Access     ATA      HMS360404D5CF00  CA2A PQ: 0 ANSI: 5
> ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xc0020000, irq=142
> sd 0:0:0:0: [sda] 7999488 512-byte logical blocks: (4.10 GB/3.81 GiB)
> aoe: AoE v85 initialised.
> rc32434_wdt: Stopped watchdog timer
> rc32434_wdt: Watchdog Timer version 1.0, timer margin: 20 sec
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't
> support DPO or FUA
> NET: Registered protocol family 26
> Netfilter messages via NETLINK v0.30.
> nf_conntrack version 0.5.0 (903 buckets, 3612 max)
>  sda: sda1 sda2 sda3
> nf_tables: (c) 2007-2009 Patrick McHardy <kaber@trash.net>
> sd 0:0:0:0: [sda] Attached SCSI removable disk
> nf_tables_compat: (c) 2012 Pablo Neira Ayuso <pablo@netfilter.org>
> xt_time: kernel timezone is -0000
> ip_tables: (C) 2000-2006 Netfilter Core Team
> arp_tables: (C) 2002 David S. Miller
> NET: Registered protocol family 17
> bridge: automatic filtering via arp/ip/ip6tables has been deprecated.
> Update your scripts to load br_netfilter if you need this.
> Bridge firewalling registered
> Ebtables v2.0 registered
> EXT4-fs (sda3): couldn't mount as ext3 due to feature incompatibilities
> EXT4-fs (sda3): INFO: recovery required on readonly filesystem
> EXT4-fs (sda3): write access will be enabled during recovery
> random: nonblocking pool is initialized
> EXT4-fs (sda3): recovery complete
> EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
> VFS: Mounted root (ext4 filesystem) readonly on device 8:3.
> Freeing unused kernel memory: 188K
> EXT4-fs (sda3): re-mounted. Opts: (null)
> EXT4-fs (sda3): re-mounted. Opts: (null)
> EXT4-fs (sda3): re-mounted. Opts: (null)
> EXT4-fs (sda3): re-mounted. Opts: (null)
> EXT4-fs (sda3): re-mounted. Opts: (null)
> EXT4-fs (sda3): re-mounted. Opts: (null)
> Adding 117428k swap on /dev/sda2.  Priority:-1 extents:1 across:117428k
> device eth0 entered promiscuous mode
> device eth1 entered promiscuous mode
> device eth2 entered promiscuous mode
> 
> 
> > If you take the cards out, do the lines you mention above change?
> 
> I have to test it. But with the cards out I never experimented a crash
> 
> this is the board
> http://www.downthebunker.com/reloaded/space/viewtopic.php?f=79&t=271
> 
> 
> > What sort of crashes do you see?  I assume it doesn't crash without
> > the cards?
> 
> This rb532 is currently tested this way:
> - two miniPCI Quad-UART installed
> - /dev/ttyS5 attached to a machine which continuously sends messages
> on the serial
> - eth0, eth1, eth1 configured as bridge
> - eth1 attached to a machine which continuously requests TFTP packages
> on the ethernet
> - eth0 attached to the local network, with one ssh section to monitor
> the machine
> - the application minicom does monitor /dev/ttyS5
> 
> the machine looks working properly in a short time, but  within 48h I
> do see weird behaviors, and crashes seem referred to
> - minicom
> - in.tftpd
> 
> do_page_fault(): sending SIGSEGV to in.tftpd for invalid write access
> to 0401a8c8
> epc = 77c7afa4 in libc-2.9.so[77bc9000+160000]
> ra  = 77c7af88 in libc-2.9.so[77bc9000+160000]
> 
> uc-rb532 ~ # CPU 0 Unable to handle kernel paging request at virtual
> address 1040ff60, epc == 8049543c, ra == 80495fe0
> Oops[#1]:
> CPU: 0 PID: 6395 Comm: in.tftpd Not tainted 4.4.197-BlurryFishButt-rb532 #2
> task: 83660588 ti: 80ed4000 task.ti: 80ed4000
> Status: 1810e803        KERNEL EXL IE
> Cause : 30800008 (ExcCode 02)
> BadVA : 1040ff60
> PrId  : 0001800a (MIPS 4Kc)
> Modules linked in:
> Process in.tftpd (pid: 6395, threadinfo=80ed4000, task=83660588, tls=77a57470)

Can you collect the output of "lspci -vvxxx" as root?

If those UARTs are capable of DMA, it's conceivable they could corrupt
something.

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
  2019-10-28 18:48     ` Bjorn Helgaas
@ 2019-10-28 18:06       ` Carlo Pisani
  2019-10-28 19:43         ` Bjorn Helgaas
  0 siblings, 1 reply; 13+ messages in thread
From: Carlo Pisani @ 2019-10-28 18:06 UTC (permalink / raw)
  To: bjorn; +Cc: Bjorn Helgaas, linux-pci

> What's your .config file?  The knowledge about the host bridge windows
> must be compiled in somewhere.

here it is

http://www.downthebunker.com/chunk_of/stuff/public/projects/sonoko-x11/router-board/kernel/k4.4.197-rb532.config

too long to be attached to this email

> The UARTs do not have DMA enabled (BusMaster-) in the lspci output, so
> they shouldn't be able to corrupt memory.  The NICs *do* have DMA
> enabled.  Does the problem still happen if you turn off the NIC
> drivers (via-rhine and ath9k, it looks like)?

I will recompile the kernel and re-test the router. It's a 48 hours burn-in test

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
  2019-10-28 16:37   ` Carlo Pisani
@ 2019-10-28 18:48     ` Bjorn Helgaas
  2019-10-28 18:06       ` Carlo Pisani
  0 siblings, 1 reply; 13+ messages in thread
From: Bjorn Helgaas @ 2019-10-28 18:48 UTC (permalink / raw)
  To: Carlo Pisani; +Cc: Bjorn Helgaas, linux-pci

On Mon, Oct 28, 2019 at 12:37 PM Carlo Pisani <carlojpisani@gmail.com> wrote:
>
> > > > These resources are supplied to the PCI core, probably from DT.  A
> > > > complete dmesg log would show more.
>
> The rb532 does not have device tree support, so the answer is no.
> I am using a common vanilla kernel without any extra patch.

What's your .config file?  The knowledge about the host bridge windows
must be compiled in somewhere.

> 00:02.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S
> [Rhine-III] (rev 86)
>         Subsystem: AST Research Inc Device 086c
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping+ SERR- FastB2B- DisINTx-

> 00:05.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad
> 16950 UART) function 0 (Uart) (rev 01) (prog-if 06 [16950])
>         Subsystem: Oxford Semiconductor Ltd Device 0000
>         Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-

> > If those UARTs are capable of DMA, it's conceivable they could corrupt
> something.
>
> yes, it looks like something corrupts the memory.

The UARTs do not have DMA enabled (BusMaster-) in the lspci output, so
they shouldn't be able to corrupt memory.  The NICs *do* have DMA
enabled.  Does the problem still happen if you turn off the NIC
drivers (via-rhine and ath9k, it looks like)?

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
  2019-10-28 19:43         ` Bjorn Helgaas
@ 2019-10-28 18:49           ` Carlo Pisani
  2019-11-04 14:59             ` Bjorn Helgaas
  0 siblings, 1 reply; 13+ messages in thread
From: Carlo Pisani @ 2019-10-28 18:49 UTC (permalink / raw)
  To: bjorn; +Cc: Bjorn Helgaas, linux-pci

> It looks like you're using a v4.4-based kernel, which is 3 1/2 years
> old.  In general people are not very interested in debugging kernels
> that old.  It's better if you can reproduce the problem on a current
> kernel, then backport the fix if you need it in an older kernel.

as specified in this topic (1), kernel >= v4.11 does not even boot on rb532.
When tftpboot, the firmware says "out of range", and hangs.


(1) http://www.downthebunker.com/reloaded/space/viewtopic.php?f=79&p=2755

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
  2019-10-28 18:06       ` Carlo Pisani
@ 2019-10-28 19:43         ` Bjorn Helgaas
  2019-10-28 18:49           ` Carlo Pisani
  0 siblings, 1 reply; 13+ messages in thread
From: Bjorn Helgaas @ 2019-10-28 19:43 UTC (permalink / raw)
  To: Carlo Pisani; +Cc: Bjorn Helgaas, Bjorn Helgaas, linux-pci

On Mon, Oct 28, 2019 at 2:06 PM Carlo Pisani <carlojpisani@gmail.com> wrote:
>
> > What's your .config file?  The knowledge about the host bridge windows
> > must be compiled in somewhere.
>
> here it is
>
> http://www.downthebunker.com/chunk_of/stuff/public/projects/sonoko-x11/router-board/kernel/k4.4.197-rb532.config
>
> too long to be attached to this email
>
> > The UARTs do not have DMA enabled (BusMaster-) in the lspci output, so
> > they shouldn't be able to corrupt memory.  The NICs *do* have DMA
> > enabled.  Does the problem still happen if you turn off the NIC
> > drivers (via-rhine and ath9k, it looks like)?
>
> I will recompile the kernel and re-test the router. It's a 48 hours burn-in test

It looks like you're using a v4.4-based kernel, which is 3 1/2 years
old.  In general people are not very interested in debugging kernels
that old.  It's better if you can reproduce the problem on a current
kernel, then backport the fix if you need it in an older kernel.

Bjorn

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
  2019-10-28 18:49           ` Carlo Pisani
@ 2019-11-04 14:59             ` Bjorn Helgaas
  0 siblings, 0 replies; 13+ messages in thread
From: Bjorn Helgaas @ 2019-11-04 14:59 UTC (permalink / raw)
  To: Carlo Pisani; +Cc: bjorn, linux-pci

On Mon, Oct 28, 2019 at 07:49:55PM +0100, Carlo Pisani wrote:
> > It looks like you're using a v4.4-based kernel, which is 3 1/2 years
> > old.  In general people are not very interested in debugging kernels
> > that old.  It's better if you can reproduce the problem on a current
> > kernel, then backport the fix if you need it in an older kernel.
> 
> as specified in this topic (1), kernel >= v4.11 does not even boot on rb532.
> When tftpboot, the firmware says "out of range", and hangs.

I think the first step is to fix the problem that prevents current
kernels from booting.  It's not really practical to debug v4.4.

It sounds like the firmware fails to even load v4.11?  If that's the
case, it's probably not a problem with the kernel itself, since it
hasn't even started executing.  Possibly a kernel size problem?  Maybe
the v4.11 kernel is larger than v4.4, v4.9, etc?  Does v4.11 boot if
you strip out non-essential drivers?

> (1) http://www.downthebunker.com/reloaded/space/viewtopic.php?f=79&p=2755

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
       [not found] <CA+QBN9D4bckEZmNhLJPBmr92St1W2GGyazLGR9kANFk2cfV8Pg@mail.gmail.com>
@ 2019-11-04 16:30 ` Bjorn Helgaas
  0 siblings, 0 replies; 13+ messages in thread
From: Bjorn Helgaas @ 2019-11-04 16:30 UTC (permalink / raw)
  To: Carlo Pisani; +Cc: linux-pci

[+cc linux-pci]

On Mon, Nov 04, 2019 at 05:04:54PM +0100, Carlo Pisani wrote:
> > > > It sounds like the firmware fails to even load v4.11?  If that's the
> > > > case, it's probably not a problem with the kernel itself, since it
> > > > hasn't even started executing.  Possibly a kernel size problem?  Maybe
> > > > the v4.11 kernel is larger than v4.4, v4.9, etc?  Does v4.11 boot if
> > > > you strip out non-essential drivers?
> 
> kernel v4.11 is 7.5Mbyte and doesn't boot from the TFTboot option
> offered by the firmware, it claims "out of range", which makes no
> sense
> 
> out of range in what? too big? bad initialized? who knows ....
> 
> > Is the v4.11 kernel image bigger than the v4.4 kernel that boots?
> 
> everything bigger than 7Mbyte seems to be bad for the firmware.

You should be able to test this by adding built-in drivers to your
v4.4 kernel so it becomes larger than 7 MB.  If the kernel size is the
problem, a large v4.4 kernel should fail the same way the v4.11 kernel
does.

> anyway, I post here to hear if someone is on the RB532A (Mikrotik),
> should I also open a ticket to OpenWrt?

I guess it wouldn't hurt to open an OpenWrt ticket because maybe more
people there have experience with the RB532A.  But if the problem is
simply that the RB532A has broken Rhine devices that don't correctly
support PCI MMIO access, the only fix is to work around it by using
I/O port access instead.

Your matrix at [1] seems to show that the only reliable "stable for
48h" combination is the one with PCI MMIO access disabled.

If there's some way to identify that broken device or the platform,
e.g., RB532A, somebody could write a quirk to automatically disable
PCI MMIO in the driver.  But the comment in the driver already
mentions that, so I guess it's not trivial to identify those cases.

[1] http://www.downthebunker.com/reloaded/space/viewtopic.php?f=79&p=2755

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
       [not found] <CA+QBN9B4qfxpEa69TB=+MngG9bN0puwByAeGCMxk_Y7fgaKhpQ@mail.gmail.com>
@ 2019-11-04 16:07 ` Bjorn Helgaas
  0 siblings, 0 replies; 13+ messages in thread
From: Bjorn Helgaas @ 2019-11-04 16:07 UTC (permalink / raw)
  To: Carlo Pisani; +Cc: bjorn, linux-pci

[+cc linux-pci]

On Mon, Nov 04, 2019 at 03:18:46PM +0100, Carlo Pisani wrote:
> hi
> with this setup changes, it seems stable after 3 days of burn-in testing
> 
> VIA_RHINE st to PCI_IO
> Wifi Atheros9: unset
> 
> --- .config  2019-10-28 20:02:02.000000000 +0100
> +++ .config  2019-03-22 10:08:26.000000000 +0100
> @@ -1105,7 +1105,7 @@
>  # CONFIG_NET_VENDOR_TOSHIBA is not set
>  CONFIG_NET_VENDOR_VIA=y
>  CONFIG_VIA_RHINE=y
> -CONFIG_VIA_RHINE_MMIO=y
> +# CONFIG_VIA_RHINE_MMIO is not set
> 
> it seems there is a bug in the PCI and the bug manifests when
> "VIA_RHINE_MMIO" is enabled

In v5.4-rc1 (it's possible v4.4 is different), CONFIG_VIA_RHINE_MMIO
is only used here:

  static int rhine_init_one_pci(struct pci_dev *pdev, ...)
  {
    ...
    /* This driver was written to use PCI memory space. Some early versions
     * of the Rhine may only work correctly with I/O space accesses.
     * TODO: determine for which revisions this is true and assign the flag
     *       in code as opposed to this Kconfig option (???)
     */
  #ifdef CONFIG_VIA_RHINE_MMIO
          u32 quirks = rqNeedEnMMIO;
  #else
          u32 quirks = 0;
  #endif
  ...
          ioaddr = pci_iomap(pdev, (quirks & rqNeedEnMMIO ? 1 : 0), io_size);

So the only effect is that if CONFIG_VIA_RHINE_MMIO=y, the driver uses
BAR 1 (PCI MMIO space) instead of BAR 0 (PCI I/O port space).

That comment is pretty interesting -- perhaps the rb532 has those
early Rhine devices that don't work correctly with PCI MMIO space?

My guess is that either you have those early broken Rhine devices, or
there's some similar problem in the via-rhine driver.

If the device works at all, the problem is probably in the driver
rather than in the PCI core.  After the driver probes the device, the
PCI core is pretty much out of the picture.

> Il giorno mar 29 ott 2019 alle ore 00:31 Bjorn Helgaas
> <bjorn.helgaas@gmail.com> ha scritto:
> >
> > Unset CONFIG_VIA_RHINE and CONFIG_ATH9K.
> >
> > On Mon, Oct 28, 2019 at 6:05 PM Carlo Pisani <carlojpisani@gmail.com> wrote:
> > >
> > > what have I to remove in the config file?
> > >
> > > Il giorno lun 28 ott 2019 alle ore 22:09 Bjorn Helgaas
> > > <bjorn.helgaas@gmail.com> ha scritto:
> > > >
> > > > That config option doesn't affect whether the device uses DMA.
> > > >
> > > > On Mon, Oct 28, 2019 at 4:02 PM Carlo Pisani <carlojpisani@gmail.com> wrote:
> > > > >
> > > > > I have just removed this
> > > > >
> > > > > CONFIG_VIA_RHINE_MMIO:
> > > > > This instructs the driver to use PCI shared memory (MMIO) instead of
> > > > > programmed I/O ports (PIO). Enabling this gives an improvement in
> > > > > processing time in parts of the driver.
> > > > >
> > > > > and I am going to recompile the kernel
> > > > >
> > > > >
> > > > > Il giorno lun 28 ott 2019 alle ore 20:57 Bjorn Helgaas
> > > > > <bjorn.helgaas@gmail.com> ha scritto:
> > > > > >
> > > > > > On Mon, Oct 28, 2019 at 2:52 PM Carlo Pisani <carlojpisani@gmail.com> wrote:
> > > > > > >
> > > > > > > > The UARTs do not have DMA enabled (BusMaster-) in the lspci output, so
> > > > > > > > they shouldn't be able to corrupt memory.  The NICs *do* have DMA
> > > > > > > > enabled.  Does the problem still happen if you turn off the NIC
> > > > > > > > drivers (via-rhine and ath9k, it looks like)?
> > > > > > >
> > > > > > > how did you understand that uart do not have DMA enabled?
> > > > > > > what did you look at in the lspci output?
> > > > > >
> > > > > > The "Bus Master" bit determines whether the device can issue memory
> > > > > > read/write requests, i.e., DMA.  In your lspci output, it showed
> > > > > > "BusMaster-" for the UARTs, which means the bit is cleared.  The NICs
> > > > > > have "BusMaster+", which means they *can* issue DMA requests.

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
       [not found] <CA+QBN9AzXHifP4=F1O1jjbGP0yNxBZeTPgPJvpcKFb9Z4f30KA@mail.gmail.com>
@ 2019-11-04 15:58 ` Bjorn Helgaas
  0 siblings, 0 replies; 13+ messages in thread
From: Bjorn Helgaas @ 2019-11-04 15:58 UTC (permalink / raw)
  To: Carlo Pisani; +Cc: linux-pci

[+cc linux-pci (please keep the list copied so others can
contribute/benefit and it's searchable via list archives)]

On Mon, Nov 04, 2019 at 04:25:02PM +0100, Carlo Pisani wrote:
> > I think the first step is to fix the problem that prevents current
> > kernels from booting.  It's not really practical to debug v4.4.
> 
> does anyone have a modern kernel working for rb532?
> because I suspect Linux is in regressing regarding this point.

I have no idea what rb532 is or whether Linux is regressing on it.
Any platform that isn't tested occasionally does tend to regress over
time.

> > It sounds like the firmware fails to even load v4.11?  If that's the
> > case, it's probably not a problem with the kernel itself, since it
> > hasn't even started executing.  Possibly a kernel size problem?  Maybe
> > the v4.11 kernel is larger than v4.4, v4.9, etc?  Does v4.11 boot if
> > you strip out non-essential drivers?
> 
> I do not know, and I don't understand. The rb532 manual doesn't say a
> word regarding the maximal size of the kernel, which in our case is
> less than 8Mbyte

Is the v4.11 kernel image bigger than the v4.4 kernel that boots?

> We tried to strip extra functions out of the kernel v5.*, but no dice
> 
> hence, first we need to fix kernel 4.4 which boots and work, then we
> can try to understand what is wrong with kernel v5.*
> 
> our time is limited, and we have to complete a project rather than
> play with the kernel

Sorry, I should have been more clear.  I don't think it's practical
*for me* to debug something on v4.4.  It may well be practical for you
because you have different constraints than I do.

Bjorn

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
  2019-10-25 14:33   ` Oxford Semiconductor Ltd OX16PCI954 - weird dmesg Carlo Pisani
@ 2019-10-25 16:37     ` Bjorn Helgaas
  0 siblings, 0 replies; 13+ messages in thread
From: Bjorn Helgaas @ 2019-10-25 16:37 UTC (permalink / raw)
  To: Carlo Pisani; +Cc: linux-pci, linuxppc-dev, linux

On Fri, Oct 25, 2019 at 04:33:13PM +0200, Carlo Pisani wrote:
> pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff]
> pci_bus 0000:00: root bus resource [io  0x18800000-0x188fffff]
> pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
> pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
> pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
> pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
> pci 0000:00:04.0: BAR 0: assigned [mem 0x50000000-0x5000ffff]
> pci 0000:00:05.0: BAR 1: assigned [mem 0x50010000-0x50010fff]
> pci 0000:00:05.0: BAR 3: assigned [mem 0x50011000-0x50011fff]
> pci 0000:00:0a.0: BAR 1: assigned [mem 0x50012000-0x50012fff]
> pci 0000:00:0a.0: BAR 3: assigned [mem 0x50013000-0x50013fff]
> pci 0000:00:02.0: BAR 0: assigned [io  0x18800000-0x188000ff]
> pci 0000:00:02.0: BAR 1: assigned [mem 0x50014000-0x500140ff]
> pci 0000:00:03.0: BAR 0: assigned [io  0x18800400-0x188004ff]
> pci 0000:00:03.0: BAR 1: assigned [mem 0x50014100-0x500141ff]
> pci 0000:00:05.0: BAR 0: assigned [io  0x18800800-0x1880081f]
> pci 0000:00:05.0: BAR 2: assigned [io  0x18800820-0x1880083f]
> pci 0000:00:0a.0: BAR 0: assigned [io  0x18800840-0x1880085f]
> pci 0000:00:0a.0: BAR 2: assigned [io  0x18800860-0x1880087f]
> 
> 
> 00:00.0 Non-VGA unclassified device: Integrated Device Technology,
> Inc. Device 0000
>         Subsystem: Device 0214:011d
>         Flags: bus master, 66MHz, medium devsel, latency 60, IRQ 140
>         Memory at <unassigned> (32-bit, prefetchable)
>         I/O ports at <ignored>
>         I/O ports at <ignored>
> 
> 00:02.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S
> [Rhine-III] (rev 86)
>         Subsystem: AST Research Inc Device 086c
>         Flags: bus master, stepping, medium devsel, latency 64, IRQ 142
>         I/O ports at 18800000 [size=256]
>         Memory at 50014000 (32-bit, non-prefetchable) [size=256]
>         Capabilities: [40] Power Management version 2
>         Kernel driver in use: via-rhine
> 
> 00:03.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S
> [Rhine-III] (rev 86)
>         Subsystem: AST Research Inc Device 086c
>         Flags: bus master, stepping, medium devsel, latency 64, IRQ 143
>         I/O ports at 18800400 [size=256]
>         Memory at 50014100 (32-bit, non-prefetchable) [size=256]
>         Capabilities: [40] Power Management version 2
>         Kernel driver in use: via-rhine
> 
> 00:04.0 Network controller: Atheros Communications Inc. Device 0029 (rev 01)
>         Subsystem: Atheros Communications Inc. Device 2091
>         Flags: bus master, 66MHz, medium devsel, latency 168, IRQ 142
>         Memory at 50000000 (32-bit, non-prefetchable) [size=64K]
>         Capabilities: [44] Power Management version 2
>         Kernel driver in use: ath9k
> 
> 00:05.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad
> 16950 UART) function 0 (Uart) (rev 01) (prog-if 06 [)
>         Subsystem: Oxford Semiconductor Ltd Device 0000
>         Flags: medium devsel, IRQ 143
>         I/O ports at 18800800 [size=32]
>         Memory at 50010000 (32-bit, non-prefetchable) [size=4K]
>         I/O ports at 18800820 [size=32]
>         Memory at 50011000 (32-bit, non-prefetchable) [size=4K]
>         Capabilities: [40] Power Management version 2
>         Kernel driver in use: serial
> 
> 00:05.1 Non-VGA unclassified device: Oxford Semiconductor Ltd
> OX16PCI954 (Quad 16950 UART) function 0 (Disabled) (rev 01)
>         Subsystem: Oxford Semiconductor Ltd Device 0000
>         Flags: medium devsel, IRQ 143
>         I/O ports at <unassigned> [disabled]
>         I/O ports at <unassigned> [disabled]
>         I/O ports at <unassigned> [disabled]
>         Capabilities: [40] Power Management version 2
> 
> 00:0a.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad
> 16950 UART) function 0 (Uart) (rev 01) (prog-if 06 [)
>         Subsystem: Oxford Semiconductor Ltd Device 0000
>         Flags: medium devsel, IRQ 140
>         I/O ports at 18800840 [size=32]
>         Memory at 50012000 (32-bit, non-prefetchable) [size=4K]
>         I/O ports at 18800860 [size=32]
>         Memory at 50013000 (32-bit, non-prefetchable) [size=4K]
>         Capabilities: [40] Power Management version 2
>         Kernel driver in use: serial
> 
> 00:0a.1 Non-VGA unclassified device: Oxford Semiconductor Ltd
> OX16PCI954 (Quad 16950 UART) function 0 (Disabled) (rev 01)
>         Subsystem: Oxford Semiconductor Ltd Device 0000
>         Flags: medium devsel, IRQ 140
>         I/O ports at <unassigned> [disabled]
>         I/O ports at <unassigned> [disabled]
>         I/O ports at <unassigned> [disabled]
>         Capabilities: [40] Power Management version 2
> 
> 
> hi guys
> I have a couple of miniPCI Oxford Semiconductor Ltd OX16PCI954 cards
> installed, and the dmesg looks weird
> 
> espeially these lines
> pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff]
> pci_bus 0000:00: root bus resource [io  0x18800000-0x188fffff]
> pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
> pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]

These resources are supplied to the PCI core, probably from DT.  A
complete dmesg log would show more.

> pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
> pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)

> besides, I am experimenting crashes happening in burn-in tests, and I
> do suspect it's something related to the newly added cards

If you take the cards out do the lines you mention above change?

What sort of crashes do you see?  I assume it doesn't crash without
the cards?

It *looks* like the miniPCI cards should be these devices:

  00:05.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) (rev 01) (prog-if 06 [)
  00:0a.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) (rev 01) (prog-if 06 [)

which are unrelated to the 00:00.0 device with the broken BAR.

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
  2019-10-24 17:11 ` [PATCH v6 01/30] PCI: Fix race condition in pci_enable/disable_device() Sergey Miroshnichenko
@ 2019-10-25 14:33   ` Carlo Pisani
  2019-10-25 16:37     ` Bjorn Helgaas
  0 siblings, 1 reply; 13+ messages in thread
From: Carlo Pisani @ 2019-10-25 14:33 UTC (permalink / raw)
  To: linux-pci, Bjorn Helgaas; +Cc: linuxppc-dev, linux

pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff]
pci_bus 0000:00: root bus resource [io  0x18800000-0x188fffff]
pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
pci 0000:00:04.0: BAR 0: assigned [mem 0x50000000-0x5000ffff]
pci 0000:00:05.0: BAR 1: assigned [mem 0x50010000-0x50010fff]
pci 0000:00:05.0: BAR 3: assigned [mem 0x50011000-0x50011fff]
pci 0000:00:0a.0: BAR 1: assigned [mem 0x50012000-0x50012fff]
pci 0000:00:0a.0: BAR 3: assigned [mem 0x50013000-0x50013fff]
pci 0000:00:02.0: BAR 0: assigned [io  0x18800000-0x188000ff]
pci 0000:00:02.0: BAR 1: assigned [mem 0x50014000-0x500140ff]
pci 0000:00:03.0: BAR 0: assigned [io  0x18800400-0x188004ff]
pci 0000:00:03.0: BAR 1: assigned [mem 0x50014100-0x500141ff]
pci 0000:00:05.0: BAR 0: assigned [io  0x18800800-0x1880081f]
pci 0000:00:05.0: BAR 2: assigned [io  0x18800820-0x1880083f]
pci 0000:00:0a.0: BAR 0: assigned [io  0x18800840-0x1880085f]
pci 0000:00:0a.0: BAR 2: assigned [io  0x18800860-0x1880087f]


00:00.0 Non-VGA unclassified device: Integrated Device Technology,
Inc. Device 0000
        Subsystem: Device 0214:011d
        Flags: bus master, 66MHz, medium devsel, latency 60, IRQ 140
        Memory at <unassigned> (32-bit, prefetchable)
        I/O ports at <ignored>
        I/O ports at <ignored>

00:02.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S
[Rhine-III] (rev 86)
        Subsystem: AST Research Inc Device 086c
        Flags: bus master, stepping, medium devsel, latency 64, IRQ 142
        I/O ports at 18800000 [size=256]
        Memory at 50014000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 2
        Kernel driver in use: via-rhine

00:03.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S
[Rhine-III] (rev 86)
        Subsystem: AST Research Inc Device 086c
        Flags: bus master, stepping, medium devsel, latency 64, IRQ 143
        I/O ports at 18800400 [size=256]
        Memory at 50014100 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] Power Management version 2
        Kernel driver in use: via-rhine

00:04.0 Network controller: Atheros Communications Inc. Device 0029 (rev 01)
        Subsystem: Atheros Communications Inc. Device 2091
        Flags: bus master, 66MHz, medium devsel, latency 168, IRQ 142
        Memory at 50000000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [44] Power Management version 2
        Kernel driver in use: ath9k

00:05.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad
16950 UART) function 0 (Uart) (rev 01) (prog-if 06 [)
        Subsystem: Oxford Semiconductor Ltd Device 0000
        Flags: medium devsel, IRQ 143
        I/O ports at 18800800 [size=32]
        Memory at 50010000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at 18800820 [size=32]
        Memory at 50011000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2
        Kernel driver in use: serial

00:05.1 Non-VGA unclassified device: Oxford Semiconductor Ltd
OX16PCI954 (Quad 16950 UART) function 0 (Disabled) (rev 01)
        Subsystem: Oxford Semiconductor Ltd Device 0000
        Flags: medium devsel, IRQ 143
        I/O ports at <unassigned> [disabled]
        I/O ports at <unassigned> [disabled]
        I/O ports at <unassigned> [disabled]
        Capabilities: [40] Power Management version 2

00:0a.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad
16950 UART) function 0 (Uart) (rev 01) (prog-if 06 [)
        Subsystem: Oxford Semiconductor Ltd Device 0000
        Flags: medium devsel, IRQ 140
        I/O ports at 18800840 [size=32]
        Memory at 50012000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at 18800860 [size=32]
        Memory at 50013000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2
        Kernel driver in use: serial

00:0a.1 Non-VGA unclassified device: Oxford Semiconductor Ltd
OX16PCI954 (Quad 16950 UART) function 0 (Disabled) (rev 01)
        Subsystem: Oxford Semiconductor Ltd Device 0000
        Flags: medium devsel, IRQ 140
        I/O ports at <unassigned> [disabled]
        I/O ports at <unassigned> [disabled]
        I/O ports at <unassigned> [disabled]
        Capabilities: [40] Power Management version 2


hi guys
I have a couple of miniPCI Oxford Semiconductor Ltd OX16PCI954 cards
installed, and the dmesg looks weird

espeially these lines
pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff]
pci_bus 0000:00: root bus resource [io  0x18800000-0x188fffff]
pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)

besides, I am experimenting crashes happening in burn-in tests, and I
do suspect it's something related to the newly added cards

any enlightenment?

^ permalink raw reply	[flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-11-04 16:30 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CA+QBN9C_o8HanAzXpDUN410g2o5+xfx64pbX3_VHVDKcj5N3kA@mail.gmail.com>
2019-10-28 17:13 ` Oxford Semiconductor Ltd OX16PCI954 - weird dmesg Bjorn Helgaas
2019-10-28 16:37   ` Carlo Pisani
2019-10-28 18:48     ` Bjorn Helgaas
2019-10-28 18:06       ` Carlo Pisani
2019-10-28 19:43         ` Bjorn Helgaas
2019-10-28 18:49           ` Carlo Pisani
2019-11-04 14:59             ` Bjorn Helgaas
2019-10-28 16:46   ` Carlo Pisani
     [not found] <CA+QBN9D4bckEZmNhLJPBmr92St1W2GGyazLGR9kANFk2cfV8Pg@mail.gmail.com>
2019-11-04 16:30 ` Bjorn Helgaas
     [not found] <CA+QBN9B4qfxpEa69TB=+MngG9bN0puwByAeGCMxk_Y7fgaKhpQ@mail.gmail.com>
2019-11-04 16:07 ` Bjorn Helgaas
     [not found] <CA+QBN9AzXHifP4=F1O1jjbGP0yNxBZeTPgPJvpcKFb9Z4f30KA@mail.gmail.com>
2019-11-04 15:58 ` Bjorn Helgaas
2019-10-24 17:11 [PATCH v6 00/30] PCI: Allow BAR movement during hotplug Sergey Miroshnichenko
2019-10-24 17:11 ` [PATCH v6 01/30] PCI: Fix race condition in pci_enable/disable_device() Sergey Miroshnichenko
2019-10-25 14:33   ` Oxford Semiconductor Ltd OX16PCI954 - weird dmesg Carlo Pisani
2019-10-25 16:37     ` Bjorn Helgaas

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.