Re: sis, psim,anf jmr3904 test results
On 27/11/14 20:43, Joel Sherrill wrote: sparc/sis === Passed: 511 Failed: 3 Timeouts: 7 Invalid:0 - Total:521 Failures: heapwalk.exe dl02.exe psx13.exe Timeouts: *** Interactive termios.exe, pppd.exe, capture.exe, top.exe, monitor.exe, fileio.exe Why do you get timeouts for these tests? They should run 20s waiting for user input and then exit if nothing happened. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] libcsupport: Delete malloc statistics
On 27/11/14 16:40, Gedare Bloom wrote: Any particular reason for dropping memalign_calls? If you are interested in particular function calls, then I suggest to use some sort of tracing. Any other stats get dropped? I added the dropped stats to the Heap_Statistics: http://git.rtems.org/rtems/commit/?id=d006b46df31f6e5f28237fe40eafb135e684b739 I think we have now quite useful heap statistics. If something is missing, then we can add it on demand. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] libcsupport: Delete malloc statistics
Great, thanks for doing this, the stats look a lot cleaner to me. On Fri, Nov 28, 2014 at 7:43 AM, Sebastian Huber wrote: > On 27/11/14 16:40, Gedare Bloom wrote: >> >> Any particular reason for dropping memalign_calls? > > > If you are interested in particular function calls, then I suggest to use > some sort of tracing. > >> >> Any other stats get dropped? > > > I added the dropped stats to the Heap_Statistics: > > http://git.rtems.org/rtems/commit/?id=d006b46df31f6e5f28237fe40eafb135e684b739 > > I think we have now quite useful heap statistics. If something is missing, > then we can add it on demand. > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: sis, psim,anf jmr3904 test results
On 11/28/2014 04:11 AM, Sebastian Huber wrote: On 27/11/14 20:43, Joel Sherrill wrote: sparc/sis === Passed: 511 Failed: 3 Timeouts: 7 Invalid:0 - Total:521 Failures: heapwalk.exe dl02.exe psx13.exe Timeouts: *** Interactive termios.exe, pppd.exe, capture.exe, top.exe, monitor.exe, fileio.exe Why do you get timeouts for these tests? They should run 20s waiting for user input and then exit if nothing happened. I don't know. Only took 5.9 seconds of computer time to run by hand and prints "END OF" message. When run with rtems-tester, it gives the timeout but looking at top, it doesn't appear to be running anymore. Time shows at 0:00.17 [1/1] p:0 f:0 t:0 i:0 | sparc/sis: fileio.exe > gdb: /users/joel/rtems-4.11-work/tools/bin/sparc-rtems4.11-gdb -i=mi --nx --quiet ./sparc-rtems4.11/c/sis/testsuites/samples/fileio/fileio.exe > Reading symbols from ./sparc-rtems4.11/c/sis/testsuites/samples/fileio/fileio.exe... > done. > target sim > Connected to the simulator. > load > run > Starting program: /users/joel/rtems-4.11-work/b-sis/sparc-rtems4.11/c/sis/testsuites/samples/fileio/fileio.exe ] *** BEGIN OF TEST FILE I/O *** ] *** TIMEOUT TIMEOUT Result: timeoutTime: 0:03:02.200058 My guess would be that it is stuck in the first polling read and not returning. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 15/20] chainimpl.h: Add _Assert() to _Chain_Initialize_empty()
> On Nov 26, 2014, at 13:55 , Gedare Bloom wrote: > > I guess the difference is whether the assert implies a local > assumption (I require this var is not NULL) or a global one (This var > has been previously verified to be not NULL). It may be worth > classifying asserts in those two categories. Yes, it is important that as RTEMS puts assertions in to satisfy automated code verification processes that we don't lose information as to why a given assertion is added. Do we know that a pointer can't possibly NULL (oh-oh, what happened? We checked that!) or is it a library function that we need to use and we want to tell the code verifier to shut-up. The base part of RTEMS needs to protect against the first situation, especially if it is made easier (RSB) to add third part libraries. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
University project - recommendations?
Hello, I am a university student and am looking for a school project. I am interested in RTEMS and so I thought I could help out with development. The project should take several "school months". It should also involve the kernel space, not user space. I have browsed through the wiki/trac and I found these 3: 1) CFI-standard flash device interface, 2) CEXP integration, 3) TCP stack rewrite. I don't have any experience with implementing TCP, but I have some experience with data structures on block devices (manipulating MBR and GPT labels). But I don't know how much of help my experience is. I have hard time guessing time requirements for these, so can anyone give me a hint how complex these are? Or can you give me any other project assignments? Any input is welcome. Best regards, Dominik Taborsky ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: University project - recommendations?
On Fri, Nov 28, 2014 at 4:17 PM, Dominik Taborsky wrote: > Hello, > > I am a university student and am looking for a school project. I am > interested in RTEMS and so I thought I could help out with development. > The project should take several "school months". It should also involve > the kernel space, not user space. > Welcome! What areas are you most interested in working on? Are you interested in something that might continue beyond your project? Do you want to be more into core kernel development, hardware abstraction, "middleware" (networks, drivers, etc)? Based on the three projects you posted, I'm guessing the latter, something that operates between the kernel and the hardware. What is your expected hours/wk to spend on this? That will help in gauging the level of effort you should undertake. GSoC-size projects aim at full-time (40 hours) effort for 2 months AFTER getting through the "getting started" and defining project requirements and milestones. Keep in mind that many of the open projects we defined are aimed at GSoC size or greater. You'll probably need to carve off a smaller-size project from a larger one to fit your time constraints. You should also do the "Getting Started" with the RTEMS Source Builder to start getting comfortable with the tools. Ask if you need help, or especially if you run into broken links. Our website has recently migrated and some things broke. > I have browsed through the wiki/trac and I found these 3: > 1) CFI-standard flash device interface, > 2) CEXP integration, > 3) TCP stack rewrite. > I don't know that CEXP integration is that interesting anymore. One of the key features of CEXP is dynamic loading, which is not supported through the RTEMS linker and loader projects (RTL). You might ask Chris Johns if there are projects available for RTL. The TCP stack has mostly been refreshed from BSD by now. I'm not sure about its status. Improving the support for devices and especially frameworks for drivers is a timely project with good potential. See the recent commits that added cpukit/dev/i2c. You might try writing some drivers for i2c devices to fit the new framework. Sebastian Huber may have more info for you. The difficult part in this is testing. We had a GSoC student (Andre Marques) look at some I/O device frameworks as part of the raspberrypi effort too, so you might look for those conversations or contact him directly. > I don't have any experience with implementing TCP, but I have some > experience with data structures on block devices (manipulating MBR and GPT > labels). But I don't know how much of help my experience is. > > I have hard time guessing time requirements for these, so can anyone give > me a hint how complex these are? Or can you give me any other project > assignments? > Estimating time is hard! Especially without much context for your availability or skills. :) In general, I'd suggest scoping out a project with many smaller milestones so that you can make good progress, even if you don't get to the end, you should have a nice set of accomplishments. Gedare > Any input is welcome. > > Best regards, > Dominik Taborsky > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel