Bug 462845 - Diskless client lock up with r8169 driver with kernel 2.6.26.3-14
Diskless client lock up with r8169 driver with kernel 2.6.26.3-14
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-19 07:08 EDT by Jeremy Sanders
Modified: 2008-09-24 12:08 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-24 12:08:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeremy Sanders 2008-09-19 07:08:52 EDT
Description of problem:
We have a set of x86-64 diskless systems. They have their root partitions mounted over nfs. They use the r8169 network driver and gigabit ethernet. On changing the kernel from kernel-2.6.25.14-69.fc8 to kernel-2.6.26.3-14.fc8 they randomly lock up over a period of minutes to several hours after bootup with no activity.

We also have some x86-64 systems with forcedeth and x86 systems with e1000, which show no problems, so we suspect this is a problem with the r8169 network driver on these systems. 

A system with the same motherboard as the r8169 systems, but using a real root disk, works okay and doesn't lock up.

There is no debugging information in the logs or on the console from the problem. The systems aren't pingable after lockup and the console does not response to key presses (even caps lock).

Version-Release number of selected component (if applicable):
kernel-2.6.26.3-14.fc8

How reproducible:
Every time

Steps to Reproduce:
1. Boot computer
2.
3.
  
Actual results:
Locks up.

Expected results:
Does not lock up.

Additional info:
[root@xsa1 ~]# lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South]
00:05.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
00:0f.0 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
Comment 1 Jeremy Sanders 2008-09-19 07:11:33 EDT
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
Comment 2 Jeremy Sanders 2008-09-24 12:08:13 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.