):
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
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" an
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
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 to exist.
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
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"
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
10 matches
Mail list logo
