Bug 466181
Summary: | F10b1 fails to see drives attached to a CCISS adapter | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul Moore <paul.moore> | ||||||||||
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | urgent | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | rawhide | CC: | adaora.onyia, bryan.stillwell, dchapman, kernel-maint, mike.miller, pertusus, richard, rick.hester | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | All | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2008-10-15 21:31:33 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: | |||||||||||||
Bug Depends On: | |||||||||||||
Bug Blocks: | 438944 | ||||||||||||
Attachments: |
|
Description
Paul Moore
2008-10-08 21:44:23 UTC
If you run lshal on tty1 once you're in the graphical environment, does it see the CCISS-attached devices? Created attachment 319889 [details]
Output from lshal
Created attachment 319890 [details]
Output from dmesg
I have no idea how to make sense of the lshal output so I've attached the captured output, as well as the output from dmesg, and attached them to this bug. Let me know if you need any more information. Disks aren't showing up in hal, therefore anaconda won't know they exist This appears to be specific to recent kernels. I took an F9 system and updated to the latest hal and it works OK. However then when I updated the kernel hal then only showed the cciss controllers and not the disks on that controller. Also does not appear to be fedora kernel specific. I have a RHEL5.2 ia64 system with a kernel built directly from Linus's git tree and it shows the same behavior. Not sure if this should be considered a kernel bug or not, it might be a valid change in behavior on the kernel side that needs to be reflected in hal? Probably not but I want to rule that out before reassigning this to kernel. cciss is notorious for moving things around in proc/sysfs and having to do adjustments to the probing code for it. For a long time, we were having to update anaconda/kudzu just about every release for something changing. I have narrowed this down to a specific git commit upstream: commit 6ae5ce8e8d4de666f31286808d2285aa6a50fa40 Author: Mike Miller <mike.miller> Date: Mon Aug 4 11:54:52 2008 +0200 cciss: remove redundant code Adding Mike Miller to the CC list for his input. Mike, It appears we no longer register all the information in sysfs. Some of the info that allows hal to find the disks isn't there in these recent kernels. This has the affect of anaconda and mkinitrd not knowing about cciss so we cannot install to or boot from cciss under Fedora. I will try to dig into this more deeply on monday. On the previous kernels (prior to the "remove redundant code" patch) we saw info about the cciss disks in 2 locations A generic block directory: /sys/block/cciss!c0d0 which is a symlink to /sys/devices/virtual/block/cciss!c0d0 and in a directory specific to that cciss card's PCI address: /sys/devices/pci0000:40/0000:40:13.0/0000:45:00.0/0000:46:08.0/block/cciss!c0d0 The latter (the pci one) is the one that hal uses. That directory is missing after the "remove redundant code" patch. That path exists up to this point: /sys/devices/pci0000:40/0000:40:13.0/0000:45:00.0/0000:46:08.0/ but it is missing the "block" directory. What appears to be happening here is we are creating disk kobjects that do not have the correct parent (parent is NULL). The parent was previously set via: cciss.c:3629 (in cciss_init_one) disk->driverfs_dev = &pdev->dev; which is then used later in register_disk to set the parent: fs/partitions/check.c:417 disk->dev.parent = disk->driverfs_dev; So, it seems the proper place for this is in the new cciss_add_disk function, however that does not have access to the pdev which was passed in to cciss_init_one. The parent ends up being NULL so in sysfs these disks show up as "virtual" disks and are not tied to the controller. i.e. they get created in sysfs under: /sys/devices/virtual/.... insead of where "real" devices should show up: /sys/devices/pci..../..../ Created attachment 320227 [details]
prevent orphaned cciss disks
Mike,
This fixes this issue. Can I send this upstream with a signed-off-by from you? I would like to get this upstream soon so we can be sure that cciss works for Fedora-10.
Doug, I just made this same patch yesterday and had it tested in Ft. Collins. I'll send my patch up today. -- mikem Created attachment 320340 [details]
Patch to fix orphaned disks and sysfs symlink
Doug,
This is identical to your patch. I've submitted it upstream.
Fixed in 2.6.27-15 |