[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: MCM boot-up problems - possible filesystem or flash issues?



Hi.
Are you sure that your /dev/console pointing on the correct serial port? Check it in 
/any/dir/axis/e100lx_mcm/target/cris-axis-linux-gnu/dev/ .

Regards
/Magnus

-----Original Message-----
From: Fettahlioglu, Mahmut [mailto:Mahmut.Fettahlioglu@xxxxxxx.au]
Sent: den 12 december 2002 09:31
To: Axis development List (E-mail)
Subject: RE: MCM boot-up problems - possible filesystem or flash issues?


> Can you send us the output from the debug port?

The kernel sends the following to the debug port (serial port 0):

Uncompressing Linux...
Done. Now booting the kernel.
Linux version 2.4.19 (mahmut@xxxxxxx.96 20000427
(experimental)) #5 Wed Dec 11 16:36:19 EST 2002
Setting up paging and the MMU.
On node 0 totalpages: 1024
zone(0): 1024 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Linux/CRIS port on ETRAX 100LX (c) 2001, 2002 Axis Communications AB
Kernel command line: root=/dev/mtdblock3
Enabling watchdog...
Calibrating delay loop... 99.73 BogoMIPS
Memory: 7032k/8192k available (701k kernel code, 1160k reserved, 191k data,
32k init)
kmem_create: Forcing size word alignment - mm_struct
kmem_create: Forcing size word alignment - filp
Dentry cache hash table entries: 1024 (order: 0, 8192 bytes)
Inode cache hash table entries: 1024 (order: 0,8192 bytes)
kmem_create: Forcing size word alignment - inode_cache
Mount-cache hash table entries: 1024 (order: 0, 8192 bytes)
kmem_create: Forcing size word alignment - bdev_cache
kmem_create: Forcing size word alignment - cdev_cache
Buffer-cache hash table entries: 2048 (order: 0, 8192 bytes)
Page-cache hash table entries: 2048 (order: 0, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
kmem_create: Forcing size word alignment - sock
Initializing RT netlink socket
Starting kswapd
kmem_create: Forcing size word alignment - file lock cache
JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
kmem_create: Forcing size word alignment - jffs_node
kmem_create: Forcing size word alignment - blkdev_requests
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
ETRAX 100LX 10/100MBit ethernet v2.0 (c) 2000-2001 Axis Communications AB
eth0 initialized
eth0: changed MAC to 00:40:8C:CD:00:00
ETRAX 100LX serial-driver 1.40 $, (c) 2000-2002 Axis Communications AB
ttyS0 at 0xb0000060 is a builtin UART with DMA
fast_timer_init()
cse0: Probing a 0x04000000 bytes large window at 0xe0000000.
cse0: Probing for AMD compatible flash...
cse0: Found 1 x 2MiB Atmel AT49xV16x at 0x0
cse1: Probing a 0x04000000 bytes large window at 0xe4000000.
cse1: Probing for AMD compatible flash...
cse1: Found no AMD compatible device at location zero
CFI: Found no cse1 device at location zero
cse0: 0x00200000 bytes of flash memory.
Found a valid partition table at 0xf001000a-0xf0010056.
/dev/flash1 at 0x00010000, size 0x001a0000
/dev/flash2 at 0x001b0000, size 0x00050000
Adding readonly flash partition for romfs image:
/dev/flash3 at 0x0007ca1f, size 0x000f6000
Creating 4 MTD partitions on "cse0":
0x00000000-0x00010000 : "part0"
0x00010000-0x001b0000 : "part1"
0x001b0000-0x00200000 : "part2"
0x0007ca1f-0x00172a1f : "romfs"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
kmem_create: Forcing size word alignment - ip_dst_cache
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (cramfs filesystem) readonly.
Freeing unused kernel memory: 32k freed

And it hangs after that. I had a look in the kernel source and it was
looking like the kernel was hanging after calling execve() in the init()
function (os/linux/init/main.c:545). I put some debug statements just before
the kernel is trying to execute the "init" executable from one of the
possible locations. This resulted in the following lines being appended to
the debug output:

Trying to execute /sbin/init
Trying to execute /etc/init
Trying to execute /bin/init

And it hangs after that. It seems like the kernel hangs after it calls
execve() for "/bin/init". I then added some debug statements to the init
executable so that they should have been printed when the init process
starts but they never get printed. BTW, I have determined the reason for the
other problem (not being able to boot in normal bootstrap mode), and I think
that the two problems can be linked as explained below..


> >process. It just hangs without printing anything to the 
> serial port at all.
> 
> Two possible reasons:
> 
> 1. e100boot executes its own SDRAM initialization sequence 
> and the code
>    then does the same. If your arch/cris/lib/dram_init.S is incorrect
>    the SDRAMs would not be initialized correctly and the startup
>    would fail. As far as I can see the file supplied in 2.4.19 is
>    correct. Did you build your 2.4.19 tree from scratch or did you
>    upgrade an existing tree?
> 2. The BS0 pin indicates the flash buswidth for ETRAX. If that pin is
>    high the ETRAX would try to access the flash as a 32 bit flash.

I found why this happens as explained below... I built the development
environment from fresh e100lx_mcm-R1_0_0 and linux kernel 2.4.19 tarballs
and built everything from scratch.

> >0x00000000 : 0x20303034 0x20202020 0x20202020 0x33202020
> >0x00000010 : 0x33323834 0x35343239 0xbea09301 0xffff0930
> This is not correct. You expect the same data as in the fimage
> file i.e. 050f 25f0 etc. When doing memdumps you should dump
> uncached addresses (i.e. start at 0x80000000). This is because
> the boot loader runs from cache and if you dump cached memory 
> you may replace the code that prints the memory from the cache.

Yes, the flash contents after a flash write were not correct. I initially
realized that only the first 28 bytes of the flash contents were incorrect,
the rest was ok. Further investigation showed that while the client
bootloader was loading the flash image file fimage (which is 0x200018 bytes
long) to the RAM starting at address 0xc0004000, the memory was wrapping
around after 0x200000 bytes and the last 28 bytes were overwriting the start
of the buffer!!

This can be observed from the following memory dumps. The following dump is
generated by the following command while network- booting the MCM:
etrax100boot --setreg b0000000 000095f8 --setreg b0000004 00000104 --setreg
b000000c 00601515 --setreg b0000008 8000c002 --pause 20000 --setreg b0000008
8000c602 --setreg b0000008 8000c002 --setreg +0 7 --label label1 --setreg
b0000008 8000c402 --setreg b0000008 8000c002 --loop +0 label1 --setreg
b0000008 8060c202 --setreg b0000008 8000c002 --setreg b0000008 80008002
--setreg b0000030 0000ff00 --setreg b0000038 0000ff00 --file fimage c0004000
--memdump c0004000 c00040ff --memdump c0204000 c02040ff

The output is:
---------------------------------------
Using internal boot loader: INTERNAL_NW - Network boot (default).
Starting boot...


Device ID = 0xffffabb3
This bootloader was built by mahmut on Thu Dec 12 17:37:21 EST 2002.
Checksum of bootloader is 0x000a96cf
Waiting for load info.
Checksum of file is 0x00002323
Got load info.
SET_REGISTER
0xb0000000
0x000095f8
SET_REGISTER
0xb0000004
0x00000104
SET_REGISTER
0xb000000c
0x00601515
SET_REGISTER
0xb0000008
0x8000c002
PAUSE_LOOP
0x00020000
SET_REGISTER
0xb0000008
0x8000c602
SET_REGISTER
0xb0000008
0x8000c002
SET_REGISTER
0x38001f00
0x00000007
SET_REGISTER
0xb0000008
0x8000c402
SET_REGISTER
0xb0000008
0x8000c002
LOOP
0x38001f00
0x38001f5c
SET_REGISTER
0xb0000008
0x8000c402
SET_REGISTER
0xb0000008
0x8000c002
LOOP
0x38001f00
0x38001f5c
SET_REGISTER
0xb0000008
0x8000c402
SET_REGISTER
0xb0000008
0x8000c002
LOOP
0x38001f00
0x38001f5c
SET_REGISTER
0xb0000008
0x8000c402
SET_REGISTER
0xb0000008
0x8000c002
LOOP
0x38001f00
0x38001f5c
SET_REGISTER
0xb0000008
0x8000c402
SET_REGISTER
0xb0000008
0x8000c002
LOOP
0x38001f00
0x38001f5c
SET_REGISTER
0xb0000008
0x8000c402
SET_REGISTER
0xb0000008
0x8000c002
LOOP
0x38001f00
0x38001f5c
SET_REGISTER
0xb0000008
0x8000c402
SET_REGISTER
0xb0000008
0x8000c002
LOOP
0x38001f00
0x38001f5c
SET_REGISTER
0xb0000008
0x8000c402
SET_REGISTER
0xb0000008
0x8000c002
LOOP
0x38001f00
0x38001f5c
SET_REGISTER
0xb0000008
0x8060c202
SET_REGISTER
0xb0000008
0x8000c002
SET_REGISTER
0xb0000008
0x80008002
SET_REGISTER
0xb0000030
0x0000ff00
SET_REGISTER
0xb0000038
0x0000ff00
PACKET_INFO
0xc0004000
0x00200018
Checksum of file is 0x14c110f1
MEM_DUMP
0xc0004000
0xc00040ff
0xc0004000 : 0x20303034 0x20202020 0x20202020 0x33202020
0xc0004010 : 0x39313834 0x37313736 0xbf55beda 0xffff0930
0xc0004020 : 0x0e6fffff 0x00000003 0x00980d7f 0x0be0b000
0xc0004030 : 0x95f80e6f 0x0d7f0000 0xb0000000 0x0e6f0be0
0xc0004040 : 0x00000104 0x00040d7f 0x0be0b000 0x0e6f6242
0xc0004050 : 0x00601515 0x000c0d7f 0x0be0b000 0x80022e6f
0xc0004060 : 0x2f2f8060 0x00ff0000 0x23f02056 0x00402e6f
0xc0004070 : 0x1e6f0000 0x80608002 0x1f2f3661 0x00000003
0xc0004080 : 0x10003f2f 0x30160000 0x1eef050f 0x00000000
0xc0004090 : 0x050f301c 0x00202f6f 0xe0120000 0x1eef050f
0xc00040a0 : 0x00000001 0x050f3008 0x00202f6f 0x1e6f0000
0xc00040b0 : 0x00601515 0x00001f2f 0x20040080 0x23e1050f
0xc00040c0 : 0x80021e6f 0x1f2f8060 0x8000f9ff 0x00001f6f
0xc00040d0 : 0x56618000 0xc0001f6f 0x23d00000 0x0d7f1762
0xc00040e0 : 0xb0000008 0x2e6f1be1 0x00002710 0x228120ff
0xc00040f0 : 0x012e2e6f 0x3e6f0000 0x00000142 0x4e428674
MEM_DUMP
0xc0204000
0xc02040ff
0xc0204000 : 0x20303034 0x20202020 0x20202020 0x33202020
0xc0204010 : 0x39313834 0x37313736 0xbf55beda 0xffff0930
0xc0204020 : 0x0e6fffff 0x00000003 0x00980d7f 0x0be0b000
0xc0204030 : 0x95f80e6f 0x0d7f0000 0xb0000000 0x0e6f0be0
0xc0204040 : 0x00000104 0x00040d7f 0x0be0b000 0x0e6f6242
0xc0204050 : 0x00601515 0x000c0d7f 0x0be0b000 0x80022e6f
0xc0204060 : 0x2f2f8060 0x00ff0000 0x23f02056 0x00402e6f
0xc0204070 : 0x1e6f0000 0x80608002 0x1f2f3661 0x00000003
0xc0204080 : 0x10003f2f 0x30160000 0x1eef050f 0x00000000
0xc0204090 : 0x050f301c 0x00202f6f 0xe0120000 0x1eef050f
0xc02040a0 : 0x00000001 0x050f3008 0x00202f6f 0x1e6f0000
0xc02040b0 : 0x00601515 0x00001f2f 0x20040080 0x23e1050f
0xc02040c0 : 0x80021e6f 0x1f2f8060 0x8000f9ff 0x00001f6f
0xc02040d0 : 0x56618000 0xc0001f6f 0x23d00000 0x0d7f1762
0xc02040e0 : 0xb0000008 0x2e6f1be1 0x00002710 0x228120ff
0xc02040f0 : 0x012e2e6f 0x3e6f0000 0x00000142 0x4e428674
END
Exiting with code 0
---------------------------------------

I tried the same thing with the developer board. I used the following
command to generate the dump:
etrax100boot --setreg b0000000 000095f8 --setreg b0000004 00000104 --setreg
b000000c 1a200040 --setreg b0000008 00005611 --setreg b0000030 00001df0
--setreg b0000038 00001ef3 --bootfile DBG2 --file fimage c0004000 --memdump
c0004000 c00040ff --memdump c0204000 c02040ff

From the serial port of the developer board, I got the following output:
---------------------------------------
SET_REGISTER
0xB0000038
0x00001EF3
PACKET_INFO
0xC0004000
0x00200018
Checksum of file is 0x15CE690A
MEM_DUMP
0xC0004000
0xC00040FF
0xC0004000 : 0x25F0050F 0x000A0D3F 0x0D7F0000 0x0000001E
0xC0004010 : 0x0EEF0A60 0xFFFFFFFF 0x050F3008 0xFFFF0930
0xC0004020 : 0x0E6FFFFF 0x00000003 0x00980D7F 0x0BE0B000
0xC0004030 : 0x95F80E6F 0x0D7F0000 0xB0000000 0x0E6F0BE0
0xC0004040 : 0x00000104 0x00040D7F 0x0BE0B000 0x00400E6F
0xC0004050 : 0x0D7F1A20 0xB000000C 0x0E6F0BE0 0x00005611
0xC0004060 : 0x00080D7F 0x0BE0B000 0x00003E6F 0x0A630001
0xC0004070 : 0x050F0EEF 0x2066F025 0x320A050F 0x0EDF0E53
0xC0004080 : 0x205ABEEF 0x2C53050F 0x821C8662 0x16634E63
0xC0004090 : 0x01A2BD3F 0x46E00000 0x050F2044 0x1E63727F
0xC00040A0 : 0x050F200C 0x2E631668 0xE00C26A8 0x1EEF050F
0xC00040B0 : 0xFFFFFFFF 0x2E6330D4 0x4E635E63 0x43903210
0xC00040C0 : 0x050F60DD 0x60044391 0x7661050F 0x00001E2F
0xC00040D0 : 0xBD3F0001 0x000001A2 0x30C356E0 0x0E4F050F
0xC00040E0 : 0x0D7F001D 0xB0000031 0x0E4F0BC0 0x0D7F00F0
0xC00040F0 : 0xB0000030 0x0E4F0BC0 0x0D7F001E 0xB0000039
MEM_DUMP
0xC0204000
0xC02040FF
0xC0204000 : 0x20303034 0x20202020 0x20202020 0x33202020
0xC0204010 : 0x34383536 0x39333138 0x72E4091A 0xB07BB3B5
0xC0204020 : 0x602C832D 0xBCE9B8F9 0xD915BB3B 0x2E0BEC34
0xC0204030 : 0xB205418B 0xA95B1698 0x14627B04 0x2526599D
0xC0204040 : 0x88FCF992 0xF8D33918 0xBA7CC964 0x93DFCF80
0xC0204050 : 0x74F87BCC 0x13A44775 0x2EF3DCD5 0xB9A2CE6B
0xC0204060 : 0x5878BBE6 0xB60C7927 0xD07493A5 0x571970B1
0xC0204070 : 0x58FE802A 0x6F292694 0x04DCBD38 0x9620BC90
0xC0204080 : 0x477B38C8 0xABB51FC7 0xEA158875 0x60E4D499
0xC0204090 : 0xE7825CFC 0x448D7F7A 0xE7906E76 0x48191D65
0xC02040A0 : 0xBD006812 0x1524D0CA 0x6E767DD8 0x968ED082
0xC02040B0 : 0xD1156F60 0xA7DBDE12 0xE125DDF5 0x9824DA07
0xC02040C0 : 0xC5321BC1 0x1666387F 0xBF131C37 0x3398EBEF
0xC02040D0 : 0xB780B931 0x919C4A4E 0xB4296D06 0x5A85AF82
0xC02040E0 : 0xF7ACEE16 0x13DD0D31 0xFCEF73E5 0xBDE7BBDC
0xC02040F0 : 0xF3E51354 0x0AFA6435 0xFEA1160F 0xB369D8C7
END
---------------------------------------

This shows that the memory addresses 0xc0004000 and 0xc0204000 in the MCM
chip are actually pointing to the same physical memory while on the
developer board they are not.

To experiment further, I removed the last 28 bytes from the fimage file, and
I then downloaded and flashed this image file to the MCM (the last 28 bytes
were only some FF's, device id and file checksum, which did not break
anything if removed). Now, when I print the flash contents at 0x80000000, I
get exactly the same contents with the fimage file. With that flash
contents, the MCM can now boot in normal bootstrap mode as well. Of course,
it also does not get through the problem of cannot starting the "init"
process.

I think that "the problem of not being able to start the 'init' process" is
possibly linked with this situation. If the kernel expects a separate memory
at the 0xc0204000 address but this actually wraps around and overwrites the
memory at 0xc0004000 when accessed, it is normal for the machine to hang
when accessing this memory.

Is it normal for all MCMs to have this sort of memory configuration, or is
it peculiar to our board only? Our hardware engineer has told me that he has
done exactly the same thing as the serial-device example in the axis
web-site. We are not using any external RAM or flash as in that example. Do
you think we need to change something in our hardware connections, or will
changing some settings in the software fix our problem (such as the base
memory address to copy the flash image, and contigious memory blocks for the
kernel to use)?

Regards,

Mahmut

> -----Original Message-----
> From: Mikael Starvik [mailto:mikael.starvik@xxxxxxx.com]
> Sent: Wednesday, 11 December 2002 18:14
> To: 'Fettahlioglu, Mahmut'; dev-etrax
> Cc: 'fredrik.norrman@xxxxxxx.com'
> Subject: RE: MCM boot-up problems - possible filesystem or 
> flash issues?
> 
> 
> Hi,
> 
> Great that you have come this far!
> 
> > R_SDRAM_CONFIG = 00601515
> > R_SDRAM_TIMING = 80608002 (Changing this to 80008002 as 
> suggested in some
> >emails in the list did not work).
> 
> Looks correct 
> 
> >a) the file is present in the filesystem TOC but its 
> contents are invalid
> >b) the system hangs when trying to access the flash, the 
> partition, or the
> >filesystem driver
> 
> Can you send us the output from the debug port?
> 
> >A network boot using the flashitall script works well, 
> 
> The first time you should run boot_linux -F to write the rescue 
> partition.
> 
> >2- When we are not network booting, the system does not even 
> do the above
> >process. It just hangs without printing anything to the 
> serial port at all.
> 
> Two possible reasons:
> 
> 1. e100boot executes its own SDRAM initialization sequence 
> and the code
>    then does the same. If your arch/cris/lib/dram_init.S is incorrect
>    the SDRAMs would not be initialized correctly and the startup
>    would fail. As far as I can see the file supplied in 2.4.19 is
>    correct. Did you build your 2.4.19 tree from scratch or did you
>    upgrade an existing tree?
> 2. The BS0 pin indicates the flash buswidth for ETRAX. If that pin is
>    high the ETRAX would try to access the flash as a 32 bit flash.
> 
> 
> Bit 31 indicates that the cache shouldn't be used. This means
> that 0x80000000 and 0x00000000 is the same except that the cache
> is used for 0x00000000. 
> 
> >0x00000000 : 0x20303034 0x20202020 0x20202020 0x33202020
> >0x00000010 : 0x33323834 0x35343239 0xbea09301 0xffff0930
> 
> This is not correct. You expect the same data as in the fimage
> file i.e. 050f 25f0 etc. When doing memdumps you should dump
> uncached addresses (i.e. start at 0x80000000). This is because
> the boot loader runs from cache and if you dump cached memory 
> you may replace the code that prints the memory from the cache.
> 
> Good luck
> /Mikael
> 
> -----Original Message-----
> From: owner-dev-etrax@xxxxxxx.com]On">mailto:owner-dev-etrax@xxxxxxx.com]On
> Behalf Of Fettahlioglu, Mahmut
> Sent: Wednesday, December 11, 2002 7:50 AM
> To: dev-etrax
> Cc: 'fredrik.norrman@xxxxxxx.com'
> Subject: MCM boot-up problems - possible filesystem or flash issues?
> 
> 
> We have recently puchased a number of MCM chips, and built a board as
> suggested in the reference design. Now we are in a stage 
> where we can test
> their boot-up and operation, however we are having some 
> problems during the
> bootup process. I have followed the "Linux installation to 
> MCM" document
> step-by-step in order not to cause any problems, so I'm using the
> e100lx_mcm-R1_0_0 and linux kernel 2.4.19 without making any 
> modifications
> to their configurations. We are not using any external RAM or 
> flash, so I
> did not have to modify the related kernel configuration. So, 
> I'm using 
>  R_SDRAM_CONFIG = 00601515
>  R_SDRAM_TIMING = 80608002 (Changing this to 80008002 as 
> suggested in some
> emails in the list did not work).
> 
> 1- A network boot using the flashitall script works well, and 
> we can see
> that the new flash contents being written and the CPU jumping 
> to 0x00000000.
> After this, the serial port output from the MCM works ok, and 
> the kernel
> initializes without problems until it comes to the stage of 
> executing the
> "init" process. After putting some extra debug statements to 
> the relevant
> code, I've seen the kernel executing /bin/init, and the 
> system hangs there
> afterwards. I've put a debug statement to the beginning of 
> main() in the
> init process, and it never gets printed out. Possible reasons 
> I can think of
> are:
> a) the file is present in the filesystem TOC but its contents 
> are invalid
> b) the system hangs when trying to access the flash, the 
> partition, or the
> filesystem driver
> 
> 2- When we are not network booting, the system does not even 
> do the above
> process. It just hangs without printing anything to the 
> serial port at all.
> I've read that during normal bootup, the CPU jumps to 0x80000002 and
> executes instructions from there. When I've used e100boot to 
> have the CPU
> jump to  0x80000002, it hangs there either. When I use 
> e100boot to have the
> CPU jump to  0x00000000, I get the results of (1). I did a 
> memdump using
> e100boot on both these locations, and saw that 0x80000000 and 
> 0x00000000
> contain the same data, they are probably mapped to the same 
> physical memory.
> So the only difference between jumping to the two different 
> addresses is
> that the instruction at 0x0 is not executed when the CPU jumps to
> 0x80000002. This address contains the instruction "2030" as 
> shown below:
> 
> 0x00000000 : 0x20303034 0x20202020 0x20202020 0x33202020
> 0x00000010 : 0x33323834 0x35343239 0xbea09301 0xffff0930
> 0x00000020 : 0x0e6fffff 0x00000003 0x00980d7f 0x0be0b000
> 0x00000030 : 0x95f80e6f 0x0d7f0000 0xb0000000 0x0e6f0be0
> 0x00000040 : 0x00000104 0x00040d7f 0x0be0b000 0x0e6f6242
> 0x00000050 : 0x00601515 0x000c0d7f 0x0be0b000 0x80022e6f
> 0x00000060 : 0x2f2f8060 0x00ff0000 0x23f02056 0x00402e6f
> 0x00000070 : 0x1e6f0000 0x80608002 0x1f2f3661 0x00000003
> 0x00000080 : 0x10003f2f 0x30160000 0x1eef050f 0x00000000
> 0x00000090 : 0x050f301c 0x00202f6f 0xe0120000 0x1eef050f
> 0x000000a0 : 0x00000001 0x050f3008 0x00202f6f 0x1e6f0000
> 0x000000b0 : 0x00601515 0x00001f2f 0x20040080 0x23e1050f
> 0x000000c0 : 0x80021e6f 0x1f2f8060 0x8000f9ff 0x00001f6f
> 0x000000d0 : 0x56618000 0xc0001f6f 0x23d00000 0x0d7f1762
> 0x000000e0 : 0xb0000008 0x2e6f1be1 0x00002710 0x228120ff
> 0x000000f0 : 0x012e2e6f 0x3e6f0000 0x00000142 0x4e428674
> 
> I was assuming this should probably be a NOP operation, but I 
> have yet to
> investigate this as well.
> 
> Did anyone experience a similar situation? I would appreciate any
> suggestions on what's happening.
> 
> Regards,
> 
> Mahmut
>  
> --------------------------------------------------------------
> --------------
> ---------------------
> Mahmut Fettahlioglu
> Senior Software Engineer
> 
> Open Access Pty Ltd
> PO Box 301
> Crows Nest NSW 1585
>  
> Phone		02 9978 7009
> Fax		02 9978 7099
> Email		<mahmut.fettahlioglu@xxxxxxx.au>
> --------------------------------------------------------------
> --------------
> ---------------------
> This email is intended only for the use of the individual or entity
> named above and may contain information that is confidential and
> privileged. If you are not the intended recipient, you are hereby
> notified that any dissemination, distribution or copying of this
> email is strictly prohibited. If you have received this email in
> error, please notify us immediately by return email or telephone 
> 02 9978 7009 and destroy the original message.
>