RTV forum PL | NewsGroups PL

resetowanie urządzenia USB

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - resetowanie urządzenia USB

Goto page Previous  1, 2, 3  Next

Marek
Guest

Sun Mar 04, 2018 11:27 pm   



On Sun, 4 Mar 2018 00:12:39 -0800 (PST),
Budyń<budynpl.poland_at_gmail.com> wrote:
Quote:
Jakies inne opcje? Albo jakas znana metoda resetu programowego? To
widzia
łbym najchętniej.

Jedynie możesz przeładować moduły uhci/ohci, ale to nie zawsze
pomaga. To jest faktycznie problematyczne, bo czegoś takiego jak
programowy reset USB faktycznie nie ma.

--
Marek

Jarosław Sokołowski
Guest

Mon Mar 05, 2018 1:17 am   



Pan Zbych napisał:

Quote:
To jest normalny przypadek, potrafię go wywołać na zawołanie. Usunięte
pliki w uniksach znikają po zamknięciu ostatniego uchwytu.

Dobrze wiem jak jest w uniksach, chodziło mi o konkretny plik /dev/*
i tak gapowaty program z nim współpółpracujący, że się nie połapie
gdy mu partner do rozmowy zemrze.

Gapowate w tym przypadku jest zachowanie funkcji write i read, które
nie zwracają kodów błędów gdy próbujemy pisać/czytać ze "znikniętego"
urządzenia.

Funkcje write i read nie są gapowate, robia dobrze to, co do nich należy.

--
Jarek

Zbych
Guest

Mon Mar 05, 2018 8:11 am   



W dniu 05.03.2018 o 01:17, Jarosław Sokołowski pisze:
Quote:
Pan Zbych napisał:

To jest normalny przypadek, potrafię go wywołać na zawołanie. Usunięte
pliki w uniksach znikają po zamknięciu ostatniego uchwytu.

Dobrze wiem jak jest w uniksach, chodziło mi o konkretny plik /dev/*
i tak gapowaty program z nim współpółpracujący, że się nie połapie
gdy mu partner do rozmowy zemrze.

Gapowate w tym przypadku jest zachowanie funkcji write i read, które
nie zwracają kodów błędów gdy próbujemy pisać/czytać ze "znikniętego"
urządzenia.

Funkcje write i read nie są gapowate, robia dobrze to, co do nich należy.

Pisanie do nieistniejących urządzeń bez sygnalizacji błędów? Chyba mamy
inną definicję poprawności.

Jarosław Sokołowski
Guest

Mon Mar 05, 2018 8:32 am   



Pan Zbych napisał:

Quote:
To jest normalny przypadek, potrafię go wywołać na zawołanie.
Usunięte pliki w uniksach znikają po zamknięciu ostatniego uchwytu.

Dobrze wiem jak jest w uniksach, chodziło mi o konkretny plik /dev/*
i tak gapowaty program z nim współpółpracujący, że się nie połapie
gdy mu partner do rozmowy zemrze.

Gapowate w tym przypadku jest zachowanie funkcji write i read, które
nie zwracają kodów błędów gdy próbujemy pisać/czytać ze "znikniętego"
urządzenia.

Funkcje write i read nie są gapowate, robia dobrze to, co do nich należy.

Pisanie do nieistniejących urządzeń bez sygnalizacji błędów? Chyba mamy
inną definicję poprawności.

Chyba. W każdym razie jest to najbardziej prawdopodobne wyjaśnienie.

--
Jarek

Zbych
Guest

Mon Mar 05, 2018 8:44 am   



W dniu 05.03.2018 o 08:32, Jarosław Sokołowski pisze:
Quote:
Pan Zbych napisał:

Gapowate w tym przypadku jest zachowanie funkcji write i read, które
nie zwracają kodów błędów gdy próbujemy pisać/czytać ze "znikniętego"
urządzenia.

Funkcje write i read nie są gapowate, robia dobrze to, co do nich należy.

Pisanie do nieistniejących urządzeń bez sygnalizacji błędów? Chyba mamy
inną definicję poprawności.

Chyba. W każdym razie jest to najbardziej prawdopodobne wyjaśnienie.

Zostawię tylko info dla potomnych, bo odpowiedzi Jarka są tradycyjnie
bezużyteczne:

Z manuala funkcji read i write:
On error, -1 is returned, and errno is set appropriately.

I tego wspomniane funkcje read/write nie robią jeśli urządzenie zniknie.

Budyń
Guest

Mon Mar 05, 2018 9:08 am   



W dniu niedziela, 4 marca 2018 23:27:57 UTC+1 użytkownik Marek napisał:
Quote:
On Sun, 4 Mar 2018 00:12:39 -0800 (PST),
Budyń wrote:
Jakies inne opcje? Albo jakas znana metoda resetu programowego? To
widzia
łbym najchętniej.

Jedynie możesz przeładować moduły uhci/ohci, ale to nie zawsze
pomaga. To jest faktycznie problematyczne, bo czegoś takiego jak
programowy reset USB faktycznie nie ma.


na razie przed rebootem dodałem próbę wykonania
modprobe -r ftdi_sio

a dopiero jak sie nie uda to reboot.

i nawet od wczoraj jedno takie sie wykonało czyli uniknąłem jednego reboota :)

dzieki wszystkim za porady


b.

Zbych
Guest

Mon Mar 05, 2018 10:32 am   



W dniu 05.03.2018 o 10:22, Adam Wysocki pisze:
Quote:
Zbych <abuse_at_onet.pl> wrote:

Z manuala funkcji read i write:
On error, -1 is returned, and errno is set appropriately.

I tego wspomniane funkcje read/write nie robią jeśli urządzenie zniknie.

Spodziewałbym się EIO. Ciekawe, czemu tak się nie dzieje (nie sprawdzałem,
bo teraz nie mam jak, ale wierzę).

Ja zazwyczaj używam IO w wersji nieblokującej (O_NONBLOCK), z ciekawości
muszę sprawdzić czy bez tej flagi też jest problem z sygnalizacją błędów.

Marek
Guest

Mon Mar 05, 2018 10:43 am   



On Mon, 5 Mar 2018 08:44:37 +0100, Zbych <abuse_at_onet.pl> wrote:
Quote:
I tego wspomniane funkcje read/write nie robią jeśli urządzenie
zniknie.

Problem nie jest w prymitywach read/write, bo one nie wiedzą, że
piszą do urządzeń to raz. Dwa to jest konsekwencja VFS, trzymania
otwartego uchwytu w kontekście VFS io. Zjawisko, które powoduje
opisywany problem jest bardziej skomplikiwany, nie jest wadą ale
kkonsekwecja użycia wartswy API gdzie mamy read//write Ominięcie
tego problemu to komunikacja zurządzeniem nie przez read/write ale
bezpośrednio z driverem urządzenia (i tracąc wszystkie inne zalety
użycia warstwy gdzie mamy read/write).

--
Marek

Adam Wysocki
Guest

Mon Mar 05, 2018 11:14 am   



Zbych <abuse_at_onet.pl> wrote:

Quote:
Plik urządzenia znika, ale nadal jest otwarty przez program. Przez to
nowy pojawia się pod inną nazwą.

Też nie zawsze się to dzieje.

Prawda. Mówię o sytuacji "domyślnej" i ftdi.

--
[ Email: a_at_b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Adam Wysocki
Guest

Mon Mar 05, 2018 11:19 am   



Zbych <abuse_at_onet.pl> wrote:

Quote:
To jest normalny przypadek, potrafię go wywołać na zawołanie. Usunięte
pliki w uniksach znikają po zamknięciu ostatniego uchwytu.

Jeśli mówisz o inode, to tak, ale dowiązanie nazwy do inode znika od razu,
gdy jest usunięte.

--
[ Email: a_at_b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Adam Wysocki
Guest

Mon Mar 05, 2018 11:22 am   



Zbych <abuse_at_onet.pl> wrote:

Quote:
Z manuala funkcji read i write:
On error, -1 is returned, and errno is set appropriately.

I tego wspomniane funkcje read/write nie robią jeśli urządzenie zniknie.

Spodziewałbym się EIO. Ciekawe, czemu tak się nie dzieje (nie sprawdzałem,
bo teraz nie mam jak, ale wierzę).

--
[ Email: a_at_b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Adam Wysocki
Guest

Wed Mar 07, 2018 11:37 am   



Zbych <abuse_at_onet.pl> wrote:

Quote:
Ja zazwyczaj używam IO w wersji nieblokującej (O_NONBLOCK), z ciekawości
muszę sprawdzić czy bez tej flagi też jest problem z sygnalizacją błędów.

W sumie nie powinno to nic zmieniać. Spodziewałbym się, że po odpięciu
urządzenia select() zwróci odczytywalność, a read() zwróci 0 (ale nie
sprawdzałem).

Tak się składa, że mam teraz na tapecie program, który gada z ttyACM
(moduł cdc_acm) blokującym I/O (naprzemiennie pisze do portu i czeka na
odpowiedź). Po odpięciu kabelka blokujący read() zwrócił 0 (EOF), a
późniejszy tcdrain (wywołujący ioctl TCSBRK) -1 (errno = EIO).

Dodatkowy test pokazał, że gdy read() zwróci EOF, to kolejny read()
również zwraca EOF, ale kolejny write() zwraca -1 z errno = EIO. Kołacze
mi się po głowie, że w przypadku socketów zachowanie read() było inne (gdy
zwrócił EOF, to kolejny read() zwracał błąd), ale głowy za to uciąć nie
dam -- może mi się coś przywidziało.

Nie wiem czy cokolwiek zmienia fakt, że urządzenie nie jest podłączone
bezpośrednio, tylko przez "przejęcie" portu w VirtualBox (ten Linux chodzi
w wirtualce na Windows 7). Niby nie powinien.

--
[ Email: a_at_b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Adam Wysocki
Guest

Wed Mar 07, 2018 11:39 am   



Mario <Mario_at_w.pl> wrote:

Quote:
Zapalarka może pomóc.

Byle nie tak Smile https://www.youtube.com/watch?v=RtlYi1yLTVQ#t=46

--
[ Email: a_at_b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Zbych
Guest

Wed Mar 07, 2018 12:17 pm   



W dniu 07.03.2018 o 10:37, Adam Wysocki pisze:
Quote:
Zbych <abuse_at_onet.pl> wrote:

Ja zazwyczaj używam IO w wersji nieblokującej (O_NONBLOCK), z ciekawości
muszę sprawdzić czy bez tej flagi też jest problem z sygnalizacją błędów.

W sumie nie powinno to nic zmieniać. Spodziewałbym się, że po odpięciu
urządzenia select() zwróci odczytywalność, a read() zwróci 0 (ale nie
sprawdzałem).

Tak się składa, że mam teraz na tapecie program, który gada z ttyACM
(moduł cdc_acm) blokującym I/O (naprzemiennie pisze do portu i czeka na
odpowiedź). Po odpięciu kabelka blokujący read() zwrócił 0 (EOF), a
późniejszy tcdrain (wywołujący ioctl TCSBRK) -1 (errno = EIO).

Dodatkowy test pokazał, że gdy read() zwróci EOF, to kolejny read()
również zwraca EOF, ale kolejny write() zwraca -1 z errno = EIO. Kołacze
mi się po głowie, że w przypadku socketów zachowanie read() było inne (gdy
zwrócił EOF, to kolejny read() zwracał błąd), ale głowy za to uciąć nie
dam -- może mi się coś przywidziało.

Nie wiem czy cokolwiek zmienia fakt, że urządzenie nie jest podłączone
bezpośrednio, tylko przez "przejęcie" portu w VirtualBox (ten Linux chodzi
w wirtualce na Windows 7). Niby nie powinien.

Zacząłem to jeszcze raz sprawdzać i na ubuntu 14 (kernel 4.4.0) mam tak:

1. write zwraca błąd i errno=5 (EIO, Input/output error) jeśli
urządzenie zniknie, niezależnie czy używam trybu blokującego czy nie.

2. read w trybie blokującym czeka na dane, jak wypnę w trakcie czekania
wtyczkę to przerywa czekanie zwracając 0, czego nie traktuję jako błąd.
Kolejne wywoływania read zwracają cały czas 0

3. read w trybie nieblokującym zwraca mi błąd i errno=11 (EAGAIN,
Resource temporarily unavailable) gdy wtyczka jest wpięta i nie ma
danych do odbioru czyli zachwuje się prawidłowo. Ale za to zwraca 0
(brak błędu) jak wtyczkę wypnę.

Testy z read powtórzyłem też na ubuntu 16 z kernelem 4.4, zachowanie
identyczne.

Problem polega na tym, że mam urządzenia z który tylko czytam dane
(skanery, klawiatury) i takie zachowanie read jest delikatnie mówiąc
irytujące.

Adam Wysocki
Guest

Thu Mar 08, 2018 1:10 am   



Zbych <abuse_at_onet.pl> wrote:

Quote:
2. read w trybie blokującym czeka na dane, jak wypnę w trakcie czekania
wtyczkę to przerywa czekanie zwracając 0, czego nie traktuję jako błąd.
Kolejne wywoływania read zwracają cały czas 0

Wartość 0 oznacza EOF ("koniec pliku", zamknięte połączenie, koniec
strumienia danych). To coś innego niż brak danych (bo wtedy jak sam
zauważasz blokujący read poczeka, a nieblokujący zwróci EAGAIN).

Quote:
Problem polega na tym, że mam urządzenia z który tylko czytam dane
(skanery, klawiatury) i takie zachowanie read jest delikatnie mówiąc
irytujące.

Hmm, jak dla mnie jest prawidłowe. Po prostu read() nie ma prawa zwrócić
0, jeżeli urządzenie jest podłączone i działa, ale nie ma danych. Wartość
0 oznacza, że kanał komunikacyjny został zamknięty i dane się skończyły
(to nie to samo, co chwilowy brak danych, które mogą przyjść później, bo
strumień jest otwarty; gdy read() zwróci 0, to dane już nie przyjdą).

--
[ Email: a_at_b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

Goto page Previous  1, 2, 3  Next

elektroda NewsGroups Forum Index - Elektronika Polska - resetowanie urządzenia USB

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map