|
Bugzilla – Full Text Bug Listing |
| Summary: | CCISS Driver for SCSI-raid not found | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Hans Witvliet <hwit> |
| Component: | Kernel | Assignee: | Hannes Reinecke <hare> |
| Status: | RESOLVED FIXED | QA Contact: | Klaus Kämpf <kkaempf> |
| Severity: | Blocker | ||
| Priority: | P5 - None | CC: | kgw |
| Version: | Beta 2 | ||
| Target Milestone: | --- | ||
| Hardware: | 64bit | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | Beta-NTS | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
requested: /var/log/boot.msg
as requested: output from dmesg 10.2 output from yast output of lcpci detailed output from lspci |
||
|
Description
Hans Witvliet
2005-08-29 07:29:07 UTC
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.. |