Allon Stern wrote:
On Oct 10, 2008, at 2:34 AM, Loren A. Linden Levy wrote:
We have a Coldfire 5282 Lite running uClinux-2.4 from CVS that
connects to an NFS server to dump out data that is read in through the
control ports from an FPGA. This system has been working fine through
most of our tests but when we started taking real volumes of data we
found that when the output reaches a certain size the uClinux client
board hangs and we have to reboot to take more data. As one would
imagine this is not an optimum mode of running for us.
We end up with a string of print statements of the form:
nfs: RPC call returned error 14
RPC: sendmsg returned error 14
and this hangs the embedded client. I looked in asm-m68k/errno.h and
found:
#define EFAULT 14 /* Bad address */
The file size for the output is on the order of 3.5-4 MB. I am not
sure if this is the actual error, and I really have no idea
what it means. Any help or guidance would be very much appreciated.
How very odd.
I ran into a very similar situation using our custom M5282 device,
using the 2.6 kernel (8.8.8 with 11 patch)
It would happen at around 4MB of data.
At first I thought it was my custom MTD mapping driver, since I was
copying files between flash and NFS, but then I tried copying between
two NFS mounts and has the same problem, and between two flash mounts
and didn't.
In some of my debugging, I added a stack trace to my Access Error
Exception handler (in my case, it was 12: Error on data read). Here's
a stack trace:
0x0005de78 -- 0x0005de68 + 0x0010 mnt_want_write
0x0005adec -- 0x0005add0 + 0x001c touch_atime
0x00038ca0 -- 0x00038744 + 0x055c generic_file_aio_read
0x00048bea -- 0x00048b3a + 0x00b0 do_sync_read
0x00049326 -- 0x000492c2 + 0x0064 vfs_read
0x000496aa -- 0x0004966a + 0x0040 sys_read
0x000131f0 -- 0x0001316c + 0x0084 system_call
In another run, I got this:
BUG: failure at fs/nfs/write.c:364/nfs_inode_add_request()!
Kernel panic - not syncing: BUG!
Anyone else seeing NFS difficulty, particularly writing large files?
Again, this was 2.6, not 2.4 as Loren is using.
-
allon
------------------------------------------------------------------------
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
Hi,
UDP has been misbehaving for us all along. We went without UDP for
quite a while after we moved to 2.6, until I found a checksum (
http://forum.niosforum.com/forum/index.php?showtopic=8250 ) problem in
the UDP core. This got it working again and others have reported success
as well, but I still notice that the number of errors reported from the
network stack increases in line with the amount of UDP traffic.
For example, if you do an `ifconfig eth0` and look at the error count on
the "RX Packets:" and "TX Packets:" lines.. then do anything that
utilizes udp and reinspect the errors, I'm seeing that the errors climb.
So there's still something amiss in the UDP core.
Another thing worth mentioning is that the problem most definitely lies
in the UDP stuff itself and not in any particular driver. We use a
non-standard modified version of the MoreThanIP 10/100/1000 driver, yet
others using the bundled drivers see the same (or similar) probs.
Anyway, a temporary workaround on the "copying large files via NFS"
problem is to tell NFS to use TCP.
mount -t nfs 192.168.1.100:/shared/utils /mnt/utils -o tcp
This works for us, and we can copy humongous files without errors.
~ umodjm
--
Thank you,
Dennis McLeod
Software Engineer
BittWare, Inc
9 Hills Ave
Concord, NH 03301
[EMAIL PROTECTED]
603 226 0404 x514
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
