So I've gone back to the drawing board, and reviewed this issue as thoroughly as I can. The issue is PCI reads/writes can overlap with each other (not just writes). This shouldn't generally be an issue but if some reads take a while, for example, there could be another read/write on its way on another CPU and at least for our PCI 11n devices that will make them angry. Some PCI hosts don't seem to do this but some others do. It should be noted this issue is not present on our pre-802.11n devices or our new 11n PCI-express devices.
So with clarified, here's a second attempt at serialization. The first patch wasn't doing anything because we never initialized ah->config.serialize_regmode. We do that now only on non-UP systems. The last patch in the series is perhaps overkill -- but it would deal with rare case of a UP system coming up and you hotplugging a second CPU later. It may also help with suspend, but don't quote me on that yet. Anyway, here's the latest stab at it: http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2009-02-11/serialization-v2.patch This applies against today's wireless-testing/compat-wireless updates. Please test and let me know if ath9k with PCI devices on HT/Multi-CPU issues are corrected by it. Known issue: ping flood in a terminal makes it painful to come back. I've been trying to look for a more neater way to guarantee serialization but so far this is what I have. I do wonder, for example, if some of the atomic.h (atomic_inc_and_test()) stuff may let us use it to somehow serialize CPU entry into a read/write. Although its not designed for it may be worth considering. I also some of the most evil code I've seen lately on drivers/pci/quirks.c and did wonder if there was a fix we can re-use through there but didn't see anything. If you know have any other ideas please let me know. Luis _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
