qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci expres


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 00/26] q35 chipset support for native pci express support
Date: Tue, 17 May 2011 09:15:39 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]