View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001102 | channel: elrepo/el8 | kmod-isci | public | 2021-06-02 13:31 | 2021-06-23 03:19 |
| Reporter | tgl | Assigned To | pperry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | x86_64 | OS | RHEL | OS Version | 8.4 |
| Summary | 0001102: Please update kmod-isci for RHEL 8.4 kernels | ||||
| Description | It's that time again ... the existing isci module is rejected by dracut for 8.4 kernels. | ||||
| Tags | No tags attached. | ||||
|
|
Please see https://elrepo.org/bugs/view.php?id=1093 We tried building kmod-isci for el8.3 but were unsuccessful due to failed module dependencies. The package has since been removed from the repository. |
|
|
I'm confused by that statement, because you previously built kmod-isci-1.2.0-6.el8_3.elrepo which was working just fine for me with 8.3 kernels, modulo having to explicitly tell dracut to include it. See previous thread at https://elrepo.org/bugs/view.php?id=1047 |
|
|
Hmm, sounds like we have had conflicting reports :-) I've updated and rebuilt against the RHEL 8.4 kernel for you, as: kmod-isci-1.2.0-7.el8_4.elrepo.x86_64.rpm Packages are uploaded to the testing repository, and should be available shortly. Please test with: yum --enablerepo=elrepo-testing update kmod-isci and reboot to your el8.4 kernel. Please can you let us know how you get on. Thanks |
|
|
Thanks for rebuilding! The new build does get included into initramfs, but the 4.18.0-305.3.1.el8_4.x86_64 kernel still doesn't work for me. I see a message flash by very quickly, to the effect of "Warning: firewire - this hardware is not supported for new deployments" and then things freeze up, much as if I didn't have the isci module installed. There is no firewire interface in this box, I'm pretty sure, so I wonder if something is being misidentified. 4.18.0-240.22.1.el8_3.x86_64 still works great for me with the previous version of kmod-isci. I saw the comments about the LTS kernel series in the other issue, and maybe I should just go that way, but I'm reluctant to abandon Red Hat's official kernel. |
|
|
Oh ... scratch that ... using the working kernel, I see $ dmesg| grep -i fire [ 3.567563] firewire_ohci 0000:0a:02.0: added OHCI v1.10 device as card 0, 4 IR + 8 IT contexts, quirks 0x2 [ 4.072116] firewire_core 0000:0a:02.0: created device fw0: GUID 003048000020f26f, S400 which is news to me but there it is. I wonder if that's interfering with the isci driver somehow? On the working kernel, the isci interface is identified first: ]$ dmesg| grep -i isci [ 3.501526] isci: loading out-of-tree module taints kernel. [ 3.501622] isci: module verification failed: signature and/or required key missing - tainting kernel [ 3.512384] isci: Intel(R) C600 SAS Controller Driver - version 1.2.0 [ 3.519018] isci 0000:05:00.0: driver configured for rev: 5 silicon [ 3.519032] isci 0000:05:00.0: OEM parameter table found in OROM [ 3.519035] isci 0000:05:00.0: OEM SAS parameters (version: 1.0) loaded (platform) [ 3.529283] isci 0000:05:00.0: SCU controller 0: phy 3-0 cables: {short, short, short, short} [ 3.531529] scsi host0: isci |
|
|
I see that Firewire warning flash up on my RHEL8.4 box too, so I wouldn't be too concerned about that and probably isn't related. Yes, we managed to fix the bug that was causing the module not to be in the initramfs, so I'm please to hear it is included this time. I assume you are not even able to boot into rescue mode and capture any errors from dmesg? I suspect you would see unknown symbol error(S) as reported in bug 1093. I'm not sure what more we can do if the latest kmod-isci module is not working for you. For something as fundamental as a scsi driver for the array from which you boot, I would try to go down a route that is better/fully supported as we are likely to encounter such issues for every point release. At present, our alternative kernel packages are the best solution we can offer you. |
|
|
Forgive my ignorance about such issues, but I'm not sure how to capture dmesg from a kernel that won't boot to working userland. I tried removing 'quiet' from the kernel command line and replacing it with 'rescue', and was rewarded to the extent of seeing messages flash by too quickly to follow. I tried videoing that, and I am able to spot that the isci module *is* loaded, along with the expected complaint that it taints the kernel. But I don't think I can spot where things are actually going bad, unless there's some way to get the dmesg text out of this environment. |
|
|
btw ... to clarify that: I can see that all the lines I quoted above from a successful 8.3 boot do show up in the video of 8.4's failure. So apparently things are going south after initial module load, but I don't know what to look for. |
|
|
I would like to start with a "Thank you!" for providing the kmod packages for the isci driver. I'm replying to this ticket because the el8_4 build of isci is causing a kernel panic when scsi_transport_sas is probing for devices on the Intel SCU bus. This was experienced with CentOS 8.4's "Linux version 4.18.0-305.3.1.el8.x86_64." The log of the serial console is attached below in the serial.txt file. Digging in, I see in the most recent changelog entry/section of the isci-kmod.spec from the src.rpm file: - Backported from kernel-4.18.20 I did a compare of stable v4.18.20 and https://vault.centos.org/8.4.2105/BaseOS/Source/SPackages/kernel-4.18.0-305.el8.src.rpm for the drivers/scsi/isci path and found the upstream vendor backported cc29a1b0a3f2597ce887d339222fa85b9307706d and 170b7d2de29e6239b8dbc63a88de1fa9789b0d8d to the 4.18.0-305.el8 release series for iscsi which isn't present in stable v4.18.20. https://github.com/torvalds/linux/commit/cc29a1b0a3f2597ce887d339222fa85b9307706d https://github.com/torvalds/linux/commit/170b7d2de29e6239b8dbc63a88de1fa9789b0d8d The original diff between the two is in the kmod-upstream.diff file. I replaced the source code in the isci-1.2.0.tar.gz file with the contents of kernel-4.18.0-305.el8.src.rpm:drivers/scsi/isci (keeping the Makefile from the original iscsi-1.2.0.tar.gz of course) and rebuilt the src.rpm. I installed the resultant kmod binary rpm package on the system experiencing the panic with ELRepo testing repo's kmod-isci-1.2.0-7.el8_4.elrepo.x86_64.rpm and the node came back without issue finding all the disks on the bus behind the Intel SCU. So I suspect cc29a1b0a3f2597ce887d339222fa85b9307706d is needed in the 4.18.0-305.el8 series. Is there any reason to not use the driver sources as included in the upstream vendor's kernel src.rpm for the kmod package build? Thanks again! serial.txt (5,413 bytes)
[ 0.000000] Linux version 4.18.0-305.3.1.el8.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 8.4.1 20200928 (Red Hat 8.4.1-1) (GCC)) #1 SMP Tue Jun 1 16:14:33 UTC 2021
<snip>
[ 6.932396] isci: loading out-of-tree module taints kernel.
[ 6.951093] isci: module verification failed: signature and/or required key missing - tainting kernel
[ 6.967149] isci: Intel(R) C600 SAS Controller Driver - version 1.2.0
<snip>
[ 7.049014] isci 0000:05:00.0: driver configured for rev: 6 silicon
[ 7.049023] resource sanity check: requesting [mem 0x000c8000-0x000d19ff], which spans more than PCI Bus 0000:00 [mem 0x000c8000-0x000cbfff window]
[ 7.049031] caller isci_request_oprom+0x2b/0x210 [isci] mapping multiple BARs
[ 7.049033] isci 0000:05:00.0: OEM parameter table found in OROM
[ 7.049036] isci 0000:05:00.0: OEM SAS parameters (version: 1.1) loaded (platform)
<snip>
[ 7.052065] isci 0000:05:00.0: SCU controller 0: phy 3-0 cables: {short, short, short, short}
[ 7.054476] scsi host6: isci
<snip>
[ 9.800047] ata7.00: ATA-8: ST91000640NS, SN03, max UDMA/133
[ 9.806486] ata7.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 32)
[ 9.814981] ata7.00: configured for UDMA/133
[ 9.830957] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
[ 9.839841] PGD 0 P4D 0
[ 9.842765] Oops: 0002 [#1] SMP PTI
[ 9.846749] CPU: 5 PID: 789 Comm: kworker/u272:1 Tainted: G OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1
[ 9.858949] Hardware name: Intel Corporation S2600JF/S2600JF, BIOS SE5C600.86B.02.06.0007.082420181029 08/24/2018
[ 9.870572] Workqueue: 0000:05:00.0_disco_q sas_discover_domain [libsas]
[ 9.878169] RIP: 0010:scsi_queue_rq+0x25a/0xa90
[ 9.883331] Code: 98 00 00 00 8b 92 28 01 00 00 48 8d 94 16 20 02 00 00 48 89 93 88 02 00 00 8b 88 50 02 00 00 85 c9 74 2c 48 8b 83 a0 02 00 00 <48> c7 00 00 00 00 00 48 c7 40 08 00 00 00 00 48 c7 40 10 00 00 00
[ 9.904480] RSP: 0018:ffffba9307cf39e8 EFLAGS: 00010202
[ 9.910418] RAX: 0000000000000000 RBX: ffff9f96bd82f010 RCX: 0000000000000007
[ 9.918495] RDX: ffff9f96bd82f358 RSI: ffff9f96bd82f138 RDI: ffff9f96bd82f138
[ 9.926579] RBP: ffff9f96be5f6000 R08: 0000000000000000 R09: ffff9f96bd82f170
[ 9.934656] R10: 0000000000000001 R11: 0000000000000024 R12: ffff9f967f5a4000
[ 9.942745] R13: ffff9f96be5f6000 R14: 0000000000000000 R15: ffffba9307cf3a98
[ 9.950821] FS: 0000000000000000(0000) GS:ffff9f971ed40000(0000) knlGS:0000000000000000
[ 9.960000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9.966512] CR2: 0000000000000000 CR3: 0000000aa8810006 CR4: 00000000000606e0
[ 9.974595] Call Trace:
[ 9.977436] blk_mq_dispatch_rq_list+0x11c/0x730
[ 9.982701] ? scsi_mq_init_request+0x3b/0xa0
[ 9.987669] ? __sbitmap_get_word+0x2a/0x80
[ 9.992441] ? schedule+0x61/0xa0
[ 9.996240] __blk_mq_sched_dispatch_requests+0xc6/0x170
[ 10.002276] blk_mq_sched_dispatch_requests+0x30/0x60
[ 10.008030] __blk_mq_run_hw_queue+0x51/0xd0
[ 10.012899] __blk_mq_delay_run_hw_queue+0x141/0x160
[ 10.018553] blk_mq_sched_insert_request+0xfc/0x1b0
[ 10.024109] ? bio_phys_segments+0x14/0x20
[ 10.028776] blk_execute_rq+0x4b/0xa0
[ 10.032964] __scsi_execute+0xeb/0x250
[ 10.037248] scsi_probe_and_add_lun+0x1a8/0xe50
[ 10.042417] __scsi_scan_target+0xa1/0x5d0
[ 10.047094] ? __pm_runtime_resume+0x54/0x70
[ 10.051963] scsi_scan_target+0xf6/0x100
[ 10.056444] sas_rphy_add+0x15f/0x1b0 [scsi_transport_sas]
[ 10.062684] sas_probe_devices+0xc8/0x12c [libsas]
[ 10.068137] sas_discover_domain.cold.16+0x9b/0x10a [libsas]
[ 10.074565] process_one_work+0x1a7/0x360
[ 10.079144] worker_thread+0x30/0x390
[ 10.083332] ? create_worker+0x1a0/0x1a0
[ 10.087811] kthread+0x116/0x130
[ 10.091514] ? kthread_flush_work_fn+0x10/0x10
[ 10.096577] ret_from_fork+0x35/0x40
[ 10.100668] Modules linked in: ib_qib(OE) isci(OE) rdmavt ib_uverbs igb libsas ahci crc32c_intel libahci scsi_transport_sas ib_core i2c_algo_bit libata dca dm_mirror dm_region_hash dm_log dm_mod
[ 10.120182] CR2: 0000000000000000
[ 10.124026] ---[ end trace 37471bd37d2a3e29 ]---
[ 10.132924] RIP: 0010:scsi_queue_rq+0x25a/0xa90
[ 10.138085] Code: 98 00 00 00 8b 92 28 01 00 00 48 8d 94 16 20 02 00 00 48 89 93 88 02 00 00 8b 88 50 02 00 00 85 c9 74 2c 48 8b 83 a0 02 00 00 <48> c7 00 00 00 00 00 48 c7 40 08 00 00 00 00 48 c7 40 10 00 00 00
[ 10.159234] RSP: 0018:ffffba9307cf39e8 EFLAGS: 00010202
[ 10.165171] RAX: 0000000000000000 RBX: ffff9f96bd82f010 RCX: 0000000000000007
[ 10.173247] RDX: ffff9f96bd82f358 RSI: ffff9f96bd82f138 RDI: ffff9f96bd82f138
[ 10.181324] RBP: ffff9f96be5f6000 R08: 0000000000000000 R09: ffff9f96bd82f170
[ 10.189401] R10: 0000000000000001 R11: 0000000000000024 R12: ffff9f967f5a4000
[ 10.197478] R13: ffff9f96be5f6000 R14: 0000000000000000 R15: ffffba9307cf3a98
[ 10.205554] FS: 0000000000000000(0000) GS:ffff9f971ed40000(0000) knlGS:0000000000000000
[ 10.214727] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 10.221248] CR2: 0000000000000000 CR3: 0000000aa8810006 CR4: 00000000000606e0
[ 10.229326] Kernel panic - not syncing: Fatal exception
[ 10.235343] Kernel Offset: 0x2a400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 10.250113] ---[ end Kernel panic - not syncing: Fatal exception ]---
kmod-upstream.diff (3,241 bytes)
diff -Nrpu /tmp/d/isci-1.2.0/init.c drivers/scsi/isci/init.c
--- /tmp/d/isci-1.2.0/init.c 2018-11-21 02:22:14.000000000 -0600
+++ drivers/scsi/isci/init.c 2021-06-22 15:53:39.671745869 -0500
@@ -588,6 +588,13 @@ static struct isci_host *isci_host_alloc
shost->max_lun = ~0;
shost->max_cmd_len = MAX_COMMAND_SIZE;
+ /* turn on DIF support */
+ scsi_host_set_prot(shost,
+ SHOST_DIF_TYPE1_PROTECTION |
+ SHOST_DIF_TYPE2_PROTECTION |
+ SHOST_DIF_TYPE3_PROTECTION);
+ scsi_host_set_guard(shost, SHOST_DIX_GUARD_CRC);
+
err = scsi_add_host(shost, &pdev->dev);
if (err)
goto err_shost;
@@ -675,13 +682,6 @@ static int isci_pci_probe(struct pci_dev
goto err_host_alloc;
}
pci_info->hosts[i] = h;
-
- /* turn on DIF support */
- scsi_host_set_prot(to_shost(h),
- SHOST_DIF_TYPE1_PROTECTION |
- SHOST_DIF_TYPE2_PROTECTION |
- SHOST_DIF_TYPE3_PROTECTION);
- scsi_host_set_guard(to_shost(h), SHOST_DIX_GUARD_CRC);
}
err = isci_setup_interrupts(pdev);
diff -Nrpu /tmp/d/isci-1.2.0/Makefile drivers/scsi/isci/Makefile
--- /tmp/d/isci-1.2.0/Makefile 2021-05-10 11:21:30.639849426 -0500
+++ drivers/scsi/isci/Makefile 2021-06-02 12:32:30.226027414 -0500
@@ -1,46 +1,9 @@
-# If KERNELRELEASE is defined, the make command using this Makefile has
-# been invoked by the kernel build system and so can use its language.
-# Otherwise, if KERNELRELEASE is null, a make command was issued from
-# the command line. So invoke the kernel build system.
-
-ifeq ($(KERNELRELEASE),)
-
- # KVERSION should be set in the environment if this
- # build is not for the currently running kernel.
- KVERSION ?= $(shell uname -r)
-
- # BUILD_DIR should be set in the environment if a
- # subdirectory of /lib/modules/ is not appropriate.
- BUILD_DIR ?= /lib/modules/${KVERSION}/build
-
- PWD := $(shell pwd)
-
-modules:
- $(MAKE) -C $(BUILD_DIR) M=$(PWD) modules
-
-modules_install:
- $(MAKE) -C $(BUILD_DIR) M=$(PWD) modules_install
-
-clean:
- rm -rf *~ *.o .*.cmd *.mod.c *.ko *.ko.unsigned .depend \
- .tmp_versions modules.order Module.symvers Module.markers
-
-.PHONY: modules modules_install clean
-
-else
-
-# Called from kernel build system -- just declare the module(s).
-
-# obj-m += scsi_transport_sas.o
-# obj-m += libsas/
-
-obj-m += isci.o
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_SCSI_ISCI) += isci.o
isci-objs := init.o phy.o request.o \
remote_device.o port.o \
host.o task.o probe_roms.o \
remote_node_context.o \
remote_node_table.o \
unsolicited_frame_control.o \
- port_config.o
-
-endif
+ port_config.o \
diff -Nrpu /tmp/d/isci-1.2.0/phy.c drivers/scsi/isci/phy.c
--- /tmp/d/isci-1.2.0/phy.c 2018-11-21 02:22:14.000000000 -0600
+++ drivers/scsi/isci/phy.c 2021-06-22 15:53:39.671745869 -0500
@@ -753,7 +753,6 @@ enum sci_status sci_phy_event_handler(st
default:
phy_event_warn(iphy, state, event_code);
return SCI_FAILURE;
- break;
}
return SCI_SUCCESS;
case SCI_PHY_SUB_AWAIT_IAF_UF:
@@ -957,7 +956,6 @@ enum sci_status sci_phy_event_handler(st
default:
phy_event_warn(iphy, state, event_code);
return SCI_FAILURE_INVALID_STATE;
- break;
}
return SCI_SUCCESS;
default:
|
|
|
Excellent, thank you for the feedback - that's really helpful. I've rebuilt kmod-isci-1.2.0-8.el8_4.elrepo.x86_64.rpm using the RHEL kernel-4.18.0-305.el8.x86_64 source code as you described. Packages are syncing to the testing repository and should be available on mirror sites shortly. I'd appreciate if you could give us feedback if the packages work for you. In answer to your question, we have a choice of sources for such kmod packages - either the kernel.org 4.18.20 sources or from the RHEL kernel SRPM, originally based off 4.18.0. In a case such as this, where the driver is completely disabled in the RHEL kernel, the assumption is that Red Hat would not bother backporting fixes to code for a driver which is disabled, not built, and not supported by Red Hat, hence the kernel.org 4.18.20 sources should in theory be newer. However, as you've demonstrated, that's not the case here so happy to switch to the RHEL kernel sources in this case. |
|
|
I verify that the newly built kmod works! # uname -r 4.18.0-305.3.1.el8.x86_64 # rpm -q --last kmod-isci kmod-isci-1.2.0-8.el8_4.elrepo.x86_64 Tue 22 Jun 2021 06:23:50 PM CDT # lsblk --scsi NAME HCTL TYPE VENDOR MODEL REV TRAN sda 6:0:0:0 disk ATA ST91000640NS SN03 sas sdb 6:0:1:0 disk ATA ST91000640NS SN03 sas sdc 6:0:2:0 disk ATA Samsung SSD 850 2B6Q sas sdd 6:0:3:0 disk ATA Samsung SSD 850 2B6Q sas # cat /sys/class/scsi_host/host6/proc_name isci # cat /sys/module/isci/srcversion 90C42F18E0CB6615D9F09F8 # modinfo isci filename: /lib/modules/4.18.0-305.3.1.el8.x86_64/weak-updates/isci/isci.ko firmware: isci/isci_firmware.bin license: Dual BSD/GPL version: 1.2.0 rhelversion: 8.4 srcversion: 90C42F18E0CB6615D9F09F8 alias: pci:v00008086d00001D6Asv*sd*bc*sc*i* alias: pci:v00008086d00001D68sv*sd*bc*sc*i* alias: pci:v00008086d00001D66sv*sd*bc*sc*i* alias: pci:v00008086d00001D64sv*sd*bc*sc*i* alias: pci:v00008086d00001D62sv*sd*bc*sc*i* alias: pci:v00008086d00001D60sv*sd*bc*sc*i* alias: pci:v00008086d00001D6Bsv*sd*bc*sc*i* alias: pci:v00008086d00001D69sv*sd*bc*sc*i* alias: pci:v00008086d00001D67sv*sd*bc*sc*i* alias: pci:v00008086d00001D65sv*sd*bc*sc*i* alias: pci:v00008086d00001D63sv*sd*bc*sc*i* alias: pci:v00008086d00001D61sv*sd*bc*sc*i* depends: libsas,scsi_transport_sas name: isci vermagic: 4.18.0-305.el8.x86_64 SMP mod_unload modversions sig_id: PKCS#7 signer: ELRepo.org Secure Boot Key sig_key: E9:D4:71:CF:B4:FE:13:6C sig_hashalgo: sha256 signature: 0D:FF:FA:79:15:90:D1:9C:01:90:B3:F3:38:FF:12:C9:25:F5:7B:8F: C5:30:C8:12:FF:1D:BB:CF:8E:5F:6C:D6:CD:B7:8C:62:9F:24:B2:F1: A9:F6:76:D7:85:39:89:32:CA:7A:9E:BC:1F:B6:B8:D0:AF:6E:8F:EC: 9E:EF:8E:5B:4E:1A:ED:A0:60:C0:BB:68:96:3D:80:D7:9E:A3:C7:EE: FB:71:45:26:02:E7:48:BA:1C:CD:7B:BC:48:EE:EE:67:97:E6:3D:A7: E1:02:A3:06:C3:0C:E4:7F:50:E8:4F:50:ED:F1:C0:27:0E:20:0E:5C: 6B:07:08:32:A1:74:F8:69:66:EB:F2:BB:77:22:70:2F:FE:69:C3:53: B2:1A:68:CF:66:94:98:56:46:4C:03:48:3F:6D:F3:7C:25:15:7A:B6: 94:7E:AC:E3:17:0C:3D:8C:BA:17:59:CF:C5:CF:B3:BF:C5:4A:99:1E: 27:53:E3:F3:61:EF:D7:9D:A0:C6:12:A4:1B:8B:91:B3:95:C4:A1:11: F8:82:B5:69:39:BB:9F:C9:6A:CE:CF:19:87:B5:B8:E0:9F:3D:3C:AC: 1C:2B:E1:E3:36:9B:CF:20:2E:B3:3E:BB:04:32:A5:B8:82:77:E9:CE: 10:81:D1:99:F8:8A:97:3B:1F:DB:2A:9F:5A:EE:26:20:D0:98:39:9C: 40:A5:49:B2:77:6D:85:DA:CD:67:3E:7D:9A:03:2F:29:BC:13:98:9B: 08:CF:98:0C:0F:29:26:CF:40:BA:29:9A:6F:0B:46:F0:E8:70:72:26: 7D:8A:E3:FE:C8:06:19:37:9E:AE:92:97:17:C2:84:8A:B0:09:1C:1D: 7A:68:3D:80:EE:00:D9:F0:3C:EB:D1:95:98:1A:4B:CD:5B:F6:31:4B: 04:FA:6C:B5:F4:A0:E5:5A:F8:37:AC:BC:D1:B8:5E:0C:84:76:2F:41: 74:67:E2:C2:9D:59:55:F5:8B:74:D1:DA:E2:B3:C7:E7:57:A9:C2:97: 9C:54:3B:4C:A7:8C:47:95:76:2C:2D:99:95:97:FB:02:B3:4B:00:38: 01:65:D2:9D:D5:B8:4A:1A:09:CA:54:AF:DC:7B:26:D2:AF:66:56:72: 66:AC:AF:F2:B9:92:AB:96:FE:AB:C0:41:7F:14:33:82:AA:08:00:9B: 9A:1E:8A:CC:12:67:7D:40:D4:7F:1F:13:AD:09:38:FE:6E:81:CB:E4: 53:3D:DE:1D:7B:9F:44:25:77:BA:94:93:75:D2:00:AB:66:EA:1D:ED: DF:E3:62:7A:74:2D:A6:98:06:4E:CF:E9:5D:C3:E2:4C:01:39:F6:71: 38:98:05:E1:EC:4A:85:B1:58:38:C2:DC parm: no_outbound_task_to:No Outbound Task Timeout (1us incr) (byte) parm: ssp_max_occ_to:SSP Max occupancy timeout (100us incr) (ushort) parm: stp_max_occ_to:STP Max occupancy timeout (100us incr) (ushort) parm: ssp_inactive_to:SSP inactivity timeout (100us incr) (ushort) parm: stp_inactive_to:STP inactivity timeout (100us incr) (ushort) parm: phy_gen:PHY generation (1: 1.5Gbps 2: 3.0Gbps 3: 6.0Gbps) (byte) parm: max_concurr_spinup:Max concurrent device spinup (byte) parm: cable_selection_override:This field indicates length of the SAS/SATA cable between host and device. If any bits > 15 are set (default) indicates "use platform defaults" (uint) # ls -l /lib/modules/4.18.0-305.3.1.el8.x86_64/weak-updates/isci/isci.ko lrwxrwxrwx 1 root root 53 Jun 22 18:28 /lib/modules/4.18.0-305.3.1.el8.x86_64/weak-updates/isci/isci.ko -> /lib/modules/4.18.0-305.el8.x86_64/extra/isci/isci.ko # rpm -qf /lib/modules/4.18.0-305.el8.x86_64/extra/isci/isci.ko kmod-isci-1.2.0-8.el8_4.elrepo.x86_64 Thank you for the super fast turnaround on this! |
|
|
Brilliant - Thank you for the feedback! I've promoted packages to the main repository. I'll build updated DUD iso images later for those wanting to install el8.4 boot devices. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2021-06-02 13:31 | tgl | New Issue | |
| 2021-06-02 13:31 | tgl | Status | new => assigned |
| 2021-06-02 13:31 | tgl | Assigned To | => toracat |
| 2021-06-02 14:00 | toracat | Relationship added | related to 0001047 |
| 2021-06-02 18:34 | toracat | Relationship added | related to 0001056 |
| 2021-06-02 18:37 | toracat | Relationship added | related to 0001093 |
| 2021-06-02 19:32 | pperry | Note Added: 0007647 | |
| 2021-06-02 20:08 | tgl | Note Added: 0007648 | |
| 2021-06-03 03:39 | pperry | Note Added: 0007651 | |
| 2021-06-03 03:40 | pperry | Status | assigned => feedback |
| 2021-06-03 11:06 | tgl | Note Added: 0007653 | |
| 2021-06-03 11:06 | tgl | Status | feedback => assigned |
| 2021-06-03 11:11 | tgl | Note Added: 0007654 | |
| 2021-06-03 11:35 | pperry | Note Added: 0007655 | |
| 2021-06-03 12:48 | tgl | Note Added: 0007656 | |
| 2021-06-03 12:53 | tgl | Note Added: 0007657 | |
| 2021-06-11 18:20 | toracat | Assigned To | toracat => pperry |
| 2021-06-22 17:19 | jser | Note Added: 0007689 | |
| 2021-06-22 17:19 | jser | File Added: serial.txt | |
| 2021-06-22 17:19 | jser | File Added: kmod-upstream.diff | |
| 2021-06-22 18:20 | pperry | Note Added: 0007690 | |
| 2021-06-22 18:21 | pperry | Note Edited: 0007690 | |
| 2021-06-22 18:21 | pperry | Assigned To | pperry => |
| 2021-06-22 18:22 | pperry | Assigned To | => pperry |
| 2021-06-22 18:22 | pperry | Status | assigned => feedback |
| 2021-06-22 19:55 | jser | Note Added: 0007691 | |
| 2021-06-23 03:19 | pperry | Note Added: 0007692 | |
| 2021-06-23 03:19 | pperry | Status | feedback => resolved |
| 2021-06-23 03:19 | pperry | Resolution | open => fixed |
