open-iscsi fails to stop, causes kernel lockup

Bug #1207760 reported by Alexander List on 2013-08-02
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
open-iscsi (Ubuntu)
High
Unassigned

Bug Description

Setup:

I have a Synology DS1512+ NAS and use that as an iSCSI target.
The iscsi volume is used as a physical volume for LVM.
LVM logical volumes are mounted on the host.
Inside one of the volumes, which is mounted on /srv/vm, I have VM images which are used by qemu-kvm.

Every time I need to stop open-iscsi, due to reboot, or even if there is a package update (!), open-iscsi tries to stop (!) all targets without warning and fails.

Even if I stop all services and unmount my LVs, open-iscsi fails to stop.

Hardware is a Supermicro X9SCM-F, using a Samsung SSD as system disk.

Aug 2 15:04:24 zimba kernel: [ 74.051378] Aborting journal on device dm-3-8.
Aug 2 15:04:24 zimba kernel: [ 74.056034] Buffer I/O error on device dm-3, logical block 134250496
Aug 2 15:04:24 zimba kernel: [ 74.062523] lost page write due to I/O error on dm-3
Aug 2 15:04:24 zimba kernel: [ 74.062566] JBD2: I/O error detected when updating journal superblock for dm-3-8.
Aug 2 15:04:42 zimba kernel: [ 92.480114] BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u:5:79]
Aug 2 15:04:42 zimba kernel: [ 92.486619] Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables kvm_intel kvm rfcomm bnep bluetooth nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi rc_tt_1500 tda10048 tda827x ir_lirc_codec lirc_dev tda10023 ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder dvb_usb_ttusb2 ir_nec_decoder dvb_usb dvb_core rc_core bridge stp option psmouse usb_wwan i7core_edac edac_core serio_raw joydev usbserial dm_multipath lp mac_hid parport ext2 usb_storage usbhid hid e1000e
Aug 2 15:04:42 zimba kernel: [ 92.486652] CPU 0
Aug 2 15:04:42 zimba kernel: [ 92.486652] Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables kvm_intel kvm rfcomm bnep bluetooth nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi rc_tt_1500 tda10048 tda827x ir_lirc_codec lirc_dev tda10023 ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder dvb_usb_ttusb2 ir_nec_decoder dvb_usb dvb_core rc_core bridge stp option psmouse usb_wwan i7core_edac edac_core serio_raw joydev usbserial dm_multipath lp mac_hid parport ext2 usb_storage usbhid hid e1000e
Aug 2 15:04:42 zimba kernel: [ 92.486677]
Aug 2 15:04:42 zimba kernel: [ 92.486678] Pid: 79, comm: kworker/u:5 Not tainted 3.2.0-33-generic #52-Ubuntu Supermicro X8SIL/X8SIL
Aug 2 15:04:42 zimba kernel: [ 92.486681] RIP: 0010:[<ffffffff8165b219>] [<ffffffff8165b219>] _raw_spin_unlock_irqrestore+0x19/0x30
Aug 2 15:04:42 zimba kernel: [ 92.486687] RSP: 0018:ffff8804217c7d98 EFLAGS: 00000286
Aug 2 15:04:42 zimba kernel: [ 92.486688] RAX: 0000000000000286 RBX: 0000000000000008 RCX: 0000000000000008
Aug 2 15:04:42 zimba kernel: [ 92.486690] RDX: ffff8804244c7808 RSI: 0000000000000286 RDI: 0000000000000286
Aug 2 15:04:42 zimba kernel: [ 92.486691] RBP: ffff8804217c7da0 R08: ffffffff81cde520 R09: 0000000000000100
Aug 2 15:04:42 zimba kernel: [ 92.486692] R10: dead000000200200 R11: 0000000000000000 R12: ffffffff81cde520
Aug 2 15:04:42 zimba kernel: [ 92.486694] R13: 0000000000000100 R14: dead000000200200 R15: 0000000000000000
Aug 2 15:04:42 zimba kernel: [ 92.486695] FS: 0000000000000000(0000) GS:ffff88043fc00000(0000) knlGS:0000000000000000
Aug 2 15:04:42 zimba kernel: [ 92.486697] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Aug 2 15:04:42 zimba kernel: [ 92.486698] CR2: 00007ff3b78945f0 CR3: 0000000001c05000 CR4: 00000000000026e0
Aug 2 15:04:42 zimba kernel: [ 92.486700] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Aug 2 15:04:42 zimba kernel: [ 92.486701] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Aug 2 15:04:42 zimba kernel: [ 92.486703] Process kworker/u:5 (pid: 79, threadinfo ffff8804217c6000, task ffff88042172c500)
Aug 2 15:04:42 zimba kernel: [ 92.486704] Stack:
Aug 2 15:04:42 zimba kernel: [ 92.488871] ffff8804210a6130 ffff8804217c7dd0 ffffffff8142f994 ffff8804210a6130
Aug 2 15:04:42 zimba kernel: [ 92.488873] ffff8804210a6000 ffff8804210a6018 0000000000000000 ffff8804217c7e00
Aug 2 15:04:42 zimba kernel: [ 92.488876] ffffffffa018bfec ffff8804210a6080 ffff880422aa5200 ffff880423b0d600
Aug 2 15:04:42 zimba kernel: [ 92.488879] Call Trace:
Aug 2 15:04:42 zimba kernel: [ 92.491379] [<ffffffff8142f994>] scsi_remove_target+0xb4/0xe0
Aug 2 15:04:42 zimba kernel: [ 92.491385] [<ffffffffa018bfec>] __iscsi_unbind_session+0xbc/0x190 [scsi_transport_iscsi]
Aug 2 15:04:42 zimba kernel: [ 92.491389] [<ffffffff81084c8a>] process_one_work+0x11a/0x480
Aug 2 15:04:42 zimba kernel: [ 92.491392] [<ffffffff81085954>] worker_thread+0x164/0x370
Aug 2 15:04:42 zimba kernel: [ 92.491394] [<ffffffff810857f0>] ? manage_workers.isra.30+0x130/0x130
Aug 2 15:04:42 zimba kernel: [ 92.491396] [<ffffffff8108a1dc>] kthread+0x8c/0xa0
Aug 2 15:04:42 zimba kernel: [ 92.491399] [<ffffffff81665774>] kernel_thread_helper+0x4/0x10
Aug 2 15:04:42 zimba kernel: [ 92.491401] [<ffffffff8108a150>] ? flush_kthread_worker+0xa0/0xa0
Aug 2 15:04:42 zimba kernel: [ 92.491403] [<ffffffff81665770>] ? gs_change+0x13/0x13
Aug 2 15:04:42 zimba kernel: [ 92.491404] Code: 48 8b 5d f0 4c 8b 65 f8 c9 c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 53 66 66 66 66 90 48 89 f3 e8 8e 2a 9e ff 66 90 48 89 df 57 9d <66> 66 90 66 90 5b 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00
Aug 2 15:04:42 zimba kernel: [ 92.514441] Call Trace:
Aug 2 15:04:42 zimba kernel: [ 92.514443] [<ffffffff8142f994>] scsi_remove_target+0xb4/0xe0
Aug 2 15:04:42 zimba kernel: [ 92.514447] [<ffffffffa018bfec>] __iscsi_unbind_session+0xbc/0x190 [scsi_transport_iscsi]
Aug 2 15:04:42 zimba kernel: [ 92.514450] [<ffffffff81084c8a>] process_one_work+0x11a/0x480
Aug 2 15:04:42 zimba kernel: [ 92.514452] [<ffffffff81085954>] worker_thread+0x164/0x370
Aug 2 15:04:42 zimba kernel: [ 92.514454] [<ffffffff810857f0>] ? manage_workers.isra.30+0x130/0x130
Aug 2 15:04:42 zimba kernel: [ 92.514456] [<ffffffff8108a1dc>] kthread+0x8c/0xa0
Aug 2 15:04:42 zimba kernel: [ 92.514458] [<ffffffff81665774>] kernel_thread_helper+0x4/0x10
Aug 2 15:04:42 zimba kernel: [ 92.514460] [<ffffffff8108a150>] ? flush_kthread_worker+0xa0/0xa0
Aug 2 15:04:42 zimba kernel: [ 92.514464] [<ffffffff81665770>] ? gs_change+0x13/0x13

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: open-iscsi 2.0.871-0ubuntu9.12.04.2
ProcVersionSignature: Ubuntu 3.2.0-33.52-generic 3.2.31
Uname: Linux 3.2.0-33-generic x86_64
ApportVersion: 2.0.1-0ubuntu17.3
Architecture: amd64
Date: Fri Aug 2 15:48:11 2013
MarkForUpload: True
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: open-iscsi
UpgradeStatus: Upgraded to precise on 2012-05-02 (457 days ago)
mtime.conffile..etc.iscsi.iscsid.conf: 2011-07-27T17:12:11
---
ApportVersion: 2.0.1-0ubuntu17.3
Architecture: amd64
DistroRelease: Ubuntu 12.04
MarkForUpload: True
Package: open-iscsi 2.0.871-0ubuntu9.12.04.2
PackageArchitecture: amd64
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.2.0-33.52-generic 3.2.31
Tags: precise
Uname: Linux 3.2.0-33-generic x86_64
UpgradeStatus: Upgraded to precise on 2012-05-02 (457 days ago)
UserGroups:

mtime.conffile..etc.iscsi.iscsid.conf: 2011-07-27T17:12:11

Alexander List (alexlist) wrote :
description: updated
Alexander List (alexlist) wrote :

In order to get a working system again, I had to circumvent the package update by backing up /etc/iscsi, removing it, purging the package, and reinstalling the package, afterwards restoring the config.

tags: added: apport-collected
description: updated

apport information

Alexander List (alexlist) wrote :

I think it's a very bad idea to try to stop all targets while LVM still uses them, and services depend on the LVM LVs ...
(open-iscsi.prerm)

The warning in README.Debian is nice, but doesn't really address the problem.

Changed in open-iscsi (Ubuntu):
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers