From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21686 invoked by alias); 25 Jun 2004 22:04:30 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 21608 invoked from network); 25 Jun 2004 22:04:28 -0000 Received: from unknown (HELO web41301.mail.yahoo.com) (66.218.93.186) by sourceware.org with SMTP; 25 Jun 2004 22:04:28 -0000 Message-ID: <20040625220427.78235.qmail@web41301.mail.yahoo.com> Received: from [67.96.253.254] by web41301.mail.yahoo.com via HTTP; Fri, 25 Jun 2004 15:04:27 PDT Date: Fri, 25 Jun 2004 22:04:00 -0000 From: agyhoo To: ecos-discuss@ecos.sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [ECOS] need help with console i/o X-SW-Source: 2004-06/txt/msg00266.txt.bz2 Hi, I am using an A&M rattler board that has 2 serial ports SMC1 and SCC1. I am using SMC1 as my console device. I configured /dev/ser1 with the necessary settings and mapped my console driver "/dev/tty0" to the "/dev/ser1" serial driver. I also set the console device to "/dev/tty0" for the ISO C library I/O fns. I also selected the "inherit console settings" option under ROM monitor support. In the Redboot configuration my diagnostic and debug channels are both set to SMC1. Now, in my application "main" routine (I am using POSIX and ISO C library), I am spawning 3-4 pthreads. I use printfs to print out info about threads being spawned. The threads include my own version of the dhcp mgmt thread, snmp agent thread and a telnet server thread. I notice that my console output is erratic at best. SOmetimes, I get the letters jumbled, sometimes not. If my output is verbose, everything locks up (I am not able to ping the target or anything). If I download application via GDB, the console output is dumped on GDB console and seems to behave better. Another interesting observation is that if I start my application with the ethernet port unplugged, I am guaranteed to lock up my application. If I replace my printfs with diag_printfs, this doesn't happen. I know that the /dev/ser1 driver is an interrupt driven driver. Could there be some issues with the initialization sequence and interrupts being enabled in a timely manner? Is the scheduler enabled before the main thread is invoked? Another possibility is that the hal diag serial driver and the /dev/tty0 driver are clashing trying to access the same device...would this cause a lockup? This problem has kept cropping up and going away for a while now...I would really appreciate any help so that I can resolve it once and for all. Thanks. - Anunoy PS> I am using fairly current CVS sources (checked out about a couple of weeks ago) __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss