Red Hat Bugzilla – Bug 190620
kernel-2.6.16-1.2107_FC5, NFS server stop working
Last modified: 2015-01-04 17:26:51 EST
Description of problem:
After upgrading to kernel-2.6.16-1.2107_FC5,
NFS server do not respond to mount request.
Version-Release number of selected component (if applicable):
depended on hardware. I have tested this on four PCs.
a. Athlon XP 2200, 8139too : occur
b. Sempron 2600+, e1000 : occur
c. Celeron 950MHz, r8169 : not occur
d. K6-2 450MHz, tulip : not occur
I switched HDD between a and c, then tested again:
a. Athlon XP 2200, 8139too: occur
c. Celeron 950MHz, r8169: not occur
It seems CPU related?
Steps to Reproduce:
1. upgrade to kernel-2.6.16-1.2107_FC5
3. service nfs start
4. exportfs '*:/home'
5. mount foobar:/home /mnt # from other host
NFS server not responding, and cause timeout.
mount: mount to NFS server 'foobar' failed: timed out (retrying).
foobar:/home is mounted on /mnt
does booting with pci=nomsi make this go away?
I tried "pci=nomsi" and got a message "PCI: Unknown option `nomsi'".
All problems are stay there.
Created attachment 128574 [details]
dmesg with "pci=nomsi"
Sigh, this option was added post 2.6.16. Please try noapic instead. Thanks.
alternatively, 2108 from http://people.redhat.com/davej/kernels/Fedora/FC5 has
this disabled by default.
Created attachment 128578 [details]
dmesg with noapic
I already tried "noapic" and "pci=irqroute", and got same problems.
00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host
Bridge00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237
AC97 Audio Controller (rev 50)
00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon
I tried kernel-2.6.16-1.2108_FC5.i686.rpm, and, got same problems again.
Created attachment 128579 [details]
dmesg of kernel-2.6.16-1.2108_FC5.i686
Created attachment 128580 [details]
this is dmesg of 2096, which shows no problem
After upgrading to kernel-2.6.16-1.2107_FC5, my network is dead. Old
kernel-2.6.16-1.2096_FC5 works just fine, though.
Configuration: Athlon 64 X2 on an ASUS A8N-SLI Premium motherboard
alias eth1 forcedeth
alias eth0 skge
where eth0 is not connected to any network, and eth1 is the main interface on a
Results: Boot hangs at NFS mount. Booting kernel-2.6.16-1.2107_FC5 in single
user mode then starting network shows normal routing etc, but pings to machines
on the same subnet fail. Old kernel-2.6.16-1.2096_FC5 works just fine, though.
For what it is worth, I have more or less the same problem as comment #10.
I have a Tyan Tomkat K8E (same nForce Ultra 4 chipset as the ASUS A8N-SLI
I believe) with an Athlon X2 4400+ and the x86_64 version of FC5. Under
.2107 the forcedeth driver doesn't work; under .2096 it does.
- a stock kernel.org 18.104.22.168 works fine.
- 'noapic' and 'pci=irqroute' make no difference.
- on .2107 the driver emits no complaints about life or anything, as far as
I can see; it just doesn't emit or receive packets.
It looks like the original submission was wrt the linux box running an NFS
server. For the record, I'm seeing what appears to be the same problem where
the linux box is the NFS _client_ (the server is Solaris 9). Rebooting into
the previous 2.6.16-1.2096_FC5smp allows me to work.
I tested 2.6.16-1.2109_FC5, and all problems are gone.
NFS server works again, graphical boot works again.
Thank you Dave!
I can confirm that 2.6.16-1.2111_FC5 (which is what I found as current at the
URL in comment #5) fixes the problem for me.
New kernel-2.6.16-1.2111_FC5 fixes the problem for me, too.