W dniu 04.03.2018 o 14:25, Jarosław Sokołowski pisze:
> Pan Zbych napisał:
>
>> Gdy urządzenie na nowo się pojawia a stare połączenie nie zostało
>> zamknięte to zostanie użyta nowa nazwa (np. zamiast ttyUSB0 będzie
>> ttyUSB1).
>
> To jednak rzadki (niespotykany?) przypadek, by tty faktycznie zniknął,
> a plik z diwajsem pozostał. Ale w ogólności uwaga słuszna -- warto tak
> to opisać w udev, by diwajs dostawał zawsze alias /dev/OneWire czy cóś.

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

do góry

W dniu 04.03.2018 o 15:27, Adam Wysocki pisze:
> Jarosław Sokołowski <j...@l...waw.pl> wrote:
>
>> To jednak rzadki (niespotykany?) przypadek, by tty faktycznie zniknął,
>> a plik z diwajsem pozostał. Ale w ogólności uwaga słuszna -- warto tak
>> to opisać w udev, by diwajs dostawał zawsze alias /dev/OneWire czy cóś.
>
> Plik urządzenia znika, ale nadal jest otwarty przez program. Przez to nowy
> pojawia się pod inną nazwą.

Też nie zawsze się to dzieje. Wyjątkiem są np. drukarki i urządzenie do
których napisaliśmy regułki udev wymuszające inne zachowanie. W takim
przypadku po wypięciu urządzenia również trzeba zamknąć plik i ponownie
go otworzyć, bo na uchwycie do "starego" pliku już nie nawiążemy
komunikacji.

do góry

Pan Zbych napisał:

>>> Gdy urządzenie na nowo się pojawia a stare połączenie nie zostało
>>> zamknięte to zostanie użyta nowa nazwa (np. zamiast ttyUSB0 będzie
>>> ttyUSB1).
>>
>> To jednak rzadki (niespotykany?) przypadek, by tty faktycznie zniknął,
>> a plik z diwajsem pozostał. Ale w ogólności uwaga słuszna -- warto tak
>> to opisać w udev, by diwajs dostawał zawsze alias /dev/OneWire czy cóś.
>
> 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.

--
Jarek

do góry

W dniu 04.03.2018 o 21:14, Jarosław Sokołowski pisze:
> Pan Zbych napisał:
>
>>>> Gdy urządzenie na nowo się pojawia a stare połączenie nie zostało
>>>> zamknięte to zostanie użyta nowa nazwa (np. zamiast ttyUSB0 będzie
>>>> ttyUSB1).
>>>
>>> To jednak rzadki (niespotykany?) przypadek, by tty faktycznie zniknął,
>>> a plik z diwajsem pozostał. Ale w ogólności uwaga słuszna -- warto tak
>>> to opisać w udev, by diwajs dostawał zawsze alias /dev/OneWire czy cóś.
>>
>> 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.

do góry

W dniu 04.03.2018 o 10:17, Jarosław Sokołowski pisze:
> Budyń nie dowiedział sie u linuxiarzy jak w raspberrypi programowo
> wywołać reset urządzenia usb, używa tego do pomiaru temperatury:
>
>> http://www.meraprojekt.com.pl/mp00202.html i zdarza się ze coś
>> się zwiesi i nie czyta. Fizyczne wyciągnięcie z gniazda i powtórne
>> włożenie pomaga. Obszedłem problem wywołując reboot całego systemu :/
>> Mam tam wolny przekaźnik - puściłbym zasilanie tamtędy, czy możnaby
>> zasilanie +5V wyłączać na chwilę aby urządzenie się zresetowało?
>>
>> Jakies inne opcje? Albo jakas znana metoda resetu programowego?
>> To widziałbym najchętniej.
>
> Jeśli faktycznie *zawiesi się urządzenie USB*, to już trudno z nim
> się dogadać przez USB (bo przez co innego?) -- pozostaje tylko
> odcięcie zasilania. I tak czasem się robi, gdy nie ma innego wyjścia.
> Przekaźnik to spory overkill, tu prąd nie przekracza 100 mA, lepszy
> byłby jakis półprzewodnik. Można nawet zwierać na moment do masy
> linię zasilającą port USB.
>
> W tym przypadku najpewniej mamy do czynienia z wyżej opisaną sytuacją,
> ale nic nie szkodzi, by zbadać sprawę dokładniej i spróbowac innych
> sztuczek. Datasheet podaje, że toto komunikuje się z systamem przez
> port rs232 wytworzony z USB przez chip FT232RL. Czy w momencie zwiechy
> ten port znika? Najpewniej jest to plik /dev/ttyUSB0, o ile udev
> inaczej nie postanowił. Można spróbowac usunąć i załadować ponownie
> moduł kernela, licząc na to, że diwajs się przy tym jakoś ogarnie
> ("modprobe -r usbserial" i "modprobe usbserial").
>
> Z obsługa awarii ogólnie jest ciężka sprawa, bo trudno sytuację
> wywołać na żądanie by popatrzeć co się dzieje.

Zapalarka może pomóc.


--
pozdrawiam
MD

do góry

On Sun, 4 Mar 2018 00:12:39 -0800 (PST),
Budyń<b...@g...com> 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.

--
Marek

do góry

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.

--
Jarek

do góry

W dniu niedziela, 4 marca 2018 23:27:57 UTC+1 użytkownik Marek napisał:
> 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.

do góry

W dniu 05.03.2018 o 01:17, Jarosław Sokołowski pisze:
> 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.

do góry

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.

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

--
Jarek

do góry