Bug 227281

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.

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.

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)

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.

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.

Moving to 'devel' as discussed on
https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00095.html.

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

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.

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.

I am still getting pata_hpt3x2n loaded, but no disks are being seen on this
mornings boot.iso which is using the 2982 kernel.

Moving to anaconda. hpt_3x2n doesn't handle the 302

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)"

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.

I meant to leave the status as needinfo, as the last comment was just FYI, not
the answer to the question being asked.

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.

I retested this on a boot.iso version from early March 13th and goit the same
problem.

If hpt_3x2n doesn't handle the 302,why does it claim to via PCI ids?

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

And note, that the hpt37x module did seem to work for my card when it got loaded.

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
problems.

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)

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.

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;
                                break;

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

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

Initial patch committed in 1.2.68-1. Will require that anaconda is rebuilt
against this version for anything to happen in the installer.

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.

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). 

Ok rev 0 is HPT372 rev 1 is HPT372 rev 2 is HPT372N

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.

Created attachment 154448 [details]
dmesg of the "unable to find root device" case

Created attachment 154449 [details]
dmesg of a successful boot with usb stick plugged in

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.

Allan - Please file this as a different bug - it's not related to this issue.

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.

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.

Bruno -- was this resolved with test4?

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.

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.

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.

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.

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..

It's using the same logic (vendor, device, revision id) that's in the drivers.
What exactly else is it supposed to do?

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.

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.