<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:12pt"><div>I think I solved my first problem but a new problem has manifested itself. On the first issue, I thought the machine was hung, but I noticed under the session information dialogue that the virtual machine was reading data. I let the machine run for about 15 minutes "hung" on the cursor and it finally came up with the following error:<br><br>"This kernel requires the following feature not present on the cpu: pae/nx"<br><br>Turns out this is a known error as described here for Ubuntu 8.10 (Still a problem with 9.10 obviously):<br><span><a target="_blank" href="https://help.ubuntu.com/community/VirtualBox/Installation">https://help.ubuntu.com/community/VirtualBox/Installation</a></span><br><br>The workaround on VirtualBox version 3.1.6 is to enable pae/nx feature. Right click on the fedora machine you've
setup (must be shutdown) follow the path:<br>settings > system > processor > enable pae/nx <br></div><div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"><br>The system boots now however after a while it arrives with the following error:<br>"prefdm respawning too fast stopped"<br><br>The screen goes blank and the boot process hangs. From reading through Fedora forums it appears to be a problem with a failure of the X-configuration as described here:<br><span><a target="_blank" href="http://forums.fedoraforum.org/showthread.php?t=188317">http://forums.fedoraforum.org/showthread.php?t=188317</a></span><br><br>The workaround appears to be to rename the xorg.conf file????? Does anyone have any ideas how I could go about doing this for a virtual system?<br><br>Sorry for the ongoing trouble, I'd love to just install Fedora however Ubuntu is my working system, if I keep having troubles I'll just go through the process of
installing all the packages and maybe try to setup a debian repository so any other Ubuntu users can install all the packages directly through apt. <br><br>- kim<br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> "rtems-users-request@rtems.org" <rtems-users-request@rtems.org><br><b><span style="font-weight: bold;">To:</span></b> rtems-users@rtems.org<br><b><span style="font-weight: bold;">Sent:</span></b> Fri, May 7, 2010 4:00:36 AM<br><b><span style="font-weight: bold;">Subject:</span></b> rtems-users Digest, Vol 44, Issue 7<br></font><br>
Send rtems-users mailing list submissions to<br> <a ymailto="mailto:rtems-users@rtems.org" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br><span> <a target="_blank" href="http://www.rtems.org/mailman/listinfo/rtems-users">http://www.rtems.org/mailman/listinfo/rtems-users</a></span><br>or, via email, send a message with subject or body 'help' to<br> <a ymailto="mailto:rtems-users-request@rtems.org" href="mailto:rtems-users-request@rtems.org">rtems-users-request@rtems.org</a><br><br>You can reach the person managing the list at<br> <a ymailto="mailto:rtems-users-owner@rtems.org" href="mailto:rtems-users-owner@rtems.org">rtems-users-owner@rtems.org</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of rtems-users digest..."<br><br><br>Today's
Topics:<br><br> 1. Setting to prevent memory allocation (Yaklin, Allan C)<br> 2. RE: Setting to prevent memory allocation (Yaklin, Allan C)<br> 3. Re: Setting to prevent memory allocation (Joel Sherrill)<br> 4. Virtual machine installation issue. (Kim George)<br> 5. Bluetooth (Robert S. Grimes)<br> 6. RE: Bluetooth (Lu Chih Wen)<br> 7. Re: [PATCH] ftpd: RETR of a directory should fail (Chris Johns)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 6 May 2010 12:34:03 -0600<br>From: "Yaklin, Allan C" <<a ymailto="mailto:acyakli@sandia.gov" href="mailto:acyakli@sandia.gov">acyakli@sandia.gov</a>><br>To: "'<a ymailto="mailto:rtems-users@rtems.com" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>'" <<a ymailto="mailto:rtems-users@rtems.com" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>><br>Subject: Setting
to prevent memory allocation<br>Message-ID:<br> <<a ymailto="mailto:A8CAC25314C27F4E9E1BAA280339ACD016EC9BF6F0@ES02SNLNT.srn.sandia.gov" href="mailto:A8CAC25314C27F4E9E1BAA280339ACD016EC9BF6F0@ES02SNLNT.srn.sandia.gov">A8CAC25314C27F4E9E1BAA280339ACD016EC9BF6F0@ES02SNLNT.srn.sandia.gov</a>><br>Content-Type: text/plain; charset="us-ascii"<br><br>Hello,<br><br>I'm working on an embedded system with limited memory, and we were wondering if there was a way to prevent RTEMS programs from dynamic allocating memory. I was specifically thinking of a possible setting in confdefs.h, but I was unable to find anything relevant when searching through the file. Is this possible in RTEMS?<br><br>--<br>Allan Yaklin<br><a ymailto="mailto:acyakli@sandia.gov" href="mailto:acyakli@sandia.gov">acyakli@sandia.gov</a><br><br><br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br><span>URL: <<a
target="_blank" href="http://www.rtems.org/pipermail/rtems-users/attachments/20100506/60cbfca0/attachment-0001.htm">http://www.rtems.org/pipermail/rtems-users/attachments/20100506/60cbfca0/attachment-0001.htm</a>></span><br><br>------------------------------<br><br>Message: 2<br>Date: Thu, 6 May 2010 14:51:44 -0600<br>From: "Yaklin, Allan C" <<a ymailto="mailto:acyakli@sandia.gov" href="mailto:acyakli@sandia.gov">acyakli@sandia.gov</a>><br>To: "'<a ymailto="mailto:rtems-users@rtems.com" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>'" <<a ymailto="mailto:rtems-users@rtems.com" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>><br>Subject: RE: Setting to prevent memory allocation<br>Message-ID:<br> <<a ymailto="mailto:A8CAC25314C27F4E9E1BAA280339ACD016EC9BF752@ES02SNLNT.srn.sandia.gov"
href="mailto:A8CAC25314C27F4E9E1BAA280339ACD016EC9BF752@ES02SNLNT.srn.sandia.gov">A8CAC25314C27F4E9E1BAA280339ACD016EC9BF752@ES02SNLNT.srn.sandia.gov</a>><br>Content-Type: text/plain; charset="us-ascii"<br><br>I apologize for cluttering your inboxes, but I didn't ask the right question the first time around.<br><br>Does the RTEMS kernel dynamically allocate memory? If it does, is there a setting in confdefs.h to prevent it?<br><br>--<br>Allan Yaklin<br><a ymailto="mailto:acyakli@sandia.gov" href="mailto:acyakli@sandia.gov">acyakli@sandia.gov</a><br>(505) 284-8660<br><br>From: <a ymailto="mailto:rtems-users-bounces@rtems.org" href="mailto:rtems-users-bounces@rtems.org">rtems-users-bounces@rtems.org</a> [mailto:<a ymailto="mailto:rtems-users-bounces@rtems.org" href="mailto:rtems-users-bounces@rtems.org">rtems-users-bounces@rtems.org</a>] On Behalf Of Yaklin, Allan C<br>Sent: Thursday, May 06, 2010 12:34 PM<br>To: '<a
ymailto="mailto:rtems-users@rtems.com" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>'<br>Subject: Setting to prevent memory allocation<br><br>Hello,<br><br>I'm working on an embedded system with limited memory, and we were wondering if there was a way to prevent RTEMS programs from dynamic allocating memory. I was specifically thinking of a possible setting in confdefs.h, but I was unable to find anything relevant when searching through the file. Is this possible in RTEMS?<br><br>--<br>Allan Yaklin<br><a ymailto="mailto:acyakli@sandia.gov" href="mailto:acyakli@sandia.gov">acyakli@sandia.gov</a><br><br><br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br><span>URL: <<a target="_blank"
href="http://www.rtems.org/pipermail/rtems-users/attachments/20100506/39f4744b/attachment-0001.htm">http://www.rtems.org/pipermail/rtems-users/attachments/20100506/39f4744b/attachment-0001.htm</a>></span><br><br>------------------------------<br><br>Message: 3<br>Date: Thu, 6 May 2010 16:45:55 -0500<br>From: Joel Sherrill <<a ymailto="mailto:joel.sherrill@OARcorp.com" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a>><br>To: "Yaklin, Allan C" <<a ymailto="mailto:acyakli@sandia.gov" href="mailto:acyakli@sandia.gov">acyakli@sandia.gov</a>><br>Cc: "'<a ymailto="mailto:rtems-users@rtems.com" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>'" <<a ymailto="mailto:rtems-users@rtems.com" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>><br>Subject: Re: Setting to prevent memory allocation<br>Message-ID: <<a ymailto="mailto:4BE33893.4080506@oarcorp.com"
href="mailto:4BE33893.4080506@oarcorp.com">4BE33893.4080506@oarcorp.com</a>><br>Content-Type: text/plain; charset="windows-1252"; format=flowed<br><br>On 05/06/2010 03:51 PM, Yaklin, Allan C wrote:<br>><br>> I apologize for cluttering your inboxes, but I didn?t ask the right <br>> question the first time around.<br>><br>> Does the RTEMS kernel dynamically allocate memory? If it does, is <br>> there a setting in confdefs.h to prevent it?<br>><br>Not via malloc at all. But after the 1st task runs, it is<br>only in a very few specific places:<br><br>+ thread create (for stacks, etc)<br>+ message queue create<br><br><br>POSIX may do a few others but that should be it for the Classic API.<br><br>Those come from the RTEMS Workspace.<br><br>--joel<br>><br>> --<br>><br>> Allan Yaklin<br>><br>> <a ymailto="mailto:acyakli@sandia.gov" href="mailto:acyakli@sandia.gov">acyakli@sandia.gov</a><br>><br>> (505)
284-8660<br>><br>> *From:* <a ymailto="mailto:rtems-users-bounces@rtems.org" href="mailto:rtems-users-bounces@rtems.org">rtems-users-bounces@rtems.org</a> <br>> [mailto:<a ymailto="mailto:rtems-users-bounces@rtems.org" href="mailto:rtems-users-bounces@rtems.org">rtems-users-bounces@rtems.org</a>] *On Behalf Of *Yaklin, Allan C<br>> *Sent:* Thursday, May 06, 2010 12:34 PM<br>> *To:* '<a ymailto="mailto:rtems-users@rtems.com" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>'<br>> *Subject:* Setting to prevent memory allocation<br>><br>> Hello,<br>><br>> I?m working on an embedded system with limited memory, and we were <br>> wondering if there was a way to prevent RTEMS programs from dynamic <br>> allocating memory. I was specifically thinking of a possible setting <br>> in confdefs.h, but I was unable to find anything relevant when <br>> searching through the file. Is this possible in
RTEMS?<br>><br>> --<br>><br>> Allan Yaklin<br>><br>> <a ymailto="mailto:acyakli@sandia.gov" href="mailto:acyakli@sandia.gov">acyakli@sandia.gov</a><br>><br><br><br>-- <br>Joel Sherrill, Ph.D. Director of Research& Development<br><a ymailto="mailto:joel.sherrill@OARcorp.com" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research<br>Ask me about RTEMS: a free RTOS Huntsville AL 35805<br> Support Available (256) 722-9985<br><br><br><br><br>------------------------------<br><br>Message: 4<br>Date: Thu, 6 May 2010 19:21:27 -0700 (PDT)<br>From: Kim George <<a ymailto="mailto:kim.george83@yahoo.com" href="mailto:kim.george83@yahoo.com">kim.george83@yahoo.com</a>><br>To: <a ymailto="mailto:rtems-users@rtems.org"
href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>Subject: Virtual machine installation issue.<br>Message-ID: <<a ymailto="mailto:89524.70548.qm@web46408.mail.sp1.yahoo.com" href="mailto:89524.70548.qm@web46408.mail.sp1.yahoo.com">89524.70548.qm@web46408.mail.sp1.yahoo.com</a>><br>Content-Type: text/plain; charset="us-ascii"<br><br>Hi,<br><br>I'm having some trouble installing the Fedora virtual machine through Virtualbox on my Ubuntu 9.10 (Karmic Koala) system.<br><br>When I try to boot the virtual machine the system freezes on the cursor. <br><br>I've never used Virtualbox before so I may have done something wrong. I created a new fedora linux machine and then when selecting the boot hard disk I've selected the use existing hard disk option and pointed to the c++.vmdk file which I downloaded via torrent.<br><br>Has anyone experienced something similar that can suggest a workaround?<br><br>Cheers,<br><br>Kim
George<br>Mechanical Engineer<br>Montreal Canada<br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br><span>URL: <<a target="_blank" href="http://www.rtems.org/pipermail/rtems-users/attachments/20100506/e0fb93d4/attachment-0001.htm">http://www.rtems.org/pipermail/rtems-users/attachments/20100506/e0fb93d4/attachment-0001.htm</a>></span><br><br>------------------------------<br><br>Message: 5<br>Date: Thu, 06 May 2010 23:32:41 -0400<br>From: "Robert S. Grimes" <<a ymailto="mailto:rsg@alum.mit.edu" href="mailto:rsg@alum.mit.edu">rsg@alum.mit.edu</a>><br>To: <a ymailto="mailto:rtems-users@rtems.com" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a><br>Subject: Bluetooth<br>Message-ID: <<a ymailto="mailto:4BE389D9.1030305@alum.mit.edu" href="mailto:4BE389D9.1030305@alum.mit.edu">4BE389D9.1030305@alum.mit.edu</a>><br>Content-Type: text/plain; charset="iso-8859-1";
Format="flowed"<br><br>Hi,<br><br>On a new project using a Freescale ColdFire MCF5227x processor (CVS <br>head), I will need to support a Bluetooth protocol stack. I did a <br>search of the mailing list archive, and got only one hit from 2000, so I <br>am posting now.<br><br>Has anyone any experience with Bluetooth, ideally with RTEMS, though <br>other platforms could be helpful?<br><br>I have heard rumors of lwBT out there from a few years back, but haven't <br>been able to locate anything current.<br><br>Anyone interested in collaboration?<br><br>Thanks in advance for any insight/pointers!<br>-Bob<br><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: rsg.vcf<br>Type: text/x-vcard<br>Size: 247 bytes<br>Desc: not available<br><span>URL: <<a target="_blank"
href="http://www.rtems.org/pipermail/rtems-users/attachments/20100506/379ecbe1/attachment-0001.vcf">http://www.rtems.org/pipermail/rtems-users/attachments/20100506/379ecbe1/attachment-0001.vcf</a>></span><br><br>------------------------------<br><br>Message: 6<br>Date: Fri, 7 May 2010 11:49:56 +0800<br>From: "Lu Chih Wen" <<a ymailto="mailto:rudolph@jmicron.com" href="mailto:rudolph@jmicron.com">rudolph@jmicron.com</a>><br>To: "'Robert S. Grimes'" <<a ymailto="mailto:rsg@alum.mit.edu" href="mailto:rsg@alum.mit.edu">rsg@alum.mit.edu</a>>, <<a ymailto="mailto:rtems-users@rtems.com" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>><br>Subject: RE: Bluetooth<br>Message-ID: <<a ymailto="mailto:201005070349.o473ntWX016966@jmr105.jmicron.com" href="mailto:201005070349.o473ntWX016966@jmr105.jmicron.com">201005070349.o473ntWX016966@jmr105.jmicron.com</a>><br>Content-Type: text/plain;
charset="us-ascii"<br><br>Hi Robert<br><br>I am interested in Bluetooth on RTEMS, and have an ARM9 SOC EVB(With USB<br>OTG) with BT USB dongle(with CSR chip) .<br>How can I collaborate with you ?<br><br>Thanks<br>you<br><br>-----Original Message-----<br>From: <a ymailto="mailto:rtems-users-bounces@rtems.org" href="mailto:rtems-users-bounces@rtems.org">rtems-users-bounces@rtems.org</a> [mailto:<a ymailto="mailto:rtems-users-bounces@rtems.org" href="mailto:rtems-users-bounces@rtems.org">rtems-users-bounces@rtems.org</a>]<br>On Behalf Of Robert S. Grimes<br>Sent: Friday, May 07, 2010 11:33 AM<br>To: <a ymailto="mailto:rtems-users@rtems.com" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a><br>Subject: Bluetooth<br><br>Hi,<br><br>On a new project using a Freescale ColdFire MCF5227x processor (CVS <br>head), I will need to support a Bluetooth protocol stack. I did a <br>search of the mailing list archive, and got only one hit from 2000, so
I <br>am posting now.<br><br>Has anyone any experience with Bluetooth, ideally with RTEMS, though <br>other platforms could be helpful?<br><br>I have heard rumors of lwBT out there from a few years back, but haven't <br>been able to locate anything current.<br><br>Anyone interested in collaboration?<br><br>Thanks in advance for any insight/pointers!<br>-Bob<br><br><br><br><br>------------------------------<br><br>Message: 7<br>Date: Fri, 07 May 2010 18:00:23 +1000<br>From: Chris Johns <<a ymailto="mailto:chrisj@rtems.org" href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>><br>To: Ralf Corsepius <<a ymailto="mailto:ralf.corsepius@rtems.org" href="mailto:ralf.corsepius@rtems.org">ralf.corsepius@rtems.org</a>><br>Cc: <a ymailto="mailto:rtems-users@rtems.org" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>Subject: Re: [PATCH] ftpd: RETR of a directory should fail<br>Message-ID: <<a
ymailto="mailto:4BE3C897.2000902@rtems.org" href="mailto:4BE3C897.2000902@rtems.org">4BE3C897.2000902@rtems.org</a>><br>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>On 6/05/10 11:12 PM, Ralf Corsepius wrote:<br>> On 05/06/2010 02:33 PM, Sebastian Huber wrote:<br>>> On 05/06/2010 02:12 PM, Ralf Corsepius wrote:<br>>>> On 05/06/2010 01:48 PM, Sebastian Huber wrote:<br>>>>> On 05/06/2010 01:42 PM, Ralf Corsepius wrote:<br>>>>><br>>>>>> On 05/06/2010 01:27 PM, Sebastian Huber wrote:<br>>>>>><br>>>>>><br>>>>>>> Please do not send patches to this mailing list. Instead they should<br>>>>>>> go into<br>>>>>>> the bugzilla data base:<br>>>>>>><br>>>>>> Sebastian, no idea were you've got this idea from.<br>>>>>><br>>>>> It just makes
sense.<br>>>>><br>>>> Many projects will disagree with you.<br>>>><br>>>> The traditional arguments against bugzilla (floating around ever since<br>>>> bugzilla exists):<br>>>> - It requires a log-in. Many users refuse to get one.<br>>> Yes, this is annoying, but it is only a configuration issue.<br>> Not only this, it also is a matter of spam prevention.<br><br>Agreed. We do not have to remove bugs that are spam. When I converted <br>the GANTS database to bugzilla a large number of bugs were spam.<br><br>><br>>> For FreeBSD it is<br>>> possible to send bug reports without a log in (they use Gnats).<br>>><br>><br>>>> - It means additional bureaucracy / overhead.<br>>> Yes, but this overhead helps to track the patches and reports.<br>>><br>><br>> Bugzilla has it's use-case: Bug tracking. I.e. to report bugs, esp. in<br>> cases when no
immediate patch is around.<br>><br>> For reviewing patches, bugzilla doesn't add any value in comparison to<br>> posting to lists.<br><br>I find a bug's single list of the thread easier to deal with. I can also <br>find what I need to deal with quicker. Email and threading is weak and <br>breaks.<br><br>> Finally, "patch-tracking" in general - Whether this makes any sense at<br>> all is highly questionable.<br><br>In terms of bugzilla maybe, other approaches, I tjink they could be <br>useful. RTEMS has a large number of targets and some are 16bit. This <br>makes the code sometimes difficult to get clean on all platforms. I <br>think asking a user to download and build on all targets and BSPs is too <br>much but this becomes the role of the person who applies the patch.<br><br>The daily build system I run that posts the errors in a table is part of <br>a process to help deal with this issue but it is after the patch has <br>been applied.
The system is actually called the 'patch queue' and one <br>day it would be nice to be able to submit a patch and get back the <br>results. The feedback would the targets the patch breaks on and the <br>differences in warning levels. This is not about a system to manage <br>patches in RTEMS, rather a place to vet patches from users.<br><br>> Forcing/pushing around people to use bugzilla to submit patches<br>> certainly can be considered to rude and unfriendly.<br><br>We need to be flexible and approachable. If someone only wants to submit <br>a patch to the mailing list that is fine with me. I just hope they are <br>prepared to follow up and ping to make sure it is in the queue to be <br>committed.<br><br>>>> - It means having http:-access<br>>>> - It's ui and usabilty leaves much to be desired.<br>>> Yes, it is not perfect. I am not a Bugzilla expert, but Gnats has also an<br>>> email interface (and more).<br>>
Bugzillas internals are a real mess, customizing it is a night-mare.<br><br>Customization only ends in tears. Maybe this is doing us a service :)<br><br>> GNATS once was easy to maintain/customize, but it was unstable and had<br>> an effectively dead upstream. I don't know if this situation meanwhile<br><span>> might have changed (<a target="_blank" href="http://www.gnu.org/software/gnats/">http://www.gnu.org/software/gnats/</a> indicates GNATS</span><br>> is dead).<br><br>I hope things have not changed.<br><br>> Openly said, I am really surprised, anybody is still using GNATS,<br>> because most users switched away from it<br>> (RTEMS was one of them - IIRC, we switched away from GNATS to bugzilla<br>> in 2005).<br><br>Lets not go there. I still have memories of the pain that caused.<br><br>Chris<br><br><br>------------------------------<br><br>_______________________________________________<br>rtems-users mailing list<br><a
ymailto="mailto:rtems-users@rtems.org" href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br><span><a target="_blank" href="http://www.rtems.org/mailman/listinfo/rtems-users">http://www.rtems.org/mailman/listinfo/rtems-users</a></span><br><br><br>End of rtems-users Digest, Vol 44, Issue 7<br>******************************************<br></div></div>
</div></body></html>