Bug 1190467 - Wireless/Bluetooth Ralink RT3290 does not work (hard block of device)
Summary: Wireless/Bluetooth Ralink RT3290 does not work (hard block of device)
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 23
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-08 10:24 UTC by schaefi
Modified: 2023-11-07 03:55 UTC (History)
16 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-07-29 06:00:12 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Output from dmesg (97.42 KB, text/plain)
2015-02-20 15:29 UTC, schaefi
no flags Details
output of dmidecode (14.72 KB, text/plain)
2015-02-20 15:30 UTC, schaefi
no flags Details
acpi.dump (357.50 KB, text/plain)
2015-03-16 20:29 UTC, schaefi
no flags Details

Description schaefi 2015-02-08 10:24:32 UTC
Description of problem:

The wireless network on my laptop HP Envy 6-1160ez with a Ralink RT3290 network controller does not work. In the menue/network settings the airplane mode is "on" and can not be switched to "off". Attempts to switch the wireless on using rfkill fail and the wireless is still shown as "hard blocked: yes". The problem seems to be known for various laptops (HP, Asus, etc.) and various linux distributions (fedora, ubuntu, archlinux) including numerous releases of the distributions.


Version-Release number of selected components:
Here is a little information on my system:

I run Fedora 21 under EFI-secure mode. In the BIOS/UEFI the following setting are applied:
UEFI: enabled
legacy support: disabled

uname -a
Linux hoelderlin 3.17.4-301.fc21.x86_64 #1 SMP Thu Nov 27 19:09:10 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

iwconfig
wlo1      IEEE 802.11bgn  ESSID:off/any
          Mode:Managed  Access Point: Not-Associated   Tx-Power=off
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
eno1      no wireless extensions.
lo        no wireless extensions.

lspci -v
...
01:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a)
        DeviceName: Realtek PCIe GBE Family Controller
        Subsystem: Hewlett-Packard Company Device 1896
        Flags: bus master, fast devsel, latency 0, IRQ 29
        I/O ports at 2000 [size=256]
        Memory at c0404000 (64-bit, prefetchable) [size=4K]
        Memory at c0400000 (64-bit, prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: r8169
        Kernel modules: r8169
02:00.0 Network controller: Ralink corp. RT3290 Wireless 802.11n 1T/1R PCIe
        DeviceName: Ralink RT3290LE 802.11bgn 1x1 Wi-Fi and Bluetooth 4.0 Combo Ada
        Subsystem: Hewlett-Packard Company Ralink RT3290LE 802.11bgn 1x1 Wi-Fi and Bluetooth 4.0 Combo Adapter
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at c0510000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: rt2800pci
        Kernel modules: rt2800pci
02:00.1 Bluetooth: Ralink corp. RT3290 Bluetooth
        Subsystem: Hewlett-Packard Company Ralink RT3290LE 802.11bgn 1x1 Wi-Fi and Bluetooth 4.0 Combo Adapter
        Flags: bus master, fast devsel, latency 0
        Memory at c0500000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>

rfkill list all
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: yes


Attempts to fix the problem

1. Fix by menu selection
Selecting in the gnome menu "settings" -> "network".
Then toggle the airplane mode from "on" to "off" does not work. The mode immediately switches back to "on"

2. Fix by rfkill
rfkill shows that the wireless is hard blocked. Run:
rfkill list all
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: yes
Then run:
rfkill unblock all
Unfortunately this does not fix the problem. The device still remains in the status "Hard blocked: yes"

3. Fix by nmcli
nmcli shows that the wireless is disabled. Run:
nmcli radio wifi
disabled
Then run:
nmcli radio wifi on
Unfortunately this also does not fix the probelm. The device  still remains in the status "disabled"

4. Fix by using the hardware button
My laptop does not have a specific hardware button to switch on wireless. There is a button "F12" which shows a wireless symbold and a red light. Unfortunaltey pressing "F12" or pressing "FN + F12" does not give any results.


Analysis Background:
The Ralink RT3290 seems to be a very common wireless hardware in laptops. It has been frequently used in HP-Laptops, Asus-Laptops and others. I first ran into this problem 2 years ago with Fedora 18 and ubuntu 12.10 and have been unable to fix the problem at that time. The bug also seems to be in numerous distributions like Fedora, ubuntu and archlinux. The bug still seems to be unsolved according to many reports and has not been reported to Fedora 21 yet. This bug report tries to summarize the status as of February 2014 and document the bug for Fedora 21. Here are some external references:
http://forums.fedoraforum.org/showthread.php?t=299388
http://askubuntu.com/questions/459436/ubuntu-14-04-ralink-rt-3290-wireless-lan-hard-blocked
http://askubuntu.com/questions/360589/problems-with-rt3290-card-running-using-rt2800-driver-on-ubuntu-13-04
https://bbs.archlinux.org/viewtopic.php?pid=1356895#p1356895


Workaround
A workaround that worked for me is the "suspend-trick".
Suspend your laptop by closing the lid and then re-open the laptop by opening the lid. The airplane mode is now switched to "off" and the wireless can be used without problems.


Further analysis:  
The workaround suggests that the bug is not a drive problem but a combination of driver and system control.

Please let me know if you need further information.
Please let me also know if you experience the same or similar problems. In this case please provide the hardware/software info as shown above. 
Thanks.

Comment 1 Peter Robinson 2015-02-10 17:01:40 UTC
kernel issue, not release

Comment 2 Stanislaw Gruszka 2015-02-20 10:34:02 UTC
Please do dmesg > dmesg.txt and dmidecode > dmidecode.txt and attach both .txt files.

Comment 3 schaefi 2015-02-20 15:29:04 UTC
Created attachment 993939 [details]
Output from dmesg

Comment 4 schaefi 2015-02-20 15:30:04 UTC
Created attachment 993941 [details]
output of dmidecode

Comment 5 schaefi 2015-02-20 15:39:33 UTC
(In reply to Stanislaw Gruszka from comment #2)
> Please do dmesg > dmesg.txt and dmidecode > dmidecode.txt and attach both
> .txt files.

Here your find the outputs of dmesg and dmidecode.

The outputs are taken shortly after this actions:
1. try (and fail) to un-set the airplane mode
2. Close the lid (with the laptop going to susend mode)
3. Re-open the lid (with the laptop waking up from suspend mode)
4. un-set the airplane mode and connect to the WLAN

I hope that helps. Please let me know if you need further info.

Comment 6 Stanislaw Gruszka 2015-02-23 12:56:44 UTC
I forgot to ask for ACPI tables, please also do acpidump > acpi.dump and attach acpi.dump file here.

Comment 7 jnikolak 2015-03-08 09:12:22 UTC
I had a similar issue which is now resolved. I ran some upgrades to install kde.
After a reboot I lost internet connection.

I was able to resolve this by downloading the dvd for rhe 7.1
Loading this iso as a repository, then ran yum update -y

In addition to this step, it would still not work.
So I blacklisted all wireless drivers that may have caused the conflict via:
vi /etc/modprobe.d/blacklist

blacklist rt2800pci
blacklist rt2800usb
blacklist rt2800lib

I did this because I was seeing RTLINK input/output errors

Then on console ran:
# modprobe rt2x00usb
# modprobe rt2x00lib
# modprobe rt2x00pci

After this its now working well and actually my connection is a little stronger.
However I didn't take a baseline to confirm.

Comment 8 schaefi 2015-03-15 22:36:33 UTC
(In reply to Stanislaw Gruszka from comment #6)
> I forgot to ask for ACPI tables, please also do acpidump > acpi.dump and
> attach acpi.dump file here.

Hi Stanislaw.

I have not installed acpidump. 
Please let me know if this answers your question or if I should install acpica-tools to provide the dump.

Comment 9 Stanislaw Gruszka 2015-03-16 10:28:24 UTC
Yes, please install acpica-tools and provide the dump.

Comment 10 schaefi 2015-03-16 20:29:12 UTC
Created attachment 1002498 [details]
acpi.dump

output of acpidump
(looks very cryptical to me ;-o  )

Comment 11 Fedora Kernel Team 2015-04-28 18:33:13 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs.

Fedora 21 has now been rebased to 3.19.5-200.fc21.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22.

If you experience different issues, please open a new bug report for those.

Comment 12 Stanislaw Gruszka 2015-04-29 09:08:41 UTC
After looking at provided dumps, I think the RFKILL switch should be supported by existing hp-wireless driver, it load because we can see those messages:

[   14.271470] Initializing HPQ6001 module
[   14.271575] input: HP Wireless hotkeys as /devices/virtual/input/input9

It should be possible to unblock the wireless, if it is not, perhaps switch is hard-blocked in BIOS ?

Comment 13 Fedora End Of Life 2015-11-04 11:12:02 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 14 Ganapathi Kamath 2015-12-01 09:00:47 UTC

[]# # below are two scripts bluetooth_start.sh and bluetooth_stop.sh, that make starting and stopping this driver easier, as a temporary workaround to get things working. The driver does not feel robust though.



[]# cat /etc/fedora-release 
Fedora release 23 (Twenty Three)

[]# uname -a
Linux localhost.localdomain 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[]# # created the following two scripts for starting/stopping drivers
# # The drivers are very flaky

[]# # (1) first download the 3.9.4.1 driver  https://github.com/f1u77y/rtbth-dkms-aur/archive/3.9.4.1.tar.gz
[]# # (2) gunzip, untar, make
[]# # (3) sign the driver using your key for UEFI (for instructions read elsewhere) rtbth.ko



[]# cat $SCRIPTDIR/bluetooth_start.sh
#!/usr/bin/bash

if [ $EUID -ne 0 ]
then
  echo "need root permissions"
  exit 1
fi
SCRIPTDIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
RTBTHDIR=${SCRIPTDIR}/../rtbth

#${SCRIPTDIR}/bluetooth_stop.sh
#echo "starting"

modprobe bluetooth 
# bluetooth also loads bnep, rfcomm
lsmod | grep rtbth >/dev/null || insmod ${RTBTHDIR}/rtbth.ko
systemctl start bluetooth.service
if [ ! -c /dev/rtbth ]
then
  mknod /dev/rtbth c 192 0 
fi
pgrep rtbt >/dev/null && ( nohup ${RTBTHDIR}/tools/rtbt >/tmp/rtbt.h 2>&1 & )



[]# cat $SCRIPTDIR/bluetooth_stop.sh
#!/usr/bin/bash

if [ $EUID -ne 0 ]
then
  echo "need root permissions"
  exit 1
fi

SCRIPTDIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
RTBTHDIR=${SCRIPTDIR}/../rtbth

pkill -f rtbt
systemctl stop bluetooth.service
systemctl stop bluetooth.service
lsmod | grep rtbth >/dev/null && rmmod rtbth
modprobe -r bnep
modprobe -r rfcomm
modprobe -r bluetooth



# lsmod | egrep -i "rtb|bne|blu"
bnep                   20480  2
rtbth                  81920  1
bluetooth             483328  36 bnep,rtbth,rfcomm
rfkill                 24576  7 cfg80211,hp_wmi,bluetooth


# pgrep -l "rtb|blu"
488 rtbth_us
497 bluetoothd
515 rtbt
2955 blueman-applet

Comment 15 schaefi 2016-07-29 06:00:12 UTC
Hi

I solved the problem:
https://bugzilla.redhat.com/show_bug.cgi?id=1359340

I went to the bios and reloaded the default values.
Now I can switch on and off the airplane mode.
Moreover the airplane mode can be switched on/off by the F12-button
that is implemented in my HP-laptop as a button to switch on/off the WLAN.

Unfortunately I do not know what exactly the technical reason is behind the error.

Thanks anyway

Comment 16 Ashesh Singh 2017-05-07 10:23:29 UTC
This is bullshit. How can this be closed with the resolution "WORKSFORME"?
There is no proper support for this device in the Kernel.
Some fixes are available over the internet but they need to integrated into the Kernel code so that it's fixed permanently for everyone.

Comment 17 Michael Xavier 2023-11-07 03:55:43 UTC
Hi, I have the same problem with Fedora 39, I tried to download and compile the following module, but I had problems doing so

https://github.com/loimu/rtbth-dkms



this is the log when execute "sudo make"

/home/michaels/Documentos/rtbth-dkms/rtbth_core_us.c:1741:21: nota: en expansión de macro ‘kfifo_out’
 1741 |                     kfifo_out(fifo, buf, pkt_len);
      |                     ^~~~~~~~~
  CC [M]  /home/michaels/Documentos/rtbth-dkms/rtbth_hlpr_hw.o
  CC [M]  /home/michaels/Documentos/rtbth-dkms/rtbth_hlpr_dbg.o
  CC [M]  /home/michaels/Documentos/rtbth-dkms/rtbth_hlpr_linux.o
  LD [M]  /home/michaels/Documentos/rtbth-dkms/rtbth.o
  MODPOST /home/michaels/Documentos/rtbth-dkms/Module.symvers
  CC [M]  /home/michaels/Documentos/rtbth-dkms/rtbth.mod.o
  LD [M]  /home/michaels/Documentos/rtbth-dkms/rtbth.ko
  BTF [M] /home/michaels/Documentos/rtbth-dkms/rtbth.ko
Skipping BTF generation for /home/michaels/Documentos/rtbth-dkms/rtbth.ko due to unavailability of vmlinux
make[1]: se sale del directorio '/usr/src/kernels/6.5.9-200.fc38.x86_64'


Note You need to log in before you can comment on or make changes to this bug.