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) kernel. Version-Release number of selected component (if applicable): kernel-smp-2.6.9-42.0.8.EL 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.
Created attachment 148807 [details] kern syslog output
Today the same crash occurred with: 2.6.9-42.0.2.ELsmp 2.6.9-42.0.3.ELsmp 2.6.9-42.0.10.ELsmp
Created attachment 149674 [details] panic bt
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
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.
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.
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.
/etc/sysconfig/nfs RPCNFSDARGS="-N 2" 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 ?
*** This bug has been marked as a duplicate of 191831 ***