From: "Fernando Luis Vázquez Cao" <fernando@oss.ntt.co.jp>
To: Igor Kovalenko <igor.v.kovalenko@gmail.com>
Cc: "Mark McLoughlin" <markmc@redhat.com>,
"Anthony Liguori" <aliguori@us.ibm.com>,
"角田 勇人" <kakuta.hayato@oss.ntt.co.jp>,
qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] rtl8139: honor RxOverflow flag in can_receive method
Date: Tue, 31 Jan 2012 10:25:45 +0900 [thread overview]
Message-ID: <4F274319.7000301@oss.ntt.co.jp> (raw)
In-Reply-To: <CAA8-O=VSxoSZ4yxcHh2_86HUYV42sAnN3OfNqUJtH_Jtmurh9Q@mail.gmail.com>
Hi Igor,
Thank you for the prompt reply. I really appreciate it.
(2012年01月31日 02:28), Igor Kovalenko wrote:
> 2012/1/30 Fernando Luis Vázquez Cao<fernando@oss.ntt.co.jp>:
>> Some drivers (Linux' 8139too among them) rely on the NIC injecting an interrupt
>> in the event of a receive buffer overflow and, accordingly, set the RxOverflow
>> bit in the interrupt mask. Unfortunately rtl8139's can_receive method ignores
>> the RxOverflow flag, which may lead to a situation where rtl8139 stops receiving
>> packets (can_receive returns 0) when the receive buffer becomes full.
>>
>> If the driver eventually read from the receive buffer or reset the card the
>> emulator could recover from this situation. However some implementations only
>> do this upon receiving an interrupt with either RxOK or RxOverflow set in the
>> ISR; interrupt that will never come because QEMU's flow control mechanisms would
>> prevent rtl8139 from receiving any packet.
>>
>> Letting packets go through when the overflow interrupt is enabled makes the
>> QEMU emulator compliant to the spec and solves the problem.
>>
>> This patch should fix a relatively common (in our experience) network stall
>> observed when running enterprise distros with rtl8139 as the NIC; in some cases
>> the 8139too device driver gets loaded and when under heavy load the network
>> eventually stops working.
> It would be great to see specific example to verify the issue.
Sure. In the gdb debug session included inline below you can see that
after a
while RxBufPtr-RxBufAddr becomes too small to accommodate a MTU sized
packet and, because of the current can_receive logic, rtl8139 will stop
receiving
packets from other QEMU VLAN clients.
> Otherwise the change looks great.
Could I have your "Acked-by"? By the way, whose tree should this patch
go through?
----- gdb debug session
(gdb) p *(RTL8139State *) 0x144143a0
$3 = {phys = "TR\000bS:\000", mult = "\000\000\000\200\000\000\004@",
TxStatus = {565346, 565346, 565346, 565346}, TxAddr = {899350528,
899352064, 899353600,
899355136}, RxBuf = 894697472, RxBufferSize = 32768, RxBufPtr = 0,
RxBufAddr = 0, IntrStatus = 0, IntrMask = 49279, TxConfig = 2004878976,
RxConfig = 63374,
RxMissed = 0, CSCR = 832, Cfg9346 = 0 '\0', Config0 = 0 '\0', Config1
= 12 '\f', Config3 = 1 '\001', Config4 = 0 '\0', Config5 = 0 '\0',
clock_enabled = 1 '\001', bChipCmdState = 12 '\f', MultiIntr = 0,
BasicModeCtrl = 4096, BasicModeStatus = 30765, NWayAdvert = 1505,
NWayLPAR = 1505,
NWayExpansion = 1, CpCmd = 0, TxThresh = 0 '\0', pci_dev =
0x14414150, vc = 0x14414550, macaddr = "TR\000bS:", rtl8139_mmio_io_addr
= 104, currTxDesc = 0,
cplus_enabled = 0, currCPlusRxDesc = 0, currCPlusTxDesc = 0,
RxRingAddrLO = 0, RxRingAddrHI = 0, eeprom = {contents = {33065, 4332,
33081, 0, 0, 0, 0, 21076,
25088, 14931, 0 <repeats 54 times>}, mode = 1, tick = 0, address
= 9 '\t', input = 0, output = 0, eecs = 1 '\001', eesk = 0 '\0', eedi =
0 '\0',
eedo = 1 '\001'}, TCTR = 0, TimerInt = 0, TCTR_base = 0,
tally_counters = {TxOk = 0, RxOk = 0, TxERR = 0, RxERR = 10, MissPkt =
0, FAE = 0, Tx1Col = 0,
TxMCol = 0, RxOkPhy = 1302, RxOkBrd = 2, RxOkMul = 10, TxAbt = 0,
TxUndrn = 0}, cplus_txbuffer = 0x0, cplus_txbuffer_len = 0,
cplus_txbuffer_offset = 0,
timer = 0x0}
(gdb) c
Continuing.
[Thread 0x42c3a940 (LWP 2739) exited]
[New Thread 0x42c3a940 (LWP 2791)]
Program received signal SIGINT, Interrupt.
0x0000003a3a4cced2 in select () from /lib64/libc.so.6
(gdb) d
Delete all breakpoints? (y or n) y
(gdb)
(gdb) c
Continuing.
Program received signal SIGINT, Interrupt.
0x0000003a3a4cced2 in select () from /lib64/libc.so.6
(gdb) p *(RTL8139State *) 0x144143a0
$4 = {phys = "TR\000bS:\000", mult = "\000\000\000\200\000\000\004@",
TxStatus = {565308, 565346, 565346, 565346}, TxAddr = {899350528,
899352064, 899353600,
899355136}, RxBuf = 894697472, RxBufferSize = 32768, RxBufPtr =
22032, RxBufAddr = 20544, IntrStatus = 0, IntrMask = 49279, TxConfig =
2004878976,
RxConfig = 63374, RxMissed = 0, CSCR = 832, Cfg9346 = 0 '\0', Config0
= 0 '\0', Config1 = 12 '\f', Config3 = 1 '\001', Config4 = 0 '\0',
Config5 = 0 '\0',
clock_enabled = 1 '\001', bChipCmdState = 12 '\f', MultiIntr = 0,
BasicModeCtrl = 4096, BasicModeStatus = 30765, NWayAdvert = 1505,
NWayLPAR = 1505,
NWayExpansion = 1, CpCmd = 0, TxThresh = 0 '\0', pci_dev =
0x14414150, vc = 0x14414550, macaddr = "TR\000bS:", rtl8139_mmio_io_addr
= 104, currTxDesc = 1,
cplus_enabled = 0, currCPlusRxDesc = 0, currCPlusTxDesc = 0,
RxRingAddrLO = 0, RxRingAddrHI = 0, eeprom = {contents = {33065, 4332,
33081, 0, 0, 0, 0, 21076,
25088, 14931, 0 <repeats 54 times>}, mode = 1, tick = 0, address
= 9 '\t', input = 0, output = 0, eecs = 1 '\001', eesk = 0 '\0', eedi =
0 '\0',
eedo = 1 '\001'}, TCTR = 0, TimerInt = 0, TCTR_base = 0,
tally_counters = {TxOk = 0, RxOk = 0, TxERR = 0, RxERR = 10, MissPkt =
0, FAE = 0, Tx1Col = 0,
TxMCol = 0, RxOkPhy = 10277, RxOkBrd = 3, RxOkMul = 10, TxAbt = 0,
TxUndrn = 0}, cplus_txbuffer = 0x0, cplus_txbuffer_len = 0,
cplus_txbuffer_offset = 0,
timer = 0x0}
-----
Thanks,
Fernando
next prev parent reply other threads:[~2012-01-31 1:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-30 2:17 [Qemu-devel] [PATCH] rtl8139: honor RxOverflow flag in can_receive method Fernando Luis Vázquez Cao
2012-01-30 17:28 ` Igor Kovalenko
2012-01-31 1:25 ` Fernando Luis Vázquez Cao [this message]
2012-01-31 4:12 ` Igor Kovalenko
2012-01-31 4:21 ` Fernando Luis Vázquez Cao
2012-02-01 22:11 ` Anthony Liguori
2012-02-03 2:16 ` Fernando Luis Vázquez Cao
2012-02-14 7:33 ` Fernando Luis Vázquez Cao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F274319.7000301@oss.ntt.co.jp \
--to=fernando@oss.ntt.co.jp \
--cc=aliguori@us.ibm.com \
--cc=igor.v.kovalenko@gmail.com \
--cc=kakuta.hayato@oss.ntt.co.jp \
--cc=markmc@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).