I am trying to write simple program, that uses libftdi, and I have come across a strange problem.
When running the program as non-root it looks like this:
./BoxDriver
Naruszenie ochrony pamięci (zrzut pamięci)
And in Dmesg the last line I see is:
[ 3320.467864] BoxDriver[4205]: segfault at 0 ip 00007f05c2821f7a sp 00007ffd9c6c9c00 error 4 in libftdi.so.1.20.0[7f05c2820000+7000]
I am using Ubuntu:
Linux AdamsPC 3.19.0-30-generic #34-Ubuntu SMP Fri Oct 2 22:08:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
And FTDI device:
Bus 001 Device 011: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC
The program runs fine, when it is running as a root:
sudo ./BoxDriver
OK, started
I have also tried to debug the source code (in eclipse ang gcc, no seg fault occurred), and the problem is with:
ftdi_usb_open(ftc, 0x0403, 0x6010)
It always returns -8, that stands for : "get product description failed"
I have searched for any answer, most are about adding user to dialout group, or adding rule to udev, but none of answers I have founded worked.
Any suggestions are highly appreciated. Thanks
There is a few different ways to fix this but generally it sounds like your user account does not have permission to interface with the USB device. You could add the user to the appropriate group I believe for ubuntu that is dialout so.
sudo usermod -a -G dialout user
Alternatively if multiple accounts need to use it but they all should have permissions you could change the filesystem it's mounted to to have full permissions.
sudo chmod 777 /media/drive_name
Related
I'm using a Blue Pill board (STM32F103CB with 128kB of flash according to st-info --probe) via a clone ST-Link/V2 like this one. I've also tested using a genuine ST-Link/V2 like this one. I get the same result, described below, with both programmers.
My system is Linux (Debian LXDE) and I've installed OpenOCD from Liviu Ionescu's releases here.
My OpenOCD installation is working. As well as the Blue Pill I have a ST-Nucleo-F103RB board, and I can connect to it using OpenOCD. The command
openocd -f board/st_nucleo_f103rb.cfg
using the standard .cfg file that ships with OpenOCD gives
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v18 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.271135
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
But I still haven't managed to connect to my Blue Pill using the ST-Link/V2 programmers. I've read everything I can find, including relevant sections of https://elinux.org/Category:OpenOCD and as much as I can personally digest of http://openocd.org/doc/. The following is where I've got to.
The .cfg file stm32f103c8_blue_pill.cfg doesn't work for me. It produces the output described below.
Based on what I've read I've prepared my own .cfg file at ../board/stm32f103.cfg. It says:
source [find interface/stlink.cfg]
transport select hla_swd
source [find target/stm32f1x.cfg]
#source [find board/stm32f103c8_blue_pill.cfg]
#reset_config srst_only
#reset_config none separate
Sources I've read suggest this should work, but it doesn't. Using my .cfg described above, it I can use either target/stm32f1x.cfg or board/stm32f103c7_blue_pill.cfg, and I still get the same output as described below. (In the case of both of those .cfg files I'm using the standard files, as shipped with OpenOCD.) I've tested with both of the reset_config variants shown above, and with neither. None of the combinations works.
The file interface/stlink.cfg that I'm using is modified. I've changed it to state the correct device_desc "ST-LINK/V2" and the correct vid_pid 0x0483 0x3748. (Both confirmed using lsusb.) So, ignoring commented lines, stlink.cfg reads
interface hla
hla_layout stlink
hla_device_desc "ST-LINK/V2"
hla_vid_pid 0x0483 0x3748
I've experimented with including the hla_serial of the programmer. Interestingly, lsusb can't find the full serial number. st-info --probe finds the serial number, but gives a slightly different number from the STLinkUpgrade firmware application. I've tried using both serial numbers. No difference.
Here's the command I give to OpenOCD:
openocd -s ~/stm32/openocd/scripts -f board/stm32f103.cfg
Notice that I have to set the path using -s for this command. With the ST-Nucleo-F103RB board, I don't have to do this. With the stm32f103.cfg file, however, if I don't set the path I get:
Error: Can't find board/stm32f103.cfg
in procedure 'script'
If I use the full command shown above, with -s to set the path, I get:
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
/[..]stm32/openocd/scripts/target/stm32f1x.cfg:47: Error: invalid command name "dap"
in procedure 'script'
at file "embedded:startup.tcl", line 60
at file "/[..]stm32/openocd/scripts/board/stm32f103.cfg", line 18
at file "/[..]stm32/openocd/scripts/target/stm32f1x.cfg", line 47
Here's the offending line 47 of stm32f1x.cfg:
dap create $_CHIPNAME.dap -chain-position $_CHIPNAME.cpu
I've searched for items on Stackoverflow/ similar about Error: invalid command name "dap". Using the OpenOCD documentation I understand that the dap create command exists, and roughly what it does. The most similar reported error I've found documented is at https://elinux.org/OpenOCD_Troubleshooting:_Invalid_Command_Name_JTAG, and the solution suggested there doesn't seem to be applicable because I'm not invoking interface/stlink.cfg from the command line.
I can't see what I'm doing wrong, and I'm now completely stuck. If someone can give me a steer I'd be really grateful. Sorry it's such a long post.
I just encountered this problem too. Officially there are no binaries provided, only source code. But there are two sites which release binaries was recommended by OpenOCD official:
1. Maintained by Freddie Chopin.
2. Maintained by Liviu Ionescu in Github.
I tried the latest version(OpenOCD 0.10.0 commit date: 2017-01-22 20:31:28 build date: 2017-01-23) released from Freddie Chopin's site, and I encountered this Error: invalid command name "dap" problem. But all *.cfg files I referenced had ran normally in my another computer with another OpenOCD binary(although I forgot where did I download that binary).
Not sure what went wrong, so I turned to the latest version(gnu-mcu-eclipse-openocd-0.10.0-11-20190118-1134-win64.zip) released by GNU MCU Eclipse(maintained by Liviu Ionescu), the error was gone, problem solved.
PS: I'm not saying there is a bug in Freddie Chopin's build, but if someone encountered this problem, maybe you can solve it by trying the version which is currently under actively maintained.
Agree with Wulfric, using standard install for OpenOCD
sudo apt install openocd
gave the "dap" error.
However the github version openocd-xpack worked correctly.
Using:
Linux clamps 4.15.0-66-generic #75-Ubuntu SMP ... as remote, Windows 8/10 as client target MIMXRT1010-EVK
My computer kept rebooting lately showing me the blue screen while I was working on RHEL 'n vmware.
The last time the computer had reboot when I turned it on again and tried to work on RHEL here's what I have.
Did anyone of you face the same problem already ?
Thanks
In essence, the error is:
dracut-initqueue[217]: Warning: dracut-initqueue timeout - starting timeout scripts
[...]
dracut-initqueue[217]: Warning: Could not boot.
dracut-initqueue[217]: Warning: /dev/disk/by-uuid/5b757528-cc16-4ff0-819d-805c908d9b35 does not exist
Starting Dracut Emergency Shell...
Warning: /dev/disk/by-uuid/5b757528-cc16-4ff0-819d-805c908d9b35 does not exist
Generating "/run/initramfs/rdsosreport.txt"
Entering emergency mode. Exist the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.
EDIT: after #Naushad Ahmad's comment:
# chroot /mnt/sysimage/
chroot: failed to run command '/bin/bash' : No such file ordirectory
# cat /etc/fstab
# cat /boot/grub2/grub.cfg
cat: /boot/grud2/grub.cfg: No such file or directory
# ls /boot
initramfs-3.10.0-693.cl7.x86_64.img
# _
[anaconda] 1:main* 2:shell 3:log 4:storage-log 5:program-log Switch tab: Alt+Tab | Help: F1
But the thing is when I start the rescue mode I ve that error message :
You don't have any Linux partitions.
I am trying to create a kickstart for Centos 7.3. I have a windows desktop with VMware Workstation Player installed. I started with a dvd that has Centos 7.3 on it. I then created a vm in VMware Workstation Player and installed the os. I restarted the vm and copied over all the files from /dev/sr0 from my dvd to a new place. I copied the anaconda file and renamed it to ks.cfg. I then used the command below to make an iso.
mkisofs -o /home/kickstart.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-road-size 4 -boot-info-able -J -R -v "centos7.3"
Next I took this and burned it to a blank cd using
growisofs --dvd-compat -Z /dev/cdrom=/home/kickstart.iso
When I use this in VirtualBox as the optical drive mounted the installer gets stuck on
Started Show Plymouth Boot Screen
Started Device-Mapper Multipath Device Controller
Starting Open-iSCSI...
Reached target Paths.
Reached target Basic System.
Started Open-iSCSI.
Starting dracut initqueue hook..
then on VMware Workstation Player it goes to
Started Show Plymouth Boot Screen
Started Device-Mapper Multipath Device Controller
Starting Open-iSCSI...
Reached target Paths.
Reached target Basic System.
Started Open-iSCSI.
Starting dracut initqueue hook..
... [sda] Assuming cache: write though
Why is it hanging on these spots? I have tried looked everywhere and can't seem to find any solutions so far.
you've probably found something else for this but in case not, or in case someone else encounters this... I encountered some issues with this as well. I don't know if I have the exact issue, though it was hanging on dracut init, and changing this bit allowed the install to continue.
What it turned out to be was the -V flag on the mkisofs command. Whatever you name it with the -V flag (which it doesn't look like you have), it needs to be the value of LABEL in your /isolinux/isolinux.cfg file. In my fiddling I was using "MyLinuxISO" for this value.
in my /isolinux/isolinux.cfg:
label linux
menu label ^Install CentOS Linux 7 with KS
menu default
kernel vmlinuz
append initrd=initrd.img inst.stage2=hd:LABEL=MyLinuxISO ks=cdrom:/ks.cfg
using mkisofs
mkisofs -o /home/kickstart.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-road-size 4 -boot-info-able -J -R -v -V "MyLinuxISO"
Don't know if this will help you but give it a shot?
Cheers
I run a vnc server on my workstation and connect with another computer. Both of the server and client are running Debian Jessie:
$ uname -a
Linux debian-VAIO 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u2 (2016-06-25) x86_64 GNU/Linux
Xfce is installed for the vnc server and xstartup is:
$ cat ~/.vnc/xstartup
#!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid grey
export XKL_XMODMAP_DISABLE=1
exec startxfce4
In the ~/.bashrc, I have added the lines below:
export LIBGL_ALWAYS_INDIRECT=y
export LD_PRELOAD='/usr/lib/x86_64-linux-gnu/libstdc++.so.6'
Currently, when I ssh to the server with ssh -X, the $DISPLAY is localhost:10.0, and the vtk related command will launch an X window. However, if a vnc server is launched in the ssh terminal, logging into xfce and opening a terminal in it, the $DISPLAY is :1.0 and vtk fails to launch an X window, with the following message:
Error: In /home/orobix/Desktop/vmtk-build/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 394
vtkXOpenGLRenderWindow (0x2c30f10): Could not find a decent visual
Error: In /home/orobix/Desktop/vmtk-build/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 394
vtkXOpenGLRenderWindow (0x2c30f10): Could not find a decent visual
Error: In /home/orobix/Desktop/vmtk-build/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 394
vtkXOpenGLRenderWindow (0x2c30f10): Could not find a decent visual
Error: In /home/orobix/Desktop/vmtk-build/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx, line 613
vtkXOpenGLRenderWindow (0x2c30f10): GLX not found. Aborting.
I think it might be relate to the missed config of X server in xstartup of vnc server. But I don't know how to do it. Could anyone help me debug it? Any further information will be provided if needed. Thanks!
20160823 Update
I accepted the suggestion of VirtualGL + TurboVNC and installed the two components. A simple config using vglserver_config was done according to http://www.virtualgl.org/vgldoc/2_1_1/#hd009001 part 6.1. Then I made vncserver of TurboVNC to run xfce with xstartup.turbovnc:
#!/bin/sh
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
OS=`uname -s`
exec startxfce4
On the client, I use vncviewer of TurboVNC to connect the server. The desktop looks quite different from that in a default vncserver. Then I tried
/opt/VirtualGL/bin/vglrun vmtkimageviewer -ifile image_volume_voi.vti
in which the vmtkimageviewer should open up a window, but finally it gives out an error:
Executing vmtkimageviewer ...
X Error of failed request: GLXBadContext
Major opcode of failed request: 156 (GLX)
Minor opcode of failed request: 6 (X_GLXIsDirect)
Serial number of failed request: 17
Current serial number in output stream: 16
And unfortunately, I find that with ssh -X, I cannot launch the X window as I did before, although $DISPLAY is still localhost:10.0. The output is:
Executing vmtkimageviewer ...
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 156 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Value in failed request: 0x0
Serial number of failed request: 37
Current serial number in output stream: 38
But I think I am closer to the fact, as it looks like VirtualGL works(?). What to do for the next?
Plain and simple the X server variant that's being used by Xrdp (either Xvnc or Xvfb) simply doesn't support OpenGL / GLX and thus programs that need OpenGL will not work in that configuration.
Fallback to Mesa swrast or llvmpipe is possible though: http://www.mesa3d.org/llvmpipe.html
Finally, I got everything done. VirtualGL only is enough for my purpose. Just install and config as the section 6.2 & 6.3 in its user's guide. Use the default vncserver and vncviewer as usual, TurboVNC is not needed. Use vglrun when you need an OpenGL support. One modification is that I should remove export LIBGL_ALWAYS_INDIRECT=y in my .bashrc.
It runs fluent in my case. #datenwolf: Thank you again!
On a Windows(R) machine the following function can be used for querying the system power status of the machine:
BOOL WINAPI GetSystemPowerStatus(LPSYSTEM_POWER_STATUS lpSystemPowerStatus);
Is there something similar for a Linux machine?
On most linux systems a daemon named acpid runs all the time monitoring for ACPI events and normally logs info to /var/log/acpid or /var/log/messages. There is a manpage for it at http://linux.die.net/man/8/acpid. acpid stores current ACPI info in /proc/acpi although that's being relocated to /sys somewhere and /sys/power/state holds the current power state seen by catting it (cat /sys/power/state). More info about ACPI is at http://acpi.sourceforge.net/documentation/sleep.html. JCM mentioned a command line tool for ACPI status monitoring named AcpiTool available at http://sourceforge.net/projects/acpitool/. I built that on CentOS and it works fine. Just follow the instructions in its INSTALL file to install it -- it requires a C++ compiler, which is commonly on linux or if not install one using yum or apt.
dmidecode can do many kinds of queries for low level issues including system power supply and controls, see http://linux.die.net/man/8/dmidecode
In collaboration with freedesktop.org RedHat developed and provides DeviceKit-power pre RH7 which is called UPower starting with RH7. It consists of a daemon and command line tool. A manpage for it is at http://www.pkill.info/linux/man/1-upower/. The --dump option of the command line tool provides some useful info but rarely up to date. Maybe restarting the daemon would cause an update. Here is an example of the output from a CentOS 6 host:
ca:17: devkit-power --dump
Device: /org/freedesktop/DeviceKit/Power/devices/line_power_ACAD
native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
power supply: yes
updated: Tue Dec 23 20:28:27 2014 (866 seconds ago)
has history: no
has statistics: no
line-power
online: yes
Daemon:
daemon-version: 014
can-suspend: no
can-hibernate yes
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: no
Most major PC vendors such as Dell and HP provide their own apps for power management and monitoring and I've found it is best to use them because they know how to query custom probes designed into the HW and print full diagnostics for their support team.
On My Ubuntu system I found this Information in /sys/class/power_suply/ADP1/online .
For example I used it in a script in an If statement with the following code:
if (( CPUBenutzung > 11 )) || ! (( $(cat /sys/class/power_suply/ADP1/online) )); then Stopmining ; fi
for me this worked fine and stopped the mining process allways when there was no power connected or I did use for some other reason all 12 threads of my notebook.