Re: Xen PV Networking issue - disable PV NIC in XENHVM FreeBSD?
--On 11 February 2014 18:20 +0100 Roger Pau Monné roger@citrix.com wrote: You could try to disable the following: ifconfig xnX -rxcsum -txcsum -tso4 -lro As a follow-up to this, using: ifconfig xnX -rxcsum -txcsum Does actually fix the problem. I finally got a block of time to go through all this stuff again the other day [it's amazing what difference actually having a decent chunk of uninterrupted time makes!] You do need to be careful when setting this - as at one point, it seemed to cause some kind of issue that may have flooded the network (if it did - this would be the second time we've seen a XenServer DomU flood things by jabbering the same packet over, and over). -Karl ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Current problem reports assigned to freebsd-xen@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/183139 xen[xen] [patch] ifconfig options on xn0 lost after xen v o kern/180788 xen[xen] [panic] XEN PV kernel 9.2-BETA1 panics on boot o kern/180403 xen[xen] Problems with GENERIC and XENHVM kernels with Xe o kern/180402 xen[xen] XEN kernel does not load in XenClient 4.5.5 o kern/179814 xen[xen] mountroot fails with error=19 under Xen on 9-STA o kern/176471 xen[xen] xn driver crash on detach o kern/176053 xen[xen] [patch] i386: Correct wrong usage of vsnprintf() o kern/175954 xen[xen] XENHVM xn network driver extreme packet loss dur o kern/175822 xen[xen] FreeBSD 9.1 does not work with Xen 4.0 o kern/175757 xen[xen] [patch] xen pvhvm looses keyboard input from VNC o kern/171873 xen[xen] xn network device floods warning in dmesg o kern/171118 xen[xen] FreeBSD XENHVM guest doesn't shutdown cleanly o kern/166174 xen[xen] Problems ROOT MOUNT ERROR freebsd 8.3 o kern/165418 xen[xen] Problems mounting root filesystem from XENHVM o kern/164630 xen[xen] XEN HVM kernel: run_interrupt_driven_hooks: stil o kern/164450 xen[xen] Failed to install FreeeBSD 9.0-RELEASE from CD i o kern/162677 xen[xen] FreeBSD not compatible with Current Stable Xen o kern/161318 xen[xen] sysinstall crashes with floating point exception o kern/155468 xen[xen] Xen PV i386 multi-kernel CPU system is not worki o kern/155353 xen[xen] [patch] put nudging TOD message under boot_ver o kern/154833 xen[xen]: xen 4.0 - DomU freebsd8.2RC3 i386, XEN kernel. o kern/154473 xen[xen] xen 4.0 - DomU freebsd8.1 i386, XEN kernel. Not o kern/154472 xen[xen] xen 4.0 - DomU freebsd8.1 i386 xen kernel reboot o kern/154428 xen[xen] xn0 network interface and PF - Massive performan o kern/153674 xen[xen] i386/XEN idle thread shows wrong percentages o kern/153672 xen[xen] [panic] i386/XEN panics under heavy fork load o kern/153620 xen[xen] Xen guest system clock drifts in AWS EC2 (FreeBS o kern/153477 xen[xen] XEN pmap code abuses vm page queue lock o kern/153150 xen[xen] xen/ec2: disable checksum offloading on interfac o kern/152228 xen[xen] [panic] Xen/PV panic with machdep.idle_mwait=1 o kern/144629 xen[xen] FreeBSD 8-RELEASE XEN pvm networking doesn't wor o kern/143398 xen[xen] FreeBSD 8-RELEASE XEN pvm networking doesn't wor o kern/143340 xen[xen] FreeBSD 8-RELEASE XEN pvm networking doesn't wor f kern/143069 xen[xen] [panic] Xen Kernel Panic - Memory modified after f kern/135667 xenufs filesystem corruption on XEN DomU system f kern/135421 xen[xen] FreeBSD Xen PVM DomU network failure - netfronc. f kern/135178 xen[xen] Xen domU outgoing data transfer stall when TSO i p kern/135069 xen[xen] FreeBSD-current/Xen SMP doesn't function at all f i386/124516 xen[xen] FreeBSD-CURRENT Xen Kernel Segfaults when config o kern/118734 xen[xen] FreeBSD 6.3-RC1 and FreeBSD 7.0-BETA 4 fail to b 40 problems total. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: FreeBSD 10-R 8 vCPU panics at boot under XenServer (on 8 'core' CPU)
On 17/02/14 15:44, Karl Pielorz wrote: Hi, I've got a FreeBSD 10-R amd64 DomU guest I'm using under XenServer 6.2 (SP1) - this was working fine (i.e. had been restarted many times - while I look at things like HAST). I noticed the other day it was only set to use 4 vCPU's - so I increased this to 8 (the machine has an 4 Core, 8 Thread Xeon 1230v3 in it - which Xen see's as 8 CPU cores). However, it won't boot reliably now: ... SMP: AP CPU #5 Launched panic: can't schedule timer cpuid = 0 KDB: stack backtrace: #0 0x808e7dd0 at kdb_backtrace+0x60 #1 0x808af8b5 at panic+0x155 #2 0x807a14dd at xentimer_et_start+0xed #3 0x80d66d6d at loadtimer+0xfd #4 0x80d657fd at handleevents+0x308 #5 0x80d65fc8 at timercb+0x308 #6 0x807a152d at xentimer_intr+0x4d #7 0x80883e5b at intr_event_handle+0x9b ... Less than 8 vCPU's seems to boot OK (e.g. 7) and 8 vCPU's has booted a couple of times (out of 30+ reboots). I usually do most of my testing on a Xen W3550 (8-ways), with a 8 vCPU guest, and I've never seen this crash before. I've even booted a 12 vCPU guest on this 8-way system, and it was fine. How many guests are you running on this host, and how many vCPUs has each one assigned? The system is running GENERIC with: options NO_ADAPTIVE_MUTEXES options NO_ADAPTIVE_RWLOCKS options NO_ADAPTIVE_SX In addition XenServer is set to pass through the bare machine's LSI and two Intel NIC's (which it does - and are working, once FreeBSD is booted). I don't think those modifications have any effect on the timer, but could you try to recompile without the NO_ADAPTIE_* modifications and without any device pass-through? In order to provide more debug info, could you apply the following patch: http://xenbits.xen.org/people/royger/0001-xen-debug-Xen-PV-timer.patch It will expand the panic message a little bit. Also, after applying the patch you can manually edit sys/dev/xen/timer/timer.c and increase NUM_RETRIES to see if that solves the problem. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: [Xen-devel] [PATCH RFC 09/13] xen: change quality of the MADT ACPI enumerator
On 14/02/14 18:51, John Baldwin wrote: On Thursday, February 13, 2014 8:49:24 pm Andrew Cooper wrote: On 08/02/2014 21:42, John Baldwin wrote: On Tuesday, December 24, 2013 12:20:58 PM Roger Pau Monne wrote: Lower the quality of the MADT ACPI enumerator, so on Xen Dom0 we can force the usage of the Xen mptable enumerator even when ACPI is detected. Hmm, so I think one question is why does the existing MADT parser not work with the MADT table provided by Xen? This may very well be correct, but if it's only a small change to make the existing MADT parser work with Xen's MADT table, that route might be preferable. For dom0, the MADT seen is the system MADT, which does not bear any reality to dom0's topology. For PV domU, no MADT will be found. For HVM domU, the MADT seen ought to represent (virtual) reality. Hmm, the other changes suggested that you do want to use the I/O APIC entries and interrupt overrides from the system MADT for dom0? Just not the CPU entries. Is that correct? Yes, we need the interrupt entries in order to interact with the underlying hardware, but not the CPU entries/topology. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: FreeBSD 10-R 8 vCPU panics at boot under XenServer (on 8 'core' CPU)
--On 17 February 2014 16:56 +0100 Roger Pau Monné roger@citrix.com wrote: How many guests are you running on this host, and how many vCPUs has each one assigned? Only 1 active guest (the FreeBSD one) - there are others on there, but they're not running (so I'm hoping they don't count? :) I don't think those modifications have any effect on the timer, but could you try to recompile without the NO_ADAPTIE_* modifications and without any device pass-through? Removed the NO_ADAPTIVE_ stuff from the Kernel - I'll have to do the PCI passthrough removes later. In order to provide more debug info, could you apply the following patch: http://xenbits.xen.org/people/royger/0001-xen-debug-Xen-PV-timer.patch It will expand the panic message a little bit. Also, after applying the patch you can manually edit sys/dev/xen/timer/timer.c and increase NUM_RETRIES to see if that solves the problem. Ok, with that patch applied, removing the NO_ADAPTIVE_* (but like I said - still with the PCI passthroughs in place) I get: panic: can't schedule timer on vCPU#0, interval: 112847ns I'll increase NUM_TRIES, try that - then remove the PCI passthrough devices and give that ago - that'll have to do those in a bit, and post when done. Thanks, -Karl ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
Re: FreeBSD 10-R 8 vCPU panics at boot under XenServer (on 8 'core' CPU)
--On 17 February 2014 16:56:14 +0100 Roger Pau Monné roger@citrix.com wrote: In order to provide more debug info, could you apply the following patch: http://xenbits.xen.org/people/royger/0001-xen-debug-Xen-PV-timer.patch It will expand the panic message a little bit. Also, after applying the patch you can manually edit sys/dev/xen/timer/timer.c and increase NUM_RETRIES to see if that solves the problem. Ok, tried adjusting the NUM_RETRIES #define in that patch (I left the PCI passthroughs in place at the moment). I had no idea what to set it to - so I went for 600. With it set at 600 that same guest now boots Ok now every time I've tried. But I did notice the whole 'SMP AP CPU #x Launched!' takes forever, and varies a lot (e.g. one boot it took nearly 2 minutes to launch all CPU's and continue). I removed the PCI passthroughs on that guest, and it now flies through the AP launches. Unfortunately though I need the passthroughs :( I've passed through the onboard LSI 2308 SAS controller (mps), and a dual port PCI-E Intel NIC (igb) - all the passthroughs work on FreeBSD once it's booted - but obviously, not without causing the slow AP CPU launches. I also remembered I set 'hw.pci.enable_msi=1' and 'hw.pci.enable_msix=0' in /etc/sysctl.conf - someone else found that was necessary to use the LSI in passthrough mode. Aside from the slow launches, do you think (as they work) it's going to cause issues leaving those passthroughs active? Thanks, -Karl ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org
