Re: xn ethernet issues as DOMU under NetBSD DOM0
See this PR from 2014 --> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188369 (there another earlier about the same error message on 9.X and that was fixed on 10-CURRENT at the time, but was "broke" later) The issue happen with any NetBSD version from 5.x to 7.x with any xen version but it only stared in FreeBSD 10-Current, so I was always inclined to this being a regression in 10 not a NetBSD backend issue. Also I did post in netbsd mailling list and the reply was something in the lines of "was working fine, nothing changed at our side, so its probably FreeBSD problem" Also as I posted in that PR I experienced a similar issue with Windows GPLPV drivers and the dev fixed it, the issue was that certain features were not supported and the frontend just assume they were cause that's how it works on linux, and I'm no expert so I can go into much detail, but it was related to checksum, tso and I think gso. I tried to bisect the git commits, but there was simply to much changes, what I did find was that this never worked on 10.x +++ only 9, anyway everything was reported there and eventually I got no replies back so I gave up on NetBSD+FreeBSD-10. Unfortunately this needs someone with proper skills on either side (netbsd/freeBSD) to be fixed, the perfect solution would be to add NetBSD backend support for this things (just not sure if its worth the time for the possible performance gain!? - also that's a question for the NetBSD folks ofc) ___ freebsd-xen@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: xn ethernet issues as DOMU under NetBSD DOM0
I've only gotten two emails on this, so forgive me if this has been discussed. On Sat, May 07, 2016 at 04:11:52PM +, Stephen Jones wrote: > From: kmacy...@gmail.com [mailto:kmacy...@gmail.com] On Behalf Of K. Macy > >That would explain it. If the Linux backend supports TSO, then netfront will > >of course advertise TSO. And >presumably there's no way to query the > >netback, since Xen is linux-centric. Assuming you haven't already I would > >>disable TSO. > > > Or have you already tried that? > > This morning I've tried building a kernel without the TCP_OFFLOAD option. > When booting the new system, I see this in dmesg: > > xn0: at device/vif/0 on xenbusb_front0 > xn0: Ethernet address: 00:16:3e:00:00:30 > xn0: backend features: feature-sg feature-gso-tcp4 > xn_txeof: WARNING: response is -1! > This means the backend returns -1 for the tx request, but -1 is just a general error code so it doesn't reveal much. It would be interesting to see if there is anything shown on the backend side -- if netbsd's netback logs something. > Ifconfig -v xn0 looks like: > > xn0: flags=8843 metric 0 mtu 1500 > options=403 > > Pings work, ftp works (I was able to get the src.txz file off of > ftp.freebsd.org to build the kernel) > ssh does not work (handshaking fails) but I can login via telnet. However, > just about anything > that requires lots of output gets a bit clobbered. > > Are there any other kernel/sysctl parameters I should be disabling? > > It is almost working, but I need help to know if this is a netfront or a > netback issue. If it is a NetBSD issue > I'll move the discussion over to port-...@netbsd.org I think what you can do is to try the same kernel with a Linux backend. That would be a good way of telling which side is at fault. Wei. ___ freebsd-xen@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[Bug 209327] Under XenServer 6.5 - Live Migration results in a Kernel Panic when the VM 'Lands' on the other Node
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209327 Roger Pau Monné changed: What|Removed |Added Status|New |In Progress Assignee|freebsd-xen@FreeBSD.org |roy...@freebsd.org --- Comment #5 from Roger Pau Monné --- Created attachment 170177 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=170177&action=edit Proposed fix Could you also try the following patch on a VM with vCPUs > 1? It should apply cleanly against either 10.3-RELEASE source or the stable/10 branch, and you should only need to recompile the kernel. FWIW, I would just download 10.3 sources, apply the patch and recompile the kernel. Thanks. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-xen@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[Bug 209327] Under XenServer 6.5 - Live Migration results in a Kernel Panic when the VM 'Lands' on the other Node
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209327 --- Comment #4 from Roger Pau Monné --- (In reply to kpielorz from comment #3) That's even more weird. Could it be that the VM with local storage only has 1 vCPU, while the VMs with shared storage have more than 1 vCPU? Could you try to migrate a VM with only 1 vCPU and see if the same happens? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-xen@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[Bug 209327] Under XenServer 6.5 - Live Migration results in a Kernel Panic when the VM 'Lands' on the other Node
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209327 --- Comment #3 from kpiel...@tdx.co.uk --- Hi, In your test - did you use shared storage? Having looked at this yesterday, and this morning - I tried setting up a completely separate pool - and found: - Live migration with local storage in XenCenter Works. - Live migration with shared (iSCSI) storage panics. - Live migration from shared (iSCSI) to local storage panics. - Live migration from local storage to shared (iSCSI) panics. All of the above complete fine with FreeBSD 10.2. I've also tested this on both our production XenServer 6.5 / HP Proliant Gen8 pool - and test 6.5 / Proliant Gen9 pool - with the same results. I don't know if your test used shared, or local storage. -Karl -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-xen@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[Bug 188261] [xen] FreeBSD DomU PVHVM guests cannot 'route' traffic for other Xen PV guests on same Dom0 Host.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188261 --- Comment #13 from Andreas Pflug --- Yes, only Linux Dom0. I've only seen one anomaly with offloading, which was fixed in Windows PVM drivers a long time ago, so I assume that there's something in FreeBSD Dom0 that's disguising the bug. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-xen@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
