You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(35) |
Oct
(73) |
Nov
(37) |
Dec
(60) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(76) |
Feb
(301) |
Mar
(123) |
Apr
(29) |
May
(61) |
Jun
(45) |
Jul
(10) |
Aug
(63) |
Sep
(17) |
Oct
(28) |
Nov
(43) |
Dec
(60) |
2007 |
Jan
(71) |
Feb
(86) |
Mar
(20) |
Apr
|
May
(73) |
Jun
(67) |
Jul
(40) |
Aug
(67) |
Sep
(30) |
Oct
(38) |
Nov
(113) |
Dec
(159) |
2008 |
Jan
(208) |
Feb
(299) |
Mar
(105) |
Apr
(64) |
May
(328) |
Jun
(135) |
Jul
(221) |
Aug
(119) |
Sep
(132) |
Oct
(293) |
Nov
(180) |
Dec
(225) |
2009 |
Jan
(136) |
Feb
(161) |
Mar
(226) |
Apr
(363) |
May
(188) |
Jun
(269) |
Jul
(297) |
Aug
(141) |
Sep
(237) |
Oct
(191) |
Nov
(137) |
Dec
(211) |
2010 |
Jan
(141) |
Feb
(234) |
Mar
(254) |
Apr
(370) |
May
(215) |
Jun
(211) |
Jul
(199) |
Aug
(234) |
Sep
(294) |
Oct
(182) |
Nov
(197) |
Dec
(263) |
2011 |
Jan
(115) |
Feb
(135) |
Mar
(114) |
Apr
(177) |
May
(181) |
Jun
(116) |
Jul
(230) |
Aug
(166) |
Sep
(93) |
Oct
(119) |
Nov
(104) |
Dec
(146) |
2012 |
Jan
(138) |
Feb
(182) |
Mar
(190) |
Apr
(126) |
May
(131) |
Jun
(92) |
Jul
(103) |
Aug
(74) |
Sep
(41) |
Oct
(65) |
Nov
(90) |
Dec
(97) |
2013 |
Jan
(73) |
Feb
(80) |
Mar
(152) |
Apr
(93) |
May
(96) |
Jun
(49) |
Jul
(73) |
Aug
(72) |
Sep
(86) |
Oct
(115) |
Nov
(80) |
Dec
(61) |
2014 |
Jan
(115) |
Feb
(171) |
Mar
(191) |
Apr
(150) |
May
(51) |
Jun
(117) |
Jul
(131) |
Aug
(91) |
Sep
(92) |
Oct
(101) |
Nov
(62) |
Dec
(108) |
2015 |
Jan
(118) |
Feb
(58) |
Mar
(79) |
Apr
(99) |
May
(64) |
Jun
(95) |
Jul
(69) |
Aug
(74) |
Sep
(77) |
Oct
(94) |
Nov
(118) |
Dec
(50) |
2016 |
Jan
(47) |
Feb
(137) |
Mar
(159) |
Apr
(50) |
May
(45) |
Jun
(77) |
Jul
(63) |
Aug
(80) |
Sep
(58) |
Oct
(49) |
Nov
(28) |
Dec
(46) |
2017 |
Jan
(34) |
Feb
(36) |
Mar
(108) |
Apr
(127) |
May
(73) |
Jun
(90) |
Jul
(28) |
Aug
(39) |
Sep
(51) |
Oct
(60) |
Nov
(32) |
Dec
(57) |
2018 |
Jan
(73) |
Feb
(19) |
Mar
(32) |
Apr
(52) |
May
(42) |
Jun
(35) |
Jul
(50) |
Aug
(21) |
Sep
(19) |
Oct
(24) |
Nov
(47) |
Dec
(35) |
2019 |
Jan
(37) |
Feb
(51) |
Mar
(59) |
Apr
(44) |
May
(42) |
Jun
(36) |
Jul
(15) |
Aug
(3) |
Sep
(36) |
Oct
(44) |
Nov
(29) |
Dec
(14) |
2020 |
Jan
(16) |
Feb
(20) |
Mar
(10) |
Apr
(13) |
May
(49) |
Jun
(15) |
Jul
(37) |
Aug
(37) |
Sep
(11) |
Oct
(13) |
Nov
(49) |
Dec
(25) |
2021 |
Jan
(23) |
Feb
(12) |
Mar
(15) |
Apr
(15) |
May
(10) |
Jun
(17) |
Jul
(9) |
Aug
(39) |
Sep
(55) |
Oct
(25) |
Nov
(30) |
Dec
(17) |
2022 |
Jan
(10) |
Feb
(14) |
Mar
(1) |
Apr
(4) |
May
(34) |
Jun
(2) |
Jul
(13) |
Aug
(7) |
Sep
(2) |
Oct
(11) |
Nov
(2) |
Dec
(5) |
2023 |
Jan
(4) |
Feb
(7) |
Mar
(4) |
Apr
|
May
|
Jun
(10) |
Jul
(1) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
(8) |
Feb
(2) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Sietse v. Z. <si...@wi...> - 2023-08-01 08:07:17
|
Disk initialization only creates an empty partition table (MBR or GPT). My guess would be that you have IOMeter configured in such a way that it overwrites the partition table, hence making the disk unitialized again. -Sietse From: Storage Team <b.s...@gm...> Sent: Sunday, July 9, 2023 1:24 PM To: scs...@li... Subject: [Scst-devel] presenting one of our windows hosts via Scst Dear all, I hope this email finds you well. The issue in which we have faced is for the occasion that we have presented one of our windows hosts via Scst, one volume of ZFS Pool with PC protocol. The time that atmosphere is empty, we use IOMeter software for the performance tests. The issue which we were faced, is like, when the volume is presented to windows host, in Windows the disk is shown empty. And we, by converting it to MBR, turn it into Initialize mode for IOMeter. when we kick-off the performance test. After a few seconds the disk in Windows host will be altered to Not Initialized. The question is that whether there is a solution to this or not. Any recommendations will be advantageous. With regards. Storage Team |
From: Storage T. <b.s...@gm...> - 2023-07-09 12:30:20
|
Dear all, I hope this email finds you well. The issue in which we have faced is for the occasion that we have presented one of our windows hosts via Scst, one volume of ZFS Pool with PC protocol. The time that atmosphere is empty, we use IOMeter software for the performance tests. The issue which we were faced, is like, when the volume is presented to windows host, in Windows the disk is shown empty. And we, by converting it to MBR, turn it into Initialize mode for IOMeter. when we kick-off the performance test. After a few seconds the disk in Windows host will be altered to Not Initialized. The question is that whether there is a solution to this or not. Any recommendations will be advantageous. With regards. Storage Team |
From: Lev V. <le...@za...> - 2023-06-29 11:28:13
|
Hi Gleb, I applied the patch, and yes, now the reported command counter is correct. Thanks, -Lev. -----Original Message----- From: Gleb Chesnokov [mailto:gle...@sc...v] Sent: Wednesday, June 28, 2023 19:34 To: lev...@za...; scs...@li... Cc: 'Yaron Presente' Subject: Re: [Scst-devel] SCST suspend takes much time on iser target Hi Lev, On 6/20/23 15:12, Lev Vainblat wrote: > Hello, > > isert-scst has a dedicated workqueue where RDMA completion handler (isert_cq_comp_work_cb) runs. New commands arrive to isert_cq_comp_work_cb() that eventually checks (in scst_translate_lun()) if SCST is suspended: > > isert_cq_comp_work_cb -> > > isert_poll_cq -> > > isert_pdu_rx -> > > cmnd_rx_start -> > > scsi_cmnd_start -> > > scst_cmd_init_stage1_done -> > > scst_cmd_init_done -> > > scst_init_cmd -> > > __scst_init_cmd -> > > scst_translate_lun > > If SCST is suspended, scst_init_cmd() sleeps 50ms in order to "keep initiator away from too many BUSY commands". The problem is that this sleep sticks the workqueue thread, that is responsible also to complete "old" requests, that were received _/before/_ scst_suspend_activity(). As a result suspend itself may take much time, because "old" commands do not get thread context to be finished. > > For example in my environment with ~80 outstanding commands suspend takes ~3sec. If I comment out msleep(50) in scst_init_cmd(), it takes just ~100ms. > > Another less important but still annoying issue is with log in scst_suspend_activity(). It prints the number of active commands, but it calls scst_get_cmd_counter() -> percpu_ref_read(&scst_cmd_count) immediately after percpu_ref_kill(). percpu_ref_kill() calls __percpu_ref_switch_to_atomic() that _asynchronously_ invokes percpu_ref_switch_to_atomic_rcu(), only there scst_cmd_count becomes really atomic. Until percpu_ref_switch_to_atomic_rcu() is finished, the value returned by scst_get_cmd_counter() is wrong and confusing. In my tests it takes ~20ms after percpu_ref_kill() until scst_get_cmd_counter() returns real command count. > > I'm using SCST 3.6 but on a [pretty old] kernel 4.14. > > Thanks, > > -Lev. > > > > _______________________________________________ > Scst-devel mailing list > https://lists.sourceforge.net/lists/listinfo/scst-devel Thank you for the report and investigation! I will take a look at the first problem next week, for the second problem I made a fix: https://github.com/SCST-project/scst/commit/6a925490fd5447033aabb847ab3418a20aba4266 Could you retest the second issue using it? Thanks, Gleb |
From: Gleb C. <gle...@sc...> - 2023-06-28 16:33:40
|
Hi Lev, On 6/20/23 15:12, Lev Vainblat wrote: > Hello, > > isert-scst has a dedicated workqueue where RDMA completion handler (isert_cq_comp_work_cb) runs. New commands arrive to isert_cq_comp_work_cb() that eventually checks (in scst_translate_lun()) if SCST is suspended: > > isert_cq_comp_work_cb -> > > isert_poll_cq -> > > isert_pdu_rx -> > > cmnd_rx_start -> > > scsi_cmnd_start -> > > scst_cmd_init_stage1_done -> > > scst_cmd_init_done -> > > scst_init_cmd -> > > __scst_init_cmd -> > > scst_translate_lun > > If SCST is suspended, scst_init_cmd() sleeps 50ms in order to "keep initiator away from too many BUSY commands". The problem is that this sleep sticks the workqueue thread, that is responsible also to complete "old" requests, that were received _/before/_ scst_suspend_activity(). As a result suspend itself may take much time, because "old" commands do not get thread context to be finished. > > For example in my environment with ~80 outstanding commands suspend takes ~3sec. If I comment out msleep(50) in scst_init_cmd(), it takes just ~100ms. > > Another less important but still annoying issue is with log in scst_suspend_activity(). It prints the number of active commands, but it calls scst_get_cmd_counter() -> percpu_ref_read(&scst_cmd_count) immediately after percpu_ref_kill(). percpu_ref_kill() calls __percpu_ref_switch_to_atomic() that _asynchronously_ invokes percpu_ref_switch_to_atomic_rcu(), only there scst_cmd_count becomes really atomic. Until percpu_ref_switch_to_atomic_rcu() is finished, the value returned by scst_get_cmd_counter() is wrong and confusing. In my tests it takes ~20ms after percpu_ref_kill() until scst_get_cmd_counter() returns real command count. > > I'm using SCST 3.6 but on a [pretty old] kernel 4.14. > > Thanks, > > -Lev. > > > > _______________________________________________ > Scst-devel mailing list > https://lists.sourceforge.net/lists/listinfo/scst-devel Thank you for the report and investigation! I will take a look at the first problem next week, for the second problem I made a fix: https://github.com/SCST-project/scst/commit/6a925490fd5447033aabb847ab3418a20aba4266 Could you retest the second issue using it? Thanks, Gleb |
From: Sietse v. Z. <si...@wi...> - 2023-06-28 08:45:54
|
Hi Gleb, That looks to be much better: [sietse@san ~]$ uptime 10:32:21 up 13:39, 2 users, load average: 0.00, 0.00, 0.00 -Sietse -----Original Message----- From: Gleb Chesnokov <gle...@sc...v> Sent: Tuesday, June 27, 2023 4:21 PM To: Sietse van Zanen <si...@wi...>; scs...@li... Subject: Re: [Scst-devel] Blocked kernel threads under kernel 6.3 Hi Sietse, On 6/27/23 15:20, Sietse van Zanen wrote: > Looking at the code, I get the idea that this may actually be expected behavior? > > If I trace scst_init_thread(): > > while (!kthread_should_stop()) { > > scst_wait_event_lock_irq(scst_init_cmd_list_waitQ, > > test_init_cmd_list(), > > scst_init_lock); > > scst_do_job_init(); > > } > > #define scst_wait_event_lock_irq(wq_head, condition, lock) \ > > do { \ > > if (condition) \ > > break; \ > > __scst_wait_event_lock_irq(wq_head, condition, lock); \ > > } while (0) > > #define __scst_wait_event_lock_irq(wq_head, condition, lock) \ > > (void)___scst_wait_event(wq_head, condition, TASK_UNINTERRUPTIBLE, 0, > > static inline bool test_init_cmd_list(void) > > { > > return (!list_empty(&scst_init_cmd_list) && > > !scst_activity_suspended()) || > > unlikely(kthread_should_stop()) || > > (scst_init_poll_cnt > 0); > > } > > So, if I understand correctly the scst_initd thread basically waits in an uninterruptable state until the command queue is not empty and scst is not suspended or is being shutdown. > > -Sietse > > *From:*Sietse van Zanen <si...@wi...> > *Sent:* Tuesday, June 27, 2023 11:30 AM > *To:* scs...@li... > *Subject:* [Scst-devel] Blocked kernel threads under kernel 6.3 > > Hi, > > When running under kernel 6.3 there are 9 scst processes that are forever blocked instead of sleeping, leading to a load of 9.0 on an idle system. > > [sietse@san system]$ uptime > > 10:11:34 up 13:07, 1 user, load average: 9.01, 9.01, 9.00 > > [sietse@san system]$ ps axo pid,state,args | grep D > > PID S COMMAND > > 136 D [scst_uid] > > 139 D [scst_initd] > > 140 D [scsi_tm] > > 141 D [scst_mgmtd] > > 142 D [scst_usr_cleanupd] > > 143 D [iscsird0_0] > > 144 D [iscsird0_1] > > 145 D [iscsiwr0_0] > > 146 D [iscsiwr0_1] > > This is in initramfs without any user space processes running. It seems that as soon as these kernel threads are started, they block. > > I am testing with 6.3 kernel, so haven’t actually tried to configure scst. > > Jun 27 11:09:32 san kernel: sysrq: Show Blocked State > > Jun 27 11:09:32 san kernel: task:scst_uid state:D stack:0 pid:137 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 > > Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: sysfs_work_thread_fn+0x204/0x350 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? scst_sysfs_queue_wait_work+0x1b0/0x1b0 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:scst_initd state:D stack:0 pid:144 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 > > Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: scst_init_thread+0x226/0x370 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? scst_lookup_tgt_dev+0x30/0x30 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:scsi_tm state:D stack:0 pid:145 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 > > Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: scst_tm_thread+0x223/0x1850 > > Jun 27 11:09:32 san kernel: ? check_preempt_curr+0x59/0xd0 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 > > Jun 27 11:09:32 san kernel: ? scst_clear_aca+0xe0/0xe0 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:scst_mgmtd state:D stack:0 pid:146 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 > > Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: scst_global_mgmt_thread+0x194/0x3b0 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? scst_unregister_session_non_gpl+0x10/0x10 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:scst_usr_cleanu state:D stack:0 pid:147 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: ? dev_usr_parse+0x10/0x10 > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 > > Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 > > Jun 27 11:09:32 san kernel: ? _raw_spin_unlock+0xd/0x30 > > Jun 27 11:09:32 san kernel: ? finish_task_switch+0xc4/0x320 > > Jun 27 11:09:32 san kernel: ? dev_usr_parse+0x10/0x10 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: dev_user_cleanup_thread+0x20b/0x560 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? dev_usr_parse+0x10/0x10 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:iscsird0_0 state:D stack:0 pid:148 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 > > Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: istrd+0x244/0xa80 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? iscsi_get_send_cmnd+0x90/0x90 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:iscsird0_1 state:D stack:0 pid:149 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 > > Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: istrd+0x244/0xa80 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? iscsi_get_send_cmnd+0x90/0x90 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:iscsiwr0_0 state:D stack:0 pid:150 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 > > Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: istwr+0x243/0x330 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? iscsi_send+0xb20/0xb20 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:iscsiwr0_1 state:D stack:0 pid:151 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 > > Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: istwr+0x243/0x330 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? iscsi_send+0xb20/0xb20 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > -Sietse > > > > _______________________________________________ > Scst-devel mailing list > https://lists.sourceforge.net/lists/listinfo/scst-devel Thank you for the report! Fix candidate has been merged into the master branch, could you retest the issue using it? Thanks, Gleb |
From: Gleb C. <gle...@sc...> - 2023-06-27 14:35:40
|
Hi Sietse, On 6/27/23 15:20, Sietse van Zanen wrote: > Looking at the code, I get the idea that this may actually be expected behavior? > > If I trace scst_init_thread(): > > while (!kthread_should_stop()) { > > scst_wait_event_lock_irq(scst_init_cmd_list_waitQ, > > test_init_cmd_list(), > > scst_init_lock); > > scst_do_job_init(); > > } > > #define scst_wait_event_lock_irq(wq_head, condition, lock) \ > > do { \ > > if (condition) \ > > break; \ > > __scst_wait_event_lock_irq(wq_head, condition, lock); \ > > } while (0) > > #define __scst_wait_event_lock_irq(wq_head, condition, lock) \ > > (void)___scst_wait_event(wq_head, condition, TASK_UNINTERRUPTIBLE, 0, > > static inline bool test_init_cmd_list(void) > > { > > return (!list_empty(&scst_init_cmd_list) && > > !scst_activity_suspended()) || > > unlikely(kthread_should_stop()) || > > (scst_init_poll_cnt > 0); > > } > > So, if I understand correctly the scst_initd thread basically waits in an uninterruptable state until the command queue is not empty and scst is not suspended or is being shutdown. > > -Sietse > > *From:*Sietse van Zanen <si...@wi...> > *Sent:* Tuesday, June 27, 2023 11:30 AM > *To:* scs...@li... > *Subject:* [Scst-devel] Blocked kernel threads under kernel 6.3 > > Hi, > > When running under kernel 6.3 there are 9 scst processes that are forever blocked instead of sleeping, leading to a load of 9.0 on an idle system. > > [sietse@san system]$ uptime > > 10:11:34 up 13:07, 1 user, load average: 9.01, 9.01, 9.00 > > [sietse@san system]$ ps axo pid,state,args | grep D > > PID S COMMAND > > 136 D [scst_uid] > > 139 D [scst_initd] > > 140 D [scsi_tm] > > 141 D [scst_mgmtd] > > 142 D [scst_usr_cleanupd] > > 143 D [iscsird0_0] > > 144 D [iscsird0_1] > > 145 D [iscsiwr0_0] > > 146 D [iscsiwr0_1] > > This is in initramfs without any user space processes running. It seems that as soon as these kernel threads are started, they block. > > I am testing with 6.3 kernel, so haven’t actually tried to configure scst. > > Jun 27 11:09:32 san kernel: sysrq: Show Blocked State > > Jun 27 11:09:32 san kernel: task:scst_uid state:D stack:0 pid:137 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 > > Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: sysfs_work_thread_fn+0x204/0x350 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? scst_sysfs_queue_wait_work+0x1b0/0x1b0 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:scst_initd state:D stack:0 pid:144 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 > > Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: scst_init_thread+0x226/0x370 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? scst_lookup_tgt_dev+0x30/0x30 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:scsi_tm state:D stack:0 pid:145 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 > > Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: scst_tm_thread+0x223/0x1850 > > Jun 27 11:09:32 san kernel: ? check_preempt_curr+0x59/0xd0 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 > > Jun 27 11:09:32 san kernel: ? scst_clear_aca+0xe0/0xe0 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:scst_mgmtd state:D stack:0 pid:146 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 > > Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: scst_global_mgmt_thread+0x194/0x3b0 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? scst_unregister_session_non_gpl+0x10/0x10 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:scst_usr_cleanu state:D stack:0 pid:147 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: ? dev_usr_parse+0x10/0x10 > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 > > Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 > > Jun 27 11:09:32 san kernel: ? _raw_spin_unlock+0xd/0x30 > > Jun 27 11:09:32 san kernel: ? finish_task_switch+0xc4/0x320 > > Jun 27 11:09:32 san kernel: ? dev_usr_parse+0x10/0x10 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: dev_user_cleanup_thread+0x20b/0x560 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? dev_usr_parse+0x10/0x10 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:iscsird0_0 state:D stack:0 pid:148 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 > > Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: istrd+0x244/0xa80 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? iscsi_get_send_cmnd+0x90/0x90 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:iscsird0_1 state:D stack:0 pid:149 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 > > Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: istrd+0x244/0xa80 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? iscsi_get_send_cmnd+0x90/0x90 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:iscsiwr0_0 state:D stack:0 pid:150 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 > > Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: istwr+0x243/0x330 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? iscsi_send+0xb20/0xb20 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > Jun 27 11:09:32 san kernel: task:iscsiwr0_1 state:D stack:0 pid:151 ppid:2 flags:0x00004000 > > Jun 27 11:09:32 san kernel: Call Trace: > > Jun 27 11:09:32 san kernel: <TASK> > > Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 > > Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 > > Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 > > Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 > > Jun 27 11:09:32 san kernel: schedule+0x50/0x90 > > Jun 27 11:09:32 san kernel: istwr+0x243/0x330 > > Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 > > Jun 27 11:09:32 san kernel: ? iscsi_send+0xb20/0xb20 > > Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 > > Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 > > Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 > > Jun 27 11:09:32 san kernel: </TASK> > > -Sietse > > > > _______________________________________________ > Scst-devel mailing list > https://lists.sourceforge.net/lists/listinfo/scst-devel Thank you for the report! Fix candidate has been merged into the master branch, could you retest the issue using it? Thanks, Gleb |
From: Sietse v. Z. <si...@wi...> - 2023-06-27 12:20:34
|
Looking at the code, I get the idea that this may actually be expected behavior? If I trace scst_init_thread(): while (!kthread_should_stop()) { scst_wait_event_lock_irq(scst_init_cmd_list_waitQ, test_init_cmd_list(), scst_init_lock); scst_do_job_init(); } #define scst_wait_event_lock_irq(wq_head, condition, lock) \ do { \ if (condition) \ break; \ __scst_wait_event_lock_irq(wq_head, condition, lock); \ } while (0) #define __scst_wait_event_lock_irq(wq_head, condition, lock) \ (void)___scst_wait_event(wq_head, condition, TASK_UNINTERRUPTIBLE, 0, static inline bool test_init_cmd_list(void) { return (!list_empty(&scst_init_cmd_list) && !scst_activity_suspended()) || unlikely(kthread_should_stop()) || (scst_init_poll_cnt > 0); } So, if I understand correctly the scst_initd thread basically waits in an uninterruptable state until the command queue is not empty and scst is not suspended or is being shutdown. -Sietse From: Sietse van Zanen <si...@wi...> Sent: Tuesday, June 27, 2023 11:30 AM To: scs...@li... Subject: [Scst-devel] Blocked kernel threads under kernel 6.3 Hi, When running under kernel 6.3 there are 9 scst processes that are forever blocked instead of sleeping, leading to a load of 9.0 on an idle system. [sietse@san system]$ uptime 10:11:34 up 13:07, 1 user, load average: 9.01, 9.01, 9.00 [sietse@san system]$ ps axo pid,state,args | grep D PID S COMMAND 136 D [scst_uid] 139 D [scst_initd] 140 D [scsi_tm] 141 D [scst_mgmtd] 142 D [scst_usr_cleanupd] 143 D [iscsird0_0] 144 D [iscsird0_1] 145 D [iscsiwr0_0] 146 D [iscsiwr0_1] This is in initramfs without any user space processes running. It seems that as soon as these kernel threads are started, they block. I am testing with 6.3 kernel, so haven't actually tried to configure scst. Jun 27 11:09:32 san kernel: sysrq: Show Blocked State Jun 27 11:09:32 san kernel: task:scst_uid state:D stack:0 pid:137 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: sysfs_work_thread_fn+0x204/0x350 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? scst_sysfs_queue_wait_work+0x1b0/0x1b0 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:scst_initd state:D stack:0 pid:144 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: scst_init_thread+0x226/0x370 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? scst_lookup_tgt_dev+0x30/0x30 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:scsi_tm state:D stack:0 pid:145 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: scst_tm_thread+0x223/0x1850 Jun 27 11:09:32 san kernel: ? check_preempt_curr+0x59/0xd0 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 Jun 27 11:09:32 san kernel: ? scst_clear_aca+0xe0/0xe0 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:scst_mgmtd state:D stack:0 pid:146 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: scst_global_mgmt_thread+0x194/0x3b0 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? scst_unregister_session_non_gpl+0x10/0x10 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:scst_usr_cleanu state:D stack:0 pid:147 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: ? dev_usr_parse+0x10/0x10 Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 Jun 27 11:09:32 san kernel: ? _raw_spin_unlock+0xd/0x30 Jun 27 11:09:32 san kernel: ? finish_task_switch+0xc4/0x320 Jun 27 11:09:32 san kernel: ? dev_usr_parse+0x10/0x10 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: dev_user_cleanup_thread+0x20b/0x560 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? dev_usr_parse+0x10/0x10 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:iscsird0_0 state:D stack:0 pid:148 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: istrd+0x244/0xa80 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? iscsi_get_send_cmnd+0x90/0x90 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:iscsird0_1 state:D stack:0 pid:149 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: istrd+0x244/0xa80 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? iscsi_get_send_cmnd+0x90/0x90 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:iscsiwr0_0 state:D stack:0 pid:150 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: istwr+0x243/0x330 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? iscsi_send+0xb20/0xb20 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:iscsiwr0_1 state:D stack:0 pid:151 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: istwr+0x243/0x330 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? iscsi_send+0xb20/0xb20 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> -Sietse |
From: Sietse v. Z. <si...@wi...> - 2023-06-27 09:50:37
|
Hi, When running under kernel 6.3 there are 9 scst processes that are forever blocked instead of sleeping, leading to a load of 9.0 on an idle system. [sietse@san system]$ uptime 10:11:34 up 13:07, 1 user, load average: 9.01, 9.01, 9.00 [sietse@san system]$ ps axo pid,state,args | grep D PID S COMMAND 136 D [scst_uid] 139 D [scst_initd] 140 D [scsi_tm] 141 D [scst_mgmtd] 142 D [scst_usr_cleanupd] 143 D [iscsird0_0] 144 D [iscsird0_1] 145 D [iscsiwr0_0] 146 D [iscsiwr0_1] This is in initramfs without any user space processes running. It seems that as soon as these kernel threads are started, they block. I am testing with 6.3 kernel, so haven't actually tried to configure scst. Jun 27 11:09:32 san kernel: sysrq: Show Blocked State Jun 27 11:09:32 san kernel: task:scst_uid state:D stack:0 pid:137 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: sysfs_work_thread_fn+0x204/0x350 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? scst_sysfs_queue_wait_work+0x1b0/0x1b0 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:scst_initd state:D stack:0 pid:144 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: scst_init_thread+0x226/0x370 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? scst_lookup_tgt_dev+0x30/0x30 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:scsi_tm state:D stack:0 pid:145 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: scst_tm_thread+0x223/0x1850 Jun 27 11:09:32 san kernel: ? check_preempt_curr+0x59/0xd0 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 Jun 27 11:09:32 san kernel: ? scst_clear_aca+0xe0/0xe0 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:scst_mgmtd state:D stack:0 pid:146 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? set_next_entity+0xc2/0x100 Jun 27 11:09:32 san kernel: ? set_next_task_fair+0x74/0x1c0 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: scst_global_mgmt_thread+0x194/0x3b0 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? scst_unregister_session_non_gpl+0x10/0x10 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:scst_usr_cleanu state:D stack:0 pid:147 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: ? dev_usr_parse+0x10/0x10 Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 Jun 27 11:09:32 san kernel: ? _raw_spin_unlock+0xd/0x30 Jun 27 11:09:32 san kernel: ? finish_task_switch+0xc4/0x320 Jun 27 11:09:32 san kernel: ? dev_usr_parse+0x10/0x10 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: dev_user_cleanup_thread+0x20b/0x560 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? dev_usr_parse+0x10/0x10 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:iscsird0_0 state:D stack:0 pid:148 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: istrd+0x244/0xa80 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? iscsi_get_send_cmnd+0x90/0x90 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:iscsird0_1 state:D stack:0 pid:149 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: istrd+0x244/0xa80 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? iscsi_get_send_cmnd+0x90/0x90 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:iscsiwr0_0 state:D stack:0 pid:150 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: istwr+0x243/0x330 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? iscsi_send+0xb20/0xb20 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> Jun 27 11:09:32 san kernel: task:iscsiwr0_1 state:D stack:0 pid:151 ppid:2 flags:0x00004000 Jun 27 11:09:32 san kernel: Call Trace: Jun 27 11:09:32 san kernel: <TASK> Jun 27 11:09:32 san kernel: __schedule+0x618/0x13a0 Jun 27 11:09:32 san kernel: ? _raw_spin_unlock_irqrestore+0x16/0x40 Jun 27 11:09:32 san kernel: ? debug_print_with_prefix+0x1e1/0x220 Jun 27 11:09:32 san kernel: ? preempt_count_add+0x5e/0xb0 Jun 27 11:09:32 san kernel: ? _raw_spin_lock_irqsave+0x39/0x80 Jun 27 11:09:32 san kernel: ? _raw_spin_lock+0x14/0x40 Jun 27 11:09:32 san kernel: schedule+0x50/0x90 Jun 27 11:09:32 san kernel: istwr+0x243/0x330 Jun 27 11:09:32 san kernel: ? wake_bit_function+0x60/0x60 Jun 27 11:09:32 san kernel: ? iscsi_send+0xb20/0xb20 Jun 27 11:09:32 san kernel: kthread+0xe1/0x100 Jun 27 11:09:32 san kernel: ? kthread_blkcg+0x30/0x30 Jun 27 11:09:32 san kernel: ret_from_fork+0x22/0x30 Jun 27 11:09:32 san kernel: </TASK> -Sietse |
From: Lev V. <le...@za...> - 2023-06-20 13:07:44
|
Hello, � isert-scst has a dedicated workqueue where RDMA completion handler (isert_cq_comp_work_cb) runs. New commands arrive to isert_cq_comp_work_cb() that eventually checks (in scst_translate_lun()) if SCST is suspended: � isert_cq_comp_work_cb -> isert_poll_cq -> isert_pdu_rx -> cmnd_rx_start -> scsi_cmnd_start -> scst_cmd_init_stage1_done -> scst_cmd_init_done -> scst_init_cmd -> __scst_init_cmd -> scst_translate_lun If SCST is suspended, scst_init_cmd() sleeps 50ms in order to "keep initiator away from too many BUSY commands". The problem is that this sleep sticks the workqueue thread, that is responsible also to complete "old" requests, that were received _before_ scst_suspend_activity(). As a result suspend itself may take much time, because "old" commands do not get thread context to be finished. For example in my environment with ~80 outstanding commands suspend takes ~3sec. If I comment out msleep(50) in scst_init_cmd(), it takes just ~100ms. Another less important but still annoying issue is with log in scst_suspend_activity(). It prints the number of active commands, but it calls scst_get_cmd_counter() -> percpu_ref_read(&scst_cmd_count) immediately after percpu_ref_kill(). percpu_ref_kill() calls __percpu_ref_switch_to_atomic() that _asynchronously_ invokes percpu_ref_switch_to_atomic_rcu(), only there scst_cmd_count becomes really atomic. Until percpu_ref_switch_to_atomic_rcu() is finished, the value returned by scst_get_cmd_counter() is wrong and confusing. In my tests it takes ~20ms after percpu_ref_kill() until scst_get_cmd_counter() returns real command count. I'm using SCST 3.6 but on a [pretty old] kernel 4.14. ಚ Thanks, -Lev. |
From: Орлов И. В. <or...@so...> - 2023-06-14 05:42:04
|
Good afternoon, Bart! Thank you for responding to my question. Yes, the initiator shutdown is emergency, without closing connections (an emergency power outage is simulated). Since a direct connection of the Infiniband ports of the Target and Initiator is used, the port on Target goes into Shutdown state at the same time. Thanks, Ivan > От: Bart Van Assche <bva...@ac...> > Отправлено: 13.06.2023 17:51 > Кому: Орлов Иван Викторович <or...@so...>; scst-devel <scs...@li...> > Тема: > > On 6/9/23 00:32, Орлов Иван Викторович wrote: > > After the initiator host shuts down, active connections remain on the > > target. Is this how it should be? > > During an orderly shutdown the SRP initiator should close all > connections to the target. Was an orderly shutdown performed or was the > initiator perhaps powered off without giving the SRP initiator the > chance to log out? > > Thanks, > > Bart. Данное сообщение может содержать конфиденциальную информацию, не подлежащую разглашению и защищенную законодательством РФ. Нарушение законодательства о коммерческой тайне влечет за собой дисциплинарную, гражданско-правовую, административную или уголовную ответственность согласно ст. 14 Закона "О коммерческой тайне". |
From: Bart V. A. <bva...@ac...> - 2023-06-13 14:52:00
|
On 6/9/23 00:32, Орлов Иван Викторович wrote: > After the initiator host shuts down, active connections remain on the > target. Is this how it should be? During an orderly shutdown the SRP initiator should close all connections to the target. Was an orderly shutdown performed or was the initiator perhaps powered off without giving the SRP initiator the chance to log out? Thanks, Bart. |
From: Орлов И. В. <or...@so...> - 2023-06-09 07:51:22
|
Hi, all!After the initiator host shuts down, active connections remain on the target. Is this how it should be? root@pg-s-hw10:/sys/kernel/scst_tgt/targets/ib_srpt/fe80:0000:0000:0000:1070:fd03:00e5:ad19/sessions# ls -ldrwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_1drwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_13drwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_14drwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_15drwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_16drwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_17drwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_18drwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_20drwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_23drwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_26drwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_28drwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_29drwxr-xr-x 6 root root 0 июн 9 09:38 fe80:0000:0000:0000:1070:fd03:00e5:ad29_6Until these connections are closed, it is not possible to establish a connection with another target from the this target host:Jun 9 09:46:52 pg-s-hw11 kernel: [ 329.539782] ib_srpt: Received SRP_LOGIN_REQ with i_port_id 1070:fd03:00e5:ad29:1070:fd03:00e5:ad19, t_port_id 0070:fd03:00e5:ad28:0070:fd03:00e5:ad28 and it_iu_len 8260 on port 1 (guid=fe80:0000:0000:0000:1070:fd03:00e5:ad29); pkey 0xffffJun 9 09:46:52 pg-s-hw11 kernel: [ 329.540852] [353]: scst: Using security group "internal_links" for initiator "fe80:0000:0000:0000:1070:fd03:00e5:ad19" (target fe80:0000:0000:0000:1070:fd03:00e5:ad29)Jun 9 09:46:52 pg-s-hw11 kernel: [ 329.541514] ib_srpt: Received CM REJ for ch fe80:0000:0000:0000:1070:fd03:00e5:ad19-346; reason 10; private data 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.Jun 9 09:46:54 pg-s-hw11 kernel: [ 331.813404] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:1070:fd03:00e5:ad19-346. Данное сообщение может содержать конфиденциальную информацию, не подлежащую разглашению и защищенную законодательством РФ. Нарушение законодательства о коммерческой тайне влечет за собой дисциплинарную, гражданско-правовую, административную или уголовную ответственность согласно ст. 14 Закона "О коммерческой тайне". |
From: Gleb C. <gle...@sc...> - 2023-03-14 11:50:34
|
Hi Marco, On 3/14/23 14:42, Marco Tosato wrote: > Hello I'm trying to build and install SCST 3.7.0 on Debian 11 and > found a couple of problems following the instructions reported in > INSTALL.md file. > > I downloaded the 3.7 release file from > https://github.com/SCST-project/scst/releases > > All the process has been run as a normal user not as root. > > 1) "make release" > > In the "Building SCST" paragraph there is a small script to build SCST > and create a package suitable for the current distro. The first line > of the script is > make release > > This target is not actually defined in the Makefile. I'm not sure > which is the correct target to call, maybe something like > > make 2release > make all > > should do the job? > > Personally I built the software with the following commands > > make 2release > make scst iscsi fcst scst_local usr > > I avoided make all because of troubles compiling the "qla" and > "mellanox" targets which I don't actually need at the moment. > > > 2) Building the .DEB package > > After successfully building SCST with > > make 2release > make scst iscsi fcst scst_local usr > > I tried to create the DEB package but I failed. I installed the > required pieces of software for building the DEB as described in > INSTALL.md "Building SCST" > > sudo apt install build-essential debhelper devscripts gcc make > lintian quilt > sudo apt install linux-headers-$(uname -r) || sudo apt install > pve-headers-$(uname -r) > > and the run > > make dpkg > > the command output is in the attached logfile, but it boils down to a > lot of errors similar to this one > > > dpkg-source: error: cannot represent change to fcst/fcst.ko: > binary file contents changed > dpkg-source: error: add fcst/fcst.ko in > debian/source/include-binaries if you want to store the modified > binary in the debian tarball > > I'm sorry but I'm unable to figure out the problem by myself. > > Attached are the output generated by "make dpkg" . > > Thanks a lot! > > > _______________________________________________ > Scst-devel mailing list > https://lists.sourceforge.net/lists/listinfo/scst-devel Could you try this sequence: 1) make extraclean 2) make dpkg Thanks, Gleb |
From: Marco T. <mar...@gm...> - 2023-03-14 11:42:48
|
Hello I'm trying to build and install SCST 3.7.0 on Debian 11 and found a couple of problems following the instructions reported in INSTALL.md file. I downloaded the 3.7 release file from https://github.com/SCST-project/scst/releases All the process has been run as a normal user not as root. 1) "make release" In the "Building SCST" paragraph there is a small script to build SCST and create a package suitable for the current distro. The first line of the script is make release This target is not actually defined in the Makefile. I'm not sure which is the correct target to call, maybe something like make 2release make all should do the job? Personally I built the software with the following commands make 2release make scst iscsi fcst scst_local usr I avoided make all because of troubles compiling the "qla" and "mellanox" targets which I don't actually need at the moment. 2) Building the .DEB package After successfully building SCST with make 2release make scst iscsi fcst scst_local usr I tried to create the DEB package but I failed. I installed the required pieces of software for building the DEB as described in INSTALL.md "Building SCST" sudo apt install build-essential debhelper devscripts gcc make lintian quilt sudo apt install linux-headers-$(uname -r) || sudo apt install pve-headers-$(uname -r) and the run make dpkg the command output is in the attached logfile, but it boils down to a lot of errors similar to this one dpkg-source: error: cannot represent change to fcst/fcst.ko: binary file contents changed dpkg-source: error: add fcst/fcst.ko in debian/source/include-binaries if you want to store the modified binary in the debian tarball I'm sorry but I'm unable to figure out the problem by myself. Attached are the output generated by "make dpkg" . Thanks a lot! |
From: Adam B. <ada...@gm...> - 2023-03-07 11:12:50
|
Hello, Is it possible to reclaim space on volumes that are exported via iSCSI target with vdisk_blockio handler and thin_provisioned attribute set to '0'? Best Regards. Adam Blaszczykowski |
From: Stanislav U. <29...@gm...> - 2023-03-02 05:45:28
|
Hello! Sorry, I was distracted by the main work and missed the release date of the SCST 3.7.0((( Thank you for your work! I want to send a small gift to your project again)) Please let me know how it is better to do this? С уважением, Ульянкин Стас моб. +79029272373 |
From: <lig...@si...> - 2023-02-15 09:00:38
|
Hi, Anyone could help to give a whole compatibility list of SCST FC support? Like qla2xxx: support kernel aa-bb, FC speed xxG-yyG, SCST version pre-3.5 qla2x00t: support kernel aa-bb, FC speed xxG-yyG, SCST version post-3.4 qla2x00t-32gbit: support kernel aa-bb, FC speed xxG-yyG, SCST version Thanks! Ligong lig...@si... |
From: Gleb C. <gle...@sc...> - 2023-02-13 07:16:12
|
Hi Steve, On 2/2/23 20:49, Steve Houle wrote: > Hi, > > I will try to make it short. > I have a server running Centos 7.9 with Kernel > 3.10.0-1160.83.1.el7.x86_64 and > I need to connect it to a SAN using fibre channel. Ther server has a > QLogic 4Gb > card (QLogic Corp. SP232-based 4Gb Fibre Channel to PCI Express HBA > (rev 02)). > > For many reason I cannot upgrade this server to higher Centos version > so I'm stuck > in 7.9 for now. > > I get that last version available of SCST on Github using branch 3.7.x > (I have > the same issue with other branch). > On first I try the "easy" with #make rpm > It looks to compile good up to scstadmin that failed with error : > Only one of PREFIX or INSTALL_BASE can be given. Not both. > make[3]: *** [makefile] Error 25 > > I did some research on Google and in the mailing-list but every > solution I try > get me the same error. > Some forum mention that could be a problem with the compilation of the > Perl > module SCST. But I'm far from a developer and I cannot point out the > problem. > > Is anybody can help me ? > > Regards > Steve Houle > > > _______________________________________________ > Scst-devel mailing list > https://lists.sourceforge.net/lists/listinfo/scst-devel I wasn't able to reproduce your problem on Centos 7.9. Could you provide full build logs? Thanks, Gleb. |
From: Grant A. <GAlbitz@All-Bits.com> - 2023-02-12 20:38:53
|
Yes thank you, it looks like I was incorrect in assuming it was an issue with the new kernel. I was able to get it to work after your patch now though! -----Original Message----- From: Gleb Chesnokov <gle...@sc...v> Sent: Sunday, February 12, 2023 12:42 PM To: Grant Albitz <GAlbitz@All-Bits.com>; scs...@li... Subject: Re: [Scst-devel] issues with kernel 5.15.0-60 Hi, On 2/10/23 21:31, Grant Albitz wrote: > > > Hello, > > > I posted more info on the issues page on github. It seems there is a > problem with the newer kernel on ubuntu 22.04. I don't notice a build > error when issuing the make command but the modules will not load. > Error ranges from invalid argument when loading the vdisk module to > others saying its the wrong version. Complete info was posted on > github, just wanted to start a discussion. I have reverted the kernel > update to -58 and am back up and running for now. > > > Thank you > > > Grant > > > > _______________________________________________ > Scst-devel mailing list > https://lists.sourceforge.net/lists/listinfo/scst-devel As far as I understand, you have been using SCST master branch. There was some regression that was causing a mismatch version problem (now it is fixed). So you can try to retest the problem with the latest version of SCST. Thanks, Gleb _______________________________________________ Scst-devel mailing list https://lists.sourceforge.net/lists/listinfo/scst-devel |
From: Gleb C. <gle...@sc...> - 2023-02-12 17:42:35
|
Hi, On 2/10/23 21:31, Grant Albitz wrote: > > > Hello, > > > I posted more info on the issues page on github. It seems there is a > problem with the newer kernel on ubuntu 22.04. I don't notice a build > error when issuing the make command but the modules will not load. > Error ranges from invalid argument when loading the vdisk module to > others saying its the wrong version. Complete info was posted on > github, just wanted to start a discussion. I have reverted the kernel > update to -58 and am back up and running for now. > > > Thank you > > > Grant > > > > _______________________________________________ > Scst-devel mailing list > https://lists.sourceforge.net/lists/listinfo/scst-devel As far as I understand, you have been using SCST master branch. There was some regression that was causing a mismatch version problem (now it is fixed). So you can try to retest the problem with the latest version of SCST. Thanks, Gleb |
From: Grant A. <GAlbitz@All-Bits.com> - 2023-02-10 18:31:32
|
Hello, I posted more info on the issues page on github. It seems there is a problem with the newer kernel on ubuntu 22.04. I don't notice a build error when issuing the make command but the modules will not load. Error ranges from invalid argument when loading the vdisk module to others saying its the wrong version. Complete info was posted on github, just wanted to start a discussion. I have reverted the kernel update to -58 and am back up and running for now. Thank you Grant |
From: Mike K. <mik...@gm...> - 2023-02-07 14:52:54
|
Hi Steve, I don't know what the problem is with your connection; but do know that CentOS did EOL after 7.9 and support will be dropped sometimes in 202x! You other options are Rocky Linux, which the latest releases are 8.7 and 9.1 -- they are aligned with RHEL and kind of the follow-up of CentOS! If upgrading to Rocky is an option, I suggest trying 8.7 or 9.1 and see if that makes a difference. Otherwise, it could be the QLogic! Best Regards, Mike On Thu, Feb 2, 2023 at 12:50 PM Steve Houle <sh....@gm...> wrote: > Hi, > > I will try to make it short. > I have a server running Centos 7.9 with Kernel 3.10.0-1160.83.1.el7.x86_64 > and > I need to connect it to a SAN using fibre channel. Ther server has a > QLogic 4Gb > card (QLogic Corp. SP232-based 4Gb Fibre Channel to PCI Express HBA (rev > 02)). > > For many reason I cannot upgrade this server to higher Centos version so > I'm stuck > in 7.9 for now. > > I get that last version available of SCST on Github using branch 3.7.x (I > have > the same issue with other branch). > On first I try the "easy" with #make rpm > It looks to compile good up to scstadmin that failed with error : > Only one of PREFIX or INSTALL_BASE can be given. Not both. > make[3]: *** [makefile] Error 25 > > I did some research on Google and in the mailing-list but every solution I > try > get me the same error. > Some forum mention that could be a problem with the compilation of the Perl > module SCST. But I'm far from a developer and I cannot point out the > problem. > > Is anybody can help me ? > > Regards > Steve Houle > _______________________________________________ > Scst-devel mailing list > https://lists.sourceforge.net/lists/listinfo/scst-devel > |
From: Steve H. <sh....@gm...> - 2023-02-02 17:50:12
|
Hi, I will try to make it short. I have a server running Centos 7.9 with Kernel 3.10.0-1160.83.1.el7.x86_64 and I need to connect it to a SAN using fibre channel. Ther server has a QLogic 4Gb card (QLogic Corp. SP232-based 4Gb Fibre Channel to PCI Express HBA (rev 02)). For many reason I cannot upgrade this server to higher Centos version so I'm stuck in 7.9 for now. I get that last version available of SCST on Github using branch 3.7.x (I have the same issue with other branch). On first I try the "easy" with #make rpm It looks to compile good up to scstadmin that failed with error : Only one of PREFIX or INSTALL_BASE can be given. Not both. make[3]: *** [makefile] Error 25 I did some research on Google and in the mailing-list but every solution I try get me the same error. Some forum mention that could be a problem with the compilation of the Perl module SCST. But I'm far from a developer and I cannot point out the problem. Is anybody can help me ? Regards Steve Houle |
From: Gleb C. <gle...@sc...> - 2023-01-12 19:33:50
|
Hi Tony, On 1/12/23 21:52, Tony Battersby wrote: > I have about 14 patches to fix various target-mode issues in qla2xxx. > Most of the patches affect the upstream qla2xxx driver in addition to > scst_qla2xxx.c, so when the patches are ready, I will submit them to the > kernel mailing lists in addition to scst-devel. But for now I am > submitting these two patches that affect only scst_qla2xxx.c, so they > can be applied directly to SCST. I will send out the rest of the > patches sometime in the next few days. Thank you for the contribution! I will apply these two patches to the master branch this week. Thanks, Gleb |
From: Tony B. <to...@cy...> - 2023-01-12 19:07:28
|
I have about 14 patches to fix various target-mode issues in qla2xxx. Most of the patches affect the upstream qla2xxx driver in addition to scst_qla2xxx.c, so when the patches are ready, I will submit them to the kernel mailing lists in addition to scst-devel. But for now I am submitting these two patches that affect only scst_qla2xxx.c, so they can be applied directly to SCST. I will send out the rest of the patches sometime in the next few days. Tony Battersby Cybernetics |