Avvio lento a causa di device usb

[Max]

Da tempo Linux Mint 18.2 era diventata lenta al boot.
Dopo un po' di sbattimenti per cercare di isolare la causa è saltato
fuori che è colpa dell'Oculus Rift e dai suoi sensori(un totale di 3
porte usb).

Purtroppo non ci sono driver ufficiale e quindi il sistema andava in
palla appresso a questi 3 device per lui sconosciuti.

Oltre alla soluzione ovvia(staccare i tre connettori usb) che consigliate?

[sacarde]

- da quando funzionava hai fatto un aggiornamento del kernel?

- riavviando il vecchio kernel funziona?

[Max]

Post by sacarde
- da quando funzionava hai fatto un aggiornamento del kernel?
- riavviando il vecchio kernel funziona?

provato con 4.8 e 4.10, stesso problema.

[sacarde]

quando e' in questa "pausa" puoi aprire una consolle (ctrl-alt-f1, f2 ...)
e eseguire dei comandi tipo:

systemctl --failed [visualizza i servizi andati male]

journalctl -b -p err [visualizza i log degli errori]


p.s.
quindi l'aggiornamento che causa l'errore non e' del kernel ma di qualcos'altro

[Max]

Post by sacarde
quando e' in questa "pausa" puoi aprire una consolle (ctrl-alt-f1, f2 ...)
systemctl --failed [visualizza i servizi andati male]
journalctl -b -p err [visualizza i log degli errori]
p.s.
quindi l'aggiornamento che causa l'errore non e' del kernel ma di qualcos'altro

Il "blocco" sta dopo grub e prima che inizia a caricare i servizi, lo
schermo è completamente nero e nessuna console è raggiungibile.
I comandi li posso eseguire dopo "lo stallo":


"0 loaded units listed"

"Aug 06 09:19:07 massimo-z170 kernel: usb 1-12: device descriptor
read/all, error 8
Aug 06 09:19:07 massimo-z170 kernel: hid-generic 0003:2833:0031.0004:
usb_submit_urb(ctrl) failed: -1
Aug 06 09:19:07 massimo-z170 kernel: hid-generic 0003:2833:0031.000A:
usb_submit_urb(ctrl) failed: -1"

[sacarde]

provato a togliere dalla riga del kernel di grub

i parametri: quiet splash

e ad aggiungere: noapic nolapic

[Max]

Post by sacarde
provato a togliere dalla riga del kernel di grub
i parametri: quiet splash
e ad aggiungere: noapic nolapic

provato, ma il problema non è sparito.

[sacarde]

vedi i messaggi del kernel?


dove si ferma

[Max]

Post by sacarde
vedi i messaggi del kernel?
dove si ferma

si ferma prima che appaiono, non vedo nulla quando c'è il blocco.

grub --> schermata nera(attesa di circa 15 secondi in cui non vedo
nulla) -> boot normale

[sacarde]

scusa

per "avvio lento" intendi quei 15 sec prima che il kernel si avvii ?

[Max]

Post by sacarde
scusa
per "avvio lento" intendi quei 15 sec prima che il kernel si avvii ?

si, perdonami se non si era capito, colpa mia. Dopo quello stallo ci
mette pochi secondi(sta su ssd).

[sacarde]

quindi non c'entra il kernel ne il sistema

sembrerebbe grub


fatto degli aggiornamenti di grub?

[Max]

Post by sacarde
quindi non c'entra il kernel ne il sistema
sembrerebbe grub
fatto degli aggiornamenti di grub?

grub è quello installato da mint xfce 18.2

[sacarde]

hai fatto dei cambiamenti a livello di BIOS ?

usb-legacy o simili?

[Max]

Post by sacarde
hai fatto dei cambiamenti a livello di BIOS ?
usb-legacy o simili?

no, tutto lasciato a default.
Magari per sfizio provo a cambiare e vedere se si velocizza il boot, ma
non credo...

[Yoda]

Post by Max

Post by sacarde
scusa
per "avvio lento" intendi quei 15 sec prima che il kernel si avvii ?

si, perdonami se non si era capito, colpa mia. Dopo quello stallo ci
mette pochi secondi (sta su ssd).

Mazzate 15 secodi!! in 15 secondi io son gia' al login.

Aggiungo un comsiglio per individuare questi tempi e la loro origine.
Prova a dare:
dmesg --color=always -x | cut -c-88 | less

la pipe a cut e' per tagliare prima che vada a capo. Poi puoi ridarlo
senza, se qualche riga ti interessa, nella forma generale:
dmesg -H

Oppure puoi guardarti separatamente ad esempio quelli del kernel e
quelli di systemctl con:
dmesg --color=always -x -f kern | cut -c-88 | less

dmesg --color=always -x -f daemon | cut -c-88 | less

Comunque il comando dmesg e' ricchissimo d'opzioni, per vedertele e per
giunta in italiano, ti consiglio, invece di "man dmesg", di dare:
dmesg --help

Ciao!

[Max]

Post by Yoda

Post by Max

Post by sacarde
scusa
per "avvio lento" intendi quei 15 sec prima che il kernel si avvii ?

si, perdonami se non si era capito, colpa mia. Dopo quello stallo ci
mette pochi secondi (sta su ssd).

Mazzate 15 secodi!! in 15 secondi io son gia' al login.
Aggiungo un comsiglio per individuare questi tempi e la loro origine.
dmesg --color=always -x | cut -c-88 | less
la pipe a cut e' per tagliare prima che vada a capo. Poi puoi ridarlo
dmesg -H
Oppure puoi guardarti separatamente ad esempio quelli del kernel e
dmesg --color=always -x -f kern | cut -c-88 | less
dmesg --color=always -x -f daemon | cut -c-88 | less
Comunque il comando dmesg e' ricchissimo d'opzioni, per vedertele e per
dmesg --help
Ciao!

l'origine già l'ho capita, l'oculus rift :-)

quello che volevo capire era come fare a stoppare il problema senza
staccare le prese usb.
grazie cmq.

[Yoda]

Post by Max

Post by Yoda

Post by Max

Post by sacarde
scusa
per "avvio lento" intendi quei 15 sec prima che il kernel si avvii ?

si, perdonami se non si era capito, colpa mia. Dopo quello stallo ci
mette pochi secondi (sta su ssd).

dmesg --color=always -x | cut -c-88 | less

l'origine già l'ho capita, l'oculus rift :-)
quello che volevo capire era come fare a stoppare il problema senza
staccare le prese usb.

Era per vedere se /veramente/ il kernel entra dopo 15 secondi.
Se per esempio in TUTTO ci mette 20 secondi (visto che dici che
con l'ssd e' velocissimo), dovresti trovare 5 secondi come tempo
finale di:
dmesg -x

Ciao ma volevo dirti che io ci credo poco che l'usb ritardi l'avvio
prina che entri il kernel.. chi lo frena? il bios?

[sacarde]

l'ordine di avvio dei device e'...

1 usb
2 cdrom
3 hd1

?

[Yoda]

Post by sacarde
l'ordine di avvio dei device e'...
1 usb
2 cdrom
3 hd1
?

Allora, se tu pensi che sia il bios, il rimedio forse e' semplicissimo.
Entri nel setup del bios, da me phoenix-intel con <F2>, e scegli di
avviare SOLO dal o dai dischi fissi.
Se e quando dovessi voler avviare da altro (usb, cdrom, rete..) ti basta
battere all'avvio il tasto apposito, da me <F10> e di li' scegli.

[Max]

Post by Yoda

Post by sacarde
l'ordine di avvio dei device e'...
1 usb
2 cdrom
3 hd1
?

Allora, se tu pensi che sia il bios, il rimedio forse e' semplicissimo.
Entri nel setup del bios, da me phoenix-intel con <F2>, e scegli di
avviare SOLO dal o dai dischi fissi.
Se e quando dovessi voler avviare da altro (usb, cdrom, rete..) ti basta
battere all'avvio il tasto apposito, da me <F10> e di li' scegli.

non era questo, in realtà controllando, il bios non ha proprio il lista
device usb (solo dvd e dischi)

[sacarde]

sarebbe utile capire quando funzionava o se ha funzionato bene



p.s.
quali valori vedi dal comando: lsusb (con l'oculus attaccato)

[Max]

Post by sacarde
sarebbe utile capire quando funzionava o se ha funzionato bene

da sempre, Oculus comprato da poco.

Post by sacarde
p.s.
quali valori vedi dal comando: lsusb (con l'oculus attaccato)

Bus 004 Device 002: ID 2833:3031
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 2833:0031
Bus 003 Device 002: ID 2833:2031
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 0451:8140 Texas Instruments, Inc.
Bus 002 Device 003: ID 0451:8140 Texas Instruments, Inc.
Bus 002 Device 002: ID 2833:0211
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 006: ID 046d:c539 Logitech, Inc.
Bus 001 Device 004: ID 046d:c260 Logitech, Inc.
Bus 001 Device 005: ID 0451:8142 Texas Instruments, Inc. TUSB8041 4-Port Hub
Bus 001 Device 003: ID 0451:8142 Texas Instruments, Inc. TUSB8041 4-Port Hub
Bus 001 Device 002: ID 045e:02e6 Microsoft Corp.
Bus 001 Device 009: ID 046d:c081 Logitech, Inc.
Bus 001 Device 012: ID 046d:c225 Logitech, Inc. G11/G15 Keyboard / G keys
Bus 001 Device 010: ID 046d:c221 Logitech, Inc. G11/G15 Keyboard / Keyboard
Bus 001 Device 008: ID 046d:c223 Logitech, Inc. G11/G15 Keyboard / USB Hub
Bus 001 Device 011: ID 0603:0002 Novatek Microelectronics Corp.
Bus 001 Device 007: ID 2833:0211
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[Max]

Post by Yoda

Post by Max
quello che volevo capire era come fare a stoppare il problema senza
staccare le prese usb.

Era per vedere se /veramente/ il kernel entra dopo 15 secondi.

E infatti non è cosi, ecco la parte dove rallenta da dmesg:


kern :info : [ 4.530494] hid-generic 0003:046D:C225.000D: input,h
kern :err : [ 12.003017] hid-generic 0003:2833:0031.0001: us
kern :warn : [ 12.003024] hid-generic 0003:2833:0031.0001:
kern :info : [ 12.003255] hid-generic 0003:2833:0031.0001: hid
kern :err : [ 22.242877] hid-generic 0003:2833:0031.0002: us
kern :warn : [ 22.242896] hid-generic 0003:2833:0031.0002:
kern :info : [ 22.243114] hid-generic 0003:2833:0031.0002: hid
kern :info : [ 23.554033] raid6: sse2x1 gen() 11777 MB/s

Post by Yoda
Se per esempio in TUTTO ci mette 20 secondi (visto che dici che
con l'ssd e' velocissimo), dovresti trovare 5 secondi come tempo
dmesg -x
Ciao ma volevo dirti che io ci credo poco che l'usb ritardi l'avvio
prina che entri il kernel.. chi lo frena? il bios?

hai ragione, tratto in inganno dallo schermo nero...
Il ritardo è quando il kernel valuta la porta usb dove si trova
l'oculus, non prima.

Tempi finali di dmesg:

11.306772 con l'oculus staccato.

31.790526 con l'oculus attaccato.

Quindi quando ho detto 15 secondo sono stato ottimista :-(

[Yoda]

Post by Max

Post by Yoda
Era per vedere se /veramente/ il kernel entra dopo 15 secondi.

kern :info : [ 4.530494] hid-generic 0003:046D:C225.000D: input,h
kern :err : [ 12.003017] hid-generic 0003:2833:0031.0001: us
kern :info : [ 12.003255] hid-generic 0003:2833:0031.0001: hid
kern :err : [ 22.242877] hid-generic 0003:2833:0031.0002: us
kern :info : [ 22.243114] hid-generic 0003:2833:0031.0002: hid
kern :info : [ 23.554033] raid6: sse2x1 gen() 11777 MB/s

Ma se e' il kernel allora hai mille strade.. comincia a dare come root
(o se root e' impedito mettici sudo):

dpkg-reconfigure udev

Pero' questo vale solo se i pacchetti sono .deb, io la mint non la
conosco e se hai i .rpm quel comando non esiste.

Inoltre, sempre se e' Debian-derivata, posta quello che c'e' nel file:
/etc/initramfs-tools/conf.d/driver-policy

basta la riga con "MODULES=..." e visto che ci sei guarda la data del
file stesso, se anteriore all'aggiornamento che t'ha sputtanato l'usb.

[sacarde]

- non lo riconosco tra quelli elencati da "lsusb"

- se lo inserisci in un secondo momento?

cosa vedi dalle ultime righe di: dmesg

[Max]

Post by sacarde
- non lo riconosco tra quelli elencati da "lsusb"
- se lo inserisci in un secondo momento?
cosa vedi dalle ultime righe di: dmesg

dmesg|grep Oculus



[ 1.394831] usb 3-1: Manufacturer: Oculus VR, Inc.
[ 1.511819] usb 2-2: Manufacturer: Oculus VR
[ 1.539947] usb 4-1: Manufacturer: Oculus VR, Inc.
[ 1.945305] usb 3-1.1: Manufacturer: Oculus VR, Inc.
[ 2.475229] usb 1-10: Manufacturer: Oculus VR
[ 12.003059] hid-generic 0003:2833:0031.0003: hiddev0,hidraw11: USB
HID v1.10 Device [Oculus VR, Inc. Rift] on usb-0000:03:00.0-1.1/input0
[ 22.242889] hid-generic 0003:2833:0031.000D: hiddev0,hidraw12: USB
HID v1.10 Device [Oculus VR, Inc. Rift] on usb-0000:03:00.0-1.1/input1

[sacarde]

e se lo inserisci dopo il boot ?

[Max]

Post by sacarde
e se lo inserisci dopo il boot ?

dici di inserire l'usb subito dopo che parte grub? Oppure di vedere se
c'è uno stallo quando sono già al desktop?

[sacarde]

inserisci l'usb dopo che il sistema si e' avviato completamente...

e da "dmesg" vedere quanto in quanto tempo viene viso e caricato il driver (e se funziona)

[Max]

Post by sacarde
inserisci l'usb dopo che il sistema si e' avviato completamente...
e da "dmesg" vedere quanto in quanto tempo viene viso e caricato il driver (e se funziona)

appena posso riavvio e ti faccio sapere. Che non funzioni non ci sono
dubbi. L'oculus su Linux non ha alcun supporto :-(

[Max]

Post by sacarde
inserisci l'usb dopo che il sistema si e' avviato completamente...
e da "dmesg" vedere quanto in quanto tempo viene viso e caricato il driver (e se funziona)

[ 140.845707] usb 3-1: new high-speed USB device number 2 using xhci_hcd
[ 141.046248] usb 3-1: New USB device found, idVendor=2833, idProduct=2031
[ 141.046252] usb 3-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 141.046255] usb 3-1: Product: Rift
[ 141.046257] usb 3-1: Manufacturer: Oculus VR, Inc.
[ 141.046259] usb 3-1: SerialNumber: 123456789A
[ 141.047076] hub 3-1:1.0: USB hub found
[ 141.047143] hub 3-1:1.0: 4 ports detected
[ 141.165963] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
[ 141.191715] usb 4-1: New USB device found, idVendor=2833, idProduct=3031
[ 141.191719] usb 4-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 141.191722] usb 4-1: Product: Rift
[ 141.191724] usb 4-1: Manufacturer: Oculus VR, Inc.
[ 141.191726] usb 4-1: SerialNumber: 123456789A
[ 141.193027] hub 4-1:1.0: USB hub found
[ 141.193395] hub 4-1:1.0: 4 ports detected
[ 141.333713] usb 3-1.1: new full-speed USB device number 3 using xhci_hcd
[ 141.592898] usb 3-1.1: New USB device found, idVendor=2833,
idProduct=0031
[ 141.592902] usb 3-1.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 141.592905] usb 3-1.1: Product: Rift
[ 141.592907] usb 3-1.1: Manufacturer: Oculus VR, Inc.
[ 141.592909] usb 3-1.1: SerialNumber: WMHD314B5007CK
[ 151.798838] hid-generic 0003:2833:0031.000C: usb_submit_urb(ctrl)
failed: -1
[ 151.798880] hid-generic 0003:2833:0031.000C: timeout initializing reports
[ 151.799247] hid-generic 0003:2833:0031.000C: hiddev0,hidraw11: USB
HID v1.10 Device [Oculus VR, Inc. Rift] on usb-0000:03:00.0-1.1/input0

[sacarde]

quindi 10 secondi circa


p.s.

qui sembrerebbe un device conosciuto

https://wiki.archlinux.org/index.php/Oculus_Rift

[Max]

Post by Yoda
/etc/initramfs-tools/conf.d/driver-policy
basta la riga con "MODULES=..." e visto che ci sei guarda la data del
file stesso, se anteriore all'aggiornamento che t'ha sputtanato l'usb.

quel file non c'è su mint, eppure è una derivata di Ubuntu, la quale è
derivata da Debian :-)

Ragazzi ci tengo a precisare che il problema (Mint 18.2 installata solo
poche settimane fa con installazione pulita, pulita) c'è sempre stato su
questa installazione, fin dal primo giorno.

[Max]

On 10/08/17 18:39, Max wrote:


Risolto!!!

Ho aggiunto questo parametro a grub:

usbhid.quirks=0x2833:0x0031:0x20000000

In questo modo gli dico di fottersene di controllare dove sta l'oculus.

[Yoda]

Post by Max
Risolto!!!

Cioe' al kernel - penso.

Post by Max
usbhid.quirks=0x2833:0x0031:0x20000000

Complimenti! ma questo coniglio da qual cappello l'hai tirato fuori?!

Post by Max
In questo modo gli dico di fottersene di controllare dove sta l'oculus.

[Max]

Post by Yoda

Post by Max
Risolto!!!

Cioe' al kernel - penso.

si, configurando i parametri da passargli da /etc/default/grub

Post by Yoda

Post by Max
usbhid.quirks=0x2833:0x0031:0x20000000

Complimenti! ma questo coniglio da qual cappello l'hai tirato fuori?!

google :-P

https://forums.linuxmint.com/viewtopic.php?t=156993



Cmq grazie anche a voi due che avete perso tempo insieme a me ;-)

[sacarde]

facci sapere se e quando l'apparecchio funzionera!

[Max]

Post by sacarde
facci sapere se e quando l'apparecchio funzionera!

su questo la vedo più dura. Serve il supporto ufficiale su un device
complicato come questo.


Uno dal team di sviluppo:

"From what I can gather GNU/LINUX support is not completely off the
table for the future, but it has been de-prioritized in comparison to
other operating environments at this time."

un no educato :-(