Hi Pavel, > The log seems to show that you are very short on memory. The backtraces > come from "page allocation failure", not from any conditions in the > ath9k driver. You have a lot of free swap, so I assume it's the > non-swappable memory. This is also evidenced by lowmem_reserve: > > lowmem_reserve[]: 0 0 0 0 > > I haven't heard of any major memory leaks in ath9k, so I would not blame > it on the driver unless you can show that you don't get that problem > with another driver. This is a very strange issue indeed. I had 2GB of RAM on the laptop at that moment (now they are 1.5GB) and was running nothing else. Hence, a memory leak seems more than likely in this situation. I didn't think to check the amount of free memory during the problems, but I'll certainly give it a shot. I am not experiencing this problem with b43 or with the proprietary Broadcom driver and my bcm based adapter. The only time I've seen it is with ath9k, both the karmic koala one and the cutting edge one. Can you please give me some hints as to tests I can do for you, or debugging I can enable so I can give you more useful information? The stall during large transfers is 100% reproducible. It would be wonderful if I can show you more debug info and shed some light on the situation. > > In the future, please send kernel logs produced by the dmesg command. > This will avoid the timestamps from syslogd (especially since you > already have kernel timestamps) and it would ensure that no kernel > messages are skipped by syslogd because of their low urgency. I had already lost the dmesg output due to a reboot. But in the future, I'll make sure to grab the info before rebooting. I will follow up with more results. Cheers, Iordan -- The conscious mind has only one thread of execution. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
