Just go to my github - github.com/erikarn/ - then click on
repositories, then the HAL fork, then just file an issue there.



Adrian


On 17 March 2013 14:22, Joshua Isom <jri...@gmail.com> wrote:
> How do you file a bug report against the fork?
>
>
> On 3/16/2013 7:25 PM, Adrian Chadd wrote:
>>
>> On 15 March 2013 15:33, Joshua Isom <jri...@gmail.com> wrote:
>>
>>>> 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
>>>> ar9300_hw_attach: ar9300_eeprom_attach returned 0
>>>> ath0: RX status length: 48
>>>> ath0: RX buffer size: 4096
>>>> ath0: TX descriptor length: 128
>>>> ath0: TX status length: 36
>>>> ath0: TX buffers per descriptor: 4
>>>> ar9300_freebsd_setup_x_tx_desc: called, 0x0/0, 0x0/0, 0x0/0
>>
>>
>> .. I really should remove that, but.
>>
>>>> ath0: ath_edma_setup_rxfifo: type=0, FIFO depth = 16 entries
>>>> ath0: ath_edma_setup_rxfifo: type=1, FIFO depth = 128 entries
>>>> ath0: [HT] enabling HT modes
>>>> ath0: [HT] enabling short-GI in 20MHz mode
>>>> ath0: [HT] 1 stream STBC receive enabled
>>>> ath0: [HT] 1 stream STBC transmit enabled
>>>> ath0: [HT] 3 RX streams; 3 TX streams
>>>> ath0: AR9380 mac 448.3 RF5110 phy 0.0
>>
>>
>> Cool, normal AR9380. Nothing fancy.
>>
>>>> ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0000
>>
>>
>>>> ar9300_Stub_GetSlotTime: called
>>>> ar9300_Stub_GetSlotTime: called
>>>> ar9300_Stub_GetCTSTimeout: called
>>>> ar9300_Stub_GetCTSTimeout: called
>>>> ar9300_Stub_GetAntennaSwitch: called
>>>> ar9300_Stub_GetAntennaSwitch: called
>>
>>
>> Ok. I should implement those stub routines in the driver. Can you file
>> a bug report (against my fork, not the qca tree) with the above stubs?
>> That way I don't forget.
>>
>> I wonder why you see them and I don't. Or do I just never check dmesg.
>>
>>>> wlan0: Ethernet address: 64:70:02:18:6d:95
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>
>>
>> This is well known. For some odd reason I get a RXEOL interrupt when I
>> initialise the RX FIFO. I don't know why yet. It's harmless but I'd
>> like to figure out why.
>>
>>>> ar9300_reset[4254]: ar9300_stop_dma_receive failed
>>
>>
>> Likely another channel scan, maybe? Or maybe it finally associated?
>>
>>>> ath0: ath_edma_recv_proc_queue: handled npkts 0 ngood 0
>>
>>
>> Thanks for being patient so far!
>>
>>
>>
>> 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"

Reply via email to