Hi Sujith,
Any update on this problem?
I tried it on .31-rc9 (using ubuntu's ubuntu-karmic.git - which is
rebased to -rc9) again, and the problem still exists.
As I mentioned earlier, the driver absolutely drops the WLAN
connection when subjected to network IO (apparently, anything 10MiB
cannot
On Wednesday 19 Aug 2009 9:21:13 am Sujith wrote:
Kunal Gangakhedkar wrote:
Any way we can help debug this issue?
It gets really annoying when the driver goes berserk in the middle of a
big file transfer - even on LAN. :(
rmmod'ing and modprobe'ing the driver again seems to get it
On Tue, 2009-08-18 at 23:46 +0530, Kunal Gangakhedkar wrote:
Note that Michael noticed the performance degradation. That's another
target for bisection, whether it's related or not.
Any way we can help debug this issue?
It gets really annoying when the driver goes berserk in the middle of
On Tue, 2009-08-18 at 14:07 -0700, Luis R. Rodriguez wrote:
On Tue, Aug 18, 2009 at 2:04 PM, Pavel Roskinpro...@gnu.org wrote:
On Tue, 2009-08-18 at 23:46 +0530, Kunal Gangakhedkar wrote:
Note that Michael noticed the performance degradation. That's another
target for bisection, whether
On Tue, 2009-08-18 at 14:24 -0700, Luis R. Rodriguez wrote:
Anyway, why is it better for bisecting?
Because to help developers not have to do:
git branch -m poo
git checkout -b master origin/master
# Then apply patches manually
Instead of the better rebasing:
git branch -m
Kunal Gangakhedkar wrote:
Any way we can help debug this issue?
It gets really annoying when the driver goes berserk in the middle of a big
file transfer - even on LAN. :(
rmmod'ing and modprobe'ing the driver again seems to get it working; but, as
the network load increases, the driver
Seems to be happening with AR9285 in my HP laptop as well.
I was about to write a msg to this list with the same performance issues when
I saw this thread.
Kunal
On Thursday 13 Aug 2009 10:51:54 am Sujith wrote:
Pavel Roskin wrote:
sync_cause is always 0x2000 when that message is printed,
On Thu, 2009-08-13 at 09:24 +0530, Sujith wrote:
The commit which exposed this message was:
ath9k: Change DEBUG level for certain interrupt
Yes, I found that already.
This error message was suppressed all these days.
Not sure as to why this is being generated in such large numbers.
Still
On Thu, 2009-08-13 at 10:51 +0530, Sujith wrote:
Pavel Roskin wrote:
sync_cause is always 0x2000 when that message is printed, so there are
no other causes.
SYNC_LOCAL_TIMEOUT is generated when the PCIe core hangs, unable to complete
a DMA transfer. I am able to see this with 9280, 9281
