[ath9k-devel] [RFC] Serialization of writes

[ath9k-devel] [RFC] Serialization of writes

[Luis R. Rodriguez]

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/serialize.patch

  Luis

[ath9k-devel] [RFC] Serialization of writes

[Luis R. Rodriguez]

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/serialize.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,,,

  Luis

[ath9k-devel] [RFC] Serialization of writes

[Chris Kennedy]

On Feb 3, 2009, at 10:47 PM, 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/serialize.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,,,


So the PCIe chip/cards (AR5418) are not prone to this serial write  
problem?
That would be interesting, I have one (a D-Link DWA-556) and put it  
into my SMP
system tonight testing this patch (my AR5416 is busy unfortunately in  
a non PCIe system).
Well it seems the SMP system is running quite stable with the AR5418,  
and it was doing
hard lockups like the others with SMP see with the AR5416 I have.   
Not sure exactly
what that shows, but figure it's an interesting tidbit of  
information, and I'm happy now
because that's the system I really wanted to have the wireless AP on  
initially.  I'll report
back if it isn't so stable long term, and I'm sticking to G mode too  
because in N mode
the PCIe card doesn't do well with outgoing traffic (same as my PCI  
card, great incoming
slow outgoing in N mode) but it weirdly
does the G clients (when in N mode) normal speed (15-20 Mbit/s, both  
input/output).  I'm not sure why,
maybe the PCIe card is different enough, or a fluke, but it's the  
same software versions
and config files on both systems.  I'm wondering if this PCIe card  
really doesn't lock up
SMP systems, and it's not picky about serial writes, does that say  
it's a serial write problem
or is there possibly even more difference between the two chip  
versions and something
else could be wrong (but seems to point out that locking possibly  
isn't the issue, since both
I would guess are generally treated the same with the general locking  
in the driver).  I didn't
realize there was that much difference in the two chips, but guessing  
there must be.

Thanks,
Chris

>
>   Luis
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [RFC] Serialization of writes

[W. van den Akker]

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..

gr,
Willem

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[ath9k-devel] [RFC] Serialization of writes

[W. van den Akker]

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.

Greetings,
Willem

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[ath9k-devel] [RFC] Serialization of writes

[Chris Kennedy]

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),
again two perfectly identically setup systems but one I didn't apply
the patch (non-SMP).  So I figured I messed something up, not sure
how the spinlock in the patch would prevent udev from running right for
the first reg domain set but not effect anything else, and then let
hostapd set it (because I have US set in hostapd.conf as the reg domain
and it calls it fine then).

Log attached with debug level set to show what mine is doing....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log3.gz
Type: application/x-gzip
Size: 6266 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090204/f0d3ef2e/attachment-0001.bin 
-------------- next part --------------


Thanks,
Chris

>
> Greetings,
> Willem
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] [RFC] Serialization of writes

[Luis R. Rodriguez]

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.

  Luis

[ath9k-devel] [RFC] Serialization of writes

[Chris Kennedy]

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.

Thanks,
Chris


>
>   Luis

[ath9k-devel] [RFC] Serialization of writes

[Luis R. Rodriguez]

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.

  Luis

[ath9k-devel] [RFC] Serialization of writes

[W. van den Akker]

> 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....



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[ath9k-devel] [RFC] Serialization of writes

[W. van den Akker]

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.

Thanks, 
Willem

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[ath9k-devel] [RFC] Serialization of writes

[Luis R. Rodriguez]

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

[ath9k-devel] [RFC] Serialization of writes

[W. van den Akker]

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

I use the latest wireless git with the SMP patch applied. So it is 2.6.29-rc3

gr,
Willem

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[ath9k-devel] [RFC] Serialization of writes

[Luis R. Rodriguez]

On Thu, Feb 05, 2009 at 12:44:51PM -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'

You shouldn't be setting this, CRDA will set it to what it should be,
the kernel will reject any country it doesn't expect. The example I gave
was to print it out to see if the udev script was being picked up.

  Luis

[ath9k-devel] [RFC] Serialization of writes

[W. van den Akker]

On Thursday 05 February 2009 22:33:32 Luis R. Rodriguez wrote:
> On Thu, Feb 05, 2009 at 12:44:51PM -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/patche
> > > >> >>>>>>>>s/ 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'
>
> You shouldn't be setting this, CRDA will set it to what it should be,
> the kernel will reject any country it doesn't expect. The example I gave
> was to print it out to see if the udev script was being picked up.
>
>   Luis

Whatever I have filled in (hostapd.conf entry country_code set or default)
is giving the same result. The 'NL' option is recognized. I browsed the code
of crda and the check for the country code is ok.

Also udevadm monitor doesnt give any feedback on user-events. 
I woud assume if I use crda or start hostapd it would give some kind of 
output..

gr,
Willem


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[ath9k-devel] [RFC] Serialization of writes

[Luis R. Rodriguez]

On Thu, Feb 05, 2009 at 01:44:15PM -0800, W. van den Akker wrote:
> Whatever I have filled in (hostapd.conf entry country_code set or default)
> is giving the same result. The 'NL' option is recognized. I browsed the code
> of crda and the check for the country code is ok.
> 
> Also udevadm monitor doesnt give any feedback on user-events.

Do you mean when you do this?

udevadm monitor --environment kernel

> I woud assume if I use crda or start hostapd it would give some kind of
> output..

Yeah you can also just use this to test this:

iw reg set NL

Mind, you if you already set NL it will just return 0
as that was already set, so you may want to try some other
country and then switch back to another one to run these
tests.

  Luis

[ath9k-devel] [RFC] Serialization of writes

[W. van den Akker]

On Thursday 05 February 2009 23:13:09 Luis R. Rodriguez wrote:
> On Thu, Feb 05, 2009 at 01:44:15PM -0800, W. van den Akker wrote:
> > Whatever I have filled in (hostapd.conf entry country_code set or
> > default) is giving the same result. The 'NL' option is recognized. I
> > browsed the code of crda and the check for the country code is ok.
> >
> > Also udevadm monitor doesnt give any feedback on user-events.
>
> Do you mean when you do this?
>
> udevadm monitor --environment kernel
>
> > I woud assume if I use crda or start hostapd it would give some kind of
> > output..
>
> Yeah you can also just use this to test this:
>
> iw reg set NL
>
> Mind, you if you already set NL it will just return 0
> as that was already set, so you may want to try some other
> country and then switch back to another one to run these
> tests.
>
>   Luis

ok using iw reg set NL give the following output:

UEVENT[1233872197.595448] change   /devices/platform/regulatory.0 (platform)
ACTION=change
DEVPATH=/devices/platform/regulatory.0
SUBSYSTEM=platform
COUNTRY=NL
PHYSDEVBUS=platform
MODALIAS=platform:regulatory
SEQNUM=1245

UDEV  [1233872197.599832] change   /devices/platform/regulatory.0 (platform)
UDEV_LOG=3
ACTION=change
DEVPATH=/devices/platform/regulatory.0
SUBSYSTEM=platform
COUNTRY=NL
PHYSDEVBUS=platform
MODALIAS=platform:regulatory
SEQNUM=1245
UDEVD_EVENT=1

So this looks promissing... doesnt it?
It shows the UDEV rules are correctly installed..

Question is why hostapd wont start the adapter into an AP.
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

gr,
Willem


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[ath9k-devel] [RFC] Serialization of writes

[W. van den Akker]

On Thursday 05 February 2009, W. van den Akker wrote:
> On Thursday 05 February 2009 23:13:09 Luis R. Rodriguez wrote:
> > On Thu, Feb 05, 2009 at 01:44:15PM -0800, W. van den Akker wrote:
> > > Whatever I have filled in (hostapd.conf entry country_code set or
> > > default) is giving the same result. The 'NL' option is recognized. I
> > > browsed the code of crda and the check for the country code is ok.
> > >
> > > Also udevadm monitor doesnt give any feedback on user-events.
> >
> > Do you mean when you do this?
> >
> > udevadm monitor --environment kernel
> >
> > > I woud assume if I use crda or start hostapd it would give some kind of
> > > output..
> >
> > Yeah you can also just use this to test this:
> >
> > iw reg set NL
> >
> > Mind, you if you already set NL it will just return 0
> > as that was already set, so you may want to try some other
> > country and then switch back to another one to run these
> > tests.
> >
> >   Luis
>
> ok using iw reg set NL give the following output:
>
> UEVENT[1233872197.595448] change   /devices/platform/regulatory.0
> (platform) ACTION=change
> DEVPATH=/devices/platform/regulatory.0
> SUBSYSTEM=platform
> COUNTRY=NL
> PHYSDEVBUS=platform
> MODALIAS=platform:regulatory
> SEQNUM=1245
>
> UDEV  [1233872197.599832] change   /devices/platform/regulatory.0
> (platform) UDEV_LOG=3
> ACTION=change
> DEVPATH=/devices/platform/regulatory.0
> SUBSYSTEM=platform
> COUNTRY=NL
> PHYSDEVBUS=platform
> MODALIAS=platform:regulatory
> SEQNUM=1245
> UDEVD_EVENT=1
>
> So this looks promissing... doesnt it?
> It shows the UDEV rules are correctly installed..
>
> Question is why hostapd wont start the adapter into an AP.
> 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
>
> gr,
> Willem

When I run hostapd -dd /etc/hostapd/hostapd.con, I get
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

the udevadm monitor --environment kernel gives for the command above:

UDEV the event which udev sends out after rule processing
UEVENT the kernel uevent

UEVENT[1234014277.977997] add      /class/net/mon.wlan0 (net)
ACTION=add
DEVPATH=/class/net/mon.wlan0
SUBSYSTEM=net
PHYSDEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:03:02.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=ath9k
INTERFACE=mon.wlan0
IFINDEX=11
SEQNUM=1253

UDEV  [1234014277.991195] add      /class/net/mon.wlan0 (net)
UDEV_LOG=3
ACTION=add
DEVPATH=/class/net/mon.wlan0
SUBSYSTEM=net
PHYSDEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:03:02.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=ath9k
INTERFACE=mon.wlan0
IFINDEX=11
SEQNUM=1253
UDEVD_EVENT=1

UEVENT[1234014278.022651] remove   /class/net/mon.wlan0 (net)
ACTION=remove
DEVPATH=/class/net/mon.wlan0
SUBSYSTEM=net
PHYSDEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:03:02.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=ath9k
INTERFACE=mon.wlan0
IFINDEX=11
SEQNUM=1254

UDEV  [1234014278.029097] remove   /class/net/mon.wlan0 (net)
UDEV_LOG=3
ACTION=remove
DEVPATH=/class/net/mon.wlan0
SUBSYSTEM=net
PHYSDEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:03:02.0
PHYSDEVBUS=pci
PHYSDEVDRIVER=ath9k
INTERFACE=mon.wlan0
IFINDEX=11
SEQNUM=1254
UDEVD_EVENT=1

Also  if I do a 'iw reg set NL', I get
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [HEADER] 16 octets
    .nlmsg_len = 36
    .nlmsg_type = 2 <ERROR>
    .nlmsg_flags = 0 <>
    .nlmsg_seq = 1234014506
    .nlmsg_pid = 6291
  [ERRORMSG] 20 octets
    .error = -11 "Resource temporarily unavailable"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .nlmsg_type = 20 <0x14>
    .nlmsg_flags = 5 <REQUEST,ACK>
    .nlmsg_seq = 1234014506
    .nlmsg_pid = 6291
---------------------------  END NETLINK MESSAGE   ---------------------------
command failed: Resource temporarily unavailable (-11)

No output in udevadm....

This was working in 2.9.29-rc2-wl but is broken in 2.9.29-rc3-wl


gr,
Willem

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[ath9k-devel] [RFC] Serialization of writes

[W. van den Akker]

On Saturday 07 February 2009, W. van den Akker wrote:
> On Thursday 05 February 2009, W. van den Akker wrote:
> > On Thursday 05 February 2009 23:13:09 Luis R. Rodriguez wrote:
> > > On Thu, Feb 05, 2009 at 01:44:15PM -0800, W. van den Akker wrote:
> > > > Whatever I have filled in (hostapd.conf entry country_code set or
> > > > default) is giving the same result. The 'NL' option is recognized. I
> > > > browsed the code of crda and the check for the country code is ok.
> > > >
> > > > Also udevadm monitor doesnt give any feedback on user-events.
> > >
> > > Do you mean when you do this?
> > >
> > > udevadm monitor --environment kernel
> > >
> > > > I woud assume if I use crda or start hostapd it would give some kind
> > > > of output..
> > >
> > > Yeah you can also just use this to test this:
> > >
> > > iw reg set NL
> > >
> > > Mind, you if you already set NL it will just return 0
> > > as that was already set, so you may want to try some other
> > > country and then switch back to another one to run these
> > > tests.
> > >
> > >   Luis
> >
> > ok using iw reg set NL give the following output:
> >
> > UEVENT[1233872197.595448] change   /devices/platform/regulatory.0
> > (platform) ACTION=change
> > DEVPATH=/devices/platform/regulatory.0
> > SUBSYSTEM=platform
> > COUNTRY=NL
> > PHYSDEVBUS=platform
> > MODALIAS=platform:regulatory
> > SEQNUM=1245
> >
> > UDEV  [1233872197.599832] change   /devices/platform/regulatory.0
> > (platform) UDEV_LOG=3
> > ACTION=change
> > DEVPATH=/devices/platform/regulatory.0
> > SUBSYSTEM=platform
> > COUNTRY=NL
> > PHYSDEVBUS=platform
> > MODALIAS=platform:regulatory
> > SEQNUM=1245
> > UDEVD_EVENT=1
> >
> > So this looks promissing... doesnt it?
> > It shows the UDEV rules are correctly installed..
> >
> > Question is why hostapd wont start the adapter into an AP.
> > 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
> >
> > gr,
> > Willem
>
> When I run hostapd -dd /etc/hostapd/hostapd.con, I get
> 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
>
> the udevadm monitor --environment kernel gives for the command above:
>
> UDEV the event which udev sends out after rule processing
> UEVENT the kernel uevent
>
> UEVENT[1234014277.977997] add      /class/net/mon.wlan0 (net)
> ACTION=add
> DEVPATH=/class/net/mon.wlan0
> SUBSYSTEM=net
> PHYSDEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:03:02.0
> PHYSDEVBUS=pci
> PHYSDEVDRIVER=ath9k
> INTERFACE=mon.wlan0
> IFINDEX=11
> SEQNUM=1253
>
> UDEV  [1234014277.991195] add      /class/net/mon.wlan0 (net)
> UDEV_LOG=3
> ACTION=add
> DEVPATH=/class/net/mon.wlan0
> SUBSYSTEM=net
> PHYSDEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:03:02.0
> PHYSDEVBUS=pci
> PHYSDEVDRIVER=ath9k
> INTERFACE=mon.wlan0
> IFINDEX=11
> SEQNUM=1253
> UDEVD_EVENT=1
>
> UEVENT[1234014278.022651] remove   /class/net/mon.wlan0 (net)
> ACTION=remove
> DEVPATH=/class/net/mon.wlan0
> SUBSYSTEM=net
> PHYSDEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:03:02.0
> PHYSDEVBUS=pci
> PHYSDEVDRIVER=ath9k
> INTERFACE=mon.wlan0
> IFINDEX=11
> SEQNUM=1254
>
> UDEV  [1234014278.029097] remove   /class/net/mon.wlan0 (net)
> UDEV_LOG=3
> ACTION=remove
> DEVPATH=/class/net/mon.wlan0
> SUBSYSTEM=net
> PHYSDEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:03:02.0
> PHYSDEVBUS=pci
> PHYSDEVDRIVER=ath9k
> INTERFACE=mon.wlan0
> IFINDEX=11
> SEQNUM=1254
> UDEVD_EVENT=1
>
> Also  if I do a 'iw reg set NL', I get
> -- Debug: Received Message:
> --------------------------   BEGIN NETLINK MESSAGE
> --------------------------- [HEADER] 16 octets
>     .nlmsg_len = 36
>     .nlmsg_type = 2 <ERROR>
>     .nlmsg_flags = 0 <>
>     .nlmsg_seq = 1234014506
>     .nlmsg_pid = 6291
>   [ERRORMSG] 20 octets
>     .error = -11 "Resource temporarily unavailable"
>   [ORIGINAL MESSAGE] 16 octets
>     .nlmsg_len = 16
>     .nlmsg_type = 20 <0x14>
>     .nlmsg_flags = 5 <REQUEST,ACK>
>     .nlmsg_seq = 1234014506
>     .nlmsg_pid = 6291
> ---------------------------  END NETLINK MESSAGE  
> --------------------------- command failed: Resource temporarily
> unavailable (-11)
>
> No output in udevadm....
>
> This was working in 2.9.29-rc2-wl but is broken in 2.9.29-rc3-wl
>
>

To test the seralization patch I have applied it to the 2.6.29-rc3 kernel 
release. It didnt make any differences. The system hangs within minutes after
a reboot. So the patch didnt work.

I couldnt test with he 2.6.29-rc3-wl kernel becuause of the problems mentioned 
in the quoted text abouve. Kernel 2.6.29-rc3 didnt have such problems.

If more information needed I would gladly give them.

gr,
Willem

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[ath9k-devel] [RFC] Serialization of writes

[Luis R. Rodriguez]

On Sun, Feb 8, 2009 at 9:18 AM, W. van den Akker <listsrv@wilsoft.nl> wrote:

>
> To test the seralization patch I have applied it to the 2.6.29-rc3 kernel
> release. It didnt make any differences. The system hangs within minutes after
> a reboot. So the patch didnt work.

Thanks for testing, will have to re-think serialization requirements
(unless that is not your specific issue). Essentially this was an
attempt to port what our driver does in windows for serialization. The
way its handled there is the write is serialized by calling the write
to a register through NdisMSynchronizeWithInterrupt(). I just checked
ndiswrapper code and if their port work is correct it seems a
spin_lock_irqsave() is the right port for ath9k except ndiswrapper
holds the lock per interrupt which means ndiswrapper may actually
allow other CPUs to write while another has its writes going (which I
am not sure if it is correct). Anyway if someone is truly familiar
with NdisMSynchronizeWithInterrupt() please let me know, I'll have to
do some more digging to ensure we do it correctly. Keep in mind
mac80211 callbacks and timers.

> I couldnt test with he 2.6.29-rc3-wl kernel becuause of the problems mentioned
> in the quoted text abouve. Kernel 2.6.29-rc3 didnt have such problems.
>
> If more information needed I would gladly give them.

Yes, I wan to try to reproduce your issues, please compile ath9k with
debugging enabled [1] and when loading ath9k enable
ATH_DBG_REGULATORY. Please post your log of that:

sudo rmmod ath9k mac80211 cfg80211
sudo dmesg -c > /dev/null
sudo modprobe ath9k debug=0x00000080

Please use the latest code from wireless-testing so if you had issues
with hostapd on SMP please boot with only one CPU enabled.

What version of udev and hal (freedesktop.org HAL) do you have?

Please also post your hostapd.conf.

[1] http://linuxwireless.org/en/users/Drivers/ath9k#Enablingdebug

  Luis

[ath9k-devel] [RFC] Serialization of writes

[W. van den Akker]

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'

gr,
Willem

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[ath9k-devel] [RFC] Serialization of writes

[Luis R. Rodriguez]

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