Re: Atheros AR9565 detected, not working

2015-01-26 Thread Adrian Chadd
On 23 January 2015 at 12:45, Anthony Jenkins anthony.b.jenk...@att.net 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

2015-01-23 Thread 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 scoobi_...@yahoo.com 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 adr...@freebsd.org
To: Anthony Jenkins anthony.b.jenk...@att.net
Cc: Anthony Jenkins scoobi_...@yahoo.com; wirel...@freebsd.org
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 anthony.b.jenk...@att.net
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 adr...@freebsd.org 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

Re: Atheros AR9565 detected, not working

2015-01-10 Thread 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 scoobi_...@yahoo.com 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 adr...@freebsd.org
 To: Anthony Jenkins anthony.b.jenk...@att.net
 Cc: Anthony Jenkins scoobi_...@yahoo.com; wirel...@freebsd.org
 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 anthony.b.jenk...@att.net
 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 adr...@freebsd.org 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_S1  /* bit 1: polarity
 */
 ar9300eep.h:#define EEP_RFSILENT_GPIO_SEL  0x00fc  /* bits 2..7:
 gpio PIN */
 ar9300eep.h:#define EEP_RFSILENT_GPIO_SEL_S2  /* 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

Re: Atheros AR9565 detected, not working

2015-01-10 Thread 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 adr...@freebsd.org
 To: Anthony Jenkins anthony.b.jenk...@att.net 
Cc: Anthony Jenkins scoobi_...@yahoo.com; wirel...@freebsd.org 
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 anthony.b.jenk...@att.net 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 adr...@freebsd.org 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 */
 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_SEL    0x001c
 ../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_GPIO_SEL_S    2
 ../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_POLARITY    0x0002
 ../ah_eeprom_v1.h:#define AR_EEPROM_RFSILENT_POLARITY_S    1
 ../ah_eeprom_v3.h:#define    AR_EEPROM_RFSILENT    0x0f    /* RF
 Silent/Clock Run Enable */
 ../ah_eeprom_v3.h:#define AR_EEPROM_RFSILENT_GPIO_SEL    0x001c
 ../ah_eeprom_v3.h:#define

Re: Atheros AR9565 detected, not working

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



-a


On 7 January 2015 at 21:10, Anthony Jenkins anthony.b.jenk...@att.net 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 adr...@freebsd.org 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, 

Re: Atheros AR9565 detected, not working

2015-01-07 Thread 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 adr...@freebsd.org 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)) {
   

Re: Atheros AR9565 detected, not working

2015-01-07 Thread 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 adr...@freebsd.org 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

2014-12-23 Thread Adrian Chadd
On 22 December 2014 at 14:57, Adrian Chadd adr...@freebsd.org 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

2014-12-22 Thread 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 adr...@freebsd.org
To: Anthony Jenkins scoobi_...@yahoo.com 
Cc: wirel...@freebsd.org 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 scoobi_...@yahoo.com 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 adr...@freebsd.org
 To: Anthony Jenkins scoobi_...@yahoo.com
 Cc: freebsd-wireless@freebsd.org 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 scoobi_...@yahoo.com 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 scoobi_...@yahoo.com 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

Re: Atheros AR9565 detected, not working

2014-12-22 Thread 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 scoobi_...@yahoo.com 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 scoobi_...@yahoo.com 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 adr...@freebsd.org
 To: Anthony Jenkins scoobi_...@yahoo.com
 Cc: wirel...@freebsd.org 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 scoobi_...@yahoo.com 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 adr...@freebsd.org
 To: Anthony Jenkins scoobi_...@yahoo.com
 Cc: freebsd-wireless@freebsd.org 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 scoobi_...@yahoo.com 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 scoobi_...@yahoo.com 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

Re: Atheros AR9565 detected, not working

2014-12-22 Thread 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 scoobi_...@yahoo.com 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 scoobi_...@yahoo.com 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 adr...@freebsd.org
 To: Anthony Jenkins scoobi_...@yahoo.com
 Cc: wirel...@freebsd.org 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 scoobi_...@yahoo.com 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 adr...@freebsd.org
 To: Anthony Jenkins scoobi_...@yahoo.com
 Cc: freebsd-wireless@freebsd.org 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 scoobi_...@yahoo.com 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

Re: Atheros AR9565 detected, not working

2014-12-22 Thread Adrian Chadd
On 22 December 2014 at 11:59, Anthony Jenkins scoobi_...@yahoo.com 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

2014-12-22 Thread Anthony Jenkins via freebsd-wireless
On 12/22/2014 15:22, Adrian Chadd wrote:
 On 22 December 2014 at 11:59, Anthony Jenkins scoobi_...@yahoo.com 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: Qualcomm Atheros AR9565 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: 

Re: Atheros AR9565 detected, not working

2014-12-22 Thread Adrian Chadd
On 22 December 2014 at 13:59, Anthony Jenkins scoobi_...@yahoo.com wrote:
 On 12/22/2014 15:22, Adrian Chadd wrote:
 On 22 December 2014 at 11:59, Anthony Jenkins scoobi_...@yahoo.com 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: Qualcomm Atheros AR9565 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__, 
 

Re: Atheros AR9565 detected, not working

2014-12-21 Thread 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

2014-12-18 Thread 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 adr...@freebsd.org
To: Anthony Jenkins scoobi_...@yahoo.com 
Cc: freebsd-wireless@freebsd.org 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 scoobi_...@yahoo.com 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 scoobi_...@yahoo.com 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=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT

 Features2=0x3e98320bSSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C
AMD Features=0x2e500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM
AMD

 Features2=0x1abbfffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,b17,NodeId,TBM,b23,b24
Standard Extended Features=0x8BMI1
TSC: P-state

Re: Atheros AR9565

2014-04-11 Thread 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 scoobi_...@yahoo.com 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 adr...@freebsd.org
 To: Anthony Jenkins scoobi_...@yahoo.com
 Cc: tzoi516 tzoi...@gmail.com; freebsd-wireless@freebsd.org 
 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 scoobi_...@yahoo.com 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 scoobi_...@yahoo.com 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 adr...@freebsd.org
 To: tzoi516 tzoi...@gmail.com
 Cc: freebsd-wireless@freebsd.org 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 tzoi...@gmail.com 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

Re: Atheros AR9565

2014-04-10 Thread 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 scoobi_...@yahoo.com 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 adr...@freebsd.org
 To: tzoi516 tzoi...@gmail.com
 Cc: freebsd-wireless@freebsd.org 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 tzoi...@gmail.com 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

Fwd: Re: Atheros AR9565

2014-04-09 Thread 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 tzoi...@gmail.com 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 tzoi...@gmail.com wrote:
 Sorry for another email, the errors are sporadic. I'm trying to find the
 ioctl errors 

Re: Re: Atheros AR9565

2014-04-09 Thread 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: Atheros AR9565

2014-04-09 Thread 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 tzoi...@gmail.com 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 

Re: Atheros AR9565

2014-04-09 Thread 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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 

Re: Atheros AR9565

2014-04-09 Thread 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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
 

Re: Re: Atheros AR9565

2014-04-09 Thread Adrian Chadd
Which HP laptop?


-a


On 9 April 2014 13:35, Anthony Jenkins scoobi_...@yahoo.com 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 adr...@freebsd.org
 To: tzoi516 tzoi...@gmail.com
 Cc: freebsd-wireless@freebsd.org 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 tzoi...@gmail.com 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

Re: Re: Atheros AR9565

2014-04-09 Thread Anthony Jenkins
HP ENVY 6Z-1100 Sleekbook
http://h10025.www1.hp.com/ewfrf/wc/product?cc=usdlc=enlc=enproduct=5330122


Anthony



- Original Message -
From: Adrian Chadd adr...@freebsd.org
To: Anthony Jenkins scoobi_...@yahoo.com
Cc: tzoi516 tzoi...@gmail.com; freebsd-wireless@freebsd.org 
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 scoobi_...@yahoo.com 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 adr...@freebsd.org
 To: tzoi516 tzoi...@gmail.com
 Cc: freebsd-wireless@freebsd.org 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 tzoi...@gmail.com 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

Re: Atheros AR9565

2014-04-08 Thread Adrian Chadd
It should work fine on -10 and HEAD. Is it not working fine?


-a


On 8 April 2014 09:12, tzoi516 tzoi...@gmail.com 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

2014-04-08 Thread 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 tzoi...@gmail.com 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

2014-04-08 Thread Adrian Chadd
Ah. Can you post the buffer errors you're seeing?


-a


On 8 April 2014 11:37, tzoi516 tzoi...@gmail.com 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 tzoi...@gmail.com 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

2014-04-08 Thread 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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

2014-04-08 Thread 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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

2014-04-08 Thread 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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

2014-04-08 Thread 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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

2014-04-08 Thread 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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

2014-04-08 Thread 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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 tzoi...@gmail.com 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 detected, not working

2013-07-29 Thread 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 scoobi_...@yahoo.com 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=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT
Features2=0x3e98320bSSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C
   AMD Features=0x2e500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM
   AMD
Features2=0x1abbfffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,b17,NodeId,TBM,b23,b24
   Standard Extended Features=0x8BMI1
   TSC: P-state invariant, performance statistics
real memory  = 17179869184 (16384 MB)
avail memory = 15463530496 (14747 MB)
Event timer LAPIC quality 400
ACPI APIC Table: HPQOEM 18DE
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 Version 2.1 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: HPQOEM SLIC-MPC on motherboard
acpi0: Power Button (fixed)
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
cpu2: ACPI CPU on acpi0
cpu3: ACPI CPU on acpi0
hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on
acpi0
Timecounter HPET frequency 14318180 Hz quality 950
atrtc0: AT realtime clock port 0x70-0x71 on acpi0
Event timer RTC frequency 32768 Hz quality 0
attimer0: AT timer 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: Embedded Controller: GPE 0x3 port 0x62,0x66 iomem
0xff00-0xff000fff on acpi0
acpi_button0: Power Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
vgapci0: VGA-compatible display port 0x3000-0x30ff mem
0xe000-0xefff,0xf030-0xf033 irq 17 at device 1.0 on pci0
acpi_video0: ACPI video extension on vgapci0
hdac0: ATI (0x9902) HDA Controller 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: ACPI PCI-PCI bridge at device 4.0 on pci0
pci1: ACPI PCI bus on pcib1
pci1: unknown at device 0.0 (no driver attached)
re0: RealTek 8168/8111 B/C/CP/D/DP/E/F PCIe Gigabit Ethernet port
0x2000-0x20ff mem 0xf0004000-0xf0004fff,0xf000-0xf0003fff irq 16 at
device 0.2 on pci1

Re: Atheros AR9565 detected, not working

2013-07-29 Thread 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 scoobi_...@yahoo.com 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 scoobi_...@yahoo.com 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=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT

 Features2=0x3e98320bSSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C
AMD Features=0x2e500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM
AMD

 Features2=0x1abbfffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,b17,NodeId,TBM,b23,b24
Standard Extended Features=0x8BMI1
TSC: P-state invariant, performance statistics
 real memory  = 17179869184 (16384 MB)
 avail memory = 15463530496 (14747 MB)
 Event timer LAPIC quality 400
 ACPI APIC Table: HPQOEM 18DE
 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 Version 2.1 irqs 0-23 on motherboard
 kbd1 at kbdmux0
 acpi0: HPQOEM SLIC-MPC on motherboard
 acpi0: Power Button (fixed)
 cpu0: ACPI CPU on acpi0
 cpu1: ACPI CPU on acpi0
 cpu2: ACPI CPU on acpi0
 cpu3: ACPI CPU on acpi0
 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8
 on
 acpi0
 Timecounter HPET frequency 14318180 Hz quality 950
 atrtc0: AT realtime clock port 0x70-0x71 on acpi0
 Event timer RTC frequency 32768 Hz quality 0
 attimer0: AT timer 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: Embedded Controller: GPE 0x3 port 0x62,0x66 iomem
 0xff00-0xff000fff on acpi0
 acpi_button0: Power Button on acpi0
 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
 pci0: ACPI PCI bus on pcib0
 vgapci0: VGA-compatible display port 0x3000-0x30ff mem
 0xe000-0xefff,0xf030-0xf033 irq 17 at device 1.0 on pci0
 acpi_video0: ACPI video extension on vgapci0
 hdac0: ATI (0x9902) HDA Controller 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: