| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
rdir=/opt/rtems
cd $idir
find . -type f | while read file
do
if [ ! -f ${file} ] ; then
echo ${file} missing
fi
done
|
|
|
|
| |
c/src/lib/libmisc to c/src/libmisc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
report from Philip A. Prindeville <philipp@zembu.com>:
I was working on a device driver for a certain ethernet chipset that
occassionally wraps in its buffer, and causes a resulting mbuf chain
with only a few dozen bytes in the first mbuf of the chain.
I wouldn't have thought this would be a problem, until I ran some
stress tests that flooded the ethernet receiver with packets and
started to get panics here:
250
251 if (m->m_pkthdr.len < sizeof(struct ip))
252 goto tooshort;
253
254 #ifdef DIAGNOSTIC
255 if (m->m_len < sizeof(struct ip))
256 panic("ipintr mbuf too short");
257 #endif
258
259 if (m->m_len < sizeof (struct ip) &&
260 (m = m_pullup(m, sizeof (struct ip))) == 0) {
261 ipstat.ips_toosmall++;
262 return;
263 }
264 ip = mtod(m, struct ip *);
and the panic was at line 256. But if I #undef'd DIAGNOSTICS,
then the m_pullup() at line 260 does the right thing and the packet
ends up being processed just fine.
So I started wondering, (a) why was the test checking for
something that apparently wasn't a fatal condition but rather
one that is subsequently recovered from a couple of lines later
and (b) why panic as a diagnostic "aid" from a recoverable
condition rather than just (say) log a message to the console?
All of this seems overly severe for no reason that is readily
apparent to me.
|
|
|
|
|
| |
to initialize the pthread cancellation fields. This is a patch to
_POSIX_Threads_Create_extension that fixes the problem.
|
|
|
|
| |
<raguet@crf.canon.fr> to use a local variable.
|
|
|
|
| |
process.
|
| |
|
| |
|
| |
|
|
|
|
| |
CONFIGURE_POSIX_INIT_THREAD_STACK_SIZE because in POSIX they are threads.
|
| |
|
|
|
|
| |
Eric Norum.
|
| |
|
|
|
|
| |
Renamed IMFS handler tables to include IMFS prefix.
|
|
|
|
|
| |
places to make sure memory allocated for filesystem specifif nodes
gets freed.
|
| |
|
|
|
|
| |
routine imfs_fcntl.c
|
|
|
|
| |
node used to manage file access.
|
| |
|
|
|
|
| |
to its own top level package.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
now prototypes the malloc family in stdlib.h. This causes conflicts
with the way the network stack overrides the definitions of malloc.
As best I (being Joel) can tell, commenting stdlib.h out keeps the
files compiling and referencing the desired malloc/free but results
in more warnings.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and not likely to become so. Comments on each configuration
are below.
+ Force CPU386 - This BSP was developed as part of the initial
port of RTEMS to the i386. This board has been unavailable
for a long time now.
+ GO32 - This BSP and some CPU code supported djgpp v1.x. This
version is now quite old. No one has stepped forward to
update the code to v2.x which may be technically impossible
anyway. More importantly, go32 has been superceded by the pc386 BSP.
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm working on code to mount my host based file system on the base file
system (imfs) and have a suggestion for a change to eval.c in the
c/src/lib/libc directory of the 8/20/1999 snapshot. The current version
does not test the result value returned from the evalpath callback (line 47)
in the case where follow_link is true. Attached is my suggested change.
Without this test the node_type callback may be called after evalpath
failed. node_type could set the type to some value other then
RTEMS_FILESYSTEM_HARD_LINK or RTEMS_FILESYSTEM_SYM_LINK but it seems cleaner
to add the check on result.
|
| |
|
|
|
|
|
|
| |
sigemptyset(&old_mask) needed to be added on glibc2 systems. Ian
Lance Taylor pointed out that sigemptyset() is portable so Joel removed
all conditionals around calls to sigemptyset().
|
|
|
|
| |
where wrapup left pieces out of the librtemsall.a.
|
|
|
|
| |
where wrapup left pieces out of the librtemsall.a.
|
|
|
|
| |
a top level more independently configured package.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch below actuallly consists of two patches:
1) moving librpc to c/src/librpc similar to what has been done to librtems++
2) reworked configure scripts, many safety and dependency checks added to
aclocal/*.m4 macros + configuration fixes.
To apply:
mkdir c/src/librpc
mkdir c/src/librpc/src
cp c/src/lib/librpc/*.c c/src/librpc/src
cp c/src/lib/librpc/Makefile.in c/src/librpc/src
mkdir c/src/librpc/include
mkdir c/src/librpc/include/rpc
cp c/src/lib/include/rpc/* c/src/librpc/include/rpc
patch -p1 < ../rtems-rc-19990820-7.diff
rm -rf c/src/lib/librpc
rm -rf c/src/lib/include/rpc
./autogen
The additional checks in aclocal/*m4 macros add rather restrictive, sometimes
unnecessarily restrictive constraints on the sequence of how macros can be
used in a configure.in script. Adding them has let my problems with some more
complicated configuration options vanish. Apparently some macros had not been
in the required order .
----
Now I still get some linking errors for some cpus and bsps, esp when linking
cdtest, but also at other locations:
e.g. this happens for mips64orion/p4600:
# make[5]: Entering directory
`/lfs/poseidon/users/rtems/src/multi/build/mips64orion-rtems/c/p4600/tests/samples/hello'
/opt/rtems/bin/mips64orion-rtems-gcc --pipe -B../../../../../../p4600/lib/
-specs bsp_specs -qrtems -DP4000 -DCPU_R4000 -DP3_DIAG -D_R4000 -D__mips=3
-mcpu=4600 -G0 -I../../../../../../p4600/lib/include/networking -g -Wall
-ansi -fasm -O4 -fomit-frame-pointer -o o-p4600/hello.exe
o-p4600/init.o ../../../../../../p4600/lib/no-dpmem.rel
../../../../../../p4600/lib/no-event.rel
../../../../../../p4600/lib/no-msg.rel ../../../../../../p4600/lib/no-mp.rel
../../../../../../p4600/lib/no-part.rel
../../../../../../p4600/lib/no-signal.rel
../../../../../../p4600/lib/no-timer.rel
../../../../../../p4600/lib/no-rtmon.rel
/opt/rtems/mips64orion-rtems/lib/libc.a(dtoa.o): In function `_dtoa_r':
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
collect2: ld returned 1 exit status
# mips64orion-rtems-gcc -v
Reading specs from /opt/rtems/lib/gcc-lib/mips64orion-rtems/2.95.1/specs
gcc version 2.95.1 19990816 (release)
# mips64orion-rtems-ld -v
GNU ld version 2.9.5 (with BFD 2.9.5)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch below actuallly consists of two patches:
1) moving librpc to c/src/librpc similar to what has been done to librtems++
2) reworked configure scripts, many safety and dependency checks added to
aclocal/*.m4 macros + configuration fixes.
To apply:
mkdir c/src/librpc
mkdir c/src/librpc/src
cp c/src/lib/librpc/*.c c/src/librpc/src
cp c/src/lib/librpc/Makefile.in c/src/librpc/src
mkdir c/src/librpc/include
mkdir c/src/librpc/include/rpc
cp c/src/lib/include/rpc/* c/src/librpc/include/rpc
patch -p1 < ../rtems-rc-19990820-7.diff
rm -rf c/src/lib/librpc
rm -rf c/src/lib/include/rpc
./autogen
The additional checks in aclocal/*m4 macros add rather restrictive, sometimes
unnecessarily restrictive constraints on the sequence of how macros can be
used in a configure.in script. Adding them has let my problems with some more
complicated configuration options vanish. Apparently some macros had not been
in the required order .
----
Now I still get some linking errors for some cpus and bsps, esp when linking
cdtest, but also at other locations:
e.g. this happens for mips64orion/p4600:
# make[5]: Entering directory
`/lfs/poseidon/users/rtems/src/multi/build/mips64orion-rtems/c/p4600/tests/samples/hello'
/opt/rtems/bin/mips64orion-rtems-gcc --pipe -B../../../../../../p4600/lib/
-specs bsp_specs -qrtems -DP4000 -DCPU_R4000 -DP3_DIAG -D_R4000 -D__mips=3
-mcpu=4600 -G0 -I../../../../../../p4600/lib/include/networking -g -Wall
-ansi -fasm -O4 -fomit-frame-pointer -o o-p4600/hello.exe
o-p4600/init.o ../../../../../../p4600/lib/no-dpmem.rel
../../../../../../p4600/lib/no-event.rel
../../../../../../p4600/lib/no-msg.rel ../../../../../../p4600/lib/no-mp.rel
../../../../../../p4600/lib/no-part.rel
../../../../../../p4600/lib/no-signal.rel
../../../../../../p4600/lib/no-timer.rel
../../../../../../p4600/lib/no-rtmon.rel
/opt/rtems/mips64orion-rtems/lib/libc.a(dtoa.o): In function `_dtoa_r':
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
/opt/hermes/embedded/build/build-mips64orion-tools/mips64orion-rtems/newlib/libc/stdlib/../../../../../src/newlib/libc/stdlib/dtoa.c:348: relocation truncated to fit: R_MIPS_LITERAL no symbol
collect2: ld returned 1 exit status
# mips64orion-rtems-gcc -v
Reading specs from /opt/rtems/lib/gcc-lib/mips64orion-rtems/2.95.1/specs
gcc version 2.95.1 19990816 (release)
# mips64orion-rtems-ld -v
GNU ld version 2.9.5 (with BFD 2.9.5)
|
| |
|
|
|
|
|
|
| |
The old system would panic when the loopback interface was included as
part of the network initialation structures. With the printf you get an
message, but the interface is still properly initialized.
|
| |
|
| |
|
|
|
|
|
| |
Ralf Corsepius <corsepiu@faw.uni-ulm.de> which converted many
Makefile.in's to Makefile.am's. This added a lot of files.
|
|
|
|
|
| |
Ralf Corsepius <corsepiu@faw.uni-ulm.de> which converted many
Makefile.in's to Makefile.am's. This added a lot of files.
|
|
|
|
|
| |
Ralf Corsepius <corsepiu@faw.uni-ulm.de> which converted many
Makefile.in's to Makefile.am's.
|
|
|
|
|
| |
support for return codes from POSIX threads that do an implicit exit
by returning from the bottom of the main function.
|
|
|
|
| |
in the compiler not in the header file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch below actually consists of 3 patches:
1. Addition of maintainer-mode dependencies on config.status and
aclocal.m4 for autoconf toplevel Makefile.ins. These rules are taken
over from automake generated Makefile.ins, i.e. they are contained in
any automake generated toplevel Makefile.in. Having this patch in is
at least a great releaf for me when working on RTEMS configuration :)
2. Automated support for #1 in acpolish
3. Some minor "beautifications" on Makefile.ins resulting from
running acpolish.
FYI: This patch has been generated by running
tools/update/rtems-polish.sh -ac on the source tree and manually editing
the resulting patch afterwards to work around a problem with acpolish,
which still corrupts one Makefile.in - WARNING: Be careful with running
acpolish!
I expect this patch not to have any influence on normal users, unless
they use --enable-maintainer-mode, thus merging it should be rather
harmless.
|
|
|
|
| |
fixed by Joel.
|
| |
|
|
|
|
| |
the minor number indicated the port number to try.
|
|
|
|
|
| |
against 3.6.0 so was painful to merge. It should be OK but there
is no guarantee and there are no BSPs in the tree to exercise it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Please take a look at this new patch. It contains a cleaner implementation
of the reset operation. These patches are against 4.0.0. But the files
did not change from the 3.6.0 release. Also, the cpu.h patch below still
applies. I.e. instead of using i960ca_PRCB, use i960_PRCB.
Explanation:
The previous patch removed the use of the reset instruction,
because it always fails. But this was due to the fact that
some of the registers were corrupted by the re-init procedure.
The new patches save and restore those registers when a re-init
is done.
|