I try to understand some kernel messages related to the CAN bus driver for mcp251x
in syslog I have several
hard_xmit called while tx busy
and at last
mcp251x spi0.0 can0: bus-off
What is hard_xmit and what causes it?
uname -a
Linux cilix-19 5.15.32-v7l+ #1538 SMP Thu Mar 31 19:39:41 BST 2022 armv7l GNU/Linux
dmesg | grep model
[ 0.000000] OF: fdt: Machine model: Raspberry Pi Compute Module 4 Rev 1.0
Related
I am working on an Embedded board. Using the USB-Uart converter, board serial logs are accessed on my Desktop.
On my Desktop I am using the minicom application, to view the board's logs.
1] Power on the embedded board.
2] Kernel booting logs get printed on minicom.
3] It is observed that some booting messages are get printed twice on minicom, e.g.
[ 7.553435] LCD210 platform: Hook NA51068 driver.
Dec 22 12:43:37 (none) user.warn kernel: [ 7.553435] LCD210 platform: Hook NA51068 driver.
[ 7.587133] LCD200:0: suspend_state:1
Dec 22 12:43:37 (none) user.warn kernel: [ 7.587133] LCD200:0: suspend_state:1
In the above logs, line no 1 is printed by the Linux kernel,
[ 7.553435] LCD210 platform: Hook NA51068 driver.
And line no 2. is printed by syslogd on the minicom, while the kernel is booting.
Dec 22 12:43:37 (none) user.warn kernel: [ 7.553435] LCD210 platform: Hook NA51068 driver.
The above message is also present in /var/log/messages file.
I just want to avoid printing the same message twice.
How do I stop the syslogd, to don't print the messages on serial terminal, while the Linux kernel is booting?
Got Lenovo Ideapad 3 at end of year. Installed ubuntu 20.04 on it. Webcam "works" but the image is undistinguishable (basically an indescript blob and I don't look that bad). Can run hand in front of webcam and see some change to blob, but nothing recognizable. Can turn camera on and off. Not a pro, so I've been searching and gathered the following data:
uname -a
Linux mjcasile-IdeaPad-3-15IIL05 5.8.0-44-generic #50~20.04.1-Ubuntu SMP Wed Feb 10 21:07:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Many refs to fix in 5.4.0-37-generic ... but figuring I'm at 5.8.0-44-generic would include it. Should I research backing off to 5.4.0-37-generic ? Not sure kernel level is the issue
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
sudo lshw
output includes this:
*-usb:0
description: Video
product: Integrated Camera
vendor: Chicony Electronics Co.,Ltd.
physical id: 5
bus info: usb#1:5
version: 27.11
serial: 0001
capabilities: usb-2.01
configuration: driver=uvcvideo maxpower=500mA speed=480Mbit/s
lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 2386:4339 Raydium Corporation Raydium Touch System
Bus 001 Device 002: ID 04f2:b6d9 Chicony Electronics Co., Ltd Integrated Camera
Bus 001 Device 004: ID 8087:0aaa Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
ls -l /dev/video*
crw-rw----+ 1 root video 81, 0 Mar 14 20:13 /dev/video0
crw-rw----+ 1 root video 81, 1 Mar 14 20:13 /dev/video1
dmesg
Pertinent info (per my untrained eye)
[ 2.151466] usb 1-5: New USB device found, idVendor=04f2, idProduct=b6d9, bcdDevice=27.11
[ 2.151467] usb 1-5: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[ 2.151468] usb 1-5: Product: Integrated Camera
[ 2.151469] usb 1-5: Manufacturer: Chicony Electronics Co.,Ltd.
[ 2.151470] usb 1-5: SerialNumber: 0001
...
[ 2.810480] uvcvideo: Found UVC 1.10 device Integrated Camera (04f2:b6d9)
...
[ 2.797385] videodev: Linux video capture interface: v2.00
[ 2.807515] intel_rapl_common: Found RAPL domain package
[ 2.807517] intel_rapl_common: Found RAPL domain core
[ 2.807518] intel_rapl_common: Found RAPL domain uncore
[ 2.807867] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[ 2.810480] uvcvideo: Found UVC 1.10 device Integrated Camera (04f2:b6d9)
[ 2.811987] input: Raydium Corporation Raydium Touch System as /devices/pci0000:00/0000:00:14.0/usb1/1-6/1-6:1.0/0003:2386:4339.0002/input/input12
[ 2.812088] hid-multitouch 0003:2386:4339.0002: input,hiddev0,hidraw1: USB HID v1.10 Device [Raydium Corporation Raydium Touch System] on usb-0000:00:14.0-6/input0
[ 2.812132] usbcore: registered new interface driver usbhid
[ 2.812133] usbhid: USB HID core driver
[ 2.816014] input: Integrated Camera: Integrated C as /devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.0/input/input13
[ 2.816062] usbcore: registered new interface driver uvcvideo
[ 2.816063] USB Video Class driver (1.1.1)
...
[ 3.814863] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 3.815098] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input14
[ 3.815322] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 3.816277] fbcon: i915drmfb (fb0) is primary device
[ 3.816318] Console: switching to colour frame buffer device 170x48
(on a prior run I also saw:
[ 0.168948] ACPI: Added _OSI(Linux-Dell-Video))
When I bring up VLC and Open Capture Device ... I get error:
Your input can't be opened: VLC is unable to open the MRL 'v4l2:///dev/video0'. Check the log for details.
Any idea where to begin on this? Thanks,
OK, clearly an embarrassing answer. The little label telling one how to turn the webcam on and off was actually covering the camera. Take off the label, and voila. All is good. I guess that qualifies as a "hardware" problem. More of a DFU though (Dumb darn user).
I am having an issue on some servers since some time, and fail to find the issue.
These are x86_64 server, with Intel Xeon, configured to boot in UEFI over network, through an iPXE rom.
Kernel and initramfs are the ones from Centos 8 (tried 8.0 and 8.2).
But when booting, I always end up with (on every servers, so should not be related to an hardware failure):
[ 5.542304] hid-generic 0003:0557:2221.0002: input,hidraw1: USB HID v1.00 Keyboard [Winbond Electronics Corp Hermon USB hidmouse Device] on usb-0000:00:1a.0-1.3/input1
[ 5.599611] rtc_cmos 00:02: setting system clock to 2020-06-26 19:21:43 UTC (1593199303)
[ 5.620965] md: Waiting for all devices to be available before autodetect
[ 5.640580] md: If you don't use raid, use raid=noautodetect
[ 5.659949] md: Autodetecting RAID arrays.
[ 5.676869] md: autorun ...
[ 5.691838] md: ... autorun DONE.
[ 5.707883] List of all partitions:
[ 5.723667] No filesystem could mount root, tried:
[ 5.723667]
[ 5.754724] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 5.775237] CPU: 9 PID: 1 Comm: swapper/0 Not tainted 4.18.0-193.6.3.el8_2.x86_64 #1
[ 5.815778] Call Trace:
[ 5.830360] dump_stack+0x5c/0x80
[ 5.845920] panic+0xe7/0x2a9
[ 5.860995] mount_block_root+0x2c5/0x2e9
[ 5.877407] ? do_early_param+0x91/0x91
[ 5.892617] prepare_namespace+0x135/0x16b
[ 5.907676] kernel_init_freeable+0x22e/0x258
[ 5.922607] ? rest_init+0xaa/0xaa
[ 5.937398] kernel_init+0xa/0xff
[ 5.950991] ret_from_fork+0x35/0x40
[ 5.964572] Kernel Offset: 0x2ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 6.000387] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---
The iPXE boot script is:
#!ipxe
kernel http://10.10.0.1/vmlinuz-4.18.0-193.6.3.el8_2.x86_64 initrd=initramfs-4.18.0-193.6.3.el8_2.x86_64.img selinux=0 rd.shell rd.debug root=live:http://10.10.0.1/squashfs.img rw console=tty0 console=ttyS1,115200
initrd http://10.10.0.1/initramfs-4.18.0-193.6.3.el8_2.x86_64.img
boot
Which generate this in the console:
http://10.10.0.1/vmlinuz-4.18.0-193.6.3.el8_2.x86_64... ok
http://10.10.0.1/initramfs-4.18.0-193.6.3.el8_2.x86_64.img... ok
INTEL 0x6f080f70 MAC reset (081c0261/80280783 was 081c0261/80280783)
INTEL 0x6f080f70 MAC reset (081c0261/80280783 was 081c0261/80280783)
INTEL 0x6f081ab0 MAC reset (081c0261/80280787 was 081c0261/80280787)
[ 0.000000] Linux version 4.18.0-193.6.3.el8_2.x86_64 (mockbuild#kbuilder.bsys.centos.org) (gcc version 8.3.1 20191121 (Red Hat 8.3.1-5) (GCC)) #1 SMP Wed Jun 10 11:09:32 UTC 2020
[ 0.000000] Command line: vmlinuz-4.18.0-193.6.3.el8_2.x86_64 initrd=initramfs-4.18.0-193.6.3.el8_2.x86_64.img selinux=0 rd.shell rd.debug root=live:http://10.10.0.1/squashfs.img rw console=tty0 console=ttyS1,115200
...
On the server side, on apache logs I have:
10.10.2.1 - - [26/Jun/2020:19:55:42 +0200] "GET /vmlinuz-4.18.0-193.6.3.el8_2.x86_64 HTTP/1.1" 200 8913656 "-" "iPXE/1.0.0+"
10.10.2.1 - - [26/Jun/2020:19:55:42 +0200] "GET /initramfs-4.18.0-193.6.3.el8_2.x86_64.img HTTP/1.1" 200 53703611 "-" "iPXE/1.0.0+"
So it seems to be working perfectly.
This is diskless boot here, but whatever I try (kickstart diskfull install, or even kernel+initrd alone) I always end up to this kernel panic...
I tried to reset BIOS settings, try to boot in legacy/pcbios instead of UEFI, tried to desactivate sata disks, etc. Always this same error. Also tried to use kernel+initrd from Centos ISO (checked checksum), tried to use the ones from my management node. Nothing. Do I miss something obvious?
Does any of you have an idea or already faced this kind of issue?
Many thanks in advance :-)
With my best regards
Beuk
I can't control screen brightness in KDE(power management is enabled, but I don't see the brightness control in the power management widget. The brightness keys used to work as well, but now they aren't). I'm on the unstable channel, it was working in the 19.03 release
Battery and brightness settings (Power management widget)
Powerdevil, upower seem to be running without errors, although on startup
This seems relevant -
journalctl -xb | grep brightness
Oct 09 08:47:25 blackbox kernel: thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
Oct 09 08:47:25 blackbox kernel: thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
Oct 09 08:47:43 blackbox xsession[1343]: invalid metadata "/run/current-system/sw/lib/qt-5.12.3/plugins/powerdevilkeyboardbrightnesscontrolaction_config.so"
Oct 09 08:47:43 blackbox xsession[1343]: invalid metadata "/run/current-system/sw/lib/qt-5.12.3/plugins/powerdevilbrightnesscontrolaction_config.so"
Oct 09 08:47:45 blackbox xsession[1343]: powerdevil: Falling back to helper to get brightness
Oct 09 08:47:45 blackbox xsession[1343]: powerdevil: "DBus Backend error: service start org.kde.powerdevil.backlighthelper failed: Bus name not found in system service directory"
System information
nix-info
system: "x86_64-linux",
multi-user?: yes,
version: nix-env (Nix) 2.3,
channels(root):
"nixos-20.03pre196201.07d4df59626, home-manager, nixos-hardware"
neofetch --stdout
xxx#blackbox
-----------------
OS: NixOS 20.03pre196201.07d4df59626 (Markhor) x86_64
Host: 20KGSBP200 ThinkPad X1 Carbon 6th
Kernel: 4.19.75
Uptime: 1 day, 4 hours, 16 mins
Packages: 1005 (nix-system), 1152 (nix-user)
Shell: zsh 5.7.1
Resolution: 2560x1440
DE: Plasma
WM: KWin
Theme: Breeze [GTK2]
Icons: breeze [GTK2]
CPU: Intel i5-8350U (8) # 3.600GHz
Memory: 3920MiB / 15919MiB
I had the same problem and fixed it by uninstalling the Nvidia proprietary driver for the GPU and used the open source Linux driver instead.
Goal: emulate the "sabrelite : Freescale i.MX6 Quad SABRE Lite Board (Cortex A9)" that Qemu specifically supports (doing 'qemu-system-arm -M ?' it shows up).
Qemu ver: 2.10.1 (host: fedora-27).
I have successfully cross-compiled and built a 4.1.46 Linux kernel (used the imx_v6_v7_defconfig config file) as well as a simple "skeleton" root filesystem (busybox-based). (FYI, I have a similar working setup for the ARM Cortex-A9 Versatile Express platform - I do this using my own home-spun embedded Linux system called SEALS).
Looking at the U-Boot config file used by similar boards, I figured to use 'root=/dev/mmcblk0p0' as the root= param for the kernel.
So, to try it out I then run qemu as follows (pl scroll horizontally as well to see):
qemu-system-arm -m 512 -M sabrelite -kernel zImage -drive file=rfs.img,format=raw -append "console=ttymxc0 rootfstype=ext4 root=/dev/mmcblk0p0 rw rootwait init=/sbin/init " -nographic -dtb imx6dl-sabresd.dtb
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.1.46 (kai#klaptop) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #2 SMP Mon Nov 27 17:16:22 IST 2017
[ 0.000000] CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] Machine model: Freescale i.MX6 DualLite SABRE Smart Device Board
[ 0.000000] cma: Reserved 16 MiB at 0x2f000000
[...]
So it starts to boot up just fine. But then:
[...]
[ 2.210965] /soc/aips-bus#02100000/usdhc#02194000: voltage-ranges unspecified
[ 2.211796] sdhci-esdhc-imx 2194000.usdhc: Got CD GPIO
[ 2.212199] sdhci-esdhc-imx 2194000.usdhc: Got WP GPIO
[ 2.214392] sdhci-esdhc-imx 2194000.usdhc: could not get ultra high speed state, work on normal mode
[ 2.218084] sdhci-esdhc-imx 2194000.usdhc: No vmmc regulator found
[ 2.218367] sdhci-esdhc-imx 2194000.usdhc: No vqmmc regulator found
[ 2.265431] mmc0: SDHCI controller on 2194000.usdhc [2194000.usdhc] using ADMA
[ 2.267300] mmc0: mmc_rescan_try_freq: trying to init card at 400000 Hz
[ 2.281912] /soc/aips-bus#02100000/usdhc#02198000: voltage-ranges unspecified
[ 2.282956] sdhci-esdhc-imx 2198000.usdhc: Got CD GPIO
[ 2.283703] sdhci-esdhc-imx 2198000.usdhc: Got WP GPIO
[ 2.284044] sdhci-esdhc-imx 2198000.usdhc: could not get ultra high speed state, work on normal mode
[ 2.284892] sdhci-esdhc-imx 2198000.usdhc: No vmmc regulator found
[ 2.285167] sdhci-esdhc-imx 2198000.usdhc: No vqmmc regulator found
[ 2.298029] mmc0: mmc_rescan_try_freq: trying to init card at 300000 Hz
[ 2.337904] mmc1: SDHCI controller on 2198000.usdhc [2198000.usdhc] using ADMA
[ 2.357051] /soc/aips-bus#02100000/usdhc#0219c000: voltage-ranges unspecified
[ 2.358313] sdhci-esdhc-imx 219c000.usdhc: No vmmc regulator found
[ 2.358642] sdhci-esdhc-imx 219c000.usdhc: No vqmmc regulator found
[ 2.368204] mmc0: mmc_rescan_try_freq: trying to init card at 200000 Hz
[ 2.414722] mmc2: SDHCI controller on 219c000.usdhc [219c000.usdhc] using ADMA
[ 2.440456] mmc0: mmc_rescan_try_freq: trying to init card at 100000 Hz
[...]
[ 2.986441] No soundcards found.
[ 3.007698] Waiting for root device /dev/mmcblk0p0...
Keeps waiting forever here ...
I understand that, on an actual physical board, one would have to "format" or partition the MMC (or SD) card, and have u-boot load up the kernel and rootfs into RAM. But am currently interested in getting the IMX6 working on Qemu...
So, my actual question: how can I get the root filesystem mounted and operational on Qemu?
Any help appreciated! TIA,
There are two problems here. Firstly, your command line isn't actually creating an SD card: the -drive option creates a drive object but doesn't try to plug it in anywhere (because the sabrelite board doesn't define a "default kind of block drive"). To actually plug in the drive to an emulated sd card you need
-drive file=yourfile.img,format=raw,id=mycard -device sd-card,drive=mycard
Secondly, there are bugs in QEMU's current imx6 sd controller emulation, because if you do that then the guest kernel continuously prints
[ 28.971663] mmc1: Timeout waiting for hardware interrupt.
[ 28.973619] mmc1: error -110 whilst initialising SD card
...so it has found the emulated card but isn't getting an interrupt it expects.
These can be fixed by a patch currently on the qemu-devel mailing lists and going through code review: http://patchwork.ozlabs.org/patch/834805/ plus a simple change to hw/arm/fsl-imx6.c to make it create TYPE_IMX_USDHC devices rather than TYPE_SYSBUS_SDHCI. (Basically the imx6's SD controller isn't a completely standard compatible sdhci controller but what we were creating in the QEMU model was the plain variety.)
If you do all that then you can boot a kernel that can see the mmc card:
[ 8.878283] mmc1: new SD card at address 4567
[ 8.910566] mmcblk0: mmc1:4567 QEMU! 256 MiB
With a little luck we'll be able to have this fixed in the 2.12 release of QEMU, which will be out in some time in spring 2018.
Edit as of 9 Mar 2018 -- the relevant fixes are now in QEMU master (commits fd1e5c81796, df2a5cf4c8) and will be in 2.12.