Re: Atheros AR9565 detected, not working

[Adrian Chadd]

On 23 January 2015 at 12:45, Anthony Jenkins  wrote:
> Here's a patch that works on my laptop's AR9565 - it just allows GPIO BIT_11
> accesses.  No idea why that works; I thought I discovered BIT_8 was the
> rfkill bit.  I tried allowing both BIT_11 /and/ BIT_8, but that doesn't work
> (wpa_supplicant(8) can never authenticate).  May dig further, but I'm kinda
> swamped with stuff.

I'm glad you dug this far!

> I can conditionally allow BIT_11 GPIOs if the device is an AR9565... should
> I do that?

I think we should just kill the check entirely for now. I'll go look
at doing that soon.

> Why/how does the Atheros driver emit invalid GPIO bit controls for a device?
> In other words, if my Atheros 123456 chip wants to do XXX, how does that
> translate to a GPIO bit access that needs to be blocked in the low-level
> GPIO functions?  Yet another way to put it, what's that blocking logic in
> ar9300_gpio.c there for?

Well, because upper layer routines may ask for GPIO pins to do things
(like configure LEDs, antenna switches, etc.) It's not just the HAL
that's asking for GPIO assignments.

It's not invalid - it's that some chips will glue other things into
GPIO lines. Things like external low noise RX amplifiers, high power
TX amplifiers, etc.




-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: Atheros AR9565 detected, not working

[Anthony Jenkins]

Here's a patch that works on my laptop's AR9565 - it just allows GPIO 
BIT_11 accesses.  No idea why that works; I thought I discovered BIT_8 
was the rfkill bit.  I tried allowing both BIT_11 /and/ BIT_8, but that 
doesn't work (wpa_supplicant(8) can never authenticate).  May dig 
further, but I'm kinda swamped with stuff.


I can conditionally allow BIT_11 GPIOs if the device is an AR9565... 
should I do that?


Why/how does the Atheros driver emit invalid GPIO bit controls for a 
device?  In other words, if my Atheros 123456 chip wants to do XXX, how 
does that translate to a GPIO bit access that needs to be blocked in the 
low-level GPIO functions?  Yet another way to put it, what's that 
blocking logic in ar9300_gpio.c there for?


Thanks,
Anthony

On 01/10/15 17:44, Adrian Chadd wrote:

Yup, it doesn't pick up the config options (like enabling 11n) in the
kernel config. That's turned into opt_xxx.h header files in a kernel
build directory.



-a


On 10 January 2015 at 13:11, Anthony Jenkins  wrote:

Ahhh... "make" in the module dir, not good?  I've since done a kernel build
and I noticed it's not showing up (as much).  Why would building the kernel
module that way cause that behavior?

Anthony


From: Adrian Chadd 
To: Anthony Jenkins 
Cc: Anthony Jenkins ; "wirel...@freebsd.org"

Sent: Friday, January 9, 2015 4:00 PM

Subject: Re: Atheros AR9565 detected, not working

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 

Re: Atheros AR9565 detected, not working

[Adrian Chadd]

Yup, it doesn't pick up the config options (like enabling 11n) in the
kernel config. That's turned into opt_xxx.h header files in a kernel
build directory.



-a


On 10 January 2015 at 13:11, Anthony Jenkins  wrote:
> Ahhh... "make" in the module dir, not good?  I've since done a kernel build
> and I noticed it's not showing up (as much).  Why would building the kernel
> module that way cause that behavior?
>
> Anthony
>
> 
> From: Adrian Chadd 
> To: Anthony Jenkins 
> Cc: Anthony Jenkins ; "wirel...@freebsd.org"
> 
> Sent: Friday, January 9, 2015 4:00 PM
>
> Subject: Re: Atheros AR9565 detected, not working
>
> 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

Re: Atheros AR9565 detected, not working

[Anthony Jenkins via freebsd-wireless]

Ahhh... "make" in the module dir, not good?  I've since done a kernel build and 
I noticed it's not showing up (as much).  Why would building the kernel module 
that way cause that behavior?

Anthony
  From: Adrian Chadd 
 To: Anthony Jenkins  
Cc: Anthony Jenkins ; "wirel...@freebsd.org" 
 
 Sent: Friday, January 9, 2015 4:00 PM
 Subject: Re: Atheros AR9565 detected, not working
   
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_ENABLED        0x0001  /* 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 */

Re: Atheros AR9565 detected, not working

[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: Atheros AR9565 detected, not working

[Anthony Jenkins]

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 there.
>>
>> Grr!
>>
>> * Then, the Ar5212 is doing it in ar5212Reset(), but ar5416Reset()
>> isn't doing it! So I'm going to have to go and hook that up for the
>> AR5416, AR9160, AR9280, AR9285, AR9287. Ugh.
>>
>> * the ar9300 HAL on -HEAD has this in ar9300_reset():
>>
>> /* Reset ier

Re: Atheros AR9565 detected, not working

[Anthony Jenkins]

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 there.
>
> Grr!
>
> * Then, the Ar5212 is doing it in ar5212Reset(), but ar5416Reset()
> isn't doing it! So I'm going to have to go and hook that up for the
> AR5416, AR9160, AR9280, AR9285, AR9287. Ugh.
>
> * the ar9300 HAL on -HEAD has this in ar9300_reset():
>
> /* Reset ier reference count to disabled */
> //OS_ATOMIC_SET(&ahp->ah_ier_ref_count, 1);C
> if (ath_hal_isrfkillenabled(ah)) {
> ar9300_enable_rf_kill(ah);
> }
>
> .. so it should be enabling it at reset. We shouldn't need to enable
> it during ar9300_attach() as the first reset will set it up.
>
> * The AR5212 HAL enables rfkill interrupts, but the AR9300 doesn't.
> Apparently there are .. issues. I don't know what they are. So maybe
> we should use polling on that particular GPIO pin to provide rfkill
> feedback to the driver and eventually the network stack.
>
> 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. 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.
>
> Thanks!
>
>
>
> -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"
>

___
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: Atheros AR9565 detected, not working

[Adrian Chadd]

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

Grr!

* Then, the Ar5212 is doing it in ar5212Reset(), but ar5416Reset()
isn't doing it! So I'm going to have to go and hook that up for the
AR5416, AR9160, AR9280, AR9285, AR9287. Ugh.

* the ar9300 HAL on -HEAD has this in ar9300_reset():

/* Reset ier reference count to disabled */
//OS_ATOMIC_SET(&ahp->ah_ier_ref_count, 1);C
if (ath_hal_isrfkillenabled(ah)) {
ar9300_enable_rf_kill(ah);
}

.. so it should be enabling it at reset. We shouldn't need to enable
it during ar9300_attach() as the first reset will set it up.

* The AR5212 HAL enables rfkill interrupts, but the AR9300 doesn't.
Apparently there are .. issues. I don't know what they are. So maybe
we should use polling on that particular GPIO pin to provide rfkill
feedback to the driver and eventually the network stack.

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

Thanks!



-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: Atheros AR9565 detected, not working

[Adrian Chadd]

On 22 December 2014 at 13:59, Anthony Jenkins  wrote:
> On 12/22/2014 15:22, Adrian Chadd wrote:
>> On 22 December 2014 at 11:59, Anthony Jenkins  wrote:
>>> I'll have to re-add the printf()s, but I'm pretty sure I saw 0x0B (of 
>>> course it could have been 0x08 I saw, but neither of those would make it 
>>> through the function - both 0x0B and 0x08 are blocked).
>> Please do. I'd like to fix up the HAL and driver to use the EEPROM
>> provided LED and RFKILL GPIO fields if they're populated and valid.
> Here's the chunk of boot messages for ath(4) on my laptop; it was 0x0B as I 
> originally thought:
>
> Dec 22 16:47:59 ajenkins-hplaptop kernel: pcib2: allocated memory range 
> (0xf010-0xf017) for rid 10 of pci0:2:0:0
> Dec 22 16:47:59 ajenkins-hplaptop kernel: pcib2: matched entry for 2.0.INTA
> Dec 22 16:47:59 ajenkins-hplaptop kernel: pcib2: slot 0 INTA hardwired to IRQ 
> 17
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0:  mem 
> 0xf010-0xf017 irq 17 at device 0.0 on pci2
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ioapic0: routing intpin 17 (PCI IRQ 
> 17) to lapic 16 vector 53
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: WB335 1-ANT card detected
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_attach: calling 
> ar9300_hw_attach
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_hw_attach: calling 
> ar9300_eeprom_attach
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_flash_map: unimplemented for 
> now
> Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from DRAM
> Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from EEPROM
> Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from Flash
> Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from Flash
> Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from OTP
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_hw_attach: 
> ar9300_eeprom_attach returned 0
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_fill_capability_info: 
> ah_rfsilent=0x2d
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_fill_capability_info: 
> ah_gpio_select=0x0b
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_fill_capability_info: 
> ah_polarity=0x00
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: RX status length: 48
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: RX buffer size: 4096
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: TX descriptor length: 128
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: TX status length: 36
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: TX buffers per descriptor: 4
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: ath_edma_setup_rxfifo: 
> type=0, FIFO depth = 16 entries
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: ath_edma_setup_rxfifo: 
> type=1, FIFO depth = 128 entries
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] enabling HT modes
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] enabling short-GI in 
> 20MHz mode
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] 1 stream STBC receive 
> enabled
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] 1 RX streams; 1 TX 
> streams
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11b rates: 1Mbps 2Mbps 
> 5.5Mbps 11Mbps
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11g rates: 1Mbps 2Mbps 
> 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 1T1R
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 20MHz
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 6.5Mbps - 65Mbps
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 20MHz SGI
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 7Mbps - 72Mbps
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 40MHz:
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 13.5Mbps - 135Mbps
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 40MHz SGI:
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 15Mbps - 150Mbps
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: AR9565 mac 704.0 RF5110 phy 
> 1638.6
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 2GHz radio: 0x; 5GHz 
> radio: 0x
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 1 for WME_AC_BE 
> traffic
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 0 for WME_AC_BK 
> traffic
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 2 for WME_AC_VI 
> traffic
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 3 for WME_AC_VO 
> traffic
> Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 8 for CAB traffic
>
> Here's the printf()s in the code:
>
> /*
>  * Fill all software cached or static hardware state information.
>  * Return failure if capabilities are to come from EEPROM and
>  * cannot be read.
>  */
> HAL_BOOL
> ar9300_fill_capability_info(struct ath_hal *ah)
> {
> ...
> ahpriv->ah_rfsilent = ar9300_eeprom_get(ahp, EEP_RF_SILENT);
> ath_hal_printf(ah, "%s: ah_rfsilen

Re: Atheros AR9565 detected, not working

[Anthony Jenkins via freebsd-wireless]

On 12/22/2014 15:22, Adrian Chadd wrote:
> On 22 December 2014 at 11:59, Anthony Jenkins  wrote:
>> I'll have to re-add the printf()s, but I'm pretty sure I saw 0x0B (of course 
>> it could have been 0x08 I saw, but neither of those would make it through 
>> the function - both 0x0B and 0x08 are blocked).
> Please do. I'd like to fix up the HAL and driver to use the EEPROM
> provided LED and RFKILL GPIO fields if they're populated and valid.
Here's the chunk of boot messages for ath(4) on my laptop; it was 0x0B as I 
originally thought:

Dec 22 16:47:59 ajenkins-hplaptop kernel: pcib2: allocated memory range 
(0xf010-0xf017) for rid 10 of pci0:2:0:0
Dec 22 16:47:59 ajenkins-hplaptop kernel: pcib2: matched entry for 2.0.INTA
Dec 22 16:47:59 ajenkins-hplaptop kernel: pcib2: slot 0 INTA hardwired to IRQ 17
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0:  mem 
0xf010-0xf017 irq 17 at device 0.0 on pci2
Dec 22 16:47:59 ajenkins-hplaptop kernel: ioapic0: routing intpin 17 (PCI IRQ 
17) to lapic 16 vector 53
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: WB335 1-ANT card detected
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_attach: calling 
ar9300_hw_attach
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_hw_attach: calling 
ar9300_eeprom_attach
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_flash_map: unimplemented for 
now
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from DRAM
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from EEPROM
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from Flash
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from Flash
Dec 22 16:47:59 ajenkins-hplaptop kernel: Restoring Cal data from OTP
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_hw_attach: 
ar9300_eeprom_attach returned 0
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_fill_capability_info: 
ah_rfsilent=0x2d
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_fill_capability_info: 
ah_gpio_select=0x0b
Dec 22 16:47:59 ajenkins-hplaptop kernel: ar9300_fill_capability_info: 
ah_polarity=0x00
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: RX status length: 48
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: RX buffer size: 4096
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: TX descriptor length: 128
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: TX status length: 36
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: TX buffers per descriptor: 4
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: ath_edma_setup_rxfifo: type=0, 
FIFO depth = 16 entries
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: ath_edma_setup_rxfifo: type=1, 
FIFO depth = 128 entries
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] enabling HT modes
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] enabling short-GI in 20MHz 
mode
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] 1 stream STBC receive 
enabled
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: [HT] 1 RX streams; 1 TX streams
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 
11Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 
11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 1T1R
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 20MHz
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 6.5Mbps - 65Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 20MHz SGI
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 7Mbps - 72Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 40MHz:
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 13.5Mbps - 135Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 11ng MCS 40MHz SGI:
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: MCS 0-7: 15Mbps - 150Mbps
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: AR9565 mac 704.0 RF5110 phy 
1638.6
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: 2GHz radio: 0x; 5GHz radio: 
0x
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 1 for WME_AC_BE 
traffic
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 0 for WME_AC_BK 
traffic
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 2 for WME_AC_VI 
traffic
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 3 for WME_AC_VO 
traffic
Dec 22 16:47:59 ajenkins-hplaptop kernel: ath0: Use hw queue 8 for CAB traffic

Here's the printf()s in the code:

/*
 * Fill all software cached or static hardware state information.
 * Return failure if capabilities are to come from EEPROM and
 * cannot be read.
 */
HAL_BOOL
ar9300_fill_capability_info(struct ath_hal *ah)
{
...
ahpriv->ah_rfsilent = ar9300_eeprom_get(ahp, EEP_RF_SILENT);
ath_hal_printf(ah, "%s: ah_rfsilent=0x%02x\n", __func__, 
ahpriv->ah_rfsilent);
if (ahpriv->ah_rfsilent & EEP_RFSILENT_ENABLED) {
ahp->ah_gpio_select = MS(ahpriv->ah_rfsilent, EEP_RFSILENT_GPIO_SEL);
ath_hal_printf(ah, "%s: ah_gpio_select=0x%02x\n", _

Re: Atheros AR9565 detected, not working

[Adrian Chadd]

On 22 December 2014 at 11:59, Anthony Jenkins  wrote:
> I'll have to re-add the printf()s, but I'm pretty sure I saw 0x0B (of course 
> it could have been 0x08 I saw, but neither of those would make it through the 
> function - both 0x0B and 0x08 are blocked).

Please do. I'd like to fix up the HAL and driver to use the EEPROM
provided LED and RFKILL GPIO fields if they're populated and valid.

Thanks!



-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: Atheros AR9565 detected, not working

[Anthony Jenkins via freebsd-wireless]

I'll have to re-add the printf()s, but I'm pretty sure I saw 0x0B (of course it 
could have been 0x08 I saw, but neither of those would make it through the 
function - both 0x0B and 0x08 are blocked).

Anthony

On 12/22/2014 14:51, Adrian Chadd wrote:
> See, that's where it's odd:
>
> | EepromWriteGpio: 16, WlanDisableGpio: 0, WlanLedGpio: 8
> RxBandSelectGpio: 255 |
>
> .. how'd you figure out it's GPIO 11?
>
>
>
> -adrian
>
>
> On 22 December 2014 at 11:39, Anthony Jenkins  wrote:
>> Logs attached.
>>
>> Thanks,
>> Anthony
>>
>> On 12/22/2014 11:21, Adrian Chadd wrote:
>>> Yeah, there's no GPIO check like there is in the reference code.
>>>
>>> The fact it says AR9382 is pretty telling. That's like it's asking for
>>> a very specific NIC with very specific GPIO mappings. :(
>>>
>>>
>>>
>>> -adrian
>>>
>>>
>>> On 22 December 2014 at 06:03, Anthony Jenkins  wrote:
>>>> Will do.  I'm actually thinking about reverting my changes just to see if 
>>>> stock ath(4) works (it's been a looong while since I played with bringing 
>>>> it up).  I still occasionally see the same behavior I saw before my 
>>>> changes.
>>>>
>>>> I'm using a recent Linux kernel (which works out of the box) to get it 
>>>> working in FreeBSD - the keyboard wi-fi LED and hotkey work perfectly 
>>>> there.
>>>>
>>>> Thanks,
>>>> Anthony
>>>>
>>>> 
>>>> From: Adrian Chadd 
>>>> To: Anthony Jenkins 
>>>> Cc: "wirel...@freebsd.org" 
>>>> Sent: Sunday, December 21, 2014 9:39 PM
>>>> Subject: Re: Atheros AR9565 detected, not working
>>>>
>>>>
>>>> Hi!
>>>>
>>>> ok, how'd you build things? a module, or in the kernel?
>>>>
>>>> You need to (a) build it using 'make buildkernel / make installkernel'
>>>> and (b) ensure ATH_ENABLE_11N is in your kernel configuration.
>>>>
>>>> The GPIO bits are a bit odd - let me check the other chipset drivers.
>>>>
>>>> Can you compile the tools in src/tools/tools/ath/ - then run this:
>>>>
>>>> ath_prom_dump -i ath0 -d /tmp/ath.dump
>>>> ath_ee_9300_print /tmp/ath.dump > /tmp/ath.txt
>>>>
>>>> then email the contents of ath.txt . It'll include the GPIO pin id.
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>
>>>> -adrian
>>>>
>>>>
>>>>
>>>> On 18 December 2014 at 11:53, Anthony Jenkins  wrote:
>>>>> The attached patch seems to get my rfkill GPIO working.  It seems 
>>>>> ar9300_enable_rf_kill() is never called.  I added a call to it after 
>>>>> ath_hal_enable_rfkill(), but this is probably not the right place (I see 
>>>>> it called several times while the interface is up).
>>>>>
>>>>> I also found several spots in the GPIO handling code which give up if the 
>>>>> GPIO pin is 8, 9, 11 or greater than 13; my rfkill GPIO pin is 11 (0x0B). 
>>>>>  I commented these out:
>>>>>
>>>>>
>>>>> if ((gpio == AR9382_GPIO_PIN_8_RESERVED)  ||
>>>>> (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
>>>>> (gpio == AR9382_GPIO_9_INPUT_ONLY))
>>>>> {
>>>>> return AH_FALSE;
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
>>>>> (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
>>>>> (gpio > AR9382_MAX_GPIO_INPUT_PIN_NUM))
>>>>> {
>>>>> return;
>>>>> }
>>>>>
>>>>>
>>>>> Haven't narrowed down which is responsible for me being able to send this 
>>>>> email using my AR9565.  Also I'm getting flooded with these messages 
>>>>> since moving ath & wlan out of the kernel...my patch broke something, no?
>>>>>
>>>>> 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_rx

Re: Atheros AR9565 detected, not working

[Adrian Chadd]

See, that's where it's odd:

| EepromWriteGpio: 16, WlanDisableGpio: 0, WlanLedGpio: 8
RxBandSelectGpio: 255 |

.. how'd you figure out it's GPIO 11?



-adrian


On 22 December 2014 at 11:39, Anthony Jenkins  wrote:
> Logs attached.
>
> Thanks,
> Anthony
>
> On 12/22/2014 11:21, Adrian Chadd wrote:
>> Yeah, there's no GPIO check like there is in the reference code.
>>
>> The fact it says AR9382 is pretty telling. That's like it's asking for
>> a very specific NIC with very specific GPIO mappings. :(
>>
>>
>>
>> -adrian
>>
>>
>> On 22 December 2014 at 06:03, Anthony Jenkins  wrote:
>>> Will do.  I'm actually thinking about reverting my changes just to see if 
>>> stock ath(4) works (it's been a looong while since I played with bringing 
>>> it up).  I still occasionally see the same behavior I saw before my changes.
>>>
>>> I'm using a recent Linux kernel (which works out of the box) to get it 
>>> working in FreeBSD - the keyboard wi-fi LED and hotkey work perfectly there.
>>>
>>> Thanks,
>>> Anthony
>>>
>>> 
>>> From: Adrian Chadd 
>>> To: Anthony Jenkins 
>>> Cc: "wirel...@freebsd.org" 
>>> Sent: Sunday, December 21, 2014 9:39 PM
>>> Subject: Re: Atheros AR9565 detected, not working
>>>
>>>
>>> Hi!
>>>
>>> ok, how'd you build things? a module, or in the kernel?
>>>
>>> You need to (a) build it using 'make buildkernel / make installkernel'
>>> and (b) ensure ATH_ENABLE_11N is in your kernel configuration.
>>>
>>> The GPIO bits are a bit odd - let me check the other chipset drivers.
>>>
>>> Can you compile the tools in src/tools/tools/ath/ - then run this:
>>>
>>> ath_prom_dump -i ath0 -d /tmp/ath.dump
>>> ath_ee_9300_print /tmp/ath.dump > /tmp/ath.txt
>>>
>>> then email the contents of ath.txt . It'll include the GPIO pin id.
>>>
>>> Thanks!
>>>
>>>
>>>
>>> -adrian
>>>
>>>
>>>
>>> On 18 December 2014 at 11:53, Anthony Jenkins  wrote:
>>>> The attached patch seems to get my rfkill GPIO working.  It seems 
>>>> ar9300_enable_rf_kill() is never called.  I added a call to it after 
>>>> ath_hal_enable_rfkill(), but this is probably not the right place (I see 
>>>> it called several times while the interface is up).
>>>>
>>>> I also found several spots in the GPIO handling code which give up if the 
>>>> GPIO pin is 8, 9, 11 or greater than 13; my rfkill GPIO pin is 11 (0x0B).  
>>>> I commented these out:
>>>>
>>>>
>>>> if ((gpio == AR9382_GPIO_PIN_8_RESERVED)  ||
>>>> (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
>>>> (gpio == AR9382_GPIO_9_INPUT_ONLY))
>>>> {
>>>> return AH_FALSE;
>>>> }
>>>>
>>>>
>>>>
>>>> if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
>>>> (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
>>>> (gpio > AR9382_MAX_GPIO_INPUT_PIN_NUM))
>>>> {
>>>> return;
>>>> }
>>>>
>>>>
>>>> Haven't narrowed down which is responsible for me being able to send this 
>>>> email using my AR9565.  Also I'm getting flooded with these messages since 
>>>> moving ath & wlan out of the kernel...my patch broke something, no?
>>>>
>>>> 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=1, nbufs=128?
>>>> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
>>>> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
>>>>
>>>>
>>>> Anthony
>>>> 
>>>> From: Adrian Chadd 
>>>> To: Anthony Jenkins 
>>>> Cc: "freebsd-wireless@freebsd.org" 
>>>> Sent: Monday, July 29, 2013 10:44 AM
>>>> Subject: Re: Atheros AR9565 detected, not working
>>>>
>>>>
>&

Re: Atheros AR9565 detected, not working

[Adrian Chadd]

Yeah, there's no GPIO check like there is in the reference code.

The fact it says AR9382 is pretty telling. That's like it's asking for
a very specific NIC with very specific GPIO mappings. :(



-adrian


On 22 December 2014 at 06:03, Anthony Jenkins  wrote:
> Will do.  I'm actually thinking about reverting my changes just to see if 
> stock ath(4) works (it's been a looong while since I played with bringing it 
> up).  I still occasionally see the same behavior I saw before my changes.
>
> I'm using a recent Linux kernel (which works out of the box) to get it 
> working in FreeBSD - the keyboard wi-fi LED and hotkey work perfectly there.
>
> Thanks,
> Anthony
>
> 
> From: Adrian Chadd 
> To: Anthony Jenkins 
> Cc: "wirel...@freebsd.org" 
> Sent: Sunday, December 21, 2014 9:39 PM
> Subject: Re: Atheros AR9565 detected, not working
>
>
> Hi!
>
> ok, how'd you build things? a module, or in the kernel?
>
> You need to (a) build it using 'make buildkernel / make installkernel'
> and (b) ensure ATH_ENABLE_11N is in your kernel configuration.
>
> The GPIO bits are a bit odd - let me check the other chipset drivers.
>
> Can you compile the tools in src/tools/tools/ath/ - then run this:
>
> ath_prom_dump -i ath0 -d /tmp/ath.dump
> ath_ee_9300_print /tmp/ath.dump > /tmp/ath.txt
>
> then email the contents of ath.txt . It'll include the GPIO pin id.
>
> Thanks!
>
>
>
> -adrian
>
>
>
> On 18 December 2014 at 11:53, Anthony Jenkins  wrote:
>> The attached patch seems to get my rfkill GPIO working.  It seems 
>> ar9300_enable_rf_kill() is never called.  I added a call to it after 
>> ath_hal_enable_rfkill(), but this is probably not the right place (I see it 
>> called several times while the interface is up).
>>
>> I also found several spots in the GPIO handling code which give up if the 
>> GPIO pin is 8, 9, 11 or greater than 13; my rfkill GPIO pin is 11 (0x0B).  I 
>> commented these out:
>>
>>
>> if ((gpio == AR9382_GPIO_PIN_8_RESERVED)  ||
>> (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
>> (gpio == AR9382_GPIO_9_INPUT_ONLY))
>> {
>> return AH_FALSE;
>> }
>>
>>
>>
>> if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
>> (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
>> (gpio > AR9382_MAX_GPIO_INPUT_PIN_NUM))
>> {
>> return;
>> }
>>
>>
>> Haven't narrowed down which is responsible for me being able to send this 
>> email using my AR9565.  Also I'm getting flooded with these messages since 
>> moving ath & wlan out of the kernel...my patch broke something, no?
>>
>> 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=1, nbufs=128?
>> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
>> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
>>
>>
>> Anthony
>> 
>> From: Adrian Chadd 
>> To: Anthony Jenkins 
>> Cc: "freebsd-wireless@freebsd.org" 
>> Sent: Monday, July 29, 2013 10:44 AM
>> Subject: Re: Atheros AR9565 detected, not working
>>
>>
>> Cool, thanks.
>>
>> Please make sure you post patches for all the things you fix. I'd love
>> to see this kind of thing work out of the box. :)
>>
>>
>> -adrian
>>
>> On 29 July 2013 07:36, Anthony Jenkins  wrote:
>>> Thanks Adrian,
>>>
>>> I've managed to fix a few things on this laptop, the remaining stuff is
>>> BIOS/ACPI related.  acpi_hp(4) isn't working, has something to do with WMI.
>>> Hoping if I fix the ACPI stuff I can
>> have me AR9565 working.  I'll poke
>>> around and report back; the RFKill suggestion is a good place to start
>>> looking.
>>>
>>> Thanks,
>>> Anthony
>>>
>>>
>>> On 07/29/13 10:30, Adrian Chadd wrote:
>>>>
>>>> Hm, maybe rfkill is set?
>>>>
>>>> The AR9565 is supported. I have the reference NICs from Atheros; they
>>>> work just fine.
>>>>
>>>> It may be some kind of ACPI setting to enable/disable RFKill so the
>>>> radio side is actually enabled.
>

Re: Atheros AR9565 detected, not working

[Anthony Jenkins via freebsd-wireless]

Will do.  I'm actually thinking about reverting my changes just to see if stock 
ath(4) works (it's been a looong while since I played with bringing it up).  I 
still occasionally see the same behavior I saw before my changes.

I'm using a recent Linux kernel (which works out of the box) to get it working 
in FreeBSD - the keyboard wi-fi LED and hotkey work perfectly there.

Thanks,
Anthony


From: Adrian Chadd 
To: Anthony Jenkins  
Cc: "wirel...@freebsd.org"  
Sent: Sunday, December 21, 2014 9:39 PM
Subject: Re: Atheros AR9565 detected, not working


Hi!

ok, how'd you build things? a module, or in the kernel?

You need to (a) build it using 'make buildkernel / make installkernel'
and (b) ensure ATH_ENABLE_11N is in your kernel configuration.

The GPIO bits are a bit odd - let me check the other chipset drivers.

Can you compile the tools in src/tools/tools/ath/ - then run this:

ath_prom_dump -i ath0 -d /tmp/ath.dump
ath_ee_9300_print /tmp/ath.dump > /tmp/ath.txt

then email the contents of ath.txt . It'll include the GPIO pin id.

Thanks!



-adrian



On 18 December 2014 at 11:53, Anthony Jenkins  wrote:
> The attached patch seems to get my rfkill GPIO working.  It seems 
> ar9300_enable_rf_kill() is never called.  I added a call to it after 
> ath_hal_enable_rfkill(), but this is probably not the right place (I see it 
> called several times while the interface is up).
>
> I also found several spots in the GPIO handling code which give up if the 
> GPIO pin is 8, 9, 11 or greater than 13; my rfkill GPIO pin is 11 (0x0B).  I 
> commented these out:
>
>
> if ((gpio == AR9382_GPIO_PIN_8_RESERVED)  ||
> (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
> (gpio == AR9382_GPIO_9_INPUT_ONLY))
> {
> return AH_FALSE;
> }
>
>
>
> if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
> (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
> (gpio > AR9382_MAX_GPIO_INPUT_PIN_NUM))
> {
> return;
> }
>
>
> Haven't narrowed down which is responsible for me being able to send this 
> email using my AR9565.  Also I'm getting flooded with these messages since 
> moving ath & wlan out of the kernel...my patch broke something, no?
>
> 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=1, nbufs=128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
>
>
> Anthony
> 
> From: Adrian Chadd 
> To: Anthony Jenkins 
> Cc: "freebsd-wireless@freebsd.org" 
> Sent: Monday, July 29, 2013 10:44 AM
> Subject: Re: Atheros AR9565 detected, not working
>
>
> Cool, thanks.
>
> Please make sure you post patches for all the things you fix. I'd love
> to see this kind of thing work out of the box. :)
>
>
> -adrian
>
> On 29 July 2013 07:36, Anthony Jenkins  wrote:
>> Thanks Adrian,
>>
>> I've managed to fix a few things on this laptop, the remaining stuff is
>> BIOS/ACPI related.  acpi_hp(4) isn't working, has something to do with WMI.
>> Hoping if I fix the ACPI stuff I can
> have me AR9565 working.  I'll poke
>> around and report back; the RFKill suggestion is a good place to start
>> looking.
>>
>> Thanks,
>> Anthony
>>
>>
>> On 07/29/13 10:30, Adrian Chadd wrote:
>>>
>>> Hm, maybe rfkill is set?
>>>
>>> The AR9565 is supported. I have the reference NICs from Atheros; they
>>> work just fine.
>>>
>>> It may be some kind of ACPI setting to enable/disable RFKill so the
>>> radio side is actually enabled.
>>>
>>> I'm sorry, I don't have much more than that to offer without having
>>> the laptop here.
>>>
>>> If someone's willing to send me one, I'll get 10 + wireless working on
>>> it and then hand it over to ixsystems to join the 'stuff we really
>>> should get pcbsd running smoothly on' pile. They're about $500 off of
>>>
> amazon.com.
>>>
>>> Thanks,
>>>
>>>
>>>
>>> -adrian
>>>
>>> On 29 July 2013 07:21, Anthony Jenkins  wrote:
>>>>
>>>> I just got an HP ENVY Sleekbook 6z-1100 laptop hoping it came with a
>>>> FreeBSD-supported wireless NIC.  It has an Atheros AR9565 and looki

Re: Atheros AR9565 detected, not working

[Adrian Chadd]

Oh, and ath_hal_enable_rfkill() maps to setting the capability bit:

#define ath_hal_enable_rfkill(_ah, _v) \
ath_hal_setcapability(_ah, HAL_CAP_RFSILENT, 1, _v, AH_NULL)

.. so, the AR9300 HAL code is enabling RFKILL in the HAL and then the
call to ar9300_enable_rf_kill() is unconditionally turning it on. We
likely can't do that for everyone.

So, I wonder why this is required for you!



-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: Atheros AR9565 detected, not working

[Adrian Chadd]

Hi!

ok, how'd you build things? a module, or in the kernel?

You need to (a) build it using 'make buildkernel / make installkernel'
and (b) ensure ATH_ENABLE_11N is in your kernel configuration.

The GPIO bits are a bit odd - let me check the other chipset drivers.

Can you compile the tools in src/tools/tools/ath/ - then run this:

ath_prom_dump -i ath0 -d /tmp/ath.dump
ath_ee_9300_print /tmp/ath.dump > /tmp/ath.txt

then email the contents of ath.txt . It'll include the GPIO pin id.

Thanks!



-adrian



On 18 December 2014 at 11:53, Anthony Jenkins  wrote:
> The attached patch seems to get my rfkill GPIO working.  It seems 
> ar9300_enable_rf_kill() is never called.  I added a call to it after 
> ath_hal_enable_rfkill(), but this is probably not the right place (I see it 
> called several times while the interface is up).
>
> I also found several spots in the GPIO handling code which give up if the 
> GPIO pin is 8, 9, 11 or greater than 13; my rfkill GPIO pin is 11 (0x0B).  I 
> commented these out:
>
>
> if ((gpio == AR9382_GPIO_PIN_8_RESERVED)  ||
> (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
> (gpio == AR9382_GPIO_9_INPUT_ONLY))
> {
> return AH_FALSE;
> }
>
>
>
> if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
> (gpio == AR9382_GPIO_PIN_11_RESERVED) ||
> (gpio > AR9382_MAX_GPIO_INPUT_PIN_NUM))
> {
> return;
> }
>
>
> Haven't narrowed down which is responsible for me being able to send this 
> email using my AR9565.  Also I'm getting flooded with these messages since 
> moving ath & wlan out of the kernel...my patch broke something, no?
>
> 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=1, nbufs=128?
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
>
>
> Anthony
> ____
> From: Adrian Chadd 
> To: Anthony Jenkins 
> Cc: "freebsd-wireless@freebsd.org" 
> Sent: Monday, July 29, 2013 10:44 AM
> Subject: Re: Atheros AR9565 detected, not working
>
>
> Cool, thanks.
>
> Please make sure you post patches for all the things you fix. I'd love
> to see this kind of thing work out of the box. :)
>
>
> -adrian
>
> On 29 July 2013 07:36, Anthony Jenkins  wrote:
>> Thanks Adrian,
>>
>> I've managed to fix a few things on this laptop, the remaining stuff is
>> BIOS/ACPI related.  acpi_hp(4) isn't working, has something to do with WMI.
>> Hoping if I fix the ACPI stuff I can
> have me AR9565 working.  I'll poke
>> around and report back; the RFKill suggestion is a good place to start
>> looking.
>>
>> Thanks,
>> Anthony
>>
>>
>> On 07/29/13 10:30, Adrian Chadd wrote:
>>>
>>> Hm, maybe rfkill is set?
>>>
>>> The AR9565 is supported. I have the reference NICs from Atheros; they
>>> work just fine.
>>>
>>> It may be some kind of ACPI setting to enable/disable RFKill so the
>>> radio side is actually enabled.
>>>
>>> I'm sorry, I don't have much more than that to offer without having
>>> the laptop here.
>>>
>>> If someone's willing to send me one, I'll get 10 + wireless working on
>>> it and then hand it over to ixsystems to join the 'stuff we really
>>> should get pcbsd running smoothly on' pile. They're about $500 off of
>>>
> amazon.com.
>>>
>>> Thanks,
>>>
>>>
>>>
>>> -adrian
>>>
>>> On 29 July 2013 07:21, Anthony Jenkins  wrote:
>>>>
>>>> I just got an HP ENVY Sleekbook 6z-1100 laptop hoping it came with a
>>>> FreeBSD-supported wireless NIC.  It has an Atheros AR9565 and looking at
>>>> the
>>>> logs it _seems_ like it should be working, but I get no network traffic.
>>>> I
>>>> haven't started the Atheros debugging procedure yet, save to compile in
>>>> option AH_DEBUG and move ath(4) out of the kernel & to a module to
>>>> facilitate changes.  Works (of course) in Win8 which came with laptop.
>>>> Wireless enabled LED is amber (disabled) in FreeBSD, goes from amber
> to
>>>> white (enabled) when I boot the Win8 HDD.
>>>>
>>>> Here's various

Re: Atheros AR9565 detected, not working

[Anthony Jenkins via freebsd-wireless]

The attached patch seems to get my rfkill GPIO working.  It seems 
ar9300_enable_rf_kill() is never called.  I added a call to it after 
ath_hal_enable_rfkill(), but this is probably not the right place (I see it 
called several times while the interface is up).

I also found several spots in the GPIO handling code which give up if the GPIO 
pin is 8, 9, 11 or greater than 13; my rfkill GPIO pin is 11 (0x0B).  I 
commented these out:


if ((gpio == AR9382_GPIO_PIN_8_RESERVED)  ||
(gpio == AR9382_GPIO_PIN_11_RESERVED) ||
(gpio == AR9382_GPIO_9_INPUT_ONLY))
{
return AH_FALSE;
}



if ((gpio == AR9382_GPIO_PIN_8_RESERVED) ||
(gpio == AR9382_GPIO_PIN_11_RESERVED) ||
(gpio > AR9382_MAX_GPIO_INPUT_PIN_NUM))
{
return;
}


Haven't narrowed down which is responsible for me being able to send this email 
using my AR9565.  Also I'm getting flooded with these messages since moving ath 
& wlan out of the kernel...my patch broke something, no?

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=1, nbufs=128?
ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?


Anthony

From: Adrian Chadd 
To: Anthony Jenkins  
Cc: "freebsd-wireless@freebsd.org"  
Sent: Monday, July 29, 2013 10:44 AM
Subject: Re: Atheros AR9565 detected, not working


Cool, thanks.

Please make sure you post patches for all the things you fix. I'd love
to see this kind of thing work out of the box. :)


-adrian

On 29 July 2013 07:36, Anthony Jenkins  wrote:
> Thanks Adrian,
>
> I've managed to fix a few things on this laptop, the remaining stuff is
> BIOS/ACPI related.  acpi_hp(4) isn't working, has something to do with WMI.
> Hoping if I fix the ACPI stuff I can
have me AR9565 working.  I'll poke
> around and report back; the RFKill suggestion is a good place to start
> looking.
>
> Thanks,
> Anthony
>
>
> On 07/29/13 10:30, Adrian Chadd wrote:
>>
>> Hm, maybe rfkill is set?
>>
>> The AR9565 is supported. I have the reference NICs from Atheros; they
>> work just fine.
>>
>> It may be some kind of ACPI setting to enable/disable RFKill so the
>> radio side is actually enabled.
>>
>> I'm sorry, I don't have much more than that to offer without having
>> the laptop here.
>>
>> If someone's willing to send me one, I'll get 10 + wireless working on
>> it and then hand it over to ixsystems to join the 'stuff we really
>> should get pcbsd running smoothly on' pile. They're about $500 off of
>>
amazon.com.
>>
>> Thanks,
>>
>>
>>
>> -adrian
>>
>> On 29 July 2013 07:21, Anthony Jenkins  wrote:
>>>
>>> I just got an HP ENVY Sleekbook 6z-1100 laptop hoping it came with a
>>> FreeBSD-supported wireless NIC.  It has an Atheros AR9565 and looking at
>>> the
>>> logs it _seems_ like it should be working, but I get no network traffic.
>>> I
>>> haven't started the Atheros debugging procedure yet, save to compile in
>>> option AH_DEBUG and move ath(4) out of the kernel & to a module to
>>> facilitate changes.  Works (of course) in Win8 which came with laptop.
>>> Wireless enabled LED is amber (disabled) in FreeBSD, goes from amber
to
>>> white (enabled) when I boot the Win8 HDD.
>>>
>>> Here's various logs and misc. system info.  What should I try next?
>>> Thanks
>>> in advance!
>>>
>>> [root@laptop /usr/src]# uname -a n
>>> FreeBSD laptop.qtchat.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sat Jul
>>> 27
>>> 23:45:30 EDT 2013 r...@laptop.qtchat.org:/usr/obj/usr/src/sys/MYKERNEL
>>> amd64
>>>
>>> [root@laptop /usr/src]# dmesg
>>> Copyright (c) 1992-2013 The FreeBSD Project.
>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>>  The Regents
of the University of California. All rights reserved.
>>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>>> FreeBSD 10.0-CURRENT #0: Sat Jul 27 23:45:30 EDT 2013
>>>  r...@laptop.qtchat.org:/usr/obj/usr/src/sys/MYKERNEL amd64
>>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>>> module_register: module pci/xhci already exists!
>>> Module pci/xhci failed to register: 17
>>> CPU: AMD A10-4655

Re: Atheros AR9565

[Adrian Chadd]

It could be a GPIO rfkill setup thing that requires ACPI hacking.

Honestly - the easiest way to get it going is for someone to spring
the $500 or so and by me one. :-)


-a


On 11 April 2014 07:09, Anthony Jenkins  wrote:
> I'll stick -CURRENT back on it and see if it works...
>
> Nope, my AR9565 won't connect to an access point.  The wireless LED on the HP 
> ENVY Sleekbook wireless key is amber (off) and pressing Fn+wireless key 
> doesn't do anything.  GPIO or something?  I can get you log output from 
> 'wpa_supplicant -d -d' or ath(4) debug messages or whatever, or can send the 
> device (I kinda wanna keep the laptop :-) ).
>
> Anthony
>
>
> - Original Message -
> From: Adrian Chadd 
> To: Anthony Jenkins 
> Cc: tzoi516 ; "freebsd-wireless@freebsd.org" 
> 
> Sent: Thursday, April 10, 2014 12:25 PM
> Subject: Re: Atheros AR9565
>
> Hm,
>
> I think someone needs to buy me one of these. The AR9565 that I had
> tried on worked fine.
>
>
> -a
>
>
>
> On 10 April 2014 05:59, Anthony Jenkins  wrote:
>> HP ENVY 6Z-1100 Sleekbook
>>
>> Sorry, tried replying with a URL to HP's product website, but must've gotten 
>> blocked.  Also my original (brief) email thread on my AR9565 was in July 
>> '13, not August.
>>
>> Anthony
>>
>> On 04/09/2014 05:18 PM, Adrian Chadd wrote:
>>> Which HP laptop?
>>>
>>>
>>> -a
>>>
>>>
>>> On 9 April 2014 13:35, Anthony Jenkins  wrote:
>>>> Hey, I've got one of these babies in my HP laptop; I actually posted some 
>>>> problems I was having to the list back in Aug. '13.  I could loan you mine 
>>>> and/or assist with debugging if I can have it back (can make do with an 
>>>> external wireless device).
>>>>
>>>>
>>>> Anthony
>>>>
>>>>
>>>> 
>>>> From: Adrian Chadd 
>>>> To: tzoi516 
>>>> Cc: "freebsd-wireless@freebsd.org" 
>>>> Sent: Wednesday, April 9, 2014 3:02 PM
>>>> Subject: Re: Re: Atheros AR9565
>>>>
>>>>
>>>> Hi,
>>>>
>>>> The AR9565 is a relatively new chip that hasn't really been thoroughly
>>>> tested in FreeBSD. Laptop manufacturers have also gone and done some
>>>> rather silly things to save cost on the wireless NIC itself and I'm
>>>> not sure those patches / work arounds are in -HEAD.
>>>>
>>>> please file a PR with this problem complete with your pciconf -lv
>>>> output as above.
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> -a
>>>>
>>>>
>>>> On 9 April 2014 05:40, tzoi516  wrote:
>>>>> I'm using the GENERIC kernel. Want me to create a custom kernel?
>>>>>
>>>>> pciconf info:
>>>>>
>>>>> hostb0@pci0:0:0:0:class=0x06 card=0xfa401179 chip=0x0c048086
>>>>> rev=0x06 hdr=0x00
>>>>> vendor = 'Intel Corporation'
>>>>> device = 'Haswell DRAM Controller'
>>>>> class  = bridge
>>>>> subclass   = HOST-PCI
>>>>> pcib1@pci0:0:1:0:class=0x060400 card=0xfa471179 chip=0x0c018086
>>>>> rev=0x06 hdr=0x01
>>>>> vendor = 'Intel Corporation'
>>>>> device = 'Haswell PCI Express x16 Controller'
>>>>> class  = bridge
>>>>> subclass   = PCI-PCI
>>>>> vgapci1@pci0:0:2:0:class=0x03 card=0xfa471179 chip=0x04168086
>>>>> rev=0x06 hdr=0x00
>>>>> vendor = 'Intel Corporation'
>>>>> device = 'Haswell Integrated Graphics Controller'
>>>>> class  = display
>>>>> subclass   = VGA
>>>>> hdac0@pci0:0:3:0:class=0x040300 card=0xfa4d1179 chip=0x0c0c8086
>>>>> rev=0x06 hdr=0x00
>>>>> vendor = 'Intel Corporation'
>>>>> device = 'Haswell HD Audio Controller'
>>>>> class  = multimedia
>>>>> subclass   = HDA
>>>>> xhci0@pci0:0:20:0:class=0x0c0330 card=0xfa401179 chip=0x8c318086
>>>>> rev=0x04 hdr=0x00
>>>>> vendor = 'Intel Corporation'
>>>>> device = 'Lynx Point USB xHCI Hos

Re: Atheros AR9565

[Anthony Jenkins]

I'll stick -CURRENT back on it and see if it works...

Nope, my AR9565 won't connect to an access point.  The wireless LED on the HP 
ENVY Sleekbook wireless key is amber (off) and pressing Fn+wireless key doesn't 
do anything.  GPIO or something?  I can get you log output from 'wpa_supplicant 
-d -d' or ath(4) debug messages or whatever, or can send the device (I kinda 
wanna keep the laptop :-) ).

Anthony


- Original Message -
From: Adrian Chadd 
To: Anthony Jenkins 
Cc: tzoi516 ; "freebsd-wireless@freebsd.org" 

Sent: Thursday, April 10, 2014 12:25 PM
Subject: Re: Atheros AR9565

Hm,

I think someone needs to buy me one of these. The AR9565 that I had
tried on worked fine.


-a



On 10 April 2014 05:59, Anthony Jenkins  wrote:
> HP ENVY 6Z-1100 Sleekbook
>
> Sorry, tried replying with a URL to HP's product website, but must've gotten 
> blocked.  Also my original (brief) email thread on my AR9565 was in July '13, 
> not August.
>
> Anthony
>
> On 04/09/2014 05:18 PM, Adrian Chadd wrote:
>> Which HP laptop?
>>
>>
>> -a
>>
>>
>> On 9 April 2014 13:35, Anthony Jenkins  wrote:
>>> Hey, I've got one of these babies in my HP laptop; I actually posted some 
>>> problems I was having to the list back in Aug. '13.  I could loan you mine 
>>> and/or assist with debugging if I can have it back (can make do with an 
>>> external wireless device).
>>>
>>>
>>> Anthony
>>>
>>>
>>> 
>>> From: Adrian Chadd 
>>> To: tzoi516 
>>> Cc: "freebsd-wireless@freebsd.org" 
>>> Sent: Wednesday, April 9, 2014 3:02 PM
>>> Subject: Re: Re: Atheros AR9565
>>>
>>>
>>> Hi,
>>>
>>> The AR9565 is a relatively new chip that hasn't really been thoroughly
>>> tested in FreeBSD. Laptop manufacturers have also gone and done some
>>> rather silly things to save cost on the wireless NIC itself and I'm
>>> not sure those patches / work arounds are in -HEAD.
>>>
>>> please file a PR with this problem complete with your pciconf -lv
>>> output as above.
>>>
>>> Thanks!
>>>
>>>
>>> -a
>>>
>>>
>>> On 9 April 2014 05:40, tzoi516  wrote:
>>>> I'm using the GENERIC kernel. Want me to create a custom kernel?
>>>>
>>>> pciconf info:
>>>>
>>>> hostb0@pci0:0:0:0:    class=0x06 card=0xfa401179 chip=0x0c048086
>>>> rev=0x06 hdr=0x00
>>>>     vendor     = 'Intel Corporation'
>>>>     device     = 'Haswell DRAM Controller'
>>>>     class      = bridge
>>>>     subclass   = HOST-PCI
>>>> pcib1@pci0:0:1:0:    class=0x060400 card=0xfa471179 chip=0x0c018086
>>>> rev=0x06 hdr=0x01
>>>>     vendor     = 'Intel Corporation'
>>>>     device     = 'Haswell PCI Express x16 Controller'
>>>>     class      = bridge
>>>>     subclass   = PCI-PCI
>>>> vgapci1@pci0:0:2:0:    class=0x03 card=0xfa471179 chip=0x04168086
>>>> rev=0x06 hdr=0x00
>>>>     vendor     = 'Intel Corporation'
>>>>     device     = 'Haswell Integrated Graphics Controller'
>>>>     class      = display
>>>>     subclass   = VGA
>>>> hdac0@pci0:0:3:0:    class=0x040300 card=0xfa4d1179 chip=0x0c0c8086
>>>> rev=0x06 hdr=0x00
>>>>     vendor     = 'Intel Corporation'
>>>>     device     = 'Haswell HD Audio Controller'
>>>>     class      = multimedia
>>>>     subclass   = HDA
>>>> xhci0@pci0:0:20:0:    class=0x0c0330 card=0xfa401179 chip=0x8c318086
>>>> rev=0x04 hdr=0x00
>>>>     vendor     = 'Intel Corporation'
>>>>     device     = 'Lynx Point USB xHCI Host Controller'
>>>>     class      = serial bus
>>>>     subclass   = USB
>>>> none0@pci0:0:22:0:    class=0x078000 card=0xfa401179 chip=0x8c3a8086
>>>> rev=0x04 hdr=0x00
>>>>     vendor     = 'Intel Corporation'
>>>>     device     = 'Lynx Point MEI Controller'
>>>>     class      = simple comms
>>>> ehci0@pci0:0:26:0:    class=0x0c0320 card=0xfa401179 chip=0x8c2d8086
>>>> rev=0x04 hdr=0x00
>>>>     vendor     = 'Intel Corporation'
>>>>     device     = 'Lynx Point USB Enhanced Host Controller'
>>>>

Re: Atheros AR9565

[Adrian Chadd]

Hm,

I think someone needs to buy me one of these. The AR9565 that I had
tried on worked fine.


-a


On 10 April 2014 05:59, Anthony Jenkins  wrote:
> HP ENVY 6Z-1100 Sleekbook
>
> Sorry, tried replying with a URL to HP's product website, but must've gotten 
> blocked.  Also my original (brief) email thread on my AR9565 was in July '13, 
> not August.
>
> Anthony
>
> On 04/09/2014 05:18 PM, Adrian Chadd wrote:
>> Which HP laptop?
>>
>>
>> -a
>>
>>
>> On 9 April 2014 13:35, Anthony Jenkins  wrote:
>>> Hey, I've got one of these babies in my HP laptop; I actually posted some 
>>> problems I was having to the list back in Aug. '13.  I could loan you mine 
>>> and/or assist with debugging if I can have it back (can make do with an 
>>> external wireless device).
>>>
>>>
>>> Anthony
>>>
>>>
>>> ____
>>> From: Adrian Chadd 
>>> To: tzoi516 
>>> Cc: "freebsd-wireless@freebsd.org" 
>>> Sent: Wednesday, April 9, 2014 3:02 PM
>>> Subject: Re: Re: Atheros AR9565
>>>
>>>
>>> Hi,
>>>
>>> The AR9565 is a relatively new chip that hasn't really been thoroughly
>>> tested in FreeBSD. Laptop manufacturers have also gone and done some
>>> rather silly things to save cost on the wireless NIC itself and I'm
>>> not sure those patches / work arounds are in -HEAD.
>>>
>>> please file a PR with this problem complete with your pciconf -lv
>>> output as above.
>>>
>>> Thanks!
>>>
>>>
>>> -a
>>>
>>>
>>> On 9 April 2014 05:40, tzoi516  wrote:
>>>> I'm using the GENERIC kernel. Want me to create a custom kernel?
>>>>
>>>> pciconf info:
>>>>
>>>> hostb0@pci0:0:0:0:class=0x06 card=0xfa401179 chip=0x0c048086
>>>> rev=0x06 hdr=0x00
>>>> vendor = 'Intel Corporation'
>>>> device = 'Haswell DRAM Controller'
>>>> class  = bridge
>>>> subclass   = HOST-PCI
>>>> pcib1@pci0:0:1:0:class=0x060400 card=0xfa471179 chip=0x0c018086
>>>> rev=0x06 hdr=0x01
>>>> vendor = 'Intel Corporation'
>>>> device = 'Haswell PCI Express x16 Controller'
>>>> class  = bridge
>>>> subclass   = PCI-PCI
>>>> vgapci1@pci0:0:2:0:class=0x03 card=0xfa471179 chip=0x04168086
>>>> rev=0x06 hdr=0x00
>>>> vendor = 'Intel Corporation'
>>>> device = 'Haswell Integrated Graphics Controller'
>>>> class  = display
>>>> subclass   = VGA
>>>> hdac0@pci0:0:3:0:class=0x040300 card=0xfa4d1179 chip=0x0c0c8086
>>>> rev=0x06 hdr=0x00
>>>> vendor = 'Intel Corporation'
>>>> device = 'Haswell HD Audio Controller'
>>>> class  = multimedia
>>>> subclass   = HDA
>>>> xhci0@pci0:0:20:0:class=0x0c0330 card=0xfa401179 chip=0x8c318086
>>>> rev=0x04 hdr=0x00
>>>> vendor = 'Intel Corporation'
>>>> device = 'Lynx Point USB xHCI Host Controller'
>>>> class  = serial bus
>>>> subclass   = USB
>>>> none0@pci0:0:22:0:class=0x078000 card=0xfa401179 chip=0x8c3a8086
>>>> rev=0x04 hdr=0x00
>>>> vendor = 'Intel Corporation'
>>>> device = 'Lynx Point MEI Controller'
>>>> class  = simple comms
>>>> ehci0@pci0:0:26:0:class=0x0c0320 card=0xfa401179 chip=0x8c2d8086
>>>> rev=0x04 hdr=0x00
>>>> vendor = 'Intel Corporation'
>>>> device = 'Lynx Point USB Enhanced Host Controller'
>>>> class  = serial bus
>>>> subclass   = USB
>>>> hdac1@pci0:0:27:0:class=0x040300 card=0xfa4d1179 chip=0x8c208086
>>>> rev=0x04 hdr=0x00
>>>> vendor = 'Intel Corporation'
>>>> device = 'Lynx Point High Definition Audio Controller'
>>>> class  = multimedia
>>>> subclass   = HDA
>>>> pcib2@pci0:0:28:0:class=0x060400 card=0xfa401179 chip=0x8c108086
>>>> rev=0xd4 hdr=0x01
>>>> vendor = 'Intel Corporation'
>>>>  

Re: Atheros AR9565

[Anthony Jenkins]

HP ENVY 6Z-1100 Sleekbook

Sorry, tried replying with a URL to HP's product website, but must've gotten 
blocked.  Also my original (brief) email thread on my AR9565 was in July '13, 
not August.

Anthony

On 04/09/2014 05:18 PM, Adrian Chadd wrote:
> Which HP laptop?
>
>
> -a
>
>
> On 9 April 2014 13:35, Anthony Jenkins  wrote:
>> Hey, I've got one of these babies in my HP laptop; I actually posted some 
>> problems I was having to the list back in Aug. '13.  I could loan you mine 
>> and/or assist with debugging if I can have it back (can make do with an 
>> external wireless device).
>>
>>
>> Anthony
>>
>>
>> 
>> From: Adrian Chadd 
>> To: tzoi516 
>> Cc: "freebsd-wireless@freebsd.org" 
>> Sent: Wednesday, April 9, 2014 3:02 PM
>> Subject: Re: Re: Atheros AR9565
>>
>>
>> Hi,
>>
>> The AR9565 is a relatively new chip that hasn't really been thoroughly
>> tested in FreeBSD. Laptop manufacturers have also gone and done some
>> rather silly things to save cost on the wireless NIC itself and I'm
>> not sure those patches / work arounds are in -HEAD.
>>
>> please file a PR with this problem complete with your pciconf -lv
>> output as above.
>>
>> Thanks!
>>
>>
>> -a
>>
>>
>> On 9 April 2014 05:40, tzoi516  wrote:
>>> I'm using the GENERIC kernel. Want me to create a custom kernel?
>>>
>>> pciconf info:
>>>
>>> hostb0@pci0:0:0:0:class=0x06 card=0xfa401179 chip=0x0c048086
>>> rev=0x06 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Haswell DRAM Controller'
>>> class  = bridge
>>> subclass   = HOST-PCI
>>> pcib1@pci0:0:1:0:class=0x060400 card=0xfa471179 chip=0x0c018086
>>> rev=0x06 hdr=0x01
>>> vendor = 'Intel Corporation'
>>> device = 'Haswell PCI Express x16 Controller'
>>> class  = bridge
>>> subclass   = PCI-PCI
>>> vgapci1@pci0:0:2:0:class=0x03 card=0xfa471179 chip=0x04168086
>>> rev=0x06 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Haswell Integrated Graphics Controller'
>>> class  = display
>>> subclass   = VGA
>>> hdac0@pci0:0:3:0:class=0x040300 card=0xfa4d1179 chip=0x0c0c8086
>>> rev=0x06 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Haswell HD Audio Controller'
>>> class  = multimedia
>>> subclass   = HDA
>>> xhci0@pci0:0:20:0:class=0x0c0330 card=0xfa401179 chip=0x8c318086
>>> rev=0x04 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point USB xHCI Host Controller'
>>> class  = serial bus
>>> subclass   = USB
>>> none0@pci0:0:22:0:class=0x078000 card=0xfa401179 chip=0x8c3a8086
>>> rev=0x04 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point MEI Controller'
>>> class  = simple comms
>>> ehci0@pci0:0:26:0:class=0x0c0320 card=0xfa401179 chip=0x8c2d8086
>>> rev=0x04 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point USB Enhanced Host Controller'
>>> class  = serial bus
>>> subclass   = USB
>>> hdac1@pci0:0:27:0:class=0x040300 card=0xfa4d1179 chip=0x8c208086
>>> rev=0x04 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point High Definition Audio Controller'
>>> class  = multimedia
>>> subclass   = HDA
>>> pcib2@pci0:0:28:0:class=0x060400 card=0xfa401179 chip=0x8c108086
>>> rev=0xd4 hdr=0x01
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point PCI Express Root Port'
>>> class  = bridge
>>> subclass   = PCI-PCI
>>> pcib3@pci0:0:28:2:class=0x060400 card=0xfa401179 chip=0x8c148086
>>> rev=0xd4 hdr=0x01
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point PCI Express Root Port'
>>> class  = bridge
>>> subclass   = PCI-PCI
>>> pcib4@pci0:0:28:3:class=0x060400 card=0xfa401179 chip=0x8c168086
>>> rev=0xd4 hdr=0x01
>>&g

Re: Re: Atheros AR9565

[Anthony Jenkins]

HP ENVY 6Z-1100 Sleekbook
http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&dlc=en&lc=en&product=5330122


Anthony



- Original Message -
From: Adrian Chadd 
To: Anthony Jenkins 
Cc: tzoi516 ; "freebsd-wireless@freebsd.org" 

Sent: Wednesday, April 9, 2014 5:18 PM
Subject: Re: Re: Atheros AR9565

Which HP laptop?


-a



On 9 April 2014 13:35, Anthony Jenkins  wrote:
> Hey, I've got one of these babies in my HP laptop; I actually posted some 
> problems I was having to the list back in Aug. '13.  I could loan you mine 
> and/or assist with debugging if I can have it back (can make do with an 
> external wireless device).
>
>
> Anthony
>
>
> 
> From: Adrian Chadd 
> To: tzoi516 
> Cc: "freebsd-wireless@freebsd.org" 
> Sent: Wednesday, April 9, 2014 3:02 PM
> Subject: Re: Re: Atheros AR9565
>
>
> Hi,
>
> The AR9565 is a relatively new chip that hasn't really been thoroughly
> tested in FreeBSD. Laptop manufacturers have also gone and done some
> rather silly things to save cost on the wireless NIC itself and I'm
> not sure those patches / work arounds are in -HEAD.
>
> please file a PR with this problem complete with your pciconf -lv
> output as above.
>
> Thanks!
>
>
> -a
>
>
> On 9 April 2014 05:40, tzoi516  wrote:
>> I'm using the GENERIC kernel. Want me to create a custom kernel?
>>
>> pciconf info:
>>
>> hostb0@pci0:0:0:0:    class=0x06 card=0xfa401179 chip=0x0c048086
>> rev=0x06 hdr=0x00
>>     vendor     = 'Intel Corporation'
>>     device     = 'Haswell DRAM Controller'
>>     class      = bridge
>>     subclass   = HOST-PCI
>> pcib1@pci0:0:1:0:    class=0x060400 card=0xfa471179 chip=0x0c018086
>> rev=0x06 hdr=0x01
>>     vendor     = 'Intel Corporation'
>>     device     = 'Haswell PCI Express x16 Controller'
>>     class      = bridge
>>     subclass   = PCI-PCI
>> vgapci1@pci0:0:2:0:    class=0x03 card=0xfa471179 chip=0x04168086
>> rev=0x06 hdr=0x00
>>     vendor     = 'Intel Corporation'
>>     device     = 'Haswell Integrated Graphics Controller'
>>     class      = display
>>     subclass   = VGA
>> hdac0@pci0:0:3:0:    class=0x040300 card=0xfa4d1179 chip=0x0c0c8086
>> rev=0x06 hdr=0x00
>>     vendor     = 'Intel Corporation'
>>     device     = 'Haswell HD Audio Controller'
>>     class      = multimedia
>>     subclass   = HDA
>> xhci0@pci0:0:20:0:    class=0x0c0330 card=0xfa401179 chip=0x8c318086
>> rev=0x04 hdr=0x00
>>     vendor     = 'Intel Corporation'
>>     device     = 'Lynx Point USB xHCI Host Controller'
>>     class      = serial bus
>>     subclass   = USB
>> none0@pci0:0:22:0:    class=0x078000 card=0xfa401179 chip=0x8c3a8086
>> rev=0x04 hdr=0x00
>>     vendor     = 'Intel Corporation'
>>     device     = 'Lynx Point MEI Controller'
>>     class      = simple comms
>> ehci0@pci0:0:26:0:    class=0x0c0320 card=0xfa401179 chip=0x8c2d8086
>> rev=0x04 hdr=0x00
>>     vendor     = 'Intel Corporation'
>>     device     = 'Lynx Point USB Enhanced Host Controller'
>>     class      = serial bus
>>     subclass   = USB
>> hdac1@pci0:0:27:0:    class=0x040300 card=0xfa4d1179 chip=0x8c208086
>> rev=0x04 hdr=0x00
>>     vendor     = 'Intel Corporation'
>>     device     = 'Lynx Point High Definition Audio Controller'
>>     class      = multimedia
>>     subclass   = HDA
>> pcib2@pci0:0:28:0:    class=0x060400 card=0xfa401179 chip=0x8c108086
>> rev=0xd4 hdr=0x01
>>     vendor     = 'Intel Corporation'
>>     device     = 'Lynx Point PCI Express Root Port'
>>     class      = bridge
>>     subclass   = PCI-PCI
>> pcib3@pci0:0:28:2:    class=0x060400 card=0xfa401179 chip=0x8c148086
>> rev=0xd4 hdr=0x01
>>     vendor     = 'Intel Corporation'
>>     device     = 'Lynx Point PCI Express Root Port'
>>     class      = bridge
>>     subclass   = PCI-PCI
>> pcib4@pci0:0:28:3:    class=0x060400 card=0xfa401179 chip=0x8c168086
>> rev=0xd4 hdr=0x01
>>     vendor     = 'Intel Corporation'
>>     device     = 'Lynx Point PCI Express Root Port'
>>     class      = bridge
>>     subclass   = PCI-PCI
>> ehci1@pci0:0:29:0:    class=0x0c0320 card=0xfa401179 chip=0x8c268086
>> rev=0x04 hdr=0x00
>>     vendor     = 'Intel Corporation'
>>

Re: Re: Atheros AR9565

[Adrian Chadd]

Which HP laptop?


-a


On 9 April 2014 13:35, Anthony Jenkins  wrote:
> Hey, I've got one of these babies in my HP laptop; I actually posted some 
> problems I was having to the list back in Aug. '13.  I could loan you mine 
> and/or assist with debugging if I can have it back (can make do with an 
> external wireless device).
>
>
> Anthony
>
>
> 
> From: Adrian Chadd 
> To: tzoi516 
> Cc: "freebsd-wireless@freebsd.org" 
> Sent: Wednesday, April 9, 2014 3:02 PM
> Subject: Re: Re: Atheros AR9565
>
>
> Hi,
>
> The AR9565 is a relatively new chip that hasn't really been thoroughly
> tested in FreeBSD. Laptop manufacturers have also gone and done some
> rather silly things to save cost on the wireless NIC itself and I'm
> not sure those patches / work arounds are in -HEAD.
>
> please file a PR with this problem complete with your pciconf -lv
> output as above.
>
> Thanks!
>
>
> -a
>
>
> On 9 April 2014 05:40, tzoi516  wrote:
>> I'm using the GENERIC kernel. Want me to create a custom kernel?
>>
>> pciconf info:
>>
>> hostb0@pci0:0:0:0:class=0x06 card=0xfa401179 chip=0x0c048086
>> rev=0x06 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Haswell DRAM Controller'
>> class  = bridge
>> subclass   = HOST-PCI
>> pcib1@pci0:0:1:0:class=0x060400 card=0xfa471179 chip=0x0c018086
>> rev=0x06 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Haswell PCI Express x16 Controller'
>> class  = bridge
>> subclass   = PCI-PCI
>> vgapci1@pci0:0:2:0:class=0x03 card=0xfa471179 chip=0x04168086
>> rev=0x06 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Haswell Integrated Graphics Controller'
>> class  = display
>> subclass   = VGA
>> hdac0@pci0:0:3:0:class=0x040300 card=0xfa4d1179 chip=0x0c0c8086
>> rev=0x06 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Haswell HD Audio Controller'
>> class  = multimedia
>> subclass   = HDA
>> xhci0@pci0:0:20:0:class=0x0c0330 card=0xfa401179 chip=0x8c318086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point USB xHCI Host Controller'
>> class  = serial bus
>> subclass   = USB
>> none0@pci0:0:22:0:class=0x078000 card=0xfa401179 chip=0x8c3a8086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point MEI Controller'
>> class  = simple comms
>> ehci0@pci0:0:26:0:class=0x0c0320 card=0xfa401179 chip=0x8c2d8086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point USB Enhanced Host Controller'
>> class  = serial bus
>> subclass   = USB
>> hdac1@pci0:0:27:0:class=0x040300 card=0xfa4d1179 chip=0x8c208086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point High Definition Audio Controller'
>> class  = multimedia
>> subclass   = HDA
>> pcib2@pci0:0:28:0:class=0x060400 card=0xfa401179 chip=0x8c108086
>> rev=0xd4 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point PCI Express Root Port'
>> class  = bridge
>> subclass   = PCI-PCI
>> pcib3@pci0:0:28:2:class=0x060400 card=0xfa401179 chip=0x8c148086
>> rev=0xd4 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point PCI Express Root Port'
>> class  = bridge
>> subclass   = PCI-PCI
>> pcib4@pci0:0:28:3:class=0x060400 card=0xfa401179 chip=0x8c168086
>> rev=0xd4 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point PCI Express Root Port'
>> class  = bridge
>> subclass   = PCI-PCI
>> ehci1@pci0:0:29:0:class=0x0c0320 card=0xfa401179 chip=0x8c268086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point USB Enhanced Host Controller'
>> class  = serial bus
>> subclass   = USB
>> isab0@pci0:0:31:0:class=0x060100 card=0xfa401179 chip=0x8c498086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Po

Re: Atheros AR9565

[tzoi516]

My computer is a laptop - the link to it is in my first email. I haven't
touched code out of a Windows IDE since the mid-90's, so this might be a
good learning experience for me. Thanks.

On 04/09/14 15:44, Adrian Chadd wrote:
> The driver source is in sys/dev/ath/ and sys/contrib/dev/ath/ath_hal/ar9300/
>
> I have all of the linux driver source and the atheros internal driver
> source for their AP products but their desktop drivers are .. very
> laptop specific and it's hard to get the driver source out of the
> relevant group(s).
>
>
>
> -a
>
>
> On 9 April 2014 12:28, tzoi516  wrote:
>> Hi,
>>
>> Thanks for all of the help. Where is the driver source code? I'll submit
>> a PR today.
>>
>> Thanks,
>> Mike
>>
>> On 04/09/14 15:02, Adrian Chadd wrote:
>>> Hi,
>>>
>>> The AR9565 is a relatively new chip that hasn't really been thoroughly
>>> tested in FreeBSD. Laptop manufacturers have also gone and done some
>>> rather silly things to save cost on the wireless NIC itself and I'm
>>> not sure those patches / work arounds are in -HEAD.
>>>
>>> please file a PR with this problem complete with your pciconf -lv
>>> output as above.
>>>
>>> Thanks!
>>>
>>>
>>> -a
>>>
>>>
>>> On 9 April 2014 05:40, tzoi516  wrote:
 I'm using the GENERIC kernel. Want me to create a custom kernel?

 pciconf info:

 hostb0@pci0:0:0:0:class=0x06 card=0xfa401179 chip=0x0c048086
 rev=0x06 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Haswell DRAM Controller'
 class  = bridge
 subclass   = HOST-PCI
 pcib1@pci0:0:1:0:class=0x060400 card=0xfa471179 chip=0x0c018086
 rev=0x06 hdr=0x01
 vendor = 'Intel Corporation'
 device = 'Haswell PCI Express x16 Controller'
 class  = bridge
 subclass   = PCI-PCI
 vgapci1@pci0:0:2:0:class=0x03 card=0xfa471179 chip=0x04168086
 rev=0x06 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Haswell Integrated Graphics Controller'
 class  = display
 subclass   = VGA
 hdac0@pci0:0:3:0:class=0x040300 card=0xfa4d1179 chip=0x0c0c8086
 rev=0x06 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Haswell HD Audio Controller'
 class  = multimedia
 subclass   = HDA
 xhci0@pci0:0:20:0:class=0x0c0330 card=0xfa401179 chip=0x8c318086
 rev=0x04 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Lynx Point USB xHCI Host Controller'
 class  = serial bus
 subclass   = USB
 none0@pci0:0:22:0:class=0x078000 card=0xfa401179 chip=0x8c3a8086
 rev=0x04 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Lynx Point MEI Controller'
 class  = simple comms
 ehci0@pci0:0:26:0:class=0x0c0320 card=0xfa401179 chip=0x8c2d8086
 rev=0x04 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Lynx Point USB Enhanced Host Controller'
 class  = serial bus
 subclass   = USB
 hdac1@pci0:0:27:0:class=0x040300 card=0xfa4d1179 chip=0x8c208086
 rev=0x04 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Lynx Point High Definition Audio Controller'
 class  = multimedia
 subclass   = HDA
 pcib2@pci0:0:28:0:class=0x060400 card=0xfa401179 chip=0x8c108086
 rev=0xd4 hdr=0x01
 vendor = 'Intel Corporation'
 device = 'Lynx Point PCI Express Root Port'
 class  = bridge
 subclass   = PCI-PCI
 pcib3@pci0:0:28:2:class=0x060400 card=0xfa401179 chip=0x8c148086
 rev=0xd4 hdr=0x01
 vendor = 'Intel Corporation'
 device = 'Lynx Point PCI Express Root Port'
 class  = bridge
 subclass   = PCI-PCI
 pcib4@pci0:0:28:3:class=0x060400 card=0xfa401179 chip=0x8c168086
 rev=0xd4 hdr=0x01
 vendor = 'Intel Corporation'
 device = 'Lynx Point PCI Express Root Port'
 class  = bridge
 subclass   = PCI-PCI
 ehci1@pci0:0:29:0:class=0x0c0320 card=0xfa401179 chip=0x8c268086
 rev=0x04 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Lynx Point USB Enhanced Host Controller'
 class  = serial bus
 subclass   = USB
 isab0@pci0:0:31:0:class=0x060100 card=0xfa401179 chip=0x8c498086
 rev=0x04 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Lynx Point LPC Controller'
 class  = bridge
 subclass   = PCI-ISA
 none1@pci0:0:31:3:class=0x0c0500 card=0xfa401179 chip=0x8c228086
 rev=0x04 hdr=0x00
 vendor = 'Intel Corporation'
 device = 'Lynx Point SMBus Controller'
 class  = serial bus
 subclass   = SMBus
 atapci0@pci0:0:31:5:class=0x010185 card=0xfa401179 chip=0x8c098086
 rev=0x04 hdr=0x00
 vendor = 'Int

Re: Re: Atheros AR9565

[Anthony Jenkins]

Hey, I've got one of these babies in my HP laptop; I actually posted some 
problems I was having to the list back in Aug. '13.  I could loan you mine 
and/or assist with debugging if I can have it back (can make do with an 
external wireless device).


Anthony



From: Adrian Chadd 
To: tzoi516  
Cc: "freebsd-wireless@freebsd.org"  
Sent: Wednesday, April 9, 2014 3:02 PM
Subject: Re: Re: Atheros AR9565


Hi,

The AR9565 is a relatively new chip that hasn't really been thoroughly
tested in FreeBSD. Laptop manufacturers have also gone and done some
rather silly things to save cost on the wireless NIC itself and I'm
not sure those patches / work arounds are in -HEAD.

please file a PR with this problem complete with your pciconf -lv
output as above.

Thanks!


-a


On 9 April 2014 05:40, tzoi516  wrote:
> I'm using the GENERIC kernel. Want me to create a custom kernel?
>
> pciconf info:
>
> hostb0@pci0:0:0:0:    class=0x06 card=0xfa401179 chip=0x0c048086
> rev=0x06 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Haswell DRAM Controller'
>     class      = bridge
>     subclass   = HOST-PCI
> pcib1@pci0:0:1:0:    class=0x060400 card=0xfa471179 chip=0x0c018086
> rev=0x06 hdr=0x01
>     vendor     = 'Intel Corporation'
>     device     = 'Haswell PCI Express x16 Controller'
>     class      = bridge
>     subclass   = PCI-PCI
> vgapci1@pci0:0:2:0:    class=0x03 card=0xfa471179 chip=0x04168086
> rev=0x06 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Haswell Integrated Graphics Controller'
>     class      = display
>     subclass   = VGA
> hdac0@pci0:0:3:0:    class=0x040300 card=0xfa4d1179 chip=0x0c0c8086
> rev=0x06 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Haswell HD Audio Controller'
>     class      = multimedia
>     subclass   = HDA
> xhci0@pci0:0:20:0:    class=0x0c0330 card=0xfa401179 chip=0x8c318086
> rev=0x04 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Lynx Point USB xHCI Host Controller'
>     class      = serial bus
>     subclass   = USB
> none0@pci0:0:22:0:    class=0x078000 card=0xfa401179 chip=0x8c3a8086
> rev=0x04 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Lynx Point MEI Controller'
>     class      = simple comms
> ehci0@pci0:0:26:0:    class=0x0c0320 card=0xfa401179 chip=0x8c2d8086
> rev=0x04 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Lynx Point USB Enhanced Host Controller'
>     class      = serial bus
>     subclass   = USB
> hdac1@pci0:0:27:0:    class=0x040300 card=0xfa4d1179 chip=0x8c208086
> rev=0x04 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Lynx Point High Definition Audio Controller'
>     class      = multimedia
>     subclass   = HDA
> pcib2@pci0:0:28:0:    class=0x060400 card=0xfa401179 chip=0x8c108086
> rev=0xd4 hdr=0x01
>     vendor     = 'Intel Corporation'
>     device     = 'Lynx Point PCI Express Root Port'
>     class      = bridge
>     subclass   = PCI-PCI
> pcib3@pci0:0:28:2:    class=0x060400 card=0xfa401179 chip=0x8c148086
> rev=0xd4 hdr=0x01
>     vendor     = 'Intel Corporation'
>     device     = 'Lynx Point PCI Express Root Port'
>     class      = bridge
>     subclass   = PCI-PCI
> pcib4@pci0:0:28:3:    class=0x060400 card=0xfa401179 chip=0x8c168086
> rev=0xd4 hdr=0x01
>     vendor     = 'Intel Corporation'
>     device     = 'Lynx Point PCI Express Root Port'
>     class      = bridge
>     subclass   = PCI-PCI
> ehci1@pci0:0:29:0:    class=0x0c0320 card=0xfa401179 chip=0x8c268086
> rev=0x04 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Lynx Point USB Enhanced Host Controller'
>     class      = serial bus
>     subclass   = USB
> isab0@pci0:0:31:0:    class=0x060100 card=0xfa401179 chip=0x8c498086
> rev=0x04 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Lynx Point LPC Controller'
>     class      = bridge
>     subclass   = PCI-ISA
> none1@pci0:0:31:3:    class=0x0c0500 card=0xfa401179 chip=0x8c228086
> rev=0x04 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'Lynx Point SMBus Controller'
>     class      = serial bus
>     subclass   = SMBus
> atapci0@pci0:0:31:5:    class=0x010185 card=0xfa401179 chip=0x8c098086
> rev=0x04 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = 'L

Re: Atheros AR9565

[Adrian Chadd]

The driver source is in sys/dev/ath/ and sys/contrib/dev/ath/ath_hal/ar9300/

I have all of the linux driver source and the atheros internal driver
source for their AP products but their desktop drivers are .. very
laptop specific and it's hard to get the driver source out of the
relevant group(s).



-a


On 9 April 2014 12:28, tzoi516  wrote:
> Hi,
>
> Thanks for all of the help. Where is the driver source code? I'll submit
> a PR today.
>
> Thanks,
> Mike
>
> On 04/09/14 15:02, Adrian Chadd wrote:
>> Hi,
>>
>> The AR9565 is a relatively new chip that hasn't really been thoroughly
>> tested in FreeBSD. Laptop manufacturers have also gone and done some
>> rather silly things to save cost on the wireless NIC itself and I'm
>> not sure those patches / work arounds are in -HEAD.
>>
>> please file a PR with this problem complete with your pciconf -lv
>> output as above.
>>
>> Thanks!
>>
>>
>> -a
>>
>>
>> On 9 April 2014 05:40, tzoi516  wrote:
>>> I'm using the GENERIC kernel. Want me to create a custom kernel?
>>>
>>> pciconf info:
>>>
>>> hostb0@pci0:0:0:0:class=0x06 card=0xfa401179 chip=0x0c048086
>>> rev=0x06 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Haswell DRAM Controller'
>>> class  = bridge
>>> subclass   = HOST-PCI
>>> pcib1@pci0:0:1:0:class=0x060400 card=0xfa471179 chip=0x0c018086
>>> rev=0x06 hdr=0x01
>>> vendor = 'Intel Corporation'
>>> device = 'Haswell PCI Express x16 Controller'
>>> class  = bridge
>>> subclass   = PCI-PCI
>>> vgapci1@pci0:0:2:0:class=0x03 card=0xfa471179 chip=0x04168086
>>> rev=0x06 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Haswell Integrated Graphics Controller'
>>> class  = display
>>> subclass   = VGA
>>> hdac0@pci0:0:3:0:class=0x040300 card=0xfa4d1179 chip=0x0c0c8086
>>> rev=0x06 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Haswell HD Audio Controller'
>>> class  = multimedia
>>> subclass   = HDA
>>> xhci0@pci0:0:20:0:class=0x0c0330 card=0xfa401179 chip=0x8c318086
>>> rev=0x04 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point USB xHCI Host Controller'
>>> class  = serial bus
>>> subclass   = USB
>>> none0@pci0:0:22:0:class=0x078000 card=0xfa401179 chip=0x8c3a8086
>>> rev=0x04 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point MEI Controller'
>>> class  = simple comms
>>> ehci0@pci0:0:26:0:class=0x0c0320 card=0xfa401179 chip=0x8c2d8086
>>> rev=0x04 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point USB Enhanced Host Controller'
>>> class  = serial bus
>>> subclass   = USB
>>> hdac1@pci0:0:27:0:class=0x040300 card=0xfa4d1179 chip=0x8c208086
>>> rev=0x04 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point High Definition Audio Controller'
>>> class  = multimedia
>>> subclass   = HDA
>>> pcib2@pci0:0:28:0:class=0x060400 card=0xfa401179 chip=0x8c108086
>>> rev=0xd4 hdr=0x01
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point PCI Express Root Port'
>>> class  = bridge
>>> subclass   = PCI-PCI
>>> pcib3@pci0:0:28:2:class=0x060400 card=0xfa401179 chip=0x8c148086
>>> rev=0xd4 hdr=0x01
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point PCI Express Root Port'
>>> class  = bridge
>>> subclass   = PCI-PCI
>>> pcib4@pci0:0:28:3:class=0x060400 card=0xfa401179 chip=0x8c168086
>>> rev=0xd4 hdr=0x01
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point PCI Express Root Port'
>>> class  = bridge
>>> subclass   = PCI-PCI
>>> ehci1@pci0:0:29:0:class=0x0c0320 card=0xfa401179 chip=0x8c268086
>>> rev=0x04 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point USB Enhanced Host Controller'
>>> class  = serial bus
>>> subclass   = USB
>>> isab0@pci0:0:31:0:class=0x060100 card=0xfa401179 chip=0x8c498086
>>> rev=0x04 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point LPC Controller'
>>> class  = bridge
>>> subclass   = PCI-ISA
>>> none1@pci0:0:31:3:class=0x0c0500 card=0xfa401179 chip=0x8c228086
>>> rev=0x04 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point SMBus Controller'
>>> class  = serial bus
>>> subclass   = SMBus
>>> atapci0@pci0:0:31:5:class=0x010185 card=0xfa401179 chip=0x8c098086
>>> rev=0x04 hdr=0x00
>>> vendor = 'Intel Corporation'
>>> device = 'Lynx Point 2-port SATA Controller 2 [IDE mode]'
>>> class  = mass storage
>>> subclass   = ATA
>>> vgapci0@pci0:1:0:0:class=0x030200 card=0xfa471179 chip=0x129210de
>>> rev=0xa1 hdr=0x00
>>> vendor = 'NVIDIA Corporation'
>>> class  = display
>>> subclass   = 3D
>>> ath0@pci0:3:0:0:cla

Re: Atheros AR9565

[tzoi516]

Hi,

Thanks for all of the help. Where is the driver source code? I'll submit
a PR today.

Thanks,
Mike

On 04/09/14 15:02, Adrian Chadd wrote:
> Hi,
>
> The AR9565 is a relatively new chip that hasn't really been thoroughly
> tested in FreeBSD. Laptop manufacturers have also gone and done some
> rather silly things to save cost on the wireless NIC itself and I'm
> not sure those patches / work arounds are in -HEAD.
>
> please file a PR with this problem complete with your pciconf -lv
> output as above.
>
> Thanks!
>
>
> -a
>
>
> On 9 April 2014 05:40, tzoi516  wrote:
>> I'm using the GENERIC kernel. Want me to create a custom kernel?
>>
>> pciconf info:
>>
>> hostb0@pci0:0:0:0:class=0x06 card=0xfa401179 chip=0x0c048086
>> rev=0x06 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Haswell DRAM Controller'
>> class  = bridge
>> subclass   = HOST-PCI
>> pcib1@pci0:0:1:0:class=0x060400 card=0xfa471179 chip=0x0c018086
>> rev=0x06 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Haswell PCI Express x16 Controller'
>> class  = bridge
>> subclass   = PCI-PCI
>> vgapci1@pci0:0:2:0:class=0x03 card=0xfa471179 chip=0x04168086
>> rev=0x06 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Haswell Integrated Graphics Controller'
>> class  = display
>> subclass   = VGA
>> hdac0@pci0:0:3:0:class=0x040300 card=0xfa4d1179 chip=0x0c0c8086
>> rev=0x06 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Haswell HD Audio Controller'
>> class  = multimedia
>> subclass   = HDA
>> xhci0@pci0:0:20:0:class=0x0c0330 card=0xfa401179 chip=0x8c318086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point USB xHCI Host Controller'
>> class  = serial bus
>> subclass   = USB
>> none0@pci0:0:22:0:class=0x078000 card=0xfa401179 chip=0x8c3a8086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point MEI Controller'
>> class  = simple comms
>> ehci0@pci0:0:26:0:class=0x0c0320 card=0xfa401179 chip=0x8c2d8086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point USB Enhanced Host Controller'
>> class  = serial bus
>> subclass   = USB
>> hdac1@pci0:0:27:0:class=0x040300 card=0xfa4d1179 chip=0x8c208086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point High Definition Audio Controller'
>> class  = multimedia
>> subclass   = HDA
>> pcib2@pci0:0:28:0:class=0x060400 card=0xfa401179 chip=0x8c108086
>> rev=0xd4 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point PCI Express Root Port'
>> class  = bridge
>> subclass   = PCI-PCI
>> pcib3@pci0:0:28:2:class=0x060400 card=0xfa401179 chip=0x8c148086
>> rev=0xd4 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point PCI Express Root Port'
>> class  = bridge
>> subclass   = PCI-PCI
>> pcib4@pci0:0:28:3:class=0x060400 card=0xfa401179 chip=0x8c168086
>> rev=0xd4 hdr=0x01
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point PCI Express Root Port'
>> class  = bridge
>> subclass   = PCI-PCI
>> ehci1@pci0:0:29:0:class=0x0c0320 card=0xfa401179 chip=0x8c268086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point USB Enhanced Host Controller'
>> class  = serial bus
>> subclass   = USB
>> isab0@pci0:0:31:0:class=0x060100 card=0xfa401179 chip=0x8c498086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point LPC Controller'
>> class  = bridge
>> subclass   = PCI-ISA
>> none1@pci0:0:31:3:class=0x0c0500 card=0xfa401179 chip=0x8c228086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point SMBus Controller'
>> class  = serial bus
>> subclass   = SMBus
>> atapci0@pci0:0:31:5:class=0x010185 card=0xfa401179 chip=0x8c098086
>> rev=0x04 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = 'Lynx Point 2-port SATA Controller 2 [IDE mode]'
>> class  = mass storage
>> subclass   = ATA
>> vgapci0@pci0:1:0:0:class=0x030200 card=0xfa471179 chip=0x129210de
>> rev=0xa1 hdr=0x00
>> vendor = 'NVIDIA Corporation'
>> class  = display
>> subclass   = 3D
>> ath0@pci0:3:0:0:class=0x028000 card=0x061211ad chip=0x0036168c
>> rev=0x01 hdr=0x00
>> vendor = 'Atheros Communications Inc.'
>> device = 'AR9565 Wireless Network Adapter'
>> class  = network
>> none2@pci0:4:0:0:class=0x02 card=0xfa401179 chip=0x10a11969
>> rev=0x10 hdr=0x00
>> vendor = 'Atheros Communications Inc.'
>> class  = network
>> subclass   = ethernet
>>
>>
>>
>>
>> On 04/08/14 18:29, Adrian Chadd wrote:
>>> hi,
>>>
>>> ok. Can you 

Re: Re: Atheros AR9565

[Adrian Chadd]

(.. and my standard offer applies here. I'm much better likely to fix
things if I have one of them. I likely can't buy that specific NIC;
I'd have to have the whole laptop. So if someone wishes to buy me one
of these things, I'll endeavour to improve upon power saving and wifi
support.)


-a
___
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: Re: Atheros AR9565

[Adrian Chadd]

Hi,

The AR9565 is a relatively new chip that hasn't really been thoroughly
tested in FreeBSD. Laptop manufacturers have also gone and done some
rather silly things to save cost on the wireless NIC itself and I'm
not sure those patches / work arounds are in -HEAD.

please file a PR with this problem complete with your pciconf -lv
output as above.

Thanks!


-a


On 9 April 2014 05:40, tzoi516  wrote:
> I'm using the GENERIC kernel. Want me to create a custom kernel?
>
> pciconf info:
>
> hostb0@pci0:0:0:0:class=0x06 card=0xfa401179 chip=0x0c048086
> rev=0x06 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Haswell DRAM Controller'
> class  = bridge
> subclass   = HOST-PCI
> pcib1@pci0:0:1:0:class=0x060400 card=0xfa471179 chip=0x0c018086
> rev=0x06 hdr=0x01
> vendor = 'Intel Corporation'
> device = 'Haswell PCI Express x16 Controller'
> class  = bridge
> subclass   = PCI-PCI
> vgapci1@pci0:0:2:0:class=0x03 card=0xfa471179 chip=0x04168086
> rev=0x06 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Haswell Integrated Graphics Controller'
> class  = display
> subclass   = VGA
> hdac0@pci0:0:3:0:class=0x040300 card=0xfa4d1179 chip=0x0c0c8086
> rev=0x06 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Haswell HD Audio Controller'
> class  = multimedia
> subclass   = HDA
> xhci0@pci0:0:20:0:class=0x0c0330 card=0xfa401179 chip=0x8c318086
> rev=0x04 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Lynx Point USB xHCI Host Controller'
> class  = serial bus
> subclass   = USB
> none0@pci0:0:22:0:class=0x078000 card=0xfa401179 chip=0x8c3a8086
> rev=0x04 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Lynx Point MEI Controller'
> class  = simple comms
> ehci0@pci0:0:26:0:class=0x0c0320 card=0xfa401179 chip=0x8c2d8086
> rev=0x04 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Lynx Point USB Enhanced Host Controller'
> class  = serial bus
> subclass   = USB
> hdac1@pci0:0:27:0:class=0x040300 card=0xfa4d1179 chip=0x8c208086
> rev=0x04 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Lynx Point High Definition Audio Controller'
> class  = multimedia
> subclass   = HDA
> pcib2@pci0:0:28:0:class=0x060400 card=0xfa401179 chip=0x8c108086
> rev=0xd4 hdr=0x01
> vendor = 'Intel Corporation'
> device = 'Lynx Point PCI Express Root Port'
> class  = bridge
> subclass   = PCI-PCI
> pcib3@pci0:0:28:2:class=0x060400 card=0xfa401179 chip=0x8c148086
> rev=0xd4 hdr=0x01
> vendor = 'Intel Corporation'
> device = 'Lynx Point PCI Express Root Port'
> class  = bridge
> subclass   = PCI-PCI
> pcib4@pci0:0:28:3:class=0x060400 card=0xfa401179 chip=0x8c168086
> rev=0xd4 hdr=0x01
> vendor = 'Intel Corporation'
> device = 'Lynx Point PCI Express Root Port'
> class  = bridge
> subclass   = PCI-PCI
> ehci1@pci0:0:29:0:class=0x0c0320 card=0xfa401179 chip=0x8c268086
> rev=0x04 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Lynx Point USB Enhanced Host Controller'
> class  = serial bus
> subclass   = USB
> isab0@pci0:0:31:0:class=0x060100 card=0xfa401179 chip=0x8c498086
> rev=0x04 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Lynx Point LPC Controller'
> class  = bridge
> subclass   = PCI-ISA
> none1@pci0:0:31:3:class=0x0c0500 card=0xfa401179 chip=0x8c228086
> rev=0x04 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Lynx Point SMBus Controller'
> class  = serial bus
> subclass   = SMBus
> atapci0@pci0:0:31:5:class=0x010185 card=0xfa401179 chip=0x8c098086
> rev=0x04 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Lynx Point 2-port SATA Controller 2 [IDE mode]'
> class  = mass storage
> subclass   = ATA
> vgapci0@pci0:1:0:0:class=0x030200 card=0xfa471179 chip=0x129210de
> rev=0xa1 hdr=0x00
> vendor = 'NVIDIA Corporation'
> class  = display
> subclass   = 3D
> ath0@pci0:3:0:0:class=0x028000 card=0x061211ad chip=0x0036168c
> rev=0x01 hdr=0x00
> vendor = 'Atheros Communications Inc.'
> device = 'AR9565 Wireless Network Adapter'
> class  = network
> none2@pci0:4:0:0:class=0x02 card=0xfa401179 chip=0x10a11969
> rev=0x10 hdr=0x00
> vendor = 'Atheros Communications Inc.'
> class  = network
> subclass   = ethernet
>
>
>
>
> On 04/08/14 18:29, Adrian Chadd wrote:
>> hi,
>>
>> ok. Can you please do a pciconf -lv and attach it here?
>>
>> Oh. Erm, did you compile a kernel from source? is ATH_ENABLE_11N in your 
>> kernel?
>>
>> Do a 'sysctl dev.ath.0.txagg=1' and then paste the output in dmesg here.
>>
>>
>>
>> -a
>>
>>
>> On 8 April 2014 13:38, tzoi516  wrote:
>>> OK, ki

Fwd: Re: Atheros AR9565

[tzoi516]

I'm using the GENERIC kernel. Want me to create a custom kernel?

pciconf info:

hostb0@pci0:0:0:0:class=0x06 card=0xfa401179 chip=0x0c048086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = 'Haswell DRAM Controller'
class  = bridge
subclass   = HOST-PCI
pcib1@pci0:0:1:0:class=0x060400 card=0xfa471179 chip=0x0c018086
rev=0x06 hdr=0x01
vendor = 'Intel Corporation'
device = 'Haswell PCI Express x16 Controller'
class  = bridge
subclass   = PCI-PCI
vgapci1@pci0:0:2:0:class=0x03 card=0xfa471179 chip=0x04168086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = 'Haswell Integrated Graphics Controller'
class  = display
subclass   = VGA
hdac0@pci0:0:3:0:class=0x040300 card=0xfa4d1179 chip=0x0c0c8086
rev=0x06 hdr=0x00
vendor = 'Intel Corporation'
device = 'Haswell HD Audio Controller'
class  = multimedia
subclass   = HDA
xhci0@pci0:0:20:0:class=0x0c0330 card=0xfa401179 chip=0x8c318086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Lynx Point USB xHCI Host Controller'
class  = serial bus
subclass   = USB
none0@pci0:0:22:0:class=0x078000 card=0xfa401179 chip=0x8c3a8086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Lynx Point MEI Controller'
class  = simple comms
ehci0@pci0:0:26:0:class=0x0c0320 card=0xfa401179 chip=0x8c2d8086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Lynx Point USB Enhanced Host Controller'
class  = serial bus
subclass   = USB
hdac1@pci0:0:27:0:class=0x040300 card=0xfa4d1179 chip=0x8c208086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Lynx Point High Definition Audio Controller'
class  = multimedia
subclass   = HDA
pcib2@pci0:0:28:0:class=0x060400 card=0xfa401179 chip=0x8c108086
rev=0xd4 hdr=0x01
vendor = 'Intel Corporation'
device = 'Lynx Point PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib3@pci0:0:28:2:class=0x060400 card=0xfa401179 chip=0x8c148086
rev=0xd4 hdr=0x01
vendor = 'Intel Corporation'
device = 'Lynx Point PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib4@pci0:0:28:3:class=0x060400 card=0xfa401179 chip=0x8c168086
rev=0xd4 hdr=0x01
vendor = 'Intel Corporation'
device = 'Lynx Point PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
ehci1@pci0:0:29:0:class=0x0c0320 card=0xfa401179 chip=0x8c268086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Lynx Point USB Enhanced Host Controller'
class  = serial bus
subclass   = USB
isab0@pci0:0:31:0:class=0x060100 card=0xfa401179 chip=0x8c498086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Lynx Point LPC Controller'
class  = bridge
subclass   = PCI-ISA
none1@pci0:0:31:3:class=0x0c0500 card=0xfa401179 chip=0x8c228086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Lynx Point SMBus Controller'
class  = serial bus
subclass   = SMBus
atapci0@pci0:0:31:5:class=0x010185 card=0xfa401179 chip=0x8c098086
rev=0x04 hdr=0x00
vendor = 'Intel Corporation'
device = 'Lynx Point 2-port SATA Controller 2 [IDE mode]'
class  = mass storage
subclass   = ATA
vgapci0@pci0:1:0:0:class=0x030200 card=0xfa471179 chip=0x129210de
rev=0xa1 hdr=0x00
vendor = 'NVIDIA Corporation'
class  = display
subclass   = 3D
ath0@pci0:3:0:0:class=0x028000 card=0x061211ad chip=0x0036168c
rev=0x01 hdr=0x00
vendor = 'Atheros Communications Inc.'
device = 'AR9565 Wireless Network Adapter'
class  = network
none2@pci0:4:0:0:class=0x02 card=0xfa401179 chip=0x10a11969
rev=0x10 hdr=0x00
vendor = 'Atheros Communications Inc.'
class  = network
subclass   = ethernet




On 04/08/14 18:29, Adrian Chadd wrote:
> hi,
>
> ok. Can you please do a pciconf -lv and attach it here?
>
> Oh. Erm, did you compile a kernel from source? is ATH_ENABLE_11N in your 
> kernel?
>
> Do a 'sysctl dev.ath.0.txagg=1' and then paste the output in dmesg here.
>
>
>
> -a
>
>
> On 8 April 2014 13:38, tzoi516  wrote:
>> OK, killed wpa_supplicant and downed wlan0 and ath0. After ifconfig ath0
>> up I received a ton of these:
>>
>> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
>> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
>>
>> received those about 20 times then this:
>>
>> ath0: ath_edma_recv_proc_queue: Q1: NULL bf?
>>
>> And now the top 2 are slowly scrolling.
>>
>> Mike
>>
>>
>> On 04/08/14 16:03, Adrian Chadd wrote:
>>> Right. It sounds like it's not associated.
>>>
>>> Try wlandebug +assoc and then run wpa_supplicant
>>>
>>>
>>> -a
>>>
>>>
>>> On 8 April 2014 12:21, tzoi516  wrote:
 Sorry for another email, the errors are spo

Re: Atheros AR9565

[Adrian Chadd]

hi,

ok. Can you please do a pciconf -lv and attach it here?

Oh. Erm, did you compile a kernel from source? is ATH_ENABLE_11N in your kernel?

Do a 'sysctl dev.ath.0.txagg=1' and then paste the output in dmesg here.



-a


On 8 April 2014 13:38, tzoi516  wrote:
> OK, killed wpa_supplicant and downed wlan0 and ath0. After ifconfig ath0
> up I received a ton of these:
>
> ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
> ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?
>
> received those about 20 times then this:
>
> ath0: ath_edma_recv_proc_queue: Q1: NULL bf?
>
> And now the top 2 are slowly scrolling.
>
> Mike
>
>
> On 04/08/14 16:03, Adrian Chadd wrote:
>> Right. It sounds like it's not associated.
>>
>> Try wlandebug +assoc and then run wpa_supplicant
>>
>>
>> -a
>>
>>
>> On 8 April 2014 12:21, tzoi516  wrote:
>>> Sorry for another email, the errors are sporadic. I'm trying to find the
>>> ioctl errors that I get on shutdown.
>>> These are after logging in:
>>>
>>> ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
>>> dhclient[1001]: send_packet: Invalid argument
>>> dhclient[1001]: send_packet: No buffer space available
>>> ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
>>> dhclient[1001]: send_packet: No buffer space available
>>> dhclient[1001]: send_packet: Invalid argument
>>> dhclient[1001]: send_packet: Network is down
>>>
>>> Mike
>>>
>>> On 04/08/14 14:38, Adrian Chadd wrote:
 Ah. Can you post the buffer errors you're seeing?


 -a


 On 8 April 2014 11:37, tzoi516  wrote:
> On 04/08/14 14:23, Adrian Chadd wrote:
>> It should work fine on -10 and HEAD. Is it not working fine?
>>
>>
>> -a
>>
>>
>> On 8 April 2014 09:12, tzoi516  wrote:
>>> I have a Toshiba Satellite S55-A5169
>>> This specific one:
>>> http://www.bhphotovideo.com/c/product/1024074-REG/toshiba_pskk6u_08c08t_s55_i7_4700mq_12gb_1tb_windows_8_1_15_6_silver.html)
>>>
>>> It has the Atheros combo Wi-Fi/NIC, and the Wi-Fi uses the AR9565. For
>>> it to work I have to change the SATA Controller Mode in the BIOS from
>>> "AHCI" to "Compatibility". I don't know if this information helps, and
>>> it's the only AHCI setting I can tweak.
>>>
>>> Mike
>>> ___
>>> 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"
> With SATA controller mode set to Compatibility then it works, but a
> little wonky at startup - sometimes I'll have to run wpa_supplicant -i
> wlan0 -c /etc/wpa_supplicant.conf. Infrequently a buffer error appears.
> With SATA controller mode set to AHCI then I can ifconfig wlan0 list
> scan and see available networks but I can't connect to any except for
> unprotected networks.
>
> I'm currently running FreeBSD 10.0-STABLE
>
> Mike
>
___
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: Atheros AR9565

[tzoi516]

OK, killed wpa_supplicant and downed wlan0 and ath0. After ifconfig ath0
up I received a ton of these:

ath0: ath_edma_rxbuf_alloc: nothing on rxbuf?!
ath0: ath_edma_rxfifo_alloc: Q1: alloc failed: i=0, nbufs=128?

received those about 20 times then this:

ath0: ath_edma_recv_proc_queue: Q1: NULL bf?

And now the top 2 are slowly scrolling.

Mike


On 04/08/14 16:03, Adrian Chadd wrote:
> Right. It sounds like it's not associated.
>
> Try wlandebug +assoc and then run wpa_supplicant
>
>
> -a
>
>
> On 8 April 2014 12:21, tzoi516  wrote:
>> Sorry for another email, the errors are sporadic. I'm trying to find the
>> ioctl errors that I get on shutdown.
>> These are after logging in:
>>
>> ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
>> dhclient[1001]: send_packet: Invalid argument
>> dhclient[1001]: send_packet: No buffer space available
>> ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
>> dhclient[1001]: send_packet: No buffer space available
>> dhclient[1001]: send_packet: Invalid argument
>> dhclient[1001]: send_packet: Network is down
>>
>> Mike
>>
>> On 04/08/14 14:38, Adrian Chadd wrote:
>>> Ah. Can you post the buffer errors you're seeing?
>>>
>>>
>>> -a
>>>
>>>
>>> On 8 April 2014 11:37, tzoi516  wrote:
 On 04/08/14 14:23, Adrian Chadd wrote:
> It should work fine on -10 and HEAD. Is it not working fine?
>
>
> -a
>
>
> On 8 April 2014 09:12, tzoi516  wrote:
>> I have a Toshiba Satellite S55-A5169
>> This specific one:
>> http://www.bhphotovideo.com/c/product/1024074-REG/toshiba_pskk6u_08c08t_s55_i7_4700mq_12gb_1tb_windows_8_1_15_6_silver.html)
>>
>> It has the Atheros combo Wi-Fi/NIC, and the Wi-Fi uses the AR9565. For
>> it to work I have to change the SATA Controller Mode in the BIOS from
>> "AHCI" to "Compatibility". I don't know if this information helps, and
>> it's the only AHCI setting I can tweak.
>>
>> Mike
>> ___
>> 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"
 With SATA controller mode set to Compatibility then it works, but a
 little wonky at startup - sometimes I'll have to run wpa_supplicant -i
 wlan0 -c /etc/wpa_supplicant.conf. Infrequently a buffer error appears.
 With SATA controller mode set to AHCI then I can ifconfig wlan0 list
 scan and see available networks but I can't connect to any except for
 unprotected networks.

 I'm currently running FreeBSD 10.0-STABLE

 Mike

___
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: Atheros AR9565

[tzoi516]

This is what I have now, after 5 attempts, and at 41.2% packet loss:

ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
wlan0: Trying to associate with (hardware ID) (SSID='Base SSID'
freq=1234 MHz
wlan0: [hardware ID] station assoc via MLME
wlan0: [hardware ID] assoc success at aid 3: long preamble, short slot
time, protection
wlan0: Associated with (hardware ID)
dhclient[3172]: send_packet: No buffer space available
wlan0: WPA: Key negotiation completed with (hardware ID) [PTK=TKIP GTK=TKIP]

Previous attempts had the following errors constantly cycling (having to
type all of it right now):

wlan0: link state changed to UP
dhclient[1170]: DHCPREQUEST on wlan0 to 255.255.255.255 port 67
dhclient[1170]: DHCPREQUEST on wlan0 to 255.255.255.255 port 67
dhclient[1170]: wlan0 link state up -> down
wlan0: link state changed to DOWN
wlan0: [hardware ID] station assoc via MLME
wlan0: [hardware ID] assoc success at aid 3: long preamble, short slot
time, protection
wlan0: link state changed to UP


On 04/08/14 16:03, Adrian Chadd wrote:
> Right. It sounds like it's not associated.
>
> Try wlandebug +assoc and then run wpa_supplicant
>
>
> -a
>
>
> On 8 April 2014 12:21, tzoi516  wrote:
>> Sorry for another email, the errors are sporadic. I'm trying to find the
>> ioctl errors that I get on shutdown.
>> These are after logging in:
>>
>> ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
>> dhclient[1001]: send_packet: Invalid argument
>> dhclient[1001]: send_packet: No buffer space available
>> ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
>> dhclient[1001]: send_packet: No buffer space available
>> dhclient[1001]: send_packet: Invalid argument
>> dhclient[1001]: send_packet: Network is down
>>
>> Mike
>>
>> On 04/08/14 14:38, Adrian Chadd wrote:
>>> Ah. Can you post the buffer errors you're seeing?
>>>
>>>
>>> -a
>>>
>>>
>>> On 8 April 2014 11:37, tzoi516  wrote:
 On 04/08/14 14:23, Adrian Chadd wrote:
> It should work fine on -10 and HEAD. Is it not working fine?
>
>
> -a
>
>
> On 8 April 2014 09:12, tzoi516  wrote:
>> I have a Toshiba Satellite S55-A5169
>> This specific one:
>> http://www.bhphotovideo.com/c/product/1024074-REG/toshiba_pskk6u_08c08t_s55_i7_4700mq_12gb_1tb_windows_8_1_15_6_silver.html)
>>
>> It has the Atheros combo Wi-Fi/NIC, and the Wi-Fi uses the AR9565. For
>> it to work I have to change the SATA Controller Mode in the BIOS from
>> "AHCI" to "Compatibility". I don't know if this information helps, and
>> it's the only AHCI setting I can tweak.
>>
>> Mike
>> ___
>> 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"
 With SATA controller mode set to Compatibility then it works, but a
 little wonky at startup - sometimes I'll have to run wpa_supplicant -i
 wlan0 -c /etc/wpa_supplicant.conf. Infrequently a buffer error appears.
 With SATA controller mode set to AHCI then I can ifconfig wlan0 list
 scan and see available networks but I can't connect to any except for
 unprotected networks.

 I'm currently running FreeBSD 10.0-STABLE

 Mike

___
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: Atheros AR9565

[tzoi516]

OK. The odd part is after I received those errors I did ifconfig and saw
the network was up. ping google.com with 75% packet loss. Pings now are
around 35.585 ms with 50.0% packet loss.

FreeBSD 10.0-RELEASE system with Intel (iwn0) approximately 80.833 ms
with 0% packet loss.

Mike


On 04/08/14 16:03, Adrian Chadd wrote:
> Right. It sounds like it's not associated.
>
> Try wlandebug +assoc and then run wpa_supplicant
>
>
> -a
>
>
> On 8 April 2014 12:21, tzoi516  wrote:
>> Sorry for another email, the errors are sporadic. I'm trying to find the
>> ioctl errors that I get on shutdown.
>> These are after logging in:
>>
>> ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
>> dhclient[1001]: send_packet: Invalid argument
>> dhclient[1001]: send_packet: No buffer space available
>> ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
>> dhclient[1001]: send_packet: No buffer space available
>> dhclient[1001]: send_packet: Invalid argument
>> dhclient[1001]: send_packet: Network is down
>>
>> Mike
>>
>> On 04/08/14 14:38, Adrian Chadd wrote:
>>> Ah. Can you post the buffer errors you're seeing?
>>>
>>>
>>> -a
>>>
>>>
>>> On 8 April 2014 11:37, tzoi516  wrote:
 On 04/08/14 14:23, Adrian Chadd wrote:
> It should work fine on -10 and HEAD. Is it not working fine?
>
>
> -a
>
>
> On 8 April 2014 09:12, tzoi516  wrote:
>> I have a Toshiba Satellite S55-A5169
>> This specific one:
>> http://www.bhphotovideo.com/c/product/1024074-REG/toshiba_pskk6u_08c08t_s55_i7_4700mq_12gb_1tb_windows_8_1_15_6_silver.html)
>>
>> It has the Atheros combo Wi-Fi/NIC, and the Wi-Fi uses the AR9565. For
>> it to work I have to change the SATA Controller Mode in the BIOS from
>> "AHCI" to "Compatibility". I don't know if this information helps, and
>> it's the only AHCI setting I can tweak.
>>
>> Mike
>> ___
>> 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"
 With SATA controller mode set to Compatibility then it works, but a
 little wonky at startup - sometimes I'll have to run wpa_supplicant -i
 wlan0 -c /etc/wpa_supplicant.conf. Infrequently a buffer error appears.
 With SATA controller mode set to AHCI then I can ifconfig wlan0 list
 scan and see available networks but I can't connect to any except for
 unprotected networks.

 I'm currently running FreeBSD 10.0-STABLE

 Mike

___
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: Atheros AR9565

[Adrian Chadd]

Right. It sounds like it's not associated.

Try wlandebug +assoc and then run wpa_supplicant


-a


On 8 April 2014 12:21, tzoi516  wrote:
> Sorry for another email, the errors are sporadic. I'm trying to find the
> ioctl errors that I get on shutdown.
> These are after logging in:
>
> ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
> dhclient[1001]: send_packet: Invalid argument
> dhclient[1001]: send_packet: No buffer space available
> ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
> dhclient[1001]: send_packet: No buffer space available
> dhclient[1001]: send_packet: Invalid argument
> dhclient[1001]: send_packet: Network is down
>
> Mike
>
> On 04/08/14 14:38, Adrian Chadd wrote:
>> Ah. Can you post the buffer errors you're seeing?
>>
>>
>> -a
>>
>>
>> On 8 April 2014 11:37, tzoi516  wrote:
>>> On 04/08/14 14:23, Adrian Chadd wrote:
 It should work fine on -10 and HEAD. Is it not working fine?


 -a


 On 8 April 2014 09:12, tzoi516  wrote:
> I have a Toshiba Satellite S55-A5169
> This specific one:
> http://www.bhphotovideo.com/c/product/1024074-REG/toshiba_pskk6u_08c08t_s55_i7_4700mq_12gb_1tb_windows_8_1_15_6_silver.html)
>
> It has the Atheros combo Wi-Fi/NIC, and the Wi-Fi uses the AR9565. For
> it to work I have to change the SATA Controller Mode in the BIOS from
> "AHCI" to "Compatibility". I don't know if this information helps, and
> it's the only AHCI setting I can tweak.
>
> Mike
> ___
> 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"
>>> With SATA controller mode set to Compatibility then it works, but a
>>> little wonky at startup - sometimes I'll have to run wpa_supplicant -i
>>> wlan0 -c /etc/wpa_supplicant.conf. Infrequently a buffer error appears.
>>> With SATA controller mode set to AHCI then I can ifconfig wlan0 list
>>> scan and see available networks but I can't connect to any except for
>>> unprotected networks.
>>>
>>> I'm currently running FreeBSD 10.0-STABLE
>>>
>>> Mike
>
___
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: Atheros AR9565

[tzoi516]

Sorry for another email, the errors are sporadic. I'm trying to find the
ioctl errors that I get on shutdown.
These are after logging in:

ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
dhclient[1001]: send_packet: Invalid argument
dhclient[1001]: send_packet: No buffer space available
ath0: ath_edma_recv_tasklet: sc_inreset_cnt > 0; skipping
dhclient[1001]: send_packet: No buffer space available
dhclient[1001]: send_packet: Invalid argument
dhclient[1001]: send_packet: Network is down

Mike

On 04/08/14 14:38, Adrian Chadd wrote:
> Ah. Can you post the buffer errors you're seeing?
>
>
> -a
>
>
> On 8 April 2014 11:37, tzoi516  wrote:
>> On 04/08/14 14:23, Adrian Chadd wrote:
>>> It should work fine on -10 and HEAD. Is it not working fine?
>>>
>>>
>>> -a
>>>
>>>
>>> On 8 April 2014 09:12, tzoi516  wrote:
 I have a Toshiba Satellite S55-A5169
 This specific one:
 http://www.bhphotovideo.com/c/product/1024074-REG/toshiba_pskk6u_08c08t_s55_i7_4700mq_12gb_1tb_windows_8_1_15_6_silver.html)

 It has the Atheros combo Wi-Fi/NIC, and the Wi-Fi uses the AR9565. For
 it to work I have to change the SATA Controller Mode in the BIOS from
 "AHCI" to "Compatibility". I don't know if this information helps, and
 it's the only AHCI setting I can tweak.

 Mike
 ___
 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"
>> With SATA controller mode set to Compatibility then it works, but a
>> little wonky at startup - sometimes I'll have to run wpa_supplicant -i
>> wlan0 -c /etc/wpa_supplicant.conf. Infrequently a buffer error appears.
>> With SATA controller mode set to AHCI then I can ifconfig wlan0 list
>> scan and see available networks but I can't connect to any except for
>> unprotected networks.
>>
>> I'm currently running FreeBSD 10.0-STABLE
>>
>> Mike

___
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: Atheros AR9565

[tzoi516]

dhclient[1014]: send_packet: No buffer space available - is one of them,
the other has occurred during portmaster installs.

I have two FreeBSD laptops side-by-side with the same settings to the
same router and the Intel (iwn0, with FreeBSD 10.0-RELEASE) isn't giving
me any errors.

Mike

On 04/08/14 14:38, Adrian Chadd wrote:
> Ah. Can you post the buffer errors you're seeing?
>
>
> -a
>
>
> On 8 April 2014 11:37, tzoi516  wrote:
>> On 04/08/14 14:23, Adrian Chadd wrote:
>>> It should work fine on -10 and HEAD. Is it not working fine?
>>>
>>>
>>> -a
>>>
>>>
>>> On 8 April 2014 09:12, tzoi516  wrote:
 I have a Toshiba Satellite S55-A5169
 This specific one:
 http://www.bhphotovideo.com/c/product/1024074-REG/toshiba_pskk6u_08c08t_s55_i7_4700mq_12gb_1tb_windows_8_1_15_6_silver.html)

 It has the Atheros combo Wi-Fi/NIC, and the Wi-Fi uses the AR9565. For
 it to work I have to change the SATA Controller Mode in the BIOS from
 "AHCI" to "Compatibility". I don't know if this information helps, and
 it's the only AHCI setting I can tweak.

 Mike
 ___
 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"
>> With SATA controller mode set to Compatibility then it works, but a
>> little wonky at startup - sometimes I'll have to run wpa_supplicant -i
>> wlan0 -c /etc/wpa_supplicant.conf. Infrequently a buffer error appears.
>> With SATA controller mode set to AHCI then I can ifconfig wlan0 list
>> scan and see available networks but I can't connect to any except for
>> unprotected networks.
>>
>> I'm currently running FreeBSD 10.0-STABLE
>>
>> Mike

___
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: Atheros AR9565

[Adrian Chadd]

Ah. Can you post the buffer errors you're seeing?


-a


On 8 April 2014 11:37, tzoi516  wrote:
> On 04/08/14 14:23, Adrian Chadd wrote:
>> It should work fine on -10 and HEAD. Is it not working fine?
>>
>>
>> -a
>>
>>
>> On 8 April 2014 09:12, tzoi516  wrote:
>>> I have a Toshiba Satellite S55-A5169
>>> This specific one:
>>> http://www.bhphotovideo.com/c/product/1024074-REG/toshiba_pskk6u_08c08t_s55_i7_4700mq_12gb_1tb_windows_8_1_15_6_silver.html)
>>>
>>> It has the Atheros combo Wi-Fi/NIC, and the Wi-Fi uses the AR9565. For
>>> it to work I have to change the SATA Controller Mode in the BIOS from
>>> "AHCI" to "Compatibility". I don't know if this information helps, and
>>> it's the only AHCI setting I can tweak.
>>>
>>> Mike
>>> ___
>>> 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"
> With SATA controller mode set to Compatibility then it works, but a
> little wonky at startup - sometimes I'll have to run wpa_supplicant -i
> wlan0 -c /etc/wpa_supplicant.conf. Infrequently a buffer error appears.
> With SATA controller mode set to AHCI then I can ifconfig wlan0 list
> scan and see available networks but I can't connect to any except for
> unprotected networks.
>
> I'm currently running FreeBSD 10.0-STABLE
>
> Mike
___
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: Atheros AR9565

[tzoi516]

On 04/08/14 14:23, Adrian Chadd wrote:
> It should work fine on -10 and HEAD. Is it not working fine?
>
>
> -a
>
>
> On 8 April 2014 09:12, tzoi516  wrote:
>> I have a Toshiba Satellite S55-A5169
>> This specific one:
>> http://www.bhphotovideo.com/c/product/1024074-REG/toshiba_pskk6u_08c08t_s55_i7_4700mq_12gb_1tb_windows_8_1_15_6_silver.html)
>>
>> It has the Atheros combo Wi-Fi/NIC, and the Wi-Fi uses the AR9565. For
>> it to work I have to change the SATA Controller Mode in the BIOS from
>> "AHCI" to "Compatibility". I don't know if this information helps, and
>> it's the only AHCI setting I can tweak.
>>
>> Mike
>> ___
>> 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"
With SATA controller mode set to Compatibility then it works, but a
little wonky at startup - sometimes I'll have to run wpa_supplicant -i
wlan0 -c /etc/wpa_supplicant.conf. Infrequently a buffer error appears.
With SATA controller mode set to AHCI then I can ifconfig wlan0 list
scan and see available networks but I can't connect to any except for
unprotected networks.

I'm currently running FreeBSD 10.0-STABLE

Mike
___
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: Atheros AR9565

[Adrian Chadd]

It should work fine on -10 and HEAD. Is it not working fine?


-a


On 8 April 2014 09:12, tzoi516  wrote:
> I have a Toshiba Satellite S55-A5169
> This specific one:
> http://www.bhphotovideo.com/c/product/1024074-REG/toshiba_pskk6u_08c08t_s55_i7_4700mq_12gb_1tb_windows_8_1_15_6_silver.html)
>
> It has the Atheros combo Wi-Fi/NIC, and the Wi-Fi uses the AR9565. For
> it to work I have to change the SATA Controller Mode in the BIOS from
> "AHCI" to "Compatibility". I don't know if this information helps, and
> it's the only AHCI setting I can tweak.
>
> Mike
> ___
> 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: Atheros AR9565 detected, not working

[Adrian Chadd]

Cool, thanks.

Please make sure you post patches for all the things you fix. I'd love
to see this kind of thing work out of the box. :)


-adrian

On 29 July 2013 07:36, Anthony Jenkins  wrote:
> Thanks Adrian,
>
> I've managed to fix a few things on this laptop, the remaining stuff is
> BIOS/ACPI related.  acpi_hp(4) isn't working, has something to do with WMI.
> Hoping if I fix the ACPI stuff I can have me AR9565 working.  I'll poke
> around and report back; the RFKill suggestion is a good place to start
> looking.
>
> Thanks,
> Anthony
>
>
> On 07/29/13 10:30, Adrian Chadd wrote:
>>
>> Hm, maybe rfkill is set?
>>
>> The AR9565 is supported. I have the reference NICs from Atheros; they
>> work just fine.
>>
>> It may be some kind of ACPI setting to enable/disable RFKill so the
>> radio side is actually enabled.
>>
>> I'm sorry, I don't have much more than that to offer without having
>> the laptop here.
>>
>> If someone's willing to send me one, I'll get 10 + wireless working on
>> it and then hand it over to ixsystems to join the 'stuff we really
>> should get pcbsd running smoothly on' pile. They're about $500 off of
>> amazon.com.
>>
>> Thanks,
>>
>>
>>
>> -adrian
>>
>> On 29 July 2013 07:21, Anthony Jenkins  wrote:
>>>
>>> I just got an HP ENVY Sleekbook 6z-1100 laptop hoping it came with a
>>> FreeBSD-supported wireless NIC.  It has an Atheros AR9565 and looking at
>>> the
>>> logs it _seems_ like it should be working, but I get no network traffic.
>>> I
>>> haven't started the Atheros debugging procedure yet, save to compile in
>>> option AH_DEBUG and move ath(4) out of the kernel & to a module to
>>> facilitate changes.  Works (of course) in Win8 which came with laptop.
>>> Wireless enabled LED is amber (disabled) in FreeBSD, goes from amber to
>>> white (enabled) when I boot the Win8 HDD.
>>>
>>> Here's various logs and misc. system info.  What should I try next?
>>> Thanks
>>> in advance!
>>>
>>> [root@laptop /usr/src]# uname -a n
>>> FreeBSD laptop.qtchat.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sat Jul
>>> 27
>>> 23:45:30 EDT 2013 r...@laptop.qtchat.org:/usr/obj/usr/src/sys/MYKERNEL
>>> amd64
>>>
>>> [root@laptop /usr/src]# dmesg
>>> Copyright (c) 1992-2013 The FreeBSD Project.
>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>>  The Regents of the University of California. All rights reserved.
>>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>>> FreeBSD 10.0-CURRENT #0: Sat Jul 27 23:45:30 EDT 2013
>>>  r...@laptop.qtchat.org:/usr/obj/usr/src/sys/MYKERNEL amd64
>>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>>> module_register: module pci/xhci already exists!
>>> Module pci/xhci failed to register: 17
>>> CPU: AMD A10-4655M APU with Radeon(tm) HD Graphics   (1996.31-MHz
>>> K8-class
>>> CPU)
>>>Origin = "AuthenticAMD"  Id = 0x610f01  Family = 0x15  Model = 0x10
>>> Stepping = 1
>>>
>>> Features=0x178bfbff
>>>
>>> Features2=0x3e98320b
>>>AMD Features=0x2e500800
>>>AMD
>>>
>>> Features2=0x1abbfff,NodeId,TBM,,>
>>>Standard Extended Features=0x8
>>>TSC: P-state invariant, performance statistics
>>> real memory  = 17179869184 (16384 MB)
>>> avail memory = 15463530496 (14747 MB)
>>> Event timer "LAPIC" quality 400
>>> ACPI APIC Table: 
>>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>>> FreeBSD/SMP: 1 package(s) x 4 core(s)
>>>   cpu0 (BSP): APIC ID: 16
>>>   cpu1 (AP): APIC ID: 17
>>>   cpu2 (AP): APIC ID: 18
>>>   cpu3 (AP): APIC ID: 19
>>> ioapic0: Changing APIC ID to 4
>>> ioapic0  irqs 0-23 on motherboard
>>> kbd1 at kbdmux0
>>> acpi0:  on motherboard
>>> acpi0: Power Button (fixed)
>>> cpu0:  on acpi0
>>> cpu1:  on acpi0
>>> cpu2:  on acpi0
>>> cpu3:  on acpi0
>>> hpet0:  iomem 0xfed0-0xfed003ff irq 0,8
>>> on
>>> acpi0
>>> Timecounter "HPET" frequency 14318180 Hz quality 950
>>> atrtc0:  port 0x70-0x71 on acpi0
>>> Event timer "RTC" frequency 32768 Hz quality 0
>>> attimer0:  port 0x40-0x43 on acpi0
>>> Timecounter "i8254" frequency 1193182 Hz quality 0
>>> Event timer "i8254" frequency 1193182 Hz quality 100
>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
>>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
>>> acpi_ec0:  port 0x62,0x66 iomem
>>> 0xff00-0xff000fff on acpi0
>>> acpi_button0:  on acpi0
>>> pcib0:  port 0xcf8-0xcff on acpi0
>>> pci0:  on pcib0
>>> vgapci0:  port 0x3000-0x30ff mem
>>> 0xe000-0xefff,0xf030-0xf033 irq 17 at device 1.0 on pci0
>>> acpi_video0:  on vgapci0
>>> hdac0:  mem 0xf0344000-0xf0347fff irq 18 at
>>> device 1.1 on pci0
>>> hdac0: hdac_get_capabilities: Invalid corb size (0); assuming 256.
>>> hdac0: hdac_get_capabilities: Invalid rirb size (0); assuming 256.
>>> pcib1:  at device 4.0 on pci0
>>> pci1:  on pcib1
>>> pci1:  at device 0.0 (no driver attached)
>>> re0:  port
>>> 0x2000-0x20ff mem 0xf0004000-0xf0004fff,0xf000-0xf0003fff irq 16 at
>>> device 0.2 on pci1
>>> re0: Using 1 MSI-X message

Re: Atheros AR9565 detected, not working

[Anthony Jenkins]

Thanks Adrian,

I've managed to fix a few things on this laptop, the remaining stuff is 
BIOS/ACPI related.  acpi_hp(4) isn't working, has something to do with 
WMI.  Hoping if I fix the ACPI stuff I can have me AR9565 working.  I'll 
poke around and report back; the RFKill suggestion is a good place to 
start looking.


Thanks,
Anthony

On 07/29/13 10:30, Adrian Chadd wrote:

Hm, maybe rfkill is set?

The AR9565 is supported. I have the reference NICs from Atheros; they
work just fine.

It may be some kind of ACPI setting to enable/disable RFKill so the
radio side is actually enabled.

I'm sorry, I don't have much more than that to offer without having
the laptop here.

If someone's willing to send me one, I'll get 10 + wireless working on
it and then hand it over to ixsystems to join the 'stuff we really
should get pcbsd running smoothly on' pile. They're about $500 off of
amazon.com.

Thanks,



-adrian

On 29 July 2013 07:21, Anthony Jenkins  wrote:

I just got an HP ENVY Sleekbook 6z-1100 laptop hoping it came with a
FreeBSD-supported wireless NIC.  It has an Atheros AR9565 and looking at the
logs it _seems_ like it should be working, but I get no network traffic.  I
haven't started the Atheros debugging procedure yet, save to compile in
option AH_DEBUG and move ath(4) out of the kernel & to a module to
facilitate changes.  Works (of course) in Win8 which came with laptop.
Wireless enabled LED is amber (disabled) in FreeBSD, goes from amber to
white (enabled) when I boot the Win8 HDD.

Here's various logs and misc. system info.  What should I try next? Thanks
in advance!

[root@laptop /usr/src]# uname -a n
FreeBSD laptop.qtchat.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sat Jul 27
23:45:30 EDT 2013 r...@laptop.qtchat.org:/usr/obj/usr/src/sys/MYKERNEL
amd64

[root@laptop /usr/src]# dmesg
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #0: Sat Jul 27 23:45:30 EDT 2013
 r...@laptop.qtchat.org:/usr/obj/usr/src/sys/MYKERNEL amd64
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
module_register: module pci/xhci already exists!
Module pci/xhci failed to register: 17
CPU: AMD A10-4655M APU with Radeon(tm) HD Graphics   (1996.31-MHz K8-class
CPU)
   Origin = "AuthenticAMD"  Id = 0x610f01  Family = 0x15  Model = 0x10
Stepping = 1
Features=0x178bfbff
Features2=0x3e98320b
   AMD Features=0x2e500800
   AMD
Features2=0x1abbfff,NodeId,TBM,,>
   Standard Extended Features=0x8
   TSC: P-state invariant, performance statistics
real memory  = 17179869184 (16384 MB)
avail memory = 15463530496 (14747 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
  cpu0 (BSP): APIC ID: 16
  cpu1 (AP): APIC ID: 17
  cpu2 (AP): APIC ID: 18
  cpu3 (AP): APIC ID: 19
ioapic0: Changing APIC ID to 4
ioapic0  irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0:  on motherboard
acpi0: Power Button (fixed)
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
hpet0:  iomem 0xfed0-0xfed003ff irq 0,8 on
acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
atrtc0:  port 0x70-0x71 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
acpi_ec0:  port 0x62,0x66 iomem
0xff00-0xff000fff on acpi0
acpi_button0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
vgapci0:  port 0x3000-0x30ff mem
0xe000-0xefff,0xf030-0xf033 irq 17 at device 1.0 on pci0
acpi_video0:  on vgapci0
hdac0:  mem 0xf0344000-0xf0347fff irq 18 at
device 1.1 on pci0
hdac0: hdac_get_capabilities: Invalid corb size (0); assuming 256.
hdac0: hdac_get_capabilities: Invalid rirb size (0); assuming 256.
pcib1:  at device 4.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
re0:  port
0x2000-0x20ff mem 0xf0004000-0xf0004fff,0xf000-0xf0003fff irq 16 at
device 0.2 on pci1
re0: Using 1 MSI-X message
re0: turning off MSI enable bit.
re0: ASPM disabled
re0: Chip rev. 0x4880
re0: MAC rev. 0x
miibus0:  on re0
rgephy0:  PHY 1 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master,
1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
re0: Ethernet address: 6c:3b:e5:81:21:f0
pcib2:  at device 5.0 on pci0
pci2:  on pcib2
ath0:  mem 0xf010-0xf017 irq 17 at device
0.0 on pci2
ar9300_set_stub_functions: setting stub functions
ar9300_set_stub_functions: setting stub functions
ar9300_attach: calling ar9300_hw_attach
ar9300_hw_att

Re: Atheros AR9565 detected, not working

[Adrian Chadd]

Hm, maybe rfkill is set?

The AR9565 is supported. I have the reference NICs from Atheros; they
work just fine.

It may be some kind of ACPI setting to enable/disable RFKill so the
radio side is actually enabled.

I'm sorry, I don't have much more than that to offer without having
the laptop here.

If someone's willing to send me one, I'll get 10 + wireless working on
it and then hand it over to ixsystems to join the 'stuff we really
should get pcbsd running smoothly on' pile. They're about $500 off of
amazon.com.

Thanks,



-adrian

On 29 July 2013 07:21, Anthony Jenkins  wrote:
> I just got an HP ENVY Sleekbook 6z-1100 laptop hoping it came with a
> FreeBSD-supported wireless NIC.  It has an Atheros AR9565 and looking at the
> logs it _seems_ like it should be working, but I get no network traffic.  I
> haven't started the Atheros debugging procedure yet, save to compile in
> option AH_DEBUG and move ath(4) out of the kernel & to a module to
> facilitate changes.  Works (of course) in Win8 which came with laptop.
> Wireless enabled LED is amber (disabled) in FreeBSD, goes from amber to
> white (enabled) when I boot the Win8 HDD.
>
> Here's various logs and misc. system info.  What should I try next? Thanks
> in advance!
>
> [root@laptop /usr/src]# uname -a n
> FreeBSD laptop.qtchat.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sat Jul 27
> 23:45:30 EDT 2013 r...@laptop.qtchat.org:/usr/obj/usr/src/sys/MYKERNEL
> amd64
>
> [root@laptop /usr/src]# dmesg
> Copyright (c) 1992-2013 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 10.0-CURRENT #0: Sat Jul 27 23:45:30 EDT 2013
> r...@laptop.qtchat.org:/usr/obj/usr/src/sys/MYKERNEL amd64
> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
> module_register: module pci/xhci already exists!
> Module pci/xhci failed to register: 17
> CPU: AMD A10-4655M APU with Radeon(tm) HD Graphics   (1996.31-MHz K8-class
> CPU)
>   Origin = "AuthenticAMD"  Id = 0x610f01  Family = 0x15  Model = 0x10
> Stepping = 1
> Features=0x178bfbff
> Features2=0x3e98320b
>   AMD Features=0x2e500800
>   AMD
> Features2=0x1abbfff,NodeId,TBM,,>
>   Standard Extended Features=0x8
>   TSC: P-state invariant, performance statistics
> real memory  = 17179869184 (16384 MB)
> avail memory = 15463530496 (14747 MB)
> Event timer "LAPIC" quality 400
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> FreeBSD/SMP: 1 package(s) x 4 core(s)
>  cpu0 (BSP): APIC ID: 16
>  cpu1 (AP): APIC ID: 17
>  cpu2 (AP): APIC ID: 18
>  cpu3 (AP): APIC ID: 19
> ioapic0: Changing APIC ID to 4
> ioapic0  irqs 0-23 on motherboard
> kbd1 at kbdmux0
> acpi0:  on motherboard
> acpi0: Power Button (fixed)
> cpu0:  on acpi0
> cpu1:  on acpi0
> cpu2:  on acpi0
> cpu3:  on acpi0
> hpet0:  iomem 0xfed0-0xfed003ff irq 0,8 on
> acpi0
> Timecounter "HPET" frequency 14318180 Hz quality 950
> atrtc0:  port 0x70-0x71 on acpi0
> Event timer "RTC" frequency 32768 Hz quality 0
> attimer0:  port 0x40-0x43 on acpi0
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Event timer "i8254" frequency 1193182 Hz quality 100
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
> acpi_ec0:  port 0x62,0x66 iomem
> 0xff00-0xff000fff on acpi0
> acpi_button0:  on acpi0
> pcib0:  port 0xcf8-0xcff on acpi0
> pci0:  on pcib0
> vgapci0:  port 0x3000-0x30ff mem
> 0xe000-0xefff,0xf030-0xf033 irq 17 at device 1.0 on pci0
> acpi_video0:  on vgapci0
> hdac0:  mem 0xf0344000-0xf0347fff irq 18 at
> device 1.1 on pci0
> hdac0: hdac_get_capabilities: Invalid corb size (0); assuming 256.
> hdac0: hdac_get_capabilities: Invalid rirb size (0); assuming 256.
> pcib1:  at device 4.0 on pci0
> pci1:  on pcib1
> pci1:  at device 0.0 (no driver attached)
> re0:  port
> 0x2000-0x20ff mem 0xf0004000-0xf0004fff,0xf000-0xf0003fff irq 16 at
> device 0.2 on pci1
> re0: Using 1 MSI-X message
> re0: turning off MSI enable bit.
> re0: ASPM disabled
> re0: Chip rev. 0x4880
> re0: MAC rev. 0x
> miibus0:  on re0
> rgephy0:  PHY 1 on miibus0
> rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master,
> 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
> re0: Ethernet address: 6c:3b:e5:81:21:f0
> pcib2:  at device 5.0 on pci0
> pci2:  on pcib2
> ath0:  mem 0xf010-0xf017 irq 17 at device
> 0.0 on pci2
> ar9300_set_stub_functions: setting stub functions
> ar9300_set_stub_functions: setting stub functions
> ar9300_attach: calling ar9300_hw_attach
> ar9300_hw_attach: calling ar9300_eeprom_attach
> ar9300_flash_map: unimplemented for now
> Restoring Cal data from DRAM
> Restoring Cal data from EEPROM
> Restoring Cal data from Flash
> Restoring Cal