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 w
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 no
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
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,
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" r
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 free
Tim Chase (free...@tim.thechases.com) 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
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:
> > > CA
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
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
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
__
On 4 January 2013 11:24, Monthadar Al Jaberi wrote:
> On Fri, Jan 4, 2013 at 8:13 PM, Adrian Chadd 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
... wow. How the hell is that happening?!
Adrian
On 3 January 2013 20:54, Monthadar Al Jaberi 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
> (AR716
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 m
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
wrote:
> On Wed, Jan 2, 2013 at 9:43 PM, Adrian Chadd wrote:
>> ... sounds like a definite interrupt
On Wed, Jan 2, 2013 at 9:43 PM, Adrian Chadd 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?
... 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 wrote:
I tested some more. First I changed the miniPCI slot. Now boot looks like this:
pcib0 at irq 0 on nexus0
pci0: on pcib0
ath0: 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 see
18 matches
Mail list logo
