Hi all,
I have the following device (0x168c:001c) which comes with certain MacBooks:
02:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g
Wireless PCI Express Adapter (rev 01)
The current driver from merged-upstream of a few days ago doesn't seem to
work for this card. In ath5k_hw_nic_wakeup, it dies after the nic reset
and any MMIO accesses from then on return -1 (needs a hard reboot to fix).
I dumped a trace of the working madwifi driver using mmio-trace and saw that
it only sets the bottom two bits when doing AR5K_RESET_CTL. So, the patch
below indeed makes probe work for the card.
It isn't perfect after that; it can associate with an AP but appears to reset
constantly so it's not really usable.
I'd love to get this working generally; if needed I can try out patches,
supply traces, or, given enough direction, contribute some code...
diff --git a/drivers/net/wireless/ath5k/hw.c b/drivers/net/wireless/ath5k/hw.c
index 3a4bf40..3fa0621 100644
--- a/drivers/net/wireless/ath5k/hw.c
+++ b/drivers/net/wireless/ath5k/hw.c
@@ -359,7 +359,7 @@ static int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial)
/* ...reset chipset and PCI device */
if (ah->ah_single_chip == false && ath5k_hw_nic_reset(ah,
- AR5K_RESET_CTL_CHIP | AR5K_RESET_CTL_PCI)) {
+ AR5K_RESET_CTL_BASEBAND | AR5K_RESET_CTL_PCU)) {
ATH5K_ERR(ah->ah_sc, "failed to reset the MAC Chip + PCI\n");
return -EIO;
}
--
Bob Copeland %% http://www.bobcopeland.com
2008/1/31, Bob Copeland <[email protected]>:
> Hi all,
>
> I have the following device (0x168c:001c) which comes with certain MacBooks:
>
> 02:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g
> Wireless PCI Express Adapter (rev 01)
Can you plz run ath_info tool found on madwifi-trace branch and post
the output (mac/phy revision) ?
> The current driver from merged-upstream of a few days ago doesn't seem to
> work for this card. In ath5k_hw_nic_wakeup, it dies after the nic reset
> and any MMIO accesses from then on return -1 (needs a hard reboot to fix).
>
> I dumped a trace of the working madwifi driver using mmio-trace and saw that
> it only sets the bottom two bits when doing AR5K_RESET_CTL. So, the patch
> below indeed makes probe work for the card.
>
It's a known bug, i have a patch pending already, problem is that
AR5K_RESET_CTL_PCI probably hangs the "host interface unit" and you
need to reboot as you said, just removing it also fixes the probe
problem (that seems to only happen on newer pci-e cards).
> It isn't perfect after that; it can associate with an AP but appears to reset
> constantly so it's not really usable.
>
That's interesting because even with the fix on nic_wakeup + making
initvals tables etc i tried it on a 2425 and couldn't even scan
(that's why i hadn't post the patch earlier, card wouldn't work anyway
so i left it for the patch series i'm working on). If you got your
card scanning then we are really close on fixing it !
> I'd love to get this working generally; if needed I can try out patches,
> supply traces, or, given enough direction, contribute some code...
>
Thanx a lot for your patch, just have in mind that we prefer to reset
most of the card's units to be on the safe side, that's because we
don't know what cards (mac/phy revisions) can live without reseting X
unit.
Another important question, what band was the ap on ?
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
2008/2/1, Bob Copeland <[email protected]>:
> On Thu, Jan 31, 2008 at 06:56:51PM +0200, Nick Kossifidis wrote:
> > Can you plz run ath_info tool found on madwifi-trace branch and post
> > the output (mac/phy revision) ?
>
> Sure -- full output is at http://bobcopeland.com/ath5k/ along with
> EEPROM dump and a scan of my neighborhood.
>
> MAC Version: 2424 (0xa0)
> MAC Revision: 5424 (0xa3)
> Warning: Invalid EEPROM Magic number!
> Device type: 3
> 5Ghz PHY Revision: SChip (0xa2)
> 2Ghz PHY Revision: SChip (0xa2)
>
> > so i left it for the patch series i'm working on). If you got your
> > card scanning then we are really close on fixing it !
>
> Excellent news!
>
> > Another important question, what band was the ap on ?
>
> Good question - it was a Starbucks hotspot so I'm guessing 802.11b?
>
Wow that's the first 5424 report we have ;-)
Do you have an AP so you can run the testbed-trace as described here ?
http://madwifi.org/wiki/DevDocs/MadwifiTrace
b/g modes are ok for start (you can force mode from the sta using
iwpriv ath0 mode X, x=1(a) 2(b) 3(g)) but if you can also provide
dumps for a and turbo modes it would be really cool (you 'll need an
atheros-based ap for the turbo mode to run testbed-trace, if you don't
have such ap then you can try to setup your card as AP for a and
turboa modes -static turbo-, dumps from ap operation will also do,
just make sure you force the mode through iwpriv).
If you provide me with the needed dumps i'll work on it and give you a
tarball to test asap (asap > 10days due to exams ;-( ) !!!
One more question: can you plz describe card's behaviour with ath5k ?
What error message does it return on reset-failure ?
Thanx a lot for the feedback ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Sun, Feb 10, 2008 at 09:05:38PM +0200, Nick Kossifidis wrote:
> 2008/2/10, Bob Copeland <[email protected]>:
> > I'll post a patch later tonight.
Well I spoke too soon :) I was unable to repeatedly get this to work
so I guess maybe I was lucky the times it did. Here's what I have so
far.
- in my traces the hal always set DMA == 128B. So I did not bump it up,
and that seemed to cure rx overrun. Obviously should be done on a
per-card basis.
- turned off reset of PCI to avoid host interface unit hang as discussed
previously
- noticed this card has a different sleep pending value, not sure what
the rf5413 uses compared to this
- added various registers that I have no idea what they do.
> Did you forced b mode via iwpriv while tracing (even if ap is b-only
> card will use g settings) ? You should at least see different IFS etc
> settings (check out initvals).
Not sure, I'll try them again. Are the other traces for other cards
online somewhere?
> Good work ;-)
Heh I really don't know a phy from a sta so feel free to pick this
apart...
>From 53d584dd188a131632e09353d1dd674f02a15b3c Mon Sep 17 00:00:00 2001
From: Bob Copeland <[email protected]>
Date: Sat, 9 Feb 2008 00:16:12 -0500
Subject: [PATCH] ath5k: changes for 5424/2424 cards
This adds some register writes and updates some values used by
the Atheros 5424 chipset. This is just an experimental patch that
should not be applied.
---
drivers/net/wireless/ath5k/hw.c | 29 ++++++++++++++++++++++-------
1 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath5k/hw.c b/drivers/net/wireless/ath5k/hw.c
index 3a4bf40..ba832b0 100644
--- a/drivers/net/wireless/ath5k/hw.c
+++ b/drivers/net/wireless/ath5k/hw.c
@@ -358,8 +358,8 @@ static int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial)
}
/* ...reset chipset and PCI device */
- if (ah->ah_single_chip == false && ath5k_hw_nic_reset(ah,
- AR5K_RESET_CTL_CHIP | AR5K_RESET_CTL_PCI)) {
+ if (ah->ah_single_chip == false && ath5k_hw_nic_reset(ah,
+ AR5K_RESET_CTL_CHIP)) {
ATH5K_ERR(ah->ah_sc, "failed to reset the MAC Chip + PCI\n");
return -EIO;
}
@@ -887,9 +887,9 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
*/
if (ah->ah_version != AR5K_AR5210) {
AR5K_REG_WRITE_BITS(ah, AR5K_TXCFG, AR5K_TXCFG_SDMAMR,
- AR5K_DMASIZE_512B | AR5K_TXCFG_DMASIZE);
+ AR5K_DMASIZE_128B | AR5K_TXCFG_DMASIZE);
AR5K_REG_WRITE_BITS(ah, AR5K_RXCFG, AR5K_RXCFG_SDMAMW,
- AR5K_DMASIZE_512B);
+ AR5K_DMASIZE_128B);
}
/*
@@ -981,14 +981,22 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
* Set the 32MHz reference clock on 5212 phy clock sleep register
*/
if (ah->ah_version == AR5K_AR5212) {
+ int spending;
+
ath5k_hw_reg_write(ah, AR5K_PHY_SCR_32MHZ, AR5K_PHY_SCR);
ath5k_hw_reg_write(ah, AR5K_PHY_SLMT_32MHZ, AR5K_PHY_SLMT);
ath5k_hw_reg_write(ah, AR5K_PHY_SCAL_32MHZ, AR5K_PHY_SCAL);
ath5k_hw_reg_write(ah, AR5K_PHY_SCLOCK_32MHZ, AR5K_PHY_SCLOCK);
ath5k_hw_reg_write(ah, AR5K_PHY_SDELAY_32MHZ, AR5K_PHY_SDELAY);
- ath5k_hw_reg_write(ah, ah->ah_radio == AR5K_RF5111 ?
- AR5K_PHY_SPENDING_RF5111 : AR5K_PHY_SPENDING_RF5112,
- AR5K_PHY_SPENDING);
+
+ if (ah->ah_radio <= AR5K_RF5111)
+ spending = AR5K_PHY_SPENDING_RF5111;
+ else if (ah->ah_radio <= AR5K_RF5112)
+ spending = AR5K_PHY_SPENDING_RF5112;
+ else
+ spending = 0x12;
+
+ ath5k_hw_reg_write(ah, spending, AR5K_PHY_SPENDING);
}
/*
@@ -997,6 +1005,13 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
AR5K_REG_DISABLE_BITS(ah, AR5K_BEACON, AR5K_BEACON_ENABLE |
AR5K_BEACON_RESET_TSF);
+ if (ah->ah_mac_srev >= AR5K_SREV_VER_AR2424) {
+ ath5k_hw_reg_write(ah, 0x000100aa, 0x8118);
+ ath5k_hw_reg_write(ah, 0x00003210, 0x811c);
+ ath5k_hw_reg_write(ah, 0x00000052, 0x8108);
+ ath5k_hw_reg_write(ah, 0x001e1e1e, AR5K_TXPC);
+ ath5k_hw_reg_write(ah, 0x00000004, 0x8120);
+ }
return 0;
}
--
1.5.4
--
Bob Copeland %% http://www.bobcopeland.com
On Tue, Feb 05, 2008 at 11:13:35AM +0200, Nick Kossifidis wrote:
> It's fine, that's cool it seems phy is ok (and hopefully is the same
> with 5413 as i thought), it must be some mac settings related to pci-e
> that result rx overrun, i've spotted some registers but i'll need to
> spend some time on it and right now that's not possible ;-(
So I played around with the code this weekend and have gotten it to
work somewhat (I am posting this using the driver). I think it only
works right after system power-up and something's not right because it's
a little laggy.
One weird thing -- in my traces, the g-mode tables seem to be the b-mode
tables and vice-versa. I may have mixed up the trace files but I'm not
sure how. Anyway it works without changes to the initvals.
I'll post a patch later tonight.
--
Bob Copeland %% http://www.bobcopeland.com
On Sat, Feb 02, 2008 at 03:48:34AM +0200, Nick Kossifidis wrote:
> > Yeah I have an AP but it's broadcom based. I'll try to do the traces this
> > weekend.
> >
>
> Thanx ;-)
Ok, so I did -b and -g traces. That branch is a little out of date, so
I wound up downgrading to 2.6.22.
I don't have an a-capable AP, so how might I get a/turboa/turbog traces?
Do I use wlanconfig from the madwifi docs like so:
$ iwpriv ath0 mode 1
$ wlanconfig ath0 create wlandev wifi0 wlanmode ap
What mode # is used for turbo a/g?
I put the tarballs at http://bobcopeland.com/ath5k/
> Great info ! Your card sends the RXORN interrupt (Rx overrun), at
> least we know what the problem is ;-)
>
> How about your signal strength ?
Looks fine, I think:
Quality=89/100 Signal level=-39 dBm Noise level=-96 dBm
> That's ok since we haven't added initvals/rfbuffer tables for your
> card so phy isn't initialized propertly (this is the first problem we
> should fix so we can be sure that rx overrun is not phy-related).
OK, well I guess that info is in the tarballs. I poked around in the
code, and it looks like my tables are similar to 5413 with maybe a
couple of extra registers. But I'll await your analysis. :)
> 1472 if (ah->ah_version != AR5K_AR5210) {
> 1473 /*HIU = Host Interface Unit (PCI etc)*/
> 1474 if (unlikely(data & (AR5K_ISR_HIUERR)))
> 1475 *interrupt_mask |= AR5K_INT_FATAL;
>
>
> Change AR5K_ISR_HIUERR with AR5K_ISR_RXORN
It does get rid of the message, but other than not seeing the printk
any more, it doesn't seem to help things much.
Good luck on the exams!
--
Bob Copeland %% http://www.bobcopeland.com
2008/2/12, Holger Schurig <[email protected]>:
> > Nope i have them all gathered on my laptop, you 'll sure find
> > some posted on ath5k-devel list. I'll send you a b-only trace
> > from one of my cards (a 5413) to check it out ;-)
> >
> > We are working on a way to have all dumps uploaded
> > somewhere...
>
> Why not put them into SVN ? Put them there in some original
> format and in a text-format, so you can easily add comments with
> a text editor into the dumps. That comments could then be used
> as markers for automatically comparing the dumps of different
> cards.
>
That's also a possibility ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
On Tue, Feb 12, 2008 at 09:18:05AM +0200, Nick Kossifidis wrote:
> > Not sure, I'll try them again. Are the other traces for other cards
> > online somewhere?
>
> Nope i have them all gathered on my laptop, you 'll sure find some
> posted on ath5k-devel list. I'll send you a b-only trace from one of
> my cards (a 5413) to check it out ;-)
>
> We are working on a way to have all dumps uploaded somewhere...
Okay that would be good. I was basically searching for differences by
hooking ath_hw_reg_write with a printk, sorting that, and diffing it
with a sorted file of "reg_address:value" extracted from the traces.
Would be useful to run the same scripts over other cards' dumps...
>
> > - AR5K_DMASIZE_512B);
> > + AR5K_DMASIZE_128B);
> > }
>
> Have you tried 256 ? Also have you tried only setting lower dma size for rx ?
I did a few times, but not enough to definitively say which works and
which doesn't. I'll try to get it repeatedly starting up correctly when
I get some free time, and from there I should be able to figure out
what's actually needed and what is noise.
> > + ath5k_hw_reg_write(ah, 0x001e1e1e, AR5K_TXPC);
>
> Remove TXPC and see what happens...
Sure, I'll give that a go as well.
--
Bob Copeland %% http://www.bobcopeland.com
On Thu, Jan 31, 2008 at 06:56:51PM +0200, Nick Kossifidis wrote:
> Can you plz run ath_info tool found on madwifi-trace branch and post
> the output (mac/phy revision) ?
Sure -- full output is at http://bobcopeland.com/ath5k/ along with
EEPROM dump and a scan of my neighborhood.
MAC Version: 2424 (0xa0)
MAC Revision: 5424 (0xa3)
Warning: Invalid EEPROM Magic number!
Device type: 3
5Ghz PHY Revision: SChip (0xa2)
2Ghz PHY Revision: SChip (0xa2)
> so i left it for the patch series i'm working on). If you got your
> card scanning then we are really close on fixing it !
Excellent news!
> Another important question, what band was the ap on ?
Good question - it was a Starbucks hotspot so I'm guessing 802.11b?
--
Bob Copeland %% http://www.bobcopeland.com
On Fri, Feb 01, 2008 at 02:09:26PM +0200, Nick Kossifidis wrote:
>
> Do you have an AP so you can run the testbed-trace as described here ?
> http://madwifi.org/wiki/DevDocs/MadwifiTrace
Yeah I have an AP but it's broadcom based. I'll try to do the traces this
weekend.
> One more question: can you plz describe card's behaviour with ath5k ?
> What error message does it return on reset-failure ?
Well, with the change from my original post, the card appears to
function somewhat but the cpu gets busy and the whole machine crawls.
Note, I didn't make any changes for initvals.
I can associate but not for very long. dmesg looks like this:
ath5k phy0: Atheros AR5424 chip found (MAC: 0xa3, PHY: 0x61)
NET: Registered protocol family 17
ath0: Initial auth_alg=0
ath0: authenticate with AP 00:1a:70:da:a9:cd
ath0: RX authentication from 00:1a:70:da:a9:cd (alg=0 transaction=2
status=0)
ath0: authenticated
ath0: associate with AP 00:1a:70:da:a9:cd
ath0: RX AssocResp from 00:1a:70:da:a9:cd (capab=0x411 status=0 aid=2)
ath0: associated
ath0: switched to long barker preamble (BSSID=00:1a:70:da:a9:cd)
ath5k_hw_get_isr: 0x00000020
ath5k_hw_get_isr: 0x00000020
ath5k_hw_get_isr: 0x00000020
ath5k_hw_get_isr: 0x00000020
[repeats a ton]
ath0: No ProbeResp from current AP 00:1a:70:da:a9:cd - assume out of
range
printk: 81 messages suppressed.
ath5k_hw_get_isr: 0x00000020
printk: 36 messages suppressed.
ath5k_hw_get_isr: 0x00000020
and sometimes:
ath5k phy3: noise floor calibration timeout (2462MHz)
With debug on these were the resets I was seeing, may be normal but I
didn't know:
ath5k trace ath5k_hw_stop_tx_dma:1241
ath5k trace ath5k_hw_stop_pcu_recv:2433
ath5k trace ath5k_hw_set_rx_filter:2518
ath5k trace ath5k_hw_stop_rx_dma:1143
ath5k trace ath5k_hw_reset:573
ath5k trace ath5k_hw_get_rf_gain:1349
ath5k trace ath5k_hw_nic_wakeup:290
ath5k trace ath5k_hw_set_power:1058
ath5k trace ath5k_hw_set_power:1058
ath5k trace ath5k_hw_nic_reset:1011
ath5k trace ath5k_hw_txpower:2012
ath5k trace ath5k_hw_get_rate_table:401
ath5k trace ath5k_hw_disable_pspoll:4342
ath5k trace ath5k_hw_set_opmode:2187
ath5k trace ath5k_hw_reset_tx_queue:3173
> Thanx a lot for the feedback ;-)
np!
--
Bob Copeland %% http://www.bobcopeland.com
2008/2/2, Bob Copeland <[email protected]>:
> On Fri, Feb 01, 2008 at 02:09:26PM +0200, Nick Kossifidis wrote:
> >
> > Do you have an AP so you can run the testbed-trace as described here ?
> > http://madwifi.org/wiki/DevDocs/MadwifiTrace
>
> Yeah I have an AP but it's broadcom based. I'll try to do the traces this
> weekend.
>
Thanx ;-)
> > One more question: can you plz describe card's behaviour with ath5k ?
> > What error message does it return on reset-failure ?
>
> Well, with the change from my original post, the card appears to
> function somewhat but the cpu gets busy and the whole machine crawls.
> Note, I didn't make any changes for initvals.
>
> I can associate but not for very long. dmesg looks like this:
>
> ath5k phy0: Atheros AR5424 chip found (MAC: 0xa3, PHY: 0x61)
> NET: Registered protocol family 17
> ath0: Initial auth_alg=0
> ath0: authenticate with AP 00:1a:70:da:a9:cd
> ath0: RX authentication from 00:1a:70:da:a9:cd (alg=0 transaction=2
> status=0)
> ath0: authenticated
> ath0: associate with AP 00:1a:70:da:a9:cd
> ath0: RX AssocResp from 00:1a:70:da:a9:cd (capab=0x411 status=0 aid=2)
> ath0: associated
> ath0: switched to long barker preamble (BSSID=00:1a:70:da:a9:cd)
> ath5k_hw_get_isr: 0x00000020
> ath5k_hw_get_isr: 0x00000020
> ath5k_hw_get_isr: 0x00000020
> ath5k_hw_get_isr: 0x00000020
Great info ! Your card sends the RXORN interrupt (Rx overrun), at
least we know what the problem is ;-)
How about your signal strength ?
> [repeats a ton]
> ath0: No ProbeResp from current AP 00:1a:70:da:a9:cd - assume out of
> range
That's normal since we have rx overrun frames don't reach the driver...
> and sometimes:
> ath5k phy3: noise floor calibration timeout (2462MHz)
>
That's ok since we haven't added initvals/rfbuffer tables for your
card so phy isn't initialized propertly (this is the first problem we
should fix so we can be sure that rx overrun is not phy-related).
> With debug on these were the resets I was seeing, may be normal but I
> didn't know:
>
> ath5k trace ath5k_hw_stop_tx_dma:1241
> ath5k trace ath5k_hw_stop_pcu_recv:2433
> ath5k trace ath5k_hw_set_rx_filter:2518
> ath5k trace ath5k_hw_stop_rx_dma:1143
> ath5k trace ath5k_hw_reset:573
> ath5k trace ath5k_hw_get_rf_gain:1349
> ath5k trace ath5k_hw_nic_wakeup:290
> ath5k trace ath5k_hw_set_power:1058
> ath5k trace ath5k_hw_set_power:1058
> ath5k trace ath5k_hw_nic_reset:1011
> ath5k trace ath5k_hw_txpower:2012
> ath5k trace ath5k_hw_get_rate_table:401
> ath5k trace ath5k_hw_disable_pspoll:4342
> ath5k trace ath5k_hw_set_opmode:2187
> ath5k trace ath5k_hw_reset_tx_queue:3173
>
Yup on rx overrun card resets but it worries me that get_isr reports
it, get_isr only prints an interrupt code when it doesn't process it,
and that's a bug in your case (on some cards rx overrun is fatal and
we don't handle this right now, well just one more fix to add on my
pending patches ;-) ).
Try this fix...
edit drivers/net/wireless/ath5k/hw.c, go to ath5k_hw_get_isr and
you'll see this...
1472 if (ah->ah_version != AR5K_AR5210) {
1473 /*HIU = Host Interface Unit (PCI etc)*/
1474 if (unlikely(data & (AR5K_ISR_HIUERR)))
1475 *interrupt_mask |= AR5K_INT_FATAL;
Change AR5K_ISR_HIUERR with AR5K_ISR_RXORN
This will force a card reset once you receive an RXORN interrupt (will
report it as FATAL) and will get rid of get_isr message ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
I spent a bunch of reboots on trying to narrow down what needs to stay
and what can go. Driver is still a little flaky for this card; I'd say
about one third of the time I do an insmod the card gets hung and I need
to reboot. That makes it harder to rule certain changes in/out.
Also, the calibration stuff will hang more than half the time if we
reset everything but the CTL_PCI. I've gone back to just resetting _PCU
and _BASEBAND for now. Maybe this wants a card-specific flag, or like
Jiri's patch just skip the second reset?
> Have you tried 256 ? Also have you tried only setting lower dma size for rx ?
512 for tx definitely did not work. Will try 256 and let you know.
> > + if (ah->ah_mac_srev >= AR5K_SREV_VER_AR2424) {
> > + ath5k_hw_reg_write(ah, 0x000100aa, 0x8118);
> > + ath5k_hw_reg_write(ah, 0x00003210, 0x811c);
> > + ath5k_hw_reg_write(ah, 0x00000052, 0x8108);
> > + ath5k_hw_reg_write(ah, 0x001e1e1e, AR5K_TXPC);
>
> Remove TXPC and see what happens...
Yep TXPC can absolutely go. 0x8118 can probably go away too. Still unsure
about 811c/8108.
> > + ath5k_hw_reg_write(ah, 0x00000004, 0x8120);
It never worked without this one.
--
Bob Copeland %% http://www.bobcopeland.com
> Ok, so I did -b and -g traces. That branch is a little out of date, so
> I wound up downgrading to 2.6.22.
>
> I don't have an a-capable AP, so how might I get a/turboa/turbog traces?
> Do I use wlanconfig from the madwifi docs like so:
>
> $ iwpriv ath0 mode 1
> $ wlanconfig ath0 create wlandev wifi0 wlanmode ap
>
> What mode # is used for turbo a/g?
>
turbog doesn't work, turboa is 4 i think, don't worry about turbo
modes, just try to get a regdump for a and it'll be fine (check out
initvals to be sure if you like that you are on a mode) ;-)
> I put the tarballs at http://bobcopeland.com/ath5k/
>
Great, thanx a lot ;-)
> > Great info ! Your card sends the RXORN interrupt (Rx overrun), at
> > least we know what the problem is ;-)
> >
> > How about your signal strength ?
>
> Looks fine, I think:
> Quality=89/100 Signal level=-39 dBm Noise level=-96 dBm
>
It's fine, that's cool it seems phy is ok (and hopefully is the same
with 5413 as i thought), it must be some mac settings related to pci-e
that result rx overrun, i've spotted some registers but i'll need to
spend some time on it and right now that's not possible ;-(
> > That's ok since we haven't added initvals/rfbuffer tables for your
> > card so phy isn't initialized propertly (this is the first problem we
> > should fix so we can be sure that rx overrun is not phy-related).
>
> OK, well I guess that info is in the tarballs. I poked around in the
> code, and it looks like my tables are similar to 5413 with maybe a
> couple of extra registers. But I'll await your analysis. :)
>
Might be some other part of reset/attach that we miss, i'll look on it asap ;-)
> > 1472 if (ah->ah_version != AR5K_AR5210) {
> > 1473 /*HIU = Host Interface Unit (PCI etc)*/
> > 1474 if (unlikely(data & (AR5K_ISR_HIUERR)))
> > 1475 *interrupt_mask |= AR5K_INT_FATAL;
> >
> >
> > Change AR5K_ISR_HIUERR with AR5K_ISR_RXORN
>
> It does get rid of the message, but other than not seeing the printk
> any more, it doesn't seem to help things much.
>
> Good luck on the exams!
>
Thanx a lot and thanx for the traces ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
2008/2/11, Bob Copeland <[email protected]>:
> On Sun, Feb 10, 2008 at 09:05:38PM +0200, Nick Kossifidis wrote:
> > 2008/2/10, Bob Copeland <[email protected]>:
> > > I'll post a patch later tonight.
>
> Well I spoke too soon :) I was unable to repeatedly get this to work
> so I guess maybe I was lucky the times it did. Here's what I have so
> far.
>
> - in my traces the hal always set DMA == 128B. So I did not bump it up,
> and that seemed to cure rx overrun. Obviously should be done on a
> per-card basis.
>
It makes sense, i'll see what effect this has on other cards too ;-)
> - turned off reset of PCI to avoid host interface unit hang as discussed
> previously
>
ACK
> - noticed this card has a different sleep pending value, not sure what
> the rf5413 uses compared to this
>
> - added various registers that I have no idea what they do.
>
> > Did you forced b mode via iwpriv while tracing (even if ap is b-only
> > card will use g settings) ? You should at least see different IFS etc
> > settings (check out initvals).
>
> Not sure, I'll try them again. Are the other traces for other cards
> online somewhere?
>
Nope i have them all gathered on my laptop, you 'll sure find some
posted on ath5k-devel list. I'll send you a b-only trace from one of
my cards (a 5413) to check it out ;-)
We are working on a way to have all dumps uploaded somewhere...
> > Good work ;-)
>
> Heh I really don't know a phy from a sta so feel free to pick this
> apart...
>
You 've really done a great job, that's really helpful ;-)
>
> From 53d584dd188a131632e09353d1dd674f02a15b3c Mon Sep 17 00:00:00 2001
> From: Bob Copeland <[email protected]>
> Date: Sat, 9 Feb 2008 00:16:12 -0500
> Subject: [PATCH] ath5k: changes for 5424/2424 cards
>
> This adds some register writes and updates some values used by
> the Atheros 5424 chipset. This is just an experimental patch that
> should not be applied.
> ---
> drivers/net/wireless/ath5k/hw.c | 29 ++++++++++++++++++++++-------
> 1 files changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/ath5k/hw.c b/drivers/net/wireless/ath5k/hw.c
> index 3a4bf40..ba832b0 100644
> --- a/drivers/net/wireless/ath5k/hw.c
> +++ b/drivers/net/wireless/ath5k/hw.c
> @@ -358,8 +358,8 @@ static int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial)
> }
>
> /* ...reset chipset and PCI device */
> - if (ah->ah_single_chip == false && ath5k_hw_nic_reset(ah,
> - AR5K_RESET_CTL_CHIP | AR5K_RESET_CTL_PCI)) {
> + if (ah->ah_single_chip == false && ath5k_hw_nic_reset(ah,
> + AR5K_RESET_CTL_CHIP)) {
> ATH5K_ERR(ah->ah_sc, "failed to reset the MAC Chip + PCI\n");
> return -EIO;
> }
> @@ -887,9 +887,9 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
> */
> if (ah->ah_version != AR5K_AR5210) {
> AR5K_REG_WRITE_BITS(ah, AR5K_TXCFG, AR5K_TXCFG_SDMAMR,
> - AR5K_DMASIZE_512B | AR5K_TXCFG_DMASIZE);
> + AR5K_DMASIZE_128B | AR5K_TXCFG_DMASIZE);
> AR5K_REG_WRITE_BITS(ah, AR5K_RXCFG, AR5K_RXCFG_SDMAMW,
> - AR5K_DMASIZE_512B);
> + AR5K_DMASIZE_128B);
> }
>
Have you tried 256 ? Also have you tried only setting lower dma size for rx ?
> /*
> @@ -981,14 +981,22 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
> * Set the 32MHz reference clock on 5212 phy clock sleep register
> */
> if (ah->ah_version == AR5K_AR5212) {
> + int spending;
> +
> ath5k_hw_reg_write(ah, AR5K_PHY_SCR_32MHZ, AR5K_PHY_SCR);
> ath5k_hw_reg_write(ah, AR5K_PHY_SLMT_32MHZ, AR5K_PHY_SLMT);
> ath5k_hw_reg_write(ah, AR5K_PHY_SCAL_32MHZ, AR5K_PHY_SCAL);
> ath5k_hw_reg_write(ah, AR5K_PHY_SCLOCK_32MHZ, AR5K_PHY_SCLOCK);
> ath5k_hw_reg_write(ah, AR5K_PHY_SDELAY_32MHZ, AR5K_PHY_SDELAY);
> - ath5k_hw_reg_write(ah, ah->ah_radio == AR5K_RF5111 ?
> - AR5K_PHY_SPENDING_RF5111 : AR5K_PHY_SPENDING_RF5112,
> - AR5K_PHY_SPENDING);
> +
> + if (ah->ah_radio <= AR5K_RF5111)
> + spending = AR5K_PHY_SPENDING_RF5111;
> + else if (ah->ah_radio <= AR5K_RF5112)
> + spending = AR5K_PHY_SPENDING_RF5112;
> + else
> + spending = 0x12;
> +
> + ath5k_hw_reg_write(ah, spending, AR5K_PHY_SPENDING);
> }
>
> /*
> @@ -997,6 +1005,13 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
> AR5K_REG_DISABLE_BITS(ah, AR5K_BEACON, AR5K_BEACON_ENABLE |
> AR5K_BEACON_RESET_TSF);
>
> + if (ah->ah_mac_srev >= AR5K_SREV_VER_AR2424) {
> + ath5k_hw_reg_write(ah, 0x000100aa, 0x8118);
> + ath5k_hw_reg_write(ah, 0x00003210, 0x811c);
> + ath5k_hw_reg_write(ah, 0x00000052, 0x8108);
> + ath5k_hw_reg_write(ah, 0x001e1e1e, AR5K_TXPC);
Remove TXPC and see what happens...
> + ath5k_hw_reg_write(ah, 0x00000004, 0x8120);
> + }
> return 0;
> }
>
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
2008/2/10, Bob Copeland <[email protected]>:
> On Tue, Feb 05, 2008 at 11:13:35AM +0200, Nick Kossifidis wrote:
> > It's fine, that's cool it seems phy is ok (and hopefully is the same
> > with 5413 as i thought), it must be some mac settings related to pci-e
> > that result rx overrun, i've spotted some registers but i'll need to
> > spend some time on it and right now that's not possible ;-(
>
> So I played around with the code this weekend and have gotten it to
> work somewhat (I am posting this using the driver). I think it only
> works right after system power-up and something's not right because it's
> a little laggy.
>
> One weird thing -- in my traces, the g-mode tables seem to be the b-mode
> tables and vice-versa. I may have mixed up the trace files but I'm not
> sure how. Anyway it works without changes to the initvals.
>
> I'll post a patch later tonight.
>
Did you forced b mode via iwpriv while tracing (even if ap is b-only
card will use g settings) ? You should at least see different IFS etc
settings (check out initvals).
Good work ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
> Nope i have them all gathered on my laptop, you 'll sure find
> some posted on ath5k-devel list. I'll send you a b-only trace
> from one of my cards (a 5413) to check it out ;-)
>
> We are working on a way to have all dumps uploaded
> somewhere...
Why not put them into SVN ? Put them there in some original
format and in a text-format, so you can easily add comments with
a text editor into the dumps. That comments could then be used
as markers for automatically comparing the dumps of different
cards.