Hi!
I just found a severe bug in hardware detection code of Freeldr. It uses
two configuration nodes in the hardware tree to pass information about
detected hard-disks to ntoskrnl.exe and disk.sys.
First, hard-disk information is passed as a DiskPeripheral node attached
to a DiskController node.
Second, hard-disk information is passed as an array of
CM_INT13_DRIVE_PARAMETER entries in a special system configuration node,
if the disks were detected by the BIOS.
As part of the boot process, the special system configuration node is
used by disk.sys to determine the disk geometry used by the BIOS.
Unfortunately, this configuration node did not use the extended disk
geometry (LBA geometry) but the old CHS geometry even if the LBA
geometry was available.
I already fixed this bug in my local source tree and suddenly Freeldr,
disk.sys and usetup.exe report exactly the same disk geometry as gparted
(http://gparted.sourceforge.net/download.php). Unfortunately, using this
patch breaks the 2nd stage setup.
I will provide a patch that fixes the Freeldr issue as soon as I have
cleaned up the source tree.
Please help me find the remaining bug or workaround that keeps ReactOS
from booting into 2nd stage setup! I guess it is either part of usetup
or somewhere in the partition management routines.
Regards,
Eric
Hi,
why reimplementing an unsecure IoReadPartitionTable version? It even looks like IoReadPartitionTableEx() which may arrive soon in ReactOS ;).
Best regards,
P. Schweitzer
Hi,
What You say makes sense of course.
I can't find time to dig into the code, but it sounds like you acted
correctly.
We can of course improve the setup behavior as time goes and we learn how
to do it right with various boot managers, no need to take after
Microsoft here,
but there will always be cases when we don't know how to wedge the boot in.
We can always, as long as there is a free partition or free space to
create one, get as far
as installing the OS and it's partition boot, but may be unable to
install a master boot,
if the user has an unknown boot manager we don't recognize
One way to deal with it would be to chain the master boot.
That is, we save the original master boot to a file, and implement a query
in our own master boot, whether the user want to boot ROS, or continue
with the original master boot. It would be a small matter to load the
original
master boot and giving control over to it if need be.
Sure, it's one more pit-stop on the way to OS, but it would take care
of all the cases we cannot know, or cannot handle.
Best Regards
L from Hell
Eric Kohl <eric.kohl(a)t-online.de> wrote:
> Hi!
>
> Being cooperative was my intention when I wrote this part of usetup.
> The bad thing about this approach is that usetup needs to deal with
> all kinds of different situations that developers cannot even think
> about. The only proper way to fix this situation was: "Don't touch it
> if you don't know how to deal with it!" The result was that usetup
> could only handle empty harddisks and Windows boot managers correctly.
> Except for these two cases there are lots of different situations that
> a setup application cannot deal with. That's where the user must fix
> things. That's why usetup enables users to save the bootsector to a
> floppy disk. This enables them to fix the unknown situations
> themselves. Unfortunately this means that newbies might not be able to
> install the bootcode properly. But I thought it was better not to
> overwrite a bootsector that to unintentionally damage a system.
>
> The question how to handle this correctly is a difficult one.
> Microsoft chose the easy way as they behave like they are the owner of
> the system and overwrite everything as they see fit. But implementing
> this part of the setup in a way that fits everyones needs is a very
> difficult task. Just think about the different filesystems and
> different versions of LILO and GRUB and what about other third-party
> boot-managers...
>
> Regards,
> Eric
Hi!
Please test this with GRUB and LILO, since I use LILO on my main
hardware test. I do not have access to it for the moment. During the
installation of the boot CD, I do not overwrite the MBR. I just hope
it works when I get back to work with the project.
Thanks,
James
Second that.
If it ain't broke, don't bloody "fix" it.
Best Regards
L from Hell
Alex Ionescu <ionucu(a)videotron.ca>:
> This is retarded, GAS supports Intel syntax. Why did this require
> rewriting everything in AT&T syntax and introducing bugs? And what's
> up with calling AT&T syntax "GAS" Syntax.
>
> I wonder what Brian would say....
>
> It's funny how this project gets rid of old developers, gets new
> developers, and has them make the same mistakes/idiotic things the old
> developers left for in the first place...
>
> Good job!
>
> Best regards,
> Alex Ionescu
>
>
Allow me to present a small sub-project Gabriel and I are working on. We did
a small scale consulting, but its the time to present it on a more wider
scale.
As a comment, specifically to Timo's post: 2nd class tags should not be
conflicting with Component field when possible. In case of Kernel and
win32k, a submodule should be used instead of module name: for example in
case of kernel bugs, Components should be set to Kernel, whereas 2nd class
tag should be pointing to kernel submodule, like iomgr:, ob:, mm: etc.
All opinions are most welcome
Best regards
Hi
I'd like to propose an overhaul of our bugzilla interface. The reason is
that the current interface is ugly and confusing and I think we can make
filing and handling bugs less unenjoyable ;-)
First I think it would be very useful, if we could edit the description
field of the bugs. This way we don't need to browse through dozens of
comments to find all neccessary info, while the description only
contains useless stuff. This should be restricted to the original
reporter and testers / developers.
Then when filing a new bug or looking at a bug that is already filed,
the layout is horrible. I'm not a webdesigner, so it's hard for me to
say how it should look like, but definately not the way it is. This
might be appropriate for projects whose website look like
http://www.gnu.org/software/binutils/ but I'm sure, we can do better.
Then when filing a bug there are the following fields:
- reporter - I know who I am, so why show it to me? Unneccessary
- Component: I don't think this field is really useful as it is. First:
Patches are definately not a component. Then it's often hard to tell
where the bug is. for example, if rapps doesn't download anything, is
that related to network or is it a kernel bug or win32 or rapps or is
only the server down? You often don't know it when filing a bug. Also
win32 covers a lot from win32k to shell32, but are these more closely
related than drivers and networking?
- Severity: while I think this field is useful and important, it should
only be editable by testers and developers and should not appear when a
bug is filed.
- Platform: should be removed
- OS: should be removed
- AssignTo, Cc: rarely used on first filing, should IMO only be editable
by testers / developers
- URL: While we use this field from time to time, I think the URL could
as well, if neccessary be put into the description field (provided, it
was editable). This versatile field should imo change it's purpose from
URL to TAG. So we can add different tags, like REGRESSION, PATCH, HACK,
that are currently put into the summery field. It could also contain the
regression range or guilty version
- Alias: we don't use this, or rather currently only misuse this for the
guilty version, which is problematic, as soon as 2 bugs have the same
guilty version, IMO unneccessary
- Summery: should be as wide as the description field
- Description: To get better bugreports, I suggest dividing this field
into "Steps to reproduce:" "Experienced behaviour:" "Remarks"
These fields can very well be automatically merged into one field, It's
just to show people that they must provide steps to reproduce, instead
of writing dozens of lines about their hardware configuration and how
they feel about the bug.
Regards,
Timo
Hello,
Many thanks for fixing this idiotic oversight of mine. I apologies for the long hours of debugging I must have caused.
This fix is somewhat incomplete/at the wrong place; could this be marked as such in the code, perhaps with a FIXME under my name, so that I may fix this correctly upon my return to the US?
Much obliged!
-r
Author: mjmartin
Date: Sat Aug 28 00:26:02 2010
New Revision: 48632
URL: http://svn.reactos.org/svn/reactos?rev=48632&view=rev
Log:
[ntoskrnl/ps]
- When deleting a Process remove the Process from the MmProcessList. Fixes random NonPaged Pool corruptions. Thanks aicom for assistance.
Modified:
trunk/reactos/ntoskrnl/ps/kill.c
Modified: trunk/reactos/ntoskrnl/ps/kill.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/kill.c?rev=486…
==============================================================================
--- trunk/reactos/ntoskrnl/ps/kill.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/ps/kill.c [iso-8859-1] Sat Aug 28 00:26:02 2010
@@ -300,6 +300,8 @@
/* Detach */
KeUnstackDetachProcess(&ApcState);
+
+ RemoveEntryList(&Process->MmProcessLinks);
/* Completely delete the Address Space */
MmDeleteProcessAddressSpace(Process);