Re: Atheros AR9565 detected, not working

2015-01-09 Thread Adrian Chadd
Hm, are you buliding as a module by doing "make" in the module dir? or
by doing a buildkernel?



-a


On 7 January 2015 at 21:10, Anthony Jenkins  wrote:
> Removing just the ar9300_enable_rf_kill() bit works too, but now ath(4) 
> endlessly spews
>
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=3, nbufs=128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=1, nbufs=128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=2, nbufs=128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=1, nbufs=128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=2, nbufs=128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
>
> Also changed GPIO patch to not block/just/ pin 11 ops instead of all pins as 
> in previous patch, but if allowing all pins is kosher I'd prefer that.
>
> Anthony
>
> On 01/07/2015 09:08, Anthony Jenkins wrote:
>> Hi Adrian,
>>
>> Just letting you know I haven't died in a shootout with the US FBI or 
>> anything, just been working on (and suprisingly fixing) issues with my HP 
>> Envy Sleekbook 6 since the holidays.  I'll be cleaning up my patches and 
>> posting to the wiki this week (hopefully).  Also still sitting on that ACPI 
>> patch for the RTC CMOS handler.
>>
>>> So, would you mind trying your patch again but only with the bits that
>>> allow the GPIO pins to be enabled? If that works, then I'll commit
>>> that
>> Just to be clear, instead of commenting out the early exits in the GPIO 
>> readers/writers for certain GPIO addresses, I should selectively give the 
>> AR9565 a pass?  ...or do you want me to /just/ comment out the early exits, 
>> and revert the added call to ar9300_enable_rf_kill() and see if that works?  
>> I don't like those early exit bits anyway...
>>> In parallel I'm going to have to tidy up the rfkill capability
>>> API to correctly set bits - I'll likely expand the field in the driver
>>> and have the pre-AR9300 chipset code error out if an out-of-bounds
>>> gpio value is sent.
>> Excellent!  Anything I can help with?  We /have/ an rfkill API?  ...because 
>> I need some way to connect my newly-fixed laptop wifi-enable key to some 
>> function to enable/disable the radios.  Right now I'm just throwing an event 
>> over to devd(8).
>>
>> Thanks,
>> Anthony
>>
>> On 12/23/2014 13:06, Adrian Chadd wrote:
>>> On 22 December 2014 at 14:57, Adrian Chadd  wrote:
>>>
 Ok, let me go see what's going on.
>>> I dislike when I say "let me see what's going on" and then I .. see
>>> what's going on.
>>>
>>> So:
>>>
>>> * the ar5212 HAL does the right thing - it checks the rfkill setup in
>>> ar5212Reset() and enables it if required
>>> * it also populates the rfkill data from EEPROM at attach time
>>> * the sysctl code just grabs the rfkill /eeprom field/ and .. well,
>>> that's the API. So I have to see if that's the same for the AR9300 or
>>> not. Grr.
>>>
>>> Well, it kinda is:
>>>
>>> ar9300eep.h:#define EEP_RFSILENT_ENABLED0x0001  /* bit 0:
>>> enabled/disabled */
>>> ar9300eep.h:#define EEP_RFSILENT_ENABLED_S  0   /* bit 0:
>>> enabled/disabled */
>>> ar9300eep.h:#define EEP_RFSILENT_POLARITY   0x0002  /* bit 1: polarity 
>>> */
>>> ar9300eep.h:#define EEP_RFSILENT_POLARITY_S 1   /* bit 1: polarity 
>>> */
>>> ar9300eep.h:#define EEP_RFSILENT_GPIO_SEL   0x00fc  /* bits 2..7:
>>> gpio PIN */
>>> ar9300eep.h:#define EEP_RFSILENT_GPIO_SEL_S 2   /* bits 2..7:
>>> gpio PIN */
>>>
>>> .. but on the AR5212:
>>>
>>> ../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_GPIO_SEL0x001c
>>> ../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_GPIO_SEL_S2
>>> ../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_POLARITY0x0002
>>> ../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_POLARITY_S1
>>> ../ah_eeprom_v3.h:#defineAR_EEPROM_RFSILENT0x0f/* RF
>>> Silent/Clock Run Enable */
>>> ../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_GPIO_SEL0x001c
>>> ../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_GPIO_SEL_S2
>>> ../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_POLARITY0x0002
>>> ../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_POLARITY_S1
>>>
>>> .. so more bits are available on the ar9300. I have to check the
>>> AR5416 too; maybe more bits are also available t

Re: Intel Pro/Wireless 2200BG iwi(4) card stopped working in 8-stable

2015-01-09 Thread Adrian Chadd
just note: ar5416/ar9160 are 2x2, with three antennas. but definitely
2x2 (MCS0-15) 11n chips.



-a


On 9 January 2015 at 01:54, Alexey Dokuchaev  wrote:
> On Sat, Oct 06, 2012 at 03:12:58AM +0700, Alexey Dokuchaev wrote:
>> On Fri, Oct 05, 2012 at 07:02:26AM -0700, Adrian Chadd wrote:
>> > On 5 October 2012 05:38, Alexey Dokuchaev  wrote:
>> > > Since this card gave me lots of troubles over the past, any one can
>> > > recommend a decent mini-pci replacement?  It looks like ath(4) chips
>> > > are currently best supported. [...]
>> >
>> > AR5416 or AR9220 will be fine. Even an AR9160 will be fine.
>>
>> OK, but shall I give predilection towards one of them, or they're all
>> pretty much the same?
>
> Today I've revisited this old topic and found that similar question was
> asked before on ath9k-de...@lists.ath9k.org [1].  I will quote some parts
> of it here (and thus answer my own question) for the sake of history.
>
>   Gen 1 - AR5008:
>   AR5416+AR5122 - 2x2 dual band, PCI
>   AR5416+AR5133 - 3x3 dual band, PCI
>   AR5418+AR5133 - 3x3 dual band, PCIe
>
>   Gen 2 - AR9001:
>   AR9160+AR9104 - 2x2 dual band, PCI
>   AR9160+AR9106 - 3x3 dual band, PCI
>
>   Gen 3 - AR9002:
>   AR9220 - 2x2, dual band, PCI
>   AR9280 - 2x2, dual band, PCIe
>
> [We know that] the AR9002 is a single chip solution, likely reducing cost,
> power and size. But is there any improvement to radio functionality or
> other features?
>
> Answer (by Luis R. Rodriguez):
>
> Having a single chip itself yields a lot more benefits than that.  Since
> things are closer together it also means less complexity on overall
> programming.
>
> I recommend the single chip families, and specificaly AR9280 is a great
> candidate as its dual band and uses PCI-E.  From a software perspective
> Atheros dedicates more of its own resources for testing our newer chipsets,
> the newer gernation 802.11n chipsets.  AR9001 didn't get formal testing
> but the AR9002 did.  Now its AR9002, in the near future it will be AR9003
> and so on.
>
> ./danfe
>
> [1] http://ath9k-devel.ath9k.narkive.com/GqjxAbUB/ar-chipset-differences
> ___
> 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"
___
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: Intel Pro/Wireless 2200BG iwi(4) card stopped working in 8-stable

2015-01-09 Thread Alexey Dokuchaev
On Sat, Oct 06, 2012 at 03:12:58AM +0700, Alexey Dokuchaev wrote:
> On Fri, Oct 05, 2012 at 07:02:26AM -0700, Adrian Chadd wrote:
> > On 5 October 2012 05:38, Alexey Dokuchaev  wrote:
> > > Since this card gave me lots of troubles over the past, any one can
> > > recommend a decent mini-pci replacement?  It looks like ath(4) chips
> > > are currently best supported. [...]
> > 
> > AR5416 or AR9220 will be fine. Even an AR9160 will be fine.
> 
> OK, but shall I give predilection towards one of them, or they're all
> pretty much the same?

Today I've revisited this old topic and found that similar question was
asked before on ath9k-de...@lists.ath9k.org [1].  I will quote some parts
of it here (and thus answer my own question) for the sake of history.

  Gen 1 - AR5008:
  AR5416+AR5122 - 2x2 dual band, PCI
  AR5416+AR5133 - 3x3 dual band, PCI
  AR5418+AR5133 - 3x3 dual band, PCIe

  Gen 2 - AR9001:
  AR9160+AR9104 - 2x2 dual band, PCI
  AR9160+AR9106 - 3x3 dual band, PCI

  Gen 3 - AR9002:
  AR9220 - 2x2, dual band, PCI
  AR9280 - 2x2, dual band, PCIe

[We know that] the AR9002 is a single chip solution, likely reducing cost,
power and size. But is there any improvement to radio functionality or
other features?

Answer (by Luis R. Rodriguez):

Having a single chip itself yields a lot more benefits than that.  Since
things are closer together it also means less complexity on overall
programming.

I recommend the single chip families, and specificaly AR9280 is a great
candidate as its dual band and uses PCI-E.  From a software perspective
Atheros dedicates more of its own resources for testing our newer chipsets,
the newer gernation 802.11n chipsets.  AR9001 didn't get formal testing
but the AR9002 did.  Now its AR9002, in the near future it will be AR9003
and so on.

./danfe

[1] http://ath9k-devel.ath9k.narkive.com/GqjxAbUB/ar-chipset-differences
___
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"