Trying to install F7 from scratch on a box that has the HighPoint HPT370(A?) controller (in addition to a regular PIIX) one fails - the installer doesn't appear to find the controller at all, let alone disks attached to it. Maybe a kernel 2.6.21 issue? A bit of googling tells me that some HighPoint PATA stuff has changed in it. This is an Abit TH7-II RAID motherboard, no "RAID" configured. There's a DVD drive attached to the PIIX controller (hda) and a Samsung PATA disk to the HPT370 (hde), no other disks or IDE devices, no SATA. I've had various Fedora versions installed in this box before without problems, including a current working FC6 setup. dmesg from it attached. lspci -nv says about the controller: 02:06.0 0180: 1103:0004 (rev 04) Subsystem: 1103:0001 Flags: bus master, 66MHz, medium devsel, latency 120, IRQ 16 I/O ports at a400 [size=8] I/O ports at a800 [size=4] I/O ports at ac00 [size=8] I/O ports at b000 [size=4] I/O ports at b400 [size=256] Expansion ROM at 30000000 [disabled by cmd] [size=128K] Capabilities: [60] Power Management version 2
Created attachment 155998 [details] dmesg output from a working FC6 setup
Problem appears to be that the installer tries to use pata_hpt3x2n for this controller instead of pata_hpt37x. Worked around locally by connecting the drive to the ata_piix interface for duration of the installation, and after it tweaking things to use pata_hpt37x instead of pata_hpt3x2n and recreating initrd.
Looks like all pata_hpt366, pata_hpt37x and pata_hpt3x2n in kernel match the "main" PCI id of this controller (ended up blacklisting pata_hpt366 and pata_hpt3x2n). Perhaps the subsystem ID could be used to distinguish between these?
(In reply to comment #3) > Looks like all pata_hpt366, pata_hpt37x and pata_hpt3x2n in kernel match the > "main" PCI id of this controller (ended up blacklisting pata_hpt366 and > pata_hpt3x2n). Perhaps the subsystem ID could be used to distinguish between these? Unfortunately, there's no clear info on distinuishing via subsystem ID. These chips are really distinguishable via revision ID -- blame HighPoint for the stupidest design decision. Looks like another point for my suggestion to merge pata_hpt37x and pata_hpt3x2n? :-)
See the code in pci.c - it *already* distinguishes by PCI revision, and, in fact, should be loading pata_hpt37x for your device.
# rpm -q kudzu kudzu-1.2.71-1 # /sbin/kudzu -p - class: OTHER bus: PCI detached: 0 driver: pata_hpt3x2n desc: "Triones Technologies, Inc. HPT366/368/370/370A/372/372N" vendorId: 1103 deviceId: 0004 subVendorId: 1103 subDeviceId: 0001 pciType: 1 pcidom: 0 pcibus: 2 pcidev: 6 pcifn: 0 - [...]
(In reply to comment #6) > # rpm -q kudzu > kudzu-1.2.71-1 > # /sbin/kudzu -p > - > class: OTHER > bus: PCI > detached: 0 > driver: pata_hpt3x2n > desc: "Triones Technologies, Inc. HPT366/368/370/370A/372/372N" > vendorId: 1103 > deviceId: 0004 > subVendorId: 1103 > subDeviceId: 0001 Yeah, 11030001 is the default subsystem ID for HPT370. > pciType: 1 > pcidom: 0 > pcibus: 2 > pcidev: 6 > pcifn: 0 > - > [...] Maybe judzu should take revision ID into account. That makes sense for some Ethernet cards too, namely RTL8139 based for which there are 2 drivers...
(In reply to comment #7) > Maybe judzu should take revision ID into account. That makes sense for some > Ethernet cards too, namely RTL8139 based for which there are 2 drivers... It already does have code for both of these things (as stated above)... the rtl8139 code's been in there for years. Unfortunately, I do not have hardware to test this - you'll need to fire up a debugger and check what's going on.
Created attachment 156152 [details] Candidate fix Appears to be a problem with unwanted switch fallthrough. The attached patch fixes it for me.
Oh duh. Thanks.
(In reply to comment #7) > (In reply to comment #6) > > # rpm -q kudzu > > kudzu-1.2.71-1 > > > # /sbin/kudzu -p > > - > > class: OTHER > > bus: PCI > > detached: 0 > > driver: pata_hpt3x2n > > desc: "Triones Technologies, Inc. HPT366/368/370/370A/372/372N" > > vendorId: 1103 > > deviceId: 0004 > > subVendorId: 1103 > > subDeviceId: 0001 > > Yeah, 11030001 is the default subsystem ID for HPT370. > > > pciType: 1 > > pcidom: 0 > > pcibus: 2 > > pcidev: 6 > > pcifn: 0 > > - > > [...] > > Maybe judzu should take revision ID into account. That makes sense for some > Ethernet cards too, namely RTL8139 based for which there are 2 drivers... I have same problem with Abit PB6 and HPT366. Installer does not see my hard drives. - /usr/sbin/kudzu -p class: OTHER bus: PCI detached: 0 driver: unknown desc: "Triones Technologies, Inc. HPT366/368/370/370A/372" vendorId: 1103 deviceId: 0004 subVendorId: 0000 subDeviceId: 0000 pciType: 1 pcidom: 0 pcibus: 0 pcidev: 13 pcifn: 0 It's not convenient so open machine and change hard drives to some other connection, because I use my dvd there etc. Is there a way to work around of this in installation? Before there was "device driver" disks in Red Hat installation in use in this kind of situations. How to do this that way? Or when running installer in text mode, can I take text console and load right module in the start of installing process? But if I manage installing some how, how in practice I make initrd to fix this problem? I can't start installed kernel, because it can't be found with out php366 module and I must run that kernel to make initrd? What are the concrete steps to do the initrd?
kudzu-1.2.71.1-1 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #12) > kudzu-1.2.71.1-1 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report. OK. So I have in my F7 installation .iso old version of the kudzu with the problen and in the repository new version of the kudzu which should work OK in the installation. But how I can anaconda to run this version of the kudzu? Should I unpack F7 installation .iso and replace kudzu with newer version and pack .iso again and burn dvd again or how? Can you give me a link how to do this, I'm not so deep with the installation program to proceed myself without hint how to install F7 with HPT366 machine using this fix in the repository.
You would have to use pungi to respin the tree, or wait for a group like Fedora Unity (http://www.fedoraunity.org/) to do a respin of F7.