Bug 166951 - copying files over a nfs mount results in oops
Summary: copying files over a nfs mount results in oops
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 3
Hardware: All Linux
medium
high
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-28 18:24 UTC by Jurgen Kramer
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-24 11:15:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Oops output from machine b, captured from killed ssh session (4.50 KB, text/plain)
2005-08-28 18:24 UTC, Jurgen Kramer
no flags Details

Description Jurgen Kramer 2005-08-28 18:24:56 UTC
Description of problem:
copying files from a nfs mount to the local filesystem results in a oops. As a
result the machine completely hangs and has to be rebooted manually.

Version-Release number of selected component (if applicable):
kernel 2.6.12-1.1372_FC3


How reproducible:
always

Steps to Reproduce:
1. ssh from source system (machine a) to target system (machine b)
2. On machine b: stop iptables
2. On machine b: mount nfs share from machine a (also FC3 with same kernel ver)
3. On machine b: copy files from machine a to local file system
4. On machine b: Oops....

Actual results:
Kernel oops

Expected results:
copy should work

Additional info:
both machines run the latest FC3 kernel and updates.

Comment 1 Jurgen Kramer 2005-08-28 18:24:56 UTC
Created attachment 118195 [details]
Oops output from machine b, captured from killed ssh session

Comment 2 Steve Dickson 2005-09-24 09:55:32 UTC
what is strange about this is the fact the server is
failing the messages with 'call_verify: RPC call version mismatch'
which means the client is either sending crap or the
message is getting corrupted...

would it be possible to get an binary tethereal trace of this?
something like 'tethereal -w /tmp/data.pcap host server'
then post the b2zipped data file.

Comment 3 Jurgen Kramer 2005-09-24 11:15:50 UTC
Meanwhile I have upgraded to kernel 1376 and today to 1378 and have not seen the
problem since. The nfs (and others btw) problem seemed to be hardware related, I
had to remove one of the memory DIMMs to prevent te system from randomly
crashing after several hours. I now runs stable again. This case can be closed,
not a nfs bug.



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