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
(2) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Schmidt, A. <Ann...@st...> - 2024-09-05 13:30:01
|
Can you please (1) explain what is broken in the NPIV support and (2) when it will be reinstated to the target driver? |
From: <le...@za...> - 2024-08-12 12:39:05
|
Hello, When SCST receives an INQUIRY request for an incorrect LUN, it calls scst_set_lun_not_supported_inquiry(), which returns an inquiry buffer with a peripheral qualifier of 011b and a peripheral device type of 1Fh. However, for a VPD inquiry, it is unable to populate the remaining fields. According to SPC-6, if the device server cannot return the requested data, it should terminate with CHECK CONDITION: 6.7.1 INQUIRY command introduction ... In response to an INQUIRY command received by an incorrect logical unit, the SCSI target device shall return the INQUIRY data with the peripheral qualifier set to the value defined in 6.7.2. The device server or task router (see SAM-6) shall terminate an INQUIRY command with CHECK CONDITION status only if the device server or task router is unable to return the requested INQUIRY data. Attached is a proposed patch that modifies the code to call scst_set_lun_not_supported_inquiry() only for standard INQUIRY requests. Without the patch: # sg_inq -p0x83 /dev/sdb VPD INQUIRY, page code=0x83: invalid VPD response; probably a STANDARD INQUIRY response inquiry: Malformed SCSI command response sg_inq failed: Malformed SCSI command response Patched SCST: # sg_inq -p0x83 /dev/sdb VPD INQUIRY, page code=0x83: inquiry: field in cdb illegal (page not supported) sg_inq failed: Illegal request Thanks, -Lev. |
From: Oleg z. <zem...@ya...> - 2024-07-26 22:38:06
|
<div><div><span style="background-color:#ffffff;color:#1a1a1a;float:none;font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"> Hello, I've been using scst for a long time.For the last year, gov</span><br style="background-color:rgb( 255 , 255 , 255 );color:rgb( 26 , 26 , 26 );font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" /><span style="background-color:#ffffff;color:#1a1a1a;float:none;font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"> builds have not worked for me.When I connect, I get the error "debian</span><br style="background-color:rgb( 255 , 255 , 255 );color:rgb( 26 , 26 , 26 );font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" /><span style="background-color:#ffffff;color:#1a1a1a;float:none;font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"> iscsi-scstd[1107]: Name contains invalid character: U" .The fact is that</span><br style="background-color:rgb( 255 , 255 , 255 );color:rgb( 26 , 26 , 26 );font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" /><span style="background-color:#ffffff;color:#1a1a1a;float:none;font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"> on the Windows client the default name is</span><br style="background-color:rgb( 255 , 255 , 255 );color:rgb( 26 , 26 , 26 );font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" /><span style="background-color:#ffffff;color:#1a1a1a;float:none;font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"> iqn.2000-09.org.etherboot:UNKNOWN.In Windows itself I can change the</span><br style="background-color:rgb( 255 , 255 , 255 );color:rgb( 26 , 26 , 26 );font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" /><span style="background-color:#ffffff;color:#1a1a1a;float:none;font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"> name and scst connections are available.But when working without Hdd,</span><br style="background-color:rgb( 255 , 255 , 255 );color:rgb( 26 , 26 , 26 );font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" /><span style="background-color:#ffffff;color:#1a1a1a;float:none;font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"> the network boot name is defined as iqn.2000-09.org.etherboot:UNKNOWN</span><br style="background-color:rgb( 255 , 255 , 255 );color:rgb( 26 , 26 , 26 );font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" /><span style="background-color:#ffffff;color:#1a1a1a;float:none;font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"> and the scst server does not allow you to connect.How can I fix this</span><br style="background-color:rgb( 255 , 255 , 255 );color:rgb( 26 , 26 , 26 );font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" /><span style="background-color:#ffffff;color:#1a1a1a;float:none;font-family:'ys text' , 'arial' , sans-serif;font-size:14px;font-style:normal;font-weight:400;text-align:start;text-decoration-color:initial;text-decoration-style:initial;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"> problem</span></div></div> |
From: Karol S. <sar...@9l...> - 2024-06-05 08:22:26
|
Hi! We observed that in rare occurrences enabling the target port using scst's sysfs hangs for 5 minutes and eventually link enters Unknown state, from which it cannot be recovered. We attach qla2xxx logs. Could you please investigate the issue? *** Problem description *** We are exporting SCSI devices using SCST and Qlogic FC target driver. Sometimes we need to disable & enable target for maintenance. We observed that in rare occurrences Fibre Channel port won't go up. Enabling it via scst's sysfs (basically calling sqa_enable_tgt) hangs for 5 minutes and eventually leaves the link in Unknown state. Subsequent disable/enable operations also take 5 minutes, and the problem cannot be solved without a reboot (qla2xxx_scstkernel module cannot be unloaded, rmmod hangs forever). When looking at syslog on the system when the enable operation takes long for the first time, we see a tens of "Chip Reset in progress" messages, e.g.: May 21 21:43:22 HS4x000xMN02 kernel: sqatgt(5/0): Enabling target pwwn=21:00:00:24:ff:7f:8f:a8 May 21 21:43:22 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-00af:5: Performing ISP error recovery - ha=000000001468f64f. May 21 21:43:22 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-0075:5: ZIO mode 6 enabled; timer delay (200 us). May 21 21:43:24 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-d302:5: qla2x00_get_fw_version: FC-NVMe is Enabled (0x785a) May 21 21:43:24 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-11a3:5: SCM in FW: Not Supported May 21 21:43:26 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-500a:5: LOOP UP detected (8 Gbps). May 21 21:43:26 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-d035:5: Chip Reset in progress. Purging Mbox cmd=0x22. May 21 21:43:26 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-d035:5: Chip Reset in progress. Purging Mbox cmd=0x27. May 21 21:43:26 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-8033:5: Unable to reinitialize FCE (261). May 21 21:43:26 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-d035:5: Chip Reset in progress. Purging Mbox cmd=0x27. May 21 21:43:26 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-8034:5: Unable to reinitialize EFT (261). May 21 21:43:26 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-d035:5: Chip Reset in progress. Purging Mbox cmd=0x20. May 21 21:43:26 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-d035:5: Chip Reset in progress. Purging Mbox cmd=0x69. May 21 21:43:26 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-d035:5: Chip Reset in progress. Purging Mbox cmd=0x69. (...) Finally after 20 seconds, there is"FAILED" log: May 21 21:43:46 HS4x000xMN02 kernel: qla2xxx [0000:40:00.0]-803b:5: Firmware ready **** FAILED ****. Subsequent disable/enable target executions take 5 minutes each: May 21 21:43:46 HS4x000xMN02 kernel: sqatgt(5/0): Disabling target pwwn=21:00:00:24:ff:7f:8f:a8 May 21 21:48:46 HS4x000xMN02 kernel: sqatgt(5/0): Enabling target pwwn=21:00:00:24:ff:7f:8f:a8 May 21 21:53:46 HS4x000xMN02 kernel: sqatgt(5/0): Disabling target pwwn=21:00:00:24:ff:7f:8f:a8 May 21 21:58:46 HS4x000xMN02 kernel: sqatgt(5/0): Enabling target pwwn=21:00:00:24:ff:7f:8f:a8 May 21 22:03:46 HS4x000xMN02 kernel: sqatgt(5/0): Disabling target pwwn=21:00:00:24:ff:7f:8f:a8 May 21 22:08:46 HS4x000xMN02 kernel: sqatgt(5/0): Enabling target pwwn=21:00:00:24:ff:7f:8f:a8 May 21 22:13:46 HS4x000xMN02 kernel: sqatgt(5/0): Disabling target pwwn=21:00:00:24:ff:7f:8f:a8 (...) The system we are using: - HBA: QLE2692 - OS: Red Hat 8.4 - driver version: 10.02.09.100-k (from SCST 3.8.0) - firmware version: 8.08.204 *** Investigation trial *** We did some investigation. It seems to us that there may be some problem with driver or firmware. During the first failed disable/enable attempt of each occurrence, we saw that qla_hw_data->flags->mbox_busy is turned on and never turned off. We were unable to identify the code responsible for turning on this flagon those occurrences, so it looks like it is modified by FW. We also reproduced this issue with the newer firmware 9.14.00. From our observations, usually even if one port is affected by this issue, the second works normally. In our environment it takes a few hours of disabling/enabling port in a loop (a few hundred disable/enable cycles)on production server under load. We also reproduced this issue on the same hardware, but with RHEL8.4 OS without any extra software. Note that on this setup the problem reproduced less frequently (once every few days). To simplify the test environment we removed the server from the zones on switch and we stopped exporting any devices. The frequency of the issue re occurrence hasn't changed. Regards, Karol Sarnecki |
From: Sietse v. Z. <si...@wi...> - 2024-04-26 05:12:40
|
Works fine with vanilla 6.8 for me. -Sietse From: Grant Albitz via Scst-devel <scs...@li...> Sent: Friday, 26 April 2024 02:30 To: scs...@li... Subject: [Scst-devel] Ubuntu 24.04 - kernel 6.8 Hi, Just inquiring on support for kernel 6.8 in Ubuntu 24.04. I note that scst development notes list 6.7 in the nightly builds and someone just posted 6.9 changes today. 6.8 seems to be omitted from discussion. |
From: Grant A. <GAlbitz@All-Bits.com> - 2024-04-26 00:48:07
|
Hi, Just inquiring on support for kernel 6.8 in Ubuntu 24.04. I note that scst development notes list 6.7 in the nightly builds and someone just posted 6.9 changes today. 6.8 seems to be omitted from discussion. |
From: Xiaoyu Hu <sam...@gm...> - 2024-03-28 14:38:09
|
Dear SCST users, Does anyone know whether SCST has support for LPE 32Gb FC card`? If yes, where can i find How-To? best regards, Samuel |
From: Chan, S. (S. E. - SGI) <sam...@hp...> - 2024-03-13 19:44:05
|
________________________________ From: Bart Van Assche <bva...@ac...> Sent: Tuesday, March 12, 2024 03:42 PM To: Chan, Sam (Servers ERT - SGI) <sam...@hp...>; scs...@li... <scs...@li...> Subject: Re: [Scst-devel] panic in scst_rx_mgmt_fn() On 1/26/24 12:04, Chan, Sam (Servers ERT - SGI) wrote: [3966906.400285] WARNING: CPU: 1 PID: 30180 at /root/rpmbuild/BUILD/scst-master/srpt/src/ib_srpt.c:2249 srpt_unregister_ch+0x56/0x90 [ib_srpt] I can't find any warning statement near line 2249 in ib_srpt.c. What ib_srpt version are you using? Thanks, Bart. this is scst 3.6. it's not the latest; but it's what we test and qualify with our other products. that warning is from srpt_unregister_ch(), which seems to be only in new versions. 63 64 /* Name of this kernel module. */ 65 #define DRV_NAME "ib_srpt" 66 #define DRV_VERSION "3.6.0" "#" __stringify(OFED_FLAVOR) 67 #define DRV_RELDATE "29 December 2021" here's module information.... crash.bin> module ffffffffc0ed1120 struct module { state = MODULE_STATE_LIVE, list = { next = 0xffffffffc0266168, prev = 0xffffffffc08dfc48 }, name = "scst\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000", mkobj = { kobj = { name = 0xffff972565b86ae0 "scst", entry = { next = 0xffffffffc08dfc98, prev = 0xffffffffc02661b8 }, parent = 0xffff973c7fabf0d8, kset = 0xffff973c7fabf0c0, ktype = 0xffffffffb3a55ce0, { sd = 0xffff972fb7f1a2d0, __UNIQUE_ID_rh_kabi_hide7 = { sd = 0xffff972fb7f1a2d0 }, {<No data fields>} }, kref = { refcount = { counter = 0x3 } }, state_initialized = 0x1, state_in_sysfs = 0x1, state_add_uevent_sent = 0x1, state_remove_uevent_sent = 0x0, uevent_suppress = 0x0 }, mod = 0xffffffffc0ed1120 <__this_module>, drivers_dir = 0x0, mp = 0xffff973c05c3ce00 }, modinfo_attrs = 0xffff972fe6b64400, version = 0xffff972565b86ad0 "3.6.0", srcversion = 0xffff97258d79c800 "667459CEF9F0080A16011FE", holders_dir = 0xffff972fe2b168c0, syms = 0xffffffffc0eb6030 <__ksymtab___scst_get_resid>, crcs = 0xffffffffc0eb6b00 <__kcrctab___scst_get_resid>, num_syms = 0x5d, kp = 0xffffffffc0ece6d0 <__param_auto_cm_assignment>, num_kp = 0x6, num_gpl_syms = 0x50, gpl_syms = 0xffffffffc0eb6600 <__ksymtab___scst_check_local_events>, gpl_crcs = 0xffffffffc0eb6de8 <__kcrctab___scst_check_local_events>, sig_ok = 0x0, gpl_future_syms = 0x0, gpl_future_crcs = 0x0, num_gpl_future_syms = 0x0, num_exentries = 0x0, extable = 0x0, init = 0xffffffffc08a72e4 <init_scst>, module_init = 0x0, module_core = 0xffffffffc0e71000 <scst_ext_copy_get_cur_seg_data_len>, init_size = 0x0, core_size = 0x247929, init_text_size = 0x0, core_text_size = 0x45000, init_ro_size = 0x0, core_ro_size = 0x5e000, arch = {<No data fields>}, taints = 0x3000, num_bugs = 0x72, bug_list = { next = 0xffffffffc02662c0, prev = 0xffffffffc08dfda0 }, bug_table = 0xffffffffc0eca90c, symtab = 0xffffffffc109f000, core_symtab = 0xffffffffc109f000, num_symtab = 0x88a, core_num_syms = 0x88a, strtab = 0xffffffffc10abcf0 "", core_strtab = 0xffffffffc10abcf0 "", sect_attrs = 0xffff9730c1fbc000, notes_attrs = 0xffff9730b97c9f60, args = 0xffff972fe2b16940 "scst_threads", percpu = 0x0, percpu_size = 0x0, num_tracepoints = 0x0, tracepoints_ptrs = 0x0, jump_entries = 0x0, num_jump_entries = 0x0, num_trace_bprintk_fmt = 0x0, trace_bprintk_fmt_start = 0x0, trace_events = 0x0, num_trace_events = 0x0, num_ftrace_callsites = 0x373, ftrace_callsites = 0xffffffffc0eccb38, source_list = { next = 0xffff972fe4a05f00, prev = 0xffff972fe4a05500 }, target_list = { next = 0xffff972fe2b16910, prev = 0xffff972fe2b16910 }, waiter = 0xffff973c3ac8c200, exit = 0xffffffffc0eb5880 <exit_scst>, refptr = 0x2d1dc020eaa0 } |
From: Bart V. A. <bva...@ac...> - 2024-03-12 23:14:00
|
On 1/26/24 12:04, Chan, Sam (Servers ERT - SGI) wrote: > [3966906.400285] WARNING: CPU: 1 PID: 30180 at > /root/rpmbuild/BUILD/scst-master/srpt/src/ib_srpt.c:2249 > srpt_unregister_ch+0x56/0x90 [ib_srpt] I can't find any warning statement near line 2249 in ib_srpt.c. What ib_srpt version are you using? Thanks, Bart. |
From: Chan, S. (S. E. - SGI) <sam...@hp...> - 2024-03-12 01:11:30
|
maybe a bit more data from the crash dump might help. initially, i suggested that the problem might be due to scst_unregister_session() being called in parallel to scst_rx_mgmt_fn(). but now, i don't think that's the case. here's a better output of the stack trace... crash.bin> bt -t PID: 30180 TASK: ffff972e85e1b180 CPU: 1 COMMAND: "kworker/1:0" START: machine_kexec at ffffffffb2e66294 [ffff972d3e40b920] machine_kexec at ffffffffb2e66294 [ffff972d3e40b980] __crash_kexec at ffffffffb2f22562 [ffff972d3e40ba08] scst_rx_mgmt_fn at ffffffffc0ea96c1 [scst] [ffff972d3e40ba50] crash_kexec at ffffffffb2f22650 [ffff972d3e40ba68] oops_end at ffffffffb358b798 [ffff972d3e40ba90] die at ffffffffb2e30a7b [ffff972d3e40bac0] do_trap at ffffffffb358aee0 [ffff972d3e40bb10] do_invalid_op at ffffffffb2e2d2a4 [ffff972d3e40bb28] scst_rx_mgmt_fn at ffffffffc0ea96c1 [scst] [ffff972d3e40bbc0] invalid_op at ffffffffb35972ee [ffff972d3e40bc48] scst_rx_mgmt_fn at ffffffffc0ea96c1 [scst] [ffff972d3e40bc70] scst_rx_mgmt_fn at ffffffffc0ea96c1 [scst] [ffff972d3e40bcb8] vprintk_default at ffffffffb2e9e489 [ffff972d3e40bcf8] scst_unregister_session at ffffffffc0ea9771 [scst] [ffff972d3e40bd88] srpt_unregister_ch at ffffffffc0432389 [ib_srpt] [ffff972d3e40bda0] srpt_do_compl_work at ffffffffc0436228 [ib_srpt] [ffff972d3e40be20] process_one_work at ffffffffb2ebdc4f [ffff972d3e40be68] worker_thread at ffffffffb2ebed66 [ffff972d3e40bea8] worker_thread at ffffffffb2ebec40 [ffff972d3e40bec8] kthread at ffffffffb2ec5c21 [ffff972d3e40bf30] kthread at ffffffffb2ec5b50 [ffff972d3e40bf50] ret_from_fork_nospec_end at ffffffffb3593df7 [ffff972d3e40bf80] kthread at ffffffffb2ec5b50 so scst_unregister_session() seemed to have completed before scst_rx_mgmt_fn(). both of these functions are accessing scst_session. i found that to be this, if this helps... struct scst_session { init_phase = 0x3, tgt = 0xffff972fb56f0000, sess_tgt_priv = 0xffff972e5cebb000, sess_aflags = 0x0, tgt_dev_list_mutex = { count = { counter = 0x1 }, wait_lock = { { rlock = { raw_lock = { val = { counter = 0x0 } } } } }, wait_list = { next = 0xffff972c087a4d28, prev = 0xffff972c087a4d28 }, owner = 0x0, { osq = { tail = { counter = 0x0 } }, __UNIQUE_ID_rh_kabi_hide3 = { spin_mlock = 0x0 }, {<No data fields>} } }, sess_tgt_dev_list = {{ next = 0xffff972e776be540, prev = 0xffff972e776be540 }, { next = 0xffff972c087a4d58, prev = 0xffff972c087a4d58 }, { next = 0xffff972c087a4d68, prev = 0xffff972c087a4d68 }, { next = 0xffff972c087a4d78, prev = 0xffff972c087a4d78 }, { next = 0xffff972c087a4d88, prev = 0xffff972c087a4d88 }, { next = 0xffff972c087a4d98, prev = 0xffff972c087a4d98 }, { next = 0xffff972c087a4da8, prev = 0xffff972c087a4da8 }, { next = 0xffff972c087a4db8, prev = 0xffff972c087a4db8 }, { next = 0xffff972c087a4dc8, prev = 0xffff972c087a4dc8 }, { next = 0xffff972c087a4dd8, prev = 0xffff972c087a4dd8 }, { next = 0xffff972c087a4de8, prev = 0xffff972c087a4de8 }, { next = 0xffff972c087a4df8, prev = 0xffff972c087a4df8 }, { next = 0xffff972c087a4e08, prev = 0xffff972c087a4e08 }, { next = 0xffff972c087a4e18, prev = 0xffff972c087a4e18 }, { next = 0xffff972c087a4e28, prev = 0xffff972c087a4e28 }, { next = 0xffff972c087a4e38, prev = 0xffff972c087a4e38 }, { next = 0xffff972c087a4e48, prev = 0xffff972c087a4e48 }, { next = 0xffff972c087a4e58, prev = 0xffff972c087a4e58 }, { next = 0xffff972c087a4e68, prev = 0xffff972c087a4e68 }, { next = 0xffff972c087a4e78, prev = 0xffff972c087a4e78 }, { next = 0xffff972c087a4e88, prev = 0xffff972c087a4e88 }, { next = 0xffff972c087a4e98, prev = 0xffff972c087a4e98 }, { next = 0xffff972c087a4ea8, prev = 0xffff972c087a4ea8 }, { next = 0xffff972c087a4eb8, prev = 0xffff972c087a4eb8 }, { next = 0xffff972c087a4ec8, prev = 0xffff972c087a4ec8 }, { next = 0xffff972c087a4ed8, prev = 0xffff972c087a4ed8 }, { next = 0xffff972c087a4ee8, prev = 0xffff972c087a4ee8 }, { next = 0xffff972c087a4ef8, prev = 0xffff972c087a4ef8 }, { next = 0xffff972c087a4f08, prev = 0xffff972c087a4f08 }, { next = 0xffff972c087a4f18, prev = 0xffff972c087a4f18 }, { next = 0xffff972c087a4f28, prev = 0xffff972c087a4f28 }, { next = 0xffff972c087a4f38, prev = 0xffff972c087a4f38 }}, sess_cmd_list = { next = 0xffff972c087a4f80, prev = 0xffff972c087a4f80 }, sess_list_lock = { { rlock = { raw_lock = { val = { counter = 0x0 } } } } }, refcnt = { count = { counter = 0x8000000000000001 }, percpu_count_ptr = 0x2d1dc021cc03, release = 0xffffffffc0e85bb0 <scst_sess_release>, confirm_switch = 0xffffffffb318ac10, force_atomic = 0x0, rcu = { next = 0x0, func = 0xffffffffb318ad20 } }, sess_cmd_count = { counter = 0x1 }, io_stats = {{ cmd_count = 0x0, io_byte_count = 0x0, unaligned_cmd_count = 0x0 }, { cmd_count = 0x0, io_byte_count = 0x0, unaligned_cmd_count = 0x0 }, { cmd_count = 0x0, io_byte_count = 0x0, unaligned_cmd_count = 0x0 }, { cmd_count = 0x0, io_byte_count = 0x0, unaligned_cmd_count = 0x0 }, { cmd_count = 0x0, io_byte_count = 0x0, unaligned_cmd_count = 0x0 }}, acg = 0xffff972fafcd9c00, transport_id = 0xffff973022e57f40 "\004", acg_sess_list_entry = { next = 0xffff972c646ee660, prev = 0xffff972c087a1960 }, hw_pending_work = { work = { data = { counter = 0xfffffffe0 }, entry = { next = 0xffff972c087a5078, prev = 0xffff972c087a5078 }, func = 0xffffffffc0e7e540 <scst_hw_pending_work_fn> }, timer = { entry = { next = 0x0, prev = 0x0 }, expires = 0x0, base = 0xffff97304fd93942, function = 0xffffffffb2ebbe50, data = 0xffff972c087a5070, slack = 0xffffffff, start_pid = 0xffffffff, start_site = 0x0, start_comm = "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000" }, wq = 0x0, cpu = 0x0 }, initiator_name = 0xffff972e3761d600 "fe80:0000:0000:0000:e41d:2d03:001f:7c80", sess_name = 0xffff972e3761d680 "fe80:0000:0000:0000:e41d:2d03:001f:7c80_4", sess_list_entry = { next = 0xffff972c646ee700, prev = 0xffff972c087a1a00 }, sysfs_sess_list_entry = { next = 0xffff972c646ee710, prev = 0xffff972c087a1a10 }, sess_init_list_entry = { next = 0x0, prev = 0x0 }, sess_shut_list_entry = { next = 0x0, prev = 0x0 }, init_deferred_cmd_list = { next = 0xffff972c087a5140, prev = 0xffff972c087a5140 }, init_deferred_mcmd_list = { next = 0xffff972c087a5150, prev = 0xffff972c087a5150 }, shut_phase = 0x1, shutdown_compl = 0x0, sess_cm_list_id_list = { next = 0xffff972c087a5170, prev = 0xffff972c087a5170 }, sess_cm_list_id_cleanup_work = { work = { data = { counter = 0xfffffffe0 }, entry = { next = 0xffff972c087a5188, prev = 0xffff972c087a5188 }, func = 0xffffffffc0e73d60 <sess_cm_list_id_cleanup_work_fn> }, timer = { entry = { next = 0x0, prev = 0x0 }, expires = 0x0, base = 0xffff97304fd93942, function = 0xffffffffb2ebbe50, data = 0xffff972c087a5180, slack = 0xffffffff, start_pid = 0xffffffff, start_site = 0x0, start_comm = "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000" }, wq = 0x0, cpu = 0x0 }, sess_kobj_release_cmpl = 0x0, sess_mq = 0x0, sess_kobj_ready = 0x1, sess_kobj = { name = 0xffff972e3761d5c0 "fe80:0000:0000:0000:e41d:2d03:001f:7c80_4", entry = { next = 0xffff972c087a5218, prev = 0xffff972c087a5218 }, parent = 0xffff9730ca3bf340, kset = 0x0, ktype = 0xffffffffc0ed03c0 <scst_session_ktype>, { sd = 0xffff972ee02c9d98, __UNIQUE_ID_rh_kabi_hide7 = { sd = 0xffff972ee02c9d98 }, {<No data fields>} }, kref = { refcount = { counter = 0x3 } }, state_initialized = 0x1, state_in_sysfs = 0x1, state_add_uevent_sent = 0x0, state_remove_uevent_sent = 0x0, uevent_suppress = 0x0 }, lat_kobj = 0xffff972e3761d900, reg_sess_data = 0x0, init_result_fn = 0x0, unreg_done_fn = 0xffffffffc0433cc0 <srpt_unreg_sess>, lat_stats_lock = { { rlock = { raw_lock = { val = { counter = 0x0 } } } } }, lat_stats = 0x0 } additionally, there's an error message in the dmesg that is interesting.... [3966906.400273] ------------[ cut here ]------------ [3966906.400285] WARNING: CPU: 1 PID: 30180 at /root/rpmbuild/BUILD/scst-master/srpt/src/ib_srpt.c:2249 srpt_u nregister_ch+0x56/0x90 [ib_srpt] [3966906.400289] Modules linked in: ib_srpt(OE) scst_vdisk(OE) scst(OE) rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw _cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) vfat fat skx_edac nfit libnvdimm intel_powerclamp coretemp intel_rapl iosf_mbi sgi_xvm(POE) kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd pcspkr sgi_pm(POE) lpc_ich mei_me hpilo hpwdt sg mei wmi ipmi_si ipmi_devintf ipmi_msghandler sgi_r_pool(OE) acpi_power_meter sgi_os_lib(POE) kn em(OE) ip_tables xfs libcrc32c mlx5_ib(OE) ib_uverbs(OE) raid1 ib_core(OE) sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm crct10dif_pclmul ahci c rct10dif_common crc32c_intel drm libahci mlx5_core(OE) [3966906.400379] nvme tg3 nvme_core libata mlxfw(OE) devlink mlx_compat(OE) ptp pps_core drm_panel_orientation_quirks uas usb_storage dm_mirror dm_region_hash dm_log dm_mod [3966906.400401] CPU: 1 PID: 30180 Comm: kworker/1:0 Kdump: loaded Tainted: P OE ------------ 3.10.0-1160.el7.x86_64 #1 [3966906.400404] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 11/13/2019 [3966906.400412] Workqueue: srpt srpt_do_compl_work [ib_srpt] [3966906.400415] Call Trace: [3966906.400432] [<ffffffffb3581340>] dump_stack+0x19/0x1b [3966906.400441] [<ffffffffb2e9b228>] __warn+0xd8/0x100 [3966906.400447] [<ffffffffb2e9b36d>] warn_slowpath_null+0x1d/0x20 [3966906.400453] [<ffffffffc04323a6>] srpt_unregister_ch+0x56/0x90 [ib_srpt] [3966906.400460] [<ffffffffc0436228>] srpt_do_compl_work+0x2c8/0x640 [ib_srpt] [3966906.400470] [<ffffffffb2ebdc4f>] process_one_work+0x17f/0x440 [3966906.400479] [<ffffffffb2ebed66>] worker_thread+0x126/0x3c0 [3966906.400486] [<ffffffffb2ebec40>] ? manage_workers.isra.26+0x2a0/0x2a0 [3966906.400492] [<ffffffffb2ec5c21>] kthread+0xd1/0xe0 [3966906.400498] [<ffffffffb2ec5b50>] ? insert_kthread_work+0x40/0x40 [3966906.400506] [<ffffffffb3593df7>] ret_from_fork_nospec_begin+0x21/0x21 [3966906.400512] [<ffffffffb2ec5b50>] ? insert_kthread_work+0x40/0x40 [3966906.400515] ---[ end trace 5d97197aa6829cf9 ]--- [3966906.400521] [30180]: scst: ***CRITICAL ERROR***: New mgmt cmd while shutting down the session ffff972c087a4d00 shut_phase 1 the last line is important. error is printed from here... 6915 6916 static int scst_post_rx_mgmt_cmd(struct scst_session *sess, 6917 struct scst_mgmt_cmd *mcmd) 6918 { 6919 unsigned long flags; 6920 int res = 0; 6921 6922 TRACE_ENTRY(); 6923 6924 if (unlikely(sess->shut_phase != SCST_SESS_SPH_READY)) { <--- 6925 PRINT_CRIT_ERROR("New mgmt cmd while shutting down the " 6926 "session %p shut_phase %ld", sess, sess->shut_phase); 6927 sBUG(); 6928 } 6929 the if() condition is checking sess->init_phase. from the structure above, that field is this... shut_phase = 0x1, <---- shutdown_compl = 0x0, sess_cm_list_id_list = { next = 0xffff972c087a5170, prev = 0xffff972c087a5170 }, 417 /* Set if session is initialized and ready */ 418 #define SCST_SESS_SPH_READY 0 419 if there's more from the crash dump i can provide, do let me know. thanks. -sam |
From: Patrik S. <po...@po...> - 2024-03-09 19:42:18
|
Hello, Am 09.03.2024 um 16:46 schrieb Hein-Pieter van Braam via Scst-devel <scs...@li...>: > I've been interested in running SCST as a PSCSI target. After a lot of reading it seems that right now it is no longer possible to do so. I happen to have several AIC7980 based controllers that I'd like to use for this purpose. I'm in a similar boat. While I can't help you with porting, I also want to enable to establish a "storage server" of sorts for parallel SCSI, but for enabling older IBM AS/400 to have storage again. The challenges are unusual sector sizes (520 or 522 bytes), and additional vendor specific SCSI commands SKIP_READ and SKIP_WRITE. I have not yet started to dig into this particular rabbit hole, yet. So you're not alone with an interest in pSCSI in SCST. Just wanted to make my "voice heard". As far as I remember the comments from my question many moons ago, current state of affairs is parallel SCSI support is gone due to lack of a driver maintainer. An older SCST version is needed. I have on my ToDo-List to install a Debian Linux with an appropriate Kernel do use the latest version with pSCSI support. Second, I have a dim memory to have read that only a certain LSI chips support switching to target mode. Not sure if the Adaptec chips a) support this and b) if they do, if it's known *how* to do it. :-) > Also, yes, I'm aware it is 2024. I have reasons ;) possibly poor ones. But here we are. No need to justify your reasons! :-) :wq! PoC |
From: Hein-Pieter v. B. <hp...@tm...> - 2024-03-09 16:05:44
|
Hello all! I've been interested in running SCST as a PSCSI target. After a lot of reading it seems that right now it is no longer possible to do so. I happen to have several AIC7980 based controllers that I'd like to use for this purpose. I've done some comparisons between the FreeBSD aic7xxx driver and the Linux one, and they are still fairly similar. I have also found a copy of Hu/Steve Gang's aic7xxx initial port to SCST, but that one appears to be very limited in what it can do. So, I think to make this happen I'll have to do some driver surgery :) Which I'm happy to do but I was wondering if perhaps there was some kind of documentation or perhaps someone here has some tips on how to "map" FreeBSD CAM target functionality to SCST. I've been looking at the various entry points for SCST and I think I understand what they are for, but it appears that CAM is a bit more ... integrated into the drivers than SCST is, and it is a little hard for me to work out what really does what. Particularly the int (*rdy_to_xfer)(struct scst_cmd *cmd) is difficult to find a CAM equivalent for, or I'm just entirely misunderstanding what it is supposed to do. Any help would be much appreciated! Also, yes, I'm aware it is 2024. I have reasons ;) possibly poor ones. But here we are. - HP |
From: Grant A. <GAlbitz@All-Bits.com> - 2024-02-25 05:54:22
|
I posted this issue on github as well. Today I upgraded ubuntu kernel from 5.15.0-94 to -97 as well as upgraded scst to the latest version. My esxi hosts could no longer see the storage device. I did some troubleshooting, and I was able to get it working by reverting to the 3.8 original release. I believe this may have been caused by the feb commits. 5.15.0-94 was released 2/7/2024 and I would have upgraded to that within a day or 2 of it being released, and I always upgrade scst at the same time. So based on that only the Feb16th commits are new since my last round of updates. What I was seeing in dmesg after the upgrade: [ 737.246144] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 737.247310] #PF: supervisor read access in kernel mode [ 737.248467] #PF: error_code(0x0000) - not-present page [ 737.249613] PGD 0 P4D 0 [ 737.250761] Oops: 0000 [#8] SMP NOPTI [ 737.251892] CPU: 15 PID: 3111 Comm: ISER-PSC-Net5 Tainted: P D OE 5.15.0-97-generic #107-Ubuntu [ 737.253039] Hardware name: Dell Inc. PowerEdge R740xd/07X9K0, BIOS 2.20.1 09/13/2023 [ 737.254164] RIP: 0010:vdisk_exec_sai_16+0x79/0x270 [scst_vdisk] [ 737.255288] Code: 2b 04 25 28 00 00 00 0f 85 0a 02 00 00 48 83 c4 30 31 c0 41 5c 41 5d 5d c3 cc cc cc cc 49 8b 74 24 68 48 8b 4e 28 48 8b 41 30 <48> 8b 38 48 85 ff 74 0b 48 8b 87 48 03 00 00 48 8b 78 50 48 8b 01 [ 737.257551] RSP: 0018:ffffaa36264ffd40 EFLAGS: 00010246 [ 737.258652] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d3e36d82000 [ 737.259741] RDX: ffff9d3e7c6d4df2 RSI: ffff9d1ed0640a80 RDI: ffff9d3e3a8a3080 [ 737.260830] RBP: ffffaa36264ffd80 R08: ffff9d3e7c6d4d00 R09: 0000000000000000 [ 737.261903] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9d3e7c6d4d00 [ 737.262945] R13: ffff9d1ed0640a80 R14: 0000000000000000 R15: ffffffffc0c43b40 [ 737.263988] FS: 0000000000000000(0000) GS:ffff9d5dafbc0000(0000) knlGS:0000000000000000 [ 737.265041] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 737.266074] CR2: 0000000000000000 CR3: 00000020856b4004 CR4: 00000000007706e0 [ 737.267096] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 737.268105] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 737.269102] PKRU: 55555554 [ 737.270091] Call Trace: [ 737.271075] [ 737.272047] ? show_trace_log_lvl+0x1d6/0x2ea [ 737.273034] ? show_trace_log_lvl+0x1d6/0x2ea [ 737.273999] ? vdev_do_job+0x37/0xd0 [scst_vdisk] [ 737.274959] ? show_regs.part.0+0x23/0x29 [ 737.275906] ? __die_body.cold+0x8/0xd [ 737.276853] ? __die+0x2b/0x37 [ 737.277795] ? page_fault_oops+0x13b/0x170 [ 737.278733] ? isert_pdu_send+0x9b/0xc0 [isert_scst] [ 737.279661] ? do_user_addr_fault+0x321/0x670 [ 737.280575] ? exc_page_fault+0x77/0x170 [ 737.281481] ? asm_exc_page_fault+0x27/0x30 [ 737.282376] ? vdisk_exec_sai_16+0x79/0x270 [scst_vdisk] [ 737.283263] vdev_do_job+0x37/0xd0 [scst_vdisk] [ 737.284132] fileio_exec+0x24/0x30 [scst_vdisk] [ 737.284974] scst_do_real_exec+0x59/0x140 [scst] [ 737.285845] ? _raw_spin_unlock_bh+0x1e/0x30 [ 737.286640] scst_exec_check_blocking+0xc7/0x230 [scst] [ 737.287470] scst_process_active_cmd+0x273/0x1c30 [scst] [ 737.288288] scst_cmd_thread+0x17d/0x550 [scst] [ 737.289087] ? wait_woken+0x70/0x70 [ 737.289819] ? scst_cmd_done_local+0x90/0x90 [scst] [ 737.290575] kthread+0x127/0x150 [ 737.291263] ? set_kthread_struct+0x50/0x50 [ 737.291936] ret_from_fork+0x1f/0x30 [ 737.292591] [ 737.293226] Modules linked in: scst_vdisk(OE) isert_scst(OE) iscsi_scst(OE) scst(OE) dlm rdma_cm iw_cm ib_cm bonding intel_rapl_msr intel_rapl_common isst_if_common skx_edac nfit x86_pkg_temp_thermal intel_powerclamp coretemp ipmi_ssif nls_iso8859_1 zfs(PO) kvm_intel zunicode(PO) kvm zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) rapl znvpair(PO) spl(O) dell_smbios dcdbas intel_cstate dell_wmi_descriptor wmi_bmof mei_me input_leds joydev mei ioatdma intel_pch_thermal acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter mac_hid sch_fq_codel dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua binfmt_misc msr efi_pstore ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear mlx5_ib ib_uverbs ib_core mgag200 drm_kms_helper hid_generic syscopyarea sysfillrect sysimgblt mlx5_core fb_sys_fops crct10dif_pclmul uas crc32_pclmul usbhid mlxfw cec psample [ 737.293343] ghash_clmulni_intel hid usb_storage aesni_intel ixgbe crypto_simd igb xfrm_algo tls cryptd rc_core ahci i2c_i801 nvme dca pci_hyperv_intf megaraid_sas xhci_pci nvme_core drm i2c_algo_bit lpc_ich mdio i2c_smbus libahci xhci_pci_renesas wmi [ 737.300617] CR2: 0000000000000000 [ 737.301377] ---[ end trace acea122bec946806 ]--- [ 737.315667] RIP: 0010:vdisk_exec_sai_16+0x79/0x270 [scst_vdisk] [ 737.316461] Code: 2b 04 25 28 00 00 00 0f 85 0a 02 00 00 48 83 c4 30 31 c0 41 5c 41 5d 5d c3 cc cc cc cc 49 8b 74 24 68 48 8b 4e 28 48 8b 41 30 <48> 8b 38 48 85 ff 74 0b 48 8b 87 48 03 00 00 48 8b 78 50 48 8b 01 [ 737.318063] RSP: 0018:ffffaa36264efd40 EFLAGS: 00010246 [ 737.318861] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d3e36d82000 [ 737.319663] RDX: ffff9d3e7c6d4b32 RSI: ffff9d1ed0640a80 RDI: ffff9d3e3a8a2780 [ 737.320480] RBP: ffffaa36264efd80 R08: ffff9d3e7c6d4a40 R09: 0000000000000000 [ 737.321294] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9d3e7c6d4a40 [ 737.322104] R13: ffff9d1ed0640a80 R14: 0000000000000000 R15: ffffffffc0c43b40 [ 737.322919] FS: 0000000000000000(0000) GS:ffff9d5dafbc0000(0000) knlGS:0000000000000000 [ 737.323753] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 737.324602] CR2: 0000000000000000 CR3: 00000020856b4004 CR4: 00000000007706e0 [ 737.325455] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 737.326308] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 737.327157] PKRU: 55555554 |
From: Chan, S. (S. E. - SGI) <sam...@hp...> - 2024-02-08 19:19:11
|
hello. anyone has any insight into this? feedback would be appreciated. thanks. ________________________________ From: Chan, Sam (Servers ERT - SGI) <sam...@hp...> Sent: Friday, January 26, 2024 12:04 PM To: scs...@li... <scs...@li...> Cc: Chan, Sam (Servers ERT - SGI) <sam...@hp...> Subject: panic in scst_rx_mgmt_fn() hello. a customer of mine hit a panic in SCST, that appears to be this RHEL issue... https://access.redhat.com/solutions/7017557 [https://access.redhat.com/webassets/avalon/g/shadowman-200.png]<https://access.redhat.com/solutions/7017557> Kernel panic due to BUG_ON() in the third party kernel module [scst] - Red Hat Customer Portal<https://access.redhat.com/solutions/7017557> access.redhat.com the signature of the customer's incident looks like this... crash.bin> sys KERNEL: vmlinux-3.10.0-1160.el7.x86_64.debug DUMPFILE: vmcore [PARTIAL DUMP] CPUS: 36 DATE: Fri Jul 7 16:30:28 2023 UPTIME: 46 days, 00:31:15 LOAD AVERAGE: 0.07, 0.10, 0.13 TASKS: 16860 NODENAME: cirrus-rpool0.icexa.epcc.ed.ac.uk RELEASE: 3.10.0-1160.el7.x86_64 VERSION: #1 SMP Tue Aug 18 14:50:17 EDT 2020 MACHINE: x86_64 (3000 Mhz) MEMORY: 95.7 GB PANIC: "kernel BUG at /root/rpmbuild/BUILD/scst-master/scst/src/scst_targ.c:6927!" crash.bin> bt PID: 30180 TASK: ffff972e85e1b180 CPU: 1 COMMAND: "kworker/1:0" #0 [ffff972d3e40b920] machine_kexec at ffffffffb2e66294 #1 [ffff972d3e40b980] __crash_kexec at ffffffffb2f22562 #2 [ffff972d3e40ba50] crash_kexec at ffffffffb2f22650 #3 [ffff972d3e40ba68] oops_end at ffffffffb358b798 #4 [ffff972d3e40ba90] die at ffffffffb2e30a7b #5 [ffff972d3e40bac0] do_trap at ffffffffb358aee0 #6 [ffff972d3e40bb10] do_invalid_op at ffffffffb2e2d2a4 #7 [ffff972d3e40bbc0] invalid_op at ffffffffb35972ee [exception RIP: scst_rx_mgmt_fn+0x3f1] RIP: ffffffffc0ea96c1 RSP: ffff972d3e40bc78 RFLAGS: 00010292 RAX: 0000000000000066 RBX: ffff972e32100bd0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ffff972d3e40bcf0 R8: 0000000000000000 R9: ffff97303c1fc600 R10: 0000000000024afd R11: 0000000000000001 R12: 000000000000000a R13: ffff972c087a4d00 R14: 000000000000000a R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffff972d3e40bc70] scst_rx_mgmt_fn at ffffffffc0ea96c1 [scst] #9 [ffff972d3e40bd88] srpt_unregister_ch at ffffffffc0432389 [ib_srpt] #10 [ffff972d3e40bda0] srpt_do_compl_work at ffffffffc0436228 [ib_srpt] #11 [ffff972d3e40be20] process_one_work at ffffffffb2ebdc4f #12 [ffff972d3e40be68] worker_thread at ffffffffb2ebed66 #13 [ffff972d3e40bec8] kthread at ffffffffb2ec5c21 [3966906.028065] [3750]: scst: TM fn 0 (mcmd ffff9725aa7b6af0) finished, status -1 [3966906.028229] [16851]: scst: TM fn ABORT_TASK/0 (mcmd ffff9725aa7b6a80, initiator fe80:0000:0000:0000:e41d:2d03:0029:6330, target fe80:0000:0000:0000:b883:03ff:ffa0:b520) [3966906.028238] [3750]: scst: TM fn 0 (mcmd ffff9725aa7b6a80) finished, status -1 [3966906.397460] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:e41d:2d03:001f:7c80-22886. [3966906.398071] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:e41d:2d03:001f:7c80-22887. [3966906.398471] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:e41d:2d03:001f:7c80-22888. [3966906.399072] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:e41d:2d03:001f:7c80-22889. [3966906.399670] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:e41d:2d03:001f:7c80-22890. [3966906.399978] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:e41d:2d03:001f:7c80-22891. [3966906.400273] ------------[ cut here ]------------ [3966906.400285] WARNING: CPU: 1 PID: 30180 at /root/rpmbuild/BUILD/scst-master/srpt/src/ib_srpt.c:2249 srpt_unregister_ch+0x56/0x90 [ib_srpt] [3966906.400289] Modules linked in: ib_srpt(OE) scst_vdisk(OE) scst(OE) rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) vfat fat skx_edac nfit libnvdimm intel_powerclamp coretemp intel_rapl iosf_mbi sgi_xvm(POE) kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd pcspkr sgi_pm(POE) lpc_ich mei_me hpilo hpwdt sg mei wmi ipmi_si ipmi_devintf ipmi_msghandler sgi_r_pool(OE) acpi_power_meter sgi_os_lib(POE) knem(OE) ip_tables xfs libcrc32c mlx5_ib(OE) ib_uverbs(OE) raid1 ib_core(OE) sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm crct10dif_pclmul ahci crct10dif_common crc32c_intel drm libahci mlx5_core(OE) [3966906.400379] nvme tg3 nvme_core libata mlxfw(OE) devlink mlx_compat(OE) ptp pps_core drm_panel_orientation_quirks uas usb_storage dm_mirror dm_region_hash dm_log dm_mod [3966906.400401] CPU: 1 PID: 30180 Comm: kworker/1:0 Kdump: loaded Tainted: P OE ------------ 3.10.0-1160.el7.x86_64 #1 [3966906.400404] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 11/13/2019 [3966906.400412] Workqueue: srpt srpt_do_compl_work [ib_srpt] [3966906.400415] Call Trace: [3966906.400432] [<ffffffffb3581340>] dump_stack+0x19/0x1b [3966906.400441] [<ffffffffb2e9b228>] __warn+0xd8/0x100 [3966906.400447] [<ffffffffb2e9b36d>] warn_slowpath_null+0x1d/0x20 [3966906.400453] [<ffffffffc04323a6>] srpt_unregister_ch+0x56/0x90 [ib_srpt] [3966906.400460] [<ffffffffc0436228>] srpt_do_compl_work+0x2c8/0x640 [ib_srpt] [3966906.400470] [<ffffffffb2ebdc4f>] process_one_work+0x17f/0x440 [3966906.400479] [<ffffffffb2ebed66>] worker_thread+0x126/0x3c0 [3966906.400486] [<ffffffffb2ebec40>] ? manage_workers.isra.26+0x2a0/0x2a0 [3966906.400492] [<ffffffffb2ec5c21>] kthread+0xd1/0xe0 [3966906.400498] [<ffffffffb2ec5b50>] ? insert_kthread_work+0x40/0x40 [3966906.400506] [<ffffffffb3593df7>] ret_from_fork_nospec_begin+0x21/0x21 [3966906.400512] [<ffffffffb2ec5b50>] ? insert_kthread_work+0x40/0x40 [3966906.400515] ---[ end trace 5d97197aa6829cf9 ]--- [3966906.400521] [30180]: scst: ***CRITICAL ERROR***: New mgmt cmd while shutting down the session ffff972c087a4d00 shut_phase 1 [3966906.411909] ------------[ cut here ]------------ [3966906.416723] kernel BUG at /root/rpmbuild/BUILD/scst-master/scst/src/scst_targ.c:6927! [3966906.424767] invalid opcode: 0000 [#1] SMP [3966906.429079] Modules linked in: ib_srpt(OE) scst_vdisk(OE) scst(OE) rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) vfat fat skx_edac nfit libnvdimm intel_powerclamp coretemp intel_rapl iosf_mbi sgi_xvm(POE) kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd pcspkr sgi_pm(POE) lpc_ich mei_me hpilo hpwdt sg mei wmi ipmi_si ipmi_devintf ipmi_msghandler sgi_r_pool(OE) acpi_power_meter sgi_os_lib(POE) knem(OE) ip_tables xfs libcrc32c mlx5_ib(OE) ib_uverbs(OE) raid1 ib_core(OE) sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm crct10dif_pclmul ahci crct10dif_common crc32c_intel drm libahci mlx5_core(OE) [3966906.501800] nvme tg3 nvme_core libata mlxfw(OE) devlink mlx_compat(OE) ptp pps_core drm_panel_orientation_quirks uas usb_storage dm_mirror dm_region_hash dm_log dm_mod [3966906.515767] CPU: 1 PID: 30180 Comm: kworker/1:0 Kdump: loaded Tainted: P W OE ------------ 3.10.0-1160.el7.x86_64 #1 [3966906.527477] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 11/13/2019 [3966906.536221] Workqueue: srpt srpt_do_compl_work [ib_srpt] [3966906.541743] task: ffff972e85e1b180 ti: ffff972d3e408000 task.ti: ffff972d3e408000 [3966906.549436] RIP: 0010:[<ffffffffc0ea96c1>] [<ffffffffc0ea96c1>] scst_rx_mgmt_fn+0x3f1/0x430 [scst] [3966906.558725] RSP: 0018:ffff972d3e40bc78 EFLAGS: 00010292 [3966906.564236] RAX: 0000000000000066 RBX: ffff972e32100bd0 RCX: 0000000000000006 [3966906.571581] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 [3966906.578925] RBP: ffff972d3e40bcf0 R08: 0000000000000000 R09: ffff97303c1fc600 [3966906.586271] R10: 0000000000024afd R11: 0000000000000001 R12: 000000000000000a [3966906.593617] R13: ffff972c087a4d00 R14: 000000000000000a R15: 0000000000000000 [3966906.600961] FS: 0000000000000000(0000) GS:ffff97304fc40000(0000) knlGS:0000000000000000 [3966906.609265] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [3966906.615213] CR2: 00007f6661a3ebd0 CR3: 00000012fea10000 CR4: 00000000007607e0 [3966906.622557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [3966906.629901] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [3966906.637244] PKRU: 00000000 [3966906.640138] Call Trace: [3966906.642770] [<ffffffffb2e9e489>] ? vprintk_default+0x29/0x40 [3966906.648728] [<ffffffffc0ea9771>] scst_unregister_session+0x71/0x150 [scst] [3966906.655901] [<ffffffffc0432389>] srpt_unregister_ch+0x39/0x90 [ib_srpt] [3966906.662811] [<ffffffffc0436228>] srpt_do_compl_work+0x2c8/0x640 [ib_srpt] [3966906.669896] [<ffffffffb2ebdc4f>] process_one_work+0x17f/0x440 [3966906.675931] [<ffffffffb2ebed66>] worker_thread+0x126/0x3c0 [3966906.681706] [<ffffffffb2ebec40>] ? manage_workers.isra.26+0x2a0/0x2a0 [3966906.688439] [<ffffffffb2ec5c21>] kthread+0xd1/0xe0 [3966906.693514] [<ffffffffb2ec5b50>] ? insert_kthread_work+0x40/0x40 [3966906.699812] [<ffffffffb3593df7>] ret_from_fork_nospec_begin+0x21/0x21 [3966906.706547] [<ffffffffb2ec5b50>] ? insert_kthread_work+0x40/0x40 [3966906.712843] Code: 48 89 44 24 08 4c 89 2c 24 41 b8 0e 1b 00 00 48 c7 c1 90 c9 eb c0 48 c7 c2 fe a3 ec c0 48 c7 c6 2d a4 ec c0 31 c0 e8 9f c3 fc ff <0f> 0b 83 f8 01 0f 84 6e fd ff ff 83 f8 02 74 17 85 c0 0f 84 23 [3966906.733764] RIP [<ffffffffc0ea96c1>] scst_rx_mgmt_fn+0x3f1/0x430 [scst] [3966906.741283] RSP <ffff972d3e40bc78> this seems to be triggered with IB connectivity issues, which SCST would try to recover from, but eventually would panic. comments indicates that scst_rx_mgmt_fn() shouldn't be called at same time as scst_unregister_session(). but dmesg indicates that this is the case. ---------- /* * scst_rx_mgmt_fn() - create new management command and send it for execution * * Description: * Creates new management command and sends it for execution. * * Returns 0 for success, error code otherwise. * * Must not be called in parallel with scst_unregister_session() for the * same sess. */ int scst_rx_mgmt_fn(struct scst_session *sess, const struct scst_rx_mgmt_params *params) { int res = -EFAULT; struct scst_mgmt_cmd *mcmd = NULL; char state_name[32]; ---------- thanks. sam |
From: Gleb C. <gle...@sc...> - 2024-01-30 07:58:00
|
Hi, On 1/23/24 11:43, Ali Hamid wrote: > Hi All, > can you help me,Please? > In the release section of scst, there are 3 files, one release and 2 > source code. > What is the difference between release and source code files? > Very Thanks, > > > _______________________________________________ > Scst-devel mailing list > https://lists.sourceforge.net/lists/listinfo/scst-devel Actually, there is no difference between them. The release file is only used to track the downloads number. Thanks, Gleb |
From: Chan, S. (S. E. - SGI) <sam...@hp...> - 2024-01-26 20:42:41
|
hello. a customer of mine hit a panic in SCST, that appears to be this RHEL issue... https://access.redhat.com/solutions/7017557 [https://access.redhat.com/webassets/avalon/g/shadowman-200.png]<https://access.redhat.com/solutions/7017557> Kernel panic due to BUG_ON() in the third party kernel module [scst] - Red Hat Customer Portal<https://access.redhat.com/solutions/7017557> access.redhat.com the signature of the customer's incident looks like this... crash.bin> sys KERNEL: vmlinux-3.10.0-1160.el7.x86_64.debug DUMPFILE: vmcore [PARTIAL DUMP] CPUS: 36 DATE: Fri Jul 7 16:30:28 2023 UPTIME: 46 days, 00:31:15 LOAD AVERAGE: 0.07, 0.10, 0.13 TASKS: 16860 NODENAME: cirrus-rpool0.icexa.epcc.ed.ac.uk RELEASE: 3.10.0-1160.el7.x86_64 VERSION: #1 SMP Tue Aug 18 14:50:17 EDT 2020 MACHINE: x86_64 (3000 Mhz) MEMORY: 95.7 GB PANIC: "kernel BUG at /root/rpmbuild/BUILD/scst-master/scst/src/scst_targ.c:6927!" crash.bin> bt PID: 30180 TASK: ffff972e85e1b180 CPU: 1 COMMAND: "kworker/1:0" #0 [ffff972d3e40b920] machine_kexec at ffffffffb2e66294 #1 [ffff972d3e40b980] __crash_kexec at ffffffffb2f22562 #2 [ffff972d3e40ba50] crash_kexec at ffffffffb2f22650 #3 [ffff972d3e40ba68] oops_end at ffffffffb358b798 #4 [ffff972d3e40ba90] die at ffffffffb2e30a7b #5 [ffff972d3e40bac0] do_trap at ffffffffb358aee0 #6 [ffff972d3e40bb10] do_invalid_op at ffffffffb2e2d2a4 #7 [ffff972d3e40bbc0] invalid_op at ffffffffb35972ee [exception RIP: scst_rx_mgmt_fn+0x3f1] RIP: ffffffffc0ea96c1 RSP: ffff972d3e40bc78 RFLAGS: 00010292 RAX: 0000000000000066 RBX: ffff972e32100bd0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ffff972d3e40bcf0 R8: 0000000000000000 R9: ffff97303c1fc600 R10: 0000000000024afd R11: 0000000000000001 R12: 000000000000000a R13: ffff972c087a4d00 R14: 000000000000000a R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffff972d3e40bc70] scst_rx_mgmt_fn at ffffffffc0ea96c1 [scst] #9 [ffff972d3e40bd88] srpt_unregister_ch at ffffffffc0432389 [ib_srpt] #10 [ffff972d3e40bda0] srpt_do_compl_work at ffffffffc0436228 [ib_srpt] #11 [ffff972d3e40be20] process_one_work at ffffffffb2ebdc4f #12 [ffff972d3e40be68] worker_thread at ffffffffb2ebed66 #13 [ffff972d3e40bec8] kthread at ffffffffb2ec5c21 [3966906.028065] [3750]: scst: TM fn 0 (mcmd ffff9725aa7b6af0) finished, status -1 [3966906.028229] [16851]: scst: TM fn ABORT_TASK/0 (mcmd ffff9725aa7b6a80, initiator fe80:0000:0000:0000:e41d:2d03:0029:6330, target fe80:0000:0000:0000:b883:03ff:ffa0:b520) [3966906.028238] [3750]: scst: TM fn 0 (mcmd ffff9725aa7b6a80) finished, status -1 [3966906.397460] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:e41d:2d03:001f:7c80-22886. [3966906.398071] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:e41d:2d03:001f:7c80-22887. [3966906.398471] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:e41d:2d03:001f:7c80-22888. [3966906.399072] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:e41d:2d03:001f:7c80-22889. [3966906.399670] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:e41d:2d03:001f:7c80-22890. [3966906.399978] ib_srpt: Received CM TimeWait exit for ch fe80:0000:0000:0000:e41d:2d03:001f:7c80-22891. [3966906.400273] ------------[ cut here ]------------ [3966906.400285] WARNING: CPU: 1 PID: 30180 at /root/rpmbuild/BUILD/scst-master/srpt/src/ib_srpt.c:2249 srpt_unregister_ch+0x56/0x90 [ib_srpt] [3966906.400289] Modules linked in: ib_srpt(OE) scst_vdisk(OE) scst(OE) rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) vfat fat skx_edac nfit libnvdimm intel_powerclamp coretemp intel_rapl iosf_mbi sgi_xvm(POE) kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd pcspkr sgi_pm(POE) lpc_ich mei_me hpilo hpwdt sg mei wmi ipmi_si ipmi_devintf ipmi_msghandler sgi_r_pool(OE) acpi_power_meter sgi_os_lib(POE) knem(OE) ip_tables xfs libcrc32c mlx5_ib(OE) ib_uverbs(OE) raid1 ib_core(OE) sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm crct10dif_pclmul ahci crct10dif_common crc32c_intel drm libahci mlx5_core(OE) [3966906.400379] nvme tg3 nvme_core libata mlxfw(OE) devlink mlx_compat(OE) ptp pps_core drm_panel_orientation_quirks uas usb_storage dm_mirror dm_region_hash dm_log dm_mod [3966906.400401] CPU: 1 PID: 30180 Comm: kworker/1:0 Kdump: loaded Tainted: P OE ------------ 3.10.0-1160.el7.x86_64 #1 [3966906.400404] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 11/13/2019 [3966906.400412] Workqueue: srpt srpt_do_compl_work [ib_srpt] [3966906.400415] Call Trace: [3966906.400432] [<ffffffffb3581340>] dump_stack+0x19/0x1b [3966906.400441] [<ffffffffb2e9b228>] __warn+0xd8/0x100 [3966906.400447] [<ffffffffb2e9b36d>] warn_slowpath_null+0x1d/0x20 [3966906.400453] [<ffffffffc04323a6>] srpt_unregister_ch+0x56/0x90 [ib_srpt] [3966906.400460] [<ffffffffc0436228>] srpt_do_compl_work+0x2c8/0x640 [ib_srpt] [3966906.400470] [<ffffffffb2ebdc4f>] process_one_work+0x17f/0x440 [3966906.400479] [<ffffffffb2ebed66>] worker_thread+0x126/0x3c0 [3966906.400486] [<ffffffffb2ebec40>] ? manage_workers.isra.26+0x2a0/0x2a0 [3966906.400492] [<ffffffffb2ec5c21>] kthread+0xd1/0xe0 [3966906.400498] [<ffffffffb2ec5b50>] ? insert_kthread_work+0x40/0x40 [3966906.400506] [<ffffffffb3593df7>] ret_from_fork_nospec_begin+0x21/0x21 [3966906.400512] [<ffffffffb2ec5b50>] ? insert_kthread_work+0x40/0x40 [3966906.400515] ---[ end trace 5d97197aa6829cf9 ]--- [3966906.400521] [30180]: scst: ***CRITICAL ERROR***: New mgmt cmd while shutting down the session ffff972c087a4d00 shut_phase 1 [3966906.411909] ------------[ cut here ]------------ [3966906.416723] kernel BUG at /root/rpmbuild/BUILD/scst-master/scst/src/scst_targ.c:6927! [3966906.424767] invalid opcode: 0000 [#1] SMP [3966906.429079] Modules linked in: ib_srpt(OE) scst_vdisk(OE) scst(OE) rdma_ucm(OE) ib_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_fpga_tools(OE) mlx4_en(OE) mlx4_ib(OE) mlx4_core(OE) vfat fat skx_edac nfit libnvdimm intel_powerclamp coretemp intel_rapl iosf_mbi sgi_xvm(POE) kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd pcspkr sgi_pm(POE) lpc_ich mei_me hpilo hpwdt sg mei wmi ipmi_si ipmi_devintf ipmi_msghandler sgi_r_pool(OE) acpi_power_meter sgi_os_lib(POE) knem(OE) ip_tables xfs libcrc32c mlx5_ib(OE) ib_uverbs(OE) raid1 ib_core(OE) sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm crct10dif_pclmul ahci crct10dif_common crc32c_intel drm libahci mlx5_core(OE) [3966906.501800] nvme tg3 nvme_core libata mlxfw(OE) devlink mlx_compat(OE) ptp pps_core drm_panel_orientation_quirks uas usb_storage dm_mirror dm_region_hash dm_log dm_mod [3966906.515767] CPU: 1 PID: 30180 Comm: kworker/1:0 Kdump: loaded Tainted: P W OE ------------ 3.10.0-1160.el7.x86_64 #1 [3966906.527477] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 11/13/2019 [3966906.536221] Workqueue: srpt srpt_do_compl_work [ib_srpt] [3966906.541743] task: ffff972e85e1b180 ti: ffff972d3e408000 task.ti: ffff972d3e408000 [3966906.549436] RIP: 0010:[<ffffffffc0ea96c1>] [<ffffffffc0ea96c1>] scst_rx_mgmt_fn+0x3f1/0x430 [scst] [3966906.558725] RSP: 0018:ffff972d3e40bc78 EFLAGS: 00010292 [3966906.564236] RAX: 0000000000000066 RBX: ffff972e32100bd0 RCX: 0000000000000006 [3966906.571581] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 [3966906.578925] RBP: ffff972d3e40bcf0 R08: 0000000000000000 R09: ffff97303c1fc600 [3966906.586271] R10: 0000000000024afd R11: 0000000000000001 R12: 000000000000000a [3966906.593617] R13: ffff972c087a4d00 R14: 000000000000000a R15: 0000000000000000 [3966906.600961] FS: 0000000000000000(0000) GS:ffff97304fc40000(0000) knlGS:0000000000000000 [3966906.609265] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [3966906.615213] CR2: 00007f6661a3ebd0 CR3: 00000012fea10000 CR4: 00000000007607e0 [3966906.622557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [3966906.629901] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [3966906.637244] PKRU: 00000000 [3966906.640138] Call Trace: [3966906.642770] [<ffffffffb2e9e489>] ? vprintk_default+0x29/0x40 [3966906.648728] [<ffffffffc0ea9771>] scst_unregister_session+0x71/0x150 [scst] [3966906.655901] [<ffffffffc0432389>] srpt_unregister_ch+0x39/0x90 [ib_srpt] [3966906.662811] [<ffffffffc0436228>] srpt_do_compl_work+0x2c8/0x640 [ib_srpt] [3966906.669896] [<ffffffffb2ebdc4f>] process_one_work+0x17f/0x440 [3966906.675931] [<ffffffffb2ebed66>] worker_thread+0x126/0x3c0 [3966906.681706] [<ffffffffb2ebec40>] ? manage_workers.isra.26+0x2a0/0x2a0 [3966906.688439] [<ffffffffb2ec5c21>] kthread+0xd1/0xe0 [3966906.693514] [<ffffffffb2ec5b50>] ? insert_kthread_work+0x40/0x40 [3966906.699812] [<ffffffffb3593df7>] ret_from_fork_nospec_begin+0x21/0x21 [3966906.706547] [<ffffffffb2ec5b50>] ? insert_kthread_work+0x40/0x40 [3966906.712843] Code: 48 89 44 24 08 4c 89 2c 24 41 b8 0e 1b 00 00 48 c7 c1 90 c9 eb c0 48 c7 c2 fe a3 ec c0 48 c7 c6 2d a4 ec c0 31 c0 e8 9f c3 fc ff <0f> 0b 83 f8 01 0f 84 6e fd ff ff 83 f8 02 74 17 85 c0 0f 84 23 [3966906.733764] RIP [<ffffffffc0ea96c1>] scst_rx_mgmt_fn+0x3f1/0x430 [scst] [3966906.741283] RSP <ffff972d3e40bc78> this seems to be triggered with IB connectivity issues, which SCST would try to recover from, but eventually would panic. comments indicates that scst_rx_mgmt_fn() shouldn't be called at same time as scst_unregister_session(). but dmesg indicates that this is the case. ---------- /* * scst_rx_mgmt_fn() - create new management command and send it for execution * * Description: * Creates new management command and sends it for execution. * * Returns 0 for success, error code otherwise. * * Must not be called in parallel with scst_unregister_session() for the * same sess. */ int scst_rx_mgmt_fn(struct scst_session *sess, const struct scst_rx_mgmt_params *params) { int res = -EFAULT; struct scst_mgmt_cmd *mcmd = NULL; char state_name[32]; ---------- thanks. sam |
From: Ali H. <its...@gm...> - 2024-01-23 08:43:12
|
Hi All, can you help me,Please? In the release section of scst, there are 3 files, one release and 2 source code. What is the difference between release and source code files? Very Thanks, |
From: Rob T. <ro...@rt...> - 2024-01-19 22:11:19
|
Hi Gleb, Congrats on the 3.8 release! A bit late, but this is confirmation that the shift out of bounds issue has been fixed in the 3.8 release, both on Ubuntu 22.04 and 23.10. Thanks! Rob On 1/9/2024 3:35 PM, Gleb Chesnokov wrote: > Hi Rob, > > On 12/27/23 14:20, Rob Turk wrote: >> I'm porting my code to Ubuntu 22.04LTS. >> >> Fresh install scst v3.7 from here: >> https://github.com/SCST-project/scst/releases/download/v3.7/scst-3.7.zip >> Host: Ubuntu 22.04 >> Linux ub22inst 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 >> UTC 2023 x86_64 x86_64 x86_64 GNU/Linux >> >> Registering the first device results in a trap: >> >> [Wed Dec 27 12:08:33 2023] [834]: scst: Added device CTVTL_DRIVE11 to >> group iqn.2016-09.com.consolitape.ub22inst:vtl (LUN 0, flags 0x2) to >> target iqn.2016-09.com.consolitape.ub22inst:vtl >> [Wed Dec 27 12:08:33 2023] [834]: scst: Added device CTVTL_DRIVE11 to >> group local_target (LUN 0, flags 0x2) to target local_target >> [Wed Dec 27 12:08:33 2023] >> ================================================================================ >> [Wed Dec 27 12:08:33 2023] UBSAN: shift-out-of-bounds in >> /var/lib/dkms/scst/3.7.0/build/scst/src/scst_targ.c:3912:6 >> [Wed Dec 27 12:08:33 2023] shift exponent -1 is negative >> [Wed Dec 27 12:08:33 2023] CPU: 0 PID: 1062 Comm: ctdevice Tainted: >> G OE 5.15.0-91-generic #101-Ubuntu >> [Wed Dec 27 12:08:33 2023] Hardware name: VMware, Inc. VMware Virtual >> Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 >> [Wed Dec 27 12:08:33 2023] Call Trace: >> [Wed Dec 27 12:08:33 2023] <TASK> >> [Wed Dec 27 12:08:33 2023] show_stack+0x52/0x5c >> [Wed Dec 27 12:08:33 2023] dump_stack_lvl+0x4a/0x63 >> [Wed Dec 27 12:08:33 2023] dump_stack+0x10/0x16 >> [Wed Dec 27 12:08:33 2023] ubsan_epilogue+0x9/0x36 >> [Wed Dec 27 12:08:33 2023] >> __ubsan_handle_shift_out_of_bounds.cold+0x61/0xef >> [Wed Dec 27 12:08:33 2023] ? ttwu_do_activate+0x82/0x100 >> [Wed Dec 27 12:08:33 2023] scst_process_active_cmd.cold+0xf/0x2d [scst] >> [Wed Dec 27 12:08:33 2023] ? sdev_evt_alloc+0xa0/0xa0 >> [Wed Dec 27 12:08:33 2023] ? wake_up_process+0x15/0x20 >> [Wed Dec 27 12:08:33 2023] ? sdev_evt_alloc+0xa0/0xa0 >> [Wed Dec 27 12:08:33 2023] scst_process_redirect_cmd+0xd4/0x2e0 [scst] >> [Wed Dec 27 12:08:33 2023] ? sdev_evt_alloc+0xa0/0xa0 >> [Wed Dec 27 12:08:33 2023] scst_tgt_cmd_done+0x48/0x70 [scst] >> [Wed Dec 27 12:08:33 2023] ? scsi_mq_done+0x27/0x70 >> [Wed Dec 27 12:08:33 2023] scst_local_targ_xmit_response+0x64/0x220 >> [scst_local] >> [Wed Dec 27 12:08:33 2023] scst_process_active_cmd+0x891/0x2140 [scst] >> [Wed Dec 27 12:08:33 2023] ? sgv_pool_alloc+0xab/0xa00 [scst] >> [Wed Dec 27 12:08:33 2023] scst_process_redirect_cmd+0xd4/0x2e0 [scst] >> [Wed Dec 27 12:08:33 2023] scst_cmd_done_local+0x80/0x110 [scst] >> [Wed Dec 27 12:08:33 2023] dev_user_process_reply+0x597/0x1160 >> [scst_user] >> [Wed Dec 27 12:08:33 2023] ? handle_pte_fault+0x20a/0x240 >> [Wed Dec 27 12:08:33 2023] dev_user_ioctl+0x145/0xb23 [scst_user] >> [Wed Dec 27 12:08:33 2023] __x64_sys_ioctl+0x95/0xd0 >> [Wed Dec 27 12:08:33 2023] ? __x64_sys_ioctl+0x95/0xd0 >> [Wed Dec 27 12:08:33 2023] do_syscall_64+0x5c/0xc0 >> [Wed Dec 27 12:08:33 2023] ? do_user_addr_fault+0x1e7/0x670 >> [Wed Dec 27 12:08:33 2023] ? exit_to_user_mode_prepare+0x37/0xb0 >> [Wed Dec 27 12:08:33 2023] ? irqentry_exit_to_user_mode+0x17/0x20 >> [Wed Dec 27 12:08:33 2023] ? irqentry_exit+0x1d/0x30 >> [Wed Dec 27 12:08:33 2023] ? exc_page_fault+0x89/0x170 >> [Wed Dec 27 12:08:33 2023] entry_SYSCALL_64_after_hwframe+0x62/0xcc >> [Wed Dec 27 12:08:33 2023] RIP: 0033:0x7f031494075f >> [Wed Dec 27 12:08:33 2023] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 >> 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 >> b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 >> 64 48 2b 04 25 28 00 >> [Wed Dec 27 12:08:33 2023] RSP: 002b:00007f0314020d90 EFLAGS: >> 00000246 ORIG_RAX: 0000000000000010 >> [Wed Dec 27 12:08:33 2023] RAX: ffffffffffffffda RBX: >> 00007f0314021640 RCX: 00007f031494075f >> [Wed Dec 27 12:08:33 2023] RDX: 00005592aef75dc0 RSI: >> 0000000040387506 RDI: 0000000000000004 >> [Wed Dec 27 12:08:33 2023] RBP: 00007f0314020e10 R08: >> 00005592ad199dbb R09: 00005592ad199dbb >> [Wed Dec 27 12:08:33 2023] R10: 00005592ad199dbb R11: >> 0000000000000246 R12: 00007f0314021640 >> [Wed Dec 27 12:08:33 2023] R13: 0000000000000002 R14: >> 00007f03148ba7d0 R15: 00007fff070557c0 >> [Wed Dec 27 12:08:33 2023] </TASK> >> [Wed Dec 27 12:08:33 2023] >> ================================================================================ >> [Wed Dec 27 12:08:33 2023] scsi 33:0:0:0: Sequential-Access IBM >> 03592E07 3694 PQ: 0 ANSI: 6 >> [Wed Dec 27 12:08:33 2023] [317]: scst_local: Configuring queue depth >> 64 on sdev 000000007ddafb45 (tagged supported 0) >> [Wed Dec 27 12:08:33 2023] scsi 33:0:0:0: Attached scsi generic sg2 >> type 1 >> >> The device does register and works properly. Further device >> registrations do not trigger this trap. >> >> Rob >> >> >> _______________________________________________ >> 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 > (https://github.com/SCST-project/scst/commit/be9d368361c6f302acde580e9914f14265bed2db) > > Thanks, > Gleb |
From: Vladislav B. <vs...@vl...> - 2024-01-16 20:43:13
|
Hi Gleb, Good work! Vlad On 15.01.24 15:26, Gleb Chesnokov wrote: > Hi, > > On 1/12/24 19:09, Gleb Chesnokov wrote: >> Hi, >> >> SCST 3.7.0 was released about one year ago. I plan to release version >> 3.8.0 next week. The 3.8.0 release will be based on the master branch >> (https://github.com/SCST-project/scst/). >> >> Summary of changes between versions 3.7 and 3.8 >> ----------------------------------------------- >> - Fixed depmod warnings during the installation process. >> - Resolved RPM build issues for Fedora and CentOS Stream kernels. >> - Introduced selectable debug mode levels during package building by >> passing >> PKG_BUILD_MODE=2[release, debug, perf] as an argument to make. >> - scst_disk: Implemented cluster mode support. >> - scst_vdisk: Introduced the lb_per_pb_exp attribute, allowing control >> over >> whether READ CAPACITY 16 returns LOGICAL BLOCKS PER PHYSICAL BLOCK >> EXPONENT. >> - scst_vdisk: Enabled exclusive opening of block devices to prevent >> concurrent usage. >> - iscsi-scst: Implemented iSCSI TargetAlias support. >> - iscsi-scstd: Added initiator name validation during login. >> - Added the aen_disabled attribute, enabling forcible UA sending >> instead of >> AEN from the target port. >> - Fixed UNIT ATTENTION for remote PR registrants. >> - Enhanced device blocking to ensure signal-induced waiting >> cancellation does >> not crash the system. >> - Corrected the display of the number of active commands during >> suspending. >> - qla2x00t-32gbit driver: Rectified ABORT_TASK_SET processing. >> - qla2x00t-32gbit driver: Updated from Linux kernel version v5.15 to >> v6.7. >> >> The kernel versions supported by this release are: >> * Kernel.org kernel versions v3.10..v6.7. >> * Debian / Ubuntu kernels based on upstream kernel versions v3.10..v6.7. >> * RHEL / CentOS / AlmaLinux 7.x, 8.0..8.9 and 9.0..9.3 kernels. >> * UEK version 4, 5, 6 and 7 kernels. >> >> Thanks, >> Gleb >> >> >> _______________________________________________ >> Scst-devel mailing list >> https://lists.sourceforge.net/lists/listinfo/scst-devel > I'm glad to announce SCST 3.8 is available on Github: > > https://github.com/SCST-project/scst/releases/tag/v3.8 > > Thanks, > Gleb > > > _______________________________________________ > Scst-devel mailing list > https://lists.sourceforge.net/lists/listinfo/scst-devel |
From: Gleb C. <gle...@sc...> - 2024-01-15 12:26:28
|
Hi, On 1/12/24 19:09, Gleb Chesnokov wrote: > Hi, > > SCST 3.7.0 was released about one year ago. I plan to release version > 3.8.0 next week. The 3.8.0 release will be based on the master branch > (https://github.com/SCST-project/scst/). > > Summary of changes between versions 3.7 and 3.8 > ----------------------------------------------- > - Fixed depmod warnings during the installation process. > - Resolved RPM build issues for Fedora and CentOS Stream kernels. > - Introduced selectable debug mode levels during package building by > passing > PKG_BUILD_MODE=2[release, debug, perf] as an argument to make. > - scst_disk: Implemented cluster mode support. > - scst_vdisk: Introduced the lb_per_pb_exp attribute, allowing control over > whether READ CAPACITY 16 returns LOGICAL BLOCKS PER PHYSICAL BLOCK > EXPONENT. > - scst_vdisk: Enabled exclusive opening of block devices to prevent > concurrent usage. > - iscsi-scst: Implemented iSCSI TargetAlias support. > - iscsi-scstd: Added initiator name validation during login. > - Added the aen_disabled attribute, enabling forcible UA sending instead of > AEN from the target port. > - Fixed UNIT ATTENTION for remote PR registrants. > - Enhanced device blocking to ensure signal-induced waiting cancellation > does > not crash the system. > - Corrected the display of the number of active commands during suspending. > - qla2x00t-32gbit driver: Rectified ABORT_TASK_SET processing. > - qla2x00t-32gbit driver: Updated from Linux kernel version v5.15 to v6.7. > > The kernel versions supported by this release are: > * Kernel.org kernel versions v3.10..v6.7. > * Debian / Ubuntu kernels based on upstream kernel versions v3.10..v6.7. > * RHEL / CentOS / AlmaLinux 7.x, 8.0..8.9 and 9.0..9.3 kernels. > * UEK version 4, 5, 6 and 7 kernels. > > Thanks, > Gleb > > > _______________________________________________ > Scst-devel mailing list > https://lists.sourceforge.net/lists/listinfo/scst-devel I'm glad to announce SCST 3.8 is available on Github: https://github.com/SCST-project/scst/releases/tag/v3.8 Thanks, Gleb |
From: Gleb C. <gle...@sc...> - 2024-01-12 16:10:41
|
Hi, SCST 3.7.0 was released about one year ago. I plan to release version 3.8.0 next week. The 3.8.0 release will be based on the master branch (https://github.com/SCST-project/scst/). Summary of changes between versions 3.7 and 3.8 ----------------------------------------------- - Fixed depmod warnings during the installation process. - Resolved RPM build issues for Fedora and CentOS Stream kernels. - Introduced selectable debug mode levels during package building by passing PKG_BUILD_MODE=2[release, debug, perf] as an argument to make. - scst_disk: Implemented cluster mode support. - scst_vdisk: Introduced the lb_per_pb_exp attribute, allowing control over whether READ CAPACITY 16 returns LOGICAL BLOCKS PER PHYSICAL BLOCK EXPONENT. - scst_vdisk: Enabled exclusive opening of block devices to prevent concurrent usage. - iscsi-scst: Implemented iSCSI TargetAlias support. - iscsi-scstd: Added initiator name validation during login. - Added the aen_disabled attribute, enabling forcible UA sending instead of AEN from the target port. - Fixed UNIT ATTENTION for remote PR registrants. - Enhanced device blocking to ensure signal-induced waiting cancellation does not crash the system. - Corrected the display of the number of active commands during suspending. - qla2x00t-32gbit driver: Rectified ABORT_TASK_SET processing. - qla2x00t-32gbit driver: Updated from Linux kernel version v5.15 to v6.7. The kernel versions supported by this release are: * Kernel.org kernel versions v3.10..v6.7. * Debian / Ubuntu kernels based on upstream kernel versions v3.10..v6.7. * RHEL / CentOS / AlmaLinux 7.x, 8.0..8.9 and 9.0..9.3 kernels. * UEK version 4, 5, 6 and 7 kernels. Thanks, Gleb |
From: Gleb C. <gle...@sc...> - 2024-01-09 14:59:23
|
Hi Rob, On 12/27/23 14:20, Rob Turk wrote: > I'm porting my code to Ubuntu 22.04LTS. > > Fresh install scst v3.7 from here: > https://github.com/SCST-project/scst/releases/download/v3.7/scst-3.7.zip > Host: Ubuntu 22.04 > Linux ub22inst 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC > 2023 x86_64 x86_64 x86_64 GNU/Linux > > Registering the first device results in a trap: > > [Wed Dec 27 12:08:33 2023] [834]: scst: Added device CTVTL_DRIVE11 to > group iqn.2016-09.com.consolitape.ub22inst:vtl (LUN 0, flags 0x2) to > target iqn.2016-09.com.consolitape.ub22inst:vtl > [Wed Dec 27 12:08:33 2023] [834]: scst: Added device CTVTL_DRIVE11 to > group local_target (LUN 0, flags 0x2) to target local_target > [Wed Dec 27 12:08:33 2023] > ================================================================================ > [Wed Dec 27 12:08:33 2023] UBSAN: shift-out-of-bounds in > /var/lib/dkms/scst/3.7.0/build/scst/src/scst_targ.c:3912:6 > [Wed Dec 27 12:08:33 2023] shift exponent -1 is negative > [Wed Dec 27 12:08:33 2023] CPU: 0 PID: 1062 Comm: ctdevice Tainted: > G OE 5.15.0-91-generic #101-Ubuntu > [Wed Dec 27 12:08:33 2023] Hardware name: VMware, Inc. VMware Virtual > Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 > [Wed Dec 27 12:08:33 2023] Call Trace: > [Wed Dec 27 12:08:33 2023] <TASK> > [Wed Dec 27 12:08:33 2023] show_stack+0x52/0x5c > [Wed Dec 27 12:08:33 2023] dump_stack_lvl+0x4a/0x63 > [Wed Dec 27 12:08:33 2023] dump_stack+0x10/0x16 > [Wed Dec 27 12:08:33 2023] ubsan_epilogue+0x9/0x36 > [Wed Dec 27 12:08:33 2023] > __ubsan_handle_shift_out_of_bounds.cold+0x61/0xef > [Wed Dec 27 12:08:33 2023] ? ttwu_do_activate+0x82/0x100 > [Wed Dec 27 12:08:33 2023] scst_process_active_cmd.cold+0xf/0x2d [scst] > [Wed Dec 27 12:08:33 2023] ? sdev_evt_alloc+0xa0/0xa0 > [Wed Dec 27 12:08:33 2023] ? wake_up_process+0x15/0x20 > [Wed Dec 27 12:08:33 2023] ? sdev_evt_alloc+0xa0/0xa0 > [Wed Dec 27 12:08:33 2023] scst_process_redirect_cmd+0xd4/0x2e0 [scst] > [Wed Dec 27 12:08:33 2023] ? sdev_evt_alloc+0xa0/0xa0 > [Wed Dec 27 12:08:33 2023] scst_tgt_cmd_done+0x48/0x70 [scst] > [Wed Dec 27 12:08:33 2023] ? scsi_mq_done+0x27/0x70 > [Wed Dec 27 12:08:33 2023] scst_local_targ_xmit_response+0x64/0x220 > [scst_local] > [Wed Dec 27 12:08:33 2023] scst_process_active_cmd+0x891/0x2140 [scst] > [Wed Dec 27 12:08:33 2023] ? sgv_pool_alloc+0xab/0xa00 [scst] > [Wed Dec 27 12:08:33 2023] scst_process_redirect_cmd+0xd4/0x2e0 [scst] > [Wed Dec 27 12:08:33 2023] scst_cmd_done_local+0x80/0x110 [scst] > [Wed Dec 27 12:08:33 2023] dev_user_process_reply+0x597/0x1160 [scst_user] > [Wed Dec 27 12:08:33 2023] ? handle_pte_fault+0x20a/0x240 > [Wed Dec 27 12:08:33 2023] dev_user_ioctl+0x145/0xb23 [scst_user] > [Wed Dec 27 12:08:33 2023] __x64_sys_ioctl+0x95/0xd0 > [Wed Dec 27 12:08:33 2023] ? __x64_sys_ioctl+0x95/0xd0 > [Wed Dec 27 12:08:33 2023] do_syscall_64+0x5c/0xc0 > [Wed Dec 27 12:08:33 2023] ? do_user_addr_fault+0x1e7/0x670 > [Wed Dec 27 12:08:33 2023] ? exit_to_user_mode_prepare+0x37/0xb0 > [Wed Dec 27 12:08:33 2023] ? irqentry_exit_to_user_mode+0x17/0x20 > [Wed Dec 27 12:08:33 2023] ? irqentry_exit+0x1d/0x30 > [Wed Dec 27 12:08:33 2023] ? exc_page_fault+0x89/0x170 > [Wed Dec 27 12:08:33 2023] entry_SYSCALL_64_after_hwframe+0x62/0xcc > [Wed Dec 27 12:08:33 2023] RIP: 0033:0x7f031494075f > [Wed Dec 27 12:08:33 2023] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 > c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 > 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b > 04 25 28 00 > [Wed Dec 27 12:08:33 2023] RSP: 002b:00007f0314020d90 EFLAGS: 00000246 > ORIG_RAX: 0000000000000010 > [Wed Dec 27 12:08:33 2023] RAX: ffffffffffffffda RBX: 00007f0314021640 > RCX: 00007f031494075f > [Wed Dec 27 12:08:33 2023] RDX: 00005592aef75dc0 RSI: 0000000040387506 > RDI: 0000000000000004 > [Wed Dec 27 12:08:33 2023] RBP: 00007f0314020e10 R08: 00005592ad199dbb > R09: 00005592ad199dbb > [Wed Dec 27 12:08:33 2023] R10: 00005592ad199dbb R11: 0000000000000246 > R12: 00007f0314021640 > [Wed Dec 27 12:08:33 2023] R13: 0000000000000002 R14: 00007f03148ba7d0 > R15: 00007fff070557c0 > [Wed Dec 27 12:08:33 2023] </TASK> > [Wed Dec 27 12:08:33 2023] > ================================================================================ > [Wed Dec 27 12:08:33 2023] scsi 33:0:0:0: Sequential-Access IBM > 03592E07 3694 PQ: 0 ANSI: 6 > [Wed Dec 27 12:08:33 2023] [317]: scst_local: Configuring queue depth 64 > on sdev 000000007ddafb45 (tagged supported 0) > [Wed Dec 27 12:08:33 2023] scsi 33:0:0:0: Attached scsi generic sg2 type 1 > > The device does register and works properly. Further device > registrations do not trigger this trap. > > Rob > > > _______________________________________________ > 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 (https://github.com/SCST-project/scst/commit/be9d368361c6f302acde580e9914f14265bed2db) Thanks, Gleb |
From: Rob T. <ro...@rt...> - 2023-12-27 11:57:38
|
I'm porting my code to Ubuntu 22.04LTS. Fresh install scst v3.7 from here: https://github.com/SCST-project/scst/releases/download/v3.7/scst-3.7.zip Host: Ubuntu 22.04 Linux ub22inst 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Registering the first device results in a trap: [Wed Dec 27 12:08:33 2023] [834]: scst: Added device CTVTL_DRIVE11 to group iqn.2016-09.com.consolitape.ub22inst:vtl (LUN 0, flags 0x2) to target iqn.2016-09.com.consolitape.ub22inst:vtl [Wed Dec 27 12:08:33 2023] [834]: scst: Added device CTVTL_DRIVE11 to group local_target (LUN 0, flags 0x2) to target local_target [Wed Dec 27 12:08:33 2023] ================================================================================ [Wed Dec 27 12:08:33 2023] UBSAN: shift-out-of-bounds in /var/lib/dkms/scst/3.7.0/build/scst/src/scst_targ.c:3912:6 [Wed Dec 27 12:08:33 2023] shift exponent -1 is negative [Wed Dec 27 12:08:33 2023] CPU: 0 PID: 1062 Comm: ctdevice Tainted: G OE 5.15.0-91-generic #101-Ubuntu [Wed Dec 27 12:08:33 2023] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 [Wed Dec 27 12:08:33 2023] Call Trace: [Wed Dec 27 12:08:33 2023] <TASK> [Wed Dec 27 12:08:33 2023] show_stack+0x52/0x5c [Wed Dec 27 12:08:33 2023] dump_stack_lvl+0x4a/0x63 [Wed Dec 27 12:08:33 2023] dump_stack+0x10/0x16 [Wed Dec 27 12:08:33 2023] ubsan_epilogue+0x9/0x36 [Wed Dec 27 12:08:33 2023] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xef [Wed Dec 27 12:08:33 2023] ? ttwu_do_activate+0x82/0x100 [Wed Dec 27 12:08:33 2023] scst_process_active_cmd.cold+0xf/0x2d [scst] [Wed Dec 27 12:08:33 2023] ? sdev_evt_alloc+0xa0/0xa0 [Wed Dec 27 12:08:33 2023] ? wake_up_process+0x15/0x20 [Wed Dec 27 12:08:33 2023] ? sdev_evt_alloc+0xa0/0xa0 [Wed Dec 27 12:08:33 2023] scst_process_redirect_cmd+0xd4/0x2e0 [scst] [Wed Dec 27 12:08:33 2023] ? sdev_evt_alloc+0xa0/0xa0 [Wed Dec 27 12:08:33 2023] scst_tgt_cmd_done+0x48/0x70 [scst] [Wed Dec 27 12:08:33 2023] ? scsi_mq_done+0x27/0x70 [Wed Dec 27 12:08:33 2023] scst_local_targ_xmit_response+0x64/0x220 [scst_local] [Wed Dec 27 12:08:33 2023] scst_process_active_cmd+0x891/0x2140 [scst] [Wed Dec 27 12:08:33 2023] ? sgv_pool_alloc+0xab/0xa00 [scst] [Wed Dec 27 12:08:33 2023] scst_process_redirect_cmd+0xd4/0x2e0 [scst] [Wed Dec 27 12:08:33 2023] scst_cmd_done_local+0x80/0x110 [scst] [Wed Dec 27 12:08:33 2023] dev_user_process_reply+0x597/0x1160 [scst_user] [Wed Dec 27 12:08:33 2023] ? handle_pte_fault+0x20a/0x240 [Wed Dec 27 12:08:33 2023] dev_user_ioctl+0x145/0xb23 [scst_user] [Wed Dec 27 12:08:33 2023] __x64_sys_ioctl+0x95/0xd0 [Wed Dec 27 12:08:33 2023] ? __x64_sys_ioctl+0x95/0xd0 [Wed Dec 27 12:08:33 2023] do_syscall_64+0x5c/0xc0 [Wed Dec 27 12:08:33 2023] ? do_user_addr_fault+0x1e7/0x670 [Wed Dec 27 12:08:33 2023] ? exit_to_user_mode_prepare+0x37/0xb0 [Wed Dec 27 12:08:33 2023] ? irqentry_exit_to_user_mode+0x17/0x20 [Wed Dec 27 12:08:33 2023] ? irqentry_exit+0x1d/0x30 [Wed Dec 27 12:08:33 2023] ? exc_page_fault+0x89/0x170 [Wed Dec 27 12:08:33 2023] entry_SYSCALL_64_after_hwframe+0x62/0xcc [Wed Dec 27 12:08:33 2023] RIP: 0033:0x7f031494075f [Wed Dec 27 12:08:33 2023] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00 [Wed Dec 27 12:08:33 2023] RSP: 002b:00007f0314020d90 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [Wed Dec 27 12:08:33 2023] RAX: ffffffffffffffda RBX: 00007f0314021640 RCX: 00007f031494075f [Wed Dec 27 12:08:33 2023] RDX: 00005592aef75dc0 RSI: 0000000040387506 RDI: 0000000000000004 [Wed Dec 27 12:08:33 2023] RBP: 00007f0314020e10 R08: 00005592ad199dbb R09: 00005592ad199dbb [Wed Dec 27 12:08:33 2023] R10: 00005592ad199dbb R11: 0000000000000246 R12: 00007f0314021640 [Wed Dec 27 12:08:33 2023] R13: 0000000000000002 R14: 00007f03148ba7d0 R15: 00007fff070557c0 [Wed Dec 27 12:08:33 2023] </TASK> [Wed Dec 27 12:08:33 2023] ================================================================================ [Wed Dec 27 12:08:33 2023] scsi 33:0:0:0: Sequential-Access IBM 03592E07 3694 PQ: 0 ANSI: 6 [Wed Dec 27 12:08:33 2023] [317]: scst_local: Configuring queue depth 64 on sdev 000000007ddafb45 (tagged supported 0) [Wed Dec 27 12:08:33 2023] scsi 33:0:0:0: Attached scsi generic sg2 type 1 The device does register and works properly. Further device registrations do not trigger this trap. Rob |
From: Linux H. P. <in...@li...> - 2023-09-25 16:07:03
|
Hello, Can anyone look at Kirill’s message about allowing multiple iqns to access iscsi luns? It is relevant for us too. > Hello, I have a question about ini_groups. I want to deny access for all initiators except two or more. I created denied_inis and added those initiators via sysfs in accordance with the instructions from README. And as result, the first initiator has access to target but the second don't. I also got "Initiator iqn.2006-10.net.test:ini2 not allowed to connect to target" message from log for my second initiator. How can I deny all initiators except two or more? I will be grateful for any help you can provide. Best Regards. Kirill T Best wishes, Linux Hardware Project Team |
From: Кирилл Т. <cy...@ya...> - 2023-09-15 11:56:27
|
Hello, I have a question about ini_groups. I want to deny access for all initiators except two or more. I created denied_inis and added those initiators via sysfs in accordance with the instructions from README. And as result, the first initiator has access to target but the second don't. I also got "Initiator iqn.2006-10.net.test:ini2 not allowed to connect to target" message from log for my second initiator. How can I deny all initiators except two or more? I will be grateful for any help you can provide. Best Regards. Kirill T |