| Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
in include file order.
|
|
The reentrant versions of the malloc functions in
c/src/lib/libc/malloc.c
do not match the definitions in newlib. These will be used if you use
newlib routines such as fdopen. I believe this patch to malloc.c is
needed to provide the correct versions.
|
|
Remember the test to see if a socket could be read and written at
the same time by two different tasks? I discovered that if both
tasks attempt to close the socket a panic can occur from inside the
BSD code.
Closing the same socket twice from two different threads is
certainly an error, but a panic is not the greatest error reporting
method :-)
The following small change to the socket close routine should reduce
the chances of the panic.
|
|
|
|
|
|
|
|
ports.
|
|
RTEMS workspace is to be zeroed out.
|
|
1. Finally fixes raw interrupts for pc386
2. Makes some minor cleanup in console and startup
3. Makes rtems_termios_dequeue_characters() to return count of
outstanding chars - it allows to simplify console isrs a little
bit.
4. pc386 uart modified to be friendlier to termios parameter changes,
to have minor performance improvement and to take advantage of
of above termios modification.
|
|
Here's a patch to make the rtems_showroute routine a little more
useful. For `host' route table entries the link-level address is now
displayed. This is equivalent to the old `show arp table'
information displayed by the KA9Q code.
|
|
the inet checksum routine.
|
|
I fixed the problems noted by Victor Vengerov.
1) Fix typo in cfsetispeed().
2) In rtems_termios_open, ensure that args->iop->data1 is set before calling
device-specific open routine.
|
|
|
|
I've fixed a few minor probs with the optimised version that Eric put
together for me the other day and sent the fixes back to him. Provided he
doesn't have a problem with it we've got a pretty solid in_cksum for the
ColdFire as well as straight m68k. I've enclosed my updated in_cksum_m68k.c
At the moment my own bottlenecks are elsewhere...as my driver is pulling
16bit data chunks through a libchip-esq access routine from the chip which
for a polled I/O device is never going to be quick.
|
|
for the ColdFire.
|
|
message after comments from Eric Valette <valette@crf.canon.fr>.
|
|
|
|
I have reworked the ethernet driver for the BSP pc386 and
here is the patch to apply.
|
|
Eric> NB : there is still a bug on PC386 serial line : exit does not
Eric> flush the remaining output queue. As this is not a bug in the
Eric> driver itself but somewhere in PC386 initialization/termios
Eric> relationship it will be part of another patch.
Eric> NB2 : As Emmanuel excerced the exception hanlder code, while
Eric> porting the SMC driver to the new BSD stack, we found a bug
Eric> in the exception handler : it shall not delete the current
Eric> thread in case we are running at interrupt level. This will
Eric> be part of another patch...
So here is the patch. This patch fixes the two problems mentionned above
+ it use vpath mechanism intead of copying the irq related files in
the right directory. This avoid to compile them each time and is
more homogenous with other Makefiles.
|
|
I think I figured out why rtems_panic was locking up instead of
shutting down the executive and returning to the code that called
boot_card().
Later on there is code to print some messages on the standard error
stream, a recursive call back to rtems_verror (through rtems_error)
and finally a call to _exit().
I think that the _Thread_Disable_dispatch() is preventing the final
context switch back to the boot_card() code. Does this sound right
to you?
|
|
when building the executive source.
|
|
file to switch out to CPU specific implementations.
|
|
|
|
via the user api.
|
|
Here is a patch that enables to catch exception
and get message before crashing RTEMS :)
It should be generic to any Intel port although enabled
only for pc386 BSP...
[Joel] I fixed the bug I introduced in irq_asm.s...
|
|
|
|
"Thomas Doerfler" <td@imd.m.isar.de> wrote:
>
> While implementing/testing the console/termios support for
> PPC403 in RTEMS-4.0.0-beta3, I am stuck at a certain location in
> termios.c:
>
> During "rtems_termios_initialize", the main control data structure
> "*tty" is allocated using malloc(). (Note, that malloc does not
> clear the allocated memory and my BSP does not clear memory during
> startup). Furtheron, a lot of fields of that structure are
> initialized, but the field "rawOutBufState" is not, and therefore
> keeps an arbitrary contents.
>
> When "osend()" is called the first time(with the serial device
> driver working in interrupt mode), termios gets stuck and will not
> call the device drivers output function.
>
> My questions now are:
>
> - anybody already experienced this bug?
> - is it a bug at all or did I do anything fundamentally wrong?
> - is there already a common bugfix for that?
>
> I don't like poking around in other people code, as long as I am
> not absolutely sure, what I do...
Yes, there's a bug there.
I thought that Joel had patched this already, but here's a patch to
fix this. This patch also addresses a concern that many others have
raised regarding enabling and disabling of transmitter interrupts.
First, here's the example I've been using of a simple UART-style
interrupt-driven driver:
===============================================================
void
device_write_routine (int minor, char *buf, int count)
{
UART->control_register &= ~UART_TRANSMITTER_READY;
UART->output_register = *buf;
UART->control_register |= UART_TRANSMIT_INTERRUPT_ENABLE;
}
void
device_transmit_interrupt_routine (int vector)
{
UART->control_register &= ~UART_TRANSMIT_INTERRUPT_ENABLE;
rtems_termios_dequeue_characters (device_ttyp, 1);
}
==============================================================
Several people have expressed their concern about the disable/enable
of transmitter interrupts for every character. On some machines
this disable/enable is an expensive operation. With the attached
patch applied you can write the two routines as:
==============================================================
void
device_write_routine (int minor, char *buf, int count)
{
code_to_clear_transmitter_ready_status ();
if (device_ttyp->rawOutBufState == rob_idle)
code_to_enable_transmitter_interrupts ();
code_to_send_one_character_to_transmitter (*buf);
}
void
device_transmit_interrupt_routine (int vector)
{
rtems_termios_dequeue_characters (device_ttyp, 1);
if (device_ttyp->rawOutBufState == rob_idle)
code_to_disable_transmitter_interrupts ();
}
===============================================================
|
|
|
|
|
|
a missed "&" on a write.
|
|
|
|
|
|
|
|
|
|
|
|
- Use the "hlt" instruction for the Idle thread,
- Optimise interrupt PATH leadding to thread wakeup,
- Preparation for Intel exception management that should
come before the end of the week...
|
|
Enabled on the pc386.
|
|
specific register macros and correct code in rtems.s.
|
|
|
|
Here is a enhanced version of my previous patch. This patch enables
to potentially share the new interrupt management code for all Intel targets
(pc386, go32 and force386) bsp.
Note : this patch is complete only for pc386. It still needs to
be completed for go32 and force386. I carrefully checked
that anything needed is in for force386 (only some function
name changes for IDT manipulation and GDT segment
manipulation). But anyway I will not be able to test any
of theses targets...
|
|
returned a buffer which was not zero-filled, the reference count
was not correct. When the application exitted, the "lastClose"
handler was not being called to flush the output. This problem
had manifested itself on a variety of platforms.
The function rtems_termios_dequeue_characters() incorrectly incremented
the buffer pointers when it was invoked and there were no characters
in the ring buffer. This problem had also manifested itself on a
variety of platforms. The symptom was a strange repeating of the
data in the transmitter buffer when the transmitter serial device
was supposed to go idle.
|
|
Haven't had a chance to do an extensive shake-out of 980710, but it
builds just fine on FreeBSD 2.2.5 (after termios is fixed using the
attached patch), and the tests run fine. FYI: FreeBSD doesn't support
System V IPC out of the box, but one only needs to add three options
to the kernel build configuration file, recompile the kernel, and
you're ready.
|
|
|
|
|
|
task to be deleted was created via the same API (i.e. were of the object
class created by this API). For example, a POSIX thread calling
the rtems_task_delete(SELF) directive would incorrectly update the RTEMS
object local pointer table.
Jennifer discovered this when moving tests implemented in C using the
Classic RTEMS API into a tree of Ada tests. The Ada tests were implicitly
using POSIX services. This lead to some unexpected behavior.
|
|
not a valid object class. This was discovered while looking for
a bug reported by Jennifer.
|
|
|
|
of seconds since 1988 from RTEMS and not adding in the 1970-1988 correction
factor. Plus removed checks for data/time set since POSIX does not permit
this call to fail. GNAT 3.12 depends on this.
|
|
|
