Good afternoon gentlemen...
Seems the list server has gone on a vacation.
Still waiting on the digest where Hermes added to Thomas answer..
Anyway Hermes pasted his answer to my mailbox (thank you) and so..
One more step is required in addition to the answers from Thomas and
Hermes..
A small patch in 'base/setup/usetup/bootsup.c', which contains the code
that writes 'freeldr.ini' to the HD during install. Without patching in
the desired
COM port there, trace is lost after ROS installation reboots from HD.
Perhaps we should have a wiki page to cover this ?
And/or perhaps we should make it easier to make this mod,
by moving the hard coded strings from bootsup.c into
an ini file or whatever ?
Anyway, I got my install trace, and posted a clip concerning
the Gecko breakage to CORE-12011.
Best Regards
L.
Hello,
Let me invite you to the monthly status meeting taking place this
Thursday, 29th of September, 19:00 UTC.
IRC service will only be started shortly before the meeting. Your
participation passwords and server address will be emailed to you
shortly before the meeting starts, and they are going to be different
once again as they are not stored in any database. Hopefully it's not
much of inconvenience.
Or we'll do it in #reactos-meeting on Freenode, depeonds on our admins.
Please send agenda proposals to me before the meeting so we don't waste
time trying to setup the agenda directly during the meeting.
Regards,
Aleksey Bragin
Thanks Thomas,
Yes and No...
I added Options=/DEBUG /DEBUGPORT=COM2 /BAUDRATE=115200 /SOS / KDSERIAL
which ended up on the BootCD all right, but it seems KD is never brought
in, or doesn't
use the settings from freeldr.ini on the BootCD, so no trace :/
(Ok, /SOS was perhaps a bit over the top, but anyway.)
Do you know where the source is for what becomes 'freeldr.ini' on the HD
after installation? If I can modify that, I can at least get a trace on
the later
phases of installation, after ROS boots from HD.
Then I might get a hint on why the Wine Gecko installer is broken.
(It waits forever for whatever it might be.. Lucky it can be canceled.)
Speaking of which, shouldn't the Wine Gecko installer be included
in the RosApps list so one can install it later? ATM it isn't.
Best Regards
L.
On 2016-09-27 19.00, Thomas Faber <thomas.faber(a)reactos.org> wrote:
> You should be able to simply add an
> Options=...
> line to the [Setup] section in boot/bootdata/bootcd.ini to modify
> the setup's freeldr options. That file becomes freeldr.ini in the root
> dir of the BootCD.
>
>
> On 2016-09-27 12:21, Love Nystrom wrote:
>> >Good afternoon gentlemen..
>> >
>> >Can anyone tell me at what point during ROS installation KD becomes
>> >operative?
>> >And if there is a way to change the default KD COM port from COM1 to COM2
>> >in order to trace KD output during installation?
>> >
>> >(I run my ROS tests on VMware with a com0com connection from ReactOS COM2
>> >to my host machine, which works fine after install is complete and I can
>> >edit freeldr.ini,
>> >but I'd like to be able to collect KD output during installation as well.)
>> >
>> >(COM1 is not an option, since it's a physical port on both host and guest.)
>> >
>> >Do I have to patch KD itself ?
>> >
>> >Best Regards
>> >L.
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]
Good afternoon gentlemen..
Can anyone tell me at what point during ROS installation KD becomes
operative?
And if there is a way to change the default KD COM port from COM1 to COM2
in order to trace KD output during installation?
(I run my ROS tests on VMware with a com0com connection from ReactOS COM2
to my host machine, which works fine after install is complete and I can
edit freeldr.ini,
but I'd like to be able to collect KD output during installation as well.)
(COM1 is not an option, since it's a physical port on both host and guest.)
Do I have to patch KD itself ?
Best Regards
L.
Agreed..
When the assignment and assert are separated by a call
of X distance, the assert is certainly warranted.
Just not as it stands in ke_x.h
Perhaps you could factorize as suggested, Dmitri?
Best regards
L.
On 2016-09-26 10.28, ros-dev-request(a)reactos.org wrote:
> Rationale is simple:
>
> The real headers contain a KeEnterCriticalRegionThread function, which
> has this assert, and a KeEnterCriticalRegion function, which calls
> that function with KeGetCurrentThread() at input. This is an
> optimization such that if you already have the current thread of
> interest somewhere, you can call KeEnterCriticalRegionThread and avoid
> reading from FS or GS again. ReactOS combines these two functions in
> one, and as such the ASSERT appears pointless. Factoring the functions
> would've been the correct approach -- not removing the ASSERT.
>
> Best regards,
> Alex Ionescu
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]
Agreed..
When the assignment and assert are separated by a call
of X distance, the assert is certainly warranted.
Just not as it stands in ke_x.h
Perhaps you could factorize as suggested, Dmitri?
Best regards
L.
On 2016-09-26 10.28, ros-dev-request(a)reactos.org wrote:
> Rationale is simple:
>
> The real headers contain a KeEnterCriticalRegionThread function, which
> has this assert, and a KeEnterCriticalRegion function, which calls
> that function with KeGetCurrentThread() at input. This is an
> optimization such that if you already have the current thread of
> interest somewhere, you can call KeEnterCriticalRegionThread and avoid
> reading from FS or GS again. ReactOS combines these two functions in
> one, and as such the ASSERT appears pointless. Factoring the functions
> would've been the correct approach -- not removing the ASSERT.
>
> Best regards,
> Alex Ionescu
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]
Rationale is simple:
The real headers contain a KeEnterCriticalRegionThread function, which has
this assert, and a KeEnterCriticalRegion function, which calls that
function with KeGetCurrentThread() at input. This is an optimization such
that if you already have the current thread of interest somewhere, you can
call KeEnterCriticalRegionThread and avoid reading from FS or GS again.
ReactOS combines these two functions in one, and as such the ASSERT appears
pointless. Factoring the functions would've been the correct approach --
not removing the ASSERT.
Best regards,
Alex Ionescu
On Sun, Sep 25, 2016 at 8:13 PM, Love Nystrom <love.nystrom(a)gmail.com>
wrote:
> I don't want to trod on anyone's tail, but
> assigning _Thread = KeGetCurrentThread(), and
> then asserting _Thread == KeGetCurrentThread()
> on the next line does seem excessively myopic, yes ?
>
> Unless you expect KeGetCurrentThread() to be fubar
> and return rand(), in which case the assert should be removed
> when KeGetCurrentThread() gets it's head on straight.
>
> As to the talent, or lack thereof, of MS programmers,
> we might talk about it if we ever have a table with some
> beer on it between us.
>
> They're not *all* wrong.. no ;)
> L.
>
> On 2016-09-24 23.23, ros-dev-request(a)reactos.org wrote:
>
> Subject:
> Re: [ros-dev] [ros-diffs] [dchapyshev] 72787: [NTOSKRNL] Remove unneeded
> sanity checks
>
> From:
> Alex Ionescu <ionucu(a)videotron.ca> <ionucu(a)videotron.ca>
>
> Date:
> 2016-09-24 21.29
>
> To:
> ReactOS Development List <ros-dev(a)reactos.org> <ros-dev(a)reactos.org>
>
> CC:
> Linda Wang <ros-diffs(a)reactos.org> <ros-diffs(a)reactos.org>
>
> Thanks for removing stuff that exists in the NT kernel as sanity
> checks -- the entire MS dev team must be wrong, thanks for correcting
> them all :)
>
> Make sure not to ask "anyone can explain these checks? they seem
> useless to me" when removing stuff like this.
> Best regards,
> Alex Ionescu
>
>
> On Sat, Sep 24, 2016 at 2:30 AM, <dchapyshev(a)svn.reactos.org> <dchapyshev(a)svn.reactos.org> wrote:
>
> > Author: dchapyshev> Date: Sat Sep 24 09:30:06 2016> New Revision: 72787>> URL: http://svn.reactos.org/svn/reactos?rev=72787&view=rev> Log:> [NTOSKRNL] Remove unneeded sanity checks>> Modified:> trunk/reactos/ntoskrnl/include/internal/ke_x.h>> Modified: trunk/reactos/ntoskrnl/include/internal/ke_x.h> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/…> ==============================================================================> --- trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] (original)> +++ trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] Sat Sep 24 09:30:06 2016> @@ -25,7 +25,6 @@> \> /* Sanity checks */ \> ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \> - ASSERT(_Thread == KeGetCurrentThread()); \> ASSERT((_Thread->SpecialApcDisable <= 0) && \> (_Thread->SpecialApcDisable != -32768)); \> \> @@ -42,7 +41,6 @@> \> /* Sanity checks */ \> ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \> - ASSERT(_Thread == KeGetCurrentThread()); \> ASSERT(_Thread->SpecialApcDisable < 0); \> \> /* Leave region and check if APCs are OK now */ \> @@ -66,7 +64,6 @@> PKTHREAD _Thread = KeGetCurrentThread(); \> \> /* Sanity checks */ \> - ASSERT(_Thread == KeGetCurrentThread()); \> ASSERT((_Thread->KernelApcDisable <= 0) && \> (_Thread->KernelApcDisable != -32768)); \> \> @@ -82,7 +79,6 @@> PKTHREAD _Thread = KeGetCurrentThread(); \> \> /* Sanity checks */ \> - ASSERT(_Thread == KeGetCurrentThread()); \> ASSERT(_Thread->KernelApcDisable < 0); \> \> /* Enable Kernel APCs */ \>>
>
>
> --
> There is one thing stronger than all the armies in the world,
> and that's 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
>
>
I don't want to trod on anyone's tail, but
assigning _Thread = KeGetCurrentThread(), and
then asserting _Thread == KeGetCurrentThread()
on the next line does seem excessively myopic, yes ?
Unless you expect KeGetCurrentThread() to be fubar
and return rand(), in which case the assert should be removed
when KeGetCurrentThread() gets it's head on straight.
As to the talent, or lack thereof, of MS programmers,
we might talk about it if we ever have a table with some
beer on it between us.
They're not *all* wrong.. no ;)
L.
On 2016-09-24 23.23, ros-dev-request(a)reactos.org wrote:
> Subject:
> Re: [ros-dev] [ros-diffs] [dchapyshev] 72787: [NTOSKRNL] Remove
> unneeded sanity checks
> From:
> Alex Ionescu <ionucu(a)videotron.ca>
> Date:
> 2016-09-24 21.29
>
> To:
> ReactOS Development List <ros-dev(a)reactos.org>
> CC:
> Linda Wang <ros-diffs(a)reactos.org>
>
>
> Thanks for removing stuff that exists in the NT kernel as sanity
> checks -- the entire MS dev team must be wrong, thanks for correcting
> them all:)
>
> Make sure not to ask "anyone can explain these checks? they seem
> useless to me" when removing stuff like this.
> Best regards,
> Alex Ionescu
>
>
> On Sat, Sep 24, 2016 at 2:30 AM,<dchapyshev(a)svn.reactos.org> wrote:
>> >Author: dchapyshev
>> >Date: Sat Sep 24 09:30:06 2016
>> >New Revision: 72787
>> >
>> >URL:http://svn.reactos.org/svn/reactos?rev=72787&view=rev
>> >Log:
>> >[NTOSKRNL] Remove unneeded sanity checks
>> >
>> >Modified:
>> > trunk/reactos/ntoskrnl/include/internal/ke_x.h
>> >
>> >Modified: trunk/reactos/ntoskrnl/include/internal/ke_x.h
>> >URL:http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/inter…
>> >==============================================================================
>> >--- trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] (original)
>> >+++ trunk/reactos/ntoskrnl/include/internal/ke_x.h [iso-8859-1] Sat Sep 24 09:30:06 2016
>> >@@ -25,7 +25,6 @@
>> > \
>> > /* Sanity checks */ \
>> > ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \
>> >- ASSERT(_Thread == KeGetCurrentThread()); \
>> > ASSERT((_Thread->SpecialApcDisable <= 0) && \
>> > (_Thread->SpecialApcDisable != -32768)); \
>> > \
>> >@@ -42,7 +41,6 @@
>> > \
>> > /* Sanity checks */ \
>> > ASSERT(KeGetCurrentIrql() <= APC_LEVEL); \
>> >- ASSERT(_Thread == KeGetCurrentThread()); \
>> > ASSERT(_Thread->SpecialApcDisable < 0); \
>> > \
>> > /* Leave region and check if APCs are OK now */ \
>> >@@ -66,7 +64,6 @@
>> > PKTHREAD _Thread = KeGetCurrentThread(); \
>> > \
>> > /* Sanity checks */ \
>> >- ASSERT(_Thread == KeGetCurrentThread()); \
>> > ASSERT((_Thread->KernelApcDisable <= 0) && \
>> > (_Thread->KernelApcDisable != -32768)); \
>> > \
>> >@@ -82,7 +79,6 @@
>> > PKTHREAD _Thread = KeGetCurrentThread(); \
>> > \
>> > /* Sanity checks */ \
>> >- ASSERT(_Thread == KeGetCurrentThread()); \
>> > ASSERT(_Thread->KernelApcDisable < 0); \
>> > \
>> > /* Enable Kernel APCs */ \
>> >
>> >
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]