| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] RFH: Windows2003+GPLPV packet-receive breaks aftersometi
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/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home