Bug 470726 - aic7xxx/AHA-2940U2W not catch up initialize disks, following nash's mkblkdevs is ineffective
aic7xxx/AHA-2940U2W not catch up initialize disks, following nash's mkblkdevs...
Status: CLOSED DUPLICATE of bug 466607
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-09 11:08 EST by Frantisek Hanzlik
Modified: 2008-12-15 04:17 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-15 04:17:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Frantisek Hanzlik 2008-11-09 11:08:07 EST
Description of problem:
i686 system with AHA-2940U2W controller, 2x MAXTOR ATLAS10K4 wide-SCSI disks in SW RAID1 mode. Installation OK (release Nov-3-2008, kernel 2.6.27.4-68.fc10.i686, mkinitrd-6.0.69-1.fc10.i386), but system not booted, as system disks are not
on time detected in initrd. Update to 2.6.27.4-79.fc10.i686 and mkinitrd-6.0.70-1.fc10.i386 has no effect.
It seems aic7xxx driver needs some delay to successful disks init.
When I insert into initrd's init script 5 sec sleep (3 secs was too little)
between "modprobe aic7xxx" and subsequent "mkblkdevs", then all things
passed OK. I'm not sure about other, better solution (In man pages undocumented "mkblkdevs" nash command should be responsible for it?). My fix:

...
hotplug
echo Creating block device nodes.
mkblkdevs
echo "Loading raid1 module"
modprobe -q raid1
echo "Loading raid456 module"
modprobe -q raid456
echo "Loading scsi_transport_spi module"
modprobe -q scsi_transport_spi
echo "Loading aic7xxx module"
modprobe -q aic7xxx
sleep 5                                         +++++++++++ Added delay
mkblkdevs
mdadm -As --auto=yes --run /dev/md0
resume UUID=037453da-f356-4b39-a62d-0d894696a2df
...




Version-Release number of selected component (if applicable):
mkinitrd-6.0.69-1.fc10.i386, mkinitrd-6.0.70-1.fc10.i386

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Charlie Moschel 2008-11-09 14:34:48 EST
There are a number of bugs like this, in Fedora, and several filed under RHEL too.

You can add "MODULES=scsi_scan_wait" to /etc/sysconfig/mkinitrd.  This will load the module designed for this waiting, and you won't have to edit init by hand.

For (much) more background, see
bug #466071
bug #466607
bug #466534
Comment 2 Charlie Moschel 2008-11-09 14:49:13 EST
(In reply to comment #1)
> You can add "MODULES=scsi_scan_wait" to /etc/sysconfig/mkinitrd.  This will

Sorry, that should be MODULES=scsi_wait_scan
Comment 3 Frantisek Hanzlik 2008-11-13 17:41:37 EST
Yes, it's right solution. But if it was here some /etc/sysconfig/mkinitrd
template, life would be little lighter.
Many thanks.
Comment 4 Bug Zapper 2008-11-26 00:05:38 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Hans de Goede 2008-12-15 04:17:09 EST
This bug has already been reported, so I'm closing this as a dup of the earlier report. Note that I believe we have a fix for this available now, see the comments I'm about to add to bug 466607.

*** This bug has been marked as a duplicate of bug 466607 ***

Note You need to log in before you can comment on or make changes to this bug.