Hi phoenix, > -----Original Message----- > From: Felix Niederwanger <[email protected]> > Sent: Thursday, December 7, 2023 4:58 PM > To: [email protected] > Subject: Re: Only one CPU on RockPi 5B > > Hey Guillaume, > > Finally managed to test this on Tumbleweed and there i have two CPUs. So the > issue appears to be only limited to Leap Micro 5.5 and not being present on > Tumbleweed.
That's good news! > > Hardware: Radxa RockPi 5B (Rockchip RK3588) TW 20231205 > Kernel: 6.6.3-1-default > > Should I open a bug for this issue? Yes please. And Cc me. Thanks, Guillaume > > Best, > phoenix > > On 12/1/23 09:40, Felix Niederwanger wrote: > > Hey Guillaume, > > > > Find attached the xml of the VM I created and manage via virt-manager. > > > > This server is currently in usage, I will try to make some time on the > > weekend to check Tumbleweed and report back. > > > > Stay tuned, > > phoenix > > > > On 12/1/23 09:17, Guillaume Gardet wrote: > >> Hi Phoenix, > >> > >>> -----Original Message----- > >>> From: Felix Niederwanger <[email protected]> > >>> Sent: Friday, December 1, 2023 9:09 AM > >>> To: [email protected] > >>> Subject: Only one CPU on RockPi 5B > >>> > >>> Hello! I have an interesting problem on my Radxa RockPi 5B (Rockchip > >>> RK3588) SOC: I have Leap Micro 5.5 running (Kernel > >>> 5.14.21-150500.55.36-default) and VMs cannot have more than one vCPU. > >>> > >>> When I boot a VM (here: Leap 15.5) with e.g. 2 vCPUs, I get the > >>> following error > >>> message: > >>> > >>> [ 0.003395][ T1] psci: failed to boot CPU1 (-22) [ > >>> 0.003409][ T1] CPU1: failed to boot: -22 > >>> > >>> And then after some time the system boots, but only with one CPU: > >>> > >>> # cat /proc/cpuinfo > >>> processor : 0 > >>> BogoMIPS : 48.00 > >>> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics > >>> fphp asimdh p cpuid asimdrdm lrcpc dcpop asimddp CPU implementer > >>> : 0x41 CPU architecture: 8 CPU variant : 0x4 CPU part : 0xd0b > >>> CPU revision : 0 > >>> > >>> I also observe that one full core is constantly busy on the > >>> hypervisor, or more specifically by the qemu-system-aarch64 process > >>> therein. > >>> > >>> Anyone an idea what's going on here? > >> > >> That's an interesting problem! > >> > >> Could you share the qemu command line you used to boot your guest? > >> If possible, could you try Tumbleweed as host to check if the problem > >> still exists with a more recent software stack? > >> > >> Thanks, > >> Guillaume > >> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
