Bug 242270

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.