LINUX.ORG.RU
решено Форум — Linux-hardware  

Меняется порядок плат видеозахвата PCIe

 ,


0

2

Добрый день. Вот такой вопрос. Может быть кто сталкивался с таким багом, как изменчивость нумераций устройств с перезагрузкой компа? (надеюсь, правильно сформулировал)) Например. Есть 2 платы захвата. Одноканальная и четырех канальная. Естественно, в девайсах они как video0 video1 video2 video3 video4. video0 - одноканальная, остальные видео - четырехканальная. С какой-то перезагрузкой вдруг одноканальная становится video4. Ну а одноканальная video0 и тд. В Windows я такого ни разу не наблюдал. Кто знает, как это пофиксить? Заранее благодарен.

← sata и sas диски в одной корзине в рейдах
Как и чем мерить лошадиные силы CPU? →
  1 2 3
Ответ на: комментарий от alexsher

Без правки драйверов это не исправить. А драйвера (я посмотрел) спецом этот индекс обнуляют. И этот код обнуления написан криво, инородно, писал явно другой человек (пытался спрятать баги в железе).

anonymous
()
Ответ на: комментарий от anatole

Открывай через /dev/v4l/by-path/

самое разумное предложение во всём треде! Вместо написания правил udev, которые тут полтреда зачем-то обсуждают - прописать в конфиге/команде программы устройство захвата с указание шины или идентификатора

/dev/v4l/by-path/pci-0000:00:14.0-usbv2-0:7:1.0-video-index0

или через соседнюю папку by-id

/dev/v4l/by-id/usb-046d_081b_02B11990-video-index0
GPFault ★★★
()
Ответ на: комментарий от firkax

Нет, сломали. Что за убогая логика вообще? Внедрение новых фич - не оправдание к поломке чего-то ещё. Кто так делает - просто убогие и бесстыдные криворуки, которые выдумали нелепый аргумент в якобы защиту дефектной работы своего поделия, вместо того чтобы этот дефект исправлять.

Извини, но это у тебя логика уровня - я приехал из деревни в город, а во дворе нет сортира, очень неудобно

Смотри, имена устройств НИКОГДА не были persistent. Другое дело, что они менялись РЕДКО и обычно после добавления другого оборудования или переключения в другой порт/слот/гнездо

Домашний пользователь думал - о, я перезагрузился, имя не поменялось, клево, оно наверное persistent, зачем мне чем-то думать. Потом он вставляет новый диск (и оказывается, что предыдущий был подключен не в sata0, а в sata2). или добавяляет новую pci карту. или хомячок перегрыз usb кабель и новый воткнули в другой порт. И такой - АААА, ВСЕ СЛОМАЛОСЬ!!!

Рассчитывать на не-persistent имена - очень плохая практика, за такое надо бить по рукам. То, что теперь имена меняются каждый ребут, иногда неудобно (например, когда в выводе lsscsi они не по порядку). Зато это ЗАСТВЛЯЕТ не пользоваться плохими практиками и поощряет думать головой

Так что это не сломали, а скорее починили ;)

Примерно в ту же сторону - очень хотелось бы, чтобы utf8 заменили на ucs. В котором даже с английской локалью косяки разработчиков с юникодом будут видны всем

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

Что значит не были persistent? Они были детерминированными по факту, если железо не менялось - имена тоже не менялись. А кто там чего обещал или не обещал в этом контексте не важно.

Потом он вставляет новый диск (

Ещё раз - речь про стабильную конфигурацию в которой ничего не меняют. То, что имена меняются при изменении железа никого никогда не удивляло.

И ладно бы всё описанное было в какой-то новой ОС, решили так сделать и решили. Но этот появилось там, где все уже привыкли к детерминированным именам.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Что значит не были persistent? Они были детерминированными по факту, если железо не менялось - имена тоже не менялись. А кто там чего обещал или не обещал в этом контексте не важно.

Это значит - не persistent

«если железо не менялось». А если менялось? Упс…

Важно не кто чего обещал, а кто что сделал. Настроил методом тыка? Не надо так

Ещё раз - речь про стабильную конфигурацию в которой ничего не меняют

Ещё раз, речь про persistent имена. Ты когда-нибудь работал с fc массивами?

И ладно бы всё описанное было в какой-то новой ОС, решили так сделать и решили. Но этот появилось там, где все уже привыкли к детерминированным именам.

Это появилось там, где многие привыкли делать через опу. Теперь они не могут как раньше делать через опу и сильно расстраиваются

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

Ещё раз, речь про persistent имена

Речь про детерминированные имена.

«если железо не менялось». А если менялось? Упс…

Какое ещё упс? Речь исключительно про систему в которой железо не меняют. То что при изменении железа что-то меняется - не проблема. Проблема, когда оно меняется само собой в рандомном порядке.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Ты привык использовать ненадёжный механизм. Ломался он редко. Но надежным не был.

Это плохая практика. Теперь ненадёжный механизм ломается часто, приходится включить голову и использовать надежный. Тебе доходчиво показали, что он ненадёжный. Но ты не понимаешь, что делал неправильно, ведь джва года ни единого разрыва

router ★★★★★
()
Ответ на: комментарий от GPFault

В том и проблема, что у него video-index1 съезжает, т.е. путь будет ломаться. Тут скрипт нужен, который будет искать одноканальное устройство и делать ссылки на оставшиеся многоканальные выходы.

steemandlinux ★★★★★
()
Ответ на: комментарий от router

Ты так и не объяснил чего в нём ненадёжного. Смена железа без правки конфигов - это не «ненадёжность», а нарушение правил пользования. То что конфиги надо править при смене железа, я согласен назвать неудобством. Но где ты нашёл ненадёжность, объяснишь?

firkax ★★★★★
()
Ответ на: комментарий от firkax

Ты так и не объяснил чего в нём ненадёжного.

То, что это не persistent имя. Оно может меняться и оно будет меняться

Домашний пользователь может этого долго не замечать

router ★★★★★
()
Ответ на: комментарий от firkax

Конкретный пример тебе сложно понять именно потому, что ты домашний пользователь

В работе изменение железа - особенно виртуального - не должно быть форс-мажором, из за которого что-то не запустится. Это должно быть штатной предсказуемой ситуацией

Сервер, сюрприз, должен работать дальше даже без firkax’а, который может уволиться или попасть под машину. За использование не persistent имен бьют по рукам

В своем домашнем компе - или даже домашней лабе - ты можешь этого не замечать. Но ты делаешь это неправильно

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

Переключить usb кабель в другой порт - это нормально. Это не должно приводить к необходимости переконфигурации уже настроенного оборудования

Добавление нового диска - это нормально. Это не должно приводить к необходимости переконфигурации уже настроенного оборудования

Добавление новой pci-e карты - это нормально. Это не должно приводить к необходимости переконфигурирования уже настроенного оборудования

router ★★★★★
()
Ответ на: комментарий от router

Конкретный пример тебе сложно понять именно потому, что ты домашний пользователь

Конкретный пример невозможно понять, потому что ты его не привёл! Хватит демагогией заниматься.

Поскольку ты то ли забываешь предыдущие сообщения, то ли делаешь вид что забываешь, приведу ещё раз тут заявление целиком, а то начнётся опять по кругу выдёргивание словосочетаний из контекста и фейковые возражения.

До некоторых версий в ядре линукс были детерминированные имена устройств, после - перестали быть такими. Детерминированные имена устройств означают вот что: имея некоторую конфигурацию железа, и не внося в неё модификаций (подключение/отключение устройств, перетыкание в другие слоты), ты при каждом её запуске будешь предсказуемо получать одни и те же имена для устройств. Эта возможность может использоваться: 1) в системах, где не предусмотрено или не планируется изменение конфигурации (кроме замены вышедшей из строя детали на полностью аналогичную в том же слоте), 2) в системах, где изменения конфигурации производятся только под присмотром системного администратора (возможно, имеющего соответствующую компетенцию юзера-владельца компа), исправляя должным образом конфиги. Использование этой возможности в других случаях является нарушением условий пользования системой и рассматриваться не должно. Кроме того, пользоваться этой возможностью никто не заставляет, другие варианты не отменены.

Твоё заявление заключается в том, что использование детерминированных имён в том виде, как они были в старых ядрах линукса, безусловно ненадёжно. Я в ответ прошу привести пример, когда из-за этого использования, при соблюдении условий пользования (абзац выше), произойдёт поломка.

Конкретный ответ именно на этот вопрос (а не отвлечённые рассуждения в стиле «ты неправильный») будет или нет?

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

Конкретный пример - ты слегка туповат. firkax’а уже раз десять тнули мордой в твою ошибку. firkax: «а де море?!»

  • конкретный пример: добавили новый диск
  • конкретный пример: добавили новую pci-e карту
  • конкретный пример: переключение кабеля в другой порт/гнездо/разъём

F.A.Q:

  1. Q: я делал через опу. А оно больше на работает

    A: не надо делать через опу. Делайте правильно

  2. Q: но я всю жизнь делал через опу!

    A: не надо делать через опу. Делайте правильно

  3. Q: но меня устраивало делать через опу

    A: не надо делать через опу. Делайте правильно

  4. Q: но мой сосед тоже делал через опу. и у него тоже сломалось. почините!

    A: вы оба делали неправильно. не надо делать через опу. Делайте правильно

  5. Q: но я не менял железо!

    A: а ОСь пушкин обновил?

router ★★★★★
()
Ответ на: комментарий от firkax

То, что ты называешь «правильное использование», это «повезло»

То, что ты пытаешь выдать за «неправильное использование», это нормальные ситуации

Ты так и не показал, где они

«папа, а де море?!»

отом он вставляет новый диск (и оказывается, что предыдущий был подключен не в sata0, а в sata2). или добавяляет новую pci карту. или хомячок перегрыз usb кабель и новый воткнули в другой порт. И такой - АААА, ВСЕ СЛОМАЛОСЬ!!!

«если железо не менялось». А если менялось? Упс…

В работе изменение железа - особенно виртуального - не должно быть форс-мажором, из за которого что-то не запустится. Это должно быть штатной предсказуемой ситуацией

Сервер, сюрприз, должен работать дальше даже без firkax’а, который может уволиться или попасть под машину. За использование не persistent имен бьют по рукам

  • конкретный пример: добавили новый диск
  • конкретный пример: добавили новую pci-e карту
  • конкретный пример: переключение кабеля в другой порт/гнездо/разъём
router ★★★★★
()
Ответ на: комментарий от firkax

Речь исключительно про систему в которой железо не меняют.

Этот топик как раз про это. У него 4-канальный видеозахватчик не раздает «детерминированные» индексы каналам (драйвер такой). И эти каналы получат ядерные имена в случайном порядке, хоть до, хоть после твоей «поломки».

anonymous
()
Ответ на: комментарий от firkax

Баг в чем: в том, что железо может не иметь уникального - «детерминированного» - номера из всемирного реестра уникальных номеров из-за чего сломается «детерминированная» раздача ядерных имён?

anonymous
()
Ответ на: комментарий от anonymous

А уникальные имена никак на традиционные имена устройств не влияют. Это с некоторых под для сетевух имя из мак-адреса можно генерировать, хотя я не уверен что это ядерное, возможно там всё тот же udev это делает.

firkax ★★★★★
()
Ответ на: комментарий от anonymous

Во-первых, кольцо тут ни при чём, достаточно просто параллельно в одну шину включить несколько устройств чтобы формально заявить что из них сложно найти первое. Только вот так давно не делают. Такое было во времена ISA на 16-битных компах - все слоты равноправны и электрически подключены к одним и тем же линиям, выяснить какая из двух isa-сетевух первая и правда было затруднительно, но те времена давно прошли. Сейчас все слоты всегда пронумерованы, и внутри чипов, если у них несколько функций, тоже всё пронумеровано. Ненумерованные связи остались в межкомпьютерных сетях (ethernet) - неуправляемые свитчи не отличают свои порты друг от друга, а в беспроводном случае тем более нет стабильных номеров.

firkax ★★★★★
()
Ответ на: комментарий от alexsher

Попробуй наложить патчик на http://www.mv360.net/SDK/driver/HWS/Linux/hws_20241018.zip

diff --git a/src/hws_video.c b/src/hws_video.c
index 86d7973..b0db99b 100644
--- a/src/hws_video.c
+++ b/src/hws_video.c
@@ -3235,6 +3235,7 @@ int hws_video_register(struct hws_pcie_dev *dev)
                vdev->lock = &(dev->video[i].video_lock);
                vdev->fops = &hws_fops;
                strcpy(vdev->name,KBUILD_MODNAME);
+               vdev->index = i;
                vdev->release = video_device_release_empty;
                vdev->vfl_dir = VFL_DIR_RX;
                vdev->ioctl_ops = &hws_ioctl_fops;

Каналы 4-канального адаптера станут иметь разные значения index (в /sys/class/video4linux/video*/index), и udev правила создадут правильные персистентные ссылки типа /dev/v4l/by-id/pci-XXX-video-indexN или /dev/v4l/by-path/pci-XXX-video-indexN.

iliyap ★★★★★
()

Интересно, а как быть в случае одинаковых устройств? У меня например есть несколько USB-to-Serial адаптеров, полностью одинаковых с т.з. системы. Хотел привязать их к номеру USB-порта, но вот какая штука, при перезагрузке они меняются…

Есть ли способ зафиксировать их малой кровью, не перекапывая тонны правил udev?

yaba ★★★
()
Ответ на: комментарий от iliyap

Приветствую! Спасибо. Я не стал делать это скриптом, попросту открыл исходник редактором и вставил эту строку (vdev->index = i;). И установил драйвер заново. Ничего не изменилось. Тут /sys/class/video4linux/video*/index индексы все 0.

alexsher
() автор топика
Ответ на: комментарий от yaba

Номера портов на USB-хабах, номера USB-конфигураций и номера USB-интерфейсов не меняются при перезагрузке. Используй /dev/serial/by-path. Например,

$ ls -ld /sys/class/tty/ttyUSB0
lrwxrwxrwx. 1 root root 0 Feb  6 15:25 /sys/class/tty/ttyUSB0 -> ../../devices/pci0000:00/0000:00:14.0/usb3/3-5/3-5:1.0/ttyUSB0/tty/ttyUSB0
$ ls -l /dev/serial/by-path/
total 0
lrwxrwxrwx. 1 root root 13 Feb  6 15:22 pci-0000:00:14.0-usb-0:5:1.0-port0 -> ../../ttyUSB0
  • 0000:00:14.0 – PCI адрес USB контроллера, не меняется при перезагрузке
  • :5 – номер порта на корневом хабе, не меняется при перезагрузке
  • :1.0 – номер конфигурации (bConfigurationValue) и номер интерфейса (bInterfaceNumber), не меняются при перезагрузке
  • port0 – номер порта на многопортовых usb-serial конвертерах, не меняется при перезагрузке.

При перезагрузке может поменяться только номер USB-шины (usb3 в данном примере). Но он как раз в персистентном имени не участвует.

iliyap ★★★★★
()
Ответ на: комментарий от yaba

Есть ли способ зафиксировать их малой кровью, не перекапывая тонны правил udev?

Если у них есть серийные номера, можно их юзать, если нет - то наверное только к USB портам привязываться

Правила udev тут будут довольно простые

Например, у меня 2 USB порта на передней панели десктопа

USB-to-Serial в левом:

❯ udevadm info --query=all --name=/dev/ttyUSB0 |grep DEVPATH
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-6/1-6:1.0/ttyUSB0/tty/ttyUSB0

❯ ll /dev/ttyUS*
crw-rw----@ 188,0 root  6 Feb 15:10  /dev/ttyUSB0
lrwxrwxrwx@     7 root  6 Feb 15:10  /dev/ttyUSBFrontLeft -> ttyUSB0

USB-to-Serial в правом:

❯ udevadm info --query=all --name=/dev/ttyUSB0 |grep DEVPATH
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.0/ttyUSB0/tty/ttyUSB0

❯ ll /dev/ttyUS*
crw-rw----@ 188,0 root  6 Feb 15:07  /dev/ttyUSB0
lrwxrwxrwx@     7 root  6 Feb 15:07  /dev/ttyUSBFrontRigth -> ttyUSB0

Правила:

❯ cat /etc/udev/rules.d/92-usb-serial.rules
ACTION=="add", KERNEL=="ttyUSB?", SUBSYSTEMS=="usb-serial", DEVPATH=="*/1-6/*", SYMLINK+="ttyUSBFrontLeft"
ACTION=="add", KERNEL=="ttyUSB?", SUBSYSTEMS=="usb-serial", DEVPATH=="*/1-5/*", SYMLINK+="ttyUSBFrontRigth"
alx777 ★★
()
Ответ на: комментарий от firkax

Какое ещё упс? Речь исключительно про систему в которой железо не меняют. То что при изменении железа что-то меняется - не проблема. Проблема, когда оно меняется само собой в рандомном порядке.

В свое время получил значительное количесво проблем с enumeration периферии на одном и том же железе из-за изменения таймингов инициализации ядра по поводу апгрейда 3.x -> 4.x, вкомпиливания модулей в ядро (CONFIG_ m->y) и выкомпиливания их оттуда

Удалось решить только с помощью udev

alx777 ★★
()
  1 2 3
← sata и sas диски в одной корзине в рейдах
Linux-hardware
Как и чем мерить лошадиные силы CPU? →