| *** tuxmaniac has quit IRC | 00:23 | |
| *** ChanServ has quit IRC | 00:23 | |
| *** dr__house has quit IRC | 00:24 | |
| *** ChanServ has joined #rtems | 00:28 | |
| *** irc.freenode.net sets mode: +o ChanServ | 00:28 | |
| *** tuxmaniac has joined #rtems | 00:28 | |
| *** chrisjohns has quit IRC | 00:48 | |
| *** kiwichris has joined #rtems | 00:49 | |
| lee_ | kiwichris, morning? | 02:30 |
|---|---|---|
| lee_ | kiwichris, how was the game on sat? | 02:30 |
| *** bazinski has joined #rtems | 03:23 | |
| *** cocan has joined #rtems | 05:02 | |
| *** chrisjohns2 has joined #rtems | 05:20 | |
| *** chrisjohns2 has quit IRC | 05:24 | |
| *** chrisjohns has joined #rtems | 05:24 | |
| *** tuxmaniac has quit IRC | 05:24 | |
| *** kiwichris has quit IRC | 05:24 | |
| *** ChanServ has quit IRC | 05:24 | |
| *** kiwichris has joined #rtems | 05:25 | |
| *** tuxmaniac has joined #rtems | 05:26 | |
| *** chrisjohns has quit IRC | 05:26 | |
| *** chrisjohns has joined #rtems | 05:27 | |
| *** cocan_ has joined #rtems | 05:30 | |
| *** cocan has quit IRC | 05:31 | |
| *** chrisjohns has quit IRC | 05:32 | |
| *** chrisjohns has joined #rtems | 05:33 | |
| *** ChanServ has joined #rtems | 05:38 | |
| *** irc.freenode.net sets mode: +o ChanServ | 05:38 | |
| *** cocan_ has quit IRC | 05:50 | |
| *** cocan has joined #rtems | 05:50 | |
| cocan | chrisjohns: Hi Chris | 05:58 |
| *** cocan has quit IRC | 06:59 | |
| *** cocan has joined #rtems | 06:59 | |
| *** th_d has joined #rtems | 07:05 | |
| chrisjohns | Hi Thomas | 07:34 |
| chrisjohns | th_d, hi | 07:34 |
| *** chrisjohns has quit IRC | 07:43 | |
| *** th_d has quit IRC | 07:48 | |
| *** cocan_ has joined #rtems | 07:59 | |
| *** cocan has quit IRC | 08:00 | |
| *** cocan_ is now known as cocan | 08:00 | |
| *** cocan has quit IRC | 08:20 | |
| *** DrJoel has joined #rtems | 08:50 | |
| *** ChanServ sets mode: +o DrJoel | 08:50 | |
| *** dr__house has joined #rtems | 10:47 | |
| dr__house | DrJoel: good morning :) | 10:47 |
| *** dr__house has quit IRC | 10:55 | |
| *** dr__house has joined #rtems | 10:58 | |
| dr__house | sorry about that, network problems :( | 10:58 |
| * DrJoel is on his way to lunch .. brb | 11:41 | |
| DrJoel | dr__house: before i leave.. how did the numbers in the tarball look to you? | 11:42 |
| dr__house | DrJoel: they were awesome:D | 11:42 |
| dr__house | DrJoel: we reached 99.5%!!!!!!!!!!!!!!!!!! | 11:43 |
| dr__house | :D:D | 11:43 |
| *** cocan has joined #rtems | 11:43 | |
| DrJoel | i am picking at the results of running with posix disabled. Looks like some handlers in the supercore are only used by posix so I am fixing the makefile not to build them | 11:47 |
| * DrJoel will be back in a couple of hours | 11:47 | |
| dr__house | DrJoel: cool :) | 11:48 |
| agrier | still no luck with updated newlib. I have a suspicion I'm missing some patches. | 11:58 |
| agrier | In file included from /var/obj/gsoc/sourceware/gcc-4_4-branch/newlib/libc/include/dirent.h:6, | 11:59 |
| agrier | from /projects/gsoc/sourceware/gcc-4_4-branch/newlib/libc/posix/closedir.c:41: | 11:59 |
| agrier | /var/obj/gsoc/sourceware/gcc-4_4-branch/newlib/libc/include/sys/dirent.h:10:2: error: #error "<dirent.h> not supported" | 11:59 |
| agrier | it's like configure isn't setting the include directories up correctly | 11:59 |
| *** cocan_ has joined #rtems | 12:00 | |
| *** cocan has quit IRC | 12:03 | |
| *** cocan_ is now known as cocan | 12:03 | |
| agrier | I know RTEMS provides a dirent.h | 12:03 |
| cocan | DrJoel: hi | 12:21 |
| cocan | DrJoel: is there a way to get a file from a guest computer (running RTEMS in qemu) on the host computer? | 12:23 |
| *** cocan has quit IRC | 13:33 | |
| *** cocan has joined #rtems | 13:37 | |
| * dr__house is away: Gone away for now | 14:01 | |
| * dr__house is back. | 14:04 | |
| DrJoel | cocan: there are two ways I know of. (1) to use the virtual fat support in qemu and the RTEMS FAT filesystem and (2) use the RTEMS nfsclient to access the host filesystem. | 14:34 |
| *** cocan_ has joined #rtems | 14:46 | |
| cocan_ | DrJoel: great...does anything else needs to be configured in order to make use of FAT instead of IMFS? http://www.rtems.com/wiki/index.php/Using_the_RTEMS_DOS_File_System | 14:53 |
| DrJoel | i don't think so since FAT is mounted (not the root). Check out the fileio or network-demo/telnetd for some examples. Chris should be able to help with any details | 14:54 |
| *** ChanServ has quit IRC | 14:55 | |
| cocan_ | DrJoel: ok...will do so...I am trying to get the file that contains the trace information...in order to decode on the host | 14:59 |
| * dr__house leaves for the day. Have a good day DrJoel :) | 15:00 | |
| DrJoel | good night.. your new patch is generating a tarball now. | 15:00 |
| dr__house | DrJoel: cool! :) | 15:01 |
| *** dr__house has quit IRC | 15:01 | |
| *** cocan has quit IRC | 15:05 | |
| *** ChanServ has joined #rtems | 15:13 | |
| *** irc.freenode.net sets mode: +o ChanServ | 15:13 | |
| *** cocan_ has quit IRC | 15:18 | |
| *** roxanal has quit IRC | 15:21 | |
| tuxmaniac | Hi DrJoel | 15:26 |
| tuxmaniac | end of day for me. good night. will have to wake p early tomorrow and make more commits :) | 15:27 |
| *** cocan has joined #rtems | 15:30 | |
| *** roxanal has joined #rtems | 15:36 | |
| cocan | kiwichris: Hi Chris...are you on? | 17:43 |
| *** cocan has quit IRC | 18:19 | |
| *** chrisjohns has joined #rtems | 18:23 | |
| *** DrJoel has quit IRC | 18:35 | |
| *** roxanal has quit IRC | 18:45 | |
| *** cocan has joined #rtems | 19:10 | |
| chrisjohns | cocan, hi, I am fine. | 19:14 |
| *** chrisjohns has quit IRC | 20:43 | |
| *** cocan has quit IRC | 20:45 | |
| *** chrisjohns has joined #rtems | 21:47 | |
| *** chrisjohns has quit IRC | 23:40 | |
| *** madrazr has joined #rtems | 00:04 | |
| *** lee21 has joined #rtems | 00:59 | |
| *** madrazr has quit IRC | 02:07 | |
| *** lee21 has quit IRC | 02:35 | |
| *** lee22 has joined #rtems | 02:36 | |
| *** ChanServ has quit IRC | 03:02 | |
| *** tuxmaniac has quit IRC | 03:02 | |
| *** kiwichris has quit IRC | 03:02 | |
| *** lee22 has quit IRC | 03:02 | |
| *** mwalle has quit IRC | 03:02 | |
| *** agrier has quit IRC | 03:02 | |
| *** rokka has quit IRC | 03:02 | |
| *** bazinski has quit IRC | 03:02 | |
| *** lee_ has quit IRC | 03:02 | |
| *** ChanServ has joined #rtems | 03:03 | |
| *** lee22 has joined #rtems | 03:03 | |
| *** tuxmaniac has joined #rtems | 03:03 | |
| *** kiwichris has joined #rtems | 03:03 | |
| *** bazinski has joined #rtems | 03:03 | |
| *** mwalle has joined #rtems | 03:03 | |
| *** rokka has joined #rtems | 03:03 | |
| *** agrier has joined #rtems | 03:03 | |
| *** lee_ has joined #rtems | 03:03 | |
| *** irc.freenode.net sets mode: +o ChanServ | 03:03 | |
| *** lee22 has quit IRC | 04:08 | |
| *** lee21 has joined #rtems | 04:12 | |
| *** dr__house has joined #rtems | 04:16 | |
| *** dr__house has quit IRC | 04:52 | |
| *** madrazr has joined #rtems | 05:45 | |
| *** madrazr has quit IRC | 06:09 | |
| *** madrazr has joined #rtems | 06:12 | |
| *** dr__house has joined #rtems | 08:39 | |
| *** roxanal has joined #rtems | 08:39 | |
| *** switnick has joined #rtems | 09:26 | |
| *** dr__house has quit IRC | 10:45 | |
| *** madrazr has quit IRC | 11:13 | |
| *** madrazr has joined #rtems | 11:17 | |
| *** dr__house has joined #rtems | 11:31 | |
| *** DrJoel has joined #rtems | 12:12 | |
| *** ChanServ sets mode: +o DrJoel | 12:12 | |
| DrJoel | roxana and aaron: did you see my email with the framebuffer.h and user side configuration? | 12:13 |
| DrJoel | dr__house: the arm coverage has work left. :( i committed your changes. Do you have one you want to do next? | 12:13 |
| dr__house | DrJoel: no, I thought arm would be the next thing. What about other archs? | 12:15 |
| DrJoel | skyeye and tsim are the only simulators with coverage builtin that we have BSPs for.. so back to the test case coal mine. :) | 12:16 |
| tuxmaniac | Hi DrJoel | 12:19 |
| DrJoel | i don't have any feel for which would be best for you to tackle. There are only 29 left. An easy one is probably the pthread_create with a stack you provide (set stackaddr) | 12:20 |
| DrJoel | tuxmaniac: hello | 12:20 |
| DrJoel | but there are some posix msgq left, posix key, and posix sporadic server with ~4-5 each so those are good candidates also | 12:21 |
| tuxmaniac | DrJoel: I replioed to your email. I agree a patch over the cvs is easiest. But I have added a few files and folders too and I cant get them in the cvs diff | 12:21 |
| DrJoel | just tar them up from the top of the tree and I will untar them when I apply th epatch | 12:24 |
| tuxmaniac | ok. today I will be commiting more code. Will send across a tarball by end of day today | 12:25 |
| DrJoel | no problem. | 12:28 |
| dr__house | DrJoel: cool, will check them out then | 12:29 |
| DrJoel | pick what looks interesting and doable and I will review the explanations for them to make sure about them | 12:31 |
| dr__house | DrJoel: sure | 12:33 |
| switnick | DrJoel: Hello | 12:48 |
| DrJoel | switnick: hi.. have you made any progress? | 12:49 |
| switnick | I think so | 12:49 |
| switnick | I am trying an asm implementation | 12:49 |
| switnick | is there any reason not to do this? | 12:49 |
| DrJoel | of ? | 12:49 |
| switnick | context init | 12:49 |
| DrJoel | offsets into the structure get fixed automatically in C but other that.. no | 12:50 |
| DrJoel | did you swap the order of loading the 2 halves of the sp in restore? | 12:50 |
| switnick | i did | 12:50 |
| DrJoel | did that help? | 12:50 |
| switnick | not really | 12:50 |
| DrJoel | can you see the value of the sp in gdb as it is set/ | 12:51 |
| switnick | yes | 12:51 |
| switnick | it sets fine | 12:51 |
| DrJoel | does it return to _Thread_Handler with it ret's? | 12:51 |
| switnick | no | 12:51 |
| DrJoel | where does it go/ | 12:51 |
| switnick | the value that pops of the stack is a mystery | 12:52 |
| DrJoel | that's what confuses me.. | 12:52 |
| switnick | when I look at the stack is looks ok | 12:52 |
| switnick | but after the ret an unknown value shows up | 12:52 |
| switnick | not sure where from | 12:52 |
| DrJoel | is it in memory near the sp? above or below? | 12:53 |
| switnick | yes | 12:53 |
| switnick | at and below i think | 12:54 |
| switnick | obove | 12:54 |
| switnick | above** | 12:54 |
| switnick | I will try it on the hardware that Eric sent | 12:55 |
| DrJoel | hmm.. maybe we have miscalculated where to set the sp and return address in relation to one another | 12:55 |
| switnick | I have been moving them around and redoing the calcs | 12:55 |
| switnick | seems right | 12:55 |
| switnick | I will send the diff to you | 12:56 |
| switnick | if you would like | 12:56 |
| switnick | or I can just do some more testing on hardware | 12:56 |
| DrJoel | before you send me a diff can you look at a trace and see what address the ret instruction reads versus where we put the entry point. Maybe we can just fix that. | 12:58 |
| DrJoel | try that .. if no progress in an hour or so, email me a diff and i will take a swing at it | 12:59 |
| switnick | ok | 12:59 |
| switnick | just a second | 12:59 |
| switnick | I believe that pop is post increment | 13:04 |
| switnick | if that is true then the address is corect | 13:04 |
| DrJoel | i don't trust my interpretation when the code doesn't work. :D If we can put dummy contents above and below where we think the SP should be, then what stack location is read should be obvious | 13:09 |
| switnick | ok I will do that | 13:10 |
| switnick | is there a posibility that the problem is with the simulator? | 13:11 |
| DrJoel | possible .. not likely.. if the code runs on hw and not the simulator yes but otherwise no. | 13:12 |
| DrJoel | a lot of C compiler generated code runs on the simulator | 13:12 |
| DrJoel | kiwichris: awake? | 13:13 |
| *** cocan has joined #rtems | 13:17 | |
| *** cocan has quit IRC | 13:35 | |
| dr__house | DrJoel: leaving early tonight. My back's killing me, catch you tomorrow. Have a good day :) | 13:42 |
| *** dr__house has quit IRC | 13:43 | |
| *** cocan has joined #rtems | 14:00 | |
| cocan | DrJoel: hi....any idea why I am getting this? Program heap: free of bad pointer 1C026C -- range 1BFB78 - 7FFFFF8 | 14:04 |
| cocan | DrJoel: and also Read IDE Disk Partition Table: error: ide partition table not found: RTEMS inconsistency detected | 14:05 |
| lee21 | cocan: think he didn't feel to well and left early, something about his back | 14:06 |
| DrJoel | i'm here.. :) | 14:06 |
| lee21 | oops... | 14:06 |
| cocan | lee21: :D | 14:06 |
| lee21 | ;) | 14:07 |
| DrJoel | cocan: usually that means you freed a pointer that wasn't malloc'ed | 14:07 |
| DrJoel | and in that case .. look at the message. you definitely freed a pointer not in the heap. | 14:07 |
| DrJoel | Check your .num file. It looks like a real variable address | 14:07 |
| DrJoel | whoops.. misread.. | 14:07 |
| DrJoel | probably a double free or an offset inside a malloc'ed area | 14:08 |
| DrJoel | 1C026C is in the heap (range 1BFB78 - 7FFFFF8) | 14:08 |
| cocan | DrJoel: taking a look right now | 14:09 |
| DrJoel | you can break on that print in gdb and backtrace to see where it came from | 14:25 |
| cocan | will do that if I will not be able to fix it right now | 14:29 |
| DrJoel | :) | 14:29 |
| cocan | I've just tried fileio example and it works ok...I can mount partitions, create directories and see the changes in the image disk | 14:40 |
| *** madrazr has quit IRC | 14:40 | |
| DrJoel | cocan: wonderful! is this with the virtual fat under qemu? | 14:43 |
| cocan | DrJoel: using a disk image...not the fat: option | 14:45 |
| cocan | DrJoel: using the VFAT in Qemu will map the free space of my HDD as a slave...and it doesn't work..not sure why | 14:46 |
| cocan | DrJoel: but I can always use a disk image and copy the file using mtools | 14:47 |
| switnick | DrJoel: I have a stack question. | 15:18 |
| DrJoel | switnick: shoot | 15:20 |
| switnick | I was trying to simulate the ret instruction by popping twice from the stack | 15:21 |
| switnick | to see what is there in the trace | 15:21 |
| DrJoel | and ... | 15:21 |
| switnick | then push them back on | 15:21 |
| switnick | so I get the right address here | 15:21 |
| switnick | but then when the ret occurs it goes somewhere else | 15:22 |
| switnick | not to the value I just pushed to the stack | 15:22 |
| DrJoel | very weird... | 15:23 |
| DrJoel | can you send me your patch that restores the sp in the right order .. I will play some | 15:23 |
| switnick | ok | 15:24 |
| switnick | just sent the diff | 15:29 |
| DrJoel | ok.. i will start building | 15:29 |
| *** lee21 has quit IRC | 15:45 | |
| * agrier is back in cross-compiler business | 15:49 | |
| agrier | sourceware newlib HEAD: fail | 15:49 |
| agrier | newlib 1.17.0 with RTEMS patches: success! | 15:49 |
| DrJoel | agrier: what failed on head? which gcc? | 15:50 |
| agrier | gcc 4.4.2 | 15:50 |
| agrier | I can't get newlib head to compile | 15:51 |
| agrier | went back to 1.17.0 with recent patches and it worked... | 15:52 |
| DrJoel | what error? | 15:55 |
| agrier | dirent.h not supported | 15:55 |
| agrier | it looked like newlib was missing an include path, or some autoconf magic wasn't being properly triggered | 15:56 |
| DrJoel | hmm.. ok.. maybe the gcc needed a patch | 15:56 |
| DrJoel | i don't know.. :( | 15:56 |
| agrier | same gcc -- all I changed was newlib from -HEAD to 1.17.0 with RTEMS patches | 15:56 |
| agrier | you're tracking -HEAD, right Joel? | 15:58 |
| DrJoel | yep.. and gcc -HEAD. built about a week ago. need to try it again apparently | 15:59 |
| agrier | could you run a diff against your newlib branch and email it to me, just for kicks? | 16:01 |
| DrJoel | agrier: so small I just pasted it :-D | 16:04 |
| agrier | oh really... wow | 16:04 |
| agrier | this may be NetBSD-specific. I am not enough of an autotools avatar to precisely determine what is going on | 16:04 |
| DrJoel | switnick: why does the Context_Control only have two fields now? The context save and restore assume a lot more is in there | 16:05 |
| switnick | to make the switch and init simpler | 16:06 |
| switnick | this is also the way alot of other rtos' i looked implemented their context switch | 16:06 |
| switnick | seemed to be simpler to me | 16:06 |
| switnick | is there something wrong with it? | 16:06 |
| DrJoel | but there are registers which have to be preserved across a subroutine call and they must be saved/restored. | 16:07 |
| DrJoel | did you account for all those pops during the init? | 16:07 |
| switnick | yes | 16:07 |
| DrJoel | ok.. just surprised when looking at the code.. no big deal | 16:07 |
| switnick | ok | 16:07 |
| switnick | its good to have someone asking these questions | 16:08 |
| switnick | DrJoel: any idea whats going on? | 16:45 |
| DrJoel | switnick: I think I am onto something | 16:45 |
| DrJoel | the_context = 0x2BB5 | 16:45 |
| DrJoel | entry = 0x74A5 | 16:45 |
| DrJoel | sp = 0x3D58 | 16:45 |
| DrJoel | 0x3D46 0x2B 0x00 0x00 0x00 0x00 0x00 0x00 0x00 | 16:45 |
| DrJoel | 0x3D4E 0x00 0x00 0x00 0x00 0xA5 0x74 0xA5 0x74 | 16:45 |
| DrJoel | 0x3D56 0xA5 0x74 0xA5 0x74 0xA5 0x74 0xA5 0x74 | 16:45 |
| DrJoel | I went back to the C init context.. and (think) I accounted for what you push/pop on the stack. I can not get to the Init task | 16:46 |
| DrJoel | I am writing the entry point into 3 locations in the starting stack which isn't right but I need to track down which one is giving the desired results | 16:46 |
| switnick | ok | 16:47 |
| switnick | did you look at the trace of what I sent? | 16:47 |
| DrJoel | i got 2 diff files from you in 2 emails? | 16:52 |
| switnick | wasnt sure that the attachment was sent in the first | 16:52 |
| switnick | they are the same | 16:52 |
| switnick | ignore one of them | 16:52 |
| switnick | sorry for the spam | 16:52 |
| DrJoel | you are the least of my spam.. I feel like I am close... | 16:52 |
| switnick | DrJoel: I sent the result of the trace to you. | 17:13 |
| switnick | I'm going home now | 17:13 |
| DrJoel | ok .. thanks.. I think i am onto something. I think the context init matches the restore but the save doesn't match restore.. having trouble getting into gdb now :( | 17:13 |
| switnick | will be at my computer later tonight | 17:14 |
| DrJoel | ok.. i will work on this a while.. it is close I think | 17:14 |
| switnick | ok | 17:15 |
| switnick | do you have avr-gdb? | 17:15 |
| switnick | thanks for the help | 17:17 |
| switnick | talk to you tmr | 17:17 |
| switnick | good night | 17:17 |
| DrJoel | yes.. i can step | 17:18 |
| DrJoel | good night | 17:18 |
| *** switnick has quit IRC | 17:18 | |
| agrier | is rtems/stringto.h supposed to be checked in to CVS? ;) | 18:25 |
| DrJoel | yes .. and it is.. (according to my tree) | 18:28 |
| DrJoel | Repository revision:1.2/usr1/CVS/rtems/cpukit/libmisc/stringto/stringto.h,v | 18:29 |
| DrJoel | according to cvs stat | 18:29 |
| DrJoel | did you bootstrap cpukit? | 18:29 |
| DrJoel | fwiw I switched pc386 fbvga_X to use the frame_buffer_ naming so we can test out the new confdefs.h work | 18:29 |
| * DrJoel is heading home.. i had enough of a breakthrough for josh that I hope he is moving again | 18:30 | |
| * DrJoel waves night | 18:30 | |
| *** DrJoel has quit IRC | 18:31 | |
| agrier | ahh bootstrap | 18:44 |
| *** chrisjohns has joined #rtems | 18:51 | |
| agrier | woohoo it's all working again | 19:41 |
| agrier | I was afraid I was going to have to dig out the goat book | 19:41 |
| *** switnick has joined #rtems | 19:43 | |
| *** chrisjohns has quit IRC | 20:00 | |
| *** chrisjohns has joined #rtems | 20:02 | |
| *** cocan has quit IRC | 20:02 | |
| agrier | time to head home | 20:12 |
| *** switnick has quit IRC | 20:20 | |
| roxanal | can anyone help me how is preinstall.am generated? it says it is an automatic file | 21:47 |
| roxanal | *help me understand | 21:47 |
| roxanal | I found out ./bootstrap -p :) | 21:55 |
| *** switnick has joined #rtems | 22:09 | |
| *** switnick has quit IRC | 22:46 | |
| *** lee21 has joined #rtems | 23:11 | |
| *** chrisjohns has quit IRC | 23:39 | |
| tuxmaniac | roxanal: yes. and also ensure you do a ./bootstrap again. I sometimes found just ./bootstrap -p isnt enough | 00:53 |
| *** dr__house has joined #rtems | 00:57 | |
| *** lee21 has quit IRC | 02:05 | |
| *** sebhub has joined #rtems | 02:16 | |
| *** lee21 has joined #rtems | 02:16 | |
| *** dr__house has quit IRC | 02:59 | |
| *** dr__house has joined #rtems | 04:00 | |
| *** madrazr has joined #rtems | 04:01 | |
| *** madrazr has quit IRC | 04:39 | |
| *** madrazr has joined #rtems | 05:17 | |
| *** gnumaniac has joined #rtems | 05:32 | |
| *** dr__house has quit IRC | 05:33 | |
| *** madrazr1 has joined #rtems | 05:42 | |
| *** madrazr has quit IRC | 05:42 | |
| *** bazinski has quit IRC | 05:42 | |
| *** bazinski has joined #rtems | 05:50 | |
| *** gnumaniac has quit IRC | 05:54 | |
| *** dr__house has joined #rtems | 06:17 | |
| *** dr__house has quit IRC | 07:30 | |
| *** dr__house has joined #rtems | 07:31 | |
| *** dr__house has quit IRC | 07:32 | |
| *** madrazr1 has quit IRC | 08:24 | |
| *** DrJoel has joined #rtems | 08:31 | |
| *** ChanServ sets mode: +o DrJoel | 08:31 | |
| *** switnick has joined #rtems | 08:45 | |
| *** cocan has joined #rtems | 09:11 | |
| DrJoel | switnick: did you see the email? does it run on hardware? | 09:13 |
| switnick | Didn't have a power supply last night | 09:13 |
| switnick | just about to set it up | 09:13 |
| switnick | and yes I did see the email | 09:14 |
| DrJoel | ok.. it was running ticker to the end correctly. But only when I did a printk. | 09:14 |
| switnick | I had a similar problem | 09:14 |
| DrJoel | I suspect we missed a register in the context setup.. like frame pointer or something | 09:14 |
| switnick | ok | 09:14 |
| DrJoel | does the start.S set anymore registers? I was going to look at the assembly for printk and see what it did that might help. | 09:15 |
| DrJoel | but a check on hardware at this point would be good to verify our status | 09:15 |
| switnick | ok will do | 09:15 |
| switnick | not so sure about the setup | 09:15 |
| switnick | might take some time | 09:15 |
| DrJoel | i wonder if the reg that is supposed to be zero actually is when we initialize the contexts.. | 09:21 |
| tuxmaniac | DrJoel: _read_SDR1 is not there in libcpu/spr.h I saw it is used by gen82xx bsp already. But for psim this does not get into the header file. Don't know if I am missing something | 09:30 |
| tuxmaniac | hence wrote my own | 09:30 |
| *** th_d has joined #rtems | 09:33 | |
| roxanal | DrJoel: good morning | 09:35 |
| *** cocan has quit IRC | 09:36 | |
| *** dr__house has joined #rtems | 09:43 | |
| dr__house | DrJoel: good morning | 09:43 |
| *** madrazr has joined #rtems | 09:44 | |
| *** cocan has joined #rtems | 09:52 | |
| DrJoel | hi all | 10:03 |
| DrJoel | tuxmaniac: no problem on writing your own.. just hard code.. easier to reuse :-D | 10:03 |
| DrJoel | dr__house: any thoughts on which case to tackle next? | 10:03 |
| dr__house | DrJoel: Not yet, looking at them still | 10:04 |
| roxanal | DrJoel: I don't know exactly what happened with the patch I sent you | 10:04 |
| DrJoel | dr__house: anything looking like a likely candidate? | 10:05 |
| DrJoel | roxanal: what do you mean? It merged cleanly. All i did was kill tabs and fix formatting that has been there since the file was first submitted 9 years ago | 10:06 |
| roxanal | DrJoel: I can't build rtems anymore there are some weird <<<<<<< fb_vga.c coments that were not put by me | 10:06 |
| DrJoel | those sound like CVS conflicts.. remove the file and update again | 10:07 |
| roxanal | aaa ok | 10:07 |
| DrJoel | did you see a "C" in the 1st column on that file? Instead of a "U"? | 10:07 |
| roxanal | bo | 10:08 |
| roxanal | no | 10:08 |
| DrJoel | hmm.. ok.. | 10:08 |
| roxanal | Let me try to delete and update again | 10:08 |
| roxanal | DrJoel: I updated it and looks ok now | 10:12 |
| *** th_d has quit IRC | 10:12 | |
| DrJoel | roxanal: great | 10:12 |
| DrJoel | dr__house: how do the posix message queue or the priority ceiling mutex cases look? | 10:12 |
| DrJoel | fwiw i killed the region resize case last night | 10:13 |
| tuxmaniac | roxanal: it was cvs merge conflicts. you might have changed some things in the same place as that in the cvs. hence the <<< comments | 10:13 |
| DrJoel | and am working on the last killinfo cases.. posix signals are weird | 10:13 |
| dr__house | DrJoel: oh ok. I thought that might have been interesting :P | 10:13 |
| roxanal | tuxmaniac: tks | 10:14 |
| dr__house | DrJoel: I meant the region resize | 10:14 |
| tuxmaniac | and to your question about mmap status ages back, it is slightly behind schedule. catching up | 10:14 |
| tuxmaniac | roxanal: ^ | 10:14 |
| DrJoel | dr__house: which has more code to kill? | 10:15 |
| dr__house | DrJoel: I think I shall start off with priority ceiling mutex | 10:16 |
| roxanal | tuxmaniac: don't worry about mmap I can work without it for a while | 10:17 |
| DrJoel | dr__house: ok.. i hope my explanation is right.. verify that it makes sense when you look at the assembly before doing more | 10:17 |
| dr__house | DrJoel: sure | 10:17 |
| dr__house | DrJoel: and then maybe tackle all the mutex cases at once | 10:18 |
| dr__house | DrJoel: there seems to be one other mutex initialization case | 10:18 |
| DrJoel | i worry that some of these weird small cases might be cases where it isn't a missing test, it is a code rework .. so if you have doubts let me double check | 10:19 |
| dr__house | DrJoel: in the report for coremutexsurrender.c the explanation says "" | 10:20 |
| dr__house | There must not be a test of a priority ceiling mutex getting released | 10:20 |
| dr__house | which results in a thread being unblocked and the UNBLOCKED thread's | 10:20 |
| dr__house | priority being elevated. | 10:20 |
| dr__house | DrJoel: I didn't get "There must not be .." | 10:21 |
| DrJoel | first .. new dedicated test :-D | 10:23 |
| DrJoel | two threads... Init has any priority less important than ceiling.. acquires priority ceiling mutex | 10:23 |
| DrJoel | creates 2nd thread with priority == ceiling priority of mutex | 10:23 |
| DrJoel | Init sleeps .. 2nd thread runs.. blocks on priority ceiling mutex | 10:24 |
| dr__house | ok | 10:24 |
| DrJoel | Init wakes up.. releases mutex.. it is transferred to 2nd thread.. which is already at the priority ceiling so it does NOT need its priority changed.. thus you take the branch and do not have to do the _Thread_Change_priority | 10:24 |
| DrJoel | so this is definitely a case where the annulled instruction shows us we missed a test case :-D | 10:25 |
| dr__house | ok | 10:26 |
| dr__house | DrJoel: Dinner time, be back in a little while | 10:26 |
| DrJoel | definitely easier to create a new test :-D | 10:26 |
| * dr__house is away: afk | 10:26 | |
| DrJoel | no problem.. | 10:26 |
| dr__house | DrJoel: heh, yeah :) | 10:27 |
| *** madrazr has quit IRC | 10:28 | |
| *** sebhub has quit IRC | 10:28 | |
| *** madrazr has joined #rtems | 10:48 | |
| *** cocan has quit IRC | 10:54 | |
| *** cocan has joined #rtems | 11:00 | |
| * dr__house is back. | 11:00 | |
| DrJoel | how was dinner? | 11:04 |
| * DrJoel was asked to lunch by his daughter.. she is picking me up in about 25 minutes | 11:04 | |
| dr__house | DrJoel: dinner was usual :) | 11:07 |
| dr__house | DrJoel: thats nice :) | 11:07 |
| *** lee21 has quit IRC | 11:22 | |
| dr__house | DrJoel: where should the new test case go in the testsuite? | 11:26 |
| *** switnick has quit IRC | 11:30 | |
| DrJoel | I think you can hit this with the classic api so it should go in the sptests | 11:33 |
| DrJoel | sp63? | 11:33 |
| dr__house | DrJoel: cool | 11:38 |
| *** switnick has joined #rtems | 11:42 | |
| *** lee21 has joined #rtems | 12:09 | |
| dr__house | DrJoel: where can I access the logs from rtemsLogger? Are they hosted anywhere? | 12:23 |
| tuxmaniac | dr__house: rtems.com/irclogs | 12:23 |
| dr__house | tuxmaniac: cool, thanks :) | 12:23 |
| switnick | DrJoel: have everything running now | 12:24 |
| switnick | seems to be running very slowly | 12:25 |
| switnick | is this normal? | 12:25 |
| *** lee21 has quit IRC | 12:43 | |
| *** lee21 has joined #rtems | 12:47 | |
| DrJoel | switnick: on real hardware? | 12:49 |
| switnick | yes | 12:50 |
| switnick | having a few interface problems i think | 12:50 |
| switnick | just wondering how long the hello sample should take to run | 12:50 |
| DrJoel | it is faking out the passage of time by having a special idle task call clock tick until it has gone long enough so definitely no correspondence to real time | 12:50 |
| switnick | ?? | 12:50 |
| DrJoel | hello is pretty quick normally | 12:51 |
| DrJoel | does the simulator tell you how many instructions it executes? | 12:51 |
| DrJoel | or can we approximate it by the number of lines in the trace? | 12:51 |
| switnick | yes | 12:51 |
| switnick | did some calc | 12:51 |
| DrJoel | and ..? | 12:51 |
| switnick | should be less than a second | 12:51 |
| switnick | so I must have a problem | 12:52 |
| switnick | I'm going to try and setup ddd | 12:52 |
| switnick | have a few ideas | 12:52 |
| switnick | will get back to you with progress | 12:53 |
| DrJoel | ok.. | 12:53 |
| roxanal | DrJoel: did you got/read my email about the Nano-X license? | 12:56 |
| DrJoel | yes.. need to read that license and think | 12:56 |
| roxanal | ok let me know... that is the next step I have to think about | 12:57 |
| roxanal | if we can | 12:58 |
| roxanal | not have them in I have to find a solution | 12:58 |
| DrJoel | nd if You include a notice stating that the Source Code version of the Covered Code is available under the terms of this License, including a description of how and where You have fulfilled the obligations of Section 3.2. | 13:00 |
| DrJoel | agrier: needs to confirm my reading but I think that the MPL is compatible with the RTEMS GPL+exception intention. We do not want you to have to distribute any source for anything RTEMS related with your RTEMS application. So it would be better to avoid MPL I think | 13:01 |
| DrJoel | http://www.svgalib.org/ should have similar code which is appropriately licensed for inclusion in RTEMS | 13:03 |
| roxanal | OK ... I was looking at svgalib already ;) | 13:04 |
| agrier | wait wait wait... can't we use the existing routines from vgainit.c ? | 13:04 |
| agrier | or perhaps they were being used already? | 13:08 |
| * agrier looks at linker trace to see where ega_hwinit and ega_hwterm are coming from | 13:08 | |
| agrier | I had been assuming they were coming from nano-X, but I could be mistaken. | 13:09 |
| roxanal | agrier: ega_* are coming form vgainit.c | 13:09 |
| roxanal | which is a file that got into rtems a while ago | 13:10 |
| roxanal | but is the same one that nanox is using | 13:10 |
| agrier | we could get greg to clarify the licensing of that file | 13:10 |
| DrJoel | oh.. it is an old version with the license OK | 13:11 |
| DrJoel | * Permission is granted to use, distribute, or modify this source, | 13:11 |
| DrJoel | * provided that this copyright notice remains intact. | 13:11 |
| DrJoel | no fear | 13:11 |
| roxanal | right now the file has a statement that we have "Permission is granted to use, distribute, or modify this source, | 13:12 |
| roxanal | * provided that this copyright notice remains intact." | 13:12 |
| DrJoel | and that's cool. We complied and there are no further license issues. | 13:12 |
| roxanal | just to clarify: it is ok to use it then | 13:13 |
| DrJoel | yes. it is ok to continue to use. | 13:15 |
| roxanal | Thank you :) | 13:15 |
| *** madrazr has quit IRC | 13:21 | |
| *** madrazr has joined #rtems | 13:21 | |
| *** cocan has quit IRC | 13:33 | |
| *** cocan has joined #rtems | 13:34 | |
| *** cocan has quit IRC | 13:45 | |
| DrJoel | tuxmaniac: looking forward to the races (saw status on fb) | 13:49 |
| tuxmaniac | DrJoel: actually I am not able to read data from teh segment registers because of this news :P | 13:49 |
| DrJoel | LOL | 13:51 |
| tuxmaniac | DrJoel: I am seeing _read_DAR functions used in vector_init.c but could not find its definition. a grep doesnt turn up anything | 14:08 |
| tuxmaniac | DrJoel: c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/vectors_init.c | 14:08 |
| DrJoel | ty for the path :_ | 14:08 |
| tuxmaniac | I wonder how it compiles then | 14:08 |
| DrJoel | ;-D | 14:08 |
| DrJoel | SPR_RO(DAR) | 14:09 |
| DrJoel | instantiates the method like I tried to show in my email | 14:09 |
| *** madrazr has quit IRC | 14:09 | |
| DrJoel | #include <libcpu/spr.h> | 14:09 |
| DrJoel | was near the top.. that's all that's required to instantiate the SPR methods | 14:09 |
| tuxmaniac | that doesnt have the definition of _read_DAR | 14:10 |
| tuxmaniac | i mean spr.h | 14:10 |
| DrJoel | SPR_RO(DAR) | 14:11 |
| tuxmaniac | aah I got it | 14:11 |
| DrJoel | fancy schmancy macro :-D | 14:11 |
| tuxmaniac | i was looking for _read_DAR itself like _read_SR | 14:11 |
| DrJoel | saves what you went through | 14:11 |
| tuxmaniac | DrJoel: true :S | 14:11 |
| *** cocan has joined #rtems | 14:35 | |
| DrJoel | dr__house: still there? | 15:26 |
| dr__house | DrJoel: yep | 15:26 |
| dr__house | was replying to your mail | 15:26 |
| DrJoel | the mqueuedelete path was unreachable. you have to call mq_unlink before mq_delete and it frees the memory | 15:27 |
| DrJoel | so 24 cases now and you get to ignore that one. :-D | 15:27 |
| dr__house | DrJoel: great! | 15:27 |
| DrJoel | i will do another run to verify but that leaves you focused on two big chunks in mq creation | 15:27 |
| dr__house | DrJoel: yeah cool. | 15:28 |
| dr__house | DrJoel: will look into them tomorrow, time for me to head off for the day :). Have to wake up early tomorrow. | 15:28 |
| DrJoel | your two cases should be straight forward (I hope). If you have trouble with the mq's read the opengroup.org man pages | 15:28 |
| dr__house | DrJoel: Sure. Catch you tomorrow. Have a good day. | 15:29 |
| *** dr__house has quit IRC | 15:30 | |
| DrJoel | tuxmaniac: what's your code.google.com page? | 16:48 |
| *** cocan has quit IRC | 16:50 | |
| switnick | DrJoel: Still havent been able to fix the problem | 16:55 |
| switnick | I've sent an email to eric asking for help | 16:55 |
| DrJoel | i saw it. I have no idea what's up with that. | 16:57 |
| switnick | It is working but really slowly | 16:57 |
| DrJoel | i guess it would be time to see if you can spot something in the printk disassembly that would make it "fix" the runs | 16:57 |
| DrJoel | did you calc how many instructions and how long it should ahve taken? | 16:58 |
| switnick | ~38000 | 16:58 |
| switnick | I set a breakpoint at boot_card | 16:59 |
| switnick | and got it to run successfully | 16:59 |
| DrJoel | the trace time stamp appears to be nanoseconds.. I terminated at Init in ticker.exe and it took 38619000 to get there | 17:02 |
| DrJoel | so I think ~38.s milliseconds. to initialize RTEMS. Right? | 17:03 |
| switnick | yea | 17:04 |
| switnick | thats what I got aswell | 17:04 |
| DrJoel | so anything you call slow is wrong. :-D | 17:04 |
| DrJoel | maybe real hw has a clock we have to touch | 17:05 |
| DrJoel | or mem controller.. max wait states by default? | 17:05 |
| switnick | I set the osc to 8Mhz | 17:06 |
| switnick | so even if its taking 4 or 5 clock cycles per instructions cycles should be running faster that ~38 ms | 17:07 |
| switnick | I think it might be the connection from comp to debugger | 17:08 |
| DrJoel | do you have any breakpoints? | 17:09 |
| switnick | yes | 17:09 |
| DrJoel | does it run faster without them? | 17:09 |
| switnick | I got one to break at boot card | 17:09 |
| switnick | no, even stepping takes a long time | 17:10 |
| DrJoel | unix or windows? | 17:10 |
| DrJoel | does the kit come with a known working executable to try/ | 17:12 |
| DrJoel | if not ask eric for one | 17:12 |
| * DrJoel is out the door | 17:12 | |
| DrJoel | bye all | 17:12 |
| *** DrJoel has quit IRC | 17:12 | |
| *** switnick has quit IRC | 17:14 | |
| *** cocan has joined #rtems | 17:45 | |
| *** DrJoel has joined #rtems | 19:13 | |
| *** ChanServ sets mode: +o DrJoel | 19:13 | |
| *** chrisjohns has joined #rtems | 19:32 | |
| *** cocan has quit IRC | 19:43 | |
| *** cocan has joined #rtems | 19:44 | |
| *** DrJoel has quit IRC | 19:54 | |
| *** cocan has quit IRC | 20:57 | |
| *** DrJoel has joined #rtems | 21:18 | |
| *** ChanServ sets mode: +o DrJoel | 21:18 | |
| *** DrJoel has quit IRC | 21:30 | |
| *** chrisjohns has quit IRC | 23:46 | |
| *** chrisjohns has joined #rtems | 23:46 | |
| *** madrazr has joined #rtems | 00:43 | |
| *** sebhub has joined #rtems | 01:54 | |
| sebhub | good morning | 02:07 |
| kiwichris | hi seb | 02:07 |
| sebhub | chris: why is 'extern const char* bsp_boot_cmdline;' conditionally declared in confdefs.h? | 02:08 |
| kiwichris | I will have a look. | 02:08 |
| kiwichris | it is only conditional on confdefs.h providing an Init table | 02:09 |
| kiwichris | or am I missing something ? | 02:09 |
| sebhub | yes, but this is the only place where it is declared | 02:10 |
| sebhub | i will add it also to bootcard.h | 02:10 |
| kiwichris | yes you are correct. Hmmm I will need to think about this a little more. | 02:10 |
| kiwichris | I think bootcard.h is a good place. | 02:11 |
| kiwichris | I am fighting confdefs.h and dummy.o at the moment. | 02:11 |
| kiwichris | I think there are problems with them. | 02:11 |
| kiwichris | Did you manage to take a look at my email about the bdbuf code I sent ? | 02:12 |
| sebhub | i was on holiday half of this week | 02:12 |
| kiwichris | Nice. | 02:12 |
| kiwichris | Lucky you. | 02:13 |
| kiwichris | I have completed coding and in testing. Seems to break down with a large disk. | 02:13 |
| kiwichris | I have not tested the changing of buffer sizes but will. | 02:13 |
| sebhub | i will have a look at it now | 02:13 |
| kiwichris | Ok. I have implemented worker threads for the swap out task. | 02:14 |
| kiwichris | I have no time to test this code. It also need a couple of async type output devices like SPI. | 02:14 |
| kiwichris | There is a design issue with worker threads and driver we need to think about. | 02:15 |
| tuxmaniac | I am a bit curious on some OT stuff. Hope its ok to ask here. sebhub and kiwichris are you both also part of OAR or ou do RTEMS work as part of some other firm which also uses RTEMS? | 02:26 |
| sebhub | i work for embedded brains GmbH in munich | 02:27 |
| kiwichris | I am not part of OAR but do consult to them and other. | 02:27 |
| tuxmaniac | sebhub: aah that I know. So you work for clients who have RTEMS based systems right? | 02:28 |
| sebhub | yes | 02:29 |
| kiwichris | tuxmaniac, it would be fair to say all contributors work for people with RTEMS based systems :) | 02:30 |
| kiwichris | tuxmaniac, paid or not. | 02:30 |
| tuxmaniac | kiwichris: ofcourse :) | 02:30 |
| tuxmaniac | nah I was just curious about your works. Because when I was working, I used to do Open source work only during the nights. My day job was different. It must be interesting to match your day job with your passion. hence asked | 02:32 |
| tuxmaniac | hence I quit and became a student :P | 02:32 |
| *** madrazr has quit IRC | 02:34 | |
| kiwichris | sebhub, have you played with new default Init I added ? | 02:48 |
| sebhub | what is new with the Init? :-) | 02:52 |
| sebhub | I did not notice a change | 02:52 |
| kiwichris | If you define CONFIGURE_RTEMS_INIT_TASKS_TABLE you do not need to define an Init, rather main will be called. | 02:52 |
| kiwichris | The Init is hidden away for you if you do not want it. | 02:53 |
| sebhub | ah | 02:53 |
| kiwichris | It has a little issue which I would to figure out. I currently initialise the networking if RTEMS is configured with networking. | 02:54 |
| *** madrazr has joined #rtems | 05:23 | |
| *** madrazr has quit IRC | 05:23 | |
| *** madrazr has joined #rtems | 05:40 | |
| *** madrazr has quit IRC | 06:11 | |
| *** madrazr has joined #rtems | 06:13 | |
| *** madrazr has quit IRC | 07:10 | |
| *** madrazr has joined #rtems | 07:11 | |
| *** DrJoel has joined #rtems | 07:14 | |
| *** ChanServ sets mode: +o DrJoel | 07:14 | |
| kiwichris | Hi Joel | 07:17 |
| *** cocan has joined #rtems | 07:17 | |
| *** chrisjohns has quit IRC | 07:18 | |
| DrJoel | kiwichris: hi | 07:18 |
| kiwichris | I have split the dummy.c file in 2. | 07:18 |
| DrJoel | good. I know it causes problems sometimes being one lump | 07:19 |
| kiwichris | I have created dummy-networking.c | 07:19 |
| sebhub | hi | 07:19 |
| DrJoel | sebhub: hello | 07:19 |
| kiwichris | My new Init initialises networking and I think we may need something else here. | 07:20 |
| kiwichris | This is the Init that calls main for you if your app does not contain an Init. | 07:20 |
| DrJoel | ok.. i am tinkering with standard helpers for the bsp cmdline you added | 07:20 |
| kiwichris | Nice. | 07:21 |
| kiwichris | I have the cache code building but have a problem. My bdbuf tester is showing some problems. | 07:21 |
| kiwichris | Will hut them down tomorrow. After that no need to pre-allocate buffer pools. | 07:22 |
| kiwichris | Will hunt them down tomorrow. After that no need to pre-allocate buffer pools. | 07:22 |
| * DrJoel was going to ask if one of you could try to figure out a test case to get to the heap allocate aligned case. It is now ~25% of the remaining instructions to cover. :( | 07:22 | |
| DrJoel | anyone who volunteers will get an email. :-D | 07:22 |
| DrJoel | brb | 07:22 |
| kiwichris | What do you mean by " heap allocate aligned case" ? | 07:22 |
| sebhub | sry, i am very busy until the usb mass storage works | 07:22 |
| sebhub | btw: what happend to the RTEMS_MALLOC_BOUNDARY_HELPERS? | 07:24 |
| kiwichris | DrJoel, I did notice warnings in functions like _Protected_heap_Resize_block (pheapresizeblock.c). Why is intptr_t being used rather than uintptr_t ? | 07:24 |
| DrJoel | kiwichris: i don't know why it is signed. | 07:26 |
| DrJoel | sometimes it is a +/- thing for offsets but not likely there | 07:26 |
| kiwichris | DrJoel, there is a bunch of these warnings. | 07:26 |
| kiwichris | DrJoel, yeah with size of memory a -ve does not make sense. | 07:26 |
| sebhub | the types for the task stack allocator should also match the heap types | 07:26 |
| DrJoel | kiwichris: we have 24 cases for 260 bytes (45 instructions) left to cover for the profile (score, rtems, sapi and posix dirs) we have been examining on the erc32 | 07:27 |
| *** cocan has quit IRC | 07:27 | |
| kiwichris | DrJoel, nice. Ah this is the heap traces you sent me. | 07:28 |
| DrJoel | there is a 12 instruction (48 byte) sequence in _Heap_Allocate_aligned that I can' t figure out how to get to -- even going directly to the heap API and using a fresh heap | 07:28 |
| sebhub | interesting | 07:28 |
| kiwichris | What would break if you removed them ? | 07:29 |
| DrJoel | santosh is working on a new test that will cover another 60 bytes. :-D | 07:29 |
| DrJoel | I have no idea. I can't get my head around the logic there enough to know if it is impossible to reach or not | 07:29 |
| DrJoel | I emailed Sergei Organov (who submitted it a few years ago) a couple of weeks ago but no reply. Email address may no longer be good .. who knows | 07:30 |
| kiwichris | Sure | 07:30 |
| * kiwichris off for the night | 07:31 | |
| * kiwichris is away: I'm away but logging | 07:31 | |
| DrJoel | sebhub: how's the usb going? | 07:32 |
| sebhub | i did not work with it the last two weeks | 07:32 |
| sebhub | i hope that i can start next week | 07:33 |
| sebhub | the board initialization with boot from external flash was pretty nasty | 07:33 |
| DrJoel | ok.. i hope you have a magic break through | 07:33 |
| sebhub | regarding the simple binary semaphores: are non recursive mutexes available via the classic API? | 07:34 |
| DrJoel | it's early.. what do you mean by non-recursive? | 07:36 |
| sebhub | a task blocks as soon as it tries to obtain the mutex more than once | 07:37 |
| DrJoel | that's what a simple binary semaphore does | 07:37 |
| DrJoel | the_mutex_attr.lock_nesting_behavior = CORE_MUTEX_NESTING_BLOCKS; | 07:38 |
| DrJoel | the_mutex_attr.only_owner_release = false; | 07:38 |
| DrJoel | so the assumption is that we don't track the thread that locks the simple bin sem so it can be released by any other thread/ISR. If unavailable, you block | 07:38 |
| sebhub | yes, but then priority inheritance is not available | 07:39 |
| sebhub | and i guess also priority ceilling | 07:40 |
| DrJoel | right.. you have to track the holder to have the priority inversion avoidance protocols. This combination of attributes slipped through the error checks but wasn't there. I recently improved the error checking | 07:40 |
| sebhub | ok, so there is a difference to the FreeBSD mutex API here. this should not be a big problem | 07:42 |
| DrJoel | if you like, email me a link to a description of them and I will take the time to think when I am really awake | 07:42 |
| * DrJoel needs to head to the office .. | 07:42 | |
| DrJoel | bye for now | 07:43 |
| *** DrJoel has quit IRC | 07:43 | |
| *** cocan has joined #rtems | 07:43 | |
| *** cocan_ has joined #rtems | 08:05 | |
| *** cocan has quit IRC | 08:07 | |
| *** cocan_ is now known as cocan | 08:07 | |
| *** cocan_ has joined #rtems | 08:31 | |
| *** cocan has quit IRC | 08:32 | |
| *** cocan_ is now known as cocan | 08:32 | |
| *** DrJoel has joined #rtems | 08:57 | |
| *** ChanServ sets mode: +o DrJoel | 08:57 | |
| * DrJoel is now at the office.. as if anyone notices .. LOL | 09:01 | |
| sebhub | i am nearly finished for today ;-) | 09:01 |
| * tuxmaniac notices | 09:01 | |
| tuxmaniac | DrJoel: I think PSIM also oes a pte search as loading a out of memory range (a address out of the one in linkcmds) seem to result in a unmapped address is trying to be accessed error | 09:02 |
| tuxmaniac | does* | 09:02 |
| tuxmaniac | loading into SDR1 register I mean | 09:03 |
| tuxmaniac | trying to check if its me or psim and have been doing it the whole day now :) | 09:03 |
| *** madrazr has left #rtems | 09:08 | |
| DrJoel | tuxmaniac: psim has some tracing options which might help you and you have the source :-D | 09:09 |
| *** cocan_ has joined #rtems | 09:09 | |
| *** cocan has quit IRC | 09:10 | |
| *** cocan_ is now known as cocan | 09:10 | |
| tuxmaniac | DrJoel: yes. checking the source | 09:10 |
| tuxmaniac | :) | 09:10 |
| *** cocan has quit IRC | 09:12 | |
| *** cocan has joined #rtems | 09:27 | |
| sebhub | is there a special reason why static char ttyname_buf[sizeof (_PATH_DEV) + MAXNAMLEN] = _PATH_DEV; is initialized this way in ttyname.c? | 09:57 |
| DrJoel | that's BSD code. I have no idea. On the head, it is actually disabled and we use the implementation in newlib. It is the static buffer used by ttyname which wraps ttyname_r. I would ask on the newlib list but suggest that ttyname.c be split into ttyname.c (w/static buf) and ttyname_r.c | 10:08 |
| sebhub | ah ok, so the file in libcsupport is actually dead code on the head | 10:11 |
| sebhub | hm, I have /opt/rtems-4.10/arm-rtems4.10/lpc24xx_ncs_ram/lib/librtemscpu.a(libcsupport_a-ttyname.o) this in my linker map file | 10:12 |
| sebhub | so I don't use the newlib version? | 10:13 |
| DrJoel | it should have 0 .text. It is compiled all the time but see HAVE_TTYNAME or something in there | 10:13 |
| DrJoel | but the implementation is the same. We just got rid of all cases in libcsupport where code havd been copied from newlib over the years | 10:14 |
| sebhub | ./arm-rtems4.10/c/lpc24xx_ncs_ram/cpukit/config.h:/* #undef HAVE_TTYNAME */ | 10:14 |
| sebhub | I have the ttyname stuff from libcsupport | 10:15 |
| DrJoel | hmm.. I dont | 10:17 |
| DrJoel | Hmmm.. I have the same thing | 10:17 |
| DrJoel | Ask on the list. I think we need to coordinate this via Ralf. We can split the file in libcsupport as I suggested but newlib needs to split it also and we want to move to their implementation.. So 3 things and I wonder why it isn't turned on... so best to get his feedback. He was trackign this and might have missed it. Or there is a reason | 10:18 |
| sebhub | i asked some time ago an the newlib list and it is already fixed in newlib | 10:19 |
| sebhub | in the cpukit configure.ac is a FIXME comment around ttyname | 10:22 |
| DrJoel | LOL | 10:22 |
| DrJoel | ask Ralf what's broken with ttyname configure.ac. it is his FIXME. looks like 1/3 of the job is done, we just need to split it in RTEMS and then properly handle turning it off | 10:23 |
| sebhub | in the cpukit doxygen documentation these handler modules belong all to the supercore? | 10:29 |
| DrJoel | huh? i don't understand/ | 10:30 |
| sebhub | we have a group (= module) hierarchy in the doxygen cpukit documentation with various group names that have a handler in them | 10:31 |
| sebhub | maybe it is better to put all of them in a super group "Super Core" or so | 10:32 |
| tuxmaniac | shouldnt the psim trace be enabled when I put the --enable-sim-trace in the rtems configure command itself? | 10:32 |
| tuxmaniac | [tuxmaniac@yoda psim]$ ../rtems/configure --target=powerpc-rtems4.10 --disable-multiprocessing --enable-cxx --disable-rdbg --enable-maintainer-mode --enable-tests --enable-networking --enable-posix --disable-itron --disable-deprecated --disable-ada --enable-expada --enable-rtemsbsp=psim CLOCK_DRIVER_USE_FAST_IDLE=0 | 10:33 |
| tuxmaniac | --enable-sim-trace | 10:33 |
| DrJoel | Each group should indicate a logical handler/object/package .. like chain, thread, thread queue. Not the entire subsystem. If there is a way to collect them together into a higher level that would be good. Then you would have a subsystem called Classic, POSIX, SuperCore and individual objects/groups within there | 10:34 |
| DrJoel | tuxmaniac: no.. --enable-sim-trace is a gdb build option | 10:34 |
| sebhub | yes, that is how i have done it with the Classic in the latest patch | 10:35 |
| DrJoel | like nested groups? | 10:35 |
| *** switnick has joined #rtems | 10:36 | |
| sebhub | goups may contain groups | 10:36 |
| sebhub | and one group may be contained in different groups | 10:36 |
| DrJoel | then we should have a SuperCore Group and a Classic API group, etc | 10:37 |
| DrJoel | with subgroups under them | 10:37 |
| sebhub | yes, see my latest patch | 10:37 |
| DrJoel | cool .. neatly reflects intended organization | 10:37 |
| DrJoel | it is in the queue.. :) | 10:37 |
| sebhub | *g* | 10:37 |
| sebhub | i want to structure it a little bit before the trainee gets hand on it | 10:38 |
| DrJoel | I try to convert a .h to Doxygen everytime I edit one now. | 10:38 |
| sebhub | that good, but we should agree on a standard Doxygen comment style | 10:39 |
| DrJoel | agreed. | 10:40 |
| DrJoel | when i do this i am not rewriting existing comments, just reformatting | 10:40 |
| sebhub | I personally don't like the @param directives, I think the in text parameter description like in man pages, Java API and Qt is better | 10:40 |
| DrJoel | it's a lot of monkey work to change them | 10:41 |
| tuxmaniac | DrJoel: so i rebuild gdb 4.16 with this option to verify whats really happening inside psim? | 10:42 |
| sebhub | yes, thats it | 10:42 |
| tuxmaniac | sebhub: is that for my question? | 10:42 |
| sebhub | no its for the monkey work ;-) | 10:43 |
| tuxmaniac | ok :) | 10:43 |
| DrJoel | tuxmaniac: why 4.16? gdb is at 6.8? you want a 10+ year old gdb LOL | 10:43 |
| DrJoel | it looks like the --enable-sim-trace option is turned on when the RPMs are built. It is up to you to hack on the device tree built by "psim" or psim-gdb to enable it | 10:44 |
| tuxmaniac | aah ok | 10:45 |
| DrJoel | you should be able to add a -t option to the "tar sim" command argumetns in the gdb script and add the trace options. Do a powerpc-rtems4.10-run --help and see the arguments | 10:47 |
| switnick | DrJoel: Hello | 10:54 |
| DrJoel | switnick: hi | 10:59 |
| switnick | DrJoel: Just an update, talking to Eric | 11:01 |
| DrJoel | i saw that it probably works better on windows | 11:01 |
| switnick | yea | 11:01 |
| switnick | is there some way to compile in windows? | 11:01 |
| DrJoel | yes but easier if you just use a virtual machine and Linux sometimes and Wndows sometimes .. share a folder and put exe in it. You would have to rebuild tools to windows host and that creates its own set of issues. Better to just use windows for debugger | 11:03 |
| switnick | ok | 11:04 |
| DrJoel | if you need a VMWare image, we have one available for torrent. I also have a Fedora 10 VirtualBox image but I don't know if it is finished yet. | 11:05 |
| switnick | ok | 11:10 |
| switnick | I think I should be ok | 11:10 |
| switnick | but thanks | 11:12 |
| *** cocan has quit IRC | 11:14 | |
| *** sebhub has quit IRC | 11:47 | |
| *** madrazr has joined #rtems | 11:58 | |
| *** switnick has quit IRC | 12:02 | |
| *** roxanal has quit IRC | 12:07 | |
| *** roxanal has joined #rtems | 12:26 | |
| *** switnick has joined #rtems | 12:38 | |
| tuxmaniac | DrJoel: changed the device tree ram settings and it seems it works. But still it doesnt answer my doubt of hardware pte search | 13:35 |
| tuxmaniac | tried changing the model that is simulated to be 603 which does not do hardware tlb search itself. | 13:35 |
| tuxmaniac | still the same issue | 13:35 |
| tuxmaniac | looking into it now | 13:35 |
| DrJoel | sorry.. sometimes simulators are good.. other times they require work. | 13:36 |
| DrJoel | qemu has a powerpc simulation but we don't have a BSP for it. But it might make a good reference | 13:36 |
| agrier | apparently mozilla has stacks of nokia phones to test fennec on | 13:38 |
| agrier | the simulator nokia provided them is buggy in different ways than the actual hardware | 13:39 |
| DrJoel | cool.. wish we had a big sugar daddy ;) | 13:39 |
| agrier | back in January they were looking for symbian experience. now it's shifted to linux... | 13:40 |
| tuxmaniac | agrier: yes. I remember the mozilla folks displaying some cool nokia phones at fosdem last year. some that are just prototypes with all black plastic around etc | 13:40 |
| tuxmaniac | :) | 13:40 |
| agrier | I have images in my mind of cellphones hot-glued to rackmount shelves | 13:41 |
| *** switnick has quit IRC | 13:44 | |
| *** switnick has joined #rtems | 13:44 | |
| switnick | DrJoel: Hello sorry to bother you again | 13:52 |
| DrJoel | switnick: no problem | 13:53 |
| switnick | I think I need to add some flags for the asm compilation | 13:53 |
| switnick | not sure where to add them | 13:54 |
| switnick | ASMFLAGS = $(CFLAGS) -Wa,-gstabs | 13:54 |
| switnick | something like this | 13:54 |
| tuxmaniac | any idea what generates the psim_tree. I ahve modified the linkcmds as well as the c/src/lib/libbsp/powerpc/psim/startup/device_tree to increase the oea memory size. still the psim_tree.tuxmaniac that gets generated has only 8 MB as oea memory | 13:55 |
| tuxmaniac | this file gets generated when I run the tests/psim-gdb | 13:55 |
| tuxmaniac | imodified the linkcmds and device_tree to have 64 MB | 13:56 |
| tuxmaniac | rebuilt it from scratch | 13:56 |
| DrJoel | tuxmaniac: are you using the sim-scripts from the gcc-testing cvs module? | 13:58 |
| DrJoel | switnick: you should be able to add those to CPU_CFLAGS in make/custom/avrtest.cfg... just add the Wa,...part | 13:59 |
| switnick | ok | 13:59 |
| switnick | will try that thanks | 13:59 |
| tuxmaniac | no. the ones inside the psim directory that gets populated in make | 14:00 |
| DrJoel | tuxmaniac: the scripts in that cvs module are newer and smarter .. derived from what you are looking at but better | 14:01 |
| DrJoel | if you check that out, see psim.in and *gdb*in .. everything is magically put together to share the infrastructure so all simulators are run by the same commands | 14:01 |
| tuxmaniac | yeah looking into those now | 14:01 |
| DrJoel | in the new scripts, there is a method called something like bspGenerateDeviceTree and "GetSimArgs" which should be what you are looking for | 14:02 |
| tuxmaniac | thank you DrJoel | 14:03 |
| DrJoel | bspGenerateGDBCommands in psim.in | 14:03 |
| DrJoel | these scripts are (IMHO as author) very neat. ABout 20 simulators all invoked with the same arguments. THe script is named BSP and it makes building test infrastructre on top of it a LOT easier since orthogonality is the name of the game | 14:04 |
| DrJoel | patches are gladly accepted. | 14:04 |
| DrJoel | the next step is to intewgrate the RTEMS GDB macros into the gdb side so they are always included for you | 14:04 |
| tuxmaniac | nice | 14:04 |
| tuxmaniac | DrJoel: :D fixed. *phew* | 14:19 |
| DrJoel | tuxmaniac: :D | 14:19 |
| DrJoel | Is there anything to add to the psim scripts | 14:19 |
| tuxmaniac | DrJoel: i dont think so. it worked. But I have another conceptual issue with psim. | 14:20 |
| tuxmaniac | grrr. | 14:20 |
| tuxmaniac | psim keeps calling the exception handler without completely executing the funcntion. | 14:21 |
| tuxmaniac | i mean the handler | 14:21 |
| tuxmaniac | so all it does is repeated calling of the exception handler and whenever it tries to execute a few statement, it again calls the exception handler and this goes into a vicious loop | 14:21 |
| tuxmaniac | I am trying to fix that now | 14:22 |
| tuxmaniac | :) | 14:22 |
| roxanal | DrJoel: the documentation is almost ready. I am waiting to hear back from Aaron if he wants me to change some things before submitting it to you | 15:02 |
| DrJoel | roxanal: :-D | 15:03 |
| *** lee21 has quit IRC | 15:21 | |
| * agrier reads docs | 15:21 | |
| agrier | Joel, is there any guideline for moving code into libchip? I am thinking of vgainit.c, specifically | 15:23 |
| roxanal | I was just about to ask that also | 15:24 |
| DrJoel | (1) the code has to deal with a peripheral that is not unique to a single board | 15:24 |
| DrJoel | (2) it should provide a way to configure whatever board specific hooks are needed to touch hardware | 15:24 |
| DrJoel | that's it. I think vga hits (1). What about (2)? Does it use IO instructions that might be memory mapped on another architecture? | 15:25 |
| roxanal | The IO (ioctls) structures and actions are not defined in vgainit.c | 15:28 |
| tuxmaniac | haha. looks like its printk which is the culprit | 15:29 |
| tuxmaniac | printk seems to cause a protected memory access which my MMU doesnt like | 15:29 |
| DrJoel | roxanal: vga_init has out_word which is PC specific. That would have to be configured in a way that register accesses on another board would be handled properly | 15:30 |
| DrJoel | and writeregs.. | 15:30 |
| DrJoel | does that make sense? | 15:31 |
| roxanal | yes | 15:31 |
| DrJoel | tuxmaniac: so are you passing bad data to printk? | 15:31 |
| tuxmaniac | looks like bt I dont know what bad data is . All I do is printk("DSI Exception hit") and this blocked any furhter execution of the exception handler | 15:33 |
| tuxmaniac | and MMU caused another exception when this statement was executed | 15:33 |
| tuxmaniac | and the same happened down the function with another printk | 15:33 |
| tuxmaniac | so now removing both and seeing whether life becomes much better | 15:33 |
| *** cocan has joined #rtems | 15:48 | |
| DrJoel | cocan: how are things going on your projects? | 16:01 |
| switnick | DrJoel: I think the reason I was getting the error was because of the wrong option flag | 16:02 |
| switnick | seems -g was correct | 16:02 |
| switnick | with the debug format to follow | 16:02 |
| cocan | DrJoel: great...I am working now on the decoding..had to go back and change some things on the rtems_trace tool..should finish the decoding part this week | 16:03 |
| DrJoel | switnick: good | 16:03 |
| switnick | DrJoel: the reason for all this is i'm having some problems with avr studio | 16:04 |
| DrJoel | cocan: wonderful.. be sure to start a wiki page on how to do this | 16:04 |
| DrJoel | switnick: well eric w is the man for that. :) | 16:04 |
| switnick | yea | 16:04 |
| switnick | was wondering... | 16:04 |
| switnick | can a generate an asm file? | 16:04 |
| cocan | DrJoel: ok...will do that | 16:05 |
| switnick | that I can assemble with avr studio? | 16:05 |
| DrJoel | sure .. if nothing else look in the logs for a build of a single .S file. Then cut and paste that to a script file.. use -E instead of -o XXX.o and then save the preprocessed output. | 16:08 |
| DrJoel | That will at least give you a preprocessed .s file to use as input to their assembler | 16:09 |
| DrJoel | night all .. heading home | 16:30 |
| *** DrJoel has quit IRC | 16:30 | |
| *** roxanal has quit IRC | 16:54 | |
| *** switnick has quit IRC | 16:55 | |
| *** madrazr has left #rtems | 17:46 | |
| *** madrazr has joined #rtems | 17:47 | |
| *** cocan has quit IRC | 17:55 | |
| *** roxanal has joined #rtems | 18:54 | |
| *** chrisjohns has joined #rtems | 20:32 | |
| *** chrisjohns has quit IRC | 23:42 | |
| * kiwichris is back (gone 17:07:11) | 00:38 | |
| * kiwichris is away: I'm away but logging | 01:19 | |
| *** sebhub has joined #rtems | 01:54 | |
| *** madrazr has joined #rtems | 02:12 | |
| * kiwichris is back (gone 01:11:36) | 02:30 | |
| kiwichris | sebhub, hi | 02:30 |
| sebhub | good morning | 02:31 |
| kiwichris | I am testing a new version of the cache code. Chasing a bug I have introduced. I need someone to test the swapout worker thread change and I do not really a real set up that can use it. | 02:32 |
| kiwichris | I do not have a real set up that can use it. | 02:33 |
| kiwichris | You said you have multidisk set ups. | 02:33 |
| sebhub | i said that the usb may introduce a multi disk setup | 02:33 |
| sebhub | i hope i can start with the mass storage driver next week | 02:34 |
| kiwichris | Ah ok. Any SPI based systems with more than one disk | 02:34 |
| kiwichris | USB would be a really good test. | 02:34 |
| sebhub | my usb deadline is end of august | 02:35 |
| kiwichris | I will finish my tested and the code can sit in the cache until you say more than 0 worker threads. | 02:35 |
| kiwichris | The design issue worker threads brings, is getting more than one thread into a driver at once. | 02:36 |
| kiwichris | Should we assume drivers have protection for this, ie a mutex ? | 02:36 |
| kiwichris | or queue ? | 02:36 |
| sebhub | hm, good question | 02:37 |
| kiwichris | This happens if more than one discontinuous blocks exists in the cache for the same device | 02:38 |
| kiwichris | The other solution is to only allow a single transaction to a single device at a time. This load shares the threads better | 02:39 |
| sebhub | is it not possible to assosiacte the worker threads with the devices | 02:39 |
| sebhub | associate | 02:40 |
| kiwichris | You could have that model and I suspect the changes to implement are not big, but you may only have 2 device active at once with 4 devices in a system. | 02:40 |
| kiwichris | I will not work on this any more so we have some time to ponder the issue. | 02:41 |
| kiwichris | Would you be able to chat to Thomas about it and if you come to a preferred solution let me know via email or IRC ? | 02:41 |
| sebhub | in FreeBSD the device driver specifies how many transactions it can handle concurrently | 02:42 |
| sebhub | ok | 02:42 |
| *** madrazr has left #rtems | 02:42 | |
| kiwichris | Hmm, ok. I suspect that is a DOS type function. | 02:42 |
| kiwichris | or a load share. | 02:43 |
| kiwichris | What this does mean is device can handle more than one thread. | 02:43 |
| kiwichris | For an RTOS we need to think if making the drivers more complex is worth it. | 02:43 |
| kiwichris | I suppose they are already thinking about it more. On the read path we have as many threads in the driver as there are readers. | 02:44 |
| kiwichris | The ATA driver has that silly queue and malloc stuff to handle this. | 02:44 |
| sebhub | yes, if we make it to sophisticated we could have used CAM from FreeBSD | 02:44 |
| kiwichris | CAM ? | 02:44 |
| sebhub | Command Access Method, the storage subsystem in FreeBSD | 02:45 |
| sebhub | one of the biggest subsystems | 02:45 |
| kiwichris | I will look it up. | 02:45 |
| kiwichris | is it Common Access Method or Command Access Method ? | 02:46 |
| sebhub | oh its Common, sry | 02:47 |
| kiwichris | no prob | 02:47 |
| sebhub | for the usb mass storage driver i need to implement parts of the interface to access the standard umass driver | 02:48 |
| kiwichris | If I need a file system that needs that sort of complication I would use FreeBSD, Solaris, Linux etc. | 02:48 |
| kiwichris | I am sure you do as the SCSI command set is almost a standard these days. | 02:49 |
| sebhub | yes, we should keep it simple | 02:49 |
| kiwichris | Does it include the command queuing and scheduling logic to get the best out of the buses ? | 02:49 |
| sebhub | the FreeBSD CAM yes, but my umass interface no | 02:50 |
| kiwichris | And that I think is fair. | 02:50 |
| kiwichris | This is where the system architect needs to think about the cross over between realtime and file system importance. | 02:50 |
| sebhub | yes, real time and average performance are two different goals | 02:52 |
| kiwichris | With my cache changes I have removed all pools from the cache. There is now just a cache and no pools. You specify the min and max size of buffers. | 02:52 |
| kiwichris | The benefit is a single cache is the static struct is global and all accesses are direct so I think the compiler and more to work with to get better code. | 02:53 |
| sebhub | are the buffers a whole multiple of the min size? | 02:53 |
| kiwichris | Yes. | 02:53 |
| kiwichris | eg 512 and 4096 | 02:54 |
| sebhub | ok | 02:54 |
| kiwichris | and allocation is a multiple of 2 | 02:54 |
| kiwichris | brb | 02:54 |
| kiwichris | for 512 and 4096 you have 512, 1024, 2048 and 4096. You can say any size you like but the allocation is the above list. | 02:55 |
| kiwichris | brb | 02:55 |
| *** rokka has quit IRC | 03:15 | |
| *** rokka has joined #rtems | 03:17 | |
| *** madrazr has joined #rtems | 06:12 | |
| *** dr__house has joined #rtems | 06:16 | |
| *** cocan has joined #rtems | 06:40 | |
| *** bazinski has quit IRC | 08:01 | |
| *** bazinski has joined #rtems | 09:47 | |
| *** dr__house has quit IRC | 09:50 | |
| *** madrazr has quit IRC | 09:57 | |
| *** switnick has joined #rtems | 11:09 | |
| *** sebhub has quit IRC | 11:27 | |
| *** madrazr has joined #rtems | 11:28 | |
| *** dr__house has joined #rtems | 11:29 | |
| *** bazinski has quit IRC | 11:41 | |
| *** switnick has quit IRC | 12:39 | |
| *** roxanal has quit IRC | 12:51 | |
| *** cocan has quit IRC | 14:00 | |
| *** cocan has joined #rtems | 14:15 | |
| *** switnick has joined #rtems | 14:18 | |
| *** dr__house has quit IRC | 14:28 | |
| *** switnick has quit IRC | 15:57 | |
| *** switnick has joined #rtems | 16:46 | |
| *** switnick has quit IRC | 17:00 | |
| *** cocan has quit IRC | 17:03 | |
| *** madrazr has quit IRC | 17:35 | |
| *** cocan has joined #rtems | 17:41 | |
| *** cocan has quit IRC | 18:10 | |
| *** cocan has joined #rtems | 18:11 | |
| *** cocan has quit IRC | 18:56 | |
| *** switnick has joined #rtems | 18:59 | |
| *** DrJoel has joined #rtems | 20:01 | |
| *** ChanServ sets mode: +o DrJoel | 20:01 | |
| *** switnick has quit IRC | 22:01 | |
| * kiwichris is away: I'm away but logging | 01:08 | |
| *** madrazr has joined #rtems | 02:24 | |
| *** madrazr1 has joined #rtems | 02:24 | |
| *** madrazr has quit IRC | 02:24 | |
| *** madrazr has joined #rtems | 02:25 | |
| *** madrazr1 has quit IRC | 02:25 | |
| *** madrazr has quit IRC | 05:00 | |
| *** madrazr has joined #rtems | 05:06 | |
| *** madrazr has quit IRC | 06:02 | |
| *** madrazr has joined #rtems | 07:59 | |
| * DrJoel is at home.. still drippy nose and stuffed up head .. logging .. walking by computer when I am up | 08:52 | |
| *** switnick has joined #rtems | 09:10 | |
| *** madrazr1 has joined #rtems | 09:12 | |
| *** madrazr has quit IRC | 09:12 | |
| *** dr__house has joined #rtems | 09:13 | |
| switnick | DrJoel: Hello, I have encountered some difficuties | 09:16 |
| DrJoel | switnick: what kind? | 09:16 |
| switnick | I have been talkin with Eric | 09:16 |
| switnick | he is saying to use the avr studio debugger we will need to build on windows | 09:17 |
| DrJoel | i followed some of it. | 09:17 |
| DrJoel | why doesn't the debugger in their understand the debug information in our executables? | 09:17 |
| DrJoel | they are built from the same sources | 09:17 |
| switnick | it does but it needs the source | 09:17 |
| switnick | and wont debug without it | 09:17 |
| DrJoel | then copy the source so it can find it | 09:18 |
| switnick | hmm | 09:18 |
| switnick | very smart | 09:18 |
| switnick | hadn't thought of that | 09:18 |
| DrJoel | If it lets you get far enough, you can use the gdb "directory" command to fix his search path | 09:18 |
| switnick | ok I will look into that | 09:18 |
| DrJoel | I have been through this before. Lots of tools are windows specific and require weird hw setup .. so build where you want and move what you have to. You can even publish your source directory using Samba and mount it using Windows so you aren't copying it. | 09:19 |
| DrJoel | Just access it across the network | 09:19 |
| DrJoel | play with that.. i am still stopped up.. dripping.. sneezing.. but will walk by the computer | 09:20 |
| DrJoel | need to take a steamy shower and hope it helps this morning | 09:20 |
| *** dr__house has quit IRC | 09:21 | |
| DrJoel | didn't even see dr__house here.. :( | 09:21 |
| switnick | Ok | 09:22 |
| switnick | I will try with that | 09:22 |
| switnick | thanks | 09:22 |
| *** madrazr has joined #rtems | 09:34 | |
| *** madrazr1 has quit IRC | 09:34 | |
| * DrJoel is back.. steamed from shower .. still not feeling great though. :( | 10:10 | |
| *** switnick_ has joined #rtems | 10:17 | |
| *** switnick has quit IRC | 10:19 | |
| *** switnick has joined #rtems | 10:19 | |
| *** switnick_ has quit IRC | 10:35 | |
| *** madrazr has quit IRC | 12:03 | |
| *** madrazr1 has joined #rtems | 12:03 | |
| *** switnick has quit IRC | 12:14 | |
| *** switnick has joined #rtems | 12:15 | |
| *** switnick has quit IRC | 12:23 | |
| *** madrazr has joined #rtems | 12:46 | |
| *** madrazr1 has quit IRC | 12:46 | |
| *** dr__house has joined #rtems | 12:51 | |
| dr__house | DrJoel: Good afternoon | 12:55 |
| * dr__house had a bad headache, but I feel slightly better now. | 12:57 | |
| DrJoel | dr__house: hello.. how's the testing going? | 13:54 |
| dr__house | DrJoel: kind of slow today :( | 13:55 |
| DrJoel | not feeling well or unlucky on the tests? | 13:55 |
| dr__house | DrJoel: not feeling well | 13:55 |
| DrJoel | i'm not either.. messed up a couple of attempts to hit a path through heapallocatealigned.c myself | 13:56 |
| dr__house | DrJoel: hmm.. get well soon to both of us :) | 13:57 |
| *** switnick has joined #rtems | 13:58 | |
| *** madrazr has quit IRC | 15:14 | |
| *** madrazr1 has joined #rtems | 15:14 | |
| *** dr__house has quit IRC | 16:11 | |
| *** madrazr1 has quit IRC | 17:55 | |
| *** switnick has quit IRC | 18:22 | |
| *** madrazr has joined #rtems | 01:01 | |
| *** madrazr1 has joined #rtems | 03:02 | |
| *** madrazr has quit IRC | 03:03 | |
| *** madrazr has joined #rtems | 03:44 | |
| *** madrazr1 has quit IRC | 03:44 | |
| *** madrazr has left #rtems | 06:14 | |
| *** madrazr has joined #rtems | 08:11 | |
| *** lee21 has joined #rtems | 08:38 | |
| *** dr__house has joined #rtems | 09:43 | |
| dr__house | DrJoel: good morning :) | 09:43 |
| DrJoel | dr__house: good morning! is your headache better after a good night's sleep? | 09:44 |
| dr__house | DrJoel: yep | 09:44 |
| DrJoel | i'm still stopped up but bought some new medicine which seemed to dry me up for a while. Need to be passable for a funeral today. :( | 09:44 |
| dr__house | DrJoel: oh ok. :( About that case, I don't think I am hitting the required block of code. The control isn't entering _POSIX_Message_queue_Create_support subroutine | 09:45 |
| DrJoel | hmmm.. send me your patch and let me take a look before I hop in the shower | 09:46 |
| * DrJoel is worried that the big heap case showed up in a run yesterday. I am wondering if it varies based upon the initial alignment of the heap. :( | 09:48 | |
| DrJoel | heap memory I mean | 09:48 |
| dr__house | DrJoel: Sent the patch | 09:59 |
| DrJoel | dr__house: is the code at mqueuecreatesupp.c:101 impossible to trigger because of the attempt to see if the message queue already exists and we are just attaching to it in mqueueopen.c? Just a thought.. let me look at the patch and think | 09:59 |
| dr__house | thats what I too thought | 09:59 |
| dr__house | DrJoel: ^^ | 09:59 |
| dr__house | DrJoel: _POSIX_Message_queue_Create_support() is called only after all the checks are done and hence I think that piece of code is never triggered | 10:00 |
| DrJoel | we allocate an fd in open at line 73 to see if it exists. | 10:00 |
| DrJoel | agreed. We need to mark that check as RTEMS_DEBUG. | 10:01 |
| DrJoel | Wrap it in a "#if defined(RTEMS_DEBUG)" with an explanation comment about why it can't happen. | 10:01 |
| DrJoel | To me.. these are some of the hardest cases :) | 10:01 |
| DrJoel | then focus on the memory allocation errors using the same testing pattern used in the other tests I showed you (sp18 and psxkey03?) | 10:03 |
| dr__house | DrJoel: ok, cool. | 10:04 |
| DrJoel | fwiw i went after the psignal.c case. turned out it was unreachable and i had to restructure the code. <sigh> that turned one 12 byte thing into two 4 byte so I am adding a test | 10:04 |
| dr__house | DrJoel: oh ok | 10:04 |
| DrJoel | dr__house: the memory allocation one should be fairly straight forward using those tests as templates .. actually if you base it on sp18, it will be easy.. that is using stack size.. use the number going down as msg size and reserve one of that size... keep going until it allocates it successfully and place a large (~64 byte) name on the queue. :) Then break out of the loop, delete it and the test checks that the heap is still ok | 10:06 |
| * DrJoel needs to take a shower for the steam :) | 10:06 | |
| DrJoel | brb | 10:06 |
| dr__house | sure | 10:06 |
| dr__house | DrJoel: there's mistake in that patch, it has to be assert(errno == ENFILE) instead of assert(sec_Queue==ENFILE) :P | 10:11 |
| * dr__house is away: afk | 10:40 | |
| DrJoel | yeah.. i spotted that .. corrected in email to you. the "rtems_set_errno_and_return_minus_one" is a very verbose hint at how a routine returns. :) | 10:48 |
| *** lee21 has quit IRC | 11:09 | |
| *** lee21 has joined #rtems | 11:17 | |
| * dr__house is back. | 11:49 | |
| dr__house | DrJoel: heh, yeah it is :) | 11:49 |
| *** lee21 has left #rtems | 12:11 | |
| *** madrazr has quit IRC | 15:24 | |
| * dr__house is leaving for the day. Good day/night/evening to everyone. | 16:59 | |
| *** dr__house has quit IRC | 16:59 | |
| *** chrisjohns has joined #rtems | 18:34 | |
| *** chrisjohns has quit IRC | 23:44 | |
Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!