reactos-kernel

Re: [ros-kernel] The Explorer replacement we need.

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

At 16.51 14/07/2002, you wrote:
>http://www.geoshellx.com/
>This shell just kicks ass.

I second the "kick ass" thing, but it's just a desktop. A real shell 
replacement is still far away ;-(

BTW, what's the status of Wine's shell32?

>Thats really all that needs to be said about it. It doesnt seem to suffer 
>from the short falls of litestep either such as the .ini usage and high 
>overhead.

Not to speak of the low coolness factor!

>The best part about it is it is GPL and was started by a programmer who 
>works at microsoft. =)

makes it even more cool :-) especially for us :-)

Seriously, I like it. Sober, simple, good looking, which is good for the 
press. Open source, extensible, which is good for us. Any user to confirm 
if it's also usable?

Re: [ros-kernel] reactos/tools/makefile

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

"Royce Mitchell III" <ro...@ev...> wrote:

> By the way, I noticed something interesting when I tried to boot ros this
> morning...
>
> (class2.c:1173) SectorSize: 512  SectorCount: 0
>
> Could SectorCount of 0 cause a problem?

It is okay if it is reported by your empty ZIP drive. Obviously, a harddisk
should never report this.

Eric

Re: [ros-kernel] More useful stack traces

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

s=F8n, 2002-07-14 kl. 18:26 skrev David Welch:
> On Sun, Jul 14, 2002 at 02:52:55PM +0200, Casper Hornstrup wrote:
> > Also, core dumping is only useful to developers when they have symbol
> > information. This would mean that either 1) the core dump would contain
> > the symbols (meaning that non-stripped images need to be used or the
> > symbols come from the .sym files) or b) core dumps are limited to beein=
g
> > generated by official releases so the developer has the symbol
> > information available. If b) then 6 months is probably too long between
> > releases.=20
> >
> The way I envisaged it working was that the user would run a tool to
> postprocess the core dump and produce information which could be emailed =
to us.
> We wouldn't want people sending 256MB files (or whatever the average memo=
ry
> size is these days) anyway. Obviously the core dump would have to contain
> a module list but the actual matching up of addresses to symbols could be
> done offline. Also we would need to have debugging information produced
> on builds of all types and included in offical releases. I don't see this
> as a big problem, ntoskrnl and the default hal have been built with '-g'
> unconditionally for years.

So you say it should dump the whole memory instead of just part of it (a
small memory dump in NT)? I guess it would not be too difficult to skip
free pages when dumping. Since you want to do post-processing, it sounds
like you don't care if the core dump can be interpreted by already
available debuggers like gdb. So, should we write our own tools to
interpret the core dumps or modify existing?

Let's talk about what information we need from a core dump in order to
fix a bug. The bugreport with the coredump should contain enough
information to reproduce the crash. There is of course the state of the
CPU registers at the time of the crash. Then there is the module list
and the process list.

In any case core dumps are usually not enough to reproduce a bug. The
following article provides guidelines on how to produce meaningful
bugreports:

http://freshmeat.net/articles/view/149/

Casper

Re: [ros-kernel] reactos/tools/makefile

[Royce M. I. <ro...@ev...>]

I will double-check it again now.

By the way, I noticed something interesting when I tried to boot ros this
morning...

(class2.c:1173) SectorSize: 512  SectorCount: 0

Could SectorCount of 0 cause a problem?

----- Original Message -----
From: "David Welch" <we...@cw...>
To: <rea...@li...>
Sent: Sunday, July 14, 2002 11:13 AM
Subject: Re: [ros-kernel] reactos/tools/makefile


> On Sun, Jul 14, 2002 at 09:12:56AM -0500, Royce Mitchell III wrote:
> > Yes! Thank You! Finally got a line number!!!!
> >
> > Here's the dump info:
> >
> > Page fault at high IRQL was 12
> > Bug detected code: 0x1D
> > Divide Error Exception: 0(2)
> > Processor: 0 CS:EIP 8:c00e3f98 <hal.dll: 3f98>
> >
> > C:\reactos\hal\halx86>addr2line --exe=hal.nostrip.dll 0x14f98
> > //C/reactos/hal/halx86/time.c:199
> >
> > Here's time.c:199:
> >   Val = HalpQueryCMOS(RTC_REGISTER_B);
> >
> > Why would that get a div/0?
> >
> >
> > Here's 0x10000 offset:
> >
> > C:\reactos\hal\halx86>addr2line --exe=hal.nostrip.dll 0x13f98
> > //C/reactos/hal/halx86/pci.c:411
> >
> > Here's pci.c:411:
> >    return Length - Len;
> >
> > Not sure why that would div/0 either :(
> >
> >
> > The .sym files aren't text anymore, so how do I determine what the .text
> > offset is for hal.dll?
> >
> The trap number was reported incorrectly until a few days ago. I do not
> think either of the lines you have got are right, is it possible that
> the hal you are using for the line numbers was built with different
options
> to the one that produced the error?
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel
>

Re: [ros-kernel] Status of wine modules?

[Steven E. <ste...@ya...>]

Broken. =) Will be doing more work this week.

I have been submitting bug reports to the wine
bugzilla regarding the win9xism, unixisms, and
wineisms as I find them. I just rebuilt comctl32 here.
Did you do "make -f makefile.ros" ?


> P:\REACTOS\source\wine\dlls\comctl32>make
> make: *** No targets specified and no makefile
> found.  Stop.
> 
> P:\REACTOS\source\wine\dlls\comctl32>make
> makefile.ros
> make: Nothing to be done for `makefile.ros'.
> 
> P:\REACTOS\source\wine\dlls\comctl32>
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
>
https://lists.sourceforge.net/lists/listinfo/reactos-kernel


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

Re: [ros-kernel] More useful stack traces

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

On Sun, Jul 14, 2002 at 02:52:55PM +0200, Casper Hornstrup wrote:
> Also, core dumping is only useful to developers when they have symbol
> information. This would mean that either 1) the core dump would contain
> the symbols (meaning that non-stripped images need to be used or the
> symbols come from the .sym files) or b) core dumps are limited to beeing
> generated by official releases so the developer has the symbol
> information available. If b) then 6 months is probably too long between
> releases. 
>
The way I envisaged it working was that the user would run a tool to
postprocess the core dump and produce information which could be emailed to us.
We wouldn't want people sending 256MB files (or whatever the average memory
size is these days) anyway. Obviously the core dump would have to contain
a module list but the actual matching up of addresses to symbols could be
done offline. Also we would need to have debugging information produced
on builds of all types and included in offical releases. I don't see this
as a big problem, ntoskrnl and the default hal have been built with '-g'
unconditionally for years.

[ros-kernel] Status of wine modules?

[Robert D. <od...@pn...>]

What is the current status of the wine modules in CVS?

I briefly checked makefile.ros and its includes which all appear
to be in order but seems I'm missing something.....

--------------------------------------------------------------------------------
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

P:\REACTOS\source\wine\dlls\comctl32>make
make: *** No targets specified and no makefile found.  Stop.

P:\REACTOS\source\wine\dlls\comctl32>make makefile.ros
make: Nothing to be done for `makefile.ros'.

P:\REACTOS\source\wine\dlls\comctl32>

Re: [ros-kernel] reactos/tools/makefile

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

On Sun, Jul 14, 2002 at 09:12:56AM -0500, Royce Mitchell III wrote:
> Yes! Thank You! Finally got a line number!!!!
> 
> Here's the dump info:
> 
> Page fault at high IRQL was 12
> Bug detected code: 0x1D
> Divide Error Exception: 0(2)
> Processor: 0 CS:EIP 8:c00e3f98 <hal.dll: 3f98>
> 
> C:\reactos\hal\halx86>addr2line --exe=hal.nostrip.dll 0x14f98
> //C/reactos/hal/halx86/time.c:199
> 
> Here's time.c:199:
>   Val = HalpQueryCMOS(RTC_REGISTER_B);
> 
> Why would that get a div/0?
> 
> 
> Here's 0x10000 offset:
> 
> C:\reactos\hal\halx86>addr2line --exe=hal.nostrip.dll 0x13f98
> //C/reactos/hal/halx86/pci.c:411
> 
> Here's pci.c:411:
>    return Length - Len;
> 
> Not sure why that would div/0 either :(
> 
> 
> The .sym files aren't text anymore, so how do I determine what the .text
> offset is for hal.dll?
> 
The trap number was reported incorrectly until a few days ago. I do not
think either of the lines you have got are right, is it possible that
the hal you are using for the line numbers was built with different options
to the one that produced the error?

Re: [ros-kernel] The Explorer replacement we need.

[Robert D. <od...@pn...>]

At 07:51 AM 14/07/2002 -0700, you wrote:
>http://www.geoshellx.com/
>
>This shell just kicks ass. Thats really all that needs
>to be said about it. It doesnt seem to suffer from the
>short falls of litestep either such as the .ini usage
>and high overhead. The best part about it is it is GPL
>and was started by a programmer who works at
>microsoft. =)


I have used it for quite a long time and totally agree.
It's the first shell I hope to get working on ReactOS.

Regards, Robert.

[ros-kernel] The Explorer replacement we need.

[Steven E. <ste...@ya...>]

http://www.geoshellx.com/

This shell just kicks ass. Thats really all that needs
to be said about it. It doesnt seem to suffer from the
short falls of litestep either such as the .ini usage
and high overhead. The best part about it is it is GPL
and was started by a programmer who works at
microsoft. =)

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

Re: [ros-kernel] reactos/tools/makefile

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

s=F8n, 2002-07-14 kl. 16:12 skrev Royce Mitchell III:
> Yes! Thank You! Finally got a line number!!!!
>=20
> Here's the dump info:
>=20
> Page fault at high IRQL was 12
> Bug detected code: 0x1D
> Divide Error Exception: 0(2)
> Processor: 0 CS:EIP 8:c00e3f98 <hal.dll: 3f98>
>=20
> C:\reactos\hal\halx86>addr2line --exe=3Dhal.nostrip.dll 0x14f98
> //C/reactos/hal/halx86/time.c:199
>=20
> Here's time.c:199:
>   Val =3D HalpQueryCMOS(RTC_REGISTER_B);
>=20
> Why would that get a div/0?
>=20
>=20
> Here's 0x10000 offset:
>=20
> C:\reactos\hal\halx86>addr2line --exe=3Dhal.nostrip.dll 0x13f98
> //C/reactos/hal/halx86/pci.c:411
>=20
> Here's pci.c:411:
>    return Length - Len;
>=20
> Not sure why that would div/0 either :(
>=20

I think the Divide Error Exception is incorrectly displayed.

> The .sym files aren't text anymore, so how do I determine what the .text
> offset is for hal.dll?

All kernel mode drivers have .text offset 0x11000.

You can get it by using objdump -h or nm -n.

Casper

Re: [ros-kernel] reactos/tools/makefile

[Royce M. I. <ro...@ev...>]

Yes! Thank You! Finally got a line number!!!!

Here's the dump info:

Page fault at high IRQL was 12
Bug detected code: 0x1D
Divide Error Exception: 0(2)
Processor: 0 CS:EIP 8:c00e3f98 <hal.dll: 3f98>

C:\reactos\hal\halx86>addr2line --exe=hal.nostrip.dll 0x14f98
//C/reactos/hal/halx86/time.c:199

Here's time.c:199:
  Val = HalpQueryCMOS(RTC_REGISTER_B);

Why would that get a div/0?


Here's 0x10000 offset:

C:\reactos\hal\halx86>addr2line --exe=hal.nostrip.dll 0x13f98
//C/reactos/hal/halx86/pci.c:411

Here's pci.c:411:
   return Length - Len;

Not sure why that would div/0 either :(


The .sym files aren't text anymore, so how do I determine what the .text
offset is for hal.dll?

----- Original Message -----
From: "Casper Hornstrup" <ch...@us...>
To: <rea...@li...>
Sent: Sunday, July 14, 2002 4:42 AM
Subject: Re: [ros-kernel] reactos/tools/makefile


søn, 2002-07-14 kl. 03:00 skrev Royce Mitchell III:
> Casper et all,
>
> I can't seem to get your new debug info to work, nor can I get addr2line
to
> work. I must be doing something wrong, but I don't know what :(

Experiments show that you must add 0x11000 (for most drivers) to your
addresses when passed to addr2line. 0x10000 is probably the image base,
but where does the extra 0x1000 come from? You can get the exact offset
by using objdump -h. The value is the VMA of the .text section.

Casper




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
reactos-kernel mailing list
rea...@li...
https://lists.sourceforge.net/lists/listinfo/reactos-kernel

Re: [ros-kernel] More useful stack traces

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

s=F8n, 2002-07-14 kl. 13:53 skrev Casper Hornstrup:
> s=F8n, 2002-07-14 kl. 14:00 skrev David Welch:
> > On Sat, Jul 13, 2002 at 11:27:19PM +0200, Casper Hornstrup wrote:
> > > How?
> > >
> > I think this feature rather falls between two stools: for non-technical=
 users
> > we need a core dump facility which can be automatically decoded offline=
 and
> > emailed to us; developers (who don't have two machines) need a kernel
> > debugger which uses all debugging information and has source code
> > available as well.
>=20
> A core dump facility would be nice, but I think it is complementary to
> the linenumber information in stack traces; not a replacement for it. To
> be able to core dump, the storage driver stack must be loaded so disks
> are accessible. For all crashes before this happens, core dumping is
> useless. Also, I don't always setup a system with a debugger because it
> is difficult and sometimes it helps a lot just knowing the line of code
> where a crash occur.
>=20
> Casper

Also, core dumping is only useful to developers when they have symbol
information. This would mean that either 1) the core dump would contain
the symbols (meaning that non-stripped images need to be used or the
symbols come from the .sym files) or b) core dumps are limited to beeing
generated by official releases so the developer has the symbol
information available. If b) then 6 months is probably too long between
releases. It would be nice if GDB will understand the core dumps.

Casper

Re: [ros-kernel] More useful stack traces

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

s=F8n, 2002-07-14 kl. 14:00 skrev David Welch:
> On Sat, Jul 13, 2002 at 11:27:19PM +0200, Casper Hornstrup wrote:
> > How?
> >
> I think this feature rather falls between two stools: for non-technical u=
sers
> we need a core dump facility which can be automatically decoded offline a=
nd
> emailed to us; developers (who don't have two machines) need a kernel
> debugger which uses all debugging information and has source code
> available as well.

A core dump facility would be nice, but I think it is complementary to
the linenumber information in stack traces; not a replacement for it. To
be able to core dump, the storage driver stack must be loaded so disks
are accessible. For all crashes before this happens, core dumping is
useless. Also, I don't always setup a system with a debugger because it
is difficult and sometimes it helps a lot just knowing the line of code
where a crash occur.

Casper

Re: [ros-kernel] reactos/tools/makefile

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

On Sun, Jul 14, 2002 at 11:42:48AM +0200, Casper Hornstrup wrote:
> Experiments show that you must add 0x11000 (for most drivers) to your
> addresses when passed to addr2line. 0x10000 is probably the image base,
> but where does the extra 0x1000 come from? You can get the exact offset
> by using objdump -h. The value is the VMA of the .text section.
> 
The kernel always prints code addresses relative to the start of the .text
segment of the module in question.

Re: [ros-kernel] More useful stack traces

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

On Sat, Jul 13, 2002 at 11:27:19PM +0200, Casper Hornstrup wrote:
> How?
>
I think this feature rather falls between two stools: for non-technical users
we need a core dump facility which can be automatically decoded offline and
emailed to us; developers (who don't have two machines) need a kernel
debugger which uses all debugging information and has source code
available as well.
 

Re: [ros-kernel] reactos/tools/makefile

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

"Casper Hornstrup" <ch...@us...> wrote:

> > I did a make clean, changed config as you suggested, and then did a
make,
> > then ran install.bat. I'm still crashing on the zip drive, and yes,
Eric,
> > it's an ATAPI as a previous e-mail showed. I noticed in atapi.c that if
the
> > BytesPerSector is 0, it is set to 512. I don't know if that was just put
in
> > or not, but it's still crashing.
>
> IIRC BytesPerSector is changed to 512 because the code still assumes a
> standard DOS compatible harddisk in this case. Eric can tell you wether
> this is still true.

Yes, this is true. The ATA specs say that 0 Bytes per Sector really mean 512
Bytes per Sector (default sector size). IMO it is a brain-dead concept but
most of the harddisks I have seen report 0 Bytes per Sector.

Eric

Re: [ros-kernel] reactos/tools/makefile

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

s=F8n, 2002-07-14 kl. 03:00 skrev Royce Mitchell III:
> Casper et all,
>=20
> I can't seem to get your new debug info to work, nor can I get addr2line =
to
> work. I must be doing something wrong, but I don't know what :(

Experiments show that you must add 0x11000 (for most drivers) to your
addresses when passed to addr2line. 0x10000 is probably the image base,
but where does the extra 0x1000 come from? You can get the exact offset
by using objdump -h. The value is the VMA of the .text section.

Casper

Re: [ros-kernel] reactos/tools/makefile

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

s=F8n, 2002-07-14 kl. 03:00 skrev Royce Mitchell III:
> Casper et all,
>=20
> I can't seem to get your new debug info to work, nor can I get addr2line =
to
> work. I must be doing something wrong, but I don't know what :(

I couldn't get addr2line to work either.

>=20
> I did a make clean, changed config as you suggested, and then did a make,
> then ran install.bat. I'm still crashing on the zip drive, and yes, Eric,
> it's an ATAPI as a previous e-mail showed. I noticed in atapi.c that if t=
he
> BytesPerSector is 0, it is set to 512. I don't know if that was just put =
in
> or not, but it's still crashing.

IIRC BytesPerSector is changed to 512 because the code still assumes a
standard DOS compatible harddisk in this case. Eric can tell you wether
this is still true.

> Here's my files:

Your configuration looks okay.

I don't use install.bat because it is not always up-to-date. IIRC
symbols are not copied by install.bat. I do a "make install" or "make
<module>_install". The needed files are then copied to the
reactos/reactos directory. I then have a DOS .bat file that use xcopy to
copy the whole reactos/reactos directory to the installation directory.

Casper

[ros-kernel] Can't subscribe to the reactos-cvs-commit list

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

It seems that the commit mail from mok does work. If I subscribe from my
mok account to the reactos-cvs-commit list, I get never a response from
SF. If I send a mail from my home account to my account on mok, I get a
failure mail after two or three days. See the two attached files. What
is wrong?

- Hartmut

RE: [ros-kernel] reactos/tools/makefile

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

 
> I can't seem to get your new debug info to work, nor can I get
> addr2line to work. I must be doing something wrong, but I don't know 
> what :(

Loadros is a little bit bugy. It forgot to close the opened files. At
least loadros can load 15 files if the config.sys has a statement
files=20 (or greater). I fix this bug.

- Hartmut

Re: [ros-kernel] reactos/tools/makefile

[Royce M. I. <ro...@ev...>]

Casper et all,

I can't seem to get your new debug info to work, nor can I get addr2line to
work. I must be doing something wrong, but I don't know what :(

I did a make clean, changed config as you suggested, and then did a make,
then ran install.bat. I'm still crashing on the zip drive, and yes, Eric,
it's an ATAPI as a previous e-mail showed. I noticed in atapi.c that if the
BytesPerSector is 0, it is set to 512. I don't know if that was just put in
or not, but it's still crashing.

Here's my files:

=== bootsym.bat ===
loadros system32\ntoskrnl.exe system32\hal.dll /DEBUGPORT=SCREEN bootsym.lst
=== end of bootsym.bat ===

=== bootsym.lst ===
system32\drivers\scsiport.sys
system32\drivers\atapi.sys
system32\drivers\class2.sys
system32\drivers\disk.sys
system32\drivers\vfatfs.sys
system32\config\system.hiv
system32\ntoskrnl\ntoskrnl.sym
hal\halx86\hal.sym
drivers\storage\scsiport\scsiport.sym
drivers\storage\atapi\atapi.sym
drivers\storage\class2\class2.sym
drivers\storage\disk\disk.sym
drivers\fs\vfat\vfatfs.sym
*
=== end of bootsym.lst ===

=== config ===
#
# Architecture to build for
#
# Specify one of: i386
# Possible values in the future: alpha,i386,m68k,mips,powerpc
ARCH := i386

#
# Whether to compile in the kernel debugger
#
KDBG := 0

#
# Whether to compile for debugging
#
DBG := 1

#
# Whether to compile a multiprocessor or single processor version
#
MP := 0

#
# Whether to compile for ACPI compliant systems
#
ACPI := 0
=== end of config ===

Re: [ros-kernel] reactos/tools/makefile

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

l=F8r, 2002-07-13 kl. 23:41 skrev David Kredba:
> Casper:
>=20
>=20
> There is missing E at line 59 :
>=20
> ifeq ($(HOST),mingw32-windows)
> rsym$(EX_POSTFIX): rsym.c
> 	$(HOST_CC) $(CFLAGS) -DDOS_PATHS rsym.c -o rsym$(EXE_POSTFIX)

Yes, a fix is in CVS.

Casper

Re: [ros-kernel] More useful stack traces

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

s=F8n, 2002-07-14 kl. 00:12 skrev David Welch:
> I still think there are better ways to get the same functionality.

How?

 The code for loading and parsing stabs should at least be localised in the=
 kernel
> debugger code (ntoskrnl/kd/).

Okay.

Casper

Re: [ros-kernel] More useful stack traces

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

On Sat, Jul 13, 2002 at 03:18:36PM +0200, Casper Hornstrup wrote:
> I have just committed a patch that enables ReactOS to understand .stabs
> symbols (only line number, function names, and source file names though,
> but this is enough to get useful stack traces when not using a
> debugger). When ReactOS is configured for debugging, ReactOS will try to
> load symbols for every module it loads. E.g. if ReactOS loads ndis.sys,
> it will also load \SystemRoot\symbols\ndis.sym if this file exists. The
> .sym files generated by ReactOS dating before today are text files. The
> new .sym files are binary files extracted by the tools/rsym build
> utility from the non-stripped module image. If you have old .sym text
> files in your ReactOS installation, you had better remove them on your
> next update or expect trouble.
>
I still think there are better ways to get the same functionality. The code
for loading and parsing stabs should at least be localised in the kernel
debugger code (ntoskrnl/kd/).