Bug 242270 - F7 installer does not find HPT370A, disks
F7 installer does not find HPT370A, disks
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kudzu (Show other bugs)
7
All Linux
low Severity high
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-02 17:31 EDT by Ville Skyttä
Modified: 2014-03-16 23:07 EDT (History)
1 user (show)

See Also:
Fixed In Version: 1.2.71.1-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-21 16:03:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output from a working FC6 setup (15.78 KB, text/plain)
2007-06-02 17:31 EDT, Ville Skyttä
no flags Details
Candidate fix (760 bytes, patch)
2007-06-04 19:02 EDT, Ville Skyttä
no flags Details | Diff

  None (edit)
Description Ville Skyttä 2007-06-02 17:31:56 EDT
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
Comment 1 Ville Skyttä 2007-06-02 17:31:56 EDT
Created attachment 155998 [details]
dmesg output from a working FC6 setup
Comment 2 Ville Skyttä 2007-06-03 11:05:18 EDT
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.
Comment 3 Ville Skyttä 2007-06-04 11:52:27 EDT
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?
Comment 4 Sergei Shtylyov 2007-06-04 12:55:51 EDT
(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? :-)
Comment 5 Bill Nottingham 2007-06-04 14:17:28 EDT
See the code in pci.c - it *already* distinguishes by PCI revision, and, in
fact, should be loading pata_hpt37x for your device.
Comment 6 Ville Skyttä 2007-06-04 16:06:00 EDT
# 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
-
[...]
Comment 7 Sergei Shtylyov 2007-06-04 16:18:13 EDT
(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...
Comment 8 Bill Nottingham 2007-06-04 17:22:36 EDT
(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.
Comment 9 Ville Skyttä 2007-06-04 19:02:08 EDT
Created attachment 156152 [details]
Candidate fix

Appears to be a problem with unwanted switch fallthrough.  The attached patch
fixes it for me.
Comment 10 Bill Nottingham 2007-06-04 20:00:04 EDT
Oh duh. Thanks.
Comment 11 reijo.korhonen 2007-06-16 19:08:18 EDT
(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?
Comment 12 Fedora Update System 2007-06-21 16:03:30 EDT
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.
Comment 13 reijo.korhonen 2007-07-14 19:10:07 EDT
(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.

Comment 14 Bill Nottingham 2007-07-16 13:51:57 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.