Well I was hoping not to clutter the thread with debugging,
but sometimes it happens.
On Sun, Jul 31, 2016, at 05:54 PM, John Kasunich wrote:
> Trying it resulted in an insmod failure, and what seems
> to be two more errors during the cleanup process:
I started halcmd in a terminal window instead of using
a .hal file. That lets me correlate the error messages
and log-file entries with the action(s) that cause them.
starting halcmd puts this routine stuff in the log:
Jul 31 20:10:52 beaglebone msgd:0: startup pid=31143 flavor=xenomai
rtlevel=1 usrlevel=1 halsize=524288 shm=Posix gcc=4.9.2 version=unknown
Jul 31 20:10:52 beaglebone msgd:0: ØMQ=4.0.5 czmq=2.2.0 protobuf=2.4.1
libwebsockets=<no version symbol>
Jul 31 20:10:52 beaglebone msgd:0: configured: sha=5257e28
Jul 31 20:10:52 beaglebone msgd:0: built: Jan 12 2016 15:11:16
sha=5257e28
Jul 31 20:10:52 beaglebone msgd:0: register_stuff: actual hostname as
announced by avahi='beaglebone.local'
Jul 31 20:10:52 beaglebone msgd:0: zeroconf: registering: 'Log service on
beaglebone.local pid 31143'
Jul 31 20:10:53 beaglebone msgd:0: rtapi_app:31148:user accepting commands
at ipc:///tmp/0.rtapi.a42c8c6b-4025-4f83-ba28-dad21114744a
Jul 31 20:10:53 beaglebone msgd:0: zeroconf: registered 'Log service on
beaglebone.local pid 31143' _machinekit._tcp 0 TXT
"uuid=a42c8c6b-4025-4f83-ba28-dad21114744a"
"instance=68e0f46a-577c-11e6-a405-68c90bdea250" "service=log"
"dsn=ipc:///tmp/0.log.a42c8c6b-4025-4f83-ba28-dad21114744a"
attempting to load the hal_bb_gpio driver gives:
halcmd: loadrt hal_bb_gpio output_pins=807
<stdin>:1: insmod failed, returned -1:
rtapi_rpc(): reply timeout
See /var/log/linuxcnc.log for more information.
and in the log file, this:
Jul 31 20:11:18 beaglebone msgd:0: hal_lib:31148:rt memmapped gpio port 2
to 0xb66d8000, oe: 0xb66d8134, set: 0xb66d8194, clr: 0xb66d8190
Jul 31 20:11:18 beaglebone msgd:0: rtapi_app:31148:user signal 7 - 'Bus
error' received, dumping core (current dir=/home/machinekit/grinder)
Jul 31 20:11:18 beaglebone msgd:0: rtapi_app:31148:user --- rtapi_app
backtrace: ---
Jul 31 20:11:18 beaglebone msgd:0: rtapi_app:31148:user ERROR decoding
backtrace: no debug info in ELF executable (-1)
Jul 31 20:11:18 beaglebone msgd:0: rtapi_app:31148:user ERROR decoding
backtrace: no debug info in ELF executable (-1)
Jul 31 20:11:18 beaglebone msgd:0: rtapi_app:31148:user ERROR decoding
backtrace: no debug info in ELF executable (-1)
Jul 31 20:11:18 beaglebone msgd:0: rtapi_app:31148:user ERROR decoding
backtrace: no debug info in ELF executable (-1)
Jul 31 20:11:18 beaglebone msgd:0: rtapi_app:31148:user
--------------------
Jul 31 20:11:18 beaglebone msgd:0: rtapi_app exit detected - scheduled
shutdown
Jul 31 20:11:20 beaglebone msgd:0: msgd shutting down
Jul 31 20:11:20 beaglebone msgd:0: zeroconf: unregistering 'Log service on
beaglebone.local pid 31143'
Jul 31 20:11:20 beaglebone msgd:0: log buffer hwm: 0% (5 msgs, 474 bytes
out of 524288)
Jul 31 20:11:20 beaglebone msgd:0: normal shutdown - global segment detached
the last five lines of the log are the same lines that are
printed when HAL is shut down normally. What is really
odd is that HAL is NOT shut down. I still have a halcmd
prompt, and I can still issue commands. In particular,
"show all" tells me that the GPIO driver is initializing:
halcmd: show all
Loaded HAL Components:
ID Type Flags Inst Name PID State
73 RT 0 hal_bb_gpio RT
initializing, u1:0 u2:0
72 User 0 halcmd31474 31474 ready,
u1:0 u2:0
71 uHAL i 0 hal_lib31474 31474 ready,
u1:0 u2:0
66 rHAL i 0 hal_lib 0 ready,
u1:0 u2:0
The pin list includes the driver's pins, but the function list does not
include its functions.
And when I exit from halcmd, that is when the next two errors
happen:
halcmd: quit
halcmd: cant connect to rtapi_app: -1 (uri=
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout
halcmd: the rtapi:0 RT demon is not running - please investigate
/var/log/linuxcnc.log
halcmd: the msgd:0 logger demon is not running - please investigate
/var/log/linuxcnc.log
halcmd: cant connect to rtapi_app: -1 (uri=
uuid=a42c8c6b-4025-4f83-ba28-dad21114744a): rtapi_rpc(): reply timeout
halcmd: the rtapi:0 RT demon is not running - please investigate
/var/log/linuxcnc.log
halcmd: the msgd:0 logger demon is not running - please investigate
/var/log/linuxcnc.log
machinekit@beaglebone:~/grinder$
Nothing is written to the log at this point, which makes sense
because the logger and RT daemon are both dead.
So there appears to be multiple things going on:
1) hal_bb_gpio runs into a problem that prevents it from loading
2) hal_bb_gpio fails to generate any message to identify the problem
(or maybe the message is lost due to item 3)
3) hal_bb_gpio exits poorly, apparently crashing the HAL daemon as it goes
4) halcmd is blissfully unaware that the daemon is crashed until you try to exit
Any suggestions? I'm going to start looking at the source for hal_bb_gpio,
but I'm not set up to build machinekit on the target system (beaglebone).
My understanding is that building is painfully slow, and cross-compiling
seems like an enormous PITA. Certainly not something a user can (or
should be expected to) do.
--
John Kasunich
[email protected]
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
