Hi Frode,
On Mon, Jan 29, 2018 at 05:06:39PM +0100, Frode Tennebø wrote:
> Hi.
>
> I'm porting an application to a new (to us) VME CPU board, a Kontron
> VM6050. Due to a legacy cPCI driver I'm stuck with SuSE 10 SP1 with
> kernel 2.6.16.46 at the moment. However, my current problem is with a
> PCI-VME bridge driver for this card.
2.6.16 was released Sun Mar 19 21:53:43 2006. I would like to be able
to help you out, but I don't think it's really practical to spend much
time supporting something that old.
> The manufacturer has provided us with a live Fedora 16 CD with kernel
> 3.4.9, which is functioning, and source code for the PCI-VME bridge
> driver. The controller is called ALMA and is a proprietary FPGA
> implementation by Kontron. On that Live CD everything seems to work
> as expected for the ALMA driver:
>
> > cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> 0: 172 0 0 0 IO-APIC-edge timer
> 4: 581 545 564 551 IO-APIC-edge serial
> 6: 39 38 38 38 IO-APIC-edge cpld_i2c
> 7: 48 0 0 0 IO-APIC-edge
> 8: 1 0 0 0 IO-APIC-edge rtc0
> 9: 5 3 5 3 IO-APIC-fasteoi acpi
> 12: 0 0 0 0 IO-APIC-edge cpld-gpio
> 16: 620 260 424 268 IO-APIC-fasteoi
> ehci_hcd:usb1, ioc0
> 18: 0 0 0 0 IO-APIC-fasteoi
> ata_generic
> 19: 0 0 0 0 IO-APIC-fasteoi
> ata_piix, ata_piix, Alma_ITA
> 23: 1317 8598 1326 8713 IO-APIC-fasteoi
> ehci_hcd:usb2
> 42: 224 219 225 224 PCI-MSI-edge
> i915
> 43: 0 0 1 0 PCI-MSI-edge
> 44: 3 68 62 4 PCI-MSI-edge
> 45: 1 5 52 2 PCI-MSI-edge
> 46: 47 6 5 2 PCI-MSI-edge
> 47: 2 7 16 35 PCI-MSI-edge
> 48: 0 2 2 57 PCI-MSI-edge
> 49: 18 41 5 5 PCI-MSI-edge
> 50: 2 3 2 80 PCI-MSI-edge
> 51: 2 2 1 55 PCI-MSI-edge
> 52: 1 0 0 0 PCI-MSI-edge
> p4p2
> 53: 86 167 853 73 PCI-MSI-edge
> p4p2-rx-0
> 54: 172 15 191 7 PCI-MSI-edge
> p4p2-rx-1
> 55: 11 59 763 134 PCI-MSI-edge
> p4p2-rx-2
> 56: 43 15 150 108 PCI-MSI-edge
> p4p2-rx-3
> 57: 252 92 492 0 PCI-MSI-edge
> p4p2-tx-0
> 58: 27 45 143 118 PCI-MSI-edge
> p4p2-tx-1
> 59: 100 47 134 42 PCI-MSI-edge
> p4p2-tx-2
> 60: 101 42 161 12 PCI-MSI-edge
> p4p2-tx-3
> NMI: 10 8 6 6 Non-maskable
> interrupts
> LOC: 25228 26594 20740 19765 Local timer
> interrupts
> SPU: 0 0 0 0 Spurious interrupts
> PMI: 10 8 6 6 Performance
> monitoring interrupts
> IWI: 0 0 0 0 IRQ work interrupts
> RTR: 1 0 0 0 APIC ICR read
> retries
> RES: 8923 4259 1501 1055 Rescheduling
> interrupts
> CAL: 298 297 221 258 Function call interrupts
> TLB: 393 282 546 260 TLB shootdowns
> TRM: 0 0 0 0 Thermal event interrupts
> THR: 0 0 0 0 Threshold APIC interrupts
> MCE: 0 0 0 0 Machine check exceptions
> MCP: 5 5 5 5 Machine check polls
> ERR: 48
> MIS: 0
>
> > lspci -vv
> :
> 7:09.0 Bridge: Kontron Device 9035 (rev 45)
> Subsystem: Kontron Device 0000
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 128
> Interrupt: pin A routed to IRQ 19
> Region 0: Memory at f0000000 (32-bit, non-prefetchable) [size=1M]
> Region 1: Memory at e8000000 (32-bit, non-prefetchable) [size=128M]
> Capabilities: [78] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> Kernel driver in use: ALMA
> Kernel modules: almavme
>
> > ls -l /dev/almavme
> crw------- 1 root root 221, 0 Jan 29 18:27 /dev/almavme
>
>
> For SuSE 10.1/kernel 2.6.16.46, when I load the module everything
> looks fine (including the pci-stuff) up to calling request_irq() which
> returns -ENOSYS (-38). The code which does this is in setup_irq():
>
> if (desc->handler == &no_irq_type)
> return -ENOSYS;
>
> no_irq_type is assigned in kernel/irq/handler.c:
>
> irq_desc_t irq_desc[NR_IRQS] __cacheline_aligned = {
> [0 ... NR_IRQS-1] = {
> .status = IRQ_DISABLED,
> .handler = &no_irq_type,
> .lock = SPIN_LOCK_UNLOCKED
> }
> };
>
> > cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> 0: 189 0 18127 0 IO-APIC-edge timer
> 4: 544 0 0 0 IO-APIC-edge serial
> 8: 0 0 10 0 IO-APIC-edge rtc
> 9: 0 8 0 0 IO-APIC-level acpi
> 58: 1 0 0 0 PCI-MSI-X eth0
> 66: 1108 0 0 0 PCI-MSI-X eth0-TxRx-0
> 82: 1 0 0 0 PCI-MSI-X eth1
> 90: 441 0 0 0 PCI-MSI-X eth1-TxRx-0
> 130: 817 0 0 0 IO-APIC-level ehci_hcd:usb2
> 169: 3761 0 0 0 IO-APIC-level
> ioc0, ehci_hcd:usb1
> NMI: 0 0 0 0
> LOC: 18117 18149 18135 18137
> ERR: 173
> MIS: 0
>
> IRQ 19 is not listed in /proc/interrupts.
>
> > lspci -vv
> 07:09.0 Bridge: Teknor Industrial Computers Inc Unknown device 9035 (rev 45)
> Subsystem: Teknor Industrial Computers Inc Unknown device 0000
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr+ Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 128
> Interrupt: pin A routed to IRQ 19
> Region 0: Memory at f0000000 (32-bit, non-prefetchable) [size=1M]
> Region 1: Memory at e8000000 (32-bit, non-prefetchable) [size=128M]
> Capabilities: [78] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
> Hence it looks to me that it boils down to the handlers not being
> initialised. Is the APIC sub-system not detecting the correct trigger
> in arch/i386/kernel/io_apic.c:ioapic_register_intr()? This was
> simplified/made more robust in 2.6.18. Can anything be done to force
> the correct handler? (The Fedora Live CD classify it as
> IO-APIC-fasteoi, which 2.6.16 does not have. Can I assume edge type?)
>
> Apart from the kernel difference, the only other difference is that
> the Fedora live CD is 64 bit while we are running an i586 smp version.
>
> Regards,
> -Frode
