Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 227281 - F7T1 doesn't see pata disks attached to highpoint controller
Summary: F7T1 doesn't see pata disks attached to highpoint controller
Alias: None
Product: Fedora
Classification: Fedora
Component: kudzu
Version: rawhide
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
Blocks: FC7Blocker
TreeView+ depends on / blocked
Reported: 2007-02-04 17:51 UTC by Bruno Wolff III
Modified: 2014-03-17 03:05 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-05-20 23:36:04 UTC

Attachments (Terms of Use)
Anaconda crash dump (deleted)
2007-03-08 18:34 UTC, Bruno Wolff III
no flags Details
kudzu output (deleted)
2007-03-14 00:37 UTC, Bruno Wolff III
no flags Details
dmesg of the "unable to find root device" case (deleted)
2007-05-10 02:12 UTC, Allan Duncan
no flags Details
dmesg of a successful boot with usb stick plugged in (deleted)
2007-05-10 02:14 UTC, Allan Duncan
no flags Details

Description Bruno Wolff III 2007-02-04 17:51:50 UTC
Description of problem:
I tried to install F7T1 but neither of my disk drives were seen, so there was no
devices to install to.
My system has three different kinds of pata controllers. There are 2 "normal"
controllers on the motherboard which I use for DVD drives, which were
recognized. There are 2 promise controllers for doing crappy raid on the
motherboard which are unused. There are also two high point controllers in a
single pci card. Attached to this card are two WDC WD3200JB drives which were
not seen.
Looking at the syslog file on the ram disk I didn't see any evidence that the
highpoint controller was checked for attached drives. I did see messages that
suggested both the AMD and Promise controllers were checked. I think the three
types of controllers were all seen because the pata_hpt3x2n, pata_pdc2027x and
pata_amd kernel modules were all loaded.
I didn't save off the syslog file, but might be able to do it using a floppy or
a network device if you think that will help. I can also get you similar
information from when the system boots under FC5.

Version-Release number of selected component (if applicable):
I was using the Desktop DVD iso for F7T1.

How reproducible:

Steps to Reproduce:
1. Boot off of F7T1 DVD
2. Select install or upgrade
3. Select locale info
4. Get to the screen that asks about how to use disk space
Actual results:
No drives recognized

Expected results:
2 drives recognized

Additional info:

Comment 1 Bruno Wolff III 2007-02-06 08:32:12 UTC
This might be fixed in rawhide now, but I am not completely sure yet.
I tried booting off today's boot.iso (post 2.6.20 kernel in rawhide) and while I
got stuck for other reasons it did appear to be seeing my disk drives. I didn't
get far enough to be able to get to a shell, but when I tried selecting getting
images off a hard drive, both disks showed up. I got stuck there because it
wouldn't mount the partitions, but that will be a separate bugzilla.
With some more work I think I'll be able to test this further.

Comment 2 Bruno Wolff III 2007-02-07 04:17:17 UTC
I checked a bit more carefully and found that to 2.6.20 boot.iso is loading the
pata_hpt37x module instead of the pata_hpt3x2n and that is probably the difference.
So I am going to close this one.

Comment 3 Bruno Wolff III 2007-02-14 18:18:18 UTC
I am seeing a regression in development today. My controller card is back to
triggering the loading of the pata_hpt3x2 module instead of the pata_hpt37x
module and the pata_hpt3x2 module still isn't working. (I didn't do a lot with
the system using the hpt37x driver so I don't know how well it really works, but
at least I could read data off the drives when using it.)

The kernel version appears to be kernel-2.6.20-1.2925. I am not 100% sure as the
kernel in core isn't necessarily the same as on today's boot iso image and at
the point I can get to in the install I can't open a text window to play around.
Probably the kernels are the same though as I got both today.

The following is what I get when booting FC5 using the old IDE driver:
Feb 12 22:40:32 bruno kernel: HPT302: chipset revision 1
Feb 12 22:40:32 bruno kernel: HPT302: 100% native mode on irq 169
Feb 12 22:40:32 bruno kernel:     ide2: BM-DMA at 0xe400-0xe407, BIOS settings:
hde:DMA, hdf:pio
Feb 12 22:40:32 bruno kernel:     ide3: BM-DMA at 0xe408-0xe40f, BIOS settings:
hdg:DMA, hdh:pio
Feb 12 22:40:32 bruno kernel: hde: WDC WD3200JB-00KFA0, ATA DISK drive
Feb 12 22:40:32 bruno kernel: ide2 at 0xd400-0xd407,0xd802 on irq 169
Feb 12 22:40:32 bruno kernel: hdg: WDC WD3200JB-00KFA0, ATA DISK drive
Feb 12 22:40:32 bruno kernel: ide3 at 0xdc00-0xdc07,0xe002 on irq 169

lspci shows the following info about the controller card:
00:09.0 RAID bus controller: Triones Technologies, Inc. HPT302 (rev 01)

Comment 4 Bruno Wolff III 2007-02-23 21:43:34 UTC
I tested this again with today's rawhide (kernel 2.6.20-1.2940.fc7) and got the
hpt37x driver again and my disk drives were visible again. If this is the driver
I am supposed to get, then this can probably be closed, but if I am really
supposed to get the hpt3x2 driver than there is still at least one thing that
needs to be fixed.

Comment 5 Bruno Wolff III 2007-03-01 05:15:57 UTC
I retested this with today's rawhide and I am back to having things not work.
The kernel version is 2.6.20-1.2953.fc7 and the pata module I got was pata_hpt3x2n.

Comment 6 Bill Nottingham 2007-03-02 17:40:34 UTC
Moving to 'devel' as discussed on

Comment 7 Bruno Wolff III 2007-03-04 17:57:39 UTC
2960 is also getting the hpt3x2n driver which still doesn't work for me.
I'll probably get to try the latest kernel in rawhide tonight.
Below is more detailed lspci output for my highpoint controller:
00:09.0 RAID bus controller: Triones Technologies, Inc. HPT302 (rev 01)
        Subsystem: Triones Technologies, Inc. Unknown device 0001
        Flags: bus master, 66MHz, medium devsel, latency 120, IRQ 16
        I/O ports at d400 [size=8]
        I/O ports at d800 [size=4]
        I/O ports at dc00 [size=8]
        I/O ports at e000 [size=4]
        I/O ports at e400 [size=256]
        Expansion ROM at 88100000 [disabled by cmd] [size=128K]
        Capabilities: [60] Power Management version 2
00: 03 11 06 00 05 00 30 02 01 00 04 01 00 78 00 00
10: 01 d4 00 00 01 d8 00 00 01 dc 00 00 01 e0 00 00
20: 01 e4 00 00 00 00 00 00 00 00 00 00 03 11 01 00
30: 01 00 10 88 60 00 00 00 00 00 00 00 0b 01 08 08
40: 62 dc 6d 1c a7 4e 81 06 62 dc 6d 1c a7 4e 81 06
50: 05 00 00 00 05 00 00 00 1b 00 00 23 20 00 24 00
60: 01 00 22 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 5d 00 f0 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Comment 8 Bruno Wolff III 2007-03-08 18:09:17 UTC
I tested this again this morning, with both this morning's and yesterday's
boot.iso which covered kernel versions 2967 and 2975, and got the same results
as the last time. pata_hpt3x2n was installed and neither of my PATA drives
showed up in /dev or places I looked.

Comment 9 Bruno Wolff III 2007-03-08 18:34:34 UTC
Created attachment 149602 [details]
Anaconda crash dump

I got an anaconda crash dump from another problem I was having and figured it
might have useful information about my hardware for resolving this problem, so
I am going to attach it here as well as the other bug report.

Comment 10 Bruno Wolff III 2007-03-12 18:27:39 UTC
I am still getting pata_hpt3x2n loaded, but no disks are being seen on this
mornings boot.iso which is using the 2982 kernel.

Comment 11 Alan Cox 2007-03-13 02:42:53 UTC
Moving to anaconda. hpt_3x2n doesn't handle the 302

Comment 12 Chris Lumens 2007-03-13 14:59:08 UTC
Can you drop to tty2 and attach to this bug report the results of:

python -c "import kudzu ; print kudzu.probe(kudzu.CLASS_RAID|kudzu.class_SCSI,
kudzu.BUS_UNSPEC, kudzu.PROBE_ALL)"

Comment 13 Bruno Wolff III 2007-03-13 17:41:44 UTC
I should be able to do this tonight.
The machine is actually at my old house (I am in the process of moving), but I
expect to be going there tonight, and it won't take long to do that test.

Comment 14 Bruno Wolff III 2007-03-13 17:48:00 UTC
I meant to leave the status as needinfo, as the last comment was just FYI, not
the answer to the question being asked.

Comment 15 Bruno Wolff III 2007-03-14 00:37:30 UTC
Created attachment 150007 [details]
kudzu output

The command as given wasn't exactly correct. I changed the case of 'class' to
get it to work.

Comment 16 Bruno Wolff III 2007-03-14 03:27:14 UTC
I retested this on a boot.iso version from early March 13th and goit the same

Comment 17 Bill Nottingham 2007-03-14 18:59:05 UTC
If hpt_3x2n doesn't handle the 302,why does it claim to via PCI ids?

Comment 18 Alan Cox 2007-03-14 19:12:06 UTC
The 302N has the same PCI ID as the 302 but different revision ID,  ditto
371N/372N etc, and some of them can masquerade as hpt366 in some cases too.

I'd suggest if you see an HPT  matching 37x 3x2n or 366 you load all 3 modules
if you want an easy life

Comment 19 Bruno Wolff III 2007-03-14 19:26:33 UTC
And note, that the hpt37x module did seem to work for my card when it got loaded.

Comment 20 Bruno Wolff III 2007-03-31 22:59:43 UTC
I am now getting the hpt37x driver (with the boot iso from Friday (March 30)
morning). I suspect that this has to do with the kudzu change that uses the most
narrow match rather than the first match, so other people might start having

Comment 21 Alan Cox 2007-04-01 17:57:09 UTC
Until it loads all the hpt modules matching the PCI ID this is going to happen.
Fix is as per #18, just needs someone to apply it and should all work out
providing the driver isnt buggy (which alas we've yet to find out because of
this bug)

Comment 22 Bruno Wolff III 2007-04-02 14:16:23 UTC
Well the driver at least works somewhat. I was able to install F7 using a
snapshot from Friday. I didn't run it very long, but did try some stuff using it
after the install. I didn't see anything that would have indicated a disk
problem. But I didn't stress the disks much either.

Comment 23 Bill Nottingham 2007-04-14 00:02:21 UTC
Was looking at the logic in the kernel today:

in pata_hpt37x:
                        case PCI_DEVICE_ID_TTI_HPT372:
                                /* 372N if rev >= 2*/
                                if (class_rev >= 2)
                                        return -ENODEV;
                                port = &info_hpt372;
                                chip_table = &hpt372a;

in pata_hpt3x2n:
                case PCI_DEVICE_ID_TTI_HPT372:
                        /* 372N if rev >= 1*/
                        if (class_rev == 0)
                                return -ENODEV;

This implies that if class_rev == 1, *both* drivers will try to attach, and it
will depend on module load order. Is this correct?

Comment 24 Bill Nottingham 2007-04-14 00:15:24 UTC
Initial patch committed in 1.2.68-1. Will require that anaconda is rebuilt
against this version for anything to happen in the installer.

Comment 25 Bruno Wolff III 2007-04-14 15:27:43 UTC
When the boot iso, anaconda and kudzu are ready for this to be retested, let me
know and I can test one of the cases. Since things are currently working for me
(using an April 13 snapshot), I won't notice unless something breaks.

Comment 26 Alan Cox 2007-04-17 15:24:34 UTC
Good question. Right now for 372N rev == 1 I don't actually know, and I've not
seen hardware to test this corner case (no docs for it either). 

Comment 27 Alan Cox 2007-04-17 17:12:54 UTC
Ok rev 0 is HPT372 rev 1 is HPT372 rev 2 is HPT372N

Comment 28 Allan Duncan 2007-05-08 14:36:09 UTC
I have a similar problem with FC7 test 4 Live not booting:
Motherboard ide handled by nvidia MCP2A with CD on ide0secondary DVD on
ide1primary, and Silicon Image 0680 pic with HDs on ide0p and ide1p.
Initial boot hardware scan finds both ide devices (pata_amd and pata_sil680) and
the drives themselves, allocates scsi0 - scsi3 and ata1 - ata4, but only creates
/dev/sda and /dev/sdb for the HDs.  Naturaly the boot process hangs for lack of
a root device, since the CD has no device.

Comment 29 Allan Duncan 2007-05-10 02:12:19 UTC
Created attachment 154448 [details]
dmesg of the "unable to find root device" case

Comment 30 Allan Duncan 2007-05-10 02:14:34 UTC
Created attachment 154449 [details]
dmesg of a successful boot with usb stick plugged in

Comment 31 Allan Duncan 2007-05-10 02:24:11 UTC
I have succeeded in getting a boot by having a usb stick inserted at the time,
using the CD or the DVD-RW, reliably. The dmesg logs are above for both fail and
pass.  Since the usb is mountable from the initrd shell, I can run any needed
commands from it that aren't in initrd.
Ask, and you shall receive.

Comment 32 Bill Nottingham 2007-05-10 02:30:49 UTC
Allan - Please file this as a different bug - it's not related to this issue.

Comment 33 Alan Cox 2007-05-10 10:14:31 UTC
Log shows this is a kudzu bug in #29 - the hpt driver isn't even in the log so
doesn't appear to get loaded.

Comment 34 Allan Duncan 2007-05-10 11:17:58 UTC
Sorry Alan, #28 - 31 are my submissions related to pata_amd that I saw as a
similar issue.  I've created a new bug (239757) as Bill requested and am in the
process of populating it with log files.

Comment 35 Jeremy Katz 2007-05-18 15:55:17 UTC
Bruno -- was this resolved with test4?

Comment 36 Bruno Wolff III 2007-05-18 16:27:20 UTC
I can't say for sure, since I only see half of the problem. I have been getting
the proper module loaded for a while, though I don't specifically remember if it
was before or after test4. I am fairly sure I saw both drivers getting loaded at
some point. This seemed to be consistant with the previous discussions about
loading both drivers and having the kernel check.
I will probably attempt another practice install this weekend, though I might
have issues because of the merge making the distribution to big to fit on one
DVD. I am not using pungi (yet), and had been just plopping everything on one
DVD and fudging .discinfo to get it to work. I might still be able to do
something like that.
Anyway, if I do do one, I'll take a look at what modules get loaded.

Comment 37 Jeremy Katz 2007-05-18 17:46:38 UTC
If both modules are getting loaded, then it sounds like things should be good. 
I'm going to stick the bug in MODIFIED accordingly.  When you can verify, either
bump to closed or reopen it.

Comment 38 Bruno Wolff III 2007-05-18 18:30:17 UTC
At the very least, I'll use one of my older iso images to do a test install. I
have test4 and a post test4 premerge iso image that I can use to verify whether
or not both modules get loaded.

Comment 39 Bill Nottingham 2007-05-18 18:55:49 UTC
The current code should be fixed to load only the *right* driver in anaconda.
udev will probably load all of them, and only the right one will attach.

Comment 40 Alan Cox 2007-05-18 23:29:57 UTC
Would be nice Bill but telling which is which isn't doable just on PCI space
information you have to grovel around and know what is up. The old kernel lumped
all the driver variants into one module so hid the issue. The new one loads both
which has the same effect..

Comment 41 Bill Nottingham 2007-05-19 00:25:49 UTC
It's using the same logic (vendor, device, revision id) that's in the drivers.
What exactly else is it supposed to do?

Comment 42 Alan Cox 2007-05-19 12:13:45 UTC
Actually for 366 upwards you are right, you can just use classrev. Too many
controllers too little time. So yes if you are using vendor/device/rev you'll be
able to pick the right driver.

Comment 43 Bruno Wolff III 2007-05-20 23:36:04 UTC
I did get to test this today using a rawhide from April 28th (which is right
around when test4 came out) and anaconda used just the module for my controller
(pata_hpt37x) and when running the installed versions both modules (pata_hpt37x
and pata_hpt3x2n) were loaded and the disks worked normally.
Based on comment 37, I am going to close this.

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