il wireless è disabilitato dallo switch hardware anche quando non lo è

10

Ho un computer spartano. Ha un modulo wireless integrato che fino a poco tempo fa non avevo avuto problemi. Il problema attuale è questo: ogni volta che spengo il computer e si riavvia, non riesco a "abilitare l'hardware" al wireless. In NetworkManager, ricevo un messaggio "in grigio" che dice "il wireless è disabilitato dallo switch hardware". L'interruttore hardware è abilitato (vedo il led verde accendersi e spegnersi quando premo il pulsante wireless). L'output rfkillindica che non è bloccato in modo software ma è bloccato.

Ho provato quanto segue (rt73usb è il driver del kernel per il mio modulo wireless integrato) come root:

rmmod -f rt73usb 
rfkill unblock all
modprobe rt73usb

ma non fa nulla.

L'unico modo in cui sono stato in grado di "correggere" questo problema è avviare Windows XP (si tratta di una macchina a doppio avvio ma F16 è il sistema operativo principale di utilizzo). Windows fa qualcosa che resetta qualcosa. Quando riavvio in Fedora, sono in grado di accedere al mio wireless come previsto. Anche premendo il pulsante wireless ON e OFF funziona come previsto. È solo quando spengo e poi riaccendo che il mio wireless sembra avere problemi.

Cosa posso fare per correggere questo problema? La maggior parte delle soluzioni google disponibili punta a soluzioni "soft block: yes" e quelle che non puntano alla soluzione precedente ma entrambe non funzionano per me.

Ecco alcune informazioni che potrebbero essere utili:

uname -a

Linux spartan-laptop 3.4.2-1.fc16.i686 #1 SMP Thu Jun 14 21:13:38 UTC 2012 i686 i686 i386 GNU/Linux

lsmod

Module                  Size  Used by
fcoe                   22665  0 
libfcoe                41981  1 fcoe
libfc                 101966  2 fcoe,libfcoe
scsi_transport_fc      51903  2 fcoe,libfc
lockd                  77892  0 
scsi_tgt               18993  1 scsi_transport_fc
be2iscsi               62864  0 
iscsi_boot_sysfs       15121  1 be2iscsi
8021q                  23401  0 
garp                   13744  1 8021q
stp                    12719  1 garp
llc                    13770  2 garp,stp
bnx2i                  49425  0 
cnic                   57699  1 bnx2i
uio                    14374  1 cnic
cxgb4i                 32063  0 
cxgb4                  96243  1 cxgb4i
cxgb3i                 28014  0 
libcxgbi               50450  2 cxgb4i,cxgb3i
cxgb3                 130827  1 cxgb3i
mdio                   13214  1 cxgb3
ib_iser                32861  0 
rdma_cm                36864  1 ib_iser
ib_cm                  36679  1 rdma_cm
iw_cm                  13715  1 rdma_cm
ib_sa                  23625  2 rdma_cm,ib_cm
ib_mad                 41285  2 ib_cm,ib_sa
ib_core                61955  6 ib_iser,rdma_cm,ib_cm,iw_cm,ib_sa,ib_mad
ib_addr                13473  1 rdma_cm
iscsi_tcp              18015  0 
libiscsi_tcp           19427  4 cxgb4i,cxgb3i,libcxgbi,iscsi_tcp
libiscsi               44809  8 be2iscsi,bnx2i,cxgb4i,cxgb3i,libcxgbi,ib_iser,iscsi_tcp,libiscsi_tcp
scsi_transport_iscsi    46598  8 be2iscsi,bnx2i,libcxgbi,ib_iser,iscsi_tcp,libiscsi
ip6t_REJECT            12782  2 
nf_conntrack_ipv6      13921  2 
nf_defrag_ipv6         13678  1 nf_conntrack_ipv6
ip6table_filter        12711  1 
ip6_tables             17737  1 ip6table_filter
nf_conntrack_ipv4      14280  2 
nf_defrag_ipv4         12601  1 nf_conntrack_ipv4
xt_state               12514  4 
nf_conntrack           71472  3 nf_conntrack_ipv6,nf_conntrack_ipv4,xt_state
arc4                   12473  2 
snd_hda_codec_si3054    12864  1 
snd_hda_codec_realtek    63058  1 
snd_hda_intel          32323  3 
rt73usb                26833  0 
snd_hda_codec         103493  3 snd_hda_codec_si3054,snd_hda_codec_realtek,snd_hda_intel
rt2x00usb              19162  1 rt73usb
snd_hwdep              13236  1 snd_hda_codec
rt2x00lib              51790  2 rt73usb,rt2x00usb
mac80211              436414  2 rt2x00usb,rt2x00lib
snd_seq                54638  0 
snd_seq_device         13817  1 snd_seq
cfg80211              161266  2 rt2x00lib,mac80211
snd_pcm                81330  3 snd_hda_codec_si3054,snd_hda_intel,snd_hda_codec
rfkill                 20417  2 cfg80211
coretemp               13240  0 
microcode              18713  0 
joydev                 17124  0 
iTCO_wdt               17652  0 
iTCO_vendor_support    13243  1 iTCO_wdt
serio_raw              13155  0 
i2c_i801               17485  0 
snd_timer              23896  2 snd_seq,snd_pcm
snd                    63169  15 snd_hda_codec_si3054,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer
soundcore              14116  1 snd
snd_page_alloc         13709  2 snd_hda_intel,snd_pcm
r8169                  51284  0 
mii                    13311  1 r8169
uinput                 17246  0 
sunrpc                215122  2 lockd
binfmt_misc            17207  1 
firewire_ohci          35498  0 
firewire_core          55317  1 firewire_ohci
crc_itu_t              12523  2 rt73usb,firewire_core
sdhci_pci              18211  0 
sdhci                  32642  1 sdhci_pci
yenta_socket           40293  0 
mmc_core               96866  2 sdhci_pci,sdhci
i915                  413476  3 
drm_kms_helper         30905  1 i915
drm                   205796  4 i915,drm_kms_helper
i2c_algo_bit           13058  1 i915
i2c_core               28151  5 i2c_i801,i915,drm_kms_helper,drm,i2c_algo_bit
video                  18500  1 i915

lspci

00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02)
00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
04:04.0 CardBus bridge: O2 Micro, Inc. OZ711MP1/MS1 MemoryCardBus Controller (rev 21)
04:04.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev 01)
04:04.3 Bridge: O2 Micro, Inc. Integrated MS/xD Controller (rev 01)
04:04.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)
[angelo@spartan-laptop ~]$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02)
00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
04:04.0 CardBus bridge: O2 Micro, Inc. OZ711MP1/MS1 MemoryCardBus Controller (rev 21)
04:04.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev 01)
04:04.3 Bridge: O2 Micro, Inc. Integrated MS/xD Controller (rev 01)
04:04.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)
[angelo@spartan-laptop ~]$ lspci
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02)
00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02)
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
04:04.0 CardBus bridge: O2 Micro, Inc. OZ711MP1/MS1 MemoryCardBus Controller (rev 21)
04:04.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev 01)
04:04.3 Bridge: O2 Micro, Inc. Integrated MS/xD Controller (rev 01)
04:04.4 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02)

drivers wifi

— g19fanatic
fonte

1

C'è qualcosa di rilevante nel tuo dmesg?

— Chris Down,

Sei sicuro che lo switch hardware non sia solo stato rovinato? Il fatto che questo problema si sia sviluppato su un sistema funzionante in precedenza mi suggerisce un problema a livello di hardware, il che significherebbe che non è in argomento qui. Avresti un superuser.SE, o serverfault o electronics.SE una sorta di problema.

— Warren Young,

1

Il problema si è sviluppato dopo che ho fatto un aggiornamento yum. Non sono sicuro di ciò che è stato installato (non ho mai avuto un problema facendo un aggiornamento cieco prima) ma il problema è iniziato dopo il mio ultimo aggiornamento yum e un riavvio. Il fatto che il riavvio in Windows e il riavvio in F16 suggerirebbero che è legato al software.

— g19fanatic,

Cosa rfkill listmostra? Il mio laptop HP (flextronics) ha un problema in cui, se compilo i WMIdriver per il laptop (abilitando così una gestione più avanzata dell'interruttore rfkill), si ottengono blocchi "soft" e "hard", e talvolta i soft link si rifiutano di ottenere sbloccato. rfkill listaiuterebbe a identificare uno scenario come questo.

— njsg,

@njsg, i blocchi "soft" non sono il problema. Passano avanti e indietro senza problemi. È il blocco "duro" che non "sbloccherà". Quando eseguo l'avvio in Windows, quindi Linux, quindi eseguo una rfkill evente poi premo il pulsante hardware, il blocco hardware funziona come previsto. Se quindi riavvio e vado direttamente su Linux, il blocco hardware non funziona come previsto.

— g19fanatic

2

So che sembrerà una risposta vaga ... ma controlla se hai installato un pacchetto firmware aggiornato per rt73usb. Richiede un firmware separato da inviare al dispositivo per farlo funzionare ... il che, ovviamente, Windows fornirebbe, quindi un avvio a caldo ti consente di usarlo in Linux.

Sto cercando informazioni su Fedora riguardo ai recenti aggiornamenti del driver / firmware rt73usb, ma ci vorrà un momento.

Controlla il firmware e gli aggiornamenti a questo.

Da qui , non sembra che il pacchetto rt73usb-firmware sia stato aggiornato di recente (l'ultimo è stato gennaio 2012, sei mesi fa).

Potresti provare a disinstallare il firmware, quindi reinstallarlo.

Forse la fase lunare e l'allineamento galattico richiedono questo. Non chiedere, a volte aiuta.

Ma sto ancora sospettando un problema del firmware poiché un avvio a caldo in Windows risolve il problema.

— lornix
fonte

Ho controllato yum.log e non sono stati aggiornati nulla relativi a nessuno dei moduli. Ho anche fatto come mi hai suggerito e rmmod rt73usb; yum erase rt73usnb-firmware; rebootpoi a yum install rt73usb-firmware. Questo non ha risolto il problema. Un riavvio non risolve ancora il problema di blocco dell'hardware. Solo un avvio in Windows risolve ancora il problema.

— g19fanatic

Bummer! Penso comunque che sia correlato al firmware, dal momento che l'avvio in Windows e l'avvio a caldo in Linux risolvono il problema.

— lornix,

1

Ho il sospetto che l'aggiornamento che hai descritto abbia installato una versione più recente del driver che non funziona perfettamente con l'hardware specifico che hai. Dovresti guardare il tuo log di yum /var/log/yum.loge magari correre alla yum historyricerca di qualcosa che potrebbe aver influito sul driver rt73usb, sul sottosistema usb o su altre parti correlate (dal tuo lsmod, guarderei qualsiasi cosa correlata a rt73usb, rt2x00usb, rt2x00lib, mac80211, cfg80211 o rfkill). Esegui il backup di tutte le installazioni eseguite nel periodo in cui le cose hanno iniziato a rompersi e vedi se le cose iniziano a funzionare di nuovo.

Un'altra opzione sarebbe quella di esplorare l'uso di NDISwrapper per utilizzare il vero driver di Windows. Personalmente, odio questa soluzione, ma a volte è l'unico modo per far funzionare di nuovo le cose. È probabile che anche il driver di Windows contenga l'ultimo firmware del dispositivo.

— jlp
fonte

Avevo il sospetto che un nuovo aggiornamento avesse causato il problema e fatto esattamente come mi hai raccomandato. Dopo aver esaminato il file yum.log, sembra che non sia stato aggiornato nulla relativo a nessuno di questi pacchetti. Potrei provare la soluzione wrapper NDIS ma come te odio quella soluzione alternativa. Soprattutto da quando è USATO per funzionare senza problemi e ANCORA funziona con la soluzione alternativa all'avvio di Windows ...

— g19fanatic

Potresti comunque iniziare a eseguire il backup delle modifiche fino a quando non torni a un sistema funzionante. È doloroso, ma fattibile (a meno che non torni indietro prima di iniziare a avere il problema e non funziona ancora ). È possibile utilizzare una ricerca binaria per ridurre al minimo il numero di scarichi a freddo che è necessario eseguire durante il backup di roba.

— jlp

Credo che sia così che dovrò provare a risolvere questo problema. Un metodo di ricerca binaria per rimuovere i pacchetti aggiornati sarebbe sicuramente il modo per farlo. Grazie per il suggerimento Sfortunatamente, questo problema era a casa dei miei genitori che stavo visitando per la quarta vacanza e non avrò accesso alla macchina fino a Natale!

— Meno male

2

Quindi sembra che debba essere stato un cattivo aggiornamento che ora è stato corretto. Essendo Linux, raramente (se mai) rallenta quando viene continuamente lasciato online e raramente ha bisogno di un ciclo di accensione e spegnimento. Ho un lavoro cron che passa e fa un aggiornamento yum -y come root ogni 2 settimane. Mio padre non è sicuro quando è successo, ma l'ultima volta che lo ha avviato (un'interruzione di corrente e il consumo della batteria hanno fatto morire il laptop) ha dimenticato di andare su Windows per far funzionare il wireless, ma ha notato che il wireless ha funzionato senza problemi.

— g19fanatic,

1

Credo che il problema sia legato alla gestione da parte del kernel dei cosiddetti pulsanti hardware (che in effetti potrebbero essere semi-hardware se sono pulsanti a sfioramento, non interruttori elettrici). I trigger potrebbero non essere necessariamente parte del firmware / driver wireless. Anche ACPI potrebbe esserne responsabile.

La prima cosa che farei al tuo posto è provare a riavviare su un kernel più vecchio. Se hai fatto un aggiornamento cieco, è probabile che il kernel sia stato aggiornato. Non ho familiarità con fedora in particolare, ma mi aspetto che la sua procedura di aggiornamento del kernel comporti lo spostamento delle voci di GRUB, simile a quello di Ubuntu. Quindi, per avviare un kernel più vecchio, dovresti entrare in GRUB tenendo premuto Shift(in una fase di avvio iniziale) o premendo Esc. Quindi basta selezionare un kernel più vecchio dalla lista.

Se ciò non "funziona", è possibile eseguire ulteriormente il debug del problema eseguendo quanto segue e confrontando l'output tra uno stato laptop rotto e funzionante (risolto avviando Windows):

esegui dmesg | tailsubito dopo aver premuto il pulsante . Tuttavia, potrebbe non esserci nulla di correlato.
monitorare il file di registro del deamon ACPI - Supponendo che si trovi in /var/log/acpid.log, si eseguirà tail -f /var/log/acpid.log.
eseguire un'utilità di monitoraggio degli eventi come:xev - Stampa un bel po 'di output; ma l'unica cosa a cui potresti essere interessato è se viene segnalato un evento di pressione dei tasti quando premi il pulsante. (Sì, il pulsante "hardware" potrebbe semplicemente inviare normali segnali di pressione dei tasti!)
cerca una directory relativa ai pulsanti hardware sotto /proce /sys, quindi cat, il statefile trovato sotto - Puoi usare qualcosa del genere find /proc /sys -name "*button*"per quello. La directory potrebbe in alternativa contenere switch o qualcosa di simile. Puoi anche solo usare find /proc /sys -name state, ma ciò stamperebbe anche molte directory relative ad altre cose, come il controller del disco o la scheda Ethernet.

— rozcietrzewiacz
fonte

questa è un'informazione interessante. Quando il mio wireless "funziona" (dopo un avvio a caldo di Windows), l'interruttore hardware funziona come previsto ... Disabiliterà e riattiverà correttamente il dispositivo wireless. Se faccio questo con un rfkill eventprocesso in esecuzione, mi metterò che il pulsante è stato premuto e posso vedere la harde softserrature coinvolgere e quindi sganciare correttamente. Quando sono in una "modalità di lavoro non wireless" (dopo un riavvio direttamente su Linux) e sto facendo lo rfkill eventswitch hardware viene visualizzato ma il hardblocco non si disabilita, lo fa solo il soft lock.

— g19fanatic,

@ g19fanatic Il problema di fare affidamento su ciò che rfkill eventdice è che non si può dire a quale livello il pulsante hardware non funziona. rfkillè solo un piccolo strumento utile, ma è piuttosto inutile per il debug di tali problemi hardware. Ecco perché ho suggerito metodi generici che possono individuare il problema.

— rozcietrzewiacz,

1

Un altro problema che ho visto qui è che occasionalmente il kernel non vede gli eventi (né attraverso bug nei driver o problemi hardware).

Un passaggio fondamentale nella risoluzione dei problemi è eseguire:

rfkill event

E poi passa da acceso a spento, assicurandoti di vedere una linea come questa:

1398993949.361623: idx 0 type 1 op 0 soft 0 hard 1

Quando passi da off a on, dovresti vedere una linea come questa:

1398994129.694123: idx 0 type 1 op 2 soft 0 hard 0

Nota hard 0alla fine. Se non lo vedi, il kernel non ha visto l'evento.

Gli interruttori, essendo parti in movimento, sono particolarmente suscettibili a guasti e mentre ci piace di solito sospettare prima il software, non è sempre così.

Puoi provare che rfkill sta effettivamente mostrando gli eventi usando la combinazione di tasti per disabilitare il wireless e assicurarti di vedere un soft 1evento e quindi quando riattivi dovresti vedere un soft 0evento. Se lo switch è difettoso, potresti essere in grado di giocherellare con esso fino a quando non funziona, legarlo con un nastro nella posizione di accensione ecc. O altrimenti ottenere semplicemente una scheda di rete secondaria.

Naturalmente, se non si vedono gli eventi in entrambi i casi, può trattarsi di un errore hardware o software. Tuttavia, l'ultima volta che l'ho visto, è stato un interruttore hardware difettoso (ma non completamente fallito).

— Chris Travers
fonte