* 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 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 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 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 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 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: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 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
[parent not found: <CA+QBN9D4bckEZmNhLJPBmr92St1W2GGyazLGR9kANFk2cfV8Pg@mail.gmail.com>]
* 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
[parent not found: <CA+QBN9B4qfxpEa69TB=+MngG9bN0puwByAeGCMxk_Y7fgaKhpQ@mail.gmail.com>]
* 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
[parent not found: <CA+QBN9AzXHifP4=F1O1jjbGP0yNxBZeTPgPJvpcKFb9Z4f30KA@mail.gmail.com>]
* 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
* [PATCH v6 00/30] PCI: Allow BAR movement during hotplug @ 2019-10-24 17:11 Sergey Miroshnichenko 2019-10-24 17:11 ` [PATCH v6 01/30] PCI: Fix race condition in pci_enable/disable_device() Sergey Miroshnichenko 0 siblings, 1 reply; 13+ messages in thread From: Sergey Miroshnichenko @ 2019-10-24 17:11 UTC (permalink / raw) To: linux-pci, linuxppc-dev; +Cc: Bjorn Helgaas, linux, Sergey Miroshnichenko Currently PCI hotplug works on top of resources, which are usually reserved not by the kernel, but by BIOS, bootloader, firmware, etc. These resources are gaps in the address space where BARs of new devices may fit, and extra bus number per port, so bridges can be hot-added. This series aim the former problem: it shows the kernel how to redistribute on the run, so the hotplug becomes predictable and cross-platform. A follow-up patchset will propose a solution for bus numbers. If the memory is arranged in a way that doesn't provide enough space for BARs of a new hotplugged device, the kernel can pause the drivers of the "obstructing" devices and move their BARs, so the new BARs can fit into the freed spaces. To rearrange the BARs and bridge windows these patches releases all of them after a rescan and re-assigns in the same way as during the initial PCIe topology scan at system boot. When a driver is un-paused by the kernel after the PCIe rescan, it should ioremap() the new addresses of its BARs. Drivers indicate their support of the feature by implementing the new hooks .rescan_prepare() and .rescan_done() in the struct pci_driver. If a driver doesn't yet support the feature, BARs of its devices will be considered as immovable (by checking the pci_dev_movable_bars_supported(dev)) and handled in the same way as resources with the IORESOURCE_PCI_FIXED flag. If a driver doesn't yet support the feature, its devices are guaranteed to have their BARs remaining untouched. Tested on: - x86_64 with "pci=pcie_bus_peer2peer" - POWER8 PowerNV+OPAL+PHB3 ppc64le with "pci=pcie_bus_peer2peer". This patchset is a part of our work on adding support for hotplugging bridges full of other bridges, NVME drives, SAS HBAs and GPUs without special requirements such as Hot-Plug Controller, reservation of bus numbers or memory regions by firmware, etc. Changes since v5: - Simplified the disable flag, now it is "pci=no_movable_buses"; - More deliberate marking the BARs as immovable; - Mark as immovable BARs which are used by unbound drivers; - Ignoring BAR assignment by non-kernel program components, so the kernel is able now to distribute BARs in optimal and predictable way; - Move here PowerNV-specific patches from the older "powerpc/powernv/pci: Make hotplug self-sufficient, independent of FW and DT" series; - Fix EEH cache rebuilding and PE allocation for PowerNV during rescan. Changes since v4: - Feature is enabled by default (turned on by one of the latest patches); - Add pci_dev_movable_bars_supported(dev) instead of marking the immovable BARs with the IORESOURCE_PCI_FIXED flag; - Set up PCIe bridges during rescan via sysfs, so MPS settings are now configured not only during system boot or pcihp events; - Allow movement of switch's BARs if claimed by portdrv; - Update EEH address caches after rescan for powerpc; - Don't disable completely hot-added devices which can't have BARs being fit - just disable their BARs, so they are still visible in lspci etc; - Clearer names: fixed_range_hard -> immovable_range, fixed_range_soft -> realloc_range; - Drop the patch for pci_restore_config_space() - fixed by properly using the runtime PM. Changes since v3: - Rebased to the upstream, so the patches apply cleanly again. Changes since v2: - Fixed double-assignment of bridge windows; - Fixed assignment of fixed prefetched resources; - Fixed releasing of fixed resources; - Fixed a debug message; - Removed auto-enabling the movable BARs for x86 - let's rely on the "pcie_movable_bars=force" option for now; - Reordered the patches - bugfixes first. Changes since v1: - Add a "pcie_movable_bars={ off | force }" command line argument; - Handle the IORESOURCE_PCI_FIXED flag properly; - Don't move BARs of devices which don't support the feature; - Guarantee that new hotplugged devices will not steal memory from working devices by ignoring the failing new devices with the new PCI_DEV_IGNORE flag; - Add rescan_prepare()+rescan_done() to the struct pci_driver instead of using the reset_prepare()+reset_done() from struct pci_error_handlers; - Add a bugfix of a race condition; - Fixed hotplug in a non-pre-enabled (by BIOS/firmware) bridge; - Fix the compatibility of the feature with pm_runtime and D3-state; - Hotplug events from pciehp also can move BARs; - Add support of the feature to the NVME driver. Sergey Miroshnichenko (30): PCI: Fix race condition in pci_enable/disable_device() PCI: Enable bridge's I/O and MEM access for hotplugged devices PCI: hotplug: Add a flag for the movable BARs feature PCI: Define PCI-specific version of the release_child_resources() PCI: hotplug: movable BARs: Fix reassigning the released bridge windows PCI: hotplug: movable BARs: Recalculate all bridge windows during rescan PCI: hotplug: movable BARs: Don't disable the released bridge windows PCI: hotplug: movable BARs: Don't allow added devices to steal resources PCI: Include fixed and immovable BARs into the bus size calculating PCI: Prohibit assigning BARs and bridge windows to non-direct parents PCI: hotplug: movable BARs: Try to assign unassigned resources only once PCI: hotplug: movable BARs: Calculate immovable parts of bridge windows PCI: hotplug: movable BARs: Compute limits for relocated bridge windows PCI: Make sure bridge windows include their fixed BARs PCI: Fix assigning the fixed prefetchable resources PCI: hotplug: movable BARs: Assign fixed and immovable BARs before others PCI: hotplug: movable BARs: Don't reserve IO/mem bus space PCI: hotplug: Configure MPS for hot-added bridges during bus rescan PCI: hotplug: movable BARs: Ignore the MEM BAR offsets from bootloader powerpc/pci: Fix crash with enabled movable BARs powerpc/pci: Access PCI config space directly w/o pci_dn powerpc/pci: Create pci_dn on demand powerpc/pci: hotplug: Add support for movable BARs powerpc/powernv/pci: Suppress an EEH error when reading an empty slot PNP: Don't reserve BARs for PCI when enabled movable BARs PCI: hotplug: movable BARs: Enable the feature by default nvme-pci: Handle movable BARs PCI/portdrv: Declare support of movable BARs PCI: pciehp: movable BARs: Trigger a domain rescan on hp events Revert "powerpc/powernv/pci: Work around races in PCI bridge enabling" .../admin-guide/kernel-parameters.txt | 1 + arch/powerpc/kernel/pci-hotplug.c | 43 +++ arch/powerpc/kernel/pci_dn.c | 88 ++++- arch/powerpc/kernel/rtas_pci.c | 97 ++++-- arch/powerpc/platforms/powernv/pci-ioda.c | 40 +-- arch/powerpc/platforms/powernv/pci.c | 73 ++-- arch/powerpc/platforms/pseries/setup.c | 2 + drivers/nvme/host/pci.c | 21 +- drivers/pci/bus.c | 2 +- drivers/pci/hotplug/pciehp_pci.c | 5 + drivers/pci/pci.c | 38 ++- drivers/pci/pci.h | 30 ++ drivers/pci/pcie/portdrv_pci.c | 11 + drivers/pci/probe.c | 315 +++++++++++++++++- drivers/pci/setup-bus.c | 277 +++++++++++++-- drivers/pci/setup-res.c | 50 ++- drivers/pnp/system.c | 4 + include/linux/pci.h | 21 ++ 18 files changed, 965 insertions(+), 153 deletions(-) -- 2.23.0 ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH v6 01/30] PCI: Fix race condition in pci_enable/disable_device() 2019-10-24 17:11 [PATCH v6 00/30] PCI: Allow BAR movement during hotplug Sergey Miroshnichenko @ 2019-10-24 17:11 ` Sergey Miroshnichenko 2019-10-25 14:33 ` Oxford Semiconductor Ltd OX16PCI954 - weird dmesg Carlo Pisani 0 siblings, 1 reply; 13+ messages in thread From: Sergey Miroshnichenko @ 2019-10-24 17:11 UTC (permalink / raw) To: linux-pci, linuxppc-dev Cc: Bjorn Helgaas, linux, Sergey Miroshnichenko, Srinath Mannam, Marta Rybczynska This is a yet another approach to fix an old [1-2] concurrency issue, when: - two or more devices are being hot-added into a bridge which was initially empty; - a bridge with two or more devices is being hot-added; - during boot, if BIOS/bootloader/firmware doesn't pre-enable bridges. The problem is that a bridge is reported as enabled before the MEM/IO bits are actually written to the PCI_COMMAND register, so another driver thread starts memory requests through the not-yet-enabled bridge: CPU0 CPU1 pci_enable_device_mem() pci_enable_device_mem() pci_enable_bridge() pci_enable_bridge() pci_is_enabled() return false; atomic_inc_return(enable_cnt) Start actual enabling the bridge ... pci_is_enabled() ... return true; ... Start memory requests <-- FAIL ... Set the PCI_COMMAND_MEMORY bit <-- Must wait for this Protect the pci_enable/disable_device() and pci_enable_bridge(), which is similar to the previous solution from commit 40f11adc7cd9 ("PCI: Avoid race while enabling upstream bridges"), but adding a per-device mutexes and preventing the dev->enable_cnt from from incrementing early. CC: Srinath Mannam <srinath.mannam@broadcom.com> CC: Marta Rybczynska <mrybczyn@kalray.eu> Signed-off-by: Sergey Miroshnichenko <s.miroshnichenko@yadro.com> [1] https://lore.kernel.org/linux-pci/1501858648-22228-1-git-send-email-srinath.mannam@broadcom.com/T/#u [RFC PATCH v3] pci: Concurrency issue during pci enable bridge [2] https://lore.kernel.org/linux-pci/744877924.5841545.1521630049567.JavaMail.zimbra@kalray.eu/T/#u [RFC PATCH] nvme: avoid race-conditions when enabling devices --- drivers/pci/pci.c | 26 ++++++++++++++++++++++---- drivers/pci/probe.c | 1 + include/linux/pci.h | 1 + 3 files changed, 24 insertions(+), 4 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index a97e2571a527..44d0d12c80cf 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -1643,6 +1643,8 @@ static void pci_enable_bridge(struct pci_dev *dev) struct pci_dev *bridge; int retval; + mutex_lock(&dev->enable_mutex); + bridge = pci_upstream_bridge(dev); if (bridge) pci_enable_bridge(bridge); @@ -1650,6 +1652,7 @@ static void pci_enable_bridge(struct pci_dev *dev) if (pci_is_enabled(dev)) { if (!dev->is_busmaster) pci_set_master(dev); + mutex_unlock(&dev->enable_mutex); return; } @@ -1658,11 +1661,14 @@ static void pci_enable_bridge(struct pci_dev *dev) pci_err(dev, "Error enabling bridge (%d), continuing\n", retval); pci_set_master(dev); + mutex_unlock(&dev->enable_mutex); } static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags) { struct pci_dev *bridge; + /* Enable-locking of bridges is performed within the pci_enable_bridge() */ + bool need_lock = !dev->subordinate; int err; int i, bars = 0; @@ -1678,8 +1684,13 @@ static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags) dev->current_state = (pmcsr & PCI_PM_CTRL_STATE_MASK); } - if (atomic_inc_return(&dev->enable_cnt) > 1) + if (need_lock) + mutex_lock(&dev->enable_mutex); + if (pci_is_enabled(dev)) { + if (need_lock) + mutex_unlock(&dev->enable_mutex); return 0; /* already enabled */ + } bridge = pci_upstream_bridge(dev); if (bridge) @@ -1694,8 +1705,10 @@ static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags) bars |= (1 << i); err = do_pci_enable_device(dev, bars); - if (err < 0) - atomic_dec(&dev->enable_cnt); + if (err >= 0) + atomic_inc(&dev->enable_cnt); + if (need_lock) + mutex_unlock(&dev->enable_mutex); return err; } @@ -1939,15 +1952,20 @@ void pci_disable_device(struct pci_dev *dev) if (dr) dr->enabled = 0; + mutex_lock(&dev->enable_mutex); dev_WARN_ONCE(&dev->dev, atomic_read(&dev->enable_cnt) <= 0, "disabling already-disabled device"); - if (atomic_dec_return(&dev->enable_cnt) != 0) + if (atomic_dec_return(&dev->enable_cnt) != 0) { + mutex_unlock(&dev->enable_mutex); return; + } do_pci_disable_device(dev); dev->is_busmaster = 0; + + mutex_unlock(&dev->enable_mutex); } EXPORT_SYMBOL(pci_disable_device); diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 3d5271a7a849..d4f21e413638 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -2158,6 +2158,7 @@ struct pci_dev *pci_alloc_dev(struct pci_bus *bus) INIT_LIST_HEAD(&dev->bus_list); dev->dev.type = &pci_dev_type; dev->bus = pci_bus_get(bus); + mutex_init(&dev->enable_mutex); return dev; } diff --git a/include/linux/pci.h b/include/linux/pci.h index f9088c89a534..525140e3a460 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -425,6 +425,7 @@ struct pci_dev { unsigned int no_vf_scan:1; /* Don't scan for VFs after IOV enablement */ pci_dev_flags_t dev_flags; atomic_t enable_cnt; /* pci_enable_device has been called */ + struct mutex enable_mutex; u32 saved_config_space[16]; /* Config space saved at suspend time */ struct hlist_head saved_cap_space; -- 2.23.0 ^ permalink raw reply related [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
* 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
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 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).