[ath9k-devel] [RFC] Serialization of writes

[Luis R. Rodriguez <lrodriguez@atheros.com>]

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 <listsrv@wilsoft.nl>
> wrote:
> > > On Thursday 05 February 2009, W. van den Akker wrote:
> > >> > On Wed, Feb 4, 2009 at 2:43 PM, Chris Kennedy <ivtv@groovy.org> 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
> > >> >>>>>>>
> > >> >>>>>>> <lrodriguez@atheros.com> 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