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...)
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.