I am using ar93xx board with pepe2k u-boot. I need to silence all messages printed on the console, as I found there are separate parts print on console:
1- u-boot - can be silenced via its sources
2- early kernel messages starts with something like [0.000000] Linux version x.x.x - ??????
3- later kernel messages - can be silenced via sysctl.conf
4- login - silenced via inittab
My problem is number 2. I tried different ways but with no result, here is the list of some options I tried:
disabling early printk in ar71xx/configxxx
changing CONFIG_CMDLINE="rootfstype=squashfs,jffs2 noinitrd console=null" in ar71xx/configxxx
change bootargs in uboot, console=null
Make uboot with --silence option
none of them was useful, I got confused.
Any help would be greatly appreciated.
Try passing quiet on the kernel command line.
Related
While this Q/A does not address the actual issue of: How to detect with client (eg redis-py) that redis is running out of memory constraint not by machine but by the maxmem configuration? Before inserts fail which command to use in the programm to detect about to be full?
My first guess is: info and check if used_memory_peak < maxmem setting. Is this correct?
(Besides, for out of machine memory, since defrag, use which setting, none of the returned INFO fields help here)
Well should i just try an insert and see if fail (but that would be after the fact then.)
Trail and error, good enough tested by running
while true; do redis-cli lpush mm longstringhere; done; results on maxmem - used_memory < 0.1MB with insert failures:
(error) OOM command not allowed when used memory > 'maxmemory'.
So i have set i poll it via redis-py client and once the diff goes <1mb threshold throw up, sry raise Error of course. Make sure the user_memory memory addon of your longest command is < threshold too of course otherwise you run into it on insert.
I try to figure how to calc the ~percentage of used mem so i get notification way earlier eg 90% of maxmem, therefore this solution is fine.
Info dump:
# Memory
used_memory:3126272
used_memory_human:2.98M
used_memory_rss:5292032
used_memory_rss_human:5.05M
used_memory_peak:4914296
used_memory_peak_human:4.69M
used_memory_peak_perc:63.62%
used_memory_overhead:696654...
Furthermore maxmem is not a hardcap, when running it further by eg adding members to existing set.
used_memory:3162584
used_memory_human:3.02M
code to get percent 0-100
rmem_info = pipe.info(section='memory')
{'redis_mem_percent': math.ceil(rmem_info['used_memory'] / rmem_info['maxmemory'] *100)}
I installed ROS melodic version in Ubuntu 18.04.
I'm running a rosbag in the background to mock cameras in messages rostopics.
I set the camera names in rosparams and iterated through it to capture each camera topics.
I'm using message_filter ApproximateTimeSynchronizer to get time synchronized data as mentioned in the official documentation,
http://wiki.ros.org/message_filters
But most of the time the callback function to ApproximateTimeSynchronizer is not being called/is having delay. The code snippet I'm using is given below:
What am I doing wrong here?
def camera_callback(*args):
pass # Other logic comes here
rospy.init_node('my_listener', anonymous=True)
camera_object_data = []
for camera_name in rospy.get_param('/my/cameras'):
camera_object_data.append(message_filters.Subscriber(
'/{}/hd/camera_info'.format(camera_name), CameraInfo))
camera_object_data.append(message_filters.Subscriber(
'/{}/hd/image_color_rect'.format(camera_name), Image))
camera_object_data.append(message_filters.Subscriber(
'/{}/qhd/image_depth_rect'.format(camera_name), Image))
camera_object_data.append(message_filters.Subscriber(
'/{}/qhd/points'.format(camera_name), PointCloud2)
topic_list = [filter_obj for filter_obj in camera_object_data]
ts = message_filters.ApproximateTimeSynchronizer(topic_list, 10, 1, allow_headerless=True)
ts.registerCallback(camera_callback)
rospy.spin()
Looking at your code, it seems correct. There is, however, a trouble with perhaps bad timestamps and ergo this synchronizer as well, see http://wiki.ros.org/message_filters/ApproximateTime for algorithm assumptions.
My recommendation is to write a corresponding node that publishes empty versions of these four msgs all at the same time. If it's still not working in this perfect scenario, there is an issue with the code above. If it is working just fine, then you need to pay attention to the headers.
Given that you have it as a bag file, you can step through the msgs on the command line and observe the timestamps as well. (Can also step within python).
$ rosbag play --pause recorded1.bag # step through msgs by pressing 's'
On time-noisy msgs with small payloads, I've just written a node to listen to all these msgs, and republish them all with the latest time found on any of them (for sync'd logging to csv). Not optimal, but it should reveal where the issue lies.
During my test on Pepper, I found some difficulties in realizing continuative collaborative dialog.
In particular, after about 10 minutes, it seems that the ALSpeechRecognition engine stops working.
In other words, Pepper dialog panel remains empty and/or the robot does not understand my words, even if the structure worked some minute before.
I tried to stop and restart it (i.e., the engine) via SSH terminal, by using:
qicli call ALSpeechRecognition.pause 1
qicli call ALSpeechRecognition.pause 0
It should restart the engine according to the guidelines shown here, but it does not work.
Thank you so much guys.
Sincerely,
Giovanni
According to the tutorial, starting and stopping the speech recognition engine is done by subscribing/unsubscribing it.
The recommended way to do this is unsubscribing and subscribing back to it. For me it also worked changing the speech reco language and chaging it back to the one you had previously.
Luis is right and to do so just create a function as below given and call it if ActiveListenning event comes false from ALSpeechRecognition module. Note: Use ALMemory module to get data from ALSpeechRecogntion.
asr_service = ALProxy("ALSpeechRecognition",ip,port)
memory = ALProxy("ALMemory",ip,port)
def reset():
asr_service.unsubscribe("ASR_Engine")
asr_service.subscribe("ASR_Engine")
ALS = memory.getData("ALSpeechRecognition/ActiveListening")
if ALS==False:
reset()
I'm using LabVIEW and its VISA capabilities to control a Keithley 2635A source meter. Whenever I try to identify the device, it works just fine, both in reading and writing.
viWRITE(*IDN?) /* VISA subVI to send the command to the machine */
viREAD /* VISA subVI to read output */
However, as soon as I set the voltage (or current), it does so. Then I send the command to perform a measurement, but I'm not able to read that data, with the error
VISA: (Hex 0xBFFF0015) Timeout expired before operation completed.
After that, I can not read the *IDN? output either anymore.
The source meter is connected to the PC via a National Instrument GPIB-USB-HS adaptor.
EDIT: I forgot to add, this happens in the VISA Interactive Control program as well.
Ok, apparently the documentation is not very clear. What the smua.measure.X() (where X is the needed parameter) command does is, of course, writing the measurement outcome on a buffer. In order to read that buffer, however, the simple viREAD[] is not sufficient.
So basically the answer was to simply add a print command: this way I have
viWRITE[print(smua.measure.X())];
viREAD[]
And I don't have the error anymore. Not sure why such a command is needed, but that's that. Thank you all for your time answering me.
As #Tom Blodget mentions in the comments, the machine may not have any response to read after you set the voltage. The *IDN? string is both command and query. That is, you will write the command *IDN? and read the result. Some commands do not have any response to read. Here's a quick test to see if you should be reading from the instrument. The following code is in python; I made up the GPIB command to set voltage.
sm = SourceMonitor()
# Prints out IDN
sm.query('*IDN?')
# Prints out current voltage (change this to your actual command)
sm.query('SOUR:VOLT?')
# Set a new voltage
sm.write('SOUR:VOLT 1V')
# Read the new voltage
sm.query('SOUR:VOLT?')
Note that question-marked GPIB commands and the query are used when you expect to get a response from the instrument. The instrument won't give a response for the write command. Query is a combination of write(...) and read(...). If you're using LabView, you may have to write the write and read separately.
If you need verification that the machine received your instruction and acted on it, most instruments have the following common commands:
*OPC? query to see if the operation is complete
SYST:ERR? query to see if any error was generated
Add a question mark ? to the end of the GPIB command used to set the voltage
I am extremely new to Informix and am having some trouble trying to get sqldemo installed.
Set up so far:
openSuse 12.1 (32 bit)
Informix Growth Edition 11.70 UC6
Informix SQL Developer 7.50 UC6
Informix RDS 7.50 UC6
Informix ID 7.50 UC6
After struggling a few days and a lot of reading of http://publib.boulder.ibm.com/infocenter/idshelp/v117/index.jsp, I managed to get Informix installed and On-line.
I also opted to install the demo database instance that comes with the installation.
I now and attempting to get started with Informix 4GL by Example.
I am trying to get the sqldemo database up. I don't know if it will replace the previous instance installed with Informix, but that is a different problem.
Right now as per the document, running the following should set up the DB:
sqldemo stores2t -log
I however get an error: "Invalid Locales set !!".
I have tried looking up this error and also in the documentation.
I have tried setting the CLIENT_LOCALE and DB_LOCALE in my .profile file.
For example:
export CLIENT_LOCALE=en_US.CP1252 and
export DB_LOCALE=en_US.819
This has not helped.
A push in the right direction, or perhaps some other documentation I could read that would explain things better would really be appreciated.
If any other information is required from me, please do not hesitate to ask.
Update 1
Thanks so much for the response.
A couple of things firstly that I have tried since your post.
Changed the the CLIENT_LOCALE and DB_LOCALE as you specified - Same error - So i removed it as you said it should not be set.
Fixed a problem in my PATH and made sure it has /usr/informix/bin - Same Error
INFORMIXDIR is /usr/informix
INFORMIXSERVER is ol_informix1170 (This is from the database that was installed with the informix install, don't know if this must be changed? and if so to what?)
Ran the script you mentioned, result :
INFORMIXDIR=/usr/informix
INFORMIXSERVER=ol_informix1170
INFORMIXSQLHOSTS=/usr/informix/etc/sqlhosts
LANG=en_US.UTF-8
ONCONFIG=onconfig
I noticed I had set the language to UK, which made the Locales en_gb instead if en_us, so tried changing that in my .profile, which did not help, so also tried changing the language to US and the locales to en_us, but this made no difference.
As for what you said about the sqldemo script and the already installed db, It is fine if that db is removed as this is just a test VB box for me to learn on.
Could the $INFORMIXSERVER set as ol_informix1170 be the problem?
Thank you once again for the help.
Neill
Update 2
Thanks again for the response.
A few things to note.
The dbenv results I posted is all that shows which i assume/presume (uh-oh) means that the other environment variables are not set. Which of the environment variables you posted are absolutely necessary for it to work?
As above, Where would I find the terminfo file, or does this need to be created?
As above, the SQLEXEC variable... where would I find sqlrm? I can somewhat remember from the documents I have read I think it should be $INFORMIXDIR/lib? but I only have an esql directory. Is this correct.
Barring that something in the first 3 above is not causing more problems, when trying your suggestion of DEMOPATH=en_us/0333 sqldemo stores2t -log I receive the following error:
Sorry, cannot read the mkstores3 program required to build the demonstration database. Check the /etc subdirectory of INFORMIXDIR (/usr/informix).
Checking /usr/informix/etc shows indeed that there is no mkstores3 file.
Attempting your further note of isqldemo, I get the following error:
/usr/informix/bin/isqldemo: line 58: /usr/informix/demo/sql/en_us/e01c/isqldemo: No such file or directory.
I guess this makes perfect sense as there is no e01c directory, just the 0333 directory.
Right now anything you can tell me would indeed be a consolation because my newb-ness to generally Linux and definately Informix is a big factor. Interesting that this bug has been around for so long. I guess way more experienced folk than I figured out how solve it on their own, or just never bothered with the sqldemo.
I guess that will teach me to read this:
INFORMIX-4GL by Example
Version 4.1
July 1991
Going to check now if any updated text exists, but would still appreciated more help in solving this problem. Do you think reverting to a previous snapshot before Informix was installed and not opting for the ol_informix1170 database to be included could be a possible solution? I wouldn't really see that it would be, but what do I know.
Many many thanks for your continued time and effort.
Regards,
Neill
Update 3
So I see indeed the document I was reading is ancient. I have found an updated one (2002) which uses a different script (dbaccessdemo7).
I tried running that, have run into an error, but tomorrow is another day.
For now I am going to mark this as solved because of the bug detected and resolved. I am not going to put more time and effort into sqldemo.
Thank you so much, and if I struggle with dbaccessdemo 7, I will post a new question.
Regards,
Neill
The sqldemo script won't create a new server; it may clobber your existing database (a single server may house multiple databases; indeed, there are 4 sys* databases created when a server is initialized) but it won't harm your server otherwise.
Probable cause of the error
The normal problem with invalid locales is that you've not set $INFORMIXDIR. You need $INFORMIXDIR set unless /usr/informix is (a symlink to) the correct location. You also need $INFORMIXSERVER set, and you usually need $INFORMIXDIR/bin on $PATH. Strictly, $INFORMIXSERVER is the only mandatory variable; in practice, you worry about the other two too.
The $INFORMIXDIR setting is used to locate the locale information (which is found in $INFORMIXDIR/gls) and the message files (which are found in $INFORMIXDIR/msg).
Note that CP1252 is a Windows code page. Normally on Unix, you'd either not set CLIENT_LOCALE or DB_LOCALE, or you could set them to:
export CLIENT_LOCALE=en_us.8859-1
export DB_LOCALE=en_us.8859-1
or you can choose another more appropriate (to you) locale. The 8859-15 locale includes the Euro symbol, for example, or the utf-8 locale dictates UTF-8 in the database. But, for initial debugging, stick with the 8859-1 locale, aka 819 or 0333 (all based on the IBM CCSID). If it doesn't work with 8859-1, then we have one set of problems; if it works with 8859-1 but not some other codeset or locale, then we have a different set of problems.
Follow-up info if the solution above fails
If that isn't the trouble, then I'll ask for some more details — notably, your Informix environment as reported by the dbenv script below:
: "#(#)$Id: dbenv.sh,v 2.11 2007/09/02 00:18:58 jleffler Exp $"
#
# Printout INFORMIX database environment
informix1="DB[^=]|DELIMIDENT=|SQL|ONCONFIG|TBCONFIG|INFOR"
informix2="ARC_|CLIENT_LOCALE=|GL_|GLS8BITSYS|CC8BITLEVEL|ESQL|FET_BUF_SIZE="
informix3="INF_ROLE_SEP=|NODEFDAC=|ONCONFIG|OPTCOMPIND|PDQ|PSORT"
informix4="PLCONFIG|SERVER_LOCALE|FGL|C4GL|NE_"
informix5="TCL_LIBRARY|TK_LIBRARY"
informix="$informix1|$informix2|$informix3|$informix4|$informix5"
system="COLLCHAR=|LANG=|LC_|LD_LIBRARY_PATH(_64)?=|PATH=|SHLIB_PATH="
jlss="IXD(32|64)?="
env |
egrep "^($informix|$system|$jlss)" |
sort
It's an old script; that's why the shebang is missing.
Second set of diagnosis
I was hoping for the complete output of the dbenv script; it is surprising how often something shows up. However, given what you've said, it is likely to be OK.
The INFORMIXSERVER setting sounds fine.
I'm struck by the LANG=en_US.UTF-8 setting; Informix does pay attention to $LANG and the $LC_* variables (that's why dbenv prints those out). That may be a factor in the problem. However, I would have expected CLIENT_LOCALE and SERVER_LOCALE to deal with that if it was the problem. Also, on my Mac, I have LANG=en_US.UTF-8 and yet I can connect to (8859-1) databases OK.
This is beginning to look like an install problem...or sqldemo problem...
I transitioned from a Mac to a RHEL 5 (archaic) x86/64 machine, and tried running sqldemo over there:
$ dbenv
DBDATE=Y4MD-
DBEDIT=vim
INFORMIXDIR=/work4/informix/tools-7.50.FC4
INFORMIXSERVER=toru_31
INFORMIXSQLHOSTS=/work4/informix/ids-11.70.FC4/etc/sqlhosts
INFORMIXTERM=terminfo
IXD64=/work4/informix/ids-11.70.FC4
IXD=/work4/informix/tools-7.50.FC4
IXH=/work4/informix/ids-11.70.FC4/etc/sqlhosts
IXO=/work4/informix/ids-11.70.FC4/etc/onconfig.toru_31
IXS=toru_31
LANG=en_US.UTF-8
LD_LIBRARY_PATH=/lib64:/usr/lib64:/work4/informix/tools-7.50.FC4/lib:/work4/informix/tools-7.50.FC4/lib/tools:/work4/informix/tools-7.50.FC4/lib/esql:/work4/informix/ids-11.70.FC4/lib:/work4/informix/ids-11.70.FC4/lib/esql:/work4/informix/ids-11.70.FC4/lib/cli
ONCONFIG=onconfig.toru_31
PATH=/work4/informix/tools-7.50.FC4/bin:.:/work4/jleffler/bin:/u/jleffler/bin:/work4/informix/ids-11.70.FC4/bin:/u/jleffler/linux/x86_64/bin:/work4/informix/11.70.FC1:/usr/atria/bin:/work4/jleffler/perl/v5.12.1/bin:/usr/bin:/bin:/usr/X11R6/bin:/atria_release/cm_dist/vobs/imitools/bin:/opt/rational/clearcase/bin:/opt/rational/clearquest/bin
SQLCMDLOG=/work4/jleffler/.sqlcmdlog
SQLEXEC=sqlrm
TERMINFO=/work4/jleffler/terminfo
TERM=xterm-color
$ sqldemo st2 -log
Invalid Locales set !!
$
Oh yeah? No; my locales are fine, thank you!
Well, so be it...I can reproduce your problem! That's step 1. Step 2 is to look at the expletive deleted script.
PRODUCT=sql
DEMOFILE=sqldemo
DEFLANG=en_US.8859-1
INFORMIXDIR=${INFORMIXDIR:=/usr/informix}
INFENV=$INFORMIXDIR/bin/infenv
CONVLOC=$INFORMIXDIR/bin/convloc
if [ $# -gt 0 -a "X$1" = "X-e" ] ; then
LOCALE=$DEFLANG # -e means en_US.8859-1 required
shift
else
LOCALE=`$INFENV DBLANG` # get DBLANG value
if [ "x${LOCALE}" = "x" ]; then
LOCALE=`$INFENV CLIENT_LOCALE` # try CLIENT_LOCALE instead
if [ "x${LOCALE}" = "x" ]; then
LOCALE=`$INFENV DB_LOCALE` # finally default to DB_LOCALE
fi
fi
fi
if [ "x${LOCALE}" = "x" ]; then
LOCALE=$DEFLANG # finally default to DB_LOCALE
fi
export LOCALE
if [ "x${DEMOPATH}" = "x" ]; then
echo "Invalid Locales set !!"
else
exec $INFORMIXDIR/demo/$PRODUCT/$DEMOPATH/$DEMOFILE $*
fi
exit $?
Note that test for ${DEMOPATH}; note that DEMOPATH is not set in the script. So, we've got to get it set. What to? Well, ls $INFORMIXDIR/demo/sql shows that there are various locale-specific sub-directories (en_us,
ja_jp,
ko_kr,
th_th,
zh_cn,
zh_tw) and under the en_us directory there's 0333 (only).
Please run:
DEMOPATH=en_us/0333 sqldemo stores2t -log
This more or less worked for me — I believe it would work for you. I have a slightly unusual setup in that I have just I4GL (p-code and c-code) and ISQL in the $INFORMIXDIR; the server is run out of a different directory. This means I don't have server utility programs like dbload (specifically) in $INFORMIXDIR/bin. When the sqldemo script tried to load the data with dbload, therefore, it failed for me. It would work for you because you have all the Informix software in a single directory. To add insult to injury, it runs the dbload program by explicit path, so I can't futz my PATH to make it available.
This should get you going. I have a bug to report...it is CQ idsdb00244894.
I'm sorry that you ran into so much trouble. You shouldn't have done so.