From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50274) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMEVT-00060x-2N for qemu-devel@nongnu.org; Tue, 17 May 2011 03:15:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMEVR-0006RL-Sc for qemu-devel@nongnu.org; Tue, 17 May 2011 03:15:51 -0400 Received: from goliath.siemens.de ([192.35.17.28]:28287) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMEVR-0006Qi-Ie for qemu-devel@nongnu.org; Tue, 17 May 2011 03:15:49 -0400 Message-ID: <4DD2209B.6080502@siemens.com> Date: Tue, 17 May 2011 09:15:39 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20110516215523.1d77baf4@shadowfax.no-ip.com> In-Reply-To: <20110516215523.1d77baf4@shadowfax.no-ip.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: adnan@khaleel.us Cc: Isaku Yamahata , qemu-devel@nongnu.org On 2011-05-16 23:55, Adnan Khaleel wrote: > I finally got this work after I realised that the AHCI driver was not being loaded in my disk image and that ACHI was not being enabled in the Seabios .config file. > This is really good work Yamahata, thanks. > > > As far as I can tell, everything works like the stock Qemu 0.14 except networking. The guest OS sees the network device and initialises it but I think the Qemu DHCP server/firewall never gets back, since the network device doesn't even get a 10.0.2.15 ip address during bootup and the guest dhcp client never gets an ip address, > > > eth0 device: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) > eth0 Starting DHCP4 client. . . . . . . . > eth0 DHCP4 continues in background > eth0 device: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03) > eth0 DHCP4 client (dhcpcd) is running > eth0 . . . but is still waiting for data > eth0 interface could not be set up until now > > > So doing an ifconfig later on just shows > > > eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > > > lo Link encap:Local loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNING MTU:16436 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > > I'm going to start a separate thread to see what the possible cause might be and what might be the best way to debug this. Do you have any idea if this q35 chipset going to be committed to Qemu upstream? I've recently hacked a bit on q35, rebased it over current master, found and fixed a few bugs to allow booting of WinXP and Win7, and particularly added kvm support to improve testability significantly. You can find my current work at git://git.kiszka.org/qemu.git q35-test git://git.kiszka.org/seabios.git q35-test There are some issues remaining, e.g. usb appeared broken to me. Now I just tested your scenario (e1000+usernet) with a Win7 guest, and I do not get an IP either. There is no traffic on the vlan (I attached a dump device to verify). Looking closer, it seems PCI bar mapping is failing, at least partially, see 'info pci'. I hope it's not yet another ACPI issue. Fixing the polarity bug already forced me to dig way too deep into this horrible domain. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux