Ros-dev January 2006

ros-dev@reactos.org

69 participants
136 discussions

by Hartmut Birr

Hi, I'm not able to install ros from the current trunk on real hardware. At the end of the second stage setup I see a reset, which seems to be a triple fault. After the reset, I'm again on the second stage setup. - Hartmut

18 years, 8 months

Broken Message Dispatching in Win32k

by Alex Ionescu

Hi, After applying my user-mode callback patch, I sometimes see a bugcheck caused by my debugging code. It seems that we do user-mode callbacks with Kernel APCs disabled (just like we also did them with PreviousMode == KernelMode, thank God that I had to "break" HEAD to find this huge bug... but that's another story). The old code "worked" because it did not check for this serious mistake. Normally, I've noticed that messages are sent through co_IntSendMessage which is called with KernelApcDisable == -1. That function calls some unlocking functions and then does the Callback, which is called with KernelApcDisable == 0, which is good. However, co_IntSendMessage is sometimes being called from co_MsqPeekHardwareMessage. DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable); WaitObjects[1] = MessageQueue->NewMessages; WaitObjects[0] = &HardwareMessageQueueLock; do { UserLeaveCo(); WaitStatus = KeWaitForMultipleObjects(2, WaitObjects, WaitAny, UserRequest, UserMode, FALSE, NULL, NULL); UserEnterCo(); DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable); while (co_MsqDispatchOneSentMessage(MessageQueue)) { DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable); } DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable); } while (NT_SUCCESS(WaitStatus) && STATUS_WAIT_0 != WaitStatus); In this loop, the first KernelApcState is -1. After the wait, it becomes -2. Now normally there is nothing to dispatch, so the function continues, and the -2 later becomes a -3 after another lock, then gradually goes down to -2, then back to -1. So the function enters with -1 and exits with -1, which is normal. However, if the Message Queue *does* have a message on it, then co_MsqDispatchOneSentMessage ends up being called. Remember that after the wait we're now at -2. So that function will then call co_IntSendMessage at -2, which will lower ir it to -1 before the callback. But now the callback runs at -1, which means Kernel APCs are disabled... so we bugcheck. I have absolutely NO knowledge of Win32k Message Queues/MesssageSending, but something defintely seems wrong to me here...can anyone help please? Best regards, Alex Ionescu

18 years, 8 months

Re: [ros-svn] [hbirr] 20793: - We cannot access the OwnerTable without locking the resource.

by Hartmut Birr

hbirr(a)svn.reactos.org wrote: > - We cannot access the OwnerTable without locking the resource. > - The shared waiters may wait also on the semaphore. It makes no sense to boost a waiting thread. > - The thread header is initialized like KeWaitForSingleObject (?, ?, ?, TRUE, ?). During the boost, > possible the dispatcher lock is released but the thread block (WaitNext) isn't changed. > > > > Updated files: > trunk/reactos/ntoskrnl/ex/resource.c > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-svn > > Oops, I've copied the wrong commit message. The correct is: - We cannot access the OnerTable without locking the resource. - The shared waiters may wait also on the semaphore. It makes no sence to boost a waiting thread. - The thread header is initialized like KeWaitForSingleObject (?, ?, ?, TRUE, ?). During the boost, possible the dispatcher lock is released but the thread block (WaitNext) isn't changed. - Hartmut

18 years, 8 months

Bug Check in Marea.c

by James Tabor

Hi all, With real hardware and revision 20802, At the end of first stage and after hitting the Finish button, I can reproduce this every time too, KeBugCheck at ./ntoskrnl/mm/marea.c:901 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. Technical information: *** STOP: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000) Frames: <ntoskrnl.exe:1676 (./ntoskrnl/ke/bug.c:483 (KeBugCheckEx))> <ntoskrnl.exe:168d (./ntoskrnl/ke/bug.c:504 (KeBugCheck))> <ntoskrnl.exe:4342b (./ntoskrnl/mm/marea.c:0 ())> <ntoskrnl.exe:434c4 (./ntoskrnl/mm/process.c:0 ())> <ntoskrnl.exe:55c12 (./ntoskrnl/ps/kill.c:200 (PspDeleteThread))> <ntoskrnl.exe:50cdd (./ntoskrnl/ob/object.c:0 ())> <ntoskrnl.exe:518ce (./ntoskrnl/ob/handle.c:254 (ObpDeleteHandle))> <ntoskrnl.exe:51a0b (./ntoskrnl/ob/handle.c:1112 (NtClose))> <ntoskrnl.exe:6440c (ntoskrnl/ke/i386/syscall.S:372 (KiSystemService))> <KERNEL32.dll:a697 (./lib/kernel32/misc/handle.c:0 ())> Entered debugger on embedded INT3 at 0x0008:0x80073b86. kdb:> bt Eip: <ntoskrnl.exe:73b87 (lib/rtl/i386/debug_asm.S:28 (DbgBreakPointWithStatus))> Frames: <ntoskrnl.exe:1676 (./ntoskrnl/ke/bug.c:483 (KeBugCheckEx))> <ntoskrnl.exe:168d (./ntoskrnl/ke/bug.c:504 (KeBugCheck))> <ntoskrnl.exe:4342b (./ntoskrnl/mm/marea.c:0 ())> <ntoskrnl.exe:434c4 (./ntoskrnl/mm/process.c:0 ())> <ntoskrnl.exe:55c12 (./ntoskrnl/ps/kill.c:200 (PspDeleteThread))> <ntoskrnl.exe:50cdd (./ntoskrnl/ob/object.c:0 ())> <ntoskrnl.exe:518ce (./ntoskrnl/ob/handle.c:254 (ObpDeleteHandle))> <ntoskrnl.exe:51a0b (./ntoskrnl/ob/handle.c:1112 (NtClose))> <ntoskrnl.exe:6440c (ntoskrnl/ke/i386/syscall.S:372 (KiSystemService))> <KERNEL32.dll:a697 (./lib/kernel32/misc/handle.c:0 ())> <winlogon.exe:1ae2> <winlogon.exe:20f6> <winlogon.exe:339a> <winlogon.exe:11e7> <winlogon.exe:1258> <00000000> kdb:> I go into ntoskrnl/mm/marea.c and at line 891 I change DPRINT to DPRINT1, now the system reboots and runs normal. I even have Abiword running with Winefile. Thanks, James

18 years, 8 months

Re: [ros-diffs] [hbirr] 20793: - We cannot access the OwnerTable without locking the resource.

by Alex Ionescu

hbirr(a)svn.reactos.org wrote: > if (!Resource->ActiveCount) > { > > >- /* Nobody owns it, so let's take control */ > > >+ if (Resource->NumberOfSharedWaiters == 0) >+ { >+ Owner = &Resource->OwnerThreads[1]; >+ } >+ else >+ { >+ /* Find a free entry */ >+ Owner = ExpFindFreeEntry(Resource, &OldIrql); >+ if (!Owner) goto TryAcquire; >+ } >+ >+ Owner->OwnerThread = Thread; >+ Owner->OwnerCount = 1; > > > Resource->ActiveCount = 1; > > >- Resource->OwnerThreads[1].OwnerThread = Thread; >- Resource->OwnerThreads[1].OwnerCount = 1; > > > > /* Release the lock and return */ > ExReleaseResourceLock(&Resource->SpinLock, OldIrql); > > This change makes no sense. Note that we check for !Resource->ActiveCount. This, by definition implies that there CANNOT be any exclusive owner or shared owner. Access to the resource should be granted instanteously. Best regards, Alex Ionescu

18 years, 8 months

RE: [ros-dev] Patent on FAT

by Murphy, Ged (Bolton)

Ge van Geldorp wrote: > AFAIK, it is about storing both a long and a short filename > for the same > file in the same directory. > > GvG Do we really need the ability to store short file names? Can we not just remove that feature entirely? Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

18 years, 8 months

Re: Re: [ros-dev] Patent on FAT

by Johannes Olofsson

Does it really matter if people enable it or not if we still provide the functionality? /Johannes Olofsson > Till: ReactOS Development List <ros-dev(a)reactos.org> > Rubrik: Re: [ros-dev] Patent on FAT > Datum: Wed, 11 Jan 2006 14:57:50 -0500 > Hi, > > I think we should turn off the 8.3 short filename support by default > and see what breaks. Providing a option right at the start of 2nd > stage step "Patented features" using a checkbox to enable it should > get us around the issue. Its not our problem if someone else enables > it. > > -- > Steven Edwards - ReactOS and Wine developer > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > <a > href=http://www.reactos.org/mailman/listinfo/ros-dev>http://www.reactos.org/ > mailman/listinfo/ros-dev</a>

18 years, 8 months

RE: [ros-dev] Patent on FAT

by Murphy, Ged (Bolton)

nitro2k01 wrote: > I haven't seen the patant documents, but doesn't this mean that any > file system which stores both long and short file names on the same > volume would be theoreticlly affected? > No. Long files names were incorporated into unix systems long before the days FAT, or even DOS. This patent (if correct) is linked to FAT only. If is true, it would effect many things, but I can't see Microsoft enforcing it, it would alienate themselves. Just the fact that it is there is a problem for ReactOS though, even if they don't do anything about it. I haven't been able to find a copy of the patent yet. AFAIK, it was only released today. Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

18 years, 8 months

Could someone look at bug 1263?? Please?

by WaxDragon

I've seen this bugcheck several times debugging various things. At the moment, it reproducible following the steps in the bug. This has been around for a while and it aid me greatly to have it fixed. http://www.reactos.org/bugzilla/show_bug.cgi?id=1263 WD -- <Alex_Ionescu> it's like saying let's rename Ke to Kernel because people think it's Ketchup

18 years, 8 months

RE: [ros-dev] Patent on FAT

by Murphy, Ged (Bolton)

Murphy, Ged (Bolton) wrote: > > I'm reading reports of a US patent on FAT. > Link: http://news.com.com/Microsofts+file+system+patent+upheld/2100-1012_3-6025447 .html?part=rss&tag=6025447&subj=news ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

18 years, 8 months

← Newer
1
...
6
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev January 2006