Hello.
Bartlomiej Zolnierkiewicz wrote:
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.
Can we see a bootlog please?
... 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...
The machine locks hard when the driver is loaded so I can't give a full
transcription, but here is the driver's output:
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...
The pata_hpt37x driver is refusing to work as well but it doesn't crash
the machine. Here is the relevant error message:
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
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@xxxxxxxxxxxxx>
* 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
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
