Alex wrote:
>It looks like a guarded mutex is being acquired at DPC level. That's
>pretty bad.
Well, at least it's redundant and useless. :-)
>Pushlocks shouldn't be acquired at DPC level either
Indeed. If "you" are at DPC level, you have but one synchronization to
care about - SMP (i.e. CPU<->CPU).
>, but there's no
>ASSERTs in the pushlock code that check for that.
An oversight that should be fixed, I'm sure (even if it happened to
slow down the system by a whole order of magnitude, which it won't).
>MMProbeAndLockPages should never be called for paged pool addreses
>while at DPC level,
Should MmProbeAndLock ever be called at IRQL above APC level? I mean,
what if the probing fails? Should the paging executive somehow preempt
this call and page in the missing pages (or should it simply throw a
"page not present" exception - not too great to do at DPC level I'd
say)?
>which means the driver probably called it for a
>non-paged pool address.
If my previous suspicion is correct, I build on that and suspect this
is an error in itself. The ProbeAndLock call should be done at APC
level (though I may be completely wrong, but do read my finishing
line).
>In that case, the whole loop about checking if the page is present
and
>then faulting it in is irrelevant, and won't happen.
Right. Page fault at DPC level == Bad Move(tm).
--
Mike
Hi ARMs,
Doing a good job BTW~
Thanks,
James
(ntoskrnl/kd/kdio.c:191) -----------------------------------------------------
(ntoskrnl/kd/kdio.c:192) ReactOS 0.4-SVN (Build 20080728-r34871)
(ntoskrnl/kd/kdio.c:193) Command Line: DEBUG DEBUGPORT=COM1
BUADRATE=115200 SOS
(ntoskrnl/kd/kdio.c:194) ARC Paths:
multi(0)disk(0)rdisk(0)partition(1) \ multi(0)disk(0)rdisk(0)parti
tion(1) \ReactOS\
Used memory 1015348Kb
(ntoskrnl/mm/mminit.c:295) Start End Type
(ntoskrnl/mm/mminit.c:296) 0x80000000 - 0x80800000 Undefined region
(ntoskrnl/mm/mminit.c:299) 0x80800000 - 0x80E00000 FreeLDR Kernel
mapping region
(ntoskrnl/mm/mminit.c:302) 0x80E00000 - 0x815C0000 PFN Database region
(ntoskrnl/mm/mminit.c:309) 0x815C0000 - 0x879C0000 Non paged pool region
(ntoskrnl/mm/mminit.c:312) 0x879C0000 - 0x8DDC0000 Paged pool region
(ntoskrnl/ke/i386/kiinit.c:47) Large Page support detected but not yet
taken advantage of!
WARNING: KdDebuggerInitialize1 at drivers/base/kdcom/i386/kdbg.c:489
is UNIMPLEMENTED!
WARNING: IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:700 is
UNIMPLEMENTED!
WARNING: IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:700 is
UNIMPLEMENTED!
(ntoskrnl/io/iomgr/driver.c:1356) '\Driver\BUSLOGIC' initialization
failed, status (0xc00000c0)
(ntoskrnl/io/iomgr/driver.c:1356) '\Driver\Floppy' initialization
failed, status (0xc000000e)
Assertion 'KeGetCurrentIrql()<=(1)' failed at ntoskrnl/ke/gmutex.c line 201
Entered debugger on embedded INT3 at 0x0008:0x808a8262.
kdb:> bt
Eip:
<NTOSKRNL.EXE:a8263 (lib/rtl/i386/debug_asm.S:33 (DbgBreakPoint@0))>
Frames:
<NTOSKRNL.EXE:a027 (ntoskrnl/ke/gmutex.c:201 (@KeAcquireGuardedMutex@4))>
<NTOSKRNL.EXE:6d3a2 (ntoskrnl/include/internal/mm.h:1556
(MmProbeAndLockPages@12))>
<NTOSKRNL.EXE:4f079 (ntoskrnl/io/iomgr/irp.c:694
(IoBuildAsynchronousFsdRequest@24))>
<SCSIPORT.SYS:4671 (drivers/storage/scsiport/scsiport.c:3959
(ScsiPortDpcForIsr@16))>
<NTOSKRNL.EXE:823a (ntoskrnl/ke/dpc.c:474 (@KiRetireDpcList@4))>
<NTOSKRNL.EXE:9fc59 (ntoskrnl/ke/i386/ctxswitch.S:691 (@KiIdleLoop@0))>
<00000000>
kdb:>
Hi,
I've been attempting to sync some of the Wine dlls, namely the IE
support dlls and have run in to a bit of a problem which I think is a
bug in ReactOS widl. It seems that the import keyword is not working.
When trying to build shdocvw.dll it creates a shdocvw_v1.tlb based on
shdocvw_v1.idl which imports exdisp.idl from the SDK which in turn
does an import ("stdole2.tlb")
As you can see from the output below
sedwards@mini-gimli:~/source/reactos$ make shdocvw
[WIDL] obj-i386/dll/win32/shdocvw/shdocvw_v1.tlb
error: Could not open importlib stdole2.tlb.
mingw32-make: *** [obj-i386/dll/win32/shdocvw/shdocvw_v1.tlb] Error 2
Total Build Time: 00:00:02
Notice the . at the end of stdole2.tlb? I've tried just renaming the
typelib and putting it in several intermediate folders to no effect.
If any WIDL Guru can help please find the attached patch which
contains an updated shdocvw.rbuild
Thanks
Steven
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Yesterday I was playing around with the test suite in HEAD when I moved onto
kernel32.
It was, without wanting to sound too harsh, a bit of a disgrace, with large
failures throughout the whole test range.
I suggest a hacking day on it using the test suite, a joint effort to bring
this core lib back into line. Perhaps with some emphasis on trying to make
it fun.
Whoever gets the most fixes is crowned 'king ding-a-ling' and holds the
title until the next one, opening the road up to days on ntdll, user32,
gdi32 and crt?
Ged.
Hi,
When installing Java or anything with java it hangs and just sit there
running. It could be OOo 2.4 or installing java, does not mater, I
just left the box running all night and just sits there, still
installing..
This bug fault right after I restarted. Is it waiting on a lock?
Assertion 'WaitBlock->Signaled' failed at ntoskrnl/ex/pushlock.c line 599
Entered debugger on embedded INT3 at 0x0008:0x808ad242.
kdb:> bt
Eip:
<NTOSKRNL.EXE:ad243 (lib/rtl/i386/debug_asm.S:33 (DbgBreakPoint@0))>
Frames:
<NTOSKRNL.EXE:2da24 (ntoskrnl/ex/pushlock.c:599
(@ExfAcquirePushLockExclusive@4))>
<NTOSKRNL.EXE:6eb00 (ntoskrnl/include/internal/ex.h:715
(MiProtectVirtualMemory@20))>
<NTOSKRNL.EXE:6fdbf (ntoskrnl/mm/virtual.c:927 (NtProtectVirtualMemory@20))>
<NTOSKRNL.EXE:979ca (ntoskrnl/ke/i386/trap.s:244 (KiFastCallEntry))>
<ntdll.dll:5e1a> ntdll/main/i386/dispatch.S:297 (KiFastSystemCallRet@0)
<kernel32.dll:e0ce> kernel32/mem/virtual.c:127 (VirtualProtect@16)
<jvm.dll:149b27>
kdb:>
Hi all,
I'm working on first stage gui setup.
During the development i reviewed the base/setup directory and the different
modules. I suggest following changes:
Now:
reactos.exe: atm greeting only with disabled first stage setup dialogs
setup.exe: switcher for 2nd stage setup (syssetup) or livecd
usetup.exe: textmode 1st stage setup
vmwinst.exe: don't know exactly, vm-ware driver installation
welcome.exe: nice welcome dialog without real functions
Future:
setup.exe: switcher for 1st stage gui setup, 2nd stage setup, livecd and
welcome dialog switched by command line arguments
"setup.exe" -> welcome dialog
"setup.exe -mini" -> livecd
"setup.exe -newsetup1" -> 1st stage gui setup
"setup.exe -newsetup2" -> 2nd stage (gui) setup
usetup.exe: textmode 1st-stage-setup
vmwinst.exe: keeps unchangend
reactos.exe, welcome.exe: removed
Are there any objections to go this way? If not, so i will change this soon.
Matthias
--
Matthias Kupfer Telefon +49 (0) 371 236 46 52
Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54
09122 Chemnitz
On Tue, Jul 22, 2008 at 9:56 AM, Sylvain Petreolle <spetreolle(a)yahoo.fr> wrote:
> It'sToo bad the header is not in an include directory...
Maybe it should go in the NDK then.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
> De : Steven Edwards <winehacker(a)gmail.com>
> À : ros-dev(a)reactos.org
> Envoyé le : Mardi, 22 Juillet 2008, 11h49mn 04s
> Objet : Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 34655: - Build vfatfs instead of CDFS. - Load vfatfs instead of CDFS. - Implement code in the ramdisk driver to handle both ISO and FAT ramdisks. Don't know what the big deal with support ISO ramdisks was supposed to
>
> On Tue, Jul 22, 2008 at 5:42 AM, Steven Edwards wrote:
> > On Tue, Jul 22, 2008 at 1:31 AM, wrote:
> >> #include
> >> +#include "../../../filesystems/fs_rec/fs_rec.h"
> >
> > This can cause problems with parallel makes.
>
> This is what I get for commenting at 5 am...I thought you were
> including another .c file directly. ignore the part about parallel
> makes. But do try to avoid referencing the header like this. Just set
> an include path in the rbuild file and spare my eyes the horror of the
> directory traversal.
>
> --
> Steven Edwards
>
It'sToo bad the header is not in an include directory...
Kind regards,
Sylvain Petreolle (aka Usurp)
Support artists, not multinationals - http://Iwouldntsteal.net
Supportez les artistes, pas les multinationales - http://Iwouldntsteal.net
On Tue, Jul 22, 2008 at 1:31 AM, <ros-arm-bringup(a)svn.reactos.org> wrote:
> #include <reactos/drivers/ntddrdsk.h>
> +#include "../../../filesystems/fs_rec/fs_rec.h"
This can cause problems with parallel makes.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Indeed, that's not conform to EULA that says: "You may not distribute
Distributable Code to run on a platform other than the Windows platform;".
Moreover, CDFS driver ISN'T listed as a "Distributable Code".
Please revert to avoid any problems.
P. Schweitzer
--------------------------------------------------
From: "Steven Edwards" <winehacker(a)gmail.com>
Sent: Monday, July 21, 2008 12:21 AM
To: <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 34615: - Add new
CDFSdriver. - Does not compile.
> On Sun, Jul 20, 2008 at 3:52 PM, <ros-arm-bringup(a)svn.reactos.org> wrote:
>> URL: http://svn.reactos.org/svn/reactos?rev=34615&view=rev
>> Log:
>> - Add new CDFS driver.
>> - Does not compile.
>
> Ehem...as far as I understand the EULA (unless its changed) you cannot
> use the WDK references drivers for a non-windows OS. Please revert
> this and write you own.
>
> --
> Steven Edwards
>
> "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
> http://www.reactos.org/mailman/listinfo/ros-dev
>
On Sun, Jul 20, 2008 at 3:52 PM, <ros-arm-bringup(a)svn.reactos.org> wrote:
> URL: http://svn.reactos.org/svn/reactos?rev=34615&view=rev
> Log:
> - Add new CDFS driver.
> - Does not compile.
Ehem...as far as I understand the EULA (unless its changed) you cannot
use the WDK references drivers for a non-windows OS. Please revert
this and write you own.
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hello,
after several commits that leads in broken inf-files (last one 34598 by
spetreolle), I invite to take care about following things:
1. The inf files are in UTF-16LE a.k.a. UCS-2LE.
2. All lines ends with CRLF (a single one, no other combination).
3. The files have to start with a bom (byte order mark).
4. There are no more boms allowed anywhere in the file.
Please modify that files _very_ carefully, because we can't check changes via
diff, due to the lack of utf-16 support in svn.
Matthias
--
Matthias Kupfer Telefon +49 (0) 371 236 46 52
Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54
09122 Chemnitz
On Sun, Jul 20, 2008 at 12:40 AM, <ros-arm-bringup(a)svn.reactos.org> wrote:
> - We end up crashing in CcRosTryToInitialzeFileCache because there is no SectionObjectPointer, and it is assumed this always exists.
Ninjas! I don't know if this is related but would it be possible to
switch to doing development on NoCC in case you guys run in to more
problems like these? I don't know if it would help but I assume your
going to run in to more problems with the current Cc and you might be
able to save a lot of trouble later on.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi!
A show is coming up and we need to look good. Haiku looks good and it
has networtking and draws objects very well. Please check our drawing
with test apps and look at networking and see where we are on hardware
support. I know there are bugs maybe by August 4th we can get back
some basic networking with hardware. PCI n2k? or FET?
KPANIC!
James
Maybe it's worth adding these tests to msvcrt test suite and submit
to Wine?
WBR,
Aleksey Bragin.
On Jul 17, 2008, at 2:08 AM, cfinck(a)svn.reactos.org wrote:
> Author: cfinck
> Date: Wed Jul 16 17:08:58 2008
> New Revision: 34558
>
> URL: http://svn.reactos.org/svn/reactos?rev=34558&view=rev
> Log:
> Commit my test suite I used for verifying the behaviours of wctomb,
> wcstombs and WideCharToMultiByte and writing the reimplementations
> for ReactOS on request of Stefan
Hi,
Does "make install" work for you by any chance?
I get this:
bash-3.1# make install
mingw32-make: *** No rule to make target `boot/bootdata/i386/hivecls.inf',
needed by `reactos/system32/config/default'. Stop.
I tested some of GreatLord's regressions and I can see how Aleksey would
get angry about all the fixes he has to do to GreatLord's code, but
GreatLord has fixed a whole lot more than he has broken and Fireball
chasing around 'if (Foo == FALSE)' and changing it to 'if (!Foo)' seems
pointless. We've got plenty of code formatted as 'if (Foo == FALSE)' in
the kernel that works great. Aleksey is making more work for himself by
making needless changes to GreatLord's code. All that is needed is
someone with commit access that is willing to correct GreatLord's
comments. I don't have a problem with finding a regression of GL's here
or there. Sure he should test his code before committing but as far as
breakages, but his code usually correct and all coders create breakages
one time or another.
Hi,
I did some research and found something very interesting. I kept
thinking about the last DCE commit (34289). I had a guess and modified
the user32 test for wine. The results are very clear. Apparently
windows does not care for which dc is returned if it is Cached or a
bug since hWnd is the same. When DCX_NORESETATTRS is set when calling
GetDCEx; "Does not reset the attributes of this DC to the default
attributes when this DC is released." We do this correctly in
ReleaseDC. So the next GetDCEx should keep the original DC data for
the next set of tests. Wine test is completely incorrect. So all of
our DCE attributes code is good to go. Windows did not pass the
modified "Same hDC" check and we still fail the "ROP" check. See the
windows results at the end of this message.
////////
Changes to user32/tests/dce.c:
ReleaseDC( hwnd_cache, hdc );
hdc = GetDCEx( hwnd_cache, 0, DCX_USESTYLE | DCX_NORESETATTRS );
<------ DCX_NORESETATTRS
rop = GetROP2( hdc );
ok( rop == def_rop || rop == R2_WHITE, "wrong ROP2 %d after
release\n", rop );
ReleaseDC( hwnd_cache, hdc );
+ old_hdc = hdc;
hdc = GetDCEx( hwnd_cache, 0, DCX_USESTYLE );
rop = GetROP2( hdc );
+ ok( old_hdc == hdc, "didn't get same DC %p/%p\n", old_hdc, hdc );
ok( rop == def_rop, "wrong ROP2 %d after release\n", rop );
ReleaseDC( hwnd_cache, hdc );
/* test own DC */
////////
////////
Results from XP:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
Z:\>e:
E:\>user32_crosstest dce
dce.c:79: Test failed: didn't get same DC F5010866/FC0107E0
dce: 77 tests executed (0 marked as todo, 1 failure), 0 skipped.
E:\>
/////////
I also agree.
About the last point, in Ged's mail, I'm afraid to say I've real
difficulties to code with such build time. I'm obliged to work on outdated
revisons, and on partial builds. That's really insane.
P. Schweitzer
--------------------------------------------------
From: "gedmurphy" <gedmurphy(a)gmail.com>
Sent: Wednesday, July 02, 2008 5:49 PM
To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] [ros-diffs] [dchapyshev] 34135: - Add fontext.dll
> I completely agree, this needs to be clamped down on. Do we really need 78
> different keyboard layouts at this point?
> It's fine for the people with mega fast systems and time on their hands,
> but
> most people don't fall into this category.
>
> I now try to avoid building as much as possible and I suspect more people
> will be following suit if the build time continues to increase.
>
> Ged
>
>