Re: Atheros AR9565 detected, not working
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Atheros AR9565 detected, not working
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 re0: Using 1 MSI-X message re0: turning off MSI enable bit. re0: ASPM disabled re0: Chip rev. 0x4880 re0: MAC rev. 0x miibus0: MII bus on re0 rgephy0: RTL8169S/8110S/8211 1000BASE-T media interface PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 6c:3b:e5:81:21:f0 pcib2: ACPI PCI-PCI bridge at device 5.0 on pci0 pci2: ACPI PCI bus on pcib2 ath0: Qualcomm Atheros AR9565 mem 0xf010-0xf017 irq 17 at device 0.0 on pci2 ar9300_set_stub_functions: setting stub functions ar9300_set_stub_functions: setting stub functions ar9300_attach: calling ar9300_hw_attach ar9300_hw_attach: calling ar9300_eeprom_attach ar9300_flash_map: unimplemented for now Restoring Cal data from DRAM Restoring Cal data from EEPROM Restoring Cal data from Flash Restoring Cal
Re: Atheros AR9565 detected, not working
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
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:
