On 21.12.2015 18:17, Laine Stump wrote: > These are all related to excessive, misleading, or missing info in > logs when trying to debug problems with SR-IOV network > devices. > > > Patch 2 does change the logging to eliminate an error message when no > error has occurred (or prevent overwriting a prior error if a > DISASSOCIATE is happening as part of the cleanup after said prior > error), but there is a change to behavior in patch 2 that could have > unintended bad consequences, which is why I've Cc'ed Christian at > Cisco and Stefan and Shivaprasad at IBM, in hopes that they (or > someone they can contact at their respective organizations) can look > at the change and report back if it will cause a problem. The change > in question (again, in 2/5) is that we would previously always return > a status of 0 (PORT_VDP_RESPONSE_SUCCESS) from > virNetDevVPortProfileGetStatus if instanceId was NULL; that is > *always* the case for both ASSOCIATE and DISASSOCIATE for 802.1Qbg, > and is true for all DISASSOCIATE commands for 802.1Qbh. With the > change in Patch 2/5, we now will now set status to the actual > IFLA_PORT_RESPONSE from the response message, which seems to be > correct behavior, but could have bad side effects if there is a > previously undiscovered bug at the other end of the communication. > > Laine Stump (5): > util: report the MAC address that couldn't be set > util: don't log error in virNetDevVPortProfileGetStatus if instanceId > is NULL > util: improve error reporting in virNetDevVPortProfileGetStatus > util: reduce debug log in virPCIGetVirtualFunctions() > docs: update to properly reflect meaning of fields in log filter > > daemon/libvirtd.conf | 14 ++++++--- > docs/logging.html.in | 15 ++++++---- > src/util/virnetdev.c | 23 +++++++++----- > src/util/virnetdevvportprofile.c | 65 ++++++++++++++++++++++++++++++++-------- > src/util/virpci.c | 37 ++++++----------------- > src/util/virpci.h | 4 +-- > 6 files changed, 98 insertions(+), 60 deletions(-) > ACK series modulo 2/5 where I don't feel confident enough. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list