* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 @ 2012-02-29 21:35 ` Kim Lidström 0 siblings, 0 replies; 37+ messages in thread From: Kim Lidström @ 2012-02-29 21:35 UTC (permalink / raw) To: ath9k-devel Hello! A while ago I had a situation where my AR9485 would lock up the kernel so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. Sorry I forgot his last name) were very patient in helping me and trying to debug it through patches, etc. Nothing worked. Eventually, though, I noticed that when I removed the atl1c module my wlan started working. "Awesome!" I thought... Until I noticed this other problem. Once in a while, seemingly at random, the wlan dies with the error messages in the title. And I can't possibly restore it without restarting the computer. With this message I have attached a log with the error messages. This has been a problem since.. Uhm.. Kernel 3.2.something and I'm currently running 3.2.8. For some reason it happened at least 3-4 times shortly after each other today - so I thought I might ask on here what's happening. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dmesg-ath.txt Url: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20120229/47b33c98/attachment-0001.txt ^ permalink raw reply [flat|nested] 37+ messages in thread
* "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 @ 2012-02-29 21:35 ` Kim Lidström 0 siblings, 0 replies; 37+ messages in thread From: Kim Lidström @ 2012-02-29 21:35 UTC (permalink / raw) To: linux-wireless, ath9k-devel [-- Attachment #1: Type: text/plain, Size: 862 bytes --] Hello! A while ago I had a situation where my AR9485 would lock up the kernel so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. Sorry I forgot his last name) were very patient in helping me and trying to debug it through patches, etc. Nothing worked. Eventually, though, I noticed that when I removed the atl1c module my wlan started working. "Awesome!" I thought... Until I noticed this other problem. Once in a while, seemingly at random, the wlan dies with the error messages in the title. And I can't possibly restore it without restarting the computer. With this message I have attached a log with the error messages. This has been a problem since.. Uhm.. Kernel 3.2.something and I'm currently running 3.2.8. For some reason it happened at least 3-4 times shortly after each other today - so I thought I might ask on here what's happening. [-- Attachment #2: dmesg-ath.txt --] [-- Type: text/plain, Size: 15821 bytes --] [ 13.010134] ath9k 0000:07:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 [ 13.010160] ath9k 0000:07:00.0: setting latency timer to 64 [ 13.018216] ath: EEPROM regdomain: 0x65 [ 13.018222] ath: EEPROM indicates we should expect a direct regpair map [ 13.018229] ath: Country alpha2 being used: 00 [ 13.018233] ath: Regpair used: 0x65 [ 13.045598] ieee80211 phy0: Selected rate control algorithm 'ath9k_rate_control' [ 13.046709] Registered led device: ath9k-phy0 [ 125.432441] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006100 [ 125.438365] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2778.307941] ath: Failed to stop TX DMA, queues=0x001! [ 2778.316757] ath: Failed to stop TX DMA, queues=0x001! [ 2778.328959] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026800 [ 2778.329001] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2778.956071] ath: Failed to stop TX DMA, queues=0x001! [ 2778.964851] ath: Failed to stop TX DMA, queues=0x001! [ 2779.065389] ath: Failed to stop TX DMA, queues=0x001! [ 2779.077624] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2779.077666] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2779.148709] ath: Failed to stop TX DMA, queues=0x001! [ 2779.160946] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2779.160987] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2779.232040] ath: Failed to stop TX DMA, queues=0x001! [ 2779.244279] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026e00 [ 2779.244320] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2779.315390] ath: Failed to stop TX DMA, queues=0x001! [ 2779.327625] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026e00 [ 2779.327667] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2779.398714] ath: Failed to stop TX DMA, queues=0x001! [ 2779.410946] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024800 [ 2779.410988] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2779.482047] ath: Failed to stop TX DMA, queues=0x001! [ 2779.494280] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2779.494321] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2779.565391] ath: Failed to stop TX DMA, queues=0x001! [ 2779.635381] ath: Failed to stop TX DMA, queues=0x001! [ 2779.647613] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2779.647655] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2779.718719] ath: Failed to stop TX DMA, queues=0x001! [ 2779.730960] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2779.731001] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2779.802055] ath: Failed to stop TX DMA, queues=0x001! [ 2779.814292] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2779.814333] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2779.885382] ath: Failed to stop TX DMA, queues=0x001! [ 2779.897612] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2779.897653] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2780.035637] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2780.035683] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2786.218730] ath: Failed to stop TX DMA, queues=0x001! [ 2786.230968] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2786.231010] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2786.302047] ath: Failed to stop TX DMA, queues=0x001! [ 2786.314279] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2786.314320] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2786.385371] ath: Failed to stop TX DMA, queues=0x001! [ 2786.397611] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026e00 [ 2786.397653] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2786.468725] ath: Failed to stop TX DMA, queues=0x001! [ 2786.480970] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2786.481012] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2786.552061] ath: Failed to stop TX DMA, queues=0x001! [ 2786.564291] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026800 [ 2786.564332] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2786.635371] ath: Failed to stop TX DMA, queues=0x001! [ 2786.647612] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2786.647653] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2786.718722] ath: Failed to stop TX DMA, queues=0x001! [ 2786.730957] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2786.730999] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2786.802041] ath: Failed to stop TX DMA, queues=0x001! [ 2786.814278] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2786.814318] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2786.885379] ath: Failed to stop TX DMA, queues=0x001! [ 2786.897612] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2786.897653] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2786.968722] ath: Failed to stop TX DMA, queues=0x001! [ 2786.980957] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026700 [ 2786.980999] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2787.052048] ath: Failed to stop TX DMA, queues=0x001! [ 2787.064278] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2787.064319] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2787.202303] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024800 [ 2787.202349] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2791.115624] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026800 [ 2791.115670] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2791.188715] ath: Failed to stop TX DMA, queues=0x001! [ 2791.200969] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2791.201011] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2791.272056] ath: Failed to stop TX DMA, queues=0x001! [ 2791.284290] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026700 [ 2791.284333] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2791.355372] ath: Failed to stop TX DMA, queues=0x001! [ 2791.367612] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026800 [ 2791.367653] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2791.438706] ath: Failed to stop TX DMA, queues=0x001! [ 2791.450945] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026800 [ 2791.450986] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2791.522052] ath: Failed to stop TX DMA, queues=0x001! [ 2791.534291] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2791.534332] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2791.605374] ath: Failed to stop TX DMA, queues=0x001! [ 2791.617612] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2791.617654] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2791.688707] ath: Failed to stop TX DMA, queues=0x001! [ 2791.700945] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2791.700987] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2791.772067] ath: Failed to stop TX DMA, queues=0x001! [ 2791.842039] ath: Failed to stop TX DMA, queues=0x001! [ 2791.854278] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024800 [ 2791.854320] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2791.925381] ath: Failed to stop TX DMA, queues=0x001! [ 2791.937611] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2791.937653] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2792.008721] ath: Failed to stop TX DMA, queues=0x001! [ 2792.020957] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026800 [ 2792.020998] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2792.282302] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024800 [ 2792.282349] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2796.172143] ath: Failed to stop TX DMA, queues=0x001! [ 2796.184375] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024400 [ 2796.184416] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2796.255389] ath: Failed to stop TX DMA, queues=0x001! [ 2796.267687] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026800 [ 2796.267732] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2796.338734] ath: Failed to stop TX DMA, queues=0x001! [ 2796.350970] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026e00 [ 2796.351011] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2796.422048] ath: Failed to stop TX DMA, queues=0x001! [ 2796.434277] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024e00 [ 2796.434318] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2796.505388] ath: Failed to stop TX DMA, queues=0x001! [ 2796.517622] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024800 [ 2796.517664] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2796.588726] ath: Failed to stop TX DMA, queues=0x001! [ 2796.600956] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2796.600998] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2796.672046] ath: Failed to stop TX DMA, queues=0x001! [ 2796.742046] ath: Failed to stop TX DMA, queues=0x001! [ 2796.754277] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2796.754318] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2796.825378] ath: Failed to stop TX DMA, queues=0x001! [ 2796.837611] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2796.837653] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2796.908705] ath: Failed to stop TX DMA, queues=0x001! [ 2796.920944] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026700 [ 2796.920985] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2796.992068] ath: Failed to stop TX DMA, queues=0x001! [ 2797.004302] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026400 [ 2797.004343] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2797.265647] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024800 [ 2797.265694] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2801.172046] ath: Failed to stop TX DMA, queues=0x001! [ 2801.184278] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2801.184320] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2801.255390] ath: Failed to stop TX DMA, queues=0x001! [ 2801.267622] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2801.267663] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2801.338730] ath: Failed to stop TX DMA, queues=0x001! [ 2801.350968] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026800 [ 2801.351009] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2801.422037] ath: Failed to stop TX DMA, queues=0x001! [ 2801.492055] ath: Failed to stop TX DMA, queues=0x001! [ 2801.504289] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026800 [ 2801.504331] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2801.575373] ath: Failed to stop TX DMA, queues=0x001! [ 2801.587611] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024700 [ 2801.587652] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2801.658713] ath: Failed to stop TX DMA, queues=0x001! [ 2801.670945] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2801.670985] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2801.742053] ath: Failed to stop TX DMA, queues=0x001! [ 2801.754290] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00026700 [ 2801.754332] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2801.825379] ath: Failed to stop TX DMA, queues=0x001! [ 2801.837611] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2801.837652] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2801.908711] ath: Failed to stop TX DMA, queues=0x001! [ 2801.978716] ath: Failed to stop TX DMA, queues=0x001! [ 2801.990956] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2801.990997] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2802.128955] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00006400 [ 2802.129003] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up [ 2802.268957] ath: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x00024800 [ 2802.269004] ath: Could not stop RX, we could be confusing the DMA engine when we start RX up ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-02-29 21:35 ` Kim Lidström @ 2012-02-29 21:50 ` Adrian Chadd -1 siblings, 0 replies; 37+ messages in thread From: Adrian Chadd @ 2012-02-29 21:50 UTC (permalink / raw) To: ath9k-devel Hi! Which kernel didn't this happen in? adrian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 @ 2012-02-29 21:50 ` Adrian Chadd 0 siblings, 0 replies; 37+ messages in thread From: Adrian Chadd @ 2012-02-29 21:50 UTC (permalink / raw) To: Kim Lidström; +Cc: linux-wireless, ath9k-devel Hi! Which kernel didn't this happen in? adrian ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-02-29 21:35 ` Kim Lidström @ 2012-02-29 23:52 ` Adrian Chadd -1 siblings, 0 replies; 37+ messages in thread From: Adrian Chadd @ 2012-02-29 23:52 UTC (permalink / raw) To: ath9k-devel Hi, I don't recall _how_ to do this, but would you mind verifying whether you're actually somehow using power saving modes or not? Thanks, Adrian ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 @ 2012-02-29 23:52 ` Adrian Chadd 0 siblings, 0 replies; 37+ messages in thread From: Adrian Chadd @ 2012-02-29 23:52 UTC (permalink / raw) To: Kim Lidström; +Cc: linux-wireless, ath9k-devel Hi, I don't recall _how_ to do this, but would you mind verifying whether you're actually somehow using power saving modes or not? Thanks, Adrian ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-02-29 21:35 ` Kim Lidström @ 2012-03-01 5:09 ` Mohammed Shafi -1 siblings, 0 replies; 37+ messages in thread From: Mohammed Shafi @ 2012-03-01 5:09 UTC (permalink / raw) To: ath9k-devel > With this message I have attached a log with the error messages. > This has been a problem since.. Uhm.. Kernel 3.2.something and I'm > currently running 3.2.8. > For some reason it happened at least 3-4 times shortly after each other > today - so I thought I might ask on here what's happening. disabling power save would be a nice idea, to see if this issue disappears. i got the same issue after a long stress test with some other card, sujith gave me the idea to see if disabling PS helps sudo iwconfig wlanX power off sudo iw dev wlanX set power_save off also please ensure that you run with your power adapter :) i noticed PS gets enabled via wext when we plug out the power adapter -- thanks, shafi ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 @ 2012-03-01 5:09 ` Mohammed Shafi 0 siblings, 0 replies; 37+ messages in thread From: Mohammed Shafi @ 2012-03-01 5:09 UTC (permalink / raw) To: Kim Lidström; +Cc: linux-wireless, ath9k-devel, Adrian Chadd > With this message I have attached a log with the error messages. > This has been a problem since.. Uhm.. Kernel 3.2.something and I'm > currently running 3.2.8. > For some reason it happened at least 3-4 times shortly after each other > today - so I thought I might ask on here what's happening. disabling power save would be a nice idea, to see if this issue disappears. i got the same issue after a long stress test with some other card, sujith gave me the idea to see if disabling PS helps sudo iwconfig wlanX power off sudo iw dev wlanX set power_save off also please ensure that you run with your power adapter :) i noticed PS gets enabled via wext when we plug out the power adapter -- thanks, shafi ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 5:09 ` Mohammed Shafi @ 2012-03-01 5:53 ` Kim Lidström -1 siblings, 0 replies; 37+ messages in thread From: Kim Lidström @ 2012-03-01 5:53 UTC (permalink / raw) To: ath9k-devel On 03/01/2012 06:09 AM, Mohammed Shafi wrote: >> With this message I have attached a log with the error messages. >> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm >> currently running 3.2.8. >> For some reason it happened at least 3-4 times shortly after each other >> today - so I thought I might ask on here what's happening. > > disabling power save would be a nice idea, to see if this issue disappears. > i got the same issue after a long stress test with some other card, sujith > gave me the idea to see if disabling PS helps > sudo iwconfig wlanX power off > sudo iw dev wlanX set power_save off > also please ensure that you run with your power adapter :) i noticed > PS gets enabled > via wext when we plug out the power adapter > I just tried it and will see what happens! That might take a while, though, because it seems to occur at random. But you know something? The thought has struck me before that it might have something to do with power saving. Interesting :) ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 @ 2012-03-01 5:53 ` Kim Lidström 0 siblings, 0 replies; 37+ messages in thread From: Kim Lidström @ 2012-03-01 5:53 UTC (permalink / raw) To: Mohammed Shafi, ath9k-devel, linux-wireless, Adrian Chadd On 03/01/2012 06:09 AM, Mohammed Shafi wrote: >> With this message I have attached a log with the error messages. >> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm >> currently running 3.2.8. >> For some reason it happened at least 3-4 times shortly after each other >> today - so I thought I might ask on here what's happening. > > disabling power save would be a nice idea, to see if this issue disappears. > i got the same issue after a long stress test with some other card, sujith > gave me the idea to see if disabling PS helps > sudo iwconfig wlanX power off > sudo iw dev wlanX set power_save off > also please ensure that you run with your power adapter :) i noticed > PS gets enabled > via wext when we plug out the power adapter > I just tried it and will see what happens! That might take a while, though, because it seems to occur at random. But you know something? The thought has struck me before that it might have something to do with power saving. Interesting :) ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 5:53 ` Kim Lidström (?) @ 2012-03-01 16:23 ` Mieszko Ślusarczyk 2012-03-02 6:21 ` Kim Lidström -1 siblings, 1 reply; 37+ messages in thread From: Mieszko Ślusarczyk @ 2012-03-01 16:23 UTC (permalink / raw) To: ath9k-devel Did disabling PM actually help? Wys?ane z iPoda Dnia 1 mar 2012 o godz. 06:53 Kim Lidstr?m <dexter@lacto.se> napisa?(a): > On 03/01/2012 06:09 AM, Mohammed Shafi wrote: >>> With this message I have attached a log with the error messages. >>> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm >>> currently running 3.2.8. >>> For some reason it happened at least 3-4 times shortly after each other >>> today - so I thought I might ask on here what's happening. >> >> disabling power save would be a nice idea, to see if this issue disappears. >> i got the same issue after a long stress test with some other card, sujith >> gave me the idea to see if disabling PS helps >> sudo iwconfig wlanX power off >> sudo iw dev wlanX set power_save off >> also please ensure that you run with your power adapter :) i noticed >> PS gets enabled >> via wext when we plug out the power adapter >> > > I just tried it and will see what happens! That might take a while, > though, because it seems to occur at random. > > But you know something? The thought has struck me before that it might > have something to do with power saving. Interesting :) > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 16:23 ` [ath9k-devel] " Mieszko Ślusarczyk @ 2012-03-02 6:21 ` Kim Lidström 0 siblings, 0 replies; 37+ messages in thread From: Kim Lidström @ 2012-03-02 6:21 UTC (permalink / raw) To: ath9k-devel So far it seems it's working. Haven't had a single issue for a day at least, but that's not uncommon. On 03/01/2012 05:23 PM, Mieszko ?lusarczyk wrote: > Did disabling PM actually help? > > Wys?ane z iPoda > > Dnia 1 mar 2012 o godz. 06:53 Kim Lidstr?m <dexter@lacto.se> napisa?(a): > >> On 03/01/2012 06:09 AM, Mohammed Shafi wrote: >>>> With this message I have attached a log with the error messages. >>>> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm >>>> currently running 3.2.8. >>>> For some reason it happened at least 3-4 times shortly after each other >>>> today - so I thought I might ask on here what's happening. >>> >>> disabling power save would be a nice idea, to see if this issue disappears. >>> i got the same issue after a long stress test with some other card, sujith >>> gave me the idea to see if disabling PS helps >>> sudo iwconfig wlanX power off >>> sudo iw dev wlanX set power_save off >>> also please ensure that you run with your power adapter :) i noticed >>> PS gets enabled >>> via wext when we plug out the power adapter >>> >> >> I just tried it and will see what happens! That might take a while, >> though, because it seems to occur at random. >> >> But you know something? The thought has struck me before that it might >> have something to do with power saving. Interesting :) >> >> _______________________________________________ >> ath9k-devel mailing list >> ath9k-devel at lists.ath9k.org >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 5:09 ` Mohammed Shafi (?) (?) @ 2012-03-01 14:46 ` Peter Stuge 2012-03-01 15:04 ` Mohammed Shafi ` (2 more replies) -1 siblings, 3 replies; 37+ messages in thread From: Peter Stuge @ 2012-03-01 14:46 UTC (permalink / raw) To: ath9k-devel Mohammed Shafi wrote: > disabling power save would be a nice idea, to see if this issue > disappears. I can not understand why Atheros insists on recommending "disable power saving" in response to this error which has been pouring out of ath9k hardware and driver for YEARS! It's baffling. Work with someone who has hardware clue and just fix the problem. //Peter ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 14:46 ` Peter Stuge @ 2012-03-01 15:04 ` Mohammed Shafi 2012-03-01 17:50 ` Ben Greear 2012-03-01 17:02 ` Adrian Chadd 2012-03-01 17:22 ` Felix Fietkau 2 siblings, 1 reply; 37+ messages in thread From: Mohammed Shafi @ 2012-03-01 15:04 UTC (permalink / raw) To: ath9k-devel > Work with someone who has hardware clue and just fix the problem. completely agree, we got to fix it. -- thanks, shafi ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 15:04 ` Mohammed Shafi @ 2012-03-01 17:50 ` Ben Greear 2012-03-01 18:01 ` Peter Stuge 2012-03-01 19:05 ` Sune Mølgaard 0 siblings, 2 replies; 37+ messages in thread From: Ben Greear @ 2012-03-01 17:50 UTC (permalink / raw) To: ath9k-devel On 03/01/2012 07:04 AM, Mohammed Shafi wrote: >> Work with someone who has hardware clue and just fix the problem. > > completely agree, we got to fix it. > There are folks with machines that can reproduce this very easily. Maybe offer to rent their system for some short time to see if you can reproduce it in your lab? I tried just getting their NICs and putting them in my own systems, but though I could occassionally get the error to print (maybe once every 2 days under full load) nothing locked up. It must be exacerbated by some interaction with other system components and/or the environment... Thanks, Ben -- Ben Greear <greearb@candelatech.com> Candela Technologies Inc http://www.candelatech.com ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 17:50 ` Ben Greear @ 2012-03-01 18:01 ` Peter Stuge 2012-03-01 19:05 ` Sune Mølgaard 1 sibling, 0 replies; 37+ messages in thread From: Peter Stuge @ 2012-03-01 18:01 UTC (permalink / raw) To: ath9k-devel Ben Greear wrote: > >> Work with someone who has hardware clue and just fix the problem. > > > > completely agree, we got to fix it. > > There are folks with machines that can reproduce this very easily. > > Maybe offer to rent their system for some short time to > see if you can reproduce it in your lab? This is a great idea. It would be both easy and quick. There's of course a very real risk that the problems do not occur in the lab environment (that's actually what I expect) so in the end it might be neccessary to go on a field trip to the original environment instead. But getting a machine into the lab takes a day or three with UPS and doesn't cost very much, so it's a great first step. Even if it doesn't work out it's so easy to try. > It must be exacerbated by some interaction with other system > components and/or the environment... I suspect both, but moving the system to the lab is so easy that it should absolutely be tried before moving the lab into the environment. :) //Peter ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 17:50 ` Ben Greear 2012-03-01 18:01 ` Peter Stuge @ 2012-03-01 19:05 ` Sune Mølgaard 1 sibling, 0 replies; 37+ messages in thread From: Sune Mølgaard @ 2012-03-01 19:05 UTC (permalink / raw) To: ath9k-devel Ben Greear wrote: > On 03/01/2012 07:04 AM, Mohammed Shafi wrote: >>> Work with someone who has hardware clue and just fix the problem. >> >> completely agree, we got to fix it. >> > > There are folks with machines that can reproduce this very easily. > > Maybe offer to rent their system for some short time to > see if you can reproduce it in your lab? > > I tried just getting their NICs and putting them in my own > systems, but though I could occassionally get the error to print (maybe once > every 2 days under full load) nothing locked up. It must be exacerbated by some > interaction with other system components and/or the environment... > > Thanks, > Ben > Sending my server anywhere would be inconvenient, but I could, perhaps, be persuaded to let 1, trustworthy, individual get an account and sudo rights on it. In my case, the problem doesn't lock the machine, but, of course, halts the wlan connection in question... Best, Sune -- It is my supposition that the Universe in not only queerer than we imagine, is queerer than we CAN imagine. - J. B. S. Haldane ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 14:46 ` Peter Stuge 2012-03-01 15:04 ` Mohammed Shafi @ 2012-03-01 17:02 ` Adrian Chadd 2012-03-01 17:23 ` Peter Stuge 2012-03-01 17:22 ` Felix Fietkau 2 siblings, 1 reply; 37+ messages in thread From: Adrian Chadd @ 2012-03-01 17:02 UTC (permalink / raw) To: ath9k-devel On 1 March 2012 06:46, Peter Stuge <peter@stuge.se> wrote: > Mohammed Shafi wrote: >> disabling power save would be a nice idea, ?to see if this issue >> disappears. > > I can not understand why Atheros insists on recommending "disable > power saving" in response to this error which has been pouring out > of ath9k hardware and driver for YEARS! .. to debug whether it is related to power saving support or not? I've still left power saving modes and sleep mode support off in BSD for now as, honestly, I don't have the time or the ridiculous array of laptops required to debug this.. let alone my own personal PCIe analyser. Adrian ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 17:02 ` Adrian Chadd @ 2012-03-01 17:23 ` Peter Stuge 0 siblings, 0 replies; 37+ messages in thread From: Peter Stuge @ 2012-03-01 17:23 UTC (permalink / raw) To: ath9k-devel Adrian Chadd wrote: > > I can not understand why Atheros insists on recommending "disable > > power saving" in response to this error which has been pouring out > > of ath9k hardware and driver for YEARS! > > .. to debug whether it is related to power saving support or not? That isn't debugging, it's just playing around with some knobs. Debugging starts at the lowest layer and works upwards, not the other way around. > I've still left power saving modes and sleep mode support off in BSD > for now as, honestly, I don't have the time or the ridiculous array > of laptops required to debug this.. Indeed a concentrated effort and detailed hardware knowledge is required to resolve the problem. I don't expect that a single community member can do that. I do however expect that Atheros can do it, either completely on their own, or if not (because they can't reproduce the problem) then *certainly* together with someone in the community who has a clue about hardware. This requires intimate cooperation and sharing of information that will make lawyers run and scream in fear of FCC wrath or worse. I couldn't care less. There's a significant technical problem and if there is a way to fix it then do it. If it is *really* neccessary then bring out some NDAs. > let alone my own personal PCIe analyser. Yes they're expensive but I'm sure Atheros has one. But I actually expect that the hardware has enough low-level debug functionality on a side channel that a bus analyzer is not even strictly neccessary. The hardware developers will know. If Atheros refuses to make that information available to anyone else, well, then the problem will never be solved. This isn't rocket science, it's *basic bringup* of a PCI device. (These problems were there long before PCIe.) But the errors remain, in generation after generation after generation of products going to market... //Peter ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 14:46 ` Peter Stuge 2012-03-01 15:04 ` Mohammed Shafi 2012-03-01 17:02 ` Adrian Chadd @ 2012-03-01 17:22 ` Felix Fietkau 2012-03-01 17:53 ` Peter Stuge 2 siblings, 1 reply; 37+ messages in thread From: Felix Fietkau @ 2012-03-01 17:22 UTC (permalink / raw) To: ath9k-devel On 2012-03-01 3:46 PM, Peter Stuge wrote: > Mohammed Shafi wrote: >> disabling power save would be a nice idea, to see if this issue >> disappears. > > I can not understand why Atheros insists on recommending "disable > power saving" in response to this error which has been pouring out > of ath9k hardware and driver for YEARS! > > It's baffling. > > Work with someone who has hardware clue and just fix the problem. If you weren't so locked up in your bitching and moaning habit, you might have noticed that just because the error messages are similar does not mean that it's just one bug that has been lurking in the driver for years. Just because one ore more symptoms are the same does not mean that the issue has just one cause, or always leads to the same connectivity issues. I remember at least 5 different issues that I fixed myself, which had all led to these exact symptoms, but were otherwise unrelated to each other and had different side effects. On most chips with recent kernels, these issues tend to not be fatal anymore, and at least on embedded hardware it's getting much harder to find people that can still produce connection stability issues. Sometimes I wonder why you keep wasting your energy on these rants, which do *nothing* to fix the underlying issues. In fact, while I'm writing this I wonder why I bother to respond, but I guess my answer is simply to provide some perspective for people that might stumble upon one of your mindless rants for the first time. If your intention really is to improve the situation, then please use your time to do something useful instead of writing such garbage. ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 17:22 ` Felix Fietkau @ 2012-03-01 17:53 ` Peter Stuge 2012-03-01 18:13 ` Felix Fietkau 0 siblings, 1 reply; 37+ messages in thread From: Peter Stuge @ 2012-03-01 17:53 UTC (permalink / raw) To: ath9k-devel Felix Fietkau wrote: > just because the error messages are similar does not mean that it's > just one bug that has been lurking in the driver for years. I didn't say that it's a single issue, but it's clearly a single class of issues, and I'm surprised that there is noone who can take a hard look at DMA (with all required information at hand) and make it reliable, even after so long time. > Just because one ore more symptoms are the same does not mean that the > issue has just one cause, or always leads to the same connectivity > issues. Absolutely right. And from the error messages alone "Failed to stop DMA" it's clear that connectivity issues are really not so relevant for debugging the issue, they are merely the symptom and thus not really useful. The problem must be instrumented at a much lower level. > I remember at least 5 different issues that I fixed myself, which had > all led to these exact symptoms, but were otherwise unrelated to each > other and had different side effects. You and Adrian have done and continue to do amazing work. But I don't think that it's supposed to be you who solve these issues. > On most chips with recent kernels, these issues tend to not be fatal > anymore, and at least on embedded hardware it's getting much harder > to find people that can still produce connection stability issues. Yes, IIRC the last (known?) memory corruption was resolved fall 2011. Still, DMA is not exotic, and here are DMA problems again. > Sometimes I wonder why you keep wasting your energy on these rants, > which do *nothing* to fix the underlying issues. I think it's clear that the community will never have the opportunity to work closely with Atheros on the lowest levels, so the only thing left for anyone in the community to do is to complain, so that perhaps some day Atheros will fix the issue(s). Ideally of course the complaints become too tiresome, and suddenly everyone can work together instead. But I know how foreign this is under many circumstances, so I don't expect it to happen anytime soon. > In fact, while I'm writing this I wonder why I bother to respond, > but I guess my answer is simply to provide some perspective for > people that might stumble upon one of your mindless rants for the > first time. Mindless as they may seem, I complain because I notice something that could be better than it is. I appreciate that Atheros cares about Linux (although by now so do all their competitors) and the Atheros hardware keeps looking good as always, but hardware development information in the community is not really available. > If your intention really is to improve the situation, then please > use your time to do something useful instead of writing such garbage. I tried several times, and was repeatedly shot down or simply ignored because I didn't have the latest hardware, or because I was asking too low-level questions that were not permitted to be discussed, or for some other reason. I can only guess. So I will not waste more of my time until I believe that I will get hard support in order to work efficiently. Being told to try to reverse engineer the hardware using the driver source code or any other source code does not qualify. > From what I can see, the recommendation to try disabling powersave > is actually useful for narrowing down the source of this issue... No. Disabling powersave is a workaround, but it doesn't help find the problem. Debugging the issue requires looking inside the hardware, and by now it's obvious at least to me that if that ever happens then it will be in Atheros' lab and nowhere else. //Peter ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 17:53 ` Peter Stuge @ 2012-03-01 18:13 ` Felix Fietkau 2012-03-01 18:42 ` Peter Stuge 0 siblings, 1 reply; 37+ messages in thread From: Felix Fietkau @ 2012-03-01 18:13 UTC (permalink / raw) To: ath9k-devel On 2012-03-01 6:53 PM, Peter Stuge wrote: > Felix Fietkau wrote: >> just because the error messages are similar does not mean that it's >> just one bug that has been lurking in the driver for years. > > I didn't say that it's a single issue, but it's clearly a single > class of issues, and I'm surprised that there is noone who can take a > hard look at DMA (with all required information at hand) and make it > reliable, even after so long time. Saying it's a single class of issues does not help in any way, because with the issues I've fixed so far, the cause has been wildly different. Sometimes software race conditions, sometimes wrong register settings, or sometimes actual issues in setting up DMA descriptors. >> Just because one ore more symptoms are the same does not mean that the >> issue has just one cause, or always leads to the same connectivity >> issues. > > Absolutely right. And from the error messages alone "Failed to stop > DMA" it's clear that connectivity issues are really not so relevant > for debugging the issue, they are merely the symptom and thus not > really useful. The problem must be instrumented at a much lower > level. Instrumenting at a lower level does not necessarily help. Even if you manage to capture all PCI bus traffic, there's still a good chance that this won't help, because the problem could very well be in a completely different layer. My hunch on this particular issue is that it's AR9485 specific, and there's simply a chipset difference compared to AR93xx that may not have been accounted for in the driver yet. >> I remember at least 5 different issues that I fixed myself, which had >> all led to these exact symptoms, but were otherwise unrelated to each >> other and had different side effects. > > You and Adrian have done and continue to do amazing work. But I don't > think that it's supposed to be you who solve these issues. > > >> On most chips with recent kernels, these issues tend to not be fatal >> anymore, and at least on embedded hardware it's getting much harder >> to find people that can still produce connection stability issues. > > Yes, IIRC the last (known?) memory corruption was resolved fall 2011. > > Still, DMA is not exotic, and here are DMA problems again. That last sentence makes no sense at all. >> Sometimes I wonder why you keep wasting your energy on these rants, >> which do *nothing* to fix the underlying issues. > > I think it's clear that the community will never have the opportunity > to work closely with Atheros on the lowest levels, so the only thing > left for anyone in the community to do is to complain, so that > perhaps some day Atheros will fix the issue(s). > > Ideally of course the complaints become too tiresome, and suddenly > everyone can work together instead. But I know how foreign this is > under many circumstances, so I don't expect it to happen anytime > soon. How do you define 'lowest level'? If you think that just because the message says something about DMA, it must be an issue in DMA transfers, you're completely missing the point. >> In fact, while I'm writing this I wonder why I bother to respond, >> but I guess my answer is simply to provide some perspective for >> people that might stumble upon one of your mindless rants for the >> first time. > > Mindless as they may seem, I complain because I notice something that > could be better than it is. I appreciate that Atheros cares about > Linux (although by now so do all their competitors) and the Atheros > hardware keeps looking good as always, but hardware development > information in the community is not really available. I found that people that have shown enough interest in improving ath9k and have proven to be experienced in working on such drivers tend to get access to documentation. >> If your intention really is to improve the situation, then please >> use your time to do something useful instead of writing such garbage. > > I tried several times, and was repeatedly shot down or simply ignored > because I didn't have the latest hardware, or because I was asking > too low-level questions that were not permitted to be discussed, or > for some other reason. I can only guess. So I will not waste more of > my time until I believe that I will get hard support in order to work > efficiently. Being told to try to reverse engineer the hardware using > the driver source code or any other source code does not qualify. Your definition of 'reverse engineering' is quite funny. >> From what I can see, the recommendation to try disabling powersave >> is actually useful for narrowing down the source of this issue... > > No. Disabling powersave is a workaround, but it doesn't help find the > problem. Debugging the issue requires looking inside the hardware, > and by now it's obvious at least to me that if that ever happens then > it will be in Atheros' lab and nowhere else. To me it looks somewhat ridiculous that you claim to know better what's required to debug this issue than people working with the hardware on a daily basis (Adrian, Mohammed, me). - Felix ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 18:13 ` Felix Fietkau @ 2012-03-01 18:42 ` Peter Stuge 2012-03-01 18:51 ` Peter Stuge 2012-03-01 19:18 ` Felix Fietkau 0 siblings, 2 replies; 37+ messages in thread From: Peter Stuge @ 2012-03-01 18:42 UTC (permalink / raw) To: ath9k-devel Felix Fietkau wrote: > Saying it's a single class of issues does not help in any way, because > with the issues I've fixed so far, the cause has been wildly different. > Sometimes software race conditions, sometimes wrong register settings, > or sometimes actual issues in setting up DMA descriptors. All affecting DMA. > Instrumenting at a lower level does not necessarily help. Even if you > manage to capture all PCI bus traffic, there's still a good chance that > this won't help, because the problem could very well be in a completely > different layer. Yes, it depends on what the error is of course. But making assumptions is not the way to do debugging. > > Still, DMA is not exotic, and here are DMA problems again. > > That last sentence makes no sense at all. My point is that DMA by peripheral devices and the drivers to manage it are established technologies in computer busses across the world, so it keeps surprising me that drivers in 2012 get it wrong. > > I think it's clear that the community will never have the opportunity > > to work closely with Atheros on the lowest levels, > > How do you define 'lowest level'? An example would be to monitor state machines inside the device using side channel debugging, while in parallell monitoring state machines inside the driver. Then comparing them after the fact and seeing where one goes wrong. Find out why, and audit the complete driver for similar types of errors. Of course the same issue could (theoretically) also be found purely by static analysis, but that's not very efficient. > If you think that just because the message says something about > DMA, it must be an issue in DMA transfers, you're completely > missing the point. Not saying must be the cause, but it must be eliminated before walking up the layers. > > but hardware development information in the community is not > > really available. > > I found that people that have shown enough interest in improving ath9k > and have proven to be experienced in working on such drivers tend to get > access to documentation. Well, let's say that in my experience the threshold for "approval" was set too high. As I said, and as you may remember, I was repeatedly shot down or ignored, offering to try to get to the bottom of the issues. I understand now that it may not really be legally possible for Atheros to provide the information that is actually required to get to the bottom of the issues, but that makes working on the driver too inefficient. > > Being told to try to reverse engineer the hardware using the > > driver source code or any other source code does not qualify. > > Your definition of 'reverse engineering' is quite funny. There's not just one type of reverse engineering. Suggesting hardware reverse engineering in an open source driver development effort is, well, not what I expect. > To me it looks somewhat ridiculous that you claim to know better what's > required to debug this issue than people working with the hardware on a > daily basis (Adrian, Mohammed, me). I've developed both hardware and software for more than 20 years, and neither problems nor solutions have changed much, so I think I still have a clue. //Peter ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 18:42 ` Peter Stuge @ 2012-03-01 18:51 ` Peter Stuge 2012-03-01 19:18 ` Felix Fietkau 1 sibling, 0 replies; 37+ messages in thread From: Peter Stuge @ 2012-03-01 18:51 UTC (permalink / raw) To: ath9k-devel Peter Stuge wrote: > Suggesting hardware reverse engineering in an open source driver > development effort is, well, not what I expect. To clarify a bit; we do this all the time in coreboot, but only for vendors who aren't participating in the community, where we are left with no other choice than the most inefficient method, if we want the code to get done. The extra effort is of course quite prohibitive. //Peter ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 18:42 ` Peter Stuge 2012-03-01 18:51 ` Peter Stuge @ 2012-03-01 19:18 ` Felix Fietkau 2012-03-01 19:53 ` Peter Stuge 1 sibling, 1 reply; 37+ messages in thread From: Felix Fietkau @ 2012-03-01 19:18 UTC (permalink / raw) To: ath9k-devel On 2012-03-01 7:42 PM, Peter Stuge wrote: > Felix Fietkau wrote: >> Saying it's a single class of issues does not help in any way, because >> with the issues I've fixed so far, the cause has been wildly different. >> Sometimes software race conditions, sometimes wrong register settings, >> or sometimes actual issues in setting up DMA descriptors. > > All affecting DMA. You're missing the point *again*. Many of the things I found were unrelated to DMA, but messed up the MAC state enough to trigger this warning. Of course you could say that since the MAC also does DMA, the problem must thereby somehow be DMA related, but using that to justify your whining would be kind of stupid. Let's just drop the "it says DMA, so it must be DMA related" nonsense. >> Instrumenting at a lower level does not necessarily help. Even if you >> manage to capture all PCI bus traffic, there's still a good chance that >> this won't help, because the problem could very well be in a completely >> different layer. > > Yes, it depends on what the error is of course. But making > assumptions is not the way to do debugging. Right, that's why I'm trying to bust your assumption that starting with the lowest layer is a good idea. >> > Still, DMA is not exotic, and here are DMA problems again. >> >> That last sentence makes no sense at all. > > My point is that DMA by peripheral devices and the drivers to manage > it are established technologies in computer busses across the world, > so it keeps surprising me that drivers in 2012 get it wrong. Which proves to me yet again that you're completely missing the point of what I'm saying about the likelihood of this being *NOT* DMA related. >> > I think it's clear that the community will never have the opportunity >> > to work closely with Atheros on the lowest levels, >> >> How do you define 'lowest level'? > > An example would be to monitor state machines inside the device using > side channel debugging, while in parallell monitoring state machines > inside the driver. Then comparing them after the fact and seeing > where one goes wrong. Find out why, and audit the complete driver for > similar types of errors. > > Of course the same issue could (theoretically) also be found purely > by static analysis, but that's not very efficient. In my experience, this generates *way* too much data to be of any use to narrow down the source of the problem. >> If you think that just because the message says something about >> DMA, it must be an issue in DMA transfers, you're completely >> missing the point. > > Not saying must be the cause, but it must be eliminated before > walking up the layers. ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 19:18 ` Felix Fietkau @ 2012-03-01 19:53 ` Peter Stuge 2012-03-01 20:26 ` Adrian Chadd 2012-03-01 20:40 ` Felix Fietkau 0 siblings, 2 replies; 37+ messages in thread From: Peter Stuge @ 2012-03-01 19:53 UTC (permalink / raw) To: ath9k-devel Felix Fietkau wrote: > >> Instrumenting at a lower level does not necessarily help. Even if you > >> manage to capture all PCI bus traffic, there's still a good chance that > >> this won't help, because the problem could very well be in a completely > >> different layer. > > > > Yes, it depends on what the error is of course. But making > > assumptions is not the way to do debugging. > > Right, that's why I'm trying to bust your assumption that starting > with the lowest layer is a good idea. No assumption involved. > >> > Still, DMA is not exotic, and here are DMA problems again. > >> > >> That last sentence makes no sense at all. > > > > My point is that DMA by peripheral devices and the drivers to manage > > it are established technologies in computer busses across the world, > > so it keeps surprising me that drivers in 2012 get it wrong. > > Which proves to me yet again that you're completely missing the point of > what I'm saying about the likelihood of this being *NOT* DMA related. It is, because the error leads to either or both sides thinking about DMA when they should not. > >> How do you define 'lowest level'? > > > > An example would be to monitor state machines inside the device using > > side channel debugging, while in parallell monitoring state machines > > inside the driver. Then comparing them after the fact and seeing > > where one goes wrong. Find out why, and audit the complete driver for > > similar types of errors. > > In my experience, this generates *way* too much data to be of any use to > narrow down the source of the problem. Filtering out unimportant data is of course a big part of the debugging. The very first thing to do I'd say, and also a recurring thing to do, in order to build the complete picture of what is going on. The more knowledge about the hardware one has, the faster this process is. It might need a few days of work next to the logic analyzer for someone with a predisposition. > The lower you go on the level of abstraction, the more data any kind of > debugging approach generates, meaning way more effort to analyze the > data and make sense of it. Only if the data can't be interpreted, for example, due to lack of documentation. > I don't typically start with the part that's hardest to analyze. High > level states are easier to look into and make sense of, so they're also > easier to rule out. But they mask a myriad of lower level operations. I also did not universally argue against the top-down approach, but if there is a tricky problem then I much prefer to acquire all the data once and look at it carefully, instead of trying to turn knobs to see what happens. > Code review is also a very good starting point. I actually found and > fixed more user visible bugs through code review than any other > debugging method. I expect everyone to do code review and to catch their own simple mistakes. I also expect at least one more person to have done code review before the code ends up in a kernel tree. But it is obviously impractical for a bystander to do code review of ath9k when it was first introduced, because, as always, it's a code drop, and did I mention that there is no documentation, meaning that it's impossible to catch anything but the most stupid mistakes with review alone. > Most issues can be fixed with a good understanding of the code alone, > detailed hardware knowledge is often not as important. Understanding the code is one thing. Understanding the hardware is another. The code can be studied to gain understanding of the code. The hardware can not be studied. Unless one has complete understanding of both code and hardware it's impossible to spot all errors in the code. This is why documentation and information flow is critical to have working software. Reverse engineering the hardware by studying the code leads to an at-best incomplete understanding of the hardware, and copious amounts of life will have been wasted in the process. > This isn't unique to ath9k. Agree completely. > I've fixed bugs in other drivers as well without having any form of > hardware documentation, because I'm able to read and understand > code and my brain can handle a bit of complexity. Sure, it's possible to guess what is causing a problem, but it's more reliable to know for sure. As a bonus, one might discover other smaller issues that can be fixed along the way. > OK, so let me get this straight: You can't imagine how the test result > from disabling PS could be useful for tracking down the problem, so you > automatically assume that it *must* be a lame workaround suggestion? > That seems rather narrow-minded of you. The first time it was suggested and tried it gave a bit of valuable information. Now, several years later, the same test doesn't keep on giving so many useful bits of information anymore.. Since it's a high level test it can't determine with much certainty what the key lower level effects are which make the symptom disappear. > Of course I can see multiple ways in which this information would > be useful, but I guess that may not matter to you. Right, the fact that it can mean *multiple* things is what makes it useless. I never said that the test does not narrow the search, but it's not sufficient to *identify* any issue, so when it is the only suggestion given, over and over, it is, in fact, just a workaround. //Peter ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 19:53 ` Peter Stuge @ 2012-03-01 20:26 ` Adrian Chadd 2012-03-01 20:40 ` Felix Fietkau 1 sibling, 0 replies; 37+ messages in thread From: Adrian Chadd @ 2012-03-01 20:26 UTC (permalink / raw) To: ath9k-devel Hi, It turns out that "stuff" is complicated. Want to fix it? Atheros/Qualcomm may be hiring. :-) As Felix said, the trouble with "stuck DMA" is that it's almost guaranteed to be the symptom, not the cause. Same deal with "stuck beacon". It turns out that so many weird and wonderful things have lead to "stuck beacons", some of which we're still wading through. The recent ANI patch (which I hope hasn't just been blindly accepted into the tree, grr...) is just one example of this. So, my original point still stands. If disabling power save fixes the issue, then it can be added to a bug report (Kim - you posted a bug report in bugzilla.kernel.org, right? :-) and someone can begin looking into things further. I'd love to give more useful feedback but I've _explicitly_ stayed away from network/bus power saving stuff until I've finished off the BSD 11n support and found/fixed all the weird little race conditions that keep popping up. Yes, I'm that kind of engineer. Adrian ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 19:53 ` Peter Stuge 2012-03-01 20:26 ` Adrian Chadd @ 2012-03-01 20:40 ` Felix Fietkau 2012-03-01 21:27 ` Peter Stuge 1 sibling, 1 reply; 37+ messages in thread From: Felix Fietkau @ 2012-03-01 20:40 UTC (permalink / raw) To: ath9k-devel On 2012-03-01 8:53 PM, Peter Stuge wrote: >> >> > Still, DMA is not exotic, and here are DMA problems again. >> >> >> >> That last sentence makes no sense at all. >> > >> > My point is that DMA by peripheral devices and the drivers to manage >> > it are established technologies in computer busses across the world, >> > so it keeps surprising me that drivers in 2012 get it wrong. >> >> Which proves to me yet again that you're completely missing the point of >> what I'm saying about the likelihood of this being *NOT* DMA related. > > It is, because the error leads to either or both sides thinking about > DMA when they should not. Either or both sides of what? Thinking about DMA? That sentence unfortunately makes no sense to me. Most of the time when the driver tries to stop DMA, the hardware doesn't respond in time, because either the MAC or the host interface state has locked up. It can also be caused by the MAC not fully waking up from a sleep state (hence the powersave related suggestion). >> >> How do you define 'lowest level'? >> > >> > An example would be to monitor state machines inside the device using >> > side channel debugging, while in parallell monitoring state machines >> > inside the driver. Then comparing them after the fact and seeing >> > where one goes wrong. Find out why, and audit the complete driver for >> > similar types of errors. >> >> In my experience, this generates *way* too much data to be of any use to >> narrow down the source of the problem. > > Filtering out unimportant data is of course a big part of the > debugging. The very first thing to do I'd say, and also a recurring > thing to do, in order to build the complete picture of what is going > on. > > The more knowledge about the hardware one has, the faster this > process is. It might need a few days of work next to the logic > analyzer for someone with a predisposition. > > >> The lower you go on the level of abstraction, the more data any kind of >> debugging approach generates, meaning way more effort to analyze the >> data and make sense of it. > > Only if the data can't be interpreted, for example, due to lack of > documentation. > > >> I don't typically start with the part that's hardest to analyze. High >> level states are easier to look into and make sense of, so they're also >> easier to rule out. > > But they mask a myriad of lower level operations. I also did not > universally argue against the top-down approach, but if there is a > tricky problem then I much prefer to acquire all the data once and > look at it carefully, instead of trying to turn knobs to see what > happens. >> OK, so let me get this straight: You can't imagine how the test result >> from disabling PS could be useful for tracking down the problem, so you >> automatically assume that it *must* be a lame workaround suggestion? >> That seems rather narrow-minded of you. > > The first time it was suggested and tried it gave a bit of valuable > information. Now, several years later, the same test doesn't keep on > giving so many useful bits of information anymore.. > > Since it's a high level test it can't determine with much certainty > what the key lower level effects are which make the symptom > disappear. > > >> Of course I can see multiple ways in which this information would >> be useful, but I guess that may not matter to you. > > Right, the fact that it can mean *multiple* things is what makes it > useless. In the early stages of debugging, you will usually *never* get data points that only mean one thing. One data point leads to ideas for further tests > I never said that the test does not narrow the search, but it's not > sufficient to *identify* any issue, so when it is the only suggestion > given, over and over, it is, in fact, just a workaround. Just because it cannot be used by itself to fully identify the issue doesn't mean it's a bad idea to get that data. I believe acquiring *all* data at once is impossible (or at least completely impractical), and I believe that the structured approach of going up one level at a time is horribly inefficient and often grossly misleading for bugs that show low level symptoms but have a high level causes. Incidentally, the 'trying to turn knobs to see what happens' approach plus code review have been very efficient for me in dealing with that class of bugs, and I'll take that over a random guy's random theory of how debugging should and *must* be done any day. So one of the differences between us appears to be this: You advocate that there is one way that things must be done, and if the prerequisites for that approach way aren't met, then it's impossible. My opinion is that this is nothing but a lame excuse, proven by the fact that I've been able to easily deal with similar situations in other drivers, and that I know people that have found and fixed some weird bugs in ath9k without having had any access to documentation and without having spent weeks on what you call 'reverse engineering'. I will now refrain from any further discussion with you on debugging approaches, since you seem quite comfortable and content in staying within your view of limitations and impossibilities, whereas I prefer to get some real work done. :) - Felix ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 20:40 ` Felix Fietkau @ 2012-03-01 21:27 ` Peter Stuge 2012-03-02 0:38 ` Sujith Manoharan 0 siblings, 1 reply; 37+ messages in thread From: Peter Stuge @ 2012-03-01 21:27 UTC (permalink / raw) To: ath9k-devel Felix Fietkau wrote: > > It is, because the error leads to either or both sides thinking about > > DMA when they should not. > > Either or both sides of what? Thinking about DMA? That sentence > unfortunately makes no sense to me. One side = driver Other side = hardware > Most of the time when the driver tries to stop DMA, the hardware doesn't > respond in time, because either the MAC or the host interface state has > locked up. It can also be caused by the MAC not fully waking up from a > sleep state (hence the powersave related suggestion). I should have added "or not thinking about DMA when they should" above. This is of course just as likely. > In the early stages of debugging, you will usually *never* get data > points that only mean one thing. One data point leads to ideas for > further tests Yes it can, but the issue I have with the powersave suggestion is that I haven't seen followup discussion after the test has been done. So the takeaway becomes "you can maybe avoid the problem by disabling powersave" instead of "if you first disable powersave and that makes the issue go away then you can look at this-and-this and poke there-and-there in order to make the driver do that-and-that which will show what to do next." > I believe acquiring *all* data at once is impossible (or at least > completely impractical), and I believe that the structured approach of > going up one level at a time is horribly inefficient and often grossly > misleading for bugs that show low level symptoms but have a high level > causes. It is an investment into understanding both the hardware and the code, which pays off quicker and quicker as the number of errors found goes up. Of course it's a big effort when starting from zero as the community always does. This is where the sharing of experience by Atheros engineers is critical for semblance of efficiency. > Incidentally, the 'trying to turn knobs to see what happens' approach > plus code review have been very efficient for me in dealing with that > class of bugs, and I'll take that over a random guy's random theory of > how debugging should and *must* be done any day. As I wrote in the last email it's not the only way, but it's the only way to have a complete picture of what is going on. Obviously getting there takes more effort than turning knobs, but it pays off because it gives the complete picture. > So one of the differences between us appears to be this: You advocate > that there is one way that things must be done, and if the prerequisites > for that approach way aren't met, then it's impossible. No, I never said impossible. Please make more of an effort not to put words in my mouth. I'm talking about what is reliable and efficient to reach a driver that works perfectly. > My opinion is that this is nothing but a lame excuse, That's fine of course. > proven by the fact that I've been able to easily deal with similar > situations in other drivers, and that I know people that have found > and fixed some weird bugs in ath9k without having had any access to > documentation and without having spent weeks on what you call > 'reverse engineering'. Unfortunately all this says is that the ath9k code was really *really* messy to begin with. :( This is already known, and it's also known that you have done a lot of work to clean it up. I don't think it would take weeks, but I think that loading ath9k into head without help would take several days. That's not efficient when others already have it loaded and can share information and experience. I'm not contesting that you've done good work. I'm saying that if there are difficult-to-find errors then having a complete picture of state and comparing the desired behavior with the observed behavior is unbeatable. But it requires knowing what desired behavior is, which requires information about the hardware. > I will now refrain from any further discussion with you on debugging > approaches, since you seem quite comfortable and content in staying > within your view of limitations and impossibilities, whereas I > prefer to get some real work done. :) I think you may be misunderstanding what I write. But I agree on getting work done, our discussion about prefered debugging technique does not change anything either way. //Peter ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-01 21:27 ` Peter Stuge @ 2012-03-02 0:38 ` Sujith Manoharan 2012-03-02 2:21 ` Peter Stuge 0 siblings, 1 reply; 37+ messages in thread From: Sujith Manoharan @ 2012-03-02 0:38 UTC (permalink / raw) To: ath9k-devel Peter Stuge wrote: > I think you may be misunderstanding what I write. I don't think anyone is misunderstanding anything about you, or what you write. Sujith ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-02 0:38 ` Sujith Manoharan @ 2012-03-02 2:21 ` Peter Stuge 0 siblings, 0 replies; 37+ messages in thread From: Peter Stuge @ 2012-03-02 2:21 UTC (permalink / raw) To: ath9k-devel Sujith Manoharan wrote: > I don't think anyone is misunderstanding anything about you, or > what you write. Sadly I don't know you guys, have only very briefly met Felix, and from merely the discussions on the list there's only very little that can be understood about me, as with everyone else. I think it would be great to meet and chat about other things, but the community is pretty small. Anyway, I try to write very clearly, if inconveniently blunt at times. And from Felix' response it seemed that he had misunderstood, so I tried to clarify that I do not consider anything impossible. My point is about quickly and reliably getting to the bottom of an issue. I will take too much data over not enough data every time. If it's possible to work with a complete picture, with both desired and actual results in both driver and hardware, then the output of the debugging effort ends up being excellent, and more will have been learned underway by all involved than otherwise, which in turn leads to even better understanding and quality in the future. But of course there's always a tradeoff involved when determining how much time to spend. //Peter ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-02-29 21:35 ` Kim Lidström @ 2012-03-07 17:29 ` Felix Fietkau -1 siblings, 0 replies; 37+ messages in thread From: Felix Fietkau @ 2012-03-07 17:29 UTC (permalink / raw) To: ath9k-devel On 2012-02-29 10:35 PM, Kim Lidstr?m wrote: > Hello! > A while ago I had a situation where my AR9485 would lock up the kernel > so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. Sorry I > forgot his last name) were very patient in helping me and trying to > debug it through patches, etc. Nothing worked. > Eventually, though, I noticed that when I removed the atl1c module my > wlan started working. "Awesome!" I thought... Until I noticed this other > problem. > > Once in a while, seemingly at random, the wlan dies with the error > messages in the title. And I can't possibly restore it without > restarting the computer. > > With this message I have attached a log with the error messages. > This has been a problem since.. Uhm.. Kernel 3.2.something and I'm > currently running 3.2.8. > For some reason it happened at least 3-4 times shortly after each other > today - so I thought I might ask on here what's happening. Please try this patch with powersave enabled, using a recent compat-wireless build (3.3 or linux-next based): http://nbd.name/ps-fix.patch - Felix ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 @ 2012-03-07 17:29 ` Felix Fietkau 0 siblings, 0 replies; 37+ messages in thread From: Felix Fietkau @ 2012-03-07 17:29 UTC (permalink / raw) To: Kim Lidström; +Cc: linux-wireless, ath9k-devel On 2012-02-29 10:35 PM, Kim Lidström wrote: > Hello! > A while ago I had a situation where my AR9485 would lock up the kernel > so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. Sorry I > forgot his last name) were very patient in helping me and trying to > debug it through patches, etc. Nothing worked. > Eventually, though, I noticed that when I removed the atl1c module my > wlan started working. "Awesome!" I thought... Until I noticed this other > problem. > > Once in a while, seemingly at random, the wlan dies with the error > messages in the title. And I can't possibly restore it without > restarting the computer. > > With this message I have attached a log with the error messages. > This has been a problem since.. Uhm.. Kernel 3.2.something and I'm > currently running 3.2.8. > For some reason it happened at least 3-4 times shortly after each other > today - so I thought I might ask on here what's happening. Please try this patch with powersave enabled, using a recent compat-wireless build (3.3 or linux-next based): http://nbd.name/ps-fix.patch - Felix ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-07 17:29 ` Felix Fietkau (?) @ 2012-03-07 18:35 ` Paul Farrow -1 siblings, 0 replies; 37+ messages in thread From: Paul Farrow @ 2012-03-07 18:35 UTC (permalink / raw) To: ath9k-devel Hi Felix I would like to try your patch to see if it stops my Tx DMA errors on my AR9280 chipset pcie card. 1. Do you think it might work? 2. What is the best way to apply this patch? Please be gentle with me as I am linux hobbyist and I am keen to get my Tx DMA error problem sorted. Thanks Paul On Wed, 07 Mar 2012 18:29:56 +0100, Felix Fietkau wrote: > On 2012-02-29 10:35 PM, Kim Lidstr?m wrote: >> Hello! >> A while ago I had a situation where my AR9485 would lock up the >> kernel >> so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. >> Sorry I >> forgot his last name) were very patient in helping me and trying to >> debug it through patches, etc. Nothing worked. >> Eventually, though, I noticed that when I removed the atl1c module >> my >> wlan started working. "Awesome!" I thought... Until I noticed this >> other >> problem. >> >> Once in a while, seemingly at random, the wlan dies with the error >> messages in the title. And I can't possibly restore it without >> restarting the computer. >> >> With this message I have attached a log with the error messages. >> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm >> currently running 3.2.8. >> For some reason it happened at least 3-4 times shortly after each >> other >> today - so I thought I might ask on here what's happening. > Please try this patch with powersave enabled, using a recent > compat-wireless build (3.3 or linux-next based): > http://nbd.name/ps-fix.patch > > - Felix > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Paul ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-07 17:29 ` Felix Fietkau (?) (?) @ 2012-03-07 18:37 ` Paul Farrow 2012-03-07 19:42 ` Felix Fietkau -1 siblings, 1 reply; 37+ messages in thread From: Paul Farrow @ 2012-03-07 18:37 UTC (permalink / raw) To: ath9k-devel On Wed, 07 Mar 2012 18:29:56 +0100, Felix Fietkau wrote: > On 2012-02-29 10:35 PM, Kim Lidstr?m wrote: >> Hello! >> A while ago I had a situation where my AR9485 would lock up the >> kernel >> so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. >> Sorry I >> forgot his last name) were very patient in helping me and trying to >> debug it through patches, etc. Nothing worked. >> Eventually, though, I noticed that when I removed the atl1c module >> my >> wlan started working. "Awesome!" I thought... Until I noticed this >> other >> problem. >> >> Once in a while, seemingly at random, the wlan dies with the error >> messages in the title. And I can't possibly restore it without >> restarting the computer. >> >> With this message I have attached a log with the error messages. >> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm >> currently running 3.2.8. >> For some reason it happened at least 3-4 times shortly after each >> other >> today - so I thought I might ask on here what's happening. > Please try this patch with powersave enabled, using a recent > compat-wireless build (3.3 or linux-next based): > http://nbd.name/ps-fix.patch > > - Felix > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel Hi Felix I would like to try your patch to see if it stops my Tx DMA errors on my AR9280 chipset pcie card. 1. Do you think it might work? 2. What is the best way to apply this patch? Please be gentle with me as I am linux hobbyist and I am keen to get my Tx DMA error problem sorted which I can recreate straight away every time. Thanks Paul ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-07 18:37 ` Paul Farrow @ 2012-03-07 19:42 ` Felix Fietkau 2012-03-07 19:55 ` Paul Farrow 0 siblings, 1 reply; 37+ messages in thread From: Felix Fietkau @ 2012-03-07 19:42 UTC (permalink / raw) To: ath9k-devel On 2012-03-07 7:37 PM, Paul Farrow wrote: > > On Wed, 07 Mar 2012 18:29:56 +0100, Felix Fietkau wrote: >> On 2012-02-29 10:35 PM, Kim Lidstr?m wrote: >>> Hello! >>> A while ago I had a situation where my AR9485 would lock up the >>> kernel >>> so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. >>> Sorry I >>> forgot his last name) were very patient in helping me and trying to >>> debug it through patches, etc. Nothing worked. >>> Eventually, though, I noticed that when I removed the atl1c module >>> my >>> wlan started working. "Awesome!" I thought... Until I noticed this >>> other >>> problem. >>> >>> Once in a while, seemingly at random, the wlan dies with the error >>> messages in the title. And I can't possibly restore it without >>> restarting the computer. >>> >>> With this message I have attached a log with the error messages. >>> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm >>> currently running 3.2.8. >>> For some reason it happened at least 3-4 times shortly after each >>> other >>> today - so I thought I might ask on here what's happening. >> Please try this patch with powersave enabled, using a recent >> compat-wireless build (3.3 or linux-next based): >> http://nbd.name/ps-fix.patch >> >> - Felix >> _______________________________________________ >> ath9k-devel mailing list >> ath9k-devel at lists.ath9k.org >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > > Hi Felix > > I would like to try your patch to see if it stops my Tx DMA errors on > my AR9280 chipset pcie card. > > 1. Do you think it might work? > 2. What is the best way to apply this patch? > > Please be gentle with me as I am linux hobbyist and I am keen to get my > Tx DMA error problem sorted which I can recreate straight away every > time. If your Tx DMA issues are powersave related, this patch might help to fix them. - Felix ^ permalink raw reply [flat|nested] 37+ messages in thread
* [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 2012-03-07 19:42 ` Felix Fietkau @ 2012-03-07 19:55 ` Paul Farrow 0 siblings, 0 replies; 37+ messages in thread From: Paul Farrow @ 2012-03-07 19:55 UTC (permalink / raw) To: ath9k-devel On Wed, 07 Mar 2012 20:42:35 +0100, Felix Fietkau wrote: > On 2012-03-07 7:37 PM, Paul Farrow wrote: >> >> On Wed, 07 Mar 2012 18:29:56 +0100, Felix Fietkau wrote: >>> On 2012-02-29 10:35 PM, Kim Lidstr?m wrote: >>>> Hello! >>>> A while ago I had a situation where my AR9485 would lock up the >>>> kernel >>>> so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. >>>> Sorry I >>>> forgot his last name) were very patient in helping me and trying >>>> to >>>> debug it through patches, etc. Nothing worked. >>>> Eventually, though, I noticed that when I removed the atl1c module >>>> my >>>> wlan started working. "Awesome!" I thought... Until I noticed this >>>> other >>>> problem. >>>> >>>> Once in a while, seemingly at random, the wlan dies with the error >>>> messages in the title. And I can't possibly restore it without >>>> restarting the computer. >>>> >>>> With this message I have attached a log with the error messages. >>>> This has been a problem since.. Uhm.. Kernel 3.2.something and I'm >>>> currently running 3.2.8. >>>> For some reason it happened at least 3-4 times shortly after each >>>> other >>>> today - so I thought I might ask on here what's happening. >>> Please try this patch with powersave enabled, using a recent >>> compat-wireless build (3.3 or linux-next based): >>> http://nbd.name/ps-fix.patch >>> >>> - Felix >>> _______________________________________________ >>> ath9k-devel mailing list >>> ath9k-devel at lists.ath9k.org >>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> >> >> Hi Felix >> >> I would like to try your patch to see if it stops my Tx DMA errors >> on >> my AR9280 chipset pcie card. >> >> 1. Do you think it might work? >> 2. What is the best way to apply this patch? >> >> Please be gentle with me as I am linux hobbyist and I am keen to get >> my >> Tx DMA error problem sorted which I can recreate straight away every >> time. > If your Tx DMA issues are powersave related, this patch might help to > fix them. > > - Felix At this stage I am unsure what the problems are but I know that I can recreate the TX DMA issue straight away, every time. If I wanted to apply the patch how do I go about doing that successfully as I am unsure how to do that. Thanks Paul ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2012-03-07 19:55 UTC | newest] Thread overview: 37+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-02-29 21:35 [ath9k-devel] "Failed to stop Tx DMA" and "Could not stop RX" with AR9485 Kim Lidström 2012-02-29 21:35 ` Kim Lidström 2012-02-29 21:50 ` [ath9k-devel] " Adrian Chadd 2012-02-29 21:50 ` Adrian Chadd 2012-02-29 23:52 ` [ath9k-devel] " Adrian Chadd 2012-02-29 23:52 ` Adrian Chadd 2012-03-01 5:09 ` [ath9k-devel] " Mohammed Shafi 2012-03-01 5:09 ` Mohammed Shafi 2012-03-01 5:53 ` [ath9k-devel] " Kim Lidström 2012-03-01 5:53 ` Kim Lidström 2012-03-01 16:23 ` [ath9k-devel] " Mieszko Ślusarczyk 2012-03-02 6:21 ` Kim Lidström 2012-03-01 14:46 ` Peter Stuge 2012-03-01 15:04 ` Mohammed Shafi 2012-03-01 17:50 ` Ben Greear 2012-03-01 18:01 ` Peter Stuge 2012-03-01 19:05 ` Sune Mølgaard 2012-03-01 17:02 ` Adrian Chadd 2012-03-01 17:23 ` Peter Stuge 2012-03-01 17:22 ` Felix Fietkau 2012-03-01 17:53 ` Peter Stuge 2012-03-01 18:13 ` Felix Fietkau 2012-03-01 18:42 ` Peter Stuge 2012-03-01 18:51 ` Peter Stuge 2012-03-01 19:18 ` Felix Fietkau 2012-03-01 19:53 ` Peter Stuge 2012-03-01 20:26 ` Adrian Chadd 2012-03-01 20:40 ` Felix Fietkau 2012-03-01 21:27 ` Peter Stuge 2012-03-02 0:38 ` Sujith Manoharan 2012-03-02 2:21 ` Peter Stuge 2012-03-07 17:29 ` Felix Fietkau 2012-03-07 17:29 ` Felix Fietkau 2012-03-07 18:35 ` Paul Farrow 2012-03-07 18:37 ` Paul Farrow 2012-03-07 19:42 ` Felix Fietkau 2012-03-07 19:55 ` Paul Farrow
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.