Post Reply 
Thread Rating:
  • 1 Vote(s) - 4 Average
  • 1
  • 2
  • 3
  • 4
  • 5
iPXE problems with iSCSI Boot and Windows
2016-03-12, 21:50
Post: #10
RE: iPXE problems with iSCSI Boot and Windows
Bringing the answer from ipxedevel.list: Please use the latest GIT Version (cc9f31 or later); MCB noted a regression and fixed in this commit:

<quote>librm] Do not unconditionally preserve flags across virt_call()

Commit 196f0f2 ("[librm] Convert prot_call() to a real-mode near
call") introduced a regression in which any deliberate modification to
the low 16 bits of the CPU flags (in struct i386_all_regs) would be
overwritten with the original flags value at the time of entry to

The regression arose because the alignment requirements of the
protected-mode stack necessitated the insertion of two bytes of
padding immediately below the prot_call() return address. The
solution chosen was to extend the existing "pushfl / popfl" pair to
"pushfw;pushfl / popfl;popfw". The extra "pushfw / popfw" appears at
first glance to be a no-op, but fails to take into account the fact
that the flags restored by popfl may have been deliberately modified
by the protected-mode function.

Fix by replacing "pushfw / popfw" with "pushw %ss / popw %ss". While
%ss does appear within struct i386_all_regs, any modification to the
stored value has always been ignored by prot_call() anyway.

The most visible symptom of this regression was that SAN booting would
fail since every INT 13 call would be chained to the original INT 13

Reported-by: Vishvananda Ishaya <>
Reported-by: Jamie Thompson <></quote>



"Thus far, you have been adrift within the sheltered harbor of my patience..."
Find all posts by this user
Quote this message in a reply
Post Reply 

Messages In This Thread
RE: iPXE problems with iSCSI Boot and Windows - MultimediaMan - 2016-03-12 21:50

User(s) browsing this thread: 1 Guest(s)