Hi, i try to save a running opensolaris-2008.05(snv86) HVM 32-bit DomU with xen3.2-testing (3 days old, fedoracore8-Dom0), but the saving will never ends (means hang). ... /var/log/xen/xend.log [2008-05-24 19:52:33 20386] DEBUG (XendCheckpoint:89) [xc_save]: /usr/lib64/xen/bin/xc_save 40 61 0 0 4 [2008-05-24 19:52:33 20386] DEBUG (XendCheckpoint:334) suspend [2008-05-24 19:52:33 20386] DEBUG (XendCheckpoint:92) In saveInputHandler suspend [2008-05-24 19:52:33 20386] DEBUG (XendCheckpoint:94) Suspending 61 ... [2008-05-24 19:52:33 20386] DEBUG (XendDomainInfo:467) XendDomainInfo.shutdown(suspend) [2008-05-24 19:52:33 20386] DEBUG (XendDomainInfo:1092) XendDomainInfo.handleShutdownWatch .. nothing more [root@xen04 /var/log/xen]$ xm list Name ID Mem VCPUs State Time(s) Domain-0 0 512 8 r----- 3026.1 migrating-soalris-snv86 61 384 1 -b---- 59.6 but the machine runs in a normal way (can login ,...) The save file shows only the DomU information, but no suspend-data: [root@xen04 ~]$ ls -la save -rwxr-xr-x 1 root root 1150 2008-05-24 19:52 save [root@xen04 ~]$ cat save LinuxGuestRecord^@^@^Dj(domain (domid 61) (on_crash destroy) (uuid 75594019-ba80-5a8e-cd9f-18eb2bc8aa43) (bootloader_args ) (vcpus 1) (name soalris-snv86) (on_poweroff destroy) (on_reboot restart) (bootloader ) (maxmem 384) (memory 384) (shadow_memory 4) (vcpu_avail 1) (features ) (on_xend_start ignore) (on_xend_stop ignore) (start_time 1211651473.35) (cpu_time 31.480495173) (online_vcpus 1) (image (hvm (kernel /usr/lib/xen/boot/hvmloader) (acpi 1) (apic 1) (boot c) (device_model /usr/lib64/xen/bin/qemu-dm) (pae 1) (serial pty) (usb 1) (usbdevice tablet) (notes (SUSPEND_CANCEL 1)))) (status 2) (state r-----) (store_mfn ''98302'') (device (vif (bridge xenbr) (mac 00:16:3e:15:9a:77) (script vif-bridge) (uuid 03844ac5-0b50-b8fa-26ad-9bb42cab1e21) (backend 0))) (device (vbd (uname phy:/tmp/VM105 65-soalris-snv86-0) (uuid 48b65f96-cedb-f48c-9a94-a0641fa1d212) (mode w) (dev hda:disk) (backend 0) (bootable 1) (VDI ))) (device (vkbd (backend 0))) (device (vfb (vncunused 1) (type vnc) (u uid e20dbd70-efd1-4a96-3aa1-aace1be8eb90) (location localhost:5900))) (device (console (protocol vt100) (location 3) (uuid ed3f6e65-24af-ff0c-ad46-109b0311c6f8)))) Other DomU-HJVM machines (ubuntu, opensuse) will save without problems .. Is this a solaris topic ? I thought, die HVM is independent of the OS ? Regards Danny from softwaredemo.de This message posted from opensolaris.org
opensolaris-2008.05 HVM at Xen 3.2.1 CentOS 5.1 Dom0 (both 64-bit) has same behavior. This message posted from opensolaris.org
Hi again, is there a way to track down this problem ? Or is there another (better ?) place to ask this question ? I would like to install and publish opensolaris-2008.05 on our live-demo softwaredemo.de plattform for public online access/testing. But for publishing, the "xm save/restore" commands must work... regards Danny This message posted from opensolaris.org
Daniel Schwager wrote:> i try to save a running opensolaris-2008.05(snv86) > HVM 32-bit DomU with xen3.2-testing (3 days old, > fedoracore8-Dom0), > but the saving will never ends (means hang). ...Yep, I can reproduce the same xm save hang, both on an opensolaris snv_92 dom0 / xvm-3.1.4, and on xvm-gate matrix unstable dom0 / xvm-3.3-unstable. It seems that the new xpv driver in the snv86 hvm domU causes this problem. When I boot the opensolaris 2008.05 hvm domU with option "-B ..,disable-xpv=true" xm save / xm restore starts to work. OTOH, another SXCE snv_85 hvm domU that I bfu''ed to snv_91 does xm save / xm restore just fine. So this (xpv driver ?) issue might have already been fixed somewhere between snv_86 and snv_91.> Is this a solaris topic ?Yes, seems so.> I thought, that HVM is independent of the OS ?Apparently not 100% true any more, now that OpenSolaris HVM domUs can use PV drivers. This message posted from opensolaris.org
> Another SXCE snv_85 hvm domU that I > bfu''ed to snv_91 does xm save / xm restore just > fine. So this (xpv driver ?) issue might have > already been fixed somewhere between snv_86 and > snv_91.Looks like the putback for 6639790 "need Solaris PV-on-HVM migration support" (snv_88) fixed this. This message posted from opensolaris.org
Just a note, xm save/restore works for HVM SNV90 DomU at Xen 3.2.1 F8 (Dom0) (64-bit). This message posted from opensolaris.org
Great. I will install a public solaris at softwaredemo.de at the end of next week. On question more relating to PV driver - is it possible to install PV-driver for HDD and NIC to optimize performance ? Actually, i measured only 10MB/sec writeperformance in Solaris DomU - Dom0 has something about 50MB/sec. regards Danny This message posted from opensolaris.org
View:- http://www.opensolaris.org/jive/thread.jspa?threadID=61328&tstart=30 This message posted from opensolaris.org
This is in regards:- http://bugs.opensolaris.org/view_bug.do?bug_id=6699320 Per mentioned CR only SNV91 is supposed to have bug fixed. I guess this build is available only within Sun at mean time This message posted from opensolaris.org
> This is in regards:- > http://bugs.opensolaris.org/view_bug.do?bug_id=6699320 > > Per mentioned CR only SNV91 is supposed to have bug fixed. > I guess this build is available only within Sun at mean timeThe fix for 6699320 should be part of the b91 xVM source (MQ patch xen.hg/.hg/patches/enable-shadow-optimisations): http://dlc.sun.com/osol/on/downloads/b91/ You can try to build your own b91 xvm packages from that source and install them in your xvm-3.1.4 based opensolaris dom0. The xensource development version has the change, too: http://xenbits.xensource.com/xen-unstable.hg?rev/24c86abbb387 This message posted from opensolaris.org
> The fix for 6699320 should be part of the b91 xVM > source > (MQ patch > xen.hg/.hg/patches/enable-shadow-optimisations): > > http://dlc.sun.com/osol/on/downloads/b91/ > u can try to build your own b91 xvm packages from > that source > and install them in your xvm-3.1.4 based opensolaris > dom0. > > The xensource development version has the change, > too: > > > ttp://xenbits.xensource.com/xen-unstable.hg?rev/24c86a > bbb387b91 xvm package has been built successfully. However, now 1. SNV90 HVM DomU at SNV91 Dom0 generates an error at the end of DHCP configuration and may be configured only with static IP address. (Old installer - SXCE option) 2.SNV87 HVM DomU at SNV91 Dom0 may be installed in DHCP mode. (New installer still works - SXDE option) Both HVM DomUs been installed show the same performance (pretty slow). Should i bfu SNV87 HVM DomU to SNV91 to benefit from MQ patch xen.hg/.hg/patches/enable-shadow-optimisations ? This message posted from opensolaris.org
> > The fix for 6699320 should be part of the b91 xVM source > > (MQ patch xen.hg/.hg/patches/enable-shadow-optimisations): > > > > http://dlc.sun.com/osol/on/downloads/b91/ > > you can try to build your own b91 xvm packages from that source > > and install them in your xvm-3.1.4 based opensolaris > > dom0. > > > > The xensource development version has the change, too: > > > > > > http://xenbits.xensource.com/xen-unstable.hg?rev/24c86abbb387 > b91 xvm package has been built successfully. > However, now > 1. SNV90 HVM DomU at SNV91 Dom0 generates an error > at the end of DHCP configuration and may be configured > only with static IP address. (Old installer - SXCE option)There is a problem with the PV network driver xnf (bug 6703227): when it receives packets before the xnf interface is plumbed and started, subsequent packets are not seen be the guest domain. The guest''s network interface appears to be dead for several minutes, but eventually recovers. I guess, now that HVM OpenSolaris guests can use PV drivers, the same bug could hit a HVM OpenSolaris guest domain.> 2. SNV87 HVM DomU at SNV91 Dom0 may be installed in > DHCP mode. (New installer still works - SXDE option) > Both HVM DomUs been installed show the same performance (pretty slow).Are these 32 or 64-bit HVM domUs?> Should i bfu SNV87 HVM DomU to SNV91 to benefit from MQ patch > xen.hg/.hg/patches/enable-shadow-optimisations ?As far as I understand it, updating (and booting with) the new /boot/amd64/xen.gz file is enough. And you should be running a 64-bit HVM domU. This message posted from opensolaris.org
> > > The fix for 6699320 should be part of the b91 xVM > source > > > (MQ patch > xen.hg/.hg/patches/enable-shadow-optimisations): > > > > > > http://dlc.sun.com/osol/on/downloads/b91/ > > > you can try to build your own b91 xvm packages > from that source > > > and install them in your xvm-3.1.4 based > opensolaris > > > dom0. > > > > > > The xensource development version has the change, > too: > > > > > > > > > > http://xenbits.xensource.com/xen-unstable.hg?rev/24c8 > abbb387 > > b91 xvm package has been built successfully. > > However, now > > 1. SNV90 HVM DomU at SNV91 Dom0 generates an error > > at the end of DHCP configuration and may be > configured > only with static IP address. (Old installer - SXCE > option) > > There is a problem with the PV network driver xnf > (bug 6703227): > when it receives packets before the xnf interface is > plumbed and > started, subsequent packets are not seen be the guest > domain. > > The guest''s network interface appears to be dead for > several minutes, > but eventually recovers. > > I guess, now that HVM OpenSolaris guests can use PV > drivers, > the same bug could hit a HVM OpenSolaris guest > domain. > > > 2. SNV87 HVM DomU at SNV91 Dom0 may be installed > in > > DHCP mode. (New installer still works - SXDE > option) > > Both HVM DomUs been installed show the same > performance (pretty slow). > > Are these 32 or 64-bit HVM domUs?SNV87 HVM DomU at SNV91 Dom0 (both 64-bit) bash-3.2# bin/fork -E -C 200 -L -S -W -N fork_100 -B 100 -C 100 > /tmp/fork.output Running: fork_100 for 27.06514 seconds versus 35 sec for same HVM DomU at Xen 3.2.1 F8 Dom0 (both 64-bit) If fork_100 is a fair then SNV91 Dom0 should be better for SNV HVM guest. then Xen 3.2.1 F8 Dom0. I suspect "svcs -x" output cleaning up phase by some reason took longer at SNV91 Dom0 and confused me.> > > Should i bfu SNV87 HVM DomU to SNV91 to benefit > from MQ patch > > xen.hg/.hg/patches/enable-shadow-optimisations ? > > As far as I understand it, updating (and booting > with) the new > /boot/amd64/xen.gz file is enough. And you should be > running > a 64-bit HVM domU.This message posted from opensolaris.org
All Dom0s instances multi boot on the same box C2D E8400,4 GB RAM, ASUS P5K Premium/WIFI, 2x250 GB SATA drives (Seagate Barracuda). This message posted from opensolaris.org
On 12 Jun 2008, at 11:15am, Jürgen Keil wrote:> There is a problem with the PV network driver xnf (bug 6703227): > when it receives packets before the xnf interface is plumbed and > started, subsequent packets are not seen be the guest domain. > > The guest''s network interface appears to be dead for several minutes, > but eventually recovers. > > I guess, now that HVM OpenSolaris guests can use PV drivers, > the same bug could hit a HVM OpenSolaris guest domain.It does.
> There is a problem with the PV network driver xnf > (bug 6703227): > when it receives packets before the xnf interface is > plumbed and > started, subsequent packets are not seen be the guest > domain. > > The guest''s network interface appears to be dead for > several minutes, > but eventually recovers.Through my personal experience SNV PV DomU at SNV Dom0 in DHCP mode became an issue for me since i bought Zyxel P-660RT Modem acting as DHCP bridge (about end of march 2008) . The dates in CR 6703227 are surprising me. Probably i misunderstand CR 6703227. I also cannot find SNV build number against what the bug was reported. What i usually do is SNV PV DomU at Linux Dom0 in DHCP mode and it worked and works with no problems.> > I guess, now that HVM OpenSolaris guests can use PV > drivers, > the same bug could hit a HVM OpenSolaris guest > domain. > > > 2. SNV87 HVM DomU at SNV91 Dom0 may be installed > in > > DHCP mode. (New installer still works - SXDE > option) > > Both HVM DomUs been installed show the same > performance (pretty slow). > > Are these 32 or 64-bit HVM domUs? > > > Should i bfu SNV87 HVM DomU to SNV91 to benefit > from MQ patch > > xen.hg/.hg/patches/enable-shadow-optimisations ? > > As far as I understand it, updating (and booting > with) the new > /boot/amd64/xen.gz file is enough. And you should be > running > a 64-bit HVM domU.This message posted from opensolaris.org
> SNV87 HVM DomU at SNV91 Dom0 (both 64-bit) > bash-3.2# bin/fork -E -C 200 -L -S -W -N fork_100 -B > 100 -C 100 > /tmp/fork.output > Running: fork_100 for 27.06514 seconds > versus 35 sec for same > HVM DomU at Xen 3.2.1 F8 Dom0 (both 64-bit) > If fork_100 is a fair then SNV91 Dom0 should be > better for SNV HVM guest. > then Xen 3.2.1 F8 Dom0. > I suspect "svcs -x" output cleaning up phase by > some reason took longer at > SNV91 Dom0 and confused me.I''ve just bfu''ed SNV87 HVM to SNV91 HVM and lost ability to get IP-address for HVM DomU via DHCP. Performance stays the same 26 sec. This message posted from opensolaris.org
> > There is a problem with the PV network driver xnf (bug 6703227): > > when it receives packets before the xnf interface is plumbed and > > started, subsequent packets are not seen be the guest > > domain. > > > > The guest''s network interface appears to be dead for > > several minutes, but eventually recovers. > > Through my personal experience SNV PV DomU at SNV Dom0 in > DHCP mode became an issue for me since i bought Zyxel P-660RT Modem > acting as DHCP bridge (about end of march 2008) . The dates in CR 6703227 are > surprising me. Probably i misunderstand CR 6703227. > I also cannot find SNV build number against what the bug was reported. > What i usually do is SNV PV DomU at Linux Dom0 in DHCP > mode and it worked and works with no problems.I think the xnf bug was always present, but might have been masked by the dom0 network backend driver. For a Solaris dom0, the backend network driver xnb was optimized in snv_81 (CR 6616384) and I suspect that this uncovered bug 6703227. I''m not sure how the Linux Dom0 network backend driver works, but maybe using linux dom0 network backend with a solaris domU network frontend masks the xnf bug, too. This message posted from opensolaris.org
Jürgen Keil wrote:>>> There is a problem with the PV network driver xnf (bug 6703227): >>> when it receives packets before the xnf interface is plumbed and >>> started, subsequent packets are not seen be the guest >>> domain. >>> >>> The guest''s network interface appears to be dead for >>> several minutes, but eventually recovers. >> Through my personal experience SNV PV DomU at SNV Dom0 in >> DHCP mode became an issue for me since i bought Zyxel P-660RT Modem >> acting as DHCP bridge (about end of march 2008) . The dates in CR 6703227 are >> surprising me. Probably i misunderstand CR 6703227. >> I also cannot find SNV build number against what the bug was reported. >> What i usually do is SNV PV DomU at Linux Dom0 in DHCP >> mode and it worked and works with no problems. > > I think the xnf bug was always present, but might have been masked > by the dom0 network backend driver.Yes.> For a Solaris dom0, the backend > network driver xnb was optimized in snv_81 (CR 6616384) and I suspect > that this uncovered bug 6703227. > > I''m not sure how the Linux Dom0 network backend driver works, but maybe > using linux dom0 network backend with a solaris domU network frontend > masks the xnf bug, too.Yep. It''s a race linux probably just misses the window. MRJ
Solaris 10 (05/08) HVM DomU at SNV91 Dom0 (both 64-bit) bash-3.00# uname -a SunOS dhcppc7 5.10 Generic_127128-11 i86pc i386 i86pc bash-3.00# bin/fork -E -C 200 -L -S -W -N fork_100 -B 100 -C 100 > /tmp/fork.output Running: fork_100 for 41.02157 seconds Twice faster then at SNV87 Dom0 This message posted from opensolaris.org
Box1:- C2D E8400 ASUS, P5K Premium/WIFI, 4 GB RAM default-nic="rge0" Box2:- C2D E6600 ASUS P5B Deluxe + RTL8139 (plugged into PCI slot), 4GB RAM default-nic="rtls0" Attempt to install SNV90 DomU at SNV91 Dom0 (the most recent Xen bits installed) in DHCP mode failed on Box1 (dhcp timed out) and succeded on Box2 Both Box1 and Box2 are located on the same LAN and on he same dhcp bridge (ADSL modem) This message posted from opensolaris.org
I did several installs on Box2 and succeeded every time for SNV87,89,90 DomUs at SNV91 Dom0 . DHCP request took 20-30 sec as maximum. I did also same attempts on Box1 and every time DHCP request for DomU timed out. It looks like 6703227 is hardware dependent . Per CR xnf gets DHCPOFFER (PACK ?) before it gets plumbed and brought up by DomU , but eventually recovers. Then why it doesn''t happen on Box1 (network operates faster and has different architecture) xnf never recovers. Moreover if i install DomU with static IP , then # ifconfig xnf down # ifconfig xnf unplumb # ifconfig xnf plumb # ifconfig xnf dhcp It hangs .... All what i can is to bring up xnf with static IP from corresponding subnet. In this case RTL 8169SC is integrated on the board (vs RTL 8139 plugged into PCI slot on Box2) as second NIC, first one is Marvell Yukon Gigabit Ethernet. This message posted from opensolaris.org
Boris Derzhavets wrote:> I did several installs on Box2 and succeeded every time for SNV87,89,90 DomUs at > SNV91 Dom0 . DHCP request took 20-30 sec as maximum. > I did also same attempts on Box1 and every time DHCP request for DomU timed out. > > It looks like 6703227 is hardware dependent . Per CR xnf gets DHCPOFFER (PACK ?) > before it gets plumbed and brought up by DomU , but eventually recovers. > Then why it doesn''t happen on Box1 (network operates faster and has different architecture) > xnf never recovers.What is the nic on box1? If you configure it with static IP in domU, can you communicate with outside world?> Moreover if i install DomU with static IP , then > # ifconfig xnf down > # ifconfig xnf unplumb > # ifconfig xnf plumb > # ifconfig xnf dhcp > It hangs .... >This is due to that tx intr is only sent once by xnb to kick off network I/O. So, when you plumb it again, no more intr will be seen, neither rx or tx intr. This is also a problem in 6703227. Max> All what i can is to bring up xnf with static IP from corresponding subnet. > In this case RTL 8169SC is integrated on the board (vs RTL 8139 plugged into PCI slot on Box2) as second NIC, first one is Marvell Yukon Gigabit Ethernet. > > > This message posted from opensolaris.org > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org >
The NIC is RTL8110SC integrated as a second one the board. When i install SNV DomU with static IP no /etc/resolv.conf has been created. So , i create it by hands. DNS Servers of ISP keep stay unreachable ( vs DHCP config) Next step for DHCP mode is modifying /etc/nsswitch.conf :- hosts: dns files ipnodes : dns files After that nslookup begin to return IP addresses for outside web sites (on SNV DomU in DHCP mode) and browser can be launched to external site. If IP address on DomU is static then /etc/nsswitch.conf is useless. Probably manual creating of /etc/resolv.conf is not enough in static case and i miss some additional step ? --- On Sun, 6/15/08, Max Zhen <Max.Zhen@Sun.COM> wrote: From: Max Zhen <Max.Zhen@Sun.COM> Subject: Re: [xen-discuss] Bug 6703227 To: "Boris Derzhavets" <bderzhavets@yahoo.com> Cc: xen-discuss@opensolaris.org Date: Sunday, June 15, 2008, 10:31 PM Boris Derzhavets wrote: > I did several installs on Box2 and succeeded every time for SNV87,89,90 DomUs at > SNV91 Dom0 . DHCP request took 20-30 sec as maximum. > I did also same attempts on Box1 and every time DHCP request for DomU timed out. > > It looks like 6703227 is hardware dependent . Per CR xnf gets DHCPOFFER (PACK ?) > before it gets plumbed and brought up by DomU , but eventually recovers. > Then why it doesn''t happen on Box1 (network operates faster and has different architecture) > xnf never recovers. What is the nic on box1? If you configure it with static IP in domU, can you communicate with outside world? > Moreover if i install DomU with static IP , then > # ifconfig xnf down > # ifconfig xnf unplumb > # ifconfig xnf plumb > # ifconfig xnf dhcp > It hangs .... > This is due to that tx intr is only sent once by xnb to kick off network I/O. So, when you plumb it again, no more intr will be seen, neither rx or tx intr. This is also a problem in 6703227. Max > All what i can is to bring up xnf with static IP from corresponding subnet. > In this case RTL 8169SC is integrated on the board (vs RTL 8139 plugged into PCI slot on Box2) as second NIC, first one is Marvell Yukon Gigabit Ethernet. > > > This message posted from opensolaris.org > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org >
> I did several installs on Box2 and succeeded every time for SNV87,89,90 DomUs at > SNV91 Dom0 . DHCP request took 20-30 sec as maximum. > I did also same attempts on Box1 and every time DHCP request for DomU timed out. > It looks like 6703227 is hardware dependent . Per CR xnf gets DHCPOFFER (PACK ?) > before it gets plumbed and brought up by DomU , but eventually recovers. > Then why it doesn''t happen on Box1 (network operates faster and has different architecture) > xnf never recovers. Moreover if i install DomU with static IP , then > # ifconfig xnf down > # ifconfig xnf unplumb > # ifconfig xnf plumb > # ifconfig xnf dhcp > It hangs ....eventually recovers ==> it recovers after the domU has transmitted 192 packets. It isn''t that easy to transmit so many packets, because domU won''t see incoming packets. A workaround for 6703227 is to lower the tunable "xnb_unmop_hiwat" for the xnb (network backend) driver in dom0. In your solaris dom0, run this as root: echo "xnb_unmop_hiwat/W1" | mdb -wk (this disables the xnb optimization from CR 6616384). This message posted from opensolaris.org
# echo "xnb_unmop_hiwat/W1" | mdb -wk mdb: failed to dereference symbol: unknown symbol name --- On Mon, 6/16/08, Jürgen Keil <jk@tools.de> wrote: From: Jürgen Keil <jk@tools.de> Subject: Re: [xen-discuss] Bug 6703227 To: xen-discuss@opensolaris.org Date: Monday, June 16, 2008, 5:15 AM > I did several installs on Box2 and succeeded every time for SNV87,89,90 DomUs at > SNV91 Dom0 . DHCP request took 20-30 sec as maximum. > I did also same attempts on Box1 and every time DHCP request for DomU timed out. > It looks like 6703227 is hardware dependent . Per CR xnf gets DHCPOFFER (PACK ?) > before it gets plumbed and brought up by DomU , but eventually recovers. > Then why it doesn''t happen on Box1 (network operates faster and has different architecture) > xnf never recovers. Moreover if i install DomU with static IP , then > # ifconfig xnf down > # ifconfig xnf unplumb > # ifconfig xnf plumb > # ifconfig xnf dhcp > It hangs .... eventually recovers ==> it recovers after the domU has transmitted 192 packets. It isn''t that easy to transmit so many packets, because domU won''t see incoming packets. A workaround for 6703227 is to lower the tunable "xnb_unmop_hiwat" for the xnb (network backend) driver in dom0. In your solaris dom0, run this as root: echo "xnb_unmop_hiwat/W1" | mdb -wk (this disables the xnb optimization from CR 6616384). This message posted from opensolaris.org _______________________________________________ xen-discuss mailing list xen-discuss@opensolaris.org
> # echo "xnb_unmop_hiwat/W1" | mdb -wk > mdb: failed to dereference symbol: unknown symbol nameYep, the xnb module must be loaded in dom0, otherwise the symbol isn''t known. It gets loaded automatically as soon as you start any pv domU that is configured to use a vif virtual network interface. Another problem is the changed variable is lost when the driver module gets automatically unloaded from the kernel. Instead of patching the live kernel, you can add this line to /etc/system in dom0, and reboot dom0: set xnb:xnb_unmop_hiwat = 1 This message posted from opensolaris.org
I''ve tried suggested workaround on the box with ASUS P5K Premium/WIFI ( RTL8169 integrated on the board). Virt-install still times out at dhcp request attempting to create Solaris PVM What helps :- 1.Plug in RTL8139 2. svccfg -s xvm/xend setprop config/default-nic="rtls0" 3.svcadm refresh xvm/xend 4.svcadm restart xvm/xend Cable gets replugged. Solaris brings rge0 down and rtls0 up by itself. Virt-install start behave fine in regard of DHCP requests for SNV DomU. Solution obviously is not very smart, but that''s all what i can do for now. --- On Mon, 6/16/08, Jürgen Keil <jk@tools.de> wrote: From: Jürgen Keil <jk@tools.de> Subject: Re: [xen-discuss] Bug 6703227 To: xen-discuss@opensolaris.org Date: Monday, June 16, 2008, 9:17 AM > # echo "xnb_unmop_hiwat/W1" | mdb -wk > mdb: failed to dereference symbol: unknown symbol name Yep, the xnb module must be loaded in dom0, otherwise the symbol isn''t known. It gets loaded automatically as soon as you start any pv domU that is configured to use a vif virtual network interface. Another problem is the changed variable is lost when the driver module gets automatically unloaded from the kernel. Instead of patching the live kernel, you can add this line to /etc/system in dom0, and reboot dom0: set xnb:xnb_unmop_hiwat = 1 This message posted from opensolaris.org _______________________________________________ xen-discuss mailing list xen-discuss@opensolaris.org
In my case workaround did not help. The exact name of chip on the the board is RTL8110SC I guess that RTL 8169 is not exactly the one mentioned above. If i would get a chance i would try 8169 as plugged in card. Actually, it would be nice to be able consult the list of GLDV 3 NICs which is possible to plug in and pull out. I have to mention ASUS P5K(E) 3 Deluxe boards have the same RTL8110SC as second NIC integrated on the board. First one is Marvell Yukon. It appears that i just cannot point to midrange ASUS Motherboard which would be nice for SNV at mean time. This message posted from opensolaris.org
Finally , having default-nic "rtls0" i brought up SNV PV DomU and patched the kernel with mdb. Shutdown DomU. Switched default-nic to "rge0" and restarted same SNV PV DomU. This time dhcp request hasn''t timed out during reboot and DomU loaded in DHCP mode. I can ping DNS servers of ISP , /etc/nsswitch.conf contains:- hosts : dns files However , 1. Nslookup doesn''t respond as usual (no internet access) from DomU (ssh connection to Dom0 works) 2. I cannot create another SNV PV DomU . DHCP request during install times out I''ve also rebooted DomU (created with default-nic "rtls0" ) several time having default-nic "rge0". It works (a long time awaiting DHCP request at any reboot). This message posted from opensolaris.org
I have noticed that this trick causes:- -bash-3.2# svcs -x svc:/system/webconsole:console (java web console) State: offline since Tue Jun 17 09:23:21 2008 Reason: Start method is running. See: http://sun.com/msg/SMF-8000-C4 See: smcwebserver(1M) See: /var/svc/log/system-webconsole:console.log Impact: This service is not running. ón regular basis This message posted from opensolaris.org _______________________________________________ xen-discuss mailing list xen-discuss@opensolaris.org
> Finally , having default-nic "rtls0" i brought up SNV > PV DomU and patched the kernel > with mdb. Shutdown DomU. Switched default-nic to > "rge0" and restarted same SNV PV DomU. > This time dhcp request hasn''t timed out during reboot > and DomU loaded in DHCP mode. > I can ping DNS servers of ISP , /etc/nsswitch.conf > contains:- > hosts : dns files > However , > 1. Nslookup doesn''t respond as usual (no internet > access) from DomU > (ssh connection to Dom0 works) > I cannot create another SNV PV DomU . DHCP request > during install times outAs was advised by Juergen Keil i added to /etc/system :- set xnf:xnf_cksum_offload = 0 and rebooted DomU. Patch was rollbacked:- echo "xnb_unmop_hiwat/W0xC0" | mdb -wk It fixed all problems with internet access and time required to obtain IP address by DomU via DHCP at boot up. Current issue is not connected with CR 6703227. It''s connected with wrong udp checksums generation by DHCPDISCOVER issued via rge0 interface. TCPDUMP report obtained on another host on the LAN ************************************************************************************ 08:38:01.361741 arp who-has 192.168.1.1 tell 192.168.1.39 08:38:02.220179 IP (tos 0x0, ttl 255, id 19410, offset 0, flags [DF], proto: UDP (17), length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: [bad udp cksum 19ae!] BOOTP/DHCP, Request from 00:16:3e:29:b2:18 (oui Unknown), length: 300, xid:0x872bd9e3, secs:124, flags: [none] (0x0000) Client Ethernet Address: 00:16:3e:29:b2:18 (oui Unknown) Vendor-rfc1048: DHCP:DISCOVER MSZ:1472 LT:4294967295 VC:"SUNW.i86xpv" PR:SM+DG+NS+HN+DN+BR+VO 08:38:18.970232 arp who-has 192.168.1.40 (Broadcast) tell 192.168.1.40 08:39:05.790989 IP (tos 0x0, ttl 255, id 19411, offset 0, flags [DF], proto: UDP (17), length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: [bad udp cksum daad!] BOOTP/DHCP, Request from 00:16:3e:29:b2:18 (oui Unknown), length: 300, xid:0x872bd9e3, secs:187, flags: [none] (0x0000) Client Ethernet Address: 00:16:3e:29:b2:18 (oui Unknown) Vendor-rfc1048: DHCP:DISCOVER MSZ:1472 LT:4294967295 VC:"SUNW.i86xpv" PR:SM+DG+NS+HN+DN+BR+VO **************************************************************************************** Thanks Juergen for his support and attention to customers problems.> > I''ve also rebooted DomU (created with default-nic > "rtls0" ) several time having > default-nic "rge0". It works (a long time awaiting > DHCP request at any reboot).This message posted from opensolaris.org
On 19 Jun 2008, at 5:02pm, Boris Derzhavets wrote:> It''s connected with wrong udp checksums generation by DHCPDISCOVER > issued > via rge0 interface. > TCPDUMP report obtained on another host on the LANBoris, do you have the full raw tcpdump trace for this? I''d like to look at it if possible (please send it directly to me).
> > On 19 Jun 2008, at 5:02pm, Boris Derzhavets wrote: > > It''s connected with wrong udp checksums generation > by DHCPDISCOVER > > issued > > via rge0 interface. > > TCPDUMP report obtained on another host on the LAN > > Boris, do you have the full raw tcpdump trace for > this? I''d like to > look at it if possible (please send it directly to > me).David, 1. Command has been run was "tcpdump -s 1600 -vv" . It was enough to make sure of failure checksum offloading on RTL8110SC during SNV90 DomU issued DHCPDISCOVER. If you would instruct me what command to run to obtain "full raw tcpdump trace" you would get what you ask. 2.During install SNV90 (89) on bare metal in DHCP mode failure checksum offloading on RTL8110SC happens as well. SNV87 seems to be your last build free of this issue. 3. I''ve bfu''ed 87 to 91 along with xVM at Dom0 and in this case SNV91 Dom0 appeared to be able to run on bare metal in DHCP mode. 4. I just don''t have SNV91 DVD to attempt install on bare metal, but SNV87 HVM DomU which ran fine in DHCP mode at SNV91 Dom0 been bfu''ed to 91 lost this ability.> > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.orgThis message posted from opensolaris.org
On 24 Jun 2008, at 1:26pm, Boris Derzhavets wrote:> 1. Command has been run was "tcpdump -s 1600 -vv" . It was enough > to make sure of > failure checksum offloading on RTL8110SC during SNV90 DomU issued > DHCPDISCOVER. If you would instruct me what command to run to obtain > "full raw tcpdump trace" you would get what you ask.Given the information in 2, this isn''t necessary.> 2.During install SNV90 (89) on bare metal in DHCP mode failure > checksum offloading on RTL8110SC happens as well. SNV87 seems to be > your last build free of this issue.It seems clear that this is a problem with the driver then, as the problem occurs with Solaris on bare metal.