What does "Unknown error 517" mean in Android shell?

Question

I'm trying to write to a character device in Android shell. But mksh responds with "Unknown error 517" for a whole range of operations. I've tried to use strace to track down the issue, but its not helpful. This also occurs for a whole range of device nodes in AOS 4.4, but not in 4.2.

This is what I do:

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

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

The device is there and I can both create it (mknod) and remove it, so it's not a permission problem as far as I can see.

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

All I get in strace is:

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

Looking at the mksh sources in the shf.c file doesn't offer any insight either.

I also found the EPROBE_DEFER tag in the Linux Kernel sources, in the file: ../include/linux/errno.h:

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

Any ideas what could cause this problem?

Answer 1

This is simply because bionic’s error definitions do not know about errno #517 (yet). mksh just uses what the operating system(’s C library) — in this case, Android’s bionic — provides.

This part of shf.c generates the Unknown error: %d message when the underlying operating system(’s C library) doesn’t know about the error the underlying operating system(’s kernel) generates, which is here the case.

Answer 2

As you've discovered, 517 is the value of the linux error EPROBE_DEFER, and it just means that a device driver is telling the linux kernel to try probing a particular device later. The Linux kernel calls a driver's probe() method when it wants the driver to prepare a device for usage.

Unfortunately, EPROBE_DEFER does not tell you why the probe needs to be retried, nor what you might need to do to ensure that it will succeed if you did retry. Here is a thread complaining about that.