Port-xen archive

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

Re: xen and networking problems



On Fri, Oct 30, 2009 at 02:43:26PM -0600, Brook Milligan wrote:
> Manuel Bouyer writes:
>  > Please check with netstat if you have interrupt for this device.
> 
> # vmstat -i
> interrupt                                     total     rate
> vcpu0 ioapic0 pin 17                           1205        9
> vcpu0 ioapic0                                  2644       21
> vcpu0 ioapic0                                    10        0
> vcpu0 ioapic0                                   485        3
> vcpu0 clock                                   13057      104
> vcpu0 xenbus                                     53        0
> Total                                         17454      139
> 
> Note that the ioapic0 pin 17 device corresponds to the fxp0 network
> interface.  This command was run while pinging the interface, and the
> number of interrupts increases each time the command is run.  I
> presume this means that the hardware is generating interrupts as
> packets arrive.

So interrupts are probably working

> 
> In addition, the results of netstat are below.  The number of packets
> in increased with each run of the command and the number of packets
> out increased if I pinged from this machine (although outgoing pings
> always resulted in 'ping: sendto: Host is down' errors).
> 
> # netstat -i
> Name  Mtu   Network       Address              Ipkts Ierrs    Opkts Oerrs 
> Colls
> fxp0  1500  <Link>        00:30:48:23:3a:81     1702     0       14     0     > 0
> fxp0  1500  176.16.0.2/24 172.16.0.2            1702     0       14     0     > 0
> fxp0  1500  fe80::/64     fe80::230:48ff:fe     1702     0       14     0     > 0
> lo0   33184 <Link>                                 0     0        0     0     > 0
> lo0   33184 127/8         localhost                0     0        0     0     > 0
> lo0   33184 localhost/128 ::1                      0     0        0     0     > 0
> lo0   33184 fe80::/64     fe80::1                  0     0        0     0     > 0
> 
>  > You could also run tcpdump and see if you receive some packets.
> 
> tcpdump never captured any packets under these tests, which were all
> done without creating the bridge0 interface.  (The bridge was present
> when I generated output for earlier posts.)  Before I disabled
> bridge0, however, tcpdump reported only STP packets.  For these tests
> I disabled the bridge to make sure that it wasn't interfering with the
> primary network interface.

Did you run it with -n ? Otherwise, IP reverse resolution could cause it
to stall.

> 
> Does all of this mean that the packets are arriving at the hardware
> interface, are being partially processed by the kernel network stack,
> but are being lost somewhere along the way before making it to any
> applications?

tcpdump being silent makes it worse than that, as the packets are
passed to bpf from the driver itself, in the interrupt routine.


> 
> What else can be done to track down what is going on here?

check that it's not running out of mbufs. vmstat -m will tell you
if mbuf allocation fail (mbuf and mbuf cluster). 

> 
> By the way, without a serial console is there a way to capture the
> boot messages from the xen hypervisor?  Alternatively, is there a way
> to pause the boot process so I can review the messages before they
> scroll off the screen?

'xm dmesg' should give them to you

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index