Re: [PATCH 0/6] x86: PIRQ/ELCR-related fixes and updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Maciej,

11.09.2021 18:31, I wrote:
this new table into a small unused ROM area. All looks good:
=====
[ 0.623757] 8139too: 8139too Fast Ethernet driver 0.9.28
[ 0.623757] 8139too 0000:00:03.0: PCI INT A -> PIRQ 01, mask def8, excl
0000
[ 0.623757] 8139too 0000:00:03.0: PCI INT A -> newirq 11
[ 0.623757] PCI: setting IRQ 11 as level-triggered
=====
Dumping registers with a separate program then confirmed that settings
are correct indeed.
But I'd like to note that PIRQ values passed to pirq_finali_get/set
should better be somewhow checked for validity, as otherwise some
totally unrelated chipset registers are being unintentionally accessed.

I'm now going to test IRQ sharing.

I can confirm IRQ sharing works fine, too.
I've inserted some PCI USB addon card and added "pci=usepirqmask pci=irqmask=0x800" to force a collision, now /proc/interrups says:

11:      61350    XT-PIC      ehci_hcd:usb1, ohci_hcd:usb2, eth0

Now doing USB stick reading and ethernet benchmarking in parallel shows no problem whatsoever.

Excellent work, Maciej!


Thank you,

Regards,
Nikolai


Thank you,

Regards,
Nikolai


[ 0.630068] 8139too 0000:00:03.0: IRQ routing conflict: have IRQ 11,
want IRQ 15
[ 0.641901] 8139too 0000:00:03.0 eth0: RealTek RTL8139 at 0xc2582f00,
00:11:6b:32:85:74, IRQ 11

First, INTA is apparently routed to IRQ11 (and the network card works
just fine with that), whereas pci code wants IRQ15 for some reason.

Second, dumping chipset reg 44 shows that INTA is still set to EDGE mode
anyway, although dumping port 4D1 now shows IRQ15 was changed to LEVEL
mode, exactly as indicated in the above output. I'm not sure, but the
datasheet (page 77) seems to indicate that INTx mode set in reg 44
should match the respective IRQx mode in port 4Dx (Although the ROM BIOS
seems to only have code to change triggering mode in the 44 register and
does not care about port 4Dx whatsoever, which kinda contradicts the
datasheet)

I'll do some more digging later, but any hints are appreciated anyway.


Thank you,

Regards,
Nikolai


I'm a little busy at the moment with other stuff and may not be able to
look into it properly right now. There may be no solution, not at least
an easy one. A DMI quirk is not possible, because:

DMI not present or invalid.

There is a PCI BIOS:

PCI: PCI BIOS revision 2.10 entry at 0xf6f41, last bus=0

however, so CONFIG_PCI_BIOS just might work. Please try that too, by
choosing CONFIG_PCI_GOANY or CONFIG_PCI_GOBIOS (it may break things
horribly though I imagine).

Maciej







[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux