Port-xen archive

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

Re: trouble running FreeBSD with Xen-4.11 (including weird performance issues)



So further to the apparent FreeBSD xbd(4) problems, I've also got a
performance mystery.

I have to machines that are quite similar, but from slightly different
hardware generations, a Dell R510, and a Dell PE2950.

They're both running NetBSD-current/amd64 9.99.81 with
xenkernel411-4.11.4nb6 (though each built their own code).

I've copied the same FreeBSD 12.2-p4 kernel and ISO image files and
xl.cfg file to each machine.

One (the R510) boots a domU and runs at what seems to be "normal" speed.
This first machine is also running three other domUs.  Xl reports it
using about 34s CPU time to get to the installer terminal type prompt.

The other (the PE2950) boots a domU that seems to spin in the FreeBSD
kernel and chew up absolutely enormous amounts of time.  This server is
running just the subject domU.  Xl says this one takes upwards of 1300
seconds of CPU time to get to the terminal type prompt!  Hitting ^T
during the startup (i.e. after /etc/rc starts) shows most of the time is
spent in the kernel, e.g.:

load: 1.24  cmd: rcorder 32 [running] 12.58r 0.95u 9.35s 73% 1284k

The only difference in the console output on both has to do with the
minor hardware, and especially CPU, differences.


What the possible heck can be going on here!?!?!

How can I debug this?


Also (and this is common to both systems, so is an underlying FreeBSD
issue I guess) if I'm not careful what/when I type something to the
installer (e.g. hit the right-arrow key at the wrong time) it seems to
think it's done and hints are that the system tries to go multiuser, but
it doesn't get very far before it comes to a grinding halt and will not
respond at all (though it continues to use tiny amounts of CPU according
to "xl list").

	Updating motd: /etc/motd is not writable, update failed.
	Mounting late filesystems:.
	Updating /var/run/os-release done.
	Starting cron.
	Starting background file system checks in 60 seconds.

	Thu Mar 18 22:49:32 UTC 2021

Sending a virtual NMI via "xl trigger fbsd-test nmi" will properly panic
the system, but it doesn't actually do a nice kernel backtrace so I
don't know where it's stuck:

	timeout stopping cpus
	panic: NMI indicates hardware failure
	cpuid = 0
	time = 1616107272
	KDB: stack backtrace:
	Uptime: 12m40s
	Automatic reboot in 15 seconds - press a key on the console to abort
	--> Press a key on the console to reboot,
	--> or switch off the system now.
	Rebooting...
	cpu_reset: Stopping other CPUs
	timeout stopping cpus
	No known reset method worked, attempting CPU shutdown

--
					Greg A. Woods <gwoods%acm.org@localhost>

Kelowna, BC     +1 250 762-7675           RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost>     Avoncote Farms <woods%avoncote.ca@localhost>

Attachment: pgpq8RkAllRGJ.pgp
Description: OpenPGP Digital Signature



Home | Main Index | Thread Index | Old Index