rts5139/rtsx_usb borked в 3,15 +

[112406] Самым простым решением, вероятно, было бы более частое выполнение задания cronjob и использование оберточного скрипта для выхода без каких-либо действий, если прошло недостаточно времени.


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

Итак, для "каждые 30 часов 30 минут" это будет "каждые 30 минут", а для "каждые 30 часов" это будет "каждые 6 часов" (самый большой общий коэффициент 30 и 24)

  1. Вы можете реализовать обертку одним из двух способов:
  2. Сначала вы можете сохранить временную метку в файле, а затем проверить, не превышает ли разница во времени между сейчас и сохраненной временной меткой 30 часов и 30 минут или она равна ей.
  3. Это кажется достаточно простым, но имеет две потенциальные ловушки, которые усложняют код:
  4. Небезопасный разбор сохраненного файла временных меток
  5. Позволяет немного перемотать назад [113058]и [113059] при сравнении временных меток, так как другие вещи, происходящие в системе, приведут к тому, что интервал [113060]фактический [113061] будет перемотан.
  6. Второй вариант - вообще не хранить файл временных меток и, вместо этого, провести некоторые математические расчеты. Это также теоретически быстрее, так как ядро может вернуть системное время, не опрашивая жесткий диск.
  7. Я не тестировал это на опечатки, но вот код на Python, который был расширен для наглядности.
  8. Идея такова:

Так же, как "остановленные часы работают два раза в день", так и значение [113062]minutes_since_epoch % full_interval[113063] будет только меньше, чем [113064]cron_interval[113065] один раз за [113066]full_interval[113067].

Нужно нечеткое совпадение, чтобы учесть вариации, вызванные совместным использованием ресурсов с другими процессами.

Проще всего это сделать, используя [113068][0, cron_interval)[113069] в качестве окна, внутри которого задача должна попасть, чтобы быть выполнена.

Для учета джиттера в обоих направлениях, мы сдвигаем начальный край окна назад на 10% его длительности, так как запуск слишком рано будет редким, а запуск слишком поздно может произойти в любой момент, когда система настолько погружена в работу, что оберточный скрипт задерживается при вызове [113070] времени. time()[113071].

Если, как я подозреваю, [112862]get_top.py[112863] - ваше собственное творение, просто прикрепите это сверху и измените проверку на

2
15.09.2014, 09:10
2 ответа

Просто идея: разделы на картах памяти теперь встречаются под такими именами, как /dev/mmcblk0p1. Может быть, вы ждали появления /dev/sdb1? Убедитесь, что загружен rtsx_usb и попробуйте смонтировать /dev/mmcblk0p1 (или аналогичное название).

Если это не является решением для вас, вы можете захотеть modprobe rtsx_usb и поместить соответствующий выход dmesg? В моем случае это

usbcore: registered new interface driver rtsx_usb
mmc0: new SDHC card at address e624
mmcblk0: mmc0:e624 SD04G 3.69 GiB 
mmcblk0: p1

Конечно, Вы должны убедиться, что связанные с rtsx_usb_-модули еще не загружены, когда Вы modprobe.

Как дополнительная информация:

lsmod | grep rts

rtsx_usb_ms            16899  0 
memstick               13696  1 rtsx_usb_ms
rtsx_usb_sdmmc         25280  0 
rtsx_usb               17541  2 rtsx_usb_sdmmc,rtsx_usb_ms
mmc_core              102374  2 mmc_block,rtsx_usb_sdmmc
mfd_core               12601  2 lpc_ich,rtsx_usb
usbcore               195340  7 usblp,uvcvideo,rtsx_usb,ehci_hcd,ehci_pci,usbhid,xhci_hcd
0
27.01.2020, 22:58

Как указано в ответе на RTS5129 Card Reader с Ubuntu 15.10 , asymingt написал временное исправление.

Прямая ссылка на репозиторий github:https://github.com/asymingt/rts5139

0
27.01.2020, 22:58

Теги

Похожие вопросы