Bugzilla – Bug 113749
CCISS Driver for SCSI-raid not found
Last modified: 2005-09-07 19:05:43 UTC
I presume hardware related are normally beyond the scope of the beta tests. However, in this case the hardware was recognized by elder releases and not recognized anymore (10.0 beta-1, beta-2, both 32/64) HARDWARE DESCRIPTION: System: HP-proliant (blade) DL360, 3Ghz Xeon-64, 2048MB mem CD/DVD on first primary IDE interface, hda Two 146GB ultra 320 SCSI disks connected via HP Smart Array 6i controller SYMPTOMS: After booting installationprograms (V1.9.8) starts up Routine questions are asked (language, agreement...) Finally you get an error message: ++++++++++++++++++++++++++++++++++++++ + No hardware disks were found for the installation + + Please check your hardware + ++++++++++++++++++++++++++++++++++++++ FURTHER ANALYSIS: 9.3: As said, the system normally runs Prof-9.3 9.3: (no special handling during installation required) 9.3: 9.3: The installer/yast had appended a kernel option for startup: 9.3: "resume=/dev/cciss/c0d0p1 9.3: lsmod showed the use of the module "cciss" 9.3: Root partition was mounted on /dev/cciss/c0d0p2 9.3: From messages i learned: 9.3: HPCISS driver v2.6.4 9.3: Device 0x46 found 9.3: CCISS: Using DAC cycles With this information, i tried again (10.0/b2-64) 10.0/b2: After booting from CD1, i provided same option: 10.0/b2: "resume=/dev/cciss/c0d0p1" 10.0/b2: 10.0/b2 This yielded the same results 10.0/b2 Manually trying: fdisk /dev/cciss/c0d0p2 10.0/b2 returned: unable to open 10.0/b2 Manually tried: "insmod ccis" without result Needles to say, before burning, md5's were checked. different sets of CDROMs were used, and test performed on three different blades. (Will re-test with 10.0-b3 asasp)
The resume option is added by the installation, and is needed for suspend/ resume to work properly. Please try to boot without this resume option, and append the boot log and dmesg to this report.
*** Bug 113948 has been marked as a duplicate of this bug. ***
Suggestions for original reporter: your system might have problems with PCI bus/HW ressources administration. The ACPI code which handles this isn't sufficiently reliable in many BIOSes. To narrow this down: - try booting the "Installation -- Safe settings" entry and see whether the SmartArray 6i now gets detected/the cciss module now loads successfully. - It also might be (depending on your particular hardware) that a kernel parameter like "acpi=off" is needed. - try booting SuSE Linux 10.0 beta3 There's a verified case here that *SL 10.0b3* properly loads cciss and detects a SmartArray 6i, so it can't be just the driver being unable to handle the hardware.
Created attachment 48378 [details] requested: /var/log/boot.msg after booting 10.2, no cmdline options
Created attachment 48379 [details] as requested: output from dmesg 10.2
Created attachment 48381 [details] output from yast as suggested tried: a) with no option during boot b) using "safe mode c) specifying acpi off No show, cciss driver not loaded (perhaps 64-bit specific?)
It appears as if your device has PCI Vendor/Device ID 0e11 0046 Sub-Vendor/Device ID 0e11 3201 0046 is PCI_DEVICE_ID_COMPAQ_CISSC. Looking at the device table in drivers/block/cciss.c, there are several entries for that device ID, but none of them has a matching sub-device ID. And indeed, the SA 6300 isn't listed in the supported hardware: MODULE_SUPPORTED_DEVICE("HP SA5i SA5i+ SA532 SA5300 SA5312 SA641 SA642 SA6400" " SA6i P600 P800 E400 E300"); Maybe we should ask HP about this
BTW I extracted these PCI IDs from the yast logs - do they agree with what lspci reports?
Side note for narrowing down purposes: the working SmartArray 6i mentioned in comment #4 turns out to be a different device. It gets reported by lspci as follows: 0000:04:03.0 RAID bus controller: Compaq Computer Corporation Smart Array 64xx (rev 01) Subsystem: Compaq Computer Corporation: Unknown device 4091 0000:04:03.0 Class 0104: 0e11:0046 (rev 01) Subsystem: 0e11:4091 So, once more, one needs to be truly detailed w.r.t device specification: "SmartArray 6i" isn't enough...
comment #9: YaST gets its data from hwinfo which in turn uses the same source as lspci, the /proc filesystem
I assumed as much. But I wanted to double check these values with the customer, because the numbers in the yast log are a) decimal, and b) seem to be offset by 65536, and c) buried in a 800-character line. So there's plenty of opportunity for me to get it wrong :-)
Does this still occur with Beta4?
Created attachment 48740 [details] output of lcpci As reuested, output of lspci. As you see, does not give away much more information Will try B4 today (previous attempt failed, because off bad media)
Sorry, I was a bit unspecific in my request. To obtain the PCI IDs of your device, call "lspci -s 0000:02:01.0 -nv". 0000:02:01.0 is the bus ID of your RAID array, as shown by the lspci output above.
Created attachment 48992 [details] detailed output from lspci Firstly, here the requested output. Secondly, raid controller is now recognized by 10.0/B4 Any changes? Investigate it further, or close it?
Just checked the "provides the needed information" box (assuming Hans did simply forget) to state-change the bug. Hans, hare, okir: do you agree?
I simply can't tell what may have caused the array to be recognized now. But I'm happy it's detected. Closing as fixed. Thanks, all!
Yes, i'm happy that it's solved and closed. Thanks for all the effort you all have put into it. Kind regard, back to hunting..