Feed for discussion General in project QNX Community FUSE Project.

post113310: Re: heap usage command line monitor

2015-02-13T14:58:11Z

Hi 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 America

post89948: Re: qnx kernel crash analysis and qsymoops

2011-11-09T02:46:50Z

i 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 000

post64956: Re: Error in building fuse

2010-08-30T05:58:04Z

Hi,

thanks.

I am able to compile.

regards

vibi

post64895: Re: Error in building fuse

2010-08-27T20:52:27Z

Just 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!

yao

post64891: Re: Error in building fuse

2010-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,

yao

post63734: Error in building fuse

2010-08-20T14:46:44Z

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

post42454: Re: Project Status of FUSE?

2009-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.

post42359: Project Status of FUSE?

2009-11-21T17:07:37Z

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 . . .

post40800: Re: qnet protocol dissector for ethereal/wireshark

2009-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.

post40733: Re: qnet protocol dissector for ethereal/wireshark

2009-10-27T05:40:04Z

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

post40675: Re: qnet protocol dissector for ethereal/wireshark

2009-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.

post40590: Re: qnet protocol dissector for ethereal/wireshark

2009-10-23T11:13:46Z

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.

post38381: Re: qnx kernel crash analysis and qsymoops

2009-09-18T21:04:45Z

Sorry 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

> 

>

post38081: Re: qnx kernel crash analysis and qsymoops

2009-09-16T16:14:33Z

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

post37863: Re: qnx kernel crash analysis and qsymoops

2009-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.

post37786: Re: qnx kernel crash analysis and qsymoops

2009-09-10T21:08:55Z

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.

post37766: Re: qnx kernel crash analysis and qsymoops

2009-09-10T17:20:43Z

probably 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.com

post37755: Re: qnx kernel crash analysis and qsymoops

2009-09-10T16:47:56Z

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.com

post36917: heap usage command line monitor

2009-08-30T14:47:44Z

I 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.

post36914: qnx kernel crash analysis and qsymoops

2009-08-29T12:29:38Z

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.

post36913: qnet protocol dissector for ethereal/wireshark

2009-08-29T11:57:27Z

Here 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: 0

post34585: Re: Equvalant qnxsystem calls

2009-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...

post34147: Equvalant qnxsystem calls

2009-07-21T04:20:57Z

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.

post31694: Tasks need to be picked up

2009-06-13T12:01:44Z

There 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.

post31272: Re: First Thread! :)

2009-06-09T19:01:35Z

I 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.

post31188: First Thread! :)

2009-06-09T12:09:07Z

Hi!

Is it planned to add another useful FSs in SVN repo, e.g. ZFS, sshfs?

Thanks!

WBR,

AG