So I'm running Arch on both a Raspberry Pi and a Beaglebone Black. Recently I noticed that neither device uses persistent udev naming on their network interfaces (i.e. still using eth0, wlan0 .etc).
On the Raspberry Pi, I deleted the file that prevents udev from renaming the interfaces persistently:
/etc/udev/rules.d/80-net-name-slot.rules
The Beaglebone Black is newer, and didn't even have the file. Deleting it on the Raspberry Pi appears to have had no effect. Both of them are running systemd 208.
Any idea what's going on here? Is persistent naming not supported on low-end ARM devices, or something?
Here is the output of the following command on both devices:
udevadm test-builtin net_id /sys/class/net/eth0
On the Raspberry Pi:
calling: test-builtin
=== trie on-disk ===
tool version: 208
file size: 5866515 bytes
header size 80 bytes
strings 1296323 bytes
nodes 4570112 bytes
load module index
ID_NET_NAME_MAC=enxb827eb2a5c39
ID_OUI_FROM_DATABASE=Raspberry Pi Foundation
unload module index
On the Beaglebone Black:
calling: test-builtin
=== trie on-disk ===
tool version: 208
file size: 5866515 bytes
header size 80 bytes
strings 1296323 bytes
nodes 4570112 bytes
load module index
ID_NET_NAME_MAC=enx9059af571ea7
ID_OUI_FROM_DATABASE=Texas Instruments
unload module index
Interesting enough, it's missing the ID_NET_NAME_PATH, as I get from my desktop:
calling: test-builtin
=== trie on-disk ===
tool version: 208
file size: 5882624 bytes
header size 80 bytes
strings 1301408 bytes
nodes 4581136 bytes
load module index
ID_NET_NAME_MAC=enx8c89a5c6f0ce
ID_OUI_FROM_DATABASE=Micro-Star INT'L CO., LTD
ID_NET_NAME_PATH=enp3s0
unload module index
Any ideas? I'd like to plug multiple WiFi adapters into one of these, and would prefer consistency.
You could still force names using MAC addresses:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="12:34:56:78:ab:cd", NAME="whatever"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ab:cd:12:34:56:78", NAME="somethingelse"
Related
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 attempting to boot uImage via uboot and I am getting some seemingly conflicting log info:
update Kernel1 tftp uImage-2.5 6.35. -digi-armv7a.LONEPEAK-Ver-4_33
Using FEC0 device
TFTP from server 10.12.1.77; our IP address is 10.12.1.205
Filename 'uImage-2.6.35-digi-armv7a.LONEPEAK-Ver-4_33'.
Load address: 0x94000000
Loading: #################################################################
#################################################################
###########################################
done
Bytes transferred = 2533360 (26a7f0 hex)
Calculated checksum = 0x49669c61
Updating partition 'Kernel1'
Erasing 128 KiB # 0x08540000: 0%
Erasing 128 KiB # 0x085e0000: 20%
Erasing 128 KiB # 0x08680000: 41%
Erasing 128 KiB # 0x08720000: 62%
Erasing 128 KiB # 0x087c0000: 83%
Erasing: complete
Writing: 0%
Writing: 51%
Writing: complete
Verifying: 0%
Verifying: 51%
Verifying: complete
Writing Parameters to NVRAM
Update successful
Above it shows a successful update but then when issue a reboot command I get:
scanning bus for devices... 1 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found
** Invalid boot device **
Booting partition 'Kernel0'
## Booting kernel from Legacy Image at 90007fc0 ...
Image Name: Linux-2.6.35.14-tjerbmx51_0005+
Created: 2018-10-16 21:35:37 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2533296 Bytes = 2.4 MB
Load Address: 90008000
Entry Point: 90008000
Loading Kernel Image ... OK
OK
Starting kernel ...
So my question is:
Is there a way for me to version my kernel when I build it s/t I can set the 'Image Name' so that I know its my kernel being loaded and not some type of Legacy Image??
Perhaps the CONFIG_LOCALVERSION-option of Linux kernel .config-file will help you.
From the Kernel.org:
Keep a backup kernel handy in case something goes wrong. This is
especially true for the development releases, since each new release
contains new code which has not been debugged. Make sure you keep a
backup of the modules corresponding to that kernel, as well. If you
are installing a new kernel with the same version number as your
working kernel, make a backup of your modules directory before you do
a make modules_install.
Alternatively, before compiling, use the kernel config option
“LOCALVERSION” to append a unique suffix to the regular kernel
version. LOCALVERSION can be set in the “General Setup” menu.
So during the kernel configuration you can add some clear suffix to your kernel e.g. CONFIG_LOCALVERSION="-test_some_stuff".
Some useful links: 1 and 2.
I'm attempted to use a pwm output pin as a IR transmitter using a RAMIPS SoC and the PWM IR TX kernel module. I'm running linux 4.14.37 and have added the following entry to the dts file:
pwm_ir_tx1: pwm-ir-transmitter1 {
compatible = "pwm-ir-tx";
pwms = <&pwm 1 100>;
};
I'm loading the rc-core and pwm-ir-tx kernel modules:
lsmod | grep pwm
pwm_ir_tx 2032 0
pwm_mediatek_ramips 1744 1
rc_core 19348 2 pwm_ir_tx
When the pwm-ir-tx module loads, the kernel logs:
[ 3754.108259] rc rc0: PWM IR Transmitter as /devices/platform/pwm-ir-transmitter1/rc/rc0
The sysfs nodes appear to be loaded correctly:
ls -la /sys/class/rc/
drwxr-xr-x 2 root root 0 May 29 00:18 .
drwxr-xr-x 23 root root 0 Jan 1 1970 ..
lrwxrwxrwx 1 root root 0 May 29 01:16 rc0 -> ../../devices/platform/pwm-ir-transmitter1/rc/rc0
But there is no userspace (chardev) lirc device listed in /dev so I'm not sure how I'm supposed to interact with the device. Ideally I'd like to use the Remote Controller API but this requires a chardev to be present in /dev.
ls /dev
autofs mtd2ro network_throughput
console mtd3 null
cpu_dma_latency mtd3ro port
full mtd4 ptmx
gpiochip0 mtd4ro pts
gpiochip1 mtd5 random
gpiochip2 mtd5ro shm
gpiochip3 mtd6 tty
i2c-0 mtd6ro ttyS0
kmsg mtdblock0 ttyS1
log mtdblock1 ttyS2
memory_bandwidth mtdblock2 urandom
mtd0 mtdblock3 watchdog
mtd0ro mtdblock4 watchdog0
mtd1 mtdblock5 zero
mtd1ro mtdblock6
mtd2 network_latency
I've tried loading the lirc_dev module before and after the pwm-ir-tx module, but nothing appears in /dev still, the following output appears when I load the lirc_dev module:
[ 4775.367966] lirc_dev: IR Remote Control driver registered, major 251
But still no lirc userspace device in /dev... I'm thinking the lirc_dev module is required since it provides the lirc userspace api but there doesn't appear to be any connection between it and the pwm-ir-tx module, and it's not creating any lirc chardevs in /dev.
The pwm_ir_tx module seems to be more or less a piggy-back to the pwm driver. And the pwm driver seems to be available at /sys/class/pwm/. See https://www.kernel.org/doc/Documentation/pwm.txt.
BTW, not having a lirc link in rc0/ is not uncommon - not all drivers implements this.
After reading some of rc source files in the kernel, it became obvious the ir-lirc-codec module was also required.
Basically, the pwm-ir-tx driver is defined as a type of RC_DRIVER_IR_RAW_TX. When the rc-core module registers a driver with a type of RC_DRIVER_IR_RAW or RC_DRIVER_IR_RAW_TX it calls the ir_raw_event_prepare function which in turn tries to load the ir-lirc-codec module. Once this module was available the following kernel logs appear:
[ 10.004460] lirc_dev: IR Remote Control driver registered, major 251
[ 10.131011] IR LIRC bridge handler initialized
[ 10.471561] rc rc0: PWM IR Transmitter as /devices/platform/pwm-ir-transmitter1/rc/rc0
[ 10.487456] rc rc0: lirc_dev: driver ir-lirc-codec (pwm-ir-tx) registered at minor = 0
And in /dev there is a lirc chardev device available:
ls /dev/li*
/dev/lirc0
I'm trying to setup a ramdisk for a setup I have with AT91SAM9261 and 2.6.30 kernel.
I know you would say why don't I use initramfs? I will use also that one, as of now I would like to check if I can boot with a ramdisk as rootfs.
I have already a root fs running fine on this system in jffs2 format.
I used below tutorial:
http://www.ibm.com/developerworks/library/l-initrd/
So I created the ramdisk directly on the embedded target, with 4MB size.
I used "dd" and "mkefs" and the ramdisk image works fine if I mount it as loop when rootfs is my jffs2.
I can browse mount_point and do stuff inside.
The content was created according to the section "Manually building initial RAM disk" in the above link.
In /dev I placed null and console, in /bin I copied busybox and created the links.
I set the execute attribute to init script as well, which works fine when I run it here (as loop device with jffs2 as rootfs)
In my kernel config I enabled ramdisk support as follows:
CONFIG_BLK_DEV_INITRD=y
CONFIG_RD_GZIP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
Using tftp I download the ramdisk image to 0x21100000.
At 0x20008000 I have the kernel uncompressed and at 0x22000000 the zImage copied.
However, I'm not able to boot successfully the system as it hangs when checking init process.
As I mentioned, I checked several times that my init can be executed,
I also used in the bootargs init=/bin/busybox or other scripts/binaries to check if any can be used as init.
Command line I use now:
bootargs=64M console=ttyS0,115200 root=/dev/ram0 rw
initrd=0x21100000,4194304 init=/init
For some I set ownership to "nobody" just to check if it makes any difference.
As it can be seen in the log output the ramdisk is mounted, but init fails.
It gives a warning to check the ext2 image, which I did before copying it and I have no error reported.
The tftp server is on Windows7. I though I might have some incompatibility if I copy the ramdisk image from linux to Windows then do tftp from Windows server.
So I copied the image again from Windows to linux, mounted it and checked if the FS reports any error and scripts can be executed - everything looks normal.
So I do have all files in place, attributes set, ramdisk is reported as being mounted ok as rootfs, but init cannot be found.
Uncompressing Linux......................................................................................................... done, booting the kernel.
Linux version 2.6.30-olimex (mishu#KubuntuVM) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #1 Mon Dec 29 13:53:54 CET 2014
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Olimex SAM9-L9261
Ignoring unrecognised tag 0x54410008
Memory policy: ECC disabled, Data cache writeback
Clocks: CPU 198 MHz, master 99 MHz, main 18.432 MHz
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
Kernel command line: 64M console=ttyS0,115200 root=/dev/ram0 rw initrd=0x21100000,4194304 init=/init
NR_IRQS:192
AT91: 96 gpio irqs in 3 banks
PID hash table entries: 256 (order: 8, 1024 bytes)
Console: colour dummy device 80x30
console [ttyS0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 64MB = 64MB total
Memory: 57384KB available (2924K code, 246K data, 132K init, 0K highmem)
Calibrating delay loop... 99.12 BogoMIPS (lpj=495616)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 716 bytes
NET: Registered protocol family 16
AT91: Power Management
AT91: Starting after user reset
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (junk in compressed archive); looks like an initrd
Freeing initrd memory: 4096K
NetWinder Floating Point Emulator V0.97 (double precision)
JFFS2 version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc.
msgmni has been set to 120
io scheduler noop registered
io scheduler anticipatory registered (default)
atmel_lcdfb atmel_lcdfb.0: backlight control is not available
atmel_lcdfb atmel_lcdfb.0: 225KiB frame buffer at 23140000 (mapped at ffc00000)
Console: switching to colour frame buffer device 40x30
atmel_lcdfb atmel_lcdfb.0: fb0: Atmel LCDC at 0x00600000 (mapped at c4866000), irq 21
atmel_usart.0: ttyS0 at MMIO 0xfefff200 (irq = 1) is a ATMEL_SERIAL
atmel_usart.1: ttyS1 at MMIO 0xfffb0000 (irq = 6) is a ATMEL_SERIAL
brd: module loaded
loop: module loaded
ssc ssc.1: Atmel SSC device at 0xc4878000 (irq 15)
Driver 'sd' needs updating - please use bus_type methods
dm9000 Ethernet Driver, V1.31
eth0 (dm9000): not using net_device_ops yet
eth0: dm9000e at c486a000,c486e044 IRQ 107 MAC: 3a:1f:34:08:54:64 (chip)
NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 1478 at 0x00000b8c0000
Creating 2 MTD partitions on "atmel_nand":
0x000000000000-0x000000040000 : "Partition 1"
0x000000040000-0x000020000000 : "Partition 2"
atmel_spi atmel_spi.0: Atmel SPI Controller at 0xfffc8000 (irq 12)
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
at91_ohci at91_ohci: AT91 OHCI
at91_ohci at91_ohci: new USB bus registered, assigned bus number 1
at91_ohci at91_ohci: irq 20, io mem 0x00500000
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: AT91 OHCI
usb usb1: Manufacturer: Linux 2.6.30-olimex ohci_hcd
usb usb1: SerialNumber: at91
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
udc: at91_udc version 3 May 2006
g_serial gadget: Gadget Serial v2.4
g_serial gadget: g_serial ready
mice: PS/2 mouse device common for all mice
input: gpio-keys as /class/input/input0
ads7846 spi0.2: touchscreen, irq 29
input: ADS784x Touchscreen as /class/input/input1
rtc-at91sam9 at91_rtt.0: rtc core: registered at91_rtt as rtc0
IRQ 1/rtc0: IRQF_DISABLED is not guaranteed on shared IRQs
rtc-at91sam9 at91_rtt.0: rtc0: SET TIME!
i2c /dev entries driver
i2c-gpio: probe of i2c-gpio failed with error -16
Registered led device: led1
Registered led device: led2
Registered led device: led3
Advanced Linux Sound Architecture Driver Version 1.0.20.
at73c213 spi0.3: at73c213: supported bitrate is 48500 (64 divider)
usb 1-1: new full speed USB device using at91_ohci and address 2
usb 1-1: New USB device found, idVendor=0457, idProduct=0151
usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=3
usb 1-1: Product: USB Mass Storage Device
usb 1-1: SerialNumber: 8d54bd8186b42c
usb 1-1: configuration #1 chosen from 1 choice
scsi0 : SCSI emulation for USB Mass Storage devices
ALSA device list:
#0: SAM9-L9261 external DAC on irq 15
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
rtc-at91sam9 at91_rtt.0: hctosys: unable to read the hardware clock
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 4096KiB [1 disk] into ram disk... done.
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing init memory: 132K
Failed to execute /init. Attempting defaults...
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
[<c002f414>] (unwind_backtrace+0x0/0xdc) from [<c025bd34>] (panic+0x40/0x110)
[<c025bd34>] (panic+0x40/0x110) from [<c0029500>] (init_post+0xd0/0xf8)
[<c0029500>] (init_post+0xd0/0xf8) from [<c00085a0>] (kernel_init+0xbc/0xe4)
[<c00085a0>] (kernel_init+0xbc/0xe4) from [<c0041998>] (do_exit+0x0/0x5ac)
[<c0041998>] (do_exit+0x0/0x5ac) from [<00000001>] (0x1)
I plan to rebuild busybox and try again, but as my current ramdisk image works when I mount it as loop I don't have too much confidence it will change something.
I'm out of ideas. I've been trying the whole day to get this working.
Help is much appreciated.
Thanks.
Missing libraries were the root cause for the non-executable init placed on the ramdisk.
Using chroot turned out to be extremely useful. With this issue I learned how to use chroot and simulate a jail.
Another trick was to use user_debug=31 in the command line so that the kernel will output a message saying that the file is not found.
It looks like the "file not found" does not really point to a missing file, but to a failure to read the file system due to busybox not executing properly (missing libraries).
In parallel I have compiled dynamically the busybox 1.20.02 for my arm architecture and the ramdisk worked properly (without libs).
This user_debug=31 turned out to be again useful when I compiled and ran busybox, as it was also failing after mounting the ramdisk, but it thrown out an "undefined exception" which led me to a wrong "arch" value used for compiling busybox. After changing it everything was fine.
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.