ath0: could not map interrupt (again?)

[Tim Chase]

On 2018-05-03 17:54, Oleksandr Tymoshenko wrote:
> Tim Chase (freebsd at tim.thechases.com) wrote:
> > ppb0 at pci0 dev 28 function 0 "Intel SCH PCIE" rev 0x07: apic 2
> > int 17 ...
> > athn0 at pci2 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2
> > int 17 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address
> > 00:24:d2:b3:8c:b4
> > 
> > so it looks like the interrupt *can* be shared, it just appears
> > that FreeBSD is doing something peculiar with it.  
> 
> It looks like PCI bridge allocates interupt without RF_SHAREABLE
> (see dev/pci/pci_pci.c, pcib_alloc_pcie_irq). Could you test
> this patch [1]? I am not sure if non-shareable IRQs for PCI/PCI
> bridge is a design decision or it's just that nobody has hit this
> problem before.
> 
> [1]
> https://people.freebsd.org/~gonzo/patches/pci_pci-shareable-irq.diff

Applying your one-line patch adding RF_SHAREABLE (sorry for the delay
as buildworld took ~2.5 days and buildkernel took about half a day on
this machine) does seem to have at least gotten past the initial
issue.  The pcib1 now looks like it's properly sharing the interrupt
and ath0 at least identifies.  Relevant excerpts from dmesg:

# dmesg | grep -e ath0 -e pcib1
pcib1: <ACPI PCI-PCI bridge> irq 17 at device 28.0 on pci0
pcib1: [GIANT-LOCKED]
pci1: <ACPI PCI bus> on pcib1
ath0: <Atheros 9280> mem 0xd8000000-0xd800ffff irq 17 at device 0.0
on pci2 ath0: [HT] enabling HT modes
ath0: [HT] 1 stream STBC receive enabled
ath0: [HT] 1 stream STBC transmit enabled
ath0: [HT] 2 RX streams; 2 TX streams
ath0: AR9280 mac 128.2 RF5133 phy 13.0
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0

This was performed against HEAD which, at the time, was r333254.

I'll poke at it more thoroughly in the morning, but I wanted to let
you know that it seems to be working thus far.

If you know of any particular ways in which I should stress it (to
see if IRQ 17 on pcib1 really *wasn't* supposed to be sharable), I'd
be glad to abuse it a bit.

Many thanks!

-tim