From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luis R. Rodriguez Date: Thu, 5 Feb 2009 13:34:36 -0800 Subject: [ath9k-devel] [RFC] Serialization of writes In-Reply-To: <200902052147.24856.listsrv@wilsoft.nl> References: <20090204011216.GA8220@tesla> <200902051928.11887.listsrv@wilsoft.nl> <43e72e890902051142od651cday75c87467f600ebbc@mail.gmail.com> <200902052147.24856.listsrv@wilsoft.nl> Message-ID: <20090205213436.GC12298@tesla> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On Thu, Feb 05, 2009 at 12:47:24PM -0800, W. van den Akker wrote: > On Thursday 05 February 2009 20:42:55 Luis R. Rodriguez wrote: > > On Thu, Feb 5, 2009 at 10:28 AM, W. van den Akker > wrote: > > > On Thursday 05 February 2009, W. van den Akker wrote: > > >> > On Wed, Feb 4, 2009 at 2:43 PM, Chris Kennedy wrote: > > >> >> On Feb 4, 2009, at 4:06 PM, Luis R. Rodriguez wrote: > > >> >>> On Wed, Feb 04, 2009 at 01:02:06PM -0800, Chris Kennedy wrote: > > >> >>>> On Feb 4, 2009, at 2:49 PM, W. van den Akker wrote: > > >> >>>>> On Wednesday 04 February 2009, W. van den Akker wrote: > > >> >>>>>> On Wednesday 04 February 2009, Luis R. Rodriguez wrote: > > >> >>>>>>> On Tue, Feb 3, 2009 at 5:12 PM, Luis R. Rodriguez > > >> >>>>>>> > > >> >>>>>>> wrote: > > >> >>>>>>>> Some devices requires serialization of writes, this is required > > >> >>>>>>>> for AR5416 and AR9280 PCI devices. This was not implemented in > > >> >>>>>>>> ath9k > > >> >>>>>>>> though. Here's an attempt, but I have no way of testing this as > > >> >>>>>>>> I haven't had issues with my systems or cards. I am not sure if > > >> >>>>>>>> this > > >> >>>>>>>> should fix some of the current issues being reported but it may > > >> >>>>>>>> help. > > >> >>>>>>>> > > >> >>>>>>>> Those who have issues on SMP systems with hostapd locking up -- > > >> >>>>>>>> please give this a whirl, let me know if it helps. > > >> >>>>>>>> > > >> >>>>>>>> This has 3 patches in 1 file, the one that counts it the third > > >> >>>>>>>> one > > >> >>>>>>>> but just apply it all together, 'patch -p1 serialize.patch' ( > > >> >>>>>>>> for compat-wireless users or testers) or 'git am > > >> >>>>>>>> serialize.patch' for git users. > > >> >>>>>>>> > > >> >>>>>>>> Feedback on results is appreciated. > > >> >>>>>>>> > > >> >>>>>>>> http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ > > >> >>>>>>>> ath9k/tmp/ > > >> >>>>>>>> se rialize.patch > > >> >>>>>>> > > >> >>>>>>> On second thought, this should be pretty useless since because > > >> >>>>>>> we have > > >> >>>>>>> only one tasklet and tasklets are not re-entrant on different > > >> >>>>>>> CPUs. > > >> >>>>>>> Hm,,, > > >> >>>>>> > > >> >>>>>> I will test this and will report back.. > > >> >>>>> > > >> >>>>> I have updated the git and applied the patch. But hostapd cannot > > >> >>>>> start the > > >> >>>>> adapter to work: > > >> >>>>> > > >> >>>>> xxx:/home/xx# hostapd -dd /etc/hostapd/hostapd.conf > > >> >>>>> Configuration file: /etc/hostapd/hostapd.conf > > >> >>>>> ctrl_interface_group=0 > > >> >>>>> Opening raw packet socket for ifindex 1688 > > >> >>>>> BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits) > > >> >>>>> Failed to set country code > > >> >>>>> wlan0: Unable to setup interface. > > >> >>>>> rmdir[ctrl_interface]: No such file or directory > > >> >>>>> > > >> >>>>> I am using hostapd 0.6.7. > > >> >>>> > > >> >>>> I'm not sure why this happened on my system, because i have > > >> >>>> two duplicated identical systems and one works without the > > >> >>>> patch without needing this. The one doing the same thing as > > >> >>>> yours I just put a card in though so I was thinking maybe it was > > >> >>>> something I did, but if yours is doing it too then that's odd. > > >> >>>> On mine, for the time being till I figure it out, I get it to work > > >> >>>> by doing the following (which is odd because I'm basically > > >> >>>> jump-starting udev, but udev should be working and does the second > > >> >>>> reg set)... > > >> >>>> > > >> >>>> export COUNTRY=CO > > >> >>>> /sbin/crda > > >> >>>> hostapd -dd /etc/hostapd/hostapd.conf > > >> >>>> > > >> >>>> For some reason I just have to run crda manually (I have udev > > >> >>>> script setup in proper place), > > >> >>> > > >> >>> I've now have heard a few issues with crda udev stuff. > > >> >>> Please test the udev rule by writing a bash script for your > > >> >>> /sbin/crda with something like this: > > >> >>> > > >> >>> #!/bin/bash > > >> >>> LOG=/tmp/crda.log > > >> >>> echo $(date) >> $LOG > > >> >>> echo $COUNTRY >> $LOG > > >> >>> echo ------ >> $LOG > > >> >>> /sbin/crda > > >> >>> > > >> >>> Please keep in mind the old crda used to put the udev rule into > > >> >>> /etc/udev/rules.d/regulatory.rules -- this can be removed and the > > >> >>> new place is /lib/udev/rules.d/85-regulatory.rules > > >> >>> > > >> >>> Note that restarting udev is not required as udev has an inotify for > > >> >>> the daemon on the directories IIRC. > > >> >> > > >> >> Oddly when I removed script from /etc/udev/rules.d and modified the / > > >> >> lib/udev/ one nothing was in /tmp/, but when > > >> >> putting the new script in the /etc/udev/rules.d/ then I got the /tmp/ > > >> >> log thingy working. > > >> >> Also I was able to have it actually work right, seems to have done it > > >> >> properly now, > > >> >> only thing different would be that I remove/replaced that udev rule > > >> >> file in /etc/udev/ and have it > > >> >> doing the log now in that script now. > > >> >> > > >> >> Here's the log, seems correct, all I can think is that during bootup > > >> >> it isn't doing > > >> >> this properly. did possibly moving the script away/back make udev see > > >> >> it now? > > >> >> How is /lib/udev/ exactly working, doesn't seem to be used by my > > >> >> system, that > > >> >> script is sitting in there all alone :), and doesn't seem to play > > >> >> ball with the udev system (version 124). > > >> >> > > >> >> > > >> >> ----- > > >> >> Wed Feb 4 16:21:26 CST 2009 > > >> >> 00 > > >> >> ----- > > >> >> Wed Feb 4 16:21:26 CST 2009 > > >> >> CO > > >> >> ----- > > >> >> Wed Feb 4 16:21:49 CST 2009 > > >> >> US > > >> >> ----- > > >> >> > > >> >> > > >> >> Also this explains why I've had to manually put the udev rules into / > > >> >> etc/udev/rules.d/, > > >> >> and didnt' realize it was putting one into /lib/udevl/rules.d, yet > > >> >> that just doesn't work > > >> >> on my system at all (newest Gentoo, everything up to date). Not sure > > >> >> why one system > > >> >> boots up fine and does this, always has, and other system I just put > > >> >> a card into didn't > > >> >> on bootup but now does when I went through unloading ath9k, mac80211, > > >> >> cfg80211 and > > >> >> reloading ath9k and running hostapd, now everything went smooth as > > >> >> the log shows. > > >> >> > > >> >> So definitely I'm confused now, can't just reboot this system till > > >> >> later tonight to see if it all reboots > > >> >> correctly now, but I'm suspecting it will since the mod load worked > > >> >> like it should, that log of > > >> >> my bootup does seem like it may load the driver pretty early, not > > >> >> sure if that could be a problem. > > >> > > > >> > Something with the udev rule location may be fishy -- the reason I > > >> > started putting it into /lib/udev/ was the big fat warning on debian > > >> > systems on the README on /etc/udev/rules.d/ and /lib/udev/rules.d. > > >> > According to it packages should not put rules into /etc/udev/rules.d > > >> > and it seems /lib/udev/rules.d/ is the common place. I verified this > > >> > at least on FC10, Debian and Ubuntu. > > >> > > >> First I have to make crda running on my system. It isnt installed on > > >> debian. > > >> > > >> Will report back.... > > > > > > I try to run the CRDA\Udev stuff. I installed the rules in > > > the /lib/udev/rules.d directory. Then running crda (also after booting) > > > > > > then I 'export COUNTRY=NL' > > > > > > but running the script above from Luis I get: > > > Thu Feb 5 19:24:12 CET 2009 > > > NL > > > ---- > > > Failed to set regulatory domain: -22 > > > > > > Also moving the script to the /etc/udev/rules.d makes no differences. > > > > > > By the way, its a Debian system. > > > > What kernel do you have? > > > > Luis > > perhaps an issue to mention. > The kernel option CONFIG_WIRELESS_OLD_REGULATORY is set to 'y' That's fine, this just means the kernel is built with a static "US" regulatory domain and it default to it by default. But driver regulatory hints will still be listened to.. Luis