Re: [RTnet-developers] bug: log file isn't written

[Jan K. <jan...@we...>]

Karl Reichert wrote:
> Karl Reichert wrote:
>> Jan Kiszka wrote:
>>> Karl Reichert wrote:
>>>> Jan Kiszka wrote:
>>>>> 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:
>>>>>>
>>>>>> root@rtnet:/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
>>>> Bingo, that's the case. I run '/usr/local/rtnet/sbin/tdmacfg rteth0
>>> master 10000 -i 1' before ...
>>>> But still I don't get it: with above command I just start the master,
>> to
>>> assign a send slot, I also have to assign a slot. Can't I get a log for
>>> this?
>>>
>>> Nope, because the primary master doesn't calibrate itself - usually.
>>> Against which master should it do so? It only goes through calibration
>>> if it is restarting after a failure and there is currently a backup
>>> master running in the network.
>>>
>>> Jan
>>>
>> No, not the master, if there is no backup master, then of course not ...
>> But with second command, assigning a sending slot for master, I thought it
>> would also do calibration rounds. But from logical thinking it doesn't
>> makes sense, because t_trans = 0 and t_offs = 0 ;)
>>
>> Thanks Jan, solved my question. So seems to be no bug in there :)
>>
>> Karl
> 
> Tried now a different setup: A master and a slave _not_ on the same machines, and still logging doesn't brings any effect. No log file is created. So seems like there is really a bug!

I'm not that sure, but I cannot prove the opposite: my test net is
packed in boxes, ready to be shipped (I'm moving). Will take quite a
while until it's up again, so you may have to dig on your own (strace,
printk-debugging, etc.).

Jan