We are running the latest raspibian on the raspberry pi board and have a kernel driver for a USB peripheral which is added externally (sudo insmod driverx.ko) after boot-up by connecting to the hardware using ssh (its a headless system).
The problem is as follows:
If the device is already connected to the system upon power-up then running sudo insmod driverx.ko leads to the terminal getting stuck (no response, Ctrl+C doesn't work). Running lsmod by starting another ssh session shows that the module is in use even though there is no code running that will use it.
If I plug the USB device after the system boots up then sudo insmod driverx.ko works normally, (the terminal is still active). Running lsmod subsequently shows that that module is loaded but not in use by anyone. I can then run my user code and everything is fine. Upon running my user code lsmod shows the kernel module is in use and the number of users is 1.
In our system the USB device will always be plugged in. The kernel version and the driver version are the same.
I can fill in more details but do not wish to bias or make this query un-readble.
Please advise on what could the problem be.
Thank you for your time and help.
Possibility is that, the device is already attached into some other driver during startup. If it’s the case, the device credential of your specific device has to be removed from the startup driver.
Check the USB device list before to insert your driver.
Related
I built core-image-sato-dev and after this when I did
runqemu qemux86 core-image-sato-dev
I got
runqemu - INFO - Running MACHINE=qemux86 bitbake -e...
runqemu - INFO - Continuing with the following parameters:
KERNEL: [/opt/yocto/thud_workspace/build/tmp/deploy/images/qemux86/bzImage--4.18.33+git0+865683fc87_1a564c76f4-r0-qemux86-20220121081907.bin]
MACHINE: [qemux86]
FSTYPE: [ext4]
ROOTFS: [/opt/yocto/thud_workspace/build/tmp/deploy/images/qemux86/core-image-sato-dev-qemux86.ext4]
CONFFILE: [/opt/yocto/thud_workspace/build/tmp/deploy/images/qemux86/core-image-sato-dev-qemux86.qemuboot.conf]
runqemu - INFO - Setting up tap interface under sudo
[sudo] password for yocto:
but only the first time
I don't know what password is this.
The second time I run this the password is not asked anymore
What is setting up tap interface??
[sudo] password for yocto:
I don't know what password is this. The second time I run this the password is not asked anymore
This message is from your OS, not from Yocto. The password is likely to be the login password for the yocto user in your OS.
Yocto is calling a sudo command, and so your OS prompts you to enter your sudo password. You only have to do this once, because your OS is probably remembering your sudo login for a short period of time.
What is setting up tap interface??
A TAP interface can be created within Linux's network stack, that acts like real network hardware on your PC, but each packet it receives can be sent to a userspace program (QEMU in this case) for processing. It can also transmit packets passed to it from that same userspace program.
When QEMU runs your Yocto image, it emulates a virtual hardware device. To emulate the network hardware on this virtual device, QEMU needs a way to get network packets from the real network (on your PC) into the QEMU software, so that they can be passed into the virtual device.
So, when QEMU starts to run your Yocto image, it creates a TAP interface on your PC which is then used to pipe network packets in and out of the virtual device it's emulating.
Creating TAP interfaces on Linux requires higher privileges, and so Yocto automatically runs QEMU as sudo. Otherwise, QEMU would fail with a permissions error.
I'm using buildroot to compile a minimalistic linux with a 4.19-rt kernel. It is supposed to run on a raspberry pi 3b (arm processor). Additionally I want to run it on a x86_64 linux computer and found qemu as an emulation solution for that.
Building linux and kernel and running it on the raspi works. It boots, I can login and use it.
To test qemu I followed this instruction [1]. A recent raspbian with 4.19 kernel is booting fine so qemu seems to be installed correctly.
sudo qemu-system-arm -kernel ./qemu-rpi-kernel/kernel-qemu-4.19.50-buster -hda 2019-09-26-raspbian-buster-lite.img -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -dtb qemu-rpi-kernel/versatile-pb.dtb
Bringing 1. and 2. together fails. When I try to emulate any self build linux, qemu only shows a black screen and one CPU is using 100%.
I used the same sdcard.img that works on the real hardware. I also tried to recompile the whole system with a normal 4.19 kernel (without real time). And I tried to build a versatile system (make qemu_arm_versatile_defconfig && make). None of it works.
Command to start the emulation:
sudo qemu-system-arm -kernel zImage -drive format=raw,file=sdcard.img -cpu arm1176 -m 256 -M versatilepb -no-reboot -append "root=/dev/mmcblk0p2 panic=1 rootfstype=ext4 rw" -serial stdio
My main problem is, that there is absolutly no useful output. The command outputs the following
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
sdl: SDL_OpenAudio failed
sdl: Reason: ALSA: Couldn't open audio device: Connection refused
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
sdl: SDL_OpenAudio failed
sdl: Reason: ALSA: Couldn't open audio device: Connection refused
audio: Failed to create voice `lm4549.out'
and opens a window for the graphics output (that does not show anything). The message also appears when emulating raspbian so it does not seem to be the reason.
When I run qemu with the prebuild raspbian but without the -dtb argument, I get a message like "Error: invalid dtb and unrecognized/unsupported machine ID". I would at least expect something like this with my self build code. But because there is no output I'm out of ideas what even to google for.
Does someone maybe have an idea what I'm doing wrong or how I get qemu to provide me any useful information on what went wrong?
[1] https://blog.agchapman.com/using-qemu-to-emulate-a-raspberry-pi/
The problem is that a kernel will only boot on a piece of Arm hardware if it is compiled for that hardware. Otherwise it will generally fail, usually by crashing before it is able to output anything useful.
In particular, the QEMU 'versatilepb' machine is completely different to the Raspberry Pi. Any working set of instructions that use that machine type are really running a kernel built to work with the versatilepb board and a raspi userspace/filesystem on top of that. You're trying to build a kernel that has support for only the raspi on a machine that isn't a raspi, which won't work.
It is possible to build a kernel that works on more than one piece of Arm hardware, if you compile in the support for both board types (all the device drivers for both, etc). If you want to go down that path, I would suggest looking at the differences between the kernel config for the kernel that works and your one, and add plausible looking missing things until you find out what is actually required.
Your attempt to boot on QEMU directly from sdcard.img will not work, because QEMU's versatilepb board model does not support direct boot from sdcard (this would require us to run some kind of BIOS/firmware image in the guest, which we don't have). For versatilepb you need to supply directly to QEMU the kernel, possibly an initrd, and definitely the correct dtb for the versatilepb.
You might instead try looking at QEMU's "raspi2" and "raspi3" board models, which really do model the hardware of Raspberry Pis. The disadvantages however are that these models are missing some features and are not very actively developed, so often newer kernels don't boot on them, and also since there is no USB controller model there is no way to get networking. (This is why most blog posts etc suggest using the 'versatilepb' -- userspace doesn't often really care about exactly what hardware it's running on, so unless you're trying to do kernel development you can just run a versatilepb kernel and take advantage of the features like networking that that QEMU model has.)
Advanced Linux Sound Architecture (ALSA) tries to open audio interface device . you must provide audio device in qemu . Because the kernel is compiled with ALSA audio driver and you have compiled sdl library in Buildroot.
I face a problem that I can ping to correct IP address, it have no loss. And also I use nmap ping the pi address, and I get it correctly. Then I using VNC viewer to try access to pi, but it always show up "The connection was refused by the host computer"
Did u all have any idea ?
Your problem indicates that your Raspberry Pi was reached by the connection attempt, but that no service was running on the relevant port and hence the connection was refused. I think, this is because the VNC service is not running on your Raspberry Pi.
Update 1
Raspbian now comes with the server by default thanks to a partnership with RealVNC, it just needs to be enabled.
Original
You must enable VNC Server on your Raspberry Pi using terminal
sudo apt-get update
sudo apt-get install realvnc-vnc-server
or you can also enable VNC Server on the command line using the sudo raspi-config command.
Advanced Options->VNC:Yes
Now you can connect to the VNC Server using a application such as VNC Viewer.
I have been having this issue with my Raspberry Pi Zero W even though it worked perfectly beforehand. This page https://www.realvnc.com/en/connect/docs/raspberry-pi.html should help.
I ran vncserver in a ssh window after verifying the interface settings in raspi-config.
It started the VNC Server and gave me the VNC Server catchphrase and the IP address with Port Number as shown in the photo linked below.
vncserver output
After running that command I was able to get the VNC Viewer on my windows machine to connect to the pi.
I then ran sudo systemctl enable vncserver-x11-serviced.service in the ssh window so that it would start automatically on subsequent reboots.
I've had this same problem but found a different reason. I found three ways to get around this error message.
Plug a mouse or keyboard into the Raspberry Pi zero, waking up the screen and the VNC connection.
Wait about 5 - 10 minutes which is the amount of time for the screen saver to kick in which seems to wake up VNC connection. but don't wait to long other wise run this command to get things going via ssh "systemctl start vncserver-x11-serviced.service".
I am hoping the new update they just published will fix this problem. I don't see this as much with the Raspi B3+ as with the Zero H.
The last was plug in both monitor and mouse and that for sure fixes the VNC issues but defeats the headless connection. It seems that running headless and the screen/saver are somehow related but just not smart enough to figure it out.
For people using newer version of Raspberry, VNC option is found under:
Config>Interface Options
pinging to any service will only tells us that whether the server is currently listening on that port or not. It will not tell you the possible result to connection request asked by client.
It seems that, you have installed VNC server but not started it properly. Use this command to start it...
# vncserver start
Also recheck the port number is correct or not.
With the Rasp Pi 4 - had connecting fail after rebooting both the server and client (both Rasp Pi 4s).
Took a while to realize that I have two clients: One named "VNC Client", the other "VNC Viewer for Google Chrome".
The former works, the latter doesn't.
I am currently taking an operating systems class and I need to use qemu to run a small operating system that my professor provided. I am trying to use qemu within an ubuntu 12.04 virtual machine on virtualbox on my macbook air 5.2. I know the problems I am having probably have to do with nested virtualization but the specific error I get when I try to run qemu is:
Could not access the KVM kernel module: No such file or directory
failed to initialize KVM: no such file or directory
Back to tcg accelerator.
qemu does start up the os but the window flickers quite a lot and I would like to fix the KVM problem if possible. I've done research but I can't find a solution I can understand or that works so any help would be greatly appreciated.
Also for the ubuntu virtual machine in virtualbox I have both Enable VT-x/AMD-V and Enable Nested Paging checked under Hardware Virtualization. I've also tried using
modprobe kvm-intel
and I get this error:
FATAL: Error inserting kvm_intel (/lib/modules.3.5.0-22-generic/kernel/arch/x86/kvm/kvm-intel.ko): Operation not permitted.
In my case, the virtualization was disabled.
So sudo modprobe kvm-intel kept giving me the following error
could not insert 'kvm_intel': Operation not supported
I just had to go in the BIOS and enable Virtualization.
Try with sudo modprobe kvm-intel.
In order to have the module automatically loaded at the startup of the virtual machine, do the following:
Edit the corresponding file from the shell with sudo vim /etc/modules.conf
Possibly enter your username password.
Press the key G to go to the end of the document and then o to begin inserting.
Write kvm-intel and press Enter, producing a new line.
Press Esc to return to the Normal mode of vim. "--INSERT--" will disappear from
the bottom.
Save the file and exit vim by writing :wq.
You are done. Try to reboot and load the nested virtual machine.
I used to debug the Windows Kernel using VirtualKD, WinDBG and a single Virtual Machine.
Recently I got a Linux machine, and now I wonder- What's the easiest way to debug the Windows Kernel when your host is unable to run VirtualKD/WinDBG*?
I assume the solution will require two Virtual Machines, but I rather have two instances hosted on my actual machine rather than having an instance residing inside another virtual instance...
Is there anyway to make that work?
Thanks in advance!
*Wine is the last resort for stability reasons...
Solved! Basically, I ended up using two (VirtualBox) VMs emulating a Serial connection (null-modem cable) over a Unix domain socket (on the host). For more info, read below:
Hardware setup*:
Debuggee:
Ensure the machine is turned off and edit Serial Ports settings.
Enable Port 1, and assign values as follows: Port Number: COM1, Port Mode: Host Pipe, Create Pipe: Unchecked (client), Port/File Path: /tmp/win_link.
Debugger:
Same as above (using the same path), only this time Create Pipe should be Checked (server).
Debugger setup:
Run WinDBG and press Ctrl+K to invoke Kernel Debugging.
in COM, enter: Baudrate: 115200, Port: COM1, Resets: 0 and verify that Pipe and Reconnect are unchecked (important).
You'll be presented with the following output: Opened \\\\.\com1 Waiting to reconnect...
Debuggee setup:
Run bootcfg /debug on /port com1 /baud 115200 /id 1. To verify, run bootcfg.**
Reboot.
Quite early during the booting stage, WinDBG on the other machine should detect the debuggee is running.
*Assuming VirtualBox is used. VMWare/KVM users will probably be able to achieve the same results following similar steps. Also, for more info refer to the VirtualBox docs.
**Assuming guests are Windows XP. Later versions include bcdedit, which may be used as described here.
For QEMU\KVM follow those instructions:
http://www.linux-kvm.org/page/WindowsGuestDrivers/GuestDebugging
Very helpful but applies to Windows XP machines. You can refer to the following link if you need to configure 2 Windows7-based virtual machines on a Linux host: http://www.aldeid.com/wiki/Category:Digital-Forensics/Computer-Forensics/Debugger/Kernel
Another option nowadays is to enable local kernel debugging. This comes with some limitations, however it will enable you to access kernel data while just using one VM.
This approach only works on Windows 8.0 and Windows Server 2012 and later.
Follow these steps:
Open a Command Prompt window as Administrator.
Enter bcdedit /debug on
If the computer is not already configured as the target of a debug transport, enter bcdedit /dbgsettings local
Reboot the computer.
Once the system is rebooted, you can execute WinDBG as Administrator, press ctrl+k or go to File -> Attach to kernel -> Local and press OK.
At that point, you will be able to execute kernel-only commands and access kernel structures:
Tested under Windows 10 and with the new WinDBG version (preview).
Reference: Setting Up Local Kernel Debugging of a Single Computer Manually