Description of Problem: Install hangs on computers having 3w-6XXX 3Ware RAID boards. (3w-xxxx driver fails). This problem was already described in detail [ see bugs: 51214, 54936, 55086 - detailed error description] Using Redhat Errata updates floppy was supposed to solve the problem: well it does, almost: - updates floppy solves the problem for disks having ODD number of sectors - computers with disks having EVEN number of sectors still fail to install with exactly same error How Reproducible: Try to install RH 7.2 with updates floppy on a computer having disks with EVEN number of sectors. Additional comment: - Will parted package be updated to correct that problem ? - I mean , updates floppy for anaconda is nice, but my organization uses network installs mostly , thus we have to rebuild the whole Redhat install tree with corrected libparted binary ...
Jeremy please look at this since it affects a recently released errata.
The ioctl() was only ever used on disks with an odd number of sectors as you can correctly read the last sector of the disk without a special ioctl() otherwise. Are you sure this is the same thing which is happening? Also, working on a way to make it easier to do updates with kickstart for the next batch of updates
Well... I cannot tell what is used to read last sector of a device as Redhat has not released source of the patch published as errata floppy .... What I can tell: We have (a quite big number of) machines having following configurations; 3Ware 62XX boards and following disks: (text below comes from anaconda text screen) <4>SCSI device sda: 40130456 512-byte hdwr sectors (20547MB) <4>SCSI device sdb: 156299441 512-byte hdwr sectors (80025MB) ... (7-11 more disks of same type as sdb) While trying to partition SDA (WITH updates floppy): 3w-xxxx: tw_interrupt(): Bad response, status = 0xc1, flags = 0x11, unit =0x0. 3w-xxxx: tw_scsi_eh_reset(): Reset succeeded for card 1. 3w-xxxx: tw_interrupt(): Bad response, status = 0xc1, flags 0x11, unit 0x0. scsi: device set offline - not ready or command retry failed after host reset: host 0 channel 0 id 0 lun 0 SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 80000 I/O error: dev 08:00, sector 40130454 (partitioning sdb and subsequent drives works then as expected: it was failing too without updates floppy, with get_last_sector ioctl: bread returned NULL, what was corrected) The drive at sda is certainly not the problem , it can be partitioned, formatted and used properly with IDE controller different than 3w-xxxx (and I've tested on 3 different drives of that type). So looking at above : sda has even number of sectors: 40130456 and libparted seems to trigger the problem ... sdb has odd number of sectors: 156299441 and patched (by errata floppy) libparted using special ioctl() to read last sector works ...
Created attachment 42379 [details] 3w-xxxx version 1.02.00.015 from 2.14.18-pre2
The solution to the described problem seems to be upgrading 3w-xxxx driver to at least version 1.02.00.012 in the boot kernel tree. (then rebuild boot kernel , then install tree) Quick test shows that with this upgrade even without updates floppy partitioning on both even and odd sized disks attached to 3ware 6xxx controller works correctly. (see comments in patch file) Attached patch is from kernel-2.4.18-pre2 sources, to be applied after all patches touching 3w-xxxx.c and 3w-xxxx.h files.
So should I take it that a driver disk with the new driver makes things work? If so, I'll pass it on to the kernel team to make sure the version of the driver in our kernel gets upgraded.
Well, haven't tried with driver disk, just rebuilt all install tree, and tried installation over NFS from that tree (bootnet.img was rebuilt as well) The potential problem with driver disk update would be automated kickstart installations: user has to insert additional disk manually .. not very practical on 100 (or more) nodes ... Will anaconda take the updated 3w-xxxx driver from driver disk instead of taking it from first (or second, don't remember) stage image ? The real solution would have been to release updated kernel package, this would allow people to rebuild their own install trees cleanly. Jaroslaw
Yes, it will use the one from the driver disk instead. Reassigning to kernel so that Arjan can make sure the updated driver gets into our future kernels
Rawhide kernels are at 2.4.18pre3 so will have this driver already for future versions of Red Hat Linux.