reactos-kernel

Re: [ros-kernel] Crash on boot w/ no CDROM

[Joseph G. <gal...@va...>]

> > My apologies.  This did fix the bug; it's just that there
> > is another similar one someplace.
>
> Unloading a driver (or module) is still a risky thing because a) the
driver
> object and its corresponding module are not attached to one another in any
> way and b) the driver object does not do any cleanup by itself yet. This
> will have to be fixed.
>
> > I believe we are now crashing in the call to
> > IopFreeDeviceNode() from LdrInitializeBootStartDriver().
> > It appears to be on the line:
> >
> >   RtlFreeUnicodeString(&DeviceNode->ServiceName);
> >
> > in IopFreeDeviceNode().  Hope this helps, cause I'm
> > about out of time for today :-)
>
> I already found this bug yesterday. It should be fixed in my local source
> tree.

Great!

I'm happy now that I can boot again :-)

Hope I haven't been stepping on toes or anything --
I'm very excited about this project.  It looks
to be a lot of fun.

- Joseph

Re: [ros-kernel] Crash on boot w/ no CDROM

[Eric K. <ek...@rz...>]

"Joseph Galbraith" <gal...@va...> wrote:

> My apologies.  This did fix the bug; it's just that there
> is another similar one someplace.

Unloading a driver (or module) is still a risky thing because a) the driver
object and its corresponding module are not attached to one another in any
way and b) the driver object does not do any cleanup by itself yet. This
will have to be fixed.

> I believe we are now crashing in the call to
> IopFreeDeviceNode() from LdrInitializeBootStartDriver().
> It appears to be on the line:
>
>   RtlFreeUnicodeString(&DeviceNode->ServiceName);
>
> in IopFreeDeviceNode().  Hope this helps, cause I'm
> about out of time for today :-)

I already found this bug yesterday. It should be fixed in my local source
tree.

> Also, I notice that when we call IopInitializeDriver() from
> IopInitializeService(), we also call IopInitializeDevice();
> IopInitializeDriver() seems to also call InitializeDevice()
> meaning in that particular case it would be done twice?

This is another part of the current driver mess. Needs to be cleaned up too.

Thanks for your hints! I'm currently reworking the load routine for system
start drivers. When this is done I will have a look at driver unloading.

Regards,
Eric

Re: [ros-kernel] commit messages

[David W. <we...@cw...>]

On Tue, Jun 11, 2002 at 07:34:07PM -0700, Rex Jolliff wrote:
> I changed sendmail on mok to relay to .lvcm.com.  Now I get a message
> accepted, but still dont see a message from the list.  I'm thinking the 451
> might still be occuring, but happening on the .lvcm.com server now.
>
No messages are waiting to be approved. Could sendmail be configured so 
commit messages are sent with a different domain?
 
> Several people have rather large mailboxes on mok by the way.  perhaps
> you people can delete old messages?
> 
I didn't even realise cvs users could still log in.

[ros-kernel] Patch: don't crash if DriverEntry fails

[Joseph G. <gal...@va...>]

io/device.c
io/driver.c
ldr/loader.c

* Call RtlCreateUnicodeString() instead of
  RtlInitUnicodeString() when initializing
  the DeviceNode->ServiceName, since
  IopFreeDeviceNode() will use RtlFreeUnicodeString()
  on it.

* Call ObDerefernceObject() instead of
  ExFreePool() to release the DeviceObject
  if DriverEntry fails. (Thanks, Eric.)

Thanks,

- Joseph

RE: [ros-kernel] Patch: Teach freeldr registry about multi andexpanded types

[Brian P. <br...@sg...>]

I have a few questions about this:

reactos.c line 193:
rc = RegQueryValue(hGroupKey, "List", NULL, (PUCHAR)&ValueBuffer,
&BufferSize);

Shouldn't that be:
rc = RegQueryValue(hGroupKey, "List", NULL, (PUCHAR)ValueBuffer,
&BufferSize);

And the same thing in meminit.c line 64. Since BiosMemoryMap is a
pointer to the array, you are passing in the address of the pointer to
the array and casting it to type PBIOS_MEMORY_MAP.

I also noticed that this patch changes all the function prototypes from
ULONG GetBiosMemoryMap(BIOS_MEMORY_MAP BiosMemoryMap[32]); to ULONG
GetBiosMemoryMap(PBIOS_MEMORY_MAP BiosMemoryMap); Now this would
normally be fine except that that function returns an array of exactly
32 items since the size of the memory map is not known before the
function call.

Also the %ld in the strings passed to printf() is not supported in the
printf() function included with freeldr. It should probably be updated.

Thanks for the patch, every little bit helps.

Brian


> -----Original Message-----
> From: rea...@li...
[mailto:reactos-kernel-
> ad...@li...] On Behalf Of Casper Hornstrup
> Sent: Tuesday, June 11, 2002 1:59 PM
> To: rea...@li...
> Subject: Re: [ros-kernel] Patch: Teach freeldr registry about multi
> andexpanded types
> 
> tir, 2002-06-11 kl. 21:07 skrev Joseph Galbraith:
> > freeldr\freeldr\reactos\reghive.c
> >
> >     Merge in smarts about multi: and
> >     expand: data types from the ntoskrnl
> >     version of the registry import
> >     functions so that freeldr can boot
> >     the OS again.
> >
> > Joseph
> 
> Applied. Thanks for the patch.
> 
> Casper
> 
> 
> 
> _______________________________________________________________
> 
> Multimillion Dollar Computer Inventory
> Live Webcast Auctions Thru Aug. 2002 -
> http://www.cowanalexander.com/calendar
> 
> 
> 
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

Re: [ros-kernel] Crash on boot w/ no CDROM

[Joseph G. <gal...@va...>]

> > > I get "No unclaimed devices!" from cdrom.c
> > > and then the system bugchecks in device.c
> > > calling ExFreePool(DriverObject) claiming
> > > that  the DriverObject is a non-allocated
> > > address (magic c01aeee5)
> > 
> > Could you replace this 'ExFreePool(DriverObject)' by
> > 'ObDereferenceObject(DriverObject)'. This should fix the bug.
> 
> No luck.  I still get ExFreePool of non-allocated address --
> though now the address of the DriverObject is 0xc01aefe3
> and the address listed by ExFreePool is c007ebb0 (is this
> due to the object header?)
> 
> Additionally, the magic is now 0.

My apologies.  This did fix the bug; it's just that there
is another similar one someplace.

I believe we are now crashing in the call to
IopFreeDeviceNode() from LdrInitializeBootStartDriver().
It appears to be on the line:

  RtlFreeUnicodeString(&DeviceNode->ServiceName);

in IopFreeDeviceNode().  Hope this helps, cause I'm
about out of time for today :-)

Also, I notice that when we call IopInitializeDriver() from
IopInitializeService(), we also call IopInitializeDevice();
IopInitializeDriver() seems to also call InitializeDevice()
meaning in that particular case it would be done twice?

- Joseph

Re: AW: [ros-kernel] NtDuplicateObject

[KJK::Hyperion <no...@li...>]

At 21.57 11/06/2002, you wrote:
> > > I have quickly looked at the way NtDuplicateObject works.
> > > Maybe it will help you.
> > Thanks for your help; ReactOS has actually already implemented this
> > function but I was trying to understand the restriction to inheritable
> > handles. I'll remove this check.
>DuplicateHandle from kernel32 and some calls to NtDuplicateHandle from 
>kernel32\create.c needs this check. If the check is removed in 
>NtDuplicateHandle, the check must added in this functions.

I don't understand why. What's the matter with duplicating inheritable handles?

Re: [ros-kernel] commit messages

[Rex J. <re...@lv...>]

At 11:35 PM 6/11/02 +0000, you wrote:
>On Mon, Jun 10, 2002 at 04:21:25PM -0700, Rex Jolliff wrote:
> >
>I don't think so; in this case either you would get an email back
>saying you weren't subscribed or I (the administrator) would get one.
>Perhaps it is some sort of DNS problem? Does mok have an MX record?

I changed sendmail on mok to relay to .lvcm.com.  Now I get a message
accepted, but still dont see a message from the list.  I'm thinking the 451
might still be occuring, but happening on the .lvcm.com server now.

Several people have rather large mailboxes on mok by the way.  perhaps
you people can delete old messages?


Rex Jolliff
re...@lv...

Re: [ros-kernel] commit messages

[Rex J. <re...@lv...>]

At 11:35 PM 6/11/02 +0000, you wrote:
>On Mon, Jun 10, 2002 at 04:21:25PM -0700, Rex Jolliff wrote:
> >
> > in the maillog for mok, I see the following error reported from commits:
> >
> > Jun  9 05:58:56 mok sendmail[10491]: xxx:
> >    to=...@li...,
> >    ctladdr=bpalmer (1007/200), delay=12:54:57,
> >    xdelay=00:03:00, mailer=esmtp, pri=1200407,
> >    relay=externalmx.valinux.com., dsn=4.0.0,
> >    stat=Deferred: 451-Envelope sender verification failed
> >
> > Any idea what the 451 error is?  I'm thinking that the mail addresses on
> > mok are not registered with the mailing list, and cannot therefore post.
> >
>I don't think so; in this case either you would get an email back
>saying you weren't subscribed or I (the administrator) would get one.
>Perhaps it is some sort of DNS problem? Does mok have an MX record?

Good question.  mok is a member of .lvcm.com, but doesnt appear to have
its own MX record (I checked using dig).  I'll have to see if I can get one 
added
for mok.

>_______________________________________________________________
>
>Multimillion Dollar Computer Inventory
>Live Webcast Auctions Thru Aug. 2002 - http://www.cowanalexander.com/calendar
>
>
>
>_______________________________________________
>reactos-kernel mailing list
>rea...@li...
>https://lists.sourceforge.net/lists/listinfo/reactos-kernel

Rex Jolliff
re...@lv...

Re: [ros-kernel] Crash on boot w/ no CDROM

[Joseph G. <gal...@va...>]

> > I get "No unclaimed devices!" from cdrom.c
> > and then the system bugchecks in device.c
> > calling ExFreePool(DriverObject) claiming
> > that  the DriverObject is a non-allocated
> > address (magic c01aeee5)
> 
> Could you replace this 'ExFreePool(DriverObject)' by
> 'ObDereferenceObject(DriverObject)'. This should fix the bug.

No luck.  I still get ExFreePool of non-allocated address --
though now the address of the DriverObject is 0xc01aefe3
and the address listed by ExFreePool is c007ebb0 (is this
due to the object header?)

Additionally, the magic is now 0.

Is this the general rule -- that objects allocated
by ObCreateObject() should be free'd via
ObDereferenceObject()?  I think I've spotted several
other failure cases in my soujurns through the
code that do ExFreePool on the object -- and I
debated with my self which to do in the
NtCreateToken().

Do you think that it is possible that some is
dereferencing the driver object w/o first
having referenced it?

- Joseph

Re: [ros-kernel] commit messages

[David W. <we...@cw...>]

On Mon, Jun 10, 2002 at 04:21:25PM -0700, Rex Jolliff wrote:
> 
> in the maillog for mok, I see the following error reported from commits:
> 
> Jun  9 05:58:56 mok sendmail[10491]: xxx:
>    to=...@li...,
>    ctladdr=bpalmer (1007/200), delay=12:54:57,
>    xdelay=00:03:00, mailer=esmtp, pri=1200407,
>    relay=externalmx.valinux.com., dsn=4.0.0,
>    stat=Deferred: 451-Envelope sender verification failed
> 
> Any idea what the 451 error is?  I'm thinking that the mail addresses on
> mok are not registered with the mailing list, and cannot therefore post.
> 
I don't think so; in this case either you would get an email back 
saying you weren't subscribed or I (the administrator) would get one. 
Perhaps it is some sort of DNS problem? Does mok have an MX record?

Re: [ros-kernel] Crash on boot w/ no CDROM

[Eric K. <ek...@rz...>]

"Joseph Galbraith" <gal...@va...> wrote:


> I get "No unclaimed devices!" from cdrom.c
> and then the system bugchecks in device.c
> calling ExFreePool(DriverObject) claiming
> that  the DriverObject is a non-allocated
> address (magic c01aeee5)

Could you replace this 'ExFreePool(DriverObject)' by
'ObDereferenceObject(DriverObject)'. This should fix the bug.

Eric

[ros-kernel] Crash on boot w/ no CDROM

[Joseph G. <gal...@va...>]

Currently, I'm getting a bugcheck on boot
when the CDROM driver DriverEntry fails
(no CD-rom in my bochs environment.)

I get "No unclaimed devices!" from cdrom.c
and then the system bugchecks in device.c
calling ExFreePool(DriverObject) claiming
that  the DriverObject is a non-allocated
address (magic c01aeee5)

As far as I can tell, this code looks good
to me.  Anyone have any ideas?

Thanks,

Joseph

Re: [ros-kernel] NtDuplicateObject

[David W. <we...@cw...>]

On Tue, Jun 11, 2002 at 09:57:57PM +0200, Hartmut Birr wrote:
> DuplicateHandle from kernel32 and some calls to NtDuplicateHandle from 
> kernel32\create.c needs this check. If the check is removed in 
> NtDuplicateHandle, the check must added in this functions.
> 
I don't see anything in MSDN about this behaviour. Is it documented
somewhere?

Re: [ros-kernel] Patch: Teach freeldr registry about multi and expanded types

[Casper H. <ch...@us...>]

tir, 2002-06-11 kl. 21:07 skrev Joseph Galbraith:
> freeldr\freeldr\reactos\reghive.c
> 
>     Merge in smarts about multi: and
>     expand: data types from the ntoskrnl
>     version of the registry import
>     functions so that freeldr can boot
>     the OS again.
> 
> Joseph

Applied. Thanks for the patch.

Casper

AW: [ros-kernel] NtDuplicateObject

[Hartmut B. <har...@te...>]

> -----Ursprungliche Nachricht-----
> Von:	David Welch [SMTP:we...@cw...]
> Gesendet am:	Dienstag, 11. Juni 2002 22:23
> An:	rea...@li...
> Betreff:	Re: [ros-kernel] NtDuplicateObject
>
> On Tue, Jun 11, 2002 at 03:04:06PM +0200, cra...@mi... wrote:
> > I have quickly looked at the way NtDuplicateObject works.
> > Maybe it will help you.
> >
> Thanks for your help; ReactOS has actually already implemented this
> function but I was trying to understand the restriction to inheritable
> handles. I'll remove this check.

DuplicateHandle from kernel32 and some calls to NtDuplicateHandle from 
kernel32\create.c needs this check. If the check is removed in 
NtDuplicateHandle, the check must added in this functions.

- Hartmut

Re: [ros-kernel] NtDuplicateObject

[<cra...@pl...>]

oh i see :)
so this was much more useful to me than for reactos, no i understand how this function is working :)



On Tue, Jun 11, 2002 at 08:23:25PM +0000, David Welch wrote:
> On Tue, Jun 11, 2002 at 03:04:06PM +0200, cra...@mi... wrote:
> > I have quickly looked at the way NtDuplicateObject works. 
> > Maybe it will help you.
> > 
> Thanks for your help; ReactOS has actually already implemented this 
> function but I was trying to understand the restriction to inheritable
> handles. I'll remove this check.
> 
> _______________________________________________________________
> 
> Multimillion Dollar Computer Inventory
> Live Webcast Auctions Thru Aug. 2002 - http://www.cowanalexander.com/calendar
> 
> 
> 
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

Re: [ros-kernel] CVS Commit: reactos

[David W. <we...@cw...>]

On Tue, Jun 11, 2002 at 06:56:08PM +0200, Hartmut Birr wrote:
> It seems that some programs (gditest) are not able to locate drivers in 
> memory. They load the drivers again. See the attached debug output. 
> Vidport.sys needs some little changes for runing gditest. One for the dirty 
> hack to get csrss's process handle and the other to change interrupt 10h to 
> 6dh, if loadros is used for booting.
> 
This hack will stop working completely once smss supports boot 
applications list. Is there any reason not to have csrss load vidport and 
use a I_AM_CSRSS ioctl to inform it of the address space to use. Is it
possible there are bioses that don't set 6dh, perhaps loadros could copy
the contents of 6dh to 10h since people uses it to boot are already taking 
their lives into their hands with regard to the system state after DOS 
has booted.

Re: [ros-kernel] NtDuplicateObject

[David W. <we...@cw...>]

On Tue, Jun 11, 2002 at 03:04:06PM +0200, cra...@mi... wrote:
> I have quickly looked at the way NtDuplicateObject works. 
> Maybe it will help you.
> 
Thanks for your help; ReactOS has actually already implemented this 
function but I was trying to understand the restriction to inheritable
handles. I'll remove this check.

Re: [ros-kernel] commit messages

[David W. <we...@cw...>]

On Tue, Jun 11, 2002 at 06:17:16PM +0200, Hartmut Birr wrote:
> If I subscribe from the reactos page at SF, I get never a return mail to 
> mok. I get also no return mail if I send a mail from mok to 
> <rea...@li...>. Does mok not like SF?
> 
I can subscribe the address manually.

[ros-kernel] Patch: Teach freeldr registry about multi and expanded types

[Joseph G. <gal...@va...>]

freeldr\freeldr\reactos\reghive.c

    Merge in smarts about multi: and
    expand: data types from the ntoskrnl
    version of the registry import
    functions so that freeldr can boot
    the OS again.

Joseph

[ros-kernel] CVS Commit: freeldr

[Brian P. <br...@sg...>]

Caches the current FAT sector so it doesn't read again if it doesn't
have to.
 
Modified Files:
    fat32.asm
 
Brian

Re: [ros-kernel] CVS Commit: reactos

[Eric K. <ek...@rz...>]

"Hartmut Birr" <har...@te...> wrote:


> It seems that some programs (gditest) are not able to locate drivers in
> memory. They load the drivers again. See the attached debug output.
> Vidport.sys needs some little changes for runing gditest. One for the
dirty
> hack to get csrss's process handle and the other to change interrupt 10h
to
> 6dh, if loadros is used for booting.

I just checked in a little patch that should fix this bug.
LdrpCompareModuleNames() will now accept fully qualified path names too.

Eric

AW: [ros-kernel] CVS Commit: reactos

[Hartmut B. <har...@te...>]

It seems that some programs (gditest) are not able to locate drivers in 
memory. They load the drivers again. See the attached debug output. 
Vidport.sys needs some little changes for runing gditest. One for the dirty 
hack to get csrss's process handle and the other to change interrupt 10h to 
6dh, if loadros is used for booting.

- Hartmut




> -----Ursprungliche Nachricht-----
> Von:	Eric Kohl [SMTP:ek...@rz...]
> Gesendet am:	Montag, 10. Juni 2002 11:05
> An:	ReactOS Kernel
> Betreff:	[ros-kernel] CVS Commit: reactos
>
> ntoskrnl/io/drvlck.c (removed!)
> ntoskrnl/mm/drvlck.c (new!)
> ntoskrnl/makefile
>     Moved driver locking functions.
>
> ntoskrnl/include/internal/io.h
> ntoskrnl/include/internal/ldr.h
> ntoskrnl/io/device.c
> ntoskrnl/io/driver.c (new!)
> ntoskrnl/io/iomgr.c
> ntoskrnl/ke/main.c
> ntoskrnl/ldr/loader.c
> ntoskrnl/makefile
>     Minimize access to the module object via the object manager.
>     Use module list for internal module management.
>     Protect module list with a spinlock.
>
>
> This is the first step of an attempt to reorganize and clean up the 
current
> driver/module chaos. I removed all unneccessary accesses of module 
objects
> via the object manager and replaced them by direct accesses via the 
module
> list.
>
> The next step of the cleanup will replace the current driver objects 
which
> are currently represented by MODULE_OBJECTs by the real DRIVER_OBJECTs.
> MODULE_OBJECTs will only be used as entries of the module list and won't
> appear in the object manager namespace any more.
>
>
> Regards,
> Eric

AW: [ros-kernel] commit messages

[Hartmut B. <har...@te...>]

> -----Ursprungliche Nachricht-----
> Von:	Rex Jolliff [SMTP:re...@lv...]
> Gesendet am:	Dienstag, 11. Juni 2002 01:21
> An:	rea...@li...
> Betreff:	[ros-kernel] commit messages
>
>
> in the maillog for mok, I see the following error reported from commits:
>
> Jun  9 05:58:56 mok sendmail[10491]: xxx:
>    to=...@li...,
>    ctladdr=bpalmer (1007/200), delay=12:54:57,
>    xdelay=00:03:00, mailer=esmtp, pri=1200407,
>    relay=externalmx.valinux.com., dsn=4.0.0,
>    stat=Deferred: 451-Envelope sender verification failed
>
> Any idea what the 451 error is?  I'm thinking that the mail addresses on
> mok are not registered with the mailing list, and cannot therefore post.

If I subscribe from the reactos page at SF, I get never a return mail to 
mok. I get also no return mail if I send a mail from mok to 
<rea...@li...>. Does mok not like SF?

- Hartmut