Hide Forgot
Description of problem: cpqarray module fails to detect arrays Version-Release number of selected component (if applicable): 2.6.17-1.2519.4.21.el5 How reproducible: every time Steps to Reproduce: 1. load sym53c8xx module before cpqarray module Actual results: Disks are not found Expected results: Disks should be found Additional info: linux-scsi thread here http://marc.theaimsgroup.com/?l=linux-scsi&m=115591706804045&w=2 upstream kernel patch here http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=b2b3c121076961333977f485f0d54c22121df920
Created attachment 135808 [details] upstream patch from scsi-rc-fixes
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
(In reply to comment #2) > Straight-forward fix is upstream. We should include it in 5.0. Sadly, the straight-forward fix is already in 5.0, and yet the bug persists. Chip
*** This bug has been marked as a duplicate of 205807 ***
Hi Mike, I'm moving our discussion of the cpqarray problem from bug 205807, which really does seem to be fixed by the upstream patch, to this bug (205653), which is the one I originally reported. I've done some more debugging. I dumped the entire cmdlist_t that is being sent via sendcmd in cpqarray on both RHEL-4 and RHEL-5. One thing I noticed is that one RHEL-4 (which works), the cmdlist->req.sg[0].addr value is block (512 byte) aligned, but it is not on RHEL-5 (probably due to a color offset in the underlying slab cache). Could this be a problem? Chip
# lspci -xxx -s 00:0e.0 00:0e.0 RAID bus controller: LSI Logic / Symbios Logic 53C1510 (rev 01) 00: 00 10 10 00 53 01 10 02 01 00 04 01 08 c0 00 00 10: 01 24 00 00 00 00 00 f6 00 00 00 f5 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 11 0e 40 40 30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 1e 08 40: 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 vendor_id: 0x1000 (PCI_VENDOR_ID_NCR or PCI_VENDOR_ID_LSI_LOGIC) device_id: 0x0010 (PCI_DEVICE_ID_NCR_53C1510) command: 0x0153 (PCI_COMMAND_SERR | PCI_COMMAND_PARITY | PCI_COMMAND_INVALIDATE | PCI_COMMAND_MEMORY | PCI_COMMAND_IO) status: 0x0210 (PCI_STATUS_DEVSEL_MEDIUM | PCI_STATUS_CAP_LIST) class_revision: 0x01040001 (PCI_CLASS_STORAGE_RAID << 8 | 0x01)
The "command" configuration register (0x0153) indicates that the device is not configured as a bus master. On the identical system where cpqarray works fine, the device does come up as a bus master (command == 0x0157). I wonder if that's significant.
Created attachment 137940 [details] make the device a PCI bus master; fixes the bug
Requesting an exception on the grounds of low impact (the change is only to a very old and rarely used storage controller) and low risk (it's only a one line patch). We have a couple of lab machines with this storage controller; it would be nice if we could run RHEL5 on them. Chip
QE ack for RHEL5.
Created attachment 138134 [details] Fix for bug#205653
in kernel-2.6.18-1.2725.el5
if the change from comment #13 is also needed, it should also get pushed upstream. I don't see it in 2.6.19rc6 (It also doesn't seem to be in RHEL5 CVS from what I can tell)
(In reply to comment #15) > if the change from comment #13 is also needed, it should also get pushed > upstream. I don't see it in 2.6.19rc6 It's pretty clear that if the one in comment #1 is needed, then the one in comment #13 must also be needed. Apparently LSI logic and NCR were using different PCI device ids for the same device (even though the vendor ids are the same). I'll submit to rh-kernel list for RHEL-5. Chip
A package has been built which should help the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you.
(In reply to comment #15) > if the change from comment #13 is also needed, it should also get pushed > upstream. I don't see it in 2.6.19rc6 > > (It also doesn't seem to be in RHEL5 CVS from what I can tell) > http://marc.theaimsgroup.com/?l=linux-scsi&m=116483396211563&w=2