Condividi tramite

Esercizio 4 - Identificare i problemi con i dispositivi USB

  • Articolo

I controller host USB possono spegnere solo dopo che tutti i dispositivi connessi a loro hanno immesso uno stato di basso consumo. Ciò significa che i dispositivi USB devono supportare la sospensione selettiva nei dispositivi Modern Standby per garantire che il SoC possa immettere DRIPS mentre lo schermo è spento.

Parte 1: Usare un report SleepStudy per identificare i problemi

  1. Scaricare il report sleepstudy-report_2.html generato qui.

  2. Aprire sleepstudy-report_2.html con il browser preferito.

    • Si noti che il sistema è in grado di utilizzare fino a 120 mW durante lo standby (ad esempio, vedere Sessione standby 6).

    Screenshot shows example data of the systems energy consumption including time, mWh, percent of battery, and Drain state

  3. Fare clic su Sessione 10. Il sistema consuma 2,83 watt di energia durante 11 minuti e la percentuale DRIPS è 0.

    Screenshot shows Connected Standby Session 10 example data including start time, duration, energy change, change rate and percentage power state time

  4. Guarda la tabella Top Offenders .

    1. Controller host USB (_SB. PCI0. XHC) è attivo per il 99% della durata della sessione.

    2. XHC è il controller host USB 3.0.

Screenshot shows example table of top offenders.

Quando il controller bus USB è attivo per minuti alla volta in Standby moderno, in genere significa che un dispositivo USB collegato al bus non entra in sospensione selettiva, probabilmente perché non supporta la sospensione selettiva. Il passaggio logico successivo consiste nel determinare quale dispositivo USB rimane in D0 esaminando una traccia ETL.

Per altre informazioni sulla sospensione selettiva, vedere l'argomento Sospensione selettiva USB su MSDN.

Parte 2: Usare una traccia ETL per identificare i problemi

Per approfondire l'indagine USB, è stata acquisita una traccia ETL nello stesso sistema in cui è stato generato SleepStudy .

Per analizzare i problemi relativi a USB, si useranno il grafico e la tabella DState .

  1. Scarica la traccia USBProblem.etl pregenerata qui.

  2. Aprire USBProblem.etl con WPA.

  3. Trascinare e rilasciare il grafico DRIPS nella scheda di analisi .

  4. Esaminare i motivi non Drips e trovare il controller host xHCI USB come dispositivo che impedisce al sistema di immettere DRIPS.

    • È possibile notare che il dispositivo è attivo per il 98% della traccia (come illustrato nella colonna % Tempo motivo ).

      Screenshot of sample data using WPA.

  5. Ingrandire l'area in cui è attivo il controller host xHCI USB.

    1. Selezionare il dispositivo nella tabella.

    2. Fare clic con il pulsante destro del mouse sull'intervallo blu chiaro nel grafico e scegliere Zoom.

    3. Il tempo % motivo dovrebbe ora essere 100%.

    Screenshot of WPA zoomed in on Responsible Component column

  6. Trovare il grafico Device Dstate nella categoria Power di Graph Explorer.

    Screenshot of WPA zoomed in on Power, CPU Frequency, CPU Idle States, and Device Dstate graphs

  7. Trascinare e rilasciare il grafico Device Dstate nella scheda di analisi .

    • Il grafico Device DState mostra gli stati D-D effettivi dei dispositivi nel tempo. È possibile usare i dati per determinare se un dispositivo specifico entra nello stato D appropriato mentre il sistema è in standby moderno.

      • Tipo PoFx: usato per i dispositivi gestiti da Windows Power Management Framework.

      • Tipo non PoFx: usato per i dispositivi collegati tramite USB.

  8. Spostare la colonna DState accanto alla colonna Tipo . Il riquadro di visualizzazione dovrebbe essere simile al seguente:

    Screenshot shows example DState data.

  9. Espandere la categoria Non-PoFX .

  10. Espandere la riga Dstate con il valore 0x0 (stato D0 o attivo).

  11. Ordinare in base alla colonna Nome e trovare i dispositivi USB.

    Screenshot shows example DState data based on USB devices.

I dati nella tabella dello stato D indicano che, mentre il sistema era in standby, un dispositivo composito USB era ancora nello stato D0 per il 100% del tempo. L'ID hardware del dispositivo composito è USB\VID_0BB4&PID_0BA1\00000015B42 edizione Enterprise 80F000000000000000000000. Si tratta del dispositivo che impediva l'accensione del controller XHCI.

Se il dispositivo è gestito da un driver creato da Microsoft, segnalare il problema a Microsoft. In caso contrario, queste informazioni devono essere segnalate al fornitore dell'hardware proprietario del driver per trovare una soluzione e assicurarsi che il dispositivo entri in sospensione selettiva.