lshw run on Hyper-V VM hangs system

[Stephen Barrie]

When running lshw the VM sits scanning SCSI for a full minute. At the same time CPUs show 100% usage. This appears to happen on all 4.4 kernel versions running as virtual machines on Hyper-V even with the latest integration services. This did not happen on earlier kernel versions.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-4.4.0-62-generic 4.4.0-62.83
ProcVersionSignature: Ubuntu 4.4.0-62.83-generic 4.4.40
Uname: Linux 4.4.0-62-generic x86_64
AlsaDevices:
 total 0
 crw-rw---- 1 root audio 116, 1 Feb 9 13:29 seq
 crw-rw---- 1 root audio 116, 33 Feb 9 13:29 timer
AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: amd64
ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
Date: Thu Feb 9 15:02:52 2017
HibernationDevice: RESUME=/dev/mapper/ubuntu16--test--vg-swap_1
InstallationDate: Installed on 2017-02-09 (0 days ago)
InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.3)
IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
Lspci:

Lsusb: Error: command ['lsusb'] failed with exit code 1:
MachineType: Microsoft Corporation Virtual Machine
PciMultimedia:

ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcFB: 0 hyperv_fb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-62-generic.efi.signed root=/dev/mapper/ubuntu16--test--vg-root ro
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-62-generic N/A
 linux-backports-modules-4.4.0-62-generic N/A
 linux-firmware 1.157.8
RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/26/2012
dmi.bios.vendor: Microsoft Corporation
dmi.bios.version: Hyper-V UEFI Release v1.0
dmi.board.asset.tag: None
dmi.board.name: Virtual Machine
dmi.board.vendor: Microsoft Corporation
dmi.board.version: Hyper-V UEFI Release v1.0
dmi.chassis.asset.tag: 1717-5533-3372-2633-2683-8440-10
dmi.chassis.type: 3
dmi.chassis.vendor: Microsoft Corporation
dmi.chassis.version: Hyper-V UEFI Release v1.0
dmi.modalias: dmi:bvnMicrosoftCorporation:bvrHyper-VUEFIReleasev1.0:bd11/26/2012:svnMicrosoftCorporation:pnVirtualMachine:pvrHyper-VUEFIReleasev1.0:rvnMicrosoftCorporation:rnVirtualMachine:rvrHyper-VUEFIReleasev1.0:cvnMicrosoftCorporation:ct3:cvrHyper-VUEFIReleasev1.0:
dmi.product.name: Virtual Machine
dmi.product.version: Hyper-V UEFI Release v1.0
dmi.sys.vendor: Microsoft Corporation

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1663263

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Stephen Barrie (sbarrie)]

This reporting process doesn't work from a CLI only machine. The text-based browser does not cope with the authorisation steps used to send the info to the site and sits with "Waiting to hear from Launchpad about your decision.." when I quit the browser.

Is there a way to get this information to you manually via a PC with a regular browser?

There isn't anything in the syslogs relating to this issue anyway. Just seems to be weird behaviour introduced with new kernel as described. It can be easily reproduced on every kernel 4.4 Hyper-V virtual machine

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream stable kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.4 stable kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.48

[Stephen Barrie (sbarrie)]

I tried an upstream kernel (4.4.48-040448-generic #201702090334). This is still doing the same thing.

I have seen the messages below logged relating to the DVD drive when lshw is run. If I remove the DVD drive from the VM hardware the issue goes away.

Feb 16 11:59:10 ubuntu16-test kernel: [ 88.044077] sr 0:0:0:1: [sr0] tag#2 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Feb 16 11:59:10 ubuntu16-test kernel: [ 88.044082] sr 0:0:0:1: [sr0] tag#2 Sense Key : Not Ready [current]
Feb 16 11:59:10 ubuntu16-test kernel: [ 88.044085] sr 0:0:0:1: [sr0] tag#2 Add. Sense: Medium not present - tray closed
Feb 16 11:59:10 ubuntu16-test kernel: [ 88.044088] sr 0:0:0:1: [sr0] tag#2 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00
Feb 16 11:59:10 ubuntu16-test kernel: [ 88.044090] blk_update_request: critical target error, dev sr0, sector 0
Feb 16 11:59:10 ubuntu16-test kernel: [ 88.044158] sr 0:0:0:1: [sr0] unaligned transfer
Feb 16 11:59:10 ubuntu16-test kernel: [ 88.044162] sr 0:0:0:1: [sr0] unaligned transfer
Feb 16 11:59:10 ubuntu16-test kernel: [ 88.044165] sr 0:0:0:1: [sr0] unaligned transfer
Feb 16 11:59:10 ubuntu16-test kernel: [ 88.044168] sr 0:0:0:1: [sr0] unaligned transfer

These "unaligned transfer" messages repeat about 100 times. All messages have an identical time though the symptoms of the high cpu wait % last about a minute.

This does not occur in a 16.04 VM on VMware with a DVD drive, so the issue seems to be how the DVD drive is handled on the 4.4 kernel in a Hyper-V VM. Is there a workaround to make it skip the DVD drive if empty?

[Stephen Barrie (sbarrie)]

On further investigation this issue appears to be specific to SCSI DVD drives. Hyper-V uses SCSI drives by default in Generation 2 VMs whereas VMware always uses IDE for the DVD drive, so the problem may be the SCSI driver rather than something that is specific to Hyper-V.