Hello,
eVb checked in one of his final patches yesterday from his development machine in China, where we worked on a final pass on the driver. Unfortunately, my last two (unrelated) check ins were done from his machine (as most of you know, I was in China for the past month), and he was not used to SVN caching the credentials of the last user. Revision 48748 was a checkin from eVb, and his "goodbye" was in reference to my departure. Since it used my cached credentials from the same machine, it must've caused a lot of confusion.
Many apologies and thanks for understanding.
-r
fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Sat Sep 11 09:20:26 2010
> New Revision: 48745
>
...
> /* Save EFlags */
> + Esp -= 4;
> + *(PULONG)(Esp - 2) = V86EFlags;
>
This looks wrong to me. The (Esp - 2) I mean.
> + if (KiVdmGetPrefixFlags(Flags) & PFX_FLAG_OPER32)
> + {
> + /* Read EFlags */
> + EFlags = *(PULONG)Esp;
> + Esp += 4;
> + }
> + else
> + {
> + /* Read EFlags */
> + EFlags = *(PUSHORT)Esp;
> + Esp += 2;
> /* Read correct flags and use correct stack address */
> - Esp -= 2;
> EFlags &= 0xFFFF;
>
Here the comment got broken a bit.
> /* Set new ESP */
> - TrapFrame->HardwareEsp = Esp;
> + TrapFrame->HardwareEsp = (USHORT)Esp;
>
This is not correct. We earlier calculated the flat Esp from Ss and Sp.
Example:
HardwareSegSs = 0x10, HardwareEsp = 0x10 -> flat Esp = 0x110, then you
substract 4, and get 0x10C. But this is not the value of the new
HardwareEsp. TrapFrame->HardwareEsp needs to be either modified in
parallel to the flat Esp or calculated like (USHORT)(Esp -
(TrapFrame->HardwareSegSs << 4)).
Regards,
Timo
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