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

[Karl R. <Kar...@gm...>]

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
-- 
von Karl Reichert

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger