Eddie,
I checked, and yes the registers are almost identical each time
the ftp crash occurs. I also generated the following console output
to answer your questions concerning flash-size and the "dmesg"
command output ->
$ df -k
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/root 29680 13368 16312 45% /
$ dmesg
Linux version 2.4.26-ts9 (gcc version 3.3.4) #2 Tue
Oct 25 15:3
7:44 MST 2005
CPU: Arm920Tid(wb) revision 0
Machine: ep9301
On node 0 totalpages: 2048
zone(0): 2048 pages.
zone(1): 0 pages.
zone(2): 0 pages.
On node 1 totalpages: 2048
zone(0): 2048 pages.
zone(1): 0 pages.
zone(2): 0 pages.
On node 2 totalpages: 2048
zone(0): 2048 pages.
zone(1): 0 pages.
zone(2): 0 pages.
On node 3 totalpages: 2048
zone(0): 2048 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyAM0,115200 root=/dev/mtdblock1
Relocating machine vectors to 0xffff0000
Console: colour dummy device 80x30
Calibrating delay loop... 99.94 BogoMIPS
Memory: 8MB 8MB 8MB 8MB = 32MB total
Memory: 28648KB available (1191K code, 330K data, 72K init)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
CPU: Testing write buffer: pass
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12c (20020818) Richard Gooch
devfs: boot_options: 0x1
ttyAM0 at MMIO 0x808c0000 (irq = 52) is a AMBA
ttyAM1 at MMIO 0x808d0000 (irq = 54) is a AMBA
ttyAM2 at MMIO 0x808e0000 (irq = 55) is a AMBA
pty: 1024 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
enabled
Real Time Clock Driver v1.10f
ep93xx_eth() version: ep93xx_eth.c: V1.0 09/04/2003 Cirrus Logic
RAMDISK driver initialized: 16 RAM disks of 12288K size 1024 blocksize
about to do sbc_setinfo
Searching for NAND flash...
NAND device: Manufacturer ID: 0x20, Chip ID: 0x75 (ST Micro NAND
32MiB 3,3V 8-bi
t)
Scanning device for bad blocks
Bad eraseblock 1147 at 0x011ec000
Using static partition definition
Creating 3 MTD partitions on "NAND 32MiB 3,3V 8-bit":
0x00000000-0x00004000 : "TS-BOOTROM"
0x00004000-0x01d04000 : "Linux"
0x01d04000-0x02000000 : "RedBoot"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NetWinder Floating Point Emulator V0.97 (double precision)
yaffs: Attempting MTD mount on 31.1, "1f:01"
block 1146 is bad
VFS: Mounted root (yaffs filesystem).
Mounted devfs on /dev
Freeing init memory: 72K
enable_irq(39) unbalanced from c02cd254
tsuart not loading: ts7260 board not detected
ftpd: unhandled page fault at pc=0x0000d988, lr=0x0000d984 (bad
address=0x393738
39, code 5)
pc : [<0000d988>] lr : [<0000d984>] Not tainted
sp : 7fffdad0 ip : 7fffda04 fp : 7fffed18
r10: 7fffec60 r9 : 0000f04c r8 : 41d0fc2b
r7 : 519d70a4 r6 : 41d0fc2b r5 : 7fffec38 r4 : 408717b9
r3 : 39373839 r2 : 7fffed34 r1 : 000000fb r0 : 000000fb
Flags: nzcv IRQs on FIQs on Mode USER_32 Segment user
Control: C000317F Table: 007CC000 DAC: 00000015
$
Thanks, Jerry
--- In "Eddie Dawydiuk" <> wrote:
>
> Hello,
>
> > I'm getting an ftp crash when using 'get' or 'mget' to pull a
large
> > ASCII file from the TS-7250 to my Windows system. See the
following
> > dump on the linux console.
> >
> > $ cat /proc/version
> > Linux version 2.4.26-ts9 (gcc version 3.3.4) #2
Tue
> > Oct 25 15:3
> > 7:44 MST 2005
> > $
> > $ ls -l
> > -rw-r--r-- 1 root root 444 Feb 12 20:27
> > PSECS_Driver_Configuration_Info.h
> > -rw-r--r-- 1 root root 2578 Feb 12 20:27
> > PSECS_HSMS_Block_Comm.h
> > -rw-r--r-- 1 root root 10296 Feb 12 20:27
> > PSECS_Internal_Defns.h
> > -rw-r--r-- 1 root root 111736 Feb 12 20:27
> > PSECS_NonPortable_OS_Layer_Utilities.h
> > -rw-r--r-- 1 root root 5413 Feb 12 20:27
> > PSECS_Secs_I_Block_Comm.h
> > -rw-r--r-- 1 root root 5493 Feb 12 20:27
> > PSECS_Secure_Version_Info.h
> > $
> > $
> > $ in.ftpd[89]: connection from 10.10.10.10
> > in.ftpd[89]: root logged in
> > in.ftpd[89]: //backup/Include/PSECS_Driver_Configuration_Info.h
> > downloaded
> > in.ftpd[89]: //backup/Include/PSECS_HSMS_Block_Comm.h downloaded
> > in.ftpd[89]: //backup/Include/PSECS_Internal_Defns.h downloaded
> > pc : [<0000d988>] lr : [<0000d984>] Not tainted
> > sp : 7fffdad0 ip : 7fffda04 fp : 7fffed18
> > r10: 7fffec60 r9 : 0000f04c r8 : 41d0fbe7
> > r7 : bf0ccccd r6 : 41d0fbe7 r5 : 7fffec38 r4 : 40a717b9
> > r3 : 30353738 r2 : 7fffed34 r1 : 000000fb r0 : 000000fb
> > Flags: nzcv IRQs on FIQs on Mode USER_32 Segment user
> > Control: C000317F Table: 007CC000 DAC: 00000015
> >
> > The crash occurs when transferring the large 111736 byte file.
It is
> > entirely repeatable (I can't transfer this file after multiple
> > tries). Has anyone seen this, and have any
suggestions/fixes/work-
> > arounds?
>
> I've tried to reproduce this by ftping into a TS-7250 from Windows.
I used
> the windows command line ftp client as well as the Cygwin ftp
client. I
> uploaded a 127KB ASCII file as well as a 11MB ASCII file to the TS-
7250.
> Next I downloaded the two files using both clients mentioned above.
In
> both cases I was able to download the files my Windows box without a
> kernel crash... Could you provide more information? Such as the
output
> of dmesg, the size of your flash, and if the pc register always has
the
> same address when the crash occurs.
>
> Thanks,
> //Eddie
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|