Description of problem: FC 22, was concidering going to FC 23, however, if the issue occurs on the 4.4 kernel on FC 23, this would preclude the upgrade. Problem: Booting onto 4.4 (and up) kernel qla1280 scsi_host does not show up. hornyaks@southpaw ~]$ lspci | grep -i qlogic 11:04.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 05) On the 4.3 kernel and 4.4 kernel both show up as devices. On 4.3 Kernel [hornyaks@southpaw scsi_host]$ pwd /sys/class/scsi_host [hornyaks@southpaw scsi_host]$ ls -l total 0 lrwxrwxrwx. 1 root root 0 Mar 24 09:38 host0 -> ../../devices/pci0000:00/0000:00:03.0/0000:01:00.0/0000:02:0e.0/host0/scsi_host/host0 lrwxrwxrwx. 1 root root 0 Mar 24 09:38 host1 -> ../../devices/pci0000:00/0000:00:06.0/0000:0e:00.2/0000:10:04.0/0000:11:04.0/host1/scsi_host/host1 On 4.4 kernel [hornyaks@southpaw scsi_host]$ pwd /sys/class/scsi_host [hornyaks@southpaw scsi_host]$ ls -l total 0 lrwxrwxrwx. 1 root root 0 Mar 24 09:38 host0 -> ../../devices/pci0000:00/0000:00:03.0/0000:01:00.0/0000:02:0e.0/host0/scsi_host/host0 When working correctly, we will see: [hornyaks@southpaw host1]$ cat proc_name qla1280 lsmod reveals this when working (4.3): [hornyaks@southpaw host1]$ lsmod | grep qla qla1280 32768 12 Not working (which I cannot adequately replicate at this Point in time). [hornyaks@southpaw host1]$ lsmod | grep qla qla1280 32768 0 Point being that the kernel module seems to load. Based on some investigation, I suspect the issue may relate to a udev scan and may be the same (or similar) to another bug report I may have seen. My work around is to stay on the latest known good. [hornyaks@southpaw host1]$ uname -r 4.3.6-201.fc22.x86_64 Version-Release number of selected component (if applicable): How reproducible: Every boot of 4.4 kernel and up. Steps to Reproduce: 1.Boot known non-working kernel 2.Look in /sys/class/scsi_host for scsi_host containing proc_name of qla1280, if non existant, then related scsi devices hanging of that card are not seen. 3. Actual results: No SCSI devices. Expected results: Lots of SCSI devices. Additional info: Tried to be relatively descriptive... Hope you have what you need.
4.4.6 Kernel was not an improvement. So far every 4.4 kernel has this bug.
Nothing changed in the driver itself between those two versions. Can you share dmesg for working and non-working versions? You can also try a bisect in parallel to identify a specific commit https://pagure.io/fedbisect
Created attachment 1147325 [details] dmesg working
Created attachment 1147353 [details] Not-Working dmesg
Agree do not believe any change in the module/driver has occurred. Uploaded both dmesg outputs. Produced with "dmesg | tee <filename>" Did not catch the bisect info. Will attempt as I have another chance. Attempt on non-working (assumed)? Realize that I do have to reboot a server class machine with its long POST to boot onto the kernel(s) that are not working. Will look for those scripts and see what happens. Stan
Please forgive ignorance... Not a big python user (Older school, shell/perl and a few others). Although the start script is just Bourne... [hornyaks@southpaw fedbisect]$ ./fedbisect.sh sync qla1280 kernel-4.4.6-201.fc22 4.3.6-201.fc22.x86_64 ~/temp/fedbisect/scripts ~/temp/fedbisect Traceback (most recent call last): File "./fedbisect-run.py", line 3, in <module> import bisect_state File "/home/hornyaks/temp/fedbisect/scripts/bisect_state.py", line 8, in <module> from git import Repo ImportError: No module named git Assume a Python module missing. loaded packages that made sense... python3-pygit2.x86_64, python-gitapi.noarch, & python-gitdb.x86_64 didn't make much difference
Nevermind, helps to read readme's sometimes.
*** This bug has been marked as a duplicate of bug 1319351 ***
SOrry about that, I thought it was the same issue as another driver but it looks like a similar issue but a fix on the same patch.
Can you test the scratch build at http://koji.fedoraproject.org/koji/taskinfo?taskID=13737100 ? This has a potential fix.
Sure going to plead a bit of ignorance here. Looks like a srpm Not a big deal, but not sure how to pull this package.
koji installed, just not sure of the syntax.
It's an SRPM because it's still building (sorry should have been more specific there). the x86_64 portion is now finished http://koji.fedoraproject.org/koji/taskinfo?taskID=13737103 Download kernel-4.4.8-200.rhbz1321033.fc22.x86_64.rpm kernel-core-4.4.8-200.rhbz1321033.fc22.x86_64.rpm and kernel-modules-4.4.8-200.rhbz1321033.fc22.x86_64.rpm and install those with 'dnf install <path to kernel.rpm> <path to kernel-core.rpm> <path to kernel-modules.rpm>'
Yea!!!! Yes, that means its working. Can usually tell right away, since one of the first thing the kernel does is go out an probe devices, so the attached SCSI disk pack lights up with some activity when the kernel module loads. [hornyaks@southpaw scsi_host]$ pwd /sys/class/scsi_host [hornyaks@southpaw scsi_host]$ ls -l total 0 lrwxrwxrwx. 1 root root 0 Apr 21 07:31 host0 -> ../../devices/pci0000:00/0000:00:06.0/0000:0e:00.2/0000:10:04.0/0000:11:04.0/host0/scsi_host/host0 lrwxrwxrwx. 1 root root 0 Apr 21 07:31 host1 -> ../../devices/pci0000:00/0000:00:03.0/0000:01:00.0/0000:02:0e.0/host1/scsi_host/host1 Shows up on host0 [hornyaks@southpaw host0]$ pwd /sys/class/scsi_host/host0 [hornyaks@southpaw host0]$ cat proc_name qla1280 [hornyaks@southpaw host0]$ lsmod | grep qla1280 qla1280 32768 12 Thanks, will eagerly await the official updated release, then possibly upgrade to fc23...
Issue comes back with the 4.4.9 kernel. Same symptoms Because the test kernel I had was a later version, I would not have seen any intervening kernels.
And goes away on the 4.4.11 kernel hopefully further kernels will include the fix. I'll wait for another release to be sure, then try the upgrade to FC 23.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.