Xen's automated test system is reporting[1] that something between bfb7b58b3068 and 136d4ec190af (for reference the previous pass is[2]) has broken booting winxp under Xen with Seabios.
Logs for one of the failures can be found at[3] (reached by following the email's link to [4] and clicking the header of a failing column). The VNC screenshot of the guest shows "Setup is inspecting your hardware configuration..." (at least for those which have such a screenshot, not sure why some don't).
I've not investigated more thoroughly yes, just posting in case something obvious leaps out at someone. The automated test is currently bisecting the issue, once it is done I'll let you know the result.
[1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg03543.html [2] http://lists.xen.org/archives/html/xen-devel/2014-10/msg01993.html [3] http://www.chiark.greenend.org.uk/~xensrcts/logs/31223/test-amd64-i386-xl-qe... [4] http://www.chiark.greenend.org.uk/~xensrcts/logs/31223/
On Mon, 2014-11-03 at 09:59 +0000, Ian Campbell wrote:
I've not investigated more thoroughly yes, just posting in case something obvious leaps out at someone. The automated test is currently bisecting the issue, once it is done I'll let you know the result.
If I'd read a bit further through my Monday morning INBOX I'd have found: http://lists.xen.org/archives/html/xen-devel/2014-11/msg00001.html
which indicates that the bisector has fingered:
commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f Author: Kevin O'Connor kevin@xxxxxxxxxxxx Date: Tue Oct 21 14:34:06 2014 -0400
Do full BREGS backup/restore for pmm, pnp, and irqentry_extrastack
Although these entry points only require backup and restore of the registers that the C code clobbers, there is no harm in backing up some additional registers. This allows the BREGS macros to be used which makes the code a little more readable.
Signed-off-by: Kevin O'Connor kevin@xxxxxxxxxxxx
Ian.
[1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg03543.html [2] http://lists.xen.org/archives/html/xen-devel/2014-10/msg01993.html [3] http://www.chiark.greenend.org.uk/~xensrcts/logs/31223/test-amd64-i386-xl-qe... [4] http://www.chiark.greenend.org.uk/~xensrcts/logs/31223/
Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Mon, Nov 03, 2014 at 10:05:05AM +0000, Ian Campbell wrote:
On Mon, 2014-11-03 at 09:59 +0000, Ian Campbell wrote:
I've not investigated more thoroughly yes, just posting in case something obvious leaps out at someone. The automated test is currently bisecting the issue, once it is done I'll let you know the result.
If I'd read a bit further through my Monday morning INBOX I'd have found: http://lists.xen.org/archives/html/xen-devel/2014-11/msg00001.html
which indicates that the bisector has fingered:
commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
Sorry about that - I missed one of the stack offset conversions in the PNP part of that change. The fix is below and I just pushed it to the main repo.
Thanks for catching it. -Kevin
--- a/src/romlayout.S +++ b/src/romlayout.S @@ -286,7 +286,7 @@ entry_pnp_real: movw %cx, %ds leal BREGS_size-6+12(%esp), %eax // %eax points to start of u16 args calll handle_pnp - movw %ax, 12(%esp) // Modify %eax to return %ax + movw %ax, BREGS_eax(%esp) // Modify %eax to return %ax POPBREGS popfl popl %esp
On Mon, 2014-11-03 at 09:59 -0500, Kevin O'Connor wrote:
On Mon, Nov 03, 2014 at 10:05:05AM +0000, Ian Campbell wrote:
On Mon, 2014-11-03 at 09:59 +0000, Ian Campbell wrote:
I've not investigated more thoroughly yes, just posting in case something obvious leaps out at someone. The automated test is currently bisecting the issue, once it is done I'll let you know the result.
If I'd read a bit further through my Monday morning INBOX I'd have found: http://lists.xen.org/archives/html/xen-devel/2014-11/msg00001.html
which indicates that the bisector has fingered:
commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
Sorry about that - I missed one of the stack offset conversions in the PNP part of that change. The fix is below and I just pushed it to the main repo.
Thanks for catching it.
Thanks for the quick fix!
-Kevin
--- a/src/romlayout.S +++ b/src/romlayout.S @@ -286,7 +286,7 @@ entry_pnp_real: movw %cx, %ds leal BREGS_size-6+12(%esp), %eax // %eax points to start of u16 args calll handle_pnp
movw %ax, 12(%esp) // Modify %eax to return %ax
movw %ax, BREGS_eax(%esp) // Modify %eax to return %ax POPBREGS popfl popl %esp
On Mon, 2014-11-03 at 15:42 +0000, Ian Campbell wrote:
On Mon, 2014-11-03 at 09:59 -0500, Kevin O'Connor wrote:
On Mon, Nov 03, 2014 at 10:05:05AM +0000, Ian Campbell wrote:
On Mon, 2014-11-03 at 09:59 +0000, Ian Campbell wrote:
I've not investigated more thoroughly yes, just posting in case something obvious leaps out at someone. The automated test is currently bisecting the issue, once it is done I'll let you know the result.
If I'd read a bit further through my Monday morning INBOX I'd have found: http://lists.xen.org/archives/html/xen-devel/2014-11/msg00001.html
which indicates that the bisector has fingered:
commit 99cb8f3e9af516954b2f2fba97ce1856e3d7b93f
Sorry about that - I missed one of the stack offset conversions in the PNP part of that change. The fix is below and I just pushed it to the main repo.
Thanks for catching it.
Thanks for the quick fix!
FYI the next Xen osstest run didn't suffer from this issue, thanks.
(in case you go looking at the results, it did fail for other Xen related reasons, nothing to do with seabios, but this issue is definitely gone.)
-Kevin
--- a/src/romlayout.S +++ b/src/romlayout.S @@ -286,7 +286,7 @@ entry_pnp_real: movw %cx, %ds leal BREGS_size-6+12(%esp), %eax // %eax points to start of u16 args calll handle_pnp
movw %ax, 12(%esp) // Modify %eax to return %ax
movw %ax, BREGS_eax(%esp) // Modify %eax to return %ax POPBREGS popfl popl %esp
SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
-
Ian Campbell -
Kevin O'Connor