Re: ath0: could not map interrupt (again?)

[Adrian Chadd]

And Tim - is this really mini-pci? or is it mini-pcie? (can you take a
photo? :-)



-a

On Mon, 21 May 2018 at 13:34, Adrian Chadd  wrote:

> hi,

> warner says "pcie interrupts aren't shared." :-)

> So why is this working? You're saying this is a mini-pci slot?

> Would you please file a PR so we can get some more eyeballs on this?
thanks!


> -adrian
> On Mon, 21 May 2018 at 12:55, Tim Chase  wrote:

> > I've been using this for a couple weeks now with no issues, for what
> > little value my OK is, your patch seems to be ready to roll.

> > -tim

> > On 2018-05-06 20:16, Tim Chase wrote:
> > > On 2018-05-03 17:54, Oleksandr Tymoshenko wrote:
> > > > Tim Chase (free...@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:  irq 17 at device 28.0 on pci0
> > > pcib1: [GIANT-LOCKED]
> > > pci1:  on pcib1
> > > ath0:  mem 0xd800-0xd800 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: 0x; 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
> > >
> > >
> > >
> > >


> > ___
> > freebsd-wireless@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> > To unsubscribe, send any mail to "
freebsd-wireless-unsubscr...@freebsd.org
> "
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: ath0: could not map interrupt (again?)

[Adrian Chadd]

hi,

warner says "pcie interrupts aren't shared." :-)

So why is this working? You're saying this is a mini-pci slot?

Would you please file a PR so we can get some more eyeballs on this? thanks!


-adrian
On Mon, 21 May 2018 at 12:55, Tim Chase  wrote:

> I've been using this for a couple weeks now with no issues, for what
> little value my OK is, your patch seems to be ready to roll.

> -tim

> On 2018-05-06 20:16, Tim Chase wrote:
> > On 2018-05-03 17:54, Oleksandr Tymoshenko wrote:
> > > Tim Chase (free...@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:  irq 17 at device 28.0 on pci0
> > pcib1: [GIANT-LOCKED]
> > pci1:  on pcib1
> > ath0:  mem 0xd800-0xd800 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: 0x; 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
> >
> >
> >
> >


> ___
> freebsd-wireless@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org
"
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: ath0: could not map interrupt (again?)

[Tim Chase]

I've been using this for a couple weeks now with no issues, for what
little value my OK is, your patch seems to be ready to roll.

-tim

On 2018-05-06 20:16, Tim Chase wrote:
> On 2018-05-03 17:54, Oleksandr Tymoshenko wrote:
> > Tim Chase (free...@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:  irq 17 at device 28.0 on pci0
> pcib1: [GIANT-LOCKED]
> pci1:  on pcib1
> ath0:  mem 0xd800-0xd800 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: 0x; 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
> 
> 
> 
> 


___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: ath0: could not map interrupt (again?)

[Tim Chase]

On 2018-05-03 17:54, Oleksandr Tymoshenko wrote:
> Tim Chase (free...@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:  irq 17 at device 28.0 on pci0
pcib1: [GIANT-LOCKED]
pci1:  on pcib1
ath0:  mem 0xd800-0xd800 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: 0x; 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




___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: ath0: could not map interrupt (again?)

[Tim Chase]

On 2018-05-03 17:54, Oleksandr Tymoshenko wrote:
> Tim Chase (free...@tim.thechases.com) wrote:
> > If it makes any difference, booting OpenBSD 6.3 on the machine
> > says they're both successfully on INT 17 (the ath0/athn0 works
> > there)
> > 
> > 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

Updated to head, applied the patch and am building world/kernel now.
With this underpowered machine, I suspect it may take a while.  Just
wanted to let you know your suggestion didn't drop into the void
ignored.

-tim



___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: ath0: could not map interrupt (again?)

[Tim Chase]

On 2018-05-04 00:33, Adrian Chadd wrote:
> Yeah it does look like that. I'm sorry, I don't have the
> time/energy to figure out why allocating that interrupt doesn't
> work on FreeBSD. :(

If this is more of an interrupt/kernel thing than a wifi thing, would
this be better moved to a different freebsd-*@ mailing-list?

Perhaps freebsd-drivers@ ?

-tim



___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: ath0: could not map interrupt (again?)

[Adrian Chadd]

Hi,

Yeah it does look like that. I'm sorry, I don't have the time/energy to
figure out why allocating that interrupt doesn't work on FreeBSD. :(



-adrian

On Thu, 3 May 2018 at 17:28, Tim Chase  wrote:

> On 2018-05-02 21:10, Tim Chase wrote:
> > On 2018-05-02 23:21, Adrian Chadd wrote:
> > > CAn you try booting freebsd-head and see if it's any better?
> >
> > At your advice, I created a boot image of 12.0-CURRENT r333017 but
> > see the same  "could not map interrupt" in my dmesg that I got on
> > 11.x

> If it makes any difference, booting OpenBSD 6.3 on the machine says
> they're both successfully on INT 17 (the ath0/athn0 works there)

> 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.

> -tim



> ___
> freebsd-wireless@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org
"
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: ath0: could not map interrupt (again?)

[Tim Chase]

On 2018-05-02 21:10, Tim Chase wrote:
> On 2018-05-02 23:21, Adrian Chadd wrote:
> > CAn you try booting freebsd-head and see if it's any better?  
> 
> At your advice, I created a boot image of 12.0-CURRENT r333017 but
> see the same  "could not map interrupt" in my dmesg that I got on
> 11.x

If it makes any difference, booting OpenBSD 6.3 on the machine says
they're both successfully on INT 17 (the ath0/athn0 works there)

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.

-tim



___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: ath0: could not map interrupt (again?)

[Tim Chase]

On 2018-05-02 23:21, Adrian Chadd wrote:
> CAn you try booting freebsd-head and see if it's any better?

At your advice, I created a boot image of 12.0-CURRENT r333017 but
see the same  "could not map interrupt" in my dmesg that I got on 11.x

-tim

PS: thanks for the boot-from-a-memstick-snapshot suggestion...much
faster than the svn+buildworld+buildkernel I'd been trying.
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: ath0: could not map interrupt (again?)

[Adrian Chadd]

Hi!

I'm not sure. It should be able to map it as a shared interrupt because
plenty of things could be downstream of that using a legacy interrupt. I
wonder if it's being mapped as a shared interrupt.

CAn you try booting freebsd-head and see if it's any better?


-adrian
___
freebsd-wireless@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Re: ath0: could not map interrupt

[Adrian Chadd]

On 4 January 2013 11:24, Monthadar Al Jaberi montha...@gmail.com wrote:
 On Fri, Jan 4, 2013 at 8:13 PM, Adrian Chadd adr...@freebsd.org wrote:
 Ok. The magic you need to try hacking is in ar71xx_pci.c. There's the
 7 PCI windows and the 3 interrupt lines that are configured.

 The IRQ only gets unmasked when a slot claims it as a resource. So
 you'll have to fiddle with that mapping a little.

 Look at ar71xx_pci_route_interrupt().  Maybe set it up so
 AR71XX_PCI_BASE_SLOT is 18 instead of 17?

 Works!!! :D

Hah! Nice!

 The slot is not the issue I think. The code seems to iterate through a
 couple, and when one fails it just checks the other. What it seems is
 wrong is that the interrupts are mapped wrong.
 Linux assigned IRQ 0 to slot 18, while FreeBSD assignes IRQ 1. We need
 a mapping just like openwrt. Code re-write? :D

 We need this: Slot 18 IRQ 0, Slot 19 IRQ 1, Slot 20 IRQ 2

 I don't know really what slots are physcially. Does the PCI bridge
 have many slots (ports)?

It's .. slightly more screwed up than that. Well, kind of.

You need to read up on a PCI bus primer to understand how it works.
Remember, the hardware design tries to minimise the amount of custom
hardware logic that you need - so the whole notion of PCI slots here
is really just a set of bits in the upper part of the 32 bit physical
address space.

The interrupt lines are fixed - there's what, three of them that come
off the AR71XX CPU (AR71XX_PCI_INTR_STATUS and AR71XX_PCI_INTR_MASK)
and get wired to individual physical slots. I think we only get one
wired to INTA on each physical slot.

So yes, it depends upon how they've wired up the board. It sounds like
mikroik wired slot 18 (which is just a specific combination of high
address pins) to INT0, slot 19 to INT1, slot 20 to INT2. Whereas
the PB42 and Ubiquiti hardware wires it starting at slot 17.

Look at ar71xx_pci_make_addr() to see what the slot/func/bus/etc
mapping to physical 32 bit address is.

Note there's also a PCI window register set that maps the 32 bit
physical addresses for each PCI slot to a KSEG space address that MIPS
code can get at.

So now that we've figured that out, please create a PR with the
description of the problem and the solution, and we'll have to figure
out the right way to teach the PCI glue code about this.
Chances are we can just create a PCI bus hint that defaults to 17
that says where the slots start at. Then for the Mikrotik board we can
start it at 18.


Adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org

Re: ath0: could not map interrupt

[Monthadar Al Jaberi]

Hi,

I am wondering if anyone can confirm that any ath5k (preferably
AR5413) series miniPCI wifi works on RB433/AH/UAH.

Thank you in advance

On Wed, Jan 2, 2013 at 10:29 PM, Monthadar Al Jaberi
montha...@gmail.com wrote:
 On Wed, Jan 2, 2013 at 9:43 PM, Adrian Chadd adr...@freebsd.org wrote:
 ... sounds like a definite interrupt routing issue.

 Who's been knee deep in the interrupt handling code in MIPS lately? Grrr.
 I know there's been some FDT work in MIPS and that's touched some
 interrupt code.. maybe that's interfering?

 I am not sure, I just re-compiled my kernel for RSPRO and it seems to work.

 I install openwrt on rb433ah and ath0 associated ok. and I could ping
 between RSPRO(FreeBSD) and RB433AH(Openwrt). RSPRO and non working
 RB433AH  running same kernel r243866.

 Attached is my kernel config  hints. ( I am playing around with the
 ar71xx_spi but that should not effect the pci code, I hope).

 #
 # AR71XX -- Kernel configuration file for FreeBSD/MIPS for Atheros 71xx 
 systems
 #
 # This includes all the common drivers for the AR71XX boards along with
 # the usb, net80211 and atheros driver code.
 #
 # $FreeBSD$
 #

 machine mips mips
 ident   RB433AH_MFS
 cpu CPU_MIPS4KC
 makeoptions KERNLOADADDR=0x8005
 options HZ=1000
 options HWPMC_HOOKS

 files   ../atheros/files.ar71xx

 # For now, hints are per-board.

 hints   RB433AH.hints

 makeoptions DEBUG=-g#Build kernel with gdb(1) debug 
 symbols

 # Build these as modules so small platform builds will have the
 # modules already built.
 makeoptions MODULES_OVERRIDE=random gpio ar71xx if_gif if_gre
 if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip
 wlan_ccmp wlan_rssadapt wlan_amrr ath ath_pci

 options DDB
 options KDB

 options SCHED_4BSD  #4BSD scheduler
 options INET#InterNETworking
 #optionsINET6   # IPv6

 # options   NFS_CL  #Network Filesystem Client

 options PSEUDOFS#Pseudo-filesystem framework
 options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time 
 extensions

 # options   NFS_LEGACYRPC
 # Debugging for use in -current
 options INVARIANTS
 options INVARIANT_SUPPORT
 options WITNESS
 options WITNESS_SKIPSPIN
 options DEBUG_REDZONE
 options DEBUG_MEMGUARD

 options FFS #Berkeley Fast Filesystem
 # options SOFTUPDATES #Enable FFS soft updates support
 # options UFS_ACL #Support for access control lists
 # options UFS_DIRHASH #Improve performance on big
 directories
 # options   MSDOSFS # Read MSDOS filesystems; 
 useful for USB/CF

 device  pci
 device  ar71xx_pci

 # RTC - requires hackery in the spibus code to work
 device  pcf2123_rtc

 # GEOM modules
 device  geom_redboot# to get access to the SPI flash partitions
 device  geom_uzip   # compressed in-memory filesystem hackery!
 device  geom_map
 options GEOM_UZIP

 # NANDFS
 options NANDFS

 ## Boot from the first MFS uzip
 #optionsROOTDEVNAME=\ufs:md0.uzip\
 #optionsMD_ROOT
 #optionsMD_ROOT_SIZE=9000

 # Boot from NFS
 options NFSLOCKD#Network Lock Manager
 options NFSCLIENT   #Network Filesystem Client
 options NFS_ROOT

 options BOOTP
 options BOOTP_NFSROOT
 options BOOTP_NFSV3
 options BOOTP_WIRED_TO=arge1
 options BOOTP_COMPAT
 options ROOTDEVNAME=\nfs:172.16.0.101:/usr/obj/rb433ah/nfs\


 # 802.11 framework
 options IEEE80211_DEBUG
 options IEEE80211_ALQ
 options IEEE80211_SUPPORT_MESH
 # This option is currently broken for if_ath_tx.
 options IEEE80211_SUPPORT_TDMA
 options IEEE80211_AMPDU_AGE
 device  wlan# 802.11 support
 device  wlan_wep# 802.11 WEP support
 device  wlan_ccmp   # 802.11 CCMP support
 device  wlan_tkip   # 802.11 TKIP support
 device  wlan_xauth  # 802.11 hostap support
 device  wlan_acl# 802.11 ACL support

 # Atheros wireless NICs
 device  ath # Atheros interface support
 device  ath_pci # Atheros PCI/Cardbus bus
 options ATH_DEBUG
 options ATH_DIAGAPI
 options ATH_ENABLE_11N
 options AH_DEBUG
 options AH_DEBUG_ALQ
 options ALQ
 device  ath_hal
 option  AH_SUPPORT_AR5416
 device  ath_rate_sample
 option  AH_RXCFG_SDMAMW_4BYTES
 option  AH_AR5416_INTERRUPT_MITIGATION
 # There's no DFS radar detection support yet so this won't actually
 # detect 

Re: ath0: could not map interrupt

[Monthadar Al Jaberi]

Maybe this is the root of the problem.

On RSPRO the PCI start slot enumerating from 17. While RB433AH start
from 18. That can explain why Slot 20 of RB433AH won't even attach
(AR7161 only has 3 slots, slot 17 to 19). That can also explain why I
get device_timeout on slot 18 and 19 cause they are miss aligned. And
don't see any interrupts from ath(4) when enabling interrupt
debugging.

I will keep digging into why they won't start enumerating correct.

br,

On Fri, Jan 4, 2013 at 2:28 AM, Monthadar Al Jaberi montha...@gmail.com wrote:
 Hi,

 I am wondering if anyone can confirm that any ath5k (preferably
 AR5413) series miniPCI wifi works on RB433/AH/UAH.

 Thank you in advance

 On Wed, Jan 2, 2013 at 10:29 PM, Monthadar Al Jaberi
 montha...@gmail.com wrote:
 On Wed, Jan 2, 2013 at 9:43 PM, Adrian Chadd adr...@freebsd.org wrote:
 ... sounds like a definite interrupt routing issue.

 Who's been knee deep in the interrupt handling code in MIPS lately? Grrr.
 I know there's been some FDT work in MIPS and that's touched some
 interrupt code.. maybe that's interfering?

 I am not sure, I just re-compiled my kernel for RSPRO and it seems to work.

 I install openwrt on rb433ah and ath0 associated ok. and I could ping
 between RSPRO(FreeBSD) and RB433AH(Openwrt). RSPRO and non working
 RB433AH  running same kernel r243866.

 Attached is my kernel config  hints. ( I am playing around with the
 ar71xx_spi but that should not effect the pci code, I hope).

 #
 # AR71XX -- Kernel configuration file for FreeBSD/MIPS for Atheros 71xx 
 systems
 #
 # This includes all the common drivers for the AR71XX boards along with
 # the usb, net80211 and atheros driver code.
 #
 # $FreeBSD$
 #

 machine mips mips
 ident   RB433AH_MFS
 cpu CPU_MIPS4KC
 makeoptions KERNLOADADDR=0x8005
 options HZ=1000
 options HWPMC_HOOKS

 files   ../atheros/files.ar71xx

 # For now, hints are per-board.

 hints   RB433AH.hints

 makeoptions DEBUG=-g#Build kernel with gdb(1) debug 
 symbols

 # Build these as modules so small platform builds will have the
 # modules already built.
 makeoptions MODULES_OVERRIDE=random gpio ar71xx if_gif if_gre
 if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip
 wlan_ccmp wlan_rssadapt wlan_amrr ath ath_pci

 options DDB
 options KDB

 options SCHED_4BSD  #4BSD scheduler
 options INET#InterNETworking
 #optionsINET6   # IPv6

 # options   NFS_CL  #Network Filesystem Client

 options PSEUDOFS#Pseudo-filesystem framework
 options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time 
 extensions

 # options   NFS_LEGACYRPC
 # Debugging for use in -current
 options INVARIANTS
 options INVARIANT_SUPPORT
 options WITNESS
 options WITNESS_SKIPSPIN
 options DEBUG_REDZONE
 options DEBUG_MEMGUARD

 options FFS #Berkeley Fast Filesystem
 # options SOFTUPDATES #Enable FFS soft updates support
 # options UFS_ACL #Support for access control lists
 # options UFS_DIRHASH #Improve performance on big
 directories
 # options   MSDOSFS # Read MSDOS filesystems; 
 useful for USB/CF

 device  pci
 device  ar71xx_pci

 # RTC - requires hackery in the spibus code to work
 device  pcf2123_rtc

 # GEOM modules
 device  geom_redboot# to get access to the SPI flash partitions
 device  geom_uzip   # compressed in-memory filesystem hackery!
 device  geom_map
 options GEOM_UZIP

 # NANDFS
 options NANDFS

 ## Boot from the first MFS uzip
 #optionsROOTDEVNAME=\ufs:md0.uzip\
 #optionsMD_ROOT
 #optionsMD_ROOT_SIZE=9000

 # Boot from NFS
 options NFSLOCKD#Network Lock Manager
 options NFSCLIENT   #Network Filesystem Client
 options NFS_ROOT

 options BOOTP
 options BOOTP_NFSROOT
 options BOOTP_NFSV3
 options BOOTP_WIRED_TO=arge1
 options BOOTP_COMPAT
 options ROOTDEVNAME=\nfs:172.16.0.101:/usr/obj/rb433ah/nfs\


 # 802.11 framework
 options IEEE80211_DEBUG
 options IEEE80211_ALQ
 options IEEE80211_SUPPORT_MESH
 # This option is currently broken for if_ath_tx.
 options IEEE80211_SUPPORT_TDMA
 options IEEE80211_AMPDU_AGE
 device  wlan# 802.11 support
 device  wlan_wep# 802.11 WEP support
 device  wlan_ccmp   # 802.11 CCMP support
 device  wlan_tkip   # 802.11 TKIP support
 device  wlan_xauth  # 802.11 hostap support
 device  wlan_acl# 802.11 ACL support

 # Atheros wireless NICs
 

Re: ath0: could not map interrupt

[Adrian Chadd]

... wow. How the hell is that happening?!




Adrian


On 3 January 2013 20:54, Monthadar Al Jaberi montha...@gmail.com wrote:
 Maybe this is the root of the problem.

 On RSPRO the PCI start slot enumerating from 17. While RB433AH start
 from 18. That can explain why Slot 20 of RB433AH won't even attach
 (AR7161 only has 3 slots, slot 17 to 19). That can also explain why I
 get device_timeout on slot 18 and 19 cause they are miss aligned. And
 don't see any interrupts from ath(4) when enabling interrupt
 debugging.

 I will keep digging into why they won't start enumerating correct.

 br,

 On Fri, Jan 4, 2013 at 2:28 AM, Monthadar Al Jaberi montha...@gmail.com 
 wrote:
 Hi,

 I am wondering if anyone can confirm that any ath5k (preferably
 AR5413) series miniPCI wifi works on RB433/AH/UAH.

 Thank you in advance

 On Wed, Jan 2, 2013 at 10:29 PM, Monthadar Al Jaberi
 montha...@gmail.com wrote:
 On Wed, Jan 2, 2013 at 9:43 PM, Adrian Chadd adr...@freebsd.org wrote:
 ... sounds like a definite interrupt routing issue.

 Who's been knee deep in the interrupt handling code in MIPS lately? Grrr.
 I know there's been some FDT work in MIPS and that's touched some
 interrupt code.. maybe that's interfering?

 I am not sure, I just re-compiled my kernel for RSPRO and it seems to work.

 I install openwrt on rb433ah and ath0 associated ok. and I could ping
 between RSPRO(FreeBSD) and RB433AH(Openwrt). RSPRO and non working
 RB433AH  running same kernel r243866.

 Attached is my kernel config  hints. ( I am playing around with the
 ar71xx_spi but that should not effect the pci code, I hope).

 #
 # AR71XX -- Kernel configuration file for FreeBSD/MIPS for Atheros 71xx 
 systems
 #
 # This includes all the common drivers for the AR71XX boards along with
 # the usb, net80211 and atheros driver code.
 #
 # $FreeBSD$
 #

 machine mips mips
 ident   RB433AH_MFS
 cpu CPU_MIPS4KC
 makeoptions KERNLOADADDR=0x8005
 options HZ=1000
 options HWPMC_HOOKS

 files   ../atheros/files.ar71xx

 # For now, hints are per-board.

 hints   RB433AH.hints

 makeoptions DEBUG=-g#Build kernel with gdb(1) debug 
 symbols

 # Build these as modules so small platform builds will have the
 # modules already built.
 makeoptions MODULES_OVERRIDE=random gpio ar71xx if_gif if_gre
 if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip
 wlan_ccmp wlan_rssadapt wlan_amrr ath ath_pci

 options DDB
 options KDB

 options SCHED_4BSD  #4BSD scheduler
 options INET#InterNETworking
 #optionsINET6   # IPv6

 # options   NFS_CL  #Network Filesystem Client

 options PSEUDOFS#Pseudo-filesystem framework
 options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time 
 extensions

 # options   NFS_LEGACYRPC
 # Debugging for use in -current
 options INVARIANTS
 options INVARIANT_SUPPORT
 options WITNESS
 options WITNESS_SKIPSPIN
 options DEBUG_REDZONE
 options DEBUG_MEMGUARD

 options FFS #Berkeley Fast Filesystem
 # options SOFTUPDATES #Enable FFS soft updates support
 # options UFS_ACL #Support for access control lists
 # options UFS_DIRHASH #Improve performance on big
 directories
 # options   MSDOSFS # Read MSDOS filesystems; 
 useful for USB/CF

 device  pci
 device  ar71xx_pci

 # RTC - requires hackery in the spibus code to work
 device  pcf2123_rtc

 # GEOM modules
 device  geom_redboot# to get access to the SPI flash partitions
 device  geom_uzip   # compressed in-memory filesystem hackery!
 device  geom_map
 options GEOM_UZIP

 # NANDFS
 options NANDFS

 ## Boot from the first MFS uzip
 #optionsROOTDEVNAME=\ufs:md0.uzip\
 #optionsMD_ROOT
 #optionsMD_ROOT_SIZE=9000

 # Boot from NFS
 options NFSLOCKD#Network Lock Manager
 options NFSCLIENT   #Network Filesystem Client
 options NFS_ROOT

 options BOOTP
 options BOOTP_NFSROOT
 options BOOTP_NFSV3
 options BOOTP_WIRED_TO=arge1
 options BOOTP_COMPAT
 options ROOTDEVNAME=\nfs:172.16.0.101:/usr/obj/rb433ah/nfs\


 # 802.11 framework
 options IEEE80211_DEBUG
 options IEEE80211_ALQ
 options IEEE80211_SUPPORT_MESH
 # This option is currently broken for if_ath_tx.
 options IEEE80211_SUPPORT_TDMA
 options IEEE80211_AMPDU_AGE
 device  wlan# 802.11 support
 device  wlan_wep# 802.11 WEP support
 device  wlan_ccmp   # 802.11 CCMP support
 device  wlan_tkip   # 802.11 TKIP support

Re: ath0: could not map interrupt

[Adrian Chadd]

... sounds like a definite interrupt routing issue.

Who's been knee deep in the interrupt handling code in MIPS lately? Grrr.
I know there's been some FDT work in MIPS and that's touched some
interrupt code.. maybe that's interfering?


Adrian


On 2 January 2013 12:40, Monthadar Al Jaberi montha...@gmail.com wrote:
 I tested some more. First I changed the miniPCI slot. Now boot looks like 
 this:

 pcib0 at irq 0 on nexus0
 pci0: PCI bus on pcib0
 ath0: Atheros 5413 irq 2 at device 19.0 on pci0
 ath0: AR5413 mac 10.5 RF5413 phy 6.1
 ath0: 2GHz radio: 0x; 5GHz radio: 0x0063


 Then I created a hostap. But none of my other devices sees it (laptop, 
 iphone).

 A scan results in:

 # ifconfig wlan0 scan
 wlan0: ieee80211_scanreq: flags 0x1b duration 0x7fff mindwell 0
 maxdwell 0 nssid 0
 wlan0: start_scan_locked: active scan, duration 2147483647 mindwell 0
 maxdwell 0, desired mode 11g, append, nopick, once
 wlan0: scan set 11g dwell min 200ms max 200ms
 wlan0: scan_task: chan  11g -  11g [active, dwell min 200ms max 200ms]
 wlan0: ieee80211_ref_node (ieee80211_send_probereq:1822)
 0xc6f270:15:6d:67:21:8d refcnt 4
 wlan0: send probe req on channel 11 bssid ff:ff:ff:ff:ff:ff ssid 
 wlan0: scan_task: done, [ticks 2657909, dwell min 200 scanend 2150141333]
 wlan0: notify scan done
 root@rb433ah:~ # ath0: device timeout

 And when I try to ping a random IP address I get the following.
 Interesting is that it seems to bail out when it tries to send
 probe_resp (last in output):
 $ ping -c 1 172.168.3.2
 PING 172.168.3.2 (172.168.3.2): 56 data bytes
 ath0: device timeout
 wlan0: received beacon from 74:44:01:2d:cb:5e rssi 14
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 47, len 1
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 74, len 
 14
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 127, len 
 1
 wlan0: received beacon from 28:10:7b:8e:7a:ec rssi 46
 wlan0: [28:10:7b:8e:7a:ec] discard unhandled information element, id 51, len 8
 wlan0: [28:10:7b:8e:7a:ec] discard unhandled information element, id 51, len 8
 wlan0: [28:10:7b:8e:7a:ec] discard unhandled information element, id 127, len 
 1
 wlan0: [28:10:7b:8e:7a:ec] discard unhandled information element, id 11, len 5
 wlan0: [28:10:7b:8e:7a:ec] discard beacon frame, for off-channel 10
 wlan0: received beacon from 74:44:01:2d:cb:5e rssi 13
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 47, len 1
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 74, len 
 14
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 127, len 
 1
 wlan0: received beacon from 74:44:01:2d:cb:5e rssi 14
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 47, len 1
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 74, len 
 14
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 127, len 
 1
 wlan0: received beacon from 00:11:50:4d:c5:08 rssi 8
 wlan0: [00:11:50:4d:c5:08] discard unhandled information element, id 47, len 1
 wlan0: received beacon from 28:10:7b:8e:7a:ec rssi 40
 wlan0: [28:10:7b:8e:7a:ec] discard unhandled information element, id 51, len 8
 wlan0: [28:10:7b:8e:7a:ec] discard unhandled information element, id 51, len 8
 wlan0: [28:10:7b:8e:7a:ec] discard unhandled information element, id 127, len 
 1
 wlan0: [28:10:7b:8e:7a:ec] discard unhandled information element, id 11, len 5
 wlan0: [28:10:7b:8e:7a:ec] discard beacon frame, for off-channel 10
 wlan0: received beacon from 74:44:01:2d:cb:5e rssi 12
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 47, len 1
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 74, len 
 14
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 127, len 
 1
 wlan0: [94:0c:6d:ad:61:18] discard frame, not to bss
 wlan0: received beacon from 74:44:01:2d:cb:5e rssi 13
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 47, len 1
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 74, len 
 14
 wlan0: [74:44:01:2d:cb:5e] discard unhandled information element, id 127, len 
 1
 wlan0: received beacon from 28:10:7b:8e:7a:ec rssi 48
 wlan0: [28:10:7b:8e:7a:ec] discard unhandled information element, id 51, len 8
 wlan0: [28:10:7b:8e:7a:ec] discard unhandled information element, id 51, len 8
 wlan0: [28:10:7b:8e:7a:ec] discard unhandled information element, id 127, len 
 1
 wlan0: [28:10:7b:8e:7a:ec] discard unhandled information element, id 11, len 5
 wlan0: [28:10:7b:8e:7a:ec] discard beacon frame, for off-channel 10
 wlan0: received probe_req from 00:16:cf:3c:f7:7f rssi 2
 [00:16:cf:3c:f7:7f] discard probe_req frame, ssid mismatch:
 0x9ccca48e6a3b0c7f661c24413d7b9e54c5e59ddbe0c2bd96a2e65410b662f71a
 wlan0: received probe_req from 00:16:cf:3c:f7:7f rssi 5
 [00:16:cf:3c:f7:7f] discard probe_req frame, ssid mismatch: default
 wlan0: received beacon from 74:44:01:2d:cb:5e