[etherlab-dev] "ecrt_master_write_idn(...)" and "invalid opcode: 0000"

PAUL-SOFTWARE software at paul.eu
Tue Feb 18 10:16:29 CET 2014


That is exactly what I was looking for, thank you very much!

Now I am one step closer to my solution, depending that I am disallowed to make any more kmalloc's in our realtime environment. But, it seems that I need a change in the master, so I could make a soe_read similar to a sdo_read...
I try it for my self and will report back suggesting a change solution which might be adding functions like ecrt_soe_request_read(...) and so on....




-----Ursprüngliche Nachricht-----
Von: Gavin Lambert [mailto:gavinl at compacsort.com] 
Gesendet: Dienstag, 18. Februar 2014 08:03
An: Koch Daniel
Cc: etherlab-dev at etherlab.org
Betreff: RE: [etherlab-dev] "ecrt_master_write_idn(...)" and "invalid opcode: 0000"

Quoth Koch Daniel:
> Everytime I try to reset a slave-error on a BoschRexroth Servo-Drive by
> sendig a SoE-Message (S-0-0099) via ecrt_master_write_idn, i am facing a
> kernel issue (see below) on my rtai-system (version 3.6.1 on a patched
> linux 2.6.24 with ethercat-master 1.5.2). Has anybody ever faced this
> issue as well? Hopefully, anyone knows a hint getting rid off of this?

I can't speak to this exactly, but:

> Feb 13 15:15:20 pc-wt1 kernel: Call Trace:
> Feb 13 15:15:20 pc-wt1 kernel:  [<c0162967>] __kmalloc+0x9c/0xd5
> Feb 13 15:15:20 pc-wt1 kernel:  [<c023750c>] vscnprintf+0x14/0x20
> Feb 13 15:15:20 pc-wt1 kernel:  [<f91b4144>]
> ec_soe_request_alloc+0x23/0x52 [ec_master]
> Feb 13 15:15:20 pc-wt1 kernel:  [<f91af8d2>]
> ecrt_master_write_idn+0x62/0x2d1 [ec_master]
> Feb 13 15:15:20 pc-wt1 kernel:  [<f986bfc8>] calc_idn+0x52/0x5c [r7912]

This trace indicates that inside ec_soe_request_alloc, it was trying to call
vscnprintf.  The only path that would do this is when kernel memory
allocation fails.

This suggests that you are either out of memory or something was making it
request an allocation for a silly number of bytes (perhaps an incorrect
parameter value somewhere).

Given that the allocation inside vscnprintf also appears to have failed
(with a crash), it's likely that you are out of memory.






More information about the etherlab-dev mailing list