In VxWorks, I can display global variables in the shell like so:
-> my_global
my_global = 0x103c4110: value = 4 = 0x4
Is there a way to do the same with a RTP global variable?
You can display global variables in a specific RTP by using the command (cmd) interpreter and attaching to the RTP.
Here is an example with comments in parenthesis.
-> cmd (switch to command interpreter)
[vxWorks *]# rtp exec Hello_RTP.vxe &
Launching process 'Hello_RTP.vxe' ...
Process 'Hello_RTP.vxe' (process Id = 0x105e4d50) launched.
Attachment number for process 'Hello_RTP.vxe' is %1.
[vxWorks *]# echo $my_global (display my_global in the kernel context)
0x4
[vxWorks *]# %1 (attach to RTP - can also use rtp attach)
[Hello_RTP]# echo $my_global
0x6b7 (global variable from RTP context)
[Hello_RTP]# echo $my_global
0x16e1 (same global variable..it increments)
[Hello_RTP]# %0 (detach from RTP. Go to kernel)
[vxWorks *]# echo $my_global (back to kernel context)
0x4
Note that this is only available in VxWorks 6.x Before the 6 release, there was no RTP in vxWorks.
Related
I use the gpsd python library in order to read and parse the NMEA string recieved from the gps device. I would like to send some command to gps in order to fine tune the measurement rate, report rate and so on.
It is possible using the gpsd library or I must send the command with in other way?
According to 'gpsd' manual:
To send a binary control string to a specified device, write to the
control socket a '&', followed by the device name, followed by '=',
followed by the control string in paired hex digits.
So if you have gpsd service running as gpsd -F /var/run/gpsd.sock you can use the following code to send commands to the gps device:
import socket
import sys
# Create a socket
sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
# Connect the socket to the port where the GPSD is listening
gpsd_address = '/var/run/gpsd.sock'
sock.connect(gpsd_address)
# #BSSL 0x01<CR><LF> - Set NMEA Output Sentence (GGA only)
# cmd = '#BSSL 0x01' + '\r\n'
# #RST<CR><LF> - RST - Reset
cmd = '#RST' + '\r\n'
message = '&/dev/ttyUSB1='
cmd_hex = cmd.encode('utf-8').hex()
print ('cmd_hex {}'.format(cmd_hex))
# cmd_hex 405253540d0a
message += cmd_hex
bin_message = message.encode('utf-8')
print ("bin message {}".format(bin_message))
# bin message b'&/dev/ttyUSB1=405253540d0a'
sock.sendall(bin_message)
data = sock.recv(16)
print ('received {}'.format(data))
# received b'OK\n'
sock.close()
In my case I am sending #RST command followed by CR, LF symbols.
I have a problem configuring the bootrom parameters for my virtual machine VxWorks 5.5.
I want to change the target IP address. I tried modifying the DEFAULT_BOOT_LINE macro in config.h. But, I didn't work. I use printf to check the value of DEFAULT_BOOT_LINE. It didn't changed.
This seems that DEFAULT_BOOT_LINE is defined elsewhere beside config.h and can't be modified. Do you know what the problem is? Is there other methods to change the bootrom parameters?
To erase BOOT_LINE_ADRS and get back to DEFAULT_BOOT_LINE,
-> my_boot_line = malloc (8)
-> memset my_boot_line, 0x00, 8
-> memset my_boot_line, 0xff, 4
-> sysNvRamSet my_boot_line, 8, 0 /* This line depends on your BSP. */
To change boot parameters at the bootrom prompt,
[VxWorks Boot] c
To change boot parameters at shell prompt,
-> bootChange /* at the shell prompt */
I am debugging OpenSSH code where it seems multiple channels have been allocated on single SSH session (single connected child server).
My queries could be naive here:
Under what conditions can multiple channels be opened?
What are the SSH message flows which lead to multiple channels? A message flow chart will be very helpful.
Is it correct to free channels[0] in the case below?
(gdb) p channels[0]
$1 = (Channel *) 0xb0f33e20
(gdb) p channels[0]->rfd
$2 = 0xd
(gdb) p channels[0]->efd
$3 = 0xffffffff
(gdb) p channels[0]->wfd
$4 = 0xffffffff
(gdb) p channels[1]->wfd
$5 = 0x9
(gdb) p channels[1]->efd
$6 = 0xffffffff
(gdb) p channels[1]->rfd
$7 = 0x9
Under what conditions can multiple channels be opened?
Every channel is either X11 forwarding, TCP port forwarding (there might be more types), UNIX domain socket forwarding (or ssh-agent socket) or MUX proxy. Consulting source code describing the types is a good start. They are opened, if the client requests them using command-line options (-X, -L, -R, -D, -A, ...) which are described in the manual page for ssh.
What are the SSH message flows which lead to multiple channels? A message flow chart will be very helpful.
If you will run the OpenSSH client and/or server in debug mode (LogLevel DEBUG3), you will get a lot of useful information what messages are being exchanged for various use cases.
Is it correct to free channels[0] in the case below?
Most probably not, but it is not clear what you ask here and what is the context. That is obviously valid channel with read file descriptor pointing to FD 0x0D so you might expect there will be something to read at some point.
How should i go about reading value from TAR register in msp430. I wnat to see the values, like we have serial monitor to do so in Arduino. I know we do not have anything like that in msp(except energia of course).I am coding in CCS 5.5.0.
The registers for the MSP430 processors are defined in standard headers and can then just be accessed as variables, they are just memory locations after all. There is a gotcha with the TAR and TBR registers in that they can sometimes return an intermediate value if they are in the process of being updated as a clock count increments the register contents so I have always used the following code to guard against this problem.
uint16_t Timer_Value ;
Timer_Value = TAR ;
while ( Timer_Value != TAR )
{
Timer_Value = TAR ;
}
I'm using Redis (2.4.2) and with the INFO command I can read stats about my Redis server.
There are many stats, including some about how much memory is used. And one is "used_memory_peak" that seems to hold the maximum amount of memory Redis has ever taken.
I've deleted a bunch of key, and I'd like to reset this stat since it affects the scale of my Munin graphs.
There is a CONFIG RESETSTAT command, but it doesn't seem to affect this particular stat.
Any idea how I could do this, without having to export/delete/import my dataset ?
EDIT :
According to #antirez himself (issue 369 on GitHub), this is an intended behavior, but it this feature could be improved to be more useful in a future release.
The implementation of CONFIG RESETSTAT is quite simple:
} else if (!strcasecmp(c->argv[1]->ptr,"resetstat")) {
if (c->argc != 2) goto badarity;
server.stat_keyspace_hits = 0;
server.stat_keyspace_misses = 0;
server.stat_numcommands = 0;
server.stat_numconnections = 0;
server.stat_expiredkeys = 0;
addReply(c,shared.ok);
So it does not initialize the server.stat_peak_memory field used to store the maximum amount of memory ever used by Redis. I don't know if it is a bug or a feature.
Here is a hack to reset the value without having to stop Redis. The idea is to use gdb in batch mode to just change the value of the variable (which is part of a static structure). Normally Redis is compiled with debugging symbols.
# Here we have plenty of things in this instance
> ./redis-cli info | grep peak
used_memory_peak:1363052184
used_memory_peak_human:1.27G
# Let's do some cleaning: everything is wiped out
# don't do this in production !!!
> ./redis-cli flushdb
OK
# Again the same values, while some memory has been freed
> ./redis-cli info | grep peak
used_memory_peak:1363052184
used_memory_peak_human:1.27G
# Here is the magic command: reset the parameter with gdb (output and warnings to be ignored)
> gdb -batch -n -ex 'set variable server.stat_peak_memory = 0' ./redis-server `pidof redis-server`
Missing separate debuginfo for /lib64/libm.so.6
Missing separate debuginfo for /lib64/libdl.so.2
Missing separate debuginfo for /lib64/libpthread.so.0
[Thread debugging using libthread_db enabled]
[New Thread 0x41001940 (LWP 22837)]
[New Thread 0x40800940 (LWP 22836)]
Missing separate debuginfo for /lib64/libc.so.6
Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff51ff000
0x00002af0b5eef218 in epoll_wait () from /lib64/libc.so.6
# And now, result is different: great !
> ./redis-cli info | grep peak
used_memory_peak:718768
used_memory_peak_human:701.92K
This is a hack: think twice before applying this trick on a production instance.
Simple trick to clear peal memory::
Step 1:
/home/logproc/redis/bin/redis-cli BGREWRITEAOF
wait till it finish rewriting aof file.
Step 2:
restart redis db
Done. Thats It.