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 <[EMAIL PROTECTED]> * 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
