Bug 44109 - Installer hangs & crashes with aic7xxx module
Summary: Installer hangs & crashes with aic7xxx module
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-06-11 13:42 UTC by Andrew G. Lowery
Modified: 2007-04-18 16:33 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2001-07-06 16:02:02 UTC

Attachments (Terms of Use)

Description Andrew G. Lowery 2001-06-11 13:42:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
When installing RedHat Linux 7.1 using expert mode and choosing the 
aic7xxx module, the installer crashes transferring the image to the 
harddisk. I recieve an error signal 11.

If I choose the experimental aic7xxx module doing an expert install, the 
install hangs when doing the image transfer.

I am using an Adaptec uh2940 on an x86 platform. Mandrake 8.0 & RedHat 7.0 
will install fine. RedHat 7.1 will not install.

How reproducible:

Steps to Reproduce:
1.Install RedHat 7.1
2.Chose Expert Mode
3.Pick either the default aic7xxx or experimentatl aic7xxx module.

Actual Results:  Install crashes with signal 11 error message or just 
hangs indefinitely.

Expected Results:  I should be able to install RedHat 7.1 without any 

Additional info:

Comment 1 Brent Fox 2001-06-11 22:46:00 UTC
Kernel problem.  Reassigning.

Comment 2 Andrew G. Lowery 2001-06-12 01:50:03 UTC
After reading a recommendation at www.mandrake.com on adaptec issues, I upgraded
the BIOS (firmware) on my Adaptec 2940UW SCSI controller from version 1.25 to
version 2.20. I was then able to install RedHat 7.1 and run it with no issues.

In short, It appears that the Adaptec module AIC7xxx was updated to keep up with
firmware changes on the Adaptec cards. If you have an old SCSI BIOS (firmware)
revision on your SCSI card, you will have problems using the new updated Adaptec
driver included in RedHat 7.1.


Comment 3 Need Real Name 2001-06-25 16:46:09 UTC
I am experiencing similar problems on a FIC VA-503+ K6-3/450.  I have a 
ST34501W and a XM-6201 CD.  The problems started as a hang on boot after 
upgrading the kernel from 2.2.19 to 2.4.[123].  Contact with the aic7xxx 
maintainer and several driver versions provided no change in the symptoms, 
which were a complete system hang (no KB, hard reset required) after the 
xxx instructions downloaded message.  

Subsequently, I tried a Redhat 7.1 install which hung when the 'loading 
aic7xxx driver' message displayed.  A hard reset was required, KB did not 
work.  I plan to disable wide negotiation and try an upgrade to bios 2.20.

Comment 4 Need Real Name 2001-06-26 00:30:08 UTC
I tried disabling wide negotation as mentioned in a Usenet article
with no effect on the hang. I also upgraded the adapter BIOS to
2.20 with no effect. The AHA-2940UW has been tried in all three
PCI slots and in combination with the other PCI cards (Matrox Mil2
and 3Com 3c905cx-tx). This board uses a MVP3 chipset and is set to
'non PNP OS'.

This bug should have the severity adjusted to high and the priority
set to high also, IMHO. What should be done to try and resolve the

Comment 5 Carl R. Hughes 2001-07-05 13:10:01 UTC
I have been experiencing the same problem with the aic7xx driver load locking 
durring install of Red Hat 7.1.  I have an Adaptec AHA-2940 with SCSI BIOS 
level v1.32.  I call Adaptec and they informed me that the original AHA-2940 
would not be supported, but that the AHA-2940 Ultra Kit, or the 29160N SCSI 
controllers would support the Linux 7.1 install.

Is there a way to use the old drive with the new kernel?  I would rather not 
have to spend $275.00 for a new controller.

Comment 6 Need Real Name 2001-07-06 16:01:59 UTC
Does anyone have any comments on why the older AHA2940UWs would not
be supported while the units with the Wide-Narrow bridge would be?

This is looking more and more like what has been described as a PCI
routing problem. I have tried kernels 2.4.5 and 2.4.6 and see this as the
last two messages:
SCSI system driver: ......
PCI: Assigned IRQ5 for device 00:0A:0

and then the system is hung - no keyboard - big red switch time.
I have tried UP build kernels, with/without IOAPIC. Also, BIOS/direct settings for PCI
inquiry. Same results.  RH70 runs fine on 2.2.17 with the 3c59x driver updates.

When trying to boot with 2.2.16-22 (RH71), I see things like:
PCI: Found IRQ 5 for device 00:07:2
IRQ routing conflict in pirq table for device 00:07:2
usb-uhci.c: USB UHCI at I/O 0xe000 IRQ 11
eth0: scatter/gather enabled. h/w checksums enabled.

Then it hangs, displaying 'Loading AIC7xxx driver' on virtual screen 1

I see there are some fixes in this area in the ac tree and will try 2.4.5-ac24 for fun.

Is anyone actively working this issue?

Comment 7 Doug Ledford 2001-08-23 23:29:55 UTC
First, this bug is being closed.  The original problem as reported by aglowery
was resolved by the third comment.  The second problem, reported by edt is not
related to the first problem (and it does indeed look like an interrupt routing
problem, and I would be looking for an updated BIOS for your motherboard to
solve the PIRQ routing table conflict, and I'm sure the reason that compiling a
UP kernel with IOAPIC support didn't solve your problem is that your motherboard
isn't an SMP motherboard, doesn't have an IOAPIC, and therefore we can't find
and use an MP interrupt routing table instead of the PIRQ table, and since we
can't find the MP table, we fall back to PIRQ routing anyway, so the UP-IOAPIC
option is useless to you).  But, since edt's problem isn't the same as the
original, it doesn't belong on this bug report and I'm not going to hold this
one open for it.  The third problem reported by chughes1 sounds like the problem
aglowery had, and a BIOS updated on the 2940UW might very well solve the
problem.  Until chughes1 has done that, we won't know.  If an Adaptec BIOS
update doesn't solve your problem chughes1, then please open a new bug report.

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