[PATCH for-4.8] ipxe: update to newer commit

[PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

The current commit in tree is rather old. It has come to a point that
cherry-picking commits from upstream isn't trivial anymore.

There is long term plan to track ipxe upstream, but for 4.8 release, we
should just update ipxe to a newer commit (they are using rolling
release model now).

Forward-port the one boot prompt patch that is still relevant and retire
the rest which are already in upstream.

Reported-by: Juergen Schinker <ba1020@homie.homelinux.net>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Juergen Schinker <ba1020@homie.homelinux.net>
---
 tools/firmware/etherboot/Makefile                  |   2 +-
 .../etherboot/patches/boot_prompt_option.patch     |  28 ++-
 .../firmware/etherboot/patches/build-compare.patch |  19 --
 tools/firmware/etherboot/patches/build_fix_1.patch |  28 ---
 tools/firmware/etherboot/patches/build_fix_2.patch |  48 -----
 tools/firmware/etherboot/patches/build_fix_3.patch |  13 --
 tools/firmware/etherboot/patches/build_fix_4.patch | 225 ---------------------
 tools/firmware/etherboot/patches/series            |   5 -
 8 files changed, 14 insertions(+), 354 deletions(-)
 delete mode 100644 tools/firmware/etherboot/patches/build-compare.patch
 delete mode 100644 tools/firmware/etherboot/patches/build_fix_1.patch
 delete mode 100644 tools/firmware/etherboot/patches/build_fix_2.patch
 delete mode 100644 tools/firmware/etherboot/patches/build_fix_3.patch
 delete mode 100644 tools/firmware/etherboot/patches/build_fix_4.patch

diff --git a/tools/firmware/etherboot/Makefile b/tools/firmware/etherboot/Makefile
index a0578d2..459a1e2 100644
--- a/tools/firmware/etherboot/Makefile
+++ b/tools/firmware/etherboot/Makefile
@@ -10,7 +10,7 @@ else
 IPXE_GIT_URL ?= git://git.ipxe.org/ipxe.git
 endif
 
-IPXE_GIT_TAG := 9a93db3f0947484e30e753bbd61a10b17336e20e
+IPXE_GIT_TAG := 827dd1bfee67daa683935ce65316f7e0f057fe1c
 
 IPXE_TARBALL_URL ?= $(XEN_EXTFILES_URL)/ipxe-git-$(IPXE_GIT_TAG).tar.gz
 
diff --git a/tools/firmware/etherboot/patches/boot_prompt_option.patch b/tools/firmware/etherboot/patches/boot_prompt_option.patch
index 25d72c5..aed0bf0 100644
--- a/tools/firmware/etherboot/patches/boot_prompt_option.patch
+++ b/tools/firmware/etherboot/patches/boot_prompt_option.patch
@@ -1,24 +1,22 @@
-diff --git a/src/arch/i386/prefix/romprefix.S b/src/arch/i386/prefix/romprefix.S
-index 0f92415..cce7505 100644
---- a/src/arch/i386/prefix/romprefix.S
-+++ b/src/arch/i386/prefix/romprefix.S
-@@ -391,6 +391,7 @@ no_pmm:
- 	xorw	%di, %di
- 	cs rep	movsb
- 
+--- a/src/arch/x86/prefix/romprefix.S	2016-10-10 13:09:18.126031400 +0100
++++ b/src/arch/x86/prefix/romprefix.S	2016-10-10 13:11:22.930680278 +0100
+@@ -468,6 +468,7 @@
+ 	testb	$PCI_FUNC_MASK, init_pci_busdevfn
+ 	jnz	no_shell
+ .endif
 +#ifndef NO_POST_PROMPT
  	/* Prompt for POST-time shell */
  	movw	$init_message_prompt, %si
  	xorw	%di, %di
-@@ -418,6 +419,7 @@ no_pmm:
+@@ -495,6 +496,7 @@
  	pushw	%cs
  	call	exec
- 2:
 +#endif
- 	/* Restore registers */
- 	popw	%gs
- 	popw	%fs
-@@ -546,6 +548,7 @@ init_message_pmm:
+ no_shell:
+ 	movb	$( '\n' ), %al
+ 	xorw	%di, %di
+ 	call	print_character
+@@ -636,6 +638,7 @@
  init_message_int19:
  	.asciz	" INT19"
  	.size	init_message_int19, . - init_message_int19
@@ -26,7 +24,7 @@ index 0f92415..cce7505 100644
  init_message_prompt:
  	.asciz	"\nPress Ctrl-B to configure "
  	.size	init_message_prompt, . - init_message_prompt
-@@ -555,6 +558,7 @@ init_message_dots:
+@@ -645,6 +648,7 @@
  init_message_done:
  	.asciz	"\n\n"
  	.size	init_message_done, . - init_message_done
diff --git a/tools/firmware/etherboot/patches/build-compare.patch b/tools/firmware/etherboot/patches/build-compare.patch
deleted file mode 100644
index d41f68b..0000000
--- a/tools/firmware/etherboot/patches/build-compare.patch
+++ /dev/null
@@ -1,19 +0,0 @@
-The result of $(wildcard *) is random.
-Sort input files to reduce build-compare noise.
----
- ipxe/src/Makefile.housekeeping |    2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-Index: ipxe/src/Makefile.housekeeping
-===================================================================
---- ipxe/src/Makefile.housekeeping
-+++ ipxe/src/Makefile.housekeeping
-@@ -773,7 +773,7 @@ BLIB		= $(BIN)/blib.a
- $(BLIB) : $(BLIB_OBJS) $(BLIB_LIST) $(MAKEDEPS)
- 	$(Q)$(RM) $(BLIB)
- 	$(QM)$(ECHO) "  [AR] $@"
--	$(Q)$(AR) r $@ $(BLIB_OBJS)
-+	$(Q)$(AR) r $@ $(sort $(BLIB_OBJS))
- 	$(Q)$(RANLIB) $@
- blib : $(BLIB)
- 
diff --git a/tools/firmware/etherboot/patches/build_fix_1.patch b/tools/firmware/etherboot/patches/build_fix_1.patch
deleted file mode 100644
index 9eacb9b..0000000
--- a/tools/firmware/etherboot/patches/build_fix_1.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-Fix compile error in isabus_probe with gcc 4.7
-
-The copy of ipxe used during Xen tools build does not define
-ISA_PROBE_ADDRS. As a result isa_extra_probe_addrs[] has a size of 0.
-ISA_IOADDR() tries to access that empty array, which is detected by the
-newer gcc (or perhaps the warning was just turned into an error)
-
-drivers/bus/isa.c: In function 'isabus_probe':
-drivers/bus/isa.c:112:18: error: array subscript is above array bounds [-Werror=array-bounds]
-
----
- src/drivers/bus/isa.c |    3 +++
- 1 file changed, 3 insertions(+)
-
-Index: ipxe/src/drivers/bus/isa.c
-===================================================================
---- ipxe.orig/src/drivers/bus/isa.c
-+++ ipxe/src/drivers/bus/isa.c
-@@ -97,6 +97,9 @@ static int isabus_probe ( struct root_de
- 	int ioidx;
- 	int rc;
- 
-+	if ( ISA_EXTRA_PROBE_ADDR_COUNT == 0 )
-+		return 0;
-+
- 	for_each_table_entry ( driver, ISA_DRIVERS ) {
- 		for ( ioidx = ISA_IOIDX_MIN ( driver ) ;
- 		      ioidx <= ISA_IOIDX_MAX ( driver ) ; ioidx++ ) {
diff --git a/tools/firmware/etherboot/patches/build_fix_2.patch b/tools/firmware/etherboot/patches/build_fix_2.patch
deleted file mode 100644
index da24ddd..0000000
--- a/tools/firmware/etherboot/patches/build_fix_2.patch
+++ /dev/null
@@ -1,48 +0,0 @@
-fix compile error in isabus_probe with gcc4.7
-
-The copy of ipxe used during Xen tools build fails to compile with gcc
-4.7:
-drivers/net/myri10ge.c: In function 'myri10ge_command':
-drivers/net/myri10ge.c:308:3: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
-drivers/net/myri10ge.c:310:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
-
-This patch simply turns the pad array into quantities of u32.
-If thats not the right fix due to hardware limitations, I can provide a
-different patch.
-
----
- src/drivers/net/myri10ge.c     |    6 +++---
- src/drivers/net/myri10ge_mcp.h |    2 +-
- 2 files changed, 4 insertions(+), 4 deletions(-)
-
-Index: ipxe/src/drivers/net/myri10ge.c
-===================================================================
---- ipxe.orig/src/drivers/net/myri10ge.c
-+++ ipxe/src/drivers/net/myri10ge.c
-@@ -304,10 +304,10 @@ static int myri10ge_command ( struct myr
- 	command->response_addr.high = 0;
- 	command->response_addr.low
- 		= htonl ( virt_to_bus ( &priv->dma->command_response ) );
--	for ( i=0; i<36; i+=4 )
--		* ( uint32 * ) &command->pad[i] = 0;
-+	for ( i=0; i<9; i++ )
-+		command->pad[i] = 0;
- 	wmb();
--	* ( uint32 * ) &command->pad[36] = 0;
-+	command->pad[9] = 0;
- 
- 	/* Wait up to 2 seconds for a response. */
- 
-Index: ipxe/src/drivers/net/myri10ge_mcp.h
-===================================================================
---- ipxe.orig/src/drivers/net/myri10ge_mcp.h
-+++ ipxe/src/drivers/net/myri10ge_mcp.h
-@@ -80,7 +80,7 @@ struct mcp_cmd {
-   /* 16 */
-   struct mcp_dma_addr response_addr;
-   /* 24 */
--  uint8_t pad[40];
-+  uint32_t pad[10];
- };
- typedef struct mcp_cmd mcp_cmd_t;
- 
diff --git a/tools/firmware/etherboot/patches/build_fix_3.patch b/tools/firmware/etherboot/patches/build_fix_3.patch
deleted file mode 100644
index 13eeb47..0000000
--- a/tools/firmware/etherboot/patches/build_fix_3.patch
+++ /dev/null
@@ -1,13 +0,0 @@
-diff --git a/src/drivers/infiniband/qib7322.c b/src/drivers/infiniband/qib7322.c
-index b66f8ef..d8a54c9 100644
---- a/src/drivers/infiniband/qib7322.c
-+++ b/src/drivers/infiniband/qib7322.c
-@@ -2120,7 +2120,7 @@ static int qib7322_ahb_write ( struct qib7322 *qib7322, unsigned int location,
-  */
- static int qib7322_ahb_mod_reg ( struct qib7322 *qib7322, unsigned int location,
- 				 uint32_t value, uint32_t mask ) {
--	uint32_t old_value;
-+	uint32_t old_value = 0;
- 	uint32_t new_value;
- 	int rc;
- 
diff --git a/tools/firmware/etherboot/patches/build_fix_4.patch b/tools/firmware/etherboot/patches/build_fix_4.patch
deleted file mode 100644
index 9271c8c..0000000
--- a/tools/firmware/etherboot/patches/build_fix_4.patch
+++ /dev/null
@@ -1,225 +0,0 @@
-From 1b56452121672e6408c38ac8926bdd6998a39004 Mon Sep 17 00:00:00 2001
-From: Christian Hesse <mail@eworm.de>
-Date: Thu, 23 Apr 2015 13:33:26 +0200
-Subject: [PATCH] [ath9k] Remove confusing logic inversion in an ANI variable
-
-This changed in Linux kernel the same way in commit 7067e701
-("ath9k_hw: remove confusing logic inversion in an ANI variable") by
-Felix Fietkau.
-
-Additionally this fixes "error: logical not is only applied to the
-left hand side of comparison" with GCC 5.1.0.
-
-Signed-off-by: Christian Hesse <mail@eworm.de>
-Signed-off-by: Michael Brown <mcb30@ipxe.org>
----
- src/drivers/net/ath/ath9k/ani.h              |  2 +-
- src/drivers/net/ath/ath9k/ath9k_ani.c        | 16 ++++++++--------
- src/drivers/net/ath/ath9k/ath9k_ar5008_phy.c | 18 +++++++++---------
- src/drivers/net/ath/ath9k/ath9k_ar9003_phy.c | 12 ++++++------
- 4 files changed, 24 insertions(+), 24 deletions(-)
-
-diff --git a/src/drivers/net/ath/ath9k/ani.h b/src/drivers/net/ath/ath9k/ani.h
-index dbd4d4d..ba87ba0 100644
---- a/src/drivers/net/ath/ath9k/ani.h
-+++ b/src/drivers/net/ath/ath9k/ani.h
-@@ -125,7 +125,7 @@ struct ar5416AniState {
- 	u8 mrcCCKOff;
- 	u8 spurImmunityLevel;
- 	u8 firstepLevel;
--	u8 ofdmWeakSigDetectOff;
-+	u8 ofdmWeakSigDetect;
- 	u8 cckWeakSigThreshold;
- 	u32 listenTime;
- 	int32_t rssiThrLow;
-diff --git a/src/drivers/net/ath/ath9k/ath9k_ani.c b/src/drivers/net/ath/ath9k/ath9k_ani.c
-index ff7df49..76ca79c 100644
---- a/src/drivers/net/ath/ath9k/ath9k_ani.c
-+++ b/src/drivers/net/ath/ath9k/ath9k_ani.c
-@@ -177,7 +177,7 @@ static void ath9k_hw_ani_ofdm_err_trigger_old(struct ath_hw *ah)
- 
- 	rssi = BEACON_RSSI(ah);
- 	if (rssi > aniState->rssiThrHigh) {
--		if (!aniState->ofdmWeakSigDetectOff) {
-+		if (aniState->ofdmWeakSigDetect) {
- 			if (ath9k_hw_ani_control(ah,
- 					 ATH9K_ANI_OFDM_WEAK_SIGNAL_DETECTION,
- 					 0)) {
-@@ -192,7 +192,7 @@ static void ath9k_hw_ani_ofdm_err_trigger_old(struct ath_hw *ah)
- 			return;
- 		}
- 	} else if (rssi > aniState->rssiThrLow) {
--		if (aniState->ofdmWeakSigDetectOff)
-+		if (!aniState->ofdmWeakSigDetect)
- 			ath9k_hw_ani_control(ah,
- 				     ATH9K_ANI_OFDM_WEAK_SIGNAL_DETECTION,
- 				     1);
-@@ -202,7 +202,7 @@ static void ath9k_hw_ani_ofdm_err_trigger_old(struct ath_hw *ah)
- 		return;
- 	} else {
- 		if ((ah->dev->channels + ah->dev->channel)->band == NET80211_BAND_2GHZ) {
--			if (!aniState->ofdmWeakSigDetectOff)
-+			if (aniState->ofdmWeakSigDetect)
- 				ath9k_hw_ani_control(ah,
- 				     ATH9K_ANI_OFDM_WEAK_SIGNAL_DETECTION,
- 				     0);
-@@ -360,7 +360,7 @@ static void ath9k_hw_ani_lower_immunity_old(struct ath_hw *ah)
- 	if (rssi > aniState->rssiThrHigh) {
- 		/* XXX: Handle me */
- 	} else if (rssi > aniState->rssiThrLow) {
--		if (aniState->ofdmWeakSigDetectOff) {
-+		if (!aniState->ofdmWeakSigDetect) {
- 			if (ath9k_hw_ani_control(ah,
- 				 ATH9K_ANI_OFDM_WEAK_SIGNAL_DETECTION,
- 				 1) == 1)
-@@ -436,9 +436,9 @@ static void ath9k_ani_reset_old(struct ath_hw *ah)
- 	if (aniState->spurImmunityLevel != 0)
- 		ath9k_hw_ani_control(ah, ATH9K_ANI_SPUR_IMMUNITY_LEVEL,
- 				     aniState->spurImmunityLevel);
--	if (aniState->ofdmWeakSigDetectOff)
-+	if (!aniState->ofdmWeakSigDetect)
- 		ath9k_hw_ani_control(ah, ATH9K_ANI_OFDM_WEAK_SIGNAL_DETECTION,
--				     !aniState->ofdmWeakSigDetectOff);
-+				     aniState->ofdmWeakSigDetect);
- 	if (aniState->cckWeakSigThreshold)
- 		ath9k_hw_ani_control(ah, ATH9K_ANI_CCK_WEAK_SIGNAL_THR,
- 				     aniState->cckWeakSigThreshold);
-@@ -709,8 +709,8 @@ void ath9k_hw_ani_init(struct ath_hw *ah)
- 
- 		ani->rssiThrHigh = ATH9K_ANI_RSSI_THR_HIGH;
- 		ani->rssiThrLow = ATH9K_ANI_RSSI_THR_LOW;
--		ani->ofdmWeakSigDetectOff =
--			!ATH9K_ANI_USE_OFDM_WEAK_SIG;
-+		ani->ofdmWeakSigDetect =
-+			ATH9K_ANI_USE_OFDM_WEAK_SIG;
- 		ani->cckNoiseImmunityLevel = ATH9K_ANI_CCK_DEF_LEVEL;
- 	}
- 
-diff --git a/src/drivers/net/ath/ath9k/ath9k_ar5008_phy.c b/src/drivers/net/ath/ath9k/ath9k_ar5008_phy.c
-index 60e87e9..2b6c133 100644
---- a/src/drivers/net/ath/ath9k/ath9k_ar5008_phy.c
-+++ b/src/drivers/net/ath/ath9k/ath9k_ar5008_phy.c
-@@ -1141,12 +1141,12 @@ static int ar5008_hw_ani_control_old(struct ath_hw *ah,
- 			REG_CLR_BIT(ah, AR_PHY_SFCORR_LOW,
- 				    AR_PHY_SFCORR_LOW_USE_SELF_CORR_LOW);
- 
--		if (!on != aniState->ofdmWeakSigDetectOff) {
-+		if (on != aniState->ofdmWeakSigDetect) {
- 			if (on)
- 				ah->stats.ast_ani_ofdmon++;
- 			else
- 				ah->stats.ast_ani_ofdmoff++;
--			aniState->ofdmWeakSigDetectOff = !on;
-+			aniState->ofdmWeakSigDetect = on;
- 		}
- 		break;
- 	}
-@@ -1215,10 +1215,10 @@ static int ar5008_hw_ani_control_old(struct ath_hw *ah,
- 
- 	DBG2("ath9k: ANI parameters:\n");
- 	DBG2(
--		"noiseImmunityLevel=%d, spurImmunityLevel=%d, ofdmWeakSigDetectOff=%d\n",
-+		"noiseImmunityLevel=%d, spurImmunityLevel=%d, ofdmWeakSigDetect=%d\n",
- 		aniState->noiseImmunityLevel,
- 		aniState->spurImmunityLevel,
--		!aniState->ofdmWeakSigDetectOff);
-+		aniState->ofdmWeakSigDetect);
- 	DBG2(
- 		"cckWeakSigThreshold=%d, firstepLevel=%d, listenTime=%d\n",
- 		aniState->cckWeakSigThreshold,
-@@ -1307,18 +1307,18 @@ static int ar5008_hw_ani_control_new(struct ath_hw *ah,
- 			REG_CLR_BIT(ah, AR_PHY_SFCORR_LOW,
- 				    AR_PHY_SFCORR_LOW_USE_SELF_CORR_LOW);
- 
--		if (!on != aniState->ofdmWeakSigDetectOff) {
-+		if (on != aniState->ofdmWeakSigDetect) {
- 			DBG2("ath9k: "
- 				"** ch %d: ofdm weak signal: %s=>%s\n",
- 				chan->channel,
--				!aniState->ofdmWeakSigDetectOff ?
-+				aniState->ofdmWeakSigDetect ?
- 				"on" : "off",
- 				on ? "on" : "off");
- 			if (on)
- 				ah->stats.ast_ani_ofdmon++;
- 			else
- 				ah->stats.ast_ani_ofdmoff++;
--			aniState->ofdmWeakSigDetectOff = !on;
-+			aniState->ofdmWeakSigDetect = on;
- 		}
- 		break;
- 	}
-@@ -1467,7 +1467,7 @@ static int ar5008_hw_ani_control_new(struct ath_hw *ah,
- 	DBG2("ath9k: "
- 		"ANI parameters: SI=%d, ofdmWS=%s FS=%d MRCcck=%s listenTime=%d ofdmErrs=%d cckErrs=%d\n",
- 		aniState->spurImmunityLevel,
--		!aniState->ofdmWeakSigDetectOff ? "on" : "off",
-+		aniState->ofdmWeakSigDetect ? "on" : "off",
- 		aniState->firstepLevel,
- 		!aniState->mrcCCKOff ? "on" : "off",
- 		aniState->listenTime,
-@@ -1554,7 +1554,7 @@ static void ar5008_hw_ani_cache_ini_regs(struct ath_hw *ah)
- 	/* these levels just got reset to defaults by the INI */
- 	aniState->spurImmunityLevel = ATH9K_ANI_SPUR_IMMUNE_LVL_NEW;
- 	aniState->firstepLevel = ATH9K_ANI_FIRSTEP_LVL_NEW;
--	aniState->ofdmWeakSigDetectOff = !ATH9K_ANI_USE_OFDM_WEAK_SIG;
-+	aniState->ofdmWeakSigDetect = ATH9K_ANI_USE_OFDM_WEAK_SIG;
- 	aniState->mrcCCKOff = 1; /* not available on pre AR9003 */
- }
- 
-diff --git a/src/drivers/net/ath/ath9k/ath9k_ar9003_phy.c b/src/drivers/net/ath/ath9k/ath9k_ar9003_phy.c
-index 6103040..2244b77 100644
---- a/src/drivers/net/ath/ath9k/ath9k_ar9003_phy.c
-+++ b/src/drivers/net/ath/ath9k/ath9k_ar9003_phy.c
-@@ -859,18 +859,18 @@ static int ar9003_hw_ani_control(struct ath_hw *ah,
- 			REG_CLR_BIT(ah, AR_PHY_SFCORR_LOW,
- 				    AR_PHY_SFCORR_LOW_USE_SELF_CORR_LOW);
- 
--		if (!on != aniState->ofdmWeakSigDetectOff) {
-+		if (on != aniState->ofdmWeakSigDetect) {
- 			DBG2("ath9k: "
- 				"** ch %d: ofdm weak signal: %s=>%s\n",
- 				chan->channel,
--				!aniState->ofdmWeakSigDetectOff ?
-+				aniState->ofdmWeakSigDetect ?
- 				"on" : "off",
- 				on ? "on" : "off");
- 			if (on)
- 				ah->stats.ast_ani_ofdmon++;
- 			else
- 				ah->stats.ast_ani_ofdmoff++;
--			aniState->ofdmWeakSigDetectOff = !on;
-+			aniState->ofdmWeakSigDetect = on;
- 		}
- 		break;
- 	}
-@@ -1013,7 +1013,7 @@ static int ar9003_hw_ani_control(struct ath_hw *ah,
- 			      AR_PHY_MRC_CCK_ENABLE, is_on);
- 		REG_RMW_FIELD(ah, AR_PHY_MRC_CCK_CTRL,
- 			      AR_PHY_MRC_CCK_MUX_REG, is_on);
--		if (!is_on != aniState->mrcCCKOff) {
-+		if (!(is_on != aniState->mrcCCKOff)) {
- 			DBG2("ath9k: "
- 				"** ch %d: MRC CCK: %s=>%s\n",
- 				chan->channel,
-@@ -1037,7 +1037,7 @@ static int ar9003_hw_ani_control(struct ath_hw *ah,
- 	DBG2("ath9k: "
- 		"ANI parameters: SI=%d, ofdmWS=%s FS=%d MRCcck=%s listenTime=%d ofdmErrs=%d cckErrs=%d\n",
- 		aniState->spurImmunityLevel,
--		!aniState->ofdmWeakSigDetectOff ? "on" : "off",
-+		aniState->ofdmWeakSigDetect ? "on" : "off",
- 		aniState->firstepLevel,
- 		!aniState->mrcCCKOff ? "on" : "off",
- 		aniState->listenTime,
-@@ -1137,7 +1137,7 @@ static void ar9003_hw_ani_cache_ini_regs(struct ath_hw *ah)
- 	/* these levels just got reset to defaults by the INI */
- 	aniState->spurImmunityLevel = ATH9K_ANI_SPUR_IMMUNE_LVL_NEW;
- 	aniState->firstepLevel = ATH9K_ANI_FIRSTEP_LVL_NEW;
--	aniState->ofdmWeakSigDetectOff = !ATH9K_ANI_USE_OFDM_WEAK_SIG;
-+	aniState->ofdmWeakSigDetect = ATH9K_ANI_USE_OFDM_WEAK_SIG;
- 	aniState->mrcCCKOff = !ATH9K_ANI_ENABLE_MRC_CCK;
- }
- 
--- 
-2.4.3
-
diff --git a/tools/firmware/etherboot/patches/series b/tools/firmware/etherboot/patches/series
index 2c39853..86cb300 100644
--- a/tools/firmware/etherboot/patches/series
+++ b/tools/firmware/etherboot/patches/series
@@ -1,6 +1 @@
 boot_prompt_option.patch
-build_fix_1.patch
-build_fix_2.patch
-build_fix_3.patch
-build-compare.patch
-build_fix_4.patch
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Ian Jackson]

Wei Liu writes ("[PATCH for-4.8] ipxe: update to newer commit"):
> The current commit in tree is rather old. It has come to a point that
> cherry-picking commits from upstream isn't trivial anymore.
> 
> There is long term plan to track ipxe upstream, but for 4.8 release, we
> should just update ipxe to a newer commit (they are using rolling
> release model now).
> 
> Forward-port the one boot prompt patch that is still relevant and retire
> the rest which are already in upstream.

As I said IRL, I think this is a goiod approach.  (I hadn't realised
we were cloning it rather than getting a tarball from xenbits...)

How did you choose 827dd1bfee67daa683935ce65316f7e0f057fe1c ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Mon, Oct 10, 2016 at 04:34:31PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.8] ipxe: update to newer commit"):
> > The current commit in tree is rather old. It has come to a point that
> > cherry-picking commits from upstream isn't trivial anymore.
> > 
> > There is long term plan to track ipxe upstream, but for 4.8 release, we
> > should just update ipxe to a newer commit (they are using rolling
> > release model now).
> > 
> > Forward-port the one boot prompt patch that is still relevant and retire
> > the rest which are already in upstream.
> 
> As I said IRL, I think this is a goiod approach.  (I hadn't realised
> we were cloning it rather than getting a tarball from xenbits...)
> 
> How did you choose 827dd1bfee67daa683935ce65316f7e0f057fe1c ?
> 

That's the latest commit -- since upstream wants us to always use the
latest, I just picked that one.

I built that commit with gcc 4.9 and gcc 6.1, both compiled OK.
Realistically I don't expect issues with nic boot roms -- those are the
only things we really use AFAICT.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Ian Jackson]

Wei Liu writes ("Re: [PATCH for-4.8] ipxe: update to newer commit"):
> On Mon, Oct 10, 2016 at 04:34:31PM +0100, Ian Jackson wrote:
> > How did you choose 827dd1bfee67daa683935ce65316f7e0f057fe1c ?
> 
> That's the latest commit -- since upstream wants us to always use the
> latest, I just picked that one.
> 
> I built that commit with gcc 4.9 and gcc 6.1, both compiled OK.
> Realistically I don't expect issues with nic boot roms -- those are the
> only things we really use AFAICT.

Err, good.  Well, perhaps we can wait a week and see if anyone reports
hideous breakage in that ipxe revision ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Mon, Oct 10, 2016 at 04:51:13PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH for-4.8] ipxe: update to newer commit"):
> > On Mon, Oct 10, 2016 at 04:34:31PM +0100, Ian Jackson wrote:
> > > How did you choose 827dd1bfee67daa683935ce65316f7e0f057fe1c ?
> > 
> > That's the latest commit -- since upstream wants us to always use the
> > latest, I just picked that one.
> > 
> > I built that commit with gcc 4.9 and gcc 6.1, both compiled OK.
> > Realistically I don't expect issues with nic boot roms -- those are the
> > only things we really use AFAICT.
> 
> Err, good.  Well, perhaps we can wait a week and see if anyone reports
> hideous breakage in that ipxe revision ?
> 

Sure. I will check ipxe mailing list in one week.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Boris Ostrovsky]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On 10/10/2016 12:33 PM, Wei Liu wrote:
> On Mon, Oct 10, 2016 at 04:51:13PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("Re: [PATCH for-4.8] ipxe: update to newer commit"):
>>> On Mon, Oct 10, 2016 at 04:34:31PM +0100, Ian Jackson wrote:
>>>> How did you choose 827dd1bfee67daa683935ce65316f7e0f057fe1c ?
>>> That's the latest commit -- since upstream wants us to always use the
>>> latest, I just picked that one.
>>>
>>> I built that commit with gcc 4.9 and gcc 6.1, both compiled OK.
>>> Realistically I don't expect issues with nic boot roms -- those are the
>>> only things we really use AFAICT.
>> Err, good.  Well, perhaps we can wait a week and see if anyone reports
>> hideous breakage in that ipxe revision ?
>>
> Sure. I will check ipxe mailing list in one week.

FWIW, here is the patch that I used to pacify gcc.

-boris

[-- Attachment #2: ipxe.patch --]
[-- Type: text/x-patch, Size: 11844 bytes --]

--- ./src/core/stringextra.c.orig	2016-09-01 13:32:19.324143538 -0400
+++ ./src/core/stringextra.c	2016-09-01 13:35:00.948147391 -0400
@@ -186,7 +186,7 @@
 {
 	char *sbegin, *send;
 
-	sbegin  = s ? s : ___strtok;
+	sbegin  = s;
 	if (!sbegin) {
 		return NULL;
 	}
--- ./src/include/nic.h.orig	2016-09-01 13:34:13.587146262 -0400
+++ ./src/include/nic.h	2016-09-01 14:02:19.043186446 -0400
@@ -199,7 +199,8 @@
 
 #undef DRIVER
 #define DRIVER(_name_text,_unused2,_unused3,_name,_probe,_disable)	  \
-	static const char _name ## _text[] = _name_text;		  \
+	static __attribute__ (( unused )) const char			\
+	_name ## _text[] = _name_text;		  \
 	static inline int						  \
 	_name ## _probe ( struct nic *nic, void *hwdev ) {		  \
 		return _probe ( nic, hwdev );				  \
--- ./src/hci/mucurses/windows.c.orig	2016-09-01 13:34:04.834146053 -0400
+++ ./src/hci/mucurses/windows.c	2016-09-01 14:11:07.750199052 -0400
@@ -16,9 +16,6 @@
  * @ret rc	return status code
  */
 int delwin ( WINDOW *win ) {
-	if ( win == NULL )
-		return ERR;
-
 	/* I think we should blank the region covered by the window -
 	   ncurses doesn't do this, but they have a buffer, so they
 	   may just be deleting from an offscreen context whereas we
@@ -49,8 +46,6 @@
 WINDOW *derwin ( WINDOW *parent, int nlines, int ncols,
 	     		  	 int begin_y, int begin_x ) {
 	WINDOW *child;
-	if ( parent == NULL )
-		return NULL;
 	if ( ( child = malloc( sizeof( WINDOW ) ) ) == NULL )
 		return NULL;
 	if ( ( (unsigned)ncols > parent->width ) || 
@@ -73,8 +68,6 @@
  */
 WINDOW *dupwin ( WINDOW *orig ) {
 	WINDOW *copy;
-	if ( orig == NULL )
-		return NULL;
 	if ( ( copy = malloc( sizeof( WINDOW ) ) ) == NULL )
 		return NULL;
 	copy->scr = orig->scr;
@@ -97,8 +90,6 @@
  * @ret rc	return status code
  */
 int mvwin ( WINDOW *win, int y, int x ) {
-	if ( win == NULL )
-		return ERR;
 	if ( ( ( (unsigned)y + win->height ) > LINES ) ||
 	     ( ( (unsigned)x + win->width ) > COLS ) )
 		return ERR;
@@ -147,8 +138,6 @@
 WINDOW *subwin ( WINDOW *parent, int nlines, int ncols,
 			         int begin_y, int begin_x ) {
 	WINDOW *child;
-	if ( parent == NULL )
-		return NULL;
 	if ( ( child = malloc( sizeof( WINDOW ) ) ) == NULL )
 		return NULL;
 	child = newwin( nlines, ncols, begin_y, begin_x );
--- ./src/drivers/net/igb/igb_phy.c.orig	2016-09-01 14:06:58.151193101 -0400
+++ ./src/drivers/net/igb/igb_phy.c	2016-09-01 14:07:12.503193443 -0400
@@ -91,18 +91,18 @@
 	if (!(phy->ops.read_reg))
 		goto out;
 
-		ret_val = phy->ops.read_reg(hw, PHY_ID1, &phy_id);
-		if (ret_val)
-			goto out;
+	ret_val = phy->ops.read_reg(hw, PHY_ID1, &phy_id);
+	if (ret_val)
+		goto out;
 
-		phy->id = (u32)(phy_id << 16);
-		usec_delay(20);
-		ret_val = phy->ops.read_reg(hw, PHY_ID2, &phy_id);
-		if (ret_val)
-			goto out;
+	phy->id = (u32)(phy_id << 16);
+	usec_delay(20);
+	ret_val = phy->ops.read_reg(hw, PHY_ID2, &phy_id);
+	if (ret_val)
+		goto out;
 
-		phy->id |= (u32)(phy_id & PHY_REVISION_MASK);
-		phy->revision = (u32)(phy_id & ~PHY_REVISION_MASK);
+	phy->id |= (u32)(phy_id & PHY_REVISION_MASK);
+	phy->revision = (u32)(phy_id & ~PHY_REVISION_MASK);
 
 out:
 	return ret_val;
--- ./src/drivers/net/ath/ath5k/ath5k_phy.c.orig	2016-09-01 13:32:38.317143990 -0400
+++ ./src/drivers/net/ath/ath5k/ath5k_phy.c	2016-09-01 14:09:20.384196492 -0400
@@ -1219,12 +1219,12 @@
 
 	/* Update radio registers */
 	ath5k_hw_reg_write(ah, (phy_sig & ~(AR5K_PHY_SIG_FIRPWR)) |
-		AR5K_REG_SM(-1, AR5K_PHY_SIG_FIRPWR), AR5K_PHY_SIG);
+		AR5K_REG_SM(-1U, AR5K_PHY_SIG_FIRPWR), AR5K_PHY_SIG);
 
 	ath5k_hw_reg_write(ah, (phy_agc & ~(AR5K_PHY_AGCCOARSE_HI |
 			AR5K_PHY_AGCCOARSE_LO)) |
-		AR5K_REG_SM(-1, AR5K_PHY_AGCCOARSE_HI) |
-		AR5K_REG_SM(-127, AR5K_PHY_AGCCOARSE_LO), AR5K_PHY_AGCCOARSE);
+		AR5K_REG_SM(-1U, AR5K_PHY_AGCCOARSE_HI) |
+		AR5K_REG_SM(-127U, AR5K_PHY_AGCCOARSE_LO), AR5K_PHY_AGCCOARSE);
 
 	ath5k_hw_reg_write(ah, (phy_sat & ~(AR5K_PHY_ADCSAT_ICNT |
 			AR5K_PHY_ADCSAT_THR)) |
--- ./src/drivers/net/ath/ath5k/ath5k.c.orig	2016-09-01 13:32:28.652143760 -0400
+++ ./src/drivers/net/ath/ath5k/ath5k.c	2016-09-01 14:08:21.819195095 -0400
@@ -85,46 +85,6 @@
 	PCI_ROM(0x168c, 0x001d, "ath2417", "Atheros 2417 Nala", AR5K_AR5212),
 };
 
-/* Known SREVs */
-static const struct ath5k_srev_name srev_names[] = {
-	{ "5210",	AR5K_VERSION_MAC,	AR5K_SREV_AR5210 },
-	{ "5311",	AR5K_VERSION_MAC,	AR5K_SREV_AR5311 },
-	{ "5311A",	AR5K_VERSION_MAC,	AR5K_SREV_AR5311A },
-	{ "5311B",	AR5K_VERSION_MAC,	AR5K_SREV_AR5311B },
-	{ "5211",	AR5K_VERSION_MAC,	AR5K_SREV_AR5211 },
-	{ "5212",	AR5K_VERSION_MAC,	AR5K_SREV_AR5212 },
-	{ "5213",	AR5K_VERSION_MAC,	AR5K_SREV_AR5213 },
-	{ "5213A",	AR5K_VERSION_MAC,	AR5K_SREV_AR5213A },
-	{ "2413",	AR5K_VERSION_MAC,	AR5K_SREV_AR2413 },
-	{ "2414",	AR5K_VERSION_MAC,	AR5K_SREV_AR2414 },
-	{ "5424",	AR5K_VERSION_MAC,	AR5K_SREV_AR5424 },
-	{ "5413",	AR5K_VERSION_MAC,	AR5K_SREV_AR5413 },
-	{ "5414",	AR5K_VERSION_MAC,	AR5K_SREV_AR5414 },
-	{ "2415",	AR5K_VERSION_MAC,	AR5K_SREV_AR2415 },
-	{ "5416",	AR5K_VERSION_MAC,	AR5K_SREV_AR5416 },
-	{ "5418",	AR5K_VERSION_MAC,	AR5K_SREV_AR5418 },
-	{ "2425",	AR5K_VERSION_MAC,	AR5K_SREV_AR2425 },
-	{ "2417",	AR5K_VERSION_MAC,	AR5K_SREV_AR2417 },
-	{ "xxxxx",	AR5K_VERSION_MAC,	AR5K_SREV_UNKNOWN },
-	{ "5110",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_5110 },
-	{ "5111",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_5111 },
-	{ "5111A",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_5111A },
-	{ "2111",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_2111 },
-	{ "5112",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_5112 },
-	{ "5112A",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_5112A },
-	{ "5112B",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_5112B },
-	{ "2112",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_2112 },
-	{ "2112A",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_2112A },
-	{ "2112B",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_2112B },
-	{ "2413",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_2413 },
-	{ "5413",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_5413 },
-	{ "2316",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_2316 },
-	{ "2317",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_2317 },
-	{ "5424",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_5424 },
-	{ "5133",	AR5K_VERSION_RAD,	AR5K_SREV_RAD_5133 },
-	{ "xxxxx",	AR5K_VERSION_RAD,	AR5K_SREV_UNKNOWN },
-};
-
 #define ATH5K_SPMBL_NO   1
 #define ATH5K_SPMBL_YES  2
 #define ATH5K_SPMBL_BOTH 3
--- ./src/drivers/net/ath/ath5k/ath5k_reset.c.orig	2016-09-01 13:32:44.493144138 -0400
+++ ./src/drivers/net/ath/ath5k/ath5k_reset.c	2016-09-01 14:07:48.153194293 -0400
@@ -135,13 +135,6 @@
 }
 
 
-/*
- * index into rates for control rates, we can set it up like this because
- * this is only used for AR5212 and we know it supports G mode
- */
-static const unsigned int control_rates[] =
-	{ 0, 1, 1, 1, 4, 4, 6, 6, 8, 8, 8, 8 };
-
 /**
  * ath5k_hw_write_rate_duration - fill rate code to duration table
  *
--- ./src/drivers/net/ath/ath9k/ath9k_eeprom.c.orig	2016-09-01 13:33:17.247144919 -0400
+++ ./src/drivers/net/ath/ath9k/ath9k_eeprom.c	2016-09-01 14:10:05.426197566 -0400
@@ -371,7 +371,7 @@
 			/* FIXME: array overrun? */
 			for (i = 0; i < numXpdGains; i++) {
 				minPwrT4[i] = data_9287[idxL].pwrPdg[i][0];
-				maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];
+				maxPwrT4[i] = data_9287[idxL].pwrPdg[i][intercepts - 1];
 				ath9k_hw_fill_vpd_table(minPwrT4[i], maxPwrT4[i],
 						data_9287[idxL].pwrPdg[i],
 						data_9287[idxL].vpdPdg[i],
@@ -381,7 +381,7 @@
 		} else if (eeprom_4k) {
 			for (i = 0; i < numXpdGains; i++) {
 				minPwrT4[i] = data_4k[idxL].pwrPdg[i][0];
-				maxPwrT4[i] = data_4k[idxL].pwrPdg[i][4];
+				maxPwrT4[i] = data_4k[idxL].pwrPdg[i][intercepts - 1];
 				ath9k_hw_fill_vpd_table(minPwrT4[i], maxPwrT4[i],
 						data_4k[idxL].pwrPdg[i],
 						data_4k[idxL].vpdPdg[i],
@@ -391,7 +391,7 @@
 		} else {
 			for (i = 0; i < numXpdGains; i++) {
 				minPwrT4[i] = data_def[idxL].pwrPdg[i][0];
-				maxPwrT4[i] = data_def[idxL].pwrPdg[i][4];
+				maxPwrT4[i] = data_def[idxL].pwrPdg[i][intercepts - 1];
 				ath9k_hw_fill_vpd_table(minPwrT4[i], maxPwrT4[i],
 						data_def[idxL].pwrPdg[i],
 						data_def[idxL].vpdPdg[i],
--- ./src/drivers/net/via-rhine.c.orig	2016-09-01 13:33:48.177145656 -0400
+++ ./src/drivers/net/via-rhine.c	2016-09-01 14:03:12.604187723 -0400
@@ -947,11 +947,11 @@
             // if (tp->chip_id == 0x3065)
             if( tp->chip_revision < 0x80 && tp->chip_revision >=0x40 )
                 intr_status |= inb(nic->ioaddr + IntrStatus2) << 16;
-                intr_status = (intr_status & ~DEFAULT_INTR);
-                if ( action == ENABLE ) 
-                    intr_status = intr_status | DEFAULT_INTR;
-                    outw(intr_status, nic->ioaddr + IntrEnable);
-                break;
+            intr_status = (intr_status & ~DEFAULT_INTR);
+            if ( action == ENABLE ) 
+                intr_status = intr_status | DEFAULT_INTR;
+                outw(intr_status, nic->ioaddr + IntrEnable);
+            break;
         case FORCE :
             outw(0x0010, nic->ioaddr + 0x84);
            break;
--- ./src/drivers/net/via-velocity.c.orig	2016-09-01 13:33:56.257145849 -0400
+++ ./src/drivers/net/via-velocity.c	2016-09-01 14:05:20.607190775 -0400
@@ -89,13 +89,6 @@
 #define RX_THRESH_MIN   0
 #define RX_THRESH_MAX   3
 #define RX_THRESH_DEF   0
-/* rx_thresh[] is used for controlling the receive fifo threshold.
-   0: indicate the rxfifo threshold is 128 bytes.
-   1: indicate the rxfifo threshold is 512 bytes.
-   2: indicate the rxfifo threshold is 1024 bytes.
-   3: indicate the rxfifo threshold is store & forward.
-*/
-VELOCITY_PARAM(rx_thresh, "Receive fifo threshold");
 
 #define DMA_LENGTH_MIN  0
 #define DMA_LENGTH_MAX  7
--- ./src/drivers/net/sis190.c.orig	2016-09-01 13:33:32.767145289 -0400
+++ ./src/drivers/net/sis190.c	2016-09-01 14:04:48.268190004 -0400
@@ -72,12 +72,6 @@
 static const u32 sis190_intr_mask =
 	RxQEmpty | RxQInt | TxQ1Int | TxQ0Int | RxHalt | TxHalt | LinkChange;
 
-/*
- * Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
- * The chips use a 64 element hash table based on the Ethernet CRC.
- */
-static const int multicast_filter_limit = 32;
-
 static void __mdio_cmd(void *ioaddr, u32 ctl)
 {
 	unsigned int i;
--- ./src/drivers/net/skge.c.orig	2016-09-01 13:33:39.681145453 -0400
+++ ./src/drivers/net/skge.c	2016-09-01 14:04:12.235189145 -0400
@@ -83,9 +83,6 @@
 /* Avoid conditionals by using array */
 static const int txqaddr[] = { Q_XA1, Q_XA2 };
 static const int rxqaddr[] = { Q_R1, Q_R2 };
-static const u32 rxirqmask[] = { IS_R1_F, IS_R2_F };
-static const u32 txirqmask[] = { IS_XA1_F, IS_XA2_F };
-static const u32 napimask[] = { IS_R1_F|IS_XA1_F, IS_R2_F|IS_XA2_F };
 static const u32 portmask[] = { IS_PORT_1, IS_PORT_2 };
 
 /* Determine supported/advertised modes based on hardware.
@@ -1921,8 +1918,6 @@
 	skge->tx_ring.to_clean = e;
 }
 
-static const u8 pause_mc_addr[ETH_ALEN] = { 0x1, 0x80, 0xc2, 0x0, 0x0, 0x1 };
-
 static inline u16 phy_length(const struct skge_hw *hw, u32 status)
 {
 	if (hw->chip_id == CHIP_ID_GENESIS)
--- ./src/drivers/net/e1000/e1000_phy.c.orig	2016-09-01 13:33:26.591145141 -0400
+++ ./src/drivers/net/e1000/e1000_phy.c	2016-09-01 14:05:59.666191706 -0400
@@ -167,18 +167,18 @@
 	if (!(phy->ops.read_reg))
 		goto out;
 
-		ret_val = phy->ops.read_reg(hw, PHY_ID1, &phy_id);
-		if (ret_val)
-			goto out;
+	ret_val = phy->ops.read_reg(hw, PHY_ID1, &phy_id);
+	if (ret_val)
+		goto out;
 
-		phy->id = (u32)(phy_id << 16);
-		usec_delay(20);
-		ret_val = phy->ops.read_reg(hw, PHY_ID2, &phy_id);
-		if (ret_val)
-			goto out;
+	phy->id = (u32)(phy_id << 16);
+	usec_delay(20);
+	ret_val = phy->ops.read_reg(hw, PHY_ID2, &phy_id);
+	if (ret_val)
+		goto out;
 
-		phy->id |= (u32)(phy_id & PHY_REVISION_MASK);
-		phy->revision = (u32)(phy_id & ~PHY_REVISION_MASK);
+	phy->id |= (u32)(phy_id & PHY_REVISION_MASK);
+	phy->revision = (u32)(phy_id & ~PHY_REVISION_MASK);
 
 out:
 	return ret_val;

[-- Attachment #3: Type: text/plain, Size: 127 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Mon, Oct 10, 2016 at 01:38:48PM -0400, Boris Ostrovsky wrote:
> On 10/10/2016 12:33 PM, Wei Liu wrote:
> > On Mon, Oct 10, 2016 at 04:51:13PM +0100, Ian Jackson wrote:
> >> Wei Liu writes ("Re: [PATCH for-4.8] ipxe: update to newer commit"):
> >>> On Mon, Oct 10, 2016 at 04:34:31PM +0100, Ian Jackson wrote:
> >>>> How did you choose 827dd1bfee67daa683935ce65316f7e0f057fe1c ?
> >>> That's the latest commit -- since upstream wants us to always use the
> >>> latest, I just picked that one.
> >>>
> >>> I built that commit with gcc 4.9 and gcc 6.1, both compiled OK.
> >>> Realistically I don't expect issues with nic boot roms -- those are the
> >>> only things we really use AFAICT.
> >> Err, good.  Well, perhaps we can wait a week and see if anyone reports
> >> hideous breakage in that ipxe revision ?
> >>
> > Sure. I will check ipxe mailing list in one week.
> 
> FWIW, here is the patch that I used to pacify gcc.
> 

Cherry-picking upstream patches is one thing, writing new ones is
another.  This is essentially forking ipxe. I would avoid doing this
whenever I can.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Ian Jackson]

Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
> On 10/10/2016 12:33 PM, Wei Liu wrote:
> > Sure. I will check ipxe mailing list in one week.
> 
> FWIW, here is the patch that I used to pacify gcc.

Thanks.  I don't think we would want to add more private patches to
our ipxe in Xen 4.8.

Maybe we could consider these as backports to earlier releases.
However, I looked at the patch and it mostly seems to be removing null
pointer checks.  I find this ... surprising.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Boris Ostrovsky]

On 10/11/2016 05:52 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
>> On 10/10/2016 12:33 PM, Wei Liu wrote:
>>> Sure. I will check ipxe mailing list in one week.
>> FWIW, here is the patch that I used to pacify gcc.
> Thanks.  I don't think we would want to add more private patches to
> our ipxe in Xen 4.8.
>
> Maybe we could consider these as backports to earlier releases.
> However, I looked at the patch and it mostly seems to be removing null
> pointer checks.  I find this ... surprising.
>

That's because routines have __nonnull attribute (which tells compiler
that arguments are never NULL) and new gcc warns on non-NULL checks for
these arguments.

Another interesting new warning that is fatal with -Werror is
    if(a)
        foo();
        bar();

gcc warns that bar() is indented and maybe braces are needed.

BTW, another option for backporting may be removing -Werror. If we know
we are not changing sources then we might consider this.

Copy/paste so whitespaces will probably be messed up:

diff --git a/tools/firmware/etherboot/Makefile
b/tools/firmware/etherboot/Makefile
index a0578d2..1576b3 100644
--- a/tools/firmware/etherboot/Makefile
+++ b/tools/firmware/etherboot/Makefile
@@ -25,7 +25,7 @@ ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom,
$(ETHERBOOT_NICS)))
 all: $(ROMS)
 
 %.rom: $D/src/arch/i386/Makefile
-       $(MAKE) -C $D/src bin/$(*F).rom
+       $(MAKE) NO_WERROR=1 -C $D/src bin/$(*F).rom
 
 $T:
        if ! $(FETCHER) _$T $(IPXE_TARBALL_URL); then \
@@ -45,7 +45,7 @@ $D/src/arch/i386/Makefile: $T Config
        cat Config >>$@
 
 $D/src/bin/NIC: $D/src/arch/i386/Makefile
-       $(MAKE) -C $D/src bin/NIC
+       $(MAKE) NO_WERROR=1 -C $D/src bin/NIC
 
 .PHONY: clean
 clean:



-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Ian Jackson]

Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
> On 10/11/2016 05:52 AM, Ian Jackson wrote:
> > Maybe we could consider these as backports to earlier releases.
> > However, I looked at the patch and it mostly seems to be removing null
> > pointer checks.  I find this ... surprising.
> 
> That's because routines have __nonnull attribute (which tells compiler
> that arguments are never NULL) and new gcc warns on non-NULL checks for
> these arguments.

*sigh*  Why don't we just disable that warning ?

> Another interesting new warning that is fatal with -Werror is
>     if(a)
>         foo();
>         bar();
> 
> gcc warns that bar() is indented and maybe braces are needed.

Do we actually have cases like this ?  Are they real bugs ?

> BTW, another option for backporting may be removing -Werror. If we know
> we are not changing sources then we might consider this.

Perhaps we could disable warnings more selectively.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Boris Ostrovsky]

On 10/11/2016 09:32 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
>> On 10/11/2016 05:52 AM, Ian Jackson wrote:
>>> Maybe we could consider these as backports to earlier releases.
>>> However, I looked at the patch and it mostly seems to be removing null
>>> pointer checks.  I find this ... surprising.
>> That's because routines have __nonnull attribute (which tells compiler
>> that arguments are never NULL) and new gcc warns on non-NULL checks for
>> these arguments.
> *sigh*  Why don't we just disable that warning ?

We could but what if an old compiler doesn't support that option?
Although it looks like -Wno-<option>, which is what we'd use, may be OK:

ostr@workbase> gcc foo.c
ostr@workbase> gcc -Wfoo foo.c
gcc: error: unrecognized command line option ‘-Wfoo’; did you mean ‘-Wno-’?
ostr@workbase> gcc -Wno-foo foo.c
ostr@workbase>


>
>> Another interesting new warning that is fatal with -Werror is
>>     if(a)
>>         foo();
>>         bar();
>>
>> gcc warns that bar() is indented and maybe braces are needed.
> Do we actually have cases like this ?  Are they real bugs ?

Yes we have (for example igb_phy.c change in the patch that I sent) and
no, they don't look like bugs.

>
>> BTW, another option for backporting may be removing -Werror. If we know
>> we are not changing sources then we might consider this.
> Perhaps we could disable warnings more selectively.

I scanned the changes again and at least one appears to be fixing a
legitimate bug (buffer overrun). There is an upstream patch for that,
which is essentially what I have there, but not as a separate patch.

-boris



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Ian Jackson]

Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
> We could but what if an old compiler doesn't support that option?
> Although it looks like -Wno-<option>, which is what we'd use, may be OK:
> 
> ostr@workbase> gcc foo.c
> ostr@workbase> gcc -Wfoo foo.c
> gcc: error: unrecognized command line option ‘-Wfoo’; did you mean ‘-Wno-’?
> ostr@workbase> gcc -Wno-foo foo.c
> ostr@workbase>

Many many years ago I filed a bug asking the gcc folks to make
 -Wno-some-random-warning-option-that-gcc-does-not-know-about
not be an error.

That was eventually done.  I'm not sure exactly when the change was
made.  Does gcc -Wno-foo work properly on all the gcc's we care about ?

> >> Another interesting new warning that is fatal with -Werror is
> >>     if(a)
> >>         foo();
> >>         bar();
> >>
> >> gcc warns that bar() is indented and maybe braces are needed.
> > Do we actually have cases like this ?  Are they real bugs ?
> 
> Yes we have (for example igb_phy.c change in the patch that I sent) and
> no, they don't look like bugs.

I guess we can disable that warning too then.

> >> BTW, another option for backporting may be removing -Werror. If we know
> >> we are not changing sources then we might consider this.
> > Perhaps we could disable warnings more selectively.
> 
> I scanned the changes again and at least one appears to be fixing a
> legitimate bug (buffer overrun). There is an upstream patch for that,
> which is essentially what I have there, but not as a separate patch.

I don't think a buffer overflow in ipxe is any kind of problem.  The
_whole purpose_ of ipxe is to take unauthenticated data from the
network and unconditionally execute it...

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Boris Ostrovsky]

On 10/11/2016 10:54 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
>> We could but what if an old compiler doesn't support that option?
>> Although it looks like -Wno-<option>, which is what we'd use, may be OK:
>>
>> ostr@workbase> gcc foo.c
>> ostr@workbase> gcc -Wfoo foo.c
>> gcc: error: unrecognized command line option ‘-Wfoo’; did you mean ‘-Wno-’?
>> ostr@workbase> gcc -Wno-foo foo.c
>> ostr@workbase>
> Many many years ago I filed a bug asking the gcc folks to make
>  -Wno-some-random-warning-option-that-gcc-does-not-know-about
> not be an error.
>
> That was eventually done.  I'm not sure exactly when the change was
> made.  Does gcc -Wno-foo work properly on all the gcc's we care about ?
>
>>>> Another interesting new warning that is fatal with -Werror is
>>>>     if(a)
>>>>         foo();
>>>>         bar();
>>>>
>>>> gcc warns that bar() is indented and maybe braces are needed.
>>> Do we actually have cases like this ?  Are they real bugs ?
>> Yes we have (for example igb_phy.c change in the patch that I sent) and
>> no, they don't look like bugs.
> I guess we can disable that warning too then.
>
>>>> BTW, another option for backporting may be removing -Werror. If we know
>>>> we are not changing sources then we might consider this.
>>> Perhaps we could disable warnings more selectively.
>> I scanned the changes again and at least one appears to be fixing a
>> legitimate bug (buffer overrun). There is an upstream patch for that,
>> which is essentially what I have there, but not as a separate patch.
> I don't think a buffer overflow in ipxe is any kind of problem.  The
> _whole purpose_ of ipxe is to take unauthenticated data from the
> network and unconditionally execute it...


How about this then:

diff --git a/tools/firmware/etherboot/Makefile
b/tools/firmware/etherboot/Makefile
index a0578d2..49d5c27 100644
--- a/tools/firmware/etherboot/Makefile
+++ b/tools/firmware/etherboot/Makefile
@@ -24,8 +24,16 @@ ROMS = $(addprefix $D/src/bin/, $(addsuffix .rom,
$(ETHERBOOT_NICS)))
 .PHONY: all
 all: $(ROMS)
 
+# GCC v6 may be too strict with its warnings.
+GCCVERSIONGT6 = $(shell expr `gcc -dumpversion | cut -f1 -d.` \>= 6)
+ifeq ($(GCCVERSIONGT6),1)
+IPXE_CFLAGS = -Wno-nonnull-compare -Wno-unused-const-variable \
+              -Wno-misleading-indentation \
+              -Wno-shift-negative-value -Wno-array-bounds
+endif
+
 %.rom: $D/src/arch/i386/Makefile
-       $(MAKE) -C $D/src bin/$(*F).rom
+       $(MAKE) EXTRA_CFLAGS="$(IPXE_CFLAGS)" -C $D/src bin/$(*F).rom
 
 $T:
        if ! $(FETCHER) _$T $(IPXE_TARBALL_URL); then \
@@ -45,7 +53,7 @@ $D/src/arch/i386/Makefile: $T Config
        cat Config >>$@
 
 $D/src/bin/NIC: $D/src/arch/i386/Makefile
-       $(MAKE) -C $D/src bin/NIC
+       $(MAKE) EXTRA_CFLAGS="$(IPXE_CFLAGS)" -C $D/src bin/NIC
 
 .PHONY: clean
 clean:



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit [and 1 more messages]

[Ian Jackson]

Ian Jackson writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
> That was eventually done.  I'm not sure exactly when the change was
> made.  Does gcc -Wno-foo work properly on all the gcc's we care about ?

Jan Beulich writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
> Just fyi I have run into an issue with -Wno-override-init use in Linux
> 4.8 on gcc 4.1.x, so what you say doesn't appear to hold for all gcc
> versions we permit to be used.

Well, that answers my question above.

I think the right approach is to:

 * Test -Wno-this-is-not-a-warning-option.  If gcc accepts it,
   add -Wno-something to disable the nonnull check·

 * Review the misleading indentations and if there are only a few, fix
   them in a downstream patch.  Or, if there are many, decide to
   tolerate them.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit [and 1 more messages]

[Boris Ostrovsky]

On 10/12/2016 07:00 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
>> That was eventually done.  I'm not sure exactly when the change was
>> made.  Does gcc -Wno-foo work properly on all the gcc's we care about ?
> Jan Beulich writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
>> Just fyi I have run into an issue with -Wno-override-init use in Linux
>> 4.8 on gcc 4.1.x, so what you say doesn't appear to hold for all gcc
>> versions we permit to be used.
> Well, that answers my question above.
>
> I think the right approach is to:
>
>  * Test -Wno-this-is-not-a-warning-option.  If gcc accepts it,
>    add -Wno-something to disable the nonnull check·

Back compatibility is in fact not a problem. These options would only be
passed on when gcc6+ is used

>
>  * Review the misleading indentations and if there are only a few, fix
>    them in a downstream patch.  Or, if there are many, decide to
>    tolerate them.

There are more warnings than just indentation and nonnull checks:
    -Wno-nonnull-compare
    -Wno-unused-const-variable
    -Wno-misleading-indentation
    -Wno-shift-negative-value
    -Wno-array-bounds

(The last two flagged actual bugs that have been fixed upstream).

Some of the warnings can be addressed by backporting upstream patches
but there are a few for which backporting will involve much more code
movement than fixing the code ourselves.

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit [and 1 more messages]

[Wei Liu]

On Wed, Oct 12, 2016 at 12:00:56PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
> > That was eventually done.  I'm not sure exactly when the change was
> > made.  Does gcc -Wno-foo work properly on all the gcc's we care about ?
> 
> Jan Beulich writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
> > Just fyi I have run into an issue with -Wno-override-init use in Linux
> > 4.8 on gcc 4.1.x, so what you say doesn't appear to hold for all gcc
> > versions we permit to be used.
> 
> Well, that answers my question above.
> 
> I think the right approach is to:
> 
>  * Test -Wno-this-is-not-a-warning-option.  If gcc accepts it,
>    add -Wno-something to disable the nonnull check·
> 
>  * Review the misleading indentations and if there are only a few, fix
>    them in a downstream patch.  Or, if there are many, decide to
>    tolerate them.
> 

FAOD, I consider this sub-thread for "what should we do for stable
versions of Xen". This is orthogonal to whether we should upgrade our
in-tree ipxe version. In other words, I plan to commence with the
upgrade if there is no major issue is found next week.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit [and 1 more messages]

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit [and 1 more messages]"):
> FAOD, I consider this sub-thread for "what should we do for stable
> versions of Xen". This is orthogonal to whether we should upgrade our
> in-tree ipxe version. In other words, I plan to commence with the
> upgrade if there is no major issue is found next week.

Yes.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Jan Beulich]

>>> On 11.10.16 at 16:27, <boris.ostrovsky@oracle.com> wrote:
> On 10/11/2016 09:32 AM, Ian Jackson wrote:
>> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to 
> newer commit"):
>>> On 10/11/2016 05:52 AM, Ian Jackson wrote:
>>>> Maybe we could consider these as backports to earlier releases.
>>>> However, I looked at the patch and it mostly seems to be removing null
>>>> pointer checks.  I find this ... surprising.
>>> That's because routines have __nonnull attribute (which tells compiler
>>> that arguments are never NULL) and new gcc warns on non-NULL checks for
>>> these arguments.
>> *sigh*  Why don't we just disable that warning ?
> 
> We could but what if an old compiler doesn't support that option?
> Although it looks like -Wno-<option>, which is what we'd use, may be OK:
> 
> ostr@workbase> gcc foo.c
> ostr@workbase> gcc -Wfoo foo.c
> gcc: error: unrecognized command line option ‘-Wfoo’; did you mean ‘-Wno-’?
> ostr@workbase> gcc -Wno-foo foo.c
> ostr@workbase>

Just fyi I have run into an issue with -Wno-override-init use in Linux
4.8 on gcc 4.1.x, so what you say doesn't appear to hold for all gcc
versions we permit to be used.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Andrew Cooper]

On 11/10/2016 14:32, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
>> On 10/11/2016 05:52 AM, Ian Jackson wrote:
>>> Maybe we could consider these as backports to earlier releases.
>>> However, I looked at the patch and it mostly seems to be removing null
>>> pointer checks.  I find this ... surprising.
>> That's because routines have __nonnull attribute (which tells compiler
>> that arguments are never NULL) and new gcc warns on non-NULL checks for
>> these arguments.
> *sigh*  Why don't we just disable that warning ?

*sigh* This shouldn't be warning at all.  It falls into the same
category as
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=26ea2cce0d3d25974eea3c643ce2081adfa2a69c
which is "Will cause you to actively write insecure code if you believe
the compiler".

The useful part of using __nonnull is to get the compiler to complain at
you if it does find a case where you end up passing NULL.  Forcing the
coder to remove the supposedly-redundant NULL check makes the code less
resistant to exceptional circumstances.

>
>> Another interesting new warning that is fatal with -Werror is
>>     if(a)
>>         foo();
>>         bar();
>>
>> gcc warns that bar() is indented and maybe braces are needed.
> Do we actually have cases like this ?

Yes

>   Are they real bugs ?

Very much yes.

goto fail;

This is one of the most useful warnings to have been introduced into C
compilers for a very long time.  c/s
ebdba150bff1d914805d60efa576337bbef0c305 was a real bug in our tree
caught by it.

>
>> BTW, another option for backporting may be removing -Werror. If we know
>> we are not changing sources then we might consider this.
> Perhaps we could disable warnings more selectively.

This code hasn't changed in ages.  Irrespective of what newer compilers
think, it won't start working differently,

For 4.8, if we are not going to change the iPXE version, then disabling
-Werror is probably the best move.  We have no idea which new warnings
will appear in GCC7.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Andrew Cooper]

On 11/10/2016 22:11, Andrew Cooper wrote:
>
>>> Another interesting new warning that is fatal with -Werror is
>>>     if(a)
>>>         foo();
>>>         bar();
>>>
>>> gcc warns that bar() is indented and maybe braces are needed.
>> Do we actually have cases like this ?
> Yes
>
>>   Are they real bugs ?
> Very much yes.
>
> goto fail;

Oh - it appears that CVE-2014-1266 was the impetus for introducing
-Wmisleading-indentation in the first place.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Jan Beulich]

>>> On 11.10.16 at 23:11, <andrew.cooper3@citrix.com> wrote:
> On 11/10/2016 14:32, Ian Jackson wrote:
>> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit"):
>>> BTW, another option for backporting may be removing -Werror. If we know
>>> we are not changing sources then we might consider this.
>> Perhaps we could disable warnings more selectively.
> 
> This code hasn't changed in ages.  Irrespective of what newer compilers
> think, it won't start working differently,

I'm afraid this is not a good position to take: Newer gcc may also be
more aggressive in terms of eliminating code with undefined behavior,
and warnings for such cases are a useful (pre)indicator.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Juergen Schinker]

and where have you applied that patch ? is it xen-4.8-rc1 ?

do I have to apply that patch ?

do I need to check out another tag ?

do I have to wait a week?

----- On 10 Oct, 2016, at 16:33, Wei Liu wei.liu2@citrix.com wrote:

> Sure. I will check ipxe mailing list in one week.
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Mon, Oct 10, 2016 at 07:28:22PM +0100, Juergen Schinker wrote:
> 
> and where have you applied that patch ? is it xen-4.8-rc1 ?
> 
> do I have to apply that patch ?
> 
> do I need to check out another tag ?
> 
> do I have to wait a week?
> 

No, you can try to work around this issue by appending --disable-rombios
to your ./configure invocation. You can test major functionalities of
Xen just fine without rombios.

Wei.

> ----- On 10 Oct, 2016, at 16:33, Wei Liu wei.liu2@citrix.com wrote:
> 
> > Sure. I will check ipxe mailing list in one week.
> > 
> > Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Juergen Schinker]

yeah I got it compilin' with the patch from Boris and made a deb

but this is only useful on other machines...

However booting with xen-4.8-rc1 works fine but the xen-tools didn't work , so booting a given guest was not possible

i even had live-patching enabled yay

will try again Friday with rc2 and hopefully there are more people in the xentest chat room ...

J 

----- On 11 Oct, 2016, at 09:37, Wei Liu wei.liu2@citrix.com wrote:

> No, you can try to work around this issue by appending --disable-rombios
> to your ./configure invocation. You can test major functionalities of
> Xen just fine without rombios.
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Tue, Oct 11, 2016 at 10:42:21AM +0100, Juergen Schinker wrote:
> 
> yeah I got it compilin' with the patch from Boris and made a deb
> 
> but this is only useful on other machines...
> 
> However booting with xen-4.8-rc1 works fine but the xen-tools didn't work , so booting a given guest was not possible
> 

Without having more information: there is a similar bug report for not
able to create guests, I think it is due to a bug that is already fixed
in upstream.

> i even had live-patching enabled yay
> 
> will try again Friday with rc2 and hopefully there are more people in the xentest chat room ...
> 

We're going to tag rc2 some time this week. Thanks for help testing Xen!

Wei.

> J 
> 
> ----- On 11 Oct, 2016, at 09:37, Wei Liu wei.liu2@citrix.com wrote:
> 
> > No, you can try to work around this issue by appending --disable-rombios
> > to your ./configure invocation. You can test major functionalities of
> > Xen just fine without rombios.
> > 
> > Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Juergen Schinker]

 
> 
> We're going to tag rc2 some time this week. Thanks for help testing Xen!
> 
> Wei.
> 
>> J
>> 
>> ----- On 11 Oct, 2016, at 09:37, Wei Liu wei.liu2@citrix.com wrote:
>> 
>> > No, you can try to work around this issue by appending --disable-rombios
>> > to your ./configure invocation. You can test major functionalities of
>> > Xen just fine without rombios.
>> > 
> > > Wei.

Now for the fun of it I tried the RELEASE-4.7 

and it turns out it has no support for xz-decompression 

so it can't decompress the kernel via pygrub

what

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Konrad Rzeszutek Wilk]

On Tue, Oct 11, 2016 at 08:31:31PM +0100, Juergen Schinker wrote:
> 
>  
> > 
> > We're going to tag rc2 some time this week. Thanks for help testing Xen!
> > 
> > Wei.
> > 
> >> J
> >> 
> >> ----- On 11 Oct, 2016, at 09:37, Wei Liu wei.liu2@citrix.com wrote:
> >> 
> >> > No, you can try to work around this issue by appending --disable-rombios
> >> > to your ./configure invocation. You can test major functionalities of
> >> > Xen just fine without rombios.
> >> > 
> > > > Wei.
> 
> Now for the fun of it I tried the RELEASE-4.7 
> 
> and it turns out it has no support for xz-decompression 
> 
> so it can't decompress the kernel via pygrub

I presume that it works for you in 4.8?
> 
> what
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Tue, Oct 11, 2016 at 08:31:31PM +0100, Juergen Schinker wrote:
> 
>  
> > 
> > We're going to tag rc2 some time this week. Thanks for help testing Xen!
> > 
> > Wei.
> > 
> >> J
> >> 
> >> ----- On 11 Oct, 2016, at 09:37, Wei Liu wei.liu2@citrix.com wrote:
> >> 
> >> > No, you can try to work around this issue by appending --disable-rombios
> >> > to your ./configure invocation. You can test major functionalities of
> >> > Xen just fine without rombios.
> >> > 
> > > > Wei.
> 
> Now for the fun of it I tried the RELEASE-4.7 
> 
> and it turns out it has no support for xz-decompression 
> 

That's probably because you don't have libzx development package
installed when building Xen.

> so it can't decompress the kernel via pygrub
> 
> what

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Boris Ostrovsky]

On 10/12/2016 05:27 AM, Wei Liu wrote:
> On Tue, Oct 11, 2016 at 08:31:31PM +0100, Juergen Schinker wrote:
>>  
>>> We're going to tag rc2 some time this week. Thanks for help testing Xen!
>>>
>>> Wei.
>>>
>>>> J
>>>>
>>>> ----- On 11 Oct, 2016, at 09:37, Wei Liu wei.liu2@citrix.com wrote:
>>>>
>>>>> No, you can try to work around this issue by appending --disable-rombios
>>>>> to your ./configure invocation. You can test major functionalities of
>>>>> Xen just fine without rombios.
>>>>>
>>>>> Wei.
>> Now for the fun of it I tried the RELEASE-4.7 
>>
>> and it turns out it has no support for xz-decompression 
>>
> That's probably because you don't have libzx development package
> installed when building Xen.


Which would be a new requirement for building Xen. And it broke our
(pre-historic) build server that never had it installed.

-boris


>
>> so it can't decompress the kernel via pygrub
>>
>> what
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Wed, Oct 12, 2016 at 05:03:11PM -0400, Boris Ostrovsky wrote:
> On 10/12/2016 05:27 AM, Wei Liu wrote:
> > On Tue, Oct 11, 2016 at 08:31:31PM +0100, Juergen Schinker wrote:
> >>  
> >>> We're going to tag rc2 some time this week. Thanks for help testing Xen!
> >>>
> >>> Wei.
> >>>
> >>>> J
> >>>>
> >>>> ----- On 11 Oct, 2016, at 09:37, Wei Liu wei.liu2@citrix.com wrote:
> >>>>
> >>>>> No, you can try to work around this issue by appending --disable-rombios
> >>>>> to your ./configure invocation. You can test major functionalities of
> >>>>> Xen just fine without rombios.
> >>>>>
> >>>>> Wei.
> >> Now for the fun of it I tried the RELEASE-4.7 
> >>
> >> and it turns out it has no support for xz-decompression 
> >>
> > That's probably because you don't have libzx development package
> > installed when building Xen.
> 
> 
> Which would be a new requirement for building Xen. And it broke our
> (pre-historic) build server that never had it installed.
> 

I don't think it breaks building Xen -- you just can't decompress xz
format file, right? Otherwise Juergen would not have been able to build
Xen.

Wei.

> -boris
> 
> 
> >
> >> so it can't decompress the kernel via pygrub
> >>
> >> what
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > https://lists.xen.org/xen-devel
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Juergen Schinker]

Right and still no solution 

there is no xz-dev or libxz-dev;  I installed everything which just looks remote like xz or lzma

building is no problem as I build with

./configure --enable-githttp --enable-systemd --disable-rombios --disable-qemu-traditional --disable-stubdom --disable-docs


I'm thinking of building a special VM with only stable Debian and old gcc and old everything - Pepperidge Farm remembers

and build there

----- On 13 Oct, 2016, at 09:04, Wei Liu wei.liu2@citrix.com wrote:

> I don't think it breaks building Xen -- you just can't decompress xz
> format file, right? Otherwise Juergen would not have been able to build
> Xen.
> 
> Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Thu, Oct 13, 2016 at 10:10:46AM +0100, Juergen Schinker wrote:
> Right and still no solution 
> 
> there is no xz-dev or libxz-dev;  I installed everything which just looks remote like xz or lzma
> 

On Debian it is called liblzma-dev. Not sure what distro you use.

> building is no problem as I build with
> 
> ./configure --enable-githttp --enable-systemd --disable-rombios --disable-qemu-traditional --disable-stubdom --disable-docs
> 
> 

And you sorta worked around the lzma requirement by disabling rombios.

This issue you encountered is a different issue from Boris'.

Wei.

> I'm thinking of building a special VM with only stable Debian and old gcc and old everything - Pepperidge Farm remembers
> 
> and build there
> 
> ----- On 13 Oct, 2016, at 09:04, Wei Liu wei.liu2@citrix.com wrote:
> 
> > I don't think it breaks building Xen -- you just can't decompress xz
> > format file, right? Otherwise Juergen would not have been able to build
> > Xen.
> > 
> > Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Juergen Schinker]

----- On 13 Oct, 2016, at 09:29, Wei Liu wei.liu2@citrix.com wrote:

> On Thu, Oct 13, 2016 at 10:10:46AM +0100, Juergen Schinker wrote:
>> Right and still no solution
>> 
>> there is no xz-dev or libxz-dev;  I installed everything which just looks remote
>> like xz or lzma
>> 
> 
> On Debian it is called liblzma-dev. Not sure what distro you use.
> 
>> building is no problem as I build with
>> 
>> ./configure --enable-githttp --enable-systemd --disable-rombios
>> --disable-qemu-traditional --disable-stubdom --disable-docs
>> 
>> 
> 
> And you sorta worked around the lzma requirement by disabling rombios.
> 
> This issue you encountered is a different issue from Boris'.
 
no still no solution

the xz problem is only for xen-4.7 but i gave up on that

my last test was 4.8-rc2 which also didn't work ; building and booting hypervizor is ok

xl tools                      nope

creating or starting a VM      nope

xl -v cr something              hangs forever

restarting xencommons           hangs

restarting xenconsoled          hangs

sigh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Thu, Oct 13, 2016 at 11:02:09AM +0100, Juergen Schinker wrote:
> 
> 
> ----- On 13 Oct, 2016, at 09:29, Wei Liu wei.liu2@citrix.com wrote:
> 
> > On Thu, Oct 13, 2016 at 10:10:46AM +0100, Juergen Schinker wrote:
> >> Right and still no solution
> >> 
> >> there is no xz-dev or libxz-dev;  I installed everything which just looks remote
> >> like xz or lzma
> >> 
> > 
> > On Debian it is called liblzma-dev. Not sure what distro you use.
> > 
> >> building is no problem as I build with
> >> 
> >> ./configure --enable-githttp --enable-systemd --disable-rombios
> >> --disable-qemu-traditional --disable-stubdom --disable-docs
> >> 
> >> 
> > 
> > And you sorta worked around the lzma requirement by disabling rombios.
> > 
> > This issue you encountered is a different issue from Boris'.
>  
> no still no solution
> 
> the xz problem is only for xen-4.7 but i gave up on that
> 
> my last test was 4.8-rc2 which also didn't work ; building and booting hypervizor is ok
> 
> xl tools                      nope
> 
> creating or starting a VM      nope
> 
> xl -v cr something              hangs forever
> 
> restarting xencommons           hangs
> 
> restarting xenconsoled          hangs
> 
> sigh

Hmm... I think no amount of hand-holding is going to help you.

In your situation I would suggest you to use various tools available on
Linux to figure out why it hang. Tools like strace, ldd, gdb etc, but
that's going to be rather technical and the finding isn't going to be
useful or interesting to you in the long run. The hang is likely due to
mismatch in various bits in the system.

I think your best bet is to have a clean installation of Xen.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

Add back xen-devel

On Thu, Oct 13, 2016 at 05:26:12PM +0100, Juergen Schinker wrote:
> 
> 
> ----- On 13 Oct, 2016, at 14:53, Wei Liu wei.liu2@citrix.com wrote:
> 
> > Hmm... I think no amount of hand-holding is going to help you.
> > 
> > In your situation I would suggest you to use various tools available on
> > Linux to figure out why it hang. Tools like strace, ldd, gdb etc, but
> > that's going to be rather technical and the finding isn't going to be
> > useful or interesting to you in the long run. The hang is likely due to
> > mismatch in various bits in the system.
> > 
> > I think your best bet is to have a clean installation of Xen.
> > 
> > Wei.
> 
> I don't want hand holding - this is a bug report dude
> 
> I;m very technical and it is useful and interesting

Sorry if that came out offensive to you -- I didn't mean to.

If you're really interested in going down this rabbit hole, I think you
will need to do the following:

1. Make sure all the Xen related libraries are properly installed into
   the location you specified when building Xen.
2. Use ldd to check if xl / xenstored are the ones you installed.
3. Make sure they can find all the libraries (ldd should be handy).
4. Use strace to identify when and where they hang.

There is a lot information about Xen in general on wiki.xenproject.org.
If you need to get more information about the architecture / moving
parts of Xen, check out the wiki.

After identifying why they don't work, you will have a lot more
information to either submit a detailed bug report or start hunting down
these issues for fun and profit (!). :-)

There isn't enough information in the current report for me to tell what
goes wrong in your setup. The basic life cycle of running Xen (the
operations in your bug report) is constantly tested in Xen project CI
and all developers -- neither CI nor humans spotted bugs in those areas
in the past week.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: ANNOUNCEMENT] Xen 4.8 RC2 FULL SUCCESS 13.10.16

[Juergen Schinker]

* Hardware:
 Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz


* Software:

Debian testing is the Host
 

* Guest operating systems:
Guests Ubuntu 14.04 LTS Debian Stretch/Sid Ubuntu 16.04
 
* Functionality tested:
xl 
creating booting 
pygrub

* Comments:

Wei Liu is the man

----- On 13 Oct, 2016, at 16:45, Wei Liu wei.liu2@citrix.com wrote:

> Add back xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH for-4.8] ipxe: update to newer commit

[Wei Liu]

On Thu, Oct 13, 2016 at 10:04:11AM +0100, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 05:03:11PM -0400, Boris Ostrovsky wrote:
> > On 10/12/2016 05:27 AM, Wei Liu wrote:
> > > On Tue, Oct 11, 2016 at 08:31:31PM +0100, Juergen Schinker wrote:
> > >>  
> > >>> We're going to tag rc2 some time this week. Thanks for help testing Xen!
> > >>>
> > >>> Wei.
> > >>>
> > >>>> J
> > >>>>
> > >>>> ----- On 11 Oct, 2016, at 09:37, Wei Liu wei.liu2@citrix.com wrote:
> > >>>>
> > >>>>> No, you can try to work around this issue by appending --disable-rombios
> > >>>>> to your ./configure invocation. You can test major functionalities of
> > >>>>> Xen just fine without rombios.
> > >>>>>
> > >>>>> Wei.
> > >> Now for the fun of it I tried the RELEASE-4.7 
> > >>
> > >> and it turns out it has no support for xz-decompression 
> > >>
> > > That's probably because you don't have libzx development package
> > > installed when building Xen.
> > 
> > 
> > Which would be a new requirement for building Xen. And it broke our
> > (pre-historic) build server that never had it installed.
> > 
> 
> I don't think it breaks building Xen -- you just can't decompress xz
> format file, right? Otherwise Juergen would not have been able to build
> Xen.

Now I see what happened -- upstream ipxe now requires lzma to build.

I can document that in README.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel