Bug 662903

Summary:	Inappropriate ioctl for device When set harddisk to low performance status on RHEL 5.6 host
Product:	Red Hat Enterprise Linux 5	Reporter:	Joy Pu <ypu>
Component:	kvm	Assignee:	Kevin Wolf <kwolf>
Status:	CLOSED WONTFIX	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.6	CC:	chellwig, mkenneth, virt-maint
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	683428 (view as bug list)		Environment:
Last Closed:	2011-01-14 16:24:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	580948, 683428

Description Joy Pu 2010-12-14 06:14:20 UTC

Description:
Boot up a rhel 6 guest and set the harddisk with hdparm it will fail, and return this message:
/dev/sda:
 setting fs readahead to 64
 setting unmaskirq to 0 (off)
 HDIO_SET_UNMASKINTR failed: Inappropriate ioctl for device
 setting using_dma to 0 (off)
 HDIO_SET_DMA failed: Inappropriate ioctl for device
 HDIO_GET_UNMASKINTR failed: Inappropriate ioctl for device
 HDIO_GET_DMA failed: Inappropriate ioctl for device
 readahead     = 64 (on)
The same operate will pass in RHEL6 host.


Version-Release number of selected component (if applicable):
Host: 2.6.18-236.el5
Guest: 2.6.32-71.7.1.el6
Qemu:
rpm -qa |grep kvm
kmod-kvm-83-222.el5
etherboot-roms-kvm-5.4.4-13.el5
kmod-kvm-debug-83-222.el5
etherboot-zroms-kvm-5.4.4-13.el5
kvm-qemu-img-83-222.el5
kvm-tools-83-222.el5
kvm-debuginfo-83-222.el5
kvm-83-222.el5


How reproducible:
Always

Steps to Reproduce:
1.Boot up a rhel 6 guest
2.change the harddisk status with hdparm
# hdparm -a64 -d0 -u0 /dev/sda


Actual results:
Can not set it in guest.
Expected results:
Harddisk should be set to low performance, and works well.

Additional info:
1.Host cpuinfo
processor	: 3
vendor_id	: GenuineIntel
cpu family	: 6
model		: 37
model name	: Intel(R) Core(TM) i5 CPU       M 520  @ 2.40GHz
stepping	: 2
cpu MHz		: 1199.000
cache size	: 3072 KB
physical id	: 0
siblings	: 4
core id		: 2
cpu cores	: 2
apicid		: 5
initial apicid	: 5
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid
bogomips	: 4788.19
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Comment 2 chellwig@redhat.com 2010-12-15 09:08:52 UTC

We don't implement a lot of the ATA SETFEATURES command.  Given that messing with this settings won't have an effect anyway I'm not sure there's too much of a point implementing these subcommands.

If we absolutely want to get rid of the warnings I can look into implementing mostly no-op stubs for it - although that's not quite as easy as it sounds as we need to store state that the GETFEATURES call later on will return the changed values, and we need to save that state for migrations, etc.