issue with xnf running 15th jan snapshot on Xen v. 4.5.1
Hi! I read a news today about Xen being enabled and tried it out with the Jan 15th snapshot SHA256 (install59.iso) = 8d16aeb686a1dcc3ce6e8c5192f8708d3878f7690429c843176c5e755386e4f9 on Xen v. 4.5.1 compiled from Xen sources on Debian v. 8 Jessie running on an ordinary amd64 Intel platform. (Actually i am using this very Xen platform to run my workstation as another virtual guest, so platform itselt is running solid.) I booted it with # cat openbsd.cfg builder = "hvm" name = "openbsd" memory = "512" vcpus = 1 vif = [ 'mac=00:16:3e:79:22:22,bridge=xenbr0' ] disk = [ 'phy:/dev/vg_data_wd_1tb/openbsd,hda,w', 'file:/tmp/install59.iso-20160115-ss.iso,hdd:cdrom,r'] boot="dc" vnc=1 then connected with VNC and installed OpenBSD S.S. It boots afterwards ok and when configuring xnf0 network device with ifconfig xnf0 192.168.10.128 (or with dhclient) i can ping it from outside and it seems to work forever. Also i can see other lan packets passing by xnf0 with tcpdump. But when i connect from outside say with ssh client then it hangs (i.e. cant enter anything from vnc window, created simple cronjob within OpenBSD and i see it stops updateing log file etc). While connecting i see this traffic on dom0 root@moraal-dom0:/etc/xen# tcpdump -ni vif43.0 host 192.168.10.128 19:55:05.985258 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [S], seq 3673277459, win 29200, options [mss 1460,sackOK,TS val 40346540 ecr 0,nop,wscale 7], length 0 19:55:05.985611 IP 192.168.10.128.22 > 192.168.10.10.33616: Flags [S.], seq 3141065115, ack 3673277460, win 16384, options [mss 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,TS val 345100460 ecr 40346540], length 0 19:55:05.986017 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [.], ack 1, win 229, options [nop,nop,TS val 40346540 ecr 345100460], length 0 19:55:05.987116 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq 1:33, ack 1, win 229, options [nop,nop,TS val 40346541 ecr 345100460], length 32 19:55:06.012874 IP 192.168.10.128.22 > 192.168.10.10.33616: Flags [P.], seq 1:22, ack 33, win 2168, options [nop,nop,TS val 345100460 ecr 40346541], length 21 19:55:06.013151 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [.], ack 22, win 229, options [nop,nop,TS val 40346547 ecr 345100460], length 0 19:55:06.022554 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [.], seq 33:1481, ack 22, win 229, options [nop,nop,TS val 40346549 ecr 345100460], length 1448 19:55:06.022562 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq 1481:2001, ack 22, win 229, options [nop,nop,TS val 40346549 ecr 345100460], length 520 19:55:06.023068 IP 192.168.10.128.22 > 192.168.10.10.33616: Flags [.], ack 2001, win 1926, options [nop,nop,TS val 345100460 ecr 40346549], length 0 19:55:06.023416 IP 192.168.10.128.22 > 192.168.10.10.33616: Flags [P.], seq 22:998, ack 2001, win 1926, options [nop,nop,TS val 345100460 ecr 40346549], length 976 19:55:06.026537 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq 2001:2049, ack 998, win 244, options [nop,nop,TS val 40346550 ecr 345100460], length 48 19:55:06.226645 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq 2001:2049, ack 998, win 244, options [nop,nop,TS val 40346601 ecr 345100460], length 48 19:55:06.430626 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq 2001:2049, ack 998, win 244, options [nop,nop,TS val 40346652 ecr 345100460], length 48 19:55:06.838658 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq 2001:2049, ack 998, win 244, options [nop,nop,TS val 40346754 ecr 345100460], length 48 19:55:07.654663 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq 2001:2049, ack 998, win 244, options [nop,nop,TS val 40346958 ecr 345100460], length 48 19:55:09.290635 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq 2001:2049, ack 998, win 244, options [nop,nop,TS val 40347367 ecr 345100460], length 48 19:55:12.558753 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq 2001:2049, ack 998, win 244, options [nop,nop,TS val 40348184 ecr 345100460], length 48 19:55:19.102779 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq 2001:2049, ack 998, win 244, options [nop,nop,TS val 40349820 ecr 345100460], length 48 19:55:32.174732 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq 2001:2049, ack 998, win 244, options [nop,nop,TS val 40353088 ecr 345100460], length 48 19:55:58.350805 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq 2001:2049, ack 998, win 244, options [nop,nop,TS val 40359632 ecr 345100460], length 48 . Xen logs dont say much, what i can see approx. 1 minute after hang is guest rx stalled [1897100.139144] vif vif-43-0 vif43.0: Guest Rx ready ... [1897216.889975] vif vif-43-0 vif43.0: Guest Rx stalled I am using Open vSwitch on Xen dom0 with quite simple configuration, xenbr0 being OVS switch. Interestingly, when i use PCI passthru network device instead of vif device, all
Re: issue with xnf running 15th jan snapshot on Xen v. 4.5.1
Hi, Thanks for taking your time to test and write a report. I've fixed a few issues since then and was going to ask you to test a -current kernel. Could you also please send bug reports like this to bugs@ rather than misc@. Thank you! Cheers, Mike On Sat, Jan 16, 2016 at 20:56 +0200, Imre Oolberg wrote: > Hi! > > I read a news today about Xen being enabled and tried it out with the Jan > 15th snapshot > > SHA256 (install59.iso) = > 8d16aeb686a1dcc3ce6e8c5192f8708d3878f7690429c843176c5e755386e4f9 > > on Xen v. 4.5.1 compiled from Xen sources on Debian v. 8 Jessie running on > an ordinary amd64 Intel platform. (Actually i am using this very Xen > platform to run my workstation as another virtual guest, so platform itselt > is running solid.) > > I booted it with > > # cat openbsd.cfg > builder = "hvm" > name = "openbsd" > memory = "512" > vcpus = 1 > vif = [ 'mac=00:16:3e:79:22:22,bridge=xenbr0' ] > disk = [ 'phy:/dev/vg_data_wd_1tb/openbsd,hda,w', > 'file:/tmp/install59.iso-20160115-ss.iso,hdd:cdrom,r'] > > boot="dc" > vnc=1 > > then connected with VNC and installed OpenBSD S.S. > > It boots afterwards ok and when configuring xnf0 network device with > ifconfig xnf0 192.168.10.128 (or with dhclient) i can ping it from outside > and it seems to work forever. Also i can see other lan packets passing by > xnf0 with tcpdump. But when i connect from outside say with ssh client then > it hangs (i.e. cant enter anything from vnc window, created simple cronjob > within OpenBSD and i see it stops updateing log file etc). While connecting > i see this traffic on dom0 > > root@moraal-dom0:/etc/xen# tcpdump -ni vif43.0 host 192.168.10.128 > > 19:55:05.985258 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [S], seq > 3673277459, win 29200, options [mss 1460,sackOK,TS val 40346540 ecr > 0,nop,wscale 7], length 0 > 19:55:05.985611 IP 192.168.10.128.22 > 192.168.10.10.33616: Flags [S.], seq > 3141065115, ack 3673277460, win 16384, options [mss > 1460,nop,nop,sackOK,nop,wscale 3,nop,nop,TS val 345100460 ecr 40346540], > length 0 > 19:55:05.986017 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [.], ack > 1, win 229, options [nop,nop,TS val 40346540 ecr 345100460], length 0 > 19:55:05.987116 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq > 1:33, ack 1, win 229, options [nop,nop,TS val 40346541 ecr 345100460], > length 32 > 19:55:06.012874 IP 192.168.10.128.22 > 192.168.10.10.33616: Flags [P.], seq > 1:22, ack 33, win 2168, options [nop,nop,TS val 345100460 ecr 40346541], > length 21 > 19:55:06.013151 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [.], ack > 22, win 229, options [nop,nop,TS val 40346547 ecr 345100460], length 0 > 19:55:06.022554 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [.], seq > 33:1481, ack 22, win 229, options [nop,nop,TS val 40346549 ecr 345100460], > length 1448 > 19:55:06.022562 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq > 1481:2001, ack 22, win 229, options [nop,nop,TS val 40346549 ecr 345100460], > length 520 > 19:55:06.023068 IP 192.168.10.128.22 > 192.168.10.10.33616: Flags [.], ack > 2001, win 1926, options [nop,nop,TS val 345100460 ecr 40346549], length 0 > 19:55:06.023416 IP 192.168.10.128.22 > 192.168.10.10.33616: Flags [P.], seq > 22:998, ack 2001, win 1926, options [nop,nop,TS val 345100460 ecr 40346549], > length 976 > 19:55:06.026537 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq > 2001:2049, ack 998, win 244, options [nop,nop,TS val 40346550 ecr > 345100460], length 48 > 19:55:06.226645 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq > 2001:2049, ack 998, win 244, options [nop,nop,TS val 40346601 ecr > 345100460], length 48 > 19:55:06.430626 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq > 2001:2049, ack 998, win 244, options [nop,nop,TS val 40346652 ecr > 345100460], length 48 > 19:55:06.838658 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq > 2001:2049, ack 998, win 244, options [nop,nop,TS val 40346754 ecr > 345100460], length 48 > 19:55:07.654663 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq > 2001:2049, ack 998, win 244, options [nop,nop,TS val 40346958 ecr > 345100460], length 48 > 19:55:09.290635 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq > 2001:2049, ack 998, win 244, options [nop,nop,TS val 40347367 ecr > 345100460], length 48 > 19:55:12.558753 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq > 2001:2049, ack 998, win 244, options [nop,nop,TS val 40348184 ecr > 345100460], length 48 > 19:55:19.102779 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq > 2001:2049, ack 998, win 244, options [nop,nop,TS val 40349820 ecr > 345100460], length 48 > 19:55:32.174732 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq > 2001:2049, ack 998, win 244, options [nop,nop,TS val 40353088 ecr > 345100460], length 48 > 19:55:58.350805 IP 192.168.10.10.33616 > 192.168.10.128.22: Flags [P.], seq > 2001:2049, ack 998, win 244, option
Re: issue with xnf running 15th jan snapshot on Xen v. 4.5.1
Hi! I write here for the record so possible arvhive readers know that this thread ended in couple of private emails with developer and he fixed this problem. Short version and what i can narrate is that i used GENERIC i.e. single cpu kernel and my situation was specific to this kernel. Had i used GENERIC.MP i would have not noticed it. Now i happily run OpenBSD on Xen too, .MP or not .MP, thanks! Imre On 2016-01-19 19:48, Mike Belopuhov wrote: Hi, Thanks for taking your time to test and write a report. I've fixed a few issues since then and was going to ask you to test a -current kernel. Could you also please send bug reports like this to bugs@ rather than misc@. Thank you! Cheers, Mike