2012-04-15 11 views
6

La mia domanda è piuttosto ampia, lo so, ma mi sono interrogato su questo a lungo.Un dispositivo USB difettoso potrebbe causare un crash di un kernel Linux privo di errori?

Un po 'di background. Lavoro in un laboratorio di fisica dove tutti i computer di laboratorio eseguono Debian (mix di vecchia versione e Lenny) o più recentemente Ubuntu 10.4 LTS. Abbiamo scritto un sacco di software personalizzati per interfacciarsi con l'hardware di esperimento e altri computer.

Abbiamo molte schede FPGA che controllano varie parti dell'esperimento, queste sono collegate tramite USB a diversi computer. Dopo aver aggiornato un computer che controlla un esperimento, abbiamo iniziato a vedere arresti anomali/blocchi del computer che eseguivano tutti i laser. Questo era completamente stabile.

La mia domanda è questa: se l'intero computer si blocca a causa di un problema con il a) Python/GTK software GUI b) driver di periferica USB o c) Il dispositivo reale questo può essere imputato al Linux kernel (o altri livelli del sistema operativo)?

È ingiusto chiedere al kernel di Linux di non farsi prendere dal panico anche se commetto errori nella mia implementazione di software/hardware.

La mia ipotesi: qualsiasi applicazione a livello di utente non dovrebbe mai essere in grado di arrestare l'intero sistema poiché dovrebbe avere accesso solo alle proprie cose.

Qualsiasi driver di periferica diventa parte del kernel stesso e pertanto sarà in grado di bloccarlo. Il mio ragionamento suona?

Domanda bonus: C'è un modo per isolare dispositivo e kernel in qualche modo tale che Linux continuerà a funzionare felicemente, non importa quali stupidi errori siano stati fatti con l'hardware. Ciò sarebbe molto utile per due motivi: 1) il debug è più facile con un sistema in esecuzione, 2) Ai fini dell'esperimento abbiamo davvero bisogno di lunghi periodi di inattività e avere solo una parte del crash del sistema è infinitamente migliore degli arresti anomali in uno parte del sistema si sta propagando al resto.

Qualsiasi link e materiale di lettura su questo argomento sarebbe apprezzato. Grazie.

+0

Non sono esperto in arresti anomali, ma direi che hai ragione nelle tue ipotesi. Per quanto riguarda la domanda bonus, gli errori _logical_ (cioè cattivo protocollo) dovrebbero essere gestiti dal kernel senza ulteriori problemi; ma gli errori _phisical_ (cioè cortocircuito, sovracorrente, ecc.) non possono essere, in generale, gestiti dal kernel e provocano diversi livelli di disastro. – rodrigo

risposta

3

Sei corretto che il codice non privilegiato non dovrebbe essere in grado di far cadere il sistema, a meno che non ci sia un bug del kernel. La linea tra privilegiato e privilegiato non è esattamente la stessa di user-space vs kernel, comunque. Un programma in modalità utente può aprire /dev/kmem e cestinare le strutture di dati interne del sistema operativo, se l'account utente dispone di privilegi di superutente.

Per isolare il kernel principale dai problemi del driver di periferica, eseguire il driver di dispositivo all'interno di una macchina virtuale.

Diversi sistemi VM, tra cui VMWare Workstation, supportano l'inoltro di un dispositivo USB arbitrario dall'host al guest senza un driver specifico del dispositivo sull'host.

+0

Domanda successiva. Supponendo che il driver del dispositivo sia stato scritto correttamente, qualsiasi guasto hardware (del dispositivo collegato) non dovrebbe essere in grado di far scendere il sistema, corretto? – HansHarhoff

+0

@HansHarhoff: Finché l'hardware guasto non causa le tolleranze massime consentite specificate per la porta del computer in cui è collegato a essere violato, è corretto.La maggior parte degli host USB è tollerante per i cortocircuiti, ad esempio. D'altra parte, se si ha un colpo di fulmine salta su un cavo USB, tutte le scommesse sono spente perché i valori massimi saranno superati. –

+0

Le mie due preoccupazioni principali sono come si dice cortocircuiti della porta USB (o almeno cadute di tensione) e la disconnessione accidentale/improvvisa dell'hardware. Stiamo per testare se gli hub USB alimentati potrebbero funzionare come buffer per il cortocircuito. Per quanto riguarda la rimozione improvvisa, immagino che le cose importanti siano avere un po 'di tempo quando si aspetta una risposta. – HansHarhoff

Problemi correlati