Udostępnij przez

Praca z GUID_DEVICE_RESET_INTERFACE_STANDARD

Interfejs GUID_DEVICE_RESET_INTERFACE_STANDARD definiuje standardowy sposób, w jaki sterowniki funkcjonalne mogą próbować zresetować i odzyskać wadliwe urządzenie.

Dwa typy resetowania urządzeń są dostępne za pośrednictwem tego interfejsu:

  • Resetowanie urządzenia na poziomie funkcji. W takim przypadku operacja resetowania jest ograniczona do określonego urządzenia i nie jest widoczna dla innych urządzeń. Urządzenie pozostaje połączone z magistralą przez cały czas resetowania i wraca do prawidłowego stanu (stan początkowy) po zresetowaniu. Ten typ resetowania ma najmniejszy wpływ na system.

  • Ten typ resetowania można zaimplementować za pomocą sterownika magistrali lub oprogramowania układowego ACPI. Kierowca magistrali może zaimplementować resetowanie na poziomie funkcji, jeśli specyfikacja magistrali definiuje mechanizm resetowania pasm, który spełnia wymagania. Oprogramowanie układowe ACPI może opcjonalnie zastąpić reset funkcji zdefiniowany przez sterownik magistrali własną implementacją.

  • Resetowanie urządzenia na poziomie platformy. W takim przypadku operacja resetowania powoduje zgłaszanie urządzenia jako brakującego z magistrali. Operacja resetowania ma wpływ na określone urządzenie i wszystkie inne urządzenia, które są z nim połączone za pośrednictwem tej samej szyny zasilania lub linii resetowania. Ten typ resetowania ma największy wpływ na system. System operacyjny usuwa i ponownie kompiluje stosy wszystkich urządzeń, których dotyczy problem, aby upewnić się, że wszystkie elementy są uruchamiane ponownie z pustego stanu.

Począwszy od systemu Windows 10, te wpisy rejestru w kluczu HKLM\SYSTEM\CurrentControlSet\Control\Pnp konfigurują operację resetowania:

  • DeviceResetRetryInterval: okres przed rozpoczęciem operacji resetowania. Wartość domyślna to 3 sekundy. Wartość minimalna to 100 milisekund; wartość maksymalna to 30 sekund.

  • DeviceResetMaximumRetries: liczba prób wykonania operacji resetowania.

Uwaga

Interfejs GUID_DEVICE_RESET_INTERFACE_STANDARD jest dostępny w systemie Windows 10.

Korzystanie z interfejsu resetowania urządzenia

Jeśli sterownik funkcji wykryje, że urządzenie nie działa prawidłowo, należy najpierw spróbować zresetować poziom funkcji. Jeśli resetowanie na poziomie funkcji nie rozwiąże problemu, sterownik może zdecydować się na próbę zresetowania na poziomie platformy. Jednak resetowanie na poziomie platformy powinno być używane tylko jako ostateczna opcja.

Aby wysłać zapytanie dotyczące tego interfejsu, sterownik urządzenia wysyła IRP_MN_QUERY_INTERFACE IRP w dół stosu sterowników. W przypadku tego protokołu IRP sterownik ustawia parametr wejściowy InterfaceType na GUID_DEVICE_RESET_INTERFACE_STANDARD. Po pomyślnym zakończeniu protokołu IRP parametr wyjściowy interfejsu jest wskaźnikiem do struktury DEVICE_RESET_INTERFACE_STANDARD. Ta struktura zawiera wskaźnik do procedury DeviceReset, która może służyć do żądania resetowania na poziomie funkcji lub na poziomie platformy.

Obsługa interfejsu resetowania urządzenia w sterownikach funkcji

Aby obsługiwać interfejs resetowania urządzenia, stos urządzeń musi spełniać następujące wymagania.

Sterownik funkcjonalny musi właściwie obsługiwać IRP_MN_QUERY_REMOVE_DEVICE, IRP_MN_REMOVE_DEVICE oraz IRP_MN_SURPRISE_REMOVAL.

W większości przypadków, gdy sterownik odbiera IRP_MN_QUERY_REMOVE_DEVICE, powinien zwrócić komunikat o powodzeniu, aby można było bezpiecznie usunąć urządzenie. Jednak mogą wystąpić przypadki, w których urządzenie nie może być bezpiecznie zatrzymane, na przykład jeśli urządzenie jest zablokowane w pętli zapisu w buforze pamięci. W takich przypadkach sterownik powinien zwrócić STATUS_DEVICE_HUNG jako odpowiedź na IRP_MN_QUERY_REMOVE_DEVICE. Menedżer PnP kontynuuje proces IRP_MN_QUERY_REMOVE_DEVICE i IRP_MN_REMOVE_DEVICE, ale ten konkretny stos nie otrzyma IRP_MN_REMOVE_DEVICE. Zamiast tego stos urządzeń otrzyma IRP_MN_SURPRISE_REMOVAL po zresetowaniu urządzenia.

Aby uzyskać więcej informacji o tych IRPs, zobacz:

Obsługa żądania IRP_MN_QUERY_REMOVE_DEVICE

Obsługa żądania IRP_MN_REMOVE_DEVICE

Jak obsługiwać żądanie IRP_MN_SURPRISE_REMOVAL

Obsługa interfejsu resetowania urządzenia w sterownikach filtrów

Sterowniki filtrów mogą przechwytywać IRP_MN_QUERY_INTERFACE irps, które mają typ interfejsu GUID_DEVICE_RESET_INTERFACE_STANDARD. Dzięki temu mogą nadal delegować do interfejsu GUID_DEVICE_RESET_INTERFACE_STANDARD, ale wykonywać operacje specyficzne dla urządzenia przed lub po operacji resetowania. Alternatywnie mogą zastąpić interfejs GUID_DEVICE_RESET_INTERFACE_STANDARD zwrócony przez sterownik magistrali własnym interfejsem, aby zapewnić własną operację resetowania.

Obsługa interfejsu resetowania urządzenia w sterownikach magistrali

Kierowcy magistrali, którzy uczestniczą w procesie resetowania urządzenia (czyli sterowniki magistrali skojarzone z urządzeniem, które żądają zresetowania i sterowników magistrali skojarzonych z urządzeniami, które odpowiadają na żądanie resetowania) muszą spełniać jedno z następujących wymagań:

  • Możliwość obsługi hot plug. Kierowca autobusu musi być w stanie wykryć usunięcie urządzenia z autobusu bez powiadomienia oraz podłączenie urządzenia do autobusu.

  • Alternatywnie musi zaimplementować interfejs GUID_REENUMERATE_SELF_INTERFACE_STANDARD. To symuluje odłączanie urządzenia od magistrali i ponowne podłączanie go. Wbudowane sterowniki magistrali (takie jak PCI i SDBUS) obsługują ten interfejs. W związku z tym, jeśli resetowanie urządzenia korzysta z jednej z tych szyn, nie powinny być konieczne żadne modyfikacje sterownika szyny.

W przypadku sterowników magistrali opartych na frameworku WDF, framework WDF rejestruje interfejs GUID_REENUMERATE_SELF_INTERFACE_STANDARD dla sterowników. W związku z tym zarejestrowanie tego interfejsu nie jest konieczne dla tych sterowników. Jeśli kierowca autobusu musi wykonać pewne operacje, zanim jego urządzenia podrzędne zostaną ponownie wyliczone, musi zarejestrować się w evtChildListDeviceReenumerated procedury wywołania zwrotnego i wykonać operacje w tej procedurze. Ponieważ ta procedura wywołania zwrotnego może być wywoływana równolegle dla wszystkich Fizycznych Obiektów Urządzeń (PDO), kod tej procedury może potrzebować ochrony przed warunkami wyścigu.

Oprogramowanie układowe ACPI: reset na poziomie funkcji

Aby obsługiwać resetowanie urządzenia na poziomie funkcji, musi istnieć metoda _RST zdefiniowana w zakresie urządzenia. Jeśli istnieje, ta metoda zastępuje implementację resetowania urządzenia na poziomie funkcji przez sterownik magistrali (jeśli jest dostępna) dla tego urządzenia. Po wykonaniu metoda _RST musi resetować tylko to urządzenie i nie może mieć wpływu na inne urządzenia. Dodatkowo urządzenie musi być cały czas podłączone do magistrali.

Oprogramowanie układowe ACPI: resetowanie na poziomie platformy

Aby obsługiwać resetowanie urządzeń na poziomie platformy, dostępne są dwie opcje:

  • Oprogramowanie układowe ACPI może zdefiniować usługę PowerResource, która implementuje metodę _RST, a wszystkie urządzenia, których dotyczy ta metoda resetowania, mogą odwoływać się do tej usługi PowerResource za pośrednictwem obiektu _PRR zdefiniowanego w zakresie urządzenia.

  • Urządzenie może zadeklarować obiekt _PR3. W takim przypadku sterownik ACPI używa cyklu zasilania D3cold do przeprowadzenia resetu, a zależności dotyczące resetowania zostaną określone na podstawie obiektu _PR3.

Jeśli obiekt _PRR istnieje w zakresie urządzenia, sterownik ACPI używa metody _RST w odwołanej usłudze PowerResource do wykonania resetowania. Jeśli obiekt _PRR nie jest zdefiniowany, ale obiekt _PR3 jest zdefiniowany, sterownik ACPI używa cyklu zasilania D3cold do przeprowadzenia resetu. Jeśli żaden obiekt _PRR lub _PR3 nie jest zdefiniowany, urządzenie nie obsługuje resetowania na poziomie platformy, a sterownik ACPI zgłasza, że resetowanie na poziomie platformy nie jest dostępne.

Weryfikowanie oprogramowania układowego ACPI w systemie testowym

Aby przetestować sterownik obsługujący resetowanie i odzyskiwanie urządzenia, wykonaj tę procedurę. W tej procedurze przyjęto założenie, że używasz tego przykładowego pliku ASL.

DefinitionBlock("SSDT.AML", "SSDT", 0x01, "XyzOEM", "TestTabl", 0x00001000)
{
   Scope(\_SB_)
      {
       PowerResource(PWFR, 0x5, 0x0)
       {
           Method(_RST, 0x0, NotSerialized)    { }
           
           // Placeholder methods as power resources need _ON, _OFF, _STA.
           Method(_STA, 0x0, NotSerialized)
           {
               Return(0xF)
           }

           Method(_ON_, 0x0, NotSerialized)    { }

           Method(_OFF, 0x0, NotSerialized)    { }

       } // PowerResource()
   } // Scope (\_SB_)

   // Assumes WiFi device is declared under \_SB.XYZ.
   Scope(\_SB_.XYZ.WIFI)
       {

       // Declare PWFR as WiFi reset power rail
       Name(_PRR, Package(One)
           {
               \_SB_.PWFR
           })
       } // Scope (\_SB)
}
  1. Skompiluj testowy plik ASL na AML przy użyciu kompilatora ASL, takiego jak Asl.exe. Plik wykonywalny zawarty w zestawie sterowników systemu Windows (WDK).
Asl <test>.asl

Poprzednie polecenie generuje plik SSDT.aml.

  1. Zmień nazwę pliku SSDT.aml na acpitabl.dat.

  2. Skopiuj acpitabl.dat do %systemroot%\system32 w systemie testowym.

  3. Włącz podpisywanie testowe w systemie testowym.

bcdedit /set testsigning on

  1. Uruchom ponownie system testowy.

  2. Sprawdź, czy tabela jest załadowana. W debugerze systemu Windows użyj tych poleceń.

  • !acpicache
  • dt _DESCRIPTION_HEADER adres tabeli SSDT
0: kd> !acpicache
Dumping cached ACPI tables...
  SSDT @(ffffffffffd03018) Rev: 0x1 Len: 0x000043 TableID: TestTabl
  XSDT @(ffffffffffd05018) Rev: 0x1 Len: 0x000114 TableID: HSW-FFRD
       ...
       ...
 
0: kd> dt _DESCRIPTION_HEADER ffffffffffd03018
ACPI!_DESCRIPTION_HEADER
   +0x000 Signature        : 0x54445353
   +0x004 Length           : 0x43
   +0x008 Revision         : 0x1 ''
   +0x009 Checksum         : 0x37 '7'
   +0x00a OEMID            : [6]  "XyzOEM"
   +0x010 OEMTableID       : [8]  "TestTabl"
   +0x018 OEMRevision      : 0x1000
   +0x01c CreatorID        : [4]  "MSFT"
   +0x020 CreatorRev       : 0x5000000

Zobacz także

_DEVICE_RESET_INTERFACE_STANDARD

  • Last updated on