Karl Reichert wrote:
> Jan Kiszka wrote:
>> Karl Reichert wrote:
>>> Jan Kiszka wrote:
>>>> Karl Reichert wrote:
>>>>> Hi,
>>>>>
>>>>> found sth, looks like a bug: When using 'tdmacfg rteth0 slot 0 100 -s
>>>> 100 -l rtnet.log' I do not get any logfile.
>>>>
>>>> Everything is possible given that this features was never intensively
>>>> used AFAIK (at least by myself). I do remember it once worked - right
>>>> after I implemented it.
>>>>
>>>> Just to double-check: That tdmacfg command is the first one issued
>> after
>>>> "tdmacfg rteth0 master/slave", isn't it?
>>>>
>>>> Jan
>>>>
>>> Yes it is. Searched whole / for rtnet.log, nothing is there. But from a
>> quick look at sourcecode of tdmacfg I can't find any reason why it doesn't
>> works.
>>
>> [It's a shame, but I'm lacking a test environment...]
>> Please collect an "strace" dump of the related tdmacfg run. Let's see if
>> that already gives some hints. Next step would then be gdb/ddd.
>>
>> Jan
>>
>
> Hi Jan,
>
> See below for strace log. Seems like it doesn't even tries to open a file:
>
>
>
> [EMAIL PROTECTED]:/usr/local/rtnet/sbin# strace ./tdmacfg rteth0 slot 0 100
> -s 100 -l rtnet.log
> execve("./tdmacfg", ["./tdmacfg", "rteth0", "slot", "0", "100", "-s", "100",
> "-l", "rtnet.log"], [/* 34 vars */]) = 0
> brk(0) = 0x804b000
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0xb7f85000
> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=34837, ...}) = 0
> mmap2(NULL, 34837, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f7c000
> close(3) = 0
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0`\1\000"..., 512) =
> 512
> fstat64(3, {st_mode=S_IFREG|0644, st_size=1307104, ...}) = 0
> mmap2(NULL, 1312164, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0xb7e3b000
> mmap2(0xb7f76000, 12288, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13b) = 0xb7f76000
> mmap2(0xb7f79000, 9636, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f79000
> close(3) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0xb7e3a000
> set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e3a6c0, limit:1048575,
> seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
> seg_not_present:0, useable:1}) = 0
> mprotect(0xb7f76000, 4096, PROT_READ) = 0
> munmap(0xb7f7c000, 34837) = 0
> open("/dev/rtnet", O_RDWR) = 3
> ioctl(3, NCP_IOC_GETMOUNTUID, 0x804a760) = 0
This is TDMA_IOC_CAL_RESULT_SIZE, the command to calculate the expected
size of the log file. It returns 0, and that can only mean that TDMA
considers the addressed Ethernet device as already calibrated. Possible
reasons:
- some "slot" command was already issued on the device
- device is configured as (primary) master
- calibration rounds were set to 0 ("tdmacfg ... -c 0")
- some bug is sabotaging this procedure subtly
If you think the latter, tracking the issue down should now continue at
kernel level, checking eg. the TDMA_FLAG_CALIBRATED flag.
Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
