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-requ...@lists.ath9k.org wrote: > Send ath9k-devel mailing list submissions to > ath9k-devel@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-requ...@lists.ath9k.org > > You can reach the person managing the list at > ath9k-devel-ow...@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 <n...@openwrt.org> > Subject: Re: [ath9k-devel] Ath9k MIMO Performance versus Proprietary > Drivers > To: Galen <gal...@zinkconsulting.com> > Cc: ath9k-devel@lists.ath9k.org > Message-ID: <4b8294b2.2020...@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" <mcg...@gmail.com> > Subject: Re: [ath9k-devel] AR5008 hanging computer > To: Tomi Orava <tomi.or...@ncircle.nullnet.fi> > Cc: ath9k-devel@lists.ath9k.org > Message-ID: > <43e72e891002221002v850722ciffef391f09f74...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Sun, Feb 21, 2010 at 12:31 AM, Tomi Orava > <tomi.or...@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.or...@ncircle.nullnet.fi> > Subject: Re: [ath9k-devel] AR5008 hanging computer > To: "Luis R. Rodriguez" <mcg...@gmail.com> > Cc: ath9k-devel@lists.ath9k.org > Message-ID: <20100222202457.38761sxhi60sz...@ncircle.nullnet.fi> > Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" > > Quoting "Luis R. Rodriguez" <mcg...@gmail.com>: > > > On Sun, Feb 21, 2010 at 12:31 AM, Tomi Orava > > <tomi.or...@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" <lrodrig...@atheros.com> > Subject: Re: [ath9k-devel] AR5008 hanging computer > To: Tomi Orava <tomi.or...@ncircle.nullnet.fi> > Cc: "ath9k-devel@lists.ath9k.org" <ath9k-devel@lists.ath9k.org> > Message-ID: <20100222183418.gh2...@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" <mcg...@gmail.com>: > > > > > On Sun, Feb 21, 2010 at 12:31 AM, Tomi Orava > > > <tomi.or...@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@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > > End of ath9k-devel Digest, Vol 20, Issue 28 > ******************************************* _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
