[ath9k-devel] ath9k-devel Digest, Vol 20, Issue 28

[ath9k-devel] ath9k-devel Digest, Vol 20, Issue 28

[Sascha Rehberg]

The problem of unstable wireless as soon as you download big chunks of
data has been completely solved for me since I have changed from Ubuntu
Karmic Koala to Mandriva Power Pack - works perfectly fine...don't know
what they did but it works

On Mon, 2010-02-22 at 19:34 +0100, ath9k-devel-request at lists.ath9k.org
wrote:
> Send ath9k-devel mailing list submissions to
> 	ath9k-devel at lists.ath9k.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> or, via email, send a message with subject or body 'help' to
> 	ath9k-devel-request at lists.ath9k.org
> 
> You can reach the person managing the list at
> 	ath9k-devel-owner at lists.ath9k.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ath9k-devel digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Ath9k MIMO Performance versus Proprietary Drivers
>       (Felix Fietkau)
>    2. Re: AR5008 hanging computer (Luis R. Rodriguez)
>    3. Re: AR5008 hanging computer (Tomi Orava)
>    4. Re: AR5008 hanging computer (Luis R. Rodriguez)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 22 Feb 2010 15:29:06 +0100
> From: Felix Fietkau <nbd@openwrt.org>
> Subject: Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary
> 	Drivers
> To: Galen <galenz@zinkconsulting.com>
> Cc: ath9k-devel at lists.ath9k.org
> Message-ID: <4B8294B2.2020102@openwrt.org>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> On 2010-02-21 9:41 PM, Galen wrote:
> > Hello All,
> > 
> > I have been testing out ath9k in a variety of situations. I have
> > observed it appears to have poorer handling in MIMO-intensive
> > environments than the binary drivers under Mac OS X and Windows. I
> > have two computers with identical radios (3x3:2 AR5008 Mini PCI-e)
> > and as similar of antenna configurations as possible. One computer
> > runs Windows XP + latest Atheros binary drivers and Linux 2.6.32 +
> > latest compat-wireless. (I have also tested some older versions with
> > similar results.) The other computer runs Mac OS X 10.6.2 which
> > contains the latest Atheros binary drivers.
> > 
> > *** Further Testing *** I plan to create a triple-boot environment so
> > I can compare any OS combination on exactly the same hardware.
> > Absolute care will be used when rebooting as not to move anything. I
> > will run a standard series of network tests under Linux and OS X. (It
> > is a significantly larger headache to setup Cygwin to use the same
> > tools on Windows and I will only do so if OS X versus Linux testing
> > is inconclusive.) I will also have another system in monitor mode and
> > be recording the raw 802.11 frames for later review.
> > 
> > I do not expect a significant change in behavior in my testing
> > environment, but I do expect more accurate and precise data, which
> > can hopefully help me identify the cause of the performance
> > differences.
> > 
> > *** Discussion *** While I realize some of my examples are rather
> > extreme, they clearly demonstrate the huge disparity between ath9k
> > and proprietary drivers. I suspect that ath9k may have inferior MIMO
> > support code (MRC, beamforming, etc.) as compared to the proprietary
> > drivers. I believe that STBC is still not supported yet either.
> All of the currently available common Atheros hardware such as AR9280
> and earlier chip generations do not have MRC, Beamforming and similar
> advanced features.
> Except for STBC, ath9k seems to have pretty much the same hardware
> features as Atheros' other drivers. There may be some workarounds for
> various hw issues missing, I have not extensively reviewed that yet.
> 
> While I haven't done any tests with it yet, I believe STBC could
> potentially make a difference in strong multipath environments,
> especially when dealing with lower signal strength.
> The signal strength issues might also be related to ANI, you should
> probably disable that in ath9k to make sure that it's not screwing up
> your test results.
> 
> > Can anybody comment on this issue? Have you experienced it yourself?
> While I haven't done any extensive testing in that area, nor compared it
> against proprietary APs directly, your description of ath9k issues
> sounds somewhat similar to what I'm seeing with AR9280 hardware in my tests.
> 
> > Does anybody have ideas on how this might be improved? I have been
> > considering ath9k for an embedded installation, but these multi-path
> > performance differences are pretty disturbing. Atheros has a
> > proprietary driver available with source for a very hefty license
> > fee, but I'd rather put energies into ath9k - the kind of licensing
> > fees they are working with can pay for a lot of developer time.
> I'm currently working on a new rate control algorithm for 11n, and I
> also intend to add STBC support to ath9k soon (it's only a few flags
> missing, nothing major). Maybe I should do STBC first, as it should be
> fairly straightforward.
> 
> - Felix
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 22 Feb 2010 10:02:10 -0800
> From: "Luis R. Rodriguez" <mcgrof@gmail.com>
> Subject: Re: [ath9k-devel] AR5008 hanging computer
> To: Tomi Orava <Tomi.Orava@ncircle.nullnet.fi>
> Cc: ath9k-devel at lists.ath9k.org
> Message-ID:
> 	<43e72e891002221002v850722ciffef391f09f74b0d@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> On Sun, Feb 21, 2010 at 12:31 AM, Tomi Orava
> <Tomi.Orava@ncircle.nullnet.fi> wrote:
> > On 02/18/2010 11:58 PM, Mark Sutton wrote:
> >> On Thu, Feb 18, 2010 at 12:31:26PM -0800, Mark Sutton wrote:
> >>> Hi,
> >>> ? ? ?I have this problem as well.
> >>> Hardware is:
> >>>
> >>> Atheros Communications Inc. AR5008
> >>> Atheros AR5416 MAC/BB Rev:2 AR5133 RF Rev:81
> >>>
> >>> Kernel:Linux 2.6.32.7 #2 PREEMPT Thu Feb 4 14:19:02 PST 2010 i686 GNU/Linux
> >>>
> >> Here is a call trace from last night when it hung during reboot.
> >
> > Hmm, it looks like my problem might be related to yours as well.
> >
> > My lspci entry is:
> >
> > 03:00.0 Network controller: Atheros Communications Inc. AR5008
> > Wireless Network Adapter (rev 01)
> > ? ? ? ?Subsystem: Device 07d1:3a09
> > ? ? ? ?Flags: bus master, 66MHz, medium devsel, latency 168, IRQ 11
> > ? ? ? ?Memory at 4c000000 (32-bit, non-prefetchable) [size=64K]
> > ? ? ? ?Capabilities: [40] #80 [0000]
> > ? ? ? ?Kernel driver in use: ath9k
> > ? ? ? ?Kernel modules: ath9k
> >
> > and dmesg reports the hardware as:
> >
> > phy0: Atheros AR5416 MAC/BB Rev:2 AR2133 RF Rev:81 mem=0xf8300000, irq=11
> >
> > My problem is that the laptop will eventually hang sooner or later
> > to a complete halt if there is some traffic going via the wlan
> > pcmcia card. The hang can usually be recovered by ejecting the card
> > from its slot.
> >
> > One of the logs contains the following information:
> > (kernel version isUbuntu 2.6.32-12.17-generic)
> >
> > Feb 14 14:39:52 foobar kernel: [20442.972015] BUG: soft lockup - CPU#0 stuck for 61s! [phy1:2531]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] Modules linked in: ip6table_filter ip6_tables act_police cls_flow cls_fw cls_u32 sch_htb sch_hfsc sch_ingre
> > ss sch_sfq xt_time xt_connlimit xt_realm iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_REDIRECT ipt_NETMAP ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah
> > ipt_addrtype nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_ama
> > nda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrac
> > k_netbios_ns nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG nfnetlink_log xt_multiport x
> > t_MARK xt_mark xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_CONNMARK xt_connmark xt_CLASSIFY ipt_LO
> > G iptable_mangle nfnetlink arc4 ath9k mac80211 ath cfg80211 led_class binfmt_misc rfcomm ppdev sco bnep
> > Feb 14 14:39:52 foobar kernel: l2cap lirc_mceusb lirc_dev ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_RE
> > JECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp deflate zlib_deflate ctr twofish twofish_common camellia serpent blowfish cast5 des_generic ae
> > s_i586 aes_generic xcbc rmd160 sha256_generic sha1_generic crypto_null af_key rpcsec_gss_krb5 nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc joydev pc
> > mcia snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq
> > snd_timer snd_seq_device snd yenta_socket rsrc_nonstatic pcmcia_core soundcore dell_wmi psmouse serio_raw btusb bluetooth dcdbas snd_page_alloc irda crc_c
> > citt shpchp lp parport raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor async_memcpy async_tx raid1 raid0 multipath linear dm_raid45 xor usbhi
> > d ohci1394 fbcon tileblit font bitblit softcursor intel_agp ieee1394 vga16fb vgastate tg3 video output agpg
> > Feb 14 14:39:52 foobar kernel: art
> > Feb 14 14:39:52 foobar kernel: [20442.972015]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] Pid: 2531, comm: phy1 Not tainted (2.6.32-12-generic #17-Ubuntu) Portable PC
> > Feb 14 14:39:52 foobar kernel: [20442.972015] EIP: 0060:[<c0351b62>] EFLAGS: 00000292 CPU: 0
> > Feb 14 14:39:52 foobar kernel: [20442.972015] EIP is at ioread32+0x32/0x40
> > Feb 14 14:39:52 foobar kernel: [20442.972015] EAX: 00000000 EBX: e55c8000 ECX: f86600ac EDX: f86600b8
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ESI: f4041071 EDI: 40c00000 EBP: e2239c60 ESP: e2239c60
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> > Feb 14 14:39:52 foobar kernel: [20442.972015] CR0: 8005003b CR2: b75a8000 CR3: 369ba000 CR4: 000006d0
> > Feb 14 14:39:52 foobar kernel: [20442.972015] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> > Feb 14 14:39:52 foobar kernel: [20442.972015] DR6: ffff0ff0 DR7: 00000400
> > Feb 14 14:39:52 foobar kernel: [20442.972015] Call Trace:
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<f88b83ab>] ath9k_ioread32+0x2b/0x80 [ath9k]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<f88b9ee4>] ath9k_hw_set_interrupts+0x1d4/0x360 [ath9k]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<f88d2d1d>] ath_isr+0x13d/0x170 [ath9k]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c019e204>] handle_IRQ_event+0x54/0x150
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0106e27>] ? mask_and_ack_8259A+0x57/0xf0
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c01a0734>] handle_level_irq+0x74/0x100
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0105a9d>] handle_irq+0x1d/0x30
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c05a9e4c>] do_IRQ+0x4c/0xc0
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<f88b83ab>] ? ath9k_ioread32+0x2b/0x80 [ath9k]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0103a90>] common_interrupt+0x30/0x40
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<f80700e0>] ? xor_p5_mmx_5+0x20/0x1a0 [xor]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c01517fd>] ? __do_softirq+0x4d/0x1b0
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c012a458>] ? default_spin_lock_flags+0x8/0x10
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c05a598f>] ? _spin_lock_irqsave+0x2f/0x50
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0106d37>] ? enable_8259A_irq+0x47/0x70
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c01a0772>] ? handle_level_irq+0xb2/0x100
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c01519a5>] do_softirq+0x45/0x50
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0151af5>] irq_exit+0x65/0x70
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c05a9e55>] do_IRQ+0x55/0xc0
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0103a90>] common_interrupt+0x30/0x40
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0351b62>] ? ioread32+0x32/0x40
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<f88b83ab>] ath9k_ioread32+0x2b/0x80 [ath9k]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<f88b9f7a>] ath9k_hw_set_interrupts+0x26a/0x360 [ath9k]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<f88d176e>] ath_set_channel+0x17e/0x180 [ath9k]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<f88d2b87>] ath9k_config+0x287/0x2e0 [ath9k]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<f875bcc2>] ieee80211_hw_config+0x72/0xb0 [mac80211]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<f875f635>] ieee80211_scan_work+0x175/0x320 [mac80211]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0161eee>] run_workqueue+0x8e/0x150
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<f875f4c0>] ? ieee80211_scan_work+0x0/0x320 [mac80211]
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0162034>] worker_thread+0x84/0xe0
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0165f90>] ? autoremove_wake_function+0x0/0x50
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0161fb0>] ? worker_thread+0x0/0xe0
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0165d04>] kthread+0x74/0x80
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c0165c90>] ? kthread+0x0/0x80
> > Feb 14 14:39:52 foobar kernel: [20442.972015] ?[<c01040e7>] kernel_thread_helper+0x7/0x10
> > Feb 14 14:39:52 foobar kernel: [20446.657338] pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0
> >
> > -- Here the pcmcia wlan card was ejected and the system started responding again.
> >
> > Feb 14 14:39:52 foobar kernel: [20446.693722] wlan0: deauthenticating from 00:0d:0b:b2:8c:dd by local choice (reason=3)
> > Feb 14 14:39:52 foobar kernel: [20446.701944] ath9k: Failed to stop TX DMA in 100 msec after killing last frame
> > Feb 14 14:39:52 foobar kernel: [20446.710055] ath9k: Failed to stop TX DMA in 100 msec after killing last frame
> > Feb 14 14:39:52 foobar kernel: [20446.718167] ath9k: Failed to stop TX DMA in 100 msec after killing last frame
> > Feb 14 14:39:52 foobar kernel: [20446.726279] ath9k: Failed to stop TX DMA in 100 msec after killing last frame
> > Feb 14 14:39:52 foobar kernel: [20446.734390] ath9k: Failed to stop TX DMA in 100 msec after killing last frame
> > Feb 14 14:39:52 foobar kernel: [20446.742502] ath9k: Failed to stop TX DMA in 100 msec after killing last frame
> > Feb 14 14:39:52 foobar kernel: [20446.742506] ath9k: Unable to stop TxDMA. Reset HAL!
> > Feb 14 14:39:52 foobar kernel: [20446.850877] ath9k: timeout (100000 us) on reg 0x7000: 0xffffffff & 0x00000003 != 0x00000000
> > Feb 14 14:39:52 foobar kernel: [20446.850881] ath9k: Chip reset failed
> > Feb 14 14:39:52 foobar kernel: [20446.850883] ath9k: Unable to reset hardware; reset status -22
> > Feb 14 14:39:52 foobar kernel: [20446.861656] ath9k: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff
> > Feb 14 14:39:52 foobar kernel: [20446.969249] ath9k: timeout (100000 us) on reg 0x7000: 0xffffffff & 0x00000003 != 0x00000000
> > Feb 14 14:39:52 foobar kernel: [20447.076842] ath9k: timeout (100000 us) on reg 0x7000: 0xffffffff & 0x00000003 != 0x00000000
> > Feb 14 14:39:52 foobar kernel: [20447.399108] ath9k 0000:03:00.0: PCI INT A disabled
> > Feb 14 14:39:54 foobar kernel: [20448.488074] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
> > Feb 14 14:39:54 foobar kernel: [20448.488156] pci 0000:03:00.0: reg 10 32bit mmio: [0x000000-0x00ffff]
> > Feb 14 14:39:54 foobar kernel: [20448.488495] ath9k 0000:03:00.0: enabling device (0000 -> 0002)
> > Feb 14 14:39:54 foobar kernel: [20448.488518] ath9k 0000:03:00.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11
> > Feb 14 14:39:54 foobar kernel: [20448.939749] ath: EEPROM regdomain: 0x30
> > Feb 14 14:39:54 foobar kernel: [20448.939754] ath: EEPROM indicates we should expect a direct regpair map
> > Feb 14 14:39:54 foobar kernel: [20448.939757] ath: Country alpha2 being used: AM
> > Feb 14 14:39:54 foobar kernel: [20448.939759] ath: Regpair used: 0x30
> > Feb 14 14:39:54 foobar kernel: [20448.945107] phy2: Selected rate control algorithm 'ath9k_rate_control'
> > Feb 14 14:39:54 foobar kernel: [20448.946630] cfg80211: Calling CRDA for country: AM
> > Feb 14 14:39:54 foobar kernel: [20448.947513] Registered led device: ath9k-phy2::radio
> > Feb 14 14:39:54 foobar kernel: [20448.948455] Registered led device: ath9k-phy2::assoc
> > Feb 14 14:39:54 foobar kernel: [20448.948959] Registered led device: ath9k-phy2::tx
> > Feb 14 14:39:54 foobar kernel: [20448.949443] Registered led device: ath9k-phy2::rx
> > Feb 14 14:39:54 foobar kernel: [20448.949458] phy2: Atheros AR5416 MAC/BB Rev:2 AR2133 RF Rev:81: mem=0xf8520000, irq=11
> > Feb 14 14:39:54 foobar kernel: [20449.105089] cfg80211: Current regulatory domain intersected:
> > Feb 14 14:39:54 foobar kernel: [20449.105100] ?(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> > Feb 14 14:39:54 foobar kernel: [20449.105110] ?(2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> > Feb 14 14:39:54 foobar kernel: [20449.105119] ?(5170000 KHz - 5250000 KHz @ 20000 KHz), (N/A, 1800 mBm)
> > Feb 14 14:39:54 foobar kernel: [20449.105128] ?(5250000 KHz - 5330000 KHz @ 20000 KHz), (N/A, 1800 mBm)
> > Feb 14 14:39:54 foobar kernel: [20449.162437] ADDRCONF(NETDEV_UP): wlan0: link is not ready
> > Feb 14 14:40:01 foobar kernel: [20455.898813] wlan0: deauthenticating from 00:0d:0b:b2:8c:dd by local choice (reason=3)
> > Feb 14 14:40:01 foobar kernel: [20455.904452] wlan0: direct probe to AP 00:0d:0b:b2:8c:dd (try 1)
> > Feb 14 14:40:01 foobar kernel: [20455.908238] wlan0: direct probe responded
> > Feb 14 14:40:01 foobar kernel: [20455.908242] wlan0: authenticate with AP 00:0d:0b:b2:8c:dd (try 1)
> > Feb 14 14:40:01 foobar kernel: [20455.910440] wlan0: authenticated
> >
> > I'll have to find out if there really was some original karmic kernels (without the compat-wireless backport updates)
> > that actually doesn't have this hang problem.
> 
> Karmic uses 2.6.31 which has already reached the end of its
> development. You will no longer see stable kernel releases based on
> 2.6.31.y kernels so best is to upgrade. ath9k had a large number of
> patches which did not get merged into 2.6.31 [1] which should have,
> which is why we worked hard for 2.6.32 to ensure all regressions/fixes
> are propagated to stable.
> 
> Karmic ships lbm though and that uses the 802.11 bits from 2.6.32
> which should be good.
> 
> [1] http://bombadil.infradead.org/~mcgrof/patches/ath9k/fixes-not-in-2.6.31-for-ath9k.txt
> 
>   Luis
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 22 Feb 2010 20:24:57 +0200
> From: Tomi Orava <tomi.orava@ncircle.nullnet.fi>
> Subject: Re: [ath9k-devel] AR5008 hanging computer
> To: "Luis R. Rodriguez" <mcgrof@gmail.com>
> Cc: ath9k-devel at lists.ath9k.org
> Message-ID: <20100222202457.38761sxhi60szth5@ncircle.nullnet.fi>
> Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
> 
> Quoting "Luis R. Rodriguez" <mcgrof@gmail.com>:
> 
> > On Sun, Feb 21, 2010 at 12:31 AM, Tomi Orava
> > <Tomi.Orava@ncircle.nullnet.fi> wrote:
> >> On 02/18/2010 11:58 PM, Mark Sutton wrote:
> >>> On Thu, Feb 18, 2010 at 12:31:26PM -0800, Mark Sutton wrote:
> >>>> Hi,
> >>>> ? ? ?I have this problem as well.
> >>>> Hardware is:
> >>>>
> >>>> Atheros Communications Inc. AR5008
> >>>> Atheros AR5416 MAC/BB Rev:2 AR5133 RF Rev:81
> >>>>
> >>>> Kernel:Linux 2.6.32.7 #2 PREEMPT Thu Feb 4 14:19:02 PST 2010 i686  
> >>>> GNU/Linux
> 
> <snip>
> 
> > Karmic uses 2.6.31 which has already reached the end of its
> > development. You will no longer see stable kernel releases based on
> > 2.6.31.y kernels so best is to upgrade. ath9k had a large number of
> > patches which did not get merged into 2.6.31 [1] which should have,
> > which is why we worked hard for 2.6.32 to ensure all regressions/fixes
> > are propagated to stable.
> >
> > Karmic ships lbm though and that uses the 802.11 bits from 2.6.32
> > which should be good.
> >
> > [1]  
> > http://bombadil.infradead.org/~mcgrof/patches/ath9k/fixes-not-in-2.6.31-for-ath9k.txt
> 
> Unfortunately, I completely forgot to mention the very important fact that
> in my understanding the "standard" karmic kernels ie. 2.6.31.x worked
> quite ok compared to the compat-wireless versions included in  
> linux-backports-karmic etc etc. In other words, my problem tends to be  
> that the latest
> ath9k versions are having some problems, while the older 2.6.31 seem to
> be working without hangs in my case (not counting connection drops  
> every once in a while). Sorry, for turning this upside down.
> 
> Although, I've been way too busy with other important matters, I'll  
> try to find the last "properly" working kernel by using the GIT kernel  
> versions, so that I can be sure about the used versions.  
> Unfortunately, this laptop is quite slow and the hang doesn't happen  
> immediately (might take 1-2 days, but still it will always happen with  
> newer versions of the ath9k drivers). Anyway, it's very good to know  
> if these problems are more common among cards based on these chips or  
> is this just a rare case.
> 
> This particular card was sold as D-Link DWA-645.
> 
> I'll report back after I've done some more testing in order to get  
> more facts about different ath9k driver versions.
> 
> Regards,
> Tomi Orava
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 22 Feb 2010 10:34:18 -0800
> From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
> Subject: Re: [ath9k-devel] AR5008 hanging computer
> To: Tomi Orava <tomi.orava@ncircle.nullnet.fi>
> Cc: "ath9k-devel at lists.ath9k.org" <ath9k-devel@lists.ath9k.org>
> Message-ID: <20100222183418.GH2528@tux>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Mon, Feb 22, 2010 at 10:24:57AM -0800, Tomi Orava wrote:
> > Quoting "Luis R. Rodriguez" <mcgrof@gmail.com>:
> > 
> > > On Sun, Feb 21, 2010 at 12:31 AM, Tomi Orava
> > > <Tomi.Orava@ncircle.nullnet.fi> wrote:
> > >> On 02/18/2010 11:58 PM, Mark Sutton wrote:
> > >>> On Thu, Feb 18, 2010 at 12:31:26PM -0800, Mark Sutton wrote:
> > >>>> Hi,
> > >>>> ? ? ?I have this problem as well.
> > >>>> Hardware is:
> > >>>>
> > >>>> Atheros Communications Inc. AR5008
> > >>>> Atheros AR5416 MAC/BB Rev:2 AR5133 RF Rev:81
> > >>>>
> > >>>> Kernel:Linux 2.6.32.7 #2 PREEMPT Thu Feb 4 14:19:02 PST 2010 i686  
> > >>>> GNU/Linux
> > 
> > <snip>
> > 
> > > Karmic uses 2.6.31 which has already reached the end of its
> > > development. You will no longer see stable kernel releases based on
> > > 2.6.31.y kernels so best is to upgrade. ath9k had a large number of
> > > patches which did not get merged into 2.6.31 [1] which should have,
> > > which is why we worked hard for 2.6.32 to ensure all regressions/fixes
> > > are propagated to stable.
> > >
> > > Karmic ships lbm though and that uses the 802.11 bits from 2.6.32
> > > which should be good.
> > >
> > > [1]  
> > > http://bombadil.infradead.org/~mcgrof/patches/ath9k/fixes-not-in-2.6.31-for-ath9k.txt
> > 
> > Unfortunately, I completely forgot to mention the very important fact that
> > in my understanding the "standard" karmic kernels ie. 2.6.31.x worked
> > quite ok compared to the compat-wireless versions included in  
> > linux-backports-karmic etc etc. In other words, my problem tends to be  
> > that the latest
> > ath9k versions are having some problems, while the older 2.6.31 seem to
> > be working without hangs in my case (not counting connection drops  
> > every once in a while). Sorry, for turning this upside down.
> > 
> > Although, I've been way too busy with other important matters, I'll  
> > try to find the last "properly" working kernel by using the GIT kernel  
> > versions, so that I can be sure about the used versions.  
> > Unfortunately, this laptop is quite slow and the hang doesn't happen  
> > immediately (might take 1-2 days, but still it will always happen with  
> > newer versions of the ath9k drivers). Anyway, it's very good to know  
> > if these problems are more common among cards based on these chips or  
> > is this just a rare case.
> > 
> > This particular card was sold as D-Link DWA-645.
> > 
> > I'll report back after I've done some more testing in order to get  
> > more facts about different ath9k driver versions.
> 
> You'll want to read:
> 
> http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
> http://wireless.kernel.org/en/users/Documentation/Fix_Propagation
> 
> That should get you to test and report against the right thing.
> 
>  Luis
> 
> 
> ------------------------------
> 
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 
> 
> End of ath9k-devel Digest, Vol 20, Issue 28
> *******************************************