Bug 1067784
| Summary: | qemu-kvm: block.c:850: bdrv_open_common: Assertion `bs->request_alignment != 0' failed. Aborted (core dumped) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Sibiao Luo <sluo> |
| Component: | qemu-kvm | Assignee: | Kevin Wolf <kwolf> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.0 | CC: | acathrow, areis, chayang, hhuang, huding, jcody, juzhang, knoel, kwolf, michen, pbonzini, qzhang, sluo, virt-maint, xfu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-1.5.3-53.el7 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-13 12:52:02 UTC | Type: | Bug |
| 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: | 1062840 | ||
| Bug Blocks: | 1062841 | ||
|
Description
Sibiao Luo
2014-02-21 04:02:39 UTC
(gdb) bt full
#0 0x00007f88ccb2d989 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f88ccb2f098 in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x00007f88ccb268f6 in __assert_fail_base () from /lib64/libc.so.6
No symbol table info available.
#3 0x00007f88ccb269a2 in __assert_fail () from /lib64/libc.so.6
No symbol table info available.
#4 0x00007f88d1fd0f32 in bdrv_open_common (bs=bs@entry=0x7f88d4eeb010, file=file@entry=0x0,
options=options@entry=0x7f88d4eeba20, flags=flags@entry=24802, drv=drv@entry=0x7f88d25c0740 <bdrv_iscsi>,
errp=0x7fffcc973620) at block.c:850
ret = 0
open_flags = <optimized out>
filename = 0x7f88d4d57250 ""
local_err = 0x0
__PRETTY_FUNCTION__ = "bdrv_open_common"
#5 0x00007f88d1fd54fc in bdrv_file_open (pbs=pbs@entry=0x7fffcc9736a0,
filename=filename@entry=0x7f88d4ee8500 "iscsi://10.66.9.107/iqn.2008-09.com.example:server.target2/0",
options=0x7f88d4eeba20, flags=24802, errp=errp@entry=0x7fffcc9736b0) at block.c:948
bs = 0x7f88d4eeb010
drv = 0x7f88d25c0740 <bdrv_iscsi>
drvname = <optimized out>
allow_protocol_prefix = <optimized out>
local_err = 0x0
ret = <optimized out>
#6 0x00007f88d1fd5a06 in bdrv_open (bs=0x7f88d4ee85c0,
filename=filename@entry=0x7f88d4ee8500 "iscsi://10.66.9.107/iqn.2008-09.com.example:server.target2/0",
options=0x7f88d4ee8fd0, options@entry=0x7f88d4d843d0, flags=8418, drv=drv@entry=0x7f88d25c2560 <bdrv_raw>,
errp=errp@entry=0x7fffcc975758) at block.c:1171
ret = <optimized out>
tmp_filename = "\320\367\325Ԉ\177\000\000\000\370\325Ԉ\177", '\000' <repeats 26 times>, "z]\224Έ\177\000\000\001\000\000\000\377\177\000\000\000\200\356ш\177\000\000/usr/lib64/sasl2/\000\023Ɉ\177\000\000\342Q\317ш\177\000\000@M\227\314\377\177\000\000\060M\227\314\377\177\000\000\233U\307̈\177\000\000\001\000\000\000\000\000\000\000\220U\307̈\177\000\000\271\372\263̈\177\000\000\001\000\000\000\377\177\000\000\000\220\356ш\177\000\000 G\227\314\377\177\000\000ho\226ʈ\177\000\000\024\000\000\000\000\000\000\000\342Q\317ш\177\000\000\001\000\000\000\377\177\000\000\240\251\356ш\177\000\000\260M\227\314\377"...
file = 0x0
file_options = 0x7f88d4ee9ff0
drvname = <optimized out>
local_err = 0x0
__PRETTY_FUNCTION__ = "bdrv_open"
#7 0x00007f88d20050df in blockdev_init (bs_opts=bs_opts@entry=0x7f88d4d843d0, type=type@entry=IF_NONE,
errp=errp@entry=0x7fffcc975830) at blockdev.c:516
buf = <optimized out>
file = 0x7f88d4ee8500 "iscsi://10.66.9.107/iqn.2008-09.com.example:server.target2/0"
serial = 0x0
ro = <optimized out>
bdrv_flags = 226
on_read_error = <optimized out>
on_write_error = 2
dinfo = 0x7f88d4ee8550
io_limits = {bps = {0, 0, 0}, iops = {0, 0, 0}}
snapshot = 0
copy_on_read = false
ret = <optimized out>
error = 0x0
opts = 0x7f88d4d67810
id = <optimized out>
has_driver_specific_opts = false
drv = 0x7f88d25c2560 <bdrv_raw>
#8 0x00007f88d2005cdf in drive_init (all_opts=0x7f88d4d57030, block_default_type=<optimized out>) at blockdev.c:859
value = <optimized out>
dinfo = 0x0
bs_opts = 0x7f88d4d843d0
legacy_opts = 0x7f88d4d83850
media = <optimized out>
type = IF_NONE
cyls = 0
secs = <optimized out>
translation = 0
max_devs = 0
bus_id = 0
unit_id = <optimized out>
index = <optimized out>
devaddr = 0x0
read_only = <optimized out>
copy_on_read = <optimized out>
local_err = 0x0
__PRETTY_FUNCTION__ = "drive_init"
#9 0x00007f88d20fd34b in drive_init_func (opts=<optimized out>, opaque=<optimized out>) at vl.c:1076
block_default_type = <optimized out>
#10 0x00007f88d221155b in qemu_opts_foreach (list=<optimized out>, func=func@entry=0x7f88d20fd340 <drive_init_func>,
opaque=opaque@entry=0x7f88d25f5170 <pc_machine_rhel700+48>, abort_on_failure=abort_on_failure@entry=1)
at util/qemu-option.c:1149
loc = {kind = LOC_CMDLINE, num = 2, ptr = 0x7fffcc975dc8, prev = 0x7f88d2e21340 <std_loc>}
opts = 0x7f88d4d57030
rc = 0
#11 0x00007f88d1fbd1fd in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4137
i = <optimized out>
snapshot = 0
linux_boot = 0
icount_option = 0x0
initrd_filename = 0x0
kernel_filename = 0x0
kernel_cmdline = 0x7f88d2269e60 ""
boot_order = 0x7f88d22220c6 "cad"
ds = <optimized out>
cyls = 0
heads = 0
secs = 0
translation = 0
hda_opts = <optimized out>
opts = 0x7f88d4d56690
machine_opts = <optimized out>
olist = <optimized out>
optind = 48
optarg = 0x7fffcc9777a8 "scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk"
loadvm = 0x0
machine = 0x7f88d25f5140 <pc_machine_rhel700>
cpu_model = 0x0
vga_model = 0x7f88d224bbab "none"
pid_file = 0x0
incoming = 0x0
show_vnc_port = 0
defconfig = <optimized out>
userconfig = false
log_mask = <optimized out>
log_file = 0x0
mem_trace = {malloc = 0x7f88d20fdaf0 <malloc_and_trace>, realloc = 0x7f88d20fdad0 <realloc_and_trace>,
free = 0x7f88d20fdac0 <free_and_trace>, calloc = 0x0, try_malloc = 0x0, try_realloc = 0x0}
trace_events = 0x0
trace_file = 0x0
__PRETTY_FUNCTION__ = "main"
args = {machine = 0x7fffcc9773ed, ram_size = 140225614321176, boot_device = 0x18 <Address 0x18 out of bounds>,
kernel_filename = 0xffff80003368a551 <Address 0xffff80003368a551 out of bounds>,
kernel_cmdline = 0x2 <Address 0x2 out of bounds>, initrd_filename = 0x0,
cpu_model = 0x7fff00000030 <Address 0x7fff00000030 out of bounds>}
(gdb)
# /usr/libexec/qemu-kvm -M pc -enable-kvm -m 4096 -smp 4 -no-kvm-pit-reinjection -usb -device usb-tablet,id=input0 -name sluo -uuid 990ea161-6b67-47b2-b803-19fb01d30d30 -rtc base=localtime,clock=host,driftfix=slew -drive file=/home/RHEL_7.0_20140212.1_Server_x86_64.qcow2,if=none,id=drive-system-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop -device virtio-blk-pci,vectors=0,bus=pci.0,addr=0x4,scsi=off,drive=drive-system-disk,id=system-disk,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=00:01:02:03:40:21,bus=pci.0,addr=0x5 -k en-us -boot menu=on -qmp tcp:0:5555,server,nowait -serial unix:/tmp/ttyS0,server,nowait -vnc :1 -spice disable-ticketing,port=5931 -monitor stdio -drive file=iscsi://10.66.9.107/iqn.2008-09.com.example:server.target2/0,if=none,id=drive-data-disk,format=raw,cache=none,aio=native -iscsi id=iqn1,user=redhat,password=redhat -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x7 -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk Please retry with /1 instead of /0 at the end of the iscsi URL. *** Bug 1062841 has been marked as a duplicate of this bug. *** I can reproduce it with /0. It is a bit ugly to assert this way, it should be fixed. It is not related to CHAP authentication, the following is enough IQN=iqn.2003-01.org.linux-iscsi.san01.x8664:sn.05135a0e4a11 URL=iscsi://127.0.0.1/$IQN/0 IMAGE=~/test2.img service tgtd start tgtadm --lld iscsi --op new --mode target --tid 1 -T $IQN tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b $IMAGE tgtadm --lld iscsi --op new --mode portal --param portal=127.0.0.1:3260 tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL /usr/libexec/qemu-kvm -vnc :1 -drive if=ide,file=$URL *** Bug 1062840 has been marked as a duplicate of this bug. *** (In reply to Paolo Bonzini from comment #3) > Please retry with /1 instead of /0 at the end of the iscsi URL. Use /1 is OK, but /0 will meet this bug(qemu-kvm: block.c:850: bdrv_open_common: Assertion `bs->request_alignment != 0' failed. Aborted (core dumped)). # uname -r && rpm -q qemu-kvm && rpm -q libiscsi 3.10.0-86.el7.x86_64 qemu-kvm-1.5.3-47.el7.x86_64 libiscsi-1.9.0-6.el7.x86_64 e.g1:...-drive file=iscsi://10.66.9.107/iqn.2008-09.com.example:server.target2/1,if=none,id=drive-data-disk,format=raw,cache=none,aio=native -iscsi id=iqn1,user=redhat,password=redhat -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x7 -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk Above e.g1 is ok which can boot up guest successfully and detect the libiscsi disk in guest correctly. e.g2:...-drive file=iscsi://10.66.9.107/iqn.2008-09.com.example:server.target2/0,if=none,id=drive-data-disk,format=raw,cache=none,aio=native -iscsi id=iqn1,user=redhat,password=redhat -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x7 -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk Above e.g2 meet bug 1067784 which qemu-kvm: block.c:850: bdrv_open_common: Assertion `bs->request_alignment != 0' failed. Aborted (core dumped). # iscsi-ls -s iscsi://redhat:redhat.9.107:3260/iqn.2008-09.com.example:server.target2 Target:iqn.2008-09.com.example:server.target2 Portal:10.66.9.107:3260,1 Lun:0 Type:STORAGE_ARRAY_CONTROLLER Lun:1 Type:DIRECT_ACCESS (Size:99M) Lun:2 Type:DIRECT_ACCESS (Size:99M) (In reply to Paolo Bonzini from comment #5) > I can reproduce it with /0. It is a bit ugly to assert this way, it should > be fixed. Can you explain why you think that the problem is with the assertion and not with the iscsi block driver? An alignment of 0 certainly looks wrong (if there is no specific requirement, it should be 1). I think the alignment should not be checked if bs->sg is true. request_alignment is never used for bs->sg, and a value of zero should be fine.
If you prefer to take part of this "if":
/* For /dev/sg devices the alignment is not really used.
With buffered I/O, we don't have any restrictions. */
if (bs->sg || !(s->open_flags & O_DIRECT)) {
bs->request_alignment = 1;
s->buf_align = 1;
return;
}
and move it to generic code, that's also fine, but I think an invalid value (such as 0) is better for the bs->sg case.
Oh, okay, I wasn't aware that iscsi uses bs->sg. They are special indeed, so I'm okay with skipping the test for them. (In fact, they are so special that I would prefer if they weren't a BlockDriverState at all, but I believe there was a reason for it, even though I can't remember it right now...) > In fact, they are so special that I would
> prefer if they weren't a BlockDriverState at all
On one hand I agree they are very special; I think historically there was no reason to make /dev/sg a BlockDriverState.
On the other hand, if /dev/sg were not BlockDriverStates, we would have to invent yet another polymorphic backend kind, with nontrivial code duplication between block/{raw-posix,iscsi}.c and the new kind. So perhaps it's the worst choice except all others...
Fix included in qemu-kvm-1.5.3-53.el7 Reproduce this bug using following version: kernel-3.10.0-99.el7.x86_64 qemu-kvm-1.5.3-48.el7.x86_64 Steps to Reproduce: 1. setup a iscsi server as comment 0 2. Boot a guest with this libiscsi disk # /usr/libexec/qemu-kvm -M pc -enable-kvm -m 4096 -smp 4...-drive file=iscsi://10.66.9.107/iqn.2008-09.com.example:server.target2/0,if=none,id=drive-data-disk,format=raw,cache=none,aio=native -iscsi id=iqn1,user=redhat,password=redhat -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x7 -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk Actual results: after step2, qemu-kvm core dumped as following: qemu-kvm: block.c:850: bdrv_open_common: Assertion `bs->request_alignment != 0' failed. Aborted (core dumped) Verify this bug using the following version: kernel-3.10.0-99.el7.x86_64 qemu-kvm-1.5.3-53.el7.x86_64 Steps to Verification: 1. setup a iscsi server as comment 0 2. Boot a guest with this libiscsi disk # /usr/libexec/qemu-kvm -M pc -enable-kvm -m 4096 -smp 4...-drive file=iscsi://10.66.9.107/iqn.2008-09.com.example:server.target2/0,if=none,id=drive-data-disk,format=raw,cache=none,aio=native -iscsi id=iqn1,user=redhat,password=redhat -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x7 -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk Actual results: after step2, qemu-kvm quits with the error info: (qemu) qemu-kvm: -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk: unwanted /dev/sg* qemu-kvm: -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk: Device initialization failed. qemu-kvm: -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk: Device 'scsi-hd' could not be initialized This is the correct error message indeed. A SCSI generic device like LUN 0 of your iscsi target can only be used with scsi-generic, not with scsi-disk. (In reply to Kevin Wolf from comment #17) > This is the correct error message indeed. A SCSI generic device like LUN 0 of > your iscsi target can only be used with scsi-generic, not with scsi-disk. Yes, thanks for your kindly reminds, both the pass-through(scsi-block) and assign(scsi-hd) LUN 0 of my iscsi target fail with a waring prompt 'unwanted /dev/sg*' if specified '/0' for it, while if specified '/1' to use LUN 1 of my target which has no such issue. # tgt-admin --show Target 1: iqn.2008-09.com.example:server.target2 System information: Driver: iscsi State: ready ... LUN information: LUN: 0 Type: controller SCSI ID: IET 00010000 SCSI SN: beaf10 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: null Backing store path: None Backing store flags: LUN: 1 Type: disk SCSI ID: IET 00010001 SCSI SN: beaf11 Size: 2097 MB, Block size: 512 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: rdwr Backing store path: /iscsi.img Backing store flags: Account information: redhat ACL information: ALL e.g1:...-drive file=iscsi://10.66.9.107/iqn.2008-09.com.example:server.target1/0,if=none,id=drive-data-disk,format=raw,cache=none,aio=native -iscsi id=iqn1,user=redhat,password=redhat -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x7 -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-diskWarning: option deprecated, use lost_tick_policy property of kvm-pit instead. QEMU 1.5.3 monitor - type 'help' for more information (qemu) qemu-kvm: -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk: unwanted /dev/sg* qemu-kvm: -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk: Device initialization failed. qemu-kvm: -device scsi-hd,drive=drive-data-disk,bus=scsi1.0,id=data-disk: Device 'scsi-hd' could not be initialized e.g2:... -drive file=iscsi://10.66.9.107/iqn.2008-09.com.example:server.target1/0,if=none,id=drive-data-disk,format=raw,cache=none,aio=native -iscsi id=iqn1,user=redhat,password=redhat -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x7 -device scsi-block,drive=drive-data-disk,bus=scsi1.0,id=data-disk Warning: option deprecated, use lost_tick_policy property of kvm-pit instead. QEMU 1.5.3 monitor - type 'help' for more information (qemu) qemu-kvm: -device scsi-block,drive=drive-data-disk,bus=scsi1.0,id=data-disk: unwanted /dev/sg* qemu-kvm: -device scsi-block,drive=drive-data-disk,bus=scsi1.0,id=data-disk: Device initialization failed. qemu-kvm: -device scsi-block,drive=drive-data-disk,bus=scsi1.0,id=data-disk: Device 'scsi-block' could not be initialized According to comment #15 and comment #17, set this issue to VERIFIED status, please correct me if any mistake, thanks. -------------------------------------------------------------------------- But if I met another issue 'qemu-kvm: Failed to sync10 data on iSCSI lun. SENSE KEY:ILLEGAL_REQUEST(5) ASCQ:INVALID_OPERATION_CODE(0x2000)' when shutdown guest if i use scsi-generic to specified the LUN 0 of my iscsi target with '/0'. I will separate it to a new issue(bug 1078650). (qemu) qemu-kvm: Failed to sync10 data on iSCSI lun. SENSE KEY:ILLEGAL_REQUEST(5) ASCQ:INVALID_OPERATION_CODE(0x2000) qemu-kvm: Failed to sync10 data on iSCSI lun. SENSE KEY:ILLEGAL_REQUEST(5) ASCQ:INVALID_OPERATION_CODE(0x2000) Best Regards, sluo This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request. |