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. The controller: 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 usual. 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 circumstances. *** 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 32? 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.