Apologies if this is the wrong place for this question, I'm not currently sure which level the problem is at so I'm hedging my bets a tad.
System is a LeopardBoard DM368 running TI's own SDK / LSP / BusyBox kernel.
By default the system has one UART enabled, UART0, mounted as /dev/ttyS0 which is also used/invoked via the bootargs console=ttyS0,115200n8 earlyprintk.
We want to enable UART1 as /dev/ttyS1, so have gone through the low-level board initialisation code which sets up the pinmux, clocks, etc.
On booting, the low-level init reports (via printk's I added in) that it's enabled the UART1, and the driver code reports happiness too:
[ 0.547812] serial8250.0: ttyS0 at MMIO 0x1c20000 (irq = 40) is a 16550A
[ 0.569849] serial8250.0: ttyS1 at MMIO 0x1d06000 (irq = 41) is a 16550A
However, the port does not (reliably) appear in /dev/, and there are discrepancies with its status (flow control bits) which I suspect may be causing it to hang / never transmit:
cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A mmio:0x01C20000 irq:40 tx:97998 rx:0 CTS|DSR
1: uart:16550A mmio:0x01D06000 irq:41 tx:0 rx:0 DSR
If I try to modify it from the command line I get an error:
>: stty -F /dev/ttyS1
stty: /dev/ttyS1: Inappropriate ioctl for device
Bizarrely, if I change the bootargs to console=ttyS1,115200n8 earlyprintk the port works perfectly, and ttyS0 is initialised correctly and works too:
cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A mmio:0x01C20000 irq:40 tx:0 rx:0 CTS|DSR
1: uart:16550A mmio:0x01D06000 irq:41 tx:11563 rx:0 RTS|DTR|DSR
Now, that would be fine, but our bootloader must use UART0 so it would be nice to keep all the console stuff on ttyS0 and have ttyS1 for our secondary comms.
Edit to add: I inserted a couple of printk's into serial_core.c and it seems like uart_open() is never being called for ttyS1, I'm assuming it's something in the Linux init/startup sequence that needs modifying?
I'll state now that I'm not a hardy Linux hacker so it's entirely possible I've missed some obvious/dumb thing in either the kernel code, initialisation sequence, etc.
Any thoughts greatly appreciated!
Well a nice chap over on the Linux board solved it, I need to insert a mknod /dev/ttyS1 c 4 65 somewhere.
Quite why this (apparently) happens for ttyS0 or whichever port is console I don't know, but right now all that matters is it works!
Comments / further info on the reasons why would be welcome for my own knowledge / future generations.
Related
I'm creating a ubuntu 20.04 QEMU image with debootstrap (debootstrap --arch amd64 focal .). However, when I tried to boot it with a compiled Linux kernel, it failed to boot:
[ 0.678611] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 0.681639] Call Trace:
...
[ 0.685135] ret_from_fork+0x35/0x40
[ 0.685712] Kernel Offset: disabled
[ 0.686182] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---
I'm using the following command:
sudo qemu-system-x86_64 \
-enable-kvm -cpu host -smp 2 -m 4096 -no-reboot -nographic \
-drive id=root,media=disk,file=ubuntu2004.img \
-net nic,macaddr=00:da:bc:de:00:13 -net tap,ifname=tap0,script=no \
-kernel kernel/arch/x86/boot/bzImage \
-append "root=/dev/sda1 console=ttyS0"
So I'm guessing the error comes from the wrong root device name (/dev/sda1 in my case). Is there any way to find the correct root device name?
Update from #Peter Maydell's comment:
[ 0.302200] VFS: Cannot open root device "sda1" or unknown-block(0,0): error -6
[ 0.302413] Please append a correct "root=" boot option; here are the available partitions:
[ 0.302824] fe00 4194304 vda
[ 0.302856] driver: virtio_blk
[ 0.303152] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Where vda should be the root device name.
This kind of "unable to mount root fs on unknown-block" error has several possible causes:
You asked the kernel to use the wrong device as the rootfs (or you didn't specify, and the built-in default is the wrong one)
You asked the kernel to use the right device as the rootfs, but the kernel doesn't have a device driver for it compiled in. (This might include more complicated cases like "the device is a PCI device and the kernel doesn't have the PCI controller driver compiled in.")
You asked the kernel to use the right device as the rootfs, and the kernel does have a driver for it, but it couldn't find the hardware, perhaps because the QEMU command line is incorrect
An important clue in figuring out which is the problem is to look at the part of the kernel log just before the "Kernel panic" part of the log. The kernel should print a list of "available partitions", which are the devices that it has a driver for and which are present. If that list contains a plausible looking device name, as in your case (where "vda" is listed as provided by the "virtio_blk" driver) then you now know what the root device name should be, and all you need to do is fix the kernel command line, eg "root=vda". Note that this list is a list of available partitions, so if your disk image has multiple partitions they should show up in the list as "vda1", "vda2", etc. (In this case it looks like your image is a single filesystem, not a disk image with multiple partitions, so only "vda" is in the list.)
If the kernel's list of available partitions doesn't include anything that looks like the disk you were expecting, then either the kernel is missing the driver, or the QEMU command line doesn't have the option to provide the device. This is a little harder to debug, but there may be useful information earlier in the kernel bootup log where the kernel probes for hardware -- for instance there should be logging when the PCI controller is probed. You can also of course double-check the config file for your kernel to see if the right CONFIG options are set.
If you're using a standard distro kernel then these usually have all the usual devices built-in, and your first check should be your QEMU command line. If you built your own kernel from source, check your config, especially if you were trying to achieve a "minimal" kernel with only the desired drivers present.
I have a VM backed by vCenter.
vCenter ESXi have physical adapter "Broadcom BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller" and SR-IOV enabled on this.
VM is connected to 1mgmt network (vmxnet3) and 2 SR-IOV adapters (SRIOVPassthrough).
Upon booting of the VM, only 2 networks shown up. (1mgmt and 1SR-IOV).
Journalctl -k logs showed following error.
[ 4832.408471] bnxt_en 0000:13:00.0 (unnamed net_device) (uninitialized): Error (timeout: 500015) msg {0x0 0x0} len:0
[ 4832.408930] bnxt_en: probe of 0000:13:00.0 failed with error -1
Reboot of machine did not help at all.
For the successful one adapter
bnxt_en 0000:03:00.0 eth1: NIC Link is Up, 25000 Mbps full duplex, Flow control: ON - receive & transmit
bnxt_en 0000:03:00.0 eth1: FEC autoneg off encodings: None
I did rescan of the pci devices and did multiple times reboot without any success.
Any pointers would be really helpful
We've got a similar issue and were able to fix it.
In our case we had the same error message on Debian 10, 11 and Oracle Linux 8 but we installed it directly on hardware without an hypervisor.
But it could be the same issue cause you're using passthrough.
There are two ways to fix it:
Usage of UEFI Boot
Disable PXE Boot and keep Bios / Legacy Boot
Both options fixed it.
Disabling PXE didn't work for us, but we can get the ports back online, by running
echo 0000:af:00.0 > /sys/bus/pci/drivers/bnxt_en/bind
Where 0000:af:00.0 is the PCI number for the port, which can be gotten from dmesg | grep bnxt_en and looking for the port or ports that failed.
I am trying to run NuttX on STM32f429I. I have build nuttX and flashed the nuttx to the device. But after flashing when i am trying to start minicom, it showing this problem
minicom: cannot open /dev/ttyUSB0: No such file or directory
I already followed all the steps given in this How to connect to a terminal to Serial-USB device on Ubuntu 10.10? post.
I am getting this after Serial Post setup from minicom.
Checking with lsusb
Checking with dmesg | grep tty
I have also checked with ttyUSB1,ttyUSB2, ttyACM1,ttyACM0 etc.
result of sudo lsusb -v
I am following this tutorial. My machine is Ubuntu 16.04LTE
Edit:
~/nuttxworkspace/nuttx$ dmesg | grep tty
[ 0.000000] console [tty0] enabled
[ 0.888895] 00:04: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[25292.460385] cdc_acm 2-1.5:1.1: ttyACM0: USB ACM device
Is there some reason that you would expect to see /dev/ttyUSB0? Do you have CDC/ACM device class configured? What does your configuration use for a serial console? I would expect it would use the STLink-VCOM port. There won't be any USB connection unless you have full configured it that way.
I am following riscv.org guides for toolchain building. When emulate using qemu running local built rootfilesystem (with busybox) and Linux Kernel, encounter the error below:
Running Qemu using local-built root.bin and kernel image
danny#danny:~/test/riscv/work$ qemu-system-riscv -hda root-local.bin -kernel vmlinux-local -nographic
unassigned address was called?
with addr: 102000735F80006E
not implemented for riscv
Running Qemu using riscv.org stocked root.bin and kernel image
danny#danny:~/test/riscv/work$ qemu-system-riscv -hda root.bin -kernel vmlinux -nographic
[ 0.150000] io scheduler cfq registered (default)
[ 0.160000] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 0.160000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 0.160000] TCP: cubic registered
[ 0.160000] htifbd: detected disk with ID 1
[ 0.160000] htifbd: adding htifbd0
[ 0.160000] VFS: Mounted root (ext2 filesystem) readonly on device 254:0.
[ 0.160000] devtmpfs: mounted
[ 0.160000] Freeing unused kernel memory: 64K (ffffffff80002000 - ffffffff80012000)
[ 0.200000] EXT2-fs (htifbd0): warning: mounting unchecked fs, running e2fsck is recommended
#uname -a
Linux ucbvax 3.14.15-g4073e84-dirty #4 Sun Jan 11 07:17:06 PST 2015 riscv GNU/Linux
If qemu testing using the downloaded root.bin and vmlinux from riscv.org, seem ok but cant see the busybox starting message and the terminal cant Halt :
Have tested qemu using various combination and result as below:
**root.bin vmlinux RESULT**
local-built local-built Unassigned address was called ....
Downloaded Downloaded Seem OK but without busybox starting bar
local-built Downloaded Kernelpanic-not syncing:No working init found
Downloaded local-built Unassigned address was called ....
We are starting a project to build and fabricate a RISCV silicon chip for Makers around the world and testing the toolchain now in order to port Ubuntu Core & Android to RISCV. Any idea what might probably went wrong ?
Thanks.
QEMU hasn't been fully updated to support the new RISC-V privileged spec (github issue). The update is currently underway.
For an ISA simulator, spike is a good alternative. It may not have all of the platform features of QEMU, but it could serve as a starting point while the QEMU update completes.
I am trying to fix a problem I am having on Ubuntu (tried different versions including the latest 13.10) with a USB device talking CDC/ACM on one of its interfaces. The kernel module handling this kind of devices only reports
cdc_acm 6-2:1.1: This device cannot do calls on its own. It is not a modem.
cdc_acm: probe of 6-2:1.1 failed with error -22
in dmesg and that is it. Nothing about "Zero length descriptor references" or similar stuff that other people report on the web. So I wanted to find out what the problem might be. I followed the description in http://www.silly-science.co.uk/2012/06/23/lenovo-usb-modem-in-linux-ubuntu-10-04 to compile and load a custom cdc-acm module. First, I changed the two #undefs for debug to #defines in cdc-acm.c, but I am still not getting any additional output in dmesg.
Changing the version string in cdc-acm.c's DRIVER_VERSION define to something else, I can verify that my modified module is indeed loaded. Am I looking for the debug output in the wrong place?
I managed to get debug info from cdc_acm in dmesg, and even though I don't have something special to share, these were my steps, using latest kernel as of today 4.2-rc5:
Change DEBUG and VERBOSE_DEBUG #undefs to #defines in cdc-acm.c.
make -C /lib/modules/$(uname -r)/build M=$(pwd)/drivers/usb/class modules
modprobe -r cdc_acm; insmod $(pwd)/drivers/usb/class/cdc-acm.ko
dmesg after plugging a compatible device
[...]
[14035.355036] cdc_acm 2-2:1.1: acm_tty_write - write 1
[14035.368040] cdc_acm 2-2:1.1: acm_softint
[14038.156445] cdc_acm 2-2:1.0: acm_tty_close
[14038.173054] cdc_acm 2-2:1.0: acm_ctrl_msg - rq 0x22, val 0x0, len 0x0, result 0
[14038.173059] cdc_acm 2-2:1.0: acm_port_shutdown
[14038.173640] cdc_acm 2-2:1.0: acm_ctrl_irq - urb shutting down with status: -2
[14038.174636] cdc_acm 2-2:1.1: acm_read_bulk_callback - urb 0, len 0
[...]