Bug 127434
Summary: | Kernel not detecting multiple LUNs on SCSI aic7xxx | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | D. Cross <crossd> | ||||
Component: | kernel | Assignee: | Dave Jones <davej> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 2 | CC: | barryn, david_kewley, edoutreleau, jason.casey, pfrields, wtogami | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i686 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-04-16 06:05:28 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
D. Cross
2004-07-08 05:23:35 UTC
Created attachment 101711 [details]
dmesg output
In the dmesg included, it looks like the driver is misinterpreting data
relating the LUNs. Instead of reporting small integers like the 0 and 1 as I
would expect, it has these huge hex numbers associated with it. See below.
Just so you know, for a 2.6 kernel you need to edit /etc/modprobe.conf not /etc/modules.conf. Thank you for your response. I had to drop my system back down to Fedora Core 1, which is working. I actually did try both the /etc/modprobe.conf and the /etc/modules.conf with no success in either case. My understanding was that the custom kernel build with Multiple LUN support added, would not require the either one of those files. However, I believe I built the custom kernel with the entries also. Even though we are back to Fedora Core 1, we would still like to get this resolved. The only problem is that right now I don't have a test system to experiment. I could possibly get our vendor contact to try a few things if you believe you have a potential solution. There are newer test kernels available from the following places: + rawhide (a.k.a. fc-devel) + FC3 test 1 + http://people.redhat.com/arjanv/2.6 You could try one of these newer kernels and see if it's something that's been fixed upstream (and therefore in these kernels). (My experience is that it's actually possible to use these kernels on FC1 much of the time, so you may be able to test without having to upgrade your system to FC2.) I don't know how likely this is to fix your problem, however. The only other suggestion I have is to try asking on the linux-scsi mailing list. My apologees. I thought I had included it in my original attachment that I had also tried additional kernels of version 2.6.7-X with no additional success there either. Thanks for the direction on the linux-scsi list. I had tried another list with not much response as of yet. A vendor contact has informed me that in their testing, this is apparently a kernel 2.6.X problem, and not specific to the adaptec drivers. The large hexadecimal LUN numbers noted in the dmesg output show up even with a single LUN, if the raid size is greater than about 1 TB. They have also observed this behavior with cards other than adaptec. I think this is related to using REPORT_LUNS, rather than sequential scanning, where the REPORT_LUNS response is getting mis-read. The kernel will fall back to sequential scanning if REPORT_LUNS fails (see scsi_scan.c), but it doesn't see the huge LUN values as errors. The REPORT_LUNS bug should be fixed, but there should probably be a kernel option to force sequential scanning. I'm having this problem on FC3. I will try disabling REPORT_LUNS in the source, and see if LUN 1 becomes available. Workaround: Hey, I figured out that you can manually scan individual LUNs via /procfs with: echo scsi add-single-device HOST CHANNEL ID LUN >/proc/scsi/scsi For example, this gets my disk back online: echo scsi add-single-device 1 0 8 1 >/proc/scsi/scsi any improvements with the latest updates ? As an additional datapoint, I see the same-appearing error on a box with the following specs: RHEL 4AS kernel 2.6.9-5.0.3.ELsmp x86_64 two 3ware 9500S-12MI cards 24x 400GB disks attached to 3ware cards latest 3w-9xxx driver from 3ware website dual Xeon EM64T 4GB RAM In my case, I only have one LUN per SCSI ID, one SCSI ID per 400GB disk, and the real LUN is seen fine, so I have no problems using my disks. Is there anything else I can give you to help track this down? Fedora Core 2 has now reached end of life, and no further updates will be provided by Red Hat. The Fedora legacy project will be producing further kernel updates for security problems only. If this bug has not been fixed in the latest Fedora Core 2 update kernel, please try to reproduce it under Fedora Core 3, and reopen if necessary, changing the product version accordingly. Thank you. |