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/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 39 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
blkback making assumptions about the id of the requests
Hello,
While playing with driver domains using FreeBSD I've found out that
blkback in FreeBSD makes assumptions about the id of a request instead
of actually using the id of the request on the shared ring. This seems
wrong to me, since a frontend might choose whatever ids it like for the
requests (like using 100-131 instead of 0-31). The patch attached fixes
it by copying the id from the request on the ring to blkback internal
request structure.
Roger.
From 01c3edc4446b113ec85537bb75c56c6072c4ee49 Mon Sep 17 00:00:00 2001
From: Roger Pau Monne roger@citrix.com
Date: Mon, 2 Sep 2013 15:51:47 +0200
Subject: [PATCH] xen-blkback: don't make assumptions about request ids
Blkback makes assumptions about the id of the request it received
from the frontend, this patch fixes it by always honoring the
id passed from the frontend instead of assuming there's an implicit
order in the id of the requests.
---
sys/dev/xen/blkback/blkback.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sys/dev/xen/blkback/blkback.c b/sys/dev/xen/blkback/blkback.c
index 2a220c4..500b347 100644
--- a/sys/dev/xen/blkback/blkback.c
+++ b/sys/dev/xen/blkback/blkback.c
@@ -1239,6 +1239,7 @@ xbb_get_resources(struct xbb_softc *xbb, struct
xbb_xen_reqlist **reqlist,
nreq-reqlist = *reqlist;
nreq-req_ring_idx = ring_idx;
+ nreq-id = ring_req-id;
if (xbb-abi != BLKIF_PROTOCOL_NATIVE) {
bcopy(ring_req, nreq-ring_req_storage, sizeof(*ring_req));
--
1.7.7.5 (Apple Git-26)
___
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: blkback making assumptions about the id of the requests
On Sep 2, 2013, at 11:58 AM, Roger Pau Monné roger@citrix.com wrote: Hello, While playing with driver domains using FreeBSD I've found out that blkback in FreeBSD makes assumptions about the id of a request instead of actually using the id of the request on the shared ring. This seems wrong to me, since a frontend might choose whatever ids it like for the requests (like using 100-131 instead of 0-31). The patch attached fixes it by copying the id from the request on the ring to blkback internal request structure. Roger. It looks to me like the id is set in xbb_dispatch_io(). Why it is done there and not earlier, I don't recall. -- Justin ___ 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
[CFR] Xen IPI patch
In my continuing effort to get all of Roger's Xen enhancements into FreeBSD, I'm just about finished reviewing the next patch in his series. The current status of the patch can be found here: http://people.freebsd.org/~gibbs/xen_ipi.diff The main, and late breaking, wrinkle for this patch is the newly committed PCID support form AMD64. I've done my best to translate the updated assembly IPI handlers into the C equivalents needed for Xen. But, I'm by no means an x86 assembly expert, and my current Xen installation doesn't advertise PCID, so all of the new branches I've added have yet to be tested. I also wonder if PVHVM guests are supposed to perform the PCID work natively or use some other Hypervisor functionality. Other things I'm not happy about with the patch: - hvm.c wants to use invltlb_globpcid(), but it is private to pmap.c. I've moved it to cpufunc.h to be next to invltlb(), but the definition of CR4_PGE (from specialreg.h) isn't visible in all of the contexts that include cpufunc.h. So I hackishly define it if necessary. Ick. - With the divergence of IPI handling between i386 and amd64, x86/xen/hvm.c is growing too many ifdefs. Should we delegate the definitions of the ipi functions to amd64/xen/hvm.c and i386/xen/hvm.c? - There's too much code duplication in xen_invlrng() and some of the logic in the other handlers can probably be tightened up. Unfortunately, I'm out of time for tonight. Hopefully the list will have some great suggestions/fixes/improvements for this patch before I pick it up again tomorrow. Thanks, Justin ___ 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
