Feed for discussion General in project QNX Community FUSE Project.Posts for Generalpost113310: Re: heap usage command line monitorShailendra Carpenter(deleted)http://community.qnx.com/sf/go/post1133102015-02-13T14:58:11Z2015-02-13T14:58:11ZHi Yao,
I really appreciate your help. Will you be able to point me to the download page where you have placed the heap monitor hmon utility?
Thanks and Regards
Shailendra Carpenter
Panasonic Automotive Systems of AmericaShailendra Carpenter(deleted)2015-02-13T14:58:11Zpost89948: Re: qnx kernel crash analysis and qsymoopsavaneesh dwivedihttp://community.qnx.com/sf/go/post899482011-11-09T02:46:50Z2011-11-09T02:46:50Zi am getting below message on telnet session when proc nto starts.
can you please help me in understanding or getting the call stack why it is CRASHING
as soon as proc nto starts i get below message at the time of carash
Shutdown[0,0] S/C/F=10/1/5 C/D=fe01a964/fe0a1340 state(4c00)= now lock
QNX Version 6.6.0 Release 2011/06/08-14:50:25EDT KSB:effe7000
[0]PID-TID=1-1? P/T FL=00018001/08000040
[0]ASPACE=>NULL
armle context[fe09fab4]:
0000: 00000000 004de329 400001d3 ee100e15 400001d3 00000004 fe09ec04 fe0
0020: fe0a6968 fe09fb24 00000000 fe0a1234 fe0a1894 fe09faf8 fe047bf0 fc4
0040: 400001d3
instruction[fc404930]:
00 40 93 e5 04 50 93 e5 04 00 50 e0 05 10 c1 e0 10 80 bd e8 b8 c0 a0 e3
stack[fe09faf8]:
0000: 400001d3 fe047bf0 fe0a1748 fe065db0 fe0a1748 fe04d420 00010000 fe0
0020: fe0a11ec fe09ec18 00000000 00000000 fe09eb70 fe09eb70 fe0a6138 fe0
0040: fe09ec04 00000000 00000000 00000000 00000000 fe063f58 00000000 fe0
0060: 00000000 fe047cdc 00000000 fc404000 00000000 10c55878 00000004 000avaneesh dwivedi2011-11-09T02:46:50Zpost64956: Re: Error in building fuseVibi Sreenivasan(deleted)http://community.qnx.com/sf/go/post649562010-08-30T05:58:04Z2010-08-30T05:58:04ZHi,
thanks.
I am able to compile.
regards
vibiVibi Sreenivasan(deleted)2010-08-30T05:58:04Zpost64895: Re: Error in building fuseYao Zhao(deleted)http://community.qnx.com/sf/go/post648952010-08-27T20:52:27Z2010-08-27T20:52:27ZJust checked out and had a quick try.
If you want to compile on Linux host, you have to go to trunk/lib/fuse/x86-o directory. In this directory, there is a run.sh
$sh ./run.sh
$make
good luck!
yaoYao Zhao(deleted)2010-08-27T20:52:27Zpost64891: Re: Error in building fuseYao Zhao(deleted)http://community.qnx.com/sf/go/post648912010-08-27T20:46:41Z2010-08-27T20:46:41Z> Hi,
> I am following the same method as mentioned in wiki. But i am getting error.
>
> make CPULIST=x86 install
> make -j 1 -Cnto-x86-o -fGNUmakefile install
> make[1]: Entering directory `/home/vibi/fuse/qnx/qfuse/trunk/lib/fuse/nto-x86-
> o'
> AR_HOST='ar -r' AS_HOST='gcc -c' CC_HOST='gcc -c -D__LINUX__ -D__X86__ -
> D__LITTLEENDIAN__' CL_HOST='gcc -D__LINUX__ -D__X86__ -D__LITTLEENDIAN__'
> CP_HOST='/opt/qnx641/host/linux/x86/usr/bin/qnx_cp -fpc ' DATE_HOST='/bin/date
> +%Y/%m/%d-%T-%Z' ECHO_HOST='/bin/echo' FL_HOST='/opt/qnx641/target/qnx6/usr/
> include/mk/flist-unix' GCC_VERSION='4.3.3' HOST_HOST='/bin/hostname'
> INSTALL_ROOT_AR='/home/vibi/fuse/qnx/qfuse/trunk/install/x86'
> INSTALL_ROOT_ARSHR='/home/vibi/fuse/qnx/qfuse/trunk/install/x86'
> INSTALL_ROOT_DLL='/home/vibi/fuse/qnx/qfuse/trunk/install/x86' INSTALL_ROOT_EX
> ='/home/vibi/fuse/qnx/qfuse/trunk/install/x86' INSTALL_ROOT_HDR='/home/vibi/
> fuse/qnx/qfuse/trunk/install/usr/include' INSTALL_ROOT_SO='/home/vibi/fuse/qnx
> /qfuse/trunk/install/x86' INSTALL_ROOT_linux='' INSTALL_ROOT_nto='/home/vibi/
> fuse/qnx/qfuse/trunk/install' KSH_HOST='/opt/qnx641/host/linux/x86/usr/bin/
> ksh' LD_HOST='gcc' LN_HOST='/bin/ln -sf ' MG_HOST='/bin/true' MKASMOFF_HOST='/
> opt/qnx641/host/linux/x86/usr/bin/mkasmoff ' MP_HOST='/opt/qnx641/target/qnx6/
> usr/include/mk/makepriv-unix' PB_HOST='/opt/qnx641/host/linux/x86/usr/bin/
> phabbind' PINFO_DATE='2010/08/20-20:12:54-IST' PINFO_HOST='QnX-vibi'
> PINFO_STATE='automation' PINFO_TAGID='9999' PINFO_USER='vibi' PWD_HOST='/bin/
> pwd' QNX_HOST='/opt/qnx641/host/linux/x86' RM_HOST='/bin/rm -f ' TOUCH_HOST='/
> bin/touch' UM_HOST='/opt/qnx641/host/linux/x86/usr/bin/usemsg' USER_HOST='/usr
> /bin/id -un' VERSION_REL='testbuilds' QNXVFLAGS='' QNXROOTINCS='-I/home/vibi/
> fuse/qnx/qfuse/trunk/install/usr/include -I/opt/qnx641/target/qnx6/usr/
> include' QNXROOTLIBS='-L/home/vibi/fuse/qnx/qfuse/trunk/install/x86/lib -L/
> home/vibi/fuse/qnx/qfuse/trunk/install/x86/usr/lib -L/opt/qnx641/target/qnx6/
> x86/lib -L/opt/qnx641/target/qnx6/x86/usr/lib' /opt/qnx641/host/linux/x86/usr/
> bin/ksh /opt/qnx641/target/qnx6/usr/include/mk/build-cfg install
> Building for target: nto-x86-o build:i386-pc-nto-qnx2.6.31-21-generic
> checking build system type... Invalid configuration `i386-pc-nto-qnx2.6.31-21-
> generic': machine `i386-pc-nto-qnx2.6.31-21' not recognized
> configure: error: /bin/sh ../config.sub i386-pc-nto-qnx2.6.31-21-generic
> failed
> /opt/qnx641/target/qnx6/usr/include/mk/build-cfg: error: configure failed
> make[1]: *** [install] Error 1
> make[1]: Leaving directory `/home/vibi/fuse/qnx/qfuse/trunk/lib/fuse/nto-x86-
> o'
> make: *** [install] Error 2
>
>
> Is this a known one ?
>
> Thanks & Regards
> vibi
>
I can't remember whether I support compiling on Linux host any more. At the beginning I use Linux host to port, compiling and after some time when multiplatform is added, I may drop Linux host but I can't remember.
At least it can be compiled on QNX host.
thanks,
yaoYao Zhao(deleted)2010-08-27T20:46:41Zpost63734: Error in building fuseVibi Sreenivasan(deleted)http://community.qnx.com/sf/go/post637342010-08-20T14:46:44Z2010-08-20T14:46:44ZHi,
I am following the same method as mentioned in wiki. But i am getting error.
make CPULIST=x86 install
make -j 1 -Cnto-x86-o -fGNUmakefile install
make[1]: Entering directory `/home/vibi/fuse/qnx/qfuse/trunk/lib/fuse/nto-x86-o'
AR_HOST='ar -r' AS_HOST='gcc -c' CC_HOST='gcc -c -D__LINUX__ -D__X86__ -D__LITTLEENDIAN__' CL_HOST='gcc -D__LINUX__ -D__X86__ -D__LITTLEENDIAN__' CP_HOST='/opt/qnx641/host/linux/x86/usr/bin/qnx_cp -fpc ' DATE_HOST='/bin/date +%Y/%m/%d-%T-%Z' ECHO_HOST='/bin/echo' FL_HOST='/opt/qnx641/target/qnx6/usr/include/mk/flist-unix' GCC_VERSION='4.3.3' HOST_HOST='/bin/hostname' INSTALL_ROOT_AR='/home/vibi/fuse/qnx/qfuse/trunk/install/x86' INSTALL_ROOT_ARSHR='/home/vibi/fuse/qnx/qfuse/trunk/install/x86' INSTALL_ROOT_DLL='/home/vibi/fuse/qnx/qfuse/trunk/install/x86' INSTALL_ROOT_EX='/home/vibi/fuse/qnx/qfuse/trunk/install/x86' INSTALL_ROOT_HDR='/home/vibi/fuse/qnx/qfuse/trunk/install/usr/include' INSTALL_ROOT_SO='/home/vibi/fuse/qnx/qfuse/trunk/install/x86' INSTALL_ROOT_linux='' INSTALL_ROOT_nto='/home/vibi/fuse/qnx/qfuse/trunk/install' KSH_HOST='/opt/qnx641/host/linux/x86/usr/bin/ksh' LD_HOST='gcc' LN_HOST='/bin/ln -sf ' MG_HOST='/bin/true' MKASMOFF_HOST='/opt/qnx641/host/linux/x86/usr/bin/mkasmoff ' MP_HOST='/opt/qnx641/target/qnx6/usr/include/mk/makepriv-unix' PB_HOST='/opt/qnx641/host/linux/x86/usr/bin/phabbind' PINFO_DATE='2010/08/20-20:12:54-IST' PINFO_HOST='QnX-vibi' PINFO_STATE='automation' PINFO_TAGID='9999' PINFO_USER='vibi' PWD_HOST='/bin/pwd' QNX_HOST='/opt/qnx641/host/linux/x86' RM_HOST='/bin/rm -f ' TOUCH_HOST='/bin/touch' UM_HOST='/opt/qnx641/host/linux/x86/usr/bin/usemsg' USER_HOST='/usr/bin/id -un' VERSION_REL='testbuilds' QNXVFLAGS='' QNXROOTINCS='-I/home/vibi/fuse/qnx/qfuse/trunk/install/usr/include -I/opt/qnx641/target/qnx6/usr/include' QNXROOTLIBS='-L/home/vibi/fuse/qnx/qfuse/trunk/install/x86/lib -L/home/vibi/fuse/qnx/qfuse/trunk/install/x86/usr/lib -L/opt/qnx641/target/qnx6/x86/lib -L/opt/qnx641/target/qnx6/x86/usr/lib' /opt/qnx641/host/linux/x86/usr/bin/ksh /opt/qnx641/target/qnx6/usr/include/mk/build-cfg install
Building for target: nto-x86-o build:i386-pc-nto-qnx2.6.31-21-generic
checking build system type... Invalid configuration `i386-pc-nto-qnx2.6.31-21-generic': machine `i386-pc-nto-qnx2.6.31-21' not recognized
configure: error: /bin/sh ../config.sub i386-pc-nto-qnx2.6.31-21-generic failed
/opt/qnx641/target/qnx6/usr/include/mk/build-cfg: error: configure failed
make[1]: *** [install] Error 1
make[1]: Leaving directory `/home/vibi/fuse/qnx/qfuse/trunk/lib/fuse/nto-x86-o'
make: *** [install] Error 2
Is this a known one ?
Thanks & Regards
vibiVibi Sreenivasan(deleted)2010-08-20T14:46:44Zpost42454: Re: Project Status of FUSE?Yao Zhao(deleted)http://community.qnx.com/sf/go/post424542009-11-24T04:13:59Z2009-11-24T04:13:59Z>
> Can anyone provide the current status of this project? What works vs. what
> does not?
>
> It certainly looks promising and I'd be interested in the road map for its
> continued development.
>
> Thanks . . .
For a long time I didn't work on QFUSE, sorry for that. For some reason ...
ntfs-3g works mostly and ext2 works too but not quite stable like ntfs-3g. Once a time I want to rewrite it as I think it should be faster and Linux' ext2 code is there, easy to reference but work makes me crazy sometime.
Didn't start zfsfuse port too much as I am not familiar with its compiling environment and there are problems with these tools on QNX.
It is really a nice one which supports so many filesystems but...
I want to focus on my major network for a while.
welcome everyone to fix, port for QFUSE.Yao Zhao(deleted)2009-11-24T04:13:59Zpost42359: Project Status of FUSE?Glenn Schmottlachhttp://community.qnx.com/sf/go/post423592009-11-21T17:07:37Z2009-11-21T17:07:37ZCan anyone provide the current status of this project? What works vs. what does not?
It certainly looks promising and I'd be interested in the road map for its continued development.
Thanks . . .Glenn Schmottlach2009-11-21T17:07:37Zpost40800: Re: qnet protocol dissector for ethereal/wiresharkYao Zhao(deleted)http://community.qnx.com/sf/go/post408002009-10-27T15:53:21Z2009-10-27T15:53:21Z> Hi Yao,
> Please send me the dissector. That would be very helpful for me. You can send
> me in whatever state it is now, If I am able to add something to it, I can do
> that and send it across to u.
> Thanks
> Lalit
Hi,
I put the files under this http://community.qnx.com/svn/repos/qfuse/trunk/utils/w/wireshark.
You need to check out wireshark source by yourself from wireshark svn then apply the files here. If you can contribute more then that will be great. Don't forget to read the doc/README.developer before you want to contribute:) Their code is pretty good and very strict.Yao Zhao(deleted)2009-10-27T15:53:21Zpost40733: Re: qnet protocol dissector for ethereal/wiresharkLalit Kolihttp://community.qnx.com/sf/go/post407332009-10-27T05:40:04Z2009-10-27T05:40:04ZHi Yao,
Please send me the dissector. That would be very helpful for me. You can send me in whatever state it is now, If I am able to add something to it, I can do that and send it across to u.
Thanks
LalitLalit Koli2009-10-27T05:40:04Zpost40675: Re: qnet protocol dissector for ethereal/wiresharkYao Zhao(deleted)http://community.qnx.com/sf/go/post406752009-10-26T13:49:31Z2009-10-26T13:49:31Z> Hi Yao,
>
> Can you please send me the packet format and the sequence for QNet?
> Please share if any document regarding the Qnet protocol in detail.
I don't have any document and the only document is the source code of qnet on foundry27. If you need the dissector I can post here although I didn't finish it yet.Yao Zhao(deleted)2009-10-26T13:49:31Zpost40590: Re: qnet protocol dissector for ethereal/wiresharkLalit Kolihttp://community.qnx.com/sf/go/post405902009-10-23T11:13:46Z2009-10-23T11:13:46ZHi Yao,
Can you please send me the packet format and the sequence for QNet?
Please share if any document regarding the Qnet protocol in detail.Lalit Koli2009-10-23T11:13:46Zpost38381: Re: qnx kernel crash analysis and qsymoopsYao Zhao(deleted)http://community.qnx.com/sf/go/post383812009-09-18T21:04:45Z2009-09-18T21:04:45ZSorry for late reply, too busy.
qsymoops -f ./dump.txt -s $QNX_TARGET/armle/boot/sys/procnto > dump1ee.txt
the fault instruction is
str r0, [r4] but r4 is r4: 0xfc4696d8
I didn't understand why is not alignment.
sometimes it could be cpu fault(I can't remember which arm board, cpu has prefetch problem), I didn't read this function's disassembly to see whether other registers really make sense.
armle context[fc45691c]:
Platform:armle endian:little
=========================================
QNX Version 6.4.0 Release 2008/10/21-10:59:12
QNX Version:6.4.0 Release timestamp:2008/10/21-10:59:12EDT.
=========================================
Shutdown[0,0]
Shutdown run on cpu 0, kernel cpu:0
=========================================
S/C/F=10/1/0
Signal :10 SIGBUS bus error
Code :1 BUS_ADRALN Invalid address alignment
Fault code:0 Unknown There is no this fault code
=========================================
S/C/F=10/1/0
=========================================
C/D=fe0156cc/fe0783e8
Location of the kernel's code(main):0xfe0156cc data(actives[]):0xfe0783e8
=========================================
state(f0)= now lock exit
state(f0)= now lock exit specret
Explanation of state of the kernel:
* now -- in the kernel
* lock -- nonpreemptible
* exit -- leaving kernel
* specret -- special return processing
* any number -- the interrupt nesting level.
=========================================
[0]PID-TID=1-7
The thread 7 of process 1 run on CPU 0 when the crash occurred.
=========================================
P/T FL=00019001/05020000 "proc/boot/procnto"
Process flags:0x19001.
0x00000001: _NTO_PF_NOCLDSTOP
0x00001000: _NTO_PF_CHECK_INTR Only set by interrupt_attach_*
0x00008000: _NTO_PF_RING0 Ring0 access(only process manager process)
0x00010000: _NTO_PF_SLEADER
+========
0x00019001
Thread flags :0x05020000.
0x00020000: _NTO_TF_DETACHED
0x01000000: _NTO_TF_ALIGN_FAULT
0x04000000: _NTO_TF_ALLOCED_STACK
+========
0x05020000
Process :proc/boot/procnto".
=========================================
[0]ASPACE PID=2
On CPU 0, the address space for process 2 was active.
This line appears only when the process is different from the one in the PID-TID\
line.
=========================================
armle context[fc45691c]:
Platform:armle Stored register map address:fc45691c
r0: 0x00000000 r1: 0xfc46977c r2: 0xfffff9e0 r3: 0xfc4696dc
r4: 0xfc4696d8 r5: 0xfc460060 r6: 0xfc4696dc r7: 0xfe06410c
r8: 0xfc7d3fc0 r9: 0x00000000 r10: 0xfc460360 r11(fp): 0xfc7d3f7c
r12(ip): 0x0000000e r13(sp): 0xfc7d3f5c r14(lr): 0xfe061118 r15(pc): 0xfe0611\
1c
spsr: 0x0000001f
=========================================
instruction[fe06111c]:
Current instruction address(pc):0xfe06111c and machine code:
00 00 84 e5 e3 ff ff 1a 48 31 00 eb 00 30 90 e5 41 0f 53 e3 00 40 a0 13 d6 ff
Current ip(0xfe06111c) in image is address (0x5211c), it is in function: dispatc\
h_block_receive_all(0x52040) [dispatch_block_receive_all+0xdc]
00052040 <dispatch_block_receive_all>:
52040: e1a0c00d mov ip, sp
52044: e92dd8f0 push {r4, r5, r6, r7, fp, ip, lr, pc}
52048: e24cb004 sub fp, ip, #4 ; 0x4
5204c: e24dd004 sub sp, sp, #4 ; 0x4
52050: e5905038 ldr r5, [r0, #56]
52054: e1a04000 mov r4, r0
52058: e5953018 ldr r3, [r5, #24]
5205c: e1a07001 mov r7, r1
52060: e3130004 tst r3, #4 ; 0x4
52064: 1a000038 bne 5214c <dispatch_block_receive_all+0x10c>
52068: e595302c ldr r3, [r5, #44]
5206c: e3530000 cmp r3, #0 ; 0x0
52070: 0a000009 beq 5209c <dispatch_block_receive_all+0x5c>
52074: e593302c ldr r3, [r3, #44]
52078: e3530000 cmp r3, #0 ; 0x0
520e4: e08c1001 add r1, ip, r1
520e8: ebfffffe bl 550f0 <MsgRead_r>
520e8: R_ARM_PC24 MsgRead_r
520ec: e3500000 cmp r0, #0 ; 0x0
520f0: e2601000 rsb r1, r0, #0 ; 0x0
520f4: aa00000f bge 52138 <dispatch_block_receive_all+0xf8>
520f8: e5940000 ldr r0, [r4]
520fc: ebfffffe bl 55070 <MsgError>
520fc: R_ARM_PC24 MsgError
52100: e5941034 ldr r1, [r4, #52]
52104: e5942044 ldr r2, [r4, #68]
52108: e1a03006 mov r3, r6
5210c: e595001c ldr r0, [r5, #28]
52110: e1a0e00f mov lr, pc
52114: e1a0f007 mov pc, r7
52118: e3700001 cmn r0, #1 ; 0x1
5211c: e5840000 str r0, [r4]
52120: 1affffe3 bne 520b4 <dispatch_block_receive_all+0x74>
52124: ebfffffe bl 5e64c <__get_errno_ptr>
52124: R_ARM_PC24 __get_errno_ptr
52128: e5903000 ldr r3, [r0]
5212c: e3530f41 cmp r3, #260 ; 0x104
52130: 13a04000 movne r4, #0 ; 0x0
52134: eaffffd6 b 52094 <dispatch_block_receive_all+0x54>
52138: e5943020 ldr r3, [r4, #32]
5213c: e0833000 add r3, r3, r0
52140: e1a00004 mov r0, r4
52144: e5843020 str r3, [r4, #32]
52148: e89da8f8 ldm sp, {r3, r4, r5, r6, r7, fp, sp, pc}
5214c: e3a0c000 mov ip, #0 ; 0x0
52150: e1a0200c mov r2, ip
52154: e3a00002 mov r0, #2 ; 0x2
=========================================
stack[fc7d3f5c]:
Current stack pointer:0xfc7d3f5c
0xfc7d3f5c: 0xfc4696d8 0xfc4696d8 0xfc460db8 0xfc4696d8
0xfc7d3f6c: 0xfc460364 0xfc7d3fbc 0xfc7d3f80 0xfe060920
0xfc7d3f7c: 0xfe061050 0x00000000 0xfe060584 0xfc7d3f8c
0xfc7d3f8c: 0xfc460db8 0xfc4696d8 0x00000001 0x00000000
0xfc7d3f9c: 0x00000000 0x00000000 0x00000000 0x00000000
0xfc7d3fac: 0x00000000 0x00000000 0xfc7d3fc0 0xfe072710
0xfc7d3fbc: 0xfe060878 0xfe072710 0xfc460db8 0xfc7d3fcc
0xfc7d3fcc: 0x00000003 0x00000000 0x00000001 0x00000007
backtrace:
#0 0xfe060920 in _thread_pool_thread ()
9. 0x1 in ?? ()
11. 0x3 in ?? ()
12. 0x7 in ?? ()
13. 0xfc460364 in ?? ()
14. 0xfc460db8 in ?? ()
17. 0xfc4696d8 in ?? ()
21. 0xfc7d3f80 in ?? ()
22. 0xfc7d3f8c in ?? ()
23. 0xfc7d3fbc in ?? ()
24. 0xfc7d3fc0 in ?? ()
25. 0xfc7d3fcc in ?? ()
26. 0xfe060584 in _thread_cleanup ()
27. 0xfe060878 in _thread_pool_thread ()
28. 0xfe060920 in _thread_pool_thread ()
29. 0xfe061050 in dispatch_block_receive_all ()
30. 0xfe072710 in __my_thread_exit ()
> I met with some problem with my own board. ATMEL9260 running QNX6.4.0. below
> is kernel dump,
> Thanks in advance.
>
> Weiguo
>
> Shutdown[0,0] S/C/F=10/1/0 C/D=fe0156cc/fe0783e8 state(f0)= now lock exit
> specret
> QNX Version 6.4.0 Release 2008/10/21-10:59:12EDT
> [0]PID-TID=1-7 P/T FL=00019001/05020000 "proc/boot/procnto"
> [0]ASPACE PID=2 PF=00018012
> armle context[fc45691c]:
> 0000: 00000000 fc46977c fffff9e0 fc4696dc fc4696d8 fc460060 fc4696dc fe06410c
> 0020: fc7d3fc0 00000000 fc460360 fc7d3f7c 0000000e fc7d3f5c fe061118 fe06111c
> 0040: 0000001f
> instruction[fe06111c]:
> 00 00 84 e5 e3 ff ff 1a 48 31 00 eb 00 30 90 e5 41 0f 53 e3 00 40 a0 13 d6 ff
>
> stack[fc7d3f5c]:
> 0000: fc4696d8 fc4696d8 fc460db8 fc4696d8 fc460364 fc7d3fbc fc7d3f80 fe060920
> 0020: fe061050 00000000 fe060584 fc7d3f8c fc460db8 fc4696d8 00000001 00000000
> 0040: 00000000 00000000 00000000 00000000 00000000 00000000 fc7d3fc0 fe072710
> 0060: fe060878 fe072710 fc460db8 fc7d3fcc 00000003 00000000 00000001 00000007
>
>Yao Zhao(deleted)2009-09-18T21:04:45Zpost38081: Re: qnx kernel crash analysis and qsymoopsWeiguo Chenhttp://community.qnx.com/sf/go/post380812009-09-16T16:14:33Z2009-09-16T16:14:33ZI met with some problem with my own board. ATMEL9260 running QNX6.4.0. below is kernel dump,
Thanks in advance.
Weiguo
Shutdown[0,0] S/C/F=10/1/0 C/D=fe0156cc/fe0783e8 state(f0)= now lock exit specret
QNX Version 6.4.0 Release 2008/10/21-10:59:12EDT
[0]PID-TID=1-7 P/T FL=00019001/05020000 "proc/boot/procnto"
[0]ASPACE PID=2 PF=00018012
armle context[fc45691c]:
0000: 00000000 fc46977c fffff9e0 fc4696dc fc4696d8 fc460060 fc4696dc fe06410c
0020: fc7d3fc0 00000000 fc460360 fc7d3f7c 0000000e fc7d3f5c fe061118 fe06111c
0040: 0000001f
instruction[fe06111c]:
00 00 84 e5 e3 ff ff 1a 48 31 00 eb 00 30 90 e5 41 0f 53 e3 00 40 a0 13 d6 ff
stack[fc7d3f5c]:
0000: fc4696d8 fc4696d8 fc460db8 fc4696d8 fc460364 fc7d3fbc fc7d3f80 fe060920
0020: fe061050 00000000 fe060584 fc7d3f8c fc460db8 fc4696d8 00000001 00000000
0040: 00000000 00000000 00000000 00000000 00000000 00000000 fc7d3fc0 fe072710
0060: fe060878 fe072710 fc460db8 fc7d3fcc 00000003 00000000 00000001 00000007Weiguo Chen2009-09-16T16:14:33Zpost37863: Re: qnx kernel crash analysis and qsymoopsYao Zhao(deleted)http://community.qnx.com/sf/go/post378632009-09-13T04:38:56Z2009-09-13T04:38:56Z> Just read my code: and it is not safe because when I read the data I am using
> le32_to_cpu to read the unsigned long, that is the only bad point if you can
> recompile the gen subdirectory to get the new demo_dat.c
> I changed it to unsigned int now then default demo_dat.c should work on a 64
> bit platform and which I got from 32 bits platform.
> the default demo_dat.c supports most only no ppcle and shbe so you don't need
> to recompile "gen" subdirectory to get the demo_dat.c again.
I was wrong!
I didn't read the pointer convert part. Code is updated but didn't test.Yao Zhao(deleted)2009-09-13T04:38:56Zpost37786: Re: qnx kernel crash analysis and qsymoopsYao Zhao(deleted)http://community.qnx.com/sf/go/post377862009-09-10T21:08:55Z2009-09-10T21:08:55ZJust read my code: and it is not safe because when I read the data I am using le32_to_cpu to read the unsigned long, that is the only bad point if you can recompile the gen subdirectory to get the new demo_dat.c
I changed it to unsigned int now then default demo_dat.c should work on a 64 bit platform and which I got from 32 bits platform.
the default demo_dat.c supports most only no ppcle and shbe so you don't need to recompile "gen" subdirectory to get the demo_dat.c again.Yao Zhao(deleted)2009-09-10T21:08:55Zpost37766: Re: qnx kernel crash analysis and qsymoopsYao Zhao(deleted)http://community.qnx.com/sf/go/post377662009-09-10T17:20:43Z2009-09-10T17:20:43Zprobably you have to define __USE_BSD when you compile, __bswap_32 is defined in /usr/include/bits/byteswap.h and included by endian.h.
I am not sure why on x86_64 no __USE_BSD defined.
should be safe, I greped "long" and only one place in my code is using unsigned long for address, on 64 bits Linux I know long is 64 bits and int is still 32 bits. when I defined the address as unsigned long I want it support when QNX supports 64 bits. but don't have a chance yet.
should be safe on 64bits but I didn't test on 64 bits Linux.
what will be our definition for long when 64 bits coming? I heard Windows use it as 32 still.
Yao
> Hi Yao,
>
> It doesn't link on linux - no __bswap_32
>
> Also, is it 64bit safe? I had to make the following change on x86_64 linux
>
> Index: Makefile
> ===================================================================
> --- Makefile (revision 16)
> +++ Makefile (working copy)
> @@ -4,6 +4,10 @@
> # on newer version it will return long machine name for -p.
> HOSTARCH := $(shell uname -m | sed -e 's/i.86/x86/g' -e 's/sh.*/sh/' \
> -e 's/x86pc/x86/' )
> +ifeq ($(HOSTARCH),x86_64)
> + HOSTARCH=x86
> + CFLAGS+=-m32
> +endif
> ifeq ($(ARCH),)
> ARCH := $(HOSTARCH)
> CROSS_COMPILE :=
>
> Yao Zhao wrote:
> > Here is too silent.
> >
> > I wrote a utility "qcrash/qsymoops" to analyze/decode qnx kernel dump in
> 2006 and added some features like backtrace, machine code to assembly code to
> it in 2008.
> >
> > Here is the link for it:
> > http://sourceforge.net/projects/qcrash/
> > currently it can show backtrace of ppcbe,x86,shle,armle,armbe but no mips
> support yet as I never try mips at qnx yet although used to use sb1250,1125
> for Linux 32/64 mips.
> > If you have qnx kernel crash/dump and if you are ok to publish it here, I
> can help a little bit(I am not a kernel developer so the help will be limited)
> or you can help yourself with qcrash/qsymoops.
> > There are still some cases it can't help too much as sometimes kernel
> crashes very strange and it is out of my mind(I can add more code to handle
> this). Or the printed kernel stack is too small not enough to show backtrace
> and you will only see pc there.
> >
> > If you ever developed LInux kernel probably you know why I name it to
> qsymoops although recent Linux kernel doesn't have to use an external tool to
> analyze its kernel dump, it is showed by kernel itself.
> >
> > kernel dump is some texts so sometimes it may not analyze it correctly and
> you may have to make the dump neat to make qsymoops to understand better. I am
> not quite familiar with regexp so probably you can improve it.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> >
> > General
> > http://community.qnx.com/sf/go/post36914
> >
>
> --
> cburgess@qnx.comYao Zhao(deleted)2009-09-10T17:20:43Zpost37755: Re: qnx kernel crash analysis and qsymoopsColin Burgess(deleted)http://community.qnx.com/sf/go/post377552009-09-10T16:47:56Z2009-09-10T16:47:56ZHi Yao,
It doesn't link on linux - no __bswap_32
Also, is it 64bit safe? I had to make the following change on x86_64 linux
Index: Makefile
===================================================================
--- Makefile (revision 16)
+++ Makefile (working copy)
@@ -4,6 +4,10 @@
# on newer version it will return long machine name for -p.
HOSTARCH := $(shell uname -m | sed -e 's/i.86/x86/g' -e 's/sh.*/sh/' \
-e 's/x86pc/x86/' )
+ifeq ($(HOSTARCH),x86_64)
+ HOSTARCH=x86
+ CFLAGS+=-m32
+endif
ifeq ($(ARCH),)
ARCH := $(HOSTARCH)
CROSS_COMPILE :=
Yao Zhao wrote:
> Here is too silent.
>
> I wrote a utility "qcrash/qsymoops" to analyze/decode qnx kernel dump in 2006 and added some features like backtrace, machine code to assembly code to it in 2008.
>
> Here is the link for it:
> http://sourceforge.net/projects/qcrash/
> currently it can show backtrace of ppcbe,x86,shle,armle,armbe but no mips support yet as I never try mips at qnx yet although used to use sb1250,1125 for Linux 32/64 mips.
> If you have qnx kernel crash/dump and if you are ok to publish it here, I can help a little bit(I am not a kernel developer so the help will be limited) or you can help yourself with qcrash/qsymoops.
> There are still some cases it can't help too much as sometimes kernel crashes very strange and it is out of my mind(I can add more code to handle this). Or the printed kernel stack is too small not enough to show backtrace and you will only see pc there.
>
> If you ever developed LInux kernel probably you know why I name it to qsymoops although recent Linux kernel doesn't have to use an external tool to analyze its kernel dump, it is showed by kernel itself.
>
> kernel dump is some texts so sometimes it may not analyze it correctly and you may have to make the dump neat to make qsymoops to understand better. I am not quite familiar with regexp so probably you can improve it.
>
>
>
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post36914
>
--
cburgess@qnx.comColin Burgess(deleted)2009-09-10T16:47:56Zpost36917: heap usage command line monitorYao Zhao(deleted)http://community.qnx.com/sf/go/post369172009-08-30T14:47:44Z2009-08-30T14:47:44ZI wrote a heap usage command line monitor hmon which can monitor libc's malloc statistics data.
It will be very useful when IDE can't be used or you don't want to use IDE, I didn't read how IDE implemented its malloc information but I can guess.
source is in qfuse->trunk->utils->h->hmon
help yourself.Yao Zhao(deleted)2009-08-30T14:47:44Zpost36914: qnx kernel crash analysis and qsymoopsYao Zhao(deleted)http://community.qnx.com/sf/go/post369142009-08-29T12:29:38Z2009-08-29T12:29:38ZHere is too silent.
I wrote a utility "qcrash/qsymoops" to analyze/decode qnx kernel dump in 2006 and added some features like backtrace, machine code to assembly code to it in 2008.
Here is the link for it:
http://sourceforge.net/projects/qcrash/
currently it can show backtrace of ppcbe,x86,shle,armle,armbe but no mips support yet as I never try mips at qnx yet although used to use sb1250,1125 for Linux 32/64 mips.
If you have qnx kernel crash/dump and if you are ok to publish it here, I can help a little bit(I am not a kernel developer so the help will be limited) or you can help yourself with qcrash/qsymoops.
There are still some cases it can't help too much as sometimes kernel crashes very strange and it is out of my mind(I can add more code to handle this). Or the printed kernel stack is too small not enough to show backtrace and you will only see pc there.
If you ever developed LInux kernel probably you know why I name it to qsymoops although recent Linux kernel doesn't have to use an external tool to analyze its kernel dump, it is showed by kernel itself.
kernel dump is some texts so sometimes it may not analyze it correctly and you may have to make the dump neat to make qsymoops to understand better. I am not quite familiar with regexp so probably you can improve it.Yao Zhao(deleted)2009-08-29T12:29:38Zpost36913: qnet protocol dissector for ethereal/wiresharkYao Zhao(deleted)http://community.qnx.com/sf/go/post369132009-08-29T11:57:27Z2009-08-29T11:57:27ZHere is too silent.
I spent some time on reading qnet code and wrote a packet dissector for wireshark to analyze qnet packets(not finished yet)
below is a one of the packets and later I will post a picture here.
Frame 1 (184 bytes on wire, 184 bytes captured)
Arrival Time: Aug 27, 2009 14:05:14.284193000
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 184 bytes
Capture Length: 184 bytes
[Frame is marked: False]
[Protocols in frame: eth:l4]
Ethernet II, Src: Vmware_6e:00:0a (00:0c:29:6e:00:0a), Dst: IntelCor_bf:a4:c5 (00:1c:c0:bf:a4:c5)
Destination: IntelCor_bf:a4:c5 (00:1c:c0:bf:a4:c5)
Address: IntelCor_bf:a4:c5 (00:1c:c0:bf:a4:c5)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: Vmware_6e:00:0a (00:0c:29:6e:00:0a)
Address: Vmware_6e:00:0a (00:0c:29:6e:00:0a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: QNX 6 QNET protocol (0x8204)
QNX6 QNET L4 protocol
version: L4 little endian (42)
type: L4 Lan Resolver packets (0x0b)
flag: 0x03 (First Fragment) (Last Fragment)
.... ...1 = first: Yes
.... ..1. = last: Yes
.... .0.. = crc: Not used
layer: Lan Resolver (2)
qos information
src_nd_for_dst: 0
dst_nd_for_src: 0
sconn: 0x00000000
dconn: 0x00000000
seq: 0
qos_type: Load balance (0)
src_qos_idx: 0
offset: 0
length: 132
crc: 0x00000008
QNX6 QNET LR protocol
version: 1 (1)
type: Reply (0x02)
length: 132
source: source node information
name_offset: 4 (EA6e0a)
name_len: 7
domain_offset: 11 (ott.qnx.com)
domain_len: 12
addr_offset: 23 (00:0c:29:6e:00:0a)
addr_len: 16
destination: destination node information
name_offset: 39 (EAbfa4c5)
name_len: 9
domain_offset: 48 (ott.qnx.com)
domain_len: 12
addr_offset: 60 (00:1c:c0:bf:a4:c5)
addr_len: 16
another one LR request:
QNX6 QNET L4 protocol
version: L4 little endian (42)
type: L4 Lan Resolver packets (0x0b)
flag: 0x03 (First Fragment) (Last Fragment)
.... ...1 = first: Yes
.... ..1. = last: Yes
.... .0.. = crc: Not used
layer: Lan Resolver (2)
qos information
src_nd_for_dst: 0
dst_nd_for_src: 0
sconn: 0x00000000
dconn: 0x00000000
seq: 0
qos_type: Load balance (0)
src_qos_idx: 0
offset: 0
length: 114
crc: 0x07f34d60
QNX6 QNET LR protocol
version: 1 (1)
type: Request (0x01)
length: 114
source: source node information
src_name_offset: 4 (EA6e0a)
src_name_len: 7
src_domain_offset: 11 (ott.qnx.com)
src_domain_len: 12
src_addr_offset: 23 (00:0c:29:6e:00:0a)
src_addr_len: 16
destination: destination node information
dst_name_offset: 39 (EA6e0a)
dst_name_len: 7
dst_domain_offset: 46 (ott.qnx.com)
dst_domain_len: 12
dst_addr_offset: 0
dst_addr_len: 0Yao Zhao(deleted)2009-08-29T11:57:27Zpost34585: Re: Equvalant qnxsystem callsYao Zhao(deleted)http://community.qnx.com/sf/go/post345852009-07-25T16:36:50Z2009-07-25T16:36:50Z> Hi,
> I am porting the some code of solaris on qnx following system calls are
> not supported in qnx:
>
> 1 updwtmp
>
> 2 ptsname
>
> 3 unlockpt
>
> Please provide me the name of QNX system call for the same.
>
ptsname and unlockpt are supported by 6.4 and I am not sure when they are added. They are not in document so that is a bug. Just check libc.a you will find them and headers are in stdlib.h, it seems they are in Posix spec.
updwtmp I didn't find but you could reference telnetd source code to see how it did. It is not posix function so...Yao Zhao(deleted)2009-07-25T16:36:50Zpost34147: Equvalant qnxsystem callsDeepak jainhttp://community.qnx.com/sf/go/post341472009-07-21T04:20:57Z2009-07-21T04:20:57ZHi,
I am porting the some code of solaris on qnx following system calls are not supported in qnx:
1 updwtmp
2 ptsname
3 unlockpt
Please provide me the name of QNX system call for the same.Deepak jain2009-07-21T04:20:57Zpost31694: Tasks need to be picked upYao Zhao(deleted)http://community.qnx.com/sf/go/post316942009-06-13T12:01:44Z2009-06-13T12:01:44ZThere are some tasks which need to be picked up in "Tasks".
If you want please try, new tasks are welcome too.
I was trying to finish the POSIX file system test with ntfs-3g, the difficulty is free version ntfs-3g doesn't fully support mode yet. I just guess Linux kernel did it or ? I added some code in qfuse to achieve this too and so far 70+ tests passed and I hope I can achieve 90+ like QNX4 fs test I did.Yao Zhao(deleted)2009-06-13T12:01:44Zpost31272: Re: First Thread! :)Yao Zhao(deleted)http://community.qnx.com/sf/go/post312722009-06-09T19:01:35Z2009-06-09T19:01:35ZI have put zfsfuse into svn and also tried to compile but I failed.
zfsfuse is using scons to compile, not makefile. I found scons in QNX' pkgsrc project and I tried but got some errors. Sean said the errors are known bug.
If somebody is familiar with python it will be easier to fix or debug. Maybe we can try to compile it on Linux build machine with QNX development tools installed.Yao Zhao(deleted)2009-06-09T19:01:35Zpost31188: First Thread! :)Andrew Golovnia(deleted)http://community.qnx.com/sf/go/post311882009-06-09T12:09:07Z2009-06-09T12:09:07ZHi!
Is it planned to add another useful FSs in SVN repo, e.g. ZFS, sshfs?
Thanks!
WBR,
AGAndrew Golovnia(deleted)2009-06-09T12:09:07Z