Bug 27627

If I'm reading my logs right, you have the choice of the
aic7xxx and aic7xxx_old drivers.  Try the aic7xxx_old
driver and see if it works.

In our current source tree, we have the original aic7xxx
as the aic7xxx driver, the new one as aic7xxx_new, and the
original one has a few bug fixes.  So when we come out with
a new kernel package, please do test it and make sure that
it fixes the problem.

We (Red Hat) should really try to resolve this before next release.

I have a little more information.  My original report was slightly inaccurate. 
The actual situation is that you can't mount the zip drive if no disk was
inserted during the boot process.  The same modules are present in both cases
and fdisk -l /dev/sda works in both cases, but if no disk was inserted while the
system booted, you get an error that /dev/sda4 is not a valid block device. 
This problem occurs with both the stock Fisher kernel and the Rawhide kernel. 
It does not happen with an unpatched 2.4.1 kernel which seems to use a different
aic7xxx driver from RedHat's kernel.  Unloading and reloading the aic7xxx and
sd_mod modules didn't help.

OK, please try it with the 2.4.1-0.1.9 or later kernel when it gets
to rawhide -- that should be in sync with the latest -ac releases in
terms of what aic7xxx driver it is using.  Thanks.

I'd like to try with that kernel.  Is there a way I can know when it is
available other than continually checking rawhide?  I'm also waiting for the new
kernel to do some iptables testing.

I'm sorry to say that this bug has NOT been fixed in Wolverine.

Rawhide has a more recent kernel.

Is this a regression relative to the 2.2 kernel?
I know that some people find that the boot hangs if they
do not have a disk inserted, and we're trying to fix that,
but I'm not sure it's related.

You could try
echo "scsi add-single-device C B T U > /proc/scsi/scsi"
where C is controller number, B is bus number, T is target
(your zip disk) SCSI id, and U is your target lun (probably
0) to see if that helps.

Alan reports known regressions regarding removeable devices
fixed in the source code we are building for the next rawhide.
2.4.2-0.1.16 or later will have his known regressions fixed
and be worth testing when it appears in rawhide.

echo "scsi add-single-device 0 0 6 0" > /proc/scsi/scsi

didn't work, but I'm not surprised since /proc/scsi/scsi already showed the zip
drive and fdisk -l /dev/sda already worked.  However, this made me think of
something else which actually did work.  After running the following C code:

#include <sys/types.h>
#include <linux/fs.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>

int main()
{
    int fd = open("/dev/sda", O_RDWR);
    if (fd == -1)
    {
	fprintf(stderr, "open device: %s\n", strerror(errno));
	exit(2);
    }
    if (ioctl(fd, BLKRRPART, 0) == -1)
    {
	fprintf(stderr, "ioctl BLKRRPART: %s\n", strerror(errno));
	exit(2);
    }
    return 0;
}

to force the system to reread the partition table (or running fdisk /dev/sda and
hitting "w"), it was possible to mount /dev/sda4.  I guess the kernel tries
(unsuccessfully) to read the partion table at boot time and then forgets to
reread it later when things change.

Another piece of evidence that supports this is that if you eject this disk and
insert another with a different partition table, you can't mount partitions on
the new disk that didn't exist on the old disk until after you run the above
program.

It would be unsurprising if the removable device fixes will be in the kernel you
mentioned since it looks from a casual perusal of the ac patches that 2.4.2-ac4
has code that rechecks the partition table of removable disks after it notices
that they have been changed....  Anyway, I'll retest when a new kernel makes it
to rawhide (and I notice it or see something about it here or on the wolverine
list).

Arjan, can you please double-check that those fixes went into
2.4.2-0.1.16?  If not, please put them in place for the next
build.  Thanks!

I can't reproduce this using the aic7xxx driver from kernel-2.4.2-0.1.19. 
Everything mis seen and works fine on bootup. This is with an 2930U2 
controller.

Tim

Could you retry using the 2.4.2-0.1.19 kernel in rawhide and see if this problem
still exists?

This problem is fixed in the 2.4.2-0.1.19 kernel.

"This problem is fixed in the 2.4.2-0.1.19 kernel." -> Closing as fixed in
rawhide.