The module loads just fine, and appears to initialize the controller, and
the install starts. However, mke2fs hangs (I rebooted and ran it manually
at another VT, when anaconda froze up at "formatting /").
mke2fs hangs at "initializing 42/68 block" part (it counts from 1 to 42,
then hangs). There is some periodic disk activity, but no progress.
Abit BP-6 SMP motherboard, 256MB RAM.
00:0d.0 SCSI storage controller: Adaptec AHA-2940U2/W
Subsystem: Adaptec: Unknown device 2180
Flags: bus master, medium devsel, latency 32, IRQ 5
BIST result: 00
I/O ports at a400
Memory at ec000000 (64-bit, non-prefetchable)
Expansion ROM at ea000000 [disabled]
Capabilities: [dc] Power Management version 1
00:0d.0 Class 0100: 9005:0010
I cannot run the expert mode in order to load the other aic7xxx driver (Bug 30413).
Reinstalled RHL 7.0, tried running Wolverine in upgrade mode, in order to avoid
mke2fs. "Finding packages to upgrade" took about 20 minutes, much longer than
You could make a cup of coffee, while it was "transferring install image
to hard drive". It does look like the aic7xxx driver is "working",
somewhat, but not very well.
After transferring the install image, the installer spun its wheels for
about 15 minutes, with occasional disk activity. Suddenly there was a
flurry of disk activity, and the installer kicked in into high gear, with
the "Preparing to install" progress meter. The progress of that was
slower than usual, but not much slower.
It is now upgrading the 7.0 packages to Wolvering. It appears that the
upgrade is going at more or less normal speed. Stay tuned. Although the
aic7xxx driver is definitely fubared, it may be good enough to get
Wolverine loaded in upgrade mode.
Was there anything on tty4 about scsi timeouts? I was seeing lots of scsi
timeouts with 2.4.1-0.1.9 and an aic7xxx (see bug 29304) that was upgraded via
up2date from fisher -> wolverine which caused somewhat similar effects, but it's
fixed in more recent kernels.
No timeouts, but I'm marking this one as a dupe of 29767 anyway -- similar
*** This bug has been marked as a duplicate of 29767 ***
I'm not convinced that these are the same: in 29767 the driver is quite
definitely upset about things, but in 30414 we just have plain poor performance,
and in 2.4.2-0.1.19 and later builds we have corrected at least two separate
serious performance problems, one affecting all scsi drivers, the other lesser
one specific to aic7xxx (we're using better defaults for that driver now).
2.4.2-0.1.19 should show up in rawhide shortly, and should fix this.
If not, re-open this bug.
Is that the same kernel as in RC2? Does RC2's boot image use this kernel?
Yes, that's the RC2 kernel.
Partition formatting still hangs in the RC2 installer, for several minutes, with
occasional disk activity, before resuming. However, once the filesystem is
formatted, the install proceeds at regular speed.
During an rc2 install check the following things:
Are there SCSI timeout/reset messages in the kernel logs?
If you cat /proc/scsi/aic7xxx/0 and check the default tagged queue depth, is it
If the answer to the first is no and to the second yes, then I suspect this is
the VM issues we've been chasing (and which I can duplicate here on a machine
with 1GB RAM and no space, mke2fs will cause poor performance, I've made it
better somewhat by going to another terminal and running a while true; do sync;
sleep 1; done loop) and not an aic7xxx issue.
Where do the kernel messages go with the installer running? I think the kernel
messages just go out to the screen - if so, there are definitely no errors,
since nothing appears, answering half this question.
This machine has 256MB RAM, and I was formatting the entire 9 gig disk.
Will check the tagged queue depth...
Confirmed - Default Tagged Queue Depth was 32, no errors.
This is very likely the vm bugs then, not an aic7xxx bug. It should be much
better in the latest ISOs (0328 and later). Please reopen if it isn't.