Re: hpt374 sata (Highpoint Rocket 1540)
From: Sergei Shtylyov <hidden>
Date: 2007-08-01 13:38:52
Hello. Bartlomiej Zolnierkiewicz wrote:
quoted
quoted
quoted
quoted
I've had a Highpoint Rocket 1540 (not "RocketRAID") SATA controller for a while now, using a proprietary binary driver from Highpoint in a linux 2.4 kernel. The chipset is an hpt374. The hpt366 driver freezes on boot, as reported by others.
quoted
quoted
quoted
Can we see a bootlog please?
quoted
quoted
... and the output of 'lspci -v' too.
If possible, turn off that driver, rebuild the kernel, and reboot using
some other IDE driver (or NFS), then post that output...
quoted
The machine locks hard when the driver is loaded so I can't give a full transcription, but here is the driver's output:
quoted
HPT374: IDE controller at PCI slot 0000:00:0d.0 ACPI: PCI Interrupt 0000:00:0d.0[A] -> GSI 16 (level, low) -> IRQ 16 HPT374: chipset revision 7 HPT374: DPLL base: 48 MHz, f_CNT: 141, assuming 33 MHz PCI HPT374: using 50 MHz DPLL clock HPT374: 100% native mode on irq 16 ide2: BM-DMA at 0xec00-0xec07, BIOS settings: hde:DMA, hdf:pio ide3: BM-DMA at 0xec08-0xec0f, BIOS settings: hdg:DMA, hdh:pio ACPI: PCI Interrupt 0000:00:0d.1[A] -> GSI 16 (level, low) -> IRQ 16 HPT374: no clock data saved by BIOS HPT374: DPLL base: 48 MHz, f_CNT: 93, assuming 33 MHz PCI HPT374: using 50 MHz DPLL clock ide4: BM-DMA at 0xed00-0xed07, BIOS settings: hdi:DMA, hdj:pio ide5: BM-DMA at 0xed08-0xed0f, BIOS settings: hdk:DMA, hdl:pio
That "f_CNT: 93" on the 2nd HPT374 function looks *very* suspicious -- at
first I thought that DPLL is shared between 2 functions but the datasheet
denied it...
Well, the 1st function doesn't complain about the clock data being unsaved
by BIOS, so I guess it's only saved for this function, and for 2nd one the
driver resorts to reading the f_CNT register itself -- which is already spoilt
by the HPT BIOS' own DPLL calibration. Will post a patch to try soon...
quoted
The pata_hpt37x driver is refusing to work as well but it doesn't crash the machine. Here is the relevant error message:
quoted
hpt37x: DPLL did not stabilize. pata_hpt37x: BIOS has not set timing clocks. hpt37x: DPLL did not stabilize.
Does this patch change anything?
Heh, did you *really* hope it will? :-D
[PATCH] hpt366: always tune PIO
quoted hunk ↗ jump to hunk
Index: b/drivers/ide/pci/hpt366.c ===================================================================--- a/drivers/ide/pci/hpt366.c +++ b/drivers/ide/pci/hpt366.c@@ -1,5 +1,5 @@ /* - * linux/drivers/ide/pci/hpt366.c Version 1.10 Jun 29, 2007 + * linux/drivers/ide/pci/hpt366.c Version 1.11 Jul 29, 2007 * * Copyright (C) 1999-2003 Andre Hedrick <andre@linux-ide.org> * Portions Copyright (C) 2001 Sun Microsystems, Inc.@@ -1265,10 +1265,10 @@ static void __devinit init_hwif_hpt366(i if (new_mcr != old_mcr) pci_write_config_byte(dev, hwif->select_data + 1, new_mcr); - if (!hwif->dma_base) { - hwif->drives[0].autotune = hwif->drives[1].autotune = 1; + hwif->drives[0].autotune = hwif->drives[1].autotune = 1; + + if (hwif->dma_base == 0) return; - } hwif->ultra_mask = hwif->cds->udma_mask; hwif->mwdma_mask = 0x07;
Concerning the patch (I lacked time to look at the driver to refresh my
memory before -- was looking at the new Disk-on-chip H3 driver to be submitted
for comments soon, BTW): it makes little sense in its current form since
setting any DMA mode also sets 8-bit PIO timings now (and if DMA can't be set,
the driver will fallback to PIO anyway)
I have a patch that changes this behavior and switches to always
auto-tuning PIO but I've changed my mind on how the DMA/PIO timing register
sharing should be handled now -- however, since I was unable to come up with
anything better all that time, I'll consider pushing out this version when I
have a spare time...
WBR, Sergei