Bug 716864
Summary: | ipheth: WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x108/0x17c(): | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dmitry Petrich <dmitry> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | ASSIGNED --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | bowie.owens, dane_ruyle, fullung, gansalmon, itamar, jforbes, jonathan, kernel-maint, madhu.chinakonda, mlbianchi, woodard |
Target Milestone: | --- | Keywords: | Tracking |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Unspecified | ||
Whiteboard: | abrt_hash:869ffb09debb1aa0e831caffab68dc618e7bc2d0 | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-07-11 20:36:45 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: | |||
Bug Depends On: | |||
Bug Blocks: | 702723 |
Description
Dmitry Petrich
2011-06-27 09:56:46 UTC
*** This bug has been marked as a duplicate of bug 702723 *** Package: kernel Architecture: x86_64 OS Release: Fedora release 15 (Lovelock) Comment ----- no idea, how it happens Does this still happen with the 2.6.40.x kernel updates in F15? For me, this is happening on Hyper-V. How to get the Kernel updates ? How about an ISO build? :) (In reply to comment #4) > For me, this is happening on Hyper-V. How to get the Kernel updates ? Boot into the VM, then run a yum update? > How about an ISO build? :) There is no F15 iso that has a 2.6.40 kernel. You could try the F16 Beta isos that should be released tomorrow. Can't run YUM. Well I can, but it won't find anything because Kernel crash when it hits the network layer. That's the whole problem. NICs can get their IP's from DHCP but when the OS goes to use the NIC, the Kernel crashes. I spent several hours on this last night. Got frustrated and moved to CentOS where I find the same issue occurs when I have more then one CPU added to the VM. 1 CPU NIC works fine. 2 CPUs and NIC no longer works, kernel crash. Went to 1 CPU and 2 NICs and craziness again. I think I can repeat/remedy the problem by simply changing the number of CPUs in the VM. I think I can repeat/remedy the problem by simply changing the number of CPUs in the VM. Unfortunately, this is not the case with Fedora 15. Sure hope this is the same issue. ? Also tried installing Msft's Linux integration components v3.0 (I think that is the latest). And it does not install correctly. Think it is something with the RPM arguments. It complains the current RPM (itself) is needed by kernel and missing dependency. I can force it with the --nodeps but when verifying installation after reboot, it modules are not found.. Example, /sbin/modinfo hv_vmbus Sorry for the spam. Just tried Alpha16. Downloaded the 255MB install, it seems to be working, downloading and installing what it needs. Also downloading the 3.3GB DVD. I'm thinking this looks good. Would still like to verify with the Integration Components right? (In reply to comment #8) > Sorry for the spam. > > Just tried Alpha16. Downloaded the 255MB install, it seems to be working, > downloading and installing what it needs. Also downloading the 3.3GB DVD. > I'm thinking this looks good. That's good news. > Would still like to verify with the Integration Components right? I'm not sure what those are, but if they are some out-of-tree Microsoft provided kernel modules, then we don't really need to know anything about those. We don't support them. Kernel crash after install completed and system rebooted. Think it was because I selected to send the system profile at the end of installation. When the system came up, it tried to send the profile and kernel crashes, no more network. Why would the installer be OK but not the installed operating system? *** Bug 755158 has been marked as a duplicate of this bug. *** *** Bug 757230 has been marked as a duplicate of this bug. *** I've seen this bug or something like it with 3.3.0-4.fc16.x86_64.debug. [ 2384.630835] ------------[ cut here ]------------ [ 2384.635621] WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x267/0x270() [ 2384.643042] Hardware name: X8DTH-i/6/iF/6F [ 2384.647291] NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out [ 2384.653699] Modules linked in: netconsole binfmt_misc ses enclosure mlx4_ib mlx4_en ib_ipoib ib_cm ib_addr ib_sa ib_uverbs ib_umad ib_mad ib_core ipmi_poweroff microcode serio_raw joydev ipmi_watchdog i2c_i801 iTCO_wdt ipmi_devintf iTCO_vendor_support mpt2sas i2c_core scsi_transport_sas ioatdma i7core_edac raid_class mlx4_core igb edac_core dca ipmi_si ipmi_msghandler [last unloaded: netconsole] [ 2384.692878] Pid: 0, comm: swapper/5 Not tainted 3.3.0-4.fc16.x86_64.debug #1 [ 2384.700062] Call Trace: [ 2384.702653] <IRQ> [<ffffffff81061f6f>] warn_slowpath_common+0x7f/0xc0 [ 2384.709524] [<ffffffff81062066>] warn_slowpath_fmt+0x46/0x50 [ 2384.715415] [<ffffffff81585987>] dev_watchdog+0x267/0x270 [ 2384.721052] [<ffffffff81074645>] run_timer_softirq+0x195/0x6d0 [ 2384.727134] [<ffffffff810745b0>] ? run_timer_softirq+0x100/0x6d0 [ 2384.733381] [<ffffffff816a2987>] ? _raw_spin_unlock_irqrestore+0x77/0x80 [ 2384.740311] [<ffffffff8133360b>] ? debug_object_activate+0x12b/0x1a0 [ 2384.746894] [<ffffffff81585720>] ? pfifo_fast_init+0x90/0x90 [ 2384.752791] [<ffffffff8106aef8>] __do_softirq+0xc8/0x3c0 [ 2384.758341] [<ffffffff81039e7d>] ? lapic_next_event+0x1d/0x30 [ 2384.764323] [<ffffffff816ad06c>] call_softirq+0x1c/0x30 [ 2384.769785] [<ffffffff8101c565>] do_softirq+0xa5/0xe0 [ 2384.775065] [<ffffffff8106b54e>] irq_exit+0xbe/0xf0 [ 2384.780180] [<ffffffff816ad9ee>] smp_apic_timer_interrupt+0x6e/0x99 [ 2384.786686] [<ffffffff816ac673>] apic_timer_interrupt+0x73/0x80 [ 2384.792831] <EOI> [<ffffffff8137f877>] ? intel_idle+0xe7/0x150 [ 2384.799109] [<ffffffff8137f87b>] ? intel_idle+0xeb/0x150 [ 2384.804661] [<ffffffff8137f877>] ? intel_idle+0xe7/0x150 [ 2384.810210] [<ffffffff8151c377>] cpuidle_idle_call+0xb7/0x5d0 [ 2384.816184] [<ffffffff816a730d>] ? __atomic_notifier_call_chain+0x4d/0x130 [ 2384.823286] [<ffffffff8101923f>] cpu_idle+0xdf/0x130 [ 2384.828485] [<ffffffff8168f64d>] start_secondary+0x2a0/0x2a2 [ 2384.834374] ---[ end trace eb910926dcb78354 ]--- [ 2384.839210] igb 0000:01:00.0: eth0: Reset adapter [ 2387.622841] igb 0000:01:00.0: eth0: Reset adapter [ 2390.058543] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 2395.625142] igb 0000:01:00.0: eth0: Reset adapter [ 2398.609178] igb 0000:01:00.0: eth0: Reset adapter [ 2401.079872] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 2406.587602] igb 0000:01:00.0: eth0: Reset adapter [ 2409.700656] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 2419.560643] igb 0000:01:00.0: eth0: Reset adapter [ 2422.863213] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX *** Bug 817749 has been marked as a duplicate of this bug. *** *** Bug 821152 has been marked as a duplicate of this bug. *** Moving to rawhide so this doesn't get closed due to F15 EOL *** Bug 837711 has been marked as a duplicate of this bug. *** *** Bug 839756 has been marked as a duplicate of this bug. *** This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 Is this still a problem with 3.9 based F19 kernels? Note this BZ is for the ipheth driver, please do not add trace for other drivers as these dev_watchdog warnings are completely driver specific. As to ipheth there is a truckload of reports about this issue: http://oops.kernel.org/oops/?oopsclass=default&oopstype=default&oopsdistro=default&module=&driver=ipheth&function=&file=&bugline=&oopskernel=&search=submit No code changes/solution in sight yet though |