From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mihai Moldovan Date: Wed, 01 Jun 2011 16:31:39 +0200 Subject: [ath9k-devel] AR9380 + hostapd + HT over 802.11a In-Reply-To: <4DE5E3B2.3000109@ionic.de> References: <4DE52724.2040300@ionic.de> <4DE52E1E.90903@candelatech.com> <4DE5338C.507@ionic.de> <4DE5345F.3060709@candelatech.com> <4DE535A1.7030108@ionic.de> <4DE54359.6060309@ionic.de> <4DE545FF.1090506@candelatech.com> <4DE548D4.60300@ionic.de> <4DE5E3B2.3000109@ionic.de> Message-ID: <4DE64D4B.3060406@ionic.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org Ok, some more information. Kernel: 2.6.38.6 I first thought of a race condition, as the cfg80211 subsystem tries to get an updated world entry of the regdb pretty early. However, at that time udev was already started: [ 14.319904] udev: starting version 151 [ 14.319960] udevd (2041): /proc/2041/oom_adj is deprecated, please use /proc/2041/oom_score_adj instead. [ 14.613461] md2: unknown partition table [ 14.617229] cfg80211: Calling CRDA to update world regulatory domain [ 14.645768] e1000e: Intel(R) PRO/1000 Network Driver - 1.2.20-k2 [ 14.645771] e1000e: Copyright(c) 1999 - 2011 Intel Corporation. ... Interestingly, cfg80211 wants to update the world regdom right before loading another network interface module (e1000e), which is a wired interface. Could this cause problems? This call obviously never returns, as regdomain changes afterwards are all queued but will never be acted upon: [ 18.262657] cfg80211: Pending regulatory request, waiting for it to be processed... (and several other of those messages) In order to see whether udev gets a regulatory change event, I enabled udevadm monitoring and came to this conclusion: KERNEL[1306936946.968633] add /module/cfg80211 (module) UDEV_LOG=3 ACTION=add DEVPATH=/module/cfg80211 SUBSYSTEM=module SEQNUM=2849 KERNEL[1306936946.968645] add /class/ieee80211 (class) UDEV_LOG=3 ACTION=add DEVPATH=/class/ieee80211 SUBSYSTEM=class SEQNUM=2850 KERNEL[1306936946.968711] add /devices/platform/regulatory.0 (platform) UDEV_LOG=3 ACTION=add DEVPATH=/devices/platform/regulatory.0 SUBSYSTEM=platform MODALIAS=platform:regulatory SEQNUM=2851 KERNEL[1306936946.968750] change /devices/platform/regulatory.0 (platform) UDEV_LOG=3 ACTION=change DEVPATH=/devices/platform/regulatory.0 SUBSYSTEM=platform COUNTRY=00 MODALIAS=platform:regulatory SEQNUM=2852 UDEV [1306936946.968830] add /module/cfg80211 (module) UDEV_LOG=3 STARTUP=1 ACTION=add DEVPATH=/module/cfg80211 SUBSYSTEM=module SEQNUM=2849 UDEV [1306936946.968902] add /class/ieee80211 (class) UDEV_LOG=3 STARTUP=1 ACTION=add DEVPATH=/class/ieee80211 SUBSYSTEM=class SEQNUM=2850 UDEV [1306936946.969934] add /devices/platform/regulatory.0 (platform) UDEV_LOG=3 STARTUP=1 ACTION=add DEVPATH=/devices/platform/regulatory.0 SUBSYSTEM=platform MODALIAS=platform:regulatory SEQNUM=2851 So, yep, udev is getting the change requests (two actually, as both ath9k cards are added to the system.) The rule should work fine too: KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/crda" Nothing broken here. One last thing I'll try is removing one ath9k card to see whether it works with one card only. Maybe ath9k or cfg80211 is broken here when using multiple cards at the same time. Other than that, I'm out of ideas. As far as I know, Luis is good with this CRDA stuff, so I'll CC him, just to make sure I'm not missing anything. I tried crda versions 1.0.1, 1.1.1 and git, though the behavior was the same throughout all versions. Posting results with one card only soon. Best regards and thanks, Mihai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6111 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20110601/ad7e5d68/attachment.bin