[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BUG] Xen Dom0 fails to boot with "nvme.poll_queues=24" and "dom0_max_vcpus=6 dom0_vcpus_pin"


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Egon Ojamaa <egon.ojamaa@xxxxxxxxxxxxxx>
  • Date: Mon, 12 Oct 2026 15:51:18 +0000
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=protonmail3 header.d=protonmail.com header.i="@protonmail.com" header.h="Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:Feedback-ID"
  • Cc: "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Mon, 12 Oct 2026 15:51:34 +0000
  • Feedback-id: 7420290:user:proton
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hello,

I did a follow up on: 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170270/comments/2
Confirms same bug on 5900x Zen3 system, ubuntu 26.04 LTS , kernel 
7.0.0-38-generic , non server MB.

AFAIK, dom0_max_vcpus= I think can be any value.
For sure happens with 6 and 12.

I cant find anything in logs, so I suspect it does not boot to the point 
logging can work properly.

I tried now to get somesort of log, not sure how useful, get IPMIscreencap.7z :
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170270/+attachment/6008530/+files/IPMIscreencap.7z

More info on comment 3:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170270/comments/3

Egon O.

> > Hello, Real human writing, not AI here ;)
> 
> Good to know such can still happen.
> 
> > #### Problem:
> >
> > Booting Xen hypervisor with Linux Dom0.
> > GRUB loads, Xen kernel messages load up to "Using 6 CPU"
> >
> > # From this point:
> > Next screen goes black and stays blank for 10+minutes.
> > Have to force reboot and choose non XEN kernel booting option via GRUB.
> >
> > # From this point expected behaviour without bug:
> > Next screen goes black and stays so for 30-70sec and Dom0 kernel messages 
> > appear,
> > Next login is possible and system is running, "xl info" and other xl 
> > commands function.
> >
> > #### Cause:
> > I spent 2 days rebooting to narrow this down..
> >
> > This happens if we set both settings same time:
> > NVME io polling and XEN kernel CPU limits, via default grub configs:
> >
> > GRUB_CMDLINE_LINUX_DEFAULT="nvme.poll_queues=24"
> >
> > # Can also be set via /mnt/oldroot/etc/modprobe.d/nvme.conf
> > # For proper polling setup nvme.io_poll=1 should also be set,
> > # but symptom already appears if we set only nvme.poll_queues=24
> >
> > and
> >
> > GRUB_CMDLINE_XEN_DEFAULT="dom0_max_vcpus=6 dom0_vcpus_pin"
> 
> Did you isolate which of the two options it actually is that causes the
> problem, or whether it needs to be both together? Also, is 6 a necessary
> (exact) precondition to the issue occurring?
> 
> > Sadly not my personal system, so I can not do further heavy testing on it.
> > io polling does give very good performance boost to Gen5 NVME, and even 
> > Gen4.
> > Sad we cant use it, as CPU pinning is more important for XEN hypervizor 
> > system.
> >
> > This has been also reported to launchpad.net:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170270
> 
> As was meanwhile also indicated in that report: What's completely missing
> here, but very likely necessary for further analysis, are logs. That may
> also help establishing whether it's the kernel (driver) that's hung, or
> whether the system as a whole (i.e. Xen) is stuck. If nothing else in the
> log has any indication either way, issuing a debug key (for starters just
> 'h', later maybe others) may help telling one from the other. If issuing
> debug keys isn't possible anymore, try adding "watchdog" to the Xen
> command line.
> 
> Jan
>



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.