Red Hat Bugzilla – Bug 951070
[NetKVM] Fix debug printouts line endings
Last modified: 2013-12-06 02:45:52 EST
Description of problem: In some cases debug printout is "glued" because of lack of EOL. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
http://git.engineering.redhat.com/?p=users/yvugenfi/internal-kvm-guest-drivers-windows/.git;a=commit;h=3a177b1430607d6f66c26f2462b8bd0e7da51797
http://git.engineering.redhat.com/?p=users/yvugenfi/internal-kvm-guest-drivers-windows/.git;a=commit;h=a265fcf63f8e418cd8fc2ea8ea84324d59fa267d/ http://git.engineering.redhat.com/?p=users/yvugenfi/internal-kvm-guest-drivers-windows/.git;a=commit;h=004d39904ead81de467414b53b3522aceb0cfe4b http://git.engineering.redhat.com/?p=users/yvugenfi/internal-kvm-guest-drivers-windows/.git;a=commit;h=502735f972fd5b28a22879c7b9f091d37633fd73
Pls provide how QE to test it , Thanks, Mike
I think QE can use debug view to test this issue 1.Start VM in the guest ,open debug view ,enable kernel debug 2.change netkvm macaddress in the guest (use a wrong macaddress) 3.check the output of debug view
Hello Mike, The case you described is good enough. Another test case: Disable\enable the device. Check that the output in DbgView is not "glued" to huge lines. Best regards, Yan.
Reproduced this issue on virtio-win-prewhql-0.1-58 Verified this issue on virtio-win-prewhql-0.1-59 Steps: 1.boot a win7-32 guest with virtio-net-pci 2.open debug view in guest and enable kernel debug 3.Disable\enable the virtio-net-pci in Device Manager. Actual Results: on virtio-win-prewhql-0.1-58, printout of DbgView is "glued"; on virtio-win-prewhql-0.1-59 verion ,printout of DbgView is not "glued". Based on above ,this issue has been fixed already .
Please move to verified according to comment #6.
Move status to VERIFIED according to comment #6
(In reply to comment #6) > Reproduced this issue on virtio-win-prewhql-0.1-58 > Verified this issue on virtio-win-prewhql-0.1-59 > > Steps: > 1.boot a win7-32 guest with virtio-net-pci > 2.open debug view in guest and enable kernel debug > 3.Disable\enable the virtio-net-pci in Device Manager. > > Actual Results: > on virtio-win-prewhql-0.1-58, printout of DbgView is "glued"; One detail example:during disable/enable,one of the debug information display as following: 00000498 2:08:22.281 AM [ConfigureMSIXVectors] Using message 1 for TX queue[ConfigureMSIXVectors] Using message 2 for controls[ApplyOffloadConfiguration] Requested: V4:IPCS=TxRx,TCPCS=TxRx,UDPCS=TxRx V6:TCPCS=TxRx,UDPCS=TxRx[SetOffloadField] IN TxIPChecksum TX: current=1 Supported TxRx Requested TxRx[SetOffloadField] OUT TxIPChecksum TX: new=1 (accepted)[SetOffloadField] IN TxTCPChecksum TX: current=1 Supported TxRx Requested TxRx[SetOffloadField] OUT TxTCPChecksum TX: new=1 (accepted)[SetOffloadField] IN TxUDPChecksum TX: current=1 Supported TxRx Requested TxRx[SetOffloadField] OUT TxUDPChecksum TX: new=1 (accepted)[SetOffloadField] IN RxIPChecksum RX: current=1 Supported TxRx Requested TxRx[SetOffloadField] OUT RxIPChecksum RX: new=1 (accepted)[SetOffloadField] IN RxTCPChecksum RX: current=1 Supported TxRx Requested TxRx[SetOffloadField] OUT RxTCPChecksum RX: new=1 (accepted)[SetOffloadField] IN RxUDPChecksum RX: current=1 Supported TxRx Requested TxRx > on virtio-win-prewhql-0.1-59 verion ,printout of DbgView is not "glued". printout is seperated,the message displays as following: 00000181 2:11:20.500 AM [ConfigureMSIXVectors] Using MSIX interrupts (3 messages, irql 10) 00000182 2:11:20.500 AM [ConfigureMSIXVectors] MSIX message0=000049B0=>FEE0300C 00000183 2:11:20.500 AM [ConfigureMSIXVectors] MSIX message1=000049A0=>FEE0300C 00000184 2:11:20.500 AM [ConfigureMSIXVectors] MSIX message2=00004990=>FEE0300C 00000185 2:11:20.500 AM [ConfigureMSIXVectors] Using message 0 for RX queue 00000186 2:11:20.500 AM [ConfigureMSIXVectors] Using message 1 for TX queue 00000187 2:11:20.500 AM [ConfigureMSIXVectors] Using message 2 for controls 00000188 2:11:20.500 AM [ApplyOffloadConfiguration] Requested: V4:IPCS=TxRx,TCPCS=TxRx,UDPCS=TxRx V6:TCPCS=TxRx,UDPCS=TxRx 00000189 2:11:20.500 AM [SetOffloadField] IN TxIPChecksum TX: current=-1 Supported TxRx Requested TxRx 00000190 2:11:20.500 AM [SetOffloadField] OUT TxIPChecksum TX: new=1 (accepted) 00000191 2:11:20.500 AM [SetOffloadField] IN TxTCPChecksum TX: current=-1 Supported TxRx Requested TxRx 00000192 2:11:20.500 AM [SetOffloadField] OUT TxTCPChecksum TX: new=1 (accepted) 00000193 2:11:20.500 AM [SetOffloadField] IN TxUDPChecksum TX: current=-1 Supported TxRx Requested TxRx 00000194 2:11:20.500 AM [SetOffloadField] OUT TxUDPChecksum TX: new=1 (accepted) 00000195 2:11:20.500 AM [SetOffloadField] IN RxIPChecksum RX: current=-1 Supported TxRx Requested TxRx 00000196 2:11:20.500 AM [SetOffloadField] OUT RxIPChecksum RX: new=1 (accepted) 00000197 2:11:20.500 AM [SetOffloadField] IN RxTCPChecksum RX: current=-1 Supported TxRx Requested TxRx 00000198 2:11:20.500 AM [SetOffloadField] OUT RxTCPChecksum RX: new=1 (accepted) 00000199 2:11:20.500 AM [SetOffloadField] IN RxUDPChecksum RX: current=-1 Supported TxRx Requested TxRx 00000200 2:11:20.500 AM [SetOffloadField] OUT RxUDPChecksum RX: new=1 (accepted) 00000201 2:11:20.500 AM [SetOffloadField] IN TxTCPv6Checksum TX: current=-1 Supported TxRx Requested TxRx 00000202 2:11:20.500 AM [SetOffloadField] OUT TxTCPv6Checksum TX: new=1 (accepted) 00000203 2:11:20.500 AM [SetOffloadField] IN TxUDPv6Checksum TX: current=-1 Supported TxRx Requested TxRx 00000204 2:11:20.500 AM [SetOffloadField] OUT TxUDPv6Checksum TX: new=1 (accepted) 00000205 2:11:20.500 AM [SetOffloadField] IN RxTCPv6Checksum RX: current=-1 Supported TxRx Requested TxRx 00000206 2:11:20.500 AM [SetOffloadField] OUT RxTCPv6Checksum RX: new=1 (accepted) 00000207 2:11:20.500 AM [SetOffloadField] IN RxUDPv6Checksum RX: current=-1 Supported TxRx Requested TxRx > Based on above ,this issue has been fixed already .
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1729.html