Bug 218733
Summary: | [FORCEDETH]: eth0 stops working after a while in Xen | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Herbert Xu <herbert.xu> | ||||
Component: | kernel-xen | Assignee: | Herbert Xu <herbert.xu> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 6 | CC: | bstein, mquinn, xen-maint | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-02-26 23:47:07 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Herbert Xu
2006-12-07 02:42:21 UTC
Are there any messages in dmesg (or xm dmesg) when this happens? Could you please try disabling TX checksums on eth0 (with ethtool -K peth0 tx off) to see if the problem still occurs? Thanks. Thanks for the xm dmesg output. I presume the problem occurs even when you don't run any domUs at all? If so please try disabling xend by making it not start. This will tell us whether it's to do with the changes made by xend (e.g., setting a bogus MAC) or whether it's something lower down. BTW, what does ethtool -i peth0 ethtool -k peth0 show? Hello Herbert, The output from "ethtool -i peth0": driver: forcedeth version: 0.56 firmware-version: bus-info: 0000:00:05.0 and "ethtool -k pet0": Offload parameters for peth0: rx-checksumming: off tx-checksumming: off scatter-gather: off tcp segmentation offload: off I booted without xend enabled this time and got roughly the same results. The network worked fine for approximately 46 minutes this time. It was fast and responsive and then it just stopped. Restarting the network did not help. I manually set the IP address on the eth0 interface and then started examining the arp table. There was one entry for my DHCP Server/Default Gateway machine, but it did not have a HW address (incomplete) specified. I modified the arp table to have the correct ethernet hardware address for my DHCP server/Default Gateway, but that did not seem to help the situation. Still no ping response. What would you like me to try next? I presume this problem does not appear when you use a baremetal FC6 kernel? If so please attach the dmesg from that kernel. Thanks. Hell Herbert, No the problem does not manifest itself on a bare metal kernel of the same version. Any chance of that dmesg from the working baremetal kernel? Thanks. Created attachment 143733 [details]
Requested dmesg of bare metal kernel
No problem. Here is a dmesg from a stable, baremetal kernel (same version)
running on the same machine.
What would you like me to try next?
If you have a spare partition I'd like you to check if this happens with a 32-bit (i.e., i686) HV+kernel. Thanks. Another thing to try would be to load nvnet instead of forcedeth to see if it's a driver-specific issue. If you can get the source code for nvnet :) So scratch that idea. Can you show me the ifconfig output *after* it locks up? When you ping from inside the box to the outside after the lock-up, does the TX counter in the ifconfig output increase? Thanks. change QA contact This report targets FC6, which is now end-of-life. Please re-test against Fedora 7 or later, and if the issue persists, open a new bug. Thanks |