"Calling CRDA to update world regulatory domain" - WTH??

Completely Clueless · 11-26-2013, 05:27 PM

Well, the link provide by rokytnji did answer a few questions, for which many thanks. However, it doesn't appear at first sight to solve my problem, so I have little alternative at this stage but to use the expedient of re-writing the script to allow for these constant interruptions. The idea was originally to grab the date and power off as quickly as possible, but now I plan to give it several minutes online and make repeated attempts to grab the date; if any of them are successful then they'll be compared to see if they're the due day to open the lock. This should stand a much better chance of succeeding than the former one-shot approach. Not an ideal solution by any means, but a necessary patch to apply until such time as the core of the problem can be ascertained and addressed.

Completely Clueless · 11-26-2013, 05:39 PM

On second thoughts, I'll purchase a separate hardware clock for the Pi thereby bypassing the wireless problem altogether!

Trevud0 · 11-24-2014, 09:54 PM

Quote:

Originally Posted by Completely Clueless

For some 7 months now I've had a Raspberry Pi running Raspbian acting as an embedded controller for a time release lock. The system is contained on a 4Gb SD card which has the little tab in the 'locked' position so it can't get written to or corrupted (in theory at any rate). Everything was running sweet as a nut until about a week ago when I couldn't get the lock to open.
This system relies on getting the time/date from the network via a wi-fi connection, but on examination of the problem, it seems some sort of subroutine has unaccountably started interfering with the bash script I wrote to perform the timing function and is constantly interrupting it. Here's an example of what I'm seeing on a screen when this happens:

Code:

[ 338.519037] cfg80211: Calling CRDA to update world regulatory domain
[ 338.523266] cfg80211: World regulatory domain updated:
[ 338.523269] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 338.523272] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 338.523276] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300
mBi, 2000 mBm)
[ 338.523279] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300
mBi, 2000 mBm)
[ 338.523281] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 338.523284] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 340.948738] wlan1: authenticate with 00:1d:a2:d8:7e:70 (try 1)
[ 340.950479] wlan1: authenticated
[ 340.950707] wlan1: associate with 00:1d:a2:d8:7e:70 (try 1)
[ 340.953611] wlan1: RX ReassocResp from 00:1d:a2:d8:7e:70 (capab=0x401
status=0 aidy)
[ 340.953614] wlan1: associated
[ 458.646604] wlan1: deauthenticated from 00:1d:a2:d8:7e:70 (Reason: 2)

...and so on. It actually goes on for page after page.

So anyway, I re-imaged the SD card from a backup and the same problem is happening, so it's obviously something extraneous that's changed rather than any corruption or virus on the card.
Anyone know what this problem is caused by and how I can get rid of it?
TIA,
CC

I use Slackware 14 64 bit, and upgrade to kernel 3.17 last stable solves this problem.

Trevud0 · 11-24-2014, 11:34 PM

Quote:

Originally Posted by Completely Clueless

For some 7 months now I've had a Raspberry Pi running Raspbian acting as an embedded controller for a time release lock. The system is contained on a 4Gb SD card which has the little tab in the 'locked' position so it can't get written to or corrupted (in theory at any rate). Everything was running sweet as a nut until about a week ago when I couldn't get the lock to open.
This system relies on getting the time/date from the network via a wi-fi connection, but on examination of the problem, it seems some sort of subroutine has unaccountably started interfering with the bash script I wrote to perform the timing function and is constantly interrupting it. Here's an example of what I'm seeing on a screen when this happens:

Code:

[ 338.519037] cfg80211: Calling CRDA to update world regulatory domain
[ 338.523266] cfg80211: World regulatory domain updated:
[ 338.523269] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 338.523272] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 338.523276] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300
mBi, 2000 mBm)
[ 338.523279] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300
mBi, 2000 mBm)
[ 338.523281] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 338.523284] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 340.948738] wlan1: authenticate with 00:1d:a2:d8:7e:70 (try 1)
[ 340.950479] wlan1: authenticated
[ 340.950707] wlan1: associate with 00:1d:a2:d8:7e:70 (try 1)
[ 340.953611] wlan1: RX ReassocResp from 00:1d:a2:d8:7e:70 (capab=0x401
status=0 aidy)
[ 340.953614] wlan1: associated
[ 458.646604] wlan1: deauthenticated from 00:1d:a2:d8:7e:70 (Reason: 2)

...and so on. It actually goes on for page after page.

So anyway, I re-imaged the SD card from a backup and the same problem is happening, so it's obviously something extraneous that's changed rather than any corruption or virus on the card.
Anyone know what this problem is caused by and how I can get rid of it?
TIA,
CC

update to kernel 3.17 (last stable) solves the problem for the ath9k driver.