Red Hat Bugzilla – Bug 152660
Installer Take Inordinate Amount of Time to Detect Boot Drives on SCSI Channel B of Aic7899 Controller on Tyan Thunder K7 (2462) Motherboard
Last modified: 2015-01-04 17:18:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0
Description of problem:
The system is a Tyan Thunder K7 (2462) motherboard with the latest v2.14 BIOS.
The installer seems to hang when after loading the Aic7xxx module. But after about 20-25 minutes of inactivity, it finally starts scanning each device on each channel of the controller. Because Channel B is the preferred boot channel on the 7899 Ultra160 controller, the whole process takes better than a half hour to actually find the drives, leading the user to assume that the system has either hung or that the SCSI controller has timed out.
The system being tested has no devices on Channel A. This seems to be a holdover problem from FC2 and FC3. FC1 has no problems.
I booted with "Linux nousb acpi=off noapic" as the installer also seems to hang trying to identify or communicate with the installed USB controllers. ACPI has been disabled in the mobo BIOS. The system is booting from an IDE CD-ROM drive.
While I have put this bug in the "Normal" catagory, I suspect that it has led many users to assume that the product could not be installed on their hardware.
A boot option to select the primary SCSI Channel might be helpful in this case.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install from CD.
2. Respond to all prompts as usual.
Actual Results: Eventually the system responded and I was offered the Install options screen and given the opportunity to upgrade from the existing FC1 installation. I did not proceed further as I will now try an FC3 upgrade (which I had previously assumed was broken because of this problem). I will report further regarding that install.
Expected Results: With the Fedora Core 1 (and previous Redhat versions) the drives were relatively immediately found and the install proceeded as normal. There were no extended pauses as in the cases of all FC2-FC4t1 attempts.
What driver are you trying to load? (What is the kernel module called?)
I am having the such a problem while I try to install redhat enterprise WS
version 4 on an IBM Intellistation 6850-25G which have Aic7899 Controller.
At the first stage of the installation, it searches the aic7xxx driver and gets
I didn't wait 30 minutes, I was sure that something was wrong. I will try to
wait and see if it ends.
Typing on ALT-F4 I see that it finds the correct Adaptec AIC-7899 scsi
controller, but then it gets stuck.
I also tryed to boot with noprobe, but than choosing the aic7xxx driver, it got
Is it possible to get the scsi driver image so I will load it from a disk ?
Dr. Amihai Silverman
"I also tryed to boot with noprobe, but than choosing the aic7xxx driver, it got
This is not likely to have any effect, except as you've already noticed.
"Is it possible to get the scsi driver image so I will load it from a disk ?"
I don't know what this will buy you. It is not a problem related to accessing
the driver, it is a problem related to the SCSI card itself. I suspect that
it has more to do with the way the card is being told to behave by the kernel.
I have repeated my tests several times. The period before I get any
on-screen response from the installer is always ~25 minutes. Up until this
point, the HDD activity light on the box repeats a blinking pattern
at regular intervals.
There are no further problems once the install gets past the initial barrier.
Best Regards, David Allen.
(In reply to comment #1)
> What driver are you trying to load? (What is the kernel module called?)
The problem occurs using the standard distro-supplied aic7xxx driver. Like I
said, it eventually resolves itself. It just takes nearly half an hour to do so.
Googling dug up info from others that 'insmod'ing an i2o driver instead of using
the aic7xxx module would cure the problem. But I found that after extracting the
driver module from the kernel and putting it where it could loaded (floppy or
installer's RAM disk, on HDD), neither insmod nor modprobe (both linked to the
same binary in the installer's path) would touch the module. Probably something
I did wrong.
Mass update of -test bugs to update version to fc4.
(Please retest on final release, and report results if you have not already done
I'm a bit afraid to do this because ... well, see Bug 167791.
All 2.6.12 kernels fail to complete a boot on this motherboard (Tyan K7 2462).
This is a working machine right now, albeit still running the 2.6.11 kernel, so
I am reluctant to try moving it to FC4. However, I can try the final release of
FC4 just far enough to see if this bug still exists.
My experience with this particular motherboard is that as the kernel is
"improved", SCSI support degrades.
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.
This is a mass-update to all currently open kernel bugs.
A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.
Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.
This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.
Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
Closing per previous comment.