Re: [Xen-users] RFH: Windows2003+GPLPV packet-receive breaks aftersometime (Xen 3.4.3 amd64)

[Philipp Hahn <hahn@xxxxxxxxxxxxx>]

Hello James,

thanks again for the prompt answer,

Am Montag 07 März 2011 11:58:50 schrieb James Harper:
> > XenNet <-- XenNet_PnPEventNotify
> > XenNet     (BUFFER_TOO_SHORT 100 > 28)
> > XenNet     (BUFFER_TOO_SHORT 152 > 0)
> > XenNet     (BUFFER_TOO_SHORT 152 > 0)
> > XenNet     cannot allocate packet
> > XenNet     No free packets
> > XenNet     Ran out of packets
> >
> > The last three messages are repeated multiple times.
> >
> > (I can send you the full log per private Email, if you want to take a
> > look.)

There were some more messages related to networking, which my grep missed:

XenNet     XEN_INIT_TYPE_DEVICE_STATE - 8A9F8FB4
ScatterGather = 1
LargeSendOffload = 61440
ChecksumOffload = 1
ChecksumOffloadRxCheck = 1
MTU = 1500
RxInterruptModeration = 0
Could not read NetworkAddress value (c0000001) or value is invalid
XenNet --> XenNet_D0Entry
...
XenNet <-- XenNet_D0Entry
Get Unknown OID 0x10202
Get Unknown OID 0x10203
XenNet --> XenNet_PnPEventNotify
XenNet     NdisDevicePnPEventPowerProfileChanged
XenNet <-- XenNet_PnPEventNotify
Get Unknown OID 0x10201
Get Unknown OID 0xfc010210
Get OID_TCP_TASK_OFFLOAD
XenNet     (BUFFER_TOO_SHORT 100 > 28)
Get OID_TCP_TASK_OFFLOAD
config_csum enabled
nto = 8A4141A4
nto->Size = 24
nto->TaskBufferLength = 16
config_gso enabled
nto = 8A4141C8
nto->Size = 24
nto->TaskBufferLength = 16
&(nttls->IpOptions) = 8A4141E9
Set OID_TCP_TASK_OFFLOAD
TcpIpChecksumNdisTask
  V4Transmit.IpOptionsSupported  = 0
  V4Transmit.TcpOptionsSupported = 1
  V4Transmit.TcpChecksum         = 1
  V4Transmit.UdpChecksum         = 0
  V4Transmit.IpChecksum          = 0
  V4Receive.IpOptionsSupported   = 0
  V4Receive.TcpOptionsSupported  = 0
  V4Receive.TcpChecksum          = 1
  V4Receive.UdpChecksum          = 0
  V4Receive.IpChecksum           = 0
  V6Transmit.IpOptionsSupported  = 0
  V6Transmit.TcpOptionsSupported = 0
  V6Transmit.TcpChecksum         = 0
  V6Transmit.UdpChecksum         = 0
  V6Receive.IpOptionsSupported   = 0
  V6Receive.TcpOptionsSupported  = 0
  V6Receive.TcpChecksum          = 0
  V6Receive.UdpChecksum          = 0
TcpLargeSendNdisTask
  MaxOffLoadSize                 = 61440
  MinSegmentCount                = 4
  TcpOptions                     = 0
  IpOptions                      = 0
Get OID_PNP_CAPABILITIES
Set Unknown OID 0x10119
Set OID_GEN_CURRENT_LOOKAHEAD 128 (8A6CE000)
Set OID_GEN_CURRENT_PACKET_FILTER (xi = 8A6CE000)
  NDIS_PACKET_TYPE_DIRECTED
  NDIS_PACKET_TYPE_MULTICAST
  NDIS_PACKET_TYPE_BROADCAST
Get Unknown OID 0x10203
XenNet     (BUFFER_TOO_SHORT 152 > 0)
Get Unknown OID 0x10117
XenVbd     SCSIOP_MODE_SENSE llbaa = 0, dbd = 0, page_code = 63, 
allocation_length = 12
XenPCI --> XenPci_EvtDeviceUsageNotification

> Did you try with the offload features disabled?

Uups: Because of the switch to the debugging drivers, those features were 
re-enabled. We just disabled them again, which also unblocked the domain for 
now. We'll monitor those domains for some time and see, if the problem 
re-apprears.

> > ./statistics/tx_dropped:1349522
>
> The messages you are seeing above are in the rx path in DomU which means
> the tx path in Dom0. Do your DomU's receive a large amount of traffic?

Both systems currently showing the problem do send 10 times more data then 
they receive, but that might still be above your average test case:

# ifconfig vif205.0 | tail -n 2 # Linuxs point of view
RX bytes:361147609996 (336.3 GiB)  TX bytes:20727355262 (19.3 GiB)
RX bytes:1292788783876 (1.1 TiB)  TX bytes:170447442659 (158.7 GiB)

> Most of my traffic would be in the other direction, and ->DomU traffic
> would be mostly at WAN speeds, not LAN speeds... I'll have a look at the
> code and see if I've missed something.

Thanks again.

Sincerely
Philipp Hahn
-- 
Philipp Hahn           Open Source Software Engineer      hahn@xxxxxxxxxxxxx
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  28359 Bremen                   fax: +49 421 22 232-99
                                                   http://www.univention.de/

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users