Bug 51859 - aic7xxx installer hang, 440BX chipset, onboard AIC-7890/1
aic7xxx installer hang, 440BX chipset, onboard AIC-7890/1
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Doug Ledford
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-15 19:07 EDT by Gordon Prioreschi
Modified: 2007-04-18 12:35 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-29 16:21:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Contents of /proc/pci under RH 6.0 (2.76 KB, text/plain)
2001-08-15 19:09 EDT, Gordon Prioreschi
no flags Details

  None (edit)
Description Gordon Prioreschi 2001-08-15 19:07:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (X11; I; Linux 2.2.5-15 i686)

Description of problem:
The 7.1 installer hangs loading the aic7xxx module

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Insert 7.1 installer CD
2. try to boot the installer

Actual Results:  The installer hangs loading the aic7xxx SCSI driver

Expected Results:  aic7xxx driver successfully loads and the install
continues

Additional info:

The 440GX boot disk did not work, as expected (didn't hurt to try).
I can't switch virtual consoles for some reason, so I can't tell if it's
the timeout loop or some other problem.
I'm attaching the contents of /proc/pci (the machine is currently running
RH 6.0). 
I can volunteer the machine for testing purposes (either net-attached or in
person) if it'd help.
Comment 1 Gordon Prioreschi 2001-08-15 19:09:03 EDT
Created attachment 28073 [details]
Contents of /proc/pci under RH 6.0
Comment 2 Gordon Prioreschi 2001-08-15 19:13:23 EDT
...apologies if this is a dup; it's getting kind of tough to tell.   :->
Comment 3 Gordon Prioreschi 2001-08-15 20:00:55 EDT
In case BIOS rev is significant, here's all the version information from the startup screen that seemed potentially significant:

Award Modular BIOS v4.51PG
...
ASUS P2B-D2 ACPI BIOS Revision 1011
...
Award Plug and Play BIOS Extension v1.0A
Comment 4 Doug Ledford 2001-08-23 19:00:18 EDT
Can you try using the new aic7xxx driver and see if that helps?  At the boot:
prompt, type "linux noprobe" (without the quotes of course) and then when
prompted for drivers, pick SCSI Driver and then find the new Adaptec SCSI driver
entry.  See if that helps things out.
Comment 5 Gordon Prioreschi 2001-08-27 14:02:54 EDT
Unfortunately, I'm not going to be in that office until Wednesday 8/29 or Thursday 8/30. 
I'll try the new driver then.
Comment 6 Gordon Prioreschi 2001-08-29 16:21:54 EDT
Behavior with aic7xxx_mod is different, but not much better. It turns out I can switch virtual consoles after aic7xxx_mod fails
to load; interesting excerpts from virtual console 4:

<6>PCI: Found IRQ 9 for device 00:04.2
<6>PCI: The same IRQ used for device 00:0d.1
... several lines of usb-related messages ...
<7>ISO 9660 Extensions: RRIP_1991A
<4>Unable to identify CD-ROM format.
<6>PCI: Found IRQ 10 for device 00:06.0
<6>PCI: The same IRQ used for device 00:0b.0
<4>scsi0: Someone reset channel A
<6>scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev. 6.1.7
<4>        <Adaptec aic7890/91 Ultra2 SCSI adapter>
<4>        aic7890/91: Wide Channel A, SCSI ID=7, 32/255 SCBs

after several seconds' pause, the console then loops with the message:

<4>scsi0: Someone reset channel A

scrolling by very quickly -- there doesn't seem to be a human-visible delay anywhere in the loop.

I included the PCI messages based on my reading of the other aic7xxx-related bugs in bugzilla. The second set of PCI-related
messages (regarding IRQ 10) occur just before the first SCSI-related message.

Nothing terribly interesting on virtual console 3; the only SCSI-related message appears to be the last one:

* going to insmod aic7xxx_mod.o (path is NULL)

It might help you to know that there aren't any devices connected to the onboard SCSI controller. Then why do I care about the 
driver, you ask? Well, 
I'm upgrading this workstation as a dry run for upgrading our server, which also has the 440BX chipset and *is* running SCSI-based. The 
server is a different SCSI card (AHA-2940UW PCI card instead of onboard device), but of course would use the same driver. I'm reluctant
to upgrade the server without completing a dry run on the workstation, but let me know if you have good reason to believe the 
slightly different hardware on the server would work.

Anyway, I decided to explore whether something about booting noprobe was what had allowed me to switch virtual consoles this time 
around, so I booted noprobe and fired up the original aic7xxx driver. I was able to switch virtual consoles for a second or two until the system 
went into a hard freeze (unable to switch consoles, cursor stopped blinking, ctrl-alt-del stopped working) -- which is different from the 
behavior under aic7xxx_mod, which never goes into such a hard freeze (at least, not in the first five minutes or so).

So... under the original aic7xxx, console #4 prints nothing SCSI-related -- not even a banner for the SCSI driver, *nor* does it print 
the second set of PCI-related messages. It looks just like the output for aic7xxx_new, except that it stops right after the line:

<4>Unable to identify CD-ROM format.

The output from virtual console 3 is no different, except of course that it insmods aic7xxx.o instead of aic7xxx_mod.o.


Let me know if there's anything else you need -- for instance, more info from the virtual console screens.

Thanks for your help!
Comment 7 Doug Ledford 2001-08-29 16:38:35 EDT
This is a hardware bug.  I'm closing this out as NOTABUG in the software.  The
problem you are having is because the SCSI bus is unterminated.  Your other
system might or might not have fully proper termination (you are suppossed to
have termination at both ends of the SCSI chain, it might be terminated only at
one end), but this system has no termination enabled (the Someone reset SCSI
channel A message means that there is no termination on the bus, the old driver
is going into an interrupt storm loop when this happens so the machine is locked
up, while the new driver doesn't allow a complete interrupt storm to take place,
but in both cases the system is more or less useless).  You need to either
enable termination on your motherboard SCSI controller (well, you need to enable
this termination regardless of anything else you do), plus if you do hook
anything up to it then you need to make sure that it is properly terminated as well.

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