Bug 27627 - can't mount SCSI zip drive if no disk inserted during boot
can't mount SCSI zip drive if no disk inserted during boot
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-14 11:20 EST by Jay Berkenbilt
Modified: 2007-04-18 12:31 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-06 17:26:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Red Hat Bugzilla 2001-02-14 11:20:21 EST
I had earlier reported problems seeing my CDROM drive when it has SCSI ID 0
(see bug 25997).  Since then, I've been testing with the Rawhide kernel
(2.4.0-0.99.23) which has been overall working just fine.  However, I
noticed that I can no longer mount my SCSI zip drive (/dev/sda4).  This is
the only SCSI "hard drive" I have.  I also have a tape drive and CD-ROM
drive.  I can mount /dev/sda4 fine under the default Fisher kernel and
under RedHat 6.2, but not under 2.4.0-0.99.23.  Interestingly,
/proc/scsi/scsi and the boot process both see the zip drive, and fdisk -l
/dev/sda shows the sda4 partition.  Attempting to mount says that /dev/sda4
is an invalid block device.

My SCSI controller is an on-board AIC 7890.  I have an ASUS P2B-LS
motherboard
with this chip on-board.  The board's BIOS revision is 1012.  From
/etc/sysconfig/hwconf:

class: SCSI
bus: PCI
detached: 0
driver: aic7xxx
desc: "Adaptec|AHA-2940U2/W / 7890"
vendorId: 9005
deviceId: 001f
subVendorId: 9005
subDeviceId: 000f
pciType: 1

I know there are issues with new beta AIC7xxx drivers.  Do I need to be
concerned about this?  For now, I've gone back to the default Fisher kernel
recompiled with apm changes (from bug 26261) and everything works fine. 
(My CD-ROM drive is no longer on ID 0.)

There are no siginificant differences between dmesg output with these two
kernels.  (ACPI messages are not present in 0.99.23 since ACPI is turned
off, and the CPU speed differs by a few thousands...)
Comment 1 Red Hat Bugzilla 2001-02-14 11:39:28 EST
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.
Comment 2 Red Hat Bugzilla 2001-02-15 18:08:53 EST
We (Red Hat) should really try to resolve this before next release.
Comment 3 Red Hat Bugzilla 2001-02-15 19:18:53 EST
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.
Comment 4 Red Hat Bugzilla 2001-02-15 21:47:56 EST
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.
Comment 5 Red Hat Bugzilla 2001-02-16 12:53:51 EST
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.
Comment 6 Red Hat Bugzilla 2001-02-24 01:14:22 EST
I'm sorry to say that this bug has NOT been fixed in Wolverine.
Comment 7 Red Hat Bugzilla 2001-02-27 18:43:02 EST
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.
Comment 8 Red Hat Bugzilla 2001-02-28 10:49:03 EST
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.
Comment 9 Red Hat Bugzilla 2001-02-28 23:11:27 EST
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).
Comment 10 Red Hat Bugzilla 2001-03-01 00:30:53 EST
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!
Comment 11 Red Hat Bugzilla 2001-03-06 16:09:29 EST
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
Comment 12 Red Hat Bugzilla 2001-03-06 16:53:13 EST
Could you retry using the 2.4.2-0.1.19 kernel in rawhide and see if this problem
still exists?
Comment 13 Red Hat Bugzilla 2001-03-06 17:26:10 EST
This problem is fixed in the 2.4.2-0.1.19 kernel.
Comment 14 Red Hat Bugzilla 2001-03-07 03:42:23 EST
"This problem is fixed in the 2.4.2-0.1.19 kernel." -> Closing as fixed in
rawhide.

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