EZCAP 324B: restart zamiast wyłączenia. Rozwiązanie w Debianie

Po zamontowaniu karty przechwytującej EZCAP 324B pojawił się nietypowy problem. Sam grabber działał prawidłowo, ale przy wyłączaniu komputera system kończył pracę, po czym komputer uruchamiał się ponownie. Po fizycznym wyjęciu karty ze slotu PCI Express problem całkowicie znikał.

Objaw występował zarówno w Debianie, jak i w Windows 11. W Linuksie udało się znaleźć proste i skuteczne rozwiązanie. Przy okazji diagnostyka pokazała też ciekawą konstrukcję EZCAP 324B. Karta jest fizycznie montowana w PCI Express, ale właściwy grabber pracuje jako urządzenie USB 3.0 za własnym kontrolerem xHCI.

Jak EZCAP 324B zgłasza się w systemie

Pierwszą wskazówkę dało polecenie lsusb. Karta zgłaszała się w Debianie jako:

Bus 004 Device 002: ID 32ed:3200 ezcap ezcap LIVE GAMER RAW

To może zaskakiwać, ponieważ karta jest wpięta do slotu PCI Express. Dokładniejsze sprawdzenie topologii USB wyjaśniło sytuację:

/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 003: Dev 002, If 0, Class=Video, Driver=uvcvideo, 5000M
    |__ Port 003: Dev 002, If 1, Class=Video, Driver=uvcvideo, 5000M
    |__ Port 003: Dev 002, If 2, Class=Audio, Driver=snd-usb-audio, 5000M
    |__ Port 003: Dev 002, If 3, Class=Audio, Driver=snd-usb-audio, 5000M
    |__ Port 003: Dev 002, If 7, Class=Human Interface Device, Driver=usbhid, 5000M

Wideo korzysta ze standardowego sterownika UVC uvcvideo, audio z snd-usb-audio, a dodatkowy interfejs z usbhid. W Windows 11 ten sam sprzęt ujawnia kontroler Fresco Logic USB 3.0 eXtensible Host Controller. W praktyce PCI Express służy tutaj jako magistrala dla kontrolera USB, a grabber znajduje się za nim jako urządzenie USB o identyfikatorze 32ed:3200.

Identyfikacja urządzenia w sysfs

Numer urządzenia z lsusb nie jest nazwą używaną w /sys/bus/usb/devices. W mojej konfiguracji właściwą ścieżkę można było znaleźć po VID i PID:

for d in /sys/bus/usb/devices/*; do
  [[ -f "$d/idVendor" && -f "$d/idProduct" ]] && \
  grep -q "32ed" "$d/idVendor" && \
  grep -q "3200" "$d/idProduct" && echo "$d"
done

Wynik:

/sys/bus/usb/devices/4-3

W innym komputerze albo po zmianie topologii urządzeń nazwa 4-3 może być inna, dlatego w docelowym rozwiązaniu lepiej nie wpisywać jej na stałe.

Pierwsza próba: unbind urządzenia

Pierwszy pomysł był prosty: przed zamknięciem systemu odłączyć EZCAP od sterownika USB. Ręczny test działał poprawnie, urządzenie znikało z systemu, ale komputer nadal restartował się zamiast wyłączyć.

echo 4-3 | sudo tee /sys/bus/usb/drivers/usb/unbind

To był ważny wynik. Problem nie wynikał wyłącznie z tego, że aktywny pozostawał uvcvideo, snd-usb-audio albo usbhid. Trzeba było szukać w zarządzaniu energią samego urządzenia USB.

Rozwiązanie w Debianie: power/control = on przed poweroff

Przełomem okazało się ustawienie power/control na on bezpośrednio przed wyłączeniem systemu:

echo on | sudo tee /sys/bus/usb/devices/4-3/power/control
sudo poweroff

Po tej zmianie komputer wyłączył się prawidłowo. Warto zwrócić uwagę na kierunek tej zmiany. Nie odłączamy karty i nie próbujemy jej dodatkowo usypiać. Wręcz przeciwnie, przed samym shutdownem wyłączamy runtime autosuspend dla EZCAP i pozostawiamy urządzenie w stanie aktywnym.

W mojej konfiguracji właśnie stan zarządzania energią używany przy auto prowadził do restartu podczas końcowej fazy wyłączania. Ustawienie on usuwa problem.

Dynamiczny skrypt dla EZCAP 32ed:3200

Żeby rozwiązanie nie zależało od ścieżki 4-3, przygotowałem skrypt wyszukujący kartę po jej VID i PID:

#!/bin/bash

for DEV in /sys/bus/usb/devices/*; do
    if [[ -f "$DEV/idVendor" && -f "$DEV/idProduct" ]]; then
        VENDOR=$(<"$DEV/idVendor")
        PRODUCT=$(<"$DEV/idProduct")

        if [[ "$VENDOR" == "32ed" && "$PRODUCT" == "3200" ]]; then
            echo on > "$DEV/power/control"
            echo "Ustawiono power/control=on dla $DEV"
        fi
    fi
done

Skrypt można zapisać jako:

/usr/local/sbin/fix-ezcap-power.sh

Następnie nadać mu prawa wykonywania:

sudo chmod +x /usr/local/sbin/fix-ezcap-power.sh

Test ręczny:

sudo /usr/local/sbin/fix-ezcap-power.sh

W moim przypadku skrypt zwraca:

Ustawiono power/control=on dla /sys/bus/usb/devices/4-3

Automatyczne wykonanie tylko przy zamykaniu systemu

Nie chciałem wyłączać autosuspend na stałe. Podczas normalnej pracy karta może korzystać z domyślnego power/control=auto. Wymuszenie on jest potrzebne wyłącznie przed wyłączeniem komputera.

Do tego można użyć jednostki systemd:

[Unit]
Description=Fix EZCAP USB power before shutdown
DefaultDependencies=no
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/fix-ezcap-power.sh

[Install]
WantedBy=shutdown.target

Plik zapisujemy jako:

/etc/systemd/system/fix-ezcap-power.service

Potem włączamy usługę:

sudo systemctl enable fix-ezcap-power.service

Status po włączeniu może wyglądać tak:

Loaded: loaded (.../fix-ezcap-power.service; enabled)
Active: inactive (dead)

inactive (dead) jest w tym przypadku normalne. Usługa typu oneshot nie ma działać cały czas. Ma zostać uruchomiona w odpowiednim momencie procesu zamykania systemu.

Co nie pomogło w BIOS-ie

Przed znalezieniem rozwiązania sprawdziłem również ustawienia zasilania płyty głównej. Testowałem między innymi Power Supply Idle Control = Typical Current Idle oraz Power Loading = Enabled. Zmiany te nie usunęły problemu. Podobnie zachowywał się komputer przy włączonym ErP.

Warto o tym wspomnieć, ponieważ restart zamiast wyłączenia często prowadzi diagnostykę w stronę ACPI, zasilacza albo ustawień Ryzen C-State. W tym przypadku kluczowe okazało się jednak zarządzanie energią urządzenia USB znajdującego się na karcie EZCAP.

Windows 11: ten sam objaw, trudniejsze obejście

Windows 11 zachowywał się tak samo. Wybranie opcji Zamknij kończyło się ponownym uruchomieniem komputera. W Menedżerze urządzeń widać było kontroler Fresco Logic USB 3.0 eXtensible Host Controller - 1.0 (Microsoft) oraz odpowiadający mu Root Hub.

Sprawdziłem kilka najczęściej polecanych metod:

• wyłączenie opcji pozwalającej systemowi wyłączać urządzenie w celu oszczędzania energii,
• ustawienie DeviceSelectiveSuspended=0 w rejestrze,
• przejście na sterownik Microsoft USB xHCI,
• wyłączenie kontrolera oraz Root Hub przez Disable-PnpDevice,
• ręczne wyłączenie obu urządzeń w Menedżerze urządzeń na długo przed zamknięciem systemu.

Żaden z tych sposobów nie dał odpowiednika linuksowego power/control=on. Co ciekawe, ręczne wyłączenie kontrolera i Root Hub podczas działającej sesji Windows również nie wystarczało. Można było pracować jeszcze godzinę, ale późniejsze zamknięcie systemu nadal kończyło się restartem.

Inaczej było wtedy, gdy Windows uruchomił się już z tymi urządzeniami wyłączonymi. W takim przypadku komputer zamykał się prawidłowo. To sugeruje, że znaczenie ma nie tylko końcowy stan urządzenia, ale również sposób, w jaki kontroler został zainicjalizowany podczas startu systemu i później uczestniczy w sekwencji zasilania.

Praktyczne rozwiązanie w Windows

Nie znalazłem w Windows 11 prostego i pewnego odpowiednika rozwiązania z Debiana. W moim przypadku Windows jest systemem pomocniczym, dlatego praktycznym wyjściem było pozostawienie kontrolera EZCAP wyłączonego w Menedżerze urządzeń. Dzięki temu system uruchamia się z nieaktywnym kontrolerem i później poprawnie się zamyka.

Jeżeli ktoś korzysta z EZCAP 324B głównie pod Windows, takie obejście oczywiście mija się z celem, ponieważ karta przestaje być dostępna. W takim scenariuszu warto potraktować opisane testy raczej jako diagnostykę problemu niż pełne rozwiązanie.

Wnioski

Najważniejszy wniosek jest taki, że restart komputera przy wyłączaniu nie musi oznaczać problemu z ACPI płyty głównej, zasilaczem albo samym systemem. EZCAP 324B zawiera własny kontroler USB podłączony przez PCI Express i to stan zasilania urządzenia znajdującego się za tym kontrolerem może zaburzyć końcową fazę shutdownu.

W Debianie rozwiązanie okazało się proste i działa powtarzalnie: przed poweroff należy ustawić power/control=on dla urządzenia 32ed:3200. Automatyczne wyszukiwanie po VID i PID eliminuje zależność od konkretnego numeru magistrali i portu.

W Windows 11 nie udało mi się uzyskać równie eleganckiego efektu. Jeśli pojawi się metoda pozwalająca wymusić analogiczny stan zasilania kontrolera bez wyłączania samej karty, ten artykuł uzupełnię.