Bug 462845
Summary: | Diskless client lock up with r8169 driver with kernel 2.6.26.3-14 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jeremy Sanders <jss> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8 | CC: | rmj |
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-09-24 16:08:13 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: |
Description
Jeremy Sanders
2008-09-19 11:08:52 UTC
PS The system with the real disk as root does show a r8169 problem during bootup (note that this kernel is tainted unfortunately, but the diskless systems are untainted). NETDEV WATCHDOG: eth0: transmit timed out ------------[ cut here ]------------ WARNING: at net/sched/sch_generic.c:222 dev_watchdog+0xb6/0x116() (Tainted: P ) Modules linked in: nvidia(P)(U) w83627hf hwmon_vid fuse sunrpc ipv6 dm_mirror dm_log dm_multipath dm_mod snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 parport_pc snd_rawmidi parport snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_oss floppy snd_seq_midi_event snd_seq k8temp hwmon snd_pcm_oss snd_mixer_oss i2c_viapro snd_pcm i2c_core snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep firewire_ohci snd firewire_core crc_itu_t soundcore r8169 shpchp sr_mod sg cdrom pata_via pata_acpi ata_generic libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan] Pid: 0, comm: swapper Tainted: P 2.6.26.3-14.fc8 #1 Call Trace: <IRQ> [<ffffffff810363d0>] warn_on_slowpath+0x60/0x8e [<ffffffff8103f788>] ? __mod_timer+0xc1/0xd3 [<ffffffff81046367>] ? queue_delayed_work_on+0xc3/0xd6 [<ffffffff8122b4e2>] ? dev_watchdog+0x0/0x116 [<ffffffff810463b6>] ? queue_delayed_work+0x21/0x23 [<ffffffff810463d1>] ? schedule_delayed_work+0x19/0x1b [<ffffffffa00e30d2>] ? :r8169:rtl8169_schedule_work+0x23/0x25 [<ffffffff8122b598>] dev_watchdog+0xb6/0x116 [<ffffffff8103f053>] run_timer_softirq+0x173/0x1ef [<ffffffff8103b18f>] __do_softirq+0x5e/0xd5 [<ffffffff8100d4fc>] call_softirq+0x1c/0x28 [<ffffffff8100ed0e>] do_softirq+0x44/0x8b [<ffffffff8103b0f0>] irq_exit+0x3f/0x80 [<ffffffff8100f00f>] do_IRQ+0x147/0x16c [<ffffffff8100b1a6>] ? default_idle+0x0/0x4e [<ffffffff8100c69d>] ret_from_intr+0x0/0x19 <EOI> [<ffffffff81020468>] ? native_safe_halt+0x6/0x8 [<ffffffff8129b56f>] ? atomic_notifier_call_chain+0xf/0x11 [<ffffffff8100b1d4>] ? default_idle+0x2e/0x4e [<ffffffff8100ad46>] ? cpu_idle+0x91/0xbb [<ffffffff8128851d>] ? rest_init+0x61/0x63 ---[ end trace 2ba69dfa5cac9a95 ]--- r8169: eth0: link up It now appears the hanging is not due to the kernel, but due to another update on the system leading to exhaustion of entropy. The call trace above may still need to be fixed. |