About the E820cycles parameter

About the E820cycles parameter
Http://bbs.wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=327458&pid=3002550&fromuid= 298214
Mdyblog published on 2014-11-20 06:20
"Map--int15nolow=1" is still a failure.
Video driver failed to initialized.

Well, your report is very good, it shows that Int15nolow does not work, has been replaced by the new e820cycles.

After that, we were even simpler, using only e820cycles to control it.

The real world is complex and not so ideal. We all want to be simple and easy, but we may not be able to do anything.

The default value we use is based on a computer with no bugs. Our default value is not possible with a buggy computer. So, your idea can't be realized. Incompatibility should be avoided, but our software is moving forward, is constantly improving. The old version does not have the e820cycles ability to adjust, it should be eliminated. Since the old version is obsolete, there is no incompatibility.

Http://bbs.wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=327458&pid=3002980&fromuid= 298214
No, Dot. Posted on 2014-11-20 17:43:54
>>> e820cycles=0
>>> sometimes has side effects, but can not start. This parameter e820cycles very unfriendly.

Mdyblog, you are a strong supporter of the Grub4dos development process, you are the active person. In particular, through this report, I finally cleared up the relationship between Int15nolow and E820cycles, knowing that Int15nolow is only a product of phased understanding, and e820cycles to fundamentally locate the root cause. Therefore, the Int15nolow parameter can be discarded.

I this post, is not only to give you a further explanation, but also for the maintenance of grub4dos to do a thorough technical report.

At the beginning, in the English forum, Karyonix, Shao, and other developers found that Grub4dos's int15 did not protect conventional memory (in the INT13 code space), but only the extended memory (the memory disk image in), which is the source of some blue screen (or panic) problems. We used to protect the conventional memory of the INT13 code space is through the 0x413 at the user can use the normal amount of internal memory to achieve, originally thought this is OK, but Karyonix and Shao and other people's discovery, forcing us to improve the INT15 processing program, the conventional Memory int13 Code also passed Int15 protect them. This is the dual protection, one is the use of the BIOS data area 0x413 Memory specification, the other is the use of the INT15 specification.

Next, our Chinese users quickly reported that the new version caused the blue screen to panic, as well as the old version. It took a long time to find the root cause of the problem, and it was finally known that the INT15 code was added to handle low memory (that is, conventional ram). Therefore, the Int15nolow parameter was invented to cope with these situations. Int15nolow=1, you no longer use int15 to protect conventional memory.

At the same time, there are other users reported, even if the setting int15nolow=1, there is still a blue screen panic occurs. This requires further experimentation to determine the cause of the blue screen panic. Finally, as long as the takeover of Int15 can lead to blue screen panic, do not take over the int15, you may enter Windows. At the very beginning of the int15 handler, a far jmp instruction jumps to the original ROM int15 entry, and the exact same blue screen panic occurs with the same error code. This proves that int15 is not to take over, as long as the takeover on the blue screen of the panic. Need to explain is that the occurrence of the blue screen of the death, but also just a part of the machine, other normal machines also have a lot, it seems that the normal machine than the blue screen of the machine more, blue screen is a few, but the blue screen machine also occupies a large proportion, can not be ignored. It was later reported that the blue screen problem could be solved by replacing the driver for the Win7 driver with a video card. Together with a number of other user reports, important information is provided to the developer. We gradually understand that it is only a video card driver bug, a part of the graphics driver problems, and other manufacturers of XP graphics drivers are no problem.

At that time I did not realize that Int15nolow and e820cycles are actually solving the same problem. Int15nolow solution did not find the crux of the problem, it is only a phased outcome. The final E820cycles solution is the remedy.

Now I've learned that Int15nolow's solution is unreliable, and the fundamental effective solution is to use e820cycles to control it.

Http://bbs.wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=327458&pid=3003016&fromuid= 298214
No, Dot. Posted on 2014-11-20 18:22:49 |
I'm talking about a "no memory disk to protect" case. For example, "map--mem" is not used at all.

Without using a memory disk, you also have to use int15 to protect the grub4dos INT13 code space in conventional memory, which is the double protection mentioned earlier. Previously we only use the BIOS data area 0x413 Memory specification to protect, but this is not enough, Karyonix,shao and other developers found that must use int15 to protect, otherwise on some machines will crash. However, when we use int15 to protect the INT13 code space, it is necessary to take over the int15, which will inevitably result in those buggy graphics driver BSoD (see my previous technical report). This leads to the treatment of the E820cycles method.

The INT15 memory specification is a specification that DOS, Windows, and all other x86 operating systems and applications adhere to. Without it, a DOS cannot use map--mem and Memdisk to create a virtual disk, because the DOS memory management software uses int15, it is possible to destroy an unprotected memory disk, causing the crash or failure to read the virtual disk.

Http://bbs.wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=327458&pid=3023958&fromuid= 298214
No, Dot. Posted on 2015-1-9 21:14:20
Grub4dos has made several efforts in resolving memory conflicts. The first effort, Gandalf found that Grub4dos always somehow crashed, and we learned that it was due to the high memory address of the GNU GRUB Legacy Protected mode stack. When some program fragments use more stacks, a panic occurs. In this context, we have made two improvements, one is to undo the protected mode stack, merge with the real schema stack, and keep only a stack, and the other is to move the array and local functions inside the C function out of the function body and no longer occupy the stack. Later, an improvement was made, that is, the recursive function is modified to non-recursive functions, using loops instead of recursion, greatly reducing the burden on the stack. As a result, there was no problem of unexplained crashes.

In order to solve the problem that the conventional memory is too little and there is not enough space to accommodate the new functional code, from 0.4.5, the protected mode code is moved to the extended memory, which solves the problem that the function cannot be extended. At first we used 16M of memory, and later it was added to 32M. With enough memory, we can then support running the user program.

Now the program code, it is possible to generate memory conflicts in some local scope. But this is all can be positioned, but also can be solved.

Http://bbs.wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=327458&pid=3051715&fromuid= 298214
No, Dot. Posted on 2015-2-26 03:47:30

Here's what you want to say to the developer.

A software can be perfected as far as possible in function. But sometimes, the improvement of functionality conflicts with hardware compatibility, forcing you to abandon part of the functionality while guaranteeing compatibility. Everything is a trade-off, and there is nothing absolutely correct in it. The concept of correctness differs depending on the angle of the problem. And not all of the user's requirements, you can be satisfied. It is possible that you have met some of the user's requirements, but have brought another problem. Software is not omnipotent, it can solve most of the problems, is the basic success. If you want to look at the problem with a limit challenge, it's trying to get the functionality to be plump, which may damage compatibility in some way. The UD mentioned in this question is blocked and I do it. Because the GRLDR starts, check to see if it is booting from UD. If yes, the UD area is treated as the current root area and the other boot steps are skipped. The advantage of having the UD area as the current default root is that the UD area is up front and can be adapted to a variety of harsh BIOS environments. Because UD is prioritized, it is not possible to continue to treat the UD zone as the current root when it is not started with UD (such as when a floppy disk image is started or when the hard disk is started). To avoid the UD flag being detected by subsequent boot commands, I erased the UD flag after the first time I detected UD. UD has been admitted at this point, but the subsequent start-up, if not directly simulating the BIOS and loading the first sector of UD, will not be able to detect the UD flag, because it was deliberately blocked out. I'm still talking about the status quo. As to whether it is reasonable to do so, I cannot guarantee it. That will be weighed and decided by the current developer. It's good to have the best of both worlds if you can do it well. If you don't want to think about it, don't bother thinking about these logic problems, you can keep the status quo. In a word, look at the developer's verdict.

When I maintain the grub4dos, for the user's question, if I can solve, I try to do it myself, so I am assured that it is because of their energy, but also worry about others do not conform to their own ideas. So we try to do it by myself. If I can't do it myself, I'll admit I can't do it and give up. After giving up, it is possible that others will be able to do the work, so this involves how the work fits into the grub4dos problem. Certainly not unconditional can be casually integrated, must undergo the test. New jobs often lead to new problems. Sometimes the problem will soon be revealed. But sometimes the problem lurks deep and takes years to get exposed. For example, the original GNU GRUB legacy inside the NTFS code has a problem, I do not have the ability to write NTFS code, and even do not have the ability to read the NTFS code in Linux, so there is no way to solve the problem of NTFS. Then the Bean joins the team and the bean can do the work, and the current code is the bean. While the bean does this work, it also retains the old code as if it were named Fsys_ntfs.old, which means that if not, the original code can be restored. After many years of testing, there is no problem, so the old code seems to have been deleted. The new code in fact is not completely no problem, many years later, Chenall and Yaya have found some problems, and solved. Another example is the improvement and enhancement of Yaya for Grub4dos. We have seen that some problems, such as problems in MBR and PBR code, have only recently been discovered and resolved. It can be seen that some problems lurk for a long time. Why we have long maintained the two version, one is 0.4.5c, one is 0.4.6a, that is, because the new features need to have a temper process, the new features may affect the success rate of startup, there may be compatibility and other issues. If these problems can be solved, then you can safely use the new version. The old version, as a reference, retains its value forever. Different users according to their own needs, choose a different version. The Scdrom code provided by Gandalf, as if there was a memory conflict, was unstable, and later I transplanted the CDROM code of the smart Boot manager, replacing the Gandalf code. Also Gandalf, the Chinese culture code that he did based on the VGA graphics pattern was very stable, and we kept it down until we completely turned to VBE. CDROM driver support is the first introduction of Gandalf, he has a pioneering work, can not be erased. The point I'm talking about is that the stability of the code and the subsequent performance is neededTemper the. This is by no means a denial of the value of the initial work. Similarly, the Bean's Gfxmenu graphical menu also fills the vacancy at the time. Just because Gfxmenu natural independence, it is different from Grub4dos's built-in code, it is called external message inside the code, so it is not easy to connect with grub4dos seamlessly. Therefore, we later recommend using the new VBE graphical menu mode. Karyonix provided a few patches, have been directly adopted, after several years of testing, proved to be no problem. The author of the familiar Winvblock software is Shao Miller, who is also a member of the Syslinux development team. He provided a patch related to the Eltorito cdrom, which I thought could be adopted at the outset. But then I think carefully, or strict requirements, is technology to speak technology, in the better and the best there is a little difference, since can do the best or better, you can not retreat and seek the second. I removed Shao Miller's patch as a "should avoid taking up valuable int13 code space" and after getting Chenall's consent. At the same time I eltorito.sys this software patch, and included in the Grub4dos internal maintenance together. This is "both ways to achieve the goal, but what is the best?" "The problem. I advocate modifying the Eltorito.sys software, while Shao Miller advocates modifying Grub4dos's int13 handlers. This is where the differences lie. If it is only by feeling and taking care of the face, it should certainly adopt Shao Miller's patch. But I thought over and over and felt that not adopting his patch was the greatest respect for Shao Miller. Because I feel that it is a higher demand for him, he does not belong to the kind of people who need to take care of face, so I actually admit and respect his level. If you want to take care of the face of a person, in fact, it is denied the high level of the person, and therefore counterproductive, instead of taking care of his face. In my opinion, pointing out the flaw in one's work is a great respect for him. Similarly, if someone points out my flaws, I also think that is respect for me, is honeys me. Add: From the perspective of later practice and the long-term development of the future, it seems more and more obvious that the practice of maintaining int13 is not changed. DOS is more and more difficult to adapt to the poor BIOS environment, and now DOS is basically as a second boot, that is, start grub4dos or Syslinux First, then start DOS. In particular, DOS as the protagonist of the Eltorito CD-ROM, has been very uncommon. GrUb4dos's user base, mostly windows. Therefore, if INT13 is modified only for narrow, increasingly marginalized areas, the use of such modifications is extremely low and is not used in most cases. And it takes up more than 10 bytes of valuable INT13 code space, it becomes more and more unreasonable. So everything is a trade-off. Perhaps something is reasonable at first glance, but after some careful weighing and analysis, its irrationality is exposed.

The past is all history. History can be used for reference, and history can be judged. There is no absolute right and wrong, only their own trade-offs and tendencies. The world is big and the freedom is great. Especially for open source software, the degree of freedom is quite large. There are many ways to deal with things that are not satisfactory to them, including a second one. I had to submit a patch to the GNU Grub Development Team and was not accepted, so I was forced to reinvent the board. This is completely replicable, and "reinvent the stove" is always an option. Anyone, as long as he wants, can have a stove.

Now that I'm out of the developer, I'm not making any decisions or tradeoffs anymore. What I have done in the past can be used for reference. Of course, those that are inappropriate should also be corrected. This is the responsibility of the current maintainer.

I have my advantages and disadvantages. From recent years with the defenders, developers and friends inside and outside the altar to see, I have experienced a master such as the cloud. Remember before someone said, Hu Jung is not the first chess person, there are a lot of folk have not seen the master can win Hu Jung. My personal strengths and advantages are not in the area of computer technology. For example, Chenall and Yaya are great. During my convalescence, I witnessed Chenall and Yaya's cooperation, their computer skills are above me, so I am also really happy, so I am completely relieved. Although my English is also shameful, I am willing to do some work for developers when I have the opportunity, because I find that the two developers who are currently active do not seem to be good at English.

I thought of Jaclaz, the Italians, and said a few more words. He later renamed Wonko the Sane. The man kept his word. Many years ago, when the English forum was boot-land.net, it was reboot.pro. At that time I asked him to do the promotion for grub4dos. He promised. Unexpectedly, all these years he insisted on answering Grub4dos's questions, never interrupted, ever lax, awe--

About the E820cycles parameter