Another regression

Revision 53257 breaks Vbox test runtime at 2nd stage booting.
http://svn.reactos.org/svn/reactos?view=rev&revision=53257

-- 
With best regards
Caemyr

[Sylvain Petreolle]

Does the VM have ACPI enabled ? Try to turn it off then.

 
Kind regards,
Sylvain Petreolle


>  ________________________________
> De : "caemyr(a)myopera.com" <caemyr(a)myopera.com>
> À : ros-dev(a)reactos.org
> Envoyé le : Lundi 15 Août 2011 11h27
> Objet : [ros-dev] Another regression
>
> Revision 53257 breaks Vbox test runtime at 2nd stage booting.
> http://svn.reactos.org/svn/reactos?view=rev&revision=53257
>
> -- 
> With best regards
> Caemyr
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>

Shouldn't the bug be fixed instead of workaround?

On Mon, 15 Aug 2011 10:37 +0100, "Sylvain Petreolle" <spetreolle(a)yahoo.fr>
wrote:
>   Does the VM have ACPI enabled ? Try to turn it off
> then.
>  
>   
>  Kind regards,
>  Sylvain Petreolle
>  
>   
-- 
With best regards
Caemyr

[Sylvain Petreolle]

Indeed agreed , the bug should be fixed.
 
Kind regards,
Sylvain Petreolle


>  ________________________________
> De : "caemyr(a)myopera.com" <caemyr(a)myopera.com>
> À : Sylvain Petreolle <spetreolle(a)yahoo.fr>fr>; ReactOS Development List
> <ros-dev(a)reactos.org>
> Envoyé le : Lundi 15 Août 2011 12h24
> Objet : Re: [ros-dev] Re :  Another regression
>
> Shouldn't the bug be fixed instead of workaround?
>
> On Mon, 15 Aug 2011 10:37 +0100, "Sylvain Petreolle" <spetreolle(a)yahoo.fr>
> wrote:
> >   Does the VM have ACPI enabled ? Try to turn it
> > off then.
> >  
> >   
> >  Kind regards,
> >  Sylvain Petreolle
> >  
> >   
> -- 
> With best regards
> Caemyr
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>

[Cameron Gutman]

This isn't even an ACPI bug to begin with. It's a bug with the CMake build.
Halacpi.dll (and all the other alternate HALs) aren't even built on CMake!

A glance at the log shows that it can't even find the HAL on the CD:
(P:\Trunk_slave\x86_CMake\build\base\setup\usetup\filesup.c:129) NtOpenFile failed:
c0000034, \Device\CdRom0\reactos\system32\halacpi.dll
I took a look at the CMake file in HAL but I wasn't sure how to proceed. Any fixes to
get this working are welcome.


Regards,
Cameron

On Aug 15, 2011, at 7:23 AM, Sylvain Petreolle wrote:

>   Indeed agreed , the bug should be fixed.
>   
>  Kind regards,
>  Sylvain Petreolle
>  De : "caemyr(a)myopera.com" <caemyr(a)myopera.com>
>  À : Sylvain Petreolle <spetreolle(a)yahoo.fr>fr>; ReactOS Development List
> <ros-dev(a)reactos.org>
>  Envoyé le : Lundi 15 Août 2011 12h24
>  Objet : Re: [ros-dev] Re : Another regression
>  
>  Shouldn't the bug be fixed instead of workaround?
>  
>  On Mon, 15 Aug 2011 10:37 +0100, "Sylvain Petreolle"
> <spetreolle(a)yahoo.fr> wrote:
> >   Does the VM have ACPI enabled ? Try to turn it
> > off then.
> >  
> >   
> >  Kind regards,
> >  Sylvain Petreolle
> >  
> >   
>  -- 
>  With best regards
>  Caemyr
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Amine Khaldi]

>   I took a look at the CMake file in HAL but I
> wasn't sure how to 
>  proceed. Any fixes to get this working are welcome. 
As r53264 clearly demonstrates,
that required advanced copy paste and 
English skills to figure out the meaning of the CMake scripts, in order 
to fix this "bug".

Regards,
Amine.

Yet another regression. Revision
http://svn.reactos.org/svn/reactos?view=rev&revision=53257 breaks up VBox testcd
runtime, due to pool corruption bugchecks. Its been 37h since it started. Can we have it
fixed or reverted? This is our sole working testbot, so it could be important.

I know that introducing new features to ReactOS is cool, but unfortunately, once again we,
the testers, are left alone with the bugs introduced by them. Its kinda hard to me, as I
often feel as some kind of oppressor, pointing out that something fails, only to hear back
that its my or no one's problem.

Yes, i am aware that i could probably avert it by disabling ACPI in testbot's VM. I am
not going to do this for at least two reasons:
- if i do so, everyone will feel contempt once more and forget about this, until it crops
up sometime in the future, requiring a regtesting then. Now guess who will be asked to do
so, and why that person is going to be a tester;
- if this ACPI implementation is mature enough to be ENABLED by DEFAULT, it should at
least work in VBOX. This is why i did patchbot for, but unfortunately, too many prefer to
commit to trunk (and not fix it up then);

No testman's results? Anyone cares? Naah, lets have a few more features. Just when
would you like to have a new release? Until end of the year? Forget it...

Best regards

[Cameron Gutman]

ACPI does work on VirtualBox. I performed the majority of my testing on VirtualBox. Also,
I need a stack trace from that crash to have any clue where the corruption is (still not
much of one). I have had indications of a pool corruption bug in ACPI and I need as many
logs as possible to try to track it down.

Regards,
Cameron

On Aug 16, 2011, at 4:04 PM, caemyr(a)myopera.com wrote:

>   Yet another regression. Revision
> http://svn.reactos.org/svn/reactos?view=rev&revision=53257 breaks up VBox testcd
> runtime, due to pool corruption bugchecks. Its been 37h since it started. Can we have it
> fixed or reverted? This is our sole working testbot, so it could be important.
>  
>  I know that introducing new features to ReactOS is cool, but unfortunately, once again
> we, the testers, are left alone with the bugs introduced by them. Its kinda hard to me, as
> I often feel as some kind of oppressor, pointing out that something fails, only to hear
> back that its my or no one's problem.
>  
>  Yes, i am aware that i could probably avert it by disabling ACPI in testbot's VM. I
> am not going to do this for at least two reasons:
>  - if i do so, everyone will feel contempt once more and forget about this, until it crops
> up sometime in the future, requiring a regtesting then. Now guess who will be asked to do
> so, and why that person is going to be a tester;
>  - if this ACPI implementation is mature enough to be ENABLED by DEFAULT, it should at
> least work in VBOX. This is why i did patchbot for, but unfortunately, too many prefer to
> commit to trunk (and not fix it up then);
>  
>  No testman's results? Anyone cares? Naah, lets have a few more features. Just when
> would you like to have a new release? Until end of the year? Forget it...
>  
>  Best regards
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

For that we need Colin to explain Aleksiej how is linux sysreg doing backtrace with
/KDSERIAL enabled (which seems to be the problem for vbox sysreg).


On Tue, 16 Aug 2011 16:35 -0400, "Cameron Gutman"
<cameron.gutman(a)reactos.org> wrote:
>   ACPI does work on VirtualBox. I performed the majority
> of my testing on
>  VirtualBox. Also, I need a stack trace from that crash to have any clue
>  where the corruption is (still not much of one). I have had indications
>  of a pool corruption bug in ACPI and I need as many logs as possible to
>  try to track it down.
>  
>  Regards,
>  Cameron 
-- 
With best regards
Caemyr

[Colin Finck]

caemyr(a)myopera.com wrote:
>   For that we need Colin to explain Aleksiej how is
> linux sysreg doing backtrace with /KDSERIAL enabled 
In the loop which reads from the serial buffer:

if (strstr(Buffer, "kdb:>"))
{
     ++KdbgHit;

     if (KdbgHit == 1)
     {
         /* We hit Kdbg for the first time, get a backtrace for the log */
         safewrite(ttyfd, "bt\r", 3);
         continue;
     }
     else
     {
         /* We hit it yet another time, give up here */
         [Reboot the VM and let rosautotest continue with the next test]
     }
}
else if (strstr(Buffer, "--- Press q"))
{
     /* Send Return to get more data from Kdbg */
     safewrite(ttyfd, "\r", 1);
     continue;
}


And yes, /KDSERIAL is the key here. All these commands are sent over the 
serial line.
I don't remember how it's done exactly, but bootcdregtest should always 
boot into "ReactOS (RosDbg)", which includes the /KDSERIAL parameter.


- Colin

[James Tabor]

Head does this on 2nd boot. Qemu 0.11.1


(ntoskrnl/kd/kdio.c:322) ReactOS 0.4-SVN (Build 20110818-r53292)
<Snip>
(base/services/umpnpmgr/umpnpmgr.c:2943) Device enumerated:
ACPI\PNP0303\2&ccb86d17&0000
(ntoskrnl/io/pnpmgr/pnpmgr.c:2051) ACPI\ThermalZone\2&ccb86d17&0000 is
using parent bus driver (acpi)
(ntoskrnl/io/pnpmgr/pnpmgr.c:2051) ACPI\Processor\2&ccb86d17&0000 is
using parent bus driver (acpi)
(ntoskrnl/io/pnpmgr/pnpmgr.c:2051) ACPI\FixedButton\2&ccb86d17&0000 is
using parent bus driver (acpi)
(ntoskrnl/io/pnpmgr/pnpmgr.c:3609) IRP_MN_QUERY_PNP_DEVICE_STATE
failed with status 0xc00000bb
(ntoskrnl/io/pnpmgr/pnpmgr.c:3609) IRP_MN_QUERY_PNP_DEVICE_STATE
failed with status 0xc00000bb
(ntoskrnl/io/pnpmgr/pnpmgr.c:3609) IRP_MN_QUERY_PNP_DEVICE_STATE
failed with status 0xc00000bb
(base/services/umpnpmgr/umpnpmgr.c:2943) Device enumerated:
ACPI\PNP0B00\2&ccb86d17&0000
(base/services/umpnpmgr/umpnpmgr.c:2943) Device enumerated: ACPI\PNP0A03\0
(base/services/umpnpmgr/umpnpmgr.c:2943) Device enumerated:
ACPI\Processor\2&ccb86d17&0000
(base/services/umpnpmgr/umpnpmgr.c:2943) Device enumerated:
ACPI\FixedButton\2&ccb86d17&0000
WARNING:  LdrUnloadAlternateResourceModule at
dll/ntdll/ldr/ldrapi.c:1546 is UNIMPLEMENTED!
Assertion 'GuardedMutex->Owner != Thread' failed at
ntoskrnl/include/internal/ke_x.h line 1596
Entered debugger on embedded INT3 at 0x0008:0x8090375e.
kdb:> bt
Eip:
<ntoskrnl.exe:10375f (lib/rtl/i386/debug_asm.S:32 (DbgBreakPoint))>
Frames:
<ntoskrnl.exe:c2d89 (ntoskrnl/include/internal/ke_x.h:1596
(MmNotPresentFault@12))>
<ntoskrnl.exe:c39d0 (ntoskrnl/mm/mmfault.c:275 (MmAccessFault@16))>
<ntoskrnl.exe:6b42 (ntoskrnl/ke/i386/traphdlr.c:1232 (@KiTrap0EHandler@4))>
<ntoskrnl.exe:fda74 (ntoskrnl/ke/i386/trap.s:0 (KiTrap0E))>
<ntoskrnl.exe:c6267 (ntoskrnl/mm/rmap.c:305 (MmInsertRmap@12))>
<ntoskrnl.exe:d03cc (ntoskrnl/mm/section.c:1795
(MmNotPresentFaultSectionView@16))>
<ntoskrnl.exe:c308e (ntoskrnl/mm/mmfault.c:180 (MmNotPresentFault@12))>
<ntoskrnl.exe:c39d0 (ntoskrnl/mm/mmfault.c:275 (MmAccessFault@16))>
<ntoskrnl.exe:6b42 (ntoskrnl/ke/i386/traphdlr.c:1232 (@KiTrap0EHandler@4))>
<ntoskrnl.exe:fda74 (ntoskrnl/ke/i386/trap.s:0 (KiTrap0E))>
<rpcrt4.dll:23a48>
<ntdll.dll:73b8>
<ntdll.dll:427f>
<kernel32.dll:9cca>
<msvcrt.dll:c357>
<msvcrt.dll:c381>
<rundll32.exe:1cac>
<rundll32.exe:1cf8>
<kernel32.dll:c5ca>
--- Press q to abort, any other key to continue ---
<00000000>
kdb:>

After second retry, it installed, reboot and running tests.

[James Tabor]

I'm running tests here after makex bootcdregtest. on qemu... I had one
fault that I lost, after the next retry this,


(dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name
C:\ReactOS\system32\inetcomm.dll (76140000 -> 01612000)
(dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL:
C:\ReactOS\System32\comctl32.dll
fixme:(dll/win32/wintrust/register.c:1161) stub
(dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name
C:\ReactOS\system32\mshtml.dll (76650000 -> 01612000)
(dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL:
C:\ReactOS\System32\setupapi.dll
(ntoskrnl/se/semgr.c:299) SidInToken Calls: 30000

*** Fatal System Error: 0x00000019
                       (0x00000005,0xB0190B28,0x000000F0,0xB0190B10)

Entered debugger on embedded INT3 at 0x0008:0x80903734.
kdb:> bt
Eip:
<ntoskrnl.exe:103735 (lib/rtl/i386/debug_asm.S:39
(RtlpBreakWithStatusInstruction))>
Frames:
<ntoskrnl.exe:ad96 (ntoskrnl/ke/bug.c:1110 (KeBugCheckWithTf@24))>
<ntoskrnl.exe:aee1 (ntoskrnl/ke/bug.c:1438 (KeBugCheckEx@20))>
<ntoskrnl.exe:9f1ed (ntoskrnl/mm/ARM3/expool.c:237 (ExpCheckPoolHeader@4))>
<ntoskrnl.exe:9f334 (ntoskrnl/mm/ARM3/expool.c:265 (ExpCheckPoolBlocks@4))>
<ntoskrnl.exe:9f5ca (ntoskrnl/mm/ARM3/expool.c:804 (ExFreePoolWithTag@8))>
<ntoskrnl.exe:9fb6f (ntoskrnl/mm/ARM3/expool.c:946 (ExFreePool@4))>
<ntoskrnl.exe:c0a3b (ntoskrnl/mm/freelist.c:548 (MmDereferencePage@4))>
<ntoskrnl.exe:c0628 (ntoskrnl/mm/balance.c:136 (MmReleasePageMemoryConsumer@8))>
<ntoskrnl.exe:19b7f (ntoskrnl/cc/view.c:861 (CcFreeCachePage))>
<ntoskrnl.exe:c239b (ntoskrnl/mm/marea.c:756 (MmFreeMemoryArea@16))>
<ntoskrnl.exe:195b3 (ntoskrnl/cc/view.c:910 (CcRosInternalFreeCacheSegment))>
<ntoskrnl.exe:1bc24 (ntoskrnl/cc/view.c:383 (CcRosTrimCache))>
<ntoskrnl.exe:c0150 (ntoskrnl/mm/balance.c:366 (MiBalancerThread@4))>
<ntoskrnl.exe:f1152 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))>
<ntoskrnl.exe:5bce (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))>
<ntoskrnl.exe:f10ee (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))>
<fce59d80>
<ntoskrnl.exe:154d9 (ntoskrnl/ke/wait.c:527 (KeWaitForSingleObject@20))>
<ntoskrnl.exe:c3ee2 (ntoskrnl/mm/mminit.c:292 (MmMpwThreadMain@4))>
<ntoskrnl.exe:f1152 (ntoskrnl/ps/thread.c:156
(PspSystemThreadStartup@8))>--- Press q to abort, any other key to
continue ---

<ntoskrnl.exe:5bce (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))>
<ntoskrnl.exe:f10ee (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))>
<657a2f33>
Couldn't access memory at 0x4D524133!
kdb:>

Then again retry and now the regtest it running.....

On Tue, Aug 16, 2011 at 3:35 PM, Cameron Gutman
&lt;cameron.gutman(a)reactos.org&gt; wrote:
>   ACPI does work on VirtualBox. I performed the majority
> of my testing on VirtualBox. Also, I need a stack trace from that crash to have any clue
> where the corruption is (still not much of one). I have had indications of a pool
> corruption bug in ACPI and I need as many logs as possible to try to track it down.
>
>  Regards,
>  Cameron
>

[Bernd Blaauw]

Op 16-8-2011 22:35, Cameron Gutman schreef:
>   ACPI does work on VirtualBox. I performed the majority
> of my testing on VirtualBox. Also, I need a stack trace from that crash to have any clue
> where the corruption is (still not much of one). I have had indications of a pool
> corruption bug in ACPI and I need as many logs as possible to try to track it down.
Thunderbird mail searches aren't that great, but I remember reading a 
message on the list somewhere about the request for feedback and 
bugreports on ACPI HAL and having it assigned to someone I can't recall 
right now (Cameron Gutman?).

Testing results can be found in forums at:
http://www.reactos.org/forum/viewtopic.php?f=2&t=9488

short version:
* ACPI HAL reports 2MB lower amount of memory compared to non-ACPI HAL
   (at bootup). Cosmetic issue or sign of trouble?
* Multiple/double device manager entries all over the place
   (r53421 reduces that to floppy/keyboard/mouse and COM1, yay!)
* 25+ listings of each of ACPI.SYS and PCI.SYS being loaded at bootup
   (the debug option of freeldr, thus no bootlogo)
* Increased memory requirements. r53421 boots with 72MB in p3 though

Goodluck sorting the last bits out sometime :)

PS: what's an ATA-44 controller?