Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-svn] [hbirr] 12690: - Implemented KeAcquireInterruptSpinLock and KeReleaseInterruptSpinLock.
by Alex Ionescu 01 Jan '05

01 Jan '05

hbirr(a)svn.reactos.com wrote: >- Implemented KeAcquireInterruptSpinLock and KeReleaseInterruptSpinLock. >- Implemented the interrupt handling for smp machines. > > > >Updated files: >trunk/reactos/include/ddk/kefuncs.h >trunk/reactos/include/ntos/zwtypes.h >trunk/reactos/ntoskrnl/io/irq.c >trunk/reactos/ntoskrnl/ke/i386/irq.c >trunk/reactos/ntoskrnl/ke/spinlock.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > Hi, Thanks for adding this feature to the kernel, I only have one problem with it... Would it be possible to modify the code to use the documented KINTERRUPT structure? This would (already does) wreck havoc on the new header system, which uses documented Windows structures (except in extreme cases where our code is very old, and those structures were unavailable, ie the Ob Manager structures... although enventually that code will have to be updated). The correct KINTERRUPT structure is: typedef struct _KINTERRUPT { CSHORT Type; CSHORT Size; LIST_ENTRY InterruptListEntry; PKSERVICE_ROUTINE ServiceRoutine; PVOID ServiceContext; KSPIN_LOCK SpinLock; ULONG TickCount; PKSPIN_LOCK ActualLock; PVOID DispatchAddress; ULONG Vector; KIRQL Irql; KIRQL SynchronizeIrql; BOOLEAN FloatingSave; BOOLEAN Connected; CHAR Number; UCHAR ShareVector; KINTERRUPT_MODE Mode; ULONG ServiceCount; ULONG DispatchCount; ULONG DispatchCode[106]; } *KINTERRUPT*, *PKINTERRUPT; vs ours: typedef struct _KINTERRUPT { ULONG Vector; KAFFINITY ProcessorEnableMask; KSPIN_LOCK SpinLock; PKSPIN_LOCK ActualLock; BOOLEAN Shareable; BOOLEAN FloatingSave; CHAR ProcessorNumber; PKSERVICE_ROUTINE ServiceRoutine; PVOID ServiceContext; LIST_ENTRY Entry; KIRQL Irql; KIRQL SynchLevel; KINTERRUPT_MODE InterruptMode; } KINTERRUPT; Type/Size are Windows Ob Manager headers for each Object...if you look in KOBJECTS you'll find the right value...but we don't check for this yet, so it's not important yet. I don't know what "Shareable" is however. But we only need to rename/reposition some of the items. ProcessorEnableMask also seems to be missing in the real defintion. If you'd be kind enough to do these changes, I would really appreciate it. If you have any comments, let me know. Best regards, and happy new year, Alex Ionescu

2 3

KeConnectInterrupt & ListHeads
by David Kredba 01 Jan '05

01 Jan '05

Hello, I got this with current svn tree : make[1]: Entering directory `/home/dave2/ros/reactos/ntoskrnl' ../tools/regtests ./tests/tests ./tests/_regtests.c ./tests/Makefile.tests -e ./tests/_rtstub.c ../tools/regtests -s ./tests/stubs.tst ./tests/_stubs.S ./tests/_hooks.c mingw32-windres --include-dir ../include --include-dir ../w32api/include ntoskrnl.rc -o ntoskrnl.coff mingw32-gcc -c -x assembler-with-cpp -I./include -g -I../include -I../w32api/include -D__ASM__ -D_M_IX86 -D__3GB__ -c ke/i386/multiboot.S -o ke/i386/multiboot.o mingw32-gcc -I./include -I../lib/kjs/include -Wall -Werror -D_DISABLE_TIDENTS -D__3GB__ -D__NTOSKRNL__ -I. -D_SEH_NO_NATIVE_NLG -I../include -I../w32api/include -pipe -march=i486 -D_M_IX86 -g include/ntoskrnl.h mingw32-gcc -I./include -I../lib/kjs/include -Wall -Werror -D_DISABLE_TIDENTS -D__3GB__ -D__NTOSKRNL__ -I. -D_SEH_NO_NATIVE_NLG -I../include -I../w32api/include -pipe -march=i486 -D_M_IX86 -g -c ex/i386/interlck.c -o ex/i386/interlck.o mingw32-gcc -I./include -I../lib/kjs/include -Wall -Werror -D_DISABLE_TIDENTS -D__3GB__ -D__NTOSKRNL__ -I. -D_SEH_NO_NATIVE_NLG -I../include -I../w32api/include -pipe -march=i486 -D_M_IX86 -g -c ke/i386/exp.c -o ke/i386/exp.o mingw32-gcc -I./include -I../lib/kjs/include -Wall -Werror -D_DISABLE_TIDENTS -D__3GB__ -D__NTOSKRNL__ -I. -D_SEH_NO_NATIVE_NLG -I../include -I../w32api/include -pipe -march=i486 -D_M_IX86 -g -c ke/i386/irq.c -o ke/i386/irq.o ke/i386/irq.c: In function `KeConnectInterrupt': ke/i386/irq.c:496: error: structure has no member named `ListHeads' make[1]: *** [ke/i386/irq.o] Error 1 make[1]: Leaving directory `/home/dave2/ros/reactos/ntoskrnl' make: *** [ntoskrnl] Error 2 Thanks, David

3 3

¿Serious Bug with ReactOS liveCD RC-2?
by Lucio Diaz 01 Jan '05

01 Jan '05

I tested the live cd in a: -Intel 1.6 GHZ -Mainboard Intel 82801BA and CD drives -TEAC CD-540E -Yamaha CRW8424E The liveCD was in the Yamaha drive, all worked normally till i log off, the computer resets as normally and sudenly when the computer loads again it does not detect the yamaha CD, i tried reseting several times to try to put back online but not even the light of the yamaha turned on. I finaly turned down the power and swiched on again, the both CD drives where detected. Never something similar have happened to me, it is too much casual it happens on testing the liveCD just in THAT CD, but still i can not say if it is a bug of reactos or not. Another less important isue: I get the following error when accessing to the HDD E_ACCESSDENIED_WIN32 ACCESS DENIED ERROR Context:Shellfolder::Shellfolder(IShellfolder*,LPCITEMIDLST) Location: Utility/Shellclasses CPP:280 Still i can access the HDD (this happened two with the RC-1) Best Regards and Happy New Year, Lucio Diaz. ______________________________________________ Renovamos el Correo Yahoo!: ¡250 MB GRATIS! Nuevos servicios, más seguridad http://correo.yahoo.es

8 13

Re: [ros-diffs] [ion] 12682: Fix DMA_OPERATIONS to use stdcall.
by Filip Navara 01 Jan '05

01 Jan '05

ion(a)svn.reactos.com wrote: >Fix DMA_OPERATIONS to use stdcall. > >Modified: trunk/reactos/include/ddk/iotypes.h >Modified: trunk/reactos/ntoskrnl/io/pnpdma.c > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/include/ddk/iotypes.h* > >--- trunk/reactos/include/ddk/iotypes.h 2005-01-01 08:20:47 UTC (rev 12681) >+++ trunk/reactos/include/ddk/iotypes.h 2005-01-01 08:43:02 UTC (rev 12682) >@@ -1196,18 +1196,18 @@ > > SCATTER_GATHER_ELEMENT Elements[1]; > } SCATTER_GATHER_LIST, *PSCATTER_GATHER_LIST; > > > >-typedef VOID (*PPUT_DMA_ADAPTER)( > > >+typedef VOID STDCALL (*PPUT_DMA_ADAPTER)( > > This should be written as "typedef VOID (STDCALL *PPUT_DMA_ADAPTER)" Same for the other changes you made. - Filip

1 0

(no subject)
by Stephen Hodges 01 Jan '05

01 Jan '05

Will the CVS server sync up with SVN? It would keep the cvsweb app running. Why not also sync the sourceforge project cvs with SVN? As an extra mirror How often will it sync up? Stephen Hodges HYPERLINK "http://www.thespoke.net/MyBlog/stevo/MyBlog.aspx"http://www.thespoke.net/My Blog/stevo/MyBlog.aspx -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.6.7 - Release Date: 12/30/2004

3 2

Generated file in repo
by Mike Lerwill 31 Dec '04

31 Dec '04

The file "wine_unicode.map" in "\lib\unicode" appears to be a file generated at build time and as such needs to be deleted from the repository Mike

1 0

CVS has been converted to Subversion
by Casper Hornstrup 31 Dec '04

31 Dec '04

See subject. Casper

5 7

Re: [ros-cvs] CVS Update: reactos
by Filip Navara 31 Dec '04

31 Dec '04

ekohl(a)cvs.reactos.com wrote: >CVSROOT: /CVS/ReactOS >Module name: reactos >Repository: reactos/drivers/fs/np/ >Changes by: ekohl(a)mok.osexperts.com 04/12/30 04:34:27 > >Modified files: > reactos/drivers/fs/np/: create.c fsctrl.c > >Log message: > Use a new passive pipe state (0) to ensure that client ends don't connect to server ends in calls to WaitNamed Pipe(). > > This change breaks services.exe. Now it stops loading auto-start drivers because it ends up waiting in ConnectNamedPipe call. Trace w/ old version (CVS 29/12): (database.c:729) Group 'Event log' (database.c:532) ScmStartService() called (database.c:535) Service->Type: 16 (database.c:568) ImagePath: 'C:\ReactOS\system32\eventlog.exe' (database.c:569) Type: 10 (create.c:224) NpfsCreateNamedPipe(DeviceObject c03ac950 Irp c04cb228) (create.c:229) FileObject c04cb038 (create.c:230) Pipe name \net\NtControlPipe (database.c:580) CreateNamedPipeW() done (database.c:621) Process Id: 7 Handle 8c (database.c:624) Thread Id: 44 Handle 90 database.c:633 (fsctrl.c:391) NpfsFileSystemContol(DeviceObject c03ac950 Irp c04cf870) (fsctrl.c:395) IoStack: c04cf8e0 (fsctrl.c:397) FileObject: c04cb038 (fsctrl.c:399) Fcb: c04cbe70 (fsctrl.c:401) Pipe: c04cbef0 (fsctrl.c:402) PipeName: \net\NtControlPipe (fsctrl.c:417) Connecting pipe \net\NtControlPipe (fsctrl.c:29) NpfsConnectPipe() (fsctrl.c:40) Waiting for connection... (fsctrl.c:84) No listening client fcb found -- waiting for client (create.c:81) NpfsCreate(DeviceObject c03ac950 Irp c05e3528) (create.c:87) FileObject c05e3440 (create.c:88) FileName \net\NtControlPipe (create.c:36) <\net\NtControlPipe> = <\net\NtControlPipe> (create.c:59) Server found! Fcb c04cbe70 (create.c:195) Setting the ConnectEvent for c04cbe70 (create.c:206) Success! (fsctrl.c:391) NpfsFileSystemContol(DeviceObject c03ac950 Irp c05e3528) (fsctrl.c:395) IoStack: c05e3598 (fsctrl.c:397) FileObject: c05e3440 (fsctrl.c:399) Fcb: c05dc788 (fsctrl.c:401) Pipe: c04cbef0 (fsctrl.c:402) PipeName: \net\NtControlPipe (fsctrl.c:437) Waitin(fsctrl.c:101) Client Fcb: c05dc788 (database.c:638) Control pipe connected! Trace w/ new version (CVS frozen): (database.c:729) Group 'Event log' (database.c:532) ScmStartService() called (database.c:535) Service->Type: 16 (database.c:568) ImagePath: 'C:\ReactOS\system32\eventlog.exe' (database.c:569) Type: 10 (create.c:237) NpfsCreateNamedPipe(DeviceObject c03aa9b0 Irp c04cb098) (create.c:242) FileObject c04caef8 (create.c:243) Pipe name \net\NtControlPipe (database.c:580) CreateNamedPipeW() done (database.c:621) Process Id: 7 Handle 8c (database.c:624) Thread Id: 44 Handle 90 database.c:633 (fsctrl.c:406) NpfsFileSystemContol(DeviceObject c03aa9b0 Irp c04cf870) (fsctrl.c:410) IoStack: c04cf8e0 (fsctrl.c:412) FileObject: c04caef8 (fsctrl.c:414) Fcb: c04cb158 (fsctrl.c:416) Pipe: c04cbe38 (fsctrl.c:417) PipeName: \net\NtControlPipe (fsctrl.c:432) Connecting pipe \net\NtControlPipe (fsctrl.c:29) NpfsConnectPipe() (fsctrl.c:40) Waiting for connection... (fsctrl.c:95) No listening client fcb found -- waiting for client (create.c:81) NpfsCreate(DeviceObject c03aa9b0 Irp c05e3728) (create.c:86) FileObject c05e3640 (create.c:87) FileName \net\NtControlPipe (create.c:94) NpfsCreate() open client end for special use! (create.c:36) <\net\NtControlPipe> = <\net\NtControlPipe> <<-- Here is doesn't connect because the server pipe is not in listening state. (create.c:219) Success! (fsctrl.c:406) NpfsFileSystemContol(DeviceObject c03aa9b0 Irp c05e3728) (fsctrl.c:410) IoStack: c05e3798 (fsctrl.c:412) FileObject: c05e3640 (fsctrl.c:414) Fcb: c05e77a0 (fsctrl.c:416) Pipe: c04cbe38 (fsctrl.c:417) PipeName: \net\NtControlPipe (fsctrl.c:452) Waiting for pipe \net\NtControlPipe (fsctrl.c:166) NpfsWaitPipe (fsctrl.c:188) Listening server fcb found -- connecting (create.c:451) NpfsClose(DeviceObject c03aa9b0 Irp c05e3728) (create.c:466) Fcb c05e77a0 (create.c:469) Closing pipe \net\NtControlPipe (create.c:483) Client (create.c:81) NpfsCreate(DeviceObject c03aa9b0 Irp c05e3618) (create.c:86) FileObject c05e7ef0 (create.c:87) FileName \net\NtControlPipe (create.c:94) NpfsCreate() open client end for special use! (create.c:36) <\net\NtControlPipe> = <\net\NtControlPipe> (create.c:219) Success! (fsctrl.c:406) NpfsFileSystemContol(DeviceObject c03aa9b0 Irp c05e3618) (fsctrl.c:410) IoStack: c05e3688 (fsctrl.c:412) FileObject: c05e7ef0 (fsctrl.c:414) Fcb: c05e9070 (fsctrl.c:416) Pipe: c04cbe38 (fsctrl.c:417) PipeName: \net\NtControlPipe (fsctrl.c:472) Get state (fsctrl.c:276) Status (0x0). (fsctrl.c:406) NpfsFileSystemContol(DeviceObject c03aa9b0 Irp c05e3618) (fsctrl.c:410) IoStack: c05e3688 (fsctrl.c:412) FileObject: c05e7ef0 (fsctrl.c:414) Fcb: c05e9070 (fsctrl.c:416) Pipe: c04cbe38 (fsctrl.c:417) PipeName: \net\NtControlPipe (fsctrl.c:477) Set state (fsctrl.c:349) Status (0x0). (rw.c:278) NpfsWrite() (rw.c:282) FileObject c05e7ef0 (rw.c:283) Pipe name \net\NtControlPipe (rw.c:302) Pipe is NOT connected! (rw.c:432) NpfsWrite done (Status c0000001)

2 1

CVS being converted to SVN
by Casper Hornstrup 31 Dec '04

31 Dec '04

The conversion process has begun. I expect it to take about 30 hours to complete. I have tagged CVS HEAD with the tag "SVN". Casper

3 4

RE: [ros-cvs] I can't find some head files
by Ge van Geldorp 31 Dec '04

31 Dec '04

> From: yang > > I got the source from cvs,but I can't find some head files > like roscfg.h. Why? And where can I get it? roscfg.h (and a few others) should be generated during build. Generated files are normally not stored in CVS. Gé van Geldorp.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev