Hi folks!
On Wed, May 17, 2017 at 03:05:41PM +0100, Neil Williams wrote:
On Thu, 27 Apr 2017 08:19:19 +0100 Neil Williams codehelp@debian.org wrote:
CC:'ing Andy to see if there is extra config required to get this to work.
Andy: can you look at https://staging.validation.linaro.org/scheduler/job/174524 and see why the code does not start reading from the probe?
dmesg -T and lsusb -v output is included in the log, from inside the LXC.
I've just run a local test with an AEP inside lxc on my local machine. As far as I can see, there's nothing particularly magic going on here. The only problem I see is Lisa's config file pointing at the wrong device file. arm-probe needs a ttyACM-style device to talk to. Using:
# lxc-device -n lxc-aep-test-174524 add /dev/ttyACM0
I create that device in my container. I build libwebsockets and the arm-probe software in the container, then specify /dev/ttyACM0 in the AEP config file. I can run it just fine:
root@lxc-aep-test-174524:/arm-probe# ./arm-probe/arm-probe -C panda-aep.cfg -l10 -x # configuration: panda-aep.cfg # config_name: pandaboard # trigger: 0.400000V (hyst 0.200000V) 0.000000W (hyst 0.200000W) 400us Configuration: pandaboard # date: Fri, 19 May 2017 16:29:50 +0100 # host: lxc-aep-test-174524 # + /dev/ttyACM0 Starting... sending start to 0 # VDD_ALL VDD ROOT #ff0000 SoC # # time VDD(V) VDD(A) VDD(W) 0.000500 5.11 0.0474 0.24196 0.000600 5.11 0.0364 0.18572 0.000700 5.11 0.0314 0.16012 0.000800 5.10 0.0544 0.27734 0.000900 5.10 0.0234 0.11923 0.001000 5.11 0.0304 0.15505 ...
I don't have any problems running things and getting output here.
I *have* seen two real bugs here while trying to get things running, though:
1. If the device specified in the config file doesn't exist, or is the wrong type of device, or (maybe) there is any other kind of problem with it, you get *no* useful feedback to say there's a problem. Running things under strace will show the background libarmep process attempt to use the device specified, but there's no error handling. :-(
2. The "-x" option says that the arm-probe program is meant to exit when you've done capturing, but it just sits there forever when I'm testing. I've wrapped it using the "timeout" command to work around that for now.
If I knew where to file those bugs, I would, but it's really not obvious. They're really easy to reproduce, I hope...
In terms of the /dev/ttyACM0 creation, the lxc-device man page says that it creates devices based on their existing entries on the host. Double-check that the host (dispatcher) has an appropriate /dev/ttyACM0 if you're still seeing problems?
Cheers,