2008/9/12 Romano Giannetti <[EMAIL PROTECTED]>: > > Hi all, > > I have an ath5k device in my laptop (a toshiba A305); I am running kernel > 2.6.27-rc6: > > [ 231.899321] ath5k_pci 0000:06:00.0: enabling device (0000 -> 0002) > [ 231.901148] ath5k_pci 0000:06:00.0: PCI INT A -> GSI 19 (level, low) -> > IRQ 19 > [ 231.903348] ath5k_pci 0000:06:00.0: setting latency timer to 64 > [ 231.905365] ath5k_pci 0000:06:00.0: registered as 'phy0' > [ 231.911840] ath5k phy0: Support for RF2425 is under development. > [ 231.950692] PM: Adding info for No Bus:phy0 > [ 231.952760] PM: Adding info for No Bus:wmaster0 > [ 231.954614] phy0: Selected rate control algorithm 'pid' > [ 232.002244] PM: Adding info for No Bus:wlan0 > [ 232.005649] ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70) > > It normally works ok with both my dynamic-wep work configuration and wep > home one, under NetworkManager. But sometime after resume it happens the > following: > > [ 3843.040068] evdev.c(EVIOCGBIT): Suspicious buffer size 511, limiting output > to 64 bytes. See http://userweb.kernel.org/~dtor/eviocgbit-bug.html > [ 3853.887794] ath5k phy0: noise floor calibration failed (2437MHz) > [ 3853.889748] ath5k phy0: can't reset hardware (-11) > [ 3853.891259] wlan0: Failed to config new SSID to the low-level driver > [ 3853.914507] ath5k phy0: noise floor calibration failed (2437MHz) > [ 3853.914521] ath5k phy0: ath5k_chan_set: unable to reset channel (2412 Mhz) > [ 3853.914525] wlan0: failed to restore operational channel after scan > [ 3854.250186] ath5k phy0: gain calibration timeout (2437MHz) > [ 3854.250198] ath5k phy0: can't reset hardware (-11) > [ 3854.250202] wlan0: Failed to config new BSSID to the low-level driver > > and so on and on. Nothing seems to resume the card, only a reboot; rmmod-ing > and reloading the ath5k modules has no effects: > > [ 3943.600078] PM: Removing info for No Bus:wlan0 > [ 3943.614012] PM: Removing info for No Bus:wmaster0 > [ 3943.621735] PM: Removing info for No Bus:phy0 > [ 3943.622496] ath5k_pci 0000:06:00.0: PCI INT A disabled > [ 3953.954495] ath5k_pci 0000:06:00.0: PCI INT A -> GSI 19 (level, low) -> > IRQ 19 > [ 3953.954542] ath5k_pci 0000:06:00.0: setting latency timer to 64 > [ 3953.954614] ath5k_pci 0000:06:00.0: registered as 'phy1' > [ 3953.959144] __ratelimit: 15 callbacks suppressed > [ 3953.959151] ath5k phy1: Support for RF2425 is under development. > [ 3953.998768] PM: Adding info for No Bus:phy1 > [ 3954.002174] PM: Adding info for No Bus:wmaster0 > [ 3954.003599] phy1: Selected rate control algorithm 'pid' > [ 3954.003904] PM: Adding info for No Bus:wlan0 > [ 3954.005386] ath5k phy1: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70) > [ 3954.417959] ath5k phy1: gain calibration timeout (2412MHz) > [ 3954.419628] ath5k phy1: unable to reset hardware: -11 > > is this a known problem? Can I help debugging something? Thanks! > > Romano >
You are probably in a noisy environment and noise floor calibration + gain offset calibration is taking more than usual so it times out. This is a situation well known and since we haven't implemented ANI yet (well i have an implementation ready but i need to test it and right now i'm out of time) we can't have an elegant solution yet. In the future we should keep track of phy errors and interact with hw to prevent them (that's what ANI is all about), we should also find a sane timeout interval for all chips (or introduce some algo that increases/decreases interval) so we can avoid these errors. I'm also thinking of an array that 'll hold calibration results to make that process faster (seems that HAL has an internal history buffer for noise floor calibration results, i guess we can expand this to hold I/Q calibration results, ani properties etc). Normaly noise floor calibration timeout shouldn't be a problem (and happens often), but gain offsets calibration must be done without problems because it 's needed for I/Q runtime correction (and that doesn't happen frequently, your report is the first report we get with failed gain offset calibration as long as i remember). What you can do is try tweaking the timeout intervals inside phy.c and see what's the best values for your environment, write down a min value (when you have most warnings) and a max value (when you have no warnings) and post them here. That would be very helpful ;-) -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
