From: Nikola Ciprich <extmaillist@linuxbox.cz>
To: Igor Kovalenko <igor.v.kovalenko@gmail.com>
Cc: nikola.ciprich@linuxbox.cz, qemu-devel@nongnu.org,
KVM list <kvm@vger.kernel.org>,
lfarkas@lfarkas.org
Subject: Re: [Qemu-devel] 8139cp problems - steps to reproduce
Date: Wed, 10 Sep 2008 08:55:26 +0200 [thread overview]
Message-ID: <20080910065526.GA6863@develbox.linuxbox.cz> (raw)
In-Reply-To: <b2fa41d60809081254o709c706as384549b28e6f322a@mail.gmail.com>
On Mon, Sep 08, 2008 at 11:54:01PM +0400, Igor Kovalenko wrote:
Hi Igor,
I'm using bridged TAP device. Running ethtool -S eth0 (when it's still working)
shows increasing number of rx_err (rx_fifo is also increasing, dunno what that means).
tx_ok, rx_ok are also increasing of course. Then when the network hangs, tx_ok, rx_ok stop
increasing, and only rx_err and rx_fifo keep growing...
rtl8139-diag says among others:
Transmitter enabled with NONSTANDARD! settings, maximum burst 1024 bytes.
dunno if this is related...
when trying 2.6.26 x86-32 guest, i also got this:
[ 3719.662726] eth0: Transmit timeout, status d 2b 15 80ff
[ 3719.662968] ------------[ cut here ]------------
[ 3719.662970] WARNING: at net/sched/sch_generic.c:223 dev_watchdog+0xde/0xf0()
[ 3719.662972] Modules linked in: nfs lockd sunrpc ipv6 dm_mod sbshc container button battery ac i2c_piix4 i2c_core 8139cp mii bitrev crc32 piix pata_acpi ide_pci_generic ata_piix ata_generic libata sd_mod scsi_mod dock ide_disk ide_core ext3 jbd uhci_hcd ohci_hcd ehci_hcd [last unloaded: x_tables]
[ 3719.663087] Pid: 0, comm: swapper Not tainted 2.6.26lb.01 #1
[ 3719.663091] [<c012477f>] warn_on_slowpath+0x5f/0x90
[ 3719.663112] [<e08fab2c>] cp_interrupt+0x25c/0x440 [8139cp]
[ 3719.663123] [<c013ca3d>] getnstimeofday+0x3d/0xe0
[ 3719.663136] [<c0113769>] ack_ioapic_quirk_irq+0x9/0x80
[ 3719.663143] [<c015604c>] handle_fasteoi_irq+0x8c/0xe0
[ 3719.663151] [<c0105e30>] do_IRQ+0x40/0x70
[ 3719.663155] [<c0108aaa>] nommu_map_single+0x2a/0x60
[ 3719.663158] [<c02b2840>] dev_watchdog+0x0/0xf0
[ 3719.663161] [<c0103a1f>] common_interrupt+0x23/0x28
[ 3719.663164] [<c02b2840>] dev_watchdog+0x0/0xf0
[ 3719.663168] [<c02b291e>] dev_watchdog+0xde/0xf0
[ 3719.663171] [<c012d2a6>] run_timer_softirq+0x116/0x180
[ 3719.663179] [<c01296b2>] __do_softirq+0x72/0xf0
[ 3719.663183] [<c0129767>] do_softirq+0x37/0x40
[ 3719.663186] [<c0129ab7>] irq_exit+0x57/0x70
[ 3719.663189] [<c0111e38>] smp_apic_timer_interrupt+0x58/0x90
[ 3719.663193] [<c0156bc7>] rcu_pending+0x37/0x50
[ 3719.663195] [<c0101bd0>] default_idle+0x0/0x40
[ 3719.663210] [<c0103adc>] apic_timer_interrupt+0x28/0x30
[ 3719.663212] [<c0101bd0>] default_idle+0x0/0x40
[ 3719.663216] [<c0101bfe>] default_idle+0x2e/0x40
[ 3719.663219] [<c0101af3>] cpu_idle+0x53/0xc0
[ 3719.663224] =======================
[ 3719.663225] ---[ end trace a8aacd1e409fdad8 ]---
maybe it could help?
> On Mon, Sep 8, 2008 at 11:57 AM, Nikola Ciprich <extmaillist@linuxbox.cz> wrote:
>
> If it is not guest networking... please check if rx missed is not zero
> (no idea how, probably with ethtool or with netstat -i)
> You can also try enabling overflow debugging statements near lines where
>
> s->IntrStatus |= RxOverflow
>
> ... there are 3 of these. There is quite low probability that rtl8139
> should not set RxOK if it has overflow, or that guest driver does not
> expect it in that combination (which seems to be rather valid in case
> card received full set of descriptors space of data and missed last
> packet before driver was able to read and vacate some buffers.)
>
> --
> Kind regards,
> Igor V. Kovalenko
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------------------------
Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
next prev parent reply other threads:[~2008-09-10 6:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-08 7:57 [Qemu-devel] 8139cp problems - steps to reproduce Nikola Ciprich
2008-09-08 9:59 ` [Qemu-devel] " Nikola Ciprich
2008-09-08 19:54 ` [Qemu-devel] " Igor Kovalenko
2008-09-10 6:55 ` Nikola Ciprich [this message]
2008-09-10 9:35 ` Nikola Ciprich
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=20080910065526.GA6863@develbox.linuxbox.cz \
--to=extmaillist@linuxbox.cz \
--cc=igor.v.kovalenko@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=lfarkas@lfarkas.org \
--cc=nikola.ciprich@linuxbox.cz \
--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).