Hi!
I am using a kind-of "linux from scratch" (i.e. Crux 3.0, 64 bits Intel,
kernel 3.10.32) and I am stuck with a EBUSY error return from the
wireless driver I suspect it comes from the driver behavior since it is
consistent either from the command
iw dev wlan1 set channel 2
or the comand
iwconfig wlan1 set channel 2
(it occurred also with "iw" with a kernel where the iwconfig support
emulation is off -- CONFIG_CFG82011_WEXT). The EBUSY error return occurs
as early as immediately after the initial module install, and
consistently thereafter. The wireless scanning works (reporting a nearby
beacon on channel 1).
I understand this list is not for user/integrator support but since I
control many variables in the troubleshooting exercise, some of you
might be interested in finding more about a possible bug.
Here is a sequence of commands immediately after system boot:
+ uname -a
Linux a-host 3.10.32 #2 SMP Wed Mar 5 00:39:47 UTC 2014 x86_64 Intel(R)
Atom(TM) CPU D2550 @ 1.86GHz GenuineIntel GNU/Linux
+ dmesg | grep -i wifi -C 4 -n
853-[ 2.468354] gma500 0000:00:02.0: trying to get vblank count for
disabled pipe 1
854-[ 2.556398] usb 5-2: new low-speed USB device number 2 using uhci_hcd
855-[ 2.685093] rtl8192ce:_rtl92ce_read_chip_version():<0-0> Chip
Version ID: B_CUT_88C
856-[ 2.693197] fbcon: psbdrmfb (fb0) is primary device
857:[ 2.697204] rtl8192ce: Using firmware rtlwifi/rtl8192cfwU_B.bin
858-[ 2.700363] modprobe (109) used greatest stack depth: 3928 bytes left
859-[ 2.700499] usb 5-2: skipped 1 descriptor after interface
860-[ 2.700506] usb 5-2: skipped 1 descriptor after interface
861-[ 2.705486] usb 5-2: default language 0x0409
--
889-[ 3.149779] gma500 0000:00:02.0: fb0: psbdrmfb frame buffer device
890-[ 3.149784] gma500 0000:00:02.0: registered panic notifier
891-[ 3.149870] [drm] Initialized gma500 1.0.0 2011-06-06 for
0000:00:02.0 on minor 0
892-[ 3.403646] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
893:[ 3.404050] rtlwifi: wireless switch is on
894-[ 5.579389] Adding 16777212k swap on /dev/sda6. Priority:42
extents:1 across:16777212k
895-[ 5.595963] Adding 16777212k swap on /dev/sda7. Priority:52
extents:1 across:16777212k
896-[ 5.611337] Adding 16777212k swap on /dev/sda8. Priority:62
extents:1 across:16777212k
897-[ 5.699807] rm (146) used greatest stack depth: 3032 bytes left
+ lsmod
Module Size Used by
rtl8192ce 72128 0
gma500_gfx 147187 1
rtlwifi 106604 1 rtl8192ce
rtl8192c_common 54252 1 rtl8192ce
drm_kms_helper 27871 1 gma500_gfx
+ iwconfig
eth0 no wireless extensions.
lo no wireless extensions.
sit0 no wireless extensions.
wlan1 IEEE 802.11bgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Encryption key:off
Power Management:on
+ iw dev wlan1 info
Interface wlan1
ifindex 4
wdev 0x1
addr 64:5a:04:aa:f8:16
type managed
wiphy 0
**** Here is the first occurrence of the blocking error condition:
+ iw dev wlan1 set channel 2
command failed: Device or resource busy (-16)
**** Next error is expected:
+ iw dev wlan1 scan
command failed: Network is down (-100)
+ ip link set up wlan1
+ iw dev wlan1 scan
BSS d8:6c:e9:29:e5:75(on wlan1)
TSF: 1305304974530 usec (15d, 02:35:04)
freq: 2412
... bla bla bla
* Device name: RalinkAPS
* Config methods: Label, PBC
* RF Bands: 0x1
+ iwlist wlan1 scanning
wlan1 Scan completed :
Cell 01 - Address: D8:6C:E9:29:E5:75
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=70/70 Signal level=-4 dBm
... bla bla bla
IE: Unknown: 0706434120010B10
**** Here is another instance of the blocking error condition (occurs
with iw as well):
+ iwconfig wlan1 channel 2
Error for wireless request "Set Frequency" (8B04) :
SET failed on device wlan1 ; Device or resource busy.
**** Some user of a widespread distribution reported a similar problem
and a work-around with the "iw ... interface add .." command, which I
attempt here:
+ ip link set down wlan1
+ iw dev wlan1 interface add wlan2 type managed
**** note that I don't care that the name wlan2 turns into rename5
because it did not occur without CONFIG_CFG82011_WEXT which is useless
besides the present troubleshooting:
+ iwconfig
eth0 no wireless extensions.
lo no wireless extensions.
sit0 no wireless extensions.
wlan1 IEEE 802.11bgn ESSID:off/any
Mode:Managed Frequency:2.417 GHz Access Point:
Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Encryption key:off
Power Management:off
rename5 IEEE 802.11bgn ESSID:off/any
Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
Retry long limit:7 RTS thr=2347 B Fragment thr:off
Encryption key:off
Power Management:on
**** Too bad it occurs again:
+ iw dev rename5 set channel 2
command failed: Device or resource busy (-16)
==============
Final remarks:
I went through the firmware load learning curve for a Linux
user/integrator and I am confident that the following sha1sum'ed file
has been loaded:
c81ec289a236875ab7139c0e357fdcddcc21cc46
/lib/firmware/rtlwifi/rtl8192cfwU_B.bin
(the fact that scanning works supports my confidence)
I investigated the iw source code (version 3.11, but the above is with
version 3.14) and I gave up once I traced the reported error condition
to the call to nl_recvmsgs in the iw.c source file.
I grep'ed EBUSY in the C source files in the drivers/net/rtlwifi
sub-directories and find none. I suppose some other component in the
driver detects the error condition.
If I recall correctly, the command "iw ... interface add ..." followed
by "iw ... del" for the source interface allowed me to set the channel
without the EBUSY outcome once (and the sticky EBUSY came again vey
soon) with the kernel devoid of CONFIG_CFG82011_WEXT. It makes seldom
sense to me to pursue this elusive workaround, but this could be a sign
that a fresh kernel "interface" data structure turns EBUSY-sick after
some action occurring in the driver initialization logic.
The system is a Shuttle XS36VL box
(http://us.shuttle.com/barebone/Models/XS36VL.html). It does not have a
physical wireless switch (a dmesg line above reports the switch position
as "on").
Any suggestion about a next step in troubleshooting? Maybe trying the
latest kernel release candidate?
Thanks for your attention.
-- Thierry Moreau
On 03/05/2014 12:36 AM, Thierry Moreau wrote:
> Hi!
>
> I am using a kind-of "linux from scratch" (i.e. Crux 3.0, 64 bits Intel, kernel
> 3.10.32) and I am stuck with a EBUSY error return from the wireless driver I
> suspect it comes from the driver behavior since it is consistent either from the
> command
>
> iw dev wlan1 set channel 2
>
> or the comand
>
> iwconfig wlan1 set channel 2
>
> (it occurred also with "iw" with a kernel where the iwconfig support emulation
> is off -- CONFIG_CFG82011_WEXT). The EBUSY error return occurs as early as
> immediately after the initial module install, and consistently thereafter. The
> wireless scanning works (reporting a nearby beacon on channel 1).
>
> I understand this list is not for user/integrator support but since I control
> many variables in the troubleshooting exercise, some of you might be interested
> in finding more about a possible bug.
>
> Here is a sequence of commands immediately after system boot:
>
> + uname -a
> Linux a-host 3.10.32 #2 SMP Wed Mar 5 00:39:47 UTC 2014 x86_64 Intel(R) Atom(TM)
> CPU D2550 @ 1.86GHz GenuineIntel GNU/Linux
>
> + dmesg | grep -i wifi -C 4 -n
> 853-[ 2.468354] gma500 0000:00:02.0: trying to get vblank count for disabled
> pipe 1
> 854-[ 2.556398] usb 5-2: new low-speed USB device number 2 using uhci_hcd
> 855-[ 2.685093] rtl8192ce:_rtl92ce_read_chip_version():<0-0> Chip Version ID:
> B_CUT_88C
> 856-[ 2.693197] fbcon: psbdrmfb (fb0) is primary device
> 857:[ 2.697204] rtl8192ce: Using firmware rtlwifi/rtl8192cfwU_B.bin
> 858-[ 2.700363] modprobe (109) used greatest stack depth: 3928 bytes left
> 859-[ 2.700499] usb 5-2: skipped 1 descriptor after interface
> 860-[ 2.700506] usb 5-2: skipped 1 descriptor after interface
> 861-[ 2.705486] usb 5-2: default language 0x0409
> --
> 889-[ 3.149779] gma500 0000:00:02.0: fb0: psbdrmfb frame buffer device
> 890-[ 3.149784] gma500 0000:00:02.0: registered panic notifier
> 891-[ 3.149870] [drm] Initialized gma500 1.0.0 2011-06-06 for 0000:00:02.0 on
> minor 0
> 892-[ 3.403646] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
> 893:[ 3.404050] rtlwifi: wireless switch is on
> 894-[ 5.579389] Adding 16777212k swap on /dev/sda6. Priority:42 extents:1
> across:16777212k
> 895-[ 5.595963] Adding 16777212k swap on /dev/sda7. Priority:52 extents:1
> across:16777212k
> 896-[ 5.611337] Adding 16777212k swap on /dev/sda8. Priority:62 extents:1
> across:16777212k
> 897-[ 5.699807] rm (146) used greatest stack depth: 3032 bytes left
>
> + lsmod
> Module Size Used by
> rtl8192ce 72128 0
> gma500_gfx 147187 1
> rtlwifi 106604 1 rtl8192ce
> rtl8192c_common 54252 1 rtl8192ce
> drm_kms_helper 27871 1 gma500_gfx
>
> + iwconfig
> eth0 no wireless extensions.
>
> lo no wireless extensions.
>
> sit0 no wireless extensions.
>
> wlan1 IEEE 802.11bgn ESSID:off/any
> Mode:Managed Access Point: Not-Associated Tx-Power=0 dBm
> Retry long limit:7 RTS thr=2347 B Fragment thr:off
> Encryption key:off
> Power Management:on
>
>
> + iw dev wlan1 info
> Interface wlan1
> ifindex 4
> wdev 0x1
> addr 64:5a:04:aa:f8:16
> type managed
> wiphy 0
>
> **** Here is the first occurrence of the blocking error condition:
>
> + iw dev wlan1 set channel 2
> command failed: Device or resource busy (-16)
>
> **** Next error is expected:
>
> + iw dev wlan1 scan
> command failed: Network is down (-100)
>
> + ip link set up wlan1
>
> + iw dev wlan1 scan
> BSS d8:6c:e9:29:e5:75(on wlan1)
> TSF: 1305304974530 usec (15d, 02:35:04)
> freq: 2412
> ... bla bla bla
> * Device name: RalinkAPS
> * Config methods: Label, PBC
> * RF Bands: 0x1
>
> + iwlist wlan1 scanning
> wlan1 Scan completed :
> Cell 01 - Address: D8:6C:E9:29:E5:75
> Channel:1
> Frequency:2.412 GHz (Channel 1)
> Quality=70/70 Signal level=-4 dBm
> ... bla bla bla
> IE: Unknown: 0706434120010B10
>
>
> **** Here is another instance of the blocking error condition (occurs with iw as
> well):
>
> + iwconfig wlan1 channel 2
> Error for wireless request "Set Frequency" (8B04) :
> SET failed on device wlan1 ; Device or resource busy.
>
> **** Some user of a widespread distribution reported a similar problem and a
> work-around with the "iw ... interface add .." command, which I attempt here:
>
> + ip link set down wlan1
>
> + iw dev wlan1 interface add wlan2 type managed
>
> **** note that I don't care that the name wlan2 turns into rename5 because it
> did not occur without CONFIG_CFG82011_WEXT which is useless besides the present
> troubleshooting:
>
> + iwconfig
> eth0 no wireless extensions.
>
> lo no wireless extensions.
>
> sit0 no wireless extensions.
>
> wlan1 IEEE 802.11bgn ESSID:off/any
> Mode:Managed Frequency:2.417 GHz Access Point: Not-Associated
> Tx-Power=20 dBm
> Retry long limit:7 RTS thr=2347 B Fragment thr:off
> Encryption key:off
> Power Management:off
>
> rename5 IEEE 802.11bgn ESSID:off/any
> Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
> Retry long limit:7 RTS thr=2347 B Fragment thr:off
> Encryption key:off
> Power Management:on
>
> **** Too bad it occurs again:
>
> + iw dev rename5 set channel 2
> command failed: Device or resource busy (-16)
>
>
> ==============
>
> Final remarks:
>
> I went through the firmware load learning curve for a Linux user/integrator and
> I am confident that the following sha1sum'ed file has been loaded:
> c81ec289a236875ab7139c0e357fdcddcc21cc46 /lib/firmware/rtlwifi/rtl8192cfwU_B.bin
> (the fact that scanning works supports my confidence)
>
> I investigated the iw source code (version 3.11, but the above is with version
> 3.14) and I gave up once I traced the reported error condition to the call to
> nl_recvmsgs in the iw.c source file.
>
> I grep'ed EBUSY in the C source files in the drivers/net/rtlwifi sub-directories
> and find none. I suppose some other component in the driver detects the error
> condition.
>
> If I recall correctly, the command "iw ... interface add ..." followed by "iw
> ... del" for the source interface allowed me to set the channel without the
> EBUSY outcome once (and the sticky EBUSY came again vey soon) with the kernel
> devoid of CONFIG_CFG82011_WEXT. It makes seldom sense to me to pursue this
> elusive workaround, but this could be a sign that a fresh kernel "interface"
> data structure turns EBUSY-sick after some action occurring in the driver
> initialization logic.
>
> The system is a Shuttle XS36VL box
> (http://us.shuttle.com/barebone/Models/XS36VL.html). It does not have a physical
> wireless switch (a dmesg line above reports the switch position as "on").
>
> Any suggestion about a next step in troubleshooting? Maybe trying the latest
> kernel release candidate?
I use NetworkManager and I never see errors like this.
You definitely should use either a newer kernel or the backports sources. There
is a recent change that fixes a problem in rtl8192ce that caused interrupts to
be disabled for a long time. That fix is in the mainline 3.14-rc5 and in the
wireless-testing repo. It is in the process of being applied to the various
stable kernels, but it is probably not there yet.
If you just want to try that patch, it is available at
https://lkml.org/lkml/2014/2/1/15.
Larry
On 03/05/14 07:12, Larry Finger wrote:
> On 03/05/2014 12:36 AM, Thierry Moreau wrote:
>> Hi!
>>
>> I am using a kind-of "linux from scratch" (i.e. Crux 3.0, 64 bits
>> Intel, kernel
>> 3.10.32) and I am stuck with a EBUSY error return from the wireless
>> driver I
>> suspect it comes from the driver behavior since it is consistent
>> either from the
>> command
>>
>> iw dev wlan1 set channel 2
>>
>> or the comand
>>
>> iwconfig wlan1 set channel 2
>>
>> (it occurred also with "iw" with a kernel where the iwconfig support
>> emulation
>> is off -- CONFIG_CFG82011_WEXT). The EBUSY error return occurs as
>> early as
>> immediately after the initial module install, and consistently
>> thereafter. The
>> wireless scanning works (reporting a nearby beacon on channel 1).
>> [ ... ... ]
>>
>> Any suggestion about a next step in troubleshooting? Maybe trying the
>> latest
>> kernel release candidate?
>
> I use NetworkManager and I never see errors like this.
>
> You definitely should use either a newer kernel or the backports
> sources. There is a recent change that fixes a problem in rtl8192ce that
> caused interrupts to be disabled for a long time. That fix is in the
> mainline 3.14-rc5 and in the wireless-testing repo. It is in the process
> of being applied to the various stable kernels, but it is probably not
> there yet.
>
> If you just want to try that patch, it is available at
> https://lkml.org/lkml/2014/2/1/15.
>
Thanks for your reply Larry. I had seen the interrupt latency fix
(latest release candidate) but since my problem occurs earlier than any
wifi protocol activity, I abstained from upgrading.
Anyway since you suggested it, I moved to 3.14.0-rc5 and the problem
occurs exactly as reported earlier (the dmesg indeed reports a different
module load and init sequence).
From your suggestions, I should try with tools other than iw and
iwconfig. I thought the higher level wireless management tools would use
the same kernel api.
Any other suggestion?
P.S. Yes, the "ip link set up wlan1" command was given. The EBUSY return
applies equally before and after this command.
Regards,
-- Thierry Moreau
On Wednesday 05 March 2014 06:36:50 Thierry Moreau wrote:
> I am using a kind-of "linux from scratch" (i.e. Crux 3.0, 64 bits
> Intel, kernel 3.10.32) and I am stuck with a EBUSY error return from
> the wireless driver I suspect it comes from the driver behavior since
> it is consistent either from the command
>
> iw dev wlan1 set channel 2
>
> or the comand
>
> iwconfig wlan1 set channel 2
>
> (it occurred also with "iw" with a kernel where the iwconfig support
> emulation is off -- CONFIG_CFG82011_WEXT). The EBUSY error return
> occurs as early as immediately after the initial module install, and
> consistently thereafter. The wireless scanning works (reporting a
> nearby beacon on channel 1).
It was not entirely clear for me, but have you enabled the interface
before changing the channel? I.e.
ip link set wlan0 up
iw dev wlan0 set channel 2
I suggest to try 3.13 or even 3.14(-rcish). Earlier kernels (3.10 being
the worst) had an issue[1] that impacted wireless stability.
> The system is a Shuttle XS36VL box
> (http://us.shuttle.com/barebone/Models/XS36VL.html). It does not have
> a physical wireless switch (a dmesg line above reports the switch
> position as "on").
The same box is operating in my neighbourhood (networking was not
required for its purpose). Good luck with getting multi-head working.
This box is running 3.14-rc2-something now with patches to get monitor
mode to function properly.
Kind regards,
Peter
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=60713
On 03/05/14 16:40, Larry Finger wrote:
>
> Please give me the exact set of commands you use to get this problem. If
> possible, capture the console output. As I am currently running
> long-term tests of the latest version of rtl8192ce using an RTL8188CE
> (10ec:8176), it will be a perfect time to test.
>
Here is the command script, and the console log
(....sh 2>&1 | tee ....log)
Is it possible that the Shuttle system be arranged with a digital output
enabling/inhibiting the Realtek wifi interface active participation in
wifi protocol?
I did ask Shuttle tech support, but in any event I don't want to induce
you to troubleshoot a specific system.
Thanks,
-- Thierry Moreau
On Thu, 2014-03-06 at 09:57 -0600, Larry Finger wrote:
> On 03/05/2014 01:16 PM, Thierry Moreau wrote:
> > On 03/05/14 16:40, Larry Finger wrote:
> >>
> >> Please give me the exact set of commands you use to get this problem. If
> >> possible, capture the console output. As I am currently running
> >> long-term tests of the latest version of rtl8192ce using an RTL8188CE
> >> (10ec:8176), it will be a perfect time to test.
> >>
> >
> > Here is the command script, and the console log
> > (....sh 2>&1 | tee ....log)
> >
> > Is it possible that the Shuttle system be arranged with a digital output
> > enabling/inhibiting the Realtek wifi interface active participation in wifi
> > protocol?
> >
> > I did ask Shuttle tech support, but in any event I don't want to induce you to
> > troubleshoot a specific system.
>
> The problem is not specific to the Shuttle - I can reproduce it on my HP laptop.
> Furthermore, it affects other mac80211-based drivers. The EBUSY return comes out
> of mac80211/cfg80211/nl80211 code.
I deleted the earlier bits of this thread after skimming it, but IIRC
we're talking about scanning here right? If there's already a scan
in-progress, then the stack can often return EBUSY.
For example, from both cfg80211_wext_siwscan() and
nl80211_trigger_scan(), used by 'iwlist' and 'iw' respectively:
if (rdev->scan_req) {
err = -EBUSY;
goto out;
}
Scans do not get canceled just because another random scan request comes
in. Whatever userspace there is needs to wait for a scan completion
event and then request it's new scan. There are also stack internal
scans that happen from time to time that may cause a user-requested scan
to return EBUSY.
(NM hands this all off to wpa_supplicant, which itself handles the EBUSY
by waiting a bit and then requesting another scan.)
Dan
On Wednesday 05 March 2014 19:16:08 Thierry Moreau wrote:
> On 03/05/14 16:40, Larry Finger wrote:
> > Please give me the exact set of commands you use to get this problem. If
> > possible, capture the console output. As I am currently running
> > long-term tests of the latest version of rtl8192ce using an RTL8188CE
> > (10ec:8176), it will be a perfect time to test.
>
> Here is the command script, and the console log
> (....sh 2>&1 | tee ....log)
Instead of cat, I used single-second sleeps as can be seen in the attached
script. Our logs are roughly the same (I have replaced the last three bytes of
the MAC address by XX for privacy). The rtlwifi module is patched[1], hence
the out-of-tree marking.
What is the problem that you are experiencing? I am able to connect although
it took half a minute for the first ICMP ping packets to pass (and then there
is still a lot of packet loss). This pattern is observable on the past 2.5
weeks that I have been running ping tests (ping every second to the gateway).
> Is it possible that the Shuttle system be arranged with a digital output
> enabling/inhibiting the Realtek wifi interface active participation in
> wifi protocol?
I didn't understand the first part, are you referring to a possible mistake in
attaching the antennas? When I opened up the case, I saw two antennas that
were properly secured to the card.
Regards,
Peter
[1]: http://lkml.org/lkml/2014/2/14/430
On 03/05/2014 01:16 PM, Thierry Moreau wrote:
> On 03/05/14 16:40, Larry Finger wrote:
>>
>> Please give me the exact set of commands you use to get this problem. If
>> possible, capture the console output. As I am currently running
>> long-term tests of the latest version of rtl8192ce using an RTL8188CE
>> (10ec:8176), it will be a perfect time to test.
>>
>
> Here is the command script, and the console log
> (....sh 2>&1 | tee ....log)
>
> Is it possible that the Shuttle system be arranged with a digital output
> enabling/inhibiting the Realtek wifi interface active participation in wifi
> protocol?
>
> I did ask Shuttle tech support, but in any event I don't want to induce you to
> troubleshoot a specific system.
The problem is not specific to the Shuttle - I can reproduce it on my HP laptop.
Furthermore, it affects other mac80211-based drivers. The EBUSY return comes out
of mac80211/cfg80211/nl80211 code.
I have no idea why that particular set of commands fails to be able to set the
channel. Both NetworkManager and the openSUSE ifup sequence work OK. Your system
can set channels using the scan mechanism.
If you want to track it down, you will need to put printk statements at every
place that the net/wireless code sets EBUSY to see which one triggers. Perhaps
that will expose any bug there, or in your script.
Larry
On 03/06/14 14:54, Peter Wu wrote:
> On Wednesday 05 March 2014 19:16:08 Thierry Moreau wrote:
>> On 03/05/14 16:40, Larry Finger wrote:
>>> Please give me the exact set of commands you use to get this problem. If
>>> possible, capture the console output. As I am currently running
>>> long-term tests of the latest version of rtl8192ce using an RTL8188CE
>>> (10ec:8176), it will be a perfect time to test.
>>
>> Here is the command script, and the console log
>> (....sh 2>&1 | tee ....log)
>
> Instead of cat, I used single-second sleeps as can be seen in the attached
> script. Our logs are roughly the same (I have replaced the last three bytes of
> the MAC address by XX for privacy). The rtlwifi module is patched[1], hence
> the out-of-tree marking.
>
> What is the problem that you are experiencing?
>
Indeed a good question! Likely there is no problem. Likely a
misunderstanding from my part of the wifi logic.
I was going step by step in my integration and I (wrongly?) assumed that
the command to set a channel in the wifi configuration was a requirement
for my next step: scanning done on an older wifi system detected signals
from multiple channels but the newer system scanning saw only channel 1,
hence I assumed that the newer scanning scheme needed channel changes by
the user space logic.
Now a number of clues (including your log below -- thanks) point towards
the inconsequential-ness of the EBUSY result in the specific command I
was using as a milestone.
Other clues: a) suggestion by Larry to try other tools, and b) an EBUSY
return code in net/wireless/chan.c .
Somewhere else I might learn how scanning on multiple channels can work,
but I no longer care for my deployment priorities.
> I am able to connect although
> it took half a minute for the first ICMP ping packets to pass (and then there
> is still a lot of packet loss). This pattern is observable on the past 2.5
> weeks that I have been running ping tests (ping every second to the gateway).
>
>> Is it possible that the Shuttle system be arranged with a digital output
>> enabling/inhibiting the Realtek wifi interface active participation in
>> wifi protocol?
>
> I didn't understand the first part, are you referring to a possible mistake in
> attaching the antennas? When I opened up the case, I saw two antennas that
> were properly secured to the card.
>
Please ignore this other hypothesis.
Thanks a lot to Larry and Peter. If you don't ear from me, please assume
that I successfully installed hostapd and I am an happy rtlwifi user
with the kernel 3.14.
-- Thierry Moreau
On 03/05/2014 10:27 AM, Thierry Moreau wrote:
> On 03/05/14 07:12, Larry Finger wrote:
>> On 03/05/2014 12:36 AM, Thierry Moreau wrote:
>>> Hi!
>>>
>>> I am using a kind-of "linux from scratch" (i.e. Crux 3.0, 64 bits
>>> Intel, kernel
>>> 3.10.32) and I am stuck with a EBUSY error return from the wireless
>>> driver I
>>> suspect it comes from the driver behavior since it is consistent
>>> either from the
>>> command
>>>
>>> iw dev wlan1 set channel 2
>>>
>>> or the comand
>>>
>>> iwconfig wlan1 set channel 2
>>>
>>> (it occurred also with "iw" with a kernel where the iwconfig support
>>> emulation
>>> is off -- CONFIG_CFG82011_WEXT). The EBUSY error return occurs as
>>> early as
>>> immediately after the initial module install, and consistently
>>> thereafter. The
>>> wireless scanning works (reporting a nearby beacon on channel 1).
>
>>> [ ... ... ]
>
>>>
>>> Any suggestion about a next step in troubleshooting? Maybe trying the
>>> latest
>>> kernel release candidate?
>>
>> I use NetworkManager and I never see errors like this.
>>
>> You definitely should use either a newer kernel or the backports
>> sources. There is a recent change that fixes a problem in rtl8192ce that
>> caused interrupts to be disabled for a long time. That fix is in the
>> mainline 3.14-rc5 and in the wireless-testing repo. It is in the process
>> of being applied to the various stable kernels, but it is probably not
>> there yet.
>>
>> If you just want to try that patch, it is available at
>> https://lkml.org/lkml/2014/2/1/15.
>>
>
> Thanks for your reply Larry. I had seen the interrupt latency fix (latest
> release candidate) but since my problem occurs earlier than any wifi protocol
> activity, I abstained from upgrading.
>
> Anyway since you suggested it, I moved to 3.14.0-rc5 and the problem occurs
> exactly as reported earlier (the dmesg indeed reports a different module load
> and init sequence).
>
> From your suggestions, I should try with tools other than iw and iwconfig. I
> thought the higher level wireless management tools would use the same kernel api.
>
> Any other suggestion?
>
> P.S. Yes, the "ip link set up wlan1" command was given. The EBUSY return applies
> equally before and after this command.
Please give me the exact set of commands you use to get this problem. If
possible, capture the console output. As I am currently running long-term tests
of the latest version of rtl8192ce using an RTL8188CE (10ec:8176), it will be a
perfect time to test.
Larry