For a many month I am unable to install ReactOS with DBG=1 and KDBG=1
enabled.
On the same hardware, version with DBG=0 and KDBG=0 installs and runs fine.
DBG=1, KDBG=1 enabled ReactOS booted by freeldr asks for COMUTERNAME,
Name, password, time zone etc. etc. and asks for reboot.
Then it bugchecks with :
bt
Frames: vmwinst.exe: vmwinst.c: 75 (DetectVMware)
bugcheck
KeBugCheck at dbg/kdb.c: 1495
Bug detected (code deaddead param 0 0 0 0)
Page fault at high IRQL was 2
KeBugCheckWithTf at ke/catch.c:165
Bug detected (code 1e param 0 0 0 0)
KMODE_EXCEPTION_NOT_HANDLED
Page fault Exception: 14(0)
Processo: 0 CS:EIP 8:c00b8cb7 <ntoskrnl.exe: rtl/message.c:108
(RtlFindMessage)>
cr2 e07a4604 cr3 1d84a000
Proc: c0eb1c90 Pid:7 <vmwinst> Thrd: c0ebd08 Tid: 2c
DS 10 ES 10 FS 30 GS 10
kernel stack base df255000
KeBugCheckWithTf
KeBugCheckEx
KeBugCheck
DbgBugCheckCommand
KdbDoCommand
KdbMainLoop
KdbInternalEnter
KdbEnterDebuggerException
KiDispatchException
ke/i386/usertrap.c: 139 KiUserTrapHandler
ke/i386/exp.c: 613 KiTrapHandler
/tmp/ccphDdwg.s: 146 KeUserModeCallback
vmwinst.c: 75 DetectVMware
vmwinst.c:1016 WinMain
1047 WinMain
kernel32.dll: BaseProcessStart <DEADBEEF>
If someone is interested in more debugging informations, I can send
processor registers and map files.
Regards,
David
--
David Kredba <kredba at ibot.cas.cz>
GPG: ID 1024D/5B6B02DE
Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE
PLease find the status of the Reactos support for the Nic Realtek8139 as
per my testing.
1) Detection of Pci Bus2 = Fixed
The problem of enumerating cards located on PCI BUS 2 has been fixed by
Eric Khol . The bug# 436 can be closed
2) Start Nic driver failure
The RTL8139.SYS driver loads successfully but fails to start due to the
"NdisMQueyAdapterResources" function which is unimplemnted .
The Bug#446 has been created
=> This is a blocking point for networking with this popular Nic
Best regards
Gerard
Are you getting this ?
(DBG=1, KDBG=1)
make[1]: Entering directory `/home/dave2/ros/reactos/lib/msafd'
mingw32-gcc -I./include -Wall -Werror -fno-builtin -DUNICODE
-D__USE_W32API -I.-I../../include -I../../w32api/include -pipe
-march=i486 -D_M_IX86 -g -c misc/sndrcv.c -o misc/sndrcv.o
misc/sndrcv.c: In function `WSPRecv':
misc/sndrcv.c:66: error: `AFD_IMMEDIATE' undeclared (first use in this
function)
misc/sndrcv.c:66: error: (Each undeclared identifier is reported only once
misc/sndrcv.c:66: error: for each function it appears in.)
misc/sndrcv.c: In function `WSPRecvFrom':
misc/sndrcv.c:214: error: `AFD_IMMEDIATE' undeclared (first use in this
function)
misc/sndrcv.c: In function `WSPSend':
misc/sndrcv.c:365: error: `AFD_IMMEDIATE' undeclared (first use in this
function)
misc/sndrcv.c: In function `WSPSendTo':
misc/sndrcv.c:503: error: `AFD_IMMEDIATE' undeclared (first use in this
function)
David
--
David Kredba <kredba at ibot.cas.cz>
GPG: ID 1024D/5B6B02DE
Fingerprint: F0B3312596BEDCF91DFB 0699E06AACD75B6B02DE
I found the bug in our ne2000 driver that perplexed filip. The bug was that
the meaning of the PACKET_HEADER part in ne2000 that was skipped was a simple
header put on each packet to determine what buffer page would be used next.
This header is only 4 bytes and has nothing to do with the ethernet frame
header.
I've now factored in the ethernet frame header and made tcpip work the right
way, that is to remove consideration of the ethernet frame header at layers
above lan in the receive pipe. This should make all adapters work the same
way for larger packets (and ne2000 now work right).
I found few references to how this actually works so I could still be wrong,
but I'm going on what filip said and this:
http://cvs.sourceforge.net/viewcvs.py/openh323/pwlib/tools/PacketVxD/epacke…
Which basically confirms filip's opinion.
Please try it out.
--
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman
Just came across this: http://www.genesi.lu/
Appears to be a new PPC based platform with published specs - would be
great to have ROS running on this!
Cheers
Jason
Hi,
I think some of your changes in apc.c are wrong. Apc's are always thread
local. They have nothing to do with the dispatcher database lock. The only
locking object is the ApcQueueLock from the thread structure.
- Hartmut
> -----Original Message-----
> From: ros-cvs-bounces(a)reactos.com
> [mailto:ros-cvs-bounces@reactos.com] On Behalf Of ion(a)cvs.reactos.com
> Sent: Thursday, November 11, 2004 2:24 PM
> To: ros-cvs(a)reactos.com
> Subject: [ros-cvs] CVS Update: reactos
>
>
> CVSROOT: /CVS/ReactOS
> Module name: reactos
> Repository: reactos/ntoskrnl/ps/
> Changes by: ion(a)mok.osexperts.com 04/11/11 14:23:53
>
> Modified files:
> reactos/include/ddk/: kefuncs.h ketypes.h
> reactos/ntoskrnl/include/internal/: ke.h ps.h
> reactos/ntoskrnl/ke/: apc.c process.c wait.c
> reactos/ntoskrnl/mm/: marea.c virtual.c
> reactos/ntoskrnl/mm/i386/: page.c
> reactos/ntoskrnl/ps/: psmgr.c
>
> Log message:
> Kernel:
> - apc.c: Fixed some bugs and used Dispatcher Lock.
> Simplified some functions and renamed/inlined others.
> - wait.c: Fixed some assumptions about Dispatcher Lock
> and Waiting/Alertability
> - process.c: Fully implemented KeStackAttachProcess and
> KeStackDetachProcess. Made all functions use PKPROCESS and
> not PEPROCESS.
> Memory Manager: Fixed calls to
> KeAttachProcess/DetachProcess to typecast PKPROCESS
> Process Manager: Removed call to empty function in apc.c
>
> _______________________________________________
> Ros-cvs mailing list
> Ros-cvs(a)reactos.com
> http://reactos.com/mailman/listinfo/ros-cvs
>