I'm trying to solve problem with linux printk() messages (Linux raspberrypi 3.6.11+ #87 PREEMPT Fri Feb 7 00:17:11 CET 2014 armv6l GNU/Linux).
What I have is a kernel module which implements unlocked_ioctl function from struct file_operations. When I call this function from user space with specified cmd=CMD_PRINTK, the following code is executed:
case CMD_PRINTK:
{
printk(KERN_EMERG "TEST KERN_EMERG\n");
printk(KERN_ALERT "TEST KERN_ALERT\n");
printk(KERN_CRIT "TEST KERN_CRIT\n");
printk(KERN_ERR "TEST KERN_ERR\n");
printk(KERN_WARNING "TEST KERN_WARNING\n");
printk(KERN_NOTICE "TEST KERN_NOTICE\n");
printk(KERN_INFO "TEST KERN_INFO\n");
printk(KERN_DEBUG "TEST KERN_DEBUG\n");
}
What I was expecting is that amount of displayed messages will depend on second value of
root#raspberrypi:/mnt/raspberrypi/linux/linux/mod# *cat /proc/sys/kernel/printk*
7 **4** 1 7
But what I observe is only the first message "TEST KERN_EMERG\n" which is printed by syslogd btw on every virtual terminal (pts/1...)
In kernel command line I've specified the console as tty1
root#raspberrypi:/mnt/raspberrypi/linux/linux/mod# *cat /proc/cmdline*
dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708.boardrev=0x3 bcm2708.serial=0xf8900c76 smsc95xx.macaddr=B8:27:EB:90:0C:76 dwc_otg.lpm_enable=0 **console=/dev/tty1** root=/dev/nfs nfsroot=192.168.1.102:/home/borys/rpi_rootfs ip=192.168.1.103:192.168.1.102:192.168.1.1:255.255.255.0:rpi:eth0:off rootfstype=nfs
I tried to use minicom to connect to /dev/tty1 but still I cannot observe any messages displayed there.
I tried to kill syslogd but it didn't help.
At the moment I think that I don't understand something about virtual terminals. I had setup with STLinux platform and console specified as serial port (/dev/ttyAS0) and I was able to connect with serial cable from my host computer and I saw all printk() messages.
Can someone explain how to display kernel printk() messages in virtual terminal via minicom connection?
Is it possible at all?
Will it be possible to control printk() messages verbosity then?
Updated: 05.05.2014
My colleague found first mistake in my cmdline. It should be
**console=tty1**
not
**console=/dev/tty1**
because filesystem is not available at the moment of cmdline parsing. After this change I can see debugs in virtual terminal and using
dmesg -n x
as suggested by oakad below, I can change its verbosity.
This is almost but not certainly what I wanted actually. The one thing which I'm still missing is the connection to vitural terminal tty1 via minicom.
Currenlty I can see kernel logs only on the screen connected to my raspberry pi or via serial interface ttyAMA0.
Additionally when I run my test on PC I can see kernel debugs if I switch to virtual console via Alt+Ctrl+n where n is the number of virtual console.
What I would like to have is for example:
ssh session to raspbery pi in which I start minicom and specify tty1 as a port.
The same in case of PC I would like to start xterm (/dev/pts/n) in which I start minicom and specify tty1 as a port.
Unfortunatelly both, in case of rasberry Pi and in case of PC I cannot see kernel debugs in such minicom session. In case of raspberry Pi I tried to send file from minicom and I saw it was working - file content was displayed in display connected directly to rasberry pi. Unfortuanatelly logs from rasberry to minicom are not transferred or are stucked somewhere. Does anyone could tell me if such method for kernel logs display is possible at all?
You can set your console "verbosity" level with dmesg -n x, where x is the name of the "minimal" message priority you want printed out to the console. Try saying dmesg -n debug to see everything on the console, KERN_DEBUG messages included.
Related
I'm trying to establish a connection with a gauge, which connects to a PC via usb-serial interface. I managed to do this in Windows 8 via vendor proprietary program, which uses Prolific driver version 3.2.0. In windows I monitored data exchanged between the gauge and the software with a help a of a software "HDD Software Device Monitoring Studio".
Now I want to repeat data exchange I have seen in HDD Software Device Monitoring Studio but this time in the Debian Gnu/Linux without vendor's properietary program for the gauge. To do this in Debian I installed a software "jpnevultor version 2.1.3" which seems to fit my needs, because it is able to write and read data to a serial port.
After installing this program I plugged the gauge to the PC running Debian and issued dmesg|tailcommand, int the output there was a line usb-3-1: pl2303 converter now attached to ttyUSB0so I assummed that pl2303 driver installed on the Debian and successfully identified the gauge and I can access it.
To test if I can send data to the gauge via /dev/ttyUSB0 file I created a text file named hello with the following content
FF 3A 32 34 31 3B 30 3B 30 3B 36 35 34 30 35 0D
this is a byte sequence that I monitored via HDD Software Device Monitoring Studio any time I started data exchange with a gauge via vendor proprietary program.
Now I am trying to feed this byte sequence to a gauge. First of all in Debian I executed following command jpnevulator --tty /dev/ttyUSB0 --read. It put terminal to a pending state, so I am assumming that program is waiting for a data comming from the ttyUSB0.
After then I opened second terminal window and excecute following command jpnevulator --tty /dev/ttyUSB0 -f hello --write to write data from the mentioned file hello with the byte sequence to the /dev/ttyUSB0.
Write command executed normally. But when I switched back to the first terminal window to see if there are bytes that came from the gauge I found that there none like if I didn't send any data to the /dev/ttyUSB0/.
I tried to issue following commands: modprobe -r pl2303; modprobe pl2303 and repeating mentioned write and read commands with no results. I tried setting /dev/ttyUSB0 speed to 9600 via command stty -F /dev/ttyUSB0 ispeed 9600 because , tried to change permissions of /dev/ttyUSB0 to 777 and ran all mentioned command under a root account, but the result were the same - read command didn't return any data. Could you please help me to find out why this is happenning and how can I properly write and read data to /dev/ttyUSB0?
I am having issues with my pyserial program on Ubuntu 16.
I am trying to send a break command to a hardware device using pyserial. I wrote a python script that:
Sets the port/baud/parity/bytesize/...
Opens the port
Sends a break command
Reads the return message from the device.
I run the script on my Ubuntu 16.04 machine and I get zero response, it just hangs or eventually timeouts. I copy the same script to my Windows machine, change the port (from /dev/ttyUSB0 to COM#) and my script works perfectly, gets a response from the device immediately.
When I run the script on Ubunutu I have to give permissions to the port (sudo chmod 666 /dev/ttyUSB), or I get permission denied errors when opening the port. Not sure if this matters.
Does anyone have any insight on what might be going on? I know Windows and Linux handle serial/com ports differently but I am a newbie to both Linux and serial so not sure if I am missing something.
I am using this USB to Serial cable (http://www.ugreen.com.cn/product-681-en.html) and I had to install some drivers. I connected the serial read/write pins and tested to make sure data is going through (which it is) so I know that works.
import serial
ser = serial.Serial()
ser.port = '/dev/ttyUSB0' # or COM12 on windows
ser.baudrate = 9600
ser.parity = serial.PARITY_NONE
ser.bytesize = serial.EIGHTBITS
ser.stopbits = serial.STOPBITS_ONE
ser.open()
ser.send_break(duration=0.9)
print(ser.read(10))
First off, you need to have proper permissions for accessing serial ports. It can be done by including your user into the group dialout:
sudo usermod -aG dialout <user>
You need to restart the system to complete it.
To avoid of some information to remain in buffers, you may need to clear read and write buffers before serial port operations:
pyserial 3.0:
ser.reset_input_buffer()
ser.reset_output_buffer()
pyserial 2.7 or earlier:
ser.flushInput()
ser.flushOutput()
Don't forget to close a port after all operations being done. Hope this helps.
First forget about your app and focus on the port troubleshooting, use putty in serial mode for sending a few terminal chars using this port. Use a jumper for conecting DB9 pin 3 to pin 2(rx and tx) an validate that you receive an echo of each character you type.
I need to connect 2 linux PCs via serial port. I used serial connector cable (null modem cable) to connect 2 linux PCs. But now how can I establish the connection I mean how can I test whether they are connected or not. Can anybody Please let me know the procedure.. I have tried screen command and when i run
screen /dev/ttyS0
This command is just opening new screen and i cant do anything on that new screen.
Am using Fedora-20 with kernel version 3.* in one PC and another one with Fedora-27 kernel version is 4.13
Hi finally i found solution to my problem Using this_link.
at both ends tried below steps:
1) yum install minicom
2) Then I configured minicom using minicom -s then using down arrow selected serial port setup
then pressed A from keyborad to change that serial device from
/dev/modem
to
/dev/ttyS0
press enter and chose save as dfl option then exit from minicom
After these configuration steps executed the commands suggested by #Niall Cosgrove
at one end executed cat /dev/ttyS0
at other end executed echo hello > /dev/ttyS0
finally i got hello message from one pc to other end using serial port:)
I want to be able to read from serial ports on my computer and write to a file. Inside /dev (using Bash shell on Windows 10) I can't seem to locate my USB serial ports (I have tty, tty0, tty1, and that's it for tty).
Is it located somewhere else, or even accessible through the bash shell? I just want to be able to know how to access it at this point.
In device manager, COM4 shows up under ports when I plug in my USB. I also ran the command wmic path Win32_SerialPort in the Windows command prompt and it said "No Instance(s) Available." So I'm very confused as to how I can view my Serial Ports and why they aren't showing up in certain instances.
Any clarification on how serial ports work, especially with USB, would be greatly appreciated, as I am pretty new with this stuff.
Soon, Windows will officially support serial on the Windows Subsystem for Linux (WSL). The COM_n_ ports will be available at /dev/ttyS_n_
Mapping:
COM1 >> /dev/ttyS0
COM2 >> /dev/ttyS1
...
COM192 >> /dev/ttyS191
A good functional description can be found here:
https://blogs.msdn.microsoft.com/wsl/2017/04/14/serial-support-on-the-windows-subsystem-for-linux/
NOTE: At time of writing this feature is only available on the insider builds.
I have the same problem. Apparently you still can`t use serial ports in Bash on Ubuntu on Windows (BoUoW).
You can do basic read and write operations using socat. I used Cygwin to create a socat server that sees my serial ports. I had problems with DTR and RTS pins though.
With socat you can create virtual serial ports or forward a serial port over TCP. (And much more.)
In Cygwin serial ports are listed under /dev/ as ttyS*.
For example COM3 is /dev/ttyS2 and COM4 is /dev/ttyS3.
Start the server in Cygwin with
socat -d -d -d TCP4-LISTEN:2022,reuseaddr,fork /dev/ttyS3
Start the client on BoUoW with
socat PTY,link=/tmp/vmodem0 TCP:localhost:2022
This will create a virtual serial port in BoUoW at /tmp/vmodem0 that is connected to COM4 on your machine.
My Cygwin installed on Windows 7 was working properly till I try to install a new package. The package installation failed. Then I keep getting this error every time I want to run my Open MPI program. I can successfully compile the program but cannot run it. I even remove and make a new installation without success.
Thanks for any hints. Below is the sample error message.
[Reloaded-PC:03900] [[3921,1],0] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:03900] [[3921,1],0] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:04676] [[3921,1],2] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:04676] [[3921,1],2] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
The problem is solved by disabling the unused network adapter in "Control Panel->Network and Internet->Network Connections".
It turned out the unused network adapter tried to get configured by DHCP and an IP address started with "169.254.X.X" was assigned to this adapter when DHCP fails. Somehow openmpi on Cygwin use that invalid IP address for establishing communication between processes.
I figured it out by looking at /tmp/openmpi-sessions-{username}/{PID of orterun}/contact.txt.
I had this same problem on Cygwin with OpenMPI 1.10.4.
Try adding "-report-uri -" to your mpirun command to see what IP address it's trying to use for connection:
mpirun -report-uri - -np 2 a.exe
It should print out a line that looks something like this:
568328192.0;tcp://192.168.10.103,169.254.247.11,0.0.0.0,0.0.0.0,0.0.0.0:55600
If the first IP address after the "tcp://" is not a current valid address for your machine, that's the problem and things are likely to break (even if the correct IP appears later in the list). Apparently ORTE is not smart enough to order the interfaces based on what is actually enabled and online.
If the wrong IP corresponds to an old/disabled interface, uninstall it (if possible) using the windows network connections control panel.
In my case, the first address was a DHCP address for an old hardware adapter I'd removed and thrown away long ago (but apparently not uninstalled in software). Windows normally hides such removed-but-not-uninstalled interfaces in the control panel, but the settings remain in the registry under:
HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\
Search in that registry subkey for the bogus IP address and you are likely to find the problematic interface. I fixed mine by changing the IP address in that registry key to match my current static IP, but uninstalling the interface entirely would probably also work.
I had the same problem with openmpi v 1.8.8 (which is the default version of the package installed by cygwin). Manually going back to version 1.8.6 fixed the issue for me.
I just encountered this problem and in my case I had to disable the "VirtualBox Host-Only Network" adapter (I recently installed virtualbox and have not used openmpi in cygwin after that until today).
1. Open the Cygwin terminal.
mpicc --version
mpirun --version
If not execute, follow the document below and reinstall everything. Document
2. Try turning off Bluetooth and test your program again.
3. Try closing the Wifi and test your program again (you can connect to the wired internete)
4. Open C:\Windows\System32\drivers\etc\hosts
add line
127.0.0.1 localhost cygdrive wpad
and test your program again.
5. If you have a virtual network like VirtualBox or similar, turn off the control panel and test your program again.
6. If possible, uninstall VirtualBox completely. Restart your computer and test your program again.
7. Try turning off the Windows Firewall and test your program again.
The above steps solved both the "tcp_peer_send_blocking: send () to socket 12 failed: transport endpoint is not connected" error and the slowness problem in MPI for Windows 10 - Cygwin.