[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
General PTY and CONSOLE question
- Date: Sun, 21 Sep 2008 15:15:35 -0400
- From: gds at chartertn.net (Gene Smith)
- Subject: General PTY and CONSOLE question
Joel Sherrill wrote, On 09/20/2008 05:27 PM:
> Gene Smith wrote:
>> Joel Sherrill wrote:
>>> Thomas Doerfler wrote:
>>>> during startup RTEMS tries to open "dev/console". If you don't a device
>>>> of this name, you will run into trouble. PTY will be initialized later
>>>> (AFAIK), so this can't be a replacement.
>>> Depends on the RTEMS version. This is the
>>> progression right:
>>> + in 4.6 /dev/console was required and if open() on it
>>> failed, it was a fatal error.
>>> + in 4.7.1, the open could fail without causing a fatal error.
>>> This made the console optional but open() always got
>>> pulled in.
>>> + In 4.8, this routine was refactored so there could be
>>> a "no-console.c" optional stub to avoid open() being
>> I'm still at 4.8 right now but having a problem when I don't include
>> CONSOLE_DRIVER_TABLE_ENTRY in my Device_drivers array. I don't see
>> open() being called since dbgu_init() is not called (and dbgu_init() is
>> called when CONSOLE_DRIVER_TABLE_ENTRY present). However, I can see
>> RTEMS detect a fatal error of some sort and shut down. Also, can't
>> telnet to RTEMS. Only when I include the CONSOLE... driver entry does
>> RTEMS keep running and I can telnet in.
>> My BSP (modified csb337) still includes the uart code (in dbgu.c,
>> customized for my uart) but it is basically a NOP right now. The
>> dbgu_init() function does nothing to the h/w. The dbgu_write() just
>> returns 1 (indicating the char was sent) while dbgu_read() just returns
>> -1 (indicating that nothing received). Those are the only functions that
>> touch the uart so print[fk] must call them.
> Can you dump the print[fk] output into a ring buffer so we
> can look at it?
What I did was move the dbgu_init() uart setup actions to dbgu_write()
and do this once on only the first printk char (using a flag "uart_up"
to enforce a one-shot uart init). This allow the uart to still be
initialize even when "CONSOLE_DRIVE_TABLE_ENTRY" is not in the
Device_drivers array. So with this I can still see the printk messages
in gtkterm. I also changed all printf's in my app to printk's.
What I am seeing is that it gets past all the initializations including
networking, telnetd and my primary app init but fails when freeing
memory like this:
Program heap: free of bad pointer 2031D150 -- range 202CA800 - 21000000
EXECUTIVE SHUTDOWN! Any key to reboot...
This printk occurs at malloc.c:495 when freeing memory. If I set a bp at
this line 495 and run again, I see this in gdb:
(arm-gdb) b malloc.c:495
Breakpoint 1 at 0x201b5ef8: file
Breakpoint 1, free (ptr=
During symbol reading, incomplete CFI data; unspecified registers (e.g.,
r0) at 0x201b5e7c.
495 printk( "Program heap: free of bad pointer %p -- range %p -
Current language: auto; currently c
#0 free (ptr=0x2031d150) at
#1 0x201cd798 in rtems_bsdnet_free (addr=0x2031d150, type=3) at
#2 0x201e5cac in sofree (so=0x201ce8b8) at
#3 0x02000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
So it appears that not having a CONSOLE driver causes a problem in the
networking code. The call to function in uipc_socket.c is sofree() which
calls the FREE macro. Again, if I keep the CONSOLE driver in the driver
array, I have no problems. (Note: my JTAG debugger is a bit flaky, so
the indication above of a corrupt stack may or may not be valid.)
Also, just realized that the printk at the bp is not a fatal error in
itself, so I stepped on from there with debugger. What I see is that the
stack from item #3 up is actually:
For some reason, rtems_task_telnetd seems to be coming out of its
endless loop and calling close(). When it terminates the fatal error is
flagged (after going into rtems_task_delete). I have no idea why telnetd
is terminating or is terminated. I have not at this time tried to make a
>> I can't really tell exactly where the RTEMS shutdown (rtems_panic
>> called) is occurring because I have no serial port printing and my debug
>> environment is still kind of flaky. However, I think it might be
>> occurring during a printf from what I can tell (but not necessarily the
>> 1st printf). Also, while stepping with gdb in a printf call, somehow I
>> *seemed* to end up in some networking/socket code (this is with console
>> driver disabled). Like I said, my debugger is flaky so not sure if this
>> was real or not.
> Do you get a backtrace?
> If you call printf from the wrong context (ISR or dispatching
> disabled), you can get a fatal error.
>>> + Basically the same in 4.9.
>>>> Maybe the NULL device can help you as a dummy replacement of the console?
>>> When you had to have /dev/console, you could link /dev/console
>>> to /dev/null and get by. Now you only need to do that if you print
>>> to stdout and assume that it is automatically setup for you.
>>>> Gene Smith wrote:
>>>>> Does a PTY driver require the console driver? When I remove
>>>>> CONSOLE_DRIVER_TABLE_ENTRY from the Device_drivers array I get no pty
>>>>> login. Are they somehow tied together? Examples I have seen on the list
>>>>> have the both.
>>>>> I need to run with my UART h/w disabled (I can't have it on, I need its
>>>>> I/O ports for other functions). However I would still like the PTY
>>>>> login/shell to be working (for now).
>>>>> The other problem also might be that print[kf] calls are still present
>>>>> in the code. printk still tries to send chars to the uart even when
>>>>> CONSOLE is gone. I am not sure about printf.