XP Setup freezes with versions after 0.4.5b-2011-07-14

Machine is Dell Latitude E6400, BIOS A25.

Starting XP Setup from USB stick using small ISO method as in here:
http://www.msfn.org/...aded-small-iso/

In past, on that machine starting XP Setup using using memory mapped small ISO leaded Setup to hang with black/blank screen at Text mode on some newer machines.

map --mem /WIN_SETUP/2000.ISO (0xff)

map (hd0) (hd1)

map (hd1) (hd0)

map --hook

root (0xff)

chainloader /I386/SETUPLDR.BIN

http://www.msfn.org/...all-iso-method/

Using non-memory mapped ISO was the trick to get it going.

map /WIN_SETUP/2000.ISO (0xff)

There were similar reports for the same hangs on new machines using map --mem and XP setup from ISO using firadisk/winvblock drivers.
http://reboot.pro/88...post__p__139700
http://reboot.pro/13...ge__pid__115165

Now the new issue- since grub4dos versions after 0.4.5b-2011-07-14, even though NOT using memory mapped small ISO, Setup hangs the same way with black/blank screen.
Tested many grub4dos versions from 2011-06-02 to 2011-12-02 and the issue seems to start with 2011-07-24 version, with 2011-07-14 being the last not leading to hangs using that method for installing from USB.

Try using a line of

map --e820cycles=0

just before "map --hook"

Some Windows device drivers are so buggy that they do NOT allow the int15 to be hooked by any handlers other than ROM BIOS. They will simply "commit suicide" or kill itself with BSOD or a hangup, if they detect a hooked int15.

Reports say grub4dos (as well as memdisk) would fail to start Windows(or PE) on hooking int15.

With "map --e820cycles=0", the int15 will never be hooked by grub4dos int13_handler. And this will workaround the issue.

The manufacturer and/or the device driver maker are suspected of having made this trouble on purpose. They might want to defeat(or kill) open-souce softwares, as one of their purposes.

Older grub4dos'es than 2011-7-14 will never hook int15 on a non-mem mapping, so they might encounter no problems.

Newer grub4dos'es will hook int15 by default even for non-mem mappings. So you might have to use "map --e820cycles=0" explicitly to prevent int15 hooking.

The default (and correct) value for e820cycles is (-1):

map --e820cycles=-1

If you have to use other values than -1 for a successful run of your software(PE or Windows), then this indicates that your hardware or your software(device driver in Windows) was making trouble. For your buggy software or hardware, you may try these values:

map --e820cycles=0
map --e820cycles=1
map --e820cycles=2
map --e820cycles=3
map --e820cycles=4
map --e820cycles=5
.............. etc ..............

Thanks tinybit, quite useful explanation.
map --e820cycles=0 solved the freezing in both cases, with memory and non-memory mapped ISO.

Is this going to be default grub4dos behaviour in future?
Would a line map --e820cycles=0 affect older grub4dos versions? Should we be checking the grub4dos version before using that option? I guess this is the relevant change:

2011-08-05 (tinybit)added a map option --e820cycles for Dell Laptop N4030.

Are there cases where using that option would affect functionality in a negative way and shouldn't be used?

i never thought of this, because i didn't do setup so often, i thought it was nLite's fault!

thanks for doing what i failed to do, ilko... Asking someone here.

Edited by ignored, 05 December 2011 - 08:48 PM.

@ilko

As you have noticed, --e820cycles is a new option, so it will not work with old versions. You should use the default

map --e820cycles=-1

Using any other value than -1 will be wrong.

But for the buggy hardware/software, you might have to use the wrong ones, or else the software will self-kill.

"map --e820cycles=-1" means int15 always hook.

"map --e820cycles=0" means int15 never hook.

"map --e820cycles=1" means int15 will hook at first, but after 1 cycle of call to int15 E820, it will off-hook and no longer hook again.

"map --e820cycles=2" means int15 will hook at first, but after 2 cycles of call to int15 E820, it will off-hook and no longer hook again.

"map --e820cycles=3" means int15 will hook at first, but after 3 cycles of call to int15 E820, it will off-hook and no longer hook again.

"map --e820cycles=4" means int15 will hook at first, but after 4 cycles of call to int15 E820, it will off-hook and no longer hook again.

Here "off-hook" means the grub4dos int15 E820 handler will not hook, and the original ROM int15 entry will be restored to the interrupt vector table.

Q: Is "map --e820cycles=0" going to be default grub4dos behaviour in future?

A: No. Never. The default will be(and should be) "map --e820cycles=-1" forever.

Thanks tinybit, quite useful explanation.
map --e820cycles=0 solved the freezing in both cases, with memory and non-memory mapped ISO.

Is this going to be default grub4dos behaviour in future?
Would a line map --e820cycles=0 affect older grub4dos versions? Should we be checking the grub4dos version before using that option? I guess this is the relevant change:

Are there cases where using that option would affect functionality in a negative way and shouldn't be used?

yes , there are few cases where user this method would hang the PE in loading final kernel files , specially it was reported in 0PE by pseudo , so it should be there just as a Backup , when things wont go as expected .

further TINYBIT brother can explain.

good luck my friend...

Q: Is "map --e820cycles=0" going to be default grub4dos behaviour in future?

A: No. Never. The default will be(and should be) "map --e820cycles=-1" forever.

Thanks. I meant if map --e820cycles=-1 is going to be default behaviour but didn't make it clear.
Thanks again for all your help and work on grub4dos.

yes , there are few cases where user this method would hang the PE in loading final kernel files , specially it was reported in 0PE by pseudo , so it should be there just as a Backup , when things wont go as expected .

further TINYBIT brother can explain.

good luck my friend...

Thanks, do you have any links for details?

Thanks ilko for pointing me to this thread.

 

The "map --e820cycles=0" option solved my laptop issue which I  mentioned in this post:

http://reboot.pro/to...-5#entry172366 

 

Cheers,

Dave N