From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124 Description of problem: System has 2 CPUs, AMD Opteron 248, TYAN Thunder K8W (S2885), total 4 GB of RAM, 2 times 1 GB-stripes per CPU, (TRS21192-modules), PNY Quadro FX 3000 (NVidia), ICP GDT8114RZ RAID controller. The disk layout is: 2 disks in a RAID 0, with 70 GB ID 0 und 1 1 disk with 36 GB ID 2 Supermicro SCA backplane ID 6 During the installation process it seems that anaconda tries to partition the SCSI hotplug backplane: <4>Attached scsi disk sdc at scsi0, channel 2, id 6, lun 0 <4> SCSI device sda: 143347995 512-byte hdwr sectors (73394MB) <6> Partition check: <6> sda: unknown partition table <4> SCSI devic3e sdb: 71665965 512-byte hdwr sectors (36699MB) <6> sdb: unknown partition table <6>scsi: device set offline - not ready or command retry failed after bus reset: host 0 channel 2 id 6 lun 0 <4>sdc : READ CAPACITY failed. <4>sdc : status = 1, message = 00, host = 0, driver = 00 <4>sdc : sense not available. <4>sdc : block size assumed to be 512 bytes, disk size 1GB.. <6> sdc: I/O error: dev 08:20, sector 0 <4> I/O error: dev 08:20, sector 0 <4> unable to read partition table With U3 the customer gets a different error when loading the gdth driver with the option max_ids=3 to prevent access to the backplane. In that case the install fails after starting LVM (see attached logs). Version-Release number of selected component (if applicable): RHEL U2 How reproducible: Always Steps to Reproduce: 1. Use a system with ICP RAID controller similar to the description above. 2. Try to install RHEL3U2 x86_64 Actual Results: Installation fails after trying to partition the SCA hotplug backplane. Expected Results: Partition discs and install OS Additional info:
Created attachment 102640 [details] U3_install_max_ids-3_syslog Syslog from U3 installation with gdth option max_ids=3
Created attachment 102641 [details] U3_install_max_ids-3_anacondadump Anaconda dump from U3 installation attempt with gdth option max_ids=3
Hi, we are the ones with the problem and the aforementioned system. If there are any suggestions or things to try out (patches, special boot switches or alike) we are more then happy to try them out. TIA Roman Gugganig
Created attachment 102784 [details] Messages File with failed gdth driver attempts
Hi, FYI we have now tried an installation on a different SCSI-controller and putting in the ICP later. Now, I am able to load the gdth module, but it returns weird values for the backplane. Sometimes it´s recognized as a seperate harddisk, sometimes as a generic SCSI device. When it´s recognized as a HD, the first attempt to "fdisk -l /dev/sdb" freezes the machine immediately. Recognized as a generic device I get the chance to partition and mkfs on the disk, but after several I/O-operations on it (cp) the system freezes shortly after producing a bunch of errors, all looking like this: Aug 17 12:22:15 localhost kernel: EXT3-fs error (device sd(8,18)): ext3_new_block: Allocating block in system zone - block = 1409024 Aug 17 12:22:15 localhost kernel: EXT3-fs error (device sd(8,18)): ext3_new_block: Allocating block in system zone - block = 1409025 Aug 17 12:22:15 localhost kernel: EXT3-fs error (device sd(8,18)): ext3_new_block: Allocating block in system zone - block = 1409026 and so on and so on. It looks like the culprit IS the gdth driver itself. Attached messages-file should demonstrate what I mean.
UPDATE! After reviewing the first post I have a correction to add: The system has a total of 8Gb of RAM. When I remove 4Gb and install with only 4Gb installed, all works fine. I also tried to compile the driver from ICP, but the compilation-step breaks with errors, complaining about various mismatches etc. in the include files.
Using the 3.04 version of the gdth driver (as available from the manufacturer) fixes issues with > 4GB RAM machines. The driver is available from: http://www.icp-vortex.com/ftp/download/rz_neu/linux/drivers/gdth.tgz The current 2.6 upstream driver might even be better.
This driver has bugs in regards to handling of highmem (above the 4GB limit) memory pages. It attempts to copy from command buffers in highmem to locally allocated memory, but it fails to first kmap the address in case it is outside of the 4GB address space. There is a fix for this in the 2.6 upstream kernel, but unfortunately, that driver is markedly different from the one in the 2.4.21 kernel. It will require hand sorting not only the upstream 2.6 fix but also additional fixes to solve the problem. Deferred until U6.
RHEL3 is in deep maintenance mode at this point and no further updates, other than security issues, are planned. Closing this bug out.