On Sun, Nov 2, 2008 at 10:41 AM, Bob Copeland <me@xxxxxxxxxxxxxxx> wrote: > On Sun, Nov 02, 2008 at 11:10:04AM +0200, Nick Kossifidis wrote: >> Can you test the attached patch ? >> >> It works for me (tested on a AR5413)... >> >> makis linux # iperf -s >> ------------------------------------------------------------ >> Server listening on TCP port 5001 >> TCP window size: 85.3 KByte (default) >> ------------------------------------------------------------ >> [ 4] local 192.168.1.104 port 5001 connected with 192.168.1.10 port 43192 >> [ ID] Interval Transfer Bandwidth >> [ 4] 0.0-10.6 sec 21.8 MBytes 17.2 Mbits/sec > > This patch works for me (I was seeing the same stalls). > > I somehow managed to trigger this after reloading the module: > > Nov 2 13:12:05 sludge kernel: ------------[ cut here ]------------ > Nov 2 13:12:05 sludge kernel: WARNING: at net/mac80211/main.c:236 > ieee80211_hw_config+0x82/0x8c [mac80211]() > Nov 2 13:12:05 sludge kernel: Modules linked in: ath5k af_packet > sha256_generic aes_i586 aes_generic cbc loop i915 drm binfmt_misc > acpi_cpufreq fan container nls_utf8 hfsplus dm_crypt dm_mod kvm_intel > kvm fuse sbp2 snd_hda_intel snd_pcm_oss snd_pcm snd_mixer_oss appletouch > hid_apple snd_seq_dummy snd_seq_oss arc4 ecb snd_seq_midi usbhid > snd_rawmidi snd_seq_midi_event mac80211 snd_seq ohci1394 snd_timer > snd_seq_device sr_mod ieee1394 sky2 cfg80211 sg cdrom rtc ehci_hcd > uhci_hcd thermal bitrev crc32 snd snd_page_alloc battery ac processor > button evdev unix [last unloaded: ath5k] > Nov 2 13:12:05 sludge kernel: Pid: 9748, comm: ath5k_pci Tainted: G > W 2.6.28-rc2-wl #19 > [...] > > But I think that was just a coincidence with the hardware getting > stuck in a bad state -- after reboot it was fine. If not, this at least > papers over the warning :) > > diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wireless/ath5k/base.c > index a298e8a..0308165 100644 > --- a/drivers/net/wireless/ath5k/base.c > +++ b/drivers/net/wireless/ath5k/base.c > @@ -2796,7 +2796,8 @@ ath5k_config(struct ieee80211_hw *hw, u32 changed) > sc->bintval = conf->beacon_int; > sc->power_level = conf->power_level; > > - return ath5k_chan_set(sc, conf->channel); > + ath5k_chan_set(sc, conf->channel); > + return 0; > } Not sure I agree with the WARN_ON() if the driver's mac80211 config() callback fails. In our case when we tune to a different channel we have to clear any DMA operations first and then we reset the chip. Reseting the chip can fail for whatever strange hw issue cases. The patch fixes the complaint but is the complaint sane? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
