0

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?

not2qubit
  • 14,531
  • 8
  • 95
  • 135

2 Answers2

3

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.

cybersam
  • 63,203
  • 6
  • 53
  • 76
  • Yes, this seem a very lame error to have. This error seem to occur mostly when dealing with GPIO's and where a device driver is not reaching the GPIO (or USB) for some reason. In this case, on a Qualcomm based Samsung Device, */dev/smdN* should be mapped to a *shared memory driver* from [smd.c](https://android.googlesource.com/kernel/msm/+/android-msm-flo-3.4-kitkat-mr2/arch/arm/mach-msm/smd.c). – not2qubit Dec 05 '15 at 10:41
  • I want to add another thought on this issue. Further research seem to indicate that this device configuration are not using a *shared memory driver* for communicating with baseband. So perhaps the driver simply doesn't exist in the Kernel and thus failing in a similar manner as for GPIOs (as mentioned above). There are several major/minor devices in the tree, but only ttyHS/ttyHSL/ttyUSB are listed under */proc/tty/driver/* which seem to mean everything else is not accessible as an ordinary "tty". – not2qubit Apr 21 '16 at 21:43
2

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.

mirabilos
  • 5,123
  • 2
  • 46
  • 72
  • That is a confusing answer. You say that `mksh` is just using bionic, but yet, the bionic sources you pointed to, say nothing about the error that actually appears. So where are those strings coming from? – not2qubit Feb 01 '17 at 12:53