<div dir="ltr">Hi,<div>Sorry for the delay,</div><div>Managed to test it locally too and it seems to fix the problem,</div><div>Thanks Too!</div><div><br></div><div>E</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 28, 2017 at 2:16 PM, Michael Brown <span dir="ltr"><<a href="mailto:mcb30@ipxe.org" target="_blank">mcb30@ipxe.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 26/12/17 12:47, Michael Brown wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 25/12/17 11:20, Eytan Heidingsfeld wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I retried with DEBUG=xenbus and saw that xenbus_probe_type failed for the device: device/suspend/event-channel (I think because it doesn't have a backend key - it is empty). As this device isn't critical for the usage of netfront I just commented out the error in xenbus_probe_type for one device and now it works fine.<br>
<br>
Is there any reason failing to probe the type of one device should fail the whole probe of the xenbus?<br>
<br>
I can formalize a patch the prints a warning with DBG and allows it to continue but I was wondering if there was any downside to that?<br>
</blockquote>
<br>
Does the attached (untested) patch fix the problem?  This patch skips probing any device type for which we don't have a driver anyway.<br>
</blockquote>
<br></span>
I checked that this patch did not cause a regression, and have pushed it as<br>
<br>
  <a href="http://git.ipxe.org/ipxe.git/commitdiff/e4461f6" rel="noreferrer" target="_blank">http://git.ipxe.org/ipxe.git/c<wbr>ommitdiff/e4461f6</a><br>
<br>
Thanks!<span class="HOEnZb"><font color="#888888"><br>
<br>
Michael<br>
</font></span></blockquote></div><br></div>