Re: exynos-mixer 14450000.mixer: [drm:exynos_drm_register_dma] *ERROR* Device 14450000.mixer lacks support for IOMMU
Hi Marek, I would like to recompile and install the kernel 6.6 on my ARM Chromebook. I would like to know if your patch has been accepted and included there. Thanks. On Wed, Nov 1, 2023 at 8:48 AM Chuck Zmudzinski wrote: > > On 10/31/2023 8:08 AM, Marek Szyprowski wrote: > > Hi, > > > > On 31.10.2023 00:03, Mario Marietto wrote: > >> We are a team of linux enthusiasts who are trying to boot Xen on a > >> Samsung XE303C12 Chromebook aka "snow" following the suggestions in > >> the slide show presentation here: > >> https://www.slideshare.net/xen_com_mgr/xpds16-porting-xen-on-arm-to-a-new-soc-julien-grall-arm > >> This device uses an exynos5250 SOC dual core 1.7 GHz with 2 MB RAM, it > >> is a Samsung armv7 chip with virtualization extensions. In particular, > >> we have it working fairly well both on the bare metal with a recent > >> 6.1.59 Linux LTS kernel and also with a recent 5.4.257 LTS kernel with > >> KVM, the older LTS kernel version is used to test KVM because support > >> for KVM on arm v7 was removed from Linux around kernel version 5.7. So > >> we know we have the hypervisor mode enabled because we were able to > >> use it with KVM. For Xen, we are using the latest Debian build of Xen > >> 4.17 for the Debian armhf architecture: (XEN) Xen version 4.17.2-pre > >> (Debian 4.17.1+2-gb773c48e36-1) > >> (pkg-xen-devel@xxx) (arm-linux-gnueabihf-gcc > >> (Debian 12.2.0-14) 12.2.0) debug=n Thu May 18 19:26:30 UTC 2023 The > >> Linux kernel is a custom build that adds the Xen config kernel options > >> (CONFIG_XEN_DOM0, etc) on top of a kernel that works well on the same > >> Chromebook model on the bare metal. I can provide the config options > >> of the kernel that was used if that is helpful. Our method of booting > >> is to have u-boot boot the Xen hypervisor and load the device tree > >> after adding the dom0 to the otherwise unaltered device tree from the > >> Linux kernel using u-boot fdt commands to add a /chosen node, as > >> described on the Xen wiki and in the pages linked from there. We have > >> also tried adding and loading an initrd.img using the device tree > >> /chosen node but that made no difference in our tests. We actually > >> have the Linux LTS kernel version 6.1.59 working as dom0 with Xen > >> using the same version of u-boot that we used for KVM, but with a big > >> problem. The problem we see is that when booting the 6.1.59 kernel > >> version as dom0 with Xen, the screen is totally dark and the only way > >> to access the system is remotely through ssh. Logs indicate most > >> everything else is working, such as the wifi card so we can access it > >> remotely via ssh and a USB optical mouse lights up when connected so > >> USB is also working. Obviously, the disk is also working. The > >> Chromebook is configured to boot from the device's SD card slot by > >> turning on Chrome OS developer mode options to enable booting from the > >> SD card slot. The mystery is that when booting the exact same 6.1.59 > >> kernel on the bare metal instead of booting it as dom0 on Xen, it > >> boots up with full access to the screen and we can interact with the > >> system using the X.org windows system. But booting as dom0 with Xen, > >> the screen is totally dark and the only access we have to the system > >> is through the network via ssh. Also, when booting the 5.4.257 kernel > >> with KVM in hypervisor mode, the screen works and we can interact with > >> the system through the X.org windows system. Exploring the log file,we > >> have seen the errors below : > >> > >> Without Xen (or in bare metal): > >> > >> devuan-bunsen kernel: [drm] Exynos DRM: using 1440.fimd device for > >> DMA mapping operations > >> devuan-bunsen kernel: exynos-drm exynos-drm: bound 1440.fimd (ops > >> 0xc0d96354) > >> devuan-bunsen kernel: exynos-drm exynos-drm: bound 1445.mixer (ops > >> 0xc0d97554) > >> devuan-bunsen kernel: exynos-drm exynos-drm: bound > >> 145b.dp-controller (ops 0xc0d97278) > >> devuan-bunsen kernel: exynos-drm exynos-drm: bound 1453.hdmi (ops > >> 0xc0d97bd0) > >> ... > >> devuan-bunsen kernel: Console: switching to colour frame buffer device > >> 170x48 > >> devuan-bunsen kernel: exynos-drm exynos-drm: [drm] fb0: exynosdrmfb > >> frame buffer device > >> devuan-bunsen kernel: [drm] Initialized exynos 1.1.0 20180330 for > >> exynos-dr
exynos-mixer 14450000.mixer: [drm:exynos_drm_register_dma] *ERROR* Device 14450000.mixer lacks support for IOMMU
Hello, We are a team of linux enthusiasts who are trying to boot Xen on a Samsung XE303C12 Chromebook aka "snow" following the suggestions in the slide show presentation here: https://www.slideshare.net/xen_com_mgr/xpds16-porting-xen-on-arm-to-a-new-soc-julien-grall-arm This device uses an exynos5250 SOC dual core 1.7 GHz with 2 MB RAM, it is a Samsung armv7 chip with virtualization extensions. In particular, we have it working fairly well both on the bare metal with a recent 6.1.59 Linux LTS kernel and also with a recent 5.4.257 LTS kernel with KVM, the older LTS kernel version is used to test KVM because support for KVM on arm v7 was removed from Linux around kernel version 5.7. So we know we have the hypervisor mode enabled because we were able to use it with KVM. For Xen, we are using the latest Debian build of Xen 4.17 for the Debian armhf architecture: (XEN) Xen version 4.17.2-pre (Debian 4.17.1+2-gb773c48e36-1) (pkg-xen-devel@xxx) (arm-linux-gnueabihf-gcc (Debian 12.2.0-14) 12.2.0) debug=n Thu May 18 19:26:30 UTC 2023 The Linux kernel is a custom build that adds the Xen config kernel options (CONFIG_XEN_DOM0, etc) on top of a kernel that works well on the same Chromebook model on the bare metal. I can provide the config options of the kernel that was used if that is helpful. Our method of booting is to have u-boot boot the Xen hypervisor and load the device tree after adding the dom0 to the otherwise unaltered device tree from the Linux kernel using u-boot fdt commands to add a /chosen node, as described on the Xen wiki and in the pages linked from there. We have also tried adding and loading an initrd.img using the device tree /chosen node but that made no difference in our tests. We actually have the Linux LTS kernel version 6.1.59 working as dom0 with Xen using the same version of u-boot that we used for KVM, but with a big problem. The problem we see is that when booting the 6.1.59 kernel version as dom0 with Xen, the screen is totally dark and the only way to access the system is remotely through ssh. Logs indicate most everything else is working, such as the wifi card so we can access it remotely via ssh and a USB optical mouse lights up when connected so USB is also working. Obviously, the disk is also working. The Chromebook is configured to boot from the device's SD card slot by turning on Chrome OS developer mode options to enable booting from the SD card slot. The mystery is that when booting the exact same 6.1.59 kernel on the bare metal instead of booting it as dom0 on Xen, it boots up with full access to the screen and we can interact with the system using the X.org windows system. But booting as dom0 with Xen, the screen is totally dark and the only access we have to the system is through the network via ssh. Also, when booting the 5.4.257 kernel with KVM in hypervisor mode, the screen works and we can interact with the system through the X.org windows system. Exploring the log file,we have seen the errors below : With Xen (or in bare metal): devuan-bunsen kernel: [drm] Exynos DRM: using 1440.fimd device for DMA mapping operations devuan-bunsen kernel: exynos-drm exynos-drm: bound 1440.fimd (ops 0xc0d96354) devuan-bunsen kernel: exynos-drm exynos-drm: bound 1445.mixer (ops 0xc0d97554) devuan-bunsen kernel: exynos-drm exynos-drm: bound 145b.dp-controller (ops 0xc0d97278) devuan-bunsen kernel: exynos-drm exynos-drm: bound 1453.hdmi (ops 0xc0d97bd0) ... devuan-bunsen kernel: Console: switching to colour frame buffer device 170x48 devuan-bunsen kernel: exynos-drm exynos-drm: [drm] fb0: exynosdrmfb frame buffer device devuan-bunsen kernel: [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 0 In this case,the kernel is able to use the exynos-drm kernel to start the fb0 device. But with Xen we get this error with exynos-drm: devuan-bunsen kernel: [drm] Exynos DRM: using 1440.fimd device for DMA mapping operations devuan-bunsen kernel: exynos-drm exynos-drm: bound 1440.fimd (ops 0xc0d96354) devuan-bunsen kernel: exynos-mixer 1445.mixer: [drm:exynos_drm_register_dma] *ERROR* Device 1445.mixer lacks support for IOMMU devuan-bunsen kernel: exynos-drm exynos-drm: failed to bind 1445.mixer (ops 0xc0d97554): -22 devuan-bunsen kernel: exynos-drm exynos-drm: adev bind failed: -22 devuan-bunsen kernel: exynos-dp: probe of 145b.dp-controller failed with error -22 I'm trying to find for a solution and I've googled a little bit and I found this web site : https://lore.kernel.org/linux-arm-kernel/20220208171823.226211-8-krzysztof.kozlow...@canonical.com/ with your email address and I tried to ask for some help for fixing the bug. Any ideas why booting the same Linux kernel that results in a working X.org display on the bare metal instead as dom0 on Xen would cause the display to remain dark, but most other basic functions would work, such as network, disk, and USB ? thanks. -- Mario.
libGL error: glx: failed to create dri2 screen libGL / error: failed to load driver: nouveau
Hello. I wrote this tutorial some time ago because I wanted that Blender was able to recognize CUDA and the Nvidia driver directly within the linuxulator : https://www.reddit.com/r/freebsd/comments/1118eae/how_to_install_the_nvidia_driver_5257801_cuda_12/ I was inspired by this tutorial : https://gist.github.com/Mostly-BSD/4d3cacc0ee2f045ed8505005fd664c6e someone found my tutorial and created this github : https://github.com/spfcraze/Nvidia-Drivers-linux He says that he created a Python script for updating Nvidia drivers on CentOS 7 and Ubuntu. That's nice,but it can't work. Why ? please give a look to an old post created by me some time ago and you will see : https://www.reddit.com/r/freebsd/comments/11431bi/how_to_blacklist_the_nouveau_driver_within_the/ since the nouveau driver can't be blacklisted within the Linuxulator because it's impossible to run "sudo update-initramfs -u" inside of it. For this reason,I would ask if in your opinion the nouveau driver can be blacklisted directly in FreeBSD or in some other way. FreeBSD does not contain the nouveau kernel module so there is nothing to blacklist. > https://www.reddit.com/r/freebsd/comments/11431bi/how_to_blacklist_the_nouveau_driver_within_the/ These libGL errors are from Mesa libGL, which is trying to use the userspace part of nouveau (which is part of the Mesa project), presumably based on Nvidia GPU's PCI ID being known to Mesa, despite there being no nouveau kernel interface available. Since I'm trying to use Nvidia's binary driver (the only one which works on FreeBSD), Blender should have never loaded Mesa's libGL in the first place - there is most likely a configuration problem here with libglvnd, the component responsible for choosing the correct libGL implementation. When Blender fails to detect CUDA this has nothing to do with libGL and absolutely nothing to do with nouveau. Smplayer behaves the same as blender. I think this is a general behavior. Check below what happens when I run it within the linuxulator : root@marietto:/mnt/zroot2/zroot2 # chroot /compat/ubuntulunar /bin/bash root@marietto:/# smplayer QStandardPaths: error creating runtime directory '/var/run/user/1001' (No such file or directory) This is SMPlayer v. 22.7.0 (revision 10091) running on Linux libGL error: glx: failed to create dri2 screen *libGL error: failed to load driver: nouveau* Can you figure out a method to do what I want to do ? If we are able to "connect" the nVidia driver to the CG / graphic tool instead of the nouveau one,a lot of cool features will be unfrozen on FreeBSD. For example we could try to run Unreal Engine 5 within the linuxulator,Davinci Resolve,Maya 3D,a lot of cool stuff will use the nVidia driver + CUDA and it will work great. That's because unfortunately Nouveau does not support CUDA. Thanks. -- Mario.
