everts the patch that caused the
original problem):
Reviewed-by: Michael Brown
Thanks,
Michael
On 17/06/2021 13:55, Michael Brown wrote:
one way out could be to call objcopy -D $PARAMS || objcopy $PARAMS
Testing on a clean "centos:7" container shows that "objcopy -D" works as
expected (and "objcopy --help" shows the option as existing).
This contain
On 16/06/2021 14:33, Bernhard M. Wiedemann wrote:
So this means, CentOS7 binutils has
9cb80f72d8b from 2011-12-21
but not
git blame binutils/objcopy.c|grep enable-determini
955d0b3bd75 (Roland McGrath 2013-01-07 17:40:59 + 549) -D
--enable-deterministic-archives\n\
2e30cb575a1 (Cary
On 17/05/2021 22:43, Marek Marczykowski-Górecki wrote:
In any case, the issue is not calling the hotplug script, responsible
for configuring newly created vif interface. Not kernel waiting for it.
So, I think both commits should still be reverted.
Did you also test the ability for a domU to hav
On 10/05/2021 19:53, Marek Marczykowski-Górecki wrote:
On Mon, May 10, 2021 at 07:47:01PM +0100, Michael Brown wrote:
That doesn't sound plausible to me. In the setup as you describe, how is
the kernel expected to differentiate between "hotplug script has not yet
created the node&quo
On 10/05/2021 19:32, Marek Marczykowski-Górecki wrote:
On Tue, Apr 13, 2021 at 04:25:12PM +0100, Michael Brown wrote:
The logic in connect() is currently written with the assumption that
xenbus_watch_pathfmt() will return an error for a node that does not
exist. This assumption is incorrect
rios such as reloading the xen-netfront
module within a domU, or booting a domU via iPXE. There is
unfortunately no way for the domU to work around this dom0 bug.
Fix by explicitly checking for existence of the "hotplug-status" node,
thereby creating the behaviour that was previously assumed
On 13/04/2021 11:55, Paul Durrant wrote:
Ok, so it sound like this was probably my misunderstanding of xenstore
semantics in the first place (although I'm sure I remember watch
registration failing for non-existent nodes at some point in the past...
that may have been with a non-upstream versio
On 13/04/2021 08:12, Paul Durrant wrote:
If the frontend subsequently disconnects and reconnects (e.g.
transitions through Closed->Initialising->Connected) then:
- Nothing recreates "hotplug-status"
- When the frontend re-enters Connected state, connect() sets up a
watch on "hotplug-status" a
Commit https://github.com/torvalds/linux/commit/1f25657 ("xen-netback:
remove 'hotplug-status' once it has served its purpose") seems to have
introduced a regression that prevents a vif frontend from transitioning
more than once into Connected state.
As far as I can tell:
- The defined vif sc
10 matches
Mail list logo
