Jurgen, I tried just now and was unable to reproduce weekend''s situation. SNV90 obtained IP in a couple of seconds on box with RTL8110SC I must notice , that one thing has changed in hardware config of the box. On Saturday i had 3 NICs on the box: RTL8110SC integrated on the board, RTL8139 and RTL8169 plugged into PCI slots. Installer asked me which one of interfaces to configure and i pointed to rge0 ( be sure it''s native adapter with network cable) Now i understood that rge0 was RTL8169 plugged into a slot and cable was plugged into rge1 . Right now when two PCI cards have been pulled out . On my main box interface is rge1. So, driver rge should be OK and i have to try create DomU per David''s request --- On Tue, 6/24/08, Juergen Keil <jk@tools.de> wrote: From: Juergen Keil <jk@tools.de> Subject: Re: [xen-discuss] Bug 6703227 To: bderzhavets@yahoo.com Date: Tuesday, June 24, 2008, 12:07 PM> Is that DHCP failure with the SNV90 media reproducable? > > > If yes: can you try to get a "tcpdump -x -vv -s 0" on the > other box, while the SNV90 installer tries to configure the > rge0 network interface on metal with DHCP? > > *************************************************** > Yes, i can do it tomorrow > morning. This phase shouldn''t touch > anything on hard drive (?) > If i am wrong about that ..... > ***************************************************Shouldn''t touch the hdd. This is before you select what packages should be installed, and before you select the target hdd for installation.
I''ve just installed SNV90 in DHCP mode on the box assembled with ASUS P5B Deluxe, RTL8169SC , 4 GB RAM and painlessly bfu''ed to 92 :- bash-3.2# xm info host : dhcppc10 release : 5.11 version : snv_92 machine : i86pc nr_cpus : 2 nr_nodes : 1 sockets_per_node : 1 cores_per_socket : 2 threads_per_core : 1 cpu_mhz : 2400 hw_caps : bfebfbff:20100800:00000000:00000140:0000e3bd:00000000:00000001 total_memory : 4095 free_memory : 128 xen_major : 3 xen_minor : 1 xen_extra : .4-xvm xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : Wed Jun 25 07:56:34 2008 +0400 15877:7c073a2d92b5 cc_compiler : gcc version 3.4.3 (csl-sol210-3_4-20050802) cc_compile_by : root cc_compile_domain : cc_compile_date : Wed Jun 25 07:57:04 MSD 2008 xend_config_format : 4 bash-3.2# dladm show-link LINK CLASS MTU STATE OVER rge0 phys 1500 up -- This message posted from opensolaris.org
> [Attachment log.raw.gz (12.1 K)] > > I tried just now and was unable to reproduce weekend''s situation. >SNV90 obtained IP in a couple of seconds on box with > RTL8110SCWhat did you trace in the attached log.raw.gz file? That tcpdump trace doesn''t show any bad udp checksums... This message posted from opensolaris.org
> Attached log is raw tcpdump obtained during attempt to install > SNV90 PV DomU at SNV92 Dom0 (xVM bits upgraded to 92 as well)Just to confirm: you created that tcpdump on your second computer, and not on the SNV92 Dom0 system, correct?> As suggested by Jurgen:- > SUNWPython, SUNWPython-devel reinstalled from SNV89 DVD > Bad udp checksums may be viewed in attached log:-14:50:03.351881 IP (tos 0x0, ttl 255, id 14780, offset 0, flags [DF], proto: UDP (17), length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: [bad udp cksum e8f!] BOOTP/DHCP, Request from 00:16:3e:7a:4c:a4 (oui Unknown), length: 300, xid:0xa25a435c, secs:3, flags: [none] (0x0000) Client Ethernet Address: 00:16:3e:7a:4c:a4 (oui Unknown) Vendor-rfc1048: DHCP:DISCOVER MSZ:1472 LT:4294967295 VC:"SUNW.i86xpv" PR:SM+DG+NS+HN+DN+BR+VO 0x0000: 4500 0148 39bc 4000 ff11 40e9 0000 0000 0x0010: ffff ffff 0044 0043 0134>>0145<<0101 0600 0x0020: a25a 435c 0003 0000 0000 0000 0000 0000 0x0030: 0000 0000 0000 0000 0016 3e7a 4ca4 0000 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 0x0100: 0000 0000 0000 0000 6382 5363 3501 0139 0x0110: 0205 c033 04ff ffff ff3c 0b53 554e 572e 0x0120: 6938 3678 7076 3707 0103 060c 0f1c 2bff 0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 0x0140: 0000 0000 0000 0000 This UDP packet has an UDP checksum of 0145, and that''s apparently the checksum for the UDP pseudo header with Src IP 0.0.0.0, Dest IP 255.255.255.255, Proto 11, Length 134:> 0000+0000+ffff+ffff+11+134=X20143> 2+0143145 So, if that packet was traced on a box different from the one running the SNV92 Dom0, then the realtec device / driver didn''t update the checksum at all...
> > [Attachment log.raw.gz (12.1 K)] > > > > I tried just now and was unable to reproduce > weekend''s situation. > >SNV90 obtained IP in a couple of seconds on box > with > > RTL8110SC > > What did you trace in the attached log.raw.gz file? > That tcpdump trace doesn''t show any bad udp > checksums...It''s not supposed to. Everything went well at Dom0. It was running at the LAN as diagnostic tool to catch errors in case if they appear. This message posted from opensolaris.org
--- On Wed, 6/25/08, Juergen Keil <jk@tools.de> wrote: From: Juergen Keil <jk@tools.de> Subject: Re: [xen-discuss] Bug 6703227 To: bderzhavets@yahoo.com, "David Edmondson" <dme@sun.com> Cc: xen-discuss@opensolaris.org Date: Wednesday, June 25, 2008, 10:47 AM> Attached log is raw tcpdump obtained during attempt to install > SNV90 PV DomU at SNV92 Dom0 (xVM bits upgraded to 92 as well)Just to confirm: you created that tcpdump on your second computer, and not on the SNV92 Dom0 system, correct? ****************** Yes, it''s correct ******************> As suggested by Jurgen:- > SUNWPython, SUNWPython-devel reinstalled from SNV89 DVD > Bad udp checksums may be viewed in attached log:-14:50:03.351881 IP (tos 0x0, ttl 255, id 14780, offset 0, flags [DF], proto: UDP (17), length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: [bad udp cksum e8f!] BOOTP/DHCP, Request from 00:16:3e:7a:4c:a4 (oui Unknown), length: 300, xid:0xa25a435c, secs:3, flags: [none] (0x0000) Client Ethernet Address: 00:16:3e:7a:4c:a4 (oui Unknown) Vendor-rfc1048: DHCP:DISCOVER MSZ:1472 LT:4294967295 VC:"SUNW.i86xpv" PR:SM+DG+NS+HN+DN+BR+VO 0x0000: 4500 0148 39bc 4000 ff11 40e9 0000 0000 0x0010: ffff ffff 0044 0043 0134>>0145<<0101 0600 0x0020: a25a 435c 0003 0000 0000 0000 0000 0000 0x0030: 0000 0000 0000 0000 0016 3e7a 4ca4 0000 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 0x00f0: 0000 0000 0000 0000 0000 0000 0000 0000 0x0100: 0000 0000 0000 0000 6382 5363 3501 0139 0x0110: 0205 c033 04ff ffff ff3c 0b53 554e 572e 0x0120: 6938 3678 7076 3707 0103 060c 0f1c 2bff 0x0130: 0000 0000 0000 0000 0000 0000 0000 0000 0x0140: 0000 0000 0000 0000 This UDP packet has an UDP checksum of 0145, and that''s apparently the checksum for the UDP pseudo header with Src IP 0.0.0.0, Dest IP 255.255.255.255, Proto 11, Length 134:> 0000+0000+ffff+ffff+11+134=X20143> 2+0143145 So, if that packet was traced on a box different from the one running the SNV92 Dom0, then the realtec device / driver didn''t update the checksum at all...