Что означает "Неизвестная ошибка 517" в оболочке Android?

Я пытаюсь написать символьное устройство в оболочке Android. Но mksh отвечает "Неизвестная ошибка 517" для всего диапазона операций. Я пытался использовать strace, чтобы отследить проблему, но это не помогло. Это также происходит для целого ряда узлов устройств в AOS 4.4, но не в 4.2.

Вот что я делаю:

# chmod 666 /dev/smd0
Unable to open /dev/smd0: Unknown error 517

# cat /dev/smd0
tmp-mksh: cat: /dev/smd0: Unknown error 517

Устройство есть, и я могу как создать его (mknod), так и удалить, так что, насколько я вижу, это не проблема с разрешениями.

# ls /dev/smd0
crw-rw----    1 1000     1000      222,   0 Feb 13  2014 /dev/smd0

Все, что я получаю в strace, это:

ioctl(10</dev/tty>, SNDCTL_TMR_STOP or TCSETSW, {c_iflags=0x500, c_oflags=0x5, c_cflags=0xbf, c_lflags=0x8a3b, c_line=0, c_cc="\x03\x1c\x7f\x15\x04\x00\x01\x00\x11\x13\x1a\x00\x12\x0f\x17\x16\x00\x00\x00"}) = 0
ioctl(10</dev/tty>, TIOCSPGRP, [23069]) = 0
[pid 23069] open("/dev/smd0", O_RDONLY|O_LARGEFILE) = -1 EPROBE_DEFER (Unknown error 517)
[pid 23069] open("/dev/smd0", O_WRONLY|O_LARGEFILE) = -1 EPROBE_DEFER (Unknown error 517)
[pid 23069] write(2</dev/pts/5>, "Unable to open /dev/smd0: Unknown error 517\n", 44) = 44

Просмотр источников mksh в файле shf.c также не дает никакой информации.

Я также нашел EPROBE_DEFER тег в исходных кодах ядра Linux, в файле: http://lxr.free-electrons.com/source/include/linux/errno.h:

#define EPROBE_DEFER    517     /* Driver requests probe retry */

Есть идеи, что может вызвать эту проблему?

2 ответа

Решение

Это просто потому, что определения ошибок bionic не знают об ошибке #517 (пока). mksh просто использует то, что обеспечивает операционная система (библиотека C) - в данном случае, бионическая Android.

Эта часть shf.c генерирует Unknown error: %d сообщение, когда базовая операционная система (библиотека C) не знает об ошибке, которую генерирует базовая операционная система (ядро), как в данном случае.

Как вы обнаружили, 517 это значение ошибки Linux EPROBE_DEFER, и это просто означает, что драйвер устройства сообщает ядру linux, чтобы он позже попытался исследовать конкретное устройство. Ядро Linux вызывает драйвер probe() метод, когда он хочет, чтобы драйвер подготовил устройство к использованию.

К несчастью, EPROBE_DEFER не говорит вам, почему зонд должен быть повторен, и что вы, возможно, должны сделать, чтобы убедиться, что он будет успешным, если вы повторили попытку. Вот ветка с жалобами на это.

Другие вопросы по тегам