Hi,
sometimes I get a crash in
ExWorkerThreadEntryPoint/ExInterlockedRemoveHeadList. I've checked all calls
to ExQueueWorkItem. It seems that something is wrong in the tcpip/ndis
driver. There is a timer dpc which calls ExQueueWorkItem with a static work
queue item. If the worker is not execute previous the next timer call, the
item is queued for twice. Possible it is the same bug as #425.
- Hartmut
Hello, if I start the ReactOS Setup from the "make bootcd" I get an
INACCESSIBLE_BOOT_DEVICE. I use the CVS Version of ReactOS. Can you help?
Thanx, EnricoB
Hi all,
Still running the same kernel and subsystem (see previous post) now
for 1 day 5:23 (uptime). System memory is 1.1 GBytes. First build ros
on ros started at 5% use of memory. Now after the uptime, 45% after
third build. New start has it at 24%. Slow leak~ I did not enable the
memory dumps 8^(, So no real data there. The slow action on the cmd
win console has not changed, you can still count the chars displaying
across the screen.
FYI,
James
Currently there are quite a few places in ROS src where 64-bit integral
constants are either hard-coded to be GNU C only (?), or almost worse
littered with conditional compilation.
Neither is satisfactory. 1 is making it impossible to compile using e.g. an
MS compiler, and 2 makes the code so ugly that... Well, you understand.
So, in the interest of fixing this once and for all, the only option is to
name a macro to handle these compiler specifics in one place, and then use
that macro when defining 64-bit integral constants. The question is then,
what to name it? The macro will be defined something like (omitting unsigned
here):
#if defined __GNUC__
#define ZZZ(X) X##LL
#elif defined _MSC_VER
#define ZZZ(X) X##i64
#else
#error Unknown compiler for 64-bit integral constant suffix
#endif
Serious suggestions that have surfaced so far are:
DEFINE_INT64
MAKE_INT64
If suggesting something else, keep in mind that
- while short might be beautiful (and fast to type), using short macros is
likely to sooner or later create conflicts.
- leading underscore followed by capital character or another underscore is
not legal for C++.
- It's to make it clear that it's a 64-bit int defined, why suggestions
mentioning LL or i64, as in compiler-specific extensions/implementation
details, are likely not to help or be accepted since that's exactly what we
want to get away from.
Please comment.
/Mike
gcc -I./include -I../include -D__NTOSKRNL__ -Wall -Werror
-D_DISABLE_TIDENTS -
D_SEH_NO_NATIVE_NLG -D__3GB__ -I../include -I../w32api/include -pipe
-march=i486
-D_M_IX86 -D__NTOSKRNL__ -I. -D_SEH_NO_NATIVE_NLG -I../include
-I../w32api/incl
ude -pipe -march=i486 -D_M_IX86 -D__NTOSKRNL__ -I. -D_SEH_NO_NATIVE_NLG
-I../inc
lude -I../w32api/include -pipe -march=i486 -D_M_IX86 -c ke/i386/exp.c -o
ke/i386
/exp.o
ke/i386/exp.c: In function `KiTrapHandler':
ke/i386/exp.c:579: error: `ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY'
undeclared (fi
rst use in this function)
ke/i386/exp.c:579: error: (Each undeclared identifier is reported only once
ke/i386/exp.c:579: error: for each function it appears in.)
mingw32-make[1]: *** [ke/i386/exp.o] Error 1
mingw32-make[1]: Leaving directory `C:/reactos/ntoskrnl'
mingw32-make: *** [ntoskrnl] Error 2
C:\reactos>gcc --version
gcc (GCC) 3.4.1 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I've tried my best to make a working implementaiton of
StackAttach/StackDetach, because it's almost one of the most important
APIs in NT5+ Drivers. I think I've got Detach working properly, but
Attach will require some changes to KeAttach itself so that it can save
the old ApcState & other things. I might get around to fixing it, but at
least the API should work now and allow more drivers to run sucesfully.
Also, if any Intel experts woudl like to check out KeFlushCurrentTb... I
followed the Intel Manual specs, just want to make sure I did it
properly...my GNU Assembler syntax sucks.
Best regards,
Alex Ionescu
ion(a)cvs.reactos.com wrote:
>CVSROOT: /CVS/ReactOS
>Module name: reactos
>Repository: reactos/ntoskrnl/ke/
>Changes by: ion(a)mok.osexperts.com 04/10/12 18:42:15
>
>Modified files:
> reactos/include/ddk/: kefuncs.h
> reactos/ntoskrnl/: Makefile.i386
> reactos/ntoskrnl/include/internal/: ke.h ps.h
> reactos/ntoskrnl/ke/: apc.c device.c dpc.c kthread.c process.c
>
>Log message:
> Implemented KeAreApcsDisabled, KeFlushEntireTb, KeIsExecutingDpc, KeSetKernelStackSwapEnable, KeQueryPriorityThread, KeRevertToUserAffinityThread, KeSetIdealProcessorThread, KeSetSystemAffinityThread, KeTerminateThread, KeStackAttachProcess, KeUnstackDetachProcess
>
>_______________________________________________
>Ros-cvs mailing list
>Ros-cvs(a)reactos.com
>http://reactos.com/mailman/listinfo/ros-cvs
>
>
>
Hello,
For almost a week now my symbols have been missing. It started
with gdb not reading in any symbols when I was trying to hunt down
cygwin problems, then I re-enabled KDBG in config and rebuilt and KDBG
can tell you the function name, but not the file name and line number.
Last night, I deleted my sandbox and checked out a fresh copy from
CVS, only enabling DBG. I think it was Arty who suggested I check to
see if the targets are getting the "-g" flag. I captured the entire
build into a log, and these are the only targets that had "-g" on the
gcc command line:
ntdll (-g)
opengl32 (-g3)
dnsapi (-g)
bzip2 (-g)
oskittcp (-g)
patblt (-g)
primitives (-g)
strechblt (-g)
txtscale (-g)
wm_erasebkgnd (-g)
I checked this against my symbols directory and they correspond to
.sym files that appear to be valid. All the others are 16 bytes, and
don't appear to contain any useful information.
I'm not much of a make guru, so I thought I would report it rather
than continue to hunt it down alone. ;0)
Thanks,
Andrew
--
The cheese stands alone.
Hi!
Since I have seen mesa32 crash with SSE enabled I looked into fixing it
a bit...
When I was looking at ntoskrnl/ke/i386/tskswitch.S I found FIXMEs for
debug/FPU save/restore.
Now I am wondering where should this information be stored? I think it
should be part of the TSS (include/ntos/tss.h) but I am not sure.
For SSE support the SSE registers would also have to be saved/restored
on task switches and some other stuff which I do not yet know I think.
Maybe somebody can tell me where the FPU state should be stored so I can
try to implement it.
Thanks,
blight
