// Stai leggendo ...

Hardware

Onda N501HS, ET501HS ed altri modem usb, pcmcia ed express card con linux (usbserial)

Con la guida di oggi cercheremo di spiegare in modo semplice come configurare una pc-card o un modem usb con linux. Grazie al modulo usbserial “forzeremo” il sistema a riconoscere come dispositivo modem il nostro hardware indipendentemente dall’interfaccia adottata (usb, pcmcia o express card).


Nonostante sempre più hardware sia supportato nativamente dal kernel linux (senza bisogno di ricorrere all’installazione di alcun driver) può capitare che la nostra pc-card o il nostro modem usb non venga “riconosciuto” dal sistema.

Se questo dovesse accadere è possibile tentare la strada USBSERIAL. Grazie a questo modulo, infatti, è possibile “forzare” il nostro S.O. in modo da abbinare ad un determinato hardware (individuato sulla base del codice del produttore e del numero di seriale) una “periferica” modem, passando successivamente alla configurazione di Gnome-ppp o di Kppp.

Il vantaggio di USBSERIAL e quello di fornire una soluzione “universale” ed indipendente dal tipo di interfaccia adottata dalla periferica (usb, pcmcia o express card).Ho personalmente testato la procedura alcune settimane fa con una distribuzione Ubuntu e le pc-card ONDA N501HS (pcmcia) e ONDA ET501HS (Express card).

- Per prima cosa connettiamo la periferica al pc e quindi apriamo un terminale
- Eseguiamo il comando lsusb e scorriamo l’output fino ad individuare il nostro modem (l’output dovrebbe essere simile a questo):

 Bus 001 Device 001: ID 0000:0000
Bus 002 Device 002: ID 19d2:0001
Bus 002 Device 001: ID 0000:0000


- Forziamo il sistema ad abbinare un “dispositivo modem” all’hardware individuato digitando:

sudo modprobe usbserial vendor=0x19d2 product=0x0001

- Se tutto è andato a buon fine digitando dmseg dovreste ottenere un output simile a questo:

usbcore: already loaded
usbcore: registered new drive r usbserial
drivers/usb/serial/usb-serial .c: USB Serial support registered for Generic
usbserial_generic 5-1:1.0: Ge neric converter detected
usb 5-1: Generic converter no w attached to ttyUSB0
usbserial_generic 5-1:1.1: Ge neric converter detected
usb 5-1: Generic converter no w attached to ttyUSB1
usbserial_generic 5-1:1.2: Ge neric converter detected
usb 5-1: Generic converter no w attached to ttyUSB2
usbcore: registered new drive r usbserial_generic
drivers/usb/serial/usb-serial .c: USB Serial Driver core v2.0

- Rendiamo permanenti le modifiche

sudo gedit /etc/modules

aggiungendo in coda al file la seguente stringa:

usbserial vendor=0×19d2 product=0×0001

- Ora non ci resta che passare alla configurazione di GnomePPP (utenti Gnome) o di KPPP (utenti KDE) inserendo come dispositivo il device appena “creato” /dev/ttyUSB0

Commenti

commenti


I commenti all'articolo

15 commenti for “Onda N501HS, ET501HS ed altri modem usb, pcmcia ed express card con linux (usbserial)”

  1. Ciao Skumpic,

    solo due osservazioni che ***mi riprometto di completare appena posso***

    1) La tua guida è molto chiara, ma è un po’ “Ubuntu-centrica”.

    2) Il modulo usbserial avrebbe (così ho letto) una limitazione nel buffer che non gli permette di usare come si dovrebbe una connessione HSDPA; mi pare che riesca a gestire al massimo velocità attorno a 800 650 Kbit/sec.
    Naturalmente appena sarà aggiornato, il problema si risolverà, ma, per il momento, se si desidera raggiungere velocità HSDPA è necessario patcharlo “a mano” (che non è un’operazione che chiunque sa o ha voglia di fare).
    Se si ha Linux, optare per collegarsi in HSDPA con un cellulare UMTS/HSDPA invece che con un modem USB, o con una PCMCIA o Express Card, dà il vantaggio di poter utilizzare appieno tutta la velocità che il provider mette a disposizione, dato che il modem del cellulare viene gestito da un altro modulo: il cdc_acm , che non mi risulta abbia la limitazione di buffer dell’usbserial.
    A me pare che questo limite dell’usbserial, se è vero, sia forse la più grossa pecca che ha oggi Linux con riguardo all’uso di dispositivi UMTS/HSDPA.
    Devo però aggiungere che non ho trovato documentazione ufficiale a riguardo, anche per la verifica d’obbligo, cioè ***se effettivamente questa limitazione del buffer sia vera e se sussista tuttora***: bisognerebbe cercare meglio.

    Commentato da 5m33 | marzo 4, 2008, 10:43 |
  2. ciao 5m33 ti ringrazio per il feedback:)
    Si la guida è molto ubuntu-centrica, ma per il semplice motivo che io non mi ritengo un “espertone” di linux (anzi:P).
    La mia esperienza è limitata alla distro africana, debian (qualche server domestico/soho e il mio centralino di casa) e qualcosetta di fedora.
    Come vedi tutte distro molto “dumb-user oriented”.
    Una delle pc-card che ho provato è della mia ragazza, quindi posso tranquillamente verificare eventuali limitazioni di usbserial e eventualmente scrivere 2 righe su come patchare il modulo.
    Ciao
    Skumpic

    Commentato da skumpic | marzo 4, 2008, 11:18 |
  3. Skumpic,

    tu dici:

    > Come vedi tutte distro molto “dumb-user oriented”.

    ma io credo che né Ubuntu, né Fedora siano “dumb-user” oriented. Il motivo fondamentale per cui lo credo è che penso che le capacità si vedano “dal manico”, non dalla distro che si usa, se poi la distro è una Ubuntu, che lascia ampia libertà all’utilizzatore il quale la può modellare a suo piacimento, ciò varrebbe a maggior ragione.

    Piuttosto, per me dire “Ubuntu-centrica” è un po’ come dire “Debian-centrica” e/o Gnome-centrica: “sudo” (e se, in un’altra distro, l’utente non è fra i sudoers?)… “gedit” (e se uno usa KDE?)… capisci che cosa intendo? ;-)

    Per quanto riguarda il limite nel buffer di usbserial, penso proprio che serva un approfondimento, perché pare dipenda anche dal kernel (versioni recenti potrebbero avere il modulo già patchato) e non sarei neppure sicuro che il limite non riguardi anche cdc_acm (ma anche qui bisogna vedere il kernel in uso). Ho il sospetto (ma è ancora soltanto tale) che le distro più recenti abbiano già tutti i moduli patchati, oppure usino il modulo airprime al posto di usbserial.
    Tanto per dire: OpenSuSE 10.2 usa airprime, ma questo non consente velocità superiori a 650 kbit/sec, mentre OpenSuSE 10.3 usa anch’essa airprime, ma in una versione già modificata per velocità superiori.
    Comunque ci tornerò sopra.

    Il limite del buffer non è di circa 800 Kbit/sec come avevo detto, ma di 650 Kbit/sec.

    Per il momento, posso dire che il mio cdc_acm, con kernel 2.6.18.8 raggiunge 1,6 1,7 Mbit/sec.

    Facci intanto sapere la tua prova sul campo.

    Commentato da 5m33 | marzo 4, 2008, 22:06 |
  4. [...] realtà già al momento della pubblicazione 5m33 aveva sottolineato come vi fossero dei limiti intrinsechi alla soluzione proposta (ad oner del [...]

    Commentato da Libera il VoIP | Modulo Airprime: finalmente HSDPA anche per utenti linux | marzo 17, 2008, 13:28 |
  5. [...] “Onda N501HS, ET501HS ed altri modem usb, pcmcia ed express card con linux (usbserial)“ [...]

    Commentato da Libera il VoIP | Mobile routers (terza parte) - Asus WL-500G e WL-500G Premium | aprile 8, 2008, 22:42 |
  6. Io c’ho anche provato : e va tuttto come da voi descritto :
    ma il mio notebook HP(dv2000) proprio non ne vuol sapere di connettersi con questa benedetta scheda Onda ET502HS della Tim (OndaCommunication Spa).
    la versione Ubuntu che uso è l’ultima Hardy, ho eseguito tutto , e l’output da teminale sembra tutto corretto, configurato il modem con PPP , ma sic… non va !!!!

    che fare ?

    Commentato da XXAlet | giugno 12, 2008, 13:45 |
  7. Mi posti l’output del comando dmesg che vedi una volta connessa la scheda al pc?
    GRAZIE

    Commentato da skumpic | giugno 12, 2008, 16:32 |
  8. salve a tutti.
    ho ubuntu 8.04 con Kernel 2.6.24-19 ed ogni volta che inserisco la mia Onda N501HS il sistema non la riconosce, allora sono costretto a scaricare il modulo ehci_hcd(quello delle usb2.0) e dopo qualche secondo viene riconosciuto un Qualcomm con i seguenti codici vendor:product 05c6:6613.
    Qualcuno mi sa consigliare una strada un po più elegante per evitare di sacrificare il modulo ehci…?

    grazie.
    AlexT

    Commentato da AlexT | giugno 21, 2008, 16:31 |
  9. Dei commenti seguenti, quelli che vanno dal 21 Giugno al 14 Luglio 2008 sono stati REVISIONATI COMPLESSIVAMENTE .

    >>>>>>>>>> Sono possibili ancora correzioni minori, che saranno comunque indicate qui < <<<<<<<<<
    (29 Luglio 2008, ore 17:11)

    =============== Gli aggiornamenti finali sono marcati con la barra rossa a sinistra, sottolineati e in corsivo. ===============
    (30 Luglio 2008, ore 23:28)

    Commentato da 5m33 | luglio 22, 2008, 11:36 |
  10. 5m33 scrive:

    (Testo REVISIONATO da ultimo il 29 Luglio 2008)

    @ AlexT
    ———

    sacrificare il modulo ehci… uhm… se lo scarichi non è che lo sacrifichi, perché udevd (il daemon di udev) provvederà a caricarlo automaticamente ogni volta che serve, cioè, in pratica, qualora tu inserissi una periferica USB “high speed”.

    *** 5 Luglio 2008 ***
    Non è vero, perché udev non si occupa di caricare i moduli necessari al funzionamento del dispositivo: questi devono essere già caricati per permettere ad udev di riconoscere la periferica e creare il corrispondente device file.
    *** 21 Luglio 2008 ***
    Quanto detto appena sopra (“Non è vero, perché…”) era vero con versioni ormai abbastanza vecchie del kernel e in assenza del programma hotplug.
    *** 29 Luglio 2008 ***
    Relativamente di recente, il sistema di hotplug (cioè quelle funzioni che precedentemente venivano svolte dall’applicativo “hotplug”, o dal daemon “kerneld”) è stato integrato nel kernel.
    Quando il kernel rileva un nuovo device, manda un evento di hotplug (uevent) al daemon di udev (udevd).
    Udevd provvede a caricare il modulo più adatto per il device (udevd chiama /sbin/modprobe con i contenuti della variabile d’ambiente uevent MODALIAS)
    ************
    *** 29 Luglio 2008 ***
    “Sacrificio” del driver EHCI
    —————————-

    Ma anche il caricamento automatico dei moduli vale per i driver che pilotano specificamente la periferica “pluggable” e non per quelli che servono per gestire dei dispositivi che vengono rilevati soltanto al boot, perché questi non sono “pluggable”: è il caso, per esempio, dei controller delle porte USB del PC, cioè appunto dei moduli ehci e uhci_hcd (od ohci_hcd). [*]
    In effetti, quindi, se rimuovi ehci_hcd, le porte USB del PC non lo hanno più a disposizione e le periferiche per le quali viene usato vengono rimappate dal kernel sulle interfacce alle quali è assegnato il driver “supplente” uhci_hcd (od ohci_hcd), mentre ehci_hcd verrà ricaricato in automatico soltanto al boot successivo, cioè quanto verranno nuovamente rilevati (eventi di hotplug) gli Hub USB del PC.

    [*]
    Come già accennato nell’aggiornamento più sopra, con kernel recenti udev (udevd) svolge anche la funzione di caricamento automatico dei moduli al momento dell’inserimento di un device. Con kernel non recenti questa funzione era assolta da un programma apposito: hotplug, o, ancora prima (con kernel della serie 2.4) kerneld.
    Un esempio di caricamento automatico dell modulo usb_storage:

    # modprobe -r usb_storage
    FATAL: Module usb_storage is in use.

    # umount /dev/sda

    # modprobe -r usb_storage

    OK, mi ha permesso di rimuovere il modulo. Ora tolgo la periferica USB e poi la reinserisco: il modulo usb_storage viene ricaricato automaticamente, infatti…

    # lsmod | grep usb_storage

    usb_storage       82624 1
    scsi_mod         136712 5 usb_storage,sg,st,sd_mod,sr_mod
    usbcore 128004 9 usb_storage,uhci_hcd,ehci_hcd,cdc_acm,rndis_host,cdc_ether,usbnet,usbhid
    ide_core         130504 4 usb_storage,ide_cd,piix,ide_disk

    30 Luglio 2008 (quanto segue è da verificare)
    Tuttavia, ehci_hcd potrebbe essere ricaricato in automatico in occasione di un evento di hotplug di un dispositivo che abbia al suo interno un Bus USB 2.0, quale è, appunto, la scheda dell’Onda.

    Per mantenere un determinato modulo disponibile, facendo però sì, contestualmente, che esso non venga mai assegnato a una determinata periferica, si può creare una regola di udev che faccia l’unbinding selettivo, cioè una regola che imponga di tenere scollegato un modulo rispetto a una specifica interfaccia di comunicazione fra il kernel e il device (soluzione adottata appunto dal workaround elaborato da Sergio Callegari: vedi oltre).
    ************

    *** 21 Luglio 2008 ***
    (il problema è che il kernel, nel momento in cui venisse reinserito il modulo ehci_hcd, rimapperebbe i device USB 2.0 assegnati a uhci (o a ohci) su interfacce gestite da ehci_hcd: vedi, in un commento successivo, il testo “Chiarimento sulle versioni di USB e sui relativi driver in Linux”, il 5° punto). Con la scheda dell’Onda si ripresenterebbe di conseguenza il problema
    ************

    Per evitare che il driver (sierra, airprime, usbserial, option, ecc.) per il controllo del modem nella PC-Card confligga con il driver ehci_hcd, che serve per gestire lo Hub USB (interno anch’esso alla PC-Card) come “high speed USB device”, bisogna che l’interfaccia di comunicazione con la PC-Card che il kernel farebbe gestire dal driver per “high speed” USB device (USB 2.0: ehci_hcd) venga invece associata al driver per i “low speed” o per i “full speed” USB device (USB 1.1: ohci_hcd, o uhci_hcd), invece che a quello per gli “high speed” USB device (USB 2.0: ehci_hcd).

    *** 5 Luglio 2008 ***
    Come poi appurato in seguito, non si tratta di un conflitto fra il driver che qui chiamo “di basso livello” (ehci_hcd) e quello che chiamo “di alto livello” (cioè quello per pilotare il chipset del modem), bensì di un malfunzionamento del driver per i device USB 2.0 con quella specifica periferica dell’Onda.
    Se la “colpa” sia della periferica dell’Onda, che non implementerebbe in modo corretto, le specifiche USB 2.0, mandando in tilt il driver, o sia invece del driver, può essere oggetto di discussione. Con buona probabilità, comunque, l’incompatibilità deriva dall’implementazione delle specifiche di comunicazione “high speed” all’interno della periferica.
    ************

    Siccome, però, la PC-Card si presenta al kernel come periferica “high speed” (USB 2.0), udevd le assegna il driver idoneo a questo genere di periferiche, cioè ehci_hcd. Di conseguenza, bisogna fare in modo che udevd riconosca la PC-Card senza avere a disposizione il modulo ehci_hcd e dunque assegnando ad essa ohci_hcd o uhci_hcd.

    30 Luglio 2008 (quanto segue è da verificare)
    Precisazione: il modulo ehci_hcd va rimosso dopo aver inserito la PC-Card, non prima, altrimenti udevd… lo ricaricherebbe in automatico al momento dell’inserimento della PC-Card. Rimuovendolo con la PC-Card inserita vengono deregistrate l’interfaccia assegnata all’host USB interno alla PC-Card alla quale era stato assegnato il driver EHCI e l’interfaccia assegnata al Bus USB del PC assegnato a EHCI

    Questa è la ragione per cui se si rimuove (rmmod o modprobe -r) il modulo ehci_hcd la PC-Card funziona: se la mia ipotesi è giusta, udevd è costretto a gestirla con l’altro modulo che gli resta a disposizione per le periferiche USB, che sarà cioè ohci_hcd o uhci_hcd, dopodiché, riuscendo a comunicare con la periferica, potrà caricare, in automatico, il modulo per pilotare il chipset del modem senza che si verifichino conflitti di sorta.

    *** 5 Luglio 2008 ***
    Questo è anche il motivo per cui, facendo l’unbinding selettivo di cui al workaround di Callegari (vedi oltre), alla periferica viene automaticamente assegnato un driver supplente di ehci: uhci_hcd od ohci_hcd. La periferica verrà rimappata come device associato a uhci_hcd o a ohci_hcd e funzionerà, dunque, come device “full speed” invece che “high speed”: più che sufficiente, comunque, per utilizzare il modem vista la velocità di 12 Mbit/sec supportata dalla modalità “full speed”.
    ************

    Puoi automatizzare la rimozione del modulo ehci_hcd con uno scriptino in Bash da eseguirsi dopo aver inserito la PC-Card.
    Se tu mettessi ehci_hcd in blacklist (/etc/modprobe.d/blacklist), in effetti lo “sacrificheresti”, perché eviteresti che fosse caricato al momento del boot, nonché quando fosse inserita la scheda dell’Onda. In buona sostanza, perderesti l’uso dell’USB 2.0 (ma potresti sempre utilizzarlo reinserendolo nel kernel con insmod o modprobe).

    *** 21 Luglio 2008 ***

    Il modulo ehci_hcd puoi rimuoverlo “a mano” (modprobe -r o rmmod), o anche metterlo in blacklist; però, se dovesse servirti qualora collegassi un’altra periferica USB “high speed” a una porta USB del PC, dovresti caricarlo con modprobe o insmod (caricarlo “manualmente”, perché il kernel, disponendo già di un modulo –uhci_hcd, od ohci_hcd– supplente di ehcd_hcd per gestirla non caricherebbe in automatico ehci_hcd). Tuttavia, se caricato “manualmente” con la PC-Card dell’Onda inserita, si impadronirebbe del controllo di questa, che –come già sappiamo– smetterebbe di funzionare: in buona sostanza dovresti scegliere se preferire di utilizzare l’altra periferica come “high speed” (usando cioè ehci_hcd) senza però poter usare il modem, oppure di utilizzarla come “full speed” (usando uhci_hcd o ohci_hcd) potendo al contempo usare il modem.

    Invece di scaricare tutte le volte (“a mano” o in automatico con uno script) ehci_hcd, un’altra soluzione è scrivere una regola apposita per udev. Una regola che istruisca udevd a scaricare ehci_hcd tutte le volte che viene inserita una PC-Card identificata con idProduct “19d2″ e idVendor “0002″:
    SUBSYSTEMS=="usb", SYSFS{idProduct}=="19d2", SYSFS{idVendor}=="0002", RUN+="/sbin/modprobe -r ehci_hcd"
    (!!! okkio a non fare un semplice copia&incolla della stringa qui sopra, perché WordPress –la piattaforma di gestione di questo blog– sostituisce i doppi apici con le virgolette curve, per cui puoi fare un copia&incolla, ma devi ricordarti di ripristinare i doppi apici nei punti giusti di apertura e di chiusura !!!)

    E’ una soluzione che tiene scollegato il driver ehci_hcd dalla specifica periferica, ma lo mantiene a disposizione per altre periferiche.
    ATTENZIONE ==> Si noti che, come poi si è appurato, né questa regola per udev, che fa ricorso alla rimozione del driver, né quella che fa ricorso al suo unbinding selettivo (vedi, oltre, il workaround di Callegari) possono funzionare con i codici identificativi sopra riportati. Infatti tali codici appartengono al device “modem”, cioè a quel componente che è gestito dal driver che qui chiamo “di alto livello” (il driver per il modem), ma siccome siamo di fronte a un malfunzionamento (con la scheda dell’Onda) del driver ehci_hcd, cioè di quel driver che serve per instaurare una prima comunicazione tra il PC e la PC-Card (in altre parole: del driver che pilota l’host USB interno alla PC-Card attraverso il quale il PC comunica –mediante un driver ulteriore– col circuito del modem interno alla PC-Card), i codici identificativi del modem non vengono neppure rilevati. Ragion per cui bisogna che la regola sia riferita ai codici identificativi del device che sta a monte del modem, che, appunto, è lo Hub USB interno alla PC-Card: vedi, oltre, il workaround di Callegari)
    ************

    Qui fermiamoci un attimo e… andiamo a leggerci quest’altro commento.


    5m33 scrive:

    (Testo REVISIONATO da ultimo il 29 Luglio 2008)

    Chiarimento sulle versioni di USB e sui relativi driver in Linux

    ——

    1° punto fermo (attenzione alla nomenclatura “low”, “full” e “high”)

    USB versione 1.1
    può funzionare come
    - low speed device, a 1.5 Mbit/sec
    oppure come
    - full speed device, a 12 Mbit/sec

    ==> serve un driver per periferiche conformi allo standard OHCI o UHCI

    USB versione 2.0
    funziona come
    - high speed device, a 480 Mbit/sec

    ==> serve un driver conforme allo standard EHCI

    ——

    2° punto

    Una periferica USB 2.0 connessa a un host o a uno Hub USB 1.1 funziona tranquillamente, ma alla velocità di 12 Mbit/sec invece che a 480 Mbit/sec.

    ——

    3° punto

    Perché una periferica USB 2.0 funzioni come periferica “high speed” (480 Mbit/sec) bisogna che il driver di controllo dell’host sia conforme allo standard “EHCI”.

    ——

    4° punto

    Quando un driver EHCI è in funzione, tutte le porte USB vengono controllare da questo driver e, se EHCI rileva che a una porta USB viene collegata una periferica “full” o “low speed”, allora tale porta viene associata a un driver OHCI o UHCI.
    Il driver EHCI tiene per sè soltanto le periferiche “high speed”, cosicché ciascuna porta sarà associata o a un driver per USB 2.0, oppure a un driver per USB 1.1 –mai a entrambi– in relazione al fatto che la periferica sia “high speed”, oppure non lo sia.

    ——

    5° punto

    Se un kernel Linux dispone soltanto di driver per periferiche USB 1.1 (modulo ohci_hcd, o uhci_hcd) e viene collegata una periferica USB 2.0, la periferica viene controllata da un driver USB 1.1 (vedi 2° punto), ma se mentre la periferica è collegata viene inserito nel kernel (caricato) il driver per periferiche USB 2.0 (modulo ehci_hcd), quest’ultimo si impadronisce del controllo della periferica (che viene trasferita sulla porta associata al modulo ehci_hcd).

    ————————–

    Venendo alla questione della PC-Card Onda N501HS, sulla base anche di quanto detto sopra penso si possa fare la sguente ipotesi.

    Probabilmente l’incompatibilità riguarda il driver per il controllo della periferica USB posto in relazione col driver per la gestione come modem seriale della periferica USB. Cioè, riguarda il modulo ehci_hcd in relazione al modulo sierra, che viene caricato automaticamente dopo aver inserito la PC-Card e, soprattutto, dopo aver rmosso ehci_hcd.

    *** 5 Luglio 2008 ***
    Oggi sappiamo che non si tratta di un’incompatibilità tra due driver, ma di un conflitto tra il modo in cui la periferica rispetta le specifiche dell’USB 2.0 e l’implementazione delle specifiche dell’USB 2.0 nel driver. Insomma: col driver ehci la PC-Card e il kernel non comunicano, mentre con un driver uhci o ohci, cioè un driver per USB 1.1, PC-Card e kernel comunicano.
    ************

    La PC-Card si presenta al kernel come una periferica USB 2.0 e quindi viene associata da udevd al driver ehci_hcd. A causa del conflitto tra ehci_hcd e airprime Bisogna quindi obbligare il kernel a controllare la PC-Card col driver uhci_hcd o con ohci_hcd invece che con ehci_hcd.

    *** 5 Luglio 2008 ***
    Non si tratta di un conflitto tra due driver: vedi sopra.
    ************

    Scaricando (modprobe -r o rmmod) il driver ehci_hcd, udevd entra in azione rimappando la periferica e trasferendone il controllo a uhci_hcd (o a ohci_hcd). A tal punto, il driver sierra (che pilota la periferica come modem seriale) può tranquillamente entrare in funzione (se ne occupa udevd da solo) senza problemi di conflitto col driver (di più basso livello) che sovraintende al funzionamento della periferica come periferica USB.

    *** 5 Luglio 2008 ***
    Come già detto sopra, non si tratta di un problema di conflitto fra il driver per i device USB e quello per il modem, ma di un problema di comunicazione del kernel con la periferica attraverso il driver per i device USB 2.0 (ehci_hcd): quando il kernel riesce a comunicare con la PC-Card mediante il driver alternativo per device USB 1.1 (uhci_hcd od ohci_hcd), il riconoscimento prosegue rilevando i codici identificativi del modem interno alla PC-Card: idVendor e idProduct. Questi codici permettono a udev di associare in automatico al modem un driver col sistema dei modalias.
    ************

    5m33 scrive:

    (Testo REVISIONATO da ultimo il 29 Luglio 2008)

    Qui fermiamoci un attimo, dicevo, perché non possedendo la PC-Card della Onda non posso provare come venga rilevata dal mio sistema Linux, né ricavarne l’idProduct e l’idVendor.
    In effetti, attorno a questo modello di scheda c’è un po’ di confusione.
    A me pare che questo documento…
    http://www.giddi.net/files/documents/Onda.pdf
    … tratto da http://www.giddi.net aiuti a chiarirsi un po’ le idee.

    Tuttavia, non potendo provare le cose in concreto, alcuni dubbi mi rimangono.

    In particolare:

    1. sarei curioso di sapere con certezza quali siano l’idProduct e l’idVendor di:
    - Onda N501HS (PC-Card modem)
    - Onda ET501HS (Express Card modem)
    - Onda M1HS (USB modem)

    (può darsi che mi sia un po’ perso nel cercare info in astratto, ma mi sembra che ci siano sovrapposizioni/confusioni/incertezze riguardo alla corretta attribuzione ai modelli di cui sopra delle seguenti due tre coppie di codici:
    - idVendor: 19d2 e idProduct 0002
    - idVendor: 19d2 e idProduct: 0001
    - idVendor: 05c6 e idProduct: 6613)

    (forse una mano potrebbe darcela Skumpic, perché, come ha scritto qui, in un commento di qualche tempo fa, la sua ragazza possiede uno dei modem in questione)

    2. ho il dubbio che questi modem (o alcuni di questi) commercializzati dalla Onda si presentino al kernel come CD-Rom e questo potrebbe spiegare perché venga caricato da udevd il driver ehci_hcd.

    *** 5 Luglio 2008 ***
    Questo è vero per alcuni modem: l’argomento è trattato nei commenti successivi.
    ************

    Mi rivolgo, allora, ad AlexT:
    potresti provare a fare un lsusb subito dopo che la scheda è stata associata a ehci_hcd e poi a rifarlo dopo che hai scaricato quest’ultimo e quindi dopo che la scheda ti è stata riconosciuta come Qualcomm (perché gestita da ohci_hcd o da uhci_hcd) ?
    ==> Ipotizzerei che il problema non sia un conflitto fra airprime e ehci_hcd, ma il fatto che, quando viene associata a ehci_hcd, la scheda sia in realtà vista dal sistema come un’unità CD-Rom.

    *** 5 Luglio 2008 ***
    Il riconoscimento del device come unità CD-Rom può essere una causa di problemi nel riconoscimento di alcuni modem, ma non è questo il caso del modello N501HS
    ************

    Infine, non sono riuscito a dipanare la matassa riguardo alla reale provenienza del prodotto:
    la N501HS sarebbe in realtà il modello MF330 prodotto in Cina dalla ZTE Corporation, ma pare anche che coincida con una scheda della Sierra Wireless [*].
    ==> Qual è la verità?

    [*] Fonti:

    http://www.giddi.net/files/documents/Onda.pdf
    parla della PC-Card come di una scheda della Sierra Wireless che viene riconosciuta con l’idVendor della Onda (“19d2″) e con l’idProduct “0002″.
    Da qui…
    http://www.linux-usb.org/usb.ids
    … emerge che lo stesso idProduct appartiene anche ad un altro modello di modem della Onda (MT505UP MF632).

    Sempre in…
    http://www.giddi.net/files/documents/Onda.pdf
    … si trovano menzionati moduli usbserial, sierra e airprime, quando però tutti ovviamente non servono: la scheda può essere pilotata da uno dei tre, anche se la resa può essere differente. Nella procedura descritta nel documento viene pilotata con airprime.

    Qui…
    http://blog.linux-fueled.com/2007/11/28/configurare-onda-express-card-et501hs-hsdpa-su-ubuntu-linux/
    … si trovano i codici identificativi della Express Card ET501HS: “19d2″ (l’idVendor della Onda) e “0001″.
    Nella procedura descritta questa scheda viene pilotata con usbserial.

    Qui…
    http://dpfsoftware.altervista.org/blog/?p=7
    … si parla del modem USB Onda MH600HS, che viene riconosciuto, in prima battuta, come CD-Rom con idProduct “2000″ e che con l’ausilio del tool “usb_modeswitch” può essere riconosciuto come modem con idProduct “0001″, che è lo stesso idProduct della Express Card ET501HS… mah.

    Dai commenti al post emerge anche che il modem USB Onda MT505UP ha l’idProduct “0002″, che sarebbe il medesimo del N501HS. In buona sostanza, come già si ricavava da http://www.linux-usb.org/usb.ids esistono modelli di modem diversi con la medesima circuiteria.

    Nota: l’idVendor “05c6″ è quello della Qualcomm (vedi http://www.linux-usb.org/usb.ids ) e se, come dice AlexT, la PC-Card contiene un modem della Qualcomm, parrebbe che per udev fosse giusta la regola…
    SUBSYSTEMS=="usb", SYSFS{idProduct}=="6613", SYSFS{idVendor}=="05c6", RUN+="/sbin/modprobe -r ehci_hcd".
    Quale è, quindi, la regola con l’identificazione corretta?
    Questa…
    SUBSYSTEMS=="usb", SYSFS{idProduct}=="19d2", SYSFS{idVendor}=="0002", RUN+="/sbin/modprobe -r ehci_hcd"
    … già indicata in un commento precedente…
    … o questa…
    SUBSYSTEMS=="usb", SYSFS{idProduct}=="6613", SYSFS{idVendor}=="05c6", RUN+="/sbin/modprobe -r ehci_hcd" ?

    *** 5 Luglio 2008 ***
    Abbiamo già visto nei commenti precedenti revisionati che la regola che rimuove il driver ehci_hcd, per quanto più drastica di quella che fa ricorso all’unbinding selettivo (workaround di Callegari) può essere adottata solo se si fa riferimento ai codici identificativi dell’host USB, interno alla PC-Card, che si trova a monte del chipset modem, in quanto il modem non può essere riconosciuto, visto che il kernel non riesce a comunicare con l’host USB mediante il modulo ehci_hcd, ma ci riesce (appunto) solo mediante uhci_hcd (od ohci_hcd).
    ************

    ==> Continua nei prossimi giorni


    Skumpic scrive:

    Vi confermo che la pc-card in questione è una ZTE ribrandizzata.
    Dopo martedi (ho un esame :P) provo a giocarci un pò (la utilizza quotidianamente la mia ragazza, ma sotto sistema operativo Win XP)


    AlexT scrive:

    Eccomi qui…
    per 5m33
    lanciando lsusb dopo aver connesso la pccard vengono riconosciute 3 nuove porte USB i cui vendor e product sono riconosciuti come 0000:0000.
    invece se scarico il modulo col comando sudo rmmod ehci_hcd e attendo quelche secondo viene riconosciuto 05c6:6613 qualcomm….
    Confermo anche ciò che dice skumpic sul chip utilizzato.
    Quello che le aziende fanno è acquistare i chip dalle aziende fornitrici “al meglio” quindi può capitare che lo stesso terminale funzioni con due differenti chip alla stessa maniera o per esempio di avere due modelli differenti che utilizzano lo stesso chip come per esempio la pccard N501HS e l’M1HS.
    il preambolo che espongo è che essendo da poco capitato sul mondo linux l’idea che mi sono fatto(probabilmente sbagliata) è che gli identificativi vendor e product non siano presenti nei files airprime.c/usbserial.c/quello chesia.c pertanto non trovando corrispondenza il sistema non gli assegna alcun modulo.


    AlexT scrive:

    …continuando…
    ho provato anche a scrivere la regola per i product e vendor identificati da me, ma onestamente non è cambiato nulla. quando la inserisco devo sempre scaricarmi il modulo ehc…..
    ho già scritto un bash che dopo aver inserito la pccard rimuove il modulo ehc… e attende qualche secondo poi posso avviare la connessione internet con gnome-ppp/wvdial.
    ovviamente mi piacerebbe saltare il primo step e arrivare direttamente alla connessione.


    5m33 scrive:

    (Testo REVISIONATO da ultimo il 29 Luglio 2008)

    @ AlexT
    ——-

    Ecco la SOLUZIONE (in fondo).

    Tu dicevi:

    «l’idea che mi sono fatto(probabilmente sbagliata) è che gli identificativi vendor e product non siano presenti nei files airprime.c/usbserial.c/quello chesia.c pertanto non trovando corrispondenza il sistema non gli assegna alcun modulo.»

    L’idea è probabilmente giusta ;-) riguardo al driver che qui chiamiamo “di alto livello”, ma c’è un problema più grave riguardo al driver che qui chiamiamo “di basso livello” (ehci_hcd): vedi oltre.

    Per chi ha voglia di spulciarsi i sorgenti e di vedere le differenze nei driver abbinati a diverse versioni del kernel:
    http://lxr.linux.no
    (questo, per esempio, è il più recente sorgente di airprime:
    http://lxr.linux.no/linux/drivers/usb/serial/airprime.c )

    «ho provato anche a scrivere la regola per i product e vendor identificati da me, ma onestamente non è cambiato nulla. quando la inserisco devo sempre scaricarmi il modulo ehc…»

    Ci sarà un qualche motivo per cui udev decida di assegnare alla PC-Card proprio il driver ehci_hcd e non uhci_hcd o ohci_hcd. Comunque sia, anche se non venissimo a capo del motivo, mi sa che l’inghippo stia proprio qui: fino a che udev si ostina…

    *** 5 Luglio 2008 ***
    Poi ho dedotto che il motivo è legato alla comunicazione tra subsystem “pci” e il subsystem “usb” interno alla scheda: in parole povere, quel componente della scheda che sta a monte del chipset del modem si presenta al kernel come USB 2.0 e quindi il kernel decide di utilizzare il modulo ehci_hcd. Per risolvere il problema, vedi il workaround di Sergio Callegari segnalato qui in calce.
    ************

    … ad associare ehci_hcd a questa PC-Card, tutto si blocca e quindi udev non può procedere rilevando il modem interno alla PC-Card (che, con le ultime versioni del kernel, farebbe correttamente anche senza una regola USB ad-hoc che fungesse da workaround).

    *** 5 Luglio 2008 ***
    Con le ultime versioni del kernel:
    - è possibile assegnare una porta controllata da ehci al driver uhci (o ohci): kernel 2.6.24 (questo sarebbe da approfondire)
    - c’è un meccanismo di fallback, per cui se un device non funziona con ehci viene assegnato a uhci (o ohci) : kernel 2.6.25-rc
    ************

    Siamo tornati alla casella del “Via” ?

    Forse sì, però questo supplemento di istruttoria ci ha dato modo di confermarci che in effetti saremmo di fronte a un bug (ed esiste un workaround !!!).

    Quanto si legge qui…
    http://www.hwupgrade.it/forum/showthread.php?t=1583181
    … mi pare illuminante.

    In particolare, cito quanto segue:

    «Non risultano attualmente patch per il problema di ehci_hcd, purtroppo (oppure, non le ho trovate) quindi l’unica è blacklistare il modulo oppure scaricarlo “a mano” com rmmod, ma sicuramente si perde l’USB 2.0.
    Da notare che se il modulo è già caricato e in uso perché magari dentro il pc ci sono device USB2 preattivati, non si disattiva…. e quindi non credo si possa far andare la scheda.
    Purtroppo per sistemare il modulo ehci_hcd per far andare Onda e schede “fratelle” (intendo dire, scrivere una patch al driver del kernel) bisognerebbe essere molto esperti di USB… in teoria come USB2 dovrebbe funzionare lo stesso infatti: il difetto è che viene riconosciuta la scheda come HUB USB2, ma poi non vengono “enumerati” i dispositivi ad essa collegati (il modem interno) che quindi non risultano presenti.»

    *** 5 Luglio 2008 ***
    La rimozione del modulo ehci (sempre però che sia possibile in quanto non in uso da parte di altri device) comporta sì che si perda l’uso dell’USB 2.0, ma solo fino a che il modulo non venga reinserito nel kernel con insmod (o con modprobe).
    Se ehci_hcd viene rimosso (rmmod o modprobe -r), udev provvede ad assegnare alla N501HS il modulo supplente uhci_hcd (o ohci_hcd), però se poi ehci venisse reinserito nel kernel (per poterlo usare, ad esempio, con un altro device) si impadronirebbe del controllo della N501HS (vedi, in un commento precedente, il 5° punto in “Chiarimento sulle versioni di USB e sui relativi driver in Linux”), con la conseguenza che sappiamo. In poche parole: non si riesce a fare in modo che il modulo ehci_hcd possa essere presente mentre la PC-Card si trova nello slot PCMCIA, se non usando l’unbinding selettivo di cui al workaround di Callegari.
    ************

    Mi pare opportuna e molto utile l’osservazione che il modulo non lo si può ovviamente scaricare se è in uso con un’altra periferica.

    Inoltre, questo documento…
    ==> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/129433
    … è assolutamente da leggere.
    Vi ritroviamo molti dei punti qui discussi (ZTE Corporation, idVendor e idProduct, ecc.)
    Ecco una citazione:
    «Linux kernel has already misbehaved on ehci»
    Un’altra:
    «there is a very good news. As a workaround, rather than blacklisting ehci_hcd alltogether (that results in the loss of support for USB 2 peripherals), one can just selectively disable it on some hubs.
    For instance, in my case, I can
    sudo sh -c “echo -n 0000:04:00.2 > /sys/bus/pci/drivers/ehci_hcd/unbind”
    and get my umts thing working. In principle it should not be too difficult to do it automatically when the device is detected.»

    Però poi, in un post seguente, si legge:
    «I have tried both, blacklisting ehci_hcd module, disabling it on the hub and unloading it manually. It all didn’t work. Ehci_hcd module seems to be reloading automatically each time. For instance taking the card off the laptop, unloading the module, putting it back again gives following dmesg|tail output:
    [...
    dall'output risulta che viene usato ohci_hcd...]
    But when I then unplug it and replug it ehci_hcd is back on place!»

    *** 29 Luglio 2008 *** (riguardo alla citazione qui sopra)
    Rimuovere ehci_hcd “a mano”, con modprobe -r o con rmmod, prima che la scheda venga inserita è un’operazione che non serve (anzi: serve solo a far perdere l’uso dell’USB 2.0), perché verrebbe ricaricato da udev nel momento in cui fosse inserita la scheda. Se ehci_hcd viene rimosso “a mano” dopo che la scheda è stata inserita, affinché questa possa funzionare, la sua ricomparsa è spiegabile tenendo presente che la scheda contiene uno Hub USB 2.0: quando la scheda viene tolta, le interfacce che il kernel aveva assegnato agli host dell’Hub (e che venivano controllati da uhci_hcd) scompaiono; quando viene reinserita le interfacce vengono ricreate e non c’è motivo per cui, venendo il dispositivo riconosciuto come USB 2.0, udev non carichi il modulo ehci_hcd; quello che invece non riesco a spiegare è perché (se ho capito bene) ehci_hcd ricompaia anche quando è blacklistato, o quando è stato fatto l’unbinding manuale dell’interfaccia relativa al Bus USB 2.0 della scheda: il blacklisting, infatti, impedisce il caricamento in automatico del modulo non solo all’avvio, ma anche per gli eventi di hotplug, mentre l’unbinding resta valido sino a che il PC non viene riavviato e quindi la scheda può essere tolta e reinserita più volte senza che venga caricato in automatico ehci_hcd.
    In un modo o nell’altro, mi resta poco chiaro il contenuto della citazione di cui sopra.

    30 Luglio 2008 (quanto segue è da verificare)
    1) Se la scheda non è inserita, non sono state create le interfacce per gli host USB al suo interno e quindi, anche se ehci_hcd viene rimosso (e quindi viene deregistrata l’interfaccia assegnata al Bus USB del PC controllato dal driver EHCI), verrà poi ricaricato in automatico quando la scheda verrà inserita (e quindi quando verrà creata e assegnata ad esso la nuova interfaccia per il Bus USB 2.0 interno alla scheda e verrà anche registrata, cioè associata a EHCI, l’interfaccia del Bus USB 2.0 del PC che prima era stata deregistrata).
    2) Se il modulo ehci_hcd è blacklistato, non può venire caricato in automatico da udev, ma soltanto “manualmente” con modprobe (o insmod).
    In buona sostanza: ehci_hcd viene caricato in automatico da udev solo se:
    1) non è blacklistato
    … e…
    2) ogni volta che la scheda viene inserita (perché quando la scheda non c’è –o perché è stata estratta, o perché dal momento del boot non è stata inserita– non esistono neppure le interfacce che il sistema di hotplug del kernel crea per comunicare con gli host USB al suo interno); inoltre, ehci_hcd non può essere caricato in automatico se è presente la regola di udev che fa l’unbinding di ehci_hcd dalla specifica interfaccia per il Bus 2.0 interno alla scheda; se vengono rispettate queste condizioni non è possibile che ehci_hcd ricompaia come per miracolo.
    MA ALLA FINE… ecco il vero e definitivo WORKAROUND:
    Sergio Callegari offre la soluzione elegante tanto attesa che aggira il bug:
    ==> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/129433/comments/10
    ==>… basata sull’unbindig tra ehci_hcd e la specifica interfaccia alla quale altrimenti verrebbe associato.

    … CONTINUA …                     … CONTINUA …                     … CONTINUA …

    Commentato da 5m33 | luglio 22, 2008, 11:41 |
  11. … SEGUE DAL PRECEDENTE…                     … SEGUE DAL PRECEDENTE…                     … SEGUE DAL PRECEDENTE…

    AlexT scrive:

    Ho letto il post 5m33,
    e ti chiedo cortesemente un chiarimento in merito:
    parlando di driver di alto e basso livello, se ricompilassi uno dei files di cui ho parlato nel precedente post (airprile.c/usbserial.c/quellochesia.c) inserendo la riga che permette il riconoscimento del vendorID:productID, rischierei comunque che la scheda non mi venga riconosciuta per via del fatto che il driver di livello più basso(ehci_hcd) viene caricato da UDEV?
    Nello stesso periodo mi dici anche che questo problema dovrebbe essere stato corretto nelle ultime versioni del kernel. Nel mio portatile dispongo del kernel 2.6.24-19 il bug invece era presente nel 2.6.22. Se così dovesse essere il problema non dovrei più averlo o per versione si intende un 2.7…../3.0…..?
    Inoltre nello stesso sito sul quale scrive Sergio Callegari ho visionato la lista dei bug aperti per la 2.6.24 e tra questi non c’era.
    Terza e ultima domanda leggendo qua e la mi è parso di capire che il driver di alto livello airprime.c gestisca meglio/sia più performante per le connessioni hsdpa. É vero tutto questo? se si a valle della soluzione elegante consigliata da Sergio Callegari sarà meglio associare il dispositivo al modulo suddetto o lasciar fare al sistema?
    Nei prossimi giorni proverò la soluzione del workaround di Sergio Callegari, poi posterò il commento finale.
    Al momento ringrazio per tutte le dritte e la professionalità che mi state dimostrando.

    AlexT


    Skumpic scrive:

    Ciao Alext e 5m33, in attesa di approfondire meglio la questione volevo solo informarvi che stamattina ho avuto modo di testare la pc-card della mia ragazza sulla mia ubuntu 8.04 è posso confermare il “malfunzionamento” o “mal riconoscimento”: vengono aggiunti 3 host usb con id 0000
    Con calma mi leggo i vostri ultimi interventi e poi provo le soluzioni che avete suggerito

    Ps. Sulla 7.04 andava tutto perfettamente!!!! :(

    ciao
    SKumpic


    AlexT scrive:

    …quarta e ultima domanda:
    É possibile associare l’identificazione della pccard attraverso l’indirizzo della porta fisica?


    5m33 scrive:

    (Testo REVISIONATO da ultimo il 29 Luglio 2008)

    @ AlexT
    ——–

    parlando di driver di alto e basso livello, se ricompilassi uno dei files di cui ho parlato nel precedente post (airprile.c/usbserial.c/quellochesia.c) inserendo la riga che permette il riconoscimento del vendorID:productID, rischierei comunque che la scheda non mi venga riconosciuta per via del fatto che il driver di livello più basso(ehci_hcd) viene caricato da UDEV?

    Sicuramente la scheda non verrebbe riconosciuta, in quanto il driver (di basso livello) ehci_hcd sbarra la strada a ogni altra operazione del kernel con riferimento alla scheda.
    Quindi, da quanto dici, attualmente non c’è alcun driver che riconosca in automatico il modem di questa PC-Card della Onda?
    Voglio dire: dopo che hai scaricato ehci_hcd e che la PC-Card ti è stata riconosciuta come modem della Qualcomm non viene anche attivato automaticamente un driver per pilotarla come modem?

    (controllerò anch’io, comunque: naturalmente posso farlo solo cercando informazioni sul Web, visto che non ho la PC-Card per provare)

    *** 29 Luglio 2008 ***
    Il driver caricato in automatico è il sierra
    ************

    Nello stesso periodo mi dici anche che questo problema dovrebbe essere stato corretto nelle ultime versioni del kernel.

    Mi riferivo all’associazione (binding) alla scheda del driver per la gestione del Bus: Con i kernel fino al 2.6.24 per sbloccare la situazione è necessario scaricare a mano ehci_hcd, oppure utilizzare una regola ad-hoc di udev che ne faccia l’unbinding rispetto alla specifica interfaccia USB alla quale altrimenti lo assocerebbe (quest’ultimo è il workaround di Callegari). Una volta scaricato a mano il driver ehci_hcd, o una volta che ne è stato fatto l’unbind, il kernel provvede da solo a fare in modo che lo Hub USB della scheda possa essere gestito: rimappa gli host USB interni alla scheda su interfacce di comunicazione USB assegnate al driver uhci_hcd (o al driver ohci_hcd) e, in tal modo, arriva all’idVendor e all’idProduct del modem, riconoscendolo come device con un chipset della Qualcomm. Con le ultime versioni del kernel, dalla 2.6.25 in poi, dovrebbe essere stato introdotto un meccanismo di fallback per cui se la comunicazione con un device mediante un determinato driver non va a buon fine, il device viene rimappato su un’interfaccia controllata da un driver “supplente”: nel nostro caso della scheda dell’Onda, quindi, non dovrebbe essere più necessaria alcuna rimozione manuale del modulo ehci_hcd, né alcun workaround, perché il kernel dovrebbe provvedere da solo a tentare se la comunicazione riesce utilizzando uhci_hcd (od ohci_hcd).

    A questo punto, se nel sistema ci fosse un driver per modem in grado di essere richiamato da udev in associazione ai codici idVendor e idProduct del modem della scheda, questo potrebbe essere finalmente pilotato.

    *** 29 Luglio 2008 ***
    … il driver è, appunto, il sierra
    ************

    I driver “di basso livello” sono quello per il Bus PCI (driver che qui non ci interessa), e quello (ehci_hcd, oppure uhci_hcd, oppure ohci_hcd) che gestisce il Bus USB che poggia sul Bus PCI. I driver “di alto livello” sono quelli che pilotano il circuito del modem contenuto nella scheda, cioè –in parole povere [*]– che gestiscono il corretto input per la scheda.

    *** 5 Luglio 2008 ***
    [*] Come precisato in un commento successivo, le schede modem 3G sono tutte in grado di comprendere direttamente i comandi del set Hayes (cosiddetti “comandi AT”): non occorre un driver che si occupi di “tradurli”.
    ************
    *** 29 Luglio 2008 ***
    I driver “di alto livello” sierra viene caricato in automatico dopo che il kernel riesce a comunicare con la scheda, cioè dopo aver rimosso il modulo ehci_hcd, o dopo (e questo è il workaround di Callegari) aver fatto in modo che il modulo ehci_hcd non venga associato all’interfaccia di comunicazione con la scheda (unbinding di ehci_hcd selettivo codici di “device” e di “vendor” della scheda).
    ************

    Nel mio portatile dispongo del kernel 2.6.24-19 il bug invece era presente nel 2.6.22. Se così dovesse essere il problema non dovrei più averlo o per versione si intende un 2.7…../3.0….?

    Il bug è stato introdotto per la prima volta (credo) nella versione 2.6.22 ed è tuttora presente nella 2.6.24-19. Per cambio di “versione” si intende la modifica del numero, numero che individua la release del kernel (ci sarebbe da distinguere fra “minor release” e “major release”, ma soprassediamo). Fatto sta che, se coloro che sviluppano il kernel –e, in particolare, coloro che sviluppano quella parte del kernel che consiste nel sistema “udev” per il riconoscimento delle periferiche– correggono il bug, con una prossima versione del kernel la scheda della Onda dovrebbe funzionare a dovere. Ma può anche darsi che la diatriba sulla “responsabilità” del malfunzionamento sia proprio fra gli sviluppatori del kernel Linux e quelli dei chip della scheda. In tal caso, non resta che adottare il workaround di cui parliamo.

    *** 5 Luglio 2008 ***
    In effetti, parrebbe che il malfunzionamento del kernel con la scheda dell’Onda non sia stato considerato un vero e proprio bug, in quanto non sarebbe responsabilità del modulo ehci_hcd, ma della scheda Onda (cioè del modo in cui le specifiche USB 2.0 sono state implementate in detta scheda). Fatto sta (e questo “taglia la testa al toro”) che nella versione 2.6.25-rc del kernel mi risulta esista un meccanismo di fallback per cui un device, se non funziona col driver che parrebbe il più adatto, viene assegnato a un driver supplente e quindi, sempre che un driver supplente esista, il funzionamento del device resta possibile (anche se potrebbero esserci delle defaillance dovute al fatto che è pilotato da un driver preso in sostituzione di quello considerato più adatto). Nel “nostro” caso, il driver supplente di ehci è uhci (od ohci) e, siccome la periferica è un modem che allo stato dell’arte può raggiungere al massimo la velocità di 7.2 Mbit/sec, il driver uhci (od ohci), che può gestire velocità di 12 Mbit/sec, non comporterà certo defaillance. Semmai, queste possono derivare dai driver per il modem: usbserial (che non è un driver apposito per i modem, ma è un driver generico che, in quanto tale, può pilotare qualunque periferica seriale connessa via USB, anche se le prestazioni possono non essere ottimali), airprime, option, sierra, ecc.
    ************

    Il workaround ( https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/129433/comments/10 ) elaborato da Sergio Callegari [*] è dell’Aprile di quest’anno ed è migliore del fix ( https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/129433/+viewstatus ) già fornito da Tim Gardner [**].

    ——————-
    [*]
    Dr. Sergio Callegari
    Researcher and Assistant Professor
    School of Engineering II
    University of Bologna

    Affiliated with:
    DEIS – Dept. of Electronics, Computer Sciences and Systems,
            University of Bologna (www.deis.unibo.it)
    ARCES – Advanced Research Center on Electronic Systems for
            Information and Communication Technologies
            University of Bologna (www.arces.unibo.it)
    ——————-

    30 Luglio 2008

    [**]——————-
    Il fix fornito da Tim Gardner è il seguente:
    As an hack, the correct behaviour can be obtained by blacklisting the ehci_hcd for instance in /etc/modprobe.d/blacklist-modem.
    When the ehci_hcd is blacklisted everything works correctly and the ONDA Wireless UMTS PC-CARD gets perfectly usable.

    ——————-

    Inoltre nello stesso sito sul quale scrive Sergio Callegari ho visionato la lista dei bug aperti per la 2.6.24 e tra questi non c’era.

    Il bug non risulta fra quelli aperti, perché è classificato come “fixed”. I motivi per cui venga considerato come “fixed” risiedono, probabilmente, sia nel fatto che ehci_hcd mi pare sia ancora (bah…) da ritenersi come un modulo sperimentale, sia perché (e questo motivo può essere collegato al fatto che il modulo ehci_hcd è –forzatamente?– considerato sperimentale) non è chiaro se la “colpa” sia da attribuirsi al modo in cui la scheda, che si presenta al kernel come USB 2.0, implementa le specifiche dell’USB 2.0, oppure sia da attribuirsi a un vero e proprio errore interno a ehci_hcd (e su questo mi pare lecito dubitare). Ciò forse spiega anche perché non venga neppure considerato come un bug importante (è taggato come di bassa importanza).

    Terza e ultima domanda leggendo qua e la mi è parso di capire che il driver di alto livello airprime.c gestisca meglio/sia più performante per le connessioni hsdpa. É vero tutto questo? se si a valle della soluzione elegante consigliata da Sergio Callegari sarà meglio associare il dispositivo al modulo suddetto o lasciar fare al sistema?

    Se il sistema non carica da solo il modulo (sierra, option, airprime…) per gestire la scheda come modem seguendo la soluzione già da te adottata, cioè scaricando “a mano” il modulo ehci_hcd (e dando così modo a uhci_hcd di entrare in funzione)…

    *** 29 Luglio 2008 ***
    … ma invece carica in automatico il driver sierra
    ************

    …allora non lo carica da solo neppure con la soluzione di Callegari, che evita che il driver ehci_hcd venga assegnato all’interfaccia di comunicazione con la scheda N501HS. In altri termini: la soluzione di Callegari sistema il problema del driver “di basso livello”, mentre se poi non viene caricato automaticamente un driver “di alto livello” siamo davanti a un problema di ordine diverso, ma anche questo risolvibile.

    Maggiori info su questo e sul resto qui, entro breve.


    5m33 scrive:

    (Testo REVISIONATO da ultimo il 29 Luglio 2008)

    É possibile associare l’identificazione della pccard attraverso l’indirizzo della porta fisica?

    : è cioè possibile evitare selettivamente che ehci_hcd sia associato all’interfaccia di comunicazione con l’host USB, che dà problemi, interno alla PC-Card, piuttosto che disabilitato completamente.

    Analizziamo la soluzione fornita da Callegari ( https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/129433/comments/10 ).

    Primo passo
    ——————

    Crea un file con la regola di udev che deve applicarsi al device identificato con…
    ATTRS{vendor}=="0x1131" e ATTRS{device}=="0x1562"
    … regola che fa eseguire uno script:
    /usr/local/sbin/fix-onda-n501hs

    A questo script, Callegari passa come parametro l’identificativo dell’interfaccia di comunicazione col device, identificativo che preleva con l’opzione di udev “%b” (opzione che fornisce il valore restituito anche da “$id“).

    ———————
    Da man udev:
    $id, %b
    The name of the device matched while searching the devpath upwards for SUBSYSTEMS, KERNELS, DRIVERS and ATTRS.

    ———————

    Cit. dal workaround elaborato da Callegari: Primo passo
    ——————————————————————————–

    Put a file named 50-fix-onda-n501hs.rules in /etc/udev/rules.d with the following content

    # udev rule for ONDA N501HS
    ACTION=="add", SUBSYSTEM=="pci", \
    ATTRS{vendor}=="0x1131", \
    ATTRS{device}=="0x1562" \
    RUN+="/usr/local/sbin/fix-onda-n501hs %b"

    Secondo passo
    ———————–

    Il contenuto per noi significativo dello script che si trova nel file fix-onda-n501hs è il seguente:

    Cit. da workaround elaborato da Callegari: Secondo passo
    ——————————————————————————–

    [...]

    pciid=$1
    [...]
    ( sleep $DELAY ; echo -n $pciid > /sys/bus/pci/drivers/ehci_hcd/unbind
    [...]
    ) &

    Questo script prende ($1) il valore passatogli come parametro (%b), che consiste nell’identificativo dell’interfaccia, e con tale valore istanzia la variabile “pciid”. La variabile “pciid“, a tal punto, rappresenta l’interfaccia di comunicazione col device che che dà problemi e, quindi, l’identificativo dell’interfaccia viene scritto nel file di unbinding. Il risultato sarà che quell’interfaccia PCI non verrà gestita mediante il driver ehci_hcd (e, di conseguenza, il device verrà rimappato su un’interfaccia assegnata al driver “supplente” uhci_hcd, od ohci_hcd).

    Provo a fare la stessa cosa, quasi un esercizio, col mio cellulare Nokia 6120.

    Per risalire all’identificativo dell’interfaccia di comunicazione col cellulare, collegato al PC via USB, posso prima identificare il cellulare mediante idVendor e idProduct e poi chiedere a udev di risalire verso il “parent” del device così individuato.

    Dunque:
    il comando…
    lsusb
    … restituisce il seguente output:

    Bus 003 Device 002: ID 0421:002f Nokia Mobile Phones
    [...]

    “0421″ è l’idVendor, mentre “002f” è l’idProduct.

    Dall’output di lsusb sappiamo così che il telefonino è stato riconosciuto come device numero 2 del Bus USB numero 3.
    Con questa informazione, possiamo reperire l’identificativo assegnato dal kernel all’interfaccia di comunicazione col telefonino:

    Il comando…
    udevinfo --attribute-walk --path=/sys/class/usb_device/usbdev3.2
    … restituisce il seguente output:

    Udevinfo starts with the device specified by the devpath and then
    walks up the chain of parent devices. It prints for every device
    found, all possible attributes in the udev rules key format.
    A rule to match, can be composed by the attributes of the device
    and the attributes from one single parent device.

    looking at device ‘/devices/pci0000:00/0000:00:1d.2/usb3/3-1′:
    KERNEL==”3-1″
    SUBSYSTEM==”usb”
    DRIVER==”usb”
    ATTR{configuration}==”Bulk transfer method configuration”
    ATTR{product}==”Nokia 6120 classic”
    ATTR{manufacturer}==”Nokia”
    ATTR{maxchild}==”0″
    ATTR{version}==” 2.00″
    ATTR{devnum}==”2″
    ATTR{speed}==”12″
    ATTR{bMaxPacketSize0}==”64″
    ATTR{bNumConfigurations}==”1″
    ATTR{bDeviceProtocol}==”00″
    ATTR{bDeviceSubClass}==”00″
    ATTR{bDeviceClass}==”02″
    ATTR{bcdDevice}==”0100″
    ATTR{idProduct}==”002f” // questo è l’idProduct del modello 6120
    ATTR{idVendor}==”0421″ // questo è l’idVendor della Nokia
    ATTR{bMaxPower}==” 20mA”
    ATTR{bmAttributes}==”c0″
    ATTR{bConfigurationValue}==”1″
    ATTR{bNumInterfaces}==”14″

    looking at parent device ‘/devices/pci0000:00/0000:00:1d.2/usb3′:
    KERNELS==”usb3″
    SUBSYSTEMS==”usb”
    DRIVERS==”usb”
    ATTRS{configuration}==””
    ATTRS{serial}==”0000:00:1d.2″
    ATTRS{product}==”UHCI Host Controller”
    ATTRS{manufacturer}==”Linux 2.6.18.8-0.9-default uhci_hcd”
    ATTRS{maxchild}==”2″
    ATTRS{version}==” 1.10″
    ATTRS{devnum}==”1″
    ATTRS{speed}==”12″
    ATTRS{bMaxPacketSize0}==”64″
    ATTRS{bNumConfigurations}==”1″
    ATTRS{bDeviceProtocol}==”00″
    ATTRS{bDeviceSubClass}==”00″
    ATTRS{bDeviceClass}==”09″
    ATTRS{bcdDevice}==”0206″
    ATTRS{idProduct}==”0000″
    ATTRS{idVendor}==”0000″
    ATTRS{bMaxPower}==” 0mA”
    ATTRS{bmAttributes}==”e0″
    ATTRS{bConfigurationValue}==”1″
    ATTRS{bNumInterfaces}==” 1″

    looking at parent device ‘/devices/pci0000:00/0000:00:1d.2′:
    KERNELS==”0000:00:1d.2″ // questo è l’identificativo dell’interfaccia di comunicazione
    SUBSYSTEMS==”pci”
    DRIVERS==”uhci_hcd” // questo è il DRIVER (USB) associato all’interfaccia
    ATTRS{broken_parity_status}==”0″
    ATTRS{enable}==”1″
    ATTRS{modalias}==”pci:v00008086d000024C7sv00001043sd00001748bc0Csc03i00″
    ATTRS{local_cpus}==”ffffffff”
    ATTRS{irq}==”4″
    ATTRS{class}==”0x0c0300″
    ATTRS{subsystem_device}==”0×1748″
    ATTRS{subsystem_vendor}==”0×1043″
    ATTRS{device}==”0x24c7″ // questo è primo parametro attraverso il quale avviare una regola di udev da riferirsi all’identificativo dell’interfaccia PCI
    ATTRS{vendor}==”0×8086″// questo è secondo parametro attraverso il quale avviare una regola di udev da riferirsi all’identificativo dell’interfaccia PCI

    looking at parent device ‘/devices/pci0000:00′:
    KERNELS==”pci0000:00″
    SUBSYSTEMS==””
    DRIVERS==””

    La soluzione di Callegari si è concentrata, appunto, sul driver che viene caricato automaticamente dal sistema per gestire l’interfaccia di comunicazione con l’host USB interno alla scheda che si trova a monte del chipset del modem. E’ questo, infatti, il motivo per cui non è sufficiente impostare una regola di udev che si attivi in presenza dell’idProduct e dell’idVendor del circuito del modem. Bisogna che a monte di questo non venga neppure caricato il driver (che qui chiamiamo “di basso livello”) ehci_hcd che serve per gestire la comunicazione col Bus USB della scheda. Altrimenti, il driver ehci_hcd, visto che con la scheda dell’Onda non funziona, impedisce a udev di procedere oltre, impedendo di conseguenza anche che siano rilevati l’idVendor e l’idProduct del circuito del modem e quindi impedendo anche che un’eventuale ulteriore regola di udev scritta ad-hoc con riferimento all’idVendor e all’idProduct del modem –per esempio, una regola che eseguisse modprobe usbserial vendor="0x..." product="0x..."– possa entrare in azione).

    Se, tornando al mio esercizio col Nokia, per un qualche motivo mi servisse fare in modo che il driver uhci_hcd non venisse più associato all’interfaccia assegnata dal kernel al Bus di comunicazione col Nokia 6120, dovrei scrivere l’identificativo dell’interfaccia, e cioè… “0000:00:1d.2“…
    nel file…
    /sys/bus/pci/drivers/uhci_hcd/unbind

    *** 29 Luglio 2008 ***
    Ma un’eventuale regola di udev che scrivesse in /sys/bus/pci/drivers/uhci_hcd/unbind l’identificativo dell’interfaccia 0000:00:1d.2 sarebbe eseguita soltanto al boot, in quanto, nel mio caso (a differenza di quello della scheda dell’Onda) lo Hub USB è quello del PC (non un circuito interno a una periferica “pluggable”) e, quindi, viene rilevato soltanto all’avvio del PC. Su questo, vedi l’aggiornamento del 26 Luglio 2008 all’inizio di questo thread
    *******************
    *** 5 Luglio 2008 ***
    Una volta fatto l’unbind fra il driver e la specifica interfaccia PCI, udevd interverrebbe cercando di assegnare a quest’ultima un altro driver.
    ************
    *** 29 Luglio 2008 ***
    In questo caso del Nokia, preso come esempio, però, a differenza dell’unbinding di ehci_hcd (caso della scheda Onda), non esisterebbe alcun driver in grado di supplire all’assenza di uhci_hcd (che è il driver assegnato alla periferica) e quindi se, in ipotesi, formulassi una regola per udev selettiva, che evita cioè l’assegnazione di uhci_hcd proprio all’interfaccia di comunicazione assegnata al Nokia, quest’ultimo non potrebbe più comunicare col PC (e qualsiasi ulteriore periferica USB 1.1 (cioè controllata da uhci_hcd) collegata all’interfaccia di quella specifica porta USB non potrebbe funzionare).
    *******************

    L’identificativo dell’interfaccia PCI è il valore che il workaround di Callegari estrae mediante udev e passa come parametro allo script /usr/local/sbin/fix-onda-n501hs.

    Nell’esperienza di Callegari l’identificativo dell’interfaccia è:
    0000:04:00.2
    (ricavato da alcuni output riprodotti da Callegari)

    Naturalmente, una volta individuato quale sia l’identificativo dell’interfaccia, il valore per l’unbinding del driver ehci_hcd potrebbe anche essere scritto nel file…
    /sys/bus/pci/drivers/ehci_hcd/unbind
    … mediante il comando…
    echo -n 0000:04:00.2 > /sys/bus/pci/drivers/ehci_hcd/unbind
    … ma questa operazione “manuale” sarebbe efficace solo fino allo shut down, perché il filesystem di udev (sysfs), al cui interno si trova il file per l’unbinding, viene ricreato ex novo a ogni riavvio del sistema.

    IN ESTREMA SINTESI, il workaround di Callegari consiste nel rilevare quale sia l’identificativo di interfaccia assegnato dal kernel all’host USB 2.0 interno alla scheda dell’Onda (per ottenerlo si può procedere in vari modi) e nell’evitare che il driver ehci_hcd venga associato a tale interfaccia.


    5m33 scrive:

    (Testo REVISIONATO da ultimo il 29 Luglio 2008)

    @ AlexT
    ———————–

    Una volta che hai inserito la scheda dell’Onda, controlla l’identificativo dell’interfaccia PCI-USB.

    Nel filesystem (sysfs) creato da udev e montato in /sys dovresti avere:

    /sys/bus/pcmcia/devices/

    E lì dovresti avere una sola directory corrispondente alla scheda e contenente tutti i parametri che puoi far estrarre dal comando udevinfo.

    *** 30 Luglio 2008 *** (da verificare)
    Probabilmente non ne avrà solo una di directory, perché la scheda contiene uno Hub USB con 3 porte e quindi dentro /sys/bus/pcmcia/devices/ dovrebbero esserci le directory corrispondenti alle porte USB della scheda.
    *******************

    Per esempio, io inserendo una scheda modem nello slot PCMCIA, col comando udevinfo…

    udevinfo --attribute-walk --path=/sys/bus/pcmcia/devices/0.0

    ATTENTO alle due lineette in sequenza prima di “attribute-walk” e di “path” (e, ovviamente, la subdirectory “0.0″ dev’essere eventualmente denominata come appare nel tuo sistema: per vederla fai ls /sys/bus/pcmcia/devices

    … ottengo tutte le informazioni che servono.

    Tu, con la scheda dell’Onda, nella sequenza di informazioni dell’output di udevinfo con riguardo alla path in cui si trova il driver ehci_hcd [*] troverai anche l’identificativo dell’interfaccia PCI e i parametri di “device” e di “vendor” che Callegari ha inserito nella regola di udev per passare tale identificativo allo script lanciato da udev stesso, script che va a scrivere così l’identificativo nel file…
    /sys/bus/pci/drivers/ehci_hcd/unbind

    [*]
    Velocemente:
    digita il comando lsusb
    lo schema dell’output è:
    Bus “X” Device “Y“: ID “idVendor”:”idProduct”
    … da cui ricavi il numero di Bus e il numero di Device da usarsi nel comando seguente:
    udevinfo --attribute-walk --path=/sys/class/usb_device/usbdevX.Y

    5m33 scrive:

    (Testo REVISIONATO da ultimo il 29 Luglio 2008)

    Per quanto riguarda il driver “di alto livello” (qui ho scelto di chiamarlo così), cioè quello per pilotare il chip del modem contenuto nella PC-Card della Onda, credo che nessun modulo diverso dal sierra (che viene caricato in automatico, perché è quello che udev associa alla scheda) possa essere usato senza una patch che permetta di associarlo all’idVendor e all’idProduct del chipset modem della PC-Card.

    I driver che permettono di raggiungere la velocità dell’HSDPA sono sierra, airprime, option e altri [*].
    usbserial è un driver generico che può essere abbinato velocemente all’idVendor e all’dProduct del chipset del modem contenuto nella PC-Card, cioè senza che il sorgente debba essere patchato e ricompilato, ma, non essendo un driver espressamente pensato per i modem, presenta il grosso problema del buffer limitato, per cui, senza patcharlo e ricompilarlo per questo aspetto, vai al massimo a 650 Kbit/sec.

    Comunque io, una volta sistemato il problema dell’ehci_hcd col workaround di Callegari, farei una prova con usbserial:

    modprobe usbserial vendor=0×05C6 product=0×6613

    [*]
    Posso fornire, nell’arco dei prossimi giorni, dei riferimenti (URL) che spiegano come patcharli per utilizzarli con la scheda dell’Onda in questione.

    AlexT scrive:

    Ciao 5m33,
    proverò, come già detto durante il weekend, a fare le prove proposte dal Callegari.
    Allo stato attuale confermo che il driver di alto livello che viene in automatico associato alla Onda è il Sierra.
    É mia espressa curiosità verificare le velocità del DownLink con i diversi driver ergo, credo che durante il weekend mi divertirò ad utilizzarli tutti.
    Da Lunedì prossimo dovrei poter postare qualcosa.
    Direi che anche skunpic potrebbe effettuare le stesse prove, sempre che non le abbia già effettuate e restituirci un feedback a riguardo.
    Relativamente ai riferimenti per patchare il modulo Airprime.c puoi leggere qui:
    http://www.openlinux.eu/content/view/147/
    oppure:
    http://divilinux.netsons.org/index.php/archives/709


    5m33 scrive:

    Relativamente ai riferimenti per patchare il modulo airprime.c puoi leggere qui:
    http://www.openlinux.eu/content/view/147/
    oppure:
    http://divilinux.netsons.org/index.php/archives/709

    Ce ne sono altri: prima di partire con le prove aspetta/aspettate che abbia riordinato un minimo gli URL che ho e che elencherò qui.
    Anzi, dò un’occhiata subito e magari ce la faccio.

    il driver di alto livello che viene in automatico associato alla Onda è il Sierra.
    É mia espressa curiosità verificare le velocità del DownLink con i diversi driver ergo, credo che durante il weekend mi divertirò ad utilizzarli tutti.

    Splendido: questo post diventerebbe così un riferimento che dà lo stato dell’arte in relazione a questa scheda dell’Onda.

    Ho alcune informazioni in merito al funzionamento con questa scheda del driver sierra e anche di altri. Le pubblico al più presto.


    Sergio Callegari scrive:

    Cari tutti,

    Mi ha scritto 5m33, segnalandomi il thread. Sono contento se la soluzione che ho proposto sul sito di ubuntu vi è di aiuto.

    Purtroppo non sono stato in grado di testarla su kernel più recenti del 2.6.22 perché il 2.6.24 di hardy manda saltuariamente in hard lockup un mio pc che andava perfettamente con il 2.6.22 e quindi non mi azzardo a fare l’upgrade del portatile che mi serve per lavoro.

    In ogni caso, l’idea è questa:

    1) Le schede onda, PCMCIA contengono un interfaccia host USB a cui a sua volta è connesso internamente il “modem” HSDPA (e viene da chiedersi perché non abbiano fatto un dispositivo USB direttamente).

    2) Quando si inserisce la scheda, il S.O . dovrebbe vedere un’interfaccia host USB connessa al bus PCI (via PCMCIA) e poi il modem connesso al bus USB di tale interfaccia.

    3) L’interfaccia USB presente sulla scheda si dichiara high speed capable.

    4) Il modem connesso a tale interfaccia pure si dichiara high speed capable.

    5) Conseguentemente il S.O. cerca di farli dialogare in high-speed.

    6) Ma fallisce, perché la scheda in realtà non implementa correttamente lo standard USB 2 (non si sa se per colpa dell’interfaccia USB o della periferica USB). Fatto sta che il kernel “vede” un collegamento mal funzionante tra l’interfaccia USB e la periferica USB “modem” HSDPA.

    7) Quindi il workaround per far comunicare l’interfaccia USB e la periferica USB consiste nell’obbligare il kernel a non usare il driver ehci per tale interfaccia USB (che appare come periferica sul bus PCI del sistema).

    8) Per fortuna, linux consente un “unbinding” selettivo del driver ehci, quindi è possibile dire al driver ehci di non gestire mai una certa interfaccia USB.

    9) Quello che nei messaggi del thread chiamate “driver di basso livello” è in realtà il driver dell’interfaccia USB.

    10) Dal 2.6.25 (o forse 2.6.26) non dovrebbe esserci più bisogno di alcun workaround. Infatti il kernel sarà in grado di ritentare automaticamente una connessione in full-speed quando fallisce in high-speed.

    11) Una volta che si riesce a dialogare con la periferica USB, occorre un driver per quest’ultima (quello che viene chiamato nel thread driver di alto livello).

    12) Il modem USB viene visto come l’insieme di 3 interfacce seriali. In teoria quindi usbserial dovrebbe bastare. In realtà funziona, ma non è del tutto adeguato, perché usbserial è un driver generico e non adatto a gestire i data rate necessari in una connessione HSDPA.

    13) Chi sviluppa driver ha “deciso” di affidare il modem USB della schedina ONDA al driver OPTION. Non è un fulmine di guerra perché è conservativo per quanto riguarda buffering e flow control, ma va bene.

    14) Ci sono altri driver che “apparentemente” potrebbero funzionare con la scheda (a patto ovviamente di inserire nel driver la “signature” della scheda). Per esempio il driver sierra.

    15) Attenzione tuttavia ad utilizzare driver diversi dall’option. Chi sviluppa i driver si aspetta bug report per l’option se ci sono cose che non vanno. Inoltre, alcuni driver (tipo il sierra) hanno problemi di flow control, per cui fin che il flusso di dati è dalla rete verso il PC (download), tutto bene, ma quando è dal PC verso la rete (upload) la scheda può andare in freeze.

    Ciao

    Sergio


    5m33 scrive:

    Grazie 1000, Sergio, per l’intervento. Ci sono consigli molto utili e, a questo punto, tutto ciò che di ulteriore si può dire appare (anzi: è) superato :-)
    Direi che questa è “the ultimate word

    Inserisco comunque, nel commento seguente, i riferimenti (risorse web) che stavo preparando perché riguardano anche altre schede: un’attenzione particolare dovrebbe essere prestata alle date, visto che per restare “up to date” bisogna controllare con riferimento alla singola versione del kernel (2.6.18 piuttosto che 2.6.22… 2.6.24 e… dulcis in fundo –si spera– 2.6.25)

    AlexT: attendiamo la tua prova sul campo !!!


    5m33 scrive:

    >>>>>>>>>>>>>>>>>>>>>>>>> INIZIO ELENCO < <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

    Già da un po’ di tempo a questa parte gli sviluppatori dei driver per i modem 3G hanno aumentato la dimensione del buffer da 64 bytes (la dimensione problematica) a 2048 e anche a 4096 bytes.

    I driver specifici per i modem UMTS option, airprime, sierra e altri associati ai kernel della serie 2.6, nelle ultime versioni sono già adeguati alle velocità attuali dei modem 3G.

    Il driver usbserial, che è generico per i dispositivi USB che comunicano su linea seriale, ha tuttora un buffer di 64 bytes e quindi, per poterlo usare con un modem 3G alla velocità massima raggiungibile occorre patchare il sorgente per ampliare il buffer del driver in modo che possa raggiungere la massima velocità dell HSDPA e poi ricompilarlo.

    * “Come sfruttare in Linux la piena capacità dei modem HSDPA” (Ottobre 2007)
    http://www.openlinux.eu/index.php?option=content&task=view&id=147
    – parla della patch per usbserial per ampliarne il buffer e della patch in airprime per fare in modo che sia associato a modem originariamente non supportati.

    * “GPRS/UMTS/HSDPA USB su Linux – ONDA M1HS” (Agosto 2007)
    http://www.openlinux.eu/content/view/124/39/
    – spiega come utilizzare il modem USB Onda M1HS con usbserial: idVendor e idProduct sono i medesimi del modello N501HS: vendor=0x05c6 e product=0×6613

    * “Come far funzionare una ONDA N501HS?” (fine 2007 – inizio 2008)
    http://www.slacky.eu/forum/viewtopic.php?f=1&t=22185&start=15
    – problemi nel far funzionare la scheda anche con usbserial ???
    (notare che da Slackware la scheda viene associata al driver di basso livello ohci_hcd e di conseguenza non si presenta il problema, di cui al “nostro” thread, legato al driver ehci_hcd)

    * “Onda N501HS” (inizio 2008)
    http://www.openlinux.eu/component/option,com_fireboard/Itemid,66/func,view/catid,5/id,1098/
    Linux 2.6.22.13-0.3-default ehci_hcd
    – questo utilizzatore si è scontrato con lo stesso problema discusso nel “nostro” thread: il kernel della SuSE 10.3 (2.6.22.13-0.3) riconosce la scheda come USB 2.0 e quindi carica il driver “ehci_hcd”: a quel punto (come già sappiamo fin troppo bene) l’identificazione della parte modem della scheda fallisce:

    ehci_hcd 0000:07:00.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
    usb usb7: new device found, idVendor=0000, idProduct=0000

    * “Scheda UMTS ONDA N501HS e Linux” (Novembre 2007)
    http://vfoschi.wordpress.com/2007/11/23/scheda-umts-onda-n501hs-e-linux/
    – l’autore del blog, Vito Foschi, riferisce di aver fatto funzionare la N501HS con “insmod usbserial vendor=0×19d2 product=0×2″ ;
    la parte PCI-USB della scheda viene associata a ohci_hcd, quindi tutto ok sotto questo profilo; notare che idVendor e idProduct non sono quelli che già noi conosciamo (e cioè “05c6″ e “6613″)… mah; un lettore riferisce di essersi scontrato col problema dell’ehci_hcd e, dopo avere rimosso questo modulo…

    A questo punto mi ricavo ID Product e ID Vendor con lsusb, che sono diversi dai tuoi (a me risulta una Qualcomm) e digito:
    modprobe usbserial vendor=0×05c6 product=0×6613

    … si scontra con lo stesso problema indicato qui http://www.slacky.eu/forum/viewtopic.php?f=1&t=22185&start=15 ;
    i commenti procedono con altre perplessità e con innesti relativi al modello di scheda in formato Express Card (ET502HS); ipotesi: sarà mica che in un primo periodo il chip del modem montato non era della Qualcomm, venendo riconosciuto con idVendor “19d2″ e idProduct “2″, e funzionava con usbserial, mentre oggi quello della Qualcomm (05c6 e 6613) con usbserial non va?

    * “Riconoscimento PCCard Onda N501HS” (Giugno 2008)
    http://forum.ubuntu-it.org/index.php?topic=197655.0
    – beh, questo lo conosciamo (è AlexT) ;-)

    * “Configurare Onda Express Card ET501HS HSDPA su Ubuntu Linux” (novembre 2007)
    http://blog.linux-fueled.com/2007/11/28/configurare-onda-express-card-et501hs-hsdpa-su-ubuntu-linux/
    – Qui la scheda è la Onda Express Card ET501HS; l’utilizzatore è stato fortunato, perché…

    new full speed USB device using uhci_hcd and address 32

    … (uhci invece che ehci) e con usbserial gli funziona:

    modprobe usbserial vendor=0x19d2 product=0×0001

    Notare… l’idProduct.
    Viene linkato questo documento della Onda…
    http://www.linux-fueled.com/altro/comandi.pdf
    … sul set di comandi AT per i modelli M1HS, N501HS e H600: potrebbe tornare utile.
    Si parla anche ( http://blog.linux-fueled.com/2007/11/28/configurare-onda-express-card-et501hs-hsdpa-su-ubuntu-linux/#comment-716 ) del problema della scheda riconosciuta in prima battuta come Cd-Rom (cosiddette schede “Zero CD”): l’idProduct rilevato in tal caso risulta “2000″.

    * “Modem HSDPA e modulo Airprime – Kubuntu” (Marzo 2008)
    http://divilinux.netsons.org/index.php/archives/709
    – patch del modulo airprime per poterlo usare con le schede ONDA M1HS (idVendor “05c6″ e idProduct “6613″: gli stessi della N501HS), Huawei E220 (12d1, 1003), Momo Design (05c6, 6000); nei commenti si fa riferimento ai modem “ZeroCD” e al tool “usb_modeswitch”.
    E ritroviamo anche AlexT ;-) : http://divilinux.netsons.org/index.php/archives/709#comment-9249

    * “Onda MT512HS Tim su Ubuntu Gutsy”
    http://www.andreaboscolo.it/2008/03/12/onda-mt512hs-tim/
    – Andrea Boscolo parla del modem USB Onda MT512HS: anche qui siamo di fronte a un modem “ZeroCD”: la periferica, appena viene collegata alla porta USB, si presenta al kernel come lettore di CD-Rom, con idProduct “2000″ e a questo punto il kernel le assegna il driver usb-storage; il tool usb_modeswitch permette di switchare il comportamento della periferica da “lettore CD” a “modem” [*]; notare che la periferica (non la sto chiamando “modem” intenzionamlente) contiene una memoria flash (nella quale sono memorizzati i driver utili al suo funzionamento: funzionamento sotto… Windows) che, molto probabilmente, ragionandoci un po’ sopra, può anche essere utilizzata come device di memorizzazione di massa esterno: in pratica è una chiavetta USB; penso che qualcuno ci sia già riuscito: dovrei cercare meglio in rete.

    [*]
    In realtà, la periferica ha due idProduct: “2000″ (corrispondente alla memoria flash) e “2″ (corrispondente al chip del modem). Appena essa viene collegata alla porta USB, l’idProduct che viene rilevato dal kernel è “2000″ (per un motivo che dovrei un minimo approfondire), che corrisponde a quello di un lettore di CD-Rom, ragion per cui il kernel tratta la memoria flash interna alla periferica caricando il modulo usb-storage (che, tipicamente, è quello che serve al kernel per interagire con chiavette USB, o con qualsiasi altro dispositivo di memorizzazione di massa collegato a una porta USB). A questo punto, quindi, dovrebbe essere anche creato un file all’interno della directory /dev , file che fungerebbe da interfaccia verso la periferica MT512HS trattata come “device a blocchi”. Ma, invece, noi saremmo più interessati (almeno in questo momento) ad utilizzare la periferica come “device a caratteri”, quale è appunto un modem.
    Ecco allora che ci viene in aiuto il tool usb_modeswitch, il quale, essenzialmente, che cosa fa? Rimuove il modulo usb-storage (e a questo punto scomparirà anche il file per l’interazione con la periferica come se essa fosse un “device a blocchi”, cioè un device di memorizzazione) e “switcha” (…cambia… ;-) ) l’ “idProduct” da “2000″ a “2″, cioè fa in modo che all’identificativo della periferica sia abbinato l’idProduct “2″, che è quello di un modem; la rimozione del modulo usbserial comporta che, visto che la periferica è ancora lì ben attaccata alla porta USB, il daemon di udev (udevd) la veda come una nuova periferica e rilevi i suoi dati identificativi; la periferica, infatti, grazie a usb_modeswitch, ha perso l’idProduct che aveva perché ne ha uno nuovo, dev’essere nuovamente riconosciuta da udev e non viene più rilevata con l’idProduct “2000″, bensì con l’idProduct “2″ (che è stato sostituito da usb_modeswitch); a questo punto la via per pilotarla come modem è spianata: nel caso descritto da Boscolo viene utilizzato il driver usbserial mediante le regola di udev…

    RUN+=”/sbin/modprobe usbserial vendor=0x19d2 product=0×0002″

    Onda MT505UP è anche lui un modem “ZeroCD”: nei commenti al post troviamo scritto che…

    Facendo le opportune modifiche sono finalmente riuscito a far funzionare il modem Onda MT505UP con Ubuntu 8.04beta.

    Qui…
    * “Onda N501HS – come va e impressioni” (Luglio 2006 – Marzo 2008)
    http://forum.telefonino.net/archive/index.php?t-169231.html
    … vediamo come anche gli utenti Windows si siano impantanati in questioni e dibattiti di riconoscimento (e di funzionamento) della N501HS: termini ricorrenti riguardo al “dietro le quinte” della scheda sono: “ZTE”, “SierraWireless”, Qualcomm; una lettura che però non aggiunge niente rispetto al punto a cui siamo giunti in questo thread.

    Qui…
    * “PC Card Onda ET502HS (Gennaio – Febbraio 2008)
    http://forum.ubuntu-it.org/index.php?topic=155259.msg1030400
    … si parla del modello in formato Express Card a parte le stringhe di inizializzazione su cui sorvolo, troviamo il “tragico” codice idProduct=2000, che è quello si quando la periferica viene riconosciuta come unità CD-Rom: discorso già ampiamente svolto in questo thread (vedi “ZeroCD”)

    Qui…
    * “HSDPA in Linux con Onda MH600HS” (Dicembre 2007 – Giugno 2008)
    http://dpfsoftware.altervista.org/blog/?p=7
    … si parte col modello MH600HS , che viene riconosciuto inizialmente come unità CD-Rom e che per essere utilizzato come modem necessita dell’apporto di usb_modeswitch; dopodiché si passa al livello successivo di difficoltà, dovendo affrontare due problemi in un colpo solo, poiché il modello MT505UP presenta –di grazia– oltre allo scoglio di essere riconosciuto come unità CD-Rom, anche quello del driver ehci.
    Volendo, per questo modello si può dare un’occhiata anche qui…
    “Driver onda ET505UP pcmcia” (Maggio 2008)
    * http://forum.ubuntu-it.org/index.php?topic=189233.msg1257627
    … e qui…
    * “[RISOLTO] Onda MT505UP – TIM Funziona..(forse) (!!!)” (Febbraio – Giugno 2008)
    http://forum.ubuntu-it.org/index.php/topic,160665.msg1085729

    Nel…
    * forum interno al sito del creatore di usb_modeswitch
    http://www.draisberghof.de/usb_modeswitch/bb/viewforum.php?f=3&sid=d59725ce89c6b9e71aec160862207cf1
    … troviamo una serie notevole di informazioni su diversi device

    Ma questo documento…
    * “Mounting a USB CDROM, simulated by a Novatel MC950D HSUPA G3 modem” (Giugno 2008)
    http://forum.openwrt.org/viewtopic.php?id=15919
    … è il mio preferito: forse perché è legato a un altro argomento che sto trattando in questo sito, quello dei router 3G (il router di cui si parla al link è l’Asus WL-500G Premium), forse perché rispetto a tutti i precedenti richiami a usb_modeswitch è un esempio di pensiero divergente… fatto sta che la questione del riconoscimento della periferica come unità Cd-Rom, invece che come modem, viene risolta senza tante storie con l’utility “sdparm” (che… “fetch and potentially change SCSI device attributes, send commands“), la quale può inviare a un device il comando “eject”: mandi “eject” e… “ciao ciao” al CD-Rom e benvenuto al modem… bellissimo!

    Dal driver “sierra” a quello “option” (Sergio Callegari):
    http://www.spinics.net/lists/linux-usb/msg03781.html (Aprile 2008)
    La risposta più utile (Alan Stern, uno degli sviluppatori del kernel Linux,):
    http://www.spinics.net/lists/linux-usb/msg03788.html (Aprile 2008)

    Qui c’è l’intero thread (Dicembre 2007) che –presumo– ha dato lo spunto a Callegari per il suo workaround:
    http://kerneltrap.org/mailarchive/search/%40subject+Weird+behaviour+of+UMTS+modem+with+%22/linux-usb

    L’intero thread in…
    https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/129433/
    … che termina (Aprile 2008) col workaround

    Qui in particolare…
    http://kerneltrap.org/mailarchive/linux-usb/2007/12/14/508412 (Dicembre 2007)
    … Alan Stern ci chiarisce le idee sul fatto che la “colpa” del malfunzionamento del driver ehci sia da imputare al device della Onda (mentre Callegari aveva qualche dubbio, visto che in diverse mailing-list e forum vengono lamentati problemi con ehci).

    Qui…
    http://kerneltrap.org/mailarchive/linux-usb/2007/11/27/450188
    … troviamo la patch al problema realizzata lo scorso Novembre da uno degli sviluppatori del kernel

    Il 3 Luglio è stata rilasciata l’ultima versione stabile del kernel 2.6.25.10
    Questa versione dovrebbe già integrare il meccanismo di fallback dal driver ehci a uno dei “supplenti”: il device viene tolto dalla porta controllata da ehci e assegnato a una controllata da uhci (o ohci):
    http://www.kernel.org/pub/linux/kernel/v2.6/

    =========================== FINE ELENCO ============================


    AlexT scrive:

    bene, allora
    direi che ci si può incontrare di qua la settimana prossima o, comunque, quando avrò i risultati.
    Intanto un ringraziamento doveroso a tutti.

    AlexT

    p.s.: AlexT sono sempre io!!!


    … CONTINUA …                     … CONTINUA …                     … CONTINUA …

    Commentato da 5m33 | luglio 22, 2008, 12:55 |
  12. … SEGUE DAL PRECEDENTE…                     … SEGUE DAL PRECEDENTE…                     … SEGUE DAL PRECEDENTE…

    Skumpic scrive:

    ciao, sto provando a patcharmi airprime ora.
    Scusate se sono poco presente ma qui c’e’ lo studio, un caldo infernale (pc si è spento già 2 volte, si rifiuta di lavorare pure lui) ed in più se gioco io con la pc-card la ragazza non naviga :P

    Mi sono letto tutto l’intervento. Fermo restando che per ora non c’e’ alternativa (almeno da quanto mi pare di aver capito) al workaround di Calleari rimane da capire quale sia il driver più performante per la nostra “bimba”.

    Dalle mie limitate esperienze mi pare di ricordare che usbserial su ubuntu hardy sia già patchato per l’HSDPA, in quel qual caso potrebbe tornare utile il link qui (se non è già stato menzionato):
    http://www.andreaboscolo.it/2008/03/12/onda-mt512hs-tim/

    L’alternativa è airprime (che ora mi sto patchando). La cosa simpatica è che l’id del produttore e vendor è cambiato da feisty ad hardy :)


    Skumpic scrive:

    Allora eccomi con le prime risultanze dei miei test.
    Allora il workaround di Calleari è perfetto (anzi lo ringrazio per aver partecipato alla discussione e avermi illuminato un po sulla questione :P).

    Al riavvio ecco l’output di dmesg:

    [ 94.609071] hub 6-0:1.0: USB hub found
    [ 94.609248] hub 6-0:1.0: 1 port detected
    [ 96.757053] usb 6-1: new full speed USB device using ohci_hcd and address 2
    [ 96.969185] usb 6-1: configuration #1 chosen from 1 choice
    [ 97.297311] usbcore: registered new interface driver usbserial
    [ 97.297599] /build/buildd/linux-2.6.24/drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
    [ 97.297869] usbcore: registered new interface driver usbserial_generic
    [ 97.297874] /build/buildd/linux-2.6.24/drivers/usb/serial/usb-serial.c: USB Serial Driver core
    [ 97.308562] /build/buildd/linux-2.6.24/drivers/usb/serial/usb-serial.c: USB Serial support registered for Sierra USB modem (1 port)
    [ 97.308588] /build/buildd/linux-2.6.24/drivers/usb/serial/usb-serial.c: USB Serial support registered for Sierra USB modem (3 port)
    [ 97.308621] sierra 6-1:1.0: Sierra USB modem (1 port) converter detected
    [ 97.310059] usb 6-1: Sierra USB modem (1 port) converter now attached to ttyUSB0
    [ 97.310079] sierra 6-1:1.1: Sierra USB modem (1 port) converter detected
    [ 97.313050] usb 6-1: Sierra USB modem (1 port) converter now attached to ttyUSB1
    [ 97.313072] sierra 6-1:1.2: Sierra USB modem (1 port) converter detected
    [ 97.316025] usb 6-1: Sierra USB modem (1 port) converter now attached to ttyUSB2
    [ 97.316045] usbcore: registered new interface driver sierra
    [ 97.316049] /build/buildd/linux-2.6.24/drivers/usb/serial/sierra.c: USB Driver for Sierra Wireless USB modems: v.1.2.5b

    Mentre lsusb restituisce:

    Bus 006 Device 002: ID 05c6:6613 Qualcomm, Inc.

    Come vedete carica il driver sierra, driver le cui prestazioni mi hanno lasciato abbastanza deluso. E’ umts niente più, niente prestazioni da ferrari :(
    Le stringhe necessarie per farlo navigare correttamente sono le stesse pubblicate da Andrea Boscolo (http://www.andreaboscolo.it/2008/03/12/onda-mt512hs-tim/) d’altronde la pc-card è riconosciuta con gli stessi id. Ora provo usbserial e poi gli altri driver :P


    Skumpic scrive:

    Ok, altro giro altra corsa :P Ora siamo con airprime
    Prima però volevo ringraziare 5m33, ho riletto con più calma tutto e mi sono meglio reso conto dell’ incredibile lavoro di ricerca che ha svolto nonchè della chiara esposizione.
    Gran parte delle cose che ho scritto nel precedente intervento le aveva già menzionate lui, ma non me ne ero reso conto (scusate sono fuso ultimamente e non è solo colpa del caldo…)

    [ 2465.405652] usb 7-1: new full speed USB device using ohci_hcd and address 2
    [ 2465.617496] usb 7-1: configuration #1 chosen from 1 choice
    [ 2465.904916] /build/buildd/linux-2.6.24/drivers/usb/serial/usb-serial.c: USB Serial support registered for airprime
    [ 2465.905279] airprime 7-1:1.0: airprime converter detected
    [ 2465.905605] usb 7-1: airprime converter now attached to ttyUSB0
    [ 2465.905845] usb 7-1: airprime converter now attached to ttyUSB1
    [ 2465.906085] usb 7-1: airprime converter now attached to ttyUSB2
    [ 2465.906254] airprime 7-1:1.1: airprime converter detected
    [ 2465.906470] usb 7-1: airprime converter now attached to ttyUSB3
    [ 2465.906694] usb 7-1: airprime converter now attached to ttyUSB4
    [ 2465.906922] usb 7-1: airprime converter now attached to ttyUSB5
    [ 2465.907088] airprime 7-1:1.2: airprime converter detected
    [ 2465.907301] usb 7-1: airprime converter now attached to ttyUSB6
    [ 2465.907522] usb 7-1: airprime converter now attached to ttyUSB7
    [ 2465.907785] usb 7-1: airprime converter now attached to ttyUSB8
    [ 2465.907953] usbcore: registered new interface driver airprime

    Sinceramente non mi ha impressionato e, devo dire sottovoce, forse andava meglio il sierra (a parità di condizioni). C’e’ da aggiungere però che la ONDA è una pc-card storicamente “sorda” e quindi potrebbero giocare un ruolo rilevante variabili ambientali (ok, dovrei riavviare il pc della ragazza con windows e vedere li come si comporta…) che non tengo in debita considerazione.
    Più tardi proverò con l’option che tra l’altro essendo sfruttato da alcuni tool grafici (vodafone betavine se non ricordo male) potrebbe farsi preferire.

    ciao


    Skumpic scrive:

    Ok, mi devo parzialmente correggere.
    Usando il driver airprime e cambiando le stringhe di inizializzazione il download rate sale a circa 70kbit/s (uso wind e di suo non ha mai superato i 99kbit/s con la mia pc-card che è molto meno “sorda” rispetto a questa) ed il ping si abbassa da 370ms a 120ms (alle volte anche 50ms).
    Quindi direi che è questo il driver per lei :P.

    Le nuove stringhe per gnomeppp sono:
    ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
    AT+CGDCONT=1,”IP”,”internet.wind”

    ps. Con queste stringhe il driver sierra non instaura la connessione
    ciao :)


    Skumpic scrive:

    Stamattina ho provato anche l’option

    [ 1703.187589] usb 7-1: new full speed USB device using ohci_hcd and address 2
    [ 1703.399000] usb 7-1: configuration #1 chosen from 1 choice
    [ 1703.689963] /build/buildd/linux-2.6.24/drivers/usb/serial/usb-serial.c: USB Serial support registered for GSM modem (1-port)
    [ 1703.690349] option 7-1:1.0: GSM modem (1-port) converter detected
    [ 1703.690759] usb 7-1: GSM modem (1-port) converter now attached to ttyUSB0
    [ 1703.690963] option 7-1:1.1: GSM modem (1-port) converter detected
    [ 1703.691208] usb 7-1: GSM modem (1-port) converter now attached to ttyUSB1
    [ 1703.691394] option 7-1:1.2: GSM modem (1-port) converter detected
    [ 1703.691643] usb 7-1: GSM modem (1-port) converter now attached to ttyUSB2
    [ 1703.691830] usbcore: registered new interface driver option
    [ 1703.691835] /usr/src/linux-source-2.6.24/drivers/usb/serial/option.c: USB Driver for GSM modems: v0.7.1

    Niente di trascendentale, prestazioni in linea con airprime (un pò migliori ma c’e’ da dire che sono le 9 del mattino mentre ieri erano le 18-19). Penso lascerò questo vista la possibilità di integrarlo con il tool vodafone betavine.

    Aspetto i riscontri di Alext :)
    ciao


    5m33 scrive:

    (Testo REVISIONATO da ultimo il 29 Luglio 2008)

    Skumpic:

    La cosa simpatica è che l’id del produttore e vendor è cambiato da feisty ad hardy

    8-O cioè?
    Qualcosa tipo…
    idVendor: 19d2 e idProduct: 0002 sulla Feisty che sulla Hardy diventa…
    idVendor: 05c6 e idProduct: 6613 ?

    @ Skumpic e AlexT

    Mia curiosità: l’identificativo del Bus PCI che avete (Skumpic e AlexT) rilevato (quello a cui si riferisce la regola udev di cui al workaround di Callegari) qual è? E’ questo…
    0000:04:00.2 ?

    *** 6 Luglio 2008 ***
    Non può essere lo stesso identificativo perché quello è assegnato dal kernel del computer di Callegari; sarà certamente qualcosa di simile. Lo script del workaround elaborato da Callegari rileva tale identificativo, che è diverso da caso a caso, quando viene inserita la PC-Card nello slot PCMCIA, cioè nel momento in cui udevd riceve dal kernel l’evento di hotplug (uevent) relativo alla periferica –cioè la scheda dell’Onda– che contiene uno Hub USB con tre porte, alle quali il kernel assegna tre interfacce di comunicazione, una delle quali viene vista come USB 2.0 –i cui codici identificativi sono 1131 (vendor) e 1562 (device)– e alla quale, quindi, si riferisce il workaround.
    ************

    ——————–

    Skumpic:
    [con driver Sierra]

    Le stringhe necessarie per farlo navigare correttamente sono le stesse pubblicate da Andrea Boscolo [...] d’altronde la pc-card è riconosciuta con gli stessi id

    ??? La tua, che è la N501HS, ha 05c6:6613, mentre il modem di Boscolo, che è l’MT512HS, ha 19d2:2000 (che poi switcha con usb_modeswitch a 0002). La tua ha invece gli stessi del modello M1HS.

    *** 6 Luglio 2008 ***
    Si sta parlando degli identificativi del circuito del modem, cioè di un sotto-sistema interno alla scheda ulteriore rispetto all’host USB identificato con 1131 (vendor) e 1562 (device).
    ************

    Però è vero che la stringa di inizializzazione AT+ZOPRT=5 è necessaria per tutti questi modelli.

    Skumpic:
    [con driver airprime]

    Con queste stringhe ["ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0"] il driver sierra non instaura la connessione

    Ma sei sicuro che il modem rispondesse?

    La stringa di inizializzazione è un comando AT che il driver trasferisce al modem così com’è ed è il modem che, eventualmente, la rifiuta. Il referente delle stringhe di inizializzazione è il modem, non il driver, che fa solo da tramite. Pertanto le stringhe di inizializzazione vanno saggiate in riferimento al singolo modello di modem, non al driver.
    Questo è anche il motivo per cui un modem Hayes compatibile può essere benissimo pilotato con un driver generico come usbserial. La peculiarità del driver (gestione del flusso dati, dal quale dipende la velocità e la stabilità della connessione) è spostata su altri aspetti del funzionamento del modem (vedi ciò che diceva Callegari) e questo è anche il motivo per cui esistono driver specifici, per modem diversi, che si differenziano l’uno dall’altro, ma che possono benissimo anche non differenziarsi più di tanto (da quel “tanto” dipende poi la qualità del risultato: velocità e stabilità della connessione) e avere quindi degli ambiti di operatività che si sovrappongono fino anche a coincidere (come nel caso che stiamo discutendo: intercambiabilità –sia pur con efficacia diversa– di sierra, airprime, option, oltre che universalità di usbserial).

    La stringa “AT+ZOPRT=<valore>” (vedi Boscolo) accende (valore “5) o spegne (valore “6″) l’alimentazione del modem: in pratica è un interruttore (implementato via software). Pertanto va inviata al modem prima di qualsiasi altra.

    Se il modem riceve alcune stringhe e poi non viene staccato, il settaggio che ha nella memoria volatile resta attivo, quindi, visto che i driver sono runtime (cioè possono essere rimossi, ricompilati e reinseriti anche durante il funzionamento del sistema) bisogna vedere in che sequenza li hai provati, verificare anche se sia stata inviata al modem la stringa ATZ, che lo resetta, e se il modem sia stato scollegato e poi ricollegato.

    Dal set di comandi (Hayes esteso) che si trova qui…
    http://www.giddi.net/files/documents/Onda.pdf
    … si potrebbe pensare che la stringa “AT+ZOPRT=5” (la si trova alla fine del documento) sia sempre necessaria per accendere il modem dei seguenti modelli: M1HS, N501HS, H600.

    Una volta che hai acceso il modem via software, se poi non lo stacchi puoi provare altri driver senza bisogno di inviare ogni volta la stringa che lo accende.
    Se, in ipotesi, tu hai tolto la scheda dallo slot e poi l’hai reinserita, dopodiché hai provato un altro driver cambiando stringa di inizializzazione, ma senza più metterci “AT+ZOPRT=5“, il modem resterà muto (perché è spento).

    ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0” è una stringa di inizializzazione generica. Va bene impostarla per garanzia (il modem potrebbe essere stato usato da altri e avere altri settaggi impostati), ma secondo me potresti anche evitarla perché i settings che invia sono sicuramente già presenti nei registri interni al modem. Invece, con alcuni modem, non bisogna dimenticarsi “AT+ZOPRT=5“, che è quella che accende il dispositivo (ma non potevano metterci un interruttore hardware?)


    Skumpic scrive:

    @5m33

    8-O cioè?
    Qualcosa tipo…
    idVendor: 19d2 e idProduct 0002 sulla Feisty che sulla Hardy diventa…
    idVendor: 05c6 e idProduct: 6613 ?

    ESATTO!! Il post lo feci testando il tutto su ubuntu 7.04 ed allora l’hardware fu riconosciuto con quegli id, oggi con altri diversi !!

    Però è vero che la stringa di inizializzazione AT+ZOPRT=5 è necessaria per tutti questi modelli.

    Sinceramente a me funziona anche senza quella stringa con gli airprime e con gli option. Ad ogni modo potrebbe anche darsi che io abbia “attivato” la scheda in precedenza, sinceramente non sapendo esattamente come funzionavano i comandi AT non ci ho fatto molto caso. Ti ringrazio per i chiarimenti sul funzionamento dei comandi di inizializzazione, CHIARISSIMO come sempre. Che ne pensi di un post relativo al workaround di Calleari? Quasi quasi lo metto in evidenza perchè lo trovo realmente utile !!


    AlexT scrive:

    Salve a tutti, mi rincresce dovervi dire che a causa del mio lavoro sono stato catapultato in altri luoghi e che a causa di esso non ho potuto effettuare le prove che mi ero ripromesso di fare!!!
    sabato mattina ho avuto anche qualche difficoltà col comando udevinfo…. in quanto sul terminale mi dava il messaggio che nonriusciva a trovare il file…(ricordatevi che sono alle prime armi, quindi potrei aver fatto anche qualche errore!!!) vi chiedo solo la cortesia, nel frattempo che riesco ad avere un po di tempo, di indicarmi qualche altro comando attraverso il quale poter ottenere gli stessi risultati(vendor e product della regola del Callegari).

    5m33
    dal comando dmesg ho rilevato due indirizzi:
    0000:03:00 e
    0000:06:02
    se la memoria non mi inganna.

    infine, domani dovrei essere di ritorno e penso di essere operativo da giovedì, se non vi spiace rimanderei le mie prove a partire da giovedì mattina.

    intanto buona notte!!!!


    5m33 scrive:

    (Testo REVISIONATO da ultimo il 29 Luglio 2008)

    Skumpic:

    ESATTO!! Il post lo feci testando il tutto su ubuntu 7.04 ed allora l’hardware fu riconosciuto con quegli id, oggi con altri diversi !!

    Eh… lo sospettavo infatti… questo spiega anche la confusione che avevo riscontrato nel Web riguardo agli identificativi di ‘sto modem.

    Da http://www.linux-usb.org/usb.ids risulta che…

    19d2” è l’idVendor della ONDA Communication S.p.A (mentre 05c6 è quello della Qualcomm, ma –precisiamo– siccome il chipset del modem della N501HS è un Qualcomm, i due riconoscimenti dovrebbero essere alla stessa stregua: in buona sostanza, con la Hardy la periferica viene riconosciuta andando direttamente al sodo, cioè come chipset della Qualcomm –ma per farla funzionare bisogna rimuovere il driver ehci o evitare, mediante una regola ad-hoc per udev, meglio se selettivamente, che la periferica gli venga assegnata– mentre con la Feisty veniva riconosciuta come Onda –e funzionava perché all’interfaccia PCI-USB interna alla scheda era assegnato il driver uhci od ohci. Conclusione: bah… tanto il riconoscimento serve soltanto per l’assegnazione del driver; in base all’idVendor e all’idProduct il sistema saprà quale driver assegnare: può saperlo –diciamo così– “di default” oppure perché glielo diciamo noi con apposite opzioni come quelle per usbserial, o ricompilando il driver dopo aver inserito nel punto opportuno del sorgente i codici identificativi della periferica che vogliamo fargli pilotare).

    Sempre lì ( http://www.linux-usb.org/usb.ids ) lo si trova catalogato assieme a un idProduct che —indovina un po’– è “0002” e viene attribuito al modello MT505UP. E dunque ci sarebbero da aggiungere quantomeno l’ N501HS e l’ M1HS.
    Perché dico “quantomeno”? Perché –come avevi detto anche tu– il modem MT512HS –e forse anche altri– potrebbe avere, guardandolo con le lenti di un altro kernel [mi chiedo, però, come sia possibile], gli stessi identificativi di questi appena indicati, visto che (a quanto sembrerebbe) essi cambiano a seconda del kernel. Ipotesi questa che potrebbe essere avvalorata (in via indiziale :-) ) anche dal fatto che il documento della Onda sui comanto AT elenca comandi validi per i modelli M1HS, N501HS e –ciliegina sulla torta– H600.
    Morale: sarà mica che noi stiamo qui a girarci tanto intorno, ma alla fine il chip che ‘sti modem hanno al loro interno è sempre lo stesso e cambia solo –eventualmente– una parte dei circuito che è quella che riguarda l’interfacciamento via Bus USB, che è poi anche ciò che ha fatto “arrabbiare” il kernel 2.6.24 ? (“arrabbiare”, sì, perché il device N501HS gli tende la mano per presentarsi come USB 2.0, il kernel dice “piacere e gli allunga la sua –”ehci”– ma a quel punto l’ N501HS ritira la mano come nel famoso scherzetto; metafora per dire che il sospetto –se non sbaglio avvalorato dagli sviluppatori del kernel– è che l’errore non sia interno al driver ehci, ma interno al modo in cui i circuiti di quel device implementano l’USB 2.0: il kernel…

    30 Luglio 2008
    (il sistema di hotplug oggi integrato nel kernel)

    … resta lì con un palmo di naso, cioè non può proseguire nel rilevare correttamente la presenza del circuito del modem).

    Che ne pensi di un post relativo al workaround di Calleari? Quasi quasi lo metto in evidenza perchè lo trovo realmente utile !!

    E’ la stessa idea mia: lo avverti tu che il suo commento sarà “elevato” a post?

    Inoltre, magari se riesco, mi piacerebbe riordinare e “asciugare” questo thread specifico e farne un ulteriore post a più mani (tu, AlexT e io come autori dovremmo rileggerlo prima della pubblicazione): ciò darebbe modo di fargli acquisire un rating notevolmente superiore nei motori di ricerca (rispetto all’attuale versione a mo’ di commenti) e quindi di diventare un riferimento chiaro per tutti coloro che si imbattono nel medesimo problema dell’ehci caricato dal kernel al posto dell’ohci o dell’uhci.

    AlexT:

    mi rincresce dovervi dire che a causa del mio lavoro sono stato catapultato in altri luoghi e che a causa di esso non ho potuto effettuare le prove che mi ero ripromesso di fare!!!

    Questo è normale: il thread dovrebbe essere un aiuto per discutere, ma non creare affanno; questa discussione ci ha condotto a un ottimo risultato, con l’aiuto prezioso di Callegari.

    dal comando dmesg ho rilevato due indirizzi:
    0000:03:00 e
    0000:06:02
    se la memoria non mi inganna.

    Devi fare così:

    per rilevare l’identificativo del Bus PCI uno dei modi possibili (e forse il più veloce in questo caso specifico) è:

    - inserisci la PC-Card e aspetti di vedere che il modulo ehci è stato caricato; non lo smonti e poi in una console digita…

    lsusb

    ==> che cosa vedi?

    - ora apri un’altra console e fai:

    cd /sys/bus/pci/drivers/ehci_hcd

    - in questa directory, in assenza di altre periferiche USB 2.0 (quindi: non collegare anche, per esempio, un hard disk esterno, anche perché poi il kernel si rifiuterebbe di obbedire al comando di rimozione del modulo ehci) dovresti avere un solo file (che è poi un link) denominato con l’identificativo dell’interfaccia che riguarda il “PCI device” che corrisponde al controller USB EHCI (cioè al device che tu poi, per far funzionare il modem, disabiliterai e riabiliterai, ma questa seconda volta col modulo uhci o ohci)

    *** 29 Luglio 2008 ***
    Non è così, perché un altro device USB 2.0 c’è sicuramente, dato che il kernel Linux riserva una porta USB del PC al modulo ehci_hcd e sulla relativa interfaccia vengono mappati i device USB 2.0. Di conseguenza, in /sys/bus/pci/drivers/ehci_hcd ci saranno due file, non uno solo: il primo denominato con l’identificativo di interfaccia di una porta dell’Hub USB interno al PC, l’altro denominato con l’identificativo di interfaccia di una porta USB dell’Hub USB interno alla PC-Card.
    ************

    - dunque digita…

    ls

    ==> che cosa vedi ?

    Col comando…

    udevinfo --attribute-walk --path=/sys/bus/pci/drivers/ehci_hcd/<QUI_IDENTIFICATIVO_INTERFACCIA>

    [attento alle due lineette]

    … ottieni in modo ordinato tutte le informazioni che riguardano il device (cioè l’host USB) che dà problemi.

    Le informazioni che sono registrate nelle directory del filesystem creato da udev sono organizzate in un albero molto articolato di directory all’interno del quale sono rappresentati tutti i componenti hardware del tuo PC. Quindi, navigando dentro i rami di quest’albero, trovi gli identificativi di un tipo, quelli di un altro, eccetera, eccetera.

    udevinfo è un tool per estrarre in modo mirato queste informazioni.

    Nel suo workaround, Callegari utilizza un comando che, dagli identificativi “0×1131” e “0×1562“, risale all’identificativo dell’interfaccia PCI-USB da inserire in “unbind”: questo, nel suo caso, è “0000:04:00.2“.

    *** 6 Luglio 2008 ***
    Nel suo (di Callegari) sistema Linux l’identificativo assegnato dal kernel all’interfaccia è 0000:04:00.2, ma in un altro sistema esso cambia. Quelli che non cambiano sono i due identificativi –1131 (vendor) e 1562 (device)– dell’host USB interno alla scheda, attraverso il quale il PC comunica col chipset del modem, anche questo con i propri identificativi: 05c6 (idVendor) e 6613 (idProduct).
    ************

    Volendo, l’operazione consistente nello scrivere tale identificativo nel file di “unbind” potrebbe essere fatta anche “a mano”, col comando “echo -n identificativo > /sys/bus/pci/drivers/ehci_hcd/unbind“, ma dovrebbe essere fatta ogni volta che il PC viene riavviato (poiché se il PC resta il medesimo l’identificativo assegnato dal kernel all’interfaccia non cambia, il comando potrebbe anche essere inserito in uno script da eseguire al boot).

    *** 29 Luglio 2008 ***
    No, non può funzionare, perché scrivendo in /sys/bus/pci/drivers/ehci_hcd/unbind l’identificativo di un’interfaccia che non è stata ancora creata (tale è il caso, appunto della scheda dell’Onda, prima di essere inserita nello slot) si riceve un messaggio di errore (“write error: No such device“).
    ************

    L’identificativo assegnato dal kernel all’interfaccia PCI-USB, comunque, lo trovi anche nel file di log che, se si riproduce in modo identico lo script del workaround di Callegari ( https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/129433/comments/10 ), viene creato in…
    /var/log/fix-onda-n501hs.log

    *** 29 Luglio 2008 ***
    … Nonché col comando lspci, impartito, ovviamente, dopo aver inserito la scheda.
    ************

    5m33 scrive:

    Guardate qui…
    http://www.spinics.net/lists/linux-usb/msg06319.html

    13 Jun 2008:
    no I haven’t tried the sierra. I will try monday morning and I will give you a feedback.

    Ci stanno imitando, o… LI stiamo imitando :-)

    Tutto il thread, che si riferisce all’ MT505UP:
    http://www.spinics.net/lists/linux-usb/msg06292.html
    http://www.spinics.net/lists/linux-usb/msg06304.html
    http://www.spinics.net/lists/linux-usb/msg06319.html
    http://www.spinics.net/lists/linux-usb/msg06322.html

    (driver airprime funziona, option no, sierra non si sa)

    Ed ecco una patch per il kernel 2.6.25 per evitare che l’ ET502HS venga visto come unità CD-Rom:
    una entry in unusual_devs.h [*] con idProduct 2000

    Potete seguire tutto il thread a ritroso e il successivo (che si riferisce all’ MT505UP partendo da qui:
    http://www.spinics.net/lists/linux-usb/msg04657.html

    [*]
    “The unusual_devs.h Guide”
    http://phildev.net/linux/usb-unusualdevs-notes.html

    unusual_devs.h is where we list all hardware that is a USB Storage device but somehow needs special attention. This could be because it doesn’t claim it’s a USB Storage device, it could be because it incorrectly impliments the spec, or because it otherwise has special needs.


    Skumpic scrive:

    Ehm, ma dai noi li abbiamo già provati i diversi driver con la scheda pci :):P !!!


    5m33 scrive:

    Skumpic:

    Ehm, ma dai noi li abbiamo già provati i diversi driver con la scheda pci :):P !!!

    Appunto !
    Ma loro ci hanno “battuto” di una buona decina di giorni :-)
    http://www.spinics.net/lists/linux-usb/msg06319.html
    (però si riferiscono all’ MT505UP e non all’ N501HS)


    5m33 scrive:

    (Testo REVISIONATO da ultimo il 29 Luglio 2008)

    @ AlexT o Skumpic
    ——————————

    Se uno di voi ha sotto mano la scheda N501HS, mi servirebbe conoscere l’output di alcuni comandi da digitare con la scheda inserita nello slot PCMCIA (dopodiché, una volta letto l’output, fornirò ulteriori chiarimenti)

    La scaletta dei comandi è la seguente:

    (far precedere i comandi da sudo)

    lspci
    - trovare quale sia l’interfaccia dell’ “USB 2.0 Host Controller” attribuita alla scheda (non quella della porta USB del PC a cui è assegnato il driver EHCI: a noi interessa il device interno alla scheda inserita nello slot PCMCIA)
    ==> questo è il dispositivo che quando viene rilevato deve far scattare la regola per l’unbinding del driver EHCI
    - prendere l’identificativo del device e riscriverlo preceduto da 4 zeri e un “:” [*]

    [*]
    E’ l’identificativo che si ottiene anche così:
    cd /sys/bus/pci/drivers/ehci_hcd/
    e poi digitando
    ls
    ==> (sono gli identificativi dei dispositivi ai quali il kernel ha assegnato a ehci_hcd: con la scheda inserita nello slot PCMCIA dovrebbero essercene almeno due: uno assegnato a un host USB del PC e l’altro assegnato a un host USB interno alla scheda)
    *** 29 Luglio 2008 ***
    L’identificativo dell’interfaccia che deve restare scollegata dal driver EHCI Host Controller lo si ricava col comando dmesg dopo aver inserito la scheda, o anche inserendo la scheda dopo aver digitato tail -f /var/log/messages.
    ************

    - andare qui:
    cd /sys/bus/pci/devices/<qui_id_del_device> (es: se l’identificativo fosse 01:05.0 andresti in sys/bus/pci/devices/0000:01:05.0) [*]
    - digitare
    ls
    ==> qual è l’output ?
    find ./ -name idVendor
    ==> qual è l’output ?
    find ./ -name idProduct
    ==> qual è l’output ?
    find ./ -name idVendor | xargs cat
    ==> qual è l’output ?
    find ./ -name idProduct | xargs cat
    ==> qual è l’output ?

    [*]
    In realtà questo è un link alla directory /devices/pci0000:00/0000:00:1e.0/<qui_id_del_device>/
    *** 29 Luglio 2008 ***
    Il device che dà problemi se controllato dal driver EHCI è un host USB interno alla scheda PCMCIA, quindi il suo identificativo lo si trova anche in /sys/bus/pcmcia/devices , ma altro non è che un link che punta alla directory /devices/pci0000:00/0000:00:1e.0/<qui_id_del_device>/.
    ************

    Skumpic scrive:

    @ 5m33
    Perderemo ancora terreno perche il test non riesco a farlo prima di mercoledi/giovedi :)
    Comunque appena metto le mani sulla pc-card della ragazza è la prima cosa che testo :)

    CIAO


    5m33 scrive:

    (Testo REVISIONATO da ultimo il 29 Luglio 2008)

    @ Skumpic e AlexT

    Sabato e Domenica ho revisionato i miei commenti relativi al funzionamento della PC-Card N501HS. Le parti aggiunte sono sottolineate, mentre quelle tolte sono barrate. Ho inserito anche delle annotazioni per chiarire meglio le modifiche apportate.

    Penso che, a beneficio dei lettori, potremo farne un post specifico a più mani con l’intento di venire subito al sodo, cioè di indicare in modo diretto quale sia il motivo del malfunzionamento della N501HS, comprendente il prezioso apporto di Callegari. Posso occuparmene io (ma, per avere maggior chiarezza, mi servirebbe l’output relativo alle directory dei device pci in sysfs, che chiedevo qui:
    http://blog.liberailvoip.it/2008/03/04/onda-n501hs-et501hs-ed-altri-modem-usb-pcmcia-ed-express-card-con-linux-usbserial/#comment-3597 )
    O preferite che lasciamo tutto com’è?
    Che ne dite?

    Ad AlexT segnalo in particolare la mia auto-correzione relativa al “sacrificio” del driver ehci:
    http://blog.liberailvoip.it/2008/03/04/onda-n501hs-et501hs-ed-altri-modem-usb-pcmcia-ed-express-card-con-linux-usbserial/#comment-3467

    A entrambi segnalo la parte che va da “Dal driver ‘sierra’ a quello ‘option’ (Sergio Callegari)” alla fine dell’elenco di risorse che ho compilato giorni fa: http://blog.liberailvoip.it/2008/03/04/onda-n501hs-et501hs-ed-altri-modem-usb-pcmcia-ed-express-card-con-linux-usbserial/#comment-3536

    Ci “rivediamo” alla fine di questa settimana.

    Kudos !

    P.S.
    @ Skumpic

    Perderemo ancora terreno perche il test non riesco a farlo prima di mercoledi/giovedi

    … e invece no :-) , perché rilanciamo con una succosa novità: quattro giorni fa è stato rilasciata l’ultima versione, la 2.6.25.10, del kernel con la quale la N501HS (come tutti i device che hanno problemi con ehci) dovrebbe (il condizionale è d’obbligo) funzionare: vedi sopra. La 2.6.25.1 era del 1° Maggio 2008.


    AlexT scrive:

    5m33

    Ecco gli identificativi che vengono assegnati sul mio pc:

    0000:00:03.3
    0000:06:00.2
    su quest’ultimo gli idVendor/idProduct sono gli stessi del Callegari: 0×1131/0×1562.

    Più tardi ritornerò sull’argomento…


    AlexT scrive:

    x 5m33
    allora come dicevo nel post precedente, sono due gli identificativi che vengono assegnati:
    0000:00:03.3 che ha come
    device: 0×7002
    vendor: 0×1039
    subsystem device: 0x165a
    subsystem vendor: 0×1043
    0000:06:00.2 che ha come
    device: 0×1562
    vendor: 0×1131
    subsystem device: 0×1562
    subsystem vendor: 0×1131
    (quest’ultimo è quello del workaround del Callegari)

    detto questo riporto le velocità riscontrate questo pomeriggio con i diversi driver:
    Sierra 200 KB/s
    Option 150 KB/s
    Airprime 200KB/s
    i thruput sono stati registrati alle ore 15:45, immagino io a cella scarica…

    Detto anche questo, concludo col tassello workaround:
    ho creato i due file (quello che va sul nella cartella delle regole e quello che va nella cartella sbin). ebbene non ne vuole sapere di scaricare il modulo ehci… per il device.
    ho notato 2 cose a questo proposito:
    1. sul file di log manca il parametro pciid;
    2. il file di log viene aggiornato solamente se il file fix-onda-n501hs (quello sulla cartella /usr/local/sbin) viene eseguito da root e non da utente.


    5m33 scrive:

    @ AlexT

    ———————-
    RIGUARDO AL WORKAROUND
    ———————-

    ==> Hai reso lo script in /usr/local/sbin eseguibile con chmod +x ?

    (vedi, qui in calce sub [*], la spiegazione in “verbose mode”)

    ———————-
    RIGUARDO ALLE VELOCITÀ
    ———————-

    Mi sembrano più che buone. Di certo molto meglio di quelle raggiunte da Skumpic. Anzi: direi che sono quasi al top di quanto la rete 3G attualmente riesca a offrire:
    - 200 KByte al secondo equivalgono all’incirca a 2 Megabit al secondo;
    - 150 KByte al secondo equivalgono all’incirca a 1,5 Megabit al secondo
    Se consideri che i 3 Megabit io li ho solo sfiorati pochi giorni fa (almeno: per quello di cui mi sono accorto) e che, di media, viaggio a 1,2 Megabit, sarei più che soddisfatto.
    ==> Erano KiloByte, vero? (non Kilobit)

    ————————————————
    RIGUARDO ALL’IDENTIFICATIVO DELL’INTERFACCIA PCI
    ————————————————

    Ok, perfetto, l’identificativo di interfaccia che il tuo kernel assegna per la comunicazione con la PC-Card è 0000:06:00.2.
    Ora, solo un ultimo sforzo :-) (se ti va)
    ==> Mi servirebbe l’output di lspci (non ti chiedo “lspci -v“, che sarebbe più completo, perché effettivamente questo non mi pare essenziale).
    Però, ora ti spiego anche perché mi servirebbe vedere l’output di lspci: vorrei chiarirmi le idee il più possibile sulla catena di dispositivi, innestati l’uno nell’altro, che i driver devono pilotare.
    Seguimi.
    C’è un’interfaccia PCI (PCI bridge) nella quale è innestata un’altra interfaccia PCI (CardBus bridge) che si occupa della comunicazione con la PC-Card; questa seconda interfaccia, per l’esattezza, opera attraverso un un Bus PCMCIA che fa da ponte con i chip della scheda (se ne occupa un driver per dispositivi PCMCIA: di solito “yenta_cardbus”).
    Quando viene inserita la scheda, al cui interno c’è uno Hub USB, il kernel deve assegnare dei nuovi identificativi di interfaccia (USB Controller) agli host USB dell’Hub: l’interfaccia che, applicando il workaround, non dev’essere associata a ehci_hcd è, nel tuo caso, 0000:06:00.2 (e gli identificativi dell’host USB che corrisponde ad essa sono 1131 (vendor) e 1562 (device)).
    La comunicazione con gli host USB che si trovano all’interno della PC-Card è gestita dal kernel col driver EHCI, oppure OHCI, oppure UHCI.
    Collegato all’host USB che viene riconosciuto come USB 2.0 (e che, in assenza del workaround, sarebbe quindi assegnato all’interfaccia governata da ehci_hcd) c’è il circuito del modem 3G, pilotato da un driver per modem (airprime, option, sierra, ecc.), oppure da un driver per dispositivi seriali connessi via USB (usbserial).
    Bene, la regola di udev di cui al workaround che cosa fa?
    Dice a udev: “quando rilevi un dispositivo che ha i seguenti identificativi: 0×1131 (vendor) e 0×1562 (device), preleva l’identificativo di interfaccia ed evita di gestirlo (unbind) col driver EHCI”.
    Di conseguenza, udev (il daemon udevd), quando riceve dal kernel l’evento di hotplug che gli comunica gli identificativi dei device interni alla PC-Card esegue la regola che corrisponde al device USB 2.0 e quindi non assegna il device che corrisponde all’interfaccia 0000:06:00.2 a ehci e quindi il kernel provvede a farlo controllare da a un driver supplente di EHCI, e cioè UHCI (od OHCI). La comunicazione con gli host USB, attraverso il Bus USB interno alla PC-Card, viene così gestita soltanto da uhci_hcd.
    A questo punto, la comunicazione con gli host USB procede senza intoppi, il modem viene riconosciuto coi suoi idVendor e idProduct e viene caricato automaticamente il driver utile (nel nostro caso è il sierra).

    Secondo me, per la PC-Card N501HS l’architettura è la seguente:
    PCI bridge
          CardBus bridge
                USB Controller 1.1
                USB Controller 1.1
                USB Controller 2.0 (0000:06:00.2)
                      modem

    .

    Per il mio modem 56K su PC-Card, è più semplice:
    PCI bridge (0000:00:1e.0)
          CardBus bridge (0000:01:05.0 - driver "yenta_cardbus")
                modem (0.0 - driver "serial_cs")

    Nell’albero di udev, il mio modem si trova identificato come 0.0 sotto 0000:01:05.0
    /sys/devices/pci0000:00/0000:00:1e.0/0000:01:05.0/0.0
    Nel tuo caso l’albero sarà più articolato (vedi sopra) perché c’è di mezzo il Bus USB interno alla scheda con 3 host USB, e ciascun host USB avrà un proprio identificativo (quello al quale si applica la regola di udev, nel tuo caso sarà 0000:06:00.2)


    .
    In conclusione, se tu impartisci il comando lspci prima senza e poi con la scheda inserita, vedrai che l’output con la scheda inserita è diverso: sono comparsi gli identificativi delle interfacce di comunicazione coi tre host USB e uno di questi –quello corrispondente a USB 2.0– corrisponderà all’interfaccia 06:00.2.

    ==> Se vuoi –ma senza impegno :-) — comunicami l’output di lspci.

    ————– RIGUARDO AL WORKAROUND: Verbose Mode —————-

    [*]
    udev (o meglio, il daemon udevd) è un processo di root, quindi quando lo script del workaround viene eseguito è come se fosse root a farlo. Se sul file di log manca il valore che identifica l’interfaccia PCI, significa che tale valore non è stato prelevato (vedi il mio commento su come funziona il workaround, del 25 giugno). Se non è stato prelevato, vuol dire che l’istruzione RUN della regola di udev non è andata a buon fine e, se l’hai scritta correttamente, ciò può essere spiegato col fatto che udev non è riuscito ad eseguire lo script chiamato, appunto, dall’istruzione RUN.

    Diagnosi.

    ==> Non è che hai dimenticato di rendere eseguibile lo script?

    Il fatto che tu abbia precisato che lo script riesci a eseguirlo, anche se ci riesci solo come root, contrasterebbe con questa ipotesi, ma… non è che per caso lo hai eseguito con il comando “sh” ? Perché, se così fosse, avresti chiamato lo script come parametro da passare alla shell (Bash), la quale eseguirebbe le istruzioni dello script a prescindere dal fatto che il file che contiene lo script avesse l’attributo di “eseguibile”, o meno. L’attributo di un file che permette di eseguirlo significa che quando un file inizia con la riga “#! /bin/sh” (riga che sarebbe superflua se venisse eseguito col comando sh), il suo contenuto viene trasferito a Bash, che lo interpreta. Quindi l’interprete dei comandi viene avviato a partire dalla digitazione del nome del file e con i diritti di chi ha eseguito tale file.

    Altrimenti, se cioè tu hai eseguito lo script come root digitando il suo nome direttamente, cioè non come…
    sudo sh /usr/local/sbin/fix-onda-n501hs
    (che è l’ipotesi appena fatta sopra), ma come…
    sudo /usr/local/sbin/fix-onda-n501hs
    allora, non mi viene in mente un’ipotesi che spieghi perché udev non riesce a farlo partire. A parte quella dell’errore di sintassi / ortografia / battitura. Occhio, quindi, a non fare taglia & incolla: scrivi i comandi ex-novo, perché i singoli caratteri, molto spesso vengono modificati dalla piattaforma di gestione di un blog o di un sito: due trattini possono diventare un trattino lungo, le virgolette cambiano da apici semplici in virgolette tipografiche, l’apostrofo cambia da apostrofo dritto ad apostrofo curvo (e sono proprio caratteri diversi come codice ASCII, quindi non sono assolutamente i caratteri giusti).

    Se vuoi, ecco un’illustrazione con esempi di quanto ho detto sopra:

    // test.sh è uno script che manda in output la stringa “questa è una prova”
    .
    io in /usr/local/sbin $ ls -l
    total 4
    -rw-r--r-- 1 root root 38 10 lug 15:12 test.sh

    // come vedi, ora non è eseguibile (manca l’attributo “x”),
    // però… se lo eseguo come argomento del comando “sh”, viene eseguito…
    // … sia come utente normale…

    io in /usr/local/sbin $ sh test.sh
    questa è una prova

    // sia come root

    io in /usr/local/sbin $ su
    Password:

    root in /usr/local/sbin # sh test.sh
    questa è una prova

    // ora provo a eseguire direttamente lo script come utente normale…

    root in /usr/local/sbin # exit

    io in /usr/local/sbin $ ./test.sh
    bash: ./test.sh: Permission denied

    // (non funziona)

    // ora provo a eseguirlo direttamente come root…

    io in /usr/local/sbin $ su
    Password:

    root in /usr/local/sbin # ./test.sh
    bash: ./test.sh: Permission denied

    // ... (non funziona)

    // Perché non funziona se lo eseguo direttamente chiamando il file?
    // Perché il file non ha i permessi di esecuzione: ora glieli dò:

    root in /usr/local/sbin # chmod +x test.sh

    root in /usr/local/sbin # ls -l
    total 4
    -rwxr-xr-x 1 root root 38 10 lug 15:12 test.sh

    // ... e funziona, sia come root...

    root in /usr/local/sbin # ./test.sh
    questa è una prova

    // .. sia come utente normale.

    root in /usr/local/sbin # exit

    io in /usr/local/sbin $ ./test.sh
    questa è una prova


    Commentato da 5m33 | luglio 22, 2008, 13:00 |
  13. Ciao Ragazzi,
    sono appena rientrato oggi al lavoro dopo poco più di una settimana di ferie….
    datemi il tempo di digerire il rientro ed entro qualche giorno (2-3) risponderò a tutti.

    Commentato da AlexT | luglio 28, 2008, 10:38 |
  14. @ AlexT
    ——————————-

    Ho terminato ora la rilettura delle mie revisioni del thread sulla scheda dell’Onda.
    Ci sono innumerevoli ripetizioni, ma ho preferito mantenerle per non perdere traccia dei vari passaggi. Mi rendo conto che, così com’è, il tutto è digeribile solo da chi sia già veramente dentro l’argomento, per cui mi riprometto di farne, nel prossimo futuro, una versione che invece di mantenere tutta la history venga subito al sodo. Potrei pubblicarla in un post ad-hoc.
    Gli aggiornamenti finali che ho inserito oggi sono marcati con la barra rossa a sinistra, sottolineati e in corsivo.
    Alla fin della fiera, mi pare che l’unico aspetto che mi resta poco chiaro consista nella dinamica del caricamento automatico del driver EHCI quando si toglie e si reinserisce la scheda.
    L’unico modo per saperlo sarebbe che qualcuno, in animo di generosità, facesse la prova (nel caso, fare riferimento alle parti, dove si trova scritto “da verificare“,…

    marcate come aggiornamenti del 30 Luglio: ecco qui i link:   1    ,    2    ,    3    ,    4  ).

    Buona notte a tutti :-)

    *** 29 Luglio, ore 18:28 ***
    Il thread è ora interamente revisionato. Suggerisco, però, di rimandare la sua eventuale rilettura al 31 Luglio, in modo che possa avere un giorno di tempo per ulteriori modifiche che si rendessero necessarie.

    *** 28 Luglio, ore 22:18 ***
    Sto finendo la revisione del thread: domani (29 Luglio) dovrei metterla on-line.
    ==> Se ne hai voglia, rileggi (domani, quando avrò messo on-line l’aggiornamento metterò un avviso qui) le mie risposte, perché ci saranno parecchie parti modificate.

    Commentato da 5m33 | luglio 30, 2008, 23:29 |

Lascia un commento

Devi essere autenticato per lasciare un commento.