Bug 230094 - kernel panic with nfsd
Summary: kernel panic with nfsd
Status: CLOSED DUPLICATE of bug 191831
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.4
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-26 16:26 UTC by jmccann
Modified: 2015-01-14 23:20 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-03-12 17:41:16 UTC
Target Upstream Version:

Attachments (Terms of Use)
kern syslog output (11.50 KB, text/plain)
2007-02-26 16:26 UTC, jmccann
no flags Details
panic bt (1.68 KB, text/plain)
2007-03-09 12:27 UTC, jeff
no flags Details
script that has never failed to reproduce bug on redhat 4 nfs server (382 bytes, application/octet-stream)
2007-03-09 12:31 UTC, jeff
no flags Details
updated test case (822 bytes, text/plain)
2007-03-09 16:22 UTC, jmccann
no flags Details

Description jmccann 2007-02-26 16:26:55 UTC
Description of problem:
Was running 2.6.9-42.0.3.ELsmp.  Used up2date to install 
kernel-smp-2.6.9-42.0.8.EL.  Rebooted into new kernel.  kernel panic at about
the time it entered init 5 (at GDM screen).  Happened after every reboot with
the new kernel.  Was able to boot sucessfully into previous (2.6.9-42.0.3.ELsmp)

Version-Release number of selected component (if applicable):

How reproducible:
Every time.

Additional info:
I saw this before with 2.6.9-42.0.2.ELsmp but an update to 2.6.9-42.0.3.ELsmp
seemed to fix the problem.

Comment 1 jmccann 2007-02-26 16:26:56 UTC
Created attachment 148807 [details]
kern syslog output

Comment 2 jmccann 2007-03-07 17:40:11 UTC
Today the same crash occurred with:

Comment 3 jeff 2007-03-09 12:27:42 UTC
Created attachment 149674 [details]
panic bt

Comment 4 jeff 2007-03-09 12:31:34 UTC
Created attachment 149676 [details]
script that has never failed to reproduce bug on redhat 4 nfs server

run from solaris 8 or 9 nfs client

Comment 5 jeff 2007-03-09 12:34:50 UTC
This looks like same bug im hitting.
do you have solaris clients will ?
I've reproduced it on demand by
forcing solaris a nfs client to use nfsv2.

Comment 6 jmccann 2007-03-09 16:22:19 UTC
Created attachment 149695 [details]
updated test case

Updated the test case.	For me this reproduces the panic every time.  I didn't
even need to do a write but only a listing.

Comment 7 jmccann 2007-03-09 16:27:45 UTC
Nice job Jeff with the test case!  Yes I have Solaris 9 clients.
Bumping the severity up a bit.

Kernel dudes, any tips on what else we can do to troubleshoot this?  Thanks.

Comment 8 jeff 2007-03-09 17:16:07 UTC

disables nfsv2 and I believe works around the bug.
Dont fall for MOUNTD_NFS_V2=no it does NOT disable nfsv2.

So why are some of your solaris clients using nfsv2?

For me, my network was dropping packets (bad switch)
so Im working on the theory that this caused a  mount
request v3 to fail, so solaris fell back to nfsv2.
Does your network drop packets ?  Or some solaris clients
configured to use nfsv2 ?

Comment 9 Jason Baron 2007-03-12 17:41:16 UTC

*** This bug has been marked as a duplicate of 191831 ***

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